Java 12 – switch expression

A Java nyelv a kezdeti verziók óta támogatja a switch utasítást (switch statement), ami segít programjainkban a végrehajtás többfelé ágaztatásában. Míg az if utasítással feltételesen végrehajthatunk bizonyos parancsokat, ha egy adott feltétel teljesül – illetve az else segítségével más utasításokat ha a feltétel nem teljesül – addig a switch-csel több ágat is létrehozhatunk, hogy egy adott változó különböző értékei esetén, különböző utasításokat hajtsunk végre. A Java 12 tartalmazza a switch utasításnak egy új, kísérleti verzióját, a switch expression-t, vagyis a switch kifejezést, ahol már nem csak önálló parancsként, hanem kifejezésként is használhatjuk a switch blokkot. Először nézzük meg, hogy a Java kezdeti verziója óta elérhető switch utasítás hogy néz ki és mik a jellemzői!

Példa switch utasításra

public class TestSwitchStatement {

    public static void main(String[] args) {
        int dayOfWeek = 3;
        switch (dayOfWeek) {
        case 1:
            System.out.println("hétfő");
            break;
        case 2:
            System.out.println("kedd");
            break;
        case 3:
            System.out.println("szerda");
            break;
        case 4:
            System.out.println("csütörtök");
            break;
        case 5:
            System.out.println("péntek");
            break;
        case 6:
            System.out.println("szombat");
            break;
        case 7:
            System.out.println("vasárnap");
            break;
        }
    }

}

A fenti kód tartalmaz egy int típusú dayOfWeek nevű változót, ami azt tárolja, hogy a hét hányadik napján tartunk. Mivel a hétnek hét napja van (да!), ezért itt több if-et kéne használnunk, hogy minden esetet lefedjünk és a hét napjának sorszáma alapján kiírjuk a nap nevét a standard kimenetre. Ehelyett viszont egy switch utasítást használtunk, ami 7 ágat tartalmaz és így lefedtük a várható eseteket.

Give me a break!

Feltűnhet, hogy a fenti példában sok break utasítás is szerepel. Miért van ez?

Régebbről fakadó programozási nyelvekben, mint a C, is jelen volt a switch utasítás. Ekkor még alacsonyabb szintű nyelvi elemnek szánták ezt a parancsot, és jellemző is volt azokra a feladatokra, amikre szánták, hogy a case-ek pusztán címkék voltak, és belépési pontul szolgáltak az amúgy a switch utasítás utasításblokkjában szereplő utasításokhoz. Más szóval a case címkék csak azt jelölték, hogy hányadik sorától kell elkezdeni a végrehajtását az utasításoknak, de a végrehajtás egészen a switch utasításblokkjának végéig tartott. Ezt fall-through logic-nak hívják. A Java ezt a nyelvi elemet úgy vette át, ahogy tipikusan más nyelvekben szerepelt, ezért a Java-ban is jelen van a switch utasításnál a fall-through logic. Újonnan programozást tanulóknak sokszor összezavaró ez a megvalósítás, hisz úgy gondolnak a switch-re, mint egy kizárólagos eseteket felsorakoztató struktúrára. Pedig nem így van. Ha a fenti példában nem szerepelnének a break utasítások, akkor bár a hét napjainak sorszáma alapján a helyes case-től kezdene el futni a kód, de a futását nem hagyná abba egészen a switch végéig, vagyis kiírná, hogy szerda, csütörtök, péntek, szombat, vasárnap. Ez a funkció gyakrabban okoz gondot, mint ahogy hasznot hoz. Ha mégis szeretnénk használni, akkor érdemes egy rövid egysoros kommentben jelezni, hogy itt most szándékosan használtuk a fall-through logic-ot.

Ha break utasításra fut rá a végrehajtás, akkor viszont megszakítja a switch utasításblokkjában lévő utasítások végrehajtását és kilép a switch-ből, és a switch utáni első utasítással folytatódik a program futása.

Switch expression a Java 12-ben

Holnap (2019. 03. 19.) jelenik meg a Java SE 12 verziója, ami egy új, mai igényeknek megfelelő switch kifejezést nyújt számunkra, bár igaz, hogy egyelőre csak kísérleti jelleggel. Ha ki szeretnénk próbálni, akkor engedélyeznünk kell az –enable-preview új parancssori opcióval mind fordításnál, mind futtatásnál.

Mi a különbség a switch statement és a switch expression között?

switch expression szemléltetése Drake-kelA switch statement önálló utasítás, amely ha végrehajtódik, akkor csak mellékhatása van, de nincs közvetlen eredménye.

Ezzel szemben a switch expression egy kifejezés, ami ha kiértékelődik, akkor egy eredményt is szolgáltat, ami lényegében az egész switch blokk helyére behelyettesítődik.

Talán az if-else és a feltételes hármas operátor (?:) a legjobb hasonlat erre. Míg az if-else-nél a kódblokkban megadva adhatunk meg utasításokat, amik az if feltételeként megadott kifejezés igaz / hamis volta alapján kerülnek lefuttatásra vagy kihagyásra, úgy a ?: operátornál a kérdőjel előtti kifejezés ha igaz, akkor a kérdőjel és a kettőspont közötti, míg a kérdőjel előtti kifejezés ha hamis, akkor a kettőspont utáni érték kerül behelyettesítésre az egész ?: kifejezés helyére.

Ugyanez a helyzet a switch kifejezésnél is. Nézzünk erre egy példát:

Példa switch expression-re

public class TestSwitchStatement {

    public static void main(String[] args) {
        int dayOfWeek = 3;
        String nameOfDay = switch (dayOfWeek) {
                   case 1 -> "hétfő";
                   case 2 -> "kedd";
                   case 3 -> "szerda";
                   case 4 -> "csütörtök";
                   case 5 -> "péntek";
                   case 6 -> "szombat";
                   case 7 -> "vasárnap";
                   default -> "ismeretlen";
                };
        System.out.println(nameOfDay);
    }

}

Több különbséget is megfigyelhetsz a switch statement-hez képest. A switch expression a fenti példában egy értékadás operátor jobb oldalaként szerepel, vagyis a nameOfDay változó értéke a dayOfWeek változó értéke alapján a neki megfelelő Stringet fogja megkapni. Ahogy láthatod, a lambda kifejezésekből is ismerős nyíl tokent (->) használhatjuk ezentúl a switch-en belül. Fontos különbség, hogy ha olyan case-t használunk, amit nyíl token követ, akkor nincs fall-through logic, vagyis ilyen esetben ezek a case-ek kizárják egymást. Vagy az egyik fut le, vagy a másik, de sosem lapolódnak át. Az persze előfordulhat, ha nincs default eset, hogy egyikre se illeszkedik a switch-ben megadott dayOfWeek változó értéke. A default esetet nem kötelező megadnunk, de ha nem adjuk meg, akkor minden esetet le kell fednünk case-ekkel a switch kifejezésünkben. Ha enumokról van szó, akkor végre a fordító képes ellenőrizni, hogy minden konstanst szerepeltettünk-e a case-eknél.

Hadd hívjam fel a figyelmed még egy apróságra: a switch expressionnél a switch utasításblokkjának végén van egy pontosvessző, hisz ez az, ami az egész utasítást lezárja. A switch statementek esetén a switch mögé nem kell pontosvesszőt tenni.

Bár a nyíl token segítségével elkerülhetjük a fall-through logic átláthatatlanságát, nem vagyunk rákényszerítve a használatára. Ugyanúgy használhatunk kettőspontot a case-ek felsorolásánál, és ekkor a switch statement-hez hasonlóan élhetünk ezzel a lehetőséggel. De vajon mi lesz ilyenkor a switch expression helyettesítési értéke?

Break értékkel

A switch expression-ökben egy újfajta break utasítást is használhatunk. Eddig címkézett és címkézetlen break vezérlésátadó utasításaink voltak csak, de a switch expression-ök esetén ez most kibővül egy új taggal, amikoris a break után egy értéket adunk meg. Ez nagyon hasonló a metódusok return utasításához, ahol a visszatérési értéket adhatjuk meg a return után. Pont ugyanez a szerepe a breaknek a switch expression-ön belül. Nézzünk erre is egy példát!

public class TestSwitchExpressionWithBreakReturnValue {

    public static void main(String[] args) {
        int dayOfWeek = 3;
        String nameOfDay = switch (dayOfWeek) {
                   case 1:
                       break "hétfő";
                   case 2:
                       break "kedd";
                   case 3:
                       break "szerda";
                   case 4:
                       break "csütörtök";
                   case 5:
                       break "péntek";
                   case 6:
                       break "szombat";
                   case 7:
                       break "vasárnap";
                   default:
                       break "ismeretlen";
                };
        System.out.println(nameOfDay);
    }

}

Ahogy láthatod, a fenti példában a break utasítás után egy Stringet adunk vissza eredményül és ez lesz a switch kifejezés eredménye, ez kerül behelyettesítésre az egész switch blokk helyére.

Egy case, több eset

Van még egy további funkció, amit az új switch szintaktika megenged számunkra. Korábban egy case pontosan egy esetet írhatott le, de ezentúl vesszővel elválasztva több összetartozó esetet is megadhatunk. Íme egy példa erre is:

public class TestSwitchStatementWithMultipleCases {

    public static void main(String[] args) {
        int dayOfWeek = 3;
        switch (dayOfWeek) {
        case 1, 2, 3, 4 ,5:
            System.out.println("hétköznap");
            break;
        case 6, 7:
            System.out.println("hétvége");
            break;
        }
    }

}

Finally

Fantasztikus új lehetőség vár ránk az elkövetkezendő Java verziókban. Egyelőre a switch expression még csak kipróbálás jelleggel van jelen a Java 12-ben, de várható, hogy későbbi verziókban élesítik majd. A kísérleti jellege miatt még elképzelhető, hogy változik a szintaktikája, ezért érdemes tájékozódni a production verziója megjelenése esetén. Tervezik a Java szoftverfejlesztő mérnökei, hogy mintaillesztéssel is kibővítik a switch-et, és akkor akár olyan case-eket is megadhatunk benne, hogy i < 42 és i >= 42.

Ha olvasnál még bővebben a switch expression-ökről, akkor a JEP 325 hivatalos dokumentációját ajánlom figyelmedbe.

Ha a Java legújabb verziói által nyújtott lehetőségek érdekelnek, akkor szerintem ez az előadásom is tetszeni fog neked. Kövess YouTube-on is!

Ha tetszett, oszd meg!

Programozó képzés női szemmel

Programozó képzés női szemmel

Nők az IT szektorban – 3.

Ez a poszt zárja azt a háromrészes sorozatot, melyet február végén indítottunk, és egy tavaly novemberi kerekasztalbeszélgetés inspirált. Bármilyen programozó képzés vonzó lehet az érdeklődő számára, de nőként mire vállalkozik az, aki ezen a pályán tervezi sínre tenni életét? A korábbiakban beszéltünk arról, hogy mit jelent a diverzitás a munkacsoport hatékonyságára nézve, milyen az a tipikus start-up környezet, ami afféle boys’ club hangulatot hordoz, és ez milyen hatással van a női munkavállalóra? Most azokra a trendekre fókuszálunk, amik segíthetnek feloldani ezt a konfliktust.

 

Mit lehet akkor tenni, hogy több női IT szakember legyen?

 

programozó képzés

 

Gregor Anikó szerint sokat segítene, ha a gondoskodási feladatokat társadalmiasítanák. Ne csak azok számára legyen elérhető bölcsődei foglalkozás, akinek a cége ezt lehetővé teszi, vagy annyit keres, hogy megengedhesse magának, hogy a gyerekét magán intézményekbe járassa. Ne egyéni stratégiákkal kelljen ügyeskedni. Legyen ez kollektív jog. Továbbá a standard elvárások még mindig erősen hatnak. A tanítók között a pályaelhagyók nagyobb hányada férfi. A családfenntartó szerepe összeegyeztethetetlen a versenyképtelen fizetéssel. Még ha komoly elhivatottsággal rendelkezik is az egyén, döntéshelyzetbe kényszerül.

Vásárhelyi Orsolya itt beszélt bővebben

Az imposztor szindrómáról

 

maszk

 

Nálunk itt olvashattatok róla. A nők komolyabban érintettek a témában. Ez a versenyszférában jelen lévőkre különösen igaz. Megnyilvánul ez már az álláskeresés szakaszában is. A tapasztalatok azt mutatják, hogy azoknál a hirdetéseknél, ahol az elvárt 10 készség közül nem rendelkezik mindegyikkel a női munkavállaló, már meg sem pályázza az állást, míg a férfiak közül, ha 4-et magáénak tud, már megpróbálkozik vele. Különösen komoly stresszt mér a programozói állásra jelentkezőkre az úgynevezett whiteboard interjú. Mára már nem igen kell kézzel programkódot írni. Ezekre a helyzetekre egy nő rosszabbul reagál. Oktatóként szerzett tapasztalatait is megosztotta a hallgatósággal.

Egyik csoportjának kezdő hallgatói a legelső órán találkoztak az ERROR-okkal. Elmondta nekik, hogy attól nem kell félni, ha hibára fut, azzal lehet legalább valamit kezdeni. Ahogy járkált a teremben és rápillantott a monitorokra, a férfi hallgatók előtt már irdatlan mennyiségű hibajel gyűlt össze, míg a női hallgatók előtt semmi. Megkérdezte őket, hogy min dolgoztak akkor mégis az óra alatt, majd a Ctrl+Z megmutatta, hogy igenis kitartóan próbálkoztak, csak aztán minden hibát töröltek. A lányokat arra nevelik, hogy ne hibázzanak.

 

Erre jó megoldás lenne, ha a mentorprogramokat jobban támogatnák

 

Most kitől kérdezze meg az a női munkavállaló egy IT cégnél, hogy mihez kezdjen az életével, mi lesz vele, ha gyereke születik? Ha nincs előtte női vezető, nincs példa, nehezebb megtervezni a további lépéseket.

Turcsányi-Szabó Márta rávilágított, hogy vannak már olyan cégek, ahol működik ez a mentor program. Külföldön komoly érv a digitális ipar mellett, hogy akár otthonról is végezhető, egy nőnek nem kell elvetni a családalapításra irányuló ambícióit, mert gyerek mellett is végezhető, sokkal rugalmasabb munkarendben dolgozhat. Flexibilisebbnek kellene lenni az anyákkal. Megengedhető a heti egy nap home office. Ez talán segítene a jelenlegi helyzeten.

 

A bölcsőde sem biztos, hogy megoldást jelentene

 

A babysitter kultúra nem a sajátunk. Hazánkban a női szerepek közé tartozik a gyerekekről és az idősekről való gondoskodás.

Verdes Balázs itt jegyezte meg, hogy a világ politikailag, ideológiailag erősen visszafejlődik. Amiben előre tart, az a diszkrimináció. Ekkor mesélt arról a példáról, amiről a múlt hónapban olvashattatok nálunk is. Az Amazon hozott létre mesterséges intelligenciával (ebben a magazinban találod a cikket róla) egy eszközt, hogy az új munkaerő felvételét automatizálhassa, ám igen hamar kezdte a női CV-ket kiszórni, egyszerűen a szektorbéli jelenlét alapján meghozott döntés alapján ítélte a női munkavállalót alacsonyabb értékűnek a férfiaknál.

Gregor Anikó vette fel a fonalat a babysitter kultúra gondolatánál. Jelenleg hazánkban mi vagyunk a „nyugat szitterei”. A második műszak terheit nem megoldják az emancipált nők, ellenben kiszervezik egy másik nőre. Ha helyben alkalmaznak valakit, az pedig valószínűleg alacsonyabb társadalmi státuszú. Az eltorzított emancipáció elmélete szerint csak bizonyos réteg számára érhető el az egyenlőség, ez jellemzően a felső középosztálytól kezdődik felfelé. Épp ezért az emancipáció elméletek többsége is ezeknek a nőknek a társadalmi valóságáról ír, ami összeegyeztethetetlen a nálunk megélt valósággal.

 

Kifejezetten női programozó képzés

 

keyboard

 

Vásárhelyi Orsolya itt említette azt a két lengyel lányt, aki elindította hazájában a Geek Girls Carrots kezdeményezést, ahol nők tanítanak nőket programozni. Ez a programozó képzés nem arról szól, hogy back and fejlesztőket képezzenek, hanem betekintést engedjenek a nőknek a programozás világába, megtehesse az első lépést egy olyan karrier irányába az illető, ami teljesen idegen számára, és ne kelljen rögtön elköteleznie magát egy komoly anyagi terhet jelentő képzés mellett.

Ez egy önsegítő kezdeményezés. Helyenként eltér a sikeressége. Van, ahol nagyon jó közösségek alakulnak ki ezáltal, van, ahol csírájában elhal a lelkesedés, mindenesetre jó, ha egymást támogató szakmai közösségek tudnak kialakulni alulról szerveződve, ennek hosszú távon előnyös hatásai mutatkoznak.

Nem idegen magyar vonatkozása sem, van kifejezetten nőket célzó, a kvótát szolgáló programozó képzés itthon is. A prog.hu írt a Morgan Stanley legutóbbi akciójáról. 28 lányt tanítottak meg programozni ez év alatt. Természetesen nem egyedül vitte végig az akciót. Jelentős szerepet kap ebben a NaTE (Nők a Tudományban Egyesület) Smartiz programja, ami középiskolás lányokat céloz. Oktatáskutatók, pedagógusok, társadalomtudósok működtek közre a tanmenet kialakításában.

 

Közönségkérdések

Az elhangzó kérdések között felmerült a koedukált munkakörnyezetben tapasztalt politikailag korrekt diskurzus feszültségkeltő jelenléte. Eltűnik-e ez valaha, és az embert megítélhetik-e tisztán a teljesítménye alapján? A válaszok nem voltak bizakodók.

Elhangzott a boys’ club hangulatú céges környezettel kapcsolatban, hogy megéri-e ezeknek a vállalatoknak ezen változtatni? Vásárhelyi Orsolya saját tapasztalataira alapozva ezzel kapcsolatban bizakodó. A munkáltatónak erős érdeke, hogy a humántőke profitot termeljen a számára. Egy kipihent munkavállaló hatékonyabban dolgozik. Lehet, hogy megteremti azt a munkakörnyezetet, ahonnan a dolgozó nem is akar hazamenni, de hozhat olyan döntést, hogy hétkor bezárja a kapukat. Megtiltja a hétvégi munkavégzést. Erősít a családi értékekre.

A beszélgetés során felmerült még a jövőbeli munkahelyek megszűnése. Ha a Tesla önjáró kamionjai szállítanak árut a világ legkülönfélébb A és B pontjai között, nem lesz szükség kamionsofőrre. A fizikai jellegű munkavégzők között a férfi nem tagjai felülreprezentáltak. Sok olyan kétkezi munka gépesítése válik lehetővé, amit az alsóbb társadalmi osztályok képviselői művelnek. Látható, hogy ezekre belátható időn belül nem lesz szükség. Viszont programozóra mindig lesz. Turcsányi-Szabó Márta hozzátette, hogy nincs szakma, ami mellőzné az informatikát valamilyen szinten.

Az lenne a legjobb, ha mindenki azt tanulhatná, azzal foglalkozhatna, amihez a legjobban ért. Ha mindenki zsebében ott az igazolás, meg az elvégzett programozó képzés élénk emléke a megszerzett ismeretekkel, de elve utálja, hát nem kell minden áron szoftvert fejleszteni mindenkinek.

 

Bízunk benne

hogy a jövőben sikerült azokat a pozitív irányba mutató, kooperáción alapuló irányzatokat erősíteni, melyek lehetővé teszik, hogy látens módon se mások elvárásai szerint válasszunk magunknak hivatást. Ha az akrobatika, a természettudományok, a csillagászat, a kozmetika érdekel, kötelezzük el magunkat mellette. Ha pedig épp egy programozó képzés tetszett meg, akkor ne habozzunk jelentkezni.

Ez a háromrészes sorozat épphogy engedett pár pillantást a jelenséget tápláló sok sok tényezőre. Mégis remélem, sikerült felkelteni az érdeklődést a téma iránt.

Zárásként pedig: pár hete kaptam ezt az érdekes posztot olvasásra. Jó példa a sztereotípiák megjelenésére. Korábbi posztunkhoz megjegyzésként. Köszi, Gergő!

 

victoria's secret programmer

 

Ha tetszett, oszd meg!

Milyen programozó tanfolyam való neked?

Milyen programozó tanfolyam való neked?

 

Ígértünk egy háromrészes cikksorozatot arról, hogy való-e a programozó tanfolyam nőknek.

 

Nők az IT szektorban – 2. 

Folytatva a korábbi gondolatokat, a második rész következik. Az A&K Akadémián elérhető számos programozó tanfolyam állandóan változik, fejlődik. Bízunk benne, hogy támogatjuk azokat a folyamatokat, melyek hosszútávon vezetnek a társadalom jobbítására. Ehhez eszközül a nálunk tanulók egyéni fejlesztése, folyamatos önreflexió, hatékony kommunikáció szolgál. A mai posztban haladunk tovább, hiszen a kerekasztal beszélgetés időbeli korlátossága miatt épphogy csak fellebbentett témákat, amikről érdemes elgondolkozni.

Az ’50-’60-as éveknél hagytuk abba, mikor az informatika, a technológia világa térhódítása okán magasabb presztízsre tett szert, és a nők lassan kiszorultak a szférából. Dessewffy Tibor fellebbentette, hogy létezik az üvegplafon jelensége, újabban hangos volt a média a szexuális zaklatásoktól, és a béregyenlőtlenség kérdését vizsgálva sok tanulmány születik.

 

De mi a helyzet az informatikai világban, a digitális start-upok bűvkörében? 

Mégis milyen ez a szektor? Vásárhelyi Orsolya elmondása alapján ez a legjobban fizetett szektor, épp ezért jóval nagyobb médianyilvánosságot is kap, és sokkal kevesebb a nő.

 

programozó tanfolyam

 

Turcsányi-Szabó Márta viszont rávilágított arra, hogy mivel ez egy nagyon szerteágazó szektor, lényegében bárki megtalálhatja, amire a leginkább alkalmas, a maga érdeklődésének megfelelően. Nem kellene egy kalap alá venni ezért az „informatikust”.

Ha nincs is az illetőnek korábbi tapasztalata, erre véleményünk szerint megoldást kínálhat egy-egy programozó tanfolyam. Nem a korábbi végzettség fogja igazolni, hogy rendelkezik-e valaki a megfelelő készségekkel, vagy kellően befogadó-e az ismeretanyag elsajátításra. Ha újabb mozis példával szeretnék élni, akkor gondoljunk csak a Good Will Hunting-ra. Elhangzik benne egy érvelés a kocsmai vitánál, hogy az egyetemista fiú rengeteg pénzt öl olyan tudás megszerzésébe, amit egy közkönyvtárban is megkapna. Ellenérvként megjelenik, hogy ez lehet, hogy így van, de neki lesz valami igazolás a kezében, amivel képes megszerezni azt az állást, ami megtéríti az oktatás költségeit.

Nos, ez egy teljesen más téma, és a későbbiekben egy külön cikkben foglalkozunk is vele. Visszatérve a kerekasztal beszélgetéshez, Gregor Anikó itt hozzátette, hogy a presztízspozíciók itt, a szférán belül is megvannak.

 

A front end, webdesign, grafikai fejlesztés területén több a nő

 

– Vásárhelyi Orsolya elmondása alapján. A béregyenlőtlenség megmutatkozik konkrét példákon keresztül, egy amerikai cégnél azok a nők, akiket back end fejlesztőként alkalmaztak, front end-esként vették fel. Ez éves szinten 20 000 $-os veszteséget jelentett az egyénre nézve.

A programozó tanfolyam, ha jó, nehezen elérhető. Komoly elhatározás szükséges hozzá, hogy ekkora anyagi áldozatot vállaljon a vállalkozó szellemű kezdő. Azok az oktatások, ahol az ismeretek mélységi megismerése szükséges, hosszabbak, költségesebbek. Vannak persze könnyebben elsajátítható, „modulos rendszerben” elérhető órák, ahol mérföldkövenként kell fizetni. Meghatározza egy képzés árát az is, hogy mennyire népszerű a szolgáltatás, amit kínál. Ha komoly konkurencia jelentkezik a területen, kialakulhat egyfajta árverseny, ami mutatója lehet annak is, hogy mennyire keresett a szakma. Ezekkel a mutatókkal azonban vigyázni kell, mert még sok tényező befolyásolja őket.

 

A beszélgetésben a bankszektorra terelődött a figyelem

kéz pénz nő

Itt túlnyomó többségben 30 alatti férfiak képviseltetik magukat, és körükben gyakori az alkoholfogyasztás. Jellemző erre a fajta vállalati kultúrára a géniusz istenítés, és nagyon erős a verseny. Ebben a tesztoszterongazdag kultúrában a legtöbb nő nem állja meg a helyét.

Név nélkül hivatkoznék itt most egy viszonylag friss beszélgetésre, ahol a programozó tanfolyam után elhelyezkedő pályamódosító fejlesztő egy banknál talált munkát. Érzése szerint túlszabályzott, túlkontrollált volt a légkör, és problémát okozott számára, hogy kollégái közül kevesen voltak programozók, inkább fiatal bankárok. A mindennapi feszültségek olyan stresszel jártak, amik váltásra kényszerítették. Beszámolója megerősítette bennem az ELTE-n elhangzottakat.

Gregor Anikó vette át a szót. Előkerült Sheryl Sandberg, mint női vezető ebben a világban. Dobd be magad című könyvével, amiről mi is írtunk korábban (az adott szám itt tölthető le).

 

Ez az ipar individualizálja az egyént

 

Van az a munkahely, ahonnan az ember nem akar hazamenni. Példaként említette a Prezi irodáját. Ezek a cégek arra építenek, hogy olyan környezetet teremtsenek a munkavállalónak, ami a legkevésbé sem emlékeztet egy munkahelyre. Csocsóasztal, rekreációs szoba, közös sörözés este hét után, ez mind amolyan egyetemi kollégiumi „boys club”. Tovább erősíti ezt a szervezeti és nemi kultúrát.

Pár perccel ezelőtt futott be Verdes Balázs, és itt be is csatlakozott a beszélgetésbe. Rögtön el is hangzott egy ellenérv. Egy friss kutatásra hivatkozott, amikor tevékenységeket vizsgáltak. Megpróbáltak tipikusan férfias, illetve nőies tevékenységeket (Git hub, UX, milyen programnyelvet használ, Java, PHP stb.) összegereblyézni, amit az egyén befolyásol, és kivonták ebből a gendert.

Ezek után azt vizsgálták, hogy mekkora valószínűséggel állapítható meg a tevékenységekből az illető neme. Ezeknél a viselkedéseknél eltűnik a határ közöttük. Megállapították, hogy az itt felsorolt tevékenységi körök általánosságban vett férfias, illetve nőies jellege nem befolyásolja azok végzőjét sikerességében.

Dessewffy Tibor feltette a következő, de az est folyamán megkerülhetetlen kérdést.

 

Miért baj az, ha nincs több nő IT területen?

 

afro programozó nő

 

Turcsányi-Szabó Márta ragadta meg az alkalmat, hogy erre elsőként válaszoljon. Egyszerűen azért, mert másként gondolkodunk. Minél különbözőbben vagyunk egy csoportban, annál hatékonyabban tudunk dolgozni.

Vásárhelyi Orsolya folytatta a diverzitás kérdésének tárgyalását egy amerikai példán keresztül. Korábban mi is cikkeztünk róla, a black-man code az amerikai etnikai kisebbség keze alól kikerült programkódok összessége. Sok cég kifejezetten büszke, ha sikerül az etnikai diverzitást megteremteni. Ennek racionális oka van. Jobban reagálnak a piaci igényekre, ha nem csak stanfordi fehér férfiak dolgoznak a projekteken.

Verdes Balázs mellé állt ebben a nemi megoszlás tekintetében. Kreatívabb, jobb megoldások születnek azokban a csoportokban, ahol nő is jelen van, főleg, ha ebben a csoportban kialakul egy bizalmi háló is.

Na de miért hagyják el a pályát a nők? Gregor Anikó feltette a megfelelő kérdéseket. Társadalmilag igazságos-e, hogy hogy ugyanazzal a tudással jön ki az egyetemről a két nem két képviselője, de ennél az alapvető tulajdonságuknál fogva determinálva vannak hozzáférések különböző lehetőségekhez, és sajnos ezek nem azonosak?

Vásárhelyi Orsolya a következőt tette hozzá:

Erősen hat a karrier ívére a rugalmasság

Melyik nem tud többet foglalkozni munkaidő után otthon is a hivatásával, mert a technika rohamosan fejlődik, és lépést kell vele tartani, különben nem képes reagálni az egyén az új megoldást igénylő feladatokra. Viszont, ha – írtunk korábban a háztartási munkamegosztás egyenlőtlen viszonyairól– a nőt várja a második műszak, hátrányosabb helyzetbe kerül a másik nem képviselőjével szemben.

Dessewffy Tibor hozzátette, hogy bár a média hangos a szexuális zaklatások botrányaitól, azért annak hangsúlyosabb szerepe lehet a pályaelhagyásban, hogy nehéz a nő számára beilleszkedni ebbe a fiatal férfias közegbe.

Vásárhelyi Orsolya folytatta a bro-culture fogalmának bevezetésével. Ezekben a vállalati kultúrákban gyakran alig van 40 év feletti.

 

A másik oldalt se érje sérelem

 

Verdes Balázs hozzátette, hogy a férfiak is elhagyják a pályát, ha nőiesnek ítélt tevékenységet végeznek.

Turcsányi-Szabó Márta ezzel nem teljesen tudott egyetérteni. Ő 10 évig dolgozott a „hardcore IT világban”, ami önmagában is embert próbáló feladat. Tapasztalatai alapján arra jutott, hogy aki abban a közegben végez tevékenységet, az önmagában vonzza a megbecsülést szakmán belül. Egy olyan teljesítményorientált világról beszélünk, ahol kevesebb a nemi megkülönböztetés.

Úgy gondoljuk, hogy az A&K Akadémián elérhető programozó tanfolyam alatt elsajátított „people skill”-ek segítenek abban, hogy ezeket a problémákat elhelyezkedés után a tanulóink felismerjék, és kezelni tudják.

E sok gondolatot követően juthatunk a következő nagy kérdések felé, de halasszuk ezt a következő hétre.

 

Ha tetszett, oszd meg!

Programozás tanulás nőként?

Ígértünk egy háromrészes cikksorozatot arról, hogy való-e a programozás tanulás nőknek.

 

Nők az IT szektorban – 1. 

 

Miért fontos erről beszélnünk? Mert a munkaerőpiac átalakulóban van. Ha az új lehetőségekből kiszorul a társadalom fele, az említésre méltó jelenség. A programozás tanulás nem olyan tevékenység, amitől neme alapján bárkit eltilt a háziorvosa.

 

programozás tanulás nőként

 

A nyakunkon érezzük a robotizáció fémes hideg leheletét, és ha elfog a borzongás, úgy beszélnünk kell róla mi lesz azokkal a foglalkozásokkal, szakmákkal, amikre nem lesz többé kereslet? De talán még fontosabb a kérdés: mire lesz? Az informatika láthatólag megkerülhetetlen szerepet foglal el valamilyen szinten minden hivatás képviselőjének életében. 

Tavaly november 7-én az ELTE Társadalomtudományi Karán (http://tatk.elte.hu/) volt egy érdekes program, amit aztán jól meg is látogattunk.  

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: Rögzülnek-e a korábbi nemi egyenlőtlenségek az információs korban? 

A felvezetőben Dessewffy Tibor bemutatta a megjelenteket, és rávilágított arra a társadalmi-gazdasági-politikai kontextusra, amiben az elhangzottakat értelmeznünk érdemes. Sokak számára negatív konnotációt hordoz a gender és feminizmus fogalma. Ezek a fogalmak hívószavakká devalválódtak, amiket újraértelmez a társadalom, kritikai szemléletünk legyen mindig kéznél a mindennapi beszélgetésekben.  

Egy olyan ingerben és információban gazdag környezetben, ahol a legtöbbször csak véleményeket olvasunk a témában, szinte elkerülhetetlen a gondolatok kakofóniája okozta zavar. Gregor Anikó ennek tisztázása érdekében megadta saját definícióját. Eszerint társadalmi nemről és genderről társadalmi csoportok között konstruált viszonylatként beszélünk. Ez mindenképpen hierarchikus viszony, ami strukturálja a társadalmat a sztereotípiák fényében. Ezek afféle „önbeteljesítő jóslatként” működnek tovább. 

Az első kérdés, ami körül megpróbáltak valahol a gondolati sokszínűségben rendet tenni, az a nemi reprezentáció kérdése a munkavállalók között. 

 

Tényleg alulreprezentáltak a nők az IT szektorban? 

A válasz igen. Turcsányi-Szabó Márta az ELTE Informatikai Karán tanít. Informatika mesterképzésen 24 hallgatóból 3 nő van csupán. Ennek több oka is van. A régóta élő sztereotípiák egyike: az informatika nem lányoknak való. A programozás tanulás „fiús dolog”. De negatív az informatikusok össztársadalmi megítélése is, ez már messze nem csak nem-specifikus. Egy e-learning felmérésben a kutatásban résztvevők többsége introvertált személyiségjegyeket mutatott. Az okság irányát itt nem érdemes feszegetni. Nem az lesz introvertált automatikusan, aki informatikai hivatást választ, de valószínű, hogy az introvertált személyek szívesebben választanak ilyen irányt.  

Megosztotta velünk a csoportmunkában mutatkozó tapasztalatait. Különböző feladatokban más-más szakos hallgatók működtek együtt. Hatékonyabb volt az együttműködés, ha tanárszakos hallgató is részt vett a négyfős csoportok munkájában. A heterogén csoportok teljesítménye jobb, mintha egyféle szemléletmód a domináns. 

 

lányok sportpályán

 

Gregor Anikó egy lépést távolodva a szűk témától beszélt arról, hogy az előítéletek hogyan hatnak a nőkre, mint társadalmi csoportra. A foglalkoztatás terén a gondoskodáshoz kapcsolódó hivatásokat alapvetően femininnek, nőiesnek „szokás” titulálni. Ez egy konstruált nemi pozíció, leértékelődnek azok a foglalkozások, amiket többségében nők végeznek. Komoly dilemma ez a digitális iparban is. Azzal, hogy rendszerszinten célkitűzéssé válik, hogy legyen több nő az IT szektorban, nem fognak megoldódni a kiegyenlítetlenség problémái. Fontos ehhez megvizsgálnunk az okokat, hogy miért nem választ több nő hivatást ebben a szektorban, illetve miért nagyobb a pályaelhagyók aránya a nők között. Az államigazgatás szemében a nők az a flexibilis csoport, akik bevonhatók-kivonhatók a munkapiacról tetszés szerint. Ha szükség van rájuk, úgy kiépül a home office, a rugalmas munkaidő rendszere, a részidős állások megjelennek a kínálatban. Ha épp nincs szükség a nőkre, akkor többségbe kerülnek azok a támogatási formák, melyek vonzóbbá teszik a főállású anyaságot, például. 

Holott – Vásárhelyi Orsolya rávilágított – a programozásban eredetileg nők tevékenykedtek. A lyukkártyák mellett kiválóan álltak helyt. Az IBM kampányaiban előszeretettel célozta meg a nőket, jó karrierlehetőséget ígérve a jelentkezőknek. 

Láttad esetleg a Számolás joga című filmet?  

Amellett, hogy rendkívül szórakoztató, van mondanivalója. Eredeti címe Hidden figures, és több nagyon jó kérdés mellett foglalkozik a nagy tudományos eredmények háttérszereplőivel, akikkel a történelemkönyvek kevésbé. 

Gregor Anikó később hozzátette, hogy nagyon gyakori volt az érvelés amellett, hogy a nők alkalmasabbak erre a munkára nemükből adódóan. És itt is újra felmerülnek azok a sztereotípiák, amik erősen hatnak a gondolkodásunkra, miszerint a nők monotóniatűrése jobb, a nőknek jobb a nyelvérzéke, és hát a programozáshoz is lényegében egy új nyelvet kell elsajátítani. Folytatva a történetet, az ’50-es ’60-as évek Angliájában viszont a szakma presztízse nőtt, a nők pedig lassan kiszorultak belőle. Nem számított ritkának, hogy a házasságra lépett női kollégának felmondtak, ennek hozadéka lett az a sok hosszú panaszlevél, amiben még ingyen is vállalták volna a munkát, csak hadd dolgozhassanak tovább. 

Összegezve ezt, hiába árasztjuk el nőkkel erőszakosan a szektort, ha a kulturális közeg nem válik befogadóvá, nem fog változni semmi. A programozás tanulás nem könnyebb, nem nehezebb attól, hogy ki hány X kromoszómával született. Mi alapján döntjük el: ki, mire alkalmas? 

 

fotós lány kanapén

 

 

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:

List<String> list = new ArrayList<String>();

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:

List<String> list = new ArrayList<>();

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:

var list = new ArrayList<String>();

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:

var var = "Hello and welcome Java 10!";

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?

var list = new ArrayList<String>();

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

var list = new ArrayList<String>();

ez lesz:

ArrayList<String> list = new ArrayList<String>();

Í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:

final var list = new ArrayList<String>();

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

public static void main(String[] args) throws InterruptedException, IOException {
    printProcessInfo("main", ProcessHandle.current());
    Process process = new ProcessBuilder("notepad.exe", "C:/teszt.txt").start();
    printProcessInfo("notepad", process.toHandle());
    process.waitFor();
    printProcessInfo("notepad", process.toHandle());
}

private static void printProcessInfo(String processDescription, ProcessHandle processHandle) {
    System.out.println("---------- Információk a(z) " + processDescription + " folyamatról ----------");
    System.out.printf("Folyamat azonosító (PID): %d%n", processHandle.pid());
    ProcessHandle.Info info = processHandle.info();
    System.out.printf("Parancs: %s%n", info.command().orElse(""));
    String[] arguments = info.arguments().orElse(new String[] {});
    System.out.println("Argumentumok:");
    for (String argument : arguments) {
        System.out.printf("   %s%n", argument);
    }
    System.out.printf("Parancssor: %s%n", info.commandLine().orElse(""));
    System.out.printf("Indítási idő: %s%n", info.startInstant().orElse(Instant.now()).toString());
    System.out.printf("Futási idő: %sms%n", info.totalCpuDuration().orElse(Duration.ofMillis(0)).toMillis());
    System.out.printf("Felhasználó: %s%n", info.user().orElse(""));
    System.out.println();
}

Ö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)

 

Gyakori kérdés, hogy programozó karrier diploma nélkül is építhető-e és milyen esélyekkel indul neki valaki a programozásnak, ha nincs szakirányú végzettsége?

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ő:

List<String> shoppingList = new ArrayList<>();
shoppingList.add("1 kg kenyér");
shoppingList.add("1 l tej");
shoppingList.add("10 db tojás");

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:

List<String> shoppingList = Arrays.asList("1 kg kenyér", "1 l tej", "10 db tojás");
shoppingList.add("1 kg liszt"); // se hozzáadni
shoppingList.remove(0);         // se törölni nem tudunk

Í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:

List<String> shoppingList = new ArrayList<>(Arrays.asList("1 kg kenyér", "1 l tej", "10 db tojás"));
shoppingList.add("1 kg liszt"); // tudunk hozzáadni
shoppingList.remove(0);         // tudunk törölni

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:

List<String> shoppingList = new ArrayList<String>() {{add("1 kg kenyér"); add("1 l tej"); add("10 db tojás");}};
shoppingList.add("1 kg liszt");
shoppingList.remove(0);

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:

List<String> list = List.of("1 kg kenyér", "1 l tej", "10 db tojás");
Set<String> set = Set.of("1 kg kenyér", "1 l tej", "10 db tojás");

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ű:

void method() {
    String[] shoppingArray = { "1 kg kenyér", "1 l tej", "10 db tojás" };
    methodWithArray(shoppingArray);
    methodWithVarargs(shoppingArray);
    methodWithVarargs("1 kg kenyér", "1 l tej", "10 db tojás");
}

void methodWithArray(String[] shoppingArray) {
}

void methodWithVarargs(String... shoppingArray) {
}

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:

Map<String, Integer> shoppingMap = Map.of("kenyér", 1, "tej", 1, "tojás", 10);

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:

Map<String, Integer> shoppingMap = Map.ofEntries(entry("kenyér", 1), entry("tej", 1), entry("tojás", 10));

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!