Megtanulni programozni idősebb korban is megéri?

Megtanulni programozni idősebb korban is megéri?

 

programozni idősebb korban szemüveggel a monitor előtt sem gond

 

Legalább hetente egyszer beleszaladok ebbe a kérdésbe, hogy érdemes megtanulni programozni idősebb korban? Úgy is nehéz lenne, vagy teljesen lehetetlen, nem? Nem csak önámítás, ha valaki belevág ilyen idős korban valami teljesen újba?  Azt, hogy érdemes-e megtanulni, nem tudom megválaszolni, mert mindenkinek mást jelent az érdemes. Tanulmányaim alapján azt az oldalát vizsgálom meg ennek a kérdésnek, hogy lehetséges-e megtanulni idősebb korban, és ha igen, milyen feltételekkel, hogyan? Aztán, hogy a befektetett energia, odafigyelés és az új programozói karrier eredményei valakinek megérik-e a ráfordított időt, munkát? Döntse el ki-ki saját maga!

 

Nézzük meg közelebbről, mi is történik a fejünkben!

 

Az agy használat közben folyamatosan átalakul, fejlődik, a neuronok között újabb kapcsolatok alakulnak ki. Kitartó használattal és ismétléssel, ún. „tanulási tréninggel”, ahogy a fizikai testünk más izmai, a tanulási képességünk is szinten tartható, sőt fejleszthető is. Új emberekké válhatunk általa? Nem, semmiképp sem. Megtarthatjuk a tanulási képességünket az idő előrehaladtával? Mindenképp! Lényegében a neuroplaszticitás az agy átalakulási képessége. Az agyunk minden elvégzett feladata során megváltoztatja és átalakítja saját „áramköreit”, idegsejt hálózatát, hogy elősegítse a minél hatékonyabb feladatmegoldást.

Fontos különbség, hogy nem az IQ-ról beszélünk, hanem tanulási képességről és új információk elsajátításáról. A Mensa felmérései szerint „ az IQ 17-20 éves korig fejlődik, intelligenciaszintünk ez után érdemben már nem változtatható. Egész életünk során közel azonos marad. A kognitív tréningnek nagy szerepe lehet idős korunkban a képességeink, szellemi frissességünk megtartásában.” – írja a Mensa a saját honlapján. Tanulni tehát érdemes, már csak a hanyatlás megelőzése miatt is. Hogy programozást-e? Ha az érdekel, akkor igen, azt!

 

neuronok illusztráció

 

Mi is az a tanulási vagy kognitív tréning?

 

A gondolkodási sebesség az életkorral természetszerűleg csökken. Ez szoros kapcsolatban áll azzal, hogy egyre kevésbé mozgatjuk a szemünket, ahogy idősödünk. Kb. ötödére csökken a szemmozgás tinédzserkortól nyugdíjas korig. Ez egy természetes folyamat. Ám ahogy az időskori elhízás is megelőzhető, még ha tudatosabb odafigyelést is igényel, úgy a mentális tréning is napi szinten alkalmazható agyunk mozgásban tartásához. A felismerési, gondolkodási sebességen tudatosan javíthatunk, bármilyen életkorban!

Hogyan? Kitartó gyakorlással, edzéssel, olyan gyors döntést és reakcióidőt igénylő játékokkal, melyek valódi kihívást jelentenek számunkra. Szóval, ha a gondolkodási sebességeden akarsz javítani, akkor ne keresztrejtvényt fejts, hanem csatlakozz mondjuk egy jó kis online játékhoz, ahol gyorsan kell dönteni és ami lehetőleg időre megy, hogy tudd mérni a teljesítményed! Hajrá! Már napi 20-30 perc edzés meg fog látszani a teljesítményeden, néhány hét után. Próbáld ki és mesélj róla kommentben, ha van kedved!

Nem szereted a PC játékokat? Semmi probléma, nem kell a gép előtt ülnöd! Akkor keress valami jó kis kézügyességet igénylő, gyors játékot, mondjuk zsonglőr trükköket, kislabda dobálást, először 3, majd 4, sőt 5 labdával! „A zsonglőrködés javítja a gondolkodási sebességet és segít a fókuszálásban is, tehát összességében nagyon jó az agynak.” – Dr. Nicholas Price, neuroscientist, Monash University.

 

labdát fején egyensúlyozó férfi zsonglőr

 

Mitől függ, hogy valamit meg tudunk-e jegyezni?

 

Ahhoz, hogy erre megkapjuk a választ, tudnunk kell, hogy az emlékezetnek több fajtája létezik. Attól függően, hogy egy emlék, legyen szó eseményről vagy egy új, idegen szóról, mennyi ideig marad meg az emlékezetünkben, elkülöníthetünk

  • rövid távú emlékezetet, mely néhány percig vagy óráig tart
  • hosszú távú emlékezetet, mely néhány órától kezdve akár hónapokig is kitarthat
  • és tartósan fennmaradó emlékezetet, mely akár évekig is tartósan tárolja az információkat.

Az új információk tartós megjegyzése időfüggő folyamat.” (McGaugh, 2000) De vajon miért nem jegyzünk meg valamit azon nyomban, ahogy találkoztunk vele? Miért kell várni, ismételni?

 

Miért kell tanulni?

 

Azért, mert az átmenetileg tárolt információk a rövid távú emlékezetben foglalnak helyet, és a hosszú távú emlékezetbe jutásukhoz az agyunkban levő idegsejtek szinapszisainak átalakulása szükséges. Össze kell hangolódniuk, át kell alakulniuk, ehhez pedig időre és ismétlődésre van szükség, hiszen csak olyan kapcsolatokat érdemes kialakítania, amelyekre az egyénnek bizonyítottan szüksége van. Ha ismételten találkozik egy-egy problémával, kialakítja a kapcsolatokat, mert úgy ítéli meg, ez a tudás fontos a túléléshez, előre jutáshoz. Viccesen úgy is fogalmazhatunk, hogy azok a sejtek, amelyek együtt működnek, “együtt is tüzelnek“, ennyire összehangolódnak.

Tehát nem mindegy, hogy mennyi ideig foglalkozunk egy adott információterülettel? Bizony nem. Hebb szerint “minél tovább tart a rövid idejű emlékezet reverbációja (* a sejtszintű átalakulás), annál nagyobb valószínűséggel alakul ki tartós emlékezet.” (Hebb, 1972)

emberi agy

 

Ezért nem mindegy, hogy 3 hónapos gyorstalpalón próbálsz meg megtanulni programozni, vagy egy 1 éves, tudatosan felépített képzésen. Mi ezért nem indítunk rövid, nagy intenzitású tanfolyamokat, mert biztosan tudjuk, hogy nem éred el azt a tartós eredményt, amire valójában vágysz.

Ha ez a téma bővebben is érdekel, írtunk róla korábban nyelvtanulással foglalkozó társoldalunkon, az A&K Nyelvtanulás oldalon. A blogbejegyzést itt érheted el: A rövid tanfolyamok tényleg nem hatékonyak?

 

Fókusz és a figyelem fenntartása

 

Érintettük a fókuszálás kérdését is. Nem véletlenül, hiszen programozóként talán ez az egyik legnagyobb fegyvered, ha a munka világában hadba készülsz. Még a tanulási sebességnél is fontosabb az, hogy kitartóan tudj fókuszálni. Az, hogy mennyi ideig tudsz koncentrálni, megalapozza a munkahelyi eredményességed, és hosszú távon a karriered is. Ez álljon most itt nem csak az idősebb, de fiatalabb generációk számára is, mert, ha valamivel, akkor a fókusszal mindannyiunknak dolgunk van manapság!

Egy számítógépes rendszer legbecsesebb erőforrása ma már nem a processzora, a memóriája, a merevlemeze vagy a hálózat, amelyiknek tagja, hanem az emberi figyelem.” – David Garlan, Carnegie Mellon University, Professor of Computer Science.

Daniel Goleman, amerikai pszichológus, az érzelmi és társas intelligencia kutatója szerint a koncentrációt zavaró tényezőknek két alapformája van: az érzékszervi és az érzelmi.

 

Miért fontos ezeket ilyen részletesen tudni?

 

Mert mindkettőért tehetünk, tudatosan! Nagyon fontos szempont, hogy a koncentráció javításához nem a fókuszálás képességét kell növelnünk magunkban valami csoda folytán. A titok a természetes figyelmünket megzavaró, egyéb tényezőkben rejlik. Nem figyelnünk kell jobban megtanulni, hanem „ki kell tudnunk zárni mindent, ami a figyelmet megzavarhatja.” – Dr. Stephen Macknik, Director of Behavioural Neurophysiology, Barrow Institute.

Ha ez fizikai, mondjuk hang vagy fényhatás, akkor az ellen kell tennünk. Ezek könnyen azonosítható és megszüntethető környezeti hatások. Ezért látható például sok programozó fején fejhallgató a munkahelyen is. Tudatosan kizárják a zavaró hatásokat és így eredményesebbek a munkájukban. (Feltéve, ha megfelelő önismerettel választanak hallgatnivalót hozzá.)

 

női programozó fejhallgatóval

 

Ha érzelmileg érintett meg minket egy esemény, akkor pedig azt kell helyre tennünk. Ez nem csak negatív esemény lehet, mint például egy baleset. Egy jól sikerült randi vagy egy új kisállat érkezése a családba is okozhatja a fókuszálási képességünk csökkenését. A fontos az érzelmi érintettség és a hatás a lelkünkre nézve. Épp ezért állok végig a tanulók mellett a képzés során, ha úgy érzik, érzelmileg szükségük van támogatásra. Ez nem jelenti azt, hogy folyton követem őket, hétről-hétre. Nem az én tisztem eldönteni, kinek-mikor van szüksége az érzelmileg zavaró tényezők kizárására. De már a tanévnyitón ott vagyok és jelzem, hogy ha bármikor a jövőben szükségük van rá, keressenek meg! Ha nem megy jól a munka és ennek érzelmi okai vannak az életedben, kérj segítséget egy számodra szimpatikus szakembertől!

 

Milyen előnyei vannak, ha valaki idősebb korban tanul?

 

Nem csak, hogy nem hátrányos, ha valaki felnőtt korban vág bele a tanulásba, de sok szempontból tapasztaltabb és rutinosabb is, mint fiatalabb társai. Ezeket az előnyöket ismerve és tudatosan használva életkorod a saját céljaid elérésének szolgálatába állíthatod. Ennek ismerete nem csak a tanulás és később a munka során fontos. Önbizalmat és tartást adhat számodra az állásinterjúkon is.

Nézzük tehát, milyen előnyöd is származik abból, hogy több mindennel foglalkoztál már korábban!

A korábban megszerzett tudás:

  1. elősegíti az osztályozást: könnyebben tudsz már meglevő tapasztalatokhoz új információkat kötni
  2. a figyelem felnagyítja számodra egyes ingerek hatékonyságát: előbb észreveszed a megoldást
  3. segít a szenzoros információ megszerzésében: mintha nyomra bukkannál, tudattalanul is jó irányba kezdesz el keresgélni
  4. segít neked kontextust adni a szenzorosan bejövő információknak: nem lógnak a levegőben azok a dolgok, amelyekkel találkozol

(Robert Sekuler, Professor of Neuroscience, Brandeis University, Boston.)

 

készésgek színes illusztrációja

 

 

Mi a konklúzió?

 

Megéri programozni tanulni idősebb korban? Te mit gondolsz? Összefoglalóan elmondhatjuk, hogy ha vágysz egy bizonyos tudás megszerzésére, ne mondj le róla csak azért, mert erre nem 16 évesen jöttél rá! Meg tudod csinálni, csak tenned kell érte, tudatosan tervezve, edzve a mentális izmaidat. Az állásinterjún pedig minden pozitív tulajdonságod tudatában, bátran képviseld az életkorod, mert igenis büszke lehetsz rá!

 

 

 

Források:

https://mensa.hu/az-iq-rol/gyakori-kerdesek-az-intelligenciarol

Daniel Goleman: Fókusz, Libri Kiadó, Budapest, 2013.

David Garlan: „Toward Distraction-Free Pervasive Computing”, Pervasive Computing 1, no. 2 (2002): 22-31.

Redesign My Brain series – Dr. Stephen Macknik – Director of Behavioural Neurophysiology, Barrow Institute, 2013.

Csépe Valéria – Általános pszichológia 1. – Tanulás, emlékezés, tudás, Osiris Kiadó, Budapest, 2007.

Robert Sekuler, Randolf Blake – Észlelés, Osiris Kiadó, Budapest, 2004.

Ha tetszett, oszd meg!

Java programozó fizetés

 

Junior Java programozó fizetés és az ehhez szükséges készségek

– valódi számok, Magyarországon, Budapesten –

 

Java programozó pénzt számol a gép előtt

 

 

A Java programozó fizetés az elmúlt években folyamatos emelkedést mutat. Az amúgy is átlag feletti több százezres kezdő fizetések a milliót is meghaladják már akár 5 éves szakmai tapasztalat után. Jelenleg egy jól képzett és magabiztos Junior Java programozó megfelelő egyéb készségek birtokában elérheti a bruttó 400 ezer forintos kezdőfizetést. Igen, 2019 elején, Magyarországon, alkalmazotti jogviszonyban. Ha valaki egyéni vállalkozóként teszi mindezt, vagy akár külföldön vállal munkát, ez a szám még magasabbra emelkedhet.

 

Java programozó fizetés táblázata havi bruttó összegekkel

 

A mindenhonnan visszhangzó piaci sikolyok, mi szerint nagy a hiány jó programozókból, kombinálva a csillagászati magasságokba emelkedő havi bérekkel és juttatásokkal, valóságos tömegeket vonzanak a pályára. Igen ám, de ilyen mértékű képzés és átképzés mellett hogyan lehetséges az, hogy a hiány folyamatosan fennáll és egy kezdő Java programozó fizetés ilyen magasra rúghat havi szinten? Nos, ahogy András, az A&K Akadémia alapítója szokta mondani, „junior és junior között hatalmas különbségek tudnak lenni”, és a valódi, igazán jó, és önmagát hatékonyan továbbfejleszteni képes Java programozóból valóban hatalmas hiány van a piacon. Az A&K Akadémia képzésein úgy állítottuk össze az egyes modulokat, hogy minden szükséges készséget fejlesszünk a nálunk töltött 1 év alatt, hogy a nálunk végzettek a lehető legjobb esélyekkel vághassanak bele az állásinterjúkba a képzés végeztével (sőt, néha már korábban is).

 

Milyen készségek szükségesek ahhoz, hogy ez a Java programozó fizetés elérhető legyen számodra?

 

Úgy gondoljuk, hogy minél magabiztosabb és komplexebb készségrendszerrel rendelkezel, annál gyorsabb és látványosabb sikereket érhetsz el a programozói karriered során. Ahhoz, hogy jobban átláthassuk, melyek a nélkülözhetetlen és melyek a különlegességnek számító készségek Junior szinten, érdemes csoportosítanunk a skill-eket. Ezt a csoportosítást nem önkényesen tesszük. A nagyobb cégek 3 fordulós felvételi interjúja is azt bizonyítja, hogy ők is tudatosan mérik mindhárom készségcsoport meglétét és szintjét.

 

Hard skills

 

Az ún. hard skillek a konkrét szakmai tudásod foglalják csokorba és mint legfontosabb készségek alapvető hatással vannak a kezdő Java programozó fizetés alakulására. Értelemszerűen Junior Java Programozóként nélkülözhetetlen a stabil és alapos Java SE ismeret, de a kapcsolódó technológiáké sem hanyagolható el! Ilyenek az adatbázis kezelés, hibajegykezelő szoftverek ismerete, kollaborációs szoftverek használatában való jártasság, integrált fejlesztői környezet magabiztos használata. Nélkülözhetetlen a verziókezelő rendszerek ismerete, a HTML, CSS, és a JavaScript alapok, stb. Minél szélesebb körű jártasságra teszel szert, annál rugalmasabban tudnak elhelyezni majd az egyes projekteken a munkáltató cégek. Ilyenformán érdemes a hard skill-ek fejlesztésére minél több időt fordítanod a tanulmányaid során.

 

modern óra egy férfi karján

 

 

Nyelvtudás

 

Komolyabb cégekhez a felvételi interjú már Junior szinten is tartalmaz angol nyelvi szintfelmérőt. Egy stabil és magabiztos, legalább középfokú angol nyelvtudás hiányában a jelentkező hátrányba kerül a többi felvételizővel szemben. Ha mégis sikerül felvételt nyernie lassabban tud szakmailag is fejlődni, mivel a magasabb szintű szakmai anyagok javarészt csak angol nyelven érhetőek el. A munkáltató számára is korlátozottak a lehetőségek a fejlesztő elhelyezésével kapcsolatban, különösen ha külföldi megbízásokról is szó van. Ez idővel a karrierút alakulásában és a fizetés stagnálásán is meglátszik. Feltétlenül javasoljuk, ha eddig még nem tetted, fejleszd ezt a készséged is mielőbb!

 

Soft skills

 

A Soft skills-ről, vagyis soft készségekről szerencsére egyre több szó esik napjainkban, bár még mindig jóval kevesebbszer kerül elő, mint amennyire fontos a szakmai előrehaladás szempontjából. A félreértések is gyakoriak ezen a téren. Sokszor hallom, hogy a Soft skillek nem mások, mint hogy „hogyan játsszam meg magam, hogy szimpi legyek másoknak”.

 

Tényleg ezek a Soft skillek?

Tény, hogy fontos a munkatársaink és főnökünk szimpátiája ahhoz, hogy nyugodt és kiegyensúlyozott légkörben dolgozhassunk a munkahelyünkön. A Soft készségek azonban ezen a szinten jóval túlmutatnak. Nem csak az asszertív kommunikáció, de a prezentációs készség fejlesztése, az etikett és netikett ismerete és korrekt használata, a rugalmas csapatmunka, vagy akár az érzelmi intelligencia fejlesztése is kiemelkedően fontosak a sikeres IT karrier szempontjából. Ezeket pedig egyedül, otthon, szobád magányában igencsak bajosan lehet fejleszteni, de legalább ennyire kényelmetlen a 15-30 fős nagy csoportokban egyéni előrehaladást és személyre szabott tanácsokat kapni ezen a téren. Többek között ezért is húztuk meg képzéseink létszámát 6 főnél. Kényelmes, nyugodt légkört biztosít személyes készségeid fejlesztéséhez, megfelelő mennyiségű és minőségű visszajelzés adására ösztönöz, de nem veszel el a tömegben. Ezenkívül jó szívvel ajánlom kis csoportos, kifejezetten soft készségek fejlesztését célzó önismereti fókuszú csoportjainkat is.

 

Mennyi idő mire ezeket a készségeket megfelelő szintre fejleszti valaki?

 

Nos, sem a hard sem a soft skillek, de még a nyelvtudás sem genetikailag meghatározott bennünk. Ha valaki elszánt és elkötelezi magát a folyamatos fejlődés mellett, jelentős változásokat érhet el a karrierjében és a magánéletében egyaránt. Ahhoz, hogy valaki elérjen minden készségből egy stabil Junior Java Programozó szintre, amellyel nyugodt szívvel pályázhat meg nyitott pozíciókat akár nagyobb multinacionális cégeknél is, véleményünk szerint átlagosan legalább 1 évre szükség van. Igen, ez egy hosszú út.

 

férfi úton sétál

 

Ez nem csak azt jelenti, hogy a képzésre járva közösen tanulunk egy évig, de azt is, hogy a fejlődésében elkötelezett tanuló napi szinten min. 1-2 órára időt szán a tanultak gyakorlására, újabb kérdések megfogalmazására. Nem hiszünk a villám tanulásban, ahogy a gyors személyiségváltozásban sem, hacsak nem trauma idézi elő, de nyilván, ez nem célunk. A készségszintű, rutinos programozás elsajátítása időt, kitartást és rendszeres gyakorlást igényel. A társas készségek folyamatos gyakorlásához szintén időre és helyzetgyakorlatok átélésére van szükség. A kiemelkedő Java programozó fizetés eléréséhez pedig minden készség egyidejű, rutinszerű alkalmazása szükségeltetik.

 

Mi tartja fent a motivációt hosszú távon?

 

Tehát a Junior szint eléréséhez is minimum 1 év elkötelezett tanulásra van szükség, de ennek elérése után sem állhat meg a programozó a fejlődésben. Az IT az egyik legdinamikusabban fejlődő iparág, szinte 2-3 év alatt is hatalmas változásokon megy át a szakma. Ahhoz, hogy lépést tudj tartani ezzel a irgalmatlan mértékű fejlődéssel, folyamatosan tovább kell képezned magad. Megint csak Andrást tudom idézni: „Nem telhet el nap tanulás nélkül.”  Számomra ő hiteles példája ennek, mert közel 15 év programozói tapasztalattal, cégvezetéssel és családdal a háta mögött is minden nap szán időt a tanulásra és fejlődésre.

 

De mégis hogyan maradj motivált évekig?

A folyamatos tanuláshoz szükséges motiváció megőrzéséhez azonban több kell, mint jó fizetés. Tény, hogy sokat jelent a kiemelkedő bérezés, és ezt tudva minden cég megfelelő juttatásokkal igyekszik motiválni a magasabban képzett programozókat. Felmérések szerint fontos helyen áll még az izgalmas feladatok elvégzése, a modern technológia alkalmazása és a jó munkahelyi hangulat is. Meglepően keveseket motivál azonban a sok utazási lehetőség vagy a munkahelyi dress code bevezetése.

 

Mit tehetsz te magad a saját motivációd fenntartásáért?

Coachként úgy tapasztalom, hogy az igazán hatékony önmenedzselés alapja az önismeret és a pontos értékek és motivációk felmérése. Ha saját magad szeretnéd motiválni, akkor fel kell derítened azokat a szempontokat, melyek téged személy szerint mozgásban tartanak. Tisztában vagy ezekkel? Tehát, ha most felteszed magadnak a kérdést, hogy Mondj 10 okot, miért akarsz programozó lenni?, akkor már sorolod is a válaszokat? Ha ez nincs így, egyéni coaching keretein belül megfejtheted a saját miértjeidet, melyekből aztán később, nehezebb időszakokban sikerrel meríthetsz erőt, mert nem a hogyan a valódi kérdés, hanem a miért. Ha megvan a miért, meg lesz a hogyan is!

 

Java programozó fizetés emelkedéséhez szükséges tanulást motiváló tényezők

 

Most, hogy tudod, mit kell tenned, mi lesz a következő lépésed?

 

Ha úgy érzed, szeretnéd megosztani velünk saját véleményed a kezdő Java programozó fizetés alakulásáról és az ehhez szükséges készségekről, ne habozz és írj nekünk itt kommentet, vagy üzenetet az info@ak-akademia.hu címre!

 

 

 

A cikkben megjelenő számadatok és képek forrásai:

HWSW és a Microsoft közös kutatása (2014)

Hays Salary Guide (2108-2015)

mennyitkeresel.hu felmérése 2016

Ha tetszett, oszd meg!

Programozás nőknek

Való-e a programozás nőknek?

 

Programozás nőknek fotókollázs programkóddal és női ajkakkal

 

Ha mondta már valaki, hogy nem, úgy egy gyakran emlegetett sztereotípiával találkoztál. Szeretnénk ebben a bejegyzésben kicsit körül járni a dolgot. Az IT szektor a munkapiac legdinamikusabban fejlődő része. Érdemes megnéznünk, mi a helyzet a legmagasabb bérek világában, és miért nem könnyű női kalandoroknak járni a vidéken.

 

Az ember szeret kategorizálni, személyes tapasztalatait kivetíteni másokra is, főleg, ha az élmény negatív. Nem segít ezek feloldásában, hogy a mindenki számára fogyasztásra kínált kulturális javak jórésze ráerősít ezekre a berögződésekre. Most tegye a szívére a kezét a kedves olvasó, és mondja, hogy még sosem hallotta filmben, ismerősétől egy szerelmi csalódás után, hogy “minden férfi/nő egyforma”. Akkor nézzük csak, miért is nem való a programozás nőknek?

Már gyerekkorunkban látunk magunk előtt mintákat. Azonosulunk velük. Anyu tipikusan ezt csinálja, apu meg tipikusan azt, a kislányoknak az oviban babázni kell, a fiúcskáknak meg LEGO-zni. Nemüktől függően mást hallanak a gyerekek. Egy kislánynak nem illik piszkosnak lenni, csúszni-mászni a sárban. De ha kisfiús a család? Akkor jó a gyerek, ha talpig maszatos. Egy fiú fedezze fel a világot! Másszon fára! Rosszalkodjon kicsit. A lányka maradjon a házban, meg ne fújja a szél. Ezek később csak tovább erősödnek. Deviánsnak minősül, aki máshogy viselkedik.

A reálos tárgyak megkövetelik az analitikus gondolkodást. Ezt a készséget erősítik a fiúsnak titulált gyerekkori tevékenységek, így az iskolában már előnye mutatkozik az egyik nemnek. Női oldalról viszont kompenzálni kell a kiesett időt, energia befektetést, hogy a szakadék áthidalhatóvá váljon. Ha nincs olyan motívum, ami ezt támogatná, kisebb eséllyel választ karriert egy nő a számára távoli területen. Tovább mélyíti a szakadékot, hogy a női feladatok körébe tartozó gondoskodással kapcsolatos tevékenységeket pedig ajánlják is a lányoknak. A pozitív megerősítés így vonzóbbá teszi a közszféra kínálta munkalehetőségeket, és kisebb a valószínűsége annak is, hogy vezető pozíciót pályázik egy nő.

 

Női kezek egymáson

 

Magyarországon tipikus női szerep a gyerekekről és idősekről való gondoskodás.

 

A családokban ez a feladat legtöbbször a feleségre hárul. Nem csak saját idős szüleiről, de párja családjáról egyaránt irányul felé az elvárás. Az A&K Magazin 15. lapszámában írtunk arról a szociológiai tanulmányról, ami a közép-kelet-európai háztartási munkaterheket mérte nemenként bontva.

Vannak tehát íratlan szabályok, amiket elfelejtünk felülvizsgálni, pedig lehet, hogy már inkább csak akadályoznak, mint segítik mindennapjainkat. Így amellett, hogy a fiatalkori szocializáció is azokat a szerepeket erősíti, melyekre a nő fokozatosan készül fel, később egy dinamikusan fejlődő iparággal lépést tartani, folyamatos továbbképzést, jelenlétet, extra időt ráfordítani egy nő életében kevesebb lehetőség van.

 

Hazánkban a mai napig dívik az elképzelés, hogy a nőnek otthon a helye.

 

De a legtöbb család ezt nem engedheti meg magának. Ahol pedig mindkét fél dolgozik, a második műszak terhei nem csökkennek a feminin oldalra nézve. A munkáltató részéről segítséget jelenthet, ha részidős helyeket kínál, elérhetővé teszi a home office lehetőségét, tolerálja, pártolja, ha a férfi munkavállaló vesz ki szabadságot például, ha beteg a gyermeke.

Ha sikerül is elhelyezkedni, a pályaelhagyók között több a nő, mint a férfi. A sokak számára vonzó, modern munkahelyek amolyan „boys’ club” hangulatot képviselnek. Itt egy nőnek nehezebb érvényesülnie, kevésbé érzi, hogy azonosulni tud a közösen képviselt értékekkel.

A téma mindenképpen több figyelmet érdemel. Novemberben az ELTE Társadalomtudományi Karán volt egy érdekes program. A Digitális Szociológiai Kutatóközpont szervezte kerekasztal beszélgetés résztvevői Gregor Anikó, Turcsányi-Szabó Márta, Vásárhelyi Orsolya, Verdes Balázs vettek részt, a beszélgetést Dessewffy Tibor moderálta. Az esemény címe egy jó nagy kérdőjellel a végén: Rögzülnek-e a korábbi nemi egyenlőtlenségek az információs korban?

 

Erről a következő hetekben egy háromrészes beszámolóval jelentkezünk, ahol ki tudjuk bontani az érintett témákat.

Ha tetszett, oszd meg!

Eclipse gyorsbillentyűk – produktivitási tippek Java fejlesztőknek

Bevezető gondolatok

Az Eclipse gyorsbillentyűk a segítségedre lesznek!

Rohanó világban élünk, szokták mondani. Az üzleti szférában sokszor az nyer, aki gyorsabb, aki hamarabb képes piacra dobni egy terméket. A különbféle kütyük nagyban tudnak segíteni nekünk, hogy gyorsabbak legyünk. Gondolj csak a mosógépre, mosogatógépre, porszívóra, de akár a telefonra vagy a számítógépre! Elvégeznek olyan munkákat, amiket ha nekünk saját kezűleg kéne, akkor tovább tartana. Időt spórolnak nekünk, így több időnk marad más, számunkra fontosabb dolgokra.

Ez a helyzet az informatikai eszközök esetén is fennáll. A számítógép egy ezen kütyük közül, ami segít nekünk munkánkban, kikapcsolódásunkban. Persze tudni kell rendesen kezelni. Míg egy porszívó kezelése viszonylag triviális dolog, a számítógép jóval összetettebb, így több a hibalehetőség is. Biztos vagyok benne, hogy te is tapasztaltad már, hogy bár az életünk segítése a számítógép célja, mégis néha inkább megnehezíti azt: túl lassú, nem azt teszi, amit szeretnénk, kék halált hal, General Protection Fault, stb.

A helyzet reménytelen, de nem súlyos.

Mit tehetünk?

Érdemes minél jobban megismerkednünk az eszközzel, amit használunk. Hiába van nálunk egy svájci bicska, ha fafűrészeléshez a kést használjuk. Ugyanez a helyzet a programozásban is fennáll. Az Eclipse – ahogy a többi IDE – feladata, hogy megkönnyítse életünket, könnyebbé, hatékonyabbá tegye a szoftverfejlesztést. De hiába áll rendelkezésünkre az az ezernyi kis segítség, ha nem is tudunk a létezésükről és ezért nem használjuk.

A kódminőség fontos

Összetett fogalom a hatékonyság, ezernyi tényező beleszámít, de lényegében egy sebességszerű fogalomról beszélhetünk. A sebesség nem más, mint adott idő alatt megtett út. Fontos persze, hogy először kitűzzük, hogy hova is megyünk, mert különben ha rossz irányba tesszük meg az utat, az mit sem segít hosszú távon. Így van ez a programozásban is. A cél, és egyben az egyik legnagyobb kihívás manapság a programozói szakmában, az a minőségi szoftver elkészítése gyorsan. Ellentmondásosnak hangzik, pedig nem az, csak rendszerben kell szemlélnünk a dolgot. Ahogy az algoritmuselméletből is tudhatod, nem mindig a mohó algoritmus vezet a globális optimumhoz. Ha az a cél, hogy a világ legmagasabb pontját elérjük, akkor általában nem jó megoldás azt a taktikát követni, hogy mindig menjünk arra, amerre a legjobban emelkedik az út. Ez a mohó megközelítés – jelen helyzetemben – a Gellért-hegyre (235 m) vinne, ami bár lokális optimum, mégis mily messze van a globális optimumtól, a Csomolungma (8 848 m):

A célt akkor hát tudjuk: minőségi szoftvert produkálni minél hamarabb. Két fontos tényezője van: 1. minőségi, 2. gyorsaság. Mindkettőt mérhetővé lehet tenni. Angolul az előbbit code quality-nek, utóbbit productivity-nek hívják.

A kódminőséget az ISO/IEC 25010:2011 szabvány írja le. Egy kód akkor számít jónak, ha eleget tesz a specifikációnak, könnyen olvasható és ezáltal módosítható, kiegészíthető, könnyen karbantartható. Ezt magasszintű programozási ismeretekkel, best practice-ek ésszerű követésével lehet leginkább elérni, sokat számít a szakmai tapasztalat ebben. Ennek fejlesztéséhez kitartó tanulásra lesz szükséged.

A hatékonyság növelése

A produktivitást ennél jóval könnyebb növelni, ha megismered a rendelkezésre álló eszközeidet és azok képességeit. Legjobb barátod a nagybetűs Fogyatkozás, avagy az Eclipse. Igen, a másik barátod a Google, de őt most kicsit tegyük félre! Ebben a pillanatban jelent meg (tényleg!) az Eclipse következő verziója az Eclipse Photon, amivel kapcsolatban szeretnék megosztani veled néhány újdonságot, illetve általános, Eclipse-szel kapcsolatos jótanácsokkal is szeretnélek ellátni, amik nekem személy szerint sokat segítenek a mindennapi programozói munkám során.

Eclipse gyorsbillentyűk

A legnagyobb eredményt az úgynevezett gyorsbillentyűk (hot key vagy más néven keyboard shortcut) megismerésével tudod elérni, aminek bár eleinte van egy kis tanulási görbéje, bőven megtérül. Ahogy az angol elnevezés jól mutatja, egy shortcut-ról, vagyis egy rövidebb útról van szó, ami hamarabb célba juttat. Az általános kijelölés, másolás, beillesztés lépéssorozatot biztos vagyok benne, hogy te is ismered, ráadásul ennek kivitelezéséhez az univerzális Ctrl + C és Ctrl + V gyorsbillentyűket is valószínűleg használod.

A következő táblázatban összefoglaltam a tapasztalt programozók által leggyakrabban használt billentyűkombinációkat. A billentyűparancsokat balról jobbra olvasva tudod te is kivitelezni, a pluszjel a gombok egyszerre történő lenyomását jelenti. Némely ezek közül más alkalmazásokban is használható, főleg a kurzor navigációjával és a kijelölésekkel kapcsolatosak.

GyorsbillentyűHatása
nyílbillentyűkKurzor navigálása egy karakterrel az aktuális pozícióból kiindulva a nyíl irányába.
Ctrl + CElőzetesen kijelölt szöveg másolása a vágólapra a memóriában.
Ctrl + VA kurzor aktuális pozíciójához a vágólap tartalmának a beillesztése.
Shift + nyílbillentyűkA kurzor aktuális állásától a nyílbillentyű irányába szöveg kijelölése.

A le és fel irányba történő kijelölés egész sorokat jelöl ki.

Ctrl + nyílbillentyűkKurzor navigálása az adott irányba egy szövegegységgel.
Ctrl + Shift + nyílbillentyűkKijelölés a kurzor aktuális helyzetétől szövegegységekben a lenyomott nyílbillentyű irányába.
Ctrl + AMindent kijelöl az aktuális ablakban.
Ctrl + SAz aktív szerkesztő ablak módosult tartalmának mentése.
Ctrl + Shift + SAz összes megnyitott szerkesztőablak módosult tartalmának mentése.
Ctrl + szóközA kurzor aktuális pozícióján tartalomkiegészítés kérése. Az adott ponton releváns szövegrészeket ajánl fel.
Ctrl + Alt + fel- vagy le nyílbillentyűAz aktuális sor másolása az aktuális sor felé vagy alá, ha több sor is ki volt jelölve, akkor az összes kijelölt sor másolása a megadott irányba.
Alt + fel- vagy le nyílbillentyűAz aktuális sor mozgatása felfelé vagy lefelé, ha több sor is ki volt jelölve, akkor az összes kijelölt sor mozgatása a megadott irányba.
Ctrl + Shift + XA kijelölt szöveg csupa nagybetűssé konvertálása.
Ctrl + Shift + YA kijelölt szöveg csupa kisbetűssé konvertálása.
Ctrl + Shift + CAz aktuális sor ki- vagy visszakommentezése, ha több sor is ki volt jelölve, akkor az összes kijelölt sor kommentezésének váltása.
Ctrl + Shift + RFájl megnyitása tetszőleges workspace helyről, annak nevének egy részének megadásával.
Ctrl + Shift + TTípus megnyitása tetszőleges workspace helyről, annak nevének egy részének megadásával.
Alt + Shift + RA kurzor pozícióján található típus, metódus vagy változó átnevezése annak minden hivatkozásával együtt.
Alt + Shift + LA kijelölt kódrészlet kiemelése egy új helyi változóba, a változó nevét a felugró ablakban adhatjuk meg.
Alt + Shift + MA kijelölt kódrészlet kiemelése egy új metódusba, a metódus nevét a felugró ablakban adhatjuk meg.
Ctrl + OKivonat az aktuálisan megnyitott típus tagjairól. Újbóli megnyomása hatására az örökölt tagok is megjelenítésre kerülnek.
Ctrl + Shift + OAz aktuálisan megnyitott típus import deklarációinak rendszerezése, a nem használt importok törlése, a hiányzó importok hozzáadása. Ha nem egyértelműen állapítható meg az importálni kívánt típus, akkor felugró ablakban lehetőséget kínál a találatok közül a megfelelő kiválasztására.
Ctrl + Shift + FAz aktuálisan megnyitott típus forráskódjának formázása, ha előtte kijelöltünk egy kódrészletet, akkor csak a kijelölt rész formázása.
Alt + Shift + SA Source menü megnyitása egy felugró ablakban, ahonnan lehetőségünk van a következő kódrészletek legenerálására:

  • metódusok felülírása
  • getter és setter metódusok generálása
  • delegáló metódusok generálása
  • hashCode() és equals() metódusok generálása
  • toString generálása
  • konstruktor generálása mezőkből
  • konstruktorok generálás ősosztályból
Ctrl + F11Az aktuálisan megnyitott program futtatása.
F11Az aktuálisan megnyitott program futtatása debug üzemmódban.
F6Debug üzemmódban a jelölt sor utasításának végrehajtása és lépés a következő utasításra azonos szinten.
F5Debug üzemmódban a jelölt sor utasításának végrehajtása úgy, hogy ha további metódushívást tartalmaz, akkor belépés egy hívási szinttel mélyebben.
F7Debug üzemmódban a jelölt sor és az utána lévő sorok utasításainak végrehajtása és lépés az előző hívási szintre.
F8Debug üzemmódban a program futtatása a következő breakpoint-ig.

Eclipse kódbányászat

Bár az új Eclipse Photon verziónak alapból nem része, legalábbis a mostani június release-nél, mégis említésre méltó bővítmény a JDT CodeMining. Segítségével az IntelliJ IDEA IDE-ből már talán általad is ismert feature-ök használhatók az Eclipse projekteknél. Ilyen például az osztályok és metódusok előtt megjelenő referenciaszámláló, vagy a metódusparaméterek nevének vagy típusának megjelenítése. A referenciaszámláló kattintható, aminek hatására egy keresést indít és annak eredményét jeleníti meg a Search view-ban, amely listázza a felderített hivatkozások forrását.

Nagyon hasznos plugin, javaslom kipróbálását! Telepítésének részleteit megtalálod a JDT CodeMining GitHub oldalán.

Eclipse gyorsbillentyűk hasznosságával vetekedő plugin

Összefoglaló

Hogy hatékonyan tudj programozni, érdemes megismerned az általad használt eszközök képességeit, így Java fejlesztés során az Eclipse IDE eszközkészletét, és hogy ezeket hogyan tudod a segítségedre hívni. A legjobb módja, ha begyakorlod a leggyakoribb gyorsbillentyűket, amiket a fentebbi táblázatban találsz.

Ha esetleg még most járnál programozói pályafutásod legelején, hadd ajánljam figyelmedbe a Java fejlesztői környezet beállítását képekben bemutató blog posztomat!

Ha bármi észrevételed van, esetleg javasolnál még további fontos billentyűparancsokat, amiket gyakran használsz, akkor kérlek, oszd meg véleményed egy hozzászólásban!

További jó kódolást kívánok neked! 🙂

Ha tetszett, oszd meg!

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

Máris itt a Java 10?

Java 10
Java 10

Nemrég történt, hogy a Java 9 újításai, a Project Jigsaw eredményeképp megvalósult modularizáció és társai napvilágot láttak, egészen pontosan 2017. szeptember 21-én. Előtte a Java 8 hivatalos megjelenése 2014. március 18-án volt, vagyis 3,5 év telt el a kettő között. A Java 10 pedig most egy hete 2018. március 20-án jelent meg, vagyis egy röpke fél év után.

Az Oracle – a Java gondnoka – új kiadási ütemezést tervezett meg, amelynek első alanya a Java 10. A terv, hogy félévente új főverzióját köszönthetjük a Java-nak, ami elősegíti mind a szoftverfejlesztő cégeknek, mind a programozóknak a könnyebb adaptálódást.

Mi a 12 újdonság a Java 10-ben?

Fél év alatt 12 JEP (Java Enhancement Proposal) készült el és került bele a 10-es verzióba:

  1. Local-Variable Type Inference
  2. Consolidate the JDK Forest into a Single Repository
  3. Garbage-Collector Interface
  4. Parallel Full GC for G1
  5. Application Class-Data Sharing
  6. Thread-Local Handshakes
  7. Remove the Native-Header Generation Tool (javah)
  8. Additional Unicode Language-Tag Extensions
  9. Heap Allocation on Alternative Memory Devices
  10. Experimental Java-Based JIT Compiler
  11. Root Certificates
  12. Time-Based Release Versioning

Az elkövetkezendő blog poszt sorozatban ezekről az új feature-ökről olvashatsz. Kezdjük az elején!

Helyi változó típuskikövetkeztetés

A beszédes Java

A Java mindig is híres volt arról, hogy kicsit bőbeszédű (sok a boilerplate kód). Az A&K Akadémia Java tanfolyamain is látom a tanulók arcán a csodálkozást, hogy miért kell mindent többször leírni. Gondolj csak egy egyszerű lista példányosításra:

A Java 7 segített először nekünk, mert bevezette a diamond operátort, és a típusparamétereket legalább nem kellett kétszer leírni:

Java 10 - szóhoz se lehet jutni, akkora a fejlődés

És aztán 2 427 nappal később most a Java 10-ben:

Most már legalább a változó típusát nem kell kiírnunk, hanem használhatjuk a var szót.

Szándékosan nem írtam azt, hogy kulcsszót, mert a var a klasszikus értelemben nem egy új kulcsszó, mint mondjuk az int meg a super. A var nem kulcsszó, hanem foglalt típusnév. Épp ezért ha eddig használtad a var-t, mint helyi változónevet valamelyik projektedben, akkor ez nem fog most sem fordítási hibát okozni.

Ez teljesen rendben van:

Az, hogy a var foglalt típusnév, ez azt is jelenti, hogy csak olyan helyeken használható, ahol a Java fordító egy típusnevet vár.

Szép dolog ez a típuskikövetkeztetés, de hogy is működik pontosan?

Mi lesz a list változóm típusa, ha azt így definiálom?

A Java mérnökei a KISS elvet alkalmazták (Keep it simple, stupid) és a Java fordítót egy egyszerű, de hatásos kikövetkeztetési stratégiával áldtak meg:

Épp egy ArrayList-et példányosítasz a new operátorral? Akkor ez ArrayList típusú változó lesz.

Nyilván ez nem a leg high tech-ebb megoldás, de megteszi.

Lehetett volna kidolgozni egy eljárást, ami hogyha találkozik egy var változó definícióval, akkor onnantól kezdve átvizsgálja a kódot és megnézi, hogy ha az egy referencia típus, akkor a referencián keresztül az objektum milyen tagjait éri el a kód és ezek alapján a példányosított objektum típusából kiindulva megnézné, hogy az osztályhierarchián feleleve gyalogolva melyik az a típus, ami még eleget tesz az elemzésnek, és ezt a típust választhatná a változó típusának.

Ez elég komplex lett volna és egy olyan problémát okozott volna, amit nagyon nem szeretünk. Ez pedig az, hogy ha módosítjuk a kódunkat a 342. sorban, akkor ne romoljon el a 174.-ben.

Ezt a jelenséget action at a distance-nek hívjuk, és egy ellenminta (anti-pattern), vagyis kerülendő.

De az, hogy a Java-t fejlesztő mérnökök a típuskikövetkeztetésre az egyszerűbb módszert választották ez igazából teljesen érthető. A var csak helyi változókra működik. Nem használható se paraméter változónál, se mező szintű változónál. A helyi változók hatóköre pedig a legkisebb, itt a legelfogadhatóbb az, ha egy ArrayList-re nem List interfész típusú referenciával hivatkozunk. A helyi változók pusztán konkrét metódusok implementációs részletei.

Amit a var-ral nyer(het)ünk az pedig az olvashatóság. A programozói munka során sokkal többet olvassuk a kódot, mint írjuk. Ha az agyunknak nem kell ezt a plusz terhet elviselnie, hogy még a helyi változóknál is a referencia típusát feldolgozza, akkor több agyi kapacitásunk marad a többi, lényegesebb dologra, például hogy megértsük az üzleti logikát.

Ami még szintén jó hír, hogy a var igazából nem más, mint egy szintaktikai édesítőszer (syntactic sugar). A forráskód lefordítása során a var-os kifejezéseket a fordító helyettesíti a kikövetkeztetett típussal, tehát ebből

ez lesz:

Így nem kell azon annyira aggódnunk, hogy egy új nyelvi feature használatával újabb, eddig nem ismert hibákat okozunk kódunkban.

Van var de nincs val. Miért?

Más programozási nyelvekben tipikusan a var és val is elérhető. Ez utóbbi a variable és a final szavak összevonásából keletkezett. A JEP fejlesztéseknél a közösség visszajelzéseit is mindig figyelembe veszik és a val esetén nem volt annyira szignifikáns a különbség, hogy bevezessék új nyelvi elemként. A döntést azzal is magyarázták, hogy még a helyi változók esetén a legkevésbé fontos a változó módosíthatatlansága, illetve a Java 8-ban bevezetett effectively final koncepció ezt már valamilyen szinten kezeli. Ha szeretnénk, akkor persze a var definíciónkat tehetjük final-lá ily módon:

Mostantól minden helyi változót írjak var-ral?

Semmiképp. Mint minden nyelvi elem, ez is csak egy eszközt ad a kezünkbe, amivel tudunk jobb kódot írni. De akármennyire is szép és jó eszközök vannak a kezünkben, mindig megtalálhatjuk (és meg is találjuk) a módját annak, hogy lábon lőjük magunkat.

A var-nál sincs ez másként. Fontos, hogy mindig megfontold, hogy a kód, amit a segítségével írtál, az olvashatóbb lett-e. Gondolj bele miután megírtad a kódod, hogy mit szólna hozzá egy másik programozó, aki most került a projektedre és most találkozik ezzel a kódrészlettel először. Könnyíteni vagy nehezítené számára a kódolvasást?

To var or not to var?

A var, mint új nyelvi elem, egy olyan újdonság, amivel minden Java programozó találkozni fog. A megfelelő helyzetekben alkalmazva növelheti a kód olvashatóságát és ekkor érdemes használni. Csak helyi változóknál használható. De a var ellenére a Java továbbra is erősen típus nyelv maradt. Az út, amely az egyre könnyebben olvasható kód írásához vezet még hosszú, de a Java 7-ben a diamond operátor és most a Java 10-ben a var mérföldköveknek számítanak rajta. Így hát befejezésként azt mondhatom, hogy

Congratulations. You are being rescued! Please do not resist. 🙂

Ha tetszett, oszd meg!

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 – 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!

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!