Kulty cargo w waszej pracy?

Z jakimi przykładami kultu cargo zetknęliście się w waszej pracy zawodowej?

• programowanie zorientowane obiektowo
• wieloetapowe rekrutacje z zadaniami domowymi do januszeksów
• "wymagamy X lat doświadczenia"
• "najnowsze technologie"

Tak robią inne firmy i tak my będziemy tak robić np. popularne jest Agile i wszystko robimy w Agile, popularny jest Kanban to i my robimy Kanaba. Ogólnie wszystko co idzie z Ameryki jest bezkrytycznie super więc i my to będziemy stosować. Przykłady można mnożyć...

PS. Ogólnie to takie ślepe bezkrytyczne naśladownictwo wszystkich nowinek, które pojawiają się na rynku IT. Nie neguje, że wszystko jest od razu złe, ale można zastanowić się trochę wybrać co jest dobre w danej organizacji i wprowadzić.

slowbro napisał(a):

Tak robią inne firmy i tak my będziemy tak robić np. popularne jest Agile i wszystko robimy w Agile, popularny jest Kanban to i my robimy Kanaba. Ogólnie wszystko co idzie z Ameryki jest bezkrytycznie super więc i my to będziemy stosować. Przykłady można mnożyć...

True, true.

Jeśli chodzi o najczęściej słyszane mity i legendy to:

• Java umiera
• Java to COBOL XXI. wieku
• Java jest wolna
• Java posiada milion frameworków, które junior programmer musi umieć na początku kariery

Wibowit napisał(a):

Jeśli chodzi o najczęściej słyszane mity i legendy to:

• Java umiera
• Java to COBOL XXI. wieku
• Java jest wolna
• Java posiada milion frameworków, które junior programmer musi umieć na początku kariery

Kult cargo, a mity i legendy to dwie różne sprawy.
https://pl.wikipedia.org/wiki/Kulty_cargo

• wszystko microservices!
• microservices jednak zle!
• serverless!
• wszystko w cloud!
• docker such wow such devops
• 1000 LoC? Najlepiej DDD i event sourcing
• rijaktiw wszyndzie!
• <wstaw jakikolwiek framework js>

Najbardziej osłuchanym jest Scrum i - powoli zanikająca na szczęście - wiara w jego magię pozwalającą na dowiezienie trzymiesięcznego projektu w cztery tygodnie. Najlepsze są rozmowy z ludźmi, którzy porobili sobie certyfikaty Scrum Masterów ale trochę się spóźnili na pociąg i nijak nie mogą ich wykorzystać w swojej pracy. W rezultacie non-stop powtarzają formułki typu "nie wyszło bo SINO", "nie byliśmy Agile" itp. w sytuacji, gdy metodyka raczej przeszkadzała niż pomagała.

Kolejna sprawa to korpokultura. Oprócz bycia dobrym w swojej pracy masz jeszcze się udzielać w "iwentach" firmowych. To znaczy nikt ci nie powie, że musisz... Ale jednak jeśli chcesz pójść wyżej to sporo taka działalność ułatwia. Masakra.

A, i dodałbym jeszcze "Big Data". Zasłyszana anegdota: techniczny ekspert od Big Data poszedł na spotkanie. Na miejscu siedzą ludzie - dużo poważnych menedżerów i analityków - i dyskutują, co oni nie zrobią w tym BD. Kolo się pyta o prostą rzecz - po cholerę im BD, skoro oni mają już przygotowany model matematyczny i dane pod ten model można pociągnąć z jednego możliwego miejsca. Cisza, konsternacja. W końcu odzywa się dziewczyna zatrudniona miesiąc wcześniej: "To my to jeszcze raz przemyślimy".
Przez ponad sześć miesięcy była cisza w temacie. Potem zorganizowano następne spotkanie. Tym razem ekspert nie został zaproszony. Podobno nawet jakiś projekt uruchomili, ale człowiek zdążył już stamtąd odejść.

"najnowsze technologie"
mam wrażenie, że im bardziej jest ktoś nietechniczny, tym bardziej będzie wychwalał najnowsze technologie. Może dlatego, że dla nietechnicznych każda technologia sprawia wrażenie czarnej magii, a dla osoby technicznej to normalne narzędzia, które mają zalety i wady.

i np. - Bootstrap - spotkałem się z naiwną wiarą grafików/designerów i innych osób "nietechnicznych" w to, że layout na bootstrapie się robi bardzo szybko i że wystarczy, że pokażą mi PSDki, i będzie zrobione w trymiga, bo przecież jest Bootstrap, a Bootstrap to srebrna kula. Oczywiście to, że design odbiega bardzo od bootstrapowych defaultów, to o tym już nietechniczni nie myślą.

poza tym Angular, React, Redux - ale to już mam wrażenie, że to programiści bardziej w to wierzą (Redux jest największym cargo cultem, bo wiele osób po prostu bezmyślnie kopiuje wszystko, co zobaczy w tutorialu czy w artykule na temat Reduxa, tak że nawet Dan Abramov się wiele razy dziwił, w jaki sposób ludzie używają Reduxa, albo że nie rozumieją do końca).

zrytualizowany SCRUM, te wszystkie ceremonie, story pointy, planning poker itp. Kanban itp. To jest jak dla mnie największa strata czasu. Chyba, żeby to uznać za placebo, i coś co ma zmotywować ludzi do pracy, przez wprowadzenia elementów grywalizacji czy przez zrytualizowaną integrację społeczną (np. spotkania na stojąco - trochę jak grupowa modlitwa).

No i kult lat doświadczenia, edukacji formalnej na informatyce, i doświadczenia "komercyjnego" (rozumianego najczęściej jako programowanie, które spełnia warunki: za hajs (open source się nie liczy), odbywa się w biurze (wszelka praca zdalna też się nie liczy) i jest w zespole (freelance w pojedynkę też się nie liczy) - i generalnie nie spełniasz jednego z warunków, np. nie studiowałeś na polibudzie, nie masz odpowiednich lat doświadczenia, czy odpowiedniej historii zatrudnienia "komercyjnego" i już mogą cię niektórze Janusze HRu odsiać na rekrutacji - najbardziej chętne do odsiewu są panie z HR, które nie mają pojęcia o programowaniu, natomiast szukają ciągle tylko kogoś "dla naszego klienta", mając jakieś z góry d**y ustalone kryteria, jakie kandydat powinien spełniać).

wieloetapowe rekrutacje z zadaniami domowymi do januszeksów

Właśnie. No i sam kult skillów programistycznych. Rekrutuje się pod kątem skillów programistycznych i na to się testuje programistę, podczas gdy w rzeczywistości praca programisty wymaga często również nieco innych skilli, np. skilli komunikacyjnych.

LukeJL napisał(a):

Właśnie. No i sam kult skillów programistycznych. Rekrutuje się pod kątem skillów programistycznych i na to się testuje programistę, podczas gdy w rzeczywistości praca programisty wymaga często również nieco innych skilli, np. skilli komunikacyjnych.

Bardzo słuszna uwaga.

Od siebie dodam tyle, że jeśli jako biznes zaczniemy rozliczać programistę tylko za to, co "naklepie" to zawód programisty staje się równoznaczny z zawodem stolarza. Od tej pory programista dla biznesu staje się tylko kosztem, ponieważ nic od siebie nie wnosi. Tak samo jak taniej jest iść i kupić gotowe meble, równie łatwo dla biznesu będzie poszukać gotowego rozwiązania na rynku niż zatrudniać programistów do "rzeźbienia" produktu od nowa.

Pozycja "klepacza" umiera i jeśli programista nie jest w stanie, jako specjalista, komunikować się ze światem na temat technologii, w których się specjalizuje, tłumaczyć ryzyk, zaproponować lepsze rozwiązanie, uzasadniać swój punkt widzenia i zrozumieć biznesu, który mu płaci to przede wszystkim wiele nie zarobi i prędzej czy później jego pracę zastąpi gotowy produkt.

“to musi byc szybkie, napiszmy to w c++”

Kulty cargo, z którymi kiedyś się spotkałem? Bezkrytyczna wiara w waterfall w jednym z Januszeksów. Wprawdzie to było jakieś 10 lat temu, ale jednak.

Wiara, że jak "my robimy w SCRUM" to deploy postępów na internal test server ma być co najmniej 3x dziennie (w końcu jesteśmy AGILE co nie? ;-))

Ale z tego wszystkiego i tak najbardziej mnie zirytowało bezkrytyczne trzymanie się "code guide" w jednym z projektów, gdzie mega ważne były każde wcięcia, spacje i entery (nie, nie w pythonie). I to połączone z podwójnym code review, bo "my stawiamy na jakość kodu" po tym, jak zapomnieliśmy dać "enter" przed "return" w metodzie.
Tylko szkoda, że przez to projekt posuwał się do przodu 3-5x wolniej niż powinien.

Tak. To był typowy kult cargo "super jakości" (zbyt ambitny code guide + code review, który w większości ograniczał się do łapania literówek i "enterów").

Może nie u mnie w pracy, ale dotyczy mnie - kiedyś uwierzyłem małej firmie, że więcej się u nich nauczę niż w korpo, więc wybrałem ich za mniejszą kasę, bo "W KORPO SIE NIC NIE NAUCZYSZ".

"Jestem dobrym/swietnym programista"

tamtamtu napisał(a):

"Jestem dobrym/swietnym programista"

Kolejny co nie rozumie o czym jest ten watek.

Cargo culty to mój konik. Walka z nimi jest strasznie trudna - zanim się uda jeden ubić to wyrastają 3 nowe.
Pod pojęciem cargo culty w IT (w szczególności w moich okolicahc = Java) mam na myśli praktyki i technologie, które miały kiedyś sens ze względów na np. ograniczenia hardware, kontekst biznesowy czy ogólną świadomość programistów. Niestety są nadal stosowane mimo, że środowisko się zmieniło. Często ich wycięcie jest bardzo trudne, bo nowi porgramisci od zawsze tak programują i nie znają alternatyw. Co gorsza, często funkcjonuje tzw "fałszywa alternatywa". Przykład: jak to annotacje są bez sensu ?- chcesz to wszystko w XML pisać... Jeszcze gorzej, że samo szukanie alternatyw dla zakorzenionych cargo podlega pod herezję i tzw. brak profesjonalizmu.

A teraz jedziemy was wszystkich poobraźać moi kultyści:

• serwery aplikacji,
• kontenerey servletów (tak! tomcat też, nawet jetty też...),
• java beany, settery i gettery,
• null i null checking,
• nie używanie new,
• nie używanie static,
• strach przed wątkami,
• wydajność / mikrooptymalizacje (na tym forum cudnie widać jak co chwila pojawia sie tekst o wydajnieszym kodzie...),
• interfejsy do wszystkich serwisów /komponentów,
• JavaEE,
• Spring (szczególnie @Autowired i aspekty),
• Annotacje,
• REST,
• wzorce projektowe (zwłascza behawioralne),
• mockito/ mockstrurbacja,
• ORMy na pałę, (jak używasz **save **ze spring data (na JPA) do update danych to wiedz, że pewnie używasz ORM na pałę),
• DTO mapujące Entity 1 do 1,
• Transakcje bazodanowe (nie ogarnianie, że transakcja biznesowa i bazodanowa to nie to samo), 2 phase commit,
• Bazy danych ( w szczególność SQL do przechowywania danych aplikacji),
• Java ( szczególnie jeśli używasz Lomboka),
• SCRUM,
• mikroserwisy, (szczególnie mikroserwisy w trójkę),
• lightweight - nazwij framework lekki i od razu magicznie jest piękny,
• React/Angular ftw.
  EDIT - byłbym zapomniał
• UML i MDA (choć to drugie to nie bardzo cargo cult, bo się nie roznosi - wejście w MDA zawsze oznacza śmierć - czasem wieloletnią, ale śmierć)

Rodzą się nowe culty, ale jeszcze nie osiadły dobrze:

• Reactive,
• NoSQL

Oczywiście, lista jest długa, a i tak pewnie coś pominąłem. Gdyby ktoś miał wątpliwości do niektórych punktów - to wyjaśnie dlaczego. Oczywiście prawie każdy element z podanej listy ma nadal swój rozsądny konktekst, w którym mógł by być uzasadniony, jednak jest to raczej bliżej 10% przypadków, niż 90%, jak obserwuję.

@jarekr000000: a nie było tam lambd i monad? (Może i były, ale nie w 1 trójce...)

scibi92 napisał(a):

@jarekr000000: a nie było tam lambd i monad? (Może i były, ale nie w 1 trójce...)

Dopiero wejdą na listę. Ale najpierw muszę poznać sensowną alternatywę (daj mi chwilkę - rok - dwa).

@jarekr000000 bez tego to zostaje ci pisanie w notatniku a soft klientowi wysylasz na kalkulatorze

EloMoto napisał(a):

@jarekr000000 bez tego to zostaje ci pisanie w notatniku a soft klientowi wysylasz na kalkulatorze

No i tak właśnie działa zasada fałszywej alternatywy - jak wspominałem.

az poszedlbym posluchac w marcu na cap talka o cargo funkcyjnym, ale akurat wyjezdzam :)

Czy strach przed watkami to na pewno cos zlego? ;)

Strach przed wątkami wynika w dużym stopniu z korzystania z JavaEE i Springa, gdzie użycie własnych wątków powoduje wybuch frameworka. Jak się usunie przyczynę problemu to i wątki stają się użyteczne i prostsze. Problemy z programami wielowątkowymi są generalnie nie do uniknięcia, można co najwyżej zamknąć oczy (użyć JavaEE lub Springa) i przenieść problemy związane z nie ogarnianiem watków w javie na poziom bazy danych i nie ogarnianie transaction isolation. Wychodzi to samo - tylko w innym miejscu.

jeszcze nie wiadomo co aplikacja ma robić, a już Mongo podpięte
@Maciej Cąderek

tak bardzo w punkt, że aż chciałoby się zaplusowac ten komentarz XD W ogóle nie tylko Mongo, ale ogólnie programiści JavaScript mają tendencję do wrzucania wszystkich swoich ulubionych narzędzi na bardzo wczesnym etapie rozwoju.

Programista JS jak ma do zrobienia prostą stronę, to musi od razu zainstalować Webpacka, wrzucić React, Sass (nawet jeśli jego CSSy to 3 klasy na krzyż), Redux (a jak Redux to i Redux Saga oczywiście), oczywiście React Router - też jest to jedna z bibliotek, którą się instaluje na zapas.

Poza tym oczywiście Lodash, od razu też jakiś Bootstrap wejdzie, jeszcze parę innych bibliotek "must have"...

...a potem, co najlepsze, frontendowcy się żalą w internecie, że postawienie projektu frontend zajmuje im kilka godzin i żalą się na wielkość bundla w megabajtach. Mimo, że sami sobie zgotowali ten los.

Oczywiście, czasem pewne rzeczy warto ustawić od razu. Ale co innego jest wgranie Webpacka, Babela i Reacta (taki tam przykładowy minimalny zestaw, żeby pisać w React), a co innego jest po prostu instalowanie wszystkiego jak leci, na zasadzie lubię tę bibliotekę, więc ją instaluję, mimo, że wiele bibliotek mogłoby być zainstalowane potem, kiedy naprawdę będą potrzebne.

Czyli niestety wygrywa BDUF nad KISS, YAGNI i Lean :(

Tak samo na backendzie od razu jak jest Node to musi być i Mongo, i Docker, Jenkins i parę innych pierdół, "żeby było profesjonalnie". Mam wrażenie, że programiści za dużo czasu spędzają na napawaniu się swoją własną profesjonalnością, a za mało myślą o problemach, które mają przed sobą (co potem się mści, bo nawet projekty, które niewiele robią pod kątem biznesowym są rozdmuchane do granic możliwości i pełne przeinżynierowanych abstrakcji i zależne od mnóstwa narzędzi - bo ludzie po prostu pododawali wszystko dlatego, że im się zdawało, że tak będzie profesjonalnie. Czyli - cargo cult).

problemu to i wątki stają się użyteczne i prostsze.

Duży projekt na github :

private A a;

public static A getA() {
    if(cos == null){
        synchronized (this){
            if(cos == null)){
                cos = generateHejwli();
            }
        }
    }
    return cos;
}

wygląda poprawnie, nie ?

jakoś dziwnie mi to napisać ale ... Java w przypadku wielowątkowości nie była i nie będzie "prosta" :D

The behavior of threads, particularly when not correctly synchronized, can be confusing and counterintuitive.

Java 8 Language Specification § 17.4 pp 631

@rubaszny_karp:
W Javce stosuje się inne idiomy niż w innych językach. Ja lubiłem ten: https://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom

Java w przypadku wielowątkowości nie była i nie będzie "prosta" :D

Nie musisz przecież ograniczać się do mutexów i semaforów. Jest mnóstwo różnych abstrakcji z których można wybierać. Istnieje nawet Javowe API do Akki: https://doc.akka.io/docs/akka/current/guide/introduction.html?language=java

Istnieje jakiś język, który magicznie rozwiązuje problemy wielowątkowości?

Sprawę dość bezpiecznej wielowątkowości załatwia kilka językow:
Erlang (skąd aktorzy się wzieli?), Rust i oczywiście jak wyżej podany @Maciej Cąderek: JavaScript (rozwiązuje like a boss).
Przy czym nie ma się co z JavaScriptu śmiać - bo po dodawniu WebWorkerów w zasadzie działa to trochę jak Erlang lub Akka Actors.

W Rust piszą tak:
Thread safety isn’t just documentation; it’s law.
https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html

NIestety, nie mam w Rustu żadnego doświadczenia. NIe wiem jak się sprawdza w praniu.

JavaScript - Maciej Cąderek dziś, 02:41

O'RLY? Primo - do niedawna JavaScript był jednowątkowy. Secundo, to co się obecnie dzieje to zjazd w stronę Javy, C++, itd:
https://developer.mozilla.org/pl/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer
https://github.com/tc39/ecmascript_sharedmem/blob/master/TUTORIAL.md
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics

Sprawę dość bezpiecznej wielowątkowości załatwia kilka językow:
Erlang (skąd aktorzy się wzieli?), Rust i oczywiście jak wyżej podany @Maciej Cąderek: JavaScript (rozwiązuje like a boss).

Tak się składa, że piszę projekt w Ruście od jakiegoś czasu ( https://github.com/tarsa/demixer ). Główną zaletą Rusta jest to, że mechanizm ownership i borrowing w dużej mierze rozwiązuje problem poprawności wskaźników i wycieków pamięci - czyli to co Java od wieków osiągała dzięki Garbage Collection (a Rust nie ma GC w standardzie). Sam ten mechanizm bierze swoje źródło w sprytnych wskaźnikach z C++. Rust nie ma żadnych dodatkowych magicznych właściwości. Dalej są mutexy, semafory, mutowalne współdzielone tablice, itp itd

Przy czym nie ma się co z JavaScriptu śmiać - bo po dodawniu WebWorkerów w zasadzie działa to trochę jak Erlang lub Akka Actors.

Sam mechanizm aktorów też nie sprawia, że wielowątkowość staje się przewidywalna. Możesz mieć deadlock, livelock, kolejka wiadomości do aktora może się przepełnić, wiadomości mogą się zgubić (przy zdalnych aktorach), itp itd Sposobem na uniknięcie przepełnienia buforów bez strat wydajności są Reactive Streams, ale reszta problemów pozostaje.

OFFTOP miesiąca.

OFFTOP miesiąca.

Eee tam, kult Rusta demistyfikuję :]

Dzięki za demistyfikację Rusta, ja w ich marketing i przykłady wierzyłem :-) (W sumie miało sens).

Rust jest pewnego rodzaju małą rewolucją jeśli się go porówna do C i C++. Sprytne wskaźniki znane z biblioteki standardowej C++ są w Ruście częściowo wbudowane w język i kompilator. Kompilator Rusta sprawdza o wiele więcej rzeczy na etapie kompilacji niż kompilator C++, poza tym w Ruście sporo rzeczy które w C++ są normą wymaga bloku unsafe. Idiomatyczny kod Rustowy bez bloków unsafe jest bezpieczny jeśli chodzi o poprawność wskaźników i np kolejność wywoływania destruktorów, dealokacji i odwołań.

Sprytne wskaźniki (obojętnie czy częściowo wbudowane w język jak w Ruście czy zupełnie osobno w bibliotece standardowej jak w C++) mają swoje wady i zalety w porównaniu do odśmiecania pamięci. Zaletą jest mniejsze zapotrzebowanie na pamięć i brak pauz na globalne odśmiecanie. Jedną wadą jest niekompletność - odśmiecanie pamięci za pomocą zliczania referencji ściśle rzecz biorąc nie działa, bo wysypuje się (tzn są wycieki pamięci) na łatwych do stworzenia cyklicznych referencjach. Inną wadą jest słaba wydajność w zastosowaniach wielowątkowych - z tego powodu w Ruście jest jednowątkowa Rc (zliczana referencja) oraz wielowątkowa Arc (atomowa zliczana referencja). Arc jest wielokrotnie wolniejsza od Rc, więc trzeba iść na kompromis. Kompromisu tego w przypadku takiej np Javy nie ma - w Javce kopiowanie referencji jest zawsze tanie, niezależnie od tego czy inne wątki mają referencje do tego samego obiektu.

Mimo wszystko Rust w porównaniu do C i C++ to moim zdaniem bardzo duży postęp w kwestii gwarancji zapewnianych przez kompilator.

Co do aktorów/message passing - to wiadomo, że to nie jest koniec problemów, ale jednak eliminują dużo niskopoziomowych bugów. Trochę jak haskell, nie gwarantuje, że kod liczy to co chciałeś, ale eliminuje kilka miejsc gdzie łatwo się pomylić.

Wielowątkowość czy obliczenia rozproszone to skomplikowana dziedzina. Nie ma złotego rozwiązania które nadawałoby się do wszystkich niesekwencyjnych obliczeń. Dziedzina ta obejmuje skrajnie różne rozwiązania jak np GPGPU po jednej stronie czy rozproszone centra obliczeniowe po drugiej stronie.

Mechanizm aktorów moim zdaniem bardzo dobrze nadaje się do modelowania typowych zastosowań biznesowych w aplikacjach interaktywnych (czyli nie-wsadowych, bo tam można np klepnąć jakiś strumień w Sparku i gotowe).

Odnosze wrazenie, ze REST to tez cargo kult. Serio niektorzy to chyba nie znaja innych sposobow komunikacji.

I pozniej mamy typowo eventowe dane robione for loopem i rest call per element...

To ja mam na odwrot i najpierw patrze czy mzona cos zrobic async czy musze sync.