@boni
"programowane mniej więcej tak"

No ale to było 20 lat temu, a mi w zeszłym roku firma zewnętrzna przyniosła "śliczny" system generujący test cases dla modułu zrobiony bardzo podobnie, tylko w Excelu i jeszcze o wiele gorzej. Powiedziałem, że tego g... używać nie będę bo to pozostawia trwałe szkody w mózgu i jak poprawiłem ich moduł dla nowego rocznika zrobiłem swoją generację, porządnie. Tyle że i tak nic nie pomogło - w starym roczniku trzeba było coś poprawić , zaktualizować testy w tym szicie i wykonać je jeszcze raz. Skąd się tacy biorą, co taką tabelkę uważają za świetną metodę?

@cmos

Ale bo to testy, testy to nieważne, stażysta wyklikał se kiedyś cases w Excelu i nikomu nie stała się krzywda. Tak, wiem, że jest inaczej, no ale taki mindset pokutuje tu i ówdzie, znajomych testerów uprasza się o nie wylewanie nadmiernie łez w komentarzach.

A to z notki od DCSów, to tak na oko jest moralnie sprzed 30 lat, ale ktoś (podejrzenie - wielki dostawca zaworów, pomp i innego uju-muju), pocisnął to 20 lat temu w pakiecie razem z hardwarem typu hardveryhardware. No bo w 1996 czy 98 PLC programowało się praktycznie identycznie jak dzisiaj. Ale te DCSy jednak nie.

Coś mi umyka - to nie można zamiast modernizacji zrobić zupełnie nowego systemu?

@mgr Sianko "Coś mi umyka"

Tak, ten fragment:

nie ma mowy o jakichkolwiek dłuższych wyłączeniach i przeróbkach; trzeba będzie wszystko uruchamiać równolegle i po uczciwym zwalidowaniu, przekładać sterowania "w locie".

(Czyli nowe kawałki zastępują stare po trochu, więc muszą się z tymi starymi dogadywać...).

@mgr Sianko

Taki jest sens dyskutowanej "modernizacji" (no bo jak modernizujesz wszystko, od fizycznej sieci po SCADA i top level, to przecież robisz "zupełnie nowy system"). Ale wyraźnie umyka ci główny fakap tego tematu - nikt nie ma i nie planuje budowy nowej stacji uzdatniania wody, żebyśmy se mogli grzebać w obecnej, co nie; ani nawet jej zatrzymywania poza jakimś minimum - więc ten "zupełnie nowy system" ma być zrobiony na istniejącym obiekcie, w locie.

Pomysłu, że ktokolwiek zrobi CAŁY system sterowania na 100 ekranów, 3000 obiektów i 10000 tagów równolegle do istniejącego, raczej słabo udokumentowanego (czy wspomniałem, że gdzieś zgubili schematy WSZYSTKIEGO?), po czym w jakiś weekend przerzucimy wielką wajchę i nowy system przejmie wszystko ze starego i będzie okej, nie muszę uwalać nawet u głupkowatych czy niekompetentnych klientów, więc na blogu też nie mam zamiaru. Stąd - trzeba będzie robić po kawałeczku i solidnie walidować (BTW darmo podpowiedziałem szefu jak to można zrobić w miare solidnie i tanio, gupi ja), pompę po pompie, filtr po filtrze, pomiar po pomiarze, sterownik po sterowniku, itd itd.

No, jest jeszcze opcja, żeby se zbudować w miarę mocny i dokładny symulator istniejącego nieznanego obiektu - tylko ciekawe jak, kto i za co. Raz w życiu widziałem taką udaną akcję, dla maszyny wielkości biurka i rzędu 200 I/O, więc przy "nieco" większych projektach "życzę powodzenia, nie wróżę sukcesu" (BTW często wbrew szefom, którym dużo się w temacie wydaje).

Ogólny sit-rep - po dzisiejszych rozmówkach, także z klientami, sprawa z notki zawisła w pustce, bo się te outsourcowane utrzymania ruchu pogubiły (jedne joint-venture właśnie tydzień temu poszło w pizdu i już go nie ma, drugie nie ogarnia, trzeci chcą ale nie mogą, itd). Ale niestety, ostatni news jest taki, że z obecnych oferentów tylko my (as me, myself and szefu) wypadliśmy na tyle przytomnie i kompetentnie, że Główne Ogniwo w zasadzie z nikim poza nami nie chce gadać. Tyle, że gadać nie może, bo jw. nie ma pod ręką szemranych firm, firemek i podmiotów, które byłyby władne rozmawiać o szczegółach, szczególniej planowania i finansowania tej modernizacji.

(no i gdzie są wasi IT bogowie i guru AD2017? i stylowe wcięcia i formatowania?)

Ale assembler nowoczesny był ponad pół wieku temu, a nie w 1997, więc ten program to jednak eksponat muzealny. Inna sprawa że napisać coś takiego jest względnie łatwo, ze wsparcia potrzebna tylko kartka papieru, więc motywacja dla piszącego (write-only ;-)) nie jest tak duża żeby np. robić porządną kłótnię z szefem.

@Maciek
"Ale assembler nowoczesny był ponad pół wieku temu"

Po pierwsze to to nie jest assembler.
A po drugie: Co to znaczy "assembler był nowoczesny"? W pewnych sytuacjach assembler musi być i to nie ma nic wspólnego z "nowoczesnością" czy inną modą. U nas też są kawałki w assemblerze, tak, dziś - przecież różnych elementów startupu systemu, podłączenia OS-a do sprzętu itp. nie zrobisz inaczej.

Nie znam się na automatyce przemysłowej, uczestniczyłem natomiast w projektach IT, gdzie zastępowano np. stary system bankowy nowym - opartym na innych technologiach i innej architekturze. Dało się, kasa na kontach się zgadzała.
Wracając do tej stacji, wystarczy chyba, że z rury na końcu leci woda o określonych parametrach, a czy system sterowania ma 100 ekranów czy 10 to chyba mało ważne?

@mgr Sianko
"zastępowano np. stary system bankowy nowym (...) Dało się, kasa na kontach się zgadzała. "

Jest jednak zasadnicza różnica między systemem przemieszczającym tylko bajty na dyskach, a systemem który robi coś z obiektami świata rzeczywistego.

@mgr Sianko
To nie tak prosto. Miałem okazję obserwować proces zastępowania jednego systemu SCADA drugim i sama weryfikacja interpretacji poszczególnych sygnałów z poszczególnych sterowników zajęła ekipom pracującym na dwie zmiany chyba z rok czasu. Sygnał po sygnale, z kopii ruchu produkcyjnego, z porównaniem starego i nowego systemu. Po prostu nie możesz sobie pozwolić na to, że "w jednym razie na sto" zasterujesz nie tym co trzeba albo źle zinterpretujesz "jeden sygnał na tysiąc" - bo to się może skończyć, w najlepszym przypadku, poważnymi stratami materialnymi jak coś się rozwali albo operator nie zareaguje bo zmylą go odczyty.

A to tylko warstwa "wzajemnego zrozumienia na poziomie softu" - a to co piszesz o "100 czy 10 ekranach" to kolejny obszar pełen pułapek. Pamiętaj, że na tych 100 ekranach ludzie pracowali wcześniej X lat, mają nawyki, przyzwyczajenia co do sposobu pracy, odczytu stanów etc. Jak im to zmieniasz to naprawdę musisz dopilnować tego, żeby nawyki ze starego systemu nie prowadziły do katastrofalnych dyspozycji w nowym.

I właśnie parametry wody (oraz tego że np. nie uszkodzisz pracownika uruchomieniem jakiegoś podsystemu w nieodpowiednim czasie) zależy także od tego czy operator nie myli się w nowym UI.

@mgr Sianko

Sugerowałbym nie przenosić doświadczeń z w miarę czystego IT na inne dziedziny wydające ci się IT, no bo też są w nich komputery. Na przykład, co w temacie w notce wydaje ci się ekwiwalentem "mamy skopiowaną bazę danych starego systemu bankowego, co do ostatniego nazwiska, adresu zamieszkania, bitu i grosza, i możemy to potraktować jako dane wejściowe nowego systemu oraz do dalszych testów"?

wystarczy chyba, że z rury na końcu leci woda o określonych parametrach

No. Tylko, że udowodnić, ZANIM przełożysz wajchę na nowy system, że jak przełożysz wajchę, też będzie taka lecieć, w jakimś zakresie zmienności parametrów wody surowej (BTW z malowniczego zalewu) i całej zaangażowanej fizyki i chemii (z czym sobie radzi stary system), jest "nieco" trudniej, niż porównać se dwie bazy danych bankowych. Przypominam, woda o właściwych parametrach leci tylko dlatego, że nieustannie pracuje system sterowania operujący paru tysiącami fizycznych I/O (ostatnie obrachunki mówią o rzędu 3200 bitów ON/OFF i ze 200 wartości analogowych; co ciekawe, niby sys z 1996 a analogi w 15 bitach rozdziałki, "mieli rozmach, sk...wisiny"), no i rzędu 10k zmiennych w DCSach/SCADA.

Ogólniej, coś jakbyś dziwił się, że się ludzie tak pier... z programami dla full automatycznych samolotów, no przecież wystarczy, że ten autopilot leci w miarę równo, utrzymując wysokość i kurs. Oj, pogoda bywa zmienna. Oj, parametry lotu bywają zmienne. Ojej, on musi też wystartować... Ojej, wylądować też musi... O k... on musi sobie radzić nawet jak jeden silnik albo jedna lotka wysiądzie... O ja pie... on musi robić zylion rzeczy, poza "lecieć w miarę równo". DKJP, klient chce starego autopilota wymienić na to, co właśnie piszemy, W CZASIE LOTU...

a czy system sterowania ma 100 ekranów czy 10 to chyba mało ważne

Mam nadzieję, że to tylko nieporozumienie - w naszym języku "ekran" to nie jest "terminal" czy "klient" tj. końcówka "human-machine interface" systemu, to jest umowna miara skomplikowania i interaktywności, powiedzmy, "front-endu", czyli powiedzmy, 1 ekran SCADA = 100 elementów interaktywnych dla operatora/ utrzymania ruchu/ technologa itp. A 100 ekranów to minimum parę tysięcy, unikalnych w sensie sterowania - przycisków, cyferek, wykresów, ideogramów, ikon, itd. itd. cokolwiek se kiedyś klient i projektant wymyślili w tej SCADA do oglądania i klikania w.

Więc jednak - jest to ważne, gdyż komplikacja itd. rosną nieliniowo. Np. SCADA na 100 ekranów i 10000 tagów będzie jakieś 100 razy droższa niż taka na 10 ekranów i 1000 tagów. A nie 10 razy.

@cmos

Jest jednak zasadnicza różnica między systemem przemieszczającym tylko bajty na dyskach, a systemem który robi coś z obiektami świata rzeczywistego

Yo. Głównie z tego wrednego powodu, że ogólnie rzecz biorąc świat rzeczywisty to nie jest baza danych, a baza danych to nie jest świat rzeczywisty.

@upgrade w bankach
Należy też zauważyć, że aktualizacje w bankach nie są bezprzerwowe. Komunikaty o niemożności płatności w nocy z... na... są dość częste, taki mały upgrade to kilkadziesiąt minut. Większe upgrade'y trwają po kilka h. I te kilka h czasem się przeciąga.

@symulator
Akurat popełnienie symulatora czegoś, co działa nie wiadomo jak, bo schematy zaginęły i jest w dziwnym języku nie wydaje mi się czymś specjalnie skomplikowanym. W końcu kod źródłowy jest dostępny i przetwarzalny w postaci maszynowej. Nawet jakby miało to lecieć ze screenshotów i OCR. A mając przetłumaczony kod do "normalnych" struktur danych schematy, zależności i walidację kodu łatwo już zrobić.

Pytanie tylko, czy komuś na tym zależy, bo raczej nie automatykom, zwł. nie utrzymującym obecny system, których rola po zmianach w najlepszym wypadku spadnie i będą musieli się nowego systemu uczyć.

No i ostatecznie symulator, który bezbłędnie wypluje informacje o stanach (swoich) wyjść na podstawie stanów (swoich) wejść niewiele jeszcze mówi o stanach całości systemu. W szczególności jeśli I1 ma stan wysoki to O1 również ma stan wysoki nie mówi nic o tym, że O1 steruje wlewaniem płynu do zbiornika i po 30 sek O1 w stanie wysokim I2 zmienia się na 90 (%).

Zostałem oświecony, dzięki. Wielki szacun dla automatyków.

U ^wo http://wo.blox.pl/2017/10/Jaki-dresiarz.html#ListaKomentarzy dyskusja polityczna zdryfowała na koniec dobrych czasów dla informatyków.
Np. "Tymczasem IT zaczyna zżerać własny ogon - większość roboty, którą wykonują admini sieci, specjaliści od bezpieczeństwa, nawet programiści, da się zalgorytmizować, i to właśnie się dzieje. Jeszcze 10 lat i z tysięcy ludzi zatrudnionych w IT zostanie garstka"

Zadam głupie pytanie, na które właściwie znam odpowiedź - czy wśród założeń projektowych systemów przemysłowych jest także odporność na zmiany sprzętu i języków programowania?
Tzn. podejrzewam, że teoretycznie tak.

@boni baza danych a świat rzeczywisty

Trochę rozwinę, bo też obserwuję że czyste IT ma skłonności do rozumowania "jak rekord w bazie danych reprezentuje stan konta/bilet na imprezę/stan magazynowy itp. to operuję na obiektach świata rzeczywistego i o co kaman?"

O to kaman, że to są tylko reprezentacje i wszelkie constrainty są dla nich całkowicie opcjonalne. Nawet u nas, gdzie ruszamy tylko silnikami krokowymi, zapalamy diody i sterujemy wyświetlaczem cała masa kodu idzie na uwzględnianie zależności fizycznych typu bezwładność czy pojemność elektryczna, skutkujące tym, że trzeba dać obiektowi czas zanim się zrobi następną operację, albo trzeba robić skomplikowane sekwencje czynności dla niby prostych rzeczy (wiecie ile kroków z zachowaniem zależności czasowych trzeba żeby włączyć albo wyłączyć wyświetlacz LCD, żeby uniknąć prądów skrośnych i nie zrobić mu elektrolizy ciekłych kryształów?).
I teraz przeskalujmy to lekko licząc razy tysiąc...

@janekr

U wo jest mowa o czystym IT, w bankowości czy ubezpieczeniach od wielu lat idą w stronę automatycznej generacji praktycznie wszystkiego i rzeczywiście informatyków zwalniają (bo i co to za informatyka, maski do rekordów w bazie danych plus troszkę business logic).
Ale teraz byle spłuczka czy kierunkowskaz może mieć solidny kawał softu, ich producenci w ogóle tego nie umieją i ludzi do tego mają za mało. Tyle że tu informatyk z banku nie da rady - bo to jest coś więcej niż tylko przemieszczanie bajtów po dysku.

@rozie „działa nie wiadomo jak, bo schematy zaginęły i jest w dziwnym języku nie wydaje mi się czymś specjalnie skomplikowanym”
Słowo klucz „nie wydaje” Ci się. A wiesz, że tam jest jeszcze hardware? Dziwny język to jedno, kilkadziesiąt sterowników to drugie, a teraz uświadom sobie że tam jeszcze rozchodzą się kable, kilometry kabli w różne strony. I nie ma schematów, czyli nikt nie wie dokąd, i nikt nie wie do czego są podpięte.

Ale jeśli wysłać zły sygnał, to ktoś może zginąć, albo straty pójdą w miliony. I tego się nie da backupować, bo ludzie mają jedno życie.

@koniec IT
Buhahahaha. Zalgorytmizują i to „już się dzieje”. Chyba wymianę tonera i backup bazy danych, i może updatowanie windowsow tez. Dobrym programistom pensje rosną.

@cmos No ale nie dramatyzuj. Po to są biblioteki/sterowniki, żeby z nich korzystać. Operacje na bazie danych czy obsługa RAID hardware'owego też trywialne nie są, ale i nikt przytomny robiący jakiś projekt obsługi bazy nie pisze od zera samodzielnie. Czyli: wysokopoziomowo dostajesz sprzęt ze zdefiniowanym interfejsem, który możesz obsługiwać czysto programowo, bez wnikania w fizykę.

Styk nowoczesnego programowania ze światem fizycznym ładnie widać w świecie Arduino. Dzieci sobie spokojnie z tym radzą, nawet niespecjalnie pisząc kod, bo jest język w postaci graficznych "klocków". Napisanie czujnika cofania starego typu (im bliżej do przeszkody, tym częściej pika) w oparciu o to jest trywialne, i nie trzeba programować od zera nadawania i odbioru ultradźwięków, wyliczania odległości czy generowania "beep".

Oczywiście jeśli ktoś się uprze, żeby to był ten konkretny LCD, okodowany "temi ręcami" to będzie to wyglądało zgoła inaczej.

@charliebravo Dokładnie o tym pisałem w ostatnim akapicie. Brakuje mi określeń na system, który steruje, czyli to, na czym uruchomiona jest ta dziwnie zapisana logika, co łatwo się tłumaczy/symuluje/wirtualizuje i na cały układ, czyli zbiorniki, silniki, sterowniki itp.

Czy jest sens przepisywać tylko sterowanie? Nie wiem. Z jednej strony byłoby to bardziej utrzymywalne, można by łatwo dopisać testy, znaleźć ludzi, którzy to ogarną i np. przejmą utrzymanie. Z drugiej strony i tak zostanie grzyb w postaci starych protokołów i sterowników.

@rozie
"Oczywiście jeśli ktoś się uprze, żeby to był ten konkretny LCD, okodowany "temi ręcami" to będzie to wyglądało zgoła inaczej."

No ale na tym właśnie problem polega: Możesz sobie liczyć na stabilne biblioteki do obsługi sprzętu tylko jak masz stabilną bazę sprzętową. A nawet u nas, gdzie robimy ciągle podobne rzeczy, każdy projekt jest inny - inny procesor, inne układy dookoła, inne wyświetlacze. I nie będzie inaczej - za parę lat będą inne wymagania klienta, do których trzeba będzie użyć innego sprzętu.
Owszem, na przykład PSA kombinuje żeby dostarczać sformalizowany opis urządzenia z którego wygeneruje się całą aplikację, ale przy braku stabilnego sprzętu przesuwa się tylko problem z implementacji aplikacji na implementację generatora aplikacji.

@styk ze sprzętem
W mojej obecnej pracy robimy sobie własny kodek, bo do naszych zastosowań H264 nie dostarcza. I jak już prototyp w C będzie dobrze kompresował i miał wszystkie nietypowe ficzerki, to duża czesc dekodera zostanie ręcznie przepisana na SIMD ARMa (NEON). Kompilator, nawet z vector extensions, po prostu nie robi tego optymalnie. A my chcemy Full HD dekodować 30FPS i najlepiej na jednym rdzeniu.

A jak za rok-dwa firma zechce przejść na niwy hardware, to klienci zażyczą sobie 4k i 60FPS i znowu będzie rzeźba. I dobrze, dom sobie zbuduję.

@Arduino
Z tego, że dzieciaki sobie fajnie lampką posterują nie wynika, że system automatyki na dużym obiekcie jest łatwo zrobić. Dokładnie tak samo, jak z tego że w (tu wstawić jakiś język programowania) łatwo machnąć skrypcik na dziesięć linijek, nie wynika że łatwo można napisać system na pół miliona linii.

@cmos Czekaj, czekaj, bo mieszasz automatykę "dużą" z "małą". O ile widzę jakieś parcie w automatyce małej na mniejsze-lepsze-tańsze-bardziej energooszczędne wersje, czyli zmiany, to przy "kranikach" niespecjalnie. No chyba, że jakiś piękny umysł wpadł na to, żeby do każdego "kranika" montować teraz LCD, termometr i może jeszcze GPS...

Przy czym dalej niekoniecznie jak mówisz, bo np. napędy optyczne czy dyski zmieniły się od połowy lat '90 parę razy, a sterowanie i ogólnie szyna danych jakby nie bardzo (no dobra, może raz: SCSI -> SAS oraz IDE - SATA). Więc da się to przykryć, jeśli się chce.

@charliebravo No ale to trochę co innego, jednak, bo znowu małe, masowe rzeczy z jednej strony. Z drugiej to co piszesz to nie automatyka, tylko zoptymalizowany czysty driver właśnie, czyli bardziej programowanie, choć niskopoziomowe. I kolesie piszący aplikację która z niego skorzysta już nie będą w tym rzeźbić, tylko wezmą gotowca "codec sztuk jeden". I nawet jeśli będzie się to działo w obrębie jednej firmy, bo tak się opłaca itp., to tylko szczególny przypadek. Technicznie równie dobrze moglibyście być osobną firmą, napisać ten codec i sprzedawać go wszystkim chętnym.

Z tym domem to różnie może być. Pisanie programów/optymalizacja to akurat coś, z czym AI sobie dobrze radzi. https://thenextweb.com/artificial-intelligence/2017/10/16/googles-ai-can-create-better-machine-learning-code-than-the-researchers-who-made-it/

Przykład z Arduino bardziej dotyczył warstwy prezentacji i nazwijmy to języka programowania. Tam całe arduinowe bebechy są przykryte i nie trzeba ich znać, choć oczywiście można je podejrzeć czy modyfikować. Więc nie jest tak, że "skoro to automatyka, to trzeba to programować w tak nieczytelny/niewygodny sposób" (patrz notka).

@rozie
"Pisanie programów/optymalizacja to akurat coś, z czym AI sobie dobrze radzi"

Ale to, co podlinkowałeś jest o rozpoznawaniu obrazów itp, gdzie bym się akurat spodziewał że AI będzie lepsza. Zanim AI lepiej niż człowiek zoptymalizuje driver w assemblerze to minie jeszcze z 50 lat, i to jak dobrze pójdzie.

@rozie
"Czekaj, czekaj, bo mieszasz automatykę "dużą" z "małą"."

Nie załapałeś kontekstu - ja piszę o tym, że co prawda w bankach zwalniają informatyków, ale jest cała masa branż które w IT dopiero na poważnie wchodzą i będą musiały informatyków zatrudniać. I nie myślę tu o firmach robiących osprzęt do automatyki.

@rozie

Akurat popełnienie symulatora czegoś, co działa nie wiadomo jak [...] A mając przetłumaczony kod do "normalnych" struktur danych schematy, zależności i walidację kodu łatwo już zrobić.

Spróbuj kiedyś. A bardziej serio - jednak postawiłbym cię w Sevres jako wzorzec efektu Dunninga-Krugera.

Sorki, że się wyłączyłem nieco z dyskusji, ale IMHO temat nie jest jej wart, no i trochę zajęty byłem różnościami, np. wycieczking sam się nie zrobi.

@cmos Przeczytaj jeszcze raz. Albo https://www.nytimes.com/2017/11/05/technology/machine-learning-artificial-intelligence-ai.html To nie jest AI lepsza w rozpoznawaniu obrazów. To jest AI lepsza w parametryzownaniu algorytmu do rozpoznawania obrazów AKA tworzeniu "programu" (narzędzia, nie jest to typowy program składający się z instrukcji, taka technologia) do rozpoznawania obrazów. W przeglądaniu dużych przestrzeni (rozwiązań) czy znajdowaniu nieoczekiwanych zachowań ludzie akurat są słabi (wielowymiarowo, nie tylko powolni).

Nowe branże raczej nie będą przerabiały całej ścieżki IT przez ostatnie kilkadziesiąt czy nawet kilkanaście lat, więc jest spora szansa, że zrobią to "po nowemu".

@Boni Pominąłeś W końcu kod źródłowy jest dostępny i przetwarzalny w postaci maszynowej. IIRC kompilatory itp. pisali studenci początkowych lat politechniki, translatorów z jednego języka na drugi trochę jest, podobnie jak deasemblerów czy kompilatorów.

Samo zrzucanie przerabiałem osobiście - pobieranie mapy (nieco modyfikowanej u źródła w międzyczasie) z internetu przy pomocy przeglądarki i symulowania klikania plus screenshotów, pocięcie na równe kwadraty do wykorzystania w innym systemie. Na średnim łączu i kompie z demobilu. Zdecydowanie się dało, przy minimalnym zaangażowaniu ludzkim, porównując ze zrobieniem tego ręcznie.

Jak dla mnie wyłącznie kwestia opłacalności, plus to co pisałem o faktycznej użyteczności.

Nawiasem, polecam pobawienie się jakimiś zabawkami około AI, choćby https://www.nutonian.com/products/eureqa/ jeśli jeszcze dają triala. Modele z black box (tylko wejścia i wyjścia) też zacnie budują, tylko tu problemem będzie mała próbka, więc wynik byłby mocno niepełny/zafałszowany.

@rozie

Pominąłeś W końcu kod źródłowy jest dostępny i przetwarzalny w postaci maszynowej.[...]
Samo zrzucanie przerabiałem osobiście - pobieranie mapy (nieco modyfikowanej u źródła w międzyczasie) z internetu

"Kod źródłowy jest dostępny i przetwarzalny w postaci maszynowej"? Zrzucanie interaktywnej mapy z netu przypomina ci reverse engineering jakiejś SCADA z Czernobyla? Niestety, EoT, bo kiedy próbuję jakoś skomentować twoje komentarze, to jedyne co mi się nasuwa to:

@janek.r

Zadam głupie pytanie, na które właściwie znam odpowiedź - czy wśród założeń projektowych systemów przemysłowych jest także odporność na zmiany sprzętu i języków programowania?
Tzn. podejrzewam, że teoretycznie tak.

Teoretycznie, bywa, nawet spotkałem się z zapisami w umowach / w opcjach "zamawiany system ma być paczowany i utrzymany przez lat 10" (idą za tym czasem jakieś monetki), plus oferuje się jakieś tam części zamienne/zapasowe razem z systemami, niektórzy nawet to kupują. Ale inni takie opcje słusznie czy nie, olewają.

W praktyce, jest to raczej iluzja, szczególniej w działkach, niech tylko połowicznie, związanych z Windows, i chyba nie muszę tłumaczyć dlaczego. A w działkach nie związanych ze świetnymi przyszłorocznymi pomysłami Microsoftu, jest tylko niewiele lepiej, no bo przeważnie są związane ze świetnymi przyszłorocznymi pomysłami Siemensa, Rockwella, Schneidera czy General Electric itd., a kto powiedział, że będą to pomysły lepsze czy mniej destrukcyjne dla utrzymania kodu/sprzętu niż pomysły Microsoftu.

Tak czy owak, jakiekolwiek rzeczywiście planowane działania w temacie "odporności na zmianę" nie operują OIMW obecnie poza 5-8 lat życia systemu. Czasy zaplanowanej i, powiedzmy, bezproblemowej kompatybilności przemysłówki wstecz i w przód rzędu 15-20 lat odeszły już dawno do lamusa historii.

Właśnie dlatego jest to notka w cyklu "osiongi", czyli technicznych fakapów, bo pokazuje jak dzielne tanie utrzymania ruchu, outsourcowane, CotS itd. starają się, zerowo inwestując, przeciągnąć systemy w działaniu poza lat 20; nie tylko w przemyśle, ale przecież podobnie w transporcie, wojsku, lataniu, itd. Zaprawdę powiadam wam, są w tym znacznie bardziej beztroskie i jeszcze (względnie) tańsze, niż ja utrzymujący 20 letnie szrotwageny.

@rozie
"Przeczytaj jeszcze raz."

Zrozumiałem już za pierwszym razem, i było dokładnie jak się spodziewałem.

Trochę prawdy jest w tym, że informatycy jako branża sami sobie generują całkowicie zbyteczną pracę.
Może opiszę moje przejścia z Marią ku ostrzeżeniu kolegów, dla których systemy bazodanowe to łatwizna.

Sygnał z jednej uczelni - w raporcie brakuje kompletu danych.
U nas działa, u nich przed chwilą działało, żadnych aktualizacji nie robiliśmy.
Po krótkiej analizie - u nas jest MySQL, u nich Maria DB. I właśnie zaktualizowali wersję tejże Mańki.
Ale dlaczego przestało działać? Po analizie namierzyliśmy zapytanie SQL, całkowicie poprawne, które oczywiście musi działać wszędzie, ale akurat aktualna wersja Marii DB obsługuje je źle.

Niestety dostałem polecenie służbowe: nasz klient, nasz pan, chce mieć Mańkę, jego sprawa, moja sprawa tak długo modyfikować zapytanie (metodą prób i błędów), aż znajdę zapytanie równoważne semantycznie, które będzie się dobrze liczyć u klienta.

Taką akcję miałem kilka razy...

O ileż mniej pracy miałaby branży IT, gdyby zespół od Marii DB po prostu usiadł na laurach i dał sobie spokój z wypuszczaniem kolejnych wersji.

BTW u ^wo (w tym samym wątku) zażarta dyskusja o osobliwości technologicznej, tuż za rogiem.

W kontekście tej dyskusji marne szansę widzę - jak niby owa osobliwość ma sobie poradzić bez porządnej dokumentacji?

Zamiast lekceważyć "bankowych informatyków od baz danych" można zauważyć że to takie jedno miejsce że 40-letnia aplikacja na współczesnym mainframie nikogo nie dziwi, tylko działa.

@gszczepa
Ja lekceważę bankowych informatyków od masek, nie od baz danych.

@Maria i podobne
No przecież tworzenie własnych ale z lekka niekompatybilnych wersji popularnych standardów podpierało modele biznesowe niejednego „giganta IT”
@AI, samoprogramowanie się i inne osobliwości
Tak to jest jak ktoś czyta marketingowe mambo-dżambo a myśli, że to tekst techniczny.

@gszczepa

Ale ktoś tu lekceważy bankowych informatyków? Wskaż lekceważących, a wyciągnę bolesne konsekwencje. Tu jest tylko taki drobiazg - ja się powiedzmy na tych mysqlach czy odbcach trochę znam, bo niestety muszę, ale jednak nie chodzę po blogach Janków-od-Łososia czy innych modernizujących banki i nie opowiadam im, co mi się wydaje i jak bym zrobił migrację PKO na nowe cośtam. Ba, nawet na własnym blogu o normalnym IT nie piszę, bo się nie znam. Więc tylko uprasza się o podobny poziom samokontroli u czytelników.

@janek

Zajrzałem w tę dyskusję, ale ani b.gorąca, ani b.sensowna.

IMHO najlepiej niedowarzone pomysły ignorantów na AI czy nawet osobliwość, na obecnym etapie IT, podsumował wujek Lem w "Katarze" w 1975, ustami doktora Bartha uwalając pomysł na badanie zagadki kryminalnej programem "analizy wieloczynnikowej":
I jakim sposobem, pytam pana, mógłby tego dojść komputer, jeśli we wprowadzonym materiale nie będzie ani jednego bita o tych solniczkach, o narkotyku i o gustach kulinarnych ofiar?

Powiem tak, po 40 latach mamy pewien postęp IT, ale co do "sedna" niewiele się [censored] zmieniło.

@ boni & lekceważenie

Ja akurat robiłem, co prawda nie w banku, ale w Wirtschaftsinformatik, stąd wiem, że dużą część tych informatyków od masek łatwo da się zastąpić poprawionymi generatorami. A w tym projekcie proporcje były takie, że my w pięciu robiliśmy business logic (z czego najbardziej skomplikowany kawałek robiłem ja sam), a tych od masek było trzydziestu (i mieli w swoich kawałkach 100 razy więcej błędów niż my w naszych, to nie żadna hiperbola tylko twarde dane, 1300 vs. 13). Co obrazuje skalę problemu, bo ci zwolnieni nie przebranżowią się na embedded czy automatykę.

"No przecież tworzenie własnych ale z lekka niekompatybilnych wersji popularnych standardów podpierało modele biznesowe niejednego „giganta IT” "

OK, ale na ogół nie polegało to wprowadzaniu do kolejnych wersji ordynarnych błędów.

"nie opowiadam im, co mi się wydaje i jak bym zrobił migrację PKO na nowe cośtam"

Sprawdziłem - nawet jeśli coś takiego mam na sumieniu, to nie w tym wątku.

Może pamiętacie książkę "O oprogramowaniu inaczej" Robert Laurence Barber, napisaną w czasach, gdy jeszcze nie było Księżyca^Wwindowsów?
Autor przepowiada tam dwie możliwe drogi rozwoju oprogramowania: optymistyczną - każdy kawałek softu jest tworzony przy użyciu najlepszej metodologii oprogramowania, a wdrażany dopiero po uzyskaniu pewności, że wszystko działa poprawnie, pesymistyczną - programuje się bez przesadnego przejmowania się metodologią i poprawnością, aby szybciej, aby jakoś tam działało.
Od czasu napisania tej książki wiadomo, w którą stronę poszło - IMHO gorszą od wersji pesymistycznej.

@"OK, ale na ogół nie polegało to wprowadzaniu do kolejnych wersji ordynarnych błędów."
Dla pewnych defininicji "na ogół" i "ordynarnych błędów". Ale tak ogólnie, nie zgadzam się, bo ordynarnych błędów przypominam sobie więcej niż bym chciał, i owszem, były wprowadzane w nowych wersjach, bo kiedy właściwie?

Przez analogię do notki/komentarzy przypomina mi się Microsoftowy driver ODBC do SQL Servera, który cichutko obcinał query do pewnej długości (16k znaków? Nie pamiętam już) i NIE ZGŁASZAJĄC BŁĘDU wykonywał tylko taką obciętą część. Pech chciał że nasz system robił wtedy długie polecania postaci "rozpocznij transakcję/dużo insertów/zakończ transakcje, więc skutkiem było a) urywanie części danych na końcu i b) pozostawianie otwartej transakcji. Pech numer dwa polegał na tym, że nie wszystkie urządzenia były podłączone, więc nie było widać że część danych się nie loguje, więc nikt nie zauważył o co kaman, a jedynym objawem było powolne acz nieubłagane spowalnianie działania bazy. Tak mniej więcej od "system działa szybko" w dwa tygodnie do "ledwo człapie".

Też mam o bazach danych takie se pojęcie, ale i tak wszystko zatrzymywało się na moim biurku, bo wyżej już nie było komu popchnąć. Nie wspominam tego dobrze.

@Boni Zrzucanie interaktywnej mapy z netu przypomina ci reverse engineering jakiejś SCADA z Czernobyla? Zrzucanie to zrzucanie, gdyby SCADA nie dawała dostępu do kodu inaczej, niż przez zaprezentowane ekrany. Nawet wtedy się da i nie jest to rocket science.

Samo tłumaczenie kodu to co innego, o tym było akapit wyżej. Oczywiście jest niewielka szansa, że SCADA ma zupełnie wyjątkowe właściwości/sposób działania i nie da się łatwo przełożyć na cokolwiek, ale z podanego przykładu to zupełnie nie wynika.

@Cytat z Lema - przecież AI to nie magia i zakładam podstawową wiedzę jak to działa. Wiadomo, że rozpoznawanie itp. działa jedynie dla przykładów zbliżonych do zbioru treningowego. AI wytrenowane do rozpoznawania ssaków polskich na zdjęciach nie rozpozna pingwina.

W przypadku algorytmów genetycznych jest liczenie przystosowania, dla pisania/optymalizacji byłoby to sprawdzenie składni/poprawności kompilacji plus wyniki testów. plus np. czas wykonania (jeśli on jest optymalizowany). Jeśli coś daje się szybko i automatycznie oceniać i są mniej i bardziej poprawne rozwiązania, to AG ma szansę być bardziej efektywny od człowieka w optymalizacji.

@rozie

przecież AI to nie magia i zakładam podstawową wiedzę jak to działa.

"Ale masz jakieś wsparcie?"

Wiadomo, że rozpoznawanie itp. działa jedynie dla przykładów zbliżonych do zbioru treningowego. AI wytrenowane

To co z niej za AI, może jednak nazywaj programy rozpoznawania obrazów "programami rozpoznawania obrazów".

Jeśli coś daje się szybko i automatycznie oceniać i są mniej i bardziej poprawne rozwiązania, to AG ma szansę być bardziej efektywny od człowieka w optymalizacji.

Będę się powtarzał, niestety, ale co mi pozostało - zamiast pobredzać na przypadkowych blogach o tym, co ci się wydaje, SPRÓBUJ KIEDYŚ. Darmowa podpowiedź od praktyka (bo następne to już raczej za kasę): zanim zaczniesz bawić się AG, bo "ma szanse", bo funkcja fitnessu wydawała się taka tania, bo tak pięknie miało być - rzetelnie oceń przestrzeń rozwiązań, do jakiej usiłujesz zatrudnić AG, i zasoby jakie masz dla AG wzg. tej przestrzeni. Oszczędzi ci to niejednego rozczarowania.

@Boni "Ale masz jakieś wsparcie?" Jeśli dyskusja ma być na poziomie "sztuczna inteligencja to samodzielne myślenie zaimplementowane na krzemie, stąd sztuczna", to pasuję na wejściu. Termin "machine learning" lepiej oddaje znaczenie, fakt.

To co z niej za AI, może jednak nazywaj programy rozpoznawania obrazów "programami rozpoznawania obrazów".
J.w.

Akurat AG się trochę bawiłem, dokładniej wpływem parametrów AG na wyniki. Pewnie będziesz kręcił nosem (skądinąd słusznie), że TSP dla znanych niewielkich (góra małe kilkadziesiąt) miast to nie jest coś z czego ogólne wnioski można wyciągać, ale z tego co mi wyszło, to parametry miały większy wpływ, niż przestrzeń rozwiązań. Przy czym pewnie jeszcze bardziej liczy się kształt przestrzeni, jej ciągłość i obecność ekstremów lokalnych.

AI ma tę przewagę nad człowiekiem, że czas pracy komputera jest niski w porównaniu z czasem pracy człowieka i łatwo się skaluje poziomo.

@cmos
Czym się zajmuje "informatyk od masek"?

@cmos
"Czym się zajmuje "informatyk od masek"?"

Typowa aplikacja bankowa/ubezpieczeniowa/compatible jest bazodanowa - operuje na rekordach z bazy danych, przedstawianych na ekranie w tak zwanych "maskach". Zazwyczaj te maski są mocno związane ze strukturą rekordów w bazie danych i daje się je generować.
Wiem że teraz to już nie są terminale znakowe i GUI takich aplikacji robi trochę więcej niż tylko takie maski, ale programowanie tego to nadal mało intelektualne zajęcie i idzie do automatyzacji w pierwszej kolejności.

Yrrrgh....

Tyle tylko że taki informatyk od masek [co też jest uproszczeniem, to byłoby proste jakby dane siedziały w jednej tabeli, rzeczywistość jest jakby bardziej złożona], to się zwykle nazywa "business", a informatyka bankowa to ta banda kolesi która sprawia zapytania że zapytania od businessu gdzieś się procesują i zwracają poprawne dane.

Jako "informatyk z banku" czuję się zobowiązany wtrącić. Jasne, że banki automatyzują czy outsourcują to co mogą i jeśli czyjaś praca daje się łatwo zastąpić automatem to tak się stanie. Ale "informatyków" w bankach jest jak mrówków i robią masę rzeczy. Na przykład admini serwera nie zostaną zautomatyzowani całkowicie bo duża część ich pracy jest ekspercka, a ta która nie jest to zazwyczaj jest prędzej czy później przerzucana na jakieś tańsze zespoły "pierwszej linii". Po drugie nie zostaną zautomatyzowani, bo banki mają podobne problemy co te opisywane przez gospodarza, czyli np. w 2017 nadal jakiś system chodzi na Win NT i nikt nie wie jak go zrobić na nowo tak, żeby działał dobrze. Migracja jest kosztowna i to dużo bardziej niż utrzymywanie tego przez lata. Zwłaszcza szybka migracja.
No właśnie, koszty. Kolejny powód to taki, że banki to korporacje i na kwestię "dobrze, szybko, tanio - wybierzcie dwa z trzech" często odpowiadają "to poprosimy tanio i ekstra tanio".
Zdarzały mi się sytuacje w których biznes wrzucał nową wersję jakichś serwisów, testował, to nie wstawało, ściągali developera. Ja mu mówię że w logach serwera jest "error in config.xml, line 57" a on na to "nie mam pojęcia o co chodzi". I co zrobią? Zwolnią go? Ale spora część developerów to takie same ziutki, które ledwo co ogarniają kodowanie. Tyle że są tani i można ich zatrudnić masowo.

No i te wszystkie płatności bezprzewodowe, te transakcje przez stuknięcie telefonami, te "logowanie przez rozpoznawanie twarzy" (które w przypadku banków jest traktowane dużo poważniej niż u Apple czy Samsunga i nie ma prawa dać się zmylić zdjęciem, a przynajmniej tak jest w moim.) - czego by o nich nie sądzić, to są prace koncepcyjne tworzone również przez gości z IT. Tym razem takich nieźle opłacanych dla odmiany.

@"informatyk z banku"

Nie napisałem nic w stylu "wszyscy informatycy z banku robią proste rzeczy i zostaną zastąpieni generatorem". Przecież sam robiłem w podobnych branżach i w ostatnim takim projekcie to był najbardziej skomplikowany kawałek jaki implementowałem, a zajmuję się tym od 30 lat.

Napisałem, że spora część ludzi od GUI od zastosowań bazodanowych wcześniej czy później pójdzie na bruk. Bo to się da w dużym stopniu zautomatyzować. Wiem, installed base, i tak dalej, ale to tylko kwestia czasu.

Słychać o tym co najmniej od czasu Visual Basic. Gdyby to miała być prawda, to by się to już stało.

@gszczepa

Ale typowe GUI bazodanowe nie ma wiele wspólnego z taką metodologią, jak to robi Visual Basic i podobne. To zupełnie inny temat.

Tu nie chodzi o konkretnie VB, tylko ideę automatyzacji tworzenia aplikacji.

@gszczepa

Mam wrażenie, że naciągasz i memoria ci fragilizuje - promocja VB sprzężonego z Office (aż po VBA) to była idea, że pani Kowalska i pan Smith wyjdą w końcu poza =SUMA() w Excelu, nauczą się w końcu podstaw programowania i kwerend w Accessie i właśnie - zastąpią "programistów od masek" z opowiastek cmosa itp.; ogólniej, że będą sobie budować sami front-endy aplikacji, baz danych, itp. A do tego potrzebują narzędzi jakichś, w stylu minimalny RAD sprzężony z Office, tak to przynajmniej widział MS. Ale to nie miała być "automatyzacja".

Oczywiście, ogólnie okazało się to gówno prawdą, bo statystyczni pani Kowalska i pan Smith to może i osiągnęli w końcu biegłość w klikaniu po fejsach i kotkach w necie, ale przecież nie wyszli wiele poza =SUMA() przez ostatnie ile, 20 lat?

Może inaczej - wasza dyskusja jest zwichrowana, bo "programiści od byle g..." mogą stracić pracę z wielu przyczyn, np. zarówno od automatyzacji zagadnienia, ale też od przerzucenia go na self-maintenance (tak jak stracili ją starsi tonerowi (bo każdy sam se wymienia toner) czy młodsi paczkordowi (bo każdy ma wifi)); a wam się to jakoś zlało w jedno.

@kto straci robotę w IT
Ja mam wrażenie, że duża część adminów wszelkiej maści, załatwiona przez chmury, wirtualizacje i inne kolokacje. I co z tego, że często w praktyce wyjdzie drożej i/lub gorzej - za to zgodnie z ideolo kapitalizmu.

Dość dobrze pamiętam, bo w okolicach VB 4.0 trochę chałturzyłem w tych okolicach.

VB nie był dla Pani Zosi przede wszystkim dlatego, że VB kosztował wtedy całkiem sporo kasy (i przede wszystkim nie był częścią Office). VBA to trochę inna inszość.

VB był wtedy promowany jako taki automatyzujący tool dla profesjonalisty że narysujesz myszką GUI, napiszesz logikę i resztę się wygeneruje automatycznie.

W takiej pracy jest ważna interakcja i znajomość domeny, kodowanie mniej ważne, więc automatyzacja trudna a zysk niewielki.

Potem przyszedł Internet i moje chałturzenie przeszło na znany zestaw PHP/MySQL/JS. I znowu były rozmaite toole które miały automatyzować i znowu ślad o nich zaginął, a ludzie od JS są rozchwytywani.

Moja teza jest generalnie taka:
1) proste programowanie (te właśnie formatki) zawiera na tyle dużo interakcji i znajomości domeny, że automatyzacja będzie trudna i niecelowa;
2) tool który wystarczająco będzie automatyzował, będzie na tyle skomplikowany że jego znajomość będzie specjalnością samą w sobie (w rodzaju Cognosa).
3) wrażliwość na automatyzację/inne zagrożenia (tu się zgadzam że mogą być różne) to nie jest kwestia skilla samego w sobie.

Tutaj bym zerkał na służbę zdrowia, gdzie prędzej np. lekarzy radiologów zastąpią niż ratowników medycznych czy pielęgniarki.

@Chmura,
Nie wiem, z jednej strony tak, ale z drugiej już widzę specjalistów od np. AWSa, ORAZ specjalistów od wyboru pomiędzy chmurami.

@gszczepa

Ale kiedy był VB 4.0, gdzieś w połowie '90? jakieś wnioski z 1995 przenosisz na obecną sytuację w IT? Myślałem że mówisz co najwyżej ("najwcześniej") o końcu VB "za pieniądz" i początkach VBA, kiedy VB(A) przechodził ewolucję z "profi narząd GSzczepy, który robi nam appki", do "każdy se może zrobić w Office appkę", w okolicach VB 6 i po, o ile mnie pamięć nie zwodzi.

Przenoszę, bo idea nadal żywa.


Po VB6 właśnie poszło odwrotnie, przyszedł VB .Net który jeszcze bardziej poszedł w kierunku profi i większej integracji z pozostałymi devtoolami MS.

@ Boni
Oczywiście, ogólnie okazało się to gówno prawdą, bo statystyczni pani Kowalska i pan Smith to może i osiągnęli w końcu biegłość w klikaniu po fejsach i kotkach w necie, ale przecież nie wyszli wiele poza =SUMA() przez ostatnie ile, 20 lat?
Ja mam czasami kontakt z końcowym użytkownikiem i młoda (powiedzmy do 35 lat) pani Basia z księgowości dwudziestoosobowej firmy jak dostanie skonfigurowane połączenia Excela z bazą danych to sobie spokojnie i bez przeszkolenia doklikuje się - z nudów, jak akurat nie ma ochoty na pasjansa - i robi sobie małe raporty.

@gszczepa
Potem przyszedł Internet i moje chałturzenie przeszło na znany zestaw PHP/MySQL/JS. I znowu były rozmaite toole które miały automatyzować i znowu ślad o nich zaginął, a ludzie od JS są rozchwytywani.

Generalnie jak ktoś chce małe GUI to automatyzacja tego nie jest nowością, tylko narzędzia o jakimś sensownym potencjale kosztują i wcale nie działają za dobrze (Oracle Web Forms? a wcześniej to samo bez Web? kto nie ucieknie z krzykiem?). Ale dla prostych rzeczy daje się ludziom django z domyślnym "adminem" i to jakoś daje radę. W związku z tym, że to jest łatwe, to oczekiwania się zmieniły, i każdy chce mieć na stronie kolorowe wykresy, mądre raporty, alarmy, współpracę z całym światem itp., więc suma pracy do wykonania nie maleje.

@Maciek

@pani Basia z księgowości dwudziestoosobowej firmy jak dostanie skonfigurowane

Z mojego skromnego doświadczenia, to taka pani Basia jest jedna na 20 osób, w porywach. Nawet niezależnie od wieku i od tego, czy rozważamy czystą administrację, księgowość czy raczej działy nieco "inżynierskie", które teoretycznie powinne być zylion razy bardziej zakute z exceli, baz danych, skryptów i podstaw oprogramowania itd.

@W związku z tym, że to jest łatwe, to oczekiwania się zmienił

Trochę prawda. Ale jw. nie widzę, ani w firmach w których pracuję, ani u klientów itp. żeby choć połowa ludzi przy kompach była w stanie se "zautomatyzować" czy "self-programować" te excele, oracle czy inne księgowości, czy z mojego poletka, SCADY czy historiany. Szybciej niż kiedyś uczą się nowych systemów i aplikacji, lepiej ogarniają jakieś podstawy IT i sieci, itd. ale nadal ktoś im musi dostarczać skończone rozwiązania.

BTW próby automatyzacji, ale z minimum jakiejś AI czy "ludzkiego" interfejsu, to dopiero powodowały epickie fejle. Co mi np. przypomina, jak kiedyś patrzeć nie mogłem, jak kolega się pier... z eksportem z SAP do excela, co tydzień, i RĘCZNIE przekłada i sortuje te dane, jakieś setki jeśli nie małe tysiące rekordów, no bo SAPiący konsultanci okłamali ich w żywe oczy, że "inaczej się nie da". No to napisałem mu w dzień czy pół jakiś skrypt, żeby mu te posiekane po całym arkuszu dane przenosiło przynajmniej w coś przypominającego arkusz kalkulacyjny, tj. w kolumny. W teorii dostał plik, "w tę zakładkę masz skopiować całe to gówno z eksportu, takie jak SAP wyrzuca, potem tu klikasz, i po chwili w tej zakładce dostajesz to, co, ręcznie robiłeś co poniedziałek? kuma?" - "kuma".

No zameldował mi się zara z pretensjami "CO TEN TWÓJ PROGRAM ODE MNIE CHCE?! NIBY CO MU SIĘ "NIE PRZYPOMINA?"". Bo może i była to przysługa naiwnego łosia z dobroci serca, no ale nie byłem aż tak naiwnym łosiem, żeby nie dać walidacji tego arkusza sieczki wejściowej. Więc kolesław dostał w twarz komunikatem w deseń "Skopiowany eksport nie przypomina właściwego eksportu z SAP". Bo, rzecz jasna, kolega posortował jednak coś tam ręcznie zanim wrzucił w makro, "żeby było łatwiej".

No ale wtedy cortana czy siri czy jakieś echo to było SF, może już się użyszkodnicy przyzwyczaili, że interakcja z programem to niekoniecznie kryptyczny "Access denied" czy inne "Guru Meditation".