Poprzednia notka spotkała się z żywym odzewem czytelników, więc ponieważ ostatnio temat bardzo mnie zajmuje - zarówno w pracy jak i prywatnie - to może następna.

W pracy ostatnio miałem satysfakcję z gatunku Schadenfreude - od dobrych dwóch lat marudzę przy każdej okazji szefowi działu że tak jak robią to nic z tego nie będzie i trzeba coś zmienić (lista propozycji w załączeniu). Oczywiście, jak to w korpo, nic się nie zmienia. Projekt w którym jestem udało mi się doprowadzić do jako-tako szczęśliwego końca w zasadzie tylko w taki sposób, że co poważniejsze problemy popoprawiałem na własną rękę albo powymuszałem różne rzeczy tworząc fakty dokonane. Ale równolegle idzie projekt pochodny, do innego wariantu, w zasadzie tylko przejąć ten "mój" i trochę pozmieniać. Tego nowego projektu dotąd nawet nie dotknąłem i jest on w stanie tragicznym. No i w czwartek szefu był u klienta na zebraniu kryzysowym, pojawił się tam szef działu testowania (zresztą o polskim nazwisku), stwierdził że jakość tego softu jest katastrofalna (co i ja ciągle szefowi mówię) i zaczął zadawać pytania w stylu "a czy macie development patterny?", "a czy macie continous integration?", "a czy macie automatyczne testy?" - i wszystkie te pytania pokrywały się dokładnie z tym, o czym marudzę. No i już w piątek było "Powiedz nam, co mamy robić żeby ten projekt się nie zawalił?".

Jak źle jest? SOP jest na marzec, to jest do tańszego modelu więc od samego początku ilości będą rzędu 5000 tygodniowo, a na dzień dzisiejszy kompilator daje aż 25.000 warningów. Szybko przejrzałem listę i zauważyłem, że większość z nich musi być z bardzo niewielu miejsc - pół godziny szukania, znalazłem że w dwóch miejscach ktoś zainkludował headery wewnątrz funkcji. Po usunięciu ich, ilość warningów spadła do poniżej 10.000. Rzecz graniczy z sabotażem. Funkcjonalnie to nawet nie przejęli sporej części rzeczy, które od dawna działają u nas. Jedną dość kluczowy moduł infrastrukturalny który opracowałem, zamiast go po prostu przejąć zrobili "lepiej". Poświęcili na to masę czasu, zawracali mi dupę mnóstwo razy, ale oczywiście nie zintegrowali najpierw mojej wersji, tylko od razu zabrali się za poprawianie, czym opóźnili o miesiące włączenie mechanizmów ochrony pamięci - które przecież pozwalają znaleźć sporo błędów. Na koniec jeszcze nie wszystko działa, a nie mają z tego wszystkiego żadnych zalet poza tą abstrakcyjną "lepszością". Za to będzie teraz źle, bo rozwiązania tego samego w obu projektach są różne (a na przykład cały generator kodu jest wspólny, oni poprawiają moje zmiany za każdym razem). Przy pierwszym problemie każę im to wywalić do kosza i wrócić do mojego. Tragedia po prostu, znowu trzeba będzie ratować im dupy, za każdym razem z coraz głębszego szamba.

No dobrze, ale bywa jeszcze gorzej. Wróćmy do naszych ulubionych Twit Programmers z consumer electronics.

Mam w domu zegar ścienny z DCF, produkcji znanej firmy Citizen. Trochę lat już ma. Taki zegar synchronizuje się z nadajnikiem DCF-77 (tu niedaleko, koło Aschaffenburga) w południe i o północy, jeżeli wychodzi mu że się spóźnia to nie ma sprawy - wskazówki pojadą trochę do przodu. Gorzej jest, jak się spieszy - taki zegar do tyłu się nie pokręci. Ja bym zrobił tak, że zegar powinien trochę poczekać aż upływ czasu dogoni czas wskazywany, a potem niech chodzi dalej, w końcu o ile może się pospieszyć przez 12 godzin. Tymczasem tutaj jakiś twit programmer wymyślił, że zegar pokręci się niecałe 24 godziny do przodu. Ponieważ to stara konstrukcja i wszystkie wskazówki są posprzęgane na stałe, to sekundnik musi się w tym celu obrócić 12*60=720 razy dookoła, a trwa to prawie 20 minut. Oczywiście spać się w tym pokoju nie da, jak zegar o północy przez 20 minut warczy. A teraz najlepsze: Zegar przy czasie letnim ZAWSZE stwierdza, że się spieszy - ten twit nie uwzględnił przy porównaniu flagi DST.

Teraz honourable mention dla elektroników którzy projektowali mojego notebooka marki Acer. To jest 18'' desktop replacement i ma dwie karty graficzne. Jedna (Intel) jest wolna, ale bierze mało prądu, druga (ATI Radeon HD4670) odwrotnie. Tyle że jakiś twit wymyślił, że ta szybka będzie niestandardowa i będzie wymagała specjalnego drivera. Notebook był zaprojektowany do Windowsów Vista, ja kupiłem go z Windows 7 i na początku ta szybka karta jeszcze działała. Potem, po jakiejś aktualizacji systemu przestała, w Windows 10 też nie działa. Aktualizacji drivera już nie ma i nie będzie, szlag by ich trafił. Pod Linuxem też nie chodzi, bo tam specjalnego drivera też nie ma.

Problem jest taki, że załamany twitami piszącymi soft na Androida wymyśliłem, że sam sobie napiszę rzeczy które potrzebuję. Zainstalowałem Eclipse z developmentem do Androida, on ma emulację urządzenia z Androidem. Tyle że na moim notebooku ta emulacja startuje się 11 minut. Popatrzyłem co się da zrobić i radykalne przyspieszenie dałoby włączenie hardwarowej wirtualizacji, ale do tego potrzebne jest Intel Virtualisation Technology w procesorze, a w moim tego nie ma. Następna możliwość to włączenie opcji użycia hardware karty graficznej, a tutaj ta szybka nie działa, a do wolnej nie ma już aktualnych driverów. No to może Linux? Partycję z Linuxem miałem, zainstalowałem tam takiego samego Eclipsa, Linux ma driver do tej karty od Intela i emulacja startuje w minut pięć. No to może nie ideał, ale zawsze znacznie lepiej. Na razie zorganizuję sobie to wszystko, a jak dojdę do poważnej roboty to kupię nowego notebooka.

Tak więc przeszedłem na Linuxa na notebooku. Poinstalowałem na moim serwerze Linuxowym trochę serwerowych narzędzi żeby robić development porządnie, i tu też zaraz wykryłem paru twitów. Na przykład u Epsona. Linuxowy driver drukarki od Epsona występuje w dwóch wersjach: Jedna drukuje wszystkie kolory poprzesuwane o parę milimetrów, druga trafia z kolorami we właściwe miejsca, ale wcale nie drukuje koloru żółtego. Wybór należy do Ciebie.

Następny twit jest od projektów do Eclipse. Zainstalowałem na serwerze CDO Repository Server żeby trzymać moje modele w czymś porządnym. A tu jakiś twit nie upilnował, żeby nazwy tabel w bazie danych były pisane zawsze tak samo. Na Windowsach nie ma problemu - tabele lądują w plikach a Windowsom jest scheissegal czy piszemy nazwy plików dużymi czy małymi literami. Ale Linuxowi nie jest to obojętne i od razu wychodzi błąd że nie można znaleźć tabel. Jako workaround podają żeby włączyć w MySQL-u opcję konwertującą nazwy tabel do małych liter, ale ta opcja jest globalna dla całej instancji serwera bazodanowego i wtedy zaczynają mi się wywalać wcześniej utworzone bazy, w których nazwy tabel zawierają duże litery. Wygląda na to, że na początek będę musiał poprawić na własną rękę CDO Server Project (na szczęście jest w źródłach).

I tak dalej, i tak dalej. Teraz na pociechę: Nie każdy problem z softem/hardwarem jest wywołany przez twitów. Typowy przykład to "na początku mój WiFi stick/WiFi router/urządzenie z WiFi chodziło dobrze, a teraz coraz wolniej, na pewno to przez jakiegoś twita od driverów". Otóż nie. Jak kupowałeś tego sticka, WiFi miało tylko trzech sąsiadów i to nie w Twojej klatce. Teraz WiFi mają wszyscy, a kanały mają poustawiane całkiem randomowo. Tak wygląda to u mnie w paśmie 2,4 GHz.

WiFi w paśmie 2,4GHz

WiFi jest o tyle źle zrobione, że komunikacja na kanale n zakłóca komunikację na kanałach od n-2 do n+2. Jakby poprzydzielać kanały jakoś centralnie to jeszcze może dałoby się to jakoś opanować, ale tak w realnych warunkach sieci jest tyle i poustawiane są na tyle źle że całość się ślimaczy. U mnie było jeszcze gorzej, bo pojawiał się jakiś nieprawdopodobnie mocny sygnał (chyba z biurowca naprzeciwko) zagłuszający wszystko dookoła. Jest na to tylko jeden sposób - przejść na pasmo 5GHz. Tak wygląda u mnie pasmo 5GHz:

WiFi w paśmie 5GHz

Czego i czytelnikom życzę.

Tytuł notki zainspirowany jest notką Boniego - "Twit of the Year". A co do meritum:

Jako - było nie było - fachowiec od inżynierii oprogramowania, z za chwilę trzydziestoletnim doświadczeniem, ze zgrozą obserwuję poziom wykonania programów wszędzie dookoła. Tak w zasadzie to tworzenie oprogramowania jest stosunkowo proste. Są do tego dość jasno określone zasady, cała kupa darmowych narzędzi pomocniczych, mnóstwo książek, nieprawdopodobne ilości porad do znalezienia w sieci, ... Co prawda w dowolnej innej branży też są dość jasne zasady, narzędzia, książki, tyle że przy programowaniu jest łatwiej - bardzo dużo można sobie po prostu wypróbować i poćwiczyć w domu, praktycznie za darmo. A na przykład w takim budownictwie to jakoś tak nie bardzo da radę.

Tymczasem w realnym świecie trudno o kawałek programu, który nie jest spieprzony i to najczęściej w sposób który powinien być łatwy do uniknięcia. Jaki-taki poziom mają najczęściej programy z okolic Free Software pisane w Javie, ale też wcale nie wszystkie. Dlaczego tak jest? To jest proste: Oni tam stosują się do ogólnie znanych reguł - używają development patternów, robią module testy, konsekwentnie robią komentarze w Javadocu z których potem powstaje dokumentacja, testy wykonują automatycznie w jakimś serwerze CI w rodzaju Jenkinsa, ... W sumie nic skomplikowanego, tyle że inni tego nie robią, albo robią to źle.

Ja rozumiem że bardzo duża część programów które można zdownloadować w systemowym sklepie jak Google Play czy Windows Store to produkcje półamatorskie i ich autorzy nie mają większego pojęcia o tym, co robią. Ale w produkcjach profesjonalnych, zwłaszcza w branżach które nie zajmują się tylko czystym softem nie jest wiele lepiej. Na przykład u mnie, w automotive.

U nas w fabryce, jestem jedyny który ma rzeczywiście pojęcie o inżynierii oprogramowania. Cała reszta to elektronicy, którzy na studiach mieli pobocznie cośtam o programowaniu. Albo i nawet nie i są samoukami. Niektórzy są nawet nieźli, myśleć logicznie potrafią, tyle że podstaw im brakuje. No i potem wygląda to na przykład tak, że w kawałkach w C++ nie jest nawet dobrze określone który header file jest do C, a który do C++ i jak pojawiają się problemy przy includowaniu, to ktoś łata problem takimi sposobami,  że jakbym miał jeszcze dość włosów na głowie, to bym je sobie powyrywał. W innych, zupełnie podstawowych sprawach też nie jest lepiej. A jak jakiś problem trzeba rozwiązać, to niemal każdy szuka podobnego miejsca w innym module i zrzyna rozwiązanie. A ponieważ to rozwiązanie rzadko tylko jest dobre, to złe rozwiązania rozprzestrzeniają się coraz bardziej. Testy modułowe są wymuszane przez klienta - więc robi się je na sam koniec, często już po tym jak program poszedł do na produkcję. Według mnie to zbędna robota, równie dobrze można by wyprodukować oszukany test report, nic by nie zmieniło a roboty mniej. I tak dalej, i tak dalej, ogólnie to cieszcie się że samochody w ogóle są w stanie ruszyć z miejsca.

No ale mimo wszystko programiści z automotive nie zasługują jeszcze na tytuł "Twit Programmers of the Year". Ponieważ samochód podpada pod różne takie tam związane z bezpieczeństwem (znaczy może kogoś zabić), to producenci wymuszają na wykonawcach żeby program nie wieszał się co chwilę, a przynajmniej żeby się potem jakoś znalazł. Na spełnienie tych wymagań idzie niesamowita ilość wysiłku a modus operandi typowego projektu w automotive to eskalacja. Jeszcze nigdy nie słyszałem o projekcie w automotive który by nie wszedł w eskalację. Mi to ręce opadają, bo tego wszystkiego można by uniknąć, gdyby chociaż trochę stosować się do ogólnie znanych zasad.

Ale jest branża w której jest jeszcze gorzej - to consumer electronics. Soft do telewizora jeszcze nigdy nikogo nie zabił, więc nikt nie wymusza w nim zachowania zasad fuctional safety. Ba, jak poklikać trochę w jakiś współczesny telewizor to wychodzi że oni w ogóle nawet podstawowego system testu to raczej jednak nie robią.

Skąd mi się temat wziął? Mój sprzęt audio-video już się mocno historyczny zrobił. Telewizor był jeszcze CRT, od Sony, ale nic bardzo specjalnego. Ciągłe mam video VHS i analogowy zestaw kina domowego z wejściem przez SCART. Najnowszym z urządzeń był dekoder kablowy, też dający sygnał na SCARTa. No i ten dekoder zaczął mieć problemy. Zaczęło się od różnych zakłóceń w obrazie, potem odbierał coraz mniej kanałów, w końcu zostało tylko Russia Today. A potem poszedł z niego dym - sfajczyły się dwa elektrolity. No i po analizie opcji wyszło mi, że najlepiej będzie kupić nowy telewizor, bo tunel kablowy będzie w zestawie, a i nagrywanie na dysk USB przynajmniej częściowo zastąpi video. A w następnej kolejności będzie nowe kino domowe.

Jako warunki brzegowe postawiłem rozmiar 32 cale (wystarczy mi), FullHD (4K to przesada, ale poniżej FullHD w dzisiejszych czasach bez sensu) i żeby był Smart. No i zaraz wybór skurczył mi się do zaledwie kilku modeli. A potem się doczytałem, że są już telewizory z Androidem. Ponieważ moje zdanie o programistach od telewizorów było utrwalone już od dawna, stwierdziłem że wezmę taki - jak nie będą pisać wszystkiego sami tylko wezmą za bazę niezłego Linuxa i jakie-takie API od Googla to okazji do narobienia głupot będą mieli mniej.

Od paru dni mam taki telewizor i jak widzę, prawdziwy Twit Programmer of the Year potrafi spieprzyć nawet taką integrację:

• To nie jest "telewizor na Androidzie" tylko "telewizor z własnym systemem + Androidem". Miejsca sklejenia widać dość wyraźnie. Ale i tak jest trochę lepiej niż bez Androida.
• Do telewizora można podłączyć mysz. Wszystko pięknie, tyle że rolka myszy chodzi w różnych menu, ale nie w web browserze. Po prostu nie chodzi i już, do scrollowania strony trzeba klikać w suwak, nawet ciąganie go nie działa.
• Można sobie utworzyć cztery listy ulubionych kanałów, ale wybrać jakiejś już nie. Znaczy okienko wyboru się pojawia, na liście są utworzone listy, ale listy wszystkich kanałów na niej nie ma. Nie muszę chyba pisać, że niezależnie od tego co wybiorę, po wyjściu z okienka ustawiona jest lista wszystkich kanałów. Zmienić to mogę tylko przy użyciu programu zdalnego sterowania na innym urządzeniu Androidowym. Na telewizorze nie da rady, próbowałem chyba z pół godziny. Proszę sobie darować komentarze że RTFM- w manualu nie ma o tym nawet słowa. Tytuł Twit Programmer of the Year słusznie się należy.
• Własny program do zdalnego sterowania z innego urządzenia Androidowego od producenta telewizora nie łączy się z telewizorem. Inne, od jakichś amatorów, jakoś się łączą (ale też nie wszystkie). Może ma to związek z tym, że w drugim urządzeniu WiFi chodzi na 2,4GHz, a telewizorowe na 5 GHz, ale amatorzy radzą sobie mimo routera po drodze.
• Nagrywać na dysk USB można tylko to, co się widzi. To akurat zrozumiałe - tuner jest tylko jeden. Ale nie da się odtwarzać nagranego programu na komputerze (przez DLNA) oglądając co innego.
• Jak ustawić nagrywanie na powiedzmy za dwa dni, dysk kręci się przez te dwa dni cały czas, nawet przy wyłączonym telewizorze. Naprawdę nie można go obudzić na pięć minut przed nagraniem?
• Już raz mi się coś powiesiło - oglądać TV można było, ale nie chodziło odtwarzanie nagranego programu i nic z internetem. Pomógł dopiero twardy reset z odłączeniem zasilania. Chyba zwisała część Androidowa.

Oczywiście nie twierdzę, że ten model telewizora przebija dno, z pewnością są gorsze. Ale programiści od consumer electronics rozumianej jako cała branża z pewnością zasługują na tytuł Twit Programmers of the Year

Jeszcze autoreklama, jakby czytał to jakiś decydent z branży: Za odpowiednią opłatą zorganizuję wam to bez porównania lepiej. Tylko poważne propozycje.