[mk321]

#programowanie #java

Znam dobrze Javę, dobrze podstawowe moduły Springa, podstawy JPA, podstawy Dockera (Docker Compose).
Robię takie typowo korpo-apki (backend i web, do tego trochę frontu w np. Angularze).

W co dalej iść? Jakich technologii się uczyć? Chodzi dalej o ten sam obszar (aplikacje dla banków, ubezpieczenia, telco, dokumenty itd). Żeby zostać #programista15k (senior Java developer).


1. Technologie rozproszone (Hazelcast, Ehcache itd). Żeby móc tworzyć skalowane aplikacje, które się komunikują ze sobą
2. Wejść głębiej w Hibernate, bazy danych i wydajność tego (poziomy cachowania Hibernate, lepsze indeksy na bazie danych, wejść bardziej w jakąś bazę np. Oracle / PostgreSQL). Żeby móc tworzyć aplikacje, które przetwarzają większe zbiory danych.
3. Technologie mikroserwisowe od strony aplikacji (Spring Cloud, Netflix Hystrix, Eureka, Zull). Żeby móc pisać aplikacje, które składają się z dziesiątek lub setek microseriwsów.
4. Technologie mikroserwisowe od strony DevOps (Kubernetes, może monitoring, może Rancher, OpenShift, Swarm). To jak się wdraża microserwisy. To powinni robić DevOpsi, ale często jak takiego nie ma, to wymaga się tego do backendowców.
5. Chmury (AWS, Amazon EKS - Kubernetes na AWS, może Google Cloud). Tam gdzie wdraża się microserwisy. Powinien to robić DevOps, ale jak nie ma to robią to backendowcy.
6. Obliczenia w pamięci (???, Spark?, Cassandra?). Jak są problemy ze skalowaniem i przechowywaniem danych w bazie, to liczy się w pamięci w aplikacjach. Ale nie wiem czego się tu używa.
7. Komunikacja pomiędzy aplikacjami (GraphQL, gRPC, ProtoBuf, kolejki np. Kafka, RabbitMQ). Kiedyś SOAP wyparło REST. Warto znać co jest nowego, bo może wyprze REST-a. I asynchroniczne.
8. Tematy z wysokopoziomowego projektowania aplikacji i wymagań biznesowych (DDD, Event Storming, CQRS). Przyda się przy pracy z analitykami, ale też przy przekładaniu wymagań biznesowych na projektowanie aplikacji.
9. Coś innego? Co teraz jest potrzebne lub modne?

Szczerze mówiąc bardziej kręci mnie pisanie samych aplikacji niż grzebanie w środowiskach, chmurach, DevOpsowanie itd. Ale biznes naciska, żeby programiści byli DevOpsami. Dlatego szukam innego tematu niż DevOps, ale coś poza samym kodem. Tylko żeby to przydatne było.

[m.....s]

@mk321: przejrzyj oferty pracy, popatrz co najczęściej się powtarza w opisie technologii i tego się naucz

[mk321]

@matwes: najczęściej Java i Spring. To już umiem xD
Reszta jak się pojawia, to jest mile widziane.

Właśnie nie wiem co z tego rzeczywiście jest przydatne. Kiedyś był hype na microserwisy, na NoSQL, na Sparka, na chmury. Ale po czasie to cichnie i jest używane tylko w miejscach gdzie rzeczywiście jest taka potrzeba, a nie na siłę.

[m.....s]

@mk321: jak na szybko teraz przejrzałem oferty to często powtarzają się Kubernetes, Docker, tematy devopsowe właśnie. Może trochę rzadziej chmury oraz komunikacja.

[mk321]

@matwes: no właśnie często są tematy devopsowe :/ Dla mnie to paranoja, że programista musi wchodzić w te tematy zamiast skupić się na pisaniu aplikacji.

I tak doszło do tego, że backendowy piszą frontend (fullstack), bo niektóre firmy przestały zatrudniać frontendowców. To teraz wrzućmy im jeszcze tematy devopsowe, żeby nie zatrudniać devopsów.

Nie da się wszystkiego dobrze nauczyć. Jak ktoś jest do wszystkiego, to jest do niczego. Chciałbym się w

[kriemann]

Niestety tyle tego jest, że człowiek sam nie wie, w co ręce włożyć. Stoję przed podobnym wyborem do Twojego, i stawiałbym tak jak kolega wyżej pisał - na devopsowe klimaty, Kubernetes + Docker.
Jeśli chodzi o samo programowanie, to warto zaznajomić się z GraphQL dla samego poznania jego możliwości, zalet i wad. Ja osobiście na swojej "to-learn" liście mam jeszcze poznanie trochę programowania reaktywnego (Spring WebFlux), poznanie innego frameworka i pisanie w

[m.....s]

no właśnie często są tematy devopsowe :/ Dla mnie to paranoja, że programista musi wchodzić w te tematy zamiast skupić się na pisaniu aplikacji.

@mk321: dla mnie to nic nowego. W mojej pierwszej firmie programiści zarządzali serwerami Linux na których stały aplikacje, bazy, a nawet sieciami i serwerami pocztowymi. A było to w latach 2011-2015.

[kriemann]

@mk321: @matwes: fakt, nie jest to raczej nic nowego. Ale zgadzam się z tym, że jest to trochę zrzucanie wszystkiego na głowę programisty, bo "on umie programować" i może lepiej skomponować/zautomatyzować procesy związane z devopsem. Tyle, że branża devopsowa jest już na tyle szeroka, że trochę to wygląda tak jak mk321 wyżej napisał - "Jak ktoś jest do wszystkiego, to jest do niczego".

[KwasowyProktolog10kJava]

@mk321: Jak chesz programista 15k czy tam 25k to niestety musisz znać wszystkiego po trochu. Wydaje mi się że tręd idzie w serverless i micro. Bazy danych to przeżytek za parę lat AI będzie samo optymalizować BD. A no i będzie trzeba spiąć z biznesem więc DDD + ES

[mk321]

@kriemann: GraphQL trochę poznałem i wyszło mi, że w Javie nikt tego nie używa.
W środowiskach Node.js czasem się pojawia, bo jest Apollo.
No i GraphQL ma trochę wad. Javowcy sobie głowy nie zwracają i piszą kolejne REST-owe endpointy.

Spring Reactor, WebFlux ciekawe, ale dla biznesu praktycznie żadnej wartości to nie przynosi. Zabawka dla programistów, prawie syntactic sugar. Nie mówię, że reaktywne programowanie, non-blocking i backpressure nie przynoszą korzyści biznesowi... Ale

[mk321]

@matwes: zarządzanie serwerami (poza jakimiś testowymi środowiskami) przez programistów to dla mnie patologia. Czy zwykły programista ma taką wiedzę o bezpieczeństwie, o systemie itd? Nie ma na to czasu. Może być zrobione co najwyżej "aby działało".
Od tego są administratorzy. Nie chciałbym pracować w takiej firmie gdzie ja miałbym to robić.

Kilkanaście lat temu może jeszcze się to sprawdzało. Było wszystkiego mniej, napisało się aplikację, potem nie było co robić

[mk321]

@KwasowyProktolog10kJava: wszystkiego po trochu znać może i tak. Ale w czymś trzeba się specjalizować.
Kojarzysz T-shaped skills?
Programista powinien specjalizować się w tworzeniu aplikacji i tym co najbliżej z tym związane.
Dlatego szukam obszaru w którym mógłbym się specjalizować. Jeśli wybiorę DevOps jako specjalizację (oczywiście poza programowaniem) to odrzucę specjalizowanie się we wszystkich innych obszarach.
Nie da się wszystkiego nauczyć. A na pewno nie naraz.
I nie chciałbym się specjalizować w DevOps jeśli

[mk321]

@KwasowyProktolog10kJava: jak serverless czyli np. Lambda to tym bardziej DevOpsowanie nie potrzebne, bo tylko konfiguracja chmury i wrzucenie wszystkiego na AWS.

[kriemann]

dla biznesu praktycznie żadnej wartości to nie przynosi. Zabawka dla programistów, prawie syntactic sugar.

Hm... czytales w ogole czym jest programowanie reaktywne? :) Albo czym sa w ogole rzeczy ktore wczesniej wymienilem? wydaje mi sie, ze niezupelnie wiesz o czym piszesz.
Jesli chcesz skupiac sie na tworzeniu samego kodu aplikacji i pisaniu ciagle XRepository, XService i XController, to jasne, Twoja postawa jest zrozumiala. Ale jesli chcesz sie faktycznie rozwijac, zastanow sie dobrze:

[kriemann]

Btw:

GraphQL trochę poznałem i wyszło mi, że w Javie nikt tego nie używa.

W środowiskach Node.js czasem się pojawia, bo jest Apollo. No i GraphQL ma trochę wad. Javowcy sobie głowy nie zwracają i piszą kolejne REST-owe endpointy.

Wyszlo Ci?
Javowcy sobie glowy nie zawracaja?

[leoha]

kolejki np. Kafka,

@mk321: kafka to nie kolejka, choć często jest używana jako taka.

[m.....s]

Jesli chcesz skupiac sie na tworzeniu samego kodu aplikacji i pisaniu ciagle XRepository, XService i XController, to jasne, Twoja postawa jest zrozumiala. Ale jesli chcesz sie faktycznie rozwijac, zastanow sie dobrze: czy 10-15 lat temu ludzie piszacy w J2EE mysleli w ogole o tym, ze te ich olbrzymie monolity za jakies 5 lat zdechna na rzecz Springa? Pewnie nie.

@kriemann: zdychanie Javy EE to główny powód dla którego od nowego roku

[o.....a]

no właśnie często są tematy devopsowe :/ Dla mnie to paranoja, że programista musi wchodzić w te tematy zamiast skupić się na pisaniu aplikacji.

@mk321: bo to dwa odrebne stanowiska przeciez...
Tego kto tak mysli to powinno sie mlodkiem po glowie bic...
Jeszcze tego brakowalo zeby jedna osoba pisala aplikacje, zarzadzala os, infrastruktura (sieci, servery), zarzadzala projektami, i debugowala np jbossa.
Ludziom sie w glowach p----------o.

[j.....t]

@mk321: @matwes: programowalem w Javie i szkoda czasu się uczyc po robocie jak ma się rodzinę i dzieci, teraz są takie trendy że z javowcow robią chłopców od wszystkiego xD jak masz 20-30 lat to możesz się bawić w takie cos, ale lepiej weź się wyspecjalizuj w jednej rzeczy typu kubernetes albo aws, zarobki są większe a i na rozmowach nie pytają Cię jak dziecka z algorytmów czy

[demonsthere]

@mk321: Definitywnie wiedza o dockerze i k8s. W cloud'zie często używany jest schemat "You build it You run in" i developer, który dostarcza aplikacje, ma ją dostarczyć w postaci kontenera/charta do k8s. Do tego debuggowanie działającej apki w docker/k8s wymaga podstawowych umiejętności z zakresu linux/unix.