Kutatók éjszakája 2021

Kutatók éjszakája logó

Kutatók éjszakája logóA Kutatók éjszakája nemzetközi rendezvénysorozat 2005-ben indult. Magyarország 2006-ban csatlakozott. Azóta évről-évre egyre több intézmény nyitja meg hazánkban kapuit, szervez érdekes programokat, sok-sok településen, több száz helyszínen, több ezer eseményt meghirdetve sok tízezer érdeklődő/résztvevő látogatónak biztosít tartalmas estét.

Bár a kezdeményezés elsősorban a kutatói pálya népszerűsítését szolgálja, ezért leginkább a tizen- és huszonévesekre számít, az események vonzók és elég érdekesek ahhoz, hogy a kisgyerekektől a legidősebbekig mindenki megtalálja a számára izgalmas programokat. Korábban nagyobb felsőoktatási intézmények és kutatóintézetek szerepeltek döntően, de az utóbbi néhány évben egyre több kisebb intézmény, tehetséggondozással foglalkozó középiskola, cég, egyesület is csatlakozott a rendezvényhez. A Kutatók éjszakája rendezvény minden meghirdetett programja ingyenes.

Rendezvényünk plakátja

it-tanfolyam.hu Kutatók éjszakája 2021 plakát

Az it-tanfolyam.hu 2021-ben is hirdetett programokat az eseményhez kötődően. Programjainkat elsődlegesen követőinknek, aktív hallgatóinknak és az alumni csoportunkban hirdettük meg, de persze nyílt rendezvényként valósult meg. Az eseményekre regisztrálni kellett a weblapon. A regisztrációs időszak két hétig tartott, szeptember 9-23-ig. Programjainkra szeptember 24-én 22:00-23:55-ig került sor.

A programjaink népszerűek voltak. A két teremben közel 50 érdeklődő látogatót fogadtunk. A többség több programon is részt vett. Néhányan kifejezetten egy-egy adott program iránt érdeklődtek. Többen is úton voltak késő délutántól szinte hajnalig, megragadva a lehetőséget, több helyszínt is meglátogattak. Kellemes hangulatban, tartalmasan töltöttük együtt az időt – végre újra személyes jelenléttel az offline világban – aminek igazán örülök.

Szeretném megköszönni az előadók színvonalas munkáját, igényes felkészülését. Köszönjük mindenkinek, aki részt vett a Kutatók éjszakája 2021 rendezvényünkön. Az előadások prezentációit tanfolyamaink hallgatói számára – a témához kapcsolódó témakörökhöz, ILIAS-ra feltöltve – tesszük elérhetővé.

22:00-22:25 – Kiss Balázs: Mitől okos egy otthon, egy pláza, egy város?
Néhány hónapja ismert, hogy okos lesz (időközben lett) az Etele pláza. Nem, nem szponzorálja 🙂 ezt az előadást. Ha a léptékeket tekintjük, akkor bizony éles a határ az otthonokban, intézményi és település szinten alkalmazott és alkalmazható okos technológiák között. Az előadó évek óta foglalkozik okos architektúrák fejlődésének történetével, koncepciójával, szoftveres integrációjával és konfigurációjával. Szívesen osztja meg gondolatait, kutatási eredményeit a témáról, beszél saját kisebb és nagyobb léptékű projektjeiről. Praktikus tanácsok is előkerülhetnek – igény szerint. Egyensúlyoz a kész komponensek testre szabási lehetőségei és a saját fejlesztés határán. Utóbbi kulcsszavai: hálózati kommunikáció megvalósítása szerver-kliens között vagy peer-to-peer többféle programozási nyelven, autentikáció, autorizáció, protokoll, tömörítés, felhő architektúrák. A program a Java tanfolyamaink orientáló moduljához kötődik.

22:30-22:55 – Kaczur Sándor: Algoritmus vesebeteg-donorok párosítására
Hogyan működik 2007 óta Nagy-Britanniában a vesebeteg-donorok párosítása? Sima csere 2 pár esetén adódik. 3 pár esetén körbeadják a vesét egymásnak – ez már jóval összetettebb probléma. A felépített óriási adatbázisban akár több száz lehetőség is adódhat. A probléma megfelelő párosítási algoritmus és számítógép nélkül, pusztán emberi erővel megoldhatatlan lenne. Az implementált algoritmus futási ideje mindössze 30 perc. A párosítást követően a következő lépés a műtétek egyidejűsége, és a donor szervek „utaztatása” minden lehetséges úton – földön, vízen, levegőben –, minden lehetséges közlekedési eszközzel. Hogyan működik mindez a gyakorlatban? Milyen korlátok, problémák adódnak? Milyen adatok alapján dönthető el a betegek „kompatibilitása”? Ezek közül mi kötődik az egészségügyhöz és mi a szállításhoz? Az előadó próbál válaszokat adni, de lehet, hogy a végén több lesz a kérdés, mint a válasz. Vajon milyen a párosítási algoritmus hatékonysága? A program a Java tanfolyamaink orientáló moduljához kötődik.

23:00-23:25 – Szegedi Kristóf: Hogyan változik a világ vezető innovációs vállalatainak 100-as toplistája?
A Thomson Reuters hírügynökség évről-évre közzéteszi a világ vezető innovációs vállalatait tartalmazó frissített 100-as toplistáját. Vajon milyen szempontrendszer alapján születik a döntés, alakul a rangsor? Az előadó áttekinti a háttérben lévő metodológia elemeit. Íme, néhány szempont: pénzügyi teljesítmény, a vezetők és befektetők közötti bizalom, innováció, környezeti hatás, emberek és társadalmi felelősség, hírnév, kockázatviselés és ellenálló képesség, jogszabályok betartása. Vajon mivel foglalkoznak a toplista elején lévő vállalatok? Kiderül, hogy az elmúlt néhány évben milyen változások történtek a toplista elején. Az előadó próbálja indokolni, vajon mik lehettek az elmozdulások okai. Lehetne előrejelzést adni és vajon érdemes? Közösen gondolkodunk mindezeken. A program a Java tanfolyamaink orientáló moduljához kötődik.

23:30-23:55 – Kaczur Sándor: Gondolkodjunk logikusan!
Az előadás során áttekintjük az intelligencia, a kreatív problémamegoldó és logikus gondolkodás összefüggéseit és izgalmas feladatokból válogatva közösen megoldunk néhány fejtörő feladatot. Néhány példa: Hány éves a kapitány?CHOO + CHOO = TRAIN, Logikus gondolkodás teszt.

 

22:00-22:45 – Hollós Gábor: Objektumorientált programozás vs. funkcionális programozás Java nyelven
Az előadó ismert adatszerkezeteket és ismert programozási tételeket használva összehasonlítja a hatékonyság szempontjai alapján egy-egy feladat különböző megvalósításait. Referenciaként tekint az objektumorientált megoldásokra és ehhez képest kiderül, hogy a Java 8-tól elérhető funkcionális elemek milyen változásokat jelenthetnek. Vajon kevesebb memóriát használnak? Vajon gyorsabbak? Vajon egyszerűbbek/bonyolultabbak? Vajon könnyebben megérthetőek, karbantarthatóak, dokumentálhatóak? Hogyan érdemes egyensúlyozni az általunk leprogramozott, a kollekciók hagyományos beépített műveleteit használó és a lambda kifejezések között? Kiderül. A program a Java SE szoftverfejlesztő tanfolyamunk tematikájához kötődik.

22:50-23:35 – Kiss Balázs: Denevérek a barlangban – Hálózatos Java esettanulmány tervezése és tesztelése
Az előadó újragondolta egyik örökzöld esettanulmányukat, amelynek koncepciója elérhető szakmai blogunkon: Denevérek a barlangban. Kiderül, érdemes-e változtatni a programban megvalósuló elosztott, hálózati kommunikáción. Tekintettel az utolsó néhány Java verzió újdonságaira, fókuszálva különösen a 13-astól a 17-esig. Ha érdemes refaktorálni, akkor megtudjuk, hogy mit és hogyan. Ha nem érdemes, akkor indoklást kapunk arra, hogy miért nem. Az áttekintett tesztadatokat elemezve megkapjuk a választ. A program a Java EE szoftverfejlesztő tanfolyamunk tematikájához kötődik.

23:40-23:55 – Falus Anita, Németh András: Karrierváltás után – néhány hónap KKV-s tapasztalatai szoftverfejlesztőként
Mennyire könnyű ma szoftverfejlesztőként elhelyezkedni szakirányú felsőfokú végzettség nélkül? Milyen kihívásokkal találkozhatunk a felvételi folyamat során? Milyen elvárásokat támasztanak a munkaadók egy junior szakemberrel szemben? Hogyan telnek a beilleszkedés után a hétköznapok junior fejlesztőként kis létszámmal működő informatikai profilú kisvállalkozásnál? A tanfolyamainkon 2020-ban végzett előadók karrierváltó junior szakemberként személyes tapasztalataikról számolnak be. A program a Java tanfolyamaink orientáló moduljához kötődik.

 

Egy matematika érettségi feladat megoldása programozással 2021

érettségi logó

érettségi logóA 2021-es középszintű matematika érettségi feladatsor 12. feladata inspirált arra, hogy a programozás eszköztárával oldjuk meg ezt a feladatot. Szükséges hozzá néhány programozási tétel: sorozatszámítás, eldöntés, megszámolás, kiválogatás. Többféle megoldás/megközelítés is előkerül. Érdekes belegondolni, hogy mennyire más lehetne a problémamegoldás, ha programozhatnánk a matematika érettségi vizsgán. A teljes feladatsor a megoldásokkal együtt letölthető az oktatas.hu-ról.

12. feladat

A háromjegyű pozitív egész számok közül véletlenszerűen kiválasztunk egyet. Mennyi annak a valószínűsége, hogy a kiválasztott szám számjegyei különbözők? Megoldását részletezze!

1. megoldás

Az 1. megoldás egymásba ágyazott ciklusokkal behelyettesíti a szóba jöhető 900 db háromjegyű szám számjegyeit. A feltétel 648 esetben teljesül. Három számjegy azonosságát két részfeltétel és kapcsolatával eldönthetnénk a trichotómia miatt. Három számjegy különbözőségéhez három részfeltétel és kapcsolatából áll össze a feltétel. A válasz a kedvező és összes eset aránya/hányadosa, azaz 0,72. Másképpen 648 db szám a 900 db háromjegyű szám közül. A megoldás lépésszáma 900.

2. megoldás

Az egymásba ágyazott ciklusok lépésszáma összeszorzódik. A legbelső ciklus az előtte lévő feltételtől függően kevesebbszer is végrehajtódhat, hiszen a százas és tízes helyiértéken lévő számjegyek egyezése esetén nincs értelme az egyes helyiértéken lévő számjegy vizsgálatának. Így a 2. megoldás lépésszáma 810, azaz 10%-kal kevesebb. Ez a három részből álló feltétel két részre bontásával érhető el.

3. megoldás

A 3. megoldásban egyetlen ciklus végzi a vizsgálatot, a megszámolást. A ciklusváltozó már nem számjegy, hanem maga a háromjegyű szám, amiről döntést kell hozni: különbözik-e mindegyik számjegye vagy sem. Három beszédes nevű segédváltozó segít értelmezni a Java forráskódot. Ezek az egész osztás és a maradékos osztás műveleteivel állíthatók elő.

4. megoldás

A 4. megoldás logikai visszatérési értékű segédfüggvényt alkalmaz. Ez egy menekülőutas megoldás. Ha kizáró feltétel szerint már döntést tudunk hozni (például megegyezik a százas és a tízes helyiértéken lévő számjegy), akkor hamis értékkel menekülünk. Egyébként ág nélkül ezután következhet az egyes helyiértéken lévő számjegy összehasonlítása a többivel. A második feltétel az eddigiekhez képest tagadott, mert a menekülés a cél. Ha nincs menekülés amiatt, hogy volt két megegyező számjegy, akkor – a feltételek egymásra épülése miatt – nincs más hátra, mint igaz értékkel visszatérni (ami azt jelenti, hogy nem volt egyezés, azaz minden számjegy különbözött).

5. megoldás

Az 5. megoldás segédfüggvénye a háromjegyű szám esetén a különböző számjegyek darabszámával tér vissza. A röptében előállított százaz, tízes, egyes helyiértékeken lévő számjegyekből folyam adatszerkezet készül, aminek feldolgozását a Stream API műveletei (egyediesítő, megszámoló) végzik el. Ezt a vezérlő ciklusban hárommal összehasonlítva léptethető a megszámolást megvalósító változó, hiszen ha teljesül a feltétel, akkor eggyel több megfelelő szám van, mint előtte volt.

6. megoldás

Az 6. megoldás újra másképpen közelít. Ha könnyebbnek tűnik az a feltétel, hogy mikor nem jó (kedvezőtlen) nekünk egy szám, akkor beépíthetjük ezt is. Megszámoljuk azokat a háromjegyű számokat, amelyeknél egy vagy két számjegy azonos, majd ez kivonjuk a háromjegyű számok darabszámából.

7. megoldás

A 7. megoldás már mindent folyamokkal old meg, azok képességeire építve. Az összes háromjegyű számot előállítja, majd rajtuk kiválogatás programozási tételt (szűrőt) használ (az 5. megoldás segédfüggvényére építve), végül a folyamban maradó számokat megszámolja. Ez a megoldás már olyan haladóknak való, akik magabiztosan építik össze a Stream API műveleteit és a lambda kifejezéseket. Mindent egyben. Persze hol itt a hatékonyság? Hozzászólásokban megbeszélhetjük.

8. megoldás

A 8. megoldás szintén folyam adatszerkezettel működik, de négy egymást követő lépésben végez szűrést (kiválogatást). A 900 db háromjegyű számból indulunk ki. Az 1. szűrő kihagyja a 9 db AAA számot, amelyek számjegyei azonosak és így marad utána 891 db szám. A 2. szűrő után marad 810 db szám, mert kimarad az a 81 db AAB alakú szám (ahol a százas és tízes helyiértéken lévő számjegyek megegyeznek) az összesen 90 db-ból, ami még a folyamban maradt az 1. szűrő után. A 3. szűrő kihagy 81 db ABB alakú számot és meghagy 729 db számot. A 4. szűrő kihagy 80 db ABA alakú számot és meghagy 648 db ABC alakú számot.

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

Ajánljuk matematika érettségi feladat címkénket, mert a témában évről-évre blogolunk.

A feladat a Java SE szoftverfejlesztő tanfolyam szakmai moduljának 5-8. óra: Vezérlési szerkezetek, 13-16. óra: Tömbök, valamint 21-24. óra: Objektumorientált programozás, 2. és 3. rész alkalmaihoz kötődik.

 

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.

Címkefelhő generálása

szófelhő logó

szófelhő logóA címkefelhők/szófelhők népszerűek, sok weboldalon megtalálhatóak. A CMS rendszerekben beépített szolgáltatás is lehet, vagy külön bővítmény/plugin is megvalósíthatja. Egy szövegben előforduló szavakból a gyakrabban előfordulókat nagyobb betűmérettel emeli ki. Eredménye lehet listás, táblázatos, esetleg képpé generált is. Kétféleképpen is megközelíthető, erre utal a Word Cloud és a Tag Cloud elnevezés. Utóbbi inkább egy blog taxonomiájához kapcsolódik és kategóriákra/címkékre érvényesül. A szakmai blogunkhoz is tartozik egy táblázatos címkefelhő. A szófelhő a szöveg betűméretén túl megjelenítheti a szavak előfordulását, például Java forráskód (63), címkefelhő (2).

Példánkban tetszőleges szöveget dolgozunk fel. Ebből felépítünk egy előfordulást is mutató listás szófelhőt, amely rendezett, és a szavak betűmérete 32-16-ig változik. Azok a szavak kerülnek a szófelhőbe, amelyek legalább 5-ször előfordulnak. Kezelünk kivételeket is, például olyan szavakat, amiket nem érdemes szófelhőbe tenni. Lépésenként haladva ismertetjük a megvalósító forráskódot, és külön megjeleníthetők az egyes lépések részeredményei.

A Java programozási nyelv csomagjait, osztályait, interfészeit, metódusait, műveleteit használjuk. Különböző adatszerkezetek kerülnek elő: tömb, generikus lista, generikus map, generikus folyam. Építünk a Stream API szolgáltatásaira és a lambda kifejezésekre. A megvalósítás könnyen testre szabható, kezeli a tipikusan előforduló igényeket.

1. Szövegforrás előkészítése

Generálunk egy 10 bekezdésből álló szöveget a Lorem Ipsum – All the facts – Lipsum generator weboldalon és a későbbi feldolgozáshoz mentjük a Java projekt files mappájába  lorem.txt néven. A fájl mérete: 5781 bájt. Szövegfájl:

2. Szöveges tartalom előkészítése

A megadott útvonalról a java.nio csomag metódusaival betöltjük a szövegfájl tartalmát byte[]-be, majd az s szövegbe. A replace() metódus hívásaival eltávolítjuk a szövegből a sor és bekezdés végét jelző soremelés ( LF="\n") és kocsi vissza ( CR="\r") vezérlőkaraktereket, a vessző és a pont írásjeleket (mindet külön-külön cseréljük a semmire), végül kisbetűssé alakítjuk ( toLowerCase()) a szöveget. A szöveg 5563 db karakterből áll. Előkészített szöveg:

3. Szólista elkészítése

A szóközök mentén darabolva ( split()) a szöveget elkészül belőle egy névtelen szövegtömb ( String[]), amit rögtön átalakítunk ( Arrays.asList()) szöveg típusú generikus listává ( List<String>). A lista 826 db elemből áll. Generikus lista:

4. Csoportosítás és megszámolás

A szólistát csoportosítjuk és megszámoljuk, hogy az egyes szavak hányszor fordulnak elő (másképpen: egy-egy csoport hány elemű). Elkészül a wordCountMap generikus map, amely kulcs-érték párok halmaza (leképezés). A kulcs a szó ( String), az érték a darabszáma ( Long). Alkalmazkodunk ahhoz, hogy a csoportosítás során használt counting() megszámoló művelet Long típusú értéket ad vissza. 188 db kulcs-érték párt kapunk. Generikus map:

5. Szűrés és rendezés

A generikus map-et kétszer szűrjük ( filter() művelet) úgy, hogy a kivételeket tartalmazó exceptList-ben ne szerepeljen a szó, valamint csak a legalább 5-ször előforduló szavakat hagyjuk meg. 71 db elemből álló folyam marad. Ebből a maradékból készítünk rendezett generikus folyamot ( sortedWordCountStream). A sorted() művelet két kulcs-érték párt hasonlít össze. A rendezés érték/darabszám szerint ( getValue()) csökkenő, azon belül kulcs/szavak szerint ( getKey()) növekvő sorrendet biztosít. Másképpen: ha az értékek megegyeznek, akkor a növekvő sorrendet a szavak ábécé sorrendje határozza meg, egyébként a darabszámok csökkenő sorrendje dönti el. Most már könnyen látható, hogy a leggyakrabban előforduló kevés szóból 15 van, 14 előfordulás nincs… Rendezett generikus folyam:

6. Saját típusú listává konvertálás

Definiálunk egy WordCount POJO-t, String típusú word nevű, Long típusú count nevű, int típusú fontSize nevű tulajdonságokkal, getter/setter metódusokkal, és toString() függvénnyel.

A map() intermediate művelettel a rendezett generikus folyamot bejárva, előállítjuk a POJO/ WordCount  típusú kimeneti objektumok rendezett generikus listáját. Továbbra is 71 elemmel dolgozunk. Rendezett generikus lista:

7. Darabszámok összegyűjtése

A POJO típusú rendezett generikus listában lévő objektumoktól elkért darabszámok ( getCount() POJO függvény) közül a különbözőeket ( distinct() művelet) összegyűjtjük egy Long típusú generikus listába ( distinctCountList). Az egyediesítő művelet nincs hatással az adatok sorrendjére. Tízféle előfordulást kapunk. Generikus lista:

8. Betűméret lépésköze

A szófelhőben a szavak gyakorisága alapján határozzuk meg a betűméretet. A betűméret 32-ről indul és fokozatosan csökken 16-ig. A betűméret léptetéséhez a tízféle gyakoriság/előfordulás meghatározza a stepFontSize  lépésközt. Lépésköz:

9. Betűméret kiszámítása

Csoportváltást alkalmazunk és a csoportot gi-vel indexeljük. Egy csoportba azok a POJO objektumok tartoznak, amelyeknél a szavak előfordulása megegyezik. Az algoritmus 2. lépésében az aktuális csoportra érvényesen kiszámítjuk a betűméretet ( fontSize), ami az algoritmus 3. lépésében a csoportba tartozó minden POJO objektumnál beállításra kerül a setFontSize() POJO eljárással. Az algoritmus 4. lépésében léptetjük a csoport gi indexét. A POJO-k esetén először csak a word és count tulajdonságok kerültek beállításra, de most már a fontSize tulajdonság is értéket kapott. Generikus lista:

10. HTML tartalom előállítása

A generikus lista POJO objektumain végighaladva, a forEach() záró művelettel összeállítható a weboldal szófelhőt tartalmazó része ( sbHTML). A 71 db szóból álló szófelhő HTML forráskódjának mérete 3409 bájt. HTML forráskód:

Eredmény

Szöveges formában:

lorem ipsum szófelhő

Képként (a 3. lépés részeredményéből a WordClouds.com weboldalon generálva):

lorem ipsum szófelhő eredmény

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 több alkalmához is kötődik. A Stream API-val és a lambda kifejezésekkel sokszor foglalkozunk.

Hóesés szimuláció

Hóesés szimulációt tervezünk és valósítunk meg Java nyelven. A téma igazi örökzöld. Elvileg minden télen aktuális. 😉 A grafikus felülethez és az eseménykezeléshez a swing gyűjteményt használjuk. Adott egy téglalap alakú terület amelyen – méretéhez igazodva – több száz hópehely mocorog. A területet önállóan programoztuk le – azaz ez alkotja a teljes GUI-t –, de lehetne egy nagyobb kép része is. Többféleképpen is beépítünk véletlenszerűséget a szimulációba. Tervezünk is, hiszen az sosem árt. 😉

Többnyire beépített komponenseket, elemeket használunk, de van saját, örökítéssel testre szabott komponensünk is:

  • A szimuláció a Window osztályból példányosított felületen működik, amely JFrame utód. Nem átméretezhető és látható.
  • A területet JPanel típusú pnTransparentWindow alkotja. Mérete 300*200 pixel. Színe a szürke egyik árnyalata. Ezen mozognak a hópelyhek.
  • A hópehely Snowflake típusú JPanel utód. Mérete 2*2 pixel. Színe fehér. Saját swing-es Timer biztosítja az eseménykezelését. A szimulációban 600 hópehely szerepel.

Az elkészült szimuláció

A teljes forráskódból íme a hópehely megvalósítása

A hópehelynek „tudnia kell” hol van, azaz mekkora területen mozoghat, ez a rectangle. A hópehelynek van size mérete. A hópehely saját magát mozgatja a területen a timer segítségével. Az időzítés várakoztatására/késleltetésére vonatkozó delay értéke véletlenszerűen 50, 100, , 250 milliszekundum lehet. Másképpen: a szél által össze-vissza fújt hópelyhek között lehetnek lassabban és gyorsabban mozgók is. Az eseményobjektumhoz lambda kifejezés rendeli hozzá a reakciót jelentő, mozgást megvalósító move() metódus meghívását, amely így adott időközönként bekövetkezik.

A hópelyhet a konstruktora hozza létre. Átveszi azt a pnTransparentWindow területet, amelyre később rákerül a Window példányosítása során. A gyengébb setSize() metódus helyett az erősebb setPreferredSize() metódus állítja be a méretet. Véletlenszerű x és y pozícióba kerül ki/fel a területre. A setBounds() örökölt metódus beállítja a pozícióját és méretét. Erre épít a fogadó oldalon az abszolút helyzet, külön elrendezésmenedzser nélkül. Végül a hópehely átlátszó, fehér és elindítja saját időzítőjét a timer.start() metódushívással.

Az időzítés/várakoztatás véletlenszerűsége után íme a második véletlenszerűség a szimulációban. A hópehely mozgása során a szél által össze-vissza fújva eltérő eséllyel/valószínűséggel mozog 8 lehetséges irányba az alábbiak szerint:

  • 5-5% eséllyel felfelé, azon belül jobbra vagy balra (átlósan),
  • 10-10% eséllyel jobbra vagy balra,
  • 20-20% eséllyel lefelé, azon belül jobbra vagy balra (átlósan),
  • 30% eséllyel lefelé, függőlegesen,
  • felfelé, függőlegesen nem mozog.

Az esélyek összege 100%. Másképpen kulcsszavakban: 1 = biztos esemény (teljes eseménytér, nincs más lehetőség), egymást kizáró események, geometriai valószínűség. A képen középen lévő hópehely a 8 szomszédja közül a 7 szóba jöhető közül valamelyikre adott eséllyel mozog. A geometriai valószínűséget az ábra alapján az óramutató járásával megegyezően leképeztük az 1..100 intervallumra:

A move() metódus megvalósítja a fenti tervnek megfelelően a hópehely mozgatását. Első lépésben tudni kell a jelenlegi/kiinduló location helyét (a bal felső csúcs, elkérjük). Ezután véletlenszerű esély/ tip generálódik. Az első elágazásban a hópehely translate() metódusával eltoljuk az előbb elkért pontot. Az eltolás relatív. Az utolsó elágazásban kompenzálunk, ha a hópehely alul kilépne a területről. Ekkor felül újra belép a területre. Végül beállítjuk a hópelyhet megvalósító komponenst a manipulált location helyre.

Takarékosak vagyunk: ezzel a megoldással „újrahasznosítjuk” a hópelyheket. Csak annyi van belőlük, amennyi szükséges. Nem kell őket folyamatosan megszüntetni és újra létrehozni. Nem mozognak feleslegesen. Nem mozognak olyan területen, ahol nem láthatóak.

Ötletek továbbfejlesztésre

  • A hópelyhek színe lehetne véletlenszerű a fehér és a középszürke között. Ezzel a nézőtől való távolságot, esetleg a kép élességét lehetne modellezni.
  • A szél nem feltétlenül szimmetrikus, vagy a hópelyhek mozgatását meg lehetne oldani jobbra és balra eltérő eséllyel is.
  • A terület lehetne más alakú, például trapéz, íves, kör, ellipszis.
  • Másképpen is vezérelhetnénk a szimulációt. Ahelyett, hogy most minden hópehelynek van saját időzítője, lehetne csak 5 db (lassabbak és gyorsabbak), amelyek közül véletlenszerűen kiválaszthatnánk, hogy melyik hatására mozgatjuk az adott hópelyhet. Fordítva is mehetne: az 5 db időzítőhöz előre hozzárendelhetnénk a hópelyheket. Ez így más-más felelősség, kommunikáció, üzenetküldés, vezérlés lenne az objektumok között. Hasznos tapasztalat lehet megvalósítani bármelyiket.
  • A terület lehetne egy nagyobb kép része. Például meghatározhatnánk egy tetszőleges átlátszóságot (színt vagy arányt) és többrétegű felületet megvalósítani képes JLayeredPane komponens elé vagy mögé is elhelyezhető lehetne a terület a grafikus felületen.
  • Aki kihívást keres: illessze a területet az alábbi hangulatos képre úgy, hogy a középső ablakok téglalap alakúak, a két szélső trapéz alakú vagy perspektivikus nézetű és a kör/ellipszis alakú tükörben pedig tükröződik valahonnan a hóesés látványa.
  • Még bátrabbaknak: a kandallóban lévő tüzet is lehet hasonlóan szimulálni. Itt már többféle fizikai paraméter is figyelembe vehető, például fényerősség, tükröződés. Egy 3D modellezett térben a sugárkövetés (Ray Tracing) algoritmus is megvalósítható. A hópelyheknél lehetne az egyszerű mozgástól eltérő más fizikát is programozni: rugalmas ütközéssel összetapadhatnának vagy rugalmatlan ütközéssel lepattanhatnának egymásról és mindez hathatna a sebességükre 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 szimulációs programot tervezni, kódolni, tesztelni.