"I nagle naszła mnie refleksja - mnie, i zresztą innym znajomym co lepszym automatykom, czy z poprzedniej pracy, czy z przedpoprzedniej, czy znajomym u dostawców czy klientów, nie płaci się bynajmniej za programowanie, czy za rozwiązywanie problemów nawet. Płaci się głównie za ogaranianie tego bałaganu, i tylko minimalnie za wiedzę."

Powiedziałbym, że wszystkim stukającym kod się za to płaci, a im firma większa, tym bardziej stosunek wiedza - exp robi się niekorzystny na rzecz wiedzy. W firmie z sektora ecommerce, w której teraz robię, jeden z wyżej usadzonych ludzi wprost na rozmowie o pracę przyznał, że mimo ponad roku ogarniania tematu wciąż wszystkiego nie wie. I na moje nie będzie wiedział, bo na to platforma zrobiła się zwyczajnie zbyt duża i trzeba innych pytać jak to czy tamto działa, bo samodzielnie ogarnie się może w paru procentach. I nic ci nie da, że znasz najnowsze trendy, narzędzia i możesz składnię kilku języków recytować po trzech nieprzespanych nocach i kopie pod żebra.

Spędziłem ostatnio ze dwa tygodnie na ogarnianiu raportów, które drukujemy z systemu. Chodziło o ustalenie, które raporty w starej technologii są zbędne, które należy przenieść na nową technologię, a które zostają i wygasną.
Następnie to samo z raportami w nowej technologii - zinwentaryzować, które w ogóle są używane i w którym z 5 serwisów, a które są wprawdzie w repozytorium, ale pewnie wygasły...
Do tego raporty wpisuje się do tabel systemowych, przy czym niektóre raporty istniały w tabelach, ale nie było ich już w dystrybucji, a niektóre odwrotnie.
Co gorsza za miesiąc pracę trzeba będzie powtórzyć. Albo może nie, bo raportów dotyka może z 5 osób, ale głównie ja.

Odwieczne "95% pracy, 5% talentu/wiedzy/inne" - wcale nie tylko u automatyków, stukających kod czy ogólnie "komputerowców", tylko (niemal?) zawsze i wszędzie.

Odwieczne "95% pracy, 5% talentu/wiedzy/inne" - wcale nie tylko u automatyków, stukających kod czy ogólnie "komputerowców", tylko (niemal?) zawsze i wszędzie.

Tak naprawdę moja refleksja była nieco inna, no ale chciałem się przekonać, czy komukolwiek poza mną sytuacja kojarzy się nieco inaczej niż "tak jest zawsze i wszędzie". Jak widać, nie bardzo.

Bo moim zdaniem jednak, gówno prawda, że za to się płaciło "zawsze i wszędzie". Za to się płaci w czasach zbędnego przekombinowania i wyjętych z chorej czapy wodotrysków. Szczególniej "komputerowych".

Aż mnie sprowokowałeś i sprawdziłem u siebie: prawie 60GB, ale "tylko" 25tys. plików. No cóż - nie przetwarzam aż tylu projektów, ale moje pliki są "cięższe" niż programy.

Mnie uderza w tym bajzlu jedna prawidłowość: to nie jest tak, że moja aktywność mierzona gigabajtami czy ilością plików w projektach technologicznych świadczy o moim głębokim wnikaniu w tematy/problemy. DLA MNIE większości tych plików/GB mogło by nie być - rozumiem dany problem i umiem go rozwiązać BEZ NICH. Ale tak to się nie da - potrzebna jest dokumentacja z postępów realizacji projektu technologicznego (poparty zdjęciami, wykresami, tabelkami), potrzebny jest okresowy raport dla Kierownika Tech/R&D (wyciąg z dokumentacji projektu technologicznego), potrzebny jest wyciąg z tegoż wyciągu dla Dyrektora (uproszczony, żeby zrozumiał), potrzebne są wreszcie oficjalnie zatwierdzone zalecenia technologiczne (nowe lub uaktualnienie starych, z odpowiednią numeracją wersji, itp.). Czyli lekko licząc w jednym projekcie mamy kilkadziesiąt plików, których ja nie potrzebuję, a inni ludzie w zasadzie ich nie czytają (bo nie mają do tego głowy, czasu...).

To chyba jest poligraficzna wersja tego co Boni opisujesz jako "czasy przekombinowania i wyjętych z chorej czapy wodotrysków".

@zz_top

U ciebie to chyba jednak bardziej jest to, co koledzy podnoszą, że 90% pracy to te różne duperele okołopracowe, raporty, księgowości, w ogólności biurokracja.

Mnie trochę bardziej idzie o "podkład IT" pod moją (i każdą inną) działką. Powiedzmy, w skrócie, jak to się stało, że Win10, czyli "system operacyjny" z którego piszę, waży 17GB i ma ponad 100tys plików. CO ONE DO K... NĘDZY ROBIĄ? Czy wszystko to zostało zrobione przez kopy pastę? w Javie? repozytoriami sięgającymi 1995?

I analogicznie wyglądają bardzo przemysłowe rzeczy; SCADA, historiany, programy bazodanowe, itd itp.

Nawet jeśli połowa tego szajsu to wodotryski, to nadal - w ostatniej dekadzie czy dwu coś poszło bardzo nie tak.

@Windoza
Pffff!!! Masz ewidentnie "świeżynkę" zainstalowaną. Po roku używania Win10 ma 32GB i 150tys. plików.

@Biurokracja czy wodotryski
Ja bym powiedział, że jedno i drugie. Bo w sferze IT to pewnie że mówimy o wodotryskach "puchnących" dowolny program/system w nieskończoność. Ale przecież czegoś zupełnie podobnie "oczojebnego" i całkowicie zbędnego oczekują władcy tego świata od dowolnego projektu, raportu, dokumentacji...

@laptok - z tego co słyszę masz sporą dowolność w wyborze sprzętu/OS, wiec możesz po prostu kupić sobie prywatnie jakiegoś zgrabnego 12-13" na wyjazdy. Nawet używkę pewnie. Chyba, że jakieś specoprogramowanie i licencje blokują, albo nie do końca masz synchronizację zrobioną fajnie.

Co do roboty - w przypadku sieci jest podobnie - głównym atutem administratora sieci jest znajomość (swojej) sieci. Z systemami w sumie podobnie. W jednym się z Tobą nie zgodzę - ta wiedza IMO przekłada się mocno na rozwiązywanie problemów, niedopuszczanie do nich, szybką diagnostykę i znajdowanie workaroundów/rozwiązań.

@zz_top

@biurokracja a oprogramowanie

No ale nie mylmy rzędów wielkości - jeśli jakaś SCADA czy developerka itp. która ważyła / powinna ważyć 50MB waży 5GB to jednak jest 100x więcej i 1000x bardziej przekombinowane; jakby tak działała zwykła biurokracja raportowa, prawna czy papierowa, to już byśmy wszyscy w wariatkowie siedzieli. Możesz mieć 10x tyle biurokracji i "pracy" co 20 lat temu, ale nie uwierzę, że 100x razy.

@rozie
@znać swoje zabawki

No ale nie mylmy rzędów wielkości - to że jakiś tam uproszczony model który masz/mam w główce zawsze nieco pomaga na pierdolnik w tym, co modelowane, to jasne, tylko w takim razie mój point: teraz powinniśmy modelować 10x czy 50x tyle co dawniej. No bo mam wrażenie, że tak jak ja w automatyce, admin podobnej sieci, przy podobnej ilości nodów, w 1998 miał znacznie mniej na łbie, niż w 2018. Ergo - gość w 1998 mógł swoje klocki IT czy około ogarnąć znacznie pewniej i lepiej. Ale już nie ma takiej opcji, żeby nadążyć za systemami i ich komplikacją, przecież umysły nam się nie rozwiną z nagła.

Co do skomplikowania to troszkę nie mam siły po raz n-ty powtarzać tego samego ale z drugiej strony tutaj chyba jeszcze o tym nie pisałem: moim zdaniem systemy IT (systemy operacyjne, oprogramowanie) są obecnie przekomplikowane do granic możliwości przy jednoczesnym spuszczeniu w klopie całości dobrych praktyk z zakresu niezawodności i bezpieczeństwa. Oczywiście możemy wydłubywać pojedyncze perełki i osoby, robiące rzeczy coraz lepsze i lepiej - ale to są wyjątki, pojedyncze lotosy, smętnie kwitnące nad powierzchnią morza łajna. A reszta?

Powtórzę: soft jest przeraźliwie skomplikowany i rozbudowany, a praktyki i trendy są takie, że kontrolowanie tego jest zupełnie niemożliwe. Dystrybucja (w znaczeniu "dystrybucji linuksa") stała się brzydkim słowem na "d" i konia z rzędem temu adminowi, który jest w stanie zapanować nad co bardziej rozbudowanym serwerem. Może i ma swoje pakieciki (jeśli jest tępym wstecznikiem i używa niemodnej dystrybucji), ale pierwszy-lepszy gość od PHP ma swoje systemy pobierania bibliotek do projektu, pierwszy lepszy gość od pythona, node.js, golanga i whatevera plamistego mają swoje ogony bibliotek i modułów instalowane z boku i poza kontrolą. A nie doszliśmy jeszcze do kontenerów - które z jednej strony są promowane przez biznes jak szalone, choć z drugiej branża (ale nie biznes tylko deweloperzy) powoli przyznaje się sama przed sobą, że nie ma dobrego pomysłu na pilnowanie bezpieczeństwa w kontenerach. A jeszcze snapy, a jeszcze flatpaki - to tylko zwieńczenie wierzchołka góry lodowej, bo mówimy o organizacji dystrybucji softu, nie mówiąc o jego jakości...

Dystrybucje linuksa stają się coraz mniej używalne - rodzinnie używaliśmy ich do codziennej pracy i rozrywki od ponad 10 lat i ostatnio zauważamy, że ładność ładnością (nawet dyskusyjna) ale soft jest niestabilny, wolny i niefunkcjonalny. Programy, które kiedyś nam nie ulegały awarii zaczynają się sypać regularnie (libreoffice, firefox). Systemy mają problem, żeby się uruchomić (z takich czy innych powodów) czy w ogóle działać (np. w ciągu ostatniego kwartału miałem ze trzy wycieki pamięci powiązany z totalnym zamrożeniem systemu) i nie jest to skutkiem grzebania albo pracy na "bleeding edge". Wrażenie jest na tyle przykre, że normalnie rozważamy przeniesienie się z robotą na windowsy (od 7 do 10, zależy od przypadku), bo te można opanować i działają lepiej.

O komercyjnych systemach, wdrażanych wszędzie i na dużą skalę nawet nie ma co pisać - ale potwierdzam wszystko, co napisał Boni i to, co pewnie widział ale wolał publicznie nie komentować. Gdyby to zebrać w bloga to powinien nazywać się "Kroniki kurestwa i waryactwa umysłowego" (to nie mój pomysł, ale memoria itd.). Bo co mam myśleć, jeśli typowe urządzenie (np. kamera nadzoru) z górnej półki ma podatności klasy takiej, że dwadzieścia lat temu JUŻ było to lamerstwo i nikt takich błędów nie robił?

A IoT? A automatyzowanie wszystkiego, co na drzewo nie ucieka? A podłączanie wszystkiego do centralnych serwerów, dla niepoznaki zwanych chmurami? A promowanie systemów SCADA dla energetyki "w chmurze"? I jakoś nikt na konferencji nie potrafi odpowiedzieć na pytanie o niezawodność albo bezpieczeństwo tego pierdyliona systemów, ale twardo nadaje, że "to jednak będzie przyszłość"! A bezpieczeństwo systemów mobilnych? A integracje wszystkiego ze wszystkim? A...

To jebnie kochani. I to z płaczem i wizgiem. Miejmy tylko nadzieję, że nas lud nie powywiesza za całokształt - nie jestem automatykiem, ale to nie ma znaczenia. Wszyscy bekniemy za grzechy IT.

@Boni
Powodzenia w nowej pracy!

@upadek IT
Niestety, zbyt mocno "grają" dwie reguły:
1) Ślepy nacisk na "nowe" technologie, trochę jak "nowe" mody. C++ po C, Java po C++, Javascript po Javie i tak dalej.
2) Tworzenie nowych technologii przeważnie dla (często źle pojmowanej, ale to wątek poboczny) wygody programisty/biznesu a nie klienta.

Dla przykładu: Kiedyś jak się pisało program z jakimś GUI, to brało się natywne biblioteki (przykładowo MFC na windowsach, jakiś X toolkit na UNIXach, Cocoa na jabłkach). Potem zaczęło się cross-platformowo, jakieś Qt czy inne wynalazki. A wiecie jak się teraz robi GUI? Ano bierze się cross-platformowe środowisko Javascript w rodzaju Electrona. A Electron zawiera w środku Chrome. No więc każdy malusi-prościutki programik z byle jakim UI zawiera w sobie bydlę jakim jest Chrome (30MLOC czy jakoś tak). Tak, również na komórki. I oczywiście każdy program zawiera własną kopię tego Chrome'a, bo przecież to wszystko nie jest kompatybilne między sobą. Potem użytkownik ściąga jakiś prościutki programik, ot choćby Slack na iPhone, a download liczy się w setkach megabajtów. Jakby to było napisane, jak trzeba, to może by miało ze dwa. O wiele rzędów wielkości za dużo miejsca zajmuje, o wiele za wolno chodzi, i myślicie że autorów to martwi?

Mam takich ludzi w firmie, są całkiem niegłupi i tam gdzie się znają - kompetetni, ale o pewnych rzeczach nie podyskutujesz. "Teraz tak się robi". "Nie da się lepiej". "Musi być cross platform". I tak dalej...

@Rzędy wielkości
Kłócił się nie będę, ale 25 lat temu (jak zaczynałem robotę) to za opis technologiczny wystarczała kartka A5 (fizyczna kartka, luźno zapisana - czyli odpowiednik max. kilkunastu kB). Obecnie opis technologiczny JEDNEGO WYROBU (sprawdziłem kilka przykładowych) to od 70 do 100 mega danych. Czy procesy technologiczne przez ostatnie 25 lat rzeczywiście zrobiły się tak bardzo skomplikowane? A gdzie tam! Procesy są TAKIE SAME.

@Modelowanie rzeczywistości
Ależ oczywiście, że obecnie oczekuje się modelowania rzeczywistości gigantycznie nadmiarowego i zupełnie zbędnego. Dlatego do tego modelowania coraz częściej używa się kolejnych systemów informatycznych, też nadmiarowych i w sumie zbędnych.

@charliebravo

"A Electron zawiera w środku Chrome. No więc każdy malusi-prościutki programik z byle jakim UI zawiera w sobie bydlę jakim jest Chrome (30MLOC czy jakoś tak). Tak, również na komórki."

1) Nie Chrome, a Chromium. Subtelna różnica.
2) Na komórki masz React Native, Ionica (Angular), Cordovę (co tam chcesz) i jeszcze kilka innych opcji. Electron jest dla desktopów.
3) Winę zwalaj na ludzi, którzy w JSie chcą pisać aplikacje nieprzeglądarkowe. Wcześniej też wiń Noda, bo to głównie on na to pozwolił.

"O wiele rzędów wielkości za dużo miejsca zajmuje, o wiele za wolno chodzi, i myślicie że autorów to martwi?"

Może się zdziwisz, ale tak, martwi i tak, szukają sposobów na rozwiązanie problemu bez konieczności przepisywania całej aplikacji w Javie czy innym Pythonie. Z tym, że Slack sam w sobie nie jest szybką aplikacją ze swoim pierdyliardem opcji, więc wrzucenie go w Chroma nie tworzy problemu, a "jedynie" go pogarsza. Czego na tym etapie już nie powstrzymasz, chyba że na rynku pojawi się jakiś sensowny następca JSa z opcją budowy pod mobilki i desktopy.

@Bober
"Nie Chrome a Chromium"
O, przepraszam, 24MLOC, faktycznie, waga piórkowa.
"Electron dla desktopów"
Racja, ale znowu - Slack na iOS ma setki MB. Co tam tyle waży?
"Winę zwalaj..."
Nie rozmawiamy o tym kto jest odpowiedzialny (głupie lenistwo i owczy pęd, IMO).
"Może się zdziwisz, ale tak, martwi i tak, szukają sposobów na rozwiązanie problemu bez konieczności przepisywania całej aplikacji w Javie czy innym Pythonie"
LOL, przepisanie w Javie czy Pythonie jako recepta na problem.
"Z tym, że Slack sam w sobie nie jest szybką aplikacją ze swoim pierdyliardem opcji,"
Uprzejmie proszę o wyjaśnienie, dlaczego niby apka, która jest de facto takim ładniejszym klientem IRCa "nie jest szybką aplikacją".
"chyba że na rynku pojawi się jakiś sensowny następca JSa z opcją budowy pod mobilki i desktopy"
My point exactly - musi być JS albo coś nowego!

@charliebravo

"O, przepraszam, 24MLOC, faktycznie, waga piórkowa."

Still less than 30! Ale tak po prawdzie nie wiem ile linii kodu mają obie wersje. Wiem tylko, że największym problemem w obu jest szybkość obróbki DOMa, ale to jest stale poprawiane. Zwłaszcza teraz, jak Firefox wyszedł ze swoimi propozycjami.

"Racja, ale znowu - Slack na iOS ma setki MB. Co tam tyle waży?"

Sam bym chciał to wiedzieć. Loadery? Kod ogarniający symultanicznie ileś pokoi czatowych prywatnych i publicznych? Synchro danych? Przechowywanie customowych ikonek? Bo że to jest kobyła to sam widzę, bo korzystam na co dzień w pracy. Pewnie za dużo wodotrysków nawalonych i tyla.

"Nie rozmawiamy o tym kto jest odpowiedzialny (głupie lenistwo i owczy pęd, IMO)."

Po części tak skoro wywołałeś łańcuszek języków i "bo nowe mody". Tylko że te mody otworzyły przez ludźmi nowe możliwości, więc nie dziwota, że korzystają. To że wielu z nich jest leniwych to inna inszość. Można być leniwym w każdym języku i tworzyć potworki.

"LOL, przepisanie w Javie czy Pythonie jako recepta na problem."

To tylko przykłady. W czym byś taką apkę napisał?

"Uprzejmie proszę o wyjaśnienie, dlaczego niby apka, która jest de facto takim ładniejszym klientem IRCa "nie jest szybką aplikacją"."

Pacz co napisałem wyżej. Pewnie nadmiar nikomu niepotrzebnych wodotrysków.

"My point exactly - musi być JS albo coś nowego!"

Jakie alternatywy?
No i nie musi być, ale zważ, że teraz nie operujemy na statycznych stronach, tylko mamy do ogarniania web i aplikacje, gdzie byle strona to w praktyce mała aplikacja, gdzie Android sobie, a iOS sobie, gdzie user wymaga synchronizacji, dostosowania pod urządzenia, wspólnego GUI, gdzie masz pierdyliard standardów, do których mało kto się stosuje et cetera. I wtedy wchodzą Cordova z Electronem, całe na biało i mówią "Możesz to wszystko ogarnąć z pomocą jednego zestawu kodu!". I można łamać nad tym ręce ile się chce, ale to chwilowo najlepsze, na co nas w takiej sytuacji - czytaj zrobienia apki wyglądającej jak strona, która de facto też jest apką - stać. Wymagania rosną, nie nadążamy za nimi, więc łapiemy się rozwiązań, które są gówniane, ale działają. Zbędne wodotryski też w tym wszystkim są, ale nie zwalałbym na nie całej winy.

Nie będę za bardzo komentował, no bo a) powtarzałbym się b) powtarzałbym to co piszecie c) właśnie grzebię "od zaplecza" w wiodącej SCADA+historian plus jak spiąć to z nieco zabytkową aplikacją specjalnego drukowania i to tak, żeby nie wysadzić już na testach w pizdu całej tej SCADA itd. (bo to kawałek mini-big pharma i będzie źle wyglądało w moim/naszym porfolio), więc nie mam cierpliwości a nawet litości.

Może tylko tyle - w rozmowach i przemyśleniach wkoło mnie tak jakby zbliżamy się do etapu, przynajmniej w mojej działce i w przemyśle, że ktoś przyniesie jakiś "proprietary" OS (jakieś chude distro linuxa czy inne cokolwiek), dobrze zdefiniowany bez wodotrysków, na tym pokaże powiedzmy proprietarną lekką SCADA, bez modnych wodotrysków (znaczy kernel lekki i szybki, z UI przez web, http czy w podobie), i może wygrać kawał tortu. Bo pomału znajdą się klienci podatni na marketing "A u nas NIE MA IoTu, chmury, i niespodziewanej aktualizacji Win10, i wszelkiego tego lokalnego i zdalnego bagna, chuju i muju, za to nasza SCADA działa szybko, sprawnie, i bez wsparcia zyliona ludzi z IT i serwisu (albo udających wsparcie, no bo przcież g... wiedzą w temacie tak przekombinowanych systemów) i będzie tak działać przez następne 10 lat".

Jeszcze chwila i może się takie coś przydarzyć, 10 lat temu ktoś kto miał do wydania kufereczek stóweczek oczywiście brał "najnowsze rozwiązania wielkich dostawców" i nijak nie dałby się namówić na samoograniczenie; teraz coraz bardziej widać, że wielcy dostawcy produkują te systemy "na wszystko, do wszystkiego, ze wszystkimi opcjami", czyli do wszystkiego i do niczego, i jeszcze są na deser zależni od głupich pomysłów Microsoftu, jak jasny gwint.

Wiecie Gospodarzu, ja się z Wami nie będę spierać, a nawet się zgodzę, bo i sam odczuwam lekkie zmęczenie na myśl o tym, w co postanowiłem wdepnąć parę lat temu i z czym muszę bawić się każdego dnia. Stack technologiczny w webie robi się coraz wyższy i nie ma szans by to w którymś momencie nie jebło (tragedia z leftpad tylko mnie w tym utwierdza). Dlatego jeśli pojawi się sensowna i dobrze wspierana alternatywa dla JSa i okolic, gdzie nie będę musiał korzystać z osobnego frameworka tylko po to, by połączyć ze sobą zawartość dwóch plików, to natychmiast przesiadam się bez żalu. Póki co jednak jestem tam, gdzie jestem i poza nauką innego języka po godzinach za wiele zrobić nie jestem w stanie.

I mam wrażenie, że tak jest z większością klepaczy kodu, którzy wolą siedzieć tam, gdzie są i rzeźbić. Bo jaki mają wybór? Iść do innej firmy, gdzie pewnie też będą rzeźbić, bo klient wymaga, terminy gonią, a PM dyszy w kark?

@Bober

@Stack

IMHO się robi nie tyle wyższy, co głupszy i "leniwszy". No ale ja się nie znam, problemy jak leftpad mnie nie dotykają, bo jakbym tak robił swoje kawałki, żeby mnie dotykały, to sam bym się zwolnił. I pozwał. I zdegradował. I zwolnił jeszcze raz.

@dłubacze kodu

To akurat jasne, że dłubacze jak my tu dyskutujący nie mamy wiele do zrobienia w temacie, poza, jak w tym starym kawale, bieganiem coraz szybciej z pustymi taczkami. Musi się zmienić atmosfera wśród zamawiających systemy i dostarczających developerkę, i mam wrażenie, że pomału się zmienia. Słowo kluczowe "pomału".

@tyz_Aniou Wiesz, na te bibliotekowe zależności to jak najbardziej są patenty. Można nie ciągnąć z upstreamu, tylko mieć własne repo. Można bindować wersje bibliotek. To nie musi być poza kontrolą. Tylko problem jest właśnie z bezpieczeństwem - świadomość, że w czymś zaraz będą bugi, a aktualizacja jednego komponentu powoduje konieczność aktualizacji kolejnych, zmieni się sposób działania czegoś, zapewne (bo upstream ma kompatybilność wsteczną w poważaniu). Więc developerzy średnio mają ciśnienie na ten dodatkowy rygor, szczególnie, że blokuje im to dostęp do nowych wersji i nowych ficzerów w bibliotekach, których używają. Dyskusyjne jest też, czy lepiej poprawiać wersję "działa, nie dotykamy, there be dragons" sprzed lat pięciu (lub lepiej), czy jednak w miarę ad-hoc. Bo ten pierwszy wariant to zwykle kupa roboty i nakład porównywalny z przepisaniem całości (na co czasu nie ma), więc kończy się na zapakowaniu w kontener, wyizolowaniu, pofirewallowaniu. Przy modelu rolling masz jednak tylko drobne podniesienie wersji jednego komponentu + zależności, to się daje w jakiś tam sprint wpasować, tak czysto biznesowo patrząc.

I tak, znam ludzi, którzy szukali ostatnio jakichś pakietów/repo do Debiana 6 czy nawet 5, bo "soft klienta na tym działa", a PHP tak stary, że nie bardzo daje się uruchomić we współczesnych wersjach Debiania. Znaczy pewnie można próbować przekompilować, ale pewnie skończy się na starych bibliotekach w połowie systemu, więc i tak dziurawy będzie, a głównym wektorem ataku pozostaną appka klienta + antyczny PHP.

Nieco się jednak zmienia i pojawiły się - jako standard - wersjonowanie, testy i środowiska CI. I mam wrażenie, że z 10-15 lat temu tego nie było, przynajmniej nie standardowo. To jednak poprawia odporność na działanie w zmiennym środowisku.

@Boni Nie do końca mogę się o różnicy w pracy sieciowców wypowiadać, bo i nie jest to już moja podstawowa działka (i na dobrą sprawę nigdy nie była), i ludzie których znam nie muszą w najnowszych trendach pracować, i to co robiłem było dość mocno "po nowemu" (mocno zautomatyzowana/oskrytpowana całość), ale wydaje mi się, że aż tak dużo się nie zmieniło. Trochę core i "pudełek" zostało, jednak.

Faktem jest, że na topie jest SDN i obecnie sieciowiec raczej powinien ogarniać programowanie (nawet była taka prezentacja na PLNOG "jak nie zostać bezrobotnym sieciowcem"), ale wydaje mi się, że jakby żywcem wziąć sieciowca i programistę sprzed 20 lat, to ten pierwszy ogarnie znacznie szybciej współczesne systemy i technologie.

@rozie, re SDN

Ty weź, nawet mi o tym nie przypominaj. Widziałem jedno takie, Wiodące Rozwiązanie od środka (bardzo od środka). Możliwości możliwościami - choć bardzo dyskusyjna jest ich potrzeba, jeśli mówmy o wpychaniu tego do sieci szkieletowej, która jako całość ma działać non-stop przez dekadę a zmiany w niej zachodzą raz na pół roku (a i to niewielkie) - ale to wszystko wygląda na tak wrażliwe na awarie, że proszę siadać. -dyliard komponentów, bazy danych... ratujcie. Bardzo żałuję, że nie miałem czasu na wproszenie się na poważniejsze warsztaty i zrobienie paru eksperymentów pt. "a jak wam uszkodzę ten datafile na dysku, to jak to się wam podniesie?".

Co do samoograniczania i tego że może ktoś na tym wygra - ja bym bardzo chciał, bo sam mam już dość tego bełkotu i próby wciskania kitu wszędzie. IoT to coś co należałoby potraktować miotaczem płomieni i jako klient chętnie będę brał właśnie prostsze rozwiązania (tylko pewnie jeszcze takich jest jeszcze za mało).

Ale niestety nadal bełkot wygrywa, zwłaszcza gdy decyzje podejmują goście którzy nie zadają odpowiednich pytań i lubią "gładką gadkę".
Miałem ostatnio szkolenie z softu który właśnie wprowadzamy, a którego na szczęście ja będę pewnie używał rzadko. Na dzień dobry dowiedziałem się jakie to jest innowacyjne i robiące wszystko inaczej niż do tej pory. Innowacyjność polega m.in. na tym, że wszystkie urządzenia są tam określane jako "workload". W sumie to chyba głównie na tym. Jakiego słowa używają na workload nie mam pojęcia, kusiło mnie żeby zadać to pytanie, ale uznałem że robienie z nich idiotów publicznie to może i świetna zabawa, ale dla kariery taki sobie ruch, a ja jednak chciałbym mieć na chlebuś i coś do chlebusia.
Marzę o dniu w którym jakiś ważny szefu będzie chciał zapytać mnie co sądzę o takim sofcie, a ja wtedy zadam właśnie takie pytania i powiem co sądzę o ich "innowacyjności".

Byłem na szkoleniu, w którym przedstawiano jakąś technologię generowania aplikacji bazodanowo internetowych.
Faktycznie po dokładnym wypełnieniu tablic reszta robiła się prawie sama.
Prowadzący przekonywał nas, że przy tej metodzie nie ma żadnych problemów z pielęgnacją i modyfikacją softu - oczywiście pod warunkiem, że się *wszystko* bardzo dokładnie przemyśli przy projektowania.

@tyz_Aniou No dla mnie SDNy to też trochę pic na wodę, generalnie[1]. To co miałem to dobrze oskryptowana i zautomatyzowana sieć na zasadzie powiedzmy provisioningu konfiguracji i czytania danych. Żaden rocket science i pewnie korzystalibyśmy z softu producenta, gdyby nie to, że sieć nie była homogeniczna, a producent nie chciał koszmarnych pieniędzy za soft.

Za to doświadczenie z SDN mam przy okazji zabaw z Openstackiem, gdzie to środowisko testowe średnio nam działało, mimo postawienia wg dokumentacji. No więc babrałem się z low level debugiem (ręczne sprawdzanie, podnoszenie iface-ów z ręki, ten klimat) w tej przekombinowanej nieco architekturze dobry dzień i bliski byłem zaorania wszystkiego i postawienia od zera, ale w przypływie desperacji zrobiłem najpierw restart całości i... ruszyło od kopa. TBH nie wiem co go zabolało, bo logów neutrona nie czaiłem wtedy zupełnie. Przypuszczam, że nie dotarł jakiś komunikat o wykonaniu czegoś/nie zapisał się w bazie i sobie stwierdził, że coś tam nie jest podniesione, choć było. W każdym razie nie udało mi się znaleźć różnicy w warstwie sieciowej między wersją niedziałającą i działającą.

[1] No chyba, że właśnie chmura, zwł. ta bardziej prawdziwa, a nie podstawka pod VPSy będące odpowiednikami fizycznych maszyn. Bo po prostu człowiek jest za wolny i zbyt zawodny do ogarniania tego.

Ponieważ ORACLE wypiął się na użytkowników i przestał pielęgnować ORACLE FORMS, przenosimy Łososia na javę.

Dotychczas mieliśmy niecałe 300 plików z formularzami (odpowiadają każdy jednej pozycji w menu) i do tego garść bibliotek, razem 300 plików, 280 MB. Wszystko w jednym katalogu.

Źródła nowej wersji w javie zajmują mniej miejsca - niecałe 200 MB, ale to ponad 12000 plików rozbitych na ponad 1500 katalogów.

@Boni "gówno prawda, że za to się płaciło "zawsze i wszędzie". Za to się płaci w czasach zbędnego przekombinowania"

Moja odpowiedź szła po linii "zawsze i wszędzie płaci się _głównie_ za ogarnianie swojego warsztatu, a mniej za zrobienie _idealnego_ krzesła/kurczaka/sterownika".

W tym sensie kwestia badziewnego drewna/przemysłowej hodowli mięsa/przekombinowania kompów to sprawa poboczna.