JavaEE - jak to właściwie wygląda?

Cześć,
Od jakiegoś pół roku programuję w javie[na studiach i dla siebie, bo polubiłem]. Naturalnym krokiem wydało mi się więc przejście do jej webowej części. No więc wziąłem książke Rychlickiego, Java EE. Programowanie aplikacji WWW. - i tutaj zaczyna się koszmar, jak zobaczyłem całe te konfiguracje xmlów, xhtmlów, htmlów to mnie od tego momentalnie odrzuciło.

Zastanawiam się jak to wygląda w pracy, programista JEE zajmuje się tylko logiką aplikacji, nie musi się bawić w konfigurację xmlów, etc czy to również należy do jego obowiązków? A jeżeli już to robi, to tak jak tutaj - ręcznie, czy może w ucywilizowany sposób, pokroju jakiegoś GUI Buildera do desktopu i obsługi zdarzeń?

Nie no, pracuję w Javie EE od ponad roku i nie jest tak źle.

Jeżeli chodzi o konfigurację projektu, to rzeczywiście na początku jest tego dużo, np. postawienie projektu w Mavenie (pom.xml) czy kilka innych konfiguracji w web.xml czy persistence.xml, ale to się robi raz na początku i tyle. Oczywiście trzeba wiedzieć jak to działa, jak ustala się role użytkowników systemu, dostępy, połączenie z BD, itd.

Jeżeli chodzi o fxml to raczej się z nim pracuje i trzeba popisać (IntelliJ pomaga auto uzupełnianiem i nie miałem z tym nigdy większych problemów).
Ale nikt nie powinien Ci kazać tego stylować, wystarczy, że zbudujesz zarys strony, a jakiś inny koleś od weba ogarnie CSSy.
No i nie spotkałem się nigdy z żadnym Builderem jak w JavieFX czy Androidzie.

Ale kodzenia w Javie jest dużo więcej :)

EDIT:

no i mega polecam ten tutorial

A jak startowałes to jaką miałeś wiedzę? Głównie chodzi mi o to, czy jest realna szansa dostać się na takie stanowisko ze znajomością tylko i wyłącznie czystej Javy. Rozwiązywalem sporo takich przykładowych testów z rozmów o pracę, nie mając z nimi większych problemów, ale Java EE wchodzi mi topornie.

Programista JEE robi to samo co programista Springa, czyli najczęsciej rozwija backendy tzn. encja na twarz i pchasz. Polecam serwer aplikacyjny Payara: kwartalnie wydawany GlassFish. Często zdarza się zrobienie jakiegoś GUI w JSF czy Angularze. Jako IDE IntelliJ Ultimate lub NetBeans (jak JSF to tylko z NetBeans).

Czym w ogólnym rozumowaniu tej pracy się zajmuje to wiem, bardziej chodziło właśnie o to ile pracy jest z xmlem i tego typu rzeczami a ile z kodem Javy

Są projekty, które mają mapowanie w XML np. JPA. XML warto znać. W końcu XSD to podstawa do SOAP. Ostatnio totalnie nie używam XML tylko JSON. Nie spotkałem się, aby w nowych projektach ludzie używali dużo XML. Miejsce gdzie XML wciąż jest silny to myślę, że szyny integracyjne (ESB). Nauczysz się w robocie.

To tak jeszcze ku podsumowaniu, co poza znajomością JavySE, warto znać, żeby załapać się na pierwszą pracę na stanowisku Juniora JavySE, tudzież na pierwszą pracę ale po odbytym stażu[w jakiejś Nokii dajmy na to]

Programuję w JavaEE od 2000/ 2001 roku i pamiętam jeszcze pierwsze Jbossy (EJBoss) i Websphere.

Obecnie nie musisz tak jak kiedyś grzebać się XMLach. Bo prawie wszystko da się załatwić przez annotację i konwencję...

Niestety z programowaniem ma to nadal niewiele wspólnego. (Coś jak programowanie HTML). Po prostu w konfigurujesz w tych miejscach gdzie Ci engine (JavaEE, albo Spring) pozwala i na każdym kroku musisz uważać, żeby nie wpaść w jakąś pułapkę. Dzięki "aspektom" nie działa to już jak normalna Java. ( W normalnej Java działa new, a jak metoda robi return 2+2; to nie zwróci 7. )

Tak - nienawidzę tych technologii od czasu jak poznałem alternatywy :-) (czyli dopiero od kilku lat).

Z drugiej strony jak szukasz pracy w Javie - nie masz obecnie wyjścia - to mainstream. Mało kto wie, ze można inaczej. Ja też nadal robię projekty w Springu i JavaEE, bo mi za to płacą (wystarczy prysznic w pracy i nie jeść nic ciężkostrawnego przed siądnieciem do kodu w Springu - i da sie jakoś ten dzień jakoś przeżyć).

A które to lepsze alternatywy, jeżeli można wiedzieć? Domniemam że chodzi o Scala i Akka.

Lepsze w sensie normalniejsze.
Scala - Akka - HTTP
Java - Ratpack

i te poniżej, którymi dopiero się bawiłem na poziomie hello world, ale wyglądają dobrze i mogą być hitami
Java - Spring Web Functional (nie mylić ze Springiem)
Kotlin - Ktor

Btw. to tylko biblioteki do robienia HTTP web. Czyli tylko jednej z częśći zawartych w JavaEE. (do całej reszty tez są biblioteki).

A takim pełnym odpowiednikiem całej platformy jest np. Java - Lagom. (ale tam też jest trochę magii, (dużo mniej niż w JavaEE ale jest).
(Niestety chłopaki z Lighbend całkie się natrudzili, żeby to stworzyć, ale nie umieją tego sprzedać. Byłem w tym roku na tak nudnej prezentacji Lagom, że gość z miejsca powinien dostać kontrakt od jakiejś organizacji antyalkoholowej. Wystarczyłoby mu kazać zachwalać piwo -> szybko by spożycie spadło.)

Nie demonizujmy, mimo wszystko 90% kodu aplikacji to jest "normalny kod", praktycznie niezależny od tego czy to desktopowa aplikacja w Javie SE, czy to działa pod JEE czy pod Springiem czy jeszcze czymś innym. Bo w zasadzie logika biznesowa powinna być oderwana od infrastruktury aplikacji, a już szczególnie z punktu widzenia Juniora to bez róznicy, bo nikt przy zdrowych zmysłach nie każe ci konfigurować JPA czy robić fine-tuningu serwera aplikacyjnego.

@jarekr000000: ale Ty ... nieprawdę mówisz ;)
Programuję w Javie w Springu i prawie w ogóle nic nie konfiguruje, klepię kod biznesowy. Może robiłes w jakis g technologiach, ale Spring jak już się konfiguruje to na początku a później sama aplikacja

W takim razie do CV mogę śmiało wpisywać projekty, w których zrobiłem pełnoprawną aplikację w Swingu, z testami, ze stosowaniem się do clean code, etc i będzie to warte uwagi?

O, skoro panowie są obeznani, zapytam jeszcze o jedno. Wszędzie czytam o tym mitycznym wręcz "utrzymywaniu kodu" ale nigdzie nie znalazłem informacji na czym to właściwie polega. Mógłby ktoś wyjaśnić?

Tenonymous napisał(a):

O, skoro panowie są obeznani, zapytam jeszcze o jedno. Wszędzie czytam o tym mitycznym wręcz "utrzymywaniu kodu" ale nigdzie nie znalazłem informacji na czym to właściwie polega. Mógłby ktoś wyjaśnić?

Masz duży system którego nie pisałeś i do którego dokumentacja jest zwykle słaba i masz upewnić się że nadal działa jak się podbije libki, naprawiać jakieś stare bugi które po wielu latach wyszły, dopisywać jakieś małe ficzery. Zero rozwoju.

Tenonymous napisał(a):

O, skoro panowie są obeznani, zapytam jeszcze o jedno. Wszędzie czytam o tym mitycznym wręcz "utrzymywaniu kodu" ale nigdzie nie znalazłem informacji na czym to właściwie polega. Mógłby ktoś wyjaśnić?

"Utrzymywanie kodu" polega na tym, że przychodzisz do firmy, która rozwija projekt, który istnieje np. od 15 lat (może też istnieć miesiąc) i Twoim zadaniem jest wdrożenie się w niego i rozwijanie go dalej. Tzn. dodawanie nowych funkcjonalności, naprawianie błędów (nie tylko swoich), pisanie testów i tworzenie dokumentacji. Czasami dochodzi do tego też usprawnianie instrastruktury lub procesu developmentu. Kod należy pisać tak, aby był przejrzysty, jasny, czytelny, dobrze obtestowany i miał dokumentację. Robi się to po to, aby zarówno Ty, jak i inne osoby w zespole mogły bez rzucania przekleństwami zrozumieć to, co napisałeś i wprowadzać tam zmiany, jeśli zajdzie taka potrzeba nawet bez konsultacji z Tobą, bo możesz np. w międzyczasie zmienić firmę i nie będzie jak się Ciebie o coś zapytać za parę lat. Nie ma tutaj reguły. Możesz trafić zarówno na dobry projekt, jak i słaby.

Są jakieś firmy, warte polecenia, powiedzmy z Wrocławia/Krakowa, w których jest pewna gwarancja, że albo trafi się na dobry kod do utrzymywania albo będzie pisać nowy projekt? Czy to raczej loteria?

Tenonymous napisał(a):

Cześć,
Od jakiegoś pół roku programuję w javie[na studiach i dla siebie, bo polubiłem]. Naturalnym krokiem wydało mi się więc przejście do jej webowej części. No więc wziąłem książke Rychlickiego, Java EE. Programowanie aplikacji WWW. - i tutaj zaczyna się koszmar, jak zobaczyłem całe te konfiguracje xmlów, xhtmlów, htmlów to mnie od tego momentalnie odrzuciło.

Zastanawiam się jak to wygląda w pracy, programista JEE zajmuje się tylko logiką aplikacji, nie musi się bawić w konfigurację xmlów, etc czy to również należy do jego obowiązków? A jeżeli już to robi, to tak jak tutaj - ręcznie, czy może w ucywilizowany sposób, pokroju jakiegoś GUI Buildera do desktopu i obsługi zdarzeń?

Uczenie się na własną rękę JEE to masochizm. Weź się za coś lżejszego i przyjemniejszego.
Grzebania w XMLach nauczysz się jak przyjdzie taka konieczność, z czytania książek i tak niewiele wyniknie.

Wy ludzie uczycie się JEE 5 że macie tyle XMLi czy po prostu jesteście niekompetentni i przez lata ignorowaliście zmiany?

Z tego co znajomi piszą to jeżeli chodzi o JEE to głównie utrzymanie starych aplikacji == XML. Sam w pierwszej pracy zostałem wrzucony do aplikacji w które właśnie było JEE. Szczerze mówiąc wyglądało to tragicznie. Programowanie w Javie właściwie proceduralne. Metody po 2k lini, syf w kodzie, maven który nie działał. Wielokrotnie includowane te same biblioteki przez /lib i przez mavena jednocześnie, dziesiątki lini kodu zakomentowanych, puste pętle które sie były w kodzie z d**y, zero testów, moduł springowy który był pisany przez niewiadomi kogo (ten sam bean definiowany w java config i xml a później wpierdzielony qualifier tylko po to zeby nie poleciało bean ambiguous i pomyśleć ze taka osoba zarabiała po 10k + jako senior wtf, może kiedyś będzie warto opisać tą Krakowską historie na mikro blogu). Na szczęście 3 miechy wytrzymałem i uciekłem do lepszej firmy z bardzo dobrą jakością kodu, ogarniętymi ludźmi i spełniam sie jako programista springa ;)