Péntek 13

Péntek 13

Péntek 13Sokan szerencsés vagy balszerencsés napnak tartják a péntek tizenharmadikát. Évente 1-2-3 alkalommal megtörténik, hogy a hónap 13. napja péntekre esik (minden vasárnap kezdődő hónapban). A hónap 13. napja valamivel valószínűbben péntekre esik, mint a hét bármely más napja. Átlagosan 212,35 naponként fordul elő péntek 13. Előfordulhat két egymást követő hónapban is, de akár 14 hónap is eltelhet két péntek 13 között.

A nap említése sok helyen előfordult: regényekben, filmekben, híres emberek születése vagy halála is esett péntek 13-ra. Átlag alatti közlekedési baleset szokott előfordulni ezeken a napokon – talán mert az emberek óvatosabbak. Kimutatható összefüggést/korrelációt, „péntek 13 hatást” figyeltek meg a tőzsdén is.

Hasznos lehet, ha írunk egy Java programot, amely néhány egymást követő év esetén listázza a konzolra azokat a hónapokat, amikor 13-a péntekre esik.

Tervezés

Legyen egy listFriday13(year) eljárás, amely a paraméterként átvett évben kiírja azokat a hónapokat a konzolra, amelyekben 13-a péntekre esett/esik. Például: 2019: szeptember, december. A hónapok nevei magyar nyelven jelenjenek meg. Az adott év hónapjain végighaladó ciklus legyen hatékony. Optimalizáljunk a ciklus lépésszámára! A ciklus álljon le, ha már talált 3 hónapot (mivel nem lehet több).

1. megoldás

A megoldást a tematika Tömbök témakörében az alábbiak szerint készíthetjük el. Előismeretek: változók, operátorok, ciklusok, programozási tételek, metódusok, tömbök, String összehasonlítás. Az ismert öröknaptár algoritmusokból implementáljuk az egyiket, például:

A listFriday13v1(year) eljárásban az elemi döntés egyszerű: dayOfWeek(year, month, 13).equals("Friday"). Épít az öröknaptárt megvalósító – saját – szöveget visszaadó függvényre. A függvény az algoritmus szerinti kódok előállításához ( centuryCode, monthCode, dayCode) felhasználja a szökőév ( isLeapYear(year)) függvényt, valamint két – konstansnak is tekinthető – névtelen tömböt ( new int[], new String[]).

2. megoldás

A megoldást a tematikában Objektumorientált programozás témakörében az alábbiak szerint készíthetjük el. Felhasználjuk eddigi ismereteinket és a JDK beépített dátumkezelő (tároló, formázó) funkcióit (osztályok, interfészek, konstansok, felsorolások).

A listFriday13v2(year) eljárás a Calendar absztrakt osztály konstansait használja fel az elemi döntéshez: date.get(Calendar.DAY_OF_WEEK)==Calendar.FRIDAY. A dátumot a GregorianCalendar konstruktora példányosítja és figyelni kell a 0-bázisú hónapkezelésre. A dátum formázása során ( dfMonth) beállítjuk a megfelelően paraméterezett ( "hu") Locale típusú objektumot és a hónap hosszú nevét kérjük ( "MMMM"). A metódus generikus listába gyűjti a kiválasztott hónapok nevét, amiket végül a String.join() függvény fűz össze a megjelenítéshez.

Eredmény

A vezérlésben egy ciklus 2019-től 2038-ig szervezve az alábbi eredményt adja:

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 tematikájához kötődik a fentiek szerint: 13-16. óra: Tömbök alkalom, illetve 17-28. óra: Objektumorientált programozás alkalom.

Interjú Bobály Gáborral

Bobály Gábor

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 haladó Java EE szoftverfejlesztő tanfolyamunkat is. Az IT-ben ritka, hogy öt idegen nyelven is beszél és három középfokú nyelvvizsgával is rendelkezik. Az emberi nyelveken túl több programozási nyelvvel is megismerkedett a Javan kívül: Visual Basic, Python, fejlesztett Android platformra, valamint egy-egy SQL lekérdezés sem jelent számára gondot.

Bobály Gábor

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. december 3-án.

K. S.: Milyen IT-hez is köthető munkatapasztalattal rendelkezel?

B. G.: Logisztikai munkáim során lehetőségem nyílt nevesebb vállalatirányítási rendszerekben dolgoznom, mint amilyen az SAP vagy a Fenevision, melyekben különböző munkafázisokat könyvelhettem, szervezhettem, koordinálhattam, működtethettem. Most pedig, amikor 2G, 3G, 4G, 5G-s mobilantennákat működtetek, azokat beállítanom, konfigurálnom kell távoli szerverről.

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?

B. G.: Ha a teljes szakmai pályafutásomat nézem, akkor körülbelül 20 egységnél lehetek. Kb. 10-nél érkeztem egy fordulóponthoz, egy mérföldkőhöz, ahol IT-ra tértem át és jelentkeztem hozzátok a Java SE-re, majd az EE-re. Aztán belekóstoltam a Pythonba, VBA-ba és Androidba, így közelítve a 20 egységhez. Ezek mind egy-egy kisebb mérföldkő.

K. S.: Hogyan zajlik egy tipikus munkanapod?

B. G.: Egy kb. 10 perces bejelentkezési folyamattal kezdődik, amelyben csatlakozunk a mobilantenna-irányító rendszerekhez, amelyeket német szervereken és távoli számítógépeken érünk el. Belépünk a jegyrendszerünkbe és általában egy Office-programban ahol adminisztrálunk magunknak és a cégnek. Bejelentkezünk a Cisco Jabber kommunikációs csatornára, majd a Cisco Finesse-en keresztül az ún. Abschalte-Hotline-ba (Antenna Lekapcsoló Telefonközpont), ahol várjuk többnyire a német antennatechnikusok hívásait, akik felmennek az adótornyokba és háztetőkre antennát szerelni. Mielőtt munkához látnak, aktiváljuk az erre a feladatra az ún. dispatchnél nekik létrehozott jegyüket, lekapcsoljuk az antennaállomást, hogy ne érje őket sugárzás, miután pedig végeztek a munkával vissza felkapcsoljuk és ellenőrizzük, hogy az állomásnak van-e valami hibajelzése. Ha van, megpróbáljuk megoldani a technikussal közösen. Amennyiben ez nem sikerül, akkor egy speciálisabb csoportnak tovább adjuk a probléma kezelést. Antennacsere vagy új állomás esetén többnyire mi konfiguráljuk az új antennákat. Ha minden rendben van, akkor zárjuk a jegyet és kész az adott feladat.

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

B. G.: Legalapvetőbb talán a Cisco Finesse ügyfélszolgálati Desktop, ami nálunk a hotline felület. Ez a Cisco Jabber kommunikációs szoftverre épül. Ez kell, hogy hívásokat tudjunk kezelni, koordinálni, monitorozni csoportszinten és egyénileg. Az antennaállomások üzemeltetéséhez használjuk a Huawei U2020 Topology Managert, az Ericsson Amos Object Scriptinget, valamint a Nokia Site Managert. Ezek eléréséhez a NoMachine távoli desktopot alkalmazzuk. Jegyrendszereink a belső fejlesztésű COMS és CASM.

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

B. G.: A munkám körülbelül 55%-ban adminisztráció és ahhoz kapcsolódó kommunikáció. A maradék 45% pedig az operatív munka. A hálózati meghajtónkon különböző Excel fájlokban adunk számot munkánkról. Például a lezáratlan jegyeket ellenőrizzük, vagy kiemelt ügyfelek munkáit kezeljük, ilyenek a német autógyárak, bankok vagy hivatalok. Illetve Outlookban értesítjük egymást appointment-meghívókkal, hogy leadva a műszakot, a többi kolléga mikor kapcsoljon fel egy-egy állomást.

K. S.: Nem gyakori, hogy IT munkakörben valaki német, angol, szerb nyelvekből középfokú nyelvvizsgával rendelkezik, illetve alapszinten spanyolul és olaszul is beszél. Hogyan szeretnéd ezt minél jobban hasznosítani a jövőben?

B. G.: Mindenkori pozíciómat úgy szeretném a lehetőségekhez mérten kiválasztani, hogy a lehető legtöbb tudást tudjam kamatoztatni, fejleszteni. A német technikusok mellett szoktak angol nyelven beszélő technikusok is dolgozni, ők jórészt cseh, lengyel, szlovák, román nyelvterületről jött szakemberek. Időnként szoktak nyelvi nehézségek lenni, ilyenkor egy-egy plusz nyelvtudás általában segíti a dinamikusabb kommunikációt.

Bobály Gábor

K. S.: Kipróbálnád magadat külföldön?

B. G.: Mindenképpen nyitott lennék rá. Feleségemnek kutatómunka keretében többször volt lehetősége külföldi ösztöndíjakat igénybe venni, amelyek egyikébe nem tartjuk elképzelhetetlennek a becsatlakozásomat. Most is fut néhány közös számítógépes nyelvészeti „projektünk” házon belül 😊.

K. S.: Egy vállalatirányítási rendszer testre szabása során adódhatnak egyedi szoftverfejlesztési lehetőségek? Részt vettél ilyen folyamatban?

B. G.: A vállalatirányítási rendszerünket német kollégák fejlesztik, bekapcsolódási lehetőség itt még nem adódott.

K. S.: Hogyan működsz csapatban? Hogyan illeszkedsz be egy új munkahelyen, új csapatban?

B. G.: Szakmai dolgokat tekintve, először megpróbálom megragadni a feladat gerincét, majd abból szerteágazóan kibontakozni. Próbálok időt adni magamnak a logikai értelmezésre. Ha ez sikerült, akkor általában találok saját új módokat az automatizálásra és a kreatív fejlesztésekre. Szeretek szakmai mélységekig menni és ilyenkor sok kérdést teszek fel. És ha ezek is mennek, akkor többnyire magabiztos leszek, és nem okoz gondot felvenni a csapat ütemét. Mindkét oldalról türelemre van szükség a kezdetekben.

K. S.: Tudom, hogy a csapatmunkát segítő kisebb szoftvereket fejlesztettél Java és Visual Basic nyelveken. Ismertetnéd ezeket? Hogyan merült fel rájuk az igény? Milyen folyamatokat tesznek könnyebbé? Milyen alapfunkciókat valósítanak meg?

B. G.: Először Java nyelven egy antennahibákat nyilvántartó programot készítettem. Amikor megjelenik egy hibajelzés az egyik antennán, akkor részletesebb leírása, útmutatása csak lassabb, körülményesebb úton érhető el. Ezt hivatott ez a program gyorsítani, valamint a leírást a lényegre törően leszűkíteni. Excellel szemben a kompaktivitás, könnyebb kezelhetőség, vizualitás került előtérbe.

A VBA-s programomra akkor láttam igényt, amikor láttam, hogy a többiek elég sok időt eltöltenek az Outlook-appointmentek kiküldésével. (Egy műszakot leadó kolléga sokszor több mint 10 ilyen időpontot küld ki a következő műszakban dolgozó kollégáknak antenna felkapcsolásra, adatokkal). Nekem nagyon tetszett, mikor VBA-val Excelből, miután kiválogattam CheckBoxokkal a kollégák neveit egy ListBoxba, egy gombbal elküldhetek akármennyi appointmentet. Így ez a kb. 40 perces munka lerövidül 5 percre.

K. S.: Az utóbbi 12 évben 4 munkahelyen dolgoztál 5 különböző munkakört betöltve, a logisztikától fokozatosan közeledve az IT felé. Mi motivált a váltásokra? Mennyire voltak tudatosak ezek? Hogyan kerestél új/más munkát?

B. G.: Nálam az Excelből indult minden. 2011-ben az első igazán komoly munkahelyemen a kecskeméti Mercedes-gyárban még kb. egy szum és egy átlag függvényt tudtam leírni. Utána 2016-ban családi okok miatt visszakerültem Szegedre. Ekkor a szegedi CE-Glass üveggyárban dolgoztam készletgazdálkodóként, amikor nagyon megerősödött az Excel-tudásom. Ekkor már 6-7 fajta függvény egymásba ágyazása sem okozott különösebb gondot. Ekkor kérdezte meg a feleségem, hogy miért nem tanulok programozni, mikor látta a függvény-rendszereimet. Ekkor döntöttem a programozás mellett és jelentkeztem hozzátok. A Java SE tanfolyamnak köszönhetően már tudatosan kerestem olyan munkát, ami közel áll az IT-hoz, így kerültem az ITSH-hoz.

K. S.: 2017-ben végezted el – még az IT Karrier programban nálunk – az alapozó Java SE szoftverfejlesztő tanfolyamot. Mi motivált arra, hogy jelentkezz? Miért éppen ezt választottad?

B. G.: Szegeden csak úgy tudsz programozni tanulni (nem autodidakta módon), ha beiratkozol az egyetemre, és akkor rengeteg járulékos tantárgy mellett esetleg programozást is tanulsz, továbbá azért az időtávlat is fontos (egyetemen minimum 3 év a képzés). Vagy keresel egy olyan tanfolyamot, ami csak programozásra fókuszál rövidebb időintervallumban. Ez utóbbira Szegeden akkoriban nem nyílt lehetőség. Így ár-érték arányban az IT Karrier volt a legkedvezőbb választás még úgy is, hogy fel kellett járni Pestre.

K. S.: 2018-ban végezted el – ismét nálunk – a haladó Java EE szoftverfejlesztő tanfolyamot. Mi motivált arra, hogy újra hozzánk jelentkezz, illetve arra, hogy továbbra is Java programozási nyelvvel foglalkozz?

B. G.: A Java SE képzés során szerzett kedvező tapasztalatoknak köszönhetően jelentkeztem ismét. A Java EE szerintem jobban illeszkedik egy multi cég mindennapjaiba, valamint korszerű ismeretekkel is fölruház.

K. S.: Milyen kihívást jelentett és mekkora erőfeszítést igényelt a Java EE szoftverfejlesztő tanfolyam online vizsgafeladatának csoportos megoldása?

B. G.: Hasonló csoportmunkában korábban nem vettem még részt, így érdekes kihívásnak bizonyult. Mivel egymásra épültek a feladatok, nehézséget jelentett, ha esetleg az egyik csoporttag nem készült el időre. Ugyanakkor pozitívum volt, hogy jobban tudtunk együttműködni a közös cél érdekében a csoporttársakkal és többféle megoldásra is ráláthattam.

Bobály Gábor

K. S.: Milyen soft skillek szükségesek jelenleg a programozás/szoftverfejlesztés területén?

B. G.: Szerintem elég sok. Talán a legfontosabb a logikus gondolkodás és a türelem. Fontos kitérni arra, hogy az informatika folyamatosan fejlődik, mindig keletkeznek új dolgok, ezért nyitottnak kell lenni az újra. Ahhoz, hogy a csoport is hatékonyan működjön, szükség van az együttműködésre való készségre.

K. S.: Hogyan gyűjtesz magadnak értelmes referenciát karrierváltóként?

B. G.: Egyrészt az utóbbi két munkahelyemen valamelyik munkafolyamat automatizálására vagy optimalizálására írtam programokat. Illetve munkán kívül programozgatok és ezeket mutatom fel. Végül felsorolom az önéletrajzomban azokat az IT képzéseket, amelyeken részt vettem.

K. S.: Mik a jelen és szerinted mik lesznek a jövő sikerszakmái?

B. G.: Szerintem amik a jelenben sikerszakmának tekinthetők, azok a meglehetősen nagy koncentrációt igénylő és felelősségteljes pozíciók, mint például a repülőtéri szoftverek programozása (a Lufthansa irodája hamarosan ezeket csinálja Szegeden), a légiirányítás vagy a gyógyászatban a műtőrobotok (például lézeres szemműtét) programozása.

Nekem eléggé futurisztikus a gondolkodásom 😊. Nemhiába tértem át programozásra, hiszen ez kiállja majd az idő próbáját szerintem: robot és cyborg-programozás, DNS-programozások, plazmaerőmű programozások. Remélhetőleg az emberiség továbbra is egyre több felfedezést tesz, így a programozás előtt is sok új kihívás fog adódni.

K. S.: Követed a szakmai blogunkat? Ajánlanál belőle egy-egy bejegyzést?

B. G.: Ha van időm, rá szoktam nézni :). Utóbbi időben a programozási nyelvek népszerűségéről szóló cikket találtam különösen érdekesnek, de hasznosak az egyes programozási példafeladatokat szemléltető bejegyzések is.

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

B. G.: Ez egy tipikus:
– Van szilveszterre programod?
– Még nincs.
– Írjak egyet?


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
/
Csolti Péter

Interjú Csolti Péterrel

Csolti Péter informatikatanár, az OKJ szakképzés területén dolgozik. Több intézményben is programozást tanít. A SZÁMALK-Szalézi Szakgimnáziumban a szoftverfejlesztő szak szakfelelőse. Ismeretsége az informatikával a Word és az Excel programokkal kezdődött ...
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
/

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
/
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
/
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
/

Kígyókockát készítünk

Kígyókocka

KígyókockaA kígyókocka (snake cube, chain cube) 27 egyforma méretű, egymáshoz képest mozgatható/forgatható kockából áll. A kockákat összeköti egy rugalmas fonal/gumi. Az első és az utolsó kocka egy-egy lapján egy-egy lyuk van. A közbenső kockák hat lapjából kettő lyukas. Fából és műanyagból is készülhetnek. Általában kétféle színnel színezettek a kockák. A cél, hogy a 27 kockát kígyózva „összehajtogatva” a kígyó (lánc) összeálljon egy nagyobb 3x3x3 méretű kockává.

A színek – a játék gyártóitól függően – nehézségi szinteket jelölhetnek (zöld, kék, piros, narancs, lila). Léteznek könnyebben és nehezebben megoldható kígyókockák. Előbbieknél többször fordul elő két egymással szemben lévő lyukas lap a közbenső kockákon, utóbbiaknál gyakoribbak az egymással szomszédos lapokon lévő lyukak. Másképpen: előbbiben több a három hosszú egyenes rész, utóbbi szinte állandóan tekereg. Általában a kocka egyik csúcsából kezdjük a megoldást, de az igazán nehéz játékok esetében a kígyó indulhat akár a kocka egyik lapjának (3×3) középső kockájától is.

Vannak olyan kígyókockák, amelyeknek több megoldása is van, azaz többféleképpen is összeállítható kockává. Ezek részletes ismertetése (típusok, gyártók, színek), a megoldások (statikusan és dinamikusan), irányokat mutató jelölésrendszer (Front, Left, Up, Back, Right, Down) elérhető Jaap Scherphuis – holland puzzle rajongó – weboldalán: Jaap’s Puzzle Page.

Kígyókocka

Olyan Java programot készítünk, amely véletlenszerű kígyókockát állít elő.

Tervezés

Szükséges egy háromdimenziós tömb adatszerkezet a kocka tárolására. Több okból is hasznos, ha a tömb mérete 5x5x5. Egyrészt így indexek 0-tól 4-ig futnak és a tömb közepén lévő 3x3x3-as kocka elemei kényelmesen – mátrixszerűen – indexelhetők 1-től 3-ig. Másrészt a tömb közepén lévő 3x3x3-as kocka minden elemére igaz, hogy egységesen van 26 db érvényesen indexelhető szomszédja. A 125 tömbelemből a széleken lévő 98 elem negatív számokkal feltölthető.

A szokásos i, j, k egységvektor rendszerben (koordináta-rendszerben) gondolkodva, i és j a képernyő síkját, k pedig a mélységet jelenti. A k-val 0-tól 4-ig „szeletelve” a tömböt, öt db négyzetet/mátrixot kapunk az alábbiak szerint. A színes tömbelemek negatív számokkal kerülnek feltöltésre, a kígyó útját határolják mindhárom irányból:

Kígyókocka tervezés

A belül lévő – fehér színű – 3x3x3-as kocka/tömb elemeit kezdőértékként célszerű 0-val feltölteni.

A szomszédos kockák kiválasztása során csak a középen lévő kocka 6 db lapszomszédját kell figyelembe venni. A középen lévő (a következő ábrán nem látszó) kocka három tengely szerinti 2-2-2 szomszédos kockája különböző színekkel jelölt.

Kígyókocka tervezés

Él- és csúcsszomszédság esetén nem tud tekeredni a kígyó. A forduláshoz/tekeredéshez legalább 3 – a kígyóban egymás utáni – kocka szükséges. Az aktuális kockának – pozíciójától függően – legfeljebb 6 lapszomszédja lehet. Ezt csökkenti, ha a kocka valamelyik csúcsban helyezkedik el, illetve menet közben is – ahogyan egyre hosszabb lesz a kígyó – folyamatosan csökken a még szabad elemek száma.

A megoldás során a belül lévő – fehér színű – 3x3x3-as kocka/tömb elemeit kell sorszámozni 1-től 27-ig, jelölve ezzel a kígyó útját. A kezdetben 0-val jelölt szabad elemek végül elfogynak.

Megállapodunk abban, hogy a kígyó az útját az (1, 1, 1) pozícióban kezdi és az 1 sorszámot kapja. Addig kell újabb szomszédos kockákat – egyesével haladva – kiválasztani módszeresen vagy véletlenszerűen próbálkozva, vagy akár visszalépéses algoritmussal is, amíg mind a 27 kiválasztásra kerül.

Megvalósítás

Létre kell hozni a háromdimenziós tömböt példányváltozóként:
int[][][] cube=new int[5][5][5];

A cubeInit() metódus kezdetben feltölti a tömb elemeit. A széleken lévő elemekbe különböző negatív értékek kerülnek, hogy jól megkülönböztethető legyen, melyik ciklus melyik pozíciókért felel. Másképpen is lehetne: például kezdetben minden elem -1, utána a belül lévők felülírhatók 0-val.

Hasznos a cubePlot() metódus, amellyel megjeleníthetők a konzolon a tömb elemei (állapota):

A getNextNeighbour() függvény egydimenziós tömbként ( int[]) visszaadja a paramétereként átvett – x, y, z koordinátával jelölt – kocka egyik kiválasztott szomszédját, amely a kígyó útját jelöli. A kiválasztás történhet módszeresen vagy véletlenszerűen próbálkozva, vagy akár visszalépéses algoritmussal is. A metódus forráskódját most nem részletezem. A metódus felelős a kígyó helyes útvonaláért, azaz a kiválasztás során a kígyó nem rekedhet meg zsákutcában, másképpen nem haraphatja meg saját magát.

A vezérlést a run() metódus végzi el az alábbiak szerint:

Addig fut a ciklus, amíg a kígyó nem tölti ki a 3x3x3-as kockát (másképpen: amíg a kígyó nem éri el a maximális hosszúságot). A tömb állapotát kezdetben és lépésenként is kiíratja a vezérlő metódus a konzolra.

Konzolos eredmény

A konzolos eredmény előállításánál fontos volt, a tömb változásait tudjuk követni. Az összes negatív szám elhagyható lehet a kiírásból, ha meggyőződtünk az implementált algoritmus helyes működéséről. Átlátva a problémát, a megoldás könnyen elállítható egy grafikus és/vagy egy irányokat mutató jelölésrendszer szerint is, például:

Kígyókocka tervezés

Hivatkozások

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 tematikájához kötődik. Több alkalommal is tudunk ezzel a feladattal foglalkozni, attól függően, hogy a getNextNeighbour() függvény működését hogyan tervezzük és implementáljuk:

  • A 13-16. óra: Tömbök témakör esetén a szomszédos kockák közül módszeresen – azonos sorrendben haladva a legfeljebb 6 lehetséges szomszéd közül – választjuk ki mindig az elsőt. Ekkor mindig ugyanazt az egyetlen helyes megoldást kapjuk meg.
  • A 17-28. óra: Objektumorientált programozás témakör esetén atipikusan a kivételkezelést használhatjuk vezérlésre úgy, hogy a lehetséges szomszédos kockák közül mindig véletlenszerűen választunk. Ekkor a kígyó önmagába harapását úgy előzzük meg, hogy tömb túlindexelésekor keletkező kivételt benyeljük és újrakezdjük a feladatot mindaddig, amíg találunk egy olyan megoldást, aminek lépései közben nem keletkezik kivétel.
  • Az orientáló modul 9-12. óra: Mesterséges intelligencia témakör esetén véletlenszerű kocka kiválasztási stratégiával rendelkező visszalépéses algoritmust specifikálhatunk és implementálhatunk. Ez lényegesen összetettebb feladat és mindig helyes megoldást ad több lehetséges megoldás közül.

Fejlesztők délutánja – látogatás a KUKA Hungária Kft. R&D központjában

kuka-logo2019. november 7-én délután látogatást tettem a KUKA Hungária Kft. telephelyén, ami Budapesten, a XI. kerület Dorottya udvarban található. A rendezvényre elsősorban programozáshoz értő fejlesztőket vártak, az már a jelentkezési lapról kiderült, amikor meg kellett adni, hogy milyen programnyelvekhez értek.

Az ott töltött időt három nagyobb részre lehetett osztani. Először a prezentációs bemutatkozások zajlottak, azután a robotok megtekintése, végül pedig egy pizzázással egybekötött kötetlen beszélgetés az előadókkal.

Prezentációk

Először Grósz László R&D vezető bemutatta a céget, és a KUKA cég történelmét. Régóta fennálló céget ismertem meg, melyet 1898-ban alapítottak. Abban az időben acetiléngázt állítottak elő, amivel világítótesteket lehetett működtetni. Nem sokkal később az elektromos világítás megjelenésével és terjedésével a hegesztéstechnikai szektorba helyezték át tevékenységüket, ahol úttörőnek számítottak. Látták az igényt és a lehetőséget a hegesztőgépek automatizálására, így 1956-ban első automata hegesztő gépeik a Volkswagen AG-nál kerültek üzembe. A fejlesztés tovább folytatódott és az első ipari robotjuk, a 6 elektromechanikus meghajtású tengellyel rendelkező Famulus 1973-ban készült el. 1996-ban a KUKA a robotjainak vezérlését PC alapúra cserélte, elsőként az iparágban.

Az ezredforduló után a cég számos további területen jelent meg robotjaival, például az egészségügyben. Az utóbbi évtizedben pedig azon dolgozik, hogy olyan robotokat fejlesszen ki és gyártson (LBR iiwa), amelyek képesek az emberrel együttműködve dolgozni.

Collaborative Roboter

Második előadó Komlósi István vezető fejlesztő volt, aki a mobil robotok fejlődéséről beszélt. Napjainkban fontos hívószavak az ipar 4.0 és az okos gyár. Ebbe a paradigmába illeszkedik bele a KUKA a földön mozogni képes, kerekeken mozgó robotjaival. István bemutatott nekünk egy rövidfilmet, ahol a robotok a Boeing gyárban teljesítenek szolgálatot, feladatuk pedig különböző méretű és nagyságú alkatrészek, vagy akár egy fél repülőgéptest szállítása volt.

Mindegyik robot képes volt a saját környezetét érzékelni, mozgás közben előállítani a terület térképét, és elkerülni az útjukba kerülő akadályokat. Ilyen akadályokból többféle is előfordulhatott. Átmeneti akadály, például egy ember vagy másik robot akadályozza a továbbhaladást, ekkor elegendő várakozni amíg az akadály el nem hárul. Állandó akadály, ami olyan új utat elzáró tárgy, ami korábban nem volt jelen, és nem lehet arra számítani, hogy rövid időn belül úja szabaddá válik az út. Ekkor a robotnak ki kell kerülnie az akadályt, ami azt jelenti, hogy az éppen aktuális térképet figyelembe véve új haladási útvonalat kell tervezzen a céljához, majd ezt végre kell hajtania.

A felhő alapú információfeldolgozás a robotikában is utat talált magának: a fejlesztők arra törekszenek, hogy minél inkább felhő alapú legyen a robotok információinak a feldolgozása, ahelyett, hogy magára a robotra kelljen bonyolult és drága információfeldolgozó számítógépeket telepítsenek, így csökkenthető az egyes termékek – amúgy sem csekély – ára. Ahhoz, hogy megvalósulhasson a felhő alapú információfeldolgozás, nagyon alacsony hálózati késleltetésre van szükség, például a napjainkban szárnyait bontogató 5G mobilhálózatra. Itt hangzott el a mesterséges intelligencia szerepe is, amely ipari alkalmazásokat tekintve, csak teljesen biztonságos formában, népszerű hívószóval AI-Safe módon kerülhet alkalmazásra.

Harmadik előadónk Laboda Krisztián volt, csapatvezető és Software Architect. Az ő előadása robotprogramozásról, azon belül is útvonaltervezésről szólt, természetesen csak áttekintő jelleggel. Kezdetben az ipari robotoknak saját, dedikált térre volt szükségük, amelyben mozogni tudtak. Nem voltak képesek érzékelni a környezetüket, de a rájuk bízott és előre megtervezett mozdulatsorokat tetszőleges számban megismételve precízen tudtak dolgozni. A mozgás leírása spline polinomokkal történhet.

Ha mobil robotokban gondolkodunk – ráadásul az emberrel is együttműködni képes robotokban – a probléma az, hogy nem mindig írható le a mozgás teljes pályája, hiszen váratlan események is bekövetkezhetnek a mozgás közben. Ebben az esetben pedig újra kell tervezni a mozgást, amit nyílt hurkú szabályozók használatával érnek el. Így a teljes mozgást kis időszeletekre elosztva, mindig csak a következő időszeletet megtervezve lehetőség van észlelni és reagálni a külvilág felől érkező információkra. A külvilág érzékelése bonyolult művelet, a jelenlegi tudásunk alapján már nem egy gép szenzorjaival dolgoznak az algoritmusok, hanem több gép szenzoradatát összesítve, úgynevezett szenzorfúzióval állítják elő a külvilág modelljét, és ebben a modellben tervezik meg a következő mozdulatot.

Krisztián másik megvilágításból is bemutatta a robotprogramozást. A közönséggel közösen megállapodtunk, hogy a földön élő emberek kb. 0,3%-a tud programozni, és egy-egy robot felprogramozása egy konkrét feladatra – természetesen csak nagy átlagot tekintve – kb. 200 munkaóra. A KUKA-nál azt szeretnék elérni, hogy ennél sokkal többen tudjanak robotot programozni, akár programozói tudás nélkül is, ezért létrehozták az LBR iisy kísérleti platformot.

LBR iisy Product Image

Ez a robotkar érzékeny az emberi mozdulatokra, ezért képes az együttműködésre, és a Scratch-re megszólalásig hasonlító programozási felületet kapott. A gyártó cég fejlesztői elkészítik az egyes utasítások mögött álló bonyolult kódot, így a felhasználónak már csak az egyes magasszintű utasításokat kell grafikusan összeállítania a kívánt hatás elérésére. Ezt a rendszert nyílttá szeretnék tenni a külső cégek számára, akik eszközöket szeretnének gyártani a robothoz. (Eszköz alatt itt azt értem, hogy a robot „keze” cserélhető, így több feladatra is alkalmas lehet). A külső cégek elkészíthetik az általuk kifejlesztett eszközhöz tartozó programozói könyvtárakat, amit a felhasználó egy fogd és vidd művelettel a robotjához tud rendelni. Az így elkészített programkönyvtárak pedig letölthetőek lesznek egy erre a célra épített alkalmazásboltból.

Utolsó vendég előadónk Dr. Kiss Bálint, a BME Irányítástechnika és Informatika Tanszékének vezetője volt. Ő a mobil robotok fejlesztésének jövőjébe engedett bepillantást. A fejlesztők számára megoldandó feladatok összességét egy mocsárként jellemezte, amelyben vannak könnyű, nehéz és szinte megoldhatatlan feladatok. Ha a fejlesztők meg is oldanak egy-egy feladatot, a következő lépésük a mocsárban egy újabb problémához fogja vezetni őket. Így tekintve nagyon nehéz megmondani, hogy a vágyott végkifejlet mikor is fog elérkezni. Amit mondani lehet, hogy egyes részproblémák megoldásával milyen új alkalmazási lehetőségeink lesznek a közeljövőben.

Kétféle fejlődési irányt lehet megkülönböztetni, ahogyan el lehet jutni a teljesen önállóan működő mobil robothoz. Az első irányzat sokunk számára ismert, gondoljunk csak a mai autóinkra. Egyre többféle vezetést támogató rendszert építenek be a járművekbe, ezzel egyre több feladatot vállal át az autó a vezetőtől. Az ideális állapot az lesz, ha a vezetőnek egyáltalán nem marad majd vezetési teendője. Az ipari robotok esete pont ellentéte ennek. Az ipari robot az első pillanattól kezdve önállóan és biztonságosan kell végrehajtsa a rábízott feladatot, és idővel a robot környezete válik egyre bonyolultabbá, ahogyan egyre nő az igény az alkalmazásának sokféleségére. Először még csak egy elkerített privát térben tevékenykedett, ma már emberek és folyamatosan változó környezetben kell helyt állnia. Probléma, hogy nincs egy egységes szabvány a robotok biztonságos működésére. További probléma, hogy sokféle kihívással találkozhatunk egy mobilis robot fejlesztése kapcsán, ám ezek a kihívások már évtizedek óta léteznek, mint ahogyan a rájuk adott válaszok is.

A különbség a válaszokban az eltelt idő, ugyanis egyre jobb, pontosabb, korszerűbb válaszokat tudunk adni egy-egy kihívásra. Shakey volt az első robot, amely válaszolni kívánt a kihívásokra. 1966-tól 1972-ig fejlesztették és a maga korában egyedülálló volt. Az adott válaszok minőségének javulását többek között ilyen technológiák tették lehetővé: Li-Ion akkumulátor, Lidar, szenzorfúziós becslések, Kálmán-szűrő eljárás, GPU hardver, deep learning.

Végezetül megismerkedhettünk két, a mai kor tudása szerinti válasszal a mobil robot építés kihívásaira. Egy űrben használható robottal, Robonaut 2-vel, ami éppen a nemzetközi űrállomáson tartózkodik, és egy víz alatt használható változattal, Aquanaut-tal.

Robotok megtekintése

Először a robotkarokkal dolgozó fejlesztők laborjában megismerkedtünk az LBR iiwa robotok programozásával, működésével. Placskó András fejlesztő és Schieder Gábor csapatvezető mutatta meg nekünk, milyen egyszerű is egy robotot Scratch-szerű felületen programozni. Tíz-tizenöt parancsból álló kis programmal a robotkar képes volt egy golflabdát megfogni, és egy másik pozícióba áthelyezni. Ehhez természetesen az kellett, hogy ezeket a magasszintű utasításokat előtte a mérnökök elkészítsék. Egy másik robotkaron pedig azt tudtuk kipróbálni, hogy milyen az, amikor az ember együttműködik a robotkarral. Az első bemutató program mozgatta a kart, közben pedig valaki a kezét a kar útjába tette. Alig érintette meg a kar az akadályt, azonnal megállt. Számomra meglepően kis erőket is pontosan tudott érzékelni a robotkar. Másodjára pedig kézzel szabadon mozgathattuk a robotkart és követte az iránymutatásunkat. Így lehetővé vált a „megmutatom a pozíciót”-szerű betanítás, nem csak a vezérlőn keresztüli „addig léptetem, amíg jó helyre nem kerül” fajta.

A robotkarok után továbbmentünk a mobilis robotok laborjába. Itt is két bemutatót nézhettünk meg Baji Bence csapatvezető és Fehér Ágoston csapatvezetők jóvoltából. Ezek a robotok kerekekkel rendelkeztek, így tudtak helyet változtatni. Az első robotra felszereltek egy LBR iiwa kart is, melynek kezében egy kartonlap volt. A kartonlap két felén pedig David Hasselhoff, amint egyszer boldog, egyszer pedig mérges. A robot programja szerint: ha David Hasselhoff jókedvű, akkor a robothoz legközelebbi személy elől megpróbál elmenekülni, ha pedig mérges, akkor a legközelebbi személyt üldözőbe veszi. A két állapot között pedig a robotkart ért külső nyomás váltott. David Hasselhoff mindig a célszemély felé nézett. A fejlesztők elmondták, hogy szerencsénk van, mert ezt a projektet eddig csak a KUKA-s fejlesztőcsapat látta, még nem mutatták be sehol a közönségnek. A program célja pedig az, hogy legyenek olyan látványos és egyszerű alkalmazások, melyeket kiállítások alkalmával be tudnak mutatni, így szemléltetve a robotok képességeit.

A második elkerített részben három „raktáros” robot dolgozott, alágurultak az áruval megrakott polcoknak, kicsit megemelték, és a hátukon vitték a kijelölt új pozícióba. A három robot mozgását egy központi raktár menedzser program koordinálta. A robotok önmaguktól csak arra voltak képesek, hogy a négyzetrácsosan felosztott térben egy téglalappal odébb menjenek, és annak pontosan a közepén megálljanak. A több robot ütközésmentes mozgatását a menedzser program irányította, ami teljesen a budapesti központ fejlesztése.

Számomra az volt a meglepetés, hogy több százszor, vagy ezerszer megemelt, mozgatott és letett polcok pontosan három centiméter távolságban voltak egymáshoz képest. Ilyen pontos pozícionáláshoz elegendő volt mindössze a robotok alján található egy darab kamera, és a padló virtuálisan téglalapokra osztott területén, minden téglalap közepén elhelyezkedő QR-kód-szerű matrica.

Pizza és kötetlen beszélgetés

Az utolsó napirendi pont, a pizza és a beszélgetés következett. Laboda Krisztián mellett találtam helyet, néhány további érdeklődővel együtt. Arról kérdeztük Krisztiánt, hogy milyen feltételei vannak, ha valaki a KUKA-hoz szeretne jönni dolgozni, milyen programozási nyelvet érdemes tudni, milyen tapasztalati szint elegendő egy sikeres felvételihez, hogyan zajlik náluk a felvételi eljárás. Ő azt válaszolta, hogy sokféle programnyelvvel dolgoznak, a C, C++, C#, Java nyelveket biztosan használják, de előfordul náluk a JavaScript, TypeScript is, sőt, néha a Python-ra is szükségük van. Tapasztalati szint szerint a juniortól egészen a csapatvezetőig keresnek munkatársakat, természetesen nem egyszerre mindenfélét, inkább szükség szerint. Egykörös interjúkat szoktak tartani.

Nagyon érdekes délutánt töltöttem el a KUKA Hungary Kft. rendezvényén, ahol látszott, hogy sok vendéget megfogott a téma és az ipari robotos világ. Ha valaki érdeklődne hasonló nyílt napok után, érdemes a KUKA Global oldalt követnie a facebookon, mert várható, hogy a cég félévente újabb fejlesztői délutánokat fog szervezni.

A rendezvény szervezői nem engedélyezték a fényképezést.

Kik vettek részt projektmunkában?

Projektmunka

ProjektmunkaHasonlítsuk össze a részlegeket fókuszálva arra, hogy az alkalmazottak mennyire vettek korábban részt projektmunkákban! Hányan igen és hányan nem? Van(nak) olyan részleg(ek), amelyik vezetője egyetlen alkalmazottat sem vont be projektmunkába? Van(nak) olyan részleg(ek), ahonnan mindenki csatlakozott? Vannak a feladatkiosztásban olyan aránytalanságok, amelyek kimutathatók és így a későbbiek során korrigálhatók? Készítsünk egy kimutatást arról, hogy részlegenként hány fő vett részt projektmunkában és mi a létszám! (Persze tudjuk, hogy nem minden munkakörből vonhatók be alkalmazottak.) Milyen projektjeink szoktak lenni? Van olyan részleg, ahol érdemes bővíteni a létszámot, esetleg átcsoportosítani oda erőforrást? Ezekre a kérdésekre keressük a választ.

Tervezés

Az Oracle HR sémában három tábla kapcsolódik a feladathoz: JOB_HISTORY, EMPLOYEES, DEPARTMENTS. A kapcsolatok fokszámai láthatók az alábbi ábrán. Egy részlegben több alkalmazott is lehet. Egy alkalmazott részt vehetett korábban több projektmunkában is.

Oracle HR séma

A DEPARTMENTS táblában található a részleg azonosítója ( DEPARTMENT_ID, kulcs) és neve ( DEPARTMENT_NAME). A többi adat most nem kell. 11 olyan részleg van, amihez tartozik alkalmazott.

A JOB_HISTORY tábla tárolja, hogy a már befejeződött projektekben ki ( EMPLOYEE_ID, külső kulcs) és melyik részlegből ( DEPARTMENT_ID, külső kulcs) vett részt. A dátumokat ( START_DATE, END_DATE) és a munkakör külső kulcsát ( JOB_ID) most nem használjuk. Minden projekt lezárt. 10 lezárt projekt van.

Az EMPLOYEES táblából szükséges az alkalmazott azonosítója ( EMPLOYEE_ID, kulcs), valamint részlegének azonosítója ( DEPARTMENT_ID, külső kulcs). A többi adatra most nincs szükség, de egy részletesebb – például név szerinti – kimutatáshoz már igen. 106 olyan alkalmazott van, akihez tartozik részleg (1-nek nincs).

Hozzunk létre négy oszlopból álló eredménytáblát: DEPARTMENT_ID, DEPARTMENT_NAME, COUNT_PROJECT_EMPLOYEES, COUNT_EMPLOYEES. Ennek áttekintésével választ kaphatunk a fenti kérdésekre.

1. megoldás

Induljunk ki abból, hogy a JOB_HISTORY táblában lévő DEPARTMENT_ID-hez hozzárendeljük a DEPARTMENTS táblából a DEPARTMENT_NAME-t. Ezekre csoportosítva könnyen aggregálható az adott részlegből projektmunkát végző alkalmazottak száma: COUNT_PROJECT_EMPLOYEES. Végül egy belső lekérdezés (összekapcsolva a JOB_HISTORY és az EMPLOYEES táblákat) megadja az adott részleg alkalmazotti létszámát. Az SQL lekérdezés:

SQL-megold1a

A részeredmény:

SQL-eredmeny1a

Ezután állítsuk elő a hiányzó adatokat! Tudjuk, hogy azokban a részlegekben, amelyek DEPARTMENT_ID-je nem szerepel a JOB_HISTORY táblában, de szerepel az EMPLOYEES táblában, azok léteznek, de nem „adtak” projektmunkára alkalmazottat (azaz COUNT_PROJECT_EMPLOYEES=0). Nevük és alkalmazottaik száma ugyanúgy megadható, ahogyan az előbb. Az SQL lekérdezés:

SQL-megold1b

A részeredmény:

SQL-eredmeny1b

A két részeredményt egyesíteni kell és egyben hasznos DEPARTMENT_NAME szerint növekvő sorrendbe rendezni az alábbi lekérdező paranccsal:

SQL-megold1c

Az eredmény:

SQL-eredmeny1c

2. megoldás

Kiindulhatunk abból is, hogy a DEPARTMENTS egy szótártábla, így közvetlenül hozzáférhető a DEPARTMENT_ID és a DEPARTMENT_NAME, de össze kell kapcsolni az EMPLOYEES táblával, hogy csak olyan részlegeket adjon vissza a lekérdezés, ahol van(nak) alkalmazott(ak). Az eredményhez szükséges további két oszlop könnyen aggregálható az adott részlegre vonatkozóan: a JOB_HISTORY táblában előforduló EMPLOYEE_ID-k száma adja a COUNT_PROJECT_EMPLOYEES-t (probléma nélkül tud 0 lenni) és az EMPLOYEES táblában előforduló EMPLOYEE_ID-k száma adja a COUNT_EMPLOYEES-t. A rendezés most is szükséges. Lényegesen tömörebb lekérdező parancsot kapunk:

SQL-megold2

Az eredményül kapott táblázat megegyezik az 1. megoldás eredményével.

A két megoldás teljesen különböző gondolatmenettel született. Mindkettőben vannak olyan elemek, amelyek – konkrét feladatból általánosítva – univerzálisan használhatók. Természetesen összehasonlítjuk a két megoldás végrehajtási tervét és részletesen elemezzük 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 feladat a Java adatbázis-kezelő tanfolyam 9-12. óra: Oracle HR séma elemzése, 13-16. óra: Konzolos kliensalkalmazás fejlesztése JDBC alapon, 1. rész, 33-36. óra: Grafikus kliensalkalmazás fejlesztése JDBC alapon, 2. rész alkalomhoz kapcsolódik.

Az SQL forráskód formázásához a Free Online SQL Formatter-t használtam.