Új hozzászólás Aktív témák
-
Drizzt
nagyúr
Hat en siman el tudom kepzelni. 2018-ban egy java fele magas szintu nyelven mire hasznalna az ember 8-as szamrendszert? Ha ilyet latnek, oklendeznek a code smelltol, kiveve ha a problem domain megkivanja.
Megcsinaltam amugy ezt az Oca mockot tegnap este. Nem szamoltam, hogy milyen eredmenyt kaptam, de erosen a kuszob kornyeken billegek erzesre. Ilyen vizsgat amugy van ertelme letenni? Egyik munkatarsam tervezi. Azert kerdem, mert mig pl. Network/security emberek duskalnak a certekben, addig sw. fejlesztoknel talan az eddigi 10 evem alatt egyaltalan nem lattam olyat, aki certtel rendelkezett volna. Leszamitva az agile certeket(cspo, csm).
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Szmeby #10191 üzenetére
Ezzel én is egyetértek, de sajnos állásinterjún kitalálni, hogy ki esik ebbe a kategóriába, elég nehéz feladat. Meg magadról átadni állásinterjún, hogy erre képes vagy, az is hasonlóan nehéz lehet.
De én is ismerek olyat, aki 5 év Java tapasztalattal azt hiszi, hogy a Java nem működik jól, mert két Integer objektum ==-vel összehasonlítva false, pedig ugyanaz az érték van benne...I am having fun staying poor.
-
Drizzt
nagyúr
válasz Lortech #10212 üzenetére
Miért nem simán T a paraméter az első add függvényedben, az interface-ben? Ha azt csinálod, akkor azzal meg tudod akadályozni, hogy a "impl1.add(impraw);" illetve a "impl2.add(impraw);" leforduljon. Persze az impraw.add fogad mindenféle típusú interface-et. Aztán ha type mismatch van, akkor futási időben száll el a
paramEnforcerMatrix.add(paramEnforcerVector); sor.public interface ParamEnforcer<T extends ParamEnforcer<T>> {
void add(T other);
}
class MatrixType implements ParamEnforcer<MatrixType> {
@Override
public void add(MatrixType other) {
}
}
class VectorType implements ParamEnforcer<VectorType> {
@Override
public void add(VectorType other) {
}
}
class Tester {
void test() {
MatrixType matrixType = new MatrixType();
ParamEnforcer paramEnforcerMatrix = matrixType;
VectorType vectorType = new VectorType();
ParamEnforcer paramEnforcerVector = vectorType;
matrixType.add(matrixType);
vectorType.add(vectorType);
paramEnforcerMatrix.add(paramEnforcerVector);
}
}I am having fun staying poor.
-
Drizzt
nagyúr
válasz #68216320 #10217 üzenetére
Teljesen nem olvastam vegig az alabbi linket, de szerintem minden kerdesedre valaszt kapsz belole. A valasz: attol fugg. 3 fo megoldas van: egy tabla az osszes termektipussal. Ezzel lehet a leggyorsabban lekerdezni termektipusokat ativelo modon, de constrainteket not null constrainteket nem tudsz megadni, ha az altipusok egy reszenel kellene, de legalabb egy altipusnal nem. Aztan lehet mindegyik tioust sajat tablaba rakni. Ekkor az osszes tipus lekerdezesehez tobb tablat kell lekerdezni. Aztan van a kozos tabla a kozos mezoknek, majd egyedi altipus mezoknek kulon tablak, amik visszareferalnak a kozos tulajdonsagokat tartalmazo tablara. Itt joinnal lehet lekerdezni az osszes altipus osszes elemet egyszerre. [link]
I am having fun staying poor.
-
Drizzt
nagyúr
válasz #68216320 #10229 üzenetére
Még egy aspektust akarok felvetni. Milyen táblákhoz kapcsolódik a termék még? Ha van olyan, ami termék ID-t használ, akkor innentől kezdve abban a táblában ha akarsz foreign key-t használni, akkor kénytelen leszel 3 különféle oszlopot felvenni. (Utóbbit mondjuk úgy is ki lehet küszöbölni, ha minden 1:1, 1:n kapcsolatot is kapcsolótáblával valósítasz meg, mintha n:n lenne, mert ilyenkor a foreign key a kapcsolótáblába kerül át.)
Másik dolog amit fontolj meg, hogy érdemes lehet Flywayt, vagy Liquibase-et használni, ami jelentősen meg tudja könnyíteni az életed, ha később mégis kell változtatni az adattáblák struktúráján, s ilyenkor a meglevő rendszerek update-elése automata kell, hogy legyen.
[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
válasz axioma #10244 üzenetére
Alapvetően probléma nincsen vele, de én inkább csinálnék egy másik mátrix típust(Matrix), ami teljesen a ProjMatrix implementációitól. És akkor nem lenne generikus a ProjMatrix interface, a getUnderlying helyett meg lenne egy Matrix getMatrix. És az egyes implementációknak lenne az az implementation detail-je, hogy a belső saját mátrixából hogyan fog mátrixot csinálni, factory-kal, különböző bemenő adatok alapján. Pl.: lenne egy ilyen a Matrix createMatrix(double[][] mtx), illetve valami más értelmes adat. A konstruálás paramétereit mindig az vezényelje, hogy milyen adataid lesznek ahol felhasználod ezt az interface-et.
Működni tökéletesen működni fog amit csináltál, viszont az nem fog nekem tetszeni, hogy a felhasználó kódnak végül mindenképpen tudnia kell a konkrét implementáló osztályokról, mert van olyan method az interface-ben, ami implementáció specifikus értéket vár/ad vissza. Így nem tudod pl.: ServiceLoaderrel betölteni az implementációkat, hanem minden új implementációnál újra kell majd fordítanod a kódot. Ami nem feltétlenül probléma, de egy megfontolandó dolog.
Ami sérül ebben az interface-ben, az a SOLID design elvekben a "dependency inversion principle". Nem jó practice, ha az interface felhasználója bármilyen specifikus dolgot kell tudjon az implementációból(esetedben az M típust).
[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
válasz XP NINJA #10291 üzenetére
Akkor vagy szed le egy böngésző segítségével a weboldal SSL certjét és importáld be keytool-lal a cacerts-be, vagy kapcsold ki az SSL tanúsítvány ellenőrzést. Ez a link meg azt mutatja meg, hogy hogyan tudod a saját SSL validatort összeilleszteni a FileUtils adott függvényével.
A cacerts-es importra elsőre nekem ez a kis bash utility tetszik: [link]. Persze ez Windowson nem fog menni, hacsak nincs minGw-d(esetleg git bash/ git for windows, aminek szintén a része).
[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
Most hétvégi Java önképzésem részeként ezt a videot(GoF patterns in functional light) néztem végig. Szerintem elég tanulságos volt, úgyhogy aki még nem látta, vagy nem játszadozott ebben a témakörben, annak szerintem jó móka lehet. Ha más nem, az olasz akcentus szokására is jó.
I am having fun staying poor.
-
Drizzt
nagyúr
Most először írok annotation processort. Elsőre nem túl intuitív a dolog, nagyon szokatlanok az Elementek, meg a Type-ok. Olyanok leellenőrzése, hogy valamelyik annotált method enclosing osztálya implementál-e egy interface-et, eléggé nyakatekerten és indirekten megoldhatónak tűnik(Stringre konvertálás és annak az equals-e).
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Aethelstone #10308 üzenetére
Runtime reflectionnel a feldolgozasa, meg Beandescriptor/Introspectorral az mar nagyuzemben megy, de a compile time osztaly generalas AbstactProcessor extendalassal az meg ujdonsag nekem. De hat nagyon elirigyeltem a Jaxb-tol meg a JPA-tol a metadata definialast annotaciokkal. Most kb. ahhoz hasonlot csinalok, mint amit a JPA modelgen csinal az Entity metamodel generalasakor. A zavart pont az okozza, hogy compile time a reflectionnel nem lehet kb. semmit cainalni, hanem AnnotatedConstruct, Element, meg Type, TypeMirror es tarsaik allnak rendelkezesre.
I am having fun staying poor.
-
Drizzt
nagyúr
Kérdés:
Használok bean validationt. Ebben CDI injectionnel Eventet is használok, amivel megszerzek felsőbb rétegtől adatokat, amit a validáció során fel akarok használni. Persze a teszt esetén az injektált event null lesz, meg amit az event handler által meg akarok kapni, az se lesz kitöltve, teljesen jogosan. Junit 4.12-nél valamilyen módon meg tudom-e egy ConstraintValidatornak a dependenciáit adni? Nem tudom hogyan szedi össze a Hibernate validator a ConstraintValidatorokat(felteszem annotation processorral, vagy runtime package scanninggel). Illetve hogy ebbe a procedúrába bele tudok-e nyúlni. Hmm. elsőre úgy tűnik az unwrap alkalmas lehet erre, de ki kell próbálni.
I am having fun staying poor.
-
Drizzt
nagyúr
-
Drizzt
nagyúr
Én ugyan nem értek az AWT-hez, de az hogyan találja ki up, vagy down arrow lenyomásra, hogy fel, vagy le kell állítania az aktuális sort?
A handler amit írtál, mindenképpen beállítja a textet a kijelölt sor alapján. De mi állítja be a kijelölt sort? Van valami az AWT-ben ami automatikusan állítja a sor billentyű lenyomásra? Ebben az esetben valamilyen olyan listenert kellene meghívni ami biztosan a selection megváltozása után lesz meghívva.I am having fun staying poor.
-
Drizzt
nagyúr
válasz Orionk #10365 üzenetére
Egyfelől van SQL topic, ez oda jobban illene.
Másfelől:
- Indexeket kell használni. Azt az oszlopot kell indexelni, ami a where feltételben szerepel elsősorban. Ebből is elsősorban azok lesznek gyorsak, amikor konkrét értékre vonatkozik a feltétel, vagy arra, hogy egy érték egy tartományban van-e. Ha több oszlop is van a keresésben, lehet kompozit indexeket definiálni. Ha pl.: van a,b,c oszlopra egy indexed, azt az olyan feltételekre lehet használni, ahol vagy csak a-ra, vagy a-ra és b-re, vagy a-ra, b-re, s c-re van megszorító feltétel megadva. Az index gyorsítja a keresést, de lassítja a beszúrást, törlést. Ezen kívül még fontos, hogy ha csak az indexben szereplő dolgokat fogsz kikeresni a select-tel, akkor az szinte biztosan csak memóriában fog történni, de a többi mező lekérdezéséhez már lehet a diszkhez kell fordulni, ami lassítani fog erősen. Másik megfontolás a select oszlopok számánál, hogy minden extra oszlop megnöveli a visszaadott adathalmaz méretét, emiatt ha a sávszélesség probléma az adatbázis és az alkalmazás szerver között, akkor ronthat a sebességen. Erre szoktak DTO-kat használni(olyan objektum, ami csak a teljese tábla oszlopainak egy részét tartalmazza. Azt, amire éppen minimálisan szükség van az adott probléma megoldásához.).
- Nem árt megnézni azt sem, hogy a lekérdezés tényleg fogja-e használni az elkészített indexet. Erre általában adatbázisonként különbözik, hogy milyen paranccsal, de le lehet kérdezni, hogy mi lesz a query excution plan. Abból kiderül, hogy fog-e használni indexet, vagy nem. Illetve melyiket. A kritikus lekérdezésekre szerintem mindig ellenőrizni kell.
- Ha gyakran használ az ember joint, akkor érdemes lehet elgondolkodni a joinolt tábla foreign key-ként használt oszlopának indexelésén. Ez nagyban felgyorsíthatja a join-ok sebességét.
- Ha a beszúrás és a törlés is nagyon gyakran történik meg és a tábla nagy, akkor érdemes lehet particionálni a táblát több részre. Mondjuk ha neveket tárolsz, akkor az egyik tabla csak a-b, a másik c-d, ... kezdetű neveket tartalmazza. Viszont ilyenkor pl. nehéz lesz jó foreign keyeket definálni a nevekre, s sok egyéb komplikáció előjöhet. Ha ilyen jellegű a probléma, akkor lehet érdemesebb valamilyen noSQL db-t választani RDBMS helyett.I am having fun staying poor.
-
Drizzt
nagyúr
válasz #68216320 #10411 üzenetére
Szerintem határozottan nem érdemes nulláról SE-vel elkezdeni megírni. Hiszen éppen ez lenne a Spring, meg az EE lényege: ne kelljen feltalálni a spanyolviaszt, s lehessen a business logic-ra fókuszálni.
Szerintem érdemes mindkettőhöz amúgy valamilyen maven archetype-ból kiindulni. Vannak pl.: egyszerű REST + EJB + JPA skeletonok, azokat már elég jól testre lehet szabni és kibővíteni, mégis faék egyszerűek.
[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
válasz #68216320 #10428 üzenetére
Ha külön vannak, akkor mindenképpen nyered:
- Az egyes komponensek fordítása jóval gyorsabb lesz.
- Kisebbek, célszerűen jobban értelmezhetők lesznek a komponensek.
Hátrány:
- A verziószámokkal komoly kavarodást lehet összehozni. Bár ha követi az ember a semver szabályait, akkor igazából nem kéne, de én azt tapasztalom, hogy mégis nagyon nehéz eldönteniük embereknek, hogy mikor melyik verziószámot kellene léptetniük.Extrémebb eset, ha kiszervezed teljesen független alkalmazásokba a modulokat, amik különféle API-kal kommunikálnak. Előny:
- Lehet skálázni csak azt a komponenst, amit kell.
- Lehet heterogén az architektúra.
Hátrány:
- Amint valami kimegy a hálózatra, fel kell arra készülni, hogy a kommunikációval bajok lesznek. Timeout-ok, elveszett üzenetek, duplikált üzenetek.Még lehet message bus architektúrát is alkalmazni. Ez olyan, mint az utóbbi, de az üzenetek tárolása, küldése, etc. nem a saját alkalmazásod feladata, hanem egy message bus-é. Mint pl.: a Kafka, vagy JMS.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz harylmu #10441 üzenetére
Picit kötekedés, de definíció szerint O(n*28) = O(n), lásd. Meg a HashSet.contains se feltétlenül egy lépsben talál eredményt, az függ a capacity-től, a load factortól és a hash kiszámításának komplexitásától. De Stringnél az cache-elve van, szóval csak mem lookup.
I am having fun staying poor.
-
Drizzt
nagyúr
Connection pool beállításokról van itt egy adag, de elég régi verzióhoz.
Ezen kívül ami gyanús lehet még, hogy esetleg az alkalmazásban nincsenek a kapcsolatok felszabadítva használat után. Hogyan szerzel EntityManagert, hogyan commitolsz, hívsz-e rá close-t? Valahogy injektálod, vagy EntityManagerFactory-val készítesz? Utóbbi esetben elvileg mindig kell close-olni.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz #68216320 #10493 üzenetére
Szerintem a legérdemesebb beszerezni valamelyik beginner Udemys Spring traininget. Általában nagyon szájbarágósak és a végletekig praktikusak. Ha szerencséd van, olyan helyed dolgozol, hogy van ingyen access. Ha nem, akkor érdemes kinézni valamelyik akciósat és rákölteni vagy 10-20 eurót. Szerintem ezerszer könnyebb megérteni egy ilyenből, mint könyvekből, vagy írott tutorialokból.
I am having fun staying poor.
-
Drizzt
nagyúr
Arra van-e valamifele library, ami valamilyen jsonban megadott filter/sort kriteriumokat kozvetlen Jpa criteria queryve tudna alakitani? Igazabol a formatum annyira nem is fontos, felolem lehet akar QueryParammal, vagy PathParammal. Irni tudnek, de ha van, akkor nem szeretnek ezzel foglalatoskodni. Viszont nem talalok ra hirtelen jo keresofeltetelt a guglihoz.
I am having fun staying poor.
-
Drizzt
nagyúr
Ebből sajnos úgy tűnik, hogy éppen nem érted az OOP lényegét, de majd idővel az is eljön.
Én az öröklésből elsőre a polimorfizmust emelném ki. Van például egy Alakzat osztályod. Ebben van egy teruletSzamitas metódus. Van két Alakzatod, Kor és Negyzet. Kor és Negyzet nyilván teljesen máshogy számítja ki a területét, más belső tényezők alapján. De mindkettőben közös, hogy rendelkeznek területtel, és neked ha van egy raklapnyi Alakzatod, egyszerűbb dolgod van, ha mindegyik objektum megmondja magáról, hogy az ő területe mennyi. Persze itt is megcsinálhatod, hogy valamilyen típus változóban elrakod az Alakzat típusát, és ez alapján döntöd el a területszámító függvényben, hogy mit kell tenni. De ez hosszú távon teljesen fenntarthatatlan lesz. Ugyanis ha hozzáadsz egy új Alakzatot, 99%, hogy nem fogod megkeresni az összes if-et, ami Alakzatokat kezel, s el fog romlani a programod. Míg ha a teruletSzamitas abstract metódus, vagy interface-ben van megadva, akkor amint létrehozol egy újfajta Alakzatot, kötelező lesz megadnod a teruletSzamitas fuggveny implementaciojat. Másik probléma: hogyan kezeled azt, hogy egy Kor átmérővel rendelkezik, de egy Negyzet pedig oldal hosszúsággal? Mondhatod, hogy van egy változód, ami vagy az egyik, vagy a másik dolgot reprezentálja. Viszont ha bevezetsz egy téglalapot, akkor már nem lesz elég egy oldal, kettő kell. Ilyenkor mit csinálsz? Ha az Alakzatokban csak az a közös, hogy van számítható területük, akkor nem kell ezzel foglalkoznod. Minden osztályod csak annyit fog magából megmutatni a külvilágnak, ami feltétlenül szükséges.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Ablakos #10571 üzenetére
Nem talalja a hivatkozott osztalyt. Vagy nincs a classpathon, vagy meg azt is irjak, hogy JAVA_HOME nem jdk-ra allitasar okozhatja. Mavenben milyen scopepal van a dependencia?
Megprobalod az itteni nyitoposzt aljan levo pontos verzioszammal is a derbyt? [link]
I am having fun staying poor.
-
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.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz E.Kaufmann #10595 üzenetére
Definiald pontosan mit ertesz a tobben alatt, illetve hogy azon tobbek kozul mennyinek van irasi, olvasasi, irasi es olvasasi joga. Es hogy melyik az a legtobb ERP rendszer.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz bandi0000 #10642 üzenetére
Sokféle megoldás van. Talán az egyik legegyszerűbb, hogyha van egy közös objektum, aminek van egy synchronized metódusa. Ennek a metódusnak kellene csinálnia azt a tevékenységet, amit nem szabad párhuzamosan elvégezni.
Vagy használhatsz pl. [link] ReentrantLockot. Ilyenkor ha valamit exklúzív akarsz csinálni, előtte lock, aztán unlock.
Ez a cikk elsőre jó gyorstalpalónak tűnik, bár nem olvastam végig. [link]I am having fun staying poor.
-
Drizzt
nagyúr
Ezzel az állítással alapvetően nem értek egyet. Mert az ExecutorService egy interface, ami arra van, hogy taszkokat lehessen aszinkron módon futtatni. De alapvetően arra semmilyen garancia nincs, hogy milyen sorrendben fussanak azok a taszkok le, illetve hogy melyek ne fussanak egyszerre. Ha az ember single threaded executort használ, az már valóban megoldást adhat a problémára, mint ahogy itt van rá példa. [link]
De önmagában az ExecutorService interface semmit nem mond a mutual exclusivity-ről. Épp az az interface célja, hogy a taszkok feladását ütemezés független módon engedélyezze.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Taoharcos #10656 üzenetére
Hát ha nem példányosítod, akkor null lesz. Az egy jogosabb kérdés lenne, hogy mi a fene szükség van rá egyáltalán, hogy ott legyen az a static variable, mert a felhasználási módja nem indokolja a jelenlétét. De a többiek már úgyis leírták.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Orionk #10725 üzenetére
Tömör, egy felelőssége van, se többet, se kevesebbet nem csinál mint ami a célja. Magas a koherencia a az adattagok és a metódusok között, meg az összes SOLID principle felsorolása, kifejtése, 1-2 design patternen keresztüli elmagyarázása. Én ezt várnám el egy interjúzótól. Bár juniortól lehet nem ilyet kérdeznék, hanem inkább alapvetőbb algoritmus kérdéseket, adatstruktúrákat.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz M_AND_Ms #10734 üzenetére
Nem, én ezt rendkívül fontos dolognak tartom. Ha ez nincs végig az ember fejében, amikor kódol, akkor jó eséllyel gányolt minőséget fog kiadni. Az meg most, hogy konkrétan a SOLID betűit feloldja-e valaki, vagy a lényegét elmondja a mozaikszónak, igazából mindegy, de számomra mozaikszót megjegyezni és felidézni sokkal egyszerűbb, mint bármi más módszer.
Juniortól nem ezt kérdezném, mert szinte biztos, hogy nem fogja tudni. Ott nyomatnám az egyszerűbb adatstruktúrák kérdéseit. Senior szinten viszont szerintem ez alapelvárás, akármikor.
I am having fun staying poor.
-
Drizzt
nagyúr
Persze hogy nem. De az mas kerdes, hogy erdemes-e, illetve miert. Az esetek nagy tobbsegeben akkor is kell refaktoralni, ha amugy a kod jo. Pl. ha jon valami olyan uj feature, vagy meglevo modositasa, ami a refaktoralas eredmenyekeppen sokkal egyszerubb lesz, dinamikusabb, kivulrol konfiguralhato, vagy neha epp fixebb, merevebb. Nem veletlenul van tele a refaktoring katalogus olyan lepesekkel, aminek az inverze is benne van. Az egesz refaktoring az agilehoz hasonloan azert terjedt el es lett fontos modszer, mert az it ipar rajott, hogy feature stability szinte semmilyen realis szoftverfejlesztesi projektben nincs.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz bandi0000 #10788 üzenetére
Ja, a Java EE egy framework. Egy jó nagy adag specifikáció halmaz, amit különféle app szervereknek kell implementálnia, hogy Java EE compliant-ek legyenek. Régen elég kínszenvedés volt a Java EE, orrba-szájba kellett örökölgetni mindenféle framework classból. Viszont idővel megjelent az annotation based configuration, elkezdtek egyre szeparáltabbak és önmagukban is életképesek lenni a komponensek. Így ma szerintem egyébként egy nagyon jó framework a Java EE, de tény, hogy a Spring mellett nem valószínű, hogy hosszú távon túlélő lesz. Én nem örülnék neki, ha eltűnne. De ennek főleg az az oka, hogy jelenleg ebben vagyok a leginkább otthon. Springet még csak tanulom. Illetve most főleg Kubernetest, meg Helmet, mert most épp az kell a melóban, de igyekszem visszanyergelni a java-ra.
Szóval az hátránya a Java EE-nek, hogy heavyweight runtime környezet kell hozzá, de ebben is fejlődik.
De érdekes, pl. szerintem a CDI event handling sokkal szebb, mint a Springes.
[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
válasz #68216320 #10800 üzenetére
A Linuxos program időzített futtatására használj cront, vagy egyszerűen írj egy bash scriptet, ami tight loopban vár. A kimenetet meg simán irányítsd bele egy fájlba. A Java programban ugyanezt a fájlt nyisd meg ugyanilyen időközönként. Aztán dolgozd fel, s írd ki adatbázisba. Amúgy ahogy az adatod jellegét nézem, kb. egy time series database-ben lenne a legjobb őket tárolni. Erre jó pl. Influxdb. Aztán csinálhatsz rá mindenféle fancy ábrát Grafanával.
Parse-olni ezt egyébként elég egyszerű, soronként végigolvasod, majd line.split("."), a három elemű tömböt meg felhasználod ahogy akarod..
Más: Mi a legjobb, legmélyebb Spring video course amivel találkoztatok? Kéne nekem egy masszívabb. Ha csak fizetős van, az se gond. De örülnék, ha legalább 20 óra körüli lenne és nagyon a részletekbe menő.
I am having fun staying poor.
-
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.
I am having fun staying poor.
-
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)I am having fun staying poor.
-
Drizzt
nagyúr
Ez szerintem egy elég nehezen érthető része a javanak. De a lényeg. Van a Komparator osztályod. Ezen az osztályon belül van egy inner classod, a KutyaRend. Ilyenkor a kutyarend osztály mivel nem static, ezért a példánya csak egy adott objektumpéldányon belül hozható létre. A static method nem példányhoz, hanem osztályhoz tartozik, így annak nincsen példánya, tehát nincsen benne KutyaRend létrehozási lehetőség sem. Legkönnyebben ezt itt úgy tudod megoldani, ha a Kutyarend osztályt statická teszed:
static class Kutyarend ...De ettől sokkal szebb, ha nem ágyazod be az osztályba semmilyen módon, hanem külön osztályba teszed. Sőt, ha ez a kutyák természetes rendezése, akkor elég a Kutyákat implements Comaparble<Kutyák> módon megadni, s akkor benne a compareTo-t implementálni.
Még egyszerűbb, ha használod a Java 8-as Comparators.comparing-et, így:
Collections.sort(KutyaLista, Comparators.comparing(Kutyak::getKor));
[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
Bulizhatz rekurzioval: az utolso else agban meghivhatod a kaloriaKiirt megegyszer.
Bulizhatsz do-while ciklussal: do... while (beolvasott szo nem gyumolcs).Amugy van sok furcsasag a kododban. Lehet csak a tableten nem latom, de mi szukseged van a File f parameterre? Mi a gyum, honnan jon az extended for loop elott. Van egy static String gyumod az osztalyban valamilyen ertekkel?
I am having fun staying poor.
-
Drizzt
nagyúr
És? Aki a Java9-es könyvet írta amit olvasol, azt mondta, hogy clean code enthusiast? Vagy honnan jön a tudathasadás feltételezés? Van aki követi, van aki nem. Nem szeretem a kommenteket, de néha van haszna. Főleg ha valamit úgy írsz meg, hogy elüt a best practice-ről, de van valamilyen jól megfogható oka, hogy miért van mégis úgy. Én nagyjából követem az elveket, bár a refactoring könyveket sokkal jobban és hasznosabbnak tartom.
I am having fun staying poor.
-
Drizzt
nagyúr
"Some comments are necessary or beneficial. We’ll look at a few that I consider worthy of the bits they consume." Tehát kommentet írni bizonyos esetekben és és jogos. Javadoc meg akkor igazán fontos, hogyha egy library API-ját írja le. Mivel akkor az konkrétan inkább dokumentáció, mint komment.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz ReSeTer #10871 üzenetére
[]: tömb. {ertek1, ertek2, ...}: tömb elemeket leíró literál. A lényeg, hogy több értéket felsorolhatnál, ami String és a tömbben akarod eltárolni.
Az említett könyvet nem ismerem. Totál alap Java könyvet nem is tudnék ajánlani. Inkább Java alap videokat néznék. Pl. totál kezdő szinten van a Udemy-n a Java masterclass. Az talán már 100 óránál is hosszabb, nagyon sok dologra kitér, teljesen az alapoktól kezdve. Bár angol és fizetős.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz fatal` #10881 üzenetére
"Az == a referenciát ellenőrzi, az pedig sosem lesz ugyanaz." Ez így nem teljesen igaz. Pl. ha ugyanarra a String literalra hivatkozol, akkor a referncia is ugyanaz lesz, mert a fordító észreveszi, hogy több referencia van ugyanarra a stringre már fordítási időben, így nem fogja kétszer ugyanazt a konstants elrakni a memória megfelelő szegmensébe.
I am having fun staying poor.
-
Drizzt
nagyúr
-
Drizzt
nagyúr
válasz togvau #10905 üzenetére
A streammel nincs baj, az Arrays.asListet használod rosszul. Az listát csinál a megadott tömb elemeiből. Jelen esetben egy egy elemű listád lesz, aminek az az egy eleme egy int[] lesz.
int[] ints = new int[]{0, 1, 2, 3};
Arrays.asList(ints).stream().forEach(System.out::println);
Arrays.asList(1, 2, 3).stream().forEach(System.out::println);
Arrays.stream(ints).forEach(System.out::println);
Eredménye:
[I@1218025c
1
2
3
01
2
3
I am having fun staying poor.
-
Drizzt
nagyúr
válasz floatr #10941 üzenetére
Szerintem teljesen mindegy milyen szemmel nézed, a lényeg, hogy a developernek a lehető legkényelmesebb legyen a fejlesztés, annak az összes aspektusával, különös fókuszt téve a debuggingra, a build/deploy sebességre, stb. Milyen olyan pipeline-t tudsz mondani, ami lokálisan gyorsabb, egyszerűbb, szükség esetén gyorsabban testre szabható, mintha közvetlen a gépeden fut az app server, vagy a Spring boot app? Ha csinálsz egy dockerben levő Java EE szervert, akkor ahhoz, hogy oda deployolj, ott debugolj szintén kell ultimate edition. Ha egy app server image-ből kiindulsz dockerfile-ban, és mellé rakod az alkalmazásod a buildnél, az lassabb és körlülményesebb lesz jóval. Sajnos a "jó" devops pipeline-nak gyakran az a vége, hogy az emberek csak deploy + println-nel tudnak debuggolni.
Egyébként a legjobb debugging tool meg szerintem a unit teszt, két okból is: gyors, olcsó, és ha sikerül megfejteni a hibát, automatikusan van rá regression teszt. Csak sajnos nem mindig elég a hibához a unit test.
(#10940) mobal: Ok, de a kérdés kimondottan JEE volt. Egyébként a Springes véleményeddel is vitára kelnék. Munkahelyen ultimate-et használok, itthon CE-t.Az ultimate-ben sokkal több infót kapsz. Pl. autowiringnél már ki szokta jelezni, ha nincs autowire candidate, vagy több is van, s kéne qualifier. application.properties szerkesztése közben az éppen elérhető property-t felkínálja dokumentációstul. Van JPA support. És ezek most csak ilyen hasraütésszerű dolgok, lehetne még találni bőven különbséget. Meg így is vannak amik hiányoznak ultimate-ből is. Pl. custom autoconfigurable bean-ek felismerése autowiringnél, etc.
I am having fun staying poor.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen