Java 9 újdonságai – 6. rész

Process API újítások

Előzmények

A Java korai verzióiban elég nehézkes volt új folyamatot indítani. Ehhez csak a Runtime.getRuntime().exec() metódus állt rendelkezésünkre. 2004-ben, a Java 5 megjelenésével ez megváltozott, innentől kezdve elérhetővé vált a ProcessBuilder API, amivel könnyebben lehetett létrehozni új folyamatokat. Nézzük meg, hogy mivel bővül a process API repertoárja a Java 9-ben!

process API szemléltetésére szolgáló ábra

ProcessHandle interfész

Az új ProcessHandle interfész új lehetőségeket nyit számunkra a natív folyamatok kezeléséhez. A Java 5 óta elérhető ProcessBuilder által előállított Process objektumoktól elkérhető azok ProcessHandle-je.

A ProcessHandle feladata, hogy azonosítson egy folyamatot és lehetővé tegye, hogy különféle műveleteket végezzünk el rajta. Példányok a következő statikus factory metódusok segítségével hozhatók létre:

Statikus factory metódusLétrehozott ProcessHandle objektum
current()Az aktuális folyamathoz tartozó ProcessHandle objektummal tér vissza.
of(long pid)Optional<ProcessHandle> objektummal tér vissza, ami a megadott natív folyamat azonosítóhoz tartozik.
children()Stream<ProcessHandle> objektummal tér vissza, ami az aktuális folyamathoz tartozó közvetlen gyerek folyamatokat tartalmazza.
descendants()Stream<ProcessHandle> objektummal tér vissza, ami az aktuális folyamathoz tartozó gyerek folyamatokat tartalmazza, rekurzívan azok gyerek folyamataival együtt.
parent()Optional<ProcessHandle> objektummal tér vissza, ami az aktuális folyamat szülő folyamatát tartalmazza.
allProcesses()Egy olyan Stream<ProcessHandle> objektummal tér vissza, ami az aktuális folyamat által látható össze folyamat ProcessHandle-jét tartalmazza.

További hasznos metódusok, amit a ProcessHandle interfész elérhetővé tesz:

ProcessHandle metódusLeírás
info()ProcessHandle.Info objektummal tér vissza, ami az adott folyamathoz tartozó információkat tartalmazza.
isAlive()boolean-nel tér vissza, ami azt jelzi, hogy az adott folyamat él-e még.
pid()A natív folyamat azonosítóval tér vissza, ami alapján az operációs rendszer számon tartja az adott folyamatot.
supportsNormalTermination()boolean-nel tér vissza, ami azt jelzi, hogy támogatja-e a normál leállítást az adott folyamat, vagy rákényszerítve, azonnal állítja le a folyamatot.
onExit()CompletableFuture<ProcessHandle> objektummal tér vissza, ami arra használható, hogy az adott folyamat befejeződésekor, szinkron vagy szinkron módon, elindítsunk egy tetszőleges utasítást.
destroy()boolean-nel tér vissza, ami azt mutatja meg, hogy az adott folyamat leállítási kérelme sikeresen fel lett-e dolgozva.

ProcessHandle.Info interfész

Egy folyamatra egy adott időpillanatban vonatkozó információit tartalmazza. Ezek az információk korlátozottak lehetnek az információkat igénylő folyamatra vonatkozó operációs rendszeri jogosultságok függvényében.

ProcessHandle.Info metódusLeírás
arguments()Az adott folyamat argumentumait tartalmazó String tömböt tartalmazó Optional objektummal tér vissza.
command()Az adott folyamathoz tartozó alkalmazás nevét tartalmazó Optional-lel tér vissza.
commandLine()Az adott folyamathoz tartozó parancssort tartalmazó Optional-lel tér vissza.
startInstant()Az adott folyamat indításának pillanatát tartalmazó Optional-lel tér vissza.
totalCpuDuration()Az adott folyamat által felhasznált CPU-időt tartalmazó Optional-lel tér vissza.
user()Az adott folyamat felhasználóját tartalmazó Optional-lel tér vissza.

Példa

Összefoglalás

A Java 9 process API újításai segítségével szebb kódot írhatunk. A korábbi verzióban bevezetett ProcessBuilder is jelentős lépés volt a helyes irányba, de az új lehetőségek, amiket az új interfészek, illetve az azokat megvalósító osztályok biztosítanak, fontos új eszközöket adnak a programozók kezébe, amikkel könnyebben kezelhetővé váltak a natív folyamatok.

Ha a többi Java 9-es újítás is érdekel, akkor böngészd bátran a többi blog posztot is ebben a témában!

A hivatalos javadoc-ban minden további részletet megtalálsz:

ProcessBuilder, Process, ProcessHandle, ProcessHandle.Info, CompletableFuture.

Ha tetszett, oszd meg!

Minden, amit mindig is tudni akartál a programozásról (de féltél megkérdezni)

A programozói karrierről, a diploma szükségességéről, önfejlesztésről és szórakozásról beszélgettünk exkluzív interjú keretében Almási Zsolttal, partnercégünknél, a P92-nél dolgozó fejlesztővel.

 

Egy finom tejeskávé társaságában az A&K Akadémia egyik tantermében

Mesélj kicsit magadról, hogyan lettél programozó?

Neumann János Számítástechnikai Szakgimnáziumba jártam. Akkor úgy gondoltam, hogy ebből 5 év elég is volt, nem akarok programozó lenni. Elmentem két egyetemre, de egyiket sem fejeztem be, fél évig jártam mindkettőre. Több bulin voltam, mint órán, eléggé elhanyagoltam. 🙂 Aztán elvégeztem egy OKJ-t. Ezt csak azért csináltam meg, hogy legyen papírom róla, hogy informatikában jártas vagyok. Véletlenül találkoztam a mostani főnökömmel és beszélgetés közben kiderült, hogy állást keresek, és tudta, hogy értek a programozáshoz, és bár diplomám nincs, behívtak interjúra és végül fel is vettek. Gyorsan pörögtek az események. Elvégeztem egy 6 hónapos belső képzést és aláírtam egy két éves szerződést. Eddig 3 projektben vettem részt. Körülbelül májusban lesz két éve, hogy itt vagyok.

Mi volt a legnehezebb az elején?

Egy olyan keretrendszerrel találkoztam, amit egyáltalán nem ismertem, ráadásul a keretrendszer maga a kód fele, tehát ha nem ismerem, akkor nem ismerem magát a kódot sem. Azt volt nehéz megtanulni, hogy hogyan kell használni. Ráadásul a kód sem volt egyszerű, egy metódus többezer sorral és benne nagy “if”-ekkel.

Hazaviszed a munkát?

Csak ha van kedvem, és ha érdekel annyira, hogy foglalkozzak vele otthon is. Többet szoktam azon gondolkodni, hogy hogyan lehet egy feladatot röviden megoldani, mint hogy nekiálljak a hosszú útnak. Az idő egy része azzal telik, hogy gondolkodom a rövidebb, könnyebb megoldáson. Nem fogok órákat gépelni, hogy ha meg tudom csinálni sokkal egyszerűbben is. A Java-ban az a nehéz, hogy rengeteget kell benne kódolni. Semmi kedve az embernek órákig csinálni. Keresni kell a rövidebb utakat, mert biztosan meg lehet csinálni egyszerűbben is. 🙂

Ha újrakezdhetnéd, akkor mit tennél másképp?

Ha újrakezdhetném, akkor azonnal, ahogy elvégeztem a középiskolát, elmentem volna egy ilyen helyre dolgozni, mint a P92. Ennek van értelme. Esetleg mellette megcsináltam volna az egyetemet, de nem biztos. Szerintem az egyetemnek önmagában semmi értelme nincs, úgy pedig pláne nem, hogy arra 3,5 – 5 évet tisztán rászánjak. Felesleges ebben a szakmában. Itt sokkal többet számít a gyakorlati tapasztalat.

Szerinted mit jelent, ha valaki diplomás?

Az egyetem önmagában annyit jelent, hogy van elég kitartásod elvégezni, tudsz tanulni, képes vagy magadra erőltetni a folyamatos tanulást, különben nem tudod befejezni az egyetemet. Ebben jó. Illetve bizonyos szinteken már kell a matek is, és ott tanítanak ilyet. De ez is ritka, és csak bizonyos pozíciókban van rá szükség. Külön cégek foglalkoznak ilyesmivel. Üzleti szoftverekhez nem kell matek, itt már meg van írva az a rész, csak használni kell tudni.

Gondolkodtál azon, hogy most utólag elvégzed az egyetemet?

Hááát… legfeljebb csak a papírért. Talán. De minden álláshirdetésnél az van odaírva, hogy BSc, MSc vagy azzal egyenértékű tapasztalat az adott területen. Az meg megvan. 🙂

Érezted valaha hátrányos helyzetben magad azért, mert nincs felsőfokú végzettséged?

Nem. Még nem fordult elő, hogy a papír hiányzott volna. Az ott megszerezhető tudás sem nagyon hiányzott. A matek egyszer jól jött volna, mert volt egy könyv a funkcionális programozásról, amit el akartam olvasni, de nagyon belemerült a részletekbe, és nem minden részt értettem pontosan.

Mit tanultál meg a felvételi utáni belső képzésen?

A fél éves belső képzésen a sebességet növeltük, mert ezen a munkahelyen azért kell tartani egy bizonyos tempót. Ezen kívül megtanították, hogy hogyan tudok utána nézni dolgoknak, hogyan tudom fejleszteni saját magam. Meg kellett szokni, hogy mindig újabb és újabb dolgoknak kell utána nézni.

Milyen könyveket ajánlanál kezdőknek?

The pragmatic programmert, a Clean Codert. Egyik sem kódspecifikus, inkább ilyen soft skilles. Ezenkívül a Java Core-t és a Clean codingot is mindenképp ajánlom. Ezeket angolul olvastam, magyarul nincsenek olyan jó könyvek, és ha le is fordítják magyarra, sosem fogod úgy látni azokat a kifejezéseket. A gyakorlatban úgy is minden angolul van. Ha megtanulod magyarul, és rákeresel, akkor nem találsz róla semmit, és fejben átfordítani utána elég nehéz. Jobb eredetiben olvasni.

Szerinted mennyire fontos a szakmai életben az angol? Te hogyan tanultál meg angolul?

Régebben heti 14 órában tanultam az angolt, és most angolul olvasok, tanulok, dolgozom. Az, hogy angolul kell tudni, az nem lehet kérdés. A könyveket meg kell tudni érteni, hogy tudd magad otthon fejleszteni. Informatikai szaknyelvből nem középszinten vagyok, sokkal magasabban. Lehet, hogy középszinten vagyok angolul mondjuk főzésből, mert zöldséget csak kb. tíz darabot tudok mondani. 🙂 De szaknyelvből kellenek a szavak. Sok mindent nem is tudok magyarul, csak angolul.

Most lehet, hogy németül kellene megtanulnom, mert gondolkodtam azon is, hogy kimennék Bécsbe dolgozni. Az is csak 3 óra vonattal, nem távolság, bár ha elkészül a bullet train akkor csak 13 perc lesz. 🙂 Hamarabb kiérnék vele Bécsbe, mint innen a Nyugatiba. Megérné kimenni dolgozni, mert ott még magasabbak a fizetések. A normál fizetés is 60 ezer euró évente. Még ha a harmadik legdrágább európai város, akkor is megéri.

Oda nem elég az angol nyelvtudás?

Az angol alapelvárás, de azért azt minden német álláshirdetésben írják, hogy egy kommunikációs szinten illik tudni németül is. Lehet, hogy a munkatársak egy része nem beszél angolul? Nem tudom.

Visszatérve a korábbi gondolathoz: ha jól értem, te most saját magadat fejleszted?

Igen. Olvasni és tanulni egyszerűen muszáj. Lehet egyedül is tanulni, de persze az a legjobb, ha van egy mentora az embernek, aki segít. Az nagy előny. Csak nehéz jó mentort találni. Nekem szerencsém volt itt a cégnél, mert mellettem volt István, aki csak úgy dobálta nekem a linkeket és könyvcímeket, hogy mi mindent olvassak el, tanuljak meg. Nagyon sokat segített a kifejezésekkel, hogy mire érdemes rákeresni. Ez tök jó volt, mert igazából rám volt bízva, hogy mennyit tanulok. Nagyon sokat segített benne.

Mit tanácsolnál egy teljesen kezdőnek, aki most kezd el először programozni?

Keressen rá a népszerű programnyelvekre, és válasszon egy szimpatikusat közülük! Szerintem a Java nagyon jó. De ahhoz, hogy önállóan tovább tudja saját magát fejleszteni, ahhoz először valahogy el kell érnie egy bizonyos szintet. Hiszen, ha nem tudja, hogy mit keressen, hogyan működik ez az egész, akkor esélytelen. A kezdeteknél mindenképp jó egy mentor. Ha nem tudja, hogy miben kell fejlődnie, akkor az nagy pech, ha egyedül van, és nincs kitől kérdezni, tanácsot kérni.

Milyen a jó mentor, és miért?

Legfőképp türelmes. Programozni elég nehéz dolog. Nem olyan egyszerű, mint ezt olyan sokan mondják, hogy ott van, elég elolvasni és kész. Sok helyen ez jön le a netről, de ez nem igaz. Próbálják könnyűnek mutatni, pedig nem egy könnyű dolog, szerintem. A valódi munka nem arról szól, hogy írsz valami újat. Bele kell nyúlni a meglevőbe! Senki a bolygón nem kap olyan feladatot, hogy magától írjon, tisztán egy programot, ezt megmondom neked itt a széken ülve. A valóság arról szól, hogy egy már meglevő rendszerbe kell belenyúlni felelősséggel, és az nem egyszerű. És nap, mint nap ezt kell csinálni.

 

 Szerinted mire számítsanak a kezdők a tanfolyamunk alatt?

Lesznek nehéz pontok, amin át kell majd esniük ebben biztos vagyok. Mindenkinek lesz olyan, hogy nem érti meg, amit tanul, és ülnie kell rajta 3-4 napot, és még azután is szembe kell néznie azzal, hogy nem érti meg. Idő kell neki, mire az ember rááll. Még a mai napig is simán van olyan, hogy valamit nem tudok megcsinálni és akkor egy héttel később egyszer csak katt, és beugrik. És akkor megvan! Tehát türelem kell, mindenképp! Vannak dolgok, amikhez idő kell, nem megy másképp. Lesz olyan, hogy Andris elmondja egyféleképp, nem értik meg, másképp, harmadik módon és mondhatná tizenötféleképpen, akkor sem megy. Van ilyen. Az a helyzet már nem a magyarázaton múlik. Érnie kell a gondolatnak és majd hetekkel később meg lesz az a megoldás. Erre fel kell készülni. Mindenki másképp működik.

Az elmúlt évek során volt, hogy elvesztetted a motivációdat, és beleuntál?

Persze, unalmas részek is vannak. De mit lehet ilyenkor csinálni? Beleharapok az ajkamba és várok. 🙂 Meghallgatom, megnézem, és ennyi. Ha szükségem van rá, újra és újra rákeresek, utána nézek, és előbb-utóbb megmarad. Amikor gondolkodok rajta, akkor általában gyorsan megtanulom, de bemagolni semmit nem magolok be. Felesleges. A leghatékonyabb tanulás a gyakorlás. Én sokszor elég lusta vagyok ehhez, de én is látom, hogy kell. Be kellene áldozni 1-2 órát gyakorlásra.

Most, hogy ebben dolgozol, most is folyamatosan tanulsz?

A jó pap is holtig tanul, nekünk is muszáj. Szinte havonta változik az egész, tartani kell a lépést. Muszáj olvasni, tanulni. Nem szabad abbahagyni, mert lehagy a szakma. Be kell áldozni valamit, hogy legyen rá idő. Vagy kevesebbet dolgozok konkrétan, és utána járok dolgoknak, vagy ha munka mellett nem fér bele, akkor otthon kell utána járnom. A P92-nél is van lehetőség tanulni. Angolra is lehet járni, Clean code-ra, Refactoringra, stb., heti több órában.

Próbáltad már tanítani azt, amit megtanultál?

Nem, még nem. Ha valakinek van valami problémája, elakadása, akkor szívesen segítek, persze. De tanítani az más dolog.

Milyen álmaid vannak a jövőre nézve?

Több fizetés, esetleg külföld. Volt egy lehetőség itt a P92-nél is, hogy ki lehet menni Amerikába, meg is pályáztam, de sajnos nem engem választottak. Külföldön a legtöbb helyen angol kell, úgyhogy ez nem lesz gond a jövőben sem.

Jelenleg meg vagy elégedve a fizetéseddel?

Meg vagyok elégedve, igen. Többet keresek, mint más ismerőseim, nagy átlagban. Persze vannak elképzeléseim a jövőre nézve, ha lejár a két éves szerződésem, de ez így rendben volt eddig.

Nem aggódsz, hogy mi lesz utána?

Nem. Tele van a net álláshirdetésekkel. Nem szoktam sokat aggódni, nincs miért. Eddig sem kellett sokat interjúra járnom. Anno összesen 2 helyre adtam be a CV-met, a P92 volt az egyik. Szóval kb. azonnal sikerült. Szinte azonnal fel lettem véve. Válogatós vagyok és szerencsére lehet is válogatni. Régebben azért nem mertem sok helyre elküldeni a CV-met, mert tudtam, hogy nem felelek meg, de ez most már nincs így. Most már megfelelek, van önbizalmam.

Van hobbid?

Most tanulok japánul, király. 🙂 Nem a megtérülés miatt, csak egy drága hobbi. De amúgy is tele vagyok olyan hobbikkal, amik időt és pénzt vesznek el. 🙂

A PC-s játékoknak is van haszna, csak nehéz bemutatni őket, de az életben kijön, hogy ha jó vagy ezekben a játékokban, akkor az életben is bizonyos dolgokhoz valahogy jobban értesz. Csak erre nem lehet könnyen rámutatni, hogy ez és ez az a pont, amiben jobb vagy. Játszva tanul velük az ember. Szerintem jók. Ha tudsz párhuzamot vonni a játék és egy másik dolog között, akkor nagyon hasznos. Rendszerezni is megtanulsz, nyelvet gyakorolsz, reakcióidőd is nőhet, persze játéktól függ.

Ezeken kívül sokat olvasok. Egy évben elolvasok vagy húsz ponyvát (pl. a kedvenc kiadóm az Agave), és kb. három komolyabb szakmai könyvet. Egy 400 oldalas ponyvát kb. egy nap alatt elolvasok. Leülök, vagy az utcán olvasok, utazás közben, sőt, séta közben is tudok olvasni.

Hogy állsz a soft skillekkel?

El tudom adni magam. Ha már beszélgetnem kell valakivel, akkor már előnyben vagyok. Nekem ez nem gond. Komoly konfliktusom sem volt munkahelyen senkivel. Kreatív viták vannak, vagy van, hogy hangosabbak vagyunk, de semmi komoly.

A soft skillek fejlesztéséhez van valami jó tanácsod a most induló csoportnak?

Elküldeném őket egy buliba, hogy szedjenek fel egy nőt vagy férfit! Oda pont ugyan ezek a készségek kellenek. 🙂

Köszönjük szépen a beszélgetést! 🙂

Ha tetszett, oszd meg!

Java 9 újdonságai – 5. rész

Collection factory metódusok

A Collection factory metódusok olyan új statikus metódusok, amik segítségével egyszerűbben, tömörebben és biztonságosabban inicializálhatunk collection adatstruktúrákat.

Előzmények

A Collections Framework létezése óta – vagyis már a JDK 1.2 óta (1998) – sok fejlesztőt elgondolkodtatott, hogyan lehet egy ArrayList-et egy sorban inicializálni. Bár a Java nyelvi támogatást nyújt a String literálok esetén, nem ez a helyzet a Collections Framework-nél.

Szimpla kóderek

Bár Collections literálok nincsenek a Java-ban, ahogy más referenciatípusoknál is, itt is jogos az igény az inicializálásra. Erre a legnyilvánvalóbb – mondhatni triviális – megoldás a következő:

Bár ez a megoldás helyes, mégis nagyon bőbeszédű. Tudsz ennél jobbat?

Leleményes kóderek

A fenti megoldás kicsit túl bőbeszédű, indokolatlan mennyiségű kódot kell leírni ahhoz, hogy egyszerűen alapértékre állítsunk be egy listát. Létezik egyszerűbb megoldás:

Így már sikerült egy sorossá tenni ezt az inicializációt, de érdemes megjegyezni, hogy az előző megoldással ez nem ekvivalens, van egy jelentős különbség az így alapértékre állított változó használatában. Ez a különbség névlegesen az, hogy az így példányosított lista nem méretezhető át, vagyis nem adhatunk hozzá újabb elemet és nem is törölhetünk belőle. Ha makacsak vagyunk és mégis megpróbálnánk, akkor futásidőben a virtuális gép egy UnsupportedOperationException-nel lep meg minket.

Figyelmesen elolvasva az Arrays.asList(T… a) metódus javadoc-ját fény derül ennek okára. Itt elmagyarázzák nekünk, hogy ez a metódus a könnyebb átjárhatóságot hivatott biztosítani a régebbi tömb alapú API-k és az újabb Collection alapú API-k között. A visszaadott lista objektumon végzett változtatások „átíródnak” a lista alapját szolgáló tömbbe. Érthető tehát, hogy mivel a tömbök is létrehozásuk után fix méretűek, így az Arrays.asList(T… a) metódus által visszaadott lista is fix méretű lesz.

Még leleményesebb kóderek

Egy egyszerű csavarral az előző megoldásból kerekíthetünk egy módosítható listás megoldást, ami első bőbeszédű változattal egyenértékű funkcionalitásban:

Ez nagyszerű, de kezdünk megint kicsit túl bőbeszédűek lenni. Túl sok billentyűt kell leütni ahhoz, hogy inicializáljuk a listánkat. Vajon van jobb megoldás?

Túl leleményes kóderek

Ha alaposan ismered a Java nyelv alapvető építőköveit, akkor bizonyára hallottál a példány inicializátorokról (instance initializer). Ha ezt vegyítjük egy kis névtelen belső osztállyal, akkor eredményül egy extra trükkös, első ránézésre újszerű szintaxist kapunk:

Elértük, amit szerettünk volna, egy sorban inicializáltuk a listánkat. Még mindig van néhány feleslegesnek tűnő karakter és elég sok szintaktikai elem. Ezt a megoldást szokták dupla kapcsoszárójeles inicializálásnak (double brace initialization) hívni. Bár valóban egysoros lett ez a művelet, számos dolog történik a háttérben. Vegyük sorra:

  1. Először is létrejön az ArrayList osztályból leszármaztatott névtelen osztály.
  2. Ennek az új névtelen osztálynak létrejön egy példánya.
  3. Mivel a belső kapcsoszárójel az egy példány inicializátor blokk, ezért ez a kódblokk lefut a 2. lépésben történő példányosodás során.
  4. Az utasításblokk az add() példány metódust meghívja egymás után különböző paraméterekkel, ami mivel nincs override-olva, ezért a szülő osztályból (ArrayList) megörökölt publikus add() metódust hívja meg, ami hozzáadja a paraméterként kapott elemeket a listához.
  5. A most létrejött névtelen osztály példányának referenciáját hozzárendeli a shoppingList változóhoz.

Elég sok dolog végbemegy egyetlen sorban. Ráadásul a névtelen belső osztály miatt a Java fordító külön class fájlokat gyárt a fájlrendszeren. Ha sokat használjuk ezt a trükköt, akkor a túl sok plusz class fájl miatt a programunk lelassulásának lehetünk tanúi. Az objektumorientáltság egyik alapműveletét a leszármaztatást itt nem arra használjuk, amire hivatott, mondhatni visszaélünk vele.

Tudván ezeket kijelenthetjük, hogy bár érdekes módszer ez, mégis kerülendő, anti-patternnek tekintendő.

Java 9 Collection factories to the rescue!

A Collection factory metódusok, amiket a Java 9-ben vezetnek be, elegáns megoldást nyújtanak:

Ez már tényleg sokkal jobb, mint az eddigi megoldások. Nincs túl sok szintaktikai elem és nem is kell sokat gépelnünk. Mégis van egy kis probléma, ami persze a felhasználók szempontjából igazából lényegtelen, de jó tudni róla.

Ennek az új of metódusnak pontosan mennyi paramétert is tudunk átadni? A példánkban épp 3-at adunk át, de mi van, ha valakinek kevesebb vagy több kell?

A Java 5-ös verziójában bevezették a változó hosszúságú argumentumokat (varargs). Ez lényegében egy szintaktikai édesítőszer, ami lehetővé teszi, hogy egy metódusnak ne tömböt kelljen átadnunk, hanem vesszővel felsorolhassuk az argumentumokat. A következő két metódus egyenértékű:

A változó hosszúságú argumentumoknak persze vannak megkötései, például hogy az ilyen paraméter csak a paraméterlista végén szerepelhet, illetve egy metódusnak csak egy ilyen paramétere lehet. Amikor változó hosszúságú argumentumokat váró metódust hívunk, akkor a háttérben létrejön egy tömb, ami hordozza az elemeinket. Ez persze némi teljesítménybeli visszaesést okoz, főleg ha sokszor futtatunk ilyen kódot, például ciklusban.

Hogy ezt elkerüljék, a Java fejlesztői az új of metódusnak nem csak egy változatát készítették el, hanem másik 10 overloadolt változatát is, ahol az első egy paramétert vár, a második kettőt, a harmadik hármat, és így tovább. Így amikor egy, kettő, három … tíz argumentummal hívjuk, akkor a megfelelő overloadolt változat fut le, és így elkerüljük a varargs esetén fellépő overheadet. Cserébe viszont „teleszemetelték” a Java core kódját egy csomó redundánsnak tekinthető résszel, így ezentúl több kódot kell majd karbantartaniuk az elkövetkezendő verziókban. A Java-t fejlesztő szakemberek ezt a megközelítést tartották célszerűnek.

De nem csak a List és Set kapott új factory metódusokat, hanem a Map is:

Tíz argumentumig itt is overloadolt metódusokat használhatunk a kulcs-érték párok felsorolásához, de efelett szintén változó hosszúságú argumentummal rendelkező factory metódust tudunk hívni, amit Map.Entry<K, V> objektumokba kell csomagolnunk, amihez kapunk cserébe statikus entry() metódust:

Az új statikus Collection factory metódusok fontos tudnivalói

Nem csak a bőbeszédűség csökkentése volt a cél, bár kétségtelenül nagy előny, hogy tömörebben meg tudjuk fogalmazni a kódunkat és könnyebb is átlátni. A programozói hibák is csökkenthetők néhány általános érvényű szabály bevezetésével, amit az elmúlt években már eszközöltek is, és amire most is ügyeltek.

Megfigyelték, hogy a programhibák jelentős százaléka a null értékek helytelen használatából ered. Épp ezért a collection-ös adatstruktúrákban nem használhatjuk a null-t elemként. Ezt ezek az új statikus factory metódusok se engedélyezik.

A másik hibacsökkentési lehetőség az immutabilitás (módosíthatatlanság) bevezetése. Ezek a Collection factory metódusok módosíthatatlan adatstruktúrákat produkálnak. Ez azért jó, mert sok hiba abból fakad, hogy egy módosítható adatstruktúrát a program hívási láncolata mentén végigpasszolva valahol akaratlanul módosítjuk.

Egy másik nagy előnyt azt a Map.ofEntries() megvalósítása nyújtja, ugyanis itt nem tudjuk elrontani a kulcs-érték párok párosítását, ami csak futásidőben derülne ki, mert már fordítási időben hibát kapunk és hamar kijavíthatjuk azt.

A HashSet-ek és HashMap-ek elemei mindig is látszólag véletlenszerű iterálási sorrendet eredményeztek, de volt egy determinisztikus voltuk, hogy ugyanazt a sorrendet követték minden programfutás esetén. Az új immutábilis collection-ök viszont minden futásnál más és más sorrendben iterálnak végig az elemeiken, így ha hibásan egy kódrészlet a rendezetlen elemek valamilyen sorrendjére támaszkodott, akkor most az ilyen hibákra hamar fény fog derülni (ezt hívjuk fail fast viselkedésnek).

Konklúzió

Összességében az új Collection factory metódusok egy nagyszerű új lehetőséget biztosítanak a programozók számára, amivel tömören tudják a kódjukat megfogalmazni. Érdemes tisztában lenni a részleteikkel, mint például, hogy immutábilis példányokkal térnek vissza, tiltják a null használatát és az iterálási sorrendjük is változó lehet.
A JEP 269-ben olvashatod el angolul a motivációt a megvalósítás mögött.
Ha érdekel a Java 9 többi újdonsága is, akkor azokat a Java 9-es blog posztjainkban olvashatod.

Ha tetszett, oszd meg!

Java 9 újdonságai – 4. rész

Reactive Streams API – reaktív programozás

“A reaktív folyam egy kezdeményezés egy szabvány létrehozására, ami nem blokkoló háttérnyomás esetén is aszinkron folyam feldolgozást tesz lehetővé.” Mi van? – kérdezheted magadban. Pedig ez a lényeg. Bontsuk le kicsit, hogy honnan is származik ez az egész reaktív programozás és mi az értelme! Egy fontos koncepcióról van szó.

A reaktív programozás előzményei

Napjaink alkalmazásainak nagyon más követelményeknek kell megfelelniük, mint néhány évvel ezelőtt. Régebben elég volt, ha a program sok másodperccel később reagált a felhasználói inputra. Az se volt gond, ha néha pár órára leállították karbantartás miatt az egész rendszert. A legnagyobb rendszerek is csak néhány gigabájtnyi adatot kezeltek és az egész néhány szerveren futott.

Ezzel szemben ma a felhasználók inkább milliszekundumban mérhető válaszidőt várnak még a mobiljukról elért webes alkalmazásoktól is. Sokszor már petabájtnyi adatot kezelnek (a gigabájt egymilliószorosa) és felhő alapú klasztereken futnak, ahol több száz vagy ezer magos processzor szolgálja ki a számítási igényüket. A rendelkezésreállás 99,9999% vagy még több kilences a végén, attól függ, hogy milyen rendszerről van szó.

Egyszerűen túl nagy az elvárások közti különbség, és a régen bevált módszerek már nem elégítik ki ezeket az új igényeket. Szükség van tehát valami újra. Ez az új megközelítés a reaktív programozás.

Reaktív programozás

Nagyvállalatok egymástól függetlenül fejlesztették le az IT-s rendszereiket, amik között rengeteg hasonlóság volt, bár mindegyik másképp lett implementálva. Az igények már jól körvonalazódtak külön-külön. Milyen alkalmazásra van manapság szükség? Olyanra, ami

  • jól reagál (reactive): A program a vele folytatott kommunikáció során gyorsan ad választ, ezáltal a problémák is gyorsan felfedezhetők és orvosolhatók benne. Az ilyen rendszerek gyors és konzisztens módon adnak választ a kérésekre, megbízható felső korlátot specifikálnak válaszidőnek.
  • öngyógyító (resilient): A program hiba esetén is jól reagáló marad. A hibákat adott komponensen belül kell kezelni és a különböző komponenseket izolálni kell egymástól, ezáltal lehetővé téve, hogy a rendszer részei meghibásodhassanak és helyreállhassanak az egész rendszer kompromittálása nélkül. A komponensek helyreállítását egy másik külső komponensnek való feladatdelegálással lehet megoldani, a magas elérhetőséget pedig replikációval, amikor szükséges. Az adott komponenst használó klienseket nem terheljük meghibásodás kezelésével.
  • alkalmazkodó (elastic): Az alkalmazás akkor is jól reagál, amikor nagy terhelésnek van kitéve (pl. Neptun :-)). A reaktív rendszerek képesek detektálni a terhelés mértékét és ennek megfelelően allokálni erőforrásokat a programhoz. Ennek persze vonzata, hogy globális bottleneckektől mentes architektúrájú legyen a szoftver. Az ilyen rendszerek prediktív és reaktív skálázó algoritmusokat is támogatnak és az alkalmazkodókészségüket költséghatékony módon, mindenki által elérhető hardveren és szoftveren valósítják meg. (Vagyis nem kell hozzá szuperszámítógép.)
  • üzenet vezérelt (message driven): A program aszinkron üzenetátadáson alapul, amivel jól elhatárolhatók a komponensek egymástól és azok laza csatolását eredményezi. Ez az izoláció azt is lehetővé teszi, hogy a hibákat, mint üzeneteket delegáljuk. Az explicit üzenetátadással képessé válik a terheltség kezelésére, illetve alkalmazkodás érhető el azzal, hogy az üzenetsorok hosszát megfigyeli és formálja az igényeknek megfelelően.

Durván 3 évvel ezelőtt (2014. szeptember 16-án) tették közzé a második verzióját a “Reactive Manifesto”-nak, ami ezeket az igényeket fogalmazta meg.

Új programozási paradigma

A reaktív programozás tehát nem más, mint egy új programozási paradigma, ahol adatelemek aszinkron folyamát dolgozzuk fel, és ahol az alkalmazások az új adatelemekre azok megjelenésekor reagálnak.

Az adatok folyama nem más, mint időben egymás után levő adatelemek. Ezzel a módszerrel sok memóriát spórolhatunk meg és így hatékonyabbak lehetünk, mert az adatokat folyamként dolgozzuk fel, és nem kell egy memóriában összegyűlt adathalmazon végigiterálni.

Reaktív folyamok

Amikor a Reactive Manifesto alapján a reaktív folyam megközelítés útjára indult, akkor az volt a cél, hogy egy szabványos megoldást adjanak az aszinkron folyamfeldolgozásra, nem blokkoló háttérnyomás esetén. (Erre a háttérnyomásos dologra rögtön kitérünk részletesebben.) A fő kihívás nem az volt, hogy megoldást találjanak erre a problémára – hisz ekkor már több implementáció is létezett – hanem az, hogy a különböző megoldásokat összeolvasszák és megtalálják azt a minimális halmazát az interfészeknek, metódusoknak és protokolloknak, ami leírja a szükséges műveleteket és entitásokat, hogy elérhessük ezt a célt. Ha még mindig olvasod és idáig eljutottál, akkor megérdemelnél egy ingyen csokit!

Háttérnyomás

A háttérnyomás a kulcs koncepció itt, vagyis angolul a “back pressure”. Képzeld el a termelő (producer) és fogyasztó (consumer) feleket a rendszerben! A termelő adja és a fogyasztó kapja az üzeneteket. A fogyasztó feliratkozik a termelő adatforrására, ha szeretne tőle üzeneteket kapni. Ezek után, amikor egy új üzenet elérhetővé válik, a termelő a fogyasztónak egy callback metódusát meghívva feldolgozásra átadja az üzenetet.

Ha a termelő az üzeneteket nagyobb ütemben adja ki magából, mint ahogy a fogyasztó képes azt feldolgozni, akkor a fogyasztó rá lesz kényszerítve arra, hogy egyre több és több erőforrást ragadjon magához, amely jó eséllyel crash-eli a fogyasztót. Ennek megakadályozására szükség van egy mechanizmusra, hogy a fogyasztó értesíteni tudja a termelőt, hogy az üzenetküldési sebességet csökkentse. A termelő ekkor néhány különböző módszer közül választhat, amivel ezt a helyzetet kezelheti. Ezt a mechanizmust hívjuk háttérnyomásnak, vagyis back pressure-nek.

Blokkoló háttérnyomás

Ezt a legegyszerűbb elérni. Ha a termelő és a fogyasztó azonos szálon futnak, akkor az egyik végrehajtása blokkolja a másik végrehajtását. Probléma megoldva. Persze sok esetben ez nem eszközölhető. Gondolj csak arra, hogy a termelőnek nem csak ez az egy fogyasztója van, hanem több is, és mindegyik más sebességgel képes az üzeneteket feldolgozni. Legtöbbször nem is megoldható, hogy azonos szálon fussanak, mert különböző környezetekben vannak. Ilyen esetekben szükséges egy nem blokkoló háttérnyomási mechanizmus.

Nem blokkoló háttérnyomás

Ezt úgy érhetjük el, hogy a push stratégiánkat lecseréljük pull stratégiára. Vagyis nem akkor történik küldés, amikor a termelő készen áll az új üzenetekkel, hanem akkor, amikor a fogyasztó szól, hogy készen áll x üzenet fogadására. Ekkor a termelő pontosan ennyi üzenetet küld és vár, mielőtt továbbiakat küldene.

JDK 9 Flow API

A Java 9-ben megalkotott, a fentieket minimális méretű interfészekkel támogató API-ja a JEP 226: More Concurrency Updates keretein belül valósult meg. A következő 4 interfészt tartalmazza:

Java reaktív programozás Publisher és Subscriber szerepeket szemléltető ábra

Nomenklatúra

Korábbi elnevezéseink alapján (termelő, fogyasztó) a Subscriber a fogyasztó, de a Java 9 Flow API nomenklatúrája alapján a feliratkozó, a Publisher pedig a termelő, vagyis a publikáló (kiadó). Ezeket az elnevezéseket magyarul nem tartom szerencsésnek, így ezekre az angol nevükkel, vagy a magyarban meghonosult általános nevükkel fogok hivatkozni a továbbiakban.

Subscriber

A Subscriber feliratkozik a Publisher-hez annak subscribe metódusának meghívásával. Az adatelemek nem kerülnek kiküldésre a Subscriberhez, amíg azokat nem kéri explicite. A Subscriber Subscription-ön hívott metódusai szigorúan rendezettek. Az alkalmazás a következő callback-ekre tud reagálni, amik a Subscriberen vannak definiálva:

CallbackLeírás
onSubscribeEz a metódus kerül meghívásra minden egyéb Subscriber metódus előtt az adott Subscription esetén.
onNextEz a metódus kerül meghívásra egy Subscription következő eleménél.
onErrorEz a metódus kerül meghívásra egy helyreállíthatatlan hiba esetén, ami a Publisher-ben vagy Subscription-ben történt, ami után más Subscriber metódus már nem lesz hívva a Subscription által.

Ha egy Publisher hibába ütközik, ami nem teszi lehetővé adatelemek küldését a Subscriber-nek, akkor ezen a Subscriber-en az onError metódus kerül meghívásra és további üzeneteket nem fog kapni.

onCompleteEz a metódus akkor hívódik meg, amikor már ismertté válik, hogy további Subscriber metódushívások nem lesznek egy olyan Subscription-höz, ami még nem zárult le hibával.

Subscriber példa

Publisher

A Publisher az adatelemek folyamát továbbítja a feliratkozóknak. Ezt aszinkron módon teszi, általános esetben egy Executor segítségével. A Publisher-ek biztosítják, hogy a Subscriber metódushívások minden Subscription esetén szigorúan rendezett sorrendben történnek. Ha még mindig itt vagy velem, akkor az adatfolyamon érkezik neked egy újabb csoki reaktív módon.

Publisher példa a JDK SubmissionPublisher osztályával

Subscription

Egy Publisher-t és egy Subscriber-t köt össze. A Subscriber-ek csak akkor kapnak adatelemeket, amikor explicit kérik azokat, és bármikor visszavonhatják a Subscription segítségével.

MetódusLeírás
requestHozzáadja az adott n számú elemet az aktuálisan be nem teljesített kérelmekhez az adott Subscription-nél.
cancelA Subscriber-t leállítja, ami ezek után nem kap több üzenetet. A visszavonási kérelem nem azonnal történik.

Processor

A Processor egy olyan komponens, ami Subscriber-ként és Publisher-ként is viselkedik. A Publisher és Subscriber között helyezkedik el és átalakítja az egyik folyamot egy másikra. Több Processor-t is egymás után lehet kötni, és az utolsó Processor eredményét dolgozza fel a Subscriber. A JDK nem tartalmaz konkrét Processor implementációt, így ezt az API-t felhasználó programozónak kell megvalósítania.

Processor megvalósítására egy példa, ami String-ből Integer-t készít

Példa a Processor-ral történő folyam átalakításhoz

Konklúzió

A reaktív programozás megvalósulásához a Java 9 Flow API-ja egy jó kezdet. Megadja a fejlesztőknek azt a minimális interfész csomagot, amivel reaktív programok készíthetők, de időre lesz szükség, mire ennek az ökoszisztémája kialakul. Ha más termékekben is elérhetővé válik majd a reaktív programozás API-ja – mint például adatbáziskezelő rendszerekben – akkor megvalósulhatnak majd azok a modern alkalmazások, amik a Reactive Manifesto-ban leírt feltételeknek megfelelnek.
Ha érdekel a Java 9 további nyelvi újításai, akkor olvasd el a korábbi blog posztokat is a Java 9 témában!

Forrás:
https://community.oracle.com/docs/DOC-1006738
https://aboullaite.me/java-9-new-features-reactive-streams/

Ha tetszett, oszd meg!

Diploma nélkül is lehet valaki programozó?

Megosztó kérdés ez napjainkban, hiszen a legtöbb területen akkor helyezkedhet el az ember, ha igazoltan végzettsége van (talán meglepő, de sok helyen még takarítónak sem állhat be valaki OKJ végzettség nélkül). A programozók élete ebben is, mint sok minden másban, eltér a magyar gyakorlattól. Míg jó magyar szokás szerint más területeken száz helyre adjuk be az önéletrajzunkat, és örülünk, ha egy helyről legalább negatív visszajelzést kapunk (hiszen a többitől még ennyi sem érkezik), addig a programozásban jártas, gyakorlattal rendelkező fejlesztőket kifejezetten keresik a munkaerőpiacon, népszerűek a fejvadász cégeknél és egy megfelelő LinkedIn regisztráció lehetőségek tárházát kínálhatja, már a kezdetektől is. Találhat tehát valaki jól fizető állást diploma nélkül is programozóként?

Mi a valóság diploma nélkül?

Gyakorlati tapasztalatunk az, hogy igen! Lehet valaki programozó diploma nélkül is. Erre élő példa partnercégünk pozitív hozzáállása is a felvételhez. Hasonló véleményeket mutatnak az ebben a témakörben az utóbbi években végzett országos felmérések is.
diploma nélkül is vidáman lehet programozni

Lehet, de mennyiért?

Olvasásra érdemes a KSH 2015-s tájékoztatója alapján készült rangsor a legjobban fizető, diploma nélkül végezhető szakmákról. A programozó dobogós helyet ért el:

Programozó: 300 000 – 500 000 Ft

Villamosenergetikai technikus: 315 000 Ft

Értékesítő: 315 000 Ft

(Forrás: cvonline)

Más források úgy fogalmazzák meg a jelenséget, hogy “diploma nem kell, de képzettség igen”.

Szó nincs tehát arról, hogy tanulás nélkül be lehet kerülni. De aki megfelelő tudást és gyakorlatot tud felmutatni, jó készségekkel rendelkezik, (ajánlólevele van, ahogy a nálunk végzetteknek is), az megtalálhatja a helyét a rendszerben.

A fizetések.hu felmérése is azt mutatta, hogy a diploma nélkül programozók átlag havi bruttó bére 339 és 700 ezer forint között mozog. (forrás: napi.hu)

Akkor teljesen felesleges a diploma?

Bár a tények kétségtelenül bíztatóak, ettől függetlenül azonban tagadhatatlan tény, hogy ha nem is muszáj, de mindenképp hasznos felsőfokú végzettséget szerezni IT területen, ha valaki programozó szeretne lenni. Akkor is, ha nem alapfeltétel egy állás betöltéséhez, a tudás mindig hasznos. Azt viszont érdemes szem előtt tartani, hogy a diploma megléte egyáltalán nem jelenti a szükséges gyakorlat megszerzését (nem véletlenül jelentkeznek hozzánk diplomával rendelkezők is, további gyakorlatias képzés, nyelvoktatás és szakmai személyiségfejlődés reményében). Több felsőoktatási képzés esetén is az a tapasztalatunk, hogy nagyon elméleti és gyenge gyakorlatias tudással érkeznek a hallgatók a munkaerőpiacra a diploma megszerzése után, kevés önbizalommal és zavarbaejtő szóbeli nyelvi készségekkel. A gyakorlati tudás hiánya pedig még diplomával sem kompenzálható egy állásinterjún. Ahogy a nyelvvizsga sem mentesít senkit sem a felvételi interjún az angol szaknyelvi felmérés alól. A munkáltató nem papírt keres!

Mi kell tehát az elhelyezkedéshez?

A magabiztos programozói tudás, a folyékony, magabiztos angol nyelvtudás és erős soft skillek megléte jó esélyeket ad az elhelyezkedésre akkor is, ha nincs diplomád. Ha van, akkor hasznos, de akkor se dőlj hátra, programozz sokat! A legfontosabb a szorgalmas gyakorlás és a folyamatos fejlődés.

Ha további kérdéseid vannak, vagy érdeklődsz képzéseink iránt, írj nekünk!

Ha tetszett, oszd meg!

13+1 dolog, ami megváltozik az életedben

13+1 dolog, ami megváltozik az életedben, ha nálunk tanulsz programozni

  1. Kialakul a programozói gondolkodásod vagy elmélyül a már meglevő tudásod, így esélyed lesz szakmát váltani vagy előrébb lépni a ranglétrán. Nem lesz többé céltalan, monoton robotolás a munka.
  2. Nem fogsz félni az angol nyelvtől, lazán beszélgetsz majd bárhol, bármikor, hiszen egy éven keresztül minden héten ezt teszed majd. Nem jelent majd problémát egy angol nyelvű prezentáció sem. Sőt! Talán kedved lesz még egy nyelvet megtanulni! Abban is segítünk!
  3. Kommunikációs és soft készségeid fejlődnek, és ezt nem csak a munkahelyeden, de a magánéletedben is kamatoztatni fogod. Végre nem lesz akkora stressz a randizás!
  4. Esélyed lesz dupla vagy akár tripla fizetést kapni, mint amennyit most keresel, így nincs többé diák- vagy lakáshitel, sőt, étterembe viheted a párod anélkül, hogy az étlap jobb oldalát figyelnéd.
  5. Jelentősen nő az önismereted, önbizalmad, tele leszel célokkal, tervekkel, amelyeket meg is tudsz majd valósítani. Coaching alkalmakon megbeszéljük, hogyan.
  6. Barátságokat és felbecsülhetetlen szakmai kapcsolatokat köthetsz a képzés alatt és után is. Segítünk ezek fenntartásában is alumni rendezvényeinken.
  7. Gazdagodhatsz egy remek notebookkal, ha szorgalmas vagy és kitartóan készülsz a szintfelmérőkre is. Miért is hagynád ki a lehetőséget, nem igaz?
  8. Nő a türelmed, toleranciád, érzelmi intelligenciád. Tudatosan fejlesztjük. Nincs többé ideges sorban állás a dugóban, számtalan ötletes megoldás lesz a kezedben, hogy mit kezdj az így nyert idővel. A stresszoldás nem lesz kihívás.
  9. Úgy érzed majd, hogy nincs lehetetlen. Egy év alatt törvényszerűen lesznek hullámhegyek és völgyek, lesznek nehéz időszakok, de amikor túljutsz rajtuk, új szintre lépsz az életedben. Maratoni futás, de befutsz a célba a végén és nagyon büszke leszel majd magadra és mi is rád!
  10. Többet fogsz szórakozni, csapatépítő játékokban, önismereti és szituációs feladatokban veszel részt és garantáljuk, hogy olyan dolgokat fogsz kipróbálni, amire ma még csak nem is gondolsz. Önfejleszteni jó buli, együtt nevetni pedig felszabadító élmény.
  11. Megszereted majd a tanulást. Hisszük, hogy nincsenek rossz tanulók, csak nem megfelelő technikák. Mi modern tanulástechnikai eszközökkel dolgozunk, így te is megtalálhatod majd a neked valót, amivel könnyebben fejlődhetsz.
  12. Pozitív hatással leszel a környezetedre is, mert egy ambiciózus, energikus, optimista oldaladdal találkoznak majd, amiből ők is energiát meríthetnek.
  13. Megtanulod, hogyan mutasd be az erősségeidet, saját brandet, stílust alakítasz ki, amely újraformálja nem csak a megjelenésed, de a kisugárzásod is. Egy év után magadra sem fogsz ismerni. Állásinterjú felkészítő csomagoddal és Akadémiai ajánlóleveleddel bárhol bármikor magabiztosan pályázhatsz meg számodra vonzó pozíciókat, ki fogsz tűnni a tömegből.

+1. Ha problémád merül fel a jövőben, hozzánk mindig fordulhatsz. Legyen szó szakmai kérdésekről, munkahelyi vagy magánéleti problémáról, az A&K Akadémián mi segítünk neked megtalálni a megoldást! Számíthatsz ránk!

Ha tetszett, oszd meg!

Az első 90 nap támogatása

Az első 90 nap támogatása az A&K Akadémián

A magas színvonalú képzés és a fejlődést támogató munkahelyek elérése mellett nagyon fontos számunkra a további szakmai támogatásod is. Épp ezért ültettük át a gyakorlatba is a korábban a vezetők integrációja során alkalmazott ún. “első 90 nap támogatást”.

Mit jelent az első 90 nap támogatása?

első 90 nap nehézségeit szimbolizáló kép
Ne ugorj fejest egyedül az ismeretlenbe! Mi is veled ugrunk.

Az új szakmai kihívások, új munkahely vagy új pozíció betöltése jelentős nyomást, stresszt okoz az életedben, ráadásul az első hónapok teljesítménye alapvetően meghatározhatja a munkád hosszabb távú megítélését is. Mi szeretnénk megkönnyíteni számodra ezt az időszakot, ezért dolgoztuk ki ezt a támogatási rendszert. Az A&K Akadémia 90 napos támogatása heti konzultációkat tartalmaz, amely során fejlesztéssel kapcsolatos kérdésekben is segítünk, és egyéni coaching alkalmakkal is támogatjuk az elméletben tanultak gyakorlati alkalmazását, legyen szó beilleszkedési kérdésekről, csapatirányításról, vezető készségek fejlesztéséről, időmenedzsmentről, vagy a tudatos tervezés támogatásáról.

Mi történik, ha eléred a vágyott célt?

Természetes dolog, hogy egy számodra fontos cél, egy új munkahely vagy vágyott beosztás elnyerésekor az öröm után megjelenik egyfajta félelem és bizonytalanság is, hogy vajon megfelelően el tudod-e látni az új feladatot. Az új beosztás másfajta készségek és képességek meglétét követeli meg tőled. Nem csak akkor terhel a nyomás, ha szakmát váltasz, és a programozás még új neked, de akkor is, ha feljebb szeretnél lépni a ranglétrán, hiszen más nézőpontot igényel egy csapat tagjaként és mást egy csapat irányítójaként részt venni egy projektben.

Elméleti háttér

“Bármely szervezetben az alkalmazott előbb-utóbb eljut abba a pozícióba, amelynek betöltésére alkalmas, majd biztosan előléptetik egy olyan pozícióba, amelynek ellátása meghaladja a képességeit.” – dr. Laurence J. Peter

Légy te a kivétel, akire nem vonatkozik a Peter – elv!

A Peter-elv (ami Laurence J. Peter után kapta a nevét) annyit mond, hogy az előléptetéseket sokszor aszerint osztják ki, hogy az adott személy hogyan dolgozott jelenlegi pozíciójában, és nem aszerint, hogy a következőre készségei alapján alkalmas-e. Ennek köszönhetően előbb-utóbb mindenki eljut abba a pozícióba, amire már inkompetens lesz, nem fejlődik eléggé, vagy nem alkalmas rá.

Hogyan tudod ezt kikerülni? Egyrészt önismerettel, hogy nemet tudj mondani azokra az ajánlatokra, amelyek ugyan nagyobb fizetéssel, vonzó kiegészítésekkel, hangzatos névvel vagy még többel kecsegtetnek, de a személyiségedhez, értékrendedhez, egyéni preferenciáidhoz nem illeszkednek, ezáltal hosszú távon boldogtalanná vagy sikertelenné tesznek majd. Másrészt felkészülhetsz folyamatos önfejlesztéssel, változtatással és változással, hogy a végül elfogadott pozícióban kihozhasd magadból a maximumot.

Miért kell ehhez coaching, ha vannak barátaid?

Azt, hogy szakmai konzultációkra szükséged lehet, kézenfekvőbbnek tűnhet, mint az, hogy miért hasznos emellé a coaching is, hiszen vannak barátaid, van családod, aki támogat és meghallgat. Ezt a gyakran ismételt kérdést szeretném most megválaszolni neked.

Már azzal, hogy kimondod, ami foglalkoztat, elmondod valakinek, ami történt a munkahelyeden, csökken a stressz szintje. Tudat alatt ezért is alkalmazzuk a panaszkodást olyan gyakran a mindennapi életünkben, mert instant lehetőséget biztosít a bennünk felgyülemlett negatív érzések csökkentésére, különösen, ha a hallgató fél sajnál minket és egyetért velünk. Miért hasznos a coaching beszélgetés, ahelyett, hogy otthon adnád ki magadból a feszültséget? A munkahelyváltás már önmagában nyomás alá helyezi a családi életet és a párkapcsolatot, az állandóan „hazavitt” munkahelyi feszültség ezt a nyomást csak tovább növeli. Eleinte még türelmes a környezet, de a hónapokig tartó panaszkodás arról, hogy melyik munkatárssal van problémád, vagy milyen szakmai kérdésekre nem találod a megoldást, konfliktus forrása lehet, nem csak a családi, de a baráti kapcsolataidban is. Ki szeretné olyan ember társaságában eltölteni a szabad idejét, aki másról sem tud beszélni, mint az új beosztásával járó nehézségekről, vagy ami talán még rosszabb, meg sem szólal, szinte jelen sincs, mert máshol járnak a gondolatai? Végül a megromlott hangulatért egyenesen a munka, a munkahely, a főnököd vagy a személyes alkalmatlanságod lesz a felelős, kinek-kinek vérmérséklete és önbizalma szerint. Ezért szeretnénk a szakmai konzultációkon túl privát business coaching alkalmakkal is megkönnyíteni neked ezt az időszakot. (A munka és magánélet egyensúlyáról az A&K Magazin szeptember 4-én megjelenő őszi számában olvashatsz majd részletesebben.)

90 napos támogatás az A&K Akadémián

Az Akadémiánkon elérhető első 90 nap szakmai és coaching támogatás nem csak segít csökkenteni a stresszt, gyorsabban alkalmazkodni a kihívásokhoz, de védi is a magánéletedben kialakított egyensúlyt. A munkahelyen felmerülő kérdéseket nálunk szakmai közegben vitathatod meg, és hazaérkezéskor magad mögött hagyhatod a nehézségeket, hogy teljes figyelmeddel a szeretteid felé fordulhass.

Ha nálunk végzel, akkor nem kell attól tartanod, hogy támogatás nélkül kerülsz idegen környezetbe, és végül megbánod a változtatást. Melletted állunk és támogatunk, hogy az elméletben elért siker a gyakorlatban is megvalósuljon!

Forrás: Komócsin Laura – Módszertani kézikönyv coachoknak és coachingszemléletű vezetőknek (2011.)
Ha tetszett, oszd meg!

Java 9 újdonságai – 3. rész

Java 9 linkelés

A Java 9 újdonságai cikksorozat előző részében a Java platform modul rendszeréről olvashattál. Ez az új feature lehetővé teszi alkalmazásaink különböző módokon való telepítését. A Java 9 linkelés új, opcionális statikus linkelési lépést épít be a programunk fordítási lépései közé. De kezdjük az elején!

Java 8 kompakt profilok

Ahhoz, hogy megértsük, milyen új képességekre teszünk szert a Java 9 kibővült eszközkészletével, előbb érdemes megnéznünk az előzményeket.

A Java 8 2014. március 18-án jelent meg, és rengeteg várva várt új nyelvi elemet tartalmazott. A legismertebb talán a funkcionális programozást egyszerűbb formában lehetővé tevő lambda kifejezések és a Stream API volt, de számos más újítás is ezzel a verzióval jelent meg. Ezek egyike volt a kompakt profilok bevezetése (compact profiles).

3 kompakt profilt definiáltak, amelyeknek mérhetetlenül izgalmas neveket adtak:

  • compact1
  • compact2
  • compact3

Java 8 előtt

A Java 8 előtt, amikor lefordítottuk a programunkat, nem volt lehetőségünk megadni a Java fordítónak (javac), hogy ne a Java futtatókörnyezet (JRE) teljes eszközkészletére fordítson, hanem annak csak egy részhalmazára. Ez mondjuk asztali számítógépek esetén ma már nem olyan nagy gond, mert itt bőséges memória áll rendelkezésre, viszont ha a mobil eszközökre gondolunk, már más a helyzet. Itt erősen korlátozottak az erőforrásaink. Nem csak a memória, de a processzor, tárhely, hálózati kapcsolat, akkumulátor is. Ezekre az eszközökre nem lenne célszerű a folyamatosan növekvő teljes JRE-t telepíteni, főleg, ha ki sem használjuk annak képességeit.

Java 8 után

A Java 8-ban viszont már megadhattuk a programunk fordításakor valamelyik kompakt profil nevét, ami a teljes Java futtatókörnyezetnek csak valamilyen részhalmazát tartalmazta. A kompakt profilok kibővítik egymást. A legszűkebb részhalmaz a compact1. A compact2 profil tartalmaz mindent, amit a compact1 és egyéb csomagokat is. Ugyanígy a compact3 tartalmazza a teljes compact2-t és egyéb package-eket is. Hogy melyik profil pontosan mit tartalmaz, azt az alábbi táblázatban láthatod:

compact1compact2compact3Teljes JRE SE
Core (java.lang.*)JDBCSecurity (kerberos, acl, sasl)Beans
SecurityRMIJMXInput Methods
SerializationXML JAXPJNDIIDL
NetworkingXML JAXP (adds crypto)Preferences
Ref ObjectsManagementAccessibility
Regular ExpressionsInstrumentationPrint Service
Data and TimeRMI-IIOP
Input / OutputCORBA
CollectionsJava 2D
LoggingSound
ConcurrencySwing
ReflectionAWT
JARDrag and Drop
ZIPImage IO
VersioningJAX-WS
Internationalization (I18N)
JNI
Override Mechanism
Extension Mechanism
Scripting

Megtakarított tárhely

Hogy legyen egy valós képünk arról, hogy mennyi tárhelyet is takaríthatunk meg a kompakt profilokkal, íme egy rövid mérés:

  • compact1 profil: ~14 MB
  • compact2 profil: ~18 MB
  • compact3 profil: ~21 MB
  • Teljes JRE (Java SE Embedded): ~45 MB

Jól látható, hogy a compact1 profil az amúgy is tárhelyoptimalizált teljes Java SE Embedded kiadás egyharmada csupán.
A kompakt profilok már sokat segítettek a problémán, de még mindig nem jelentettek végleges megoldást.

Java 9 linkelés – linkelési idő

A Java 9 linkelés szemléltetésére szolgáló lánc ábraNéha úgy érzem kár lefordítani magyarra a fontosabb angol szakkifejezéseket. Talán most is jobban tettem volna, ha link time-nak hagyom.

Eddig fordítási időről (compile time) és futási időről (run time) beszélhettünk programjaink kapcsán, amik a szoftverünk életciklusának két különböző fázisa. E kettő közé a Java 9-ben beférkőzött a linkelési idő (link time). A Java nyelv a kezdetektől fogva egy dinamikusan linkelő nyelv volt, vagyis amikor a forráskódot lefordítottuk bájtkódra, akkor csak a külső library-kra való hivatkozások neve került a lefordított gépi kódba. A függőségek a program futtatásakor töltődtek be. Ez lehetővé tette, hogy több Java program is használja ugyanazt a külső library-t.

A dinamikus linkelés mechanizmusában semmi nem változott, ez továbbra is így működik. Amivel a Java 9-ben most már többet tud a nyelv, az az, hogy lehetőségünk van egy opcionális statikus linkelési lépést is beépíteni a programunk életciklusába. Ez a linkelési idő, ami a fordítási idő és futási idő között van, egy statikus linkelési lépés. A statikus linkelés során modulok halmazait és azok tranzitív függőségeit (transitive dependencies) tudjuk linkelni, hogy egy run-time image-et létrehozzunk.

Java 9 linkelés – jlink parancssori eszköz

Mindezt a jlink nevű új, parancssori eszközzel tehetjük meg, az alább demonstrált módon:

 

  • module-path: Ezzel a kapcsolóval specifikálhatjuk a JDK moduljainak elérési útját. Ezek lehetnek JAR fájlok, jmod fájlok (a JDK 9 új fájlformátuma, ami hasonló a JAR fájlokhoz, de tud kezelni natív kódot és java konfigurációs fájlokat is) vagy exploded modulok.
  • add-modules: Modulok, amikre a run-time image-et le szeretnénk generáltatni.
  • limit-modules: Korlátozhatjuk a linkelést csak azokra a modulokra, amikre az alkalmazásunknak mindenképp szüksége van. Néha, amikor modulokat adunk hozzá, akkor azok tranzitív függőségeit is hozzáadjuk. Ezzel a kapcsolóval limitálhatjuk, hogy melyek ezek a modulok.
  • output: A kimeneti elérési út, ahova a generált run-time image kerül.

Konklúzió

Láthatjuk, hogy a Java 9 új, jlink parancssori eszközével a modularizált Java programokat új módokon tudjuk telepíteni, ami számos helyzetben jól jöhet. Annak köszönhetően, hogy a Java 9-ben maga a core csomagok is modularizálva lettek, ha saját projektünket is modularizálva írjuk meg és modularizált külső library-kat használunk, akkor olyan run-time image elkészítése válik lehetővé, ami a korábbi verziókban nem volt kivitelezhető.

Ha többet szeretnél olvasni a jlink használatáról, akkor azt ezen a hivatalos Oracle oldalon teheted meg.

Ha tetszett, oszd meg!

Java 9 újdonságai – 2. rész

Ez a cikksorozat a Java 9 újdonságait taglalja. Az első részben elkezdtük megnézni, hogy a Java 9 modul rendszere miért annyira fontos, milyen problémát hivatott orvosolni. Lássuk most hát a részleteket!

A Java 9 modul rendszere (Jigsaw)

A dunsztos üvegektől nincs menekvés

A JAR-ok – vagyis Java ARchive-ok ( = dunsztos üveg) – nem mások, mint lefordított Java osztályok, némi metainformációval ellátva, ZIP-re tömörítve és .jar kiterjesztéssel ellátva.

A Java 9 modul rendszere ezt a struktúrát a metainformációk terén egészíti ki. Ezentúl a moduláris JAR fájlok rendelkezni fognak egy modul leíróval (module-info.class). Ebben a leíróban meghatározhatjuk, hogy ez a modul milyen más modultól függ. Ezt a következő szintaxissal tehetjük meg:

A kocsi modulunk függ a motor modultól, vagyis ez a kocsi modul nem működőképes motor modul nélkül. Ezt grafikusan a következőképp ábrázolhatjuk:

Java 9 modul rendszer requires példa

A requires-ön túl van egy másik kulcsszavunk is, amit használhatunk. Ez a kulcsszó az exports, amivel azt adhatjuk meg, hogy a modulunk melyik csomagja (package-e) érhető el egy másik modulból. Minden, amit nem nevezünk meg az exports kulcsszóval, az alapértelmezés szerint nem exportálódik, vagyis rejtve marad más modulok előtt. Ez megoldja a bevezetőben említett potenciális kódelspagettiasodást. Ha kiegészítjük az előbbi példánkat ezzel, akkor ezt kapjuk:

Java 9 modul rendszer exports példa

Mi fog történni a Java core osztályaival?

A jó hír az, hogy ezeket is feldarabolták modulokra, így sokkal könnyebben tudják majd a jövőben kibővíteni. Ez azt is lehetővé teszi, hogy az olyan platformokon, ahol szűkösek az erőforrások – például a mobil alkalmazások – ott az adott platformra fordított kódhoz csak a tényleg szükséges modulokat mellékeljük, ezzel tárhelyet, memóriát, hálózati adatforgalmat, vagy akár akkumulátor energiát is megtakarítva.

Amikor elindítunk egy moduláris Java programot, akkor a requires függőségi lánc mentén a JVM ellenőrzi, hogy minden modul megtalálható-e. Ez sokkal kényelmesebb nekünk, mint a korábbi Java verziókban, amikor a classpath paraméterben az összes függőséget fel kellett kézzel térképeznünk és sorolnunk.

Java modul rendszer konklúzió

kirakó ami a Java 9 modul rendszerét szemléltetiEzen új feature-ök segítségével újonnan írt programjainkban újabb szinten megvalósulhat az OOP egyik alapelve, az egységbezárás (encapsulation), aminek az előnyei régóta jól ismertek.

De mint láthattuk, a JAR-októl nem szabadulunk meg, továbbra is ez lesz a formája a library-k tárolásának, csak kibővítették a leíróképességét, ezzel sok új lehetőséget megnyitva előttünk.

Ebben a blog posztban nem sikerült minden részletre kitérni, mint például a névtelen modulokra illetve az automatikus modulokra. Az említett két kulcsszón kívül vannak még egyebek is, amikkel tovább finomítható a modulok összekapcsolása.

Tanfolyamunkon természetesen gyakorlati példákon keresztül megnézzük a legfontosabb lehetőségeit ennek az új nyelvi elemnek.

Ha szívesen olvasnál még többet a Java 9 modul rendszerről, akkor figyelmedbe ajánlom az angol wiki oldalát.

Ha tetszett, oszd meg!

Java 9 újdonságai – 1. rész

Java 9 megjelenési dátuma

A Java 9 aktuális tervezett kiadási dátuma 2017. szeptember 21. Vagyis itt van a nyakunkon. Elég zűrös Java verzióról van szó, ami a határidőket illeti, ugyanis nem egyszer lett elhalasztva a kiadás dátuma. Ez talán nem is olyan meglepő, ha megnézzük, hogy milyen új feature-ök kerültek bele. Az elkövetkezendő blog posztokban sorra vesszük a leglényegesebb újdonságokat.

Java 9 oktatás az A&K Akadémián

Hogy lehet az, hogy mi már ezt a verziót oktatjuk, amikor még meg sem jelent?

A végleges hivatalos verzió még valóban nem jelent meg, de az early access (EA) verzió már egy ideje elérhető, amely mivel már túl vagyunk a feature complete dátumon, az összes feature-t tartalmazza, ami a végleges verzióban is benne lesz.

Be kell vallanom, hogy nagy mázlista vagy, ha most kezded el a Java-t tanulni, mert az egyik feature – a jshell – nagyban segíti az oktatást és a tanulást, főleg a kezdeti lépéseknél, mert nagyon szemléletes eszköz. De erről részletesen majd egy kicsit később. Először akadna itt egy kis játék…

A Java Platform modul rendszere (Jigsaw) – bevezető

Java 9 - Project JigsawA Java 9 legmeghatározóbb eleme a Project Jigsaw néven futó, a Java modularizációját célzó projekt, amely a többszöri release date csúsztatásért felelős.

Én személy szerint nem bánom, sőt, örülök is neki, hogy a projekt fejlesztése során tartott mérföldköveknél őszintén képesek voltak a projekt aktuális állapotára objektíven tekinteni, és azt mondani, hogy ez így nem elég jó.

Mint tudjuk, a Java nyelvnél erősen koncentrálnak a készítők a visszafele kompatibilitásra, vagyis hogy az új Java verziók, amennyire csak lehet, a korábbi verzióval fordított bájtkódot módosítás nélkül futtatni tudják. Persze ez nem volt mindig tartható.

A modularizáció megoldása a Java nyelv jövőjét tekintve esszenciális feladat. Ami most a Java 9-ben a nyelv részévé válik, az ezentúl mindig szerves részét fogja képezni, radikális módosítások eszközölése jelentős problémákat vetne fel. De úgy tűnik, hogy most már hamarosan tényleg lezárják ezt az alprojektet és az éles kiadás részét fogja képezni.

Miről is szól a Java Platform modul rendszere?

Eddig is volt lehetőség megírt kódunk alap szintű szervezésére. Ha arra gondolunk, hogy megírt osztályainkat már most is külön fájlokban tároljuk, illetve ezeket a fájlokat tudjuk csoportosítani mappákba, vagyis csomagokba (package-ekbe).

A modul rendszer lényege, hogy még egy absztrakciós szinttel kiegészítse ezt a csoportosítás.

Miért jó nekünk még egy absztrakciós szint?

Az alapvető probléma a Java nyelv hozzáférés módosítók limitált képességeiből adódik. Mindannyian ismerjük a public, protected, private és package private scope-okat. A public elérhetőségű osztályaink jelentik itt a problémát, ezek publikus metódusai ugyanis a publikus API-nk részét képezik, és ezáltal bármilyen más osztályból elérhetők. Ez a Java nyelv létrejötte óta hatalmas gubancokat okozott már a komplex rendszereknél, ugyanis amit a nyelv megenged, azt bizony a leleményes programozók ki is használják. Így történt ez ennél a nyelvi feature-nél is, ami átláthatatlan, szövevényes, spagetti kódot eredményezett. A spagetti kódnak súlyos hátrányai vannak.

JAR – JAR

A Java 9 előtt lényegében az egyetlen módszerünk az enkapszulációra a JAR-ok voltak. A JAR – vagyis Java ARchive – a programunk lefordított változatának egy ZIP fájlba tömörített változata, amit néhány metainformációval elláthattunk, mint például, hogy melyik osztály main metódusa a belépési pont. Ha például Java-ban JSON adatstruktúrákat szerettünk volna használni, akkor letöltöttük a megfelelő JAR fájlt, amiben minden osztály benne volt a JSON-ök kezeléséhez. Természetesen kedvünkre választhattunk az implementációk közül, mert több csapat is fejleszt saját JSON kezelőt.

Ezek után persze a programunk már csak ezen JSON kezelő JAR jelenlétében működőképes, amikor kiadjuk éles rendszerünket, akkor ezt a JAR-t se szabad elfelejtenünk.

Érdekesség

A „jar” egy angol főnév is, ami többek között dunsztos üveget jelent, amiben a lekvárt is eltesszük. A JAR elnevezés valószínűleg innen is kapta a nevét, csak mi nem lekvárt, hanem lefordított Java osztályokat teszünk el benne.

Dunsztos üvegek… dunsztos üvegek mindenütt!

Egy nagy rendszer esetén természetesen nem csak egy ilyen külső library-tól való függőségünk van, hanem több, illetve tovább bonyolítja a helyzetet, hogy egy külső library maga is lehet, hogy egy másik library-t igényel a működéséhez. Ezeket a függőségeket, más szóval dependenciákat, feloldani sokszor nem triviális feladat.

Eddig mi tévők lehettünk a JAR-ok támadása ellen?

Ennek kezelésére eddig a modern build toolok adtak elegáns megoldást, mint a Maven és a Gradle. Ezeknél a tooloknál ugyanis egy központi repository-ban számon tartják az összes publikus library (artifact) összes publikusan elérhető verzióját azok függőségeivel együtt. Ez lehetőséget biztosít számunka a build tool használata során, hogy csak azt tüntessük fel, hogy a mi aktuális projektünknek milyen külső library-kra van szüksége, és a dependenciák feloldását már maga a tool végezze. Ez azt jelenti, hogy ha például a JSON kezelő library függ egy dátum kezelő library-tól, akkor ha mi a saját projektünknél megjelöljük, hogy a JSON kezelő library-ra szükségünk van, akkor a tool automatikusan felderíti a függőségi láncolatot és feloldja a függőségeket, vagyis ebben az esetben letölti a projektünkhöz a dátum kezelő library-t is, ezzel működőképessé téve a projektünket. A JAR-ok önmagukban ezt a függőséget nem képesek kifejezni.

Ezt a súlyos problémát orvosolja a Java Platform modul rendszere, amelyről a következő blog posztban olvashatsz.

Ha tetszett, oszd meg!