Java fejlesztő ismeretek (2020)

Python nem annyira ismeretlen a tesztelésben és automatizálásban (pl robot framework, ansible). Ruby már tényleg ritkaság.

Ami egy ideig fellángolt az a Go, de a mi ügyfelünknél inkább a Go-ban megírt cuccok Java-ra átírása megy.

Androidra Java és Kotlin az officiantos nyelv, és sok sok alkalmazást fejlesztenek. Tehát érdemes megismerkedni vele. Persze nem annyira kötelező, mint egy IDEA vagy egy maven.

A react se sokkal életszerűbb szerintem, nekem rendszeresen az az érzésem a beszélgetések után, hogy a multis környezetben, 3 fő feletti csapatban dolgozók mindegyike utálja a fullstack gondolatmenetet, főleg ezt a devops+natívmobil+backend+htmlfrontend+sósborszesz+... halmozást. De persze ahogy lentebb írtam, jó az unalom ellen, kiválóan mutat egy laikus HR-es számára, mert mindig lesz egy csapat, ahova besuvaszthat.

Sokkal kisebbek a hullámok, de azért van mit tanulni. Ami meg túléli az első pár évet és megold valamilyen nyitott problémát, az általában megmarad.

Egyébként én '11-ben kezdtem kiscsicskaként, akkoriban a következő volt a menő backend oldalon:

- 6os java, valamilyen dinoszaurusz "app serverben" futtatva (pl. glassfish, weblogic)

- Java EE

- SOAP webservice XML üzenetekkel

- relációs adatbázis

- on-premise működés, esetleg VM -ekkel

Azóta

- a java maradt, csak 6-ból 15 lett :)

- a JavaEE kapott egy nem retúr jegyet a Spring(Boot) -tól, ez ma már a standard runtime üzleti környezetben is

- frontendi rendszerek nyomására erősen elmozdultunk JSON irányba, az XML ma már elavultnak számít, és eközben a JSON toolingja is sokat fejlődött

- relációs adatbázisok mellett elszaporodott a memcached/redis/mongodb használat

- onprem/vm működésből konténerizáció lett, meg cloud, kubernetes

Ma már a kritikus infrastruktúrákat leszámítva (energia, egészségügy, bank, biztosítás) szinte mindenhol felhőbe költöznek a céges IT rendszerek, szóval az eddigi nem kevés tudomány mellé fel kell venni az aws/azure tudást (így első körben), a k8s viszont onprem és cloudban is menőnek számít, úgyhogy azt is. És ezek nem játékszerek, amiket 2-3 óra alatt masterelni lehet. Például a beanstalk hiába generál és tart üzemben ec2 VM-eket, hiába értesz a VM-ekhez, a beanstalk sajátságaihoz nem fogsz érteni, csak ba szoptál vele egy kicsit.

Vagy hiába értesz a hálózatokhoz, ha VPC peeringet kell csinálnod két idegen aws account egy-egy privát hálózata között, akkor tudni kell hozzá a folyamatot, és akkor sem fog elsőre sikerülni, ha tudod, hogy pl. mi az a CIDR.

Backend oldalon sokkal lassabb a tempó, okát nem igazán tudom, és én is rühellem, hogy mindig van 3 új framework, ami menő, hasonló mint amikor nosql-t akarnak használni emberek mindenre, stb., főleg azok, akik nem kellett hogy évekig support-oljanak valamit. Amint sor kerül egy ilyen tapasztalásra, rögtön egyenesebbek a gondolatok, kevésbé fontos, hogy menő sablonkezelés legyen a frontend-ben, és rögtön egyértelműbb, hogy ami bevált, azzal dolgozz. Szerintem nagyon sok esetben egyszerűen nem is kerül lekövetésre, hogy mennyi volt a tanulási idő egy új eszköznél, és hogy vajon tényleg volt-e valós spórolás, gyorsabb-e az új munkaeszköz annyival, mint a régi, vagy csak nem unalmas, és kihívás. Előbbiből van a fizetés, utóbbi meg sok programozó személyes célja, de nem munkaköre / feladata.

Persze arra is kíváncsi lennék mik azok a backend technológiák, amikre ráférne az újragondolás (lásd még nosql jóra jól használva tényleg kiváló ötlet, ...).

Én is kiváncsi lennék, hogy hogy jön a Javához, de talán úgy, hogy ha Java a backend, akkor eléggé adja magát, hogy Angular legyen a webes UI. Javához nincsen még mainstream Blazor-szerű teljesen Javában fejleszthető Webes famework, tehát muszáj valami kliens oldali JS-t írni. Akkor meg már miért ne Angulározzunk?

Egyébként van valami olyan eszköz hozzá, amivel API definíció alapján lehet Java és TypeScript kódot generálni, amivel típushelyesen lehet hívogatni egy szerver oldali API-t TypeScript-ből, és neadjisten callback-et is támogat?

Fúj :)