Taski na poziomie juniora (Java)

Jako że przygotowuje się (metoda gospodarczą - dla nie wtajemniczonych - bez pomocy, sam jak palec) do załapania roboty jako Java delewele, mam do was ogromną prośbę która ułatwiła by mi obieranie dalszych kierunków nauki. Czy mogli byście na wpisywać w tym wątku taski jakie dostawaliście, dostajecie na stanowisku juniora, albo jakie zlecacie juniorom. Na tyle szczegółowo ile tajemnica zawodowa wam pozwala. Oczywiście nie tylko z zakresu czystej Javy ale całego ekosystemu. Z góry dzięki.

Ile firm tyle tasków. Nie wyciągniesz z tego żadnej zależności.

uczenie sie javy od podstaw w 2023

jesteś masochistą

Z reguły pierwsze zderzenie to poprawa bugów, bo tak najszybciej poznasz projekt. Potem proste rzeczy typu nowa kolumna.

Kiedyś można się było ostrzelać w projektach opensurosowych, dawać bugfixy itd...
Ale "jakoś" odczuwam że bardzo urosły bariery, aby ktos z ulicy zasłużył na przyjęty pull request (a może się ja wypaliłem)

Naucz się JDK, ale SOLIDNIE. Znajomość wątków, egzekutorów, jak działają kolekcje (pod spodem), streamy... — developeronthego 6 minut temu

Popieram.

szmeterling napisał(a):

Czy mogli byście na wpisywać w tym wątku taski jakie dostawaliście, dostajecie na stanowisku juniora, albo jakie zlecacie juniorom.

Jak ja zaczynałem pracę to dostałem w Wasko legacy projekt gdzie ostatni developer uciekł pół roku wcześniej. Więc były to wszystkie możliwe taski jakie mogą być w legacy. Pomiesiącu czy 3 miesiącach przyszedł nowy junior i on pisał niemożliwy do wykonania pomysł, ale akurat była na to dotacja z unii.

heretic napisał(a):

uczenie sie javy od podstaw w 2023

jesteś masochistą

Racja tyle innych pieknych języków jest, tylko że w Kotlinie i Scali mniej ofert pracy :(

@AnyKtokolwiek: Od tego teraz mają kabelki good-first-issue. Tam zazwyczaj są bardziej pobłażliwi. Najwięcej tego jest przy Haktoberfest.

@szmeterling: U mnie pierwszy task to napisanie aplikacji, która będzie synchronizować się w dwie strony z 3 różnymi ERP'ami (Java, android, sqlite, MySQL, Postgres, mssql, rabbitmq). Miałem na to 3 miesiące stażu, prawie mi się udało XD

Przeglądając forum zastanawiam się czy naprawdę jest tak ciężko wejść do IT. Jedni piszą że zero odzewu, inni jakieś zestawienia, statystyki że ofert wcale nie jest za wiele mniej, inni że aplikujących są masy (zwłaszcza do javy). Dla kogoś z zewnątrz wniosek jest jeden: nie wiadomo jak jest.
Obrałem sobie standardową drogę że napiszę coś do portfolio. Ale tak od A do Z z deploymentem, serwer jenkins, testy CI/CD, monitoring, logi. I trafiam na wątek gdzie pół ludu pisze że porfolio to strata czasu, nikt do niego nie zagląda. No i znowu wał.
Pytam o taski. Kolejny wał: nie ma żadnych zależności.
Więc zapytam inaczej. Podaję to co chcę się uczyć. Dajcie feedback co o tym sądzicie:

1. SpringBoot czy Spring?
2. Mapstruck, Harmcrest, Jackson, JsonPath,
3. MySQL czy Postgres?
4. JPA (Czy zagłębiać się w Hibernata czy znajomość samego interfejsu JPA wystarczy?)
5. Obsługa linuxa - bash shell
6. Jenkins czy Github Actions?
7. Docker
8. Zookeper, Haproxy, LmaxDisruptor, RabbitMQ (czy Kafka?), grpc

Żeby nie było że nic z tego nie umię. Springa coś tam znam, napisał bym na pewno coś na poziomie TODO z użyciem bibliotek podanch w pkt 2, MySQL i Rest, a nawet bym poradził jakoś napisać w DDD jak by sie nadawało ze springiem w roli adaptera.

@heretic: Zacząłem uczyć się javy bo stwierdziłem że nie będę pół roku rozkminiał jaki język wybrać jako pierwszy, Nie ukrywam że chętnie zaczął bym się uczyć kolejnego np, Clojure (nie pytajcie czemu). Z kolei wiem, że aby znaleźć prędzej robotę to lepiej by było JS jako drugi- chyba że się mylę. ( ciężko by było się uczyć javy nie od podstaw :p. Jakaś alternatywa dla javy?)
@ledi12: Skoro nie idzie wyciągnąć zależności to nie dopytuję. Czyli jednym słowem co? Uczyć się pod rekrutację i olać rozkminy?

Post przydługi..sory. Najbardziej wku... mnie to że już chciał bym robić. Wiem że dał bym sobie rady z niebanalnymi problemami bo po prostu uwielbiam rozwiązywać problemy. A tu zamiast roboty to trza rozkminiać jak się do niej dostać...

Do portfolio moze nikt nie zaglada (niekoniecznie), ale robienie projektow rozwija

Ponad 10 lat temu jako świeżak w firmie moim pierwszym zadaniem było ukrycie checkboxa na UI. Potem głównie naprawianie prostych błędów w aplikacji. Jak pokazałem że ogarniam i moje zmiany nie wywalają produkcji zacząłem dostawać pierwsze poważniejsze taski jak integracja między usługami, tworzenie UI + backend w C#, jakieś widoczki i procedurki SQL do raportów/analiz.

Zamiast tracić czas na rozmyślanie jakie będziesz dostawał taski w pierwszej robocie, skup się na nauce. Zacznij pisać normalne projekty, zbieraj wymagania, analizuj, projektuj, próbuj różnych bibliotek, wzorców, ogólnie baw się. Robienie swoich projektów i samodzielne rozwiązywanie problemów to najlepszy sposób na naukę.

szmeterling napisał(a):

Więc zapytam inaczej. Podaję to co chcę się uczyć. Dajcie feedback co o tym sądzicie:

1. SpringBoot czy Spring?

Spring Boot, jeśli będziesz kiedykolwiek musiał tykać "starego" Springa to się później douczysz.

3. Mapstruck, Harmcrest, Jackson, JsonPath,

To są biblioteki (z literówkami co prawda), nauczysz się jak będziesz potrzebował (np. JsonPath do testów API).

4. MySQL czy Postgres?

Jeśli dopiero uczysz się baz danych to jeden kij, ale lepiej Postgres przyszłościowo.

6. JPA (Czy zagłębiać się w Hibernata czy znajomość samego interfejsu JPA wystarczy?)

JPA styknie, chyba że będziesz kiedyś robił duże crudy to wtedy przyda się wiedza jak to działa (albo nie działa) pod spodem.

7. Obsługa linuxa - bash shell

Tak.

9. Jenkins czy Github Actions?

Jenkins najpierw wyklikując, a potem z Jenkinsfile. Jak to ogarniesz to GH Actions będzie formalnością.

11. Docker

Tak, bez tego dziś ani rusz. I trochę k8s by się przydało, np. z minikube.

12. Zookeper, Haproxy, LmaxDisruptor, RabbitMQ (czy Kafka?), grpc

Jakiś message broker typu Kafka - w sumie tak (to bardziej pod mikroserwisy).

Tak może dopiszę czego niektórzy nie ogarniają i rzuca się to w oczy:

• pisanie testów na sensownym poziomie (i to nie tylko unity)
• debugowanie aplikacji (trochę wynika z nieznajomości tego co siedzi pod spodem)
• generalna organizacja kodu
• build toole i CI

Z tym że na pewno nie [CIACH!] się z Jenkinsem jeśli mi za to nikt nie płaci, to narusza moją godność osobistą. Zrób sobie pipeline w github actions, 100 razy mniej [CIACH!] a robi to samo.

Pierwsze zadnaie - postaw środowisko
Drugie zadanie - jest taki bug, DUP-123 weź młody sprawdź i popraw. Na ogół jakiś bug o niskim priorytecie, złosozny pól roku temu, który albo nie jest bugiem tylko user źle kilka albo każdy nowy próbuje go naprawić i nikomu się nie udaje. Dopiero potem dostajesz drugiego taska DUP-124, w którym masz szansę zrobić fixa.

AnyKtokolwiek napisał(a):

Kiedyś można się było ostrzelać w projektach opensurosowych, dawać bugfixy itd...
Ale "jakoś" odczuwam że bardzo urosły bariery, aby ktos z ulicy zasłużył na przyjęty pull request (a może się ja wypaliłem)

Naucz się JDK, ale SOLIDNIE. Znajomość wątków, egzekutorów, jak działają kolekcje (pod spodem), streamy... — developeronthego 6 minut temu

Popieram.

Imho kompletna bzdura.

Uczenie się nowych rzeczy poprzez wrzucanie od razu na najgłębszą wodę to antywzorzec nauczania.
Równie efektywne byłoby gdyby kolega na start zaczął się uczyć asemblera albo chociaż c i ręcznego zarządzania pamięcią.

Imho takimi poradami, świadomie bądź nie, robicie ludziom krzywdę.
Juniorowi nie jest potrzebna wiedza ani o tym jak działają kolekcje pod spodem (ba, ona nie jest potrzebna często i później) ani zaawansowane zagadnienia dotyczące wielowątkowości bo zwyczajnie nikt nie wpuści do tak skomplikowanej części aplikacji takiego juniora z plakietką "rób co chcesz"...

Nie ma typowo juniorskich tasków. Junior zazwyczaj po prostu będzie potrzebował więcej pomocy, więcej dopytać.

1. SpringBoot czy Spring? - SpringBoot, jak trafisz w 2023 na appkę bez Boota to współczuję
2. Mapstruck, Harmcrest, Jackson, JsonPath, Mapstruct to syf, lepiej nie tykać. Jackson must have, a reszta whatever. Jak będziesz potrzebował to się douczysz.
3. MySQL czy Postgres? musisz znać SQL, a na jakiej bazie to nie ma znaczenia
4. JPA (Czy zagłębiać się w Hibernata czy znajomość samego interfejsu JPA wystarczy?) Hibernate w praktyce, trzeba ogarnąć jak to działa bo sama specyfikacja JPA nic Ci nie da.
5. Obsługa linuxa - bash shell dobrze podstawy podstaw znać, ale da się bez tego żyć.
6. Jenkins czy Github Actions? spotkałem się z wykorzystaniem obu i imo nie warto się uczyć, jak będzie potrzebne to się nauczysz w praktyce
7. Docker must have
8. Zookeper, Haproxy, LmaxDisruptor, RabbitMQ (czy Kafka?), grpc raczej nic z tych rzeczy. Może RabbitMQ/Kafka warto poznać na jakimś podstawowym poziomie, ale raczej klasycznie - jak będziesz potrzebować to się nauczysz.

Ogólnie jako junior dużo uczysz się w pracy. Skille jakie są potrzebne do pierwszej pracy to skille pozwalające na przejście rozmowy rekrutacyjnej, a to przede wszystkim skille miękkie i solidna znajomość javy, springa, sqla, testów.

@Grzyboo: pkt 8 wypisałem co mnie interesuje, dodał bym jeszcze kilka rzeczy ale nie chciałem przesadzać. Jedna rzecz mnie zastanawia. Skoro podstawa dla juniora to Java, spring, testy, ( umiejętności miękkie mam - skoro ludzie chcą ze mną robić to tak dedukuję), a aplikujących jest ponoć masa, to co procentuje, dodatkowe umiejętności, dobre portfolio, profesjonalne CV, gadka szmatką z hr-em, rozkminy na rozmowie technicznej ?
@RequiredNickname: twój wpis daje mi do myślenia. Od zawsze miałem tak że jak coś robiłem to musiałem podrążyć "a dlaczego tak, a nie inaczej". Wydaje się że junior ma znać procedurę tworzenia kodu w szerokim zakresie zastosowań, a nie jego rozumienie od podszewki. Dlatego też nauka się u mnie przeciąga, bo rozkminiam i doc czytam rekursywnie ( return known/unknown). Z jednej strony niby fajnie bo junior ma wiedzieć co, gdzie i kiedy ale nie musi wiedzieć dlaczego. Jednym słowem nawpierdzielac się procedur i chwalić przed rekruterem. Specyficzne... Dla mnie osobiście największe wrażenie robi efekt pracy. Pokazuje umiejętności, sposób myślenia, zaangażowanie... U mnie w robocie jak ktoś coś zrobi dobrze to pochwałę i zapamiętam ( ooo... ten ma łeb), a jak jest problem którego nikt nie umi rozwiązać, albo kiedy można ułatwić ludziom robote to się zapalam ( najczęściej stoję i patrze jak mumia). A jak wszystko dobrze idzie to gadka szmatka. To że portfolio nie jest pierwszym najistotniejszym wskaźnikiem umiejętności( i miękkich w drugiej kolejnosci) jest dla mnie zdumiewające. Z czego to wynika?

• patrząc na portfolio nie zweryfikujesz czy kandydat to napisał, rozmowa techniczna i tak musi być żeby zweryfikowac że kandydat wie co się tam dzieje
• przeglądanie tego porządnie zajmuje dużo czasu i zazwyczaj nie jest to kod jakości produkcyjnej (powiedziałbym że <10% ma readme które opisuje co to w ogóle jest i na cholerę to komu), po przeglądnięciu 20 takich projektów bardzo przestanie ci się chcieć patrzeć na githuba
• trudno porównywać to wszystko pomiędzy kandydatami
• prawie żaden zawodowy dev nie ma portfolio więc głupio wymagać tego od kandydatów

z takich fajnych przyszłościowych skilli dorzuciłbym observability logging, tracing, metrics itd. Grafana cloud ma spory free tier.(możesz uruchamiać lokalnie ale IMO szkoda czasu i zachodu). Ew zadanie z gwiazdka przeczytałbym co to opentelemtry.

Ciekawi mnie jak można cokolwiek uzyskać znjąc TYLKO SpringBoot a z hamulcem ręcznym na Spring.
Stochastyczne stawianie adnotacji az któraś zadziała ?

Takie odróznienie dla mnie swiadczy o niezrozumieniu co-jest-co
Bliźnięta bracia, którego bardziej historia ceni mówimy – partia, a w domyśle – Lenin

Ja rozumiem naukę Spring Boota w sensie rezygnacji z ręcznej konfiguracji beanów i xml-a. Absolutnie nie jako rezygnacja ze zrozumienia co się dzieje pod daną adnotacją.
Nie kopałem jeszcze w Springu za bardzo, czy używa on gdzieś java.lang.invoke?
Czy słyszeliście o takim frameworku https://activej.io/ ? Używał ktoś - wydaje się ciekawy.

szmeterling napisał(a):

Więc zapytam inaczej. Podaję to co chcę się uczyć. Dajcie feedback co o tym sądzicie:

1. SpringBoot czy Spring?

Jeden pies, ucz się Springboot + ta konfiguracja adnotacjami. Definicje endpointów, wstrzykiwanie zależności.

2. Mapstruck, Harmcrest, Jackson, JsonPath,

Różne biblioteki do różnych celów. Jacksona trzeba umieć odpalić.

3. MySQL czy Postgres?

W "Javovym MIrie" Postgres jest zdecydowanie bardziej popularny. W praktyce nie ma znaczenia, bo przeciętny programista Java w przeciętnym projekcie nawet nie wącha miejsc, gdzie różnice mogłyby mieć znaczenie.

4. JPA (Czy zagłębiać się w Hibernata czy znajomość samego interfejsu JPA wystarczy?)

Ogarnij JPA na przykładzie hibernate, ale bez zagłębiania się w detale.

5. Obsługa linuxa - bash shell

Meh... nie ma sensu pod tę pracę. Jak coś będzie potrzebne, to ogarniaj na szybko. Chyba, że chcesz iść w DevOps i np. budowanie CI/CD, to tak, będzie potrzebne.

6. Jenkins czy Github Actions?

Oba. Albo inaczej - Jenkins + coś konfigurowanego kodem.

7. Docker

No raczej. Oswoisz się ogarniając te bazy i kolejki. Polecam obejrzeć

8. Zookeper, Haproxy, LmaxDisruptor, RabbitMQ (czy Kafka?), grpc

W korpo świecie ogarnij podstawy jakichś kolejek i topic'ów. Czyli podłącz się, wyślij wiadomość, odbierz wiadomość, potwierdź otrzymanie wiadomości + rozróżniaj kolejkę od topic'u Pozostałe zagadnienia nie dla Java Juniora (raczej jakiś DevOps).

Post przydługi..sory. Najbardziej wku... mnie to że już chciał bym robić. Wiem że dał bym sobie rady z niebanalnymi problemami bo po prostu uwielbiam rozwiązywać problemy. A tu zamiast roboty to trza rozkminiać jak się do niej dostać...

E... programowanie, to w 99% rozwiązywanie banalnych problemów, tylko ten pozostały 1% bywa niebanalny ;)
Patrząc na listę, to idziesz dość szeroko, ale to dobrze, warto mieć jakąś przewagę nad konkurencją. Prawdopodobnie przeoczyłeś Git'a. Niby banał, ale warto te podstawowe rzeczy wiedzieć. Proponuję też zastanowienie się nad absolutnie elementarnym opanowaniem czegoś frontendowego. Bez zagłębiania się w detale, tak żebyś był w stanie zrobić jakikolwiek UI do swojego potencjalnego projektu. backendowego.

Zazwyczaj wygląda to tak, że dostajesz jako nowy (nieważne czy junior czy senior) w pierwszych tygodniach/miesiącach proste taski, z czasem coraz trudniejsze. Junior na początku nie dostanie np. całego nowego featura.

Przykładowe taski:

1. dodaj jakiś input w danym miejscu, który działa tak i tak.
2. popraw dany bug (zlokalizowany)

Ogólnie raczej spotykam się, że te taski po prostu są male w stylu, że wystarczy dodać jeden test i jedną/dwie funkcje w danych miejscach. Co może być problematyczne dla juniora to zlokalizowanie gdzie to wstawić, jak itd. bo junior raczej nie miał udziału w dużych projektach

Ja jestem świeżo upieczonym juniorem i moje taski wyglądały mniej więcej tak:

Pierwszy tydzień

• uruchom kod lokalnie
• dodaj tekst do UI
• dodaj triggera do bazy

Drugi tydzień

• napraw buga
• dodaj push notyfikacje

Co to ma być?! Odpisuje komuś, a tu "zbyt wiele prób, spróbuj za chwilę" i tak od wczoraj. Jak to ominąć? Kto to projektował? Ogarnij się projektancie ;). A tak na poważnie o co z tym chodzi?

Pytanko. Zdarza wam się przez tydzień pisać kod bez uruchomienia kompilatora? Nie jest to dla mnie problem ale nie chciał bym nabrać złych nawyków jeśli nie powinno się tak robić (pewnie w pracy na pewno nie bo taski i commity, ale np przy własnych projektach).

Jaki jest sens w pisaniu kodu bez sprawdzania czy choćby się kompiluje? (Już nie mówiąc o poprawności działania).

Skoro nie odpalałeś kompilatora to znaczy, że nie puszczałeś/pisałeś testów. Podręcznikowa definicja złego nawyku.

szmeterling napisał(a):

Pytanko. Zdarza wam się przez tydzień pisać kod bez uruchomienia kompilatora? Nie jest to dla mnie problem ale nie chciał bym nabrać złych nawyków jeśli nie powinno się tak robić (pewnie w pracy na pewno nie bo taski i commity, ale np przy własnych projektach).

Pomijając że to prawdopodobnie bait... nie rozumiem. Przez tydzień piszesz kod i go nawet nie uruchamiasz? Chyba że masz jakieś dziwne rozumienie kompilatora, albo piszesz w języku skryptowym gdzie go nie ma :P

@szmeterling: Kiedyś tak robiłem, potem zacząłem pisać testy.To bardzo zły nawyk bo wydaje ci się że twoja logika jest perfekcyjna, ale jest taka tylko do pierwszego uruchomienia, potem w kazdym takim nietrywialnym kodzie powyżej 500 linijek jest kolejny tydzień debugowania. Dużo łatwiej testować małe fragmenty logiki automatycznie niż recznie całego molocha po tygodniu pracy.

No właśnie pisząc ten procesor adnotacji ( w oceny i recenzje) taki nawyk mi się wykreował ( wkurzało mnie ciągłe clean, instal procesora i clean , compile apki na której go uruchamiałem). Co do testów procesora zacząłem bez ( ciężka sprawa - albo specjalne biblioteki które wykminiłem później, albo compiler API i pisanie kilkuset linijek z podmianą implementacji javacompiler). W momencie kiedy wydzieliłem procesor do osobnego projektu (sundew na githubie - link w oceny i recenzje - z komóry pisze), ogarnąłem poma to uruchomiłem kompilator dopiero dzisiaj. No i po zmianie == na != w warunku executora i dodaniu + do indexu substring w logice indexowania pliku properties ruszyło i spełniło wszystkie wymagania. Napięcie w momencie odpalenia kompilatora... @kelog daj se siana z tym baitem.
Sprostowanie. Zdarzało mi się puszczać kompilator samego procesora czy się kompiluje ale dopiero dzisiaj sprawdziłem go na osobnej apce.