Hirdetés
Új hozzászólás Aktív témák
-
floatr
veterán
válasz
urandom0
#12165
üzenetére
Bár nem vagyok képben go és rust tekintetében, de a kotlin support kimagasló a java ökoszisztémában. Az architektek/tech leadek húzzák a szájukat, az ügyfelek nem is hallottak róla, a középvezetők meg találnak rá indokot. Aztán fejest ugranak valami eszement frameworkbe, amit ugyanúgy senki nem tud használni...
Igazából csak amiatt bosszant a dolog, mert egy generációs ugrás lenne, de marad inkább a "bevált" getterszetter-lombokotsehasználj-jóvanazúgy megoldás, örül az ember ha eljutottak már java 11-ig -
#12164
floatr
veterán
Aethelstone
#12163
floatr
veterán
válasz
Aethelstone
#12163
üzenetére
Csináltam egy kis "piackutatást" állásinterjúkon. Azért nem használnak kotlint, mert kevés a fejlesztő, azért kevés a fejlesztő, mert nem használnak kotlint
-
#12162
floatr
veterán
Aethelstone
#12160
floatr
veterán
válasz
Aethelstone
#12160
üzenetére
Kotlint kell használni, az még tutibb
-
floatr
veterán
válasz
Tothg86
#12059
üzenetére
Valahogy így:
@Embeddable
public class AccountId {
private String accountNumber;
private String accountType;
...
}
@Entity
public class Account {
@EmbeddedId
@AttributeOverrides({
@AttributeOverride(name="accountNumber", column=@Column(name="account_number")),
@AttributeOverride(name="accountType", column=@Column(name="account_type"))
})
private AccountId id;
...
}az @AttributeOverrides szekciót azért tettem bele, mert ezzel pontosan el tudod nevezni a DB mezőket. A hibernatenek van olyan NamingStrategy-je (jpa/component-path), hogy hajlamos elécsapni a generált neveknek prefixként azt, hogy "id_"
[ Szerkesztve ]
-
floatr
veterán
válasz
Tothg86
#12057
üzenetére
Ebben a cikkben leírnak két lehetőséget, de én is használok több munkahelyi projekten összetett kulcsot. Az EmbeddedId-t javaslom, de pár dolgot nem árt észben tartani.
Az ID-t így te adod meg, nem a hibernate generálja. Emiatt egy új rekord mentésénél (save/saveOrUpdate) a hibernate egy selectet fog kiadni, hogy leellenőrizze, van-e már azzal a kulccsal adat a DB-ben. Ezt ki lehet kerülni mondjuk egy EntityManager.persist(...) hívással egy custom repo implementációban, ha te tudod garantálni a PK egyediségét. Ha sok adatot importálsz, problémát tud okozni.
Az ilyen táblák általában kapcsoló/kapcsolatleíró táblák, és az összetett kulcs elemei külső kulcsok (FK), amik más táblákra mutatnak. Ilyenkor a hibernate csak trükközve tudja leírni a relációt másodlagos mappeléssel, vagy a kulcsban mappelt relációval, bár nem mindig van szükség arra, hogy össze tudj kapcsolni kódban is két objektumot.[ Szerkesztve ]
-
floatr
veterán
-
#11993
floatr
veterán
Foglalt név
#11992
floatr
veterán
válasz
Foglalt név
#11992
üzenetére
Ilyen méretű és életciklusú projektek esetében megéri saját repot üzemeltetni. Nem gondolom h az ultimate build tool az ant lenne
-
#11990
floatr
veterán
Foglalt név
#11989
floatr
veterán
válasz
Foglalt név
#11989
üzenetére
Ha mérlegre kéne tenni, hogy hány alkalommal futottál bele ilyen jellegű függőségi problémába, és hány alkalommal nem kellett egy projekt elindításánál neki köszönhetően összegereblyézned a libeket, akkor gyanítom, hogy az utóbbi lenne a jellemzőbb.
Nyilván mindenki azt használ, amit akar, meg amit megszabnak neki, de ne tegyünk már úgy, mintha megkeserítené az életét egy fejlesztőnek. -
#11938
floatr
veterán
yossarian14
#11927
floatr
veterán
válasz
yossarian14
#11927
üzenetére
Már van, de a java 8ról beszéltem a példa kedvéért, abban még nem volt.
-
#11920
floatr
veterán
yossarian14
#11919
floatr
veterán
válasz
yossarian14
#11919
üzenetére
Igaz. Ezeket mindig elfelejtem, pedig nem hülyeség
-
floatr
veterán
válasz
Ablakos
#11914
üzenetére
Metódus-referenciát akartam írni, de elbabráltam.
Ha a Literacy osztályban implementálsz egy static compare metódust a Double::compare mintájára (ahogy a lambdában csináltad), akkor úgy is lehetne a streames kód, hogy:.sorted(Literacy::compare)Rövidebb nem lesz összességében, de elegánsabb, és nálam egy kód reviewn is hamarabb átmegy
[ Szerkesztve ]
-
floatr
veterán
válasz
BE4GLE
#11878
üzenetére
Örülök h sikerült ennyiből meglátni minden aspektusát.
#11881 Drizzt
Többek között azért is más a minőség, mert sokkal jobban végiggondolt az egész. Szinte már waterfall#11879 btraven
Ha már rendszerszemlélet, dobd bele egy bootba, kapja meg webfluxon a nevet, majd küldje el egy ELK-nek a generált szöveget. Tedd a szöveg generálást egy service-be, amire írhatsz 1 darab unit tesztet, minden másnál mókolsz, meg integrálsz, és többször becsapod magad.#11882 axioma
Ezért mondom, hogy ehhez túl cinikus vagyok. De az már megint nem agilis, ha droidokkal dolgozol. Ráadásul a tesztelt kód többszörösét megírod, ahol a tesztben ugyanúgy lehet hiba, amin átsiklasz, mert rosszul tesztel.[ Szerkesztve ]
-
floatr
veterán
válasz
axioma
#11875
üzenetére
Túl cinikus vagyok a TDD-hez
Az utóbbi években csak olyan agilis projektekben dolgoztam, ahol az agilitás leginkább arra vonatkozott, hogy menetközben találja ki a megrendelő, hogy mit is akar (vagy nem). A projektek óriási keretrendszereket használnak, amiben az egyes funkciók deklaratív elemeken keresztül automatikusan készülnek el. Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek.
Ha ilyen projektekre valaki rávág egy coverage kritériumot, mert az jól mutat, a teljes csapat egy emberként áll fel, és megy át a konkurenciához.
De hello ${username} példakódban piszkosul jól mutat... -
#11815
floatr
veterán
Aethelstone
#11805
floatr
veterán
válasz
Aethelstone
#11805
üzenetére
Nekem ez már a bitb.szás kategóriába tartozik. A legtöbben tervezni sem tudnak elégséges szinten, nem hogy még erre optimalizáljanak.
-
floatr
veterán
https://docs.spring.io/spring-session/reference/http-session.html
Amúgy nem tudom, miért erőlteti a security-t ennyire. Az Acegi sosem volt praktikus, és még most sem tudták használható formába gyúrni. Erre a célra max egy cache-t használnék egy-két metódusra kötve, nagyjából ennyiben ki is merülne a "session" funkciója. Igazság szerint a session is csak egy cache, aminek a kulcsát adja-veszi a frontend és a backend
[ Szerkesztve ]
-
-
-
floatr
veterán
válasz
Drizzt
#11681
üzenetére
Még sosem néztem konkrétan ezt a kódot, de "gyönyörű". Néha van olyan érzésem, amikor a runtime forrását túrom, hogy a nagy részét juniorok vagy biorobotok írják. Van egy partnerünk, aki szokott kódot auditálni, és az elemzéseik szerint botrányos minőségű a nagyobb frameworkök forrása (is)
-
-
floatr
veterán
Frontend-backend koncepció minden architektúrában jelen van, bármilyen módszer vagy paradigma mentén fejlesztesz. Egy alkalmazás komponenseinek minden egyes absztrakciós szintjén saját feladatkörük van. Ha csak egy desktop appot csinálsz, akkor is kellenek layerek, amik az adatok reprezentálásáért, feldolgozásért vagy megjelenítésért felelnek.
Szép dolog a teljesítmény, de ha a karbantarthatóság nulla, akkor az a kód semmit sem ér. Ilyenek miatt léteznek még ma is ősrégi COBOL alkalmazások, amiket senki nem akar még bottal sem piszkálni. -
#11581
floatr
veterán
Aethelstone
#11580
floatr
veterán
válasz
Aethelstone
#11580
üzenetére
Van persze, de még lusta voltam utána menni. Egyszer rászántam kb 10 percet, hogy egy hobbiprojektet megreszeljek, de nem ment egyből, aztán azóta úgy maradt. Csak amiatt mondom, hogy hajlamos ilyen problémákba belefutni.
-
#11579
floatr
veterán
Aethelstone
#11578
floatr
veterán
válasz
Aethelstone
#11578
üzenetére
Nem ismeri fel java projektként. Pontosabban a java kiegészítő elhasal, amikor beolvassa a projektet, és nem működnek a java IDE funkciók.
-
#11577
floatr
veterán
Aethelstone
#11576
floatr
veterán
válasz
Aethelstone
#11576
üzenetére
Nálam a vscode most valamiért elbabrálta a régebben létrehozott projekteket, mert gradle verziót frissítettem. Egyelőre még nem sakkoztam ki, hogy mi a baja
-
-
floatr
veterán
Jópofa tud lenni, de sokszor bevisz a málnásba. Pl van egy Function<Double, Double> metódus referenciád, amire - talán nem közvetlenül - a DoubleUnaryOperator-t ajánlja kicsit agresszívabban a kelleténél, mert hát ugye sokkal specifikusabb. Csakhogy annak a paramétere double, amire minek figyeljen a sonar, merthát az apróság, de streamben már használhatatlanná is vált
-
#11441
floatr
veterán
Aethelstone
#11440
floatr
veterán
válasz
Aethelstone
#11440
üzenetére
Nézd, kezdetektől fogva javazom, és család mellett sem okozott problémát a gradle, bár az ant-et szerettem a legjobban. Nyilván mindenkinek más az "egyszerű", de az XML tömöttsége eleve kevésbé áttekinthető, mint egy DSL, bármilyen jó code highlightot használsz. Karbantarthatóság szempontjából is nyilván jobb
Ami a design-t illeti, a legtöbb esetben nincsen papírforma, mindig van valami olyan körülmény, amihez alkalmazkodni kell. Amellett egy mostani CI migráció miatt jött elő, hogy a gradle build előnyben van a mavenessel szemben a deployment miatt, mivel több olyan dolgot implementáltunk benne, ami mindenhol tud futni, de a mavenes projekt ezt a CI-ra bízta. -
#11428
floatr
veterán
Aethelstone
#11426
floatr
veterán
válasz
Aethelstone
#11426
üzenetére
Teljesítményben jobb, de clean coding miatt is preferálják. A mavenben nem szokványos taszkokat, ami filekelezés/deployment témában befigyelhet, csak custom osztályokkal oldhatsz meg, ami rendkívül jó kódrejtésben
A groovy mondjuk nem a kedvencem, de ha kotlinos a projekt, akkor eleve adja magát. -
floatr
veterán
válasz
Drizzt
#11415
üzenetére
Mi az előnye a teljesítmény mellett? Sokkal rugalmasabb: deklaratív és procedurális egyben. Ha valami nem szokványos dolgot kell megoldani, elég egy kisebb scriptet írni benne. Nem vagy kötve a CI/CD képességeihez, és lokálisan is meg tudod azt tenni, amit a CI/CD pluginekkel támogat
Azt sem tartom valós problémának, hogy annyit kéne vele bíbelődni, hiszen a fejlesztőkörnyezetek már eléggé támogatják a nulláról kezdést is, ahogy a maven esetében. Sokkal körülményesebb a maven, de igazán nem akarok téríteni, nyilván nem kötelező, ha valaki nem akarja. Végülis lehet írni SOAP-os vagy RMI-s alkalmazást is manapság, az is működhet...Off az off-ban: szoktam találkozni olyan emberekkel, akiknél megfigyelhető az a felfogás, hogy csak abba az irányba hajlandóak elmozdulni, amerre a kényszer viszi őket. Ők általában egy idő után benne ragadnak egy adott technológiai stackben, ami egy ideig fel sem tűnik nekik. 10 évvel később viszont már riasztó, amikor még mindig servletről beszél, és oracle + jdbc a DB megoldás mindenre
-
floatr
veterán
válasz
Drizzt
#11407
üzenetére
A megfelelő build alap összerakása elhanyagolható erőforrásigényű egy átlagos projekt többi feladatához képest. Nyilván nem a legkritikusabb helyzetekben kell fejest ugrani az ismeretlenbe, de ezzel a mentalitással bele lehet ragadni technológiákba. Amúgy pont devopsos szempontból nem értem a dolgot, hiszen épp a gradle az, ami sokkal kezesebb groovy/kotlin oldalról. Compose-os projektekben befonnánk egymás haját, ha mavent kellene használni.
-
-
floatr
veterán
válasz
togvau
#11315
üzenetére
https://docs.jboss.org/hibernate/orm/5.1/userguide/html_single/chapters/domain/access.html
Azért használ eltérő módszert a két elérésre, mert field access esetében kell proxy/introspection/reflection. A hiányosság itt a framework és a technológia ismeretében van.[ Szerkesztve ]
-
floatr
veterán
válasz
togvau
#11313
üzenetére
A hibernate az @Id annotáció alapján választ stratégiát arra, hogyan kezelje a bean adatait. Ha field-en van, akkor reflection-t használ mindenre, ha getteren, akkor a metódusokat. Vegyesen csak akkor lehet használni, ha felülcsapod a default stratégiát egy
@Access(AccessType.FIELD)annotációval, amit a field-re akasztasz rá.Imádkozás helyett specifikáció, vagy tutorial. Ez a középkorban is sokszor bevált volna.
-
-
-
floatr
veterán
válasz
sztanozs
#11249
üzenetére
Ha böngészőről lenne szó, akkor lenne értelme iframe-eket használni, bár sok site nem engedi meg a beágyazást. Úgy akkor használhatnád direktben a böngésző motorját, de ha az nincsen, akkor node.js alatt vagy bármi más eszközzel talán köhögősebb egy library használata. Nyerni tuti nem fogsz, maximum ha más nyelv áll kézre.
Érdekes lenne dolgokat összehasonlítani, bár nem szívesen piszkálom sem a python-t sem a JS-t, ha nem muszáj
-
floatr
veterán
válasz
togvau
#11188
üzenetére
Ha most jobban végiggondolod, ezt SQL-ben sem lehet normálisan megcsinálni. SQL Server-nek van valami JSON-ös megoldása erre, de sosem használtam. Vagy egy nagy JOIN-ba pakolsz mindent, de akkor ismétlődés lesz, amit kézzel kell aggregálni stream-collector alapon, vagy külön kérdezed le, úgy viszont neked kell összekalapálnod az összetartozó adatokat, ha a lazy initet nem szereted.
Igazság szerint, ha ilyen adatmodelled van, érdemes elgondolkodni egy NoSQL DB-n, mint pl. a Mongo.
A H2/HSQL/Derby nem production-ready DBMS. Helyette inkább MySQL/MariaDB egy docker konténerben.
-
floatr
veterán
válasz
togvau
#11186
üzenetére
Egyrészt jó lenne, ha kicsit jobban leírnád a kérdéseidet, mert nem lehet követni, annyira csapongsz.
A JOIN FETCH egy JPA specifikus dolog, a Spring Data nem tehet róla, hogy néha kell. Ha használsz @Transactional-t, vagy open session in view filtert, akkor egy tranzakción belül, több dolgot is fel tud szippantani, mint szeretnéd.
Ha DTO-t használsz, akkor eleve máshogy fognak működni a dolgok.
Ha csak bizonyos mezőket szeretnél használni, arra ott vannak az implicit és explicit projekciók.
A fenti query a legtöbb DBMS-ben értelmezhetetlen. -
floatr
veterán
válasz
togvau
#11172
üzenetére
Belepakolsz egy @Transient annotációval jelölt metódust, ami get***Id néven visszaadja a kapcsolt entity azonosítóját.
De használhatod a gyerek-szülő kapcsolatban a JsonManagedReference és JsonBackReference annotációkat is, ami csak egyik irányban engedi a szerializációt kifejteni
[ Szerkesztve ]
-
floatr
veterán
válasz
Ezekiell
#11116
üzenetére
Csak 30-ára 3 crashlogom van. Megtartottam párat, hogy majd utánanézek, de még egyelőre inkább sajnáltam magam, mint időm lett volna rá. A code insight környékén (is) van valami gáz. Viszonylag nem kicsi a projekt, van 8 konténer, és a legborzasztóbb tényleg az, hogy néha az IDE indítás után egyszerűen az alap classpath sem látszik, mert összekavarodik a gradle sync.
-
floatr
veterán
Alapvetően nem lenne rossz, de...
Leszámítva az apró kis hm... sajátosságait mostanában eléggé bosszantó, hogy napi szinten 3-4 alkalommal hullik darabokra. Ilyet régebben még az eclipse sem csinált a legrosszabb pillanataiban sem.
Egyetlen dolog van az ideaban, ami tényleg tetszik, az a lambda-kezelés és a kapcsolódó code assist. Érdemes figyelni a VS Code-ra, mert nagyon jön fel, hónapról hónapra fejlesztik. -
floatr
veterán
Nem demagóg... dogmatikus
Nem tartom haszontalannak a sonart, de az esetek egy részében mondjuk úgy, hogy fals pozitívat jelez. A múltkor már csak röhögtem kínomban. Szokott olyanokat jelezni, hogy szerinte másképpen kéne megoldani valamit. Addig kavarta több lépésen keresztül, amíg a kód fordíthatatlan lett.
A DTO-val kapcsolatosan meg napi szinten tapasztalom, hogy kezelik az emberek. Semmivel nem lesz tőle biztonságosabb a kód. Egyszerűen csak kérdezd meg magadtól, hogy tényleg szükséged van-e rá. A dogmatikus válasz az, hogy mindig szükség van rá, mert meg lett mondva. A racionális válasz az, hogy pl máshogy reprezentálod az adatot API verziónként, ezért kell.
-
floatr
veterán
A legjobban az tetszik, hogy a sonar oldalán lévő leírás és javaslat is tele van agyatlan anti-patternekkel. Sajnos a sonar tele van hülyeséggel, nem véletlen, hogy meghagyták a lehetőségét annak, hogy kikapcsolj egy-egy szabályt
Ha DTO-kat gyártasz akár rétegenként, akár microservice-enként, akkor plusz konverziós lépéseket teszel a kódba potenciális hibaforrásokként. A leggyakoribb az, amikor egy fejlesztő erre rá van kényszerítve, hogy gépiesen átdobálja az adatokat, néha konvertál típusok közt. Komplexebb lesz a kód, és semmi nem teszi biztonságossá abban az irányban, amit a sonar szabályban és a linkjeiben -- leginkább csak -- sugallnak. A mintakód félrevezetően gyatra, hűen tükrözi a témakörben gyakori ultragagyi minimalista tutorialok szellemét. Nem ment semmi és senki automatikusan, ellenőrizetlenül, validáció, autentikáció és access control nélkül, pláne nem a Controllerből, ha publikus endpointról van szó. Ha microservice-eket használunk, akkor meg egyenesen hiba eltakarni egy újabb réteggel az adatokat pl az api gateway elől. Hasonló okokból teljesen feleslegesnek tartom az OpenSessionInView filterrel kapcsolatos felindulásokat.
A leggyakoribb érdemi oka annak, hogy DTO-t vagy projekciót kell használni, az szokott lenni, hogy teljesítménybeli optimalizációt kell csinálni, így bizonyos lekérdezéseket view-ra specializáltan kell implementálni, vagy mert a frontend nem tud mihez kezdeni összetett adatokkal. Esetleg az api gateway összegyúr két service-ből származó adatot, de az meg szvsz tervezési hiba, ha erre kényszerült rá valaki.
Egy esetben látom még a létjogosultságát a DTO-szerű képződményeknek, ha az Entity/Document bloated lenne egyébként. Ez meg szubjektív.
Nem kell, hogy egyetértsünk, de a dogmatikus kijelentések teszik tönkre a szakmát.
-
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Xiaomi Poco F3 5G 8/256 Ocean Blue
- Zalman ZM650-EBT (hibás) eladó
- Újszerű ASUS OLED Zenbook! Csak 1 kg! 13,3 coll/i5-1135g7/512SSD/16GB 4267Mhz RAM
- AKCIÓ!!! GAMER PC: RYZEN 9 5900X + RTX 3060 12GB GDDR6! GARANCIA/SZÁMLA!!!
- BONTATLAN Új Iphone 16 PRO 128Gb - 1TB Független 1év Apple GARANCIA Deák Térnél Azonnal Átvehető.
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest