Zamilkłem nieco na blogu, bo głównie rzecz biorąc, ostatnio dogoniła mnie praca, ale też chandra jesienna oraz sen zimowy (niechce)misia.
"Praca dogoniła" mnie ostatnio w sensie wstępnego odbioru projektu/systemu, nad którym głównie siedzę od roku, bo inne rzeczy to były drobiazgi za kogoś, albo małe miki. Odbiór wstępny, tj. "u nas" czyli u dostawcy, tak zwany FAT (factory acceptance tests), planowany na parę tygodni, główna dokumentacja samego FAT to ok. 100 stron raczej drobnym drukiem, plus zylion aneksów i dodatków. (Nie mylimy FAT z uruchomieniem i odbiorem systemu u klienta, tzw. SAT (site acceptance test)).
FAT robiliśmy w wersji zdalnej, tj. głównie przez Teams. Klient: Big Pharma (koncern z pierwszej piątki światowej), konkretnie zakład średniej wielkości, w innej części Irlandii (ale tu wszędzie jest blisko i to bez znaczenia). Konkretny współpracujący automatyk "u klienta": młodszego pokolenia, bardzo w porządku, bardzo kompetentny, i dość wyrozumiały.
Systemy to średnia SCADA plus wszelkie wodotryski do niej, obsługująca "infrastrukturę" od zaplecza działu fabryki, ale że to farmaceutyki, to i od zaplecza jest niezła paranoja, tudzież pewne urządzenia i instalacje podlegają np. sterylizacji i testom produkcyjnym "na pełnym wypasie", jak maszyny "naprawdę" robiące leki itp. Czyli ilości dokumentacji, zatwierdzeń i testów są przytłaczające w porównaniu z moimi pracami z "poprzedniego życia", nawet z sieciami energetycznymi, czy wielkoskalowym wod-kan.
Ogólnie, projekt to upgrade tejże SCADA+dodatków z wersji około 2009 na wersję około bieżącej (bo zanim skończyliśmy, już jest nieco nowsza...). Migracja połowy SCADA to pestka, ale drugiej połowy to koszmary. Dodatki, jak Historian czy tzw. "batch system", czy migracja baz danych za ostatnie ileś tam lat, to koszmary do kwadratu.
Wszystko jest wirtualizowane w hypervisorze, kluczowe 5 czy 6 serwerów, plus 4-5 maszyn pomocniczych (rzecz jasna, nigdy wcześniej nie robiłem w aż tak wirtualizowanym środowisku, no ale po paru tygodniach z grubsza ogarnąłem o co kaman). Plus mój laptop, chmury, Teamsy, VPNy i całe "podręczne" IT
W projekcie przez rok nieco pomagali mi koledzy, przeważnie kompetentni, przeważnie pomocni. Słowo kluczowe "przeważnie".
W trakcie FAT wyszło sporo fakapów (klika klasy "fail", czyli po prostu coś nie działa; plus garść klasy "deviation" czy "observation", czyli testy/projekt są do d..., ew. wszystko działa, ale inaczej niż klient by to widział, czy ma w starej wersji). Po pierwszej fazie testów i faili, ruszyłem w poprawki i zrobiliśmy re-testy rzeczy "łatwych i oczywistych".
W drugiej fazie, przyszło wyrzucić pewne grube migracje zrobione przez kogoś tam, i uzgodnić z klientem inne podejście do tematów bazodanowych itp. (BTW klient miał "nie wiem, po co upieraliście się na "oficjalny", ale "niedziałający", sposób A, kiedy to, co teraz mówisz w wersji B to właśnie tak, jak bym to widział"). W małe parę dni zrobiłem migrację inaczej (inna struktura baz danych plus pewna grzebologia w SQLu, w dosyć mętnych wodach), i nawet działa, tj. można se dane czy raporty obejrzeć z dzisiaj, i z 2010, jeśli ktoś potrzebuje.
W trzeciej fazie, okazało się, że kluczowy efektowny, skomplikowany i dynamiczny raport z operacji typu sterylizacja itp. w szczególnych wypadkach, których nie miałem jak przetestować wcześniej, albo mi umknęły, nieco rozsypuje formatowanie. A mówimy o wymaganiach, żeby nowy raport = stary raport, z dokładnością do "/" czy "-" w formacie daty, czy justowaniu kolumn, czy oryginalnym logo oryginalnego dostawcy systemu (ze trzy firmy-dłubacze temu).
Nowe raporty robi narzędzie SSRS od Microsoftu, dedykowane do MS SQLa itd. (stare to było CrystalClear). Raport zrobiłem miesiące temu, w wersji "minimalistycznej" od zaplecza (zamiast "wypasionej", z zylionem sub-raportów i w full projekcie Visual Studio) i wydawało się, że jest tiptop (wyniki oceniał klient, wnosił zastrzeżenia i poprawki, itp). Na tyle tiptop, że koledzy nieco nadzorujący projekt, chociaż krzywili się na moje siermiężne rozwiązanie i "nie tak to robimy", machnęli ręką; choć deklarowałem, że mogę przerobić na full wypas, jeśli "to ważne". Nie było ważne i zostawiliśmy to.
Ale okazało się, że jednak, w naprawdę dynamicznym raporcie, kiedy różne części pojawiają się i znikają praktycznie dowolnie, to ważne, bo nie sposób bez sub-raportów opanować formatowania, szczególniej "whitespaces", czyli pustych miejsc itp. gdyż taka jest wizja twórców SSRS, a jak się nie podoba, to trzeba było nie używać SSRS. A obejść problemów "hakami" się nie dało, bo jw. w tej branży standardy są takie, że np. nie ma mowy, że raport w szczególnym przypadku będzie miał dodatkową pustą stronę "rozdzielającą" (numerowaną itd., ale pustą).
Wkurzyłem się, i jednak przerobiłem raport na sub-raporty itd. itd. w parę dni; zajęło to znacznie dłużej niż myślałem, chociaż "mięsko" mogłem copy-paste z poprzedniej wersji, no ale logikę od strony SQLa (datasety, dynamikę), czy szczegóły formatowania, musiałem zrobić od podstaw. Na koniec nadziałem się na niesamowite kolejne poziomy "jak developerzy SSRS widzą pewne rzeczy i dlaczego końmi ich za to należy po majdanie włóczyć"; z pół dnia i wieczór nad jednym durnym nagłówkiem jednego sub-raportu przesiedziałem.
Ale w końcu wszystko poszło jak trzeba, z formatem ideololololo. Tylko, że jakieś 10 razy za wolno. Zacząłem wnikać, czemu to się pie... a nie robi, ale nieco zabrakło mi czasu.
Bo czas nam zaczął się kończyć (klient wolne se bierze mocno przedświątecznie), więc tylko re-testowaliśmy format i funkcje automatycznego generowania raportów w SCADA, itd. rzeczy najważniejsze, żeby "zamknąć" FAT; a co do wydajności "w czasie", ustaliliśmy, że dopiszemy uwagę (bo oficjalnie na to testu nie mieliśmy i nie robiliśmy), i poprawię czas generowanie raportów do poziomu akceptowalnego, czyli "jak obecnie w zakładzie". Bo tak czy owak na SAT temat wróciłby jak bumerang, i ew. produkcja/operatorzy wynieśliby mnie na kopach, jeśli raport generowałby się trzy razy dłużej, niż poprzednio.
Zanim puściłem oficjalne info o zakończeniu FAT i uwagi, udało mi się w pół dnia dokończyć ustalanie, czemu to się niewiarygodnie wolno miele (główna zasługa, to spie... wizja kwerend, jakie ktoś napisał w SQLu dla danych do ślicznych wykresów temperatur, ciśnień itp. 10 lat temu; ale znowu, developerka SSRS też miała tu za uszami sporo...), i poprawić co nieco. Na tyle, żeby omówić z klientem w ostatnim momencie, czy zgadza się na przerobienie paru kawałków kwerend "po mojemu". Klient klepnął, info poszło bez uwag; a po dopieszczeniu bebechów, generacja jest jakieś 30% szybsza niż starego raportu na obiekcie.
Czyli wszystko dobrze się skończyło. Chyba. Ale ostatnie parę tygodni było ciepło.
Morałów jest kilka, oczywiście:
Pandemia (praca z domu, zdalna, brak kontaktu twarzą w twarz, itd.) nie pomagała, oczywiście.
Nawet w nowej pracy, na "wysokim poziomie", trzeba być znacznie bliżej wymagającego klienta, niż szefowie/ menagerowie/ kołorkerzy sugerują, czy nawet nieco: izolują. Byłoby o parę fail na FAT mniej, jakbym wymienił z klientem dwa razy tyle emaili itd.
Nawet w nowej pracy nie należy przesadnie wierzyć w rozwiązania jakie podsuwają doświadczeni koledzy, albo jakie "kiedyś zrobiliśmy i działały (drobnym druczkiem: albo i nie)".
W ogóle nie należy ludziom przesadnie wierzyć, gdyż niektórzy prezentują na fasadzie profeskę i wiedzę, a od zaplecza mają raczej: pokłady niepewności i kolosalną beztroskę (w mojej ocenie) w aplikowaniu "czegokolwiek gdziekolwiek", aby tylko jakoś utrzymać wizję profeski i wiedzy, nie ważne jakiej jakość rozwiązania dostarczają.
O mantrze "nie naprawiamy hałd zjebologii starożytnej, tylko minimum "żeby działało", bo nie za to klient przy upgrade starożytności płaci", można by książkę popełnić. Bo są tu różne podejścia i możliwości, najróżniejsze ryzyka i rozwiązania. Czego parę przykładów było w projekcie.
Niezbadane i pokrętne są ścieżki rozumowania projektantów i developerów Microsoftu, tu - SSRS. Ale "a co nowego", akurat miewałem do czynienia a to z API Win, a to z bebechami Office, itd. itp. więc niby się wie. Ale nadal, zdziwko.