W tym wypadku klepanie rozproszonego cruda ( ͡°͜ʖ͡°)
@validshort: Najgorzej xD Ale co expa nabijesz i się nauczysz to nikt ci nie zabierze. Ja dzięki temu że przez połowę mojej kariery w IT czyli jakieś 6 lat grzebałem się w gównie, nauczyłem się jak wielu rzeczy nie robić i teraz to procentuje w dostarczanych projektach i uznaniu współpracowników.
@markaron: Story of my life. Generalnie to 90% rzeczy uczyłem się widząc jak czegoś nie robić, bo jest antywzorcem. Ładne rzeczy są na szkoleniach i konferencjach.
@validshort: Częściowo tak, bo na konferencjach pokazuje się tylko te najprostsze case'y, które potem trzeba sobie samemu ekstrapolować na użycie w codziennych projektach. Wiele osób ma tendencję do podążania za modą i onanizmu technicznego. A prawda jest taka, że każdą nowinkę techniczną, wzorzec czy bibliotekę trzeba zrozumieć, przemyśleć, przedyskutować czy faktycznie tego potrzebuję w projekcie i dopiero potem decydować się na jej użycie.
@fantazm: Ja tylko powtarzam po mądrzejszych :) Nie wiem kto jest autorem tego określenia, ale pierwszy raz usłyszałem go z ust Sławka Sobótki z Bottega IT Minds podczas jakiejś konferencji.
@markaron: No ale tak czy inaczej to naprawdę świetne określenie. Z jednej strony w mojej branży jest raczej problem często z zaczadzeniem umysłowym i nie podążaniem za trendami ("twarda" inżynieria, nasza firma po dziś dzień nie chce się przekonać do modelowania 3D np.), z drugiej strony faktycznie trzeba mieć też jakieś poczucie realizmu i nie rzucać się na coś tylko dlatego, że jest nowinką, a na pewno nie z motyką na
@fantazm: niestety (albo stety) programowanie to w większości nie jest twarda inżynieria. Styl programowania i projektowania systemów wygląda tak jak wygląda, żeby ludziom się dobrze pracowało. A to bardzo kwestia dyskusyjna. jakbyś przeniósł typowego developera sprzed 20 lat do dzisiejszego projektu (i na odwrót) to w obu przypadkach będziesz miał szok kulturowy i syndrom wyparcia.
@Saly: Możliwe, ja się na programowaniu kompletnie nie znam, zatrzymałem się w nim na etapie prostych algorytmów numerycznych i raczej nigdy dalej nie pójdę, bo mnie nie jara niestety... A szkoda, bo w sumie jeżeli idzie o sam ogar do "logiki" programowania to go mam, więc pewnie mógłbym być w tym dobry, gdyby tylko mnie to nie wyczerpywało! Pod względem zainteresowań nadawałbym się jako inżynier w typowym kraju demoludowym. Ciężki przemysł,
@validshort: jeśli jest czas na pisanie po trochu od nowa to spoko wyzwanie, ale jeśli masz po prostu dopisywać klocki do tego gówna to już bym nie chciał xD
@menelaosPL: to monolit czy mikroserwisy? Bo jest tez modułowy monolit, który ma sporo plusów jednego i drugiego, oczywiście ma tez ich minusy - ale ciężko powiedzieć czy błędem był wybór architektury czy brak doświadczenia i woli nauki. Bo nie ukrywajmy, jak ktos jest zabetonowany jako monolit, bo tak i już to swoim nastawieniem nie wykorzysta żadnych benefitow mikroserwisow, ale za to wpadnie w każdą jedna pułapkę =]
@nilphilus: tak jak kolega wyzej pisał najgorsze gowno rozproszony monolit, dziedziczy wszelkie wady monolitu i mikroserwisow, żadnych zalet, jeszcze najlepsze sa te komunikujace sie tylko synchronicznie, temporal coupling jak #!$%@?, a ile takich potworkow jest na rynku to glowa mała. Mikroserwisy niegdy nie powinny być pierwszą architekturą, docelową jak najbardziej, ale to praca inkrementacyjna, pierwszy powinien byc modularny monolit
@menelaosPL: rozproszony monolit to w sumie pierwszy raz słyszę =] w sumie ciężko mi to sobie wyobrazić. A mikroserwisow mogą byc pierwsze, ale trzeba miec świadomości, ze produkt wyjdzie później niż mógłby wyjsc monolit lub modularny monolit.
#programowanie
Wzór wypowiedzenia umowy o współpracę.( ͡° ͜ʖ ͡°)@validshort: Najgorzej xD Ale co expa nabijesz i się nauczysz to nikt ci nie zabierze. Ja dzięki temu że przez połowę mojej kariery w IT czyli jakieś 6 lat grzebałem się w gównie, nauczyłem się jak wielu rzeczy nie robić i teraz to procentuje w dostarczanych projektach i uznaniu współpracowników.
@validshort: Częściowo tak, bo na konferencjach pokazuje się tylko te najprostsze case'y, które potem trzeba sobie samemu ekstrapolować na użycie w codziennych projektach. Wiele osób ma tendencję do podążania za modą i onanizmu technicznego. A prawda jest taka, że każdą nowinkę techniczną, wzorzec czy bibliotekę trzeba zrozumieć, przemyśleć, przedyskutować czy faktycznie tego potrzebuję w projekcie i dopiero potem decydować się na jej użycie.
Tak
@markaron:
Świetne określenie! Zapisuję.
Możliwe, ja się na programowaniu kompletnie nie znam, zatrzymałem się w nim na etapie prostych algorytmów numerycznych i raczej nigdy dalej nie pójdę, bo mnie nie jara niestety... A szkoda, bo w sumie jeżeli idzie o sam ogar do "logiki" programowania to go mam, więc pewnie mógłbym być w tym dobry, gdyby tylko mnie to nie wyczerpywało! Pod względem zainteresowań nadawałbym się jako inżynier w typowym kraju demoludowym. Ciężki przemysł,
@validshort: standard, projekt tzw. CV Driven Development, ktoś chcial into mikroserwisy
@nilphilus: tak jak kolega wyzej pisał najgorsze gowno rozproszony monolit, dziedziczy wszelkie wady monolitu i mikroserwisow, żadnych zalet, jeszcze najlepsze sa te komunikujace sie tylko synchronicznie, temporal coupling jak #!$%@?, a ile takich potworkow jest na rynku to glowa mała.
Mikroserwisy niegdy nie powinny być pierwszą architekturą, docelową jak najbardziej, ale to praca inkrementacyjna, pierwszy powinien byc modularny monolit