Opublikowane w

Mail RBL checker (Python)

Tak się zdarzyło w ostatnim czasie, że w paru miejscach pojawiły się problemy z dostarczaniem maili. Prawdopodobna przyczyna niedocierania poczty była ta sama – obecność IP serwera pocztowego na RBL. Przypomniały mi się stare czasy i walka z wypisywaniem IP z RBL oraz różne metody zapobiegania dostawania się na RBLe.

Zanim jednak zaczniemy cokolwiek robić, trzeba wiedzieć, że jesteśmy na RBLu, czyli monitorować obecność IP serwera pocztowego na RBL. Do szybkich, ręcznych, doraźnych sprawdzeń pojedynczych IP polecam stronę Multi-RBL Check, nie rozwiązuje to jednak tematu ciągłego, automatycznego monitoringu obecności IP na RBLach, np. przy pomocy Zabbiksa.

Sam monitoring jest trywialny – wystarczy odpytywać przy pomocy DNS, warto to jednak jakoś „opakować”. Napisałem to ze dwa razy w życiu (IIRC oba w Perlu), napiszę więc i trzeci, tym razem w Pythonie. Oczywiście podobnych rozwiązań na GitHubie jest wiele, ale w każdym coś mi nie pasowało – albo język, albo rozbudowane zależności, albo sposób przekazywnia informacji. To ostatnie to w sumie detal, łatwo można przefiltrować informacje przy pomocy grep lub awk.

W każdym razie, wczoraj opublikowałem mail-rbl-monitor. Zdecydowanie nie jest skończony, a struktura wynika z przygotowania pod przyszłe funkcje. Znaczy sprawdzanie listy IP pobieranej z pliku.

Wkrótce temat pokrewny, ale nieco trudniejszy – monitoring reputacji IP serwerów pocztowych.

Opublikowane w

Waze jako nawigacja

Jakiś czas temu wyrzuciłem Yanosika z telefonu, z powodu fatalnej nawigacji. Zgodnie z zapowiedziami szansę dostało Waze.

Podobnie jak Google Maps, nawigacja Waze należy do Google, jednak jest rozwijana odrębnie i ma zupełnie inną filozofię. O ile Google Maps to sucha, dość sprawna nawigacja, o tyle Waze bardziej przypomina ficzerami Yanosika – personalizacja i gamifikacja jak najbardziej obecne. Jest możliwość zgłaszania przez użytkowników utrudnień na drodze, czy to patroli policyjnych, czy radarów, czy zamkniętych ulic, czy zwykłych prac drogowych. Jest też zbieranie punktów za aktywność.

Logo WazeŹródło: https://www.waze.com/about/press_resources

Pierwszą recenzję Yanosika pisałem po przejechaniu raptem 300 km, czyli – jak patrzę z perspektywy – o wiele za wcześnie. W przypadku Waze testowałem nieco dłużej – przejechałem ok. 1000 km na zalogowanym koncie, głównie w mieście. Nadal mało jak na pełny test, ale od czegoś trzeba zacząć. Tak naprawdę z Waze przejechałem ze dwa albo trzy razy tyle – dość długo korzystałem bez założonego konta i logowania. Można i tak, bez specjalnego uszczerbku dla funkcjonalności. Oczywiście gamifikacja leży wtedy, nie działa też zapamiętywanie ustawień, przynajmniej między upgrade/reinstalacją. W każdym razie z kontem jest lepiej i na tej wersji się skupię.

Pierwsza rzecz, która rzuca się w oczy po uruchomieniu Waze, to ekspozycja funkcji związanych z nawigacją i ukrycie całej reszty. Zaleta jest taka, że nawigacja jest na wierzchu, wada zaś taka, że dobrnięcie do jakichś bardziej zaawansowanych ustawień chwilę mi zajęło. Części rzeczy w ogóle w aplikacji nie ma (albo nie umiem ich znaleźć), przykładem może być ilość przejechanych kilometrów, którą sprawdzam przez WWW. Trudno mi jednoznacznie orzec, czy to zaleta, czy wada. Ustawienia domyślne są bardzo dobre.

Aplikacja potrzebuje dłuższego czasu od włączenia do gotowości do działania. Nie wiem, czy jest to kwestia słabszego telefonu, czy tak jest ogólnie ale… tak jest i jest to wada. Dodam, że podobnie ma Strava. Za to po włączeniu jest już bardzo przyjemnie. Nawigacja jest pewna (sorry, Yanosik), komunikaty przekazywane z sensownym wyprzedzeniem (sorry, Yanosik), adaptacja do zmian trasy szybka (sorry, Yanosik, „zawróć. zawróć. zawróć.”). Bardzo ładnie mówi po polsku (jest wybór lektora) i posiada rewelacyjną IMO funkcjonalność podawania nazw ulic, w które należy skręcić – podaje nie tylko kierunek skrętu, ale też nazwę.

Trasy wybiera sensownie (sorry Yanosik), orientacyjne czasy dojazdu bardzo zbliżone do rzeczywistych. Potrafi też pokazywać informacje o natężeniu ruchu na sąsiednich ulicach czy zaproponować alternatywne trasy do właśnie wybranej. Taki powiew Google Maps. Akurat średnio korzystam, ale ktoś ze znajomych szukał nawigacji pokazującej natężenie ruchu.

Największą wadą nawigacji, którą zauważyłem, jest dość częste gubienie się na skrzyżowaniach po zatrzymaniu. Potrafi stwierdzić, że jesteśmy na ulicy prostopadłej i kazać skręcać. Chwilę po ruszeniu i chwilę przed dojazdem do skrzyżowania jest OK. Nie wiem, czy kwestia aplikacji, czy telefonu i… nie jest to tak upierdliwe na jakie wygląda z opisu – informacja o skręcie jest podawana za późno, by wykonać manewr.

Zgłaszanie zdarzeń na drogach jest znacznie bardziej szczegółowe niż w Yanosiku, ale przez to bardziej skomplikowane. Nie jest to jedno kliknięcie, tylko kolejne wybory (polecam lekturę opisu w FAQ). Być może kwestia przyzwyczajenia, na pewno większa bariera wejścia i trudniejsze, wymagające więcej uwagi zgłaszanie zdarzeń. Liczę jako wadę, pewnie dobrą sprawą byłby wybór wersji pełnej i uproszczonej.

Kolejny ficzer Waze to wyszukiwanie stacji benzynowych i porównywanie cen. W przeciwieństwie do Yanosika, Waze nie współpracuje z jednym koncernem, więc jest wybór. I jakiś pożytek dla tych, którzy raczej omijają rządowe stacje. Samo porównywanie jest oparte o aktualizacje cen przez użytkowników, więc traktować należy raczej orientacyjnie, bo stacje dość często zmieniają ceny. Na szczęście przy wyszukiwaniu jest podawany czas ostatniej aktualizacji.

Inny miły ficzer to proponowanie miejsc docelowych. Czyli uruchamiamy nawigację i dostajemy – na podstawie czasu (i miejsca?) – propozycję, żeby ustawić jako miejsce docelowe pracę, bez konieczności wyboru ręcznie. Dość przyjemne, działa nieźle. Oczywiście gdyby ktoś czuł się śledzony, to można tę opcję wyłączyć. Raczej ku poprawie samopoczucia, bo śledzi nas każda nawigacja. 😉 Wyłączyć można też widoczność naszego pojazdu na mapach.

Jeszcze inne usprawnienia to zapamiętywanie miejsca pozostawienia pojazdu (można też zrobić zdjęcie, przydatne, jeśli z auta korzysta kilka osób) czy przesłanie orientacyjnego czasu dojazdu.

Pominąłem inne ficzery Waze, niezwiązane z samą aplikacją, typu live map czy carpooling. Raz, ze wykraczają poza badane zagadnienie, dwa, że nie używam. Podsumowując, uważam, że aplikacja jest zdecydowanie godna uwagi i warto dać jej szansę. W mieście jako nawigacja sprawdza się bardzo dobrze, kiedyś pewnie uzupełnię wpis o wrażenia z trasy.

UPDATE Przejechałem 2300 km, parę razy poza miastem (choć na znanej drodze) – nadal OK, stacjonarne radary zgłasza, na nic innego nie było okazji. Nadal nie mam powodu do narzekania.

Opublikowane w

Goodbye Yanosik!

Nie napisałem nic o tegorocznym urlopie. W zasadzie urlopach. W ramach nadrobienia zaległości spojrzenie na urlopy przez pryzmat appek androidowych. Zmiany są dwie: zacząłem korzystać ze Strava – ot, kolejna appka do mierzenia biegania czy pedałowania. W sumie poznałem ją, gdy oficjalna appka Kręć Kilometry przestała mi poprawnie i stabilnie działać, zwł. zapisywać trasę. Zalety: dość dokładna, fajne automagiczne porównywanie czasów na odcinkach, liczenie rekordów. Wady: dość długo „się zbiera” do wykonania operacji, czyli czasami trzeba poczekać. Ale potem działa już pewnie, więc lubię.

Zmiana druga wymaga wstępu. Na jednym z wakacyjnych wyjazdów, przed podróżą powrotną do Poznania, zaczęło się kończyć paliwo. Poszukałem stacji, zjechałem parę kilometrów w nieznany teren, zatankowałem. I wracam, wg nawigacji, tak samo zresztą jak przyjechałem. O dziwo inna trasa, niż przyjechałem, ale nie wnikam – na oko kierunek się zgadza.

Więc jadę sobie drogami między wioskami. Pasażerowie przysypiają. I nagle widzę rozjazd. Asfalt lekkim łukiem w lewo, na wprost nawierzchnia szutrowa. Nawigacja zdecydowanie pokazuje jazdę na wprost, po szutrowej. Azymut się zgadza, wiec trochę zwalniam i wjeżdżam w tę szutrową. Chwilę później ostre hamowanie, bo okrutna dziura, idealna, by urwać koło. Dobrze, że zwolniłem wjeżdżając na tę szutrową. Jadę dłuższy kawałek, dziur wcale nie ubywa. Potem było jeszcze lepiej – gruntówka w lesie, ogromne kałuże na całą szerokość. Jakoś uniknąłem zakopania czy utopienia auta i przejechałem, ale było to ładne parę kilometrów. Dodam, że w poprzednią stronę przyjechałem całą drogę zupełnie znośnym asfaltem.

Nawigacja, która mnie tak poprowadziła to oczywiście Yanosik. Stwierdziłem, że enough is enough, tym bardziej, że to nie pierwszy tego typu wyczyn, choć w tym przypadku skala porażki zadziwiła. Dodatkowo Yanosik grabił sobie u mnie już wcześniej zbieraniem dużej ilości danych („styl jazdy”) i próbą monetyzacji tej wiedzy w formie sprzedaży ubezpieczenia. Nie mam złudzeń, w tej grze kierowca traci – algorytmy i big data dają przewagę ubezpieczycielowi. O ile w przypadku cech ogólnych liczy się statystyka, to dane o stylu jazdy pozwalają na wnioskowanie poza granicą ludzkiej percepcji. Czyli software ubezpieczyciela zna lepiej zachowania kierowcy niż on sam. I jeśli stwierdzi, że jeździsz o niebezpiecznych porach, to nie tylko nie dostaniesz zniżki, ale jeszcze dopłacisz, nawet jeśli jeździsz bezpiecznie. Na dodatek nie informują, co dokładnie jest mierzone. Oczywiście nie wyraziłem zgody, ale sam fakt możliwości zbierania takich danych jest niepokojący. Pytanie o zgodę było ponawiane – liczą na to, że użytkownik się pomyli i kliknie, że się zgadza?

W każdym razie po tej akcji z nawigacją Yanosik wyleciał w trybie ekspresowym, po przejechanych z nim jakichś 20 tys. Oczywiście potrzebuję dość często nawigacji, więc użyłem tego, co miałem pod ręką – Google Maps. Korzystałem kiedyś dawno temu przez chwilę i albo nie doceniałem, albo spory postęp zrobili.

Pierwsze wrażenie: Yanosik dawał instrukcje trochę za późno czasami (do tego stopnia, że zdarzało mi się nie skręcić we właściwą ulicę), Google Maps radzi sobie o wiele lepiej, informując z sensownym wyprzedzeniem. Do tego ma przyjemny ficzer w postaci zmiany skali w zależności od aktualnej prędkości. Nie ukrywam, że przestawienie się i przyzwyczajenie do dobrego zajęło mi chwilę. Różnica jest kolosalna – Google Maps potrafi pokazywać pasy, dawać drobne wskazówki gdzie odbić, co jest bardzo przydatne na węzłach na autostradach. Za to przyznaję, że na rondach Yanosik radził sobie lepiej, choć też nie idealnie.

Brakuje oczywiście głównej funkcji Yanosika, czyli „antyradaru”, nie ma całej grywalizacji i statystyk ale… w sumie w Yanosiku grywalizacja była niedorobiona, a statystyki niespecjalnie coś wnosiły. Chociaż lubię popatrzeć. Google Maps dobrze nawiguje i… tyle. W każdym jeśli chodzi o nawigację to niebo a ziemia – totalna przepaść w jakości oprogramowania.

Rozważam jeszcze wypróbowanie głównego polskiego konkurenta Yanosika, czyli Ryśka, ale boję się, że nawigacja będzie słabsza od Google Maps, a dane dot. sytuacji na drodze gorsze, niż w Yanosiku.

UPDATE: Rysiek może kiedyś będzie testowany, ale najpierw szansę dostanie Waze – wiele osób poleca i w komentarzach na blogu (nie tylko pod tym wpisem), i poza blogiem. Podobno wykupione przez Google, jest nawigacja i antyradar, może być fajne. Recenzja za jakiś czas.

Opublikowane w

Debian skończył 24 lata; reproducible builds częścią polityki Debiana

Urodziny były parę dni temu. Rocznica jak rocznica i nie odnotowywałbym, ale szykuje się ważna zmiana w Debian Policy – pakiety powinny być budowane w sposób powtarzalny. Pisałem o tym 2,5 roku temu i bardzo mnie cieszy, że jest to oficjalna wytyczna.

Przy okazji – problem został dostrzeżony szerzej w świecie otwartego oprogramowania. O powtarzalnym budowaniu więcej można przeczytać na stronie reproducible-builds.org.

Opublikowane w

DSP2017 – głosowanie

W trakcie konkursu pisałem o projektach, które przykuły moją uwagę. Niestety, przyznaję, że nie udało mi się siąść i uczciwie przejrzeć wszystkich projektów, stąd brak kolejnych części. Dlatego, choć część z powyższych projektów znajduje się w gronie finalistów, postanowiłem zagłosować inaczej.

Bezpośrednim motywatorem były statystyki stworzone przez Cezarego. Metoda wyboru kandydatów do głosowania była prosta – sortowanie po ilości gwiazdek projektu na GitHubie i szukam czegoś ciekawego. Czemu tak? Głównie, żeby docenić przydatne projekty i zminimalizować wpływ części związanej z blogowaniem. Ostatecznie GitHub to social network, DSP2017 minie, a GH zostanie. Dlatego zachęcam do interakcji tamże.

Opublikowane w

Status abcc – 75% zrobione

Za wiele się nie wydarzyło w tym tygodniu w projekcie. Nie uruchomiłem i raczej nie uruchomię stacji testowej, bo jakoś nie ma weny. Za to zrobiłem względny porządek z opisami i funkcjonalnościami, więc powinno dać się względnie komfortowo uruchomić. Gdyby ktoś miał Linuksa i chciał się pobawić – zapraszam i czekam na uwagi. Póki co wyniki są wyświetlane na stdout i całość nie działa w pętli, tylko wykonuje jeden przebieg, ale to detale.

Rozważam uruchomienie stacji testowej oraz przejście na wypisywanie rzeczy do dorobienia/poprawki jako issues.

Czas na DSP2017 został zjedzony przez inną nową zabawkę – Pyevolve. Jest to biblioteka do algorytmów genetycznych, które chcę wykorzystać do rozwiązywania pewnego zagadnienia. No i wsiąkłem w testy, zabawę, przeglądanie dokumentacji i kodu. Z zalet: chyba pierwsza biblioteka, która wygląda na używalną. Jeśli ktoś zna inne godne uwagi (proste, rozszerzalne), to poproszę namiar.

A skoro o algorytmach genetycznych mowa – jest konkurs dotyczący algorytmów genetycznych. Chociaż ja się na grant raczej nie łapię…

Opublikowane w

Pierwsze pomiary

Wygląda, że w końcu mogę napisać, że powstało coś działającego. Nie jest to oczywiście pełna funkcjonalność, ale same pomiary są skończone. Nie twierdzę, że to ostateczna wersja, w szczególności muszę się przyjrzeć logowaniu, ale to jest ten moment, kiedy mogę pobawić się wartościami z konfiguracji i zobaczyć, jak wpływają na działanie w realnych warunkach.

Jak to wygląda? Otóż tak na szybko, uruchamiając modem GSM w sieci Virgin Mobile (3G) zarejestrowany do T-Mobile (roaming):

INFO:__main__:Route default got score 24.1516556059 on interface wlan0
INFO:__main__:Route default got score 89.6018913814 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.7111227853 on interface wlan0
INFO:__main__:Route default got score 64.5852940423 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.101962362 on interface wlan0
INFO:__main__:Route default got score 63.8392652784 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.9711829594 on interface wlan0
INFO:__main__:Route default got score 78.0421457793 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 66.7648989057 on interface wlan0
INFO:__main__:Route default got score 62.6970052719 on interface enx582c80xxxxxx

Widać, że w ostatnim pomiarze domowe WiFi (lub operator, ale stawiam na WiFi) dało się we znaki i wypadło gorzej, niż modem GSM. Różnica jest jednak minimalna i do zmiany routingu by nie doszło, nawet na domyślnych wartościach.

Wyniki po zalogowaniu natywnie, czyli do Play:

INFO:__main__:Route default got score 23.7996305738 on interface wlan0
INFO:__main__:Route default got score 307.032244546 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.561555045 on interface wlan0
INFO:__main__:Route default got score 267.205837795 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.0223884583 on interface wlan0
INFO:__main__:Route default got score 268.849682808 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.7405095782 on interface wlan0
INFO:__main__:Route default got score 275.927570888 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 38.6582265223 on interface wlan0
INFO:__main__:Route default got score 287.999381338 on interface enx582c80xxxxxx

Wszystkie wyniki dla przykładowego pliku konfiguracyjnego z repo, z dostosowaną nazwą interfejsu (jest interfejs modemu zamiast eth0) i zmienionym poziomem logowania na INFO. Wywołanie w pętli 5 razy:

for i in {1..5}; do python abcc.py --config local_test.yaml; done

Przyznaję, że jestem zaskoczony wynikami – wydawać by się mogło, że natywnie będzie działać lepiej, a tu niespodzianka. Muszę jeszcze dokładniej potestować na różnych urządzeniach, dotychczas miałem wrażenie, że w roamingu jest gorzej. Ale to już temat na inny, niezwiązany z DSP2017, wpis.

Przy okazji, to drugie wywołanie wykonuje się 71 sekund, czyli około 14 sekund na jeden pełen przebieg, a ilość przesłanych podczas badania danych (odczyt z ifconfig) to:

RX packets 11342  bytes 7440400 (7.0 MiB)
TX packets 9789  bytes 1133957 (1.0 MiB)
RX packets 11640  bytes 7475184 (7.1 MiB)
TX packets 10087  bytes 1169257 (1.1 MiB)

Czyli jakieś 7kB RX i 7 kB TX per pomiar. Czyli jakieś 10 MB/dobę, przy założeniu, że będzie wywoływane co minutę, 27/7. Czyli mniej więcej mieści się w limicie bezpłatnego pakietu Freemium w Virgin Mobile. 🙂

Opublikowane w

Skrypty pomocnicze

Wspominałem, że pewna część działania skryptu odbędzie się w zewnętrznych skryptach. Powiedzmy, że pluginach, choć to myląca nazwa. I że będą w Bashu.

Zrobiłem listę skryptów pomocniczych, których planuję używać:

  • ustawianie routingu do danego IP przez dany interfejs (bardziej gateway)
  • usunięcie routingu do danego IP przez dany interfejs (gateway)
  • ustawienie (domyślnego) routingu przez dany interfejs i gateway
  • zdjęcie (domyślnego) routingu przez dany interfejs i gateway

Jeśli chodzi o postępy, to pojawiło się wsparcie dla interfejsów, zarówno po stronie skryptu, jak i konfiguracji. Tak naprawdę pojawiła się cała sekcja interfaces, dla każdego interfejsu są określone nazwy tras, których parametry są zdefiniowane w sekcji routes. Taka konstrukcja, bo przecież nie każdy interfejs musi umożliwiać routing do każdej sieci, a nie chcę wymuszać cokolwiek długiej definicji trasy dla każdego interfejsu. Poza tym, łatwo byłoby w takim przypadku o błąd typu inne wagi czy IP.

Żeby można było mierzyć jakoś łącza do danej sieci (route) przez dany interfejs brakuje tak naprawdę pierwszych dwóch skryptów i ich wywołania – stosowne funkcje istnieją, ale są puste. Pewnie jutro/pojutrze. Mam nadzieję, że od razu pokażę pierwsze realne efekty działania, czyli wyniki pierwszych pomiarów. Stay tuned!

Opublikowane w

DSP2017 – co ciekawsze projekty

Ostatni dzwonek na wpis, a w związku z aurą i nawałem innych zajęć niewiele się u mnie wydarzyło[1], więc pozwolę sobie zacząć małą metatematykę, czyli pisać o projektach, które przykuły moją uwagę i które planuję śledzić. Ocena zupełnie subiektywna. Raczej ograniczam się do „żywych”, czyli mających szanse w konkursie, projektów. Trochę nawiązując do Blog Day, ograniczę się jednorazowo do pięciu sztuk. Docelowo pewnie zmienię linki na bezpośrednie do blogów lub repo na GitHubie.

http://uczestnicy.dajsiepoznac.pl/profil/adrian-dzik – Instant Dinner czyli podpowiadanie co tu ugotować z dostępnych w lodówce składników. Pomysł mi się bardzo podoba i może się przyjąć, choć korzystać raczej nie będę – nie mam cierpliwości do wklepywania wszystkiego i nie lubię gotować z przepisów. Parę ciekawych wyzwań – interfejs, baza przepisów.

http://uczestnicy.dajsiepoznac.pl/profil/pawel-filipek http://uczestnicy.dajsiepoznac.pl/profil/pawel-panek – dwa projekty związane z modnym temat badania czystości powietrza. Tu: informowania o zanieczyszczeniu w danym miejscu. Po cichu liczę, że będzie kolaboracja z projektem Smolgy o którym niedawno pisałem.

http://uczestnicy.dajsiepoznac.pl/profil/kamil-kubacki – projekt Citizen, czyli zgłaszanie do władz miasta/służb uszkodzeń itp. Po prostu zgłaszasz dziurę w jezdni (geolokalizacja, fota, opis) i jest to odpowiednio przeroutowane dalej, nie trzeba się edukować/odbijać od kolejnych instytucji. Przyznaję, że myślałem o czymś podobnym niedawno. Widzę fajne możliwości – ranking najsprawniej działających miast/organizacji w danym mieście (np. czas od zgłoszenia do usterki). Widzę też jeden problem: żeby to działało, instytucje muszą się zaangażować…
Podobna tematyka http://uczestnicy.dajsiepoznac.pl/profil/andrzej-chmielewski – niestety wygląda na martwe.

http://uczestnicy.dajsiepoznac.pl/profil/maciej-sykala – działko na gołębie oparte o Raspberry Pi. Temat niezbyt mi się podoba, ale przyznaję, że zakres robi wrażenie i… ciekaw jestem efektu. BTW dawno temu czytałem, że w Korei Południowej studenci projektowali automatyczne wieżyczki strzelnicze do pilnowania granic. Nie pamiętam, czy była analiza obrazu, czy po prostu wykrywanie ruchu…

http://uczestnicy.dajsiepoznac.pl/profil/sebastian-czarnecki – arduino sterowane po wifi. To mi się najprawdopodobniej zwyczajnie przyda w niedalekiej przyszłości.

Na wypadek gdyby powyższe nie wyczerpywało wymagań wpisu o IT, to przyszła mi do głowy nieco inna formuła konkursu programistycznego, która mogłaby trochę pomóc w rozwoju projektów. Pierwszy etap to prezentacja pomysłów, pisanie kodu i blogowanie (czyli dokładnie jak DSP), drugi etap to połączenie się ludzi w zespoły i wspólne rozwijanie projektów. Można by to zakończyć jakimś hackatonem, żeby ludzie się poznali na żywo. A może istnieje już coś takiego?

Co prawda nie widzę za bardzo kryteriów oceny w powyższym układzie, ale mogłoby to dać coś trwalszego i większego, niż małe projekciki, nauczyć pracy w zespołach, umożliwić poznanie ludzi i wymianę wiedzy np. o narzędziach. No ale ja cały ten konkurs traktuję bardziej jako pretekst, czyli droga jest ważniejsza od celu. 😉

[1] Przynajmniej niewiele zostało commitnięte, za to wkrótce pierwsze pomiary na dwóch łączach i pewne uwagi nt. internetu w Virgin Mobile.

Opublikowane w

Logowanie

Pora dorobić logowanie w skrypcie. Nie będę tu przepisywał tutoriali, więc jedynie odeślę do opisu logowania w Hitchhiker’s guide to Python oraz chyba nawet lepszego wpisu na temat dobrych praktyk logowania w Pythonie Docelowo konfiguracja logowania w pliku konfiguracyjnym. Waham się czy jednak syslog, czy może osobny plik, ale to jest detal.

Wczoraj w pociągu rozpisałem wstępnie, co chciałbym logować na poszczególnych poziomach i wyszło mi coś takiego:

WARNING/ERROR:

  • błąd otwarcia lub parsowania pliku konfiguracyjnego
  • nieistnienie interfejsu zdefiniowanego w pliku konfiguracyjnym
  • błąd zwrócony przez skrypty pomocnicze
  • brak skryptu pomocniczego, jeśli był zdefiniowany w pliku konfiguracyjnym[1]
  • nieosiągalne IP[2]

INFO:

  • znalezienie lepszej trasy i zmiana routingu, czyli podstawa
  • ostateczna punktacja dla danego interfejsu (docelowo może w DEBUG?)
  • znalezienie lepszej trasy, niż istniejąca, z pominięciem kosztu przełączenia[3]

DEBUG:

  • chwilowe zmiany routingu per badane IP
  • dane wczytane z konfiguracji
  • parametry wywołania funkcji
  • punktacja dla interfejsu z rozbiciem na składowe
  • parametry wywołania skryptów pomocniczych

Domyślny loglevel to oczywiście INFO. Jeśli wszystko pójdzie OK,to zmiany pojawią się w repo dziś wieczorem – niestety czas goni, a dwa wpisy w tygodniu muszą być…

[1] Wybiegam w sekcję ogólną konfiguracji, która dopiero powstanie, o skryptach pomocniczych planuję napisać w kolejnym wpisie.
[2] Jeśli będzie często występowało, to warto je usunąć, żeby nie zaburzało wyników.
[3] W celu poinformowania użytkownika, że być może warto zmienić przy okazji konfigurację sieci.



Opublikowane w

Początek

No to wysłałem na GitHuba to co mam w tej chwili. Nie ma tego wiele – w zasadzie jeśli chodzi o kod to jest to dokładnie wersja testowa o której pisałem wcześniej. Zupełnie nie miałem czasu i weny na siedzenie z kodem.

Ale nie jest tak, że nic nie przybyło w kwestii projektu. Po pierwsze, dotarł modem i udało mi się go uruchomić, więc będzie na czym testować. Po drugie, zrobiłem lekkie porządki w plikach i zaktualizowałem opis. Po trzecie i najważniejsze: chyba rozwiązałem problem wag. Proste rozwiązania są najlepsze, na papierze i szybkim teście wygląda wstępnie OK. Oczywiście jest to średnia ważona – musiałem mieć jakieś zaćmienie, że od razu o niej nie pomyślałem, ale powiedzmy, że bardziej myślałem o pliku konfiguracyjnym.

Co poza tym w temacie DSP2017? U mnie nic, poczytałem za to trochę wpisów. innych uczestników Co prawda w repozytoria nie zaglądałem, ale z wpisów mogę wywnioskować, że wszyscy mają mało czasu, generują niewiele kodu za to piszą, bo… muszą. Czyli za dużo blogowania, za mało programowania, ale chyba autor konkursu świadomie tak wybrał. Wnioskuję po dopuszczeniu wpisu niezwiązanego tematycznie z projektem jako drugiego. IMVHO trochę szkoda, bo czas zabiera, a wnosi niewiele.

Opublikowane w

Wskaźniki jakości łącza

Dumałem trochę nad parametrami łącza internetowego, które abcc mógłby mierzyć, poza tym, komentarze pod wpisem o założeniach abcc trochę pomieszały mi szyki, jeśli chodzi o chronologię, więc najwyższy czas przejść do rzeczy.

Techniczne wskaźniki jakości łącza internetowego to:

  • Opóźnienie – czyli potocznie lag albo ping, zrozumiała chyba dla każdego miara i dość powszechnie używana do określenia, czy łącze jest sprawne. Im jest mniejsze, tym lepiej. Ma znaczenie przy korzystaniu interaktywnym, czyli SSH/remote desktop albo graniu w gry online (zwł. FPP). Niezbyt istotne przy pobieraniu danych czy strumieniowaniu.
  • Straty pakietów – na sprawnym łączu strat nie ma. W przypadku łącz bezprzewodowych lub awarii, straty mogą się pojawiać. Wiążą się z koniecznością retransmisji pakietów lub utratą danych. Mają znaczenie praktycznie wszędzie. Im niższa wartość, tym lepiej.
  • Jitter – zmienność opóźnienia pakietów, czyli dokładniej statystycznie, wariancja opóźnienia pakietów. Ma znaczenie przy korzystaniu interaktywnym, szczególnie przy transmisji głosowej/video. Im niższa wartość, tym lepiej.
  • Prędkość pobierania – określa, jak szybko można pobierać dane. Ważne przy pobieraniu danych.
  • Prędkość wysyłania – określa, jak szybko można wysyłać dane. Ważne tylko przy wysyłaniu większych maili itp.

W wariancie minimum planuję mierzyć tylko dwie pierwsze miary. Waham się nad jitterem – prawdopodobnie kiedyś zaimplementuję, ale wymagałoby zmiany bibliotek i/lub liczenia wszystkiego samodzielnie. Wykonalne, ale na początek mało istotne. Z uwagi na pierwotne zastosowania (GSM) i możliwość opłat za transfer, rezygnuję z badania prędkości pobierania i wysyłania. Zresztą, jest szansa, że same pomiary mogłyby tu wpłynąć na funkcjonowanie łącza, szczególnie słabszego. Dodatkowo wymagany jest host zdalny, udostępniający określoną zawartość (w przypadku downloadu) lub pozwalający na wysyłanie treści (w przypadku uploadu). Nie skreślam zupełnie, ale zdecydowanie nie pojawi się w pierwszej wersji, a jeśli się pojawi, to domyślnie będzie wyłączony.

Na koniec pozostała część zasadnicza, czyli formuła określająca jakość łącza. Ponieważ dla większości parametrów im niższa wartość, tym lepiej, stwierdziłem, że najprościej jest liczyć tylko koszt, czyli sumować „punkty karne”, łącze o najniższej wartości „wygrywa”. W przypadku dwóch ostatnich parametrów łatwo zamienić je na analogiczne miary – im niższy czas przesyłania znanej ilości danych, tym lepiej.

Ostatecznie na razie wyszło coś takiego:

f(route)= suma(mnożnik_IP * (mnożnik_strat_route * straty_IP + mnożnik_opóźnień_route * opóźnienie_IP))

Dodatkowo całość należałoby przemnożyć przez mnożnik dla danego łącza[1] i wprowadzić, czy to do wzoru, czy przy podejmowaniu decyzji o przełączeniu, koszt przełączenia. Docelowo przydała by się pewnie jeszcze jakaś normalizacja względem ilości IP, żeby dodanie dodatkowych IP do sprawdzania nie powodowało zmiany wartości, bo to zmienia rolę kosztu przełączania. Najprostsza byłaby średnia, ale gryzie się z mnożnikami dla poszczególnych IP. Te z kolei chciałem mieć, bo wyobrażam sobie sytuację, że ktoś chce sprawdzać jakość łącza do różnych IP docelowych, ale niektóre (np. IP firmy) są bardziej istotne przy podejmowaniu decyzji.

Mnożniki dla route wprowadziłem z uwagi na możliwość ustawiania nie tylko routingu domyślnego, ale dla poszczególnych tras. Może się zdarzyć, że do sieci, do której łączymy się przez SSH ruch będzie wysyłany innym łączem, niż podstawowe, ze względu np. na mniejsze opóźnienia. Raczej na wyrost w tej chwili, ale kiedyś pewnie się przyda.

Przechodząc do spraw praktycznych: pobawiłem się chwilę w weekend, jest PoC – czytanie konfiga, część przykładowego konfiga, przepingowanie IP, liczenie kosztu (niedoskonałe). Czekam na zamówiony modem GSM. 56 linii kodu, commit do repo pewnie w tym tygodniu, ale o tym następnym razem. 😉

[1] Koszt łącza miałby być dodatkowym parametrem, dzięki któremu użytkownik może w jakiś sposób odwzorować parametry pozatechniczne, choćby koszt transmisji za pośrednictwem danego łącza.

Opublikowane w

Guetzli – lepsza kompresja JPEG

Przedwczoraj Google ogłosiło na blogu nowe narzędzie do kompresji JPEG o nazwie Guetzli, wydawane na wolnej licencji (Apache License). Ma dawać lepsze optycznie rezultaty przy mniejszym rozmiarze wynikowym (mowa nawet o 35% mniejszych plikach). Cena? Oczywiście czas kompresji.

Postanowiłem przetestować na szybko, co mogło by się zmienić, gdybym wykorzystał grafiki skompresowane przy pomocy Guetzli na blogu. W tym celu sięgnąłem po obrazki z backupu bloga i uruchomiłem program (domyślne opcje kompilacji, domyślne ustawienia jakości, czyli 90%) na moim laptopie (CPU: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz). Zdziwiło mnie to, że aż przy 12 plikach nie udało się ukończyć działania – program zgłosił błąd:

Invalid input JPEG fileGuetzli processing failed

Udało się przetworzyć 66 plików, całość trwała prawie 17 minut (sic!). Czyli jest bardzo wolno. Kompresor wykorzystywał tylko jeden rdzeń CPU. Efekty są obiecujące, zarówno wizualne, jaki i objętościowe. Mimo, że algorytm jest zaprojektowany z myślą o działaniu na możliwie nieprzetworzonych obrazach wejściowych, a te na blogu raczej są już zoptymalizowane, to łączny rozmiar udało się zmniejszyć o 14% (z ok. 3,3 MB do ok. 2,8 MB).

Jeśli wezmą się za wykorzystanie i optymalizację duże firmy, a jest na to szansa po uwolnieniu programu, może to oznaczać mniej przesyłanych danych po sieci, czyli szybsze ładowanie się stron, widoczne zwłaszcza na komórkach. Chwilowo główną barierą jest czas działania, który wygląda na zależny bezpośrednio od wielkości pliku wejściowego.

Zrobiłem jeszcze jeden test – plik JPG bezpośrednio z aparatu, rozmiar 2560×1440, rozmiar wejściowy 1,2 MB. Po kompresji (trwającej kilka minut) brak zauważalnych zmian jakości, natomiast rozmiar zmniejszony aż o 50% (614 kB).

Opublikowane w

Założenia i opis projektu abcc

Projekt abcc składa się z demona, napisanego w Pythonie, który czyta plik konfiguracyjny, a następnie na podstawie jego zawartości dokonuje cyklicznej kontroli jakości dostępnych łącz względem określonych w konfiguracji IP docelowych. Przeprowadzane operacje zapisywane są do logu (syslog?), podobnie jak oceny poszczególnych łącz.

Zakładam wykorzystanie Pythona w wersji 3, przestrzeganie PEP8 i programowanie funkcyjne. Całość ma być możliwie prosta koncepcyjnie i możliwie konfigurowalna przy pomocy pliku konfiguracyjnego za pomocą wag poszczególnych wskaźników, wag IP. Rozwiązanie ma też zapewniać użytkownikowi pełną przejrzystość działania, wybór poziomu logowania i możliwość uruchomienia w wersji „na sucho”, w celu przetestowania, jak uruchomienie z daną konfiguracją wpłynęłoby na zmiany routingu.

Aby to osiągnąć, zmienia na czas pomiaru routing do docelowych IP na dane łącze, dokonuje pomiaru jakości łącza, a następnie, po zebraniu danych dla wszystkich łącz, określa, które z nich jest najlepsze i – jeśli zachodzi taka potrzeba, dokonuje zmiany routingu.

Do zmiany routingu wykorzystywane są zewnętrzne skrypty bashowe – pozwala to na dostosowanie działania demona do różnych platform i potrzeb – np. dodanie zmiany NATowanaia, wywołanie zmian na zdalnym systemie (router sprzętowy) – bez zmian w samym silniku.

Teoretycznie można by to napisać w czystym Bashu i wywoływać z crona, ale po pierwsze, chcę potrenować Pythona, po drugie tak będzie łatwiej, bardziej elegancko i będzie otwarta droga np. do zwiększenia częstotliwości próbkowania przez zrównoleglenie pomiarów.

Z racji wymogów konkursowych dotyczących ilości postów, tworzenie projektu będzie trochę przegadane, i spowolnione, przynajmniej na początku. Zaleta jest taka, że będzie lepiej widać sposób rozumowania, gdyby ktoś chciał coś skomentować lub się przyłączyć. Commity kodu i dokumentacji będą się pojawiały w miarę równolegle z wpisami na blogu, pierwszy właśnie poszedł.