• Na początek zrootowałem swojego tableta (Acer Iconia A700). Nawet łatwo poszło.
• Wgrałem mu custom recovery, całkiem fajnie działa
• Wgrałem też mu custom system (CyanogenMod). Tu był problem - jest dużo programów instalujących ten system na zrootowanym urządzeniu, tyle że całkiem niedawno ten projekt przemianował się (na LineageOS) i w ogóle coś się pozmieniało i te starsze wersje zginęły z sieci. Żaden z instalatorów nie działa. Na szczęście znalazłem gdzieś w sieci odpowiedni kompilat (samemu skompilować jeszcze mi się nie udało) i wgrałem go na tableta. I to jest dobre, oryginalny Android ślimaczył się już straszliwie, a ten chodzi całkiem przyjemnie, można było wywalić cały bloatware i ma to parę funkcji więcej.
• Pisałem wcześniej o problemach z emulatorem Androida, dałem sobie z nim spokój. USB debugging chodzi bardzo dobrze. Potem kupię sobie parę używanych urządzeń z różnymi rozdzielczościami.
• USB debugging chodzi, tyle że nie na moim telewizorze. Philips ma politykę, że ich telewizory są nierootowalne, soft można instalować tylko z Google Play, a USB debugging mimo że można odblokować, to nie chodzi (tu jeszcze potencjalny problem połączenia USB-A z USB-A). Chociaż ostatnio trochę odpuścili, po niedawnym updacie opcja instalacji z innych źródeł się pojawiła, i co nieco narzędzi poinstalowałem. Debugging ma móc chodzić przez Ethernet, podobno komuś się z tym modelem telewizora udało, mi jeszcze nie. W ogóle to motywacja Philipsa jest "Bo jak zbrickujesz sobie telewizor za 2500 EUR to będziesz płakał" - tyle że mój telewizor był tańszy od mojej komórki i niewiele droższy od mojego tableta. Uprzedzając pytanie: Nie, nie mam komórki za 2500+.
• No to zacząłem od tableta. Na początek postanowiłem zapoznać się z obsługą sensorów. Jest do tego mnóstwo przykładowego kodu w sieci.
• Analiza kodu i zależności fizycznych pokazała, dlaczego niemal wszystkie (o ile nie wszystkie) programy robiące za kompas są do niczego. Przyczyny są dość skomplikowane, ale do pojęcia. Objaśnię je, bo to ciekawe:
  • Niemal każda komórka ma akcelerometr, którym można ustalić kierunek "w dół" (to tam, gdzie statycznie mamy przyspieszenie 1g), żyroskop do obrotów i magnetometr, pokazujący kierunek na magnetyczną północ
  • GPS podaje geolokalizację urządzenia, ale nie w którą stronę jest obrócone, więc GPS się do kompasowania nie nadaje.
  • Magnetometr podaje kierunek wprost (przez Ziemię) do bieguna magnetycznego.  Znaczy to jest (jak u nas) jakieś 40º do poziomu.
  • Duża część programów na kompas bierze po prostu składową magnetyczną w płaszczyźnie urządzenia, relatywnie do jego osi Y. Ale jak trzymać urządzenie w ręku i pochylić je trochę do siebie, to ta płaszczyzna ustawia się paskudnie blisko prostopadłości do żądanego wektora, całą dokładność szlag gwałtowny trafia i kompas kręci się na chybił-trafił.
  • Sytuację może poprawić użycie kombinacji  sygnałów z akcelerometru i magnetometru.
  • W zasadzie coś takiego jest dostępne jako wirtualny sensor pozycji urządzenia, tyle ta funkcja zrobiła się deprecated lata temu (od v2.2.x, około 2010).
  • Ponieważ nowe rozwiązanie wymaga jednego calla więcej i trochę zrozumienia (słowo kluczowe: quaternion), prawie nikt nie jest w stanie tego pojąć i prawie wszyscy robią to po staremu.
  • Nawet po nowemu, to pokazuje kierunek na północ magnetyczną, a nie na "prawdziwą" północ.
  • Znając geolokalizację (z GPS-u) można od systemu dostać wartość poprawki żeby pokazać prawdziwą północ, ale nie znalazłem jeszcze ani jednego przykładu żeby ktoś to zrobił. Ja też jeszcze nie załapałem w którym momencie trzeba wykonać jaką operację na quaternionach, ale dojdę do tego.
  • Nawet jak zrobić to dobrze, pokazywany kierunek będzie zakłócany przez zewnętrzne pola magnetyczne.
  • Generalnie wszystkie te programy są zrobione maksymalnie prosto - obracają obrazek igły kompasu zależnie od danych z sensora. Nie będzie to sensownie działać (nawet porządnie zrobione) jak nie trzymać komórki poziomo. Mam pomysł znacznie lepszego interfejsu użytkownika. I jeszcze parę innych pomysłów na aplikacje związane z kompasem.
  • Dlaczego cała ta kombinacja składowych do orientowania się na prawdziwą północ nie jest dostępna jako proste API?
• Jeszcze generalna uwaga co do API Androida: W całym tym API nie są w ogóle deklarowane wyjątki jakie funkcje mogą rzucać (deklaracja throws). Jak dla mnie to jest zupełnie podstawowy brak w designie - nieprzemyślana obsługa błędów.

Ładnie się zaczyna. Ciekawe jak będzie dalej.

No i książka rozczarowuje. Znaczy relacja z procesu Eichmanna jest interesująca (chociaż przygnębiająca), dowiedziałem się z niej sporo nowych rzeczy o karierze Eichmanna, jego aresztowaniu i procesie, mechanizmach Zagłady, różnicach między antysemityzmem w różnych krajach, itd., niestety relacja jest dość chaotyczna. Narracja leci jednym ciągiem bez żadnej strukturyzacji tekstu, rozdziały wynikają chyba tylko z pierwotnego podziału tekstu na odcinki drukowane w gazecie. No ale pewnie jako inżynier mam tu zbyt wysokie wymagania. Gorzej, że z książki niewiele mogłem się dowiedzieć na temat poddtytułowej tezy o "banalności zła". Słowo "banal*" występuje w całej książce zaledwie trzy razy i to w dużych odstępach. Brak jest jakiejś syntezy, chociaż takiej jak pojawiła się w filmie. Film jest zazwyczaj gorszy od książki, więc sądziłem że finałowa scena wykładu to tylko okrojony wybór fragmentów z tekstu, tymczasem było to właśnie to, czego w tekście brakowało. W dodatku zasadniczą treścią sceny były wyjątki z polemiki z krytycznym listem, nie należącej do pierwotnego tekstu, a tylko dodanej w późniejszych wydaniach jako postscriptum.

Jako przyczynek do "banalności zła" film jest znacznie lepszy niż książka. Na przykład książka tylko wspomina o tym (dwa razy), że Eichmanna na procesie pytano czy zabiłby swojego ojca gdyby Führer kazał, film zawiera oryginalne nagranie filmowe z procesu i pokazuje cały dialog, bardzo mocny zresztą. A akurat ten dialog bardzo dobrze ilustruje tezę autorki, naprawdę nie rozumiem dlaczego w książce nie został przytoczony. W praktyce to podtytuł "Rzecz o banalności zła" jest bardziej efektowną reklamą, niż oddaje treść książki. To znaczy książka jest też o tym, ale uzasadnienie tezy jest tylko "do samodzielnego montażu" - trzeba samemu znaleźć w książce odpowiednie argumenty i zsyntetyzować własnoręcznie. Niecierpliwym polecam jednak film. A pozostałym i książkę, i film, raczej zaczynając od filmu.

Teraz może coś o samej tezie. Autorka przed procesem Eichmanna była przekonana że zło zawsze jest "radykalne", a proces przekonał ją, że może być "banalne". Banalność miała postać niezbyt rozgarniętego i zapatrzonego w siebie nieudacznika Eichmanna, człowieka zupełnie przeciętnego i nudnego, który zza biurka zorganizował logistycznie zabicie milionów ludzi, nie potrafiąc przy tym odróżniać dobra od zła. Ja jakoś nie jestem przekonany, żeby zjawisko było takie nowe - przecież już w Rzymie cezarów jacyś przeciętni i nudni urzędnicy zza ówczesnych odpowiedników biurek organizowali zaopatrzenie legionów idących wyrzynać zbuntowaną ludność tu czy tam. I nie trzeba zaraz nikogo wymordowywać, normalne korpo też opiera się na takich ludziach, którzy zrobią wszystko co im się każe, bez zastanawiania się nad etyką. Patrz aktualny skandal dieslowski Volkswagena - przecież tam z całą pewnością nikt nie zrobił nic z uświadomionej złośliwości, czy innych niskich pobudek. Wszyscy robili to, co uznawali za dobre, każdy w swoim kawałku, najwyżej leciutko naciągając zasady, bo zawsze znalazły się jakieś usprawiedliwiające okoliczności. Przecież ja też robię w takim korpo i bywam na przykład na zebraniach z udziałem szefa całej fabryki. I to jest taki sam chłopek-roztropek jak ten uwieczniony na materiałach filmowych z procesu Eichmann. Praktycznie każdy rodzaj działalności ludzkiej wymaga współdziałania w większym zespole, skutki decyzji podejmowanych na wielu stanowiskach pojawiają się często o wiele później i zupełnie gdzie indziej. Odpowiedzialność się rozmywa, łatwo jest powiedzieć sobie jakieś "ja tylko..."  I tak będzie zawsze.

Jedno tylko mnie niepokoi. Banalny i przeciętny Eichmann był idealnym zwolennikiem dowolnej dyktatury. On nigdy nikogo nie zabił, ale zabiłby swojego ojca gdyby Führer powiedział że to zdrajca i trzeba go zabić. Ja rozumiem że tacy ludzie istnieją, jest ich w populacji całkiem spory procent i trzeba z tym żyć. Tylko ostatnimi czasy znowu udaje się różnym takim ich skutecznie zmobilizować. Świat nie idzie w dobrym kierunku. Tylko co na to poradzić?

Projekt w którym dotąd robiłem ma od dłuższego czasu dwa projekty pochodne dla dwóch innych modeli samochodów. Jeden z tych dwóch ma dwa warianty - z HUDem i bez. No ale to wszystko jest na tej samej bazie sprzętowej i ma robić z grubsza to samo, różnice są głównie w wyświetlaczu, rozłożeniu LEDów i zegarkach pokazujących niekoniecznie to samo. Tylko wziąć ten wcześniejszy projekt i trochę dopasować. No i prawdziwy twit manager of the year potrafi spieprzyć nawet coś takiego - każda z tych wersji jest wyraźnie inna, te same moduły są w różnych wersjach, albo są wręcz zupełnie inne, nawet mnóstwo nazw tych samych obiektów się nie zgadza. Nikt tego po prostu nie pilnuje. Największy problem jest z jednym z zasadniczych modułów, już w tym pierwszym projekcie on jako-tako działa tylko dlatego, że kiedyś połowę jego zrobiłem na nowo rysując statechart w Rhapsody i generując kod. Teraz zreimplementowałem go całego również w Rhapsody, narysowałem czyste i klarowne statecharty z dobrze zdefiniowanymi interfejsami, w dwa dni było zrobione, a teraz od półtora tygodnia próbuję to zintegrować z wszystkimi trzema systemami. No i wyłazi na każdym kroku to, co im powtarzam od lat: Tak się nie da pisać programów tej wielkości. Ten system jest zrobiony w AUTOSARze - to taka koncepcja modułowości do C, całkiem nie najgorsza (chociaż w pewnych aspektach nie domyślana do końca). Działa to mniej więcej tak, że każdemu modułowi definiujemy w XML porty z dobrze wyspecyfikowanymi interfejsami, a potem te porty łączymy, też w XML, są do tego narzędzia. Całość klei generowany kawałek kodu. Konsekwentnie użyte dałoby to niezły, modularny system, mimo że w C. Tyle że te twity cały czas idą po linii najmniejszego oporu i przestawiają na AUTOSAR tylko to, co absolutnie niezbędne, a pozostałe połączenia międzymodułowe są nadal robione jak ćwierć wieku temu przez #define funkcja1 funkcja2, potem w innym miejscu jest #define funkcja2 funkcja3 i tak dalej. W rezultacie nie ma żadnej modularności, a system przypomina węzeł gordyjski.

Przy okazji zauważyłem, że te nowe projekty kompilują się dobrze ponad dwa razy dłużej niż ten pierwotny, mimo że są mniejsze. Oczywiście nikt z twitów się nie skarży, ale przy czasie rekompilacji powyżej pół godziny rozsądna praca nie jest możliwa, i jest to jedna z przyczyn dlaczego te projekty są w stanie katastrofalnym. Postawiłem hipotezę roboczą, że gdzieś kluczowy header file inkluduje o wiele za dużo. Sprawdziłem i się okazało, że losowo wybrany plik źródłowy inkluduje pośrednio 55.000 headerów. Tak, dobrze widzicie: słownie pięćdziesiąt pięć tysięcy. Krótka analiza pokazała, że to idzie tak: AUTOSAR ma taki specjalny mechanizm definiowania, do której sekcji linkera dany obiekt ma iść - definiuje się powiązany z tą sekcją symbol preprocesora i includuje plik "MemMap.h" (przed obiektem i po obiekcie, zarówno przy definicji jak i deklaracji). Ten plik includuje wszystkie pliki z konkretnymi definicjami, a jest ich z grubsza tyle, ile modułów. To już robi całą masę includów. Ale teraz każdy z tych plików includuje zawsze ten sam plik z definicjami kompilatora, a przecież wystarczyłoby raz. Wywaliłem te niepotrzebne includy i ilość pośrednich includów w moim losowym pliku źródłowym spadła zaraz o 20.000 a czas rekompilacji spadł o jakieś 10%. Zawsze coś, ale w tym pierwszym projekcie jest dokładnie ten sam problem i to nie jest przyczyna różnicy czasów kompilacji. Na moje oko przyczyną jest to, że większość modułów includuje losowo i bez sensu, w pierwszym projekcie dużo tego wyczyściłem albo kazałem ludziom wyczyścić, a w tych nowych nikt się tym nie zajął, ani nawet nie przeniósł do nich poprawek. Niby drobiazg, ale 15 niepotrzebnych minut na każdą kompilację, przy sporym zespole przekłada się na stratę liczoną w osobodniach na tydzień!

W tym pierwotnym projekcie już dawno temu zauważyłem, że kompilacja idzie bez sensu: kompilowało się równolegle na pięciu corach, tyle że największy plik (wygenerowany przez AUTOSAR), kompilujący się przez 6 minut jest w grupie o nazwie alfabetycznie prawie na samym końcu. W związku z tym na końcu pozostałe cory nie mają nic do roboty, a jeden jeszcze przez 5 minut mieli ten jeden plik. Przesunąłem więc tą grupę na początek i voila - kompilacja skróciła się o prawie 5 minut czyli 30%.

W ogóle problematyka czasu i wygody kompilacji i ich wpływu na produktywność, a nawet sukces projektu jest mocno niedoceniana. Znany jest mi wypadek projektu który padł, bo każda generacja kodu z modelu trwała ponad 30 minut. Poprzednią robotę rzuciłem między innymi dlatego, że klient dla którego robiliśmy wymyślił sobie świetny tooling: Program (w Javie) składał się z sześciu części, i żeby je skompilować trzeba było każdą część kliknąć z osobna, i to nie wszystkie naraz, ale po kolei. Każda część kompilowała się 3-4 minuty, czyli akurat tyle żeby tymczasem się przełączyć i coś porobić. Tyle że jak się potem przełączało do Eclipsa to było zawsze "O k..., znowu nie pamiętam który ostatnio klikałem!".  Focusu już nie było, z konsoli też nie dało się łatwo wywnioskować. Efekt był taki, że klikało się parę razy w to samo, albo coś się pomijało i trzeba było od wszystko od nowa. Rozwiązania typu notować na karteczce, albo cały czas się gapić w tego Eclipsa były tak upierdliwe, że aż poszukałem książki od tego badziewia, ale po paru godzinach prób zrobienia żeby wszystko startowało się automatycznie z Anta dałem spokój. Nie dało się i już. Mój szef, też bardzo dobry w te klocki, nie chciał w to uwierzyć, sam się za to zabrał ale wkrótce też się poddał. Dla zainteresowanych podaję słowo kluczowe, po usłyszeniu którego trzeba szybko uciekać: Buckminster.

 Na zakończenie coś dla zmniejszenia hermetyczności notki. Przykłady twitowego i nietwitowego designu UI w elektronice konsumpcyjnej. Najpierw twitowy:

Budzik z twitowym UI

To jest typowy budzik za kilka euro, różne warianty i odmiany można kupić w każdym sklepie. Każdy ma trochę inne ustawianie czasu budzenia, praktycznie zawsze nieintuicyjne. Podejrzewam, że projektanci tego sprzętu w ogóle go nie używają, albo mają jakieś zaburzenia ze spektrum autystycznego i obudzeni w środku nocy, po ciemku, bez problemu potrafią przypomnieć sobie sekwencję klawiszy konieczną żeby alarm na stałe wyłączyć.

Ten konkretny model jest jeszcze bardziej twitowy, bo piszczy przy każdym przyciśnięciu przycisku. Autor tego rozwiązania jest z całą pewnością samotny, albo mieszka u rodziców i ma swoją, osobną sypialnię, nie dzieloną z nikim. Ale przy tak daleko posuniętym autyzmie to nic dziwnego.

A można inaczej. UI tego budzika jest zrobione genialnie:

Budzik z nietwitowym UI

Włączenie i wyłączenie alarmu robi się przy pomocy suwaków z boków. Suwak w górę - alarm włączony, suwak w dół - alarm wyłączony. Czas alarmu ustawia się po po przyciśnięciu jednego z tych większych przycisków po lewej i po prawej. Z wyświetlacza znika wtedy wszystko poza ustawianym czasem i naprawdę nie sposób tego nie umieć, nawet bez instrukcji.

Budzik z nietwitowym UI - ustawianie czasu

Suwaki podnoszą oczywiście koszt całości o kilka centów - bo program to żadna różnica, te kilkanaście linii kodu przeliczone na wielkość produkcji to koszt przyzerowy. Za to za taki budzik kasują 25 euro (sugerowana cena producenta), w sieci daje się znaleźć oferty od kilkunastu. W bonusie ma jeszcze różne cuda z podświetleniem wyświetlacza. Można? Można!

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ę.

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.

]]> http://nrdblog.cmosnet.eu/2016/10/twit-programmers-of-the-year/feed/ 36 http://nrdblog.cmosnet.eu/2016/07/marzenie-o-olimpiadzie/ http://nrdblog.cmosnet.eu/2016/07/marzenie-o-olimpiadzie/#comments Sun, 17 Jul 2016 12:33:56 +0000 http://nrdblog.cmosnet.eu/?p=11894 Obejrzałem wczoraj na arte ciekawy program - film dokumentalny "Der Traum von Olympia" ("Marzenie o olimpiadzie") - i muszę się podzielić.

Film opowiada historię olimpiady 1936 w Berlinie z punktu widzenia dwóch osób:

• Wolfganga Fürstnera - jednego z głównych jej organizatorów, oficera Wehrmachtu odpowiedzialnego za organizację i działanie wioski olimpijskiej
• Gretel Bergmann - lekkoatletki niemieckiej pochodzenia żydowskiego

Obu tych historii nie znałem, obie są bardzo znamienne i interesujące.

Najpierw o formie: Film zrobiony jest jako fabularyzowany dokument, zdjęcia dokumentalne opatrzone są pierwszoosobowym komentarzem obu bohaterów, w scenach aktorskich bohaterowie często zwracają się wprost do kamery z ich monologami wewnętrznymi. Ogólnie konwencja całkiem ciekawa. Klamra fabularna została wzięta z "Bulwaru Zachodzącego Słońca" - zaczyna się to od pierwszoosobowego monologu martwego ciała w jeziorze, kończy na scenie śmierci.

Teraz o faktach. Wolfgang Fürstner był zaangażowanym i wierzącym w narodowy socjalizm oficerem Wehrmachtu, na tyle sprawnym organizatorem, że powierzono mu organizację wioski olimpijskiej. Wymyślił on wiele z różnych chwytów, dzięki którym olimpiada 1936 w Berlinie stała się wielkim sukcesem propagandowym, Wtedy właśnie zaczęło się wykorzystywanie sportu do propagowania ideologii, zwłaszcza totalitarnych i do dziś na każdej olimpiadzie (zwłaszcza w kraju z jakąś dyktaturą, ale nie tylko) wiele rzeczy robi się dokładnie tak samo.

Fürstner przeprowadził swoje koncepcje żeby wszystko wyglądało maksymalnie pokojowo wbrew swojemu oponentowi - Wernerowi von Gilsa, który chciał żeby porządku na olimpiadzie pilnowało umundurowane wojsko dowodzone przez niego. Natomiast Fürstner zaangażował do tego zadania umundurowanych na biało synów oficerów armii i bardzo pilnował, żeby w wiosce olimpijskiej nie pojawiały się swastyki. Fürstner bardzo się starał, wierząc że będzie to wstęp do jego wielkiej kariery w Rzeszy. Ale już w trakcie organizacji olimpiady uchwalono "Ustawy Norymberskie" i zaczęto grzebać w życiorysach. I w sposób całkowicie niespodziewany znaleziono Fürstnerowi dziadka w Wehrmachcie że jego dziadek był przechrzczonym Żydem. Wbrew pozorom skłoniło to Fürstnera do jeszcze większych starań, bo wierzył on że jak wszystko pójdzie perfekcyjnie to nieprawomyślne pochodzenie zostanie mu zapomniane.

Ale tak nie było. Krótko przed otwarciem olimpiady zdegradowano Fürstnera do zastępcy komendanta wioski olimpijskiej (komendantem został jego konkurent Werner von Gilsa) pod pozorem że jak był dzień otwarty w wiosce to zwiedzający coś popsuli. Fürstner zrobił dobrą minę do złej gry i perfekcyjnie przeprowadził wszystko do końca z uśmiechem na ustach. Trzy dni po zakończeniu olimpiady został jeszcze odznaczony Niemieckim Olimpijskim Medalem Honorowym pierwszej klasy, a po imprezie na cześć uhonorowanych się zastrzelił.

Teraz druga linia narracji: Gretel Bergmann miała wielkie szanse na medal w skoku wzwyż, ale mieszkała w Anglii i miała wystartować w jej barwach. Wezwano ją więc do Niemiec (grożąc represjami dla rodziny jeżeli nie przyjedzie) i posłano na treningi z innymi sportowcami niemieckimi. Tyle że w ostatnim momencie odmówiono jej prawa do startu. I na koniec Niemcy zdobyły w skoku wzwyż medal srebrny.

Obie te historie zadedykowałbym ludziom znającym się na czymkolwiek, starającym się zrobić karierę w jakiejkolwiek dyktaturze, nawet raczej łagodnej (jak na razie), w stylu PiSowskim. Dyktatura to bardzo marny ustrój - może i na początku radzi sobie lepiej i sprawniej niż rozlazła demokracja, ale na dłuższą metę nie może być lepsza. Jeżeli nawet najlepszy fachowiec może w każdym momencie popaść w niełaskę, i to również z przyczyn całkowicie niezależnych od niego, to jeżeli tylko można, lepiej dla fachowca byłoby wybrać jakiś inny system. A i sam system dobrowolnie rezygnuje z zaangażowanych w niego fachowców pod byle pozorem - tak nie można wygrać, niektórzy ludzie są naprawdę niezastąpieni.

Los bohaterów jest też charakterystyczny: Fürstner zabił się już 1936, von Gilsa popełnił samobójstwo w 1945 po wpadnięciu w niewolę radziecką, a Gretel Bergmann która przeniosła się do USA, zdobyła tam kilka tytułów w różnych dyscyplinach sportu i żyje do dziś (ma 102 lata). Dyktatura nie jest zdrowa.

Na arte będą jeszcze dwa powtórzenia tego filmu, jedno za godzinę (niedziela 17.07. o 15:25), jedno w piątek 05.08. o 9:25, ale z pewnością można będzie go jeszcze nie raz zobaczyć.

I jeszcze dodam, że wioska olimpijska jeszcze istnieje i można ją zwiedzać. Kiedyś się wybiorę (ale będzie to raczej dopiero koło najbliższej Wielkanocy)

• Wszyscy muzułmanie to terroryści.

No to jest tak piramidalny idiotyzm, że szkoda czasu na debunk. Ale są też inne głupie wypowiedzi typu:

• Żaden X nie będzie biegał z karabinem, strzelał do ludzi i podkładał bomb

gdzie X to do wyboru:

• Europejczyk
• chrześcijanin
• katolik

No i sorry, ale wypowiadający takie stwierdzenia mają bardzo poważne braki w wykształceniu ogólnym. Więc gwoli edukacji, wzorem WO, zrobię ranking od czapy poświęcony europejskim organizacjom terrorystycznym. UWAGA: Ranking jest naprawdę od czapy, nie aspiruję do jego kompletności, kolejność dość subiektywna. A przy okazji znalazłem ciekawą stronę: (niestety z Europy uwzględnia tylko Włochy) Również niestety w wielu wypadkach nie daje się znaleźć sumarycznego body countu danej organizacji.

Kryteria zaliczenia do rankingu będą takie:

• Organizacja ma działać po WWII
• Złożona ma być z Europejczyków (przynajmniej głównie)
• Ma to być organizacja z jakimiś zamachami na koncie, nie klub dyskusyjny rozważający możliwości

Zaczniemy od honourable mentions, przykłady które nie mieszczą się w podanych kryteriach:

• Na początek: Polacy nie gęsi, i swoich terrorystów mają. Co prawda trochę nieudacznych. Bracia Kowalczykowie przygotowali zamach bombowy, bomba nawet wybuchła, ale nikogo w sali nie było. Body count: 0. No i co to za organizacja - dwóch braci nie da się policzyć jako organizacja terrorystyczna. I naprawdę nie mogę zrozumieć jak można ich czcić tablicami pamiątkowymi czy domagać się ich rehabilitacji. Na szczęście im się nie udało, ale to był podręcznikowy terroryzm.
• Jak jesteśmy przy Polakach, to AK zrobiła parę zamachów bombowych na stacje w Berlinie. Body count: 54 + 198 rannych. Nie liczy się do rankingu bo przed 1945.
• Nie mieszczą się w rankingu również różne zamachy na kliniki aborcyjne w USA. Nie udało mi się znaleźć sumarycznego body count, ale zamachów było w sumie ponad 200. Najczęściej bombowe, ale bywało że biegali terroryści z karabinami i strzelali do ludzi. Motywacja - religia chrześcijańska. Ostatni zamach był w listopadzie 2015, zginęły 3 osoby. No ale to nie Europejczycy, nie liczymy.
• Nie wliczę również częstych w latach 70-tych porwań samolotów. Robiły je różne organizacje, niekoniecznie europejskie, trudno zliczyć ile ludzi zabili terroryści a ile zginęło od kul szturmującej policji, więc żeby uniknąć sporów tylko honourable mention. Ale nie zapominajmy, że żadne inne akcje terrorystyczne nie spowodowały jakichś trwałych zmian w społeczeństwie - a przez te porwania wprowadzono kontrole pasażerów i bagażu przed wejściem do samolotu. Możemy to zobaczyć na filmach - na przykład w pierwszych filmach z cyklu o Gangu Olsena bohaterowie bez problemu wsiadają do samolotów z walizkami pełnymi gotówki. w ostatnich bywa że akcja toczy się wokół kontroli na lotnisku.

Teraz ranking:

• Miejsce 5: Niemiecki RAF, czyli Rote Armee Fraktion (nie mylić z Royal Air Force). Body count: 34, ranni: 200+. To niedużo, ale akcje ich były bardzo spektakularne. Specjalizowali się w porwaniach i morderstwach polityków i managerów bardzo wysokiego szczebla. Motywacja: lewicowo-anarchistyczna + finansowanie z bloku wschodniego.
• Miejsce 4: Włoskie Czerwone Brygady (Brigate Rosse). Nie znalazłem body countu, ale był na pewno wyższy niż RAF-u. Plus za mocny PR - szczególnie akcja z porwaniem Aldo Moro spowodowała bajeczny wzrost rozpoznawalności marki. Nawet dzieci przedszkolne w komunistycznej Polsce ją znały. Motywacja: lewicowo-anarchistyczna.
• Miejsce 3: Hiszpańska ETA (Euskadi Ta Askatasuna) Body count: 823-864 (zależnie od źródła). Motywacja: początkowo antyfaszystowska, potem lewicowo-nacjonalistyczna.
• Miejsce 2: Europejscy chrześcijanie-katolicy z IRA. (Irlandzkiej Armii Republikańskiej). Body count 1696. (Źródło) Szczytowe osiągnięcie: 22 bomby jednego dnia w jednym mieście. Motywacja: to skomplikowane. Raczej narodowa niż religijna.
• And the number one is: OAS (Organisation de l’Armée Secrète)! Może i większość działalności tej organizacji prowadzona była w Afryce Północnej, ale byli to stuprocentowi Europejczycy. Szczytowe osiągnięcie: 120 zamachów bombowych jednego dnia w jednym mieście. Motywacja: nacjonalistyczno-kolonialistyczna. Niestety nie udało mi się znaleźć sumarycznego body countu, ale ta organizacja miała największą skalę działania i najwięcej czynnych uczestników ze wszystkich europejskich organizacji terrorystycznych. Przy OAS-ie zamachy ISIS to małoskalowe amatorstwo.

 Więc młody czytelniku przekonany że uchodźcy przynoszą nie znany tu wcześniej terroryzm do pacyfistycznej Europy: Przeczytałeś - idź i nie bzdurz więcej.

 Zacznę od paniki moralnej wylewającej się z sieci: "OMG przez uchodźców bezpieczne miasta robią się takie niebezpieczne". Chodzi oczywiście o plac przed dworcem kolejowym w Kolonii. Dlaczego mnie nie dziwi, że to mniemanie w większości pochodzi z Polski? Przecież większość głoszących to ludzi nigdy nie była w Niemczech, a zwłaszcza w okolicy jakiegoś dworca.

No mać, mać, mać, serio ktoś kto był koło jakiegoś większego dworca kolejowego w dużym mieście w Niemczech uważa to miejsce za przyjemne i bezpieczne? Zwłaszcza w nocy?

Zaraz minie siedemnasty rok jak mieszkam we Frankfurcie. Na początku przez parę tygodni mieszkałem akurat w dzielnicy blisko dworca (na szczęście nie w tej najgorszej części), potem przez ileś miesięcy codziennie wysiadałem z U-Bahnu na dworcu idąc do pracy. Oczywiście było to zawsze w dzień. I nigdy nie czułem się tam szczególnie bezpiecznie. Dworzec kolejowy to zawsze jest miejsce, gdzie kręci się sporo różnych ludzi z którymi niekonieczne chciałoby się wchodzić w bliższe interakcje - jacyś narkomani na głodzie, kieszonkowcy, bezdomni,  nierzadko próbujący zdobyć jakąś kasę na używki w sposób nie zawsze legalny, a często dość nachalny. We Frankfurcie dzielnica bezpośrednio przylegająca do frontu budynku dworca to siedlisko wątpliwej rozkoszy i niewątpliwej rzeżączki, z całą przestępczą otoczką jaka się zawsze w takich miejscach tworzy. Jest tam też siedziba "klubu motocyklowego", czyli zorganizowanej przestępczości na motocyklach (Hell's Angels), co pewien czas zdarzają się tam ustawki, bywa że z ofiarami śmiertelnymi. Jest to jedyne miejsce w okolicy którego staram się unikać. Nie żebym miał jakieś lęki, ale po co, jeżeli nie trzeba? Czysty rozsądek.

I to wszystko nie jest nowe - proszę, tu zdjęcie z tej okolicy z roku 1987:

Frankfurt, dzielnica koło dworca, 1987

Byłem na placu między katedrą a dworcem w Kolonii dwa i pół roku temu, przed tą całą sytuacją z uchodźcami. No i mimo że było niedzielne południe, to czułem się tam jeszcze mniej bezpiecznie niż we Frankfurcie. Nie, nie mam żadnej paranoi, nie mam problemu jak jest tłok, nie rusza mnie jak jest brudno albo niesympatycznie. Ale widzę zaraz kto kombinuje co by tu zwędzić, kto szuka zaczepki, a kto będzie chciał mnie naciągnąć na kasę (ostatnio to chciał ze mną zwady jeden stuprocentowy Francuz w Paryżu, akurat też koło dworca, specjalnie mnie potrącił żebym zrobił awanturę, widziałem z daleka że może być problem. Zignorowałem zaczepkę, był bardzo rozczarowany). Więc nie zwalajcie na uchodźców, część z nich też tam trafi, ale nie ich uchodźstwo jest tego przyczyną i wywalenie wszystkich uchodźców żadnego problemu nie rozwiąże.

Co mnie wkurza jeszcze bardziej, to ten ton moralnej wyższości wśród Polaków, w stylu "Te pastuchy przynoszą do Europy swój prymitywny brak wyższej kultury". Młodzi ludzie, (młodzi, bo starsi pewnie pamiętają to, o czym zaraz napiszę) wam się wydaje że Polacy to takie wyższe sfery? Przypomnę, że jeszcze całkiem niedawno, w początku lat dziewięćdziesiątych, Niemcy mieli bardzo poważny problem z Polakami masowo przyjeżdżającymi "na jumę", czyli po prostu i ordynarnie kraść. Nie na drobne kradzieże kieszonkowe, jak ci z Kolonii - oni kradli wszystko co się dało zabrać i nie było pilnowane, aż do luksusowych samochodów włącznie (niemiecki dowcip z tamtych czasów: "Jedź na wczasy do Polski! Twój samochód już tam jest!"). Pamiętam wywieszki w Aldim po polsku "Wszystkie towary wyłożyć na taśmę i bez dyskusji" - nie, nie była to szykana tylko reakcja na konkretne wydarzenia. Kolega z Berlina, z którym wtedy współpracowałem w branży IT zaciągnął mnie kiedyś na ten słynny bazar, na którym handlowali Polacy, to był straszny wstyd i żenada, po paru minutach zażądałem żebyśmy już stamtąd sobie poszli. Dziś już jest trochę lepiej, ale jakiś Polak robiący bydło ciągle się zdarza (bywa przecież, że i znany polityk). Mam w dzielnicy meczet i polską parafię katolicką i więcej problemów robi ta parafia polska. Nawet jej proboszcz (którego przypadkiem znam osobiście) skarży się, że jak organizuje festyn parafialny to zawsze mu się paru schleje, a bywa że się po pijaku pobiją albo coś zdemolują. Ale tym pastuchom to brak kultury, nie to co nam.

Sorry że mi się ulało, jak skończę z przechodzeniem na Windows 10 na komputerach w domu postaram się napisać coś weselszego.

Każda, najfajniejsza nawet idea jest nic nie warta, jeżeli nie pasuje do realnie istniejącej rzeczywistości. W różnych dziedzinach ten reality check następuje w różnym czasie i w różnym nasileniu. Niektóre branże, na przykład filozofia (czy ogólnie nauki tzw. humanistyczne), mają znikomy styk z rzeczywistością, inne trochę większy, ale prawie zawsze da się ewentualne niezgodności wyprzeć jakimś "ale gdyby...". Jest jednak jedna branża w której od idei do jej brutalnej konfrontacji z rzeczywistością jest bardzo blisko - jest to informatyka. Przyjrzyjmy się więc informatyce omawianego okresu.

Realna - nie teoretyczna - informatyka, zaczęła się oczywiście od skonstruowania pierwszych, praktycznie działających komputerów. Najpierw programowano je czysto na wyczucie w kodzie maszynowym, później pojawiły się assemblery a potem pierwsze języki wysokiego poziomu jak Fortran czy Cobol. Syntaktyka tych języków została wymyślona zupełnie od czapy, jak tam się komuś wydawało że będzie dobrze. Wkrótce zaczęły się problemy z takimi odczapistycznymi definicjami - najbardziej znana jest historia błędu w programie fortranowym polegającego na tym, że ktoś zamiast przecinka w instrukcji pętli napisał kropkę. Skutek był taki, że sonda międzyplanetarna sterowana tym programem się rozwaliła. Zasadniczy problem polegał na tym, że języki programowania były zdefiniowane tylko opisowo w języku naturalnym, i każdy mógł interpretować taką definicję inaczej. I jak wtedy zapewnić, żeby ten sam program dawał te same wyniki skompilowany różnymi kompilatorami?

No i to było coś dla wyznawców rozumu - tym trzeba było się zająć naukowo. Zaczęto więc pracować nad dobrym definiowaniem języków programowania. Efektem tych starań był Algol 60. I trzeba przyznać, że to im się akurat udało. Algol 60 został zdefiniowany przy pomocy matematycznego formalizmu (notacji Backusa-Naura), pięknie i klarownie. Koncepcyjnie język ten nie różnił się znowu aż tak bardzo od obecnie używanych języków proceduralnych w rodzaju niegdysiejszego Pascala, C czy Javy (Javy bez obiektów oczywiście, obiekty to późniejsze koncepcje). W zasadzie jedynym istotnym błędem zrobionym przez projektantów tego języka było to, że nie pomyśleli o zdefiniowaniu instrukcji wejścia-wyjścia i każda implementacja miała inne. Ale ogólnie był to sukces idei.

Zachęceni sukcesem rozumowcy zajęli się następną ideą: Program zapisany jest przy pomocy matematycznego formalizmu. Całkiem jak na przykład twierdzenie matematyczne. Twierdzenie matematyczne dowodzimy, żeby sprawdzić czy jest poprawne. Dlaczego by nie zrobić tego samego z programem? Będziemy dowodzić poprawności programu tak samo jak twierdzenia i błędy w programach nie mają szans! No i oczywiście ten dowód ma zrobić automatycznie komputer!

Na pierwszy rzut oka idea była całkiem dobra. Pojawiło się mnóstwo prac i projektów na ten temat i nawet jakieś metody udało im się opracować. Ale teraz pytanie kontrolne dla czytelników zajmujących się programowaniem: Czy dowodzicie w sformalizowany sposób poprawności swoich programów? Jak sądzicie, dlaczego nie?

Ja wyjaśnię. Otóż ta koncepcja to totalne nieporozumienie. Dowiedzenie poprawności programu to wykazanie, że on robi dokładnie to, co ma robić. Skąd dowodzący poprawności komputer ma wiedzieć co program ma robić? Trzeba to zapisać w jakimś formalizmie. Łapiecie? Komputer ma porównać formalny zapis tego co program ma robić z formalnym zapisem tego jak program to robi. Czyli raz zapisujemy rozwiązanie problemu w formalizmie "celowym" a drugi raz w "implementacyjnym". No ale tak w zasadzie to jeżeli komputer potrafi porównać jeden formalizm z drugim, to chyba powinno się dać przekształcić jeden w drugi, czyż nie? Czyli ten nasz formalizm "celowy" to w zasadzie język jeszcze wyższego poziomu niż ten "implementacyjny". To tak właściwie na cholerę mamy pisać to samo dwa razy? Nie lepiej napisać raz, w tym języku wyższego poziomu, ale za to dobrze?

No ale załóżmy, że w jednym formalizmie napisze jeden człowiek, a w drugim drugi. Zawsze będzie to jakaś kontrola, co nie? To prawda. ale czy nie taniej i prościej będzie po prostu zrobić code review? I tak się bez niego nie obejdzie, jak chcemy robić porządnie.

Jest jeszcze drugi zarzut, o wiele poważniejszy. Przez takie formalne dowodzenie porównujemy nic więcej niż tylko dwie wersje rojeń na temat działania programu. Jeżeli obie wersje stworzy jeden człowiek, to nasze dowodzenie udowodni najwyżej, że jego rojenia są spójne. Przy dwóch różnych autorach będzie to dowód na spójność rojeń dwóch ludzi. Ale to nie jest wiele warte - tak naprawdę interesuje nas nie zgodność programu z rojeniami człowieka, tylko zgodność programu z rzeczywistością! Jeżeli programista będzie przekonany że jego program dostaje do obróbki znaki kodowane w ASCII to ŻADNE dowodzenie nie wykryje że program jest bez sensu, bo dane są w EBCDIC. Świat zewnętrzny, you fool!

I tak mniej więcej to się skończyło - pamiętam z jakiejś książki przykład udowodnionego i opublikowanego jako programu na 15 linii, w którym  przez ręczną analizę znaleziono 10 błędów. Jeszcze później prace matematyków wykazały, że na przykład rozstrzygnięcie czy pętla w programie się kiedyś skończy, czy nie, jest w ogólnym wypadku niemożliwe. Czyli to i tak nic nie da.

Oczywiście zgadzam się, że używamy dziś narzędzi sprawdzających to czy tamto w programach, ale z formalnym dowodzeniem nie ma to nic wspólnego.

I jeszcze: Nawet gdyby takie dowodzenie działało, to nadawałoby się tylko do niektórych, dobrze zdefiniowanych kawałków, na przykład do sortowania tabeli czy innych zadań algorytmicznych. Ale typowy, realnie istniejący program, to jest taki wielki, wielopoziomowy switch (ewentualnie schowany pod postacią hierarchii klas) wewnątrz pętli nieskończonej, jak i czego tu dowodzić?

No ale tymczasem rozumowcy zajmowali się dalszym doskonaleniem na drodze do ultymatywnego zapanowania nad przyrodą. Teraz miała powstać nowa wersja Algolu, tym razem idealna, uniwersalna i ultymatywna (serio zapewniali, że nic innego nie będzie już potrzeba!). Wytoczono najcięższe armaty: do definicji formalnej van Wijngaarden opracował gramatykę dwupoziomową, która dawała możliwość ślicznego i ścisłego opisania języka. Twórcy Raportu języka uważali że jest on tak piękny i skończony, że zostało tylko wycyzelowanie ozdobników. Każdy rozdział raportu ozdobiono pasującym cytatem z literatury, zadbano nawet o reguły ozdabiania rozdziałów przy tłumaczeniu ich na inne języki naturalne. Język nazwano Algol 68 i był to chyba jedyny język programowania który najpierw w 100% zdefiniowano formalnie, a dopiero potem przystąpiono do jakichkolwiek prób implementacji kompilatora. No i tu zaczęły się problemy. Jak już pisałem - świat rzeczywisty, you fool!

• Raport był słabo zrozumiały, bo użyta notacja nie była prosta. Aż trzeba było opracować całkiem nową, bardziej zrozumiałą jego wersję, zwaną Revised Report, potrwało aż do 1973. Przy okazji wywalono z języka parę konstrukcji jako zbędnych i przekombinowanych.
• Revised Report miał 280 stron tekstu i to tylko na formalizm plus krótkie komentarze. Przecież czegoś takiego nikt nie ogarnie! Dla porównania raport Algolu 60 miał stron ze czterdzieści włącznie ze skorowidzem, przeciętny, ogarnialny język daje się zamknąć w dwudziestu-trzydziestu.
• Raport definiował na przykład że słowa kluczowe mogą być w różne w różnych językach naturalnych. Każdy, kto używał formuł w różnych wersjach językowych MS Office z pewnością znajdzie dla tego pomysłu kilka prostych, żołnierskich słów.
• Parser Algolu 68 okazał się niespodziewanie trudny do napisania. Ludzie próbowali, próbowali, ale udawało im się parsować tylko podzbiory konstrukcji języka. A przecież definicja formalna była taka piękna!

Raport języka Algol 68

Wkrótce sprawa rypła się całkiem. Ktoś udowodnił, że gramatyki van Wijngaardena są nierozstrzygalne, czyli że napisanie kompletnego parsera tak zdefiniowanego  języka jest niemożliwe. No i to był cios w sam fundament projektu, który przecież miał być wspaniałym, ostatecznym i nieskazitelnym pomnikiem ludzkiego geniuszu. A okazał się być pomnikiem arogancji i zadufania.

Historia Algolu 68 jest typowa dla tamtych czasów i podobne znajdziemy również w innych branżach. Nimi zajmiemy się w jednej z następnych notek.

Przez całe wieki a nawet tysiąclecia znaczący udział w zwycięstwach militarnych´mieli rzemieślnicy produkujący broń. Bitwy i wojny wygrywała najczęściej strona mająca więcej i lepiej wyszkolonych żołnierzy i lepszych dowódców. Ale nie bez znaczenia była posiadana przez nich broń, a co najmniej od czasu wynalezienia miecza z miedzi robili i ulepszali ją rzemieślnicy.

Taki stan rzeczy trwał bardzo długo, ale w czasach rewolucji przemysłowej zwycięstwo lub przegrana zaczęły w coraz większym stopniu zależeć od inżynierów. Już Kościuszko w USA robił za generała, ale do zwycięstwa przyczynił się przede wszystkim jako wojskowy inżynier. Dalej widać to było coraz wyraźniej - w różnych wojnach w koloniach, w wojnie francusko-pruskiej, przewagę zdobywała strona mająca więcej i lepszą, przemysłowo produkowaną broń zaprojektowaną przez inżynierów. Szczytem była WWI, gdzie użyto mnóstwa nowych, wyinżynierowanych broni - na przykład sterowca, samolotu, okrętu podwodnego i całej masy inżynierskich ulepszeń broni istniejących.

Po WWI sytuacja uległa zmianie. To znaczy większość broni wymyślali nadal inżynierowie, ale zwycięstwo zaczęło w coraz większym stopniu zależeć od naukowców i to z pozornie niewojskowych specjalności. Na przykład od matematyków.

Już w wojnie polsko-rosyjskiej 1920 grożącą całkowitą klęskę udało się Polakom zmienić w zwycięstwo praktycznie wyłącznie dzięki pracy kilku matematyków o specjalności kryptologia. Kryptolodzy mieli swój zasadniczy udział w przebiegu i wyniku WWII, ale i inne specjalności dostały swoją szansę. Fizycy zrobili na przykład bombę atomową, obliczenia robili im inni matematycy. Ale o wiele większe znaczenie miały prace całego legionu innych, szeregowych matematyków, którzy zajmowali się optymalizacją efektywności wysiłku wojennego. Na przykład opracowywali statystyczne metody kontroli jakości, umożliwiające znaczące zmniejszenie ilości amunicji marnowanej w każdej partii na testy jakościowe. Albo rozpracowywali zagadnienia w rodzaju "czy dywizjon bombowców nocnych ma lecieć w szyku ciasnym - ryzykując zderzenia, czy luźnym - ryzykując zgubienie formacji albo zestrzelenie przez myśliwce". Kampanie wygrywano dzięki optymalizacji logistyki i minimalizacji strat.

Po wygranej WWII, jako synteza tych prac, powstała nowa dziedzina zwana "cybernetyką". Wcześni cybernetycy - jak to zwykle neofici - wierzyli że wszystkim da się bezproblemowo sterować i kierować. Naprawdę wszystkim, nie tylko prostymi układami. Tak samo miało się sterować temperaturą pieca, jak całą fabryką, mózgiem, organizmem żywym, ekosystemem (we współczesnym rozumieniu), społeczeństwem czy państwem. Dziś wiemy że były to mrzonki, że nawet pozornie proste systemy mogą być chaotyczne i sterowanie nimi nie jest trywialne abo wręcz jest niemożliwe.

No ale w tamtych czasach wszystko wyglądało na proste a nauka i rozum miały wkrótce zapanować nad całym światem ludzie mieli być dzięki temu szczęśliwi i żyć w dostatku i dobrobycie. Na pierwszy rzut oka taka koncepcja wydaje się być bardzo komunistyczna, ale tak myślano również w krajach kapitalistycznych. Wystarczy zajrzeć na okładki pism popularno- naukowych tamtych czasów. Czy to "Młody Technik",

Okładka pisma "Młody Technik"

czy "Technika Mołodieży",

Okładka pisma "Technika Mołodieży"

czy "Popular Mechanics"

Okładka pisma "Popular Mechanics"

- wszędzie widzimy taki sam futurystyczny, czysty, stechnicyzowany świat wielkich budowli, szybkich pociągów, wspaniałych samochodów, olbrzymich statków, wielgachnych pojazdów latających i lotów międzyplanetarnych. No i wielkich, inteligentnych komputerów.

A to wszystko miało być możliwe dzięki cybernetyce. Niedługo wcześniej wynalezione tranzystory umożliwiły zbudowanie układów elektronicznych naśladujących zachowanie organizmów żywych. To znaczy tak twierdzono, w praktyce były to proste zabawki elektromechaniczne, byle by miały jakiś czujnik. Na przykład słynne "cybernetyczne żółwie" były to po prostu elektryczne samochodziki z czujnikami, reagujące na przykład na dojechanie do krawędzi stołu. No ale było jakieś sprzężenie zwrotne, więc zabawka była cybernetyczna. Wkrótce praktycznie każda zabawka z silnikiem elektrycznym (jeżeli nie była zdalnie, wtedy przewodowo, sterowana) nazywała się "cybernetyczną".

Cybernetyczny żółw - skan z książki Janusza Wojciechowskiego "Nowoczesne zabawki" (1963)

Kiedy wymyślono perceptron - czyli prostą sieć neuronową - wydawało się, że wkrótce da się skopiować mózg człowieka, a potem taka kopia będzie odwalać za człowieka robotę intelektualną. Miało to być tak niedługo, że nawet realnie istniejące wtedy komputery nazywano już na zaś "mózgami elektronowymi".

Popatrzmy na popkulturę tamtych czasów - na Star Treka, radziecką Mgławicę Andromedy czy na Lema (który jak zwykle wszystko przewidział). A zwłaszcza na Cyberiadę/Bajki robotów, gdzie wszystko jest cyber, nawet cyberberysy.

Cyberiada była oczywiście w dużym stopniu satyrą, ale fascynacja cybernetyką - i w ogóle potęgą rozumu - naprawdę istniała. Wszędzie planowano przerobienie świata, w ZSRR chciano zawracać rzeki wyrąbując kanały atomówkami, w Niemczech koryta większości rzek wybetonowano, żeby porządnie płynęły. Na Nilu zbudowano wielka zaporę, bo wylewał, itd. itd., wszystko miało być lepiej, bardziej naukowo. Jak na razie sukcesy były znaczące. "Zielona rewolucja" bardzo zmniejszyła zasięg klęsk głodu w różnych krajach, szczepionki i antybiotyki zmniejszyły śmiertelność, człowiek poleciał w kosmos i postawił stopę na Księżycu.

I to jest moment, w którym rozpoczęto projekt Cybersyn. Jeszcze wszystko wydaje się proste, świat wydaje się iść ku lepszemu, cybernetyka (w szczególności społeczna) ma być szansą lewicowego rządu Chile na przeciwstawienie się wpływom amerykańskiego wywiadu, starającego się ten rząd obalić. Trochę zadziałało - zainspirowany przez CIA strajk kierowców udało się przetrwać, chociaż niekoniecznie dzięki cybernetyce. Kolejnej próba obalenia rządu była jednak udana, cybernetyka nie pomogła. System nie był gotowy, ale bardzo wątpię żeby działający był w stanie uratować Allende, a nawet dobrze działać. Wyznawcy cybernetyki i potęgi rozumu byli zbyt optymistyczni, już w początku lat 70-tych zaczynało to być widoczne. A przynajmniej widać to z dzisiejszej perspektywy.

Po czym to widać? Ooooo - na to mam mój ulubiony przykład. O nim w następnej notce.