Új hozzászólás Aktív témák

• bambano titán

  #10824

  #10822 mobal

  2019-12-19 19:20:28

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bambano

  titán

  #10822 mobal

  #10822 mobal

  "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ő)?

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

• bambano titán

  #10823

  #10822 mobal

  2019-12-19 19:17:35

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bambano

  titán

  #10822 mobal

  #10822 mobal

  "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ő)?

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

Új hozzászólás Aktív témák