A Linuxos program időzített futtatására használj cront, vagy egyszerűen írj egy bash scriptet, ami tight loopban vár. A kimenetet meg simán irányítsd bele egy fájlba. A Java programban ugyanezt a fájlt nyisd meg ugyanilyen időközönként. Aztán dolgozd fel, s írd ki adatbázisba. Amúgy ahogy az adatod jellegét nézem, kb. egy time series database-ben lenne a legjobb őket tárolni. Erre jó pl. Influxdb. Aztán csinálhatsz rá mindenféle fancy ábrát Grafanával.

Parse-olni ezt egyébként elég egyszerű, soronként végigolvasod, majd line.split("."), a három elemű tömböt meg felhasználod ahogy akarod..

Más: Mi a legjobb, legmélyebb Spring video course amivel találkoztatok? Kéne nekem egy masszívabb. Ha csak fizetős van, az se gond. De örülnék, ha legalább 20 óra körüli lenne és nagyon a részletekbe menő.

I am having fun staying poor.

A terv hasonló, de nem szeretném fájlba tárolni, hanem jó lenne java exec megoldással a kimenetet elkapni és parse-olni.
Illetve a grafana tervben van, de sima mysql-ben gondolkodtam nem influxdb-ben. Utóbbit ugyanis nem ismerem és telegraf-ot sem használtam még.

Ezért elsőkörben sql lenne. Aztán lehet nekiugrok megismerni az influxdb-t. Csak valami jó anyagot kell találnom róla, ami pontosítja bennem a lényegét, működését, felhasználását.

De köszi a tippet, tényleg ez volna a legjobb végeredmény a feladatra.
És persze docker használat is jó volna, de még az is várat magára.

[ Szerkesztve ]

A magam részéről mindenképpen szívlapáttal csapnám fejbe, aki erre a problémára java programot ír.
bash shell + sed.

szerk: letenni fájlba, linuxon, lyalylyly

[ Szerkesztve ]

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

A modorod a szokásos, neked sem ártana egy szívlapát a képedbe.

Aztán gondolom majd a sed tolja nálad az adatokat mysqldb-be (influxdb még hagyján) és ha netán win-en akarnám futtatni, akkor meg mivan? Szóval igen, java program kell. Pont java és pont azért, mert java.

[ Szerkesztve ]

a véleményedtől függetlenül súlyos hiba java vm-et meg java-s programot indítani ott, ahol egy sed vagy awk program tökéletesen elegendő. attól, hogy van java a gépeden, még nem kell minden esetben használni.
a mysql-nek van parancssori kliense, az tökéletes arra, hogy betöltsd az adatokat az adatbázisba.

"jó lenne java exec megoldással a kimenetet elkapni és parse-olni.": azt sem értem, ehhez minek java exec. feltalálták a csővezetéket, tessék szabvány bemenetet olvasni és parsolni, ha mindenáron java-ban akarod.

bocs, de úgy gondoltam, hogy nem központi probléma megoldani, hogy egy linuxon futó program kimenete hogy kerül egy windowson futó programba. te írtad, hogy linuxon futó program szenzor adatokat gyűjt. miért akarnák windowson adatbázisba rakni?

hagyd a fenébe a java-t, shell szkript topicban vagy linux kezdő topicban megmondják a jó megoldást. szenzor program kiolvassa a mért értékeket, kiküldi szabvány kimenetre, azt sed-del, awk-val vagy shell szkripttel átalakítod szabvány sql insert utasítássá, azt bele küldöd a mysql kliensbe és kész. ennyi. nem java, meg legyen kéznél jdbc driver, meg vm meg a fene se tudja még mi minden függőség.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Van pár szempont ami miatt a sheel-ből nem volna jó dolgoznom.

- Egyrészt szeretném a beérkezett értékeket validálni mielőtt tárolom. Persze ezt is lehet bash-el, de java kényelmesebb volna.
- A szerveren mindenképp van java, mert van egy API, amivel pedig le lehet majd kérdezni ezeket. Tehát a függőségek mindenképp megvanak már
- Szeretném magát az sql részt nem látható módon használni, tehát nem volna jó, ha az insert into mondjuk script-ben lenne
- Lenne windows-os gép is, ami szenzor adatot kap, ott akkor új megoldás kellene a parse-oláshoz (persze ott is megoldható)

Amit mondasz, az mondjuk tökéletes megoldás lehetne arra az esetre, amikor az rpi-ket kell használnom majd. Ott problémás lenne a java.

Azon gondolkodom, hogy esetleg tényleg a megoldás az lenne, hogy egy API-t csinálni java-ban, amit a kliensek hivogatnak és a már parse-olt adatokat azon keresztül tolnák befelé. Merthogy a szerveren amúgy is van tomcat. Aztán ott validálnám és ha oké tárolnám (mysql, influx, miegyéb) Ha nem oké majd a response jelzi a kliensnek.
Ekkor a kliens lehet mondjuk a mostani gép linux-al és akkor a sed szétszedné az adatokat (és mondjuk curl hívná az api-t). Ez járható lenne a későbbi rpi kliensek esetén is. A win-es megoldást nem tudom még, hogy ott miként lehetne szétkapni az adatokat és hívni az api-t, de gondolom ott sincs nagy csavar a dologban.

Ez mennyire lenne járható út?

Ez a formátum YAML-ként is értelmezhető, így egy YAML parser be tudja olvasni, és akkor nem egy igénytelenül gányolt shell-ninja szutyokkal oldod meg, amit 1 év múlva a saját szerzője sem tud már támogatni.
De van rá lényegében kész megoldás is: ELK stack. Azt pont ilyenekre találták ki. Logstash illesztőkön keresztül Elastic-ba tolja a szenzorok adatait, amit később Kibanával meg tudsz jeleníteni. Ezt a shelles babrálást meg felejtsd el

tökéletesen leírtad, hogy mi a baj egyes java architektekkel.
elk meg logstash meg elastic meg kibana meg a franc se tudja hány cuccot felrakni azért, hogy bekerüljön egy mért érték egy adatbázisba, az durva tévedés. mindegyik szoftver bugos. ha telerakod szoftverrel a rendszert, akkor teleraktad hibával is.

amit két sorban meg lehet írni shellben, ahhoz nem rakunk fel akkora architektúrát, hogy csak a0-s lapra lehet kinyomtatni. és ha még valaki a dockert is elkezdi emlegetni, sikítani fogok.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

"Egyrészt szeretném a beérkezett értékeket validálni mielőtt tárolom.": egyrészt lehet shellben, awk-ban, bármiben validálni. de validálhatod az adatbázisban is. már ha a mysql alkalmas erre, sose próbáltam. postgresql alkalmas.
"esetleg tényleg a megoldás az lenne, hogy egy API-t csinálni java-ban, amit a kliensek hivogatnak és a már parse-olt adatokat azon keresztül tolnák befelé.": van ilyen api, a mysql hálózati apija, minek akarnál még egy újabb apit kitalálni?

lyalyly curl... most eltekintve attól, hogy tök értelmetlen http-n csinálni ilyet, a curl-ben túl sok hiba van ahhoz, hogy komoly rendszeren használd.
ha mindenáron kell a wines kliens, akkor winre van sed, bash, mysql kliens, és ugyanaz, mint linuxon. hogy powershellben mekkora meló leprogramozni, nem tudom. de mivel úgysem tudod ugyanazt a szenzorprogramot futtatni, ezért a rendszer mindenképpen különbözni fog.

de ha már itt tartunk: miért nem rakod bele a mysql klienst a szenzorokat kezelő programba?

persze elfelejtettem az alapvető kérdést feltenni: dolgozni akarsz vagy megoldani a problémát?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az exe futtatása megoldható a Runtime.getRuntime().exec(...) hívással. Visszakapsz egy processz-t, aminek a lefutását waitFor()-ral megvárod. Itt van rá egy kis példa program, ami már demonstrálja azt is, hogy hogyan lehet az exe outputját (stdout) megszerezni. (Alternatíva, hogy az exe egy fájlba írja az outputját, amit futás után normál módon fájlként felolvasol.)

A parsolásra régebben még azt mondtam volna, hogy kell írni egy parsert, de manapság ez nem divat... Ha tényleg ennyire rögzített a szerkezet, akkor a sorban szereplő négy komponens (csoport, adatnév, értéknév, érték) előbányászható egy reguláris kifejezéssel is, pl. ezzel:

^([^.]+)\.([^.]+)\.([^.]+): *(.*?) *$

Az outputot soronként célszerű feldolgozni, az elején vagy ki kell hagyni fix számú sort, vagy egyszerűen ki kell hagyni azokat, amire nem illeszkedik a regex:
Pattern pattern = Pattern.compile(<a fenti regex>);
while (<van sor>) {
Matcher m = pattern.matcher(<a sor tartalma>);
if (m.find()) {
String sensorGroup = m.group(1);
// ...
String sensorValue = m.group(4);
// DB mentés
}
}

Alternatív szervezés: linux-ban oldod meg, amit lehet. A java program nem hajt végre exec-et, helyette a standard input-ot olvassa, és dolgozza fel. Hívni meg valahogy így:

>sensor.exe <opciók> | java -jar sensorprocessor.jar

És az egészet lehet futtatni pl. cron-ból. (Hátránya, hogy a JVM indítás kissé erőforrásigényes, 30 másodpercenként meg pláne.)

Megjegyzések: (1) fejből írtam, a kódot tekintsük pszeudokódnak, (2) a regex pattern-ben a \-eket duplikálni kell a Java string konstansban.

Szerk: A korábbi válaszokat nem láttam, pár dolog így ismétlés, bocs.

[ Szerkesztve ]

''The third planet is incapable of supporting life. Our scientists have said there's far too much oxygen in their atmosphere.''

Az a baj a script ninjákkal, hogy mindig arra a feladatra koncentrálnak, ami az orruk előtt van. Ezt meg lehet oldani két sor scripttel, ja várj még mókolok rajta.
Szinte minden esetben, amikor egy ilyen kérdés felmerül, jönnek az újabb ötletek, és a végén te is tudod nagyon jól, hogy nem kötélhintát szeretne az emberünk, hanem komplett vidámparkot. Aztán abban a vidámparkban találd meg az egyes scripteket, amiket jó esetben a szerzője tud értelmezni. Tele van a padlás ilyen "szakemberekkel", akik indulatból oldanak meg mindent.

az elastic maga az "adatbázis"
a kibana egy dashboard, amivel megjeleníted a méréseket, nyilván nem terminálon queryzgetve akarod nézegetni
a logstash a "pumpa", amivel tetszőleges forrásból, és formátummal betolod az adatokat, ha netán bejönnek új mérések

Ettől függetlenül lehet scriptekkel gányolni

Tetszik a vidamparkos hasonlat
[off, csak errol jutott eszembe, az idei adventofcode feladatainak majdnem fele egy ilyen evolucios dolog: az elejen csak 2 opcode-ot ismero ertelmezo volt a feladat, most mar komplett terkepet uzemeltet a sajat hasaban es azt kell meghajtani kivulrol algoval -- megjegyzem nekem tetszik es viszonylag uj is ez a(z elore nem ismert) funkcionkkent tovabbpockolos munkamodszer - igaz nem is java-ban hanem pythonban csinalom]

az a baj a jáva nindzsákkal, hogy ha meglátnak egy új jáva szabványt, azonnal fel akarják használni akkor is, amikor nincs mire. Meg az is, hogy soha nem az előttük levő feladatra koncentrálnak. De ha nem, akkor mire?

De az is látszik a párbeszédből, hogy sokan úgy programoznak linuxon, hogy fogalmuk sincs, mit jelent linuxon programozni. ha linuxon windowsosan akarsz programozni, akkor tegyél fel windowst.

Tele van a padlás olyan jávás szakemberekkel, akik akkor is atomtengeralattjáróról kilőtt interkontinentális ballisztikus rakétával lőnek, ha csak egy veréb a célpont.

Szerinted melyikben valószínűbb, hogy hiba lesz: egy két soros shell szkriptben vagy egy elastic-ban? Melyikre kell több erőforrást felhasználni, kiemelten emberit is: egy szkriptre vagy egy rakás jáva vm-re meg benne futó rakás szolgáltatásra? melyiket kapod meg összességében olcsóbban? hint: nem a jávát, arra mérget vehetsz.

És hiába fikázod a szkript nindzsákat, az objektív műszaki érvek ebben a feladatban nem a jáva mellett szólnak.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az ELK nem új. Van mire használni, leírtam, bár láthatóan nem sikerült beazonosítani a komponenseket. A logstash elég messze van a "ballisztikus rakétádtól".
Nem fog megállni a dolog egy property->insert trafónál, ezt nem akarod látni, nem veréb a célpont. A script nem két soros lesz, azt már most garantálom, nem rugalmas, nem használható tovább, csak egy darab script, ami szerencsés együttállásnál elég lehet workaroundnak. Rendszerszemlélet zéró.

"Nem fog megállni a dolog egy property->insert trafónál": ezt úgy hívják, hogy találgatás. Ha architekt követi el, akkor az főben járó bűn. A feladat szenzoradatok mysql-be töltése. Nem vidámpark, nem csillagháború, egy darab libikóka.

"Rendszerszemlélet zéró.": ez nyilván téves kijelentés több okból is. Egy kétsoros szkriptet összeütök két perc alatt. Tehát ha a találgatás, hogy majd valamikor beláthatatlan időtávban mégis lesz extra kérés, amire a szkript már nem alkalmas, akkor pontosan ugyanennyi idő alatt ki is dobom.

Másrészt a rendszerszemléletben alapvető, első helyen levő pontnak kell lenni, hogy a rendszeredet kicsinek tartod meg. Tehát amíg lehet, nem növeled. Minél kisebb egy rendszer, annál egyszerűbb üzemeltetni. Ja, jáva architektek ezt se szokták figyelembe venni, hogy a lomjukat üzemeltetni is kell. Meg debuggolni.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Annyira ne kapaszkodj már a szavakba, mert az eredeti felvetés annyi volt, hogy parsolni szeretne. Meg akar oldani egy problémát, amire létezik megoldás, nem is egy. Amit te javasoltál neki arra jó, hogy kézzel belökjön pár tesztadatot valahová. Egyik oldalon próbálsz ragaszkodni a "leírtakhoz" a másik oldalon meg "találgatsz". Ez tök jó, ha csak a vita kedvéért csinálod, bár már rögtön az elején megmondta, hogy köszi nem.
Nyilván 3 szutyok property beolvasására nem kell még DB sem, nemhogy teljes stack, sem sed, awk, meg majdnem szabványos reguláris kifejezések, de ha egy kicsit felnézel a billentyűzetből, akkor láthatod a céljait jövőbelátás nélkül.

Ha vitatkozni szeretnél csak, akkor biztosan találsz mást a környezetedben, ha meg van érdemi mondanivalód, akkor azzal kéne folytatni.

A scriptedet lehet, hogy kidobod minden egyes változtatásnál, bár leginkább az ötletet kéne kukázni, mert semmi másra nem jó, csak egy éppen aktuális állapot kezelésére, ahol ha hiba van az awk/sed kifejezésekben, ott nagyobb gondban van egy harmadik ember, mintha egy konfigot kéne módosítani - feltételezem, hogy ért hozzá az ember, amit csinál, márpedig ez awk/sed esetében elég nagy szó.

Ne csinaljatok mar! Szerintem senkinek nincs igaza Na jo, mondhatjuk ugy is, hogy mindkettotoknek.
A kerdes, hogy az adat _felhasznalva_ mikor es hogyan lesz. A mikor mindket ertelemben: 1. mikorra lesz kesz valami, ami mar hasznalja 2. a bekeruleshez kepest mikor (on-the-fly vagy havi osszesites). Ha a ketto kozul barmelyik a PatoPal-os verzio, akkor en bizony kezzel nyersen (az ellenorzest se eroltetnem bele) letolnam, azaz a gyujtes mar megkezdodik egy ket perces script utan; ellenben barmi magasabb szintu (adatellenorzes, osszesites stb.) plane megjelenites jellegu izet valami magas szintu, akar java nyelven tennek meg.
Most mar mindketten lohettek ide

amit mondtam eddig, az érdemi mondanivaló attól, hogy te nem értesz vele egyet. Nem a vita kedvéért csinálom, hanem azért, hogy a kedves kolléga tanulhasson belőle. Ettől egy független tény, hogy mivel te java-val foglalkozol, szerinted mindent java-ban kell megoldani.

abban pedig biztos vagyok, hogy sokkal hamarabb fog érteni valaki vagy talál valakit, aki ért a sedhez, mint egy tök idegen program json konfigjához, amiben pont ugyanazok a reguláris kifejezések vannak, mint amit sedben használsz.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Én dolgozam olyen helyen ahol ez volt a szokás, és kb. ott csaptam volna szét mindent szívlapáttal.

A végeredmény 10 ezer soros bash scriptek (vegyítve gawk-val és python szkriptek behívásával), egy olyan feladatra amire totálisan alkalmatlan. Inkább akkor python vagy valami egyéb shebangelhető szkript.

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

nem mondtam, hogy mindenre jó. viszont amit két sorban meg lehet csinálni benne, arra nyilvánvalóan alkalmas.
de tudnék mondani olyan problémát az életből, amire a 10 ezer soros shellszkript jó, a java meg nem.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

"De az is látszik a párbeszédből, hogy sokan úgy programoznak linuxon, hogy fogalmuk sincs, mit jelent linuxon programozni. ha linuxon windowsosan akarsz programozni, akkor tegyél fel windowst."

Ebből nekem az jön le, hogy akkor linuxon mindent írjunk szerinted bash-ben. Én zsh-t használok és macet munkára. Ott mit kéne csinálni?

"Szerinted melyikben valószínűbb, hogy hiba lesz: egy két soros shell szkriptben vagy egy elastic-ban?"

Tudsz unit tesztelni bash-t és jávát is, a hiba valószínűsége ugyanakkora.

"És hiába fikázod a szkript nindzsákat, az objektív műszaki érvek ebben a feladatban nem a jáva mellett szólnak."

Abban igazad van, hogy talán nem a Java a legjobb megoldás erre, de szerintem még nem is a bash. Python például. Amúgy tipikus "szkript ninja" hozzáállás, hogy feszegetjük a jvm erőforrás felhasználását, ami tény, hogy több lesz mint egy szkripté. Cserébe nem lesz olyan lassú.

Egy szó mint száz, a kollégának kell tudnia, hogy miért akarja Javában írni. De szerintem ha Ő abban akarja és van alá vas akkor hajrá. Cron + CLI alkalmazás. Én viszont erre a feladatra a Python-t javaslom ha csak ennyit kell csinálni.

#10820: Full komolyan érdekel, mikor jó a 10k soros bash a javával szemben (én olyan szituációt még tényleg nem láttam. 10k soros szkriptet is csak azért mert ahhoz értett a költő)?

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

"akkor linuxon mindent írjunk szerinted bash-ben": nem.
a fő különbség a két rendszer között (unix vs. windows), hogy a unixot eredetileg kis programok hatékony összekapcsolására találták ki, a windows meg nagy monolitikus rendszerek futtatására. pl. ha windowson elindítod az outlookot, a fél office-t maga alá rántja, mert ha a levélben van excel vagy html, akkor máris behúzza az excelt meg a html motort.

unixon ezzel szemben az az alapvetés, hogy kis programokat csinálsz (amikor csak lehet), azok egy dolgot csinálnak, de azt hatékonyan és jól, és rábízod az oprendszerre, hogy összekösse a programjaidat.

ezért amikor elhangzott itt (nem Peachmantől), hogy a szenzor program tegye le diszkre egy fájlban az adatot és azt olvassa be jávából LINUXON, akkor azt gondoltam, hogy ezzel totálisan szívenszúrja a unixos alapfilozófiát. kevésbé udvarias megfogalmazásban ekkora f.ságot évek óta nem hallottam.

tehát itt a unixos filozófia szerinti megoldás az, hogy van egy szenzorleolvasója, van egy átalakítója meg egy adatbáziskliense, amiket a shell összeköt:

sensorread | sed ... | mysql ...

ha ezt el akarjuk rontani az itteni kérdés szintjére, akkor is az a megoldás, hogy jávában a szabvány bemenetet olvassa és azt elemzi, és csővezetékkel kerül a bemenetre az adat:
sensorread | java -jar szenzorosztalyom.jar

"Cserébe nem lesz olyan lassú.": értem, tehát a bash egy pártíz-párszáz soros szenzor kimenetnél lassú lesz? kizárt. ráadásul ugye itt nem is a bash fut sokáig, mert az csak összeköti a programokat, falusiasan fogalmazva bűvészkedik a fájldeszkriptorokkal, a sok olvasást, írást egy c-ben megírt, évtizedek alatt optimalizált kód fogja csinálni a sedben. nem lesz lassú, ne aggódj, nagyjából bármit el fog verni, mint az atom. az interpretált bájtkódodat szinte biztosan rommá fogja verni.

Egyébként én csak húsz éve foglalkozom hasonló kérdésekkel, nyilván tapasztalatlan vagyok a témában, szemben pár fórumtárssal a fotelből...

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

"Full komolyan érdekel, mikor jó a 10k soros bash a javával szemben": akkor jó, amikor egy nagyobb rendszerben történő folyamatot akarsz automatizálni, és ehhez parancssoros segédprogramokat adnak csak. fontos, hogy automatizálni akarsz, tehát nincs képernyő, grafikus interfész, klikkelés. van viszont mondjuk 200 darab bináris programod, amivel meg tudod oldani a problémád részfeladatait.

ilyenkor a jáva program nagyjából úgy nézne ki, hogy folyton parancssori paramétereket rak össze, exec()-el, eredményt olvas, stb. ehhez felesleges jáva. pont jó a szkript.

egy csomó telepítő meg karbantartó szkriptet láttam már, amik ilyenek voltak.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

""Cserébe nem lesz olyan lassú.": értem, tehát a bash egy pártíz-párszáz soros szenzor kimenetnél lassú lesz?"

Ezt általánosságban értelmezd ne erre a példára levetítve.

"unixon ezzel szemben az az alapvetés, hogy kis programokat csinálsz (amikor csak lehet), azok egy dolgot csinálnak, de azt hatékonyan és jól, és rábízod az oprendszerre, hogy összekösse a programjaidat."

Ezt most vagy félreértem, vagy nem tudom elképzelni mondjuk, hogy egy szerver alkalmazás szét legyen dobva 10 futtatható binárisra és egymást hívogatják.

"Egyébként én csak húsz éve foglalkozom hasonló kérdésekkel, nyilván tapasztalatlan vagyok a témában, szemben pár fórumtárssal a fotelből..."

Senki nem mondta, hogy tapasztalatlan vagy, csak azt, hogy erre a problémára létezik kb. 100 féle jó megoldás

[ Szerkesztve ]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Én ezt is Pythonban csinálnám, de ezt úgy mondom, hogy sok tapasztalatom nincs etéren - ha már valamiféle logikára szükség lesz (például logolás, http kliens [prometheus, grafana] stb. alapján).

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

"ezért amikor elhangzott itt (nem Peachmantől), hogy a szenzor program tegye le diszkre egy fájlban az adatot és azt olvassa be jávából LINUXON, akkor azt gondoltam, hogy ezzel totálisan szívenszúrja a unixos alapfilozófiát. kevésbé udvarias megfogalmazásban ekkora f.ságot évek óta nem hallottam."

Én írtam, s egyáltalán nem értek veled egyet. Majdnem mindegy, hogy először fájlba írsz valamit és onnan pollozod, vagy közvetlenül a pipe-pal küldöd át. Utóbbi esetben ráadásul újra, meg újra meg kell hívni a feldolgozó programot, ami nem feltétlen hatékony. Fájl változásra linux alatt selecttel fel tudsz iratkozni, Javaban is megvannak a megfelelő képződmények(Watch service). Egyébként named pipe-pal lehet a legjobban áthidalni, hogy a feldolgozó mindig futhasson attól függetlenül, hogy mikor kap inputot. De én fájlba írnám inkább, mert sokkal könnyebb lesz hibát izolálni annak előfordulásakor, ha a fájlra nézve meg tudod azonnal mondani, hogy mikor frissült, meg mi van benne, anélkül hogy a két alkalmazás belében kellene turkálni.

I am having fun staying poor.

Ez egy tök jó példa volt mert mindenre van alkalmazás. De egyedi alkalmazások esetében, biztos, hogy a logikát megakarod úgy erőszakolni, hogy adott esetben, find, bzip, grepkomopatiblilis legyen? Szerintem nem.

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

jaja, így csinálják a windowsról átszökött, unixot messziről ugató fotelprogramozók

nem, nem mindegy, hogy fájlba írod-e, tehát átkergeted kétszer a fájlrendszeren és a blokkos eszközökön a cuccot, vagy memória puffereken keresztül tolod be. nem pazaroljuk az erőforrásokat. különös tekintettel az iot nevű betegségre, ahol flash drájvokat nyírhatsz ki azzal, ha fájlba írsz, mivel a ramdiszk jellemzően kevés.

select meg watch service meg toronyóra lánccal... az eredeti kérdés szerint linuxon futna, ami egy unix. nem bohóckodunk ilyenekkel.

ha az a probléma, hogy debuggolni akarod a fájlt, akkor van rá segédporgram. tee. tehát azt írod, hogy:

sensorread | tee /tmp/logfile1 | sed | tee /tmp/logfile2 | mysql

ha nem akarod azt a hatalmas nagy sedet folyton forkolni, és mindenáron bele akarsz piszkolni a fájlrendszerbe, akkor egyik taszkban:

sensorread >>/tmp/dumpfile &

másik taszkban:

tail -f /tmp/dumpfile | sed | mysql
vagy
tail -f /tmp/dumpfile | java -jar tefeldolgozod.jar

második esetben esetleg van értelme jávás watch objektumozni...

de ha már ennyire elb.szarintod az architektúrát, akkor a legegyszerűbb az, ha a szenzorok adatait logoltatod a syslogba, és abból azon a gépen ott és akkor azt csinálsz, amit akarsz.

miért érzem azt, hogy azért jobb a jáva szerinted, mert a shell programozásról fogalmad sincs?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az eddigi hozzáállásod alapján inkább lehetne rólad elmondani, hogy szereted a scriptelést, és bármire azt használnál. Amíg 2 sorról van szó, még hagyján, bár ha abba kell beletúrni valamiért, továbbra is tartom, hogy kevés ember lesz, aki tartani meri érte a hátát. Nem egy 12-factor konform cucc, de mókolni jó.
Az üzemeltetéssel és karbantartással kapcsolatban éppen a scriptekkel van baromira rossz tapasztalatom többek között a minőségbiztosítás teljes hiánya miatt, és hogy az általad említett sok száz komponens nagyon nem mentes a hibáktól. Nem baj kavarjuk össze lecsóba, mi bajunk lehet.

Azt nem vágom, hogy pont ezeknek a szenzoros dolgoknak a kezelése eléggé ingoványos terep, de te nyugodt szívvel rábíznád egy pipe-olt scriptre a dolgot, miközben szinte mindenki kivétel nélkül baromira óvatos a témával. Amíg otthon barkácsol az ember egy arduinoval két hőmérő meg három nedvességérzékelő adataival, addig még hagyján, csak akkor tartsa is otthon a "tudást".

Az meg eleve nagyon gáz, hogy "debuggolni" úgy akarsz, hogy módosítod a kódodat. Agyrém...

Muhahaha.
Remekül szórakoztatod az embert a nagyon furcsa feltételezéseiddel, de közben szerencsére jó dolgokat is mondasz.

Arról sehol nem volt eddig szó, hogy mekkora méretű lenne az adat. Én eddig mindvégig azt feltételeztem, hogy kicsi.

"select meg watch service meg toronyóra lánccal... az eredeti kérdés szerint linuxon futna, ami egy unix. nem bohóckodunk ilyenekkel." És a select melyik oprendszer egyik fontos syscallja?

A tee-t tök jó, hogy felhoztad, mert magamtól nem jutott volna eszembe a neve, remélem most jobban elmélyül a tudatomban.
A syslogos megoldás az amúgy tetszik, bennem is bennem volt.

"tail -f /tmp/dumpfile | java -jar tefeldolgozod.jar
második esetben esetleg van értelme jávás watch objektumozni..."
De ilyenkor egy sima Scanner.nextLine is elég. Az vár az új inputig, vagy amíg a stdin-je el nem tűnik.

"miért érzem azt, hogy azért jobb a jáva szerinted, mert a shell programozásról fogalmad sincs?"
Én ilyet sehol nem írtam. Különböző célokra különböző eszközök a jók. Hirtelen meg az ember mindig úgyis azt a megoldást fogja ajánlgatni, amivel éppen a legjobban képben van. Ha nagyon akarnék, akkor én is elkezdhetnék kötekedni, hogy miért mysql-ben akarod a szenzor adatokat eltárolni, amikor vannak más kifejezetten ilyen célú adatbázisok is. De nem teszem, mert valószínűleg a probléma olyan kis méretű, hogy igazából nem számít.

Ui. a mysql klienst úgy kezeled itt mindenhol, mintha minden linuxon kötelezően rajta lenne, de az ugyanúgy egy dependencia, ami vagy van, vagy nincs.

"most eltekintve attól, hogy tök értelmetlen http-n csinálni ilyet, a curl-ben túl sok hiba van ahhoz, hogy komoly rendszeren használd."
Ezt btw. még kifejthetnéd, hogy mire gondolsz. Milyen hiba? (És természetesen a curl sem feltétlen minden disztró része)

I am having fun staying poor.

Mondjuk azért tegyük hozzá, hogy amikor a tee-vel kidumpol minden átcsorgó bitet az egyes kapcsolódási pontokon, lábon lőtte a binugzos architektúráját, amit pár kommenttel feljebb vázolt, miközben diszkréten lehülyézett.

mitől is lőttem volna lábon bármit is egy tee-től?
nem is tudom ki írta, hogy szkript nindzsa meg rendszerszemlélet nélküli meg hasonlók.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Sziasztok! JavaFX működik az újabb JDK-val, pl. 13-al? Honnan kell leszedni és hogy kell beállítani, próbáltam már Eclipse plugint ill. manuálisan megadni a JAR-okat, NetBeans-ben is, de nem működik. Köszi!

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Innen kell letölteni? [link]
Ebben nincs jfxrt.jar fájl, tudtommal ez kell és a jfxswt.jar
Ha nem adom meg a jfxrt.jar-t nem is tudja importálni a javafx-et.
Telepítettem a JavaFX Scene Builder 2.0-t, ebben van jfxrt.jar. Megadtam neki, így már importálja, kiterjesztem a Application osztályt, futáskor hibát ad:
"Error: Could not find or load main class TestFX
Caused by: java.lang.NoClassDefFoundError: javafx/application/Application"

Nem tudtam megnyitni az Application.class forrástfájlt, nem találta. Megadtam neki az src.zip forrást ami a javafx-sdk-13.0.1-ban található, amit innen szedtem le: https://openjfx.io/
Most mar megnyitja forrástfájlt, de ugyanez a hiba maradt. Valami ötlet? Mindez Eclipse 2019-12-ben....

[ Szerkesztve ]

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

JDK 11 óta nincs benne a JavaFX.
https://youtu.be/nbn_tjHBRV8

[ Szerkesztve ]

Ha jól rémlik akkor ez az: [link]

"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."

Erre rájöttem. Le is töltöttem az openfx.io-ról, de nem működik. Ehhez kellene egy kis segítség.

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Megoldottam, Eclipse-ben hozza kell adni a Run Configuration-nel egy VM argumentet

A kis emberek más emberekről beszélnek, a középszerű emberek eseményekről, a nagy emberek pedig ötletekről beszélnek.

Sziasztok!
Írtam egy hosszabb kódot, amiben az Arraylist rendezése nem működik.
Csak ezt a részt kivettem, hogy egy egyszerű példán oldjam előbb meg, de ugyanúgy nem jó.
Tudtok segíteni, hogy mi a baj vele? Miért nem jó?
A Collection.sort... kezdetű sornál jelez hibát.
Ezt irja ki: non-static variable dis cannot be referenced from static context
Köszönöm a segítséget.

public class Komparator {
 class KutyaRend implements Comparator<Kutyak> {
 @Override
 public int compare(Kutyak o1, Kutyak o2) {
 return o1.getKor()-o2.getKor();
 }
 }
 public static void main(String[] args) {
 Kutyak kutya;
 ArrayList<Kutyak> KutyaLista=new ArrayList<>();
 kutya=new Kutyak("Stefi", 6);
 KutyaLista.add(kutya);
 KutyaLista.add(new Kutyak("Lacy", 2));
 KutyaLista.add(new Kutyak("Roger", 3));
 KutyaLista.add(new Kutyak("Tomi", 4));
Collections.sort(KutyaLista, new KutyaRend());

A kutyarend osztályod nem látszik statikus metódusból, amíg nem jelölöd statikusnak.

static class KutyaRend implements Comparator<Kutyak> {
   ...
}

Ez szerintem egy elég nehezen érthető része a javanak. De a lényeg. Van a Komparator osztályod. Ezen az osztályon belül van egy inner classod, a KutyaRend. Ilyenkor a kutyarend osztály mivel nem static, ezért a példánya csak egy adott objektumpéldányon belül hozható létre. A static method nem példányhoz, hanem osztályhoz tartozik, így annak nincsen példánya, tehát nincsen benne KutyaRend létrehozási lehetőség sem. Legkönnyebben ezt itt úgy tudod megoldani, ha a Kutyarend osztályt statická teszed:
static class Kutyarend ...

De ettől sokkal szebb, ha nem ágyazod be az osztályba semmilyen módon, hanem külön osztályba teszed. Sőt, ha ez a kutyák természetes rendezése, akkor elég a Kutyákat implements Comaparble<Kutyák> módon megadni, s akkor benne a compareTo-t implementálni.

Még egyszerűbb, ha használod a Java 8-as Comparators.comparing-et, így:
Collections.sort(KutyaLista, Comparators.comparing(Kutyak::getKor));

[ Szerkesztve ]

I am having fun staying poor.

comparatornak bool al kellene visszatérnie hogy rendezni lehessen

Xbox One: bandymnc

Nagyon köszönöm mindenkinek a segítséget, sikerült megoldani
Drizzt külön köszönöm a részletes magyarázatot mellé, nagyon kedves vagy

Intet kell visszaadnia.

[ Szerkesztve ]

jah bocsi :D félig figyeltem csak, de ténxleg összekevertem

Xbox One: bandymnc

Hölgyek/Urak!

Programozás vizsgára készülök, az egyik feladatnál megakadtam.

Csv file-ból kellett adatokat beolvasni ArrayListbe, aztán mindenféle metódusokat gyártani rá. A csv file-ban gyümölcsök nevei (pl. alma, körte, stb) és hozzájuk tartozó adatok vannak, többek között a kalória.

A feladat az, hogy a metódus kérje be a felhasználótól a gyümölcs nevét és a mennyiséget, és ez alapján mondja meg, hogy az adott mennyiségű gyümölcs hány kalóriát tartalmaz.

Megcsináltam a metódust, azt szeretném elérni, hogy ha a felhasználó rossz nevet ír be (ami nem szerepel az ArrayListben), akkor addig kérje, amíg jót nem ad (jelen állás szerint ha rossz nevet ír be a felhasználó, leáll a program).

Itt a kód:
public static void kaloriaKiir(ArrayList<Gyumolcs> ertekek, File f) {
        Scanner scan = new Scanner(System.in, "ISO-8859-2");
        System.out.println("Kérem a gyümölcs nevét: ");
        String nev = scan.nextLine();
        if (gyum.toString().contains(nev)) {
            System.out.println("Kérem a mennyiséget grammban: ");
            int menny = scan.nextInt();
            for (Gyumolcs gyum : ertekek) {
                if (nev.equals(gyum.Megnevezes)) {
                    System.out.println(menny + " gramm " + gyum.Megnevezes + " " + gyum.kcal / 100 * menny + " gramm kalóriát tartalmaz.");
                }
            }
        } else {
            System.out.println("Nem megfelelő név!");
        }
    }

Van valami ötletetek?

[ Szerkesztve ]

Let the Zone take me if I am.

rakj bele egy while ciklust 1.0 verziónak jó, nem tudom van e erre kifinonultabb beépített lehetősêg

Xbox One: bandymnc