Uważni czytelnicy dostrzegli, że w zeszłym tygodniu nie pojawił się żaden wpis. Regulamin DSP2017 dopuszcza przerwy w prowadzeniu projektów i… zeszły tydzień należy potraktować jako przerwę. Zresztą ponad tydzień, bo w zasadzie majówka cała nieprojektowa, z małym wyjątkiem, o którym zaraz. W każdym razie z konkursu się nie wycofałem i mam nadzieję, że tygodni roboczych będzie wystarczająco dużo. Nie liczyłem ile jest dokładnie, a zarejestrowałem się z opóźnieniem. Tak czy inaczej, nie chodzi o to by złowić króliczka…
Przerwy są dobre, czy to w pracy jako urlop, czy przy projekcie. Można spojrzeć z boku, wyskoczyć z utartych torów i nabrać energii. W każdym razie zeszły tydzień był mocno pracowity, a wypełnianie PITów, to nie jest coś, co warto odkładać na ostatnią chwilę, powiadam wam. Zresztą warto wcześniej sprawdzić, czy ma się komplet papierów, jak się okazuje. W każdym razie zdobyłem kolejny skill w zakresie obsługi podatków. Ale ostatecznie wszystko w miarę wyprostowane.
Potem był czas dobrych imprez i intensywnego chodzenia po sklepach celem urządzenia oświetlenia – powiedzmy, że 20% zrobione. A w międzyczasie doglądanie zewnętrznych rzeczy – a to serwer się zaczął restartować bez przyczyny (odpowiedź ISP rozwaliła, ale restarty ustały, hm…), a to ktoś zepsuł format danych, z których korzystam… Chwilę trwało, zanim przyswoili, że błąd zgłasza osoba z zewnątrz, a nie pracownik. Fun, fun, fun. Tylko czasu szkoda.
Udało mi się zrobić dwie związane z projektem rzeczy: przetestować uruchomienie programu na czystym systemie z ARM (działa, czemu miałby nie działać?) oraz wstawić Raspberry Pi zamiast Banana Pi jako router, czyli odzyskać właściwą sondę. Co prawda to ostatnie nie udało się w 100%, bo robiłem na szybko, trochę czasu zeszło na ustalenie, że NAT lepiej działa, jak się włączy forwarding, a po wszystkim okazało się, że logowanie przy pomocy autossh coś nie działa, ale powiedzmy, że wariant minimum jest zrobiony. Z powodu małej ilości czasu nie zaryzykowałem też wpięcia drugiego modemu.
Przerwa i programowanie w pracy skłoniło ku refleksji, że może jednak lepiej będzie docelowo przepisać to obiektowo. Głównie chodzi o łatwość wykorzystania kodu w innych projektach – dokładnie to przerabiam w pracy. W cele projektu oficjalnie tego nie wpisuję póki co, ale jeśli tylko starczy czasu, to będzie próba refaktoringu kodu.
Nie byłem świadom, że dozwolone są przerwy, teraz już doczytałem w regulaminie i będę o tym pamiętać zastanawiając się, czy nie wziąć udziału w kolejnej edycji (o ile bedzie).
Moje pythonowe projekty często tak wyglądają, że zaczyna się od pojedynczego skryptu, który jest napisany „ciurkiem”, potem zwykle go trochę sprzątam żeby było ładnie i proceduralnie aż nie osiągnie pewnego momentu, gdy uznaję, że trzeba zrobić to jednak obiektowo. Oglądałem kiedyś na youtubie wystąpienie, żeby w Pythonie nie robić klas, jeśli to nie jest koniecznie potrzebne ze względu na prostotę (i nie pamiętam, co jeszcze) ale bym musiał do tego wrócić i jeszcze raz przemyśleć. Próbowałem tak zrobić w jednym projekcie, ale potem wyszło coś takiego pośredniego, tu proceduralnie, tam obiektowo i sam nie wiem, czy jestem zadowolony z jego obecnego kształtu.
pkt 5 e. Dopuszczalna jest przerwa w pracach nad projektem, jednak okres rozwoju projektu krótszy niż 10 tygodni w trakcie trwania Konkursu skutkować będzie usunięciem z listy Uczestników
Co do obiektowo czy nie – też uważam, że przy małych skryptach nie ma co na siłę wciskać obiektowości. Z drugiej strony bardzo spodobała mi się łatwość reuse kodu w Pythonie, jeśli jest poprawnie napisany obiektowo. Tak czy inaczej bardziej chodzi mi o samo potrenowanie pisania obiektowo.