Egy példányban futó Java program

Gyakran észrevesszük, hogy a programok futtatásakor vannak bizonyos korlátok. Például egyszerre általában csak egyetlen telepítőprogram futhat egy operációs rendszeren. Vagy amíg fut egy program korábbi verziójának eltávolítása, addig nem futhat a program új verziójának telepítője. Vagy egy nagyobb erőforrás igényű program (periféria meghajtó program, képernyő videó+hang rögzítő, hardveres gyorsítást használó játékprogram) egyszerre csak egy példányban indítható el. Előfordulhat kategóriánkénti korlát is, például a különböző víruskereső programok általában „nem tűrik meg” egymást, kizárólagosságot „követelnek”.

Lássunk példát arra, hogyan kell készíteni egy példányban futó Java programot!

Néhány dolgot át kell gondolni:

  • Amikor először indítjuk el a programot, akkor olyan egyedi dolgot kell beállítani, ami mindvégig úgy marad, amíg a program fut. Ezt megtehetjük a memóriában, de megfelelő jogosultsággal futtatva a programot akár beleírhatunk a Windows rendszerleíró adatbázisába (Registry) is. Előbbi módszer platformfüggetlen lenne – ahogyan egy Java programhoz illik –, és az utóbbi megoldás pedig operációs rendszertől függne.
  • Amikor többedszer (második, harmadik… példányban) indítjuk el a programot, akkor ezt az egyedi dolgot észlelni kell és meg kell akadályozni a program másodszori, harmadszori elindítását. Hasznos, ha ezekben az esetekben kapunk hibaüzenetet, például: „This application is already running”.
  • Amikor a programot szabályosan állítjuk le, akkor a korábban beállított egyedi dolgot semmissé kell tenni. Ez biztosítja, hogy a program egymás után – egymással nem párhuzamosan, egymástól függetlenül – elindítható lesz.

A megoldás két részből áll. Ez a Java forráskód első része:

A program indulásakor le kell futni a fenti forráskódnak. A static blokk a konstruktor előtt hajtódik végre (például a modell vagy a nézet rétegben). A java.net csomag kötetlen ServerSocket osztályú ss nevű objektumát kell inicializálni helyben ( InetAddress.getLocalHost()) egy nem dedikált porttal ( 65001). Ez elsőre mindig sikerült és az objektum „beül a memóriába” egy nem blokkoló elven működő háttérszálon. Ha (többedszerre) nem sikerül létrehozni az objektumot, akkor – kezelve a kötelezően kezelendő kivételeket – hasznos jelezni ezt logban, konzolon vagy felbukkanó párbeszédablakban és a programból ki kell lépni (másképpen: a duplikált futtatását meg kell akadályozni).

Ez a Java forráskód második része:

A programból való szabályos kilépéskor le kell futni a fenti forráskódnak. Ez ellenőrzést követően lezárja az ss objektumot és kilép a programból. Például a main() metódusban, ha elfogynak az utasítások egy konzolos alkalmazásban, vagy GUI-s programban nyomógombra kattintás actionPerformed() esemény, vagy (fő)ablak bezárásának kísérlete WindowClosing() esemény.

A programot érdemes körültekintően tesztelni. Ha elrontjuk a fenti felsorolásban vázolt logikai működés végrehajtásának sorrendjét, akkor fejlesztés vagy tesztelés közben akár a számítógépet is újra kell indítanunk.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A Java EE szoftverfejlesztő tanfolyamunkon, a szakmai modul 5-8. óra Szálkezelés, párhuzamosság alkalommal megismerjük a megoldás elméleti hátterét és a 17-24. óra Socket és RMI alapú kommunikáció alkalommal többféle megvalósítást is kódolunk, tesztelünk.

Rácsrejtjelezés

Időnként készítünk oktatóprogramokat is tanfolyamainkon. Most az volt a cél, hogy kódolás/dekódolás szakterület egyik ismert betűkeveréses algoritmusának működését mutassa be lépésről-lépésre az oktatóprogram. A rácsrejtjelezést választottuk.

Az elkészült program Java swing-es felületű és Windows Classic look-and-feel bőrrel így néz ki működés közben:

A rácsrejtjelezés a képernyőképen látható 4×4-es Kódrács használatán alapul.

A titkosítandó szöveget karakterenként beleírjuk az aktuális kódrácsba soronként lefelé, azon belül balról jobbra haladva. Ha a négy pozíció betelt, akkor el kell fordítani a kódrácsot az óramutató járásával megegyező irányban 90 fokkal. Ha a szöveg hosszabb 16 karakternél, akkor elölről kell kezdeni. Ha készen vagyunk, akkor soronként haladva leírjuk egymás után a kódrácsban található karaktereket.

A megfejtéshez ismernünk kell a titkosított karaktersorozaton kívül a felhasznált kódrácsot is. A karaktersorozatot soronként lefelé haladva beírjuk a kódrácsba, az ismert kódrácsot ráhelyezve soronként lefelé, azon belül balról jobbra haladva kiolvashatjuk a megfejtést. Természetesen a kódrácsot most is forgatni kell minden negyedik karakter után.

Megfigyelhető, hogy bármely karaktert tudunk titkosítani és megfejteni. Ezért a rácsrejtjelezés ebből a szempontból univerzális módszer.

A kódrács ismerete nélkül a titkosított szöveg nem fejthető meg, tartalmára csak nehézkes következtetést adhatunk. Például, ha tudjuk, hogy milyen nyelvű a titkosított szöveg, akkor támpontot adhat a megfejtéséhez a nyelv ábécéjében előforduló betűk ismert gyakorisága.

A képernyőkép éppen a megfejtés egyik pillanatában készült. A feladó továbbította a titkosított szöveget és a kódrácsot a címzettnek, aki elkezdte annak megfejtését. A negyedik karakter a b volt, utoljára erre kattintott a (4;4) pozícióban. Ezt követte egy rácsforgatás, amelyhez tartozik egy ablak, amely megjeleníti a „Rácsforgatás következik.” szöveget. Ezután a kódrács elfordult, és a következő cella a második sor első cellája lesz. Ha hibás cellára, pozícióra kattintunk, akkor a következő hibaüzeneteket kaphatjuk: „Hibáztál! Folytathatod a titkosítást.” vagy „Hibáztál! Folytathatod a megfejtést.” Ha befejeztük a titkosítást, vagy a megfejtést, akkor a következő üzeneteket kaphatjuk: „A kódolás sikerült.” vagy „A megfejtés sikerült.”

A program tartalmaz egy gyakorlást támogatandó szövegkészletet. Ennek minden eleme 16 hosszúságú, az egyszerűség kedvéért – így nem kell véletlenszerű karakterekkel feltölteni a rács kimaradt celláit, illetve nem kell 16-os csoportokkal foglalkozni.

A Titkosítás és megfejtés fülön látható egy véletlenszerűen kiválasztott szöveg, amelyet karakterenként kódolni lehet a kódrács megfelelő cellájára kattintva. Ha kész, a Továbbítás gombbal a feladó elküldi a címzettnek a titkosított karaktersorozatot, aki hasonlóan megfejti. „Útközben” megfigyelhető, hogy éppen hányadik elforgatásnál tartunk és természetesen megjelenik az aktuális ráccsal titkosított szöveg is.

Az űrlapon lévő Kódrács csoportablak az aktuálisan, véletlenszerűen legenerált kódrácson kívül a kiválasztott cellák pozícióit is tartalmazza. Az (1;1) pozícióban a bal felső cella található. A kódrács a Másik nyomógombbal véletlenszerűen újragenerálható. Ennek megvalósításakor több probléma, ötlet is felmerülhet. Például használható visszalépéses keresés algoritmus.

Most nem specifikáljuk részletesebben, például objektumorientált tervezés, eseménykezelés, háttérbeli objektumok vagy GUI komponensek működésének/vezérlésének szintjén. Aki kedvet kapott és úgy érzi, hogy meg tudja ugrani ezt a kihívást, akkor bátran elkészítheti. Hajrá! Mivel oktatóprogram, szükséges hozzá Leírás és Teszt is.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A Java SE szoftverfejlesztő tanfolyamunkon, a szakmai modul Objektumorientált programozás témakörét követő 29-36. óra Grafikus felhasználói felület alkalmain már tudunk egyszerűbb oktatóprogramot tervezni, kódolni, tesztelni.

Rómeó és Júlia

Vajon hogyan kerül elő a Rómeó és Júlia az it-tanfolyam.hu szakmai blogban témaként? Hiszen mégiscsak egy Shakespeare színműről/tragédiáról van szó. Vajon mit programozhatunk Java nyelven ehhez kötődően épp Valentin-napon? Mindjárt kiderül.

Tegyünk fel egy kérdést és próbáljunk rá válaszolni! Vajon ki szereti jobban a másikat? Rómeó vagy Júlia?

Induljunk el az adatforrásból, amihez alkalmazkodnunk kell. A színmű angol nyelven publikusan elérhető XML formátumban: The Tragedy of Romeo and Juliet. Az XML fájlok könnyen feldolgozhatók Java nyelven. Részletek a fájlból (görgethető):

Az XML fájl felépítését tanulmányozva (1-5 alapján) megállapíthatóak az alábbiak:

  • A színmű öt felvonásból áll, ezeket <ACT></ACT> csomópontok jelölik.
  • Egy „adagnyi” beszédet a <SPEECH></SPEECH> csomópont fog össze.
  • A csomópontban található, hogy ki beszél: ez a <SPEAKER></SPEAKER> elem. A mesélő, kar esetén ez az elem üres, és a null-t nem szabad feldolgozni.
  • A csomópontban találhatók a szabadvers kimondott sorai: ezek a <LINE></LINE> elemek. Legalább egy sor minden beszédben van, és nem tudjuk előre a számukat.
  • Nem következetes helyen a DOM-ban, többféleképpen beágyazva és önállóan is előfordulhatnak <STAGEDIR></STAGEDIR> elemek. Ezek a színmű Kosztolányi-féle magyar fordításában dőlt betűvel megjelenő – cselekvésre utaló – színpadi utasítások. Van köztük csók is, amit az XML-ből nem szabad feldolgozni, bár erősen ráutaló magatartás. 🙂
  • Nem tudjuk előre, hogy hány csomópont található a fájlban.

A Java program készítése, tesztelése közben – mintegy mellékesen – megtudhatjuk, hogy Rómeó 612 sorban 24075 betűnyi, Júlia 544 sorban 21855 betűnyi szöveget mond. Persze nem mindet egymásnak mondják. Eközben vajon hányszor mondják ki a szeret, szeretem, szeretlek szavakat? A ragoktól, toldalékoktól, kis- és nagybetűket nem megkülönböztetve és attól is eltekintve, hogy éppen kinek/kiknek mondják amit éppen mondanak, egy becsléshez elegendő, ha a love szóra fókuszálunk (számíthatna a loving alak is).

Az alábbi Java forráskód betölti az XML fájlt a memóriába. Ezután kiválogatja a beszédeket. Ha a beszélő élő ember (szereplő), akkor érdekes, hogy mit/miket mond. Ha ROMEO vagy JULIET mondja az adott sort, akkor azt a program kiválogatja két generikus listába ( romeoLineList és julietLineList) beszédnyi adagokban. Ez nem szétválogatás programozási tétel, mert nem minden beszéd minden sora kerül valahová. A kivételkezelés nem kidolgozott.

Könnyen megkaphatjuk, hogy Rómeó hány darab olyan sort mond, amely tartalmazza a love szót. Például ennek a lambda kifejezésnek kiíratva az eredményét a konzolra:

Könnyen megkaphatjuk Rómeótól a 53 sornyi szöveget is így:

Íme Rómeó kiválogatott sorai (az 5. sorban kétszer is előfordul a love, de ez most nem számít):

Hasonlóan megkaphatjuk Júlia 38 kiválogatott sorát is:

Próbáljunk válaszolni a fentiek alapján a feltett kérdésre! Következtethetünk arra, hogy Rómeó jobban szereti Júliát. Legalábbis többször említi. 53>38. Persze tudjuk, hogy mindez nem ilyen egyszerű. 🙂

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java SE szoftverfejlesztő tanfolyam szakmai moduljának 21-24. óra: Objektumorientált programozás 2. rész, 25-28. óra: Objektumorientált programozás 3. rész, valamint a Java EE szoftverfejlesztő tanfolyam szakmai moduljának 9-12. óra: XML feldolgozás alkalmaihoz kötődik.

Nagyon különböző megoldásokat készíthetünk és szerteágazóan gyakorolhatunk, ha:

  • az XML fájlt kézzel mentjük a webről és utána a helyi fájlrendszerből dolgozzuk fel,
  • az XML fájlt közvetlenül a webről, dinamikusan olvassuk,
  • csak beépített XML-feldolgozást használunk,
  • külső XML API-t használunk,
  • DOM, SAX, XSL, van-e DTD,
  • XPath kifejezésekkel adunk választ a kérdésre,
  • a fenti didaktikusan egyszerű megoldás helyett haladóbb eszközöket (például: Stream API-t) használunk.

Interjú Schmidt Attilával

Schmidt Attila

Schmidt Attila három éves szoftverfejlesztői gyakorlattal (főként Android platformhoz kötődően) és két éves szoftvertesztelői tapasztalattal rendelkező mérnök-informatikus.

Schmidt Attila

Az interjút Kaczur Sándor – az it-tanfolyam.hu alapítója és oktatói csapatának szakmai vezetője – készítette 2019. augusztus 22-én.

K. S.: Már főiskolai tanulmányaid alatt is dolgoztál. Hogyan kerestél és találtál akkor munkát?

S. A.: Akkoriban még nem volt szakmai gyakorlatom és egy olyan helyen szerettem volna ezt abszolválni, ahol esetleg később teljes munkaidőben tudom folytatni a munkát. Hivatalos álláskereső oldalakon nézelődtem, nyitott szemmel jártam és a csoporttársaim tapasztalataira hagyatkoztam. Így sikerült bekerülnöm az első céghez ahol dolgoztam mobilfejlesztőként, ahol a főiskoláról egy csoporttársam volt a mobilos csapatnak a vezetője. Itt szereztem alaptudást a munka kapcsán és tapasztalatot gyűjtöttem, hogy hogyan megy mindez a gyakorlatban.

K. S.: Miről szólt a Tallymarks projekted?

S. A.: A Tallymarks egy számomra kedves mobilalkalmazás, amely ugyan egyszerű, mint a faék, a program működése viszont némileg bonyolultabb logika mentén megy végbe. 5 strigulát kell húznunk a kijelzőn: négyet függőlegesen az utolsót keresztben, mindezt úgy, hogy a program csak érvényes strigulát fogadjon el, így növekszik a számláló és tartja számon (azt, amit előtte beállítottunk például, hogy egy sorozatban hol tartunk). Sok hasonló alkalmazás létezik ezen a területen, de a kijelzőn történő rajzolás és ehhez tartozó funkció egyedülálló volt akkoriban, amikor ezt a programot fejlesztettem.

K. S.: Milyen szakterületei vannak a szoftverfejlesztésnek mobil platformhoz kötődően? Megfogalmaznád a kezdők és a rutinosak szintjén kétféleképpen ezeket?

S. A.: Kezdetben ezekre kell fókuszálni leginkább: UI összeállítása (XML), hálózatkezelés, funkciók implementálása. Ehhez jön később az adatbázis írás/olvasás, push notification/notification kezelés, verziókezelés (Git), hálózati kommunikáció és minden egyéb.

K. S.: Megpróbálnád kategorizálni – tudom, hogy nagyon nehéz – a szoftvertesztelés során előforduló tipikus hibákat? „Mire gondolt a költő”, amikor erről beszélünk…

S. A.: Tipikus hiba talán nem is létezik, ha csak nem nagyon hasonló programokat tesztelünk, amik egy kaptafa alá tartoznak, és mindig rögtön kitaláljuk, hogy hol van hiba a programban. Inkább a funkciók kombinációiban szoktunk hibára gyanakodni, de ezek nem tekinthetőek tipikusnak.

K. S.: Hogyan zajlott fejlesztőként egy tipikus munkanapod? Hogyan zajlik tesztelőként egy tipikus munkanapod?

S. A.: Az én esetemben minden nap azzal kezdődött fejlesztőként, hogy átgondoltam mi az, amit előző nap csináltam, és mi az, amit ma el szeretnék érni. Ez tesztelőként sincsen másképp, annyiban változott, hogy különböző feladataim vannak, fejlesztőként eldönthettem, hogy mi következik: például a szerver kommunikáció vagy a program funkcionalitása. Tesztelőként különféle feladatok vannak – amik függnek a program állapotától – és ez határozza meg a tesztelendő területet illetve a feladat típusát is, hogy most éppen tesztelnem kell-e, teszttervet készíteni, egy már meglévő és a rendszerben szereplő hibajegyet ellenőrizni. Persze

„a programozás lényegesen több gondolkodást igényel, mint a tesztelés”

hacsak nem automatizálásáról beszélünk – amivel én ezt a szakmát kezdtem –, és ilyen esetben is

„lényeges az, hogy mi a cél és milyen szerepet töltünk be a fejlesztés során”.

Schmidt Attila

K. S.: Jelenlegi munkád szakmai részében milyen szoftvereket használsz? Melyiket mire?

S. A.: Helix Alm (testtrack) – hibajegykezelés, Microsoft Teams – kapcsolattartás, Notepad++ – forráskód olvasás/írás.

K. S.: A munkád szervezéséhez kötődően (projektmenedzsment, időgazdálkodás, SCRUM, kommunikáció, verziókezelés) milyen szoftverekkel találkoztál eddig?

S. A.: SourceTree – verziókezelés, Trello – projektmenedzsment, Slack vagy MSTeams – kommunikáció.

K. S.: Általában atipikus, hogy fejlesztői pozíció után valaki tesztelőként folytatja. Mi motivált a váltásra?

S. A.: 2016-ban mobilfejlesztőként dolgoztam és a főnököm megkérdezte, hogy szeretnék-e tesztelő lenni, mert az egy halom pénzbe kerül a cégnek. Boldogan mondtam, hogy persze miért is ne, hiszen érdekelt ez a terület, valamint fejlesztőként is tesztelek ugyan, de kicsit mélyebben is szívesen beleásnám magam.

Fejlesztőként TDD-vel kezdtem, ami az automatizálás része. Kis idő múlva a cég elnyert 2-3 nagyobb projektet is és ezeknek én lehettem a tesztelője, így a manuális tesztelői világ is kinyílt előttem, ráadásul az akkori kollégáimmal – akik a fejlesztésben voltak jelen – remekül tudtam együttműködni.

Azt gondolom, hogy

„a fejlesztésben akkor lehetünk sikeresek, ha már elegendő rutinunk van egy projektet végigvinni az elejétől a végéig és ehhez sok-sok munkatapasztalatra és tudásra van szükség”.

A tesztelésben inkább a jártasság és a tapasztalat számít például, hogyan álljunk neki egy program tesztelésének.

K. S.: Mennyire csapatjátékosok a fejlesztők és a tesztelők? Milyen soft skillek hasznosak ezekben a munkakörökben?

S. A.: A fejlesztő és a tesztelő közötti kapcsolat nagyon fontos, elsősorban úgy gondolom, hogy a tesztelőnek kell azt éreztetni, hogy a fejlesztő munkáját szeretné segíteni és nem hátráltatja azt. Alapszabály, hogy nem szabad sokat kérdezni. Inkább egy adott problémát körültekintően körbe kell járni és meg kell érteni a probléma okát. Így meghatározó információval tudunk szolgálni, amikor a fejlesztő elé állunk, vagy ha csupán hibajegyet rögzítünk, ezzel (is) könnyítve a fejlesztő munkáját is a hiba kijavításában.

Ha csapatjátékos és segítőkész hozzáállást tanúsítunk, az sokat segíthet mind a két szakterületen, ezzel elősegítve azt, hogy hasznos információkhoz jussunk, amelyek segítenek a projekt előre haladásában.

K. S.: Ha a szakmai pályafutásod hossza 100 egység, akkor jelenlegi tapasztalataid alapján hol tartasz, és milyen mérföldköveket fogalmaznál meg ehhez kötődően?

S. A.: Ez kimondottan nehéz kérdés, de azért nem megválaszolhatatlan. Úgy gondolom, hogy az elmúlt 5 évben találkoztam pár dologgal ezen a két területen. A fejlesztést tekintve: az egy komoly mérföldkő, amikor a fejlesztő állítja elő a backendet is magának és erre írja meg a frontendet. Létrehozza a szervert, az adatbázist majd a végterméket. Ha években szeretnénk felállítani mérföldköveket magunknak, akkor a standard 1-3, 3-5, 5+ amivel számolni lehet, de ez nem mutat rá a munkavállaló tudására.

A tesztelést akkor kezdtem el, amikor a fejlesztésben úgy 15-25 között voltam és ez azóta nem is mozgott tovább, bőven lenne még mit tanulnom ezen a területen. A tesztelésben a tapasztalatok alapján egy kicsivel előrébb tartok, de ebben a szakmában is van hova tovább. Inkább az automata tesztelés felé szeretnék specializálódni.

K. S.: Hogyan tovább, mivel fogsz foglalkozni 5-10 év múlva?

S. A.: Célom, hogy tesztmenedzserré váljak és egy tesztelői csapatot koordinálhassak. Így képzelem el a jövőt 5 év múlva. Addig pedig minél több területen szeretnék tapasztalatot gyűjteni és kiegészíteni meglévő tudásomat. Érdeklődöm afelől is, hogyan zajlik a fejlesztés máshol, akár kisebb vagy nagyobb méretű cégről legyen szó.

Schmidt Attila

K. S.: Véleményed szerint mitől függ egy szoftverfejlesztő, szoftvertesztelő fizetése?

S. A.: Elsősorban a cég méretétől: startup, 10-15 éve működő vagy multinacionális. Másodsorban a munkavállaló években mérhető tapasztalatától. Ennek a kettőnek a függvénye adja meg a fizetést.

K. S.: Milyen tapasztalatod van bootcamp-es kollégával? Mit gondolsz, az idősebb (30+, 40+) karrierváltókat mi motiválja, hogy szoftverfejlesztők legyenek?

S. A.: Szerintem elsősorban a fizetés, mert sokat hallani, hogy kiemelkedően lehet keresni ezen a területen és érdeklődnek a szakma iránt, illetve érdekes is annak, aki lát benne perspektívát és elhivatott.

K. S.: Kipróbálnád magadat külföldön fejlesztői vagy tesztelői munkakörben?

S. A.: Mindig úgy voltam vele, hogy én itthon szeretnék dolgozni. Bőven van munka IT területen itthon, sőt egyre több. Egyelőre nem gondolkodom külföldi munkavállaláson, de sose tudni: biztosan átgondolnám, ha lenne rá lehetőség.

K. S.: A Java EE szoftverfejlesztő tanfolyamunk részletes tematikájához tartozik a hálózatkezelés, XML és JSON feldolgozás, valamint különböző hálózati kommunikáció megvalósítása is (Socket, RMI). Mennyire hasznosak ezek a témakörök, esettanulmányok azoknak, akik mobil irányba szeretnének specializálódni?

S. A.: A XML és JSON mindenképpen már kezdetben is hasznosak, a Socket, RMI szintén és gondolom, időben később játszanak szerepet és mindenképpen jó, ha a tanfolyam során ezekkel is megismerkedünk.

K. S.: Véleményed szerint a mesterséges intelligencia különböző szakterületei milyen hatással lesznek a szoftverfejlesztéssel és teszteléssel foglalkozó szakemberek hétköznapi tevékenységeire a közeli jövőben? És hosszabb távon?

S. A.: „Már saját magát tanítja programozni a mesterséges intelligencia.” Azt hiszem ezzel a mondattal válaszoltam is egyben arra, hogy milyen hatással lesz idővel a szoftverfejlesztésre. A tesztelésben szerintem kiváltja a konkrét tesztelőt, mint ahogyan egy gyár csomagoló részlegén a gép leváltotta már az embert, és még sokkal hatékonyabb is.

K. S.: Van kedvenc IT-s idézeted?

S. A.: “Quality is never an accident, it is always the result of intelligent effort.” – John Ruskin
Ha magyarul szeretném ezt megfogalmazni: a minőség sosem véletlenszerű, hanem a szakszerű erőfeszítés eredménye.


Blog bejegyzéseink IT karrier témakörben

Bobály Gábor

Interjú Bobály Gáborral

Bobály Gábor logisztikával foglalkozott korábban tíz évig, különböző munkahelyeken, különböző munkaköröket betöltve. Három éve tudatosan közelít az IT felé. Sikeresen elvégezte az alapozó Java SE szoftverfejlesztő, majd ezt követően a ...
Bővebben
Révész András

Interjú Révész Andrással

Révész András alapvégzettsége biológus, ökológia szakiránnyal. Szakmai pályafutását tájökológiával kezdte, azon belül is élőhely térképezéssel, amihez kötődik a térinformatika. Négy évig kutatás-fejlesztéssel foglalkozott az MTA Ökológiai és Botanikai Intézetében, majd ...
Bővebben
Schmidt Attila

Interjú Schmidt Attilával

Schmidt Attila három éves szoftverfejlesztői gyakorlattal (főként Android platformhoz kötődően) és két éves szoftvertesztelői tapasztalattal rendelkező mérnök-informatikus. Az interjút Kaczur Sándor – az it-tanfolyam.hu alapítója és oktatói csapatának szakmai vezetője ...
Bővebben
Takács Roland

Interjú Takács Rolanddal

Takács Roland egyéves automatizálási teszt mérnöki és ötéves professzionális adatbázis-kezelés (MSSQL, Oracle) tapasztalattal rendelkező mérnök-informatikus. Jól érzi magát multikulturális környezetben. 2017 nyara óta külföldön él és dolgozik. 2018 őszétől PL ...
Bővebben
Lovas Bertalan

Interjú Lovas Bertalannal

Lovas Bertalan 22 éves pályakezdő szoftverfejlesztő. A kütyük mindig érdekelték. Hivatásként és hobbiként is gondol a programozásra. Sportos, korábban dzsúdózott, tornázott és a műugrást is kipróbálta. Korábban részt vett a ...
Bővebben

Interjú Görög Ibolyával

Görög Ibolya protokollszakértőt mindenki ismeri, bemutatni nem szükséges. De mégis illik, legalább röviden: 1987-től 1999-ig a Miniszterelnöki Hivatal protokollosa, majd protokollfőnöke volt, illetve 1999-től felnőttképzésben oktat. Érdeklődési körébe tartoznak: viselkedéstörténet, ...
Bővebben
Nádai Gábor

Interjú Nádai Gáborral

„Nádai Gábor vagyok, de sokan leginkább Mefiként ismernek, a legtöbb felületen a @mefiblogger nicknév alatt vagyok elérhető. Eredetileg mérnökinformatikusként végeztem, a kétezres évek közepén a fősuli mellett saját vállalkozásba kezdtünk ...
Bővebben
Szűcs Tibor

Interjú Szűcs Tiborral

Szűcs Tibor mérnök-informatikus. Jelenleg a Corvinus Egyetem Koordinációs Irodáján dolgozik órarendszerkesztőként. Ez a feladat a létesítménygazdálkodáshoz kötődik és ő osztja be – sok-sok szempont alapján – az előadásokat, szemináriumokat, számítógépes ...
Bővebben
Markovics Győző

Interjú Markovics Győzővel

Markovics Győző nem­zet­kö­zi kap­cso­la­tok sza­kos köz­gaz­dász, va­la­mint po­li­to­ló­gi­át is ta­nult a Bu­da­pes­ti Cor­vi­nus Egye­te­men. Az egye­tem­től fő­ként időt ka­pott – fel­nő­ni a kép­zés alatt. Gya­kor­la­ti is­me­re­te­it min­dig mun­ká­val sze­rez­te. Csa­lá­di ...
Bővebben

Denevérek a barlangban

Évekkel ezelőtt hálózatos Java EE esettanulmányt akartunk készíteni Lengyel Borisz kollégával. Ötleteltünk: milyen technológiával és hogyan kommunikáljon egymással a szerver és a kliens(ek). A távoli metódushívás (Remote Method Invocation) mellett döntöttünk és elkészült a denevérek a barlangban projekt, amely evolúciós projektként azóta több változatot is megélt. A felhasználói felület (barlang) betölt néhány képet (denevér kliensek), amelyek a szerver segítségével mozognak.

Ismertetjük a tervezés folyamatát, a kliens és szerver funkcióit részletesen, végül ötleteket adunk a továbbfejlesztésre.

A főbb feladatokat így határoztuk meg:

  • az RMI kommunikációs módszer megismertetése,
  • az RMI szolgáltatás reprezentálása látványos grafikus/swinges klienssel,
  • alternatíva nyújtása a TCP protokoll közvetlenül csatlakozó socket-jére.

Elkészítettük az alábbi osztálydiagramot (persze ez nem az első változat):

Denevérek a barlangban - Osztálydiagram

A szerver és kliens funkcióit megvalósító osztályok/interfészek feladatait így határoztuk meg:

BarlangDenevérInterfész interfész:

  • véletlen 5 és 10 közötti a denevérek száma,
  • méretek a GUI-hoz.

Denevér osztály:

  • megvalósítja az RMI kliens funkciót,
  • JLabel leszármazott, külső képfájlt tölt be ( bat.jpg),
  • egyedi azonosítója van,
  • eldönti mozgásának irányát (4) és léptékét (3), mintha ultrahangot adna,
  • a szerver megadja neki, hogy az új helyre elmozdulhat-e,
  • saját magát képes mozgatni.

Pozíció interfész:

  • öröklődik a java.rmi.Remote interfészből,
  • két távolról hívható metódus fejét tartalmazza.

BarlangSzerver osztály:

  • megvalósítja az RMI szerver funkciót,
  • implementálja a Pozíció interfészt,
  • JFrame leszármazott,
  • figyel arra, hogy a denevérek ne mozogjanak ki a barlangból.

BarlangFelület osztály:

  • JFrame leszármazott,
  • GUI az RMI kliensek megjelenítéséhez.

BarlangSzerverTérkép osztály:

  • JPanel leszármazott,
  • GUI a szerveren a kliensek mozgásának követésére.

Ha futtatjuk az elkészült szerver és kliens programot, akkor ezt láthatjuk:

Denevérek a barlangban - animáció

A fejlesztés és tesztelés közben sok-sok továbbfejlesztési ötletet/javaslatot fogalmaztunk meg:

  • háttérkép a barlangról,
  • a háttérkép megvalósíthat labirintust, koordináta-rendszert,
  • átlátszó illetve egyedi képfájlok a denevéreknek,
  • a denevérek mozgásának tetszőleges iránya (360°),
  • a denevérek mozgásának egyedi léptéke,
  • a denevérek figyeljenek egymásra (ne ütközzenek össze),
  • a denevérek figyeljenek a környezetükre (ne ütközzenek bele sziklákba, cseppkövekbe),
  • a szerver követheti a denevérek útvonalát,
  • a szerver archiválhat, szerializálhat, készíthet statisztikát.

A bejegyzéshez tartozó – több lépésben továbbfejlesztett – forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java EE szoftverfejlesztő tanfolyam 21-24. óra: RMI alapú kommunikáció alkalmához kapcsolódik.