Népesedési világnap

Népesedési világnap logó

Népesedési világnap logóAz ENSZ 1987-ben július 11-ét a népesedési világnappá (World Population Day) nyilvánította. Bolygónk lakossága aznap érte el az 5 milliárdot. További kerek számok voltak: 1999. október 12-én 6 milliárd, 2011. október 30-án 7 milliárd. További kerek számok várhatóak: 2023 – 8 milliárd, 2037 – 9 milliárd, 2057 – 10 milliárd. A KSH elemzése részletes elemzéseket közöl évről-évre a témában, például: 2019-ben, 2018-ban. A worldometer.info weboldalon folyamatosan frissülő kimutatások érhetők el a népességhez globálisan, valamint országonként is: például Magyarország aktuális népesedési adatai.

A népesedési világnap inspirált egy Java program megtervezésére és megírására. A swing GUI-s program megjeleníti a worldometer.info weboldalról kinyerhető adatok alapján régiónként (kontinensenként) az elérhető adatokat 1950-től 2020-ig az alábbiak szerint egy világtérképen.

Az elkészült program

Népesedési világnap Java program

Tervezés

Objektumorientált szemlélettel, MVC architekturális tervezési mintát követünk, angol nyelvű interfész, osztály, változó, objektum, metódus nevekkel. A projekt neve: WorldPopulation, a csomag neve: worldpopulation. Amit lehet, konstansként interfészbe (szeparálva) teszünk és az MVC rétegekhez kötődő osztályok implementálják. A modell minden évszámhoz tárolja a szükséges adatokat, mindezt egyetlen betöltéssel/letöltéssel éri el. A program kliensként hat régióra vonatkozó adatot gyűjt össze, alkalmazkodva a szerver adatforráshoz. A címsorban lévő összesített adat is elérhető közvetlenül a weboldalon, de a kisebb adatforgalom érdekében hasznos inkább a kliensben összesíteni. Mindössze egyetlen eseménykezelés szükséges: a csúszka beállításával megadott évszám alapján frissíteni kell a régiók címkéit és az ablak címsorát. Öröklődés hasznos a feladat megoldása során: egyrészt interfészek, másrészt osztályok között.

Interfészek

Az ősinterfész a WorldPopulationConstants, benne az évszám intervallum MIN_YEAR és MAX_YEAR határaival, valamint a megjeleníthető régiók neveivel tömbben: REGION_NAME_ARRAY. Két utódinterfész épül az ősre: ModelConstants és ViewConstants. Előbbi interfész az adatforráshoz kapcsolódik: URL_COMMON az URL eleje, URL_ARRAY az URL végei régiónként tömbben. Utóbbi interfész a megjelenítéshez kapcsolódik: WORLD_MAP_IMAGE a háttérkép annak WORLD_MAP_RECT méretével együtt, valamint a régiónkénti REGION_RECT_ARRAY téglalapok tömbje a kezdeti pozíciókkal/méretekkel, TITLE a sablon a program címsorához (frissítendő az évszámmal és az összesített népességgel). A megfelelő utódinterfészt mindig implementálja az MVC szerint hozzá illeszkedő osztály.

Osztályok

A belépési pont a WorldPopulation.java fájlban található.

Három összetartozó elemi adatot fog össze egybe a RegionData POJO, ezek name, year, population nevű rendre String, int, long típusú adatok. Például: Európa, 2020, 747643253. Tartalmaz két függvényt: getPopulation(), valamint toString(). Utóbbi HTML formátumban adja vissza a megjelenítendő adatokat.

A JLabel-ből származik az igényekhez alakított RegionLabel osztály. Ennek van előre megadott pozíciója, mérete, betűtípusa, betűmérete, sárga háttérszíne, piros kerete. Ezenkívül a téglalap átlátszó, valamint a benne megjelenő HTML tartalom vízszintesen középre igazított. Némi extra funkció, hogy egérrel megfogva – drag and drop – áthelyezhető, ami a MouseMotionListener egérmozgást figyelő interfész mouseDragged() metódusának felülírásával válik lehetővé. A mozgathatóságáért saját maga felel. Példaként közöljük az osztály teljes forráskódját:

A webről adatokat szerez és tárolja a Model osztály, a java.io és java.net csomagokra építve. Egy példa: a https://www.worldometers.info/world-population/europe-population/ oldal forrásából nyeri ki az osztály az alábbi adatokat:

Ezek parszolását követően elkészül egy optimálisnak tekinthető, generikus listákból álló regionListArray tömb adatszerkezet. A parszolás történhet egyszerű szövegkezeléssel vagy JSON feldolgozással is. Erre épülnek a konstruktorral és vezérlővel összehangoltan működő getter metódusok: getHTML(), getRegionList(), getRegionData(), getPopulation(). A JSON adatforrás feldolgozását most nem részletezzük, de hasonlóról blogoltunk már: Időjárás Budapesten.

A grafikus felhasználói felületet adja a JFrame utód View osztály. Három GUI komponensből áll: pnWorldMap – háttérkép JPanel, lbYear – kiválasztott/aktuális év JLabel, slYear – kiválasztható/görgethető aktuális év JSlider. Izgalmas megoldani egymásra/egymáson elhelyezni a komponenseket. Egy JLayeredPane komponens  DEFAULT_LAYER rétegére kerül a térképet tartalmazó háttérkép, majd a  PALETTE_LAYER rétegére kerül dinamikusan a hat  RegionLabel osztályú/típusú objektum. A csúszka komponens slYearStateChanged() eseménykezelő metódusa vezérlőként megszólítja a modell réteget és a visszakapott adatokkal frissíti a nézet réteget (a címsorban lévő összesítéssel együtt, ezres szeparátorokkal).

Ötlet továbbfejlesztésre

Hat különböző weboldal forráskódjából kell összegyűjteni a megjelenítendő adatokat. Ez 2020-ban régiónként 71 számot jelent és hat régió van. Érdemes lehet olyan adattárolást megvalósítani, amely csökkenti a szerverhez fordulások számát, illetve a letöltendő adatok mennyiségét. Hiszen a múltbeli évekhez kötődő historikus adatok nem változnak. Ha ezekre valamilyen formában a program emlékszik, akkor elegendő az utolsó tárolt évből kiindulva az aktuális évig évenként, régiónként lekérni mindössze 6, 12, 18… számot, a program utolsó futtatásának évéből kiindulva. Ez lényegesen kevesebb lenne, mint a jelenlegi 6*71 lekért szám. A koncepció kulcsszava: inkrementális adatfrissítés. Ha megvalósítjuk az ötletet, akkor figyelni kell arra, hogy az aktuális/utolsó évben az adatok akár másodpercenként is változhatnak.

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 (ha a swing GUI-ra koncentrálunk és az adatok helyi fájlrendszerből elérhetők), és a Java EE szoftverfejlesztő tanfolyam tematikájához kapcsolódik (ha az adatokat közvetlenül a webről olvassuk).

Kommunikáció a Mars és a Föld között

Mentőexpedíció

MentőexpedícióBevezető, avagy a szomszéd messze van

Képzeljünk el egy helyzetet, amikor egyik barátunkat, családtagunkat felhívjuk telefonon, és videótelefonálást folytatunk vele, mobiltelefon segítségével egy látványos helyről. A mai technológia segítségével ennek a lehetősége már bárki számára hozzáférhető áron rendelkezésre áll. Ráadásul a kommunikáció szinte tökéletes, láthatóan késleltetés nélküli. Ám tételezzük fel, ha ezt a kommunikációs tevékenységet a Föld két távolabbi pontja között végezzük, mondjuk Magyarországról folytatunk videótelefonálást a 18000 km-re fekvő Új-Zélandra. A helyzet minimális szinten megváltozik, hiszen a nagy távolság következtében a fizikai törvényei itt már emberi léptékben is érzékelhető korlátot szabnak a kommunikáció sebességének. Persze nyugodtan mondhatnánk azt, hogy na és? Joggal, hiszen az átlagember számára fel sem tűnik, hogy az általa halott beszéd, és az általa látott kép a valóságban kevesebb, mint egy másodperc késéssel érkezik meg a küldőtől a fogadóhoz.

Ha ezt elképzeltük, és megvan a 18000 km-nyi távolság és a közel 1 mp-es késleltetés, ugorjunk egy nagyobb léptékre, melynek apropójaként hívjuk fel barátainkat telefonon a Marson. Most csak egy egyszerű példa kedvéért, eltekintve a légköri jelenségektől, a műholdak aktuális helyzetén át, a napszél tevékenységig minden más további hatástól, a Mars-Föld távolság átlagos értékével számolva. Legyünk türelmesek, hiszen a bolygók közti aktuális távolság függvényében, a fénysebesség korlátainak figyelembevételével a késleltetés meglehetősen nagy lesz. Fel fogják venni a telefont. Ne, még ne tegyük le! Igen, tudom, hogy már eltelt tíz perc, de várjunk még! Biztosan fel fogják venni a telefont. És ez a 12. percben meg is történik. A vonal végéről nem hallunk semmit? Nem csoda. Hiszen a mi jelentkezésünk 12 perc alatt ért a Marsra, és újabb 12 percet kell várni arra, hogy meghalljuk barátaink reagálását. Ugye, hogy nem is olyan egyszerű ez a bolygóközi kommunikáció?

Egy kis matematika az előzőekhez:

A Föld-Nap átlagos távolság 8,3 fényperc, ami 149,6 millió km-es távolságot jelent. Ezt alapul véve, és mivel tudjuk, hogy a Föld-Mars átlagos távolság 225 millió km, könnyen kiszámolható, hogy a két bolygó között a fény fotonjai 12,48 perc alatt teszik meg az utat. Tehát jelen technológiákkal (a két bolygó átlagos távolsága esetében) 12,48 perc alatt lehet adatot továbbítani a két égitest között. Érdekesség, hogy 2003-ban a Mars mindössze 56,3 millió km-re volt a Földtől. Gyors számtan: a távolság 3,12 fényperc. (Legközelebb 2287-ben lesz ilyen alkalom.) Azonban 2005-ben a vörös és kék bolygó mértani távolsága elérte a 402,3 millió km távolságot, azaz a 22 fénypercet. További gondolatébresztőként megemlítendő, hogy minden évben van egy két hetes időablak, amikor a Mars a Nap mögé bújik, ezáltal a kommunikáció teljesen megszakad vörös szomszédunkkal. Ebből aztán kiderül, hogy adott dátumtól függően, a Mars és a Föld között általában 7 és 44 perc között zajlik le egy „kérdés+válasz” jellegű kommunikáció.

A Mentőexpedíció című film

A fenti bevezetőből kiindulva, vegyük górcső alá az Andy Weir 2011-es A marsi című regénye alapján készült 2015-ös Mentőexpedíció című filmet. Aki nem ismerné, annak röviden annyit érdemes tudnia, hogy egy kutatócsoport heves időjárási tevékenység miatt menekülni kényszerül a Marsról. A csapat egy ember híján sikeresen eljut a felszállásra kész űrhajóig, amellyel feljutnak a űrben keringő Hermes anyahajóra. Később a Marson hagyott űrhajósról kiderül, hogy a viharos erejű szelet túlélte, bár ő maga, és űrruhája is megsérült. A következő jelenetekben Mark Watney űrhajós számára realizálódik, hogy egyedül maradt a bolygón, a következő küldetés pedig négy év múlva érkezik. Tehát három fő feladata van:

  • Egy ember számára lakhatatlan bolygón, a rendelkezésre álló eszközökből biztosítania kell az életben maradásához szükséges feltételeket, mint amilyen az élelem, a víz, és az oxigén. Ez megoldhatónak tűnik, hiszen főhősünk botanikus. Növénytermesztéssel létrehozható egy alacsonyszintű ökológiai körforgás.
    Megjegyzés:
    Fontos megemlíteni, hogy a marsi talaj a nagy hőingadozások miatt rendkívül porózus, továbbá olyan anyagokat tartalmaz (például földpátok, piroxének, olivinek), amik a vízzel vegyülve az emberi szervezet számára méregként hatnak. Például a marsi por belélegzése során, a tüdőben található nedvességgel érintkezve gáz formájában, vagy a véráramba jutva halált kiváltó vegyületek jöhetnek létre. Ehhez képest Mark, ránézésre több száz kg-nyi marsi talajt a lakrészbe talicskáz, és vizzel öntöz. Az ehhez szükséges vizet, az egyik űreszközben található hidrogén elégetésével nyeri, a marsi talajt pedig emberi végtermékkel trágyázza, miközben a növények oxigént termelnek. Ez filmben jól néz ki, de fent már kifejtettem, hogy a marsi talaj az emberi szervezet számára veszélyes lehet. További kérdést vet fel, hogy az emberi végtermék vajon megfelelő tápanyagokat rejt-e, a burgonya növekedéséhez. Ezen kívül az is kérdés, hogy az a szobányi növény termel-e elegendő oxigént. Mindenesetre főszereplőnk ezen feladatát megoldotta.
    Természetes, hogy ha minden kihívást figyelembe vettek volna a filmkészítők, akkor vagy nem készül el a film, vagy megválaszolják a NASA, valamint más űr- és bolygókutató vállalatok kérdéseit.
  • Második feladataként meg kell oldania, hogy a marsjáró roverrel eljusson a 3200 km-es távolságban fekvő Schiaparelli-kráterhez, ahová négy évvel később érkezik a következő küldetés legénysége.
    Probléma:
    Ez számos problémát vet fel, főleg mert a marsjáró egy feltöltéssel elérhető hatótávolsága csak 35 km, ráadásul a járgány fűtése rögtön elviszi a rendelkezésre álló energia felét. Ezen hátrányok meglehetősen érdekesek annak tükrében, hogy a mai járművek akár 350 km-es távolságot is könnyűszerrel megtesznek, a marsjáró légmentes kialakítása és megfelelő szigetelő anyagok használata révén pedig a fűtésre fordított energia jelentősen csökkenthető. Főleg ha elképzeljük milyen fejlesztések zajlanak le a 2030-as évekig. Tény persze, hogy a laza marsi talajon, egy teherautó méretű, nyolckerekű járművel közlekedni több energiát igényel, mint egy kisebb négy kerekű járművel haladni az aszfaltozott úton, azonban arról se feledkezzünk el, hogy a Mars felszíni tömegvonzása harmada a Föld felszíni tömegvonzásának. Mindenesetre a filmbeli főhősünk a fűtés problematikáját a radioizotópos termoelektromos generátor segítségével oldotta meg, a marsjáró hatótávját pedig egy másik, amúgy megsérült marsjáró akkumulátorainak felhasználásával duplázta meg. Így a mozi szerint 70 km távolságra tud eljutni egyetlen feltöltéssel. Ekkor kipakolja a napelem cellákat, és újratölti az akkumulátorokat.
  • Továbbá fel kell vennie a kapcsolatot a Földdel. Ez utóbbinak nem lenne akadálya, azonban a vihar tönkretette a kommunikációs berendezéseket, valamint az antennát is. A filmtől elvonatkoztatva egy ilyen eset vélhetően nem történhetne meg, ugyanis a tartalék rendszer rendelkezésre állna (dobozokban földbe ásva, dobozokban bent a lakrészben, vagy bármi más módon, amit a szakemberek alkalmasnak találnak erre a célra). A kommunikáció a Földdel gyakorlatilag életfeltétel. Máskülönben az is igaz, hogy a tartalékrendszerek Marsra szállítása extra költségekkel járna.

A film tartalma, valamint a kialakult problémák ismertetése után merüljünk bele a részletekbe, valamint az érdekes, ismert és még ismeretlen fogalmakba!

A sol fogalma

A történet teljes egésze alatt többször elhangzik egy csillagászati fogalom, ez pedig a sol. A sol tulajdonképpen a szoláris nap rövidítése, azonban használata némi bonyodalmat okoz, hiszen a sol-t, mint mértékegységet a NASA 1976-ban az első Viking űrszonda landolásakor, a marsi napok múlásának mérésére vezette be házi használatra. Jelenleg a sol egy hivatalosan nem elfogadott időegység, azonban általánosan elfogadható, hogy 1 sol esetében 1 szoláris marsi nap hosszáról beszélhetünk.

Kiegészítés:

Noha logikus lenne olyan egyértelműsítő fogalmakat bevezetni, hogy 1 földi sol, vagy 1 marsi sol, ennek ellenére az egyébként sem hivatalos időegységet ne bonyolítsuk tovább! Összehasonlításképpen 1 földi szoláris nap ~24 óra 3,5 percnek, 1 (marsi) sol pedig ~24 óra 39,5 percnek felel meg. Ez azt jelenti, hogy a Marson egy általános értelemben vett nap hossza több, mint fél órával tovább tart. További gondolatébresztő érdekesség, hogy a Földön a szoláris nap ritkán használatos. A Földön a csillagnapot szoktuk használni, ez pedig közel azonos – 0,008 s az eltérés – a Föld tengely körüli megfordulásának idejével, ami ~23 óra 56 perc. A csillagnap során azt figyeljük meg, hogy – a Földről nézve – az égbolton a távoli csillagok, mennyi idő alatt tesznek meg egy teljes fordulatot. A Föld csillagokhoz mért óriási távolsága miatt a Föld Nap körüli pályán történő mozgása egy nap alatt szinte elhanyagolható tényező. A szoláris nap esetében viszont ezzel a tényezővel is számolni kell, hiszen a Föld-Nap távolság rendkívül kicsi. Mialatt a Föld megfordul a saját tengelye körül, a Nap körüli pályán egy másik pozícióba kerül, ez utóbbi pedig már jelentősen befolyásolja a szoláris nap hosszát.

Részecske szinten a Marsig tartó út hossza

A filmben többször is elhangzanak változó utazási adatok arról, hogy mennyi idő alatt lehetséges eljutni a Földről a Marsra, illetve vissza. A jelenlegi technológiákkal ez jellemzően 5 és 10 hónap között változhat, attól függően, hogy éppen milyen a bolygók egymáshoz viszonyított aktuális állása. Az sem mindegy, hogy mekkora energiabefektetéssel szeretnénk elérni a vörös bolygót. Erre a megfelelő indítási ablak 26 havonta alakul ki, ami azt jelenti, ekkor áll rendelkezésre néhány olyan nap, amikor hatékonyan el lehet érni a Marsot. 2018-ban az InSight űrszonda nagyjából 5,5 hónap alatt jutott el a szomszédos égitestre, a kilövéstől a leszállásig számolva.

Részletek:

Itt fontos megemlíteni a Hohmann-pályát, mint pályamódosító görbét. Ennek lényege nagyjából úgy néz ki, hogy a Marsra történő utazás során, a Föld körüli pályát a rakétahajtóművek megfelelő ideig történő begyújtásával elhagyjuk. Ezzel a kör alakú pályát egy elliptikus pályára cseréljük le. A gyorsításnak olyan mértékűnek kell lennie, hogy a Nap körüli marsi pályát elérjük. Amikor ez megtörténik, a rakétahajtóműveket ismét be kell gyújtani annak érdekében, hogy az ellipszis alakú pályáról rá álljunk a Mars keringési pályájára. És itt jön képbe a megfelelő indítási ablak, ugyanis a Földről akkor kell elindulni, amikor az ellipszis pálya csúcspontjára érkezve, a Mars még éppen nem érkezett meg. Fontos tudni, hogy a Mars majdnem kétszer annyi idő alatt kerüli meg a Napot, mint a Föld. Tehát a Mars a külső pályán lassabban halad. Ez azt jelenti, hogy ha kicsúszunk az indítási ablakból, akkor a Mars pályáját elérve, a vörös bolygó már mögöttünk lesz. Így gyakorlatilag hónapokig keringhetünk a Nap körül, miközben nem kevés energiát ölünk bele a lassításba, és számos pályakorrekcióba, hogy a Mars utolérjen minket. Korábbi indulás esetén pedig pont azért kell a több energia, hogy hamarabb elérjük a Marsot, majd a nagy sebesség miatt, a találkozóhoz le is kell lassítani.

Kapcsolatfelvétel a Földdel: a hardver környezet kialakítása

Miután főhősünk realizálta, hogy egyedül maradt a Mars felszínén, és a következő küldetés csak négy évvel később érkezik, elkezd azon töprengeni, hogyan biztosítsa maga számára az életben maradáshoz szükséges feltételeket. Ezeket a fentiekben már ismertettem. Már csak kapcsolatba kellene lépnie a Földdel. Ekkor születik meg Mark fejében az ötlet, hogy felkutassa a Pathfindert, mely a marsjáróval immáron elérhető távolságba került. A Pathfinder űrszonda megtalálása kommunikációs csatornát nyit a NASA felé. Csupán annyit kell tennie, hogy kiássa, és a vélhetően elhasználódott, tönkrement akkumulátor kazettát kicserélje. A Pathfinder űrszonda a Discovery program második küldetésében vett részt 1997-ben. Feladata a légkör elemzése volt, továbbá magával vitte a kis Sojourner rovert is, mely a kövek vizsgálatát végezte. Felmerül a kérdés, hogy a főhős honnan ért ilyen sok mindenhez, hiszen botanikus. Az igazság az, hogy egy Marsra juttatott embernek nagyon sok mindenhez kell értenie. Kicsiben például egy weblap készítő szakembernek nem árt ha a kódolás mellett vannak grafikai ismeretei is. Egy katonai repülőgép pilótájának sem csak a gépet kell tudnia vezetni, de ahhoz is kell értenie, hogyan éljen túl egy ellenséges területre történő lezuhanást. Lényeg, hogy ha az ember egy adott szakterületen dolgozik, akkor a rá váró kihívásokra gyorsan tudjon reagálni. Feltételezhető, hogy a Marsra utazó személyek egy nagyjából 15-25 éves korban lévő, nagy létszámú, de már erősen megszűrt halmazból kerülnek ki, akiknek a kiválasztásuk után még akár 15-20 évnyi tanuláson és fejlődésen kell átesniük, hogy alkalmassá váljanak egy marsi kutató misszióban betölthető szerepre. A NASA jelenleg már futtat ilyen programot.

Magyar vonatkozás a filmben:

A film 48. percének 18. másodpercében, a háttérben lévő polcon egy Rubik-kocka látható.

Kapcsolatfelvétel a Földdel: a megvalósítás

Szóval megvan a Pathfinder, és sikerül működésre bírni. Eközben a NASA a műholdak segítségével felfedezte, hogy az űrhajós életben van, és mozgását folyamatosan követte. Mivel ennek művelete prioritásba került, ezért a NASA a Mars körül keringő műholdak pályáját úgy módosította, hogy az eredeti 41 óránként lezajló 17 perces szünet helyett legfeljebb 4 percig tartson egy szünet. Miután a Földön kiderült, hogy Mark a Pathfinder segítségével szeretné felvenni a kapcsolatot a Földdel, a NASA egyből a JPL-t hívta segítségül. A JPL a Jet Propulsion Laboratory, amit Kármán Tódor alapított, és ő volt az első igazgatója is. Rakétafejlesztő központnak indult, ám napjainkban fő területe a bolygókutató eszközök fejlesztése, és üzemeltetése, így a feljuttatott űreszközök kapcsolati csatornájának végpontján is ők vannak. Az ő termékük többek között a Pathfinder is. A Pathfinder orbitális egység nélkül, közvetlenül kommunikál a Földdel. Ez látható is a filmben akkor, amikor Mark az irányított antennát a Föld felé fordítja. Időközben a Földön a JPL kihozza a raktárból a Pathfinder másolatát, majd a két eszközt szinkronizálja egymással. A marsi szonda üzembe helyezése lehetővé teszi Mark számára, hogy elküldje magáról az első fotót, maga elé tartva egy táblára írt kérdéssel:

„Veszitek az adást?”

A fentiekben már említettem, hogy a Föld-Mars távolság miatt az adatok továbbítása sok időt vesz igénybe, azonban nagyobb probléma, hogy a kamera segítségével Mark ugyan tud hosszú szöveges üzeneteket, kérdéseket fotózott formában továbbítani a Földre, azonban a Pathfinder nem képes arra, hogy a Földről érkezett válaszokat bármilyen formában is megjelenítse. Viszont a JPL képes arra, hogy távolról irányítsa az űrszonda kameráját. Ezt használja ki Mark azzal, hogy első üzenetében egy eldöntendő kérdést tesz fel. Egymástól távol, egy IGEN és egy NEM táblát cövekel le a talajba, ő pedig beállt közéjük, egy harmadik táblával a kezében, amin a kérdés szerepel. A JPL pedig válaszként a kamera fejét a megfelelő tábla irányába fordítja.

Mentőexpedíció

A filmből sajnos nem derül ki, hogy a fotót a Pathfinder mi alapján készítette el pont abban a szögben. A fotó valószínűleg automatikusan készült. Ez azt is feltételezi, hogy a Pathfinder folyamatosan készítette a fotókat, és küldte azokat a JPL részére. Ami viszont biztos, hogy az űrszonda rövid idő alatt több fotót is készít, ezeket küldi el a megfelelő paraméterekkel a JPL-nek, a földi vevőegység pedig a képeket panorámaképként összeillesztve jeleníti meg.

Kapcsolatfelvétel a Földdel: „hexadeci segít a bajban”

A kapcsolatfelvétel sikeressége után a kommunikáció fejlesztése a cél.  Ezen nyilván mind a két oldalon dolgoznak, ám első körben főhősünk ötlete lendít egyet az ügyön. Az eldöntendő kérdésekkel a JPL nem tud megfelelő válaszokat adni, hiszen korlátot szab, hogy csak a kamera fejének mozgatásával tudnak üzenetet küldeni. Mark kitalálja, hogy a JPL-nek hexadecimális ASCII kódrendszerben kell válaszolnia a kérdésekre. Ez azt jelenti, hogy a Pathfindert az angol ábécé 26 betűjét, illetve további 10 számjegyet, esetleg írásjeleket tartalmazó táblák helyett csupán 16 táblával kell körbe rakni. Tíz tábla a számjegyeknek, további hat tábla pedig a betűknek A-tól F-ig. Ezzel, valamint az ASCII kódtábla segítségével két hexadecimális helyiértéken 256-féle szimbólum jeleníthető meg, úgy mint az angol ábécé kis- és nagybetűi, számok, írásjelek, illetve jelen esetben kevésbé fontos vezérlőkódok. Így minimális mennyiségű tábla kihelyezésével megfelelő kommunikáció érhető el, hiszen ha túl sok tábla kerülne kihelyezésre, úgy nehezebben lehetne észrevenni, hogy az űrszonda forgatható kamerája melyik tábla irányába néz.

Mentőexpedíció

A film ugyan nem mutatja, de feltételezhető, hogy a Pathfinder valamilyen időközönként, talán egy változáskövető/szinkronizáló algoritmus segítségével folyamatosan fotókat küld a JPL részére. Az ottani mérnökök a képek alapján így hamar rájönnek, hogy Mark milyen módszerrel szeretné fejleszteni a kommunikációt. Ennek révén a JPL csapata is ugyanazokkal a táblákkal bástyázza körbe az űrszonda másolatát, majd ennek elkészülte után azonnal el is küldik az első üzenetüket.

Mentőexpedíció

Filmbeli baki?

A film 52. percének 12. másodpercében, amikor Mark az első Földről érkezett ASCII üzenetet dekódolja papíron, az ASCII kódok második sorának végén egy kérdőjel látható. A valóságban ott nem kérdőjelnek kellene lennie, hanem 3F-nek. A kérdőjelnek pedig a 3F alatt kellene lennie, ugyanis a „?” ASCII kódja 3F. Az megint egy másik kérdés, hogy amikor a Pathfindert körbe rakja táblákkal, akkor az egyik táblán van egy kérdőjel, illetve a JPL központjában a pizzás dobozra felvázolt terv is számol egy kérdőjel karakterrel. Persze innen nézve nincsen szó bakiról, ám kérdés, hogy vajon miért kellett azt a plusz kérdőjel táblát elhelyezni.

Mentőexpedíció

Kapcsolatfelvétel a Földdel: chateljünk a Föld és a Mars között

A kommunikáció újabb szintre emelésének egyik momentuma, amikor a NASA által megadott módon, a marsjáró operációs rendszerét úgy frissítik, hogy az kommunikálni tudjon a Pathfinderrel. Ennek egyik érdekessége, hogy a marsjárót a NASA fejlesztette, a Pathfindert viszont a JPL. Ebből is látható, hogy a szabványok használata mennyire megkönnyíti a rendszerek közti átjárhatóságot, hiszen főhősünknek csupán egy rövid kóddal kell módosítania a marsjáró operációs rendszerét, így az használni tudja az űrszonda rádiófrekvenciáját. (Más kérdés, hogy egy ilyen minialkalmazás miért nincs eleve beépítve a marsjáróba?) Továbbá a rendszer valószínűleg egy egyedi fejlesztésű Linux alapú operációs rendszer, mely úgy került megírásra, hogy az operációs rendszer a marsjáróból is módosítható legyen. További érdekesség, hogy a szoftver módosítása a film 54. percében mutatott képek szerint hexadecimális gépi kóddal történik. Tulajdonképpen a módszer lehetséges, azonban a NASA-nak – a JPL-en át – a hagyományos ASCII kódtáblázat segítségével kell ezt lekommunikálnia, ami egy meglehetősen hosszadalmas folyamat lehet.

Mentőexpedíció

Érdekesség még az is, hogy miközben Mark módosítja az operációs rendszert, az életben maradásához szükséges levegőt nem a marsjáróból vételezi, hanem a szkafanderéből. Űrhajós sisakja végig a fején van. Feltételezhető, hogy az operációs rendszer módosítása után egy önellenőrző tesztet is futtatni kell. A rendszer újraindítása a jövőben már nem biztos, hogy feltétel lenne.

Filmbeli baki?

A történetben az hangzik el, hogy az operációs rendszer módosítása után a NASA ráállíthatja a marsjárót a Pathfinder rádiófrekcenciájára. Ez nyilván nem lehetséges, hiszen ahhoz, hogy Mark kommunikálni tudjon a marsjáró segítségével a Földdel, előbb szükség van az űrszonda – mint adattovábbító eszköz – közbeiktatására. Vagyis a NASA nem tud kommunikálni közvetlenül a marsjáróval, így közvetlenül nem is tud segíteni az űrszondával történő összeköttetés létrehozásában. Ellenkező esetben a kapcsolat már korábban élt volna, valamint nem a JPL folytatna kommunikációt az űrhajóssal, hanem a NASA.

A kapcsolat létrejötte után, immáron egy chat felületen zajlik a beszélgetés a JPL és Mark között. Feltételezhető, hogy a marsjáró már eleve rendelkezett valami szöveges üzenetek fogadására és küldésére alkalmas programmal. Innentől már sokkal könnyebb a kommunikáció, bár még mindig nem annyira, mint ahogyan az a filmben látszik. Ahogy nézzük az eseményeket, úgy érezzük, mintha csak a Földön chatelnének egymással. Azonban a valóság még mindig az, hogy egy kérdés-válasz kör 32 percig tart. Tehát, amikor Vincent megkérdezi a JPL-t, hogy a társai hogyan fogadták a hírt életben maradásáról, az üzenet elküldése után legalább 32 percet vár a válaszra. Mivel válasz nem érkezett, ezért egy újabb üzenetet küld el korábbi érdeklődését illetően, melynek a válaszára ismét legalább 32 percet vár. Gondoljunk csak bele, hogy ez mennyire idegtépő lehet, továbbá arról se feledkezzünk meg, hogy még itt a Földön zajló kommunikáció esetében is mennyire egyszerű egymás „szavába” vágni, hát még ilyen késleltetéssel rendelkező üzenetváltás esetén.

Az ellátmány-küldetés

Az első beszélgetések során Mark megtudja, hogy a NASA egy ellátmány-küldetést állít neki össze. Ez annyit jelent, hogy a JPL rohamtempóban megtervez és megépít egy teherszállításra alkalmas űrszondát, melyet eljuttatnak a Marsra. Érdekesség, hogy ekkor a bolygók rossz állása miatt az utazás megtételére kilenc hónap áll rendelkezésre.

Érthetetlen?

Bár az ellátmány-küldetés elkészítését az ideális hat hónap helyett a NASA csupán három hónapra rövidítette, mégsem készült egy probléma esetén azonnal indítható tartalékpéldány. Abban az esetben, amikor egy űrhajós egy idegen bolygó felszínén ragad, és ellátmány-küldetést kell számára eljuttatni, erősen kétséges, hogy a valóságban is csak egyetlen hajóval számolnának. Sokkal valószínűbb, hogy más űrügynökségek segítségét is igénybe vennék, és szükség esetére építenének még egy, vagy kettő redundáns példányt. Annál is inkább mert hasonló eset nem egyszer már a valóságban is megtörtént. Amikor a Nemzetközi Űrállomásra (ISS) indult ellátmány-küldetés, az néhány esetben kudarcba fulladt (2014: Orb-3, 2015: Progressz M–27M,  SpaceX CRS-7). Ez azonban nem jelentett veszélyt az űrben tartózkodók életére, mert minden esetben rendelkeznek annyi tartalék élelmiszerrel és más szükséges erőforrásokkal, hogy egy ilyen balul elsült küldetés ne okozzon közvetlen életveszélyt.

A jövő: kvantumkommunikáció

A kommunikáció sebességének felgyorsításán talán épp a modern fizika segíthet a jövőben. A részecskék kvantum-összefonódásának jelensége meglehetősen biztató eredményekkel kecsegtet.

További részletek:

2017 nyarán kínai kutatóknak sikerült adatot továbbítani 1200 km-es távolságba késleltetési idő nélkül. Ez gyakorlatilag a sci-fi történetekben fellelhető teleportálásnak feleltethető meg. Amennyiben ez a mindennapi gyakorlatban is megvalósulna, az szinte olyan lenne az emberiség számára, mint a tűz birtokba vétele, a fémeszközök használatának kezdete, a kerék feltalálása vagy a csavart kötél alkalmazása. Az információ késleltetés nélküli átvitelénél gyorsabb megoldás gyakorlatilag nem létezhet (leszámítva az időben visszaküldött információt, de ez már sokkal mélyebben az elméleti fizika asztala).

A kvantumkommunikáció a kvantum-összefonódás alapjain nyugszik. Ez annyit jelent, hogy egy részecskepár – például foton vagy neutron – két részecskéje között olyan jellegű kapcsolat van, hogy az egyik állapotának megváltozása akkor is hatással van a párjára, amennyiben közöttük több millió fényévnyi távolság van. Tehát ha a részecskepárokat szétválasztjuk egymástól, és két különböző helyre visszük őket, a közöttük fennálló kapcsolat ebben az esetben sem szakad meg. Amennyiben az egyik részecskében változást idézünk elő, arra a másik részecske – függetlenül a távolságtól – azonnal reagál, így az információ átadás azonnali, szám szerint 0 ms.

2019 szeptemberében a Google és a NASA kutatóinak sikerült egy olyan kvantumszámítógépet megépíteni, amely a betáplált feladatot 3 és fél perc alatt végezte el, szemben a mai hagyományos számítógépek tízezer évig tartó számítási idejével. Sajnos a hírt érdemes fenntartással kezelni, mert a NASA webhelyén közzétett cikket végül törölték.

A blog bejegyzés írása közben a hangulatról az AMAZING SPACE TRAVELING ~ Ambient Music ~ Background Music gondoskodott.

A blog bejegyzés képei az említett Mentőexpedíció (2015) című filmből származnak.

Céline Dion – Courage World Tour

Céline Dion Courage World Tour

Céline Dion Courage World TourA Céline Dion – Courage World Tour esettanulmányunkban a turné első részének koncerthelyszíneit jelenítjük meg Google Charts segítségével. Ebben a blog bejegyzésben a tervezés, megvalósítás lépéseit tekintjük át és megmutatjuk az eredményeket. A Java és JavaScript forráskódokat most nem részletezzük.

Háromféle grafikont használunk

  • idővonal (Timeline) időpontok és helyszínek Gantt diagram-szerűen,
  • térkép (Geo Chart) városok megjelölésével és időpontok jelmagyarázatban,
  • tematikus térkép az USA államaival (szintén Geo Chart), az állam területén adott koncertek száma alapján és db jelmagyarázatban.

A tervezés és megvalósítás lépései

  1. Adatokat kell szerezni egy weboldal (https://www.celinedion.com/in-concert) feldolgozásával ( saveHTML()). Ehhez a művelet a GET. Figyelni kell a megfelelő User-Agent paraméterezésére és a karakterkódolásra ( ISO-8859-1). A kapott bemeneti folyam feldolgozását pufferelt módon érdemes elvégezni. Célszerű az adatforgalom minimalizásása érdekében a weboldal tartalmát helyi fájlba menteni ( tour.html). Ügyelni kell a kötelező és az ajánlott kivételkezelésre.
  2. Értelmezni kell a tour.html fájlt. A HTML tartalom végén JSON formátumban beágyazva elérhetők a koncert turné állomásainak adatai: nekünk kell a város ( city), helyszín ( venue), dátum/idő ( startDate). Érdemes külön fájlba menteni a tour.html-ből a JSON tartalmat ( tour.json), mert abból egyszerűen betölthető ( saveJSON()).
  3. Tanulmányozni kell a Google Charts diagramok közül azt a kettőt, amiket testre kell szabni: Timeline és Geo Chart. Tudni kell: mi a diagramot tartalmazó weboldal állandónak tekinthető eleje és vége (ezeket hasznos külön interfészben konstansként tárolni: HTMLFileContent), valamint mi az adatoktól függő része (közepe). Ismerni kell a szükséges metaadatok és adatok formátumát. Érdemes átnézni a különböző testre szabási és formázási lehetőségeket a fenti diagramtípusoknál (esetleg a többi típusból is meríthetünk ötleteket).
  4. A koncert turné állomásainak összetartozó 3 adatát le kell képezni POJO-vá ( Event). Ezt érdemes privát változókkal ( city, venue, startDate) és factory metódussal megvalósítani. Célszerű, ha az adatok visszakérésére alkalmas getter metódusok is készülnek ( getTimelineChartDataTableRow(), getGeoChartDataTableRow()), amelyek kiszolgálják a megfelelő diagramtípus igényeit.
  5. A tour.json fájl feldolgozásával (parszolásával) Event típusú generikus listába vagy JSON tömbbe könnyen leképezhetők az adatok.
  6. Hasznos egy vezérlőosztály létrehozása, amely a 3 diagramtípust előállító (HTML fájlt generáló) metódust ( createTimelineChart(), createGeoChartCity(), createGeoChartCountry()) valamint a belépési pontot ( main()) tartalmazza.
  7. Generálható az idővonalat tartalmazó timelineChart.html fájl a createTimelineChart()metódussal. Ehhez 5 oszlop megadása szükséges (ebben a sorrendben): label, city, tooltip, start, end. Az első 3 adat string, az utolsó 2 adat date típusú. Egy példa Event: ['2019.09.18.', 'Québec, QC', 'Videotron Centre', new Date(2019, 09, 18, 19, 0, 0), new Date(2019, 09, 18, 21, 0, 0)].
  8. Regisztrálni kell egy Google Cloud Platform felhasználói fiókot és tanulmányozni kell a geokódolás folyamatát és lehetőségeit, hiszen a városok nevéből (formátum pl.: 'Minneapolis, MN') szükség lesz azok térképi koordinátáira. Aktiválni kell a szolgáltatás használatához szükséges mapsApiKey-t.
  9. Generálható a városokat tartalmazó geoChartCity.html fájl a createGeoChartCity() metódussal. Ehhez 3 oszlop megadása szükséges (ebben a sorrendben): city, dateCity, no . Egy példa Event: ['Minneapolis, MN', '2019.11.01. Minneapolis, MN', 1].
  10. Generálható a régiókat/államokat tartalmazó geoChartCountry.html fájl a createGeoChartCountry() metódussal. Ez egy tematikus térkép: a különböző színek jelölik az egy régió/állam városaiban tartott koncertek számát. Ehhez az adatok megfelelő rendezését követően végrehajtott csoportváltás algoritmus szükséges. 2 oszlop megadása szükséges: country, concertNo. Egy példa adatsor: ['US-TX', 3].

Az eredmények

TimelineChart grafikon:

GeoChartCity grafikon:

GeoChartCountry grafikon:

Érdemes megismerni további – térképekhez kapcsolódó – grafikontípusokat is: Geomap, Intensity Map.

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 példák a Java SE szoftverfejlesztő tanfolyam 37-44. óra: Fájlkezelés és a Java EE szoftverfejlesztő tanfolyam 1-4. óra: Elosztott alkalmazások, webszolgáltatások és 13-16. óra: JSON feldolgozás alkalmaihoz kötődnek.

Sankey-diagram készítése

Sankey diagram logó

Sankey-diagram-logoA Sankey-diagram alkalmas kétféle adatsor közötti N:M fokszámú kapcsolat, összefüggés és a köztes átmenet ábrázolására. Hangsúlyozza a fő átvitelt vagy áramlatokat egy rendszeren belül. Az áramlás irányát nyíllal szemlélteti és az áramlatok szélessége arányos az áramlási mennyiségekkel.

Feladat

Jelenítsük meg HTML formátumú weboldalként a magyarországi régiókban a foglalkoztatottak számát nemzetgazdasági szektorok szerint a KSH 2018-as adatsora alapján! Automatizáljuk egy Java programmal úgy a feladatot, hogy az év paraméterként megadható legyen!

Tervezés

A KSH témastruktúrában a táblázat elérési útja:

  • 5. Területi adatok,
  • 5.1. A munkaerő-piaci tendenciák Magyarország régióiban,
  • 5.1.3. A foglalkoztatottak száma nemzetgazdasági szektorok szerint, nemenként (2008–)

Online böngészhető táblázat:
http://www.ksh.hu/docs/hun/xstadat/xstadat_hosszu/h_qlf017.html.

Letölthető táblázat (XLS formátumban): http://www.ksh.hu/docs/hun/xstadat/xstadat_hosszu/xls/h5_1_3.xls.

A táblázatban lévő adatforrás szükséges része látható az ábrán:

KSH adatforrás Sankey-diagramhoz

A táblázatban a régiók az A105:A112 cellatartományban találhatók. A hozzájuk tartozó 3 nemzetgazdasági szektor a B-C-D oszlopok azonos soraiból olvashatók ki. POJO-k létrehozása mindenképpen hasznos a megvalósításhoz, például new SankeyData("Közép-Dunántúl", "Szolgáltatás", 253.89). Ezekből generikus listát is célszerű építeni: List<SankeyData> sankeyDataList.

Többféleképpen is hozzájuthatunk az adatokhoz attól függően, hogy milyen előismeretekkel rendelkezünk a különböző tanfolyamainkon:

  • A Java SE szoftverfejlesztő tanfolyamon „kézzel” letölthetjük a projekt files mappájába az XLS fájlt. Ezután akár manuálisan is összeállítható a POJO lista, vagy a JExcel API-val is hatékonyan feldolgozható a XLS fájl aktuális munkalapja. Fájlkezelés előtt az összeállított HTML fájlt kiírathatjuk a konzolra, ahonnan „kézzel” vágólapozva létrehozhatjuk belőle a szükséges HTML fájlt. Fájlkezeléssel persze adott mappába, adott fájlnévvel, kivételkezeléssel a java.io vagy java.nio csomagot használva a HTML fájl generálása is automatizálható.
  • A Java EE szoftverfejlesztő tanfolyamon megvalósítható, hogy a program kivételkezeléssel hálózati kapcsolatot épít, majd letölti az XLS fájlt és ezzel a feladat visszavezethető az előző esetekre. Azt is megtehetjük, hogy az XLS fájlt nem töltjük le, hanem olvasunk belőle közvetlenül a webről. Ekkor is rendelkezésünkre áll a POJO lista. Itt már tudunk HTML fájlt is automatikusan generálni.

Tanulmányoznunk kell a Google Charts galériában a Sankey diagram dokumentációját! Meg kell ismernünk a paraméterezési lehetőségeit és JavaScript forráskódját!

Megvalósítás

A createSankeyDiagram() függvény létrehozza a HTML fájl szöveges tartalmát. Átveszi adatforrásként a sankeyDataList generikus POJO listát. A String típusú sankeyData objektum tartalmazza a Stream API-val hatékonyan összefűzött – POJO-któl elkért – toString() szövegeket. Ezek a diagramhoz szükséges adatok ( addRows …). Például: "['Közép-Dunántúl', 'Szolgáltatás', 253.89]". A  String típusú  html objektum kezdetben tartalmazza a diagramhoz nem szükséges fix részeket, a diagram alapbeállításait, valamint a diagram fejlécéhez szükséges metaadatokat ( addColumnRégió, Nemzetgazdasági szektor, Foglalkoztatottak száma (ezer fő)). A függvény végül a html objektum #SankeyData# részét cseréli a sankeyData-val és az adatfüggő résszel frissített HTML tartalommal tér vissza.

Eredmény

Az egyik eredmény a generált HTML fájl (benne a grafikonhoz tartozó JavaScript) forráskódját tartalmazza:

A másik eredmény a Sankey-diagram képernyőképe, amelyről kiválóan leolvashatók az értékek:

Sankey-diagram

A böngészőben megjelenő HTML oldalon a Sankey-diagram dinamikusan – az egérkurzor pozíciójától függően – képes az aktuális adatok megjelenítésére, mintegy lebegő jelmagyarázatként.

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

Időjárás Budapesten

OpenWeatherMapWidget

Talált időjárás Widget

A Widgets constructor – OpenWeatherMap weblapon nézelődve megtetszett ez a Widget:

aktuális időjárás Budapest

Főleg az volt nagyon szimpatikus, hogy milyen egyszerűen beépíthető mindez egy webes/mobil felületre az alábbi JavaScript forráskóddal:

Mindössze egy regisztráció szükséges hozzá a Members OpenWeatherMap weboldalon a fenti forráskódba behelyettesítendő API kódért. Az egy sorba ömlesztve kapott forráskódot a Javascript Viewer, Beautifier and Formatter, Editor weblapon formáztam könnyen olvashatóvá.

Saját fejlesztés

Kedvet kaptam ezt a funkcionalitást összerakni úgy, hogy a hálózati kommunikációra helyeztem a hangsúlyt.
A nézet réteg ezért igen egyszerű, Java swing felületen, JFrame form-ként varázsolt az alábbiak szerint, mindössze JPanel és JLabel vizuális komponensekből áll. Egy JLabel osztályú komponens képes szöveg és/vagy kép megjelenítésére is.

aktuális időjárás Budapest

1. feladat

A modell rétegben tárolt település nevét és a szolgáltatás igénybevételéhez szükséges API kulcsot összerakva a Current weather data – OpenWeatherMap oldal specifikációját követve, megkapjuk az adatok lekérdezéséhez szükséges URL-t:

időjárás API URL

2. feladat

A hálózati kapcsolatot felépítve el kell kérni ( GET) az URL-ről kapott JSON formátumú adatot és tárolni kell azt a modellben ( jsonPuffer). A kivételkezelést nem részleteztem, mert most nem ezen van a hangsúly.

A jsonPuffer objektum ezt tartalmazza:

IdojarasJSON

A könnyen átlátható formátumot a JSON FORMATTER & VALIDATOR weblapon állítottam elő.

3. feladat

A JSON-t fel kell dolgozni és a különböző adatokat formázni/konvertálni kell, alkalmazkodva a megjelenítés igényeihez (például hőmérséklet Celsius fokban egész számra kerekítve, szélsebesség egytizedes pontossággal, hónap neve angolul, szükségesek a megfelelő mértékegységek). Külön gondoskodni kell arról, hogy az aktuális időjárást szimbolizáló ikonhoz (képként külön letöltve) is hozzájussunk, mert az API csupán az útvonalát jelentő URL-ből csak a fájl nevét (azonosítóját) adja meg. A kivételkezelést itt sem fejtettem ki.

4. feladat

Végül a modelltől elkért adatokkal frissíteni kell a nézetet.

Az eredmény

IdojarasBudapest


IdojarasLondon

IdojarasHouston

IdojarasTokyo

Aki kedvet kapott, annak többféle API is rendelkezésére áll, dokumentációval és példákkal együtt a https://openweathermap.org/api weboldalon. Kísérletezni bátran szabad, illetve érdemes megnézni és értelmezni azokat az adatokat, amiket JSON formátumban visszakapunk, de ehhez a feladathoz nem volt rájuk szükség.

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 EE szoftverfejlesztő tanfolyam 9-12. óra: XML feldolgozás és 13-16. óra: JSON feldolgozás alkalmaihoz kapcsolódik.