Wpis z mikrobloga

@Nofenak: tak.

Jako junior backendowiec powinieneś umieć napisać porządną aplikację backendową, do tego prosty frontend bez bajerów (wystarczy react/angular z UI material wyklikać). Następnie umieć stworzyć obraz dockera, wypchnąć do huba, zaciągnąć do AWS ECS/EC2 i nim zarządzać. Generalnie free-tier AWS podstawy powinieneś mieć opanowane. Zbyt wiele rzeczy na AWS darmowych nie jest więc dużo do nauki tam nie ma. Ogólny cały koncept chmury z teorii powinieneś znać, co to load
. Sama znajomość frameworka na backendzie to nauka na lata.. (przykład: Spring Framework)


@pabisbar: ??? a co tam masz do nauki na lata? To z czego korzystasz w pracy nauczysz się w 2-3 miesiące i korzystasz z 90% powtarzających się rzeczy. Pozostałe 10% używasz raz na rok wiec i tak musisz używać dokumentacji a nie uczyć się na pamieć, bo ciągle się te rzeczy zmieniają.

Nauka na lata to czysty kod
To co wymieniłeś to trochę sporo, chociaż zależy co masz na myśli. Sama znajomość frameworka na backendzie to nauka na lata.. (przykład: Spring Framework)


@pabisbar: a kto płaci 8 koła za brak wiedzy zdobytej latami? Nikt ci nie da normalnej pensji za umiejętność stworzenia pętli lub wystawienia endpointa, w innych zawodach to też lata nauki zanim dostaniesz 8k.
a kto płaci 8 koła za brak wiedzy zdobytej latami? Nikt ci nie da normalnej pensji za umiejętność stworzenia pętli lub wystawienia endpointa, w innych zawodach to też lata nauki zanim dostaniesz 8k.


@Kupamilosci: a to co napisałem to jakieś rok-dwa lata nauki na poziom juniora, więc też nie przesadzajmy z tą nauką latami. Wystarczy uczyć się każdego dnia 2-3h dziennie i po roku zbierze się 1000h nauki i wtedy można
@nad__czlowiek: Rok-dwa na wszystko ok, na poziom Juniora. Z frameworkiem miałem na myśli znajomość również takich modułów jak Spring Integration itd. Ta wypowiedź brzmi rozsądniej.

@Kupamilosci 8k brutto UoP ma u nas junior po 1.5-2 latach pracy zawodowej :) Na pewno nie na dzień dobry. Chociaż przy obecnej inflacji pewnie się to zmieni.

By the way, trochę szkoda ludzi którzy poświęcili czas na naukę Webfluxa i podobnych reaktywnych rozwiązań po release
@nad__czlowiek: Interesujące, przeczytam jutro w pracy. Do tej pory miałem czas na przetestowanie tego w dummy projekcie + dokumentacje oraz prezentacje z oficjalnych źródeł oracle/project loom (czyli raczej faworyzujące VTs)

(włąśnie na takich tematach płyną godziny, ale w sumie jak już pracujesz zawodowo..)
@pabisbar: imo jak się zna historie sun/oracle to standardem jest w tej branży, że wszystko co robi community zazwyczaj jest lepsze niż to co wyplują oraclowcy
np 10 lat temu spring vs java ee (obecna jakarta EE) - przepaść była kolosalna, dzisiaj spring niestety nie jest już lightweight i stał się troche taką kobyłą jak java EE była kiedyś. (podobno teraz micronaut jest lepszy od springa, ale nie miałem styczności z
@nad__czlowiek: odnośnie kobyły, wymyślili GrallVM z dockerem, próbowałem u siebie to wdrożyć ale szkoda zachodu żeby zyskać tylko lepszy startup time (chociaż może czasami aż..). To samo rekordy, niby spoko podróba lomboka ale są immutable a rekomendują żeby zastąpić nimi klasyczne DTO. Tyle, że często na klasycznych DTO robi się operacje zmieniające stan obiektu aby nie operować bezpośrednio na encjach. Więc tyle z rekordów.
@pabisbar: no z rekordami to trzeba by robić wszystko immutable, kiedyś czytałem o takim podejście żeby w ogóle nie robić setterów tylko same obiekty immutable. Nowe obiekty przez buildera (lub konstruktor gdy ma mało paramsów) a modyfikacja obiektu poprzez copy constructora(stary obiekt + nowe parametry). Bo de facto masowe get/set w każdym dto/encji jest zaprzeczeniem enkapsulacji ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ ͡°