Naprendszer szimuláció – objektumorientált tervezés

Naprendszer szimulációt terveztünk és valósítottunk meg Java nyelven, amit három részből álló blog bejegyzés sorozatban mutatunk be (ez a 2. rész):

A Naprendszer szimuláció objektumorientált tervezése

A Naprendszer égitestjeinek ábrázolása a valódi világban előforduló méretük és távolságuk szerint történik azért, hogy a szimuláció stabil legyen. A példában a Nap és a három belső bolygó szerepel, valamint a Hold. Utóbbi igazolja, hogy nem csak Nap középpontú égitestekre működőképes a modell. A szimuláció diszkrét lépések véges sorozataként valósul meg, az egyes lépések között az égitestek a virtuális térben egyenes vonalú egyenletes mozgást végeznek. Olyan lépésközt kell választani, amely rövid idő alatt kellően nagy változást képes bemutatni, ilyen például az 1 számítási ciklus / 1 nap érték. 10 képkocka / másodperces megjelenítést feltételezve – melyet egy időzítő biztosít – egy virtuális év kb. 37 másodperc alatt telik el, vagyis a Föld ennyi idő alatt tesz meg egy teljes fordulatot a Nap körül. Az égitestek kezdő pozíciója fiktív, nem függ konkrét dátumtól, együttállástól, méretük a jobb láthatóság érdekében torzított.

A program indításakor a szimuláció automatikusan indul, és nincs lehetőség a leállításra. Az alkalmazás felületének tetején foglalnak helyet a kezelő nyomógombok, a többi részt a megjelenítés/transzformált modelltér tölti ki. Futás közben – egyszerű ese­mény­ke­zelést megvalósítva – lehet változtatni a méretarányt és a nézőpontot, így az ekliptika síkját felülről és elbillentve is ábrázolhatjuk.

Kivételkezelés nem szükséges a programhoz, mert ez egy önálló demonstrációs eszköz, nem épül rá több elem, nem érhetőek el a szolgáltatásai külső programok számára.

Meghatározott cél és a szempontok: a Java projektben a csomagokat az MVC szerint hozzuk létre, a funkciókat logikusan osszuk szét, csoportosítsuk, tartsuk be az objektumorientált szemléletmód elveit, használjunk interfészt, biztosítsuk az egység­bezárást, legyen öröklődés, alkalmazzuk a polimorfizmust, legyen szép és elegáns megoldás, legyen a jelölésrendszer UML osztálydiagram. Mindez grafikus asztali Java alkalmazásként valósuljon meg.

A modell csomag (M – Model)

A modellhez 1 interfész és 5 osztály tartozik:


Az AdatInterfesz tárolja a modell számításhoz és megjelenítéshez tartozó konstansait (ezek a szimuláció paraméterei), és metódusfejet nem tartalmaz. A Pont2D osztály egy kétdimenziós pont sémája, valós x és y koordinátapárral, eltol() és túlterhelt tavolsag() metódusokkal. Ennek leszármazottja a Pont3D osztály, amely mindezt három dimenzióban biztosítja, valamint pozícióként és sebességvektorként is használható. Az Egitest osztályból létrehozott objektumnak van mérete, pozíciója, sebessége, színe és tömege. Az interfészt implementálja az Adattar osztály, amelynek egitestLista nevű generikus listája elérhetővé és egységesen kezel­hetővé teszi a tervben felsorolt 5 égitestet. A ZIndex osztályú objektumok az égitestek kirajzolásakor szükséges mélységpufferbeli adatot képesek kezelni.

A nézet csomag (V – View)

A nézet 2 osztályból áll:


Az Ablak osztály egy javax.swing.JFrame le­szár­mazott, az alkalmazás teljes grafikus felületét biztosítja, valamint előkészíti az eseménykezelést. Tartalompanelje négy vezérlő nyomógombot tartalmaz és rajta található a rajzpanel objektum, a vaszon. A RajzPanel osztály egy javax.swing.JPanel leszármazott, amely kapcsolatban áll az adattárral, és kezeli a mélységpuffert. Ez felel a szimulált 3D térben lévő objektumok 2D-beli leképezéséért, figyelembe véve a nézőpont elmozdulását is. A rajzolást a felüldefiniált (öröklődés) paintComponent() metódus végzi el.

Az Ablak osztályú objektum elsődleges szerepet tölt be a megjelenítésben, keretbe foglalva a látható komponenseket, vagyis a kezelő nyomógombokat és a modellteret. Az objektum megvalósít egy ActionListener eseménykezelőt, így a program reagálni tud a felhasználó által kiváltott eseményekre. Az ablakobjektum nagyítás és forgatás üzenetek küldésével saját vásznát – és csak azt – frissíti.

A vezérlő csomag (C – Controller)

A vezérlőt 2 osztály valósítja meg:

A Main osztály összefogja a projektet, ez a végrehajtás belépési pontja. Szükség szerint átadja az MVC szerinti objektumok referenciáit egymásnak, ezzel biztosítva a kommunikációt közöttük, valamint el is indítja a szimulációt. A Logika osztály képes az égitestek gyorsulásának és vonzásának kiszámítására, az égitestek mozgatására, továbbá a megjelenítésért felelős komponenst megfelelő időközönként értesíti a képernyő frissítésének szükségességéről, ami az alapbeállítás szerint 30 frissítés másod­percenként.

Naprendszer szimuláció – elméleti háttér

Naprendszer szimulációt terveztünk és valósítottunk meg Java nyelven, amit három részből álló blog bejegyzés sorozatban mutatunk be (ez az 1. rész):

A Naprendszer szimuláció elméleti háttere

A Naprendszer szimulációhoz elengedhetetlen, hogy ismerjük a homogén koordinátákat, az elemi műveletek egységes megvalósításához szükséges transzformációs mátrixokat, a tömegvonzás elvét és az implementációhoz szükséges MVC modellt.

Homogén koordináták

Számítógépes algoritmusokkal egyszerű a térbeli transzformáció megvalósítása, ha homogén koordinátákat használunk. Segítségükkel az affin transzformációk egységesen kezelhetők. A cél egy egységes matematikai formalizmus alkalmazása. A pontok az égitestek középpontjait fogják jelölni. Legyen a P pont 3D-beli koordinátái: P=(x, y, z). Szükséges egy konstans érték. Ha w≠0, akkor a P pont koordinátái: P=(w·x, w·y, w·z, w). Ha w=1, akkor a P pont normalizált homogén koordinátái: P=(x, y, z, 1). A pontnégyes kijelölése kölcsönösen egyértelmű.

Transzformációk

Koordináta transzformáció során az ábrázolandó grafikus objektum pontjaihoz (tárgypontokhoz) új koordináta-rendszert rendelünk hozzá. Az objektum nem változik (nem torzul, nem változtatja meg az alakját), csupán a nézőpont változik meg. Például: a koordináta-rendszer eltolása, elforgatása, a koordinátatengelyek felcserélése, tükrözése, és a léptékváltás (nagyítás, kicsinyítés, összenyomás, széthúzás), elforgatjuk az ekliptika síkját a szimulált Naprendszerben.

Pont transzformáció esetén a tárgypontokhoz hozzárendeljük azok egy adott szempont szerinti hasonmását. Például: 3D-s tárgyak leképezése 2D-s képre, objektumok eltolása, forgatása, mozgatása, égitestek mozgatása tömegvonzás alapján. Affin transzformációk (egybevágósági és hasonlósági transzformációk) alkalmazása esetén pont képe pont, szakasz képe szakasz, felület képe felület, valamint metsző térelemek eredeti metszésvonala megegyezik azok leképezett metszésvonalával.

A számítógépes grafika területén az affin transzformációk általános alakja (mátrixosan):

A pont a B=(bx, by, bz) vektorral eltolható. A pont – a T=(t11, t12, …, t33) mátrixot használva – adott szöggel elforgatható, skálázható, tükrözhető. A számítógépes grafikában ezt a transzformációs mátrixot a homogén koordinátákkal alkalmazva, az összes geometriai transzformáció hatékonyan megvalósítható, visszavezethető mátrixok szorzására. Mindezt saját magunk is implementálhatjuk, de része a DirectX és OpenGL rendering pipeline-jának is.

Más módon is lehetne: egyenes és ehhez tartozó szög párossal is dolgozhatnánk.

A tömegvonzás elve

A tömegvonzás bármely két égitest között meghatározott, függ a gravitációs állandótól és az égitestek tömegétől egyenes arányban, az égitestek (tömeg)középpontjainak távolságától fordított arányban. Ez a Newton szerinti értelmezés, amelynek képlete:

A hatás-ellenhatás törvénye miatt a vonzás – egymás felé való gyorsulás – kölcsönös, a gyorsulás az égitestek tömegével fordítottan arányos, sosem nulla. A Naprendszerben a bolygók a Nap körül keringenek, és a bolygóknak lehetnek holdjaik. Egységesen kezelve: égitestek.

A tömegvonzásnak más elméleti megközelítései is vannak: Einstein gödör-modellje, Kepler törvényei, illetve differenciál-egyenletrendszer, integrálszámítás is használható a közelítő képlet helyett (csak ideális modell esetén pontszerű az égitest és gömbszimmetrikus azok tömegeloszlása), illetve ismeretes többféle értelmezés a rendszer/modell stabilitására: Lagrange pontok, Lyapunov stabilitás.

Az MVC modell

A klasszikus megközelítés szerint a szoftveres alkalmazások három, egymástól jól elkülöníthető szereppel rendelkező egységből állnak: modell (model), nézet (view), vezérlő (controller). A Java nyelv Swing komponensei az MVC architektúra szerint működnek.

A vezérlő reagál az érkező eseményre, hozzáfér a modell adatszerkezeteihez, azaz igénybe veszi a modell szolgáltatásait, valamint frissítheti a nézetet. A nézet a vezérlő frissítési kérésére a közvetlenül megkapott adatok alapján, vagy a modelltől elkért adatok alapján frissíti saját magát. A vezérlő határozza meg az alkalmazás, komponens, program működését. Egy modellt több nézet is használhat. A modell közvetlenül is üzenheti a nézetnek, hogy megváltozott. A nézet adja a látványt, amelyet angolul skin vagy „look and feel”-nek neveznek.

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

2019. 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.

Beszámoló a Nikola Tesla – Mind from the Future kiállításról

Tesla-logo

Tesla-logoA kiállítást a nyár végével, 2019 augusztusának utolsó hetében néztem meg. Budapesten, a Kazinczy utca 21. szám alatt, az Elektrotechnikai Múzeum épületében található Tesla Loft adott helyet a rendezvénynek. Multimédiás kiállításról lévén szó, már a megérkezés pillanatában kijelzőkkel találkoztam, ahol lehetőségem nyílt közös képet készíteni a híres feltalálóval, Nikola Teslával – természetesen a fejlett informatikai technológia segítségével.

Tesla kiállításon készült kép

Minden látogató kapott egy tabletet, amelyről két órányi hanganyagot lehetett meghallgatni az egyes állomásokhoz érkezve. A hangos bemutató nagyobb részben narráció stílusú volt, de egy-egy állomáshoz érve a tudós gondolatait is meghallgathattam egyes szám első személyben. Néha-néha a hanganyagot filmes bemutató követte.

Már az első pillanatban meglepődtem a kiállítás látványvilágán. Úgy gondoltam, hogy elsősorban technikai eszközökkel fogok találkozni, ezzel szemben sokkal inkább művészi, egy kicsit mesebeli megjelenés fogadott. Természetesen nem maradtak el az egyes találmányok rekonstrukciói sem.

A bemutató Tesla életkora szerint haladt, kezdve a falutól, ahol született, gyermekkorától, iskolás éveitől végig kísérve életét. A hanganyagot hallgatva rá kellett jönnöm, hogy a készítők igen alapos kutató munkát végeztek, mert még a három éves kisgyerek Tesláról is sikerült megtudnom, hogy már akkor is különösen vonzódott a természethez, a természetben lezajló változások megfigyeléséhez. Ebben társa volt Macsak, a kedvenc macskája. Ez az érdeklődés iskolás korában csak továbbfokozódott, így alapozva meg későbbi találmányait.

Ahogyan haladtam előre a kiállítás helységein, különböző élethelyzeteket és találmányokat ismerhettem meg. Kissé szomorú volt hallani, hogy az Egyesült Államok, a lehetőségek országa bár valóban hasznos táptalaja volt Teslának, mégis sok olyan ember vette körül, akik csak a kihasználható embert és a saját bevételük növelésének eszközét látták benne. Minden egyes elért eredményért keményen meg kellett küzdenie. Mégis, sokféle területen tudott újat alkotni, a teljesség igénye nélkül: elektromosság, elektromágnesesség, távközlés, motorok és generátorok, valamint mozgófilm vetítő gépek.

Azt mondhatom, hogy igen átfogó, részletgazdag, tematikáját tekintve inkább életút jellegű, művészi megjelenésű élménnyel lettem gazdagabb.

Az utazó kiállítás Budapesten 2019. május 31-től szeptember 1-ig volt megtekinthető. Olyan városokba látogat el, amelyekben Nikola Tesla munkásságával mély nyomot hagyott.

HWSW – Szeptemberi dupla – Android/Kotlin és full-stack JavaScript fejlesztői meetup

HWSW logó

HWSW logó2018. szeptember 11-én és 12-én délután a HWSW szervezésében a Szeptemberi dupla: Android/Kotlin és full-stack JavaScript fejlesztői meetup-okon vettem részt az AnKERT-ben.

Szeptemberi dupla - Android/Kotlin és full-stack JavaScript fejlesztői meetup

Kedd – Android/Kotlin fejlesztői meetup

Kedden az első előadó Ekler Péter volt, Android Pie újdonságai fejlesztői szemszögből című előadásával. Az általános újdonságokat követte néhány példa az energiafogyasztáshoz és testreszabáshoz kötődően: az Android rendszer:

  • úgy működjön, ahogyan a felhasználók jobban szeretnék használni – és persze ezáltal a Google még jobban megismerjen bennünket ;-),
  • alkalmazkodik a rendszer a mi életstílusunkhoz,
  • adaptívan korlátozni tudja a ritkán használt appoknál az akkumulátor-használatot (digitális jólét néven eladva),
  • adaptívan képes a fényerő beállítására (szürkeárnyalatos esti megjelenítés),
  • támogat új notification-öket (ez örökösen átalakul).

Elhangzó körkérdések voltak:

  • Mennyi ideig használunk egy-egy mobil alkalmazást?
  • Hány darab mobil alkalmazást használ a felhasználók többsége?
  • Ki találja hasznosnak a digitális jólét szolgáltatásokat?
  • Vajon mennyi változott (hány százalékot) az API 25-26-ra, 26-27-re, illetve 27-28-ra?

A válaszok érdekesnek, néha meglepőnek hatottak. Hasznos ötleteket kaptunk appok fejlesztéséhez, alkalmazkodva a felhasználói szokásokhoz.

A második előadás címe Kotlin 1.3 újdonságok volt, Balogh Tamás tartotta. Hasznos tippeket kaptunk a Kotlin konfigurációhoz, illetve függőségeinek megoldásához többféle fejlesztői eszközt érintve a gyakorló fejlesztő tapasztalataira építve. Újdonságok:

  • coroutine-ok experimental megjegyzéssel (működik, stabil, de egy későbbi új API verzióban fenntartott a jog, hogy megváltozhatnak és így törődni kell még velük),
  • előjel nélküli adattípusok példákkal (nem mintha ez lenne a legfontosabb, de néha kifejezetten hasznos lehet),
  • inline class-ok, intelligens bájtkód-beillesztésként magyarázható analógiával, mintegy kibővítve a korábbi inline function-ök lehetőségeit (nagyon tanulságos és eltalált volt a példaként bemutatott forráskód),
  • contract-ok (szerződés a fejlesztő és a fordító között).

A harmadik előadó Polacsek Attila volt és A pontonhíd az RxJava és a Data Binding között című bemutatójában körüljárta a reaktív UI-ban rendelkezésre álló adatkötés lehetőségeit, korlátjait, mindezt sok apró részletet is tartalmazó forráskód-részletekkel ismertetve.

Szeptemberi dupla - Android/Kotlin és full-stack JavaScript fejlesztői meetup

Szerda – Full stack JavaScript fejlesztői meetup

Szerdán négy előadást hallgattam meg a JavaScript nyelvhez kapcsolódóan. Az első előadó Szabolcsi-Tóth Szabolcs volt, aki a nyelv eredetét, fejlődését ismertette. A JavaScript nyelv az Európai Számítógépgyártók Szövetsége (ECMA) által felügyelt, ECMA-262 számon és ECMA Script néven gondozott szabvány (https://www.ecma-international.org/publications-and-standards/standards/ecma-262/) egyik implementációja. Elsősorban webes alkalmazások számára készült. Az ECMA évente jelentet meg új változatot a szabványból. A nyelv fejlesztése teljesen nyitott, bárki küldhet be ajánlást egy-egy új funkció beépítésére. A koordináció github-on (https://tc39.es/ecma262/) keresztül zajlik. Az ECMA-262 tagok döntésén múlik, hogy az egyes ajánlások közül mi kerül be ténylegesen a nyelvbe – szigorúan szabályozott lépések sorozatát követően.

A második előadó Czibik Péter volt, aki 4 év full stack fejlesztői tapasztalatait osztotta meg velünk. Elmondta, hogy mi a különbség egy specialista és a full stack fejlesztő között, milyen előnyökkel illetve hátrányokkal járnak az egyes szerepek. Megerősített minket abban a hitünkben, hogy bár mindenhez nem lehet egyszerre érteni, ennek ellenére lehetséges olyan szerteágazó tudásra szert tenni (itt az adatbázis-backend-frontend hármasra gondolok) ami hatékonyan használható a munkában. Tapasztalata szerint náluk a RisingStack nevű cégnél először specialistákat képeznek, és onnan indulhatnak el a munkatársak a full stack irányba. Ismeretes náluk, hogy a full stack-es kollégák közül ki melyik szakterülethez ért a leginkább és ezen információ birtokában hatékonyabban tudnak együtt dolgozni az egyes projektek kivitelezése közben.

A harmadik előadóként Séra Bálint következett. Ő egy saját tapasztalatát mutatta be: hogyan lehet egy frontend-es számára optimális sorrendben betölteni a weboldalon az egyes JavaScript modulokat a lehető leggyorsabban úgy, hogy ne kelljen a felhasználónak egy üresnek látszó weboldal előtt várakoznia. Saját kódpéldákon keresztül mutatta be azt a folyamatot, ahogyan a JavaScript nyelv fejlődésével párhuzamosan bővültek a programozó lehetőségei. Először csak statikusan lehetett felsorolni a modulokat az oldal kódjában, ezzel rögtön egy sorrendiséget is meghatározva. Később erre a feladatra különböző keretrendszerek készültek. Az ES6-os JavaScript verziótól kezdve pedig szabványos eszköz áll a fejlesztő rendelkezésére, az import formájában.

Utolsó előadóként Miklós Bertalant hallgattuk meg. Ő is a nyelv fejlődésére épített, de sokkal inkább a felhasználó által tapasztalt élmény szemszögéből megközelítve a fejlesztő lehetőségeit. A JavaScript nyelv irányába is régebb óta megvolt az az igény, hogy gazdag animációs lehetőségeket tudjon biztosítani, mint a mára már elavult Flash vagy Silverlight technológiák. Ahogy ezek a lehetőségek elkezdtek megjelenni a nyelvben, úgy kezdtek megszületni a különböző keretrendszerek is, mint például a React, az Angular vagy a Single-page alkalmazások. Szerinte a mai weboldalak a progresszív megközelítést kell, hogy használják, ami egy-egy keretrendszerrel való megoldások készítése helyett inkább sok-sok kicsi ötletre épít, figyelembe véve az adott projekt szükségleteit, és ennek megfelelően alkalmazva néhány – a tarsolyban lapuló – eszköz keverékét.

Néhány előadás prezentációja letölthető.