Új hozzászólás Aktív témák
-
lanszelot
addikt
válasz
bambano
#12146
üzenetére
Hello,
Ezt nem értem. Mi az hogy en local?
Es hol van az en_US.UTF8?
A lokalizációra gondolsz?
Ha igen, Androidban nem így működik.
string.xml -ből kell többet létrehozni, amennyi nyelv van, és létrehozatalnál kiválasztani a nyelv lokalizációt. Ezután a telefon nyelvét ha váltogatod, akkor automatikusan váltja a program nyelvét.
Viszont ha gombbal szeretnéd, akkor meg lehet mondani hogy mely lokalizációval induljon.
Csak itt jön a csavar, hogy erre sincs egy fix módszer, mint ahogy semmire se Androidban, mivel folyamatosan változik, ezért találd ki most épp hogyan kell.
5 projektem van ami mind becsődölt ez a folyamatos "most már ez nem müködik, franc se tudja hogy lehet most" -
#68216320
törölt tag
válasz
bambano
#11786
üzenetére
Nos, a telefonban van scanner, de nem tudom hogyan lehetne okosítani. Azon kívül, hogy megmutatja a dekódolt szöveget és link esetén megnyit egy browsert semmi egyebet nem láttam még benne alapból. Aztán hogy éppen ezen a telefonon valahogy talán össze lehet mégis barkácsolni, hogy custom url-t hívjon, de esetleg egy másikon nem ezért szerintem jobb egy külön app erre.
Az említett leltározó program remek, de idő közben újabb igény merült fel, így magam kell írjak egy egyszerű appot. Szerencsére sok forrást találni a már említett ZXing libre alapozva, ezek lesznek a kiindulási alapok.
ZXing embedded lesz természetesen, hogy ne kelljen külső app a használathoz.
Kotlin-nak nem állok most neki, egyelőre JAVA alapon fogom elkészíteni.
Szóval a kiinduló kérdés itt el is dőlt. -
Drizzt
nagyúr
válasz
bambano
#11597
üzenetére
Pedig tok egyszeru a dolog.
Van kiindulaskor valamennyi(n) darab bucket. A bucketek gyakorlatilag tombok. Tehat van egy n elemu tombod. Minden bucketben van egy linkelt lista, vagy valamilyen annak megfelelo struktura.
A hash fuggvenyen nem modositanak semmit, mivel azt Javaban a user-nek szokas megadnia(oke, altalaban a Lombok irja meg helyette, meg lehet hasznalni a default implementaciot is, de az lehet lassu bizonyos esetekben).Kereses kulcs alapjan:
- Meghivod a kulcsra a .hashCode metodust. Igy kapod az x erteket.
- Kiszamolod , hogy x mod n = z alapjan mi a z.
- A z. bucketet kikeresed(ez egy lepesben megvan).
- A z. bucket osszes elemen vegigiteralsz, s megnezed, hogy a kulcs equals-e az eppen iteralas alatt levo elemmel. Ha igen, akkor az ott szinten eltarolt erteket visszaadod.Mikor lesz ez az egesz lassu?
- Ha a hashCode ugy van megirva, hogy minden kulcs ugyanabba a bucketbe keruljon, vagy legalabbis a bucketek egy kis reszebe. Ilyenkor abban a bucketben egy hosszu lista lesz, ami miatt nem o(1) lesz a lookup, hanem kozeliti az o(n)-et.
Ugyanez akkor is igaz lenne, ha a map-ben levo elemek szama joval nagyobb lenne, mint n. Mit csinal ez ellen a Java? Figyel egy toltottsegi szintet. Ha a toltottsegi szinte egy hataron tul van, akkor fogja, s csinal 2*n uj bucketet, s a meglevo elemeket belerakja, a regi n bucketet meg eldobja.Ebbe a pogramozo is bele tud szolni, van olyan konstruktor, amiben meg tudod adni a kezdeti n-t, s a toltottsegi tenyezot. Szoval ha tudod, hogy rohadt sok elemet fogsz belepakolni, akkor rogton csinalhatsz egy HashMap-et jo nagy n ertekkel, s akkor meguszol par rehash-t. Alapbol 16 bucket lesz, amit akkor ujrahashel, ha legalabb 13-ra no a size. Ekkor 32 bucket lesz, majd ha size legalabb 25 lesz, akkor ujrahashel 64 bucketbe, stb.
A LinkedHashMap az egy specibb valtozat, ahol az egesz HashMap-en tul egy LinkedList is fenn van tartva, ami az osszes elemet tartalmazza a hozzaadas sorrendjeben. Akkor kell hasznalni, ha fontos a hozzaadas sorrendjet tudni.
-
#68216320
törölt tag
válasz
bambano
#11483
üzenetére
De ha bekérem a kulcsot, akkor mindjárt kérhetném az adott jelszót is. Persze több jelszó esetén már kellemesebb a kulcsot megadni és azzal decrypt-álni a többit.
Viszont az alap probléma adott még. A user meg akarja változtatni a property-t kézzel, akkor hogyan tudja beírni a property-be kézzel a titkosított jelszót.
Vagyis példaként:
Egy e-mail küldő konfig fájlban lenne az smtp-host, user, pass, port. Ezeket a user kézzel állítja be a saját adatai alapján. De ugye a pass-t nem adhatja meg csak plain, mert nem biztonságos. Az email küldőt pedig egyéb osztályok hívják, szóval nincs külön indítás ahol megadhatnám a key-t, kiegészítő modul lenne.Mi van olyankor ha úgy csinálnám, hogy a program (ami hívja majd az email osztályt) minden híváskor átadja a használt key-t (mondjuk nem tudom még az honnét jönne létre). Ezzel tudja ugye decrypt-álni a jelszót az email osztály. Viszont lenne egy ellenörzés, hogy amikor plain text a konfig fájlban a jelszó (modjuk éppen szerkesztette az előbb a user), akkor először encrypt-álja és ezután az általános módon beolvassa, decrypt és használja.
Valami hasonló módon csinálja linuxon a transmission-daemon is a config fájlban.
De továbbgondolva a dolgot általános is lehetne a kérdés. Bizonyos esetekben jó lenne SQL-ben tárolt adatoknál is pár olyan értéket titkosítva tárolnom, amit a programom tud írni-olvasni, de ha a user ránéz (akinél fut a programom) ő az sql-ből nem tudja kiolvasni. Ezek olyan dolgok lennének, amikot kénytelen vagyok adni a programmal, de saját, védett adatok lennének viszont kellenek a program működéséhez és alkalmanként távolról frissíteném-bővíteném ezeket.
-
Drizzt
nagyúr
-
Drizzt
nagyúr
válasz
bambano
#10830
üzenetére
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) -
floatr
veterán
válasz
bambano
#10819
üzenetére
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...
-
Drizzt
nagyúr
válasz
bambano
#10823
üzenetére
"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.
-
válasz
bambano
#10823
üzenetére
""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
-
válasz
bambano
#10814
üzenetére
"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ő)?
-
válasz
bambano
#10803
üzenetére
É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.
-
floatr
veterán
válasz
bambano
#10816
üzenetére
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ó.
-
floatr
veterán
válasz
bambano
#10814
üzenetére
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ó. -
floatr
veterán
válasz
bambano
#10808
üzenetére
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ésekEttől függetlenül lehet scriptekkel gányolni
-
#68216320
törölt tag
válasz
bambano
#10805
üzenetére
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?
-
#68216320
törölt tag
válasz
bambano
#10803
üzenetére
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.
-
Drizzt
nagyúr
válasz
bambano
#10590
üzenetére
Miert kene, hogy legyen? Ha tobb alkalmazas irja ugyanazt az adatbazist, az a kaosz fele vezeto ut egyik elso lepcsofoka. Jo persze csak ha ket alkalmazas irja tenyleg, s szigoruan az egyik tablat csak az egyik irhatja, a masikat meg csak a masik, akkor nem lesz gond, de a db nem erre valo. Meg kell oldanod, hogy rajojj mikor jott uj uzenet, olvastak-e az uzenetet, feldolgoztak-e, stb. Onnantol kezdve, hogy ez nem igaz, baj lesz, mert nem lehet tudni ki mifele adatert felelos. Van-e erosebb kutya, vagy mero veletlen ki lesz a source of truth. Meg lehet persze history tablakba bevezetni oszlopot, hogy ki az iro alkalmazas/processz egy adathoz de elegge nyakatekert lesz. En hasznalnek socketet, vagy valamilyen felette levo absztrakciot. Vagy rmi-t. Vagy ha nagy megoldas kell, akkor Kafka, vagy Jms. Vagy persze elhangzott ezer, meg ezer Api, amit amugy tok egyszeru kezelni, pl. Soap, Rest, s kifejezetten erre valok.
-
smallmer
őstag
válasz
bambano
#10322
üzenetére
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.
-
#68216320
törölt tag
válasz
bambano
#10228
üzenetére
Fix számú, jelen esetben 3 fajta termék kategória van. Nem is várható bővülés, max jóval később talán 1-2 legfejjebb. Ez a 3 fajta termékkategória összesen 5 mezőben egyezik és minden egyébben különbözik. Ebben az esetben sem volna kényelmes inkább 3db külön-külön tábla? A lekérdezések gyorsabbak és egyszerűbbek lennének.
-
válasz
bambano
#9985
üzenetére
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). -
Lortech
addikt
válasz
bambano
#9975
üzenetére
"Fizetős lesz a java az Oracle-től": igen.
Nem.
Még úgy sem állja meg a mondat a helyét, hogy a frissítések lesznek fizetősek.
Azzal a kitétellel állja meg a helyét, hogy bizonyos főverziók frissítései és támogatása és bizonyos idő után.
Mondhatná azt is, hogy lófütyit nektek, EOL után nem csinálok frissítést, helyette megpróbál pénzt csinálni belőle. Tetszik nem tetszik, nekem ugyan nem tetszik, de maradjunk a tényeknél egy szakmai topikban, a riogatást, félinformációk terjesztését, térítést meg hagyjuk.szerk: itthagyom, de áthúzom, mert félrevezető. Tévedtem, az állítás a 10-es verzióig bezárólag állja meg a helyét, az Oracle JDK használata a 11-es verziótól kezdve valóban nem ingyenes "üzleti célú" felhasználásra.
-
Lortech
addikt
válasz
bambano
#9848
üzenetére
Jaj istenkém, hát így hívják az exceptiont, béna, inkonzisztens elnevezés. És akkor mivan?
Historikusan (pl. C és társai esetén) mutató típushoz olyan többletjelentést (pointer aritmetika) társítunk, ami Java referenciáknak nincs, ezért szoktuk különválasztani a kettőt. -
Sokimm
senior tag
válasz
bambano
#9832
üzenetére
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?
-
floatr
veterán
válasz
bambano
#9675
üzenetére
Úgy vettem észre, hogy a tech giant-nek mondott cégek kifejezetten menekülnek az oracle dolgai elől. Ha körbenézel IDE fronton, akkor láthatod, hogy minden az eclipse és idea variánsokról szól, de feltörekvőben van a vs code a redhat-es java pluginjével. Sajnos vagy sem, senkit nem érdekel a netbeans, kiszorulóban van.
A szerver témában sokkal árnyaltabb a dolog, de ha már leírtad, hogy nem érdekel az EE, akkor én arra szavaznék, amire a google is letette a voksát: jetty. Nagyon sok fejfájást okozott nálunk a tomcat.
MVC: elég egyértelműen adódik a spring mvc vagy épp a boot. Többek közt amiatt is, mert a megfelelően társított egyéb spring projektekkel tökéletesen együttműködik, és megfelelő frontend technológiával brutálisan gyorsan lehet eredményt elérni.
De mondok még valamit, ami az oracle bohóckodásának köszönhető. Gyakorlatilag az összes nagyobb piaci szereplő elindult Kotlin irányba, pl a spring is. Kisebb projektekben próbálkozunk már vele JVM-re, és úgy látom, hogy át tudja venni a java helyét, és nem csak amiatt, mert licencelés tekintetében meg tudnak szabadulni az oracle marhaságaitól, hanem mert elképesztően hatékony de általános célú is. Itt és itt van két példa, ami talán magyarázza, hogy miért mondom ezt, de lehet h az is elég, ha megnézed a kotlin stdlib lehetőségeit. Nem mellesleg érdemes megnézni a kapcsolódó trendeket. A java fokozatosan veszít a népszerűségűből, miközben a kotlin iránti érdeklődés exponenciálisan nő. Pláne ha az oracle által lesajnált enterspájz fejlesztők rájönnek, hogy nem csak androidhoz jó.
-
RexpecT
addikt
válasz
bambano
#9679
üzenetére
Én nemrég Spring Bootban raktam össze egy mini projektet, amiben egy endpoint egy MySQL adatbázisból ad vissza JSON-ben adatokat. STS-ben egyszerűen és gyorsan lehet fejleszteni, és valóban ahogy fentebb is írták, "java -jar xy.jar" -al lehet futtatni a service-t(Tomcat-et tartalmaz beépítve, de ha akarsz akkor csinálhatsz WAR file-t is).
-
-
-
válasz
bambano
#9675
üzenetére
1: Netbeans nem lesz kevesbe hasznalhato attol, hogy kevesbe nepszeru. Ha az megy, akkor semmi gond nincs azzal, ha azt hasznalod. Ha hosszutavon Java-znal, akkor mondanam, hogy IntelliJ, de az egyik legjobb fejlesztonk a mai napig Netbeanst tol, es ettol meg teljesen jol mukodik minden.
2) Wildfly vagy Wildfly Swarm, ha EE kell
3) Most azt dontsd el, hogy EE vagy sem. Ha nem akarsz EE-t, akkor Spring Boot peldaul (bar szerintem boven tul sok magic van benne), ha nem szereted a tul sok varazslatot, akkor Dropwizard. Spring vagy Dropwizard eseten nincs szukseg appszerverre, tehat nem kell se Glassfish, se WF.
-
válasz
bambano
#8548
üzenetére
> egyébként is a docker meg az openstack környékén épp most tört ki egy orbitális balhé
OpenStack korul, nem a Docker korul. A kettonek sok koze nincs egymashoz.
> a service discoveryre visszatérve:
Tul keves konkretum hangzott el idaig (reszemrol is), tehat errol most ne vitatkozzunk.
> , hogyha 1000x teljesítményre kell felskálázni a cuccot, akkor bizonyára van már a plusz lóerőből valamennyi,
Ha ugy tudsz skalazni, hogy gepeket pakolsz a rendszer ala, az fasza. Nalunk nem ez a helyzet.
-
válasz
bambano
#8546
üzenetére
En uzemeltetek, per pillanat. Marmint ha valami osszefossa magat, akkor nincs mas, aki eletre keltse, csak en. Tehat pont azert vannak ezek, hogy az en eletem egyszerusodjon. Ez van.
> elhiszed, hogy most nincs bennük hiba?
Nem. De hiba mindenben van. Es kerdes, hogy mondjuk service discoveryt irjunk mi, vagy hasznaljunk software defined networkinget? Sajnos a realitas az, hogy ha mi megirjuk, azt joval nehezebb uzemeltetni a bugok miatt, mintha felrakok egy weave-t.
Postgres vs. Consul: almat kortevel. Total mast tud a ketto, de tenyleg. Ha a Hashicorp csodbe megy, akkor a Consult kicserelni masra kb. semmi, de a Postgres ele olyan interfeszt rakni hogy tudja azt, amit nekunk kell, az sokkal tobb melo.
> valójában kell-e docker neked.
O, ezt a kerdest joparszor feltettem magamnak. A Docker nem tokeletes (sot, bugos fos), csak osszevetettem egy csomo minden massal, es per pillanat ez a kombo oldja meg a problemakat kozeptavon.
A helyzet az, hogy a problemaim 90%-a nem technikai jellegu, ergo nem az a kerdes onmagaban, hogy mik a helyes architekturalis elemek technikai szempontbol. Hanem az, hogy a developereket hogy lehet ra megtanitani, meg lehet-e, mennyi ido, etc. etc., tehat inkabb human kerdesrol van szo.
Ha az lenne a kerdes, hogy egy adott appot hogy lehet a leguzembiztosabban deployolni 2016-ban, akkor egyaltalan nem tuti, hogy a Docker lenne ra a jo valasz. Egy legacy rendszer atalakitasanal, durva skalazasnal (1000-szeres terhelesre kell atfabrikalni az egy eleg nagy rendszert kb. 1 ev alatt), massziv feature pressure mellett, elosztott csapatban (cseten tudsz kommunikalni, nagyreszt) -- tok mas problema.
-
válasz
bambano
#8544
üzenetére
Tovabbra is mondom, ez egy irtozatosan gazos architektura evolucioja valami jobb fele. Ezenkivul full remote work, mindennek mennie kell egy dev laptopon is.
A weave epp ezert van: fel tudom loni az egesz rendszert egy laptopon meg egy 10 szerverbol allo clusteren is, az app ugyanugy mukodik teljes egeszeben. Az alternativa mi lenne? DNS-re szukseged van valahogy, vagy nem? Tenyleg erdekel, hogy mi a bajod vele.
-
válasz
bambano
#8542
üzenetére
> például konfig postgresben egy konfig táblában
Igen, ez lehetne, de sajnos mindenfele szabvanyok miatt nem fogunk tudni a fo adatbazisba konfigot irni on demand. Ha meg felrakok egy masik postgrest csak erre, az mar kapasbol sokkal bonyolultabb, mint pl. a Consul (el tudom mondani, hogy miert).
Az alapveto infrastrukturat nem mi menedzseljuk hanem ... 'robotok'. (Ertsd: azt nem sikerult megoldani honapok alatt, hogy egy uj VM-et egy regi VM kulso IP-je moge rakjanak be.)
A node-ok kozotti halozat egyebkent ez: https://www.weave.works/products/weave-net/
-
MrSealRD
veterán
válasz
bambano
#8435
üzenetére
Egy Vmware-es VM-ben MS Server 2008R2-n fut tomcat alkalmazásszerveren. Java 7.
Jelenleg úgy van, hogy a VM-nek van 1x GB RAM-ja. Ezen fut három tomcat...ebből az egyiket kellene vizsgálni. A tomcat úgy van paraméterezve, hogy max 4GB memóriával tud gazdálkodni. (-Xmx)
De elég magas a kihasználtság. Ha jól emlékszem átlagban >80%. Ráadásul ha nem kap restartot egy hétig akkor úgy belassul, hogy 1 usert nem kiszolgálni...nem, hogy több százat.
-
-
-
floatr
veterán
válasz
bambano
#8148
üzenetére
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. -
#8078
kemkriszt98
tag
bambano
#8077
kemkriszt98
tag
válasz
bambano
#8077
üzenetére
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?
-
#8074
Sk8erPeter
nagyúr
bambano
#8072
Sk8erPeter
nagyúr
válasz
bambano
#8072
ü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
"
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. -
#8073
Aethelstone
addikt
bambano
#8072
Aethelstone
addikt
-
#8071
Sk8erPeter
nagyúr
bambano
#8069
Sk8erPeter
nagyúr
válasz
bambano
#8069
üzenetére
"továbbá rendesen tudni kell az enterprise java beans cuccokat, mavent, antot [...] webservice-k távoli hívását, ldap kezelést jávából [...] clusterezett glassfish-t"
Szerintem ezek kiesnek a "junior" fejlesztőtől elvárhatóak köréből, legalábbis normális esetben - ezekkel együtt már inkább "medior" lehetne, vagy mi a búbánatnak szokták ilyenkor hívni. Enterprise JavaBeans cuccok szerintem végképp nem várhatóak el juniortól, akkor inkább hagyják el a "junior" szócskát az állásajánlatból.Azt tartanám én is normálisnak, ha valóban juniort keresnek, amiket Aethelstone kolléga is írt, hogy látsszon, hogy rendesen vágja a Java-alapokat, és van esze a tanuláshoz, tehát összességében egy jó befektetésnek tűnik, aki hosszabb távon behozza az "árát" (amibe a tanulása kerül, tehát hogy lassabb, eleinte kevésbé produktív, de nyilván kevesebb is a fizetése, mint egy régebb óta a cégnél dolgozó emberkének).
-
#8070
Aethelstone
addikt
bambano
#8069
Aethelstone
addikt
válasz
bambano
#8069
üzenetére
Nem értünk egyet. Nem kell ismerni a mavent és az svn/git/akármit. Egyszer elmondják és utána emlékezni kell rá. És kb. minden új Java technológiánál ezt várják el a juniortól....meg ha valamit nem tud, akkor igenis képes legyen emberi idő alatt kiguglizni vagy tudjon érdemben kérdezni.
-
#8059
AsterixComic
csendes tag
bambano
#8058
-
#7923
Aethelstone
addikt
bambano
#7919
Aethelstone
addikt
válasz
bambano
#7919
üzenetére
Nos a tervezett rendszer mélyebb ismerete nélkül.
- Java 1.7 minimum
- Tomcat 7
- Spring Framework (Security, MVC)
- Ha kell ORM, akkor Hibernate
- Kliens oldalon JQuery a dinamikus formkezelés miatt. A JQuery ELVILEG! böngészőfüggetlen.Elsőre ezekből létre lehet hozni egy aránylag könnyűsúlyú cuccot.
-
floatr
veterán
válasz
bambano
#7919
üzenetére
Na majd erre fogsz olyan válaszokat kapni, hogy nem győzöd kapkodni a fejed. Nekem olyan szempontjaim vannak hasonló problémákra, hogy legyenek az egyes rétegek teljesen különválasztva, magyarán ne legyen olyan hibrid megoldás, ami keveri a szerveroldali és kliensoldali technológiát (pl gwt). Legyen egy kliens oldali framework, és egy SOA backend. Nekem a Spring backend és az ExtJS jött be eddig a leginkább. Utóbbit azért használom szívesebben, mert nem dizájnerek találták ki.
Dinamikus formokat saját megoldással raktunk össze, akármilyen technológia is volt a frontenden. Ha a dizájn nem az egyedi brandelés irányába menne el, akkor ennél gyorsabb eszközt nem nagyon találsz. Már nem farokméregetésiből, csak eddig ezt tapasztaltam -
estro
csendes tag
válasz
bambano
#7790
üzenetére
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. -
válasz
bambano
#7779
üzenetére
Nem világos számodra, mi az a referencia szerinti átadás. Az C++ban van például, vagy a C# out és ref paraméterek ilyenek. Ha lenne teferencia szerinti átadás, akkor tudnal swap funkciot implementalni, de nem tudsz. (probalj meg atadni egy referenciat referencia szerint Javaban, nem lehet)
-
#7783
Sk8erPeter
nagyúr
bambano
#7781
Sk8erPeter
nagyúr
válasz
bambano
#7781
üzenetére
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.
-
_kovi_
aktív tag
válasz
bambano
#7757
üzenetére
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?
-
#7698
WonderCSabo
félisten
bambano
#7687
WonderCSabo
félisten
válasz
bambano
#7687
üzenetére
É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.
-
atom44
csendes tag
-
#1091
nyaralasptt
csendes tag
bambano
#1089
nyaralasptt
csendes tag
válasz
bambano
#1089
üzenetére
Ha ennel kicsit konkretabb lennel /mennyi penzbol; lokalis adatbazis kell-e; csak fejlesztogep vagy server is, linux vs. win stb./, akkor konnyebb volna segiteni, viszont par altalanossagot azert leirok:
1. A cpu altalaban nem tul fontos tenyezo java-s fejlesztesben: a 2 mag fontos, hogy ha a JVM vagy az IDE megdoklik, akkor konnyu legyen kiloni es ne kelljen a prioritasokkal jatszani
Szerintem fejleszteni egy kozepes core 2 siman megteszi(~6600). A vinyo alt. nem tud annyi adatot adni a cpu-nak, hogy az ki legyen tomve
2. A vinyo szokott lenni a legproblemasabb resz, foleg EE java eseten a sok XML file miatt + a lokalis db is azt terheli, szoval itt erdemes erositeni. A deployment resz (5-30 perc kozepesebb alkalmazasokra) is foleg a vinyot veszi igenybe.
3.Memo: minel tobb annal jobb, bar egy jvm-mel nem lehet 1 GB-nal tobbet hatekonyan kihasznalni; 2-3 Gb kb. eleg szokott lenniA netbeans-be egyebkent az a legjobb, hogy valamit vagy rogton kiokumlal, vagy soha az eletbe.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Thinkpad T14 Gen2i 14" FHD IPS i5-1135G7 16GB 256GB NVMe IR kam gar
- Eladó használt Gigabyte AMD Radeon HD 6750 videókártya
- ZBook Fury 15 G7 15.6" FHD IPS i7-10850H RTX 3000 32GB 512GB NVMe magyar vbill ujjlolv IR kam gar
- 7DB 60GB SSD eladó kedvező áron
- HP EliteBook 830 G8 i5-11gen//16GB//256SSD//13.3 " FHD Bang&Olufsen hang
- Apple iPhone 13 256GB Kártyafüggetlen, 1Év Garanciával
- Azonnali A320 B350 X370 B450 X470 A520 B550 X570 chipset alaplap felvásárlás személyes/csomagküldés
- AKCIÓ! Épített KomPhone R5 4500 16GB RAM 240GB SSD RX 6500 XT 4GB GAMER PC termékbeszámítással
- KATONAI ÜTÉSÁLLÓ!!! Getac S410 i5-6300u, G3: i5-8365u, G4: i5-1145G7
- BESZÁMÍTÁS! Asus Prime A320M R5 1600 16GB DDR4 512GB SSD GTX 1050 Ti 4GB Rampage SHIVA TT 500W
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest