- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- gerner1
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- sziku69: Fűzzük össze a szavakat :)
- djculture: Az elvileg már senkinek nem kellő HDD-k ára is egekbe emelkedett 4 hónap alatt
- eBay-es kütyük kis pénzért
- Gurulunk, WAZE?!
- Archttila: SMART tesztelés automatizálva: smartctl poller script Zsh-ban, RPi-re
Új hozzászólás Aktív témák
-
Oryctolagus
tag
-
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?
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) -
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.
-
"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.
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.
-
"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...
-
"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.
-
"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...
""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
-
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.
"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ő)?
-
"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.
-
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.
-
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.
-
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.
#10802-ben már volt szó dockerről
-
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.
-
Aethelstone
addikt
-
Aethelstone
addikt
-
az alapvető kérdés, hogy mit akarsz.
1. programozni tanulni.
2. zenét streamelni.
utóbbi esetben feltalálták az apacs webszervert, meg egy csomó http képes médialejátszót.Programozni szeretnék tanulni. Az alapok úgy érzem megvannak, sőt még annál kicsit több is. Most igazából ötletet szeretnék meríteni, esetleg tanácsot kapni, hogy miként induljak neki. Szerver - Kliens kapcsolatig megvagyok. Az is meg van, hogy átküldöm a zenét, csak az a gond, hogy mindenképpen le kell mentenem kliens oldalon, ahhoz hogy le tudjam játszani. Most igazából olyan library-t vagy ötletet keresek amivel megoldható lenne az, hogy ne kelljen lementeni a zenefájlokat kliens oldalon.
-
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.
-
"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.
-
Ez nem valasz -- ha nem akar hozzajarulni, akkor miert nem rugja ki az OpenJDK-n dolgozo fejlesztoit? Nagyon szeretne nem hozzajarulni, de nem sikerul neki?
Az a bajod, hogy a kozossegnek nagyobb szava lesz? Most akkor bambano OSS parti vagy nem?
" The majority of the hundreds of developers building it[1] do it as their day job, and the vast majority of those are employed by Oracle (and others by Red Hat, IBM, Intel and others). Oracle has sponsored OpenJDK for the last 8-9 years, and has now completed open sourcing all of the previously closed bits of the JDK, some dating back to Sun, and some to BEA's JRockit (JFR, now part of OpenJDK 11), not to mention all the new work on the language and JVM including new GCs like ZGC and the new compiler, Graal (I just hope you don't feel too exploited by all this). Companies like Amazon, Netflix, Google, Twitter, Apple and many, many others (some of them have even forked OpenJDK internally) have not contributed significantly, despite depending so heavily on OpenJDK.
So, like it or not, this is the reality of open source. A lot of companies are happy to use it freely but less happy to contribute the significant resources necessary to build it."
Az a baj, bambano, hogy fogalmad sincs az open source-rol
csak hasznalni szeretned, de azt nem erted, hogy mitol mukodik (es mitol nem). -
"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...
-
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.
-
Aethelstone
addikt
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.
-
én arra szoktam tesztelni, hogy null-e vagy sem...
if (info.getProductString()!=null)Köszi, kipróbálom, ha odajutok!
Amúgy lehet, hogy a mutató célja (memória címterület, amiből az info.get.... et kérdeznénk) nem is létezik (nem adtak a gyártók az eszköznek nevet, és emiatt címet se foglaltak le a "névnek"). Tehát hibát dob, mert olyanra mutatok, ami nem is létezik (nem hogy csak null lenne).A string vizsgálat meg lehet logikailag nem egymás melett létező dolgokat (ez==ezzel?) vizsgál, hanem csak bele néz a mutatott területre (ha tud), és kiköp egy választ. Mivel nem tud belenézni, nem is hibának érzékeli, hanem "nem string" üzenettel tér vissza. Ha van lefoglalva terület, és bele tud nézni, és még netalán String is, akkor kiköpi válasznak, hogy true.
Ez a gondolatmenet hülyeség?
-
"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.
-
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.
-
"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.
-
Aethelstone
addikt
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.
-
"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.
-
"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.
-
"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.
-
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.
-
"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.
-
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.
-
-
é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.
-
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. -
kemkriszt98
tag
-
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.
-
-
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?
Ha az üzemeltetés hozzáértő, akkor tudja, hogy melyik gépen mi van, és éppen mi fut
(#8147) RexpecT
Jaja, régebben scriptek halmaza gondoskodott az automatizált telepítésről, frissítésről. Most continuous integration a varázsszó. Projektet eleve így érdemes elkezdeni, mert anélkül mindenki csak szenved vele. -
Aethelstone
addikt
nulláról induló projekt, az a java lesz benne, amit az elkövetkezendő 20 percben ti mondtok
nekem egy hajszállal szimpatikusabb a sunos oracle-s java, mert az telepítéskor nem turkál annyit az alap oprendszerben, mint az openjdk.Linux alatt azt, ami a disztró alap tárolóiban van. Ez az openjdk a debianban. Pont.
-
Aethelstone
addikt
-
kemkriszt98
tag
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.Azt hiszem nem teljesen értem
Azt értem, hogy ne figyeljen minden üres portra.. De akkor melyikre? Eddig random beírtam egy számot . De mi van ha élesben az a port pont foglalt lesz? Ha indításkor választok egy portot akkor honnan tudjam kliens oldalon, hogy melyik portot választottam?
-
Sk8erPeter
nagyúr
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.
"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
"
Ez pont így van."szerintem nem az a junior, akit egyáltalán nem lehet használni a fejlesztéshez, csak betanul."
Én sem ezt írtam, sőt, abszolút nem is gondolom így. Azt írtam, hogy az általad említettek mindegyike viszont nem feltétlenül várható el egy juniortól, illetve hogy kiegészítsem, ezek olyan dolgok, amikbe simán bele lehet tanulni menetközben, ha jól vág az esze a juniornak, és nem ez fogja eldönteni, hogy mennyire jó fejlesztő, hogy van-e ezekben jártassága. Ha meg nem jó az esze, és csak robotkóder, akkor meg úgyis tök mindegy. -
Aethelstone
addikt
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.
-
Sk8erPeter
nagyúr
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).
-
Aethelstone
addikt
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).
-
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.
-
Aethelstone
addikt
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.
Mindezt juniornak?
Kétlem -
AsterixComic
csendes tag
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.
-
Aethelstone
addikt
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
-
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
-
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.
-
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.
-
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
Egy kicsit tényleg zavaró, mert az int az integernek a rövidítése, viszont a javaban az Integer-el egy hivatkozó változót hozunk létre, ami egy objektumra mutat (int objektum vagy mi
), az int pedig egy primitív változó. De mondjuk aki Javat tanul az eljut az tömbökhöz, ott meg általában a tutorialokban leírják, hogy az egy objektum ami objektumokat tárol, ahhoz meg tartozik egy autoboxing folyamat, ha primitíveket akarunk tárolni. -
WonderCSabo
félisten
-
Sk8erPeter
nagyúr
ok, tehát a jávában mindig referencia szerinti átadás van, amit ők érték szerinti átadásnak neveznek.
Igen, jó nagy baromság ezeket kihangsúlyozni, hogy érték szerinti átadás, mert végül is pointert passzolgatunk ilyen alapon, és az eredeti objektumot buzeráljuk, de legalább egy kezdőt tök jól össze lehet zavarni ezzel, és totál nem fogja érteni, hogy most akkor mi van.
-
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.
Nem sajnos nem kapok accountot. A Netbeans-ből újat használunk. Szerinted akkor mi a megoldás?
Hogy miért Swing? Jó kérdés..
Tudom, hogy elavult, de ebből kell most főzni. Felvetődött az MS Azure ahol virtuálisan lehetne futtatni ilyet, de még nem néztem meg. Lehet hogy az is jó lehet?
-
WonderCSabo
félisten
Én is kétfélét használok, HU és US_en, pillanatok alatt lehet váltani. Magyar billentyűzetem van, az angol kiosztást megtanultam rajta. Így a programozás is gyorsan megy az angollal, de tudok ékezetesen is gépelni ide.
De sorry, látom elég nagy offot indítottam el. Én elég jól ismerem mindkét idét, pluginokat is fejlesztettem hozzájuk, mindkettőnek vannak előnyei és hátrányai, azt kell mondjam, teljesen felesleges vitázni rajta.
-
-
nyaralasptt
csendes tag
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Konkrét moderációval kapcsolatos kérdések
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Xbox tulajok OFF topicja
- Elemlámpa, zseblámpa
- Konzol Screenshot
- Battlefield 6
- Nem kell még temetni: 2 éves órajelcsúcsot döntöttek meg Raptor Lake-kel
- Projektor topic
- Milyen videókártyát?
- További aktív témák...
- 24 magos AMD Threadripper alapú munkára kiváló félgép, 128GB RAM-mal
- HP ZBook Fury 15 G7 i7-10850H 32GB 512GB SSD Quadro T2000 4GB FHD HUN bill, szép állapotban eladó
- Eladó MacBook Pro 16,1 2019 CTO
- új 0 km es garanciás lenovo loq rtx 5050 8gb
- Eladó teljesen újszerű karcmentes Samsung Galaxy Watch Ultra
- Apple Watch Ultra 2 49mm Titanium Case Sapphire Glass Karcmentes 91% akkumulátor 2027.04.09-ig garan
- AKCIÓ! Motorola Edge 60 Pro 5G 512GB okostelefon garanciával hibátlan működéssel
- Apple iPhone 16 128GB récezöld
- Sony Alpha 6000 + 16-50mm Black Digitális fényképezőgép
- Újszerű Apple MacBook Air 13.6" - M2, 16GB/256GB - 23 ciklus - 100% akku - Éjfekete -HUN - 3 év gari
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest