- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- Házi hangfal építés
- Nvidia GPU-k jövője - amit tudni vélünk
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- AI-ra, játékra, mindenre kiváló lehet a Gigabyte új PC-je
- TCL LCD és LED TV-k
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Vezetékes FEJhallgatók
- Fujifilm X
- ASUS notebook topic
- SSD kibeszélő
Új hozzászólás Aktív témák
-
-
#11523
bambano
titán
Oryctolagus
#11522
bambano
titán
válasz
Oryctolagus
#11522
üzenetére
lehet, megfontolnám, hogy nem a programot telepíten a pendrájvra, hanem a telepítőkészletet másolom rá...
-
#11521
bambano
titán
Oryctolagus
#11518
bambano
titán
válasz
Oryctolagus
#11518
üzenetére
nem a pendrájvod lassú, a ramod kevés.
egyébként meg árulnak külső ssd cage-t, amibe olyan ssd-t raksz, amilyet akarsz, és 3-as usb-n rádughatod a gépre. -
bambano
titán
válasz
Drizzt
#10828
üzenetére
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.jarmá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?
-
bambano
titán
"nem tudom elképzelni mondjuk, hogy egy szerver alkalmazás szét legyen dobva 10 futtatható binárisra és egymást hívogatják": oké, legyen egy egyszerű példa: biztonsági mentés.
tegyük fel, hogy a következő lépéseket akarod végrehajtani a mentéshez:
1. mentendő fájlok listájának előállítása
2. mentendő fájlok összecsomagolása egy konténerformátumba
3. konténer tömörítése
4. konténer lemezre írása.windowson erre van egy backup utility, monolitikus, felparaméterezed, fut. unixon mindegyik feladatra van egy program, és a programokat össze tudod kötni a shellel.
1. find
2. cpio
3. bzip
4. ddtehát azt mondod, hogy (a kapcsolók nem biztos, hogy jók):
find -atime 5 / | cpio -o | bzip2 -9 | dd of=/dev/rmt/0 obs=2k
A find összeszedi neked az összes fájlt, amit kevesebb, mint 5 napja néztél meg és a fájllistát kiírja a szabvány kimenetére. A find szabvány kimenetét a shell összeköti a cpio szabvány bemenetével (valójában úgy mókol a fájldeszkriptorokkal, hogy a find kimeneti puffere a cpio bemeneti puffere lesz, tehát nem a shell másolgat soronként, hanem ez kernelszintű szolgáltatás). A cpio a szabvány bemenetéről beolvassa azon fájlok nevét, amit az archívumba bele kell tennie és az archívumot kiírja a szabvány kimenetére. Ami átkerül a tömörítő bemenetére, tömöríti és kiírja a saját kimenetére. Amit megkap a dd, összeblokkosítja olyan méretre, ami a szalagegységnek optimális, majd kiírja szalagra.
Minden darab külön van, minden darabot cserélhetsz is, ha akarsz. Minden darab egy konkrét feladatot végez el. Gyakorlatilag kapsz egy kosár téglát és ebből neked kell házat építeni. Ez az erőssége és a gyengesége is egyben. Ha tudsz kosár téglát egymásra rakni, jó rendszered lesz. Ha nem, üres konzol előtt fogsz pislogni, mint kocsonyában a béka. A másik világban pont az ellentéte van, kapsz pár 14 emeletes toronyházat, amik elvileg mindent tudnak, amiről az alkotójuk azt hitte, hogy tudniuk kell. Vagy megfelel számodra, és akkor halleluja, vagy nem, akkor bukta van. Nem változtathatsz, nem babrálhatsz bele, ez van, ezt kell szeretni.
Egyébként nagyon sok ilyen szoftver van, például az adatbáziskezelőknél is gyakori, hogy van egy nagyobb program, ami a szerverfunkciókat végzi, és vannak kis, parancssori utilityk, amikkel aktiválsz bizonyos funkciókat vagy beállításokat. ezekből rakod össze a megoldásodat.
-
bambano
titán
"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
"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...
-
bambano
titán
válasz
floatr
#10817
üzenetére
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.
-
bambano
titán
válasz
floatr
#10815
üzenetére
"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.
-
bambano
titán
válasz
floatr
#10812
üzenetére
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.
-
bambano
titán
válasz
#68216320
#10806
üzenetére
"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?
-
bambano
titán
válasz
floatr
#10807
üzenetére
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.
-
bambano
titán
válasz
#68216320
#10804
üzenetére
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.
-
#10590
bambano
titán
Aethelstone
#10587
bambano
titán
válasz
Aethelstone
#10587
üzenetére
van adatbázisos megoldásod két program kommunikációjára úgy, hogy az adatbázis nem közös?
-
bambano
titán
válasz
#68216320
#10229
üzenetére
"Nem is várható bővülés": híres utolsó mondatok
a lekérdezés sebessége egyrészt nem számít akkor, amikor elméletben vizsgálsz egy logikai struktúra->tárolási struktúra leképezést, másrészt nem is tudhatod előre, mi a gyorsabb, harmadrészt oldja meg a hardver
szerintem a kód mindenféle részén folyton azt mókolni, hogy most melyik táblát kell joinolni, hova mit írsz, az nagyobb teher, mint berakni egy táblába, indexelni, a többit oldja meg az adatbáziskezelő meg a beszerzési osztály rambevásárló felelőse.
-
bambano
titán
válasz
#68216320
#10217
üzenetére
szerintem meg egy táblát kell csinálni a terméknek, azon mezőkkel, amelyek biztosan mindegyik terméknél előfordulhatnak, meg egy táblát a változó tulajdonságoknak, és abba belerakni az adott termék tulajdonságait. esetleg egy harmadikat tulajdonságtípusnak.
A harmadikba beleraknád, hogy milyen tulajdonságok fordulnak elő (pl. kijelzőméret, hdmi száma), a másodikba meg hogy termek_id,tulajdonsag_id, ertek.
-
#10146
bambano
titán
elektronika5
#10145
bambano
titán
válasz
elektronika5
#10145
üzenetére
A segítség kifejezés azt jelenti, hogy csinálod, és amikor megakadtál, konkrét problémával kapcsolatos konkrét kérdést teszel fel.
A beadandót nem fogják helyetted megírni.
-
bambano
titán
"Ez nem valasz -- ha nem akar hozzajarulni, akkor miert nem rugja ki az OpenJDK-n dolgozo fejlesztoit?": ha elolvastad volna a linket, ilyeneket olvashattál volna benne:
"az Oracle valamikor 2015 második felében de facto leállította a Java EE fejlesztését és a fejlesztőket más, stratégiailag fontosabb projektekre csoportosította át": ez, openjdk szemszögből nézve, egyenértékű a kirúgással."Az a baj, bambano, hogy fogalmad sincs az open source-rol csak hasznalni szeretned, de azt nem erted, hogy mitol mukodik (es mitol nem).": na végre, vala{k,m}i feldobta a napomat. ez legalább olyan súlyos ökörség, mint mikor le-sjw-ztek engem. ha gondolod, tárgyaljuk ki, de ne itt.
-
bambano
titán
"Persze, az Oracle rak bele a legtobb energiat": az oracle java területen jelenleg abba rak a legtöbb energiát, hogy kirázza a nyakából az egész kócerájt.
"Vicces modon az Oracle kozutalatnak orvend az OSS kozossegben, pedig az OSS egyik legfontosabb kontributora a Java miatt.": az oracle ezerrel dolgozik azon, hogy mindent kidobjon, amit a sunnal megvett. azt az egy dolgot meg, amit nem akart kidobni, tönkrevágta. így lett mariadb, így lett a staroffice-ből balhés openoffice/libreoffice fork, így tolta a levesbe az opensolarist. komoly esély van rá, hogy a sparc architektúrát is dobják, aminek a végén semmi nem marad a sunból. csak tudnám, mi a bánatos francnak vették meg...
-
bambano
titán
igen, téves.
az elemi típusoknál, mint ami az int, ha deklarálod, lefoglalódik a helye. az értéke valami lesz, nem tudjuk, hogy inicializálás nélkül mi az értéke (leginkább a korábbi memória használat után ottmaradt szemét), de egy egész számként értelmezhető szám lesz ott.
ezzel szemben az Int-nél (nagybetűvel), a deklaráció eredménye egy pointer, aminek a kezdeti értéke null, és amikor az Int típusú objektumot példányosítod, akkor lesz benne egy olyan pointer, ami az adott példányra mutat és nem null.
ugyanez igaz a Stringre.
-
bambano
titán
előrebocsátom, hogy tomketet nem használtam még...
glassfishben ennek a rossz verziónak az a szép megoldása, hogy a glassfish környezeti változói közé felveszed, hogy hol vannak a képek, és azt lekéred jávából.a helyes megoldás szerintem az, hogy nem a fájlrendszerből veszed ki a képek listáját, hanem amikor a képek odakerülnek, akkor egy adatbázisban adminisztrálod, hogy mi került fel és hova lett lerakva.
-
bambano
titán
ha találgatnom kellene, azt találgatnám, hogy letöltött egy jdk-t, azzal felrakta a netbeanst.
a netbeans belevarrja a konfigba, hogy hol van a jdk. viszont amikor upgradelte a jávát, akkor a régit levette, az új meg máshol van, pláne, ha a verziószám benne van az elérési útban. -
bambano
titán
"ha zavarnak a meglevo bugok, akkor hasznalj mast, de ha nem egy hosszutavo projekt": hosszútávú.
ha nem használok olyan környezetet (nem csak az ide-t ideértve, hanem az összes többi cuccot is), akkor belefuthatok abba, hogy a böngészők már nem képesek megjeleníteni, amit megcsináltam. Mint például a woodstockot nem kezelik az újabb netbeansek."java -jar myApp.jar": most vagy elkerülte a figyelmed, hogy webes cucc lenne, vagy komolyan gondoltad, de akkor vadásszak web konténert, adatbázis kezelő réteget, stb. ? ezt inkább kihagynám.
-
bambano
titán
"Netbeans nem lesz kevesbe hasznalhato attol, hogy kevesbe nepszeru.": ezt értem, csak a kérdés az, lesz-e, aki fejleszti, javítgatja a bugokat. mert a webjükön a release map szerint 2016. vége felé lenni kellett volna 8.2.1-esnek, de nincs. nem jött be az eclipse, de inkább a projekt elején váltanék, mint közben, ha muszáj.
ahhoz, amit csinálni kellene, szerintem nem kell ee.
"Spring vagy Dropwizard eseten nincs szukseg appszerverre, tehat nem kell se Glassfish, se WF.": és akkor min fogom futtatni? eddig glassfisht használtam, nem dobnám ki, ha nincs súlyos ellenérv.
-
bambano
titán
Segítsetek pls. stratégiai döntésben, hátha ti jobban informáltak vagytok
Anno elkezdtem egy programot írni, de félbeszakadt, viszont mostanában szeretném befejezni.
netbeansben fejlesztettem, glassfishben futtatnám. Mivel nem sokat haladtam vele, ha kidobnám az egészet, ebben az állapotában még nem fájna. A kérdések:Ami nem változtatható: debianon fejlesztenék linuxra, adatbáziskezelő postgres, a cucc webes alkalmazás lenne. Amit csak végszükség esetén változtatnék, a nyelv: a java.
1. amennyire én látom, a netbeans meghalt. kérdés:
1a: a netbeans tényleg halott, meneküljek, de akkor mire?
1b: nem, a netbeanben érdemes fejleszteni, mert támogatott cucc lesz még sokáig2. az oracle által átvett projektek közül nagyjából minden fontosabbat megdöglesztett az oracle. kérdés:
2a. maradjak a glassfishnél, mert azt nem fogja megölni, lesz update hozzá
2b. váltsak, de akkor mire? tomcatre? ee cuccokat eddig nem használtam.3. milyen keretrendszert érdemes elsőre megtanulni? springs mvc-t?
Még annyit, hogy nem tervezem, hogy ebből éljek meg. Ha a melóban kell valami, azt megcsinálom, de életcélnak nem választottam.
kösz előre is.
-
#8600
bambano
titán
fordfairlane
#8599
bambano
titán
válasz
fordfairlane
#8599
üzenetére
szerintem nem feltétlenül a sok mag számít, hanem a ram.
nekem semmi bajom a netbeans sebességével. -
bambano
titán
válasz
Amartus
#8596
üzenetére
az oracle azt hitte, hogy hozzá is csapódni fog az open source közösség, mint a sunhoz. ez nem jött be, fizetett erőforrást meg nem hajlandó rászánni. a régi sunos projekteket vagy forkolják, vagy megdöglenek maguktól. utána az oracle áttolja az apacshoz, ahol ugyanez vár rájuk. lásd hudson, openoffice, stb.
-
bambano
titán
"Es kerdes, hogy mondjuk service discoveryt irjunk mi, vagy hasznaljunk software defined networkinget?": helyes válasz: egyrészt elkerüljük, hogy service discovery-re legyen szükség, másrészt ha nem kerülhető el, akkor alap oprendszer cuccokkal oldjuk meg.
"De hiba mindenben van.": így van. vagyis a hibák össz-számát azzal tudod csökkenteni, ha a felhasznált komponensek darabszáma konvergál az elvi minimumhoz.
"A Docker nem tokeletes (sot, bugos fos), csak osszevetettem egy csomo minden massal, es per pillanat ez a kombo oldja meg a problemakat kozeptavon.": bare metállal is összevetetted?
egyébként is a docker meg az openstack környékén épp most tört ki egy orbitális balhé, úgyhogy bajban leszel.
"tehat inkabb human kerdesrol van szo.": lehetett érezni, hogy pebkac van
ha te üzemeltetsz egyedül, akkor nem elosztott csapat. maximum ki kell verekedned a csapatban a téged megillető pozíciót, ami szociológiai probléma. de sokat segít, ha csak nálad van root jelszó, a többi meg max. kibicel.
a service discoveryre visszatérve: ezzel, hogy úgy működik a hálózat, hogy bedobsz egy service-t és azt a többiek majd felfedezik, szemléletbeli problémát látok. ha te felügyeled a teljes lomot, akkor nem discoveryt kell csinálni, hanem leltár alapján beállítani azt, amit felfedezni kellene. ha politikai irányból szabad példát hozni, akkor amit csinálsz, az a szabadversenyes kapitalizmus. elkezdődik egy szolgáltatás, a piac meg vagy észreveszi, vagy nem. amit én javaslok, az a komcsi módszer: központi tervintézet előírja mindenkinek, hogy pontosan mit kell csinálni. ez utóbbi szerintem sokkal egyszerűbb.
a felskálázásról meg az a véleményem, hogyha 1000x teljesítményre kell felskálázni a cuccot, akkor bizonyára van már a plusz lóerőből valamennyi, ami majd ehhez kell. azon a plusz lóerőn kell felépíteni az új rendszert, új szemlélet szerint, nulláról, és nem a régi rendszer farigcsálásával konvergálni valamerre. ha meg nem tudnak pár plusz szervert biztosítani ehhez, akkor ott kell őket hagyni a fenébe.
"Postgres ele olyan interfeszt rakni hogy tudja azt, amit nekunk kell, az sokkal tobb melo.": ha jól láttam, két dologra akarod használni a consult: egyrészt értesüljön a gép, hogy konfig váltás volt, másrészt megkapja a konfigot. mindkettőre triviálisan megfelel a postgres, különösebb fejlesztés nélkül. egyébként sem tudok elképzelni adatbáziskezelő nélkül ilyen projektet, tehát valami már úgyis van alatta. ha nem postgres, akkor mysql, teljesen mindegy, a postgrest csak példának mondtam.
-
bambano
titán
nem ezzel a konkrét rendszerrel van bajom, hanem azokkal az architektekkel, akik úgy terveznek architektúrákat, hogy az üzemeltetés szempontjait nem veszik figyelembe. utána meg a rendszergazdák beleszakadnak, hogy életben tartsák a lomot. az ilyen "összehord a szél nagy halomba egy csomó appot, és üzemeltesd" hozzáállásból hosszabb távon mindig katasztrófa lesz.
tudod, hogy honnan lesz ezekhez a cuccokhoz supportod? elhiszed, hogy most nincs bennük hiba? elhiszed, hogy legalább addig nincs bennük hiba, míg meg nem unod és fel nem mondassz? (attól kezdve MVP: MásValaki Problémája lesz). biztos vagy benne, hogy nem hagyják abba a fejlesztését?
a másik probléma egyes architektekkel, hogy fogalmuk sincs a hálózat működéséről. arról meg pláne, hogy hogyan lehetne ugyanazt sokkal egyszerűbben megoldani.
a unix alapelve: KISS. keep it stupid and simple. ami nem kell, azt hajítsd ki, különben felesleges kockázatot vállalsz.
a magam részéről, ha választanom kellene, hogy consult rakok fel vagy postgrest, a postgres két fényévnyivel győzne. mert postgres lesz. lesz, aki kijavítja a hibáit. lesz hozzá support. consulhoz? weave helyett meg, ha nagyon muszáj, akkor openvpn.
de azt is el lehetne kezdeni firtatni, hogy valójában kell-e docker neked. csak a világ olyan, hogy aki ezt meg meri kérdezni, az eretnek és máglyára vetik.
-
-
bambano
titán
és a node-ok közötti hálózat is támogatja?
nem értem, minek raksz fel egy komplett infrastruktúrát olyan feladatra, amit valószínűleg létező cuccal is meg lehet oldani.például konfig postgresben egy konfig táblában, módosításra trigger, amit figyel az app. adatbázisod nagy valószínűséggel van. vagy dhcp opcióval, esetleg snmp trap-pel is lehet figyelmeztetni.
most arról nem beszéltem, hogy miért nem lehet úgy összerakni az alatta levő infrastruktúrát, hogy ne kelljen érdemi konfig változtatást csinálni. például pont a proxynál valószínűleg lehetne.
-
bambano
titán
válasz
MrSealRD
#8436
üzenetére
tomketet nem használtam még komolyan, de ötletek:
1. próbálj meg verziót váltani. jávából is, konténerből is, liferay-ból is. felfelé is, lefelé is.
2. van, hogy az adatbázis kapcsolat leakel. ha be tudsz állítani olyat, hogy x darab sql utasítás után zárja le az adatbázis kapcsolatot, az segíthet
3a. nekem glassfish-sel van ilyen problémám, ott a session serializációs adatok leakelnek néha, attól áll fejre. megpróbálhatnád azt, hogy egyszer megvárod, amíg teljesen megborul, leállítod, és megnézed, hogy nem hagy-e valami nagy fájlt a vinyón.
3b próbáld meg beállítani, hogy a session-öket x idő után automatikusan bezárja. -
#8298
bambano
titán
kemkriszt98
#8296
bambano
titán
válasz
kemkriszt98
#8296
üzenetére
mik azok a gpx fájlok?
firefox-szal próbáltad már? -
bambano
titán
az isten barma júzer első mozdulattal egy hosszú usernevet vagy jelszót fog beleírni. hosszú alatt tényleg hosszút értek, mondjuk 700 ezer betűből állót.
másodikra ékezetet, szóközt, stb. speciális karaktereket
harmadikra olyan karaktereket, amikkel az adatbáziskezelőt lehet fejreállítani. mindenre van xkcd.ráadásul a találgatások ellen sem ártana védekezni, tehát x darab próbálgatás után lassuló felület vagy kitiltás.
-
bambano
titán
válasz
RexpecT
#8145
üzenetére
ha az üzemeltetés minimális szinten is hozzáértő, akkor nem hagyja, hogy egy olyan gépen buildelődjön a program telepítője, amiről nem tudja, hogy mi van rajta.
tehát minden esetben, amikor a programozó csinálja a telepítőt (nyilván nagyobb projektet feltételezve), ott az üzemeltetés kaszkadőrködik.
ui: láttál már nagyobb halom vírusos telepítőcd-t?
-
-
#8087
bambano
titán
Aethelstone
#8086
bambano
titán
válasz
Aethelstone
#8086
üzenetére
linux. akkor használjam 8.1-es netbeanshez a debian jessie beépített jdk-ját?
$ java -version
java version "1.7.0_85"
OpenJDK Runtime Environment (IcedTea 2.6.1) (7u85-2.6.1-6+deb8u1)
OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode)kösz
-
#8084
bambano
titán
kemkriszt98
#8080
bambano
titán
válasz
kemkriszt98
#8080
üzenetére
én kiválasztanék egy szabvány portot, amit biztosan nem fog használni a szerver, és oda tenném.
pl. hylafax vagy ircd. -
#8077
bambano
titán
kemkriszt98
#8076
bambano
titán
válasz
kemkriszt98
#8076
üzenetére
ha a szervered minden portra figyel, akkor az a szerver egyáltalán nem fog tudni forgalmazni a neten.
a szerver progid miért nem a http porton figyel?
vagy ha ott nem lehet, akkor csinálj bele egy apró programocskát, ami megmondja, hogy hol figyel a szerver progi, ha figyel. -
#8072
bambano
titán
Sk8erPeter
#8071
bambano
titán
válasz
Sk8erPeter
#8071
üzenetére
a valódi kérdés nem az, hogy szerinted vagy szerintem mi a junior, hanem az, hogy aki majd megkérdezi, szerinte mi a junior
szerintem a junior az, akinek adott fejlesztés alatt álló szoftver esetén megmondják, hogy mi a konkrét feladata (írd meg ezt a 32 darab getter/settert) és azt végre tudja hajtani. a következő lépés, amikor már nem csak konkrét feladatokat tud elvégezni, hanem bizonyos fokig önállóan képes fejleszteni a programot, általánosabb feladatmegfogalmazásokat is képes megoldani (csinálni kell egy authentikációs modult, kb. így meg így működjön, ezek a paraméterek, stb.). ez a közepesen átsült szték vagy medium vagy mi...
szerintem nem az a junior, akit egyáltalán nem lehet használni a fejlesztéshez, csak betanul.
-
#8069
bambano
titán
Aethelstone
#8067
bambano
titán
válasz
Aethelstone
#8067
üzenetére
te kínálati oldalról nézed, az nng meg keresleti oldalról fogja nézni.
ahhoz, hogy egyetlen elgépelést ki tudjon javítani egy kommentben, ahhoz kell netbeans, verziókezelő, maven ismeret. ahhoz, hogy readonly módon elkezdhesse érdemben tanulmányozni a kódot, ahhoz kell full java meg ee ismeret is.interjúra egyébként nem árt alaposan átnézni a portáljukat is, meg utánanézni, hogy mi az a connected autó és gps. az állás jó eséllyel a portál mögötti cuccok fejlesztése (ami nem csak a portálmotort és a webshop fejlesztése, hanem egy rakás más cucc is).
-
#8058
bambano
titán
AsterixComic
#8053
bambano
titán
válasz
AsterixComic
#8053
üzenetére
nem teljesen világos számomra, hogy interjúra mész vagy már felvettek és dolgozni.
ha interjúra, akkor arra számíts, hogy bejön Rumcájsz és három másodperc alatt falhoz állít a kérdéseivelnyilván kell, hogy az alap jáva cuccokat szabvány szinten kend-vágd előröl hátra és hátulról előre, de néha alulról felfelé is. továbbá rendesen tudni kell az enterprise java beans cuccokat, mavent, antot, xml-t. ismerni kell a json-t, webservice-k távoli hívását, ldap kezelést jávából. adatbáziskezelőnek postgresql-t. ha nem csalnak az infóim, clusterezett glassfish-t használnak appszervernek és netbeansben fejlesztenek (ez utóbbira csak kisebb összeggel fogadj). van náluk ci.
nem baj, ha mindezt ubuntun vagy debianon.
-
#7939
bambano
titán
Aethelstone
#7923
bambano
titán
válasz
Aethelstone
#7923
üzenetére
miért tomcat?
-
bambano
titán
nagy help kellene nekem
a helyzet: az eddig használt kedvenc fejlesztői eszközeim atom mód elavultak és kimentek a divatból. a másik pontja a helyzetnek, hogy nulláról el kellene kezdenem írni egy alkalmazást.
a kettő következménye, hogy úgy döntöttem, az egész kóceráj megy a kukába, és (majdnem) teljes platformot váltok. a kérdés, hogy mire a felhasználói felület és környéke a segítségkérés tárgya
megváltoztathatatlan feltételek:
- jáva (nyilván, ha ide írok)
- webes kliens szerver cucc
- appszerver glassfish
- netbeansben menjen a fejlesztés.
- aktuális firefoxszal működjönváltoztatható feltételek, álmok:
- ehhez az alkalmazáshoz jó lenne, ha futásidőben változtatható formokat tudnék csinálni.a megálmodott ideális válasz a kérdésemre:
- használj icefaces-t
- használj x.y keretrendszert,
stb.tia
-
bambano
titán
válasz
pinnacle
#7826
üzenetére
linuxon kell a jre-nek, jdk-nak egy JAVA_HOME környezeti változó, ahol megtalálja a többi csatolt részét a jvm. feltételezem, windowson is kell. azért feltételezem, mert azt írtad, ha a desktopra raktad, működött, az pedig az aktuális könyvtár lesz, ezért találja meg ott, amikor máshol meg nem.
-
#7790
bambano
titán
WonderCSabo
#7787
bambano
titán
válasz
WonderCSabo
#7787
üzenetére
persze, mert ha tovább bonyolítanám, akkor kiderülne, hogy egyszer (pl. int) érték szerint átadva rögtön ott van az adat és lehet vele számítást végezni, máskor meg (pl. Integer) érték szerint átadva nincs ott az adat, hogy számítást végezz vele, hanem még kell egy dereferencia is.
ez sok profi szakembert megkavarna
-
bambano
titán
"probalj meg atadni egy referenciat referencia szerint Javaban, nem lehet": következmény: hangsúlyozni, hogy a referencia értékét adjuk át, értelmetlen. további következmény: nem érték szerint van az átadás.
kösz, hogy bizonyítod helyettem az állításomat
mindegy, én nem akarok ebből napokig tartó flame-t, úgyhogy nem erőltetem tovább a témát.
-
#7781
bambano
titán
Sk8erPeter
#7780
bambano
titán
válasz
Sk8erPeter
#7780
üzenetére
ok, tehát a jávában mindig referencia szerinti átadás van, amit ők érték szerinti átadásnak neveznek.
-
#7779
bambano
titán
Oppenheimer
#7776
bambano
titán
válasz
Oppenheimer
#7776
üzenetére
vagyis ha a referenciákat adja át, akkor nem mindig érték szerinti átadás van
-
bambano
titán
-
bambano
titán
glassfish futtatásához elég egy unix account. ha adatbázisból elég a beépített derby (vagy utóda), akkor gyakorlatilag más nem kell hozzá. accot nem kapsz az egyetemen? mert ha nem, akkor bérelned kell egy vps-t, nem túl nagy összeg. vagy meg kell beszélned a témavezetőddel, hogy szerezzen neked futtatási lehetőséget.
a netbeans glassfish támogatása verziófüggő, a régebbiekben nincs, csak tomcat támogatás. de amit a netbeans tomcathez legyárt, az simán megy egy helyesen konfigurált glassfishben. az új netbeansekben van 3-as glassfish támogatás, azokkal még ennyi gond sincs.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Bomba ár! Lenovo ThinkPad T15 G1 - i5-10GEN I 16GB I 256GB SSD I 15,6" FHD Touch I Cam I W11 I Gari!
- Lenovo ThinkPad X13 G2 multitouch
- Bomba ár! HP ProBook 430 G3 - i5-6GEN I 8GB I 256SSD I HDMI I 13,3" HD I Cam I W10 I Garancia!
- Telefon felvásárlás!! Samsung Galaxy A16, Samsung Galaxy A26, Samsung Galaxy A36, Samsung Galaxy A56
- Bomba ár! Lenovo ThinkPad T490s - i7-8GEN I 16GB I 256SSD I 14" WQHD HDR I Cam I W11 I Gari!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged