Új hozzászólás Aktív témák
-
Tothg86
tag
válasz
floatr
#12058
üzenetére
Köszönöm szépen!
Az az egy nem világos most, hogy egyelőre egy tök szimpla lekérdezéshez, a példában szereplő két mezőt (account number és account type) ugyanúgy kell mappelnem az account osztályban, hogy melyik oszlopban van az adatbázisban? Én úgy szoktam, hogy nem bizom a hibernatere, hanem mindig megadom melyik adatbázis oszlophoz mappelje. -
Tothg86
tag
válasz
floatr
#12056
üzenetére
Köszi!
Egy konkrét kérdésem is lenne.
Van egy munkahelyi tábla, amiben nincsen auto increment ID, nincs semmilyen primary key sem. Szembesültem azzal (ha jól értem), hogy a hibernate megköveteli az egyértelmű azonosítást. Mivel nincs a táblában ID, ezért egy darab azonosítót nem tudok hozzárendelni. Olvastam, hogy van lehetőség összetett kulcs hozzárendélésére az EmbeddedID annotation-nel.
Jól értem? Egy netes példában az volt, hogy egy külön osztályt hozok létre a kulcsnak, és itt jelölöm, hogy @Embeddable. De ez már beleszámít a mappingbe? -
#11992
Foglalt név
addikt
floatr
#11990
Foglalt név
addikt
válasz
floatr
#11990
üzenetére
Szerintem az összegereblyézés nem feltétlen a megfelelő előny. Ha a lib-eket berakod direktben a repo-ba, akkor robusztusabb és gyorsabb is, mint ahogy a maven levadássza őket.
Én úgy vélem projektfüggő mit, és hogyan használsz. A mai divatos eldobható szösszeneteket én is inkább összecsapom valamiben.
Ha elő kell vennem egy régi cuccot, aminek az életideje évtizedekben mérhető, csak éppen befut rá egy feature request, akkor azonban mindig meglepődöm, hogy érdekes módon az időm java részében fejlesztek és a végén lefordítom az aktuális java verzióval egy szem hiba nélkül.
Szemben azzal, mikor gradle, spring vagy valamelyik másik framework-ben az idő 60%-ban próbálok rájönni, hogy sikerült egy több százezer fejlesztő által használt keretrendszert kiadni egy olyan patch szintű upgrade-el ami nem visszafelé kompatibilis.
Persze a felháborodásom azon is múlik, hogy CD pipeline-t kell írni a korábban említett őskövülethez, amit legközelebb akkor fogunk kiadni, mikor már nem lesz gitlab. -
Sirpi
senior tag
válasz
floatr
#11925
üzenetére
És amennyiben nincs is szükséged, hogy elérd ezeket a metódusokat, mindig az interface-t használd típusnak, ne a konkrét megvalósítást, mert így bármikor ki tudod cserélni a tényleges típust (pl. LinkedList-re) anélkül, hogy a kódod egyéb részeihez hozzá kellene nyúlnod.
-
axioma
veterán
-
axioma
veterán
válasz
floatr
#11876
üzenetére
Vagy csak olyanok kozott dolgozom akik a problemat oldjak meg a szoftver letrehozasaval es az implementacio helyesseget tesztelik megfelelo szintu tesztekkel utat helyesebbnek tartjak.
Tesztet irni TDD-hez DE ugy, hogy az tenyleg minden lehetseges implementacio eseten minden hibat elkap, akkora befektetes, hogy annyi ido alatt az _egyik_ implementaciot tesztelessel egyutt egy-harom masik problemara is megcsinalja [JOL]. Teljes tesztet elore megirni ugy, hogy egy lehetseges implementacio mar a fejeben van, az meg a menet kozben kiderulo donteseknel csinal lyukat [aztan vagy betomik vagy nem... talan ahol merge feltetelbe fut].
Egy esetben jo lehet: az "agy" irja a teszteket, a code monkey-k/juniorok/etc. meg az implementaciot. De akkor sem biztos hogy kicsit is hosszabb tavra nezve.
[Termeszetesen az elozoleg irt kiveteleket fenntartva, altalanosabb meretu/beagyazottsagu/bonyolultsagu fejlesztesi feladatokra.] Es persze SZVSZ. -
#11820
Aethelstone
addikt
floatr
#11819
Aethelstone
addikt
-
Drizzt
nagyúr
válasz
floatr
#11817
üzenetére
Nem gyakori, de nem art, hogyha van az embernek az eszkotaraban valami, amivel tudja kezelni adott esetben. Nyilvan valos statisztikam nincs a dologrol, de egyebkent azert egyaltalan nem ritka, hogy sok duplikalt string van a heapen. Az mar ritkabb, hogy ezek hosszu eletuek is legyenek egyben. Es elsosorban akkor jon el az a szint, ahol erdemes kezelni.
-
-
Szmeby
tag
válasz
floatr
#11774
üzenetére
Az ilyen kérdések nem segítségkérésre valók, lévén nem konkrétak. Talán együttérzésre vágyik, ventilálni jár ide. Nincs ezzel semmi baj, a lelki támogatás is fontos. Mondjuk én személy szerint nem tudok velük mit kezdeni, de hátha valaki igen.
btraven: Gratula a játékhoz!
-
Szmeby
tag
válasz
floatr
#11690
üzenetére
Szerencsére már megtehetem, hogy a megrendelő arcába mondom, működő kódot egy majom is tud írni... kis túlzással. Szóval rengeteg pénzt spórolhat, ha inkább felvesz egy pár juniort, aki összerakja neki az appot gombokért. Ők ráadásul minden szóra engedelmeskednek, nem jönnek ezzel a nem lesz hatékony / átlátható / felhasználóbarát marhaságokkal. Ő is "jól" jár, és az én idegeimet is megkíméli.
Mindenkit bátorítanék erre, különben sose tisztul a piac, ha a fejlesztő nem áll ki a technológiai oldalért. -
skoda12
aktív tag
válasz
floatr
#11685
üzenetére
Ez szerintem minden kódra igaz. Voltam zöldmezős projekteken. 1 év után azok is úgy néztek ki, mint bármi más, amit 5 éve fejlesztenek 2 vendor céggel. Nagyon sok nagyon különböző képességű ember nyúl a kódokhoz, valószínűleg hatással van az egészre a felülről érkező nyomás is, a szűkös határidők, változó elvárások, stb. Régen én eléggé beleálltam a code reviewkba, de borzasztó sok konfliktusom volt belőle és inkább elengedtem. Funkcionális hibák esetén is inkább privátban chaten szólok az embereknek. Páran nagyon nem tudják kezelni, amikor nyílvánosan kapnak 5-6 kommentet egy PR-re.
-
btraven
őstag
válasz
floatr
#11671
üzenetére
Nálam ezt csinálta a Java. Benne van a fájl végén a write exception.
Amikor beolvasom akkor elszáll read exception-nal, de a stacktrace-ben a mentett write exceptiont is kiírja.
Először nem is értettem hogy hívódik meg a save metódus vagy mi van.
java.io.NotSerializableException volt. -
#68216320
törölt tag
válasz
floatr
#11638
üzenetére
Maradtam a pom.xml-nél. Kényelmes, ha minden ilyesmit látok egy helyen.
Más:
Hogyaza... frissítettem az STS-t és valami gond van az Eclipse-el.
Ezt a hibaüzenetet kapom: [kép]
Azt hittem a desktop gépemen van valami gond, megcsináltam a laptopon is, de ugyanez lett a vége. Ilyenkor most mivan? -
Drizzt
nagyúr
válasz
floatr
#11417
üzenetére
Remek, de ezekre nincs szuksegunk. Egyszer jo lenne atterni, de joval nagyobb annak az ara, mint amit itt sugallsz. Mindenkeppen eltart egy ideig, mig egy programozo csapat atszokik egy masik build tool-ra. Nyilvan van az a helyzet, amikor a relativ koltsege az atallasnak kisebb, mint a relativ haszna. Nalunk jelenleg nem az.
-
Drizzt
nagyúr
válasz
floatr
#11410
üzenetére
"A megfelelő build alap összerakása elhanyagolható erőforrásigényű egy átlagos projekt többi feladatához képest." Nem ertek egyet. Ez csak akkor igaz, ha az adott build rendszerhez es az azzal szembeni kovetelmeneykhez is valaki nagyon ert. Igazabol aztan utana tok mindegy, hogy pipeline-bol mavent, vagy gradle-t hivok meg.
Projektek atlagos build ideje ket perc mavennel. Intellij meg ugyis feldolgozza az egeszet belso projekt formatumra, ami sokkal gyorsabb, foleg ha szelektiven akarsz valamit futtatni. Kiprobalnam en is elesben a Gradle-t, de nem igazan varok tole semmi valos hasznot a mi use case-unkben. Ha nagyon nem lesz semmi dolgunk, akkor majd rakerul arra is a sor. A mostani maven service template-jeink tokeletesen megfelelnek az elvarasainknak, a lecserelesukben sokkal tobb lenne a potencialis risk, mint a potencialis benefit. -
btraven
őstag
válasz
floatr
#11364
üzenetére
Egyébként is kezdek rájönni hogy a legjobb a Java API-t nézni. Ott tömören pár sorban minden le van írva.
T reduce(T identity, BinaryOperator<T> accumulator)T result = identity;for (T element : this stream)result = accumulator.apply(result, element);return result;
Kell ennél több? -
togvau
senior tag
válasz
floatr
#11314
üzenetére
húúú nem hittem volna, hogy ennyire gagyi
sajnos nincs kapacitás az 5642 divatos framework lelki világát, bugjait, hiányosságait bemagolni.
Hogy sikerült rátalálni? Én akárhogy is kerestem rá guglin, csak olyan jött ki, hogy nem azt a transient-t használja ami oda kell, hanem másikat. -
togvau
senior tag
válasz
floatr
#11267
üzenetére
közben meglett, picit máshogy: mvn package
2 kérdés:
-Kellene valami tool amivel teljes java projekteket lehet összehasonlítani, java fájlonként, tartalomra. Total commander synchronize dirs volt eddig, de most nem... minden java fájlt különbözőnek érzékel, és különbözik is a mérete byte-ra, de a tartalom nagyrésze egy az egyben ugyan az. By content checkbox nem segít, karakterkódolás pedig azonos, nincs fájl végi sortörés különbség sem
-Van olyan tool amivel kigyűjhetőek, akár a pontosan egyező metódusok is? Mert az a szerencsétlen aki csinálta, még metóduson belül is 10 soros kódokat ismételget, azonos copy-paste metódusokból is sok van.
Persze az is hasznos lenne, ha a feltűnően hasonló kódrészletekre is figyelmeztetne, hogy azt egységesíteni lehet. -
togvau
senior tag
válasz
floatr
#11190
üzenetére
Ha feljoinolom a hozzá tartozót (userpropertiest), akkor is több queryt csinál. Fetch joinolni meg nem lehet, mert nem tudom mi neki a szükséges parent, mert már az összes entityt kipróbáltam a select listába rakni, de mindig azt írja, hogy a parent nincs a select listában.
Nem is production volt a cél, akkor már nem kell percenként újraindítgatni.
De meglett a megoldás, valami cachelési feature okozza, amit a jdbc url végére ;MV_STORE=FALSE rakásával ki lehet iktatni. -
togvau
senior tag
válasz
floatr
#11173
üzenetére
ja tényleg, transient, jó ötlet! A többit is megnézem majd.
Most a hype UI-val ismerkedek (angular), és abban van egy ilyen a példában, hogy : import { Observable } from 'rxjs/Observable';
erre azt írja, hogynode_modules/rxjs/Observable"' has no exported member 'Observable'.ts(2305)Mit kéne ezzel csinálni, hogy ne írja?fogalmam nincs mit csinálok,de ilyen npm install rxjs-t nyomtam, de nem nyert, lett valami rxjs a node modules-ban, de a kisbetűs observable mappában nincs observable fájl.
szerk: meglett, a vscode megtalálta ott, ahol nincs, de biztos így van, hiszen javascript ahol minden lehet bármi is, meg semmi is.
-
Ezekiell
veterán
válasz
floatr
#11118
üzenetére
Na, a gradle sync az tényleg tud kavarogni, ezt aláírom. Szerencsére 1 gombnyomás megoldja.
De ha nálad ennyi crash van, akkor ott nálad lesz valami probléma. Mondanám, h reinstall mindent, de ha ilyen tanácsot kapnék, nekem is a "b*szódjmegteis" lenne az első gondolatom
-
válasz
floatr
#11098
üzenetére
Szerintem van ráció abban amit a SonarLint ír. Lehet, hogy komplexebb lesz a dolog de akkor is biztonságosabbá válik azáltal, hogy valmait kell kezdened a DTO-val és nem tudod csak úgy pusztán elmeneteni.
Az egész sonar opcionális, nem muszály használnod. De egyszerűen, egy plugin telepítésével összeségében nagyon sokat tudsz javítani a minőségen.
Én általában a nálam okosabb emberek által javasolt dolgokat elfogadom, persze nem jelenti azt, hogy neked is el kell. Régóta létezik, ha akkor szar lenne, azért bízom benne, hogy nem létezni.
Ki volt és megint hol demagóg? Valláshábórú != demagógia (bocs, ha nem nekem szólt).
-
togvau
senior tag
válasz
floatr
#10990
üzenetére
Most kellett
Linkeltem fent a bugot, ami valahol van... exception alapján spring data-ban van, de a workaround az egy criteriaquery, aminél nem jelentkezik ugyan az a bug:@Query("select p.id from Photo p where p.user = ?1")List<Long> findIdsByUserId(long id, boolean restricted);
Ez elhasal, a linkelthez hasonló: org.springframework.dao.InvalidDataAccessApiUsageException: Parameter value [34] did not match expected type... -alMíg ugyan az a lekérdezés (kicsit még kibővítve), criteriaqueryvel, ugyan olyan metódusparaméterekkel, fut ahogy kell:
public List<Long> findIdsByUserId(long id, boolean restricted) {var cb= em.getCriteriaBuilder();var ids=cb.createQuery(Long.class);var root=ids.from(Photo.class);ids.select(cb.construct(Long.class, root.get("id")));var pred= new ArrayList<Predicate>();pred.add(cb.equal(root.get("user"), id));if (!restricted) pred.add(cb.equal(root.get("restricted"), false));ids.where(pred.toArray(new Predicate[pred.size()]));return em.createQuery(ids).getResultList();}fura. user= User entity kapcsolat, ami DB-ben egy BIGINT-et jelent user_id mezőben.
-
togvau
senior tag
válasz
floatr
#10988
üzenetére
Jaj de bonyolult, és csúnya. DeltaSpike-nál létre lehetett hozni interfacet extends EntityRepository, ahol csak @Query elég volt, ahol meg vegyesen kellett @query, és rendes metódus is, ott abstract class extends AbstractFullEntityRepository, aztán abstract metódusnál csak @query, nem abstractnál meg minden más.
Vannak bajok ezzel a spring datával, belefutottam ebbe is [link], csak sima long-al. Akkor jön elő, ha entity kapcsolat van 2 tábla között. Bár a kapcsolat DB szinten sima id-kkel van meg (bigint-ek), id alapján queryben mégse lehet szűrni, mert bár a query paraméter long, ami jó a biginthez, de spring data azt már entity-nek látja, amivel nem stimmel a long...
Akkor lehet választani, hogy vagy entity szintű kapcsolatok, vagy optimalizált lekérdezések... bár criteriaqueryvel nem próbáltam még. -
togvau
senior tag
válasz
floatr
#10984
üzenetére
Köszi, így érthető!
Manuálisan pedig entitymanager begintransactionnel lehet kezdeni, és flush-al lezárni?Ezt viszont megint nem értem:
Ez volt: (működött az autowired)@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long> {Ez lett:
@Repository
public abstract class PhotosRepo implements CrudRepository<Photo, Long> {
@PersistenceContext
private EntityManager em;
és mellé autowirednél:
.NoSuchBeanDefinitionException: No qualifying bean of type 'org..asd.db.repository.PhotosRepo' available: expected at least 1 bean which qualifies as autowire candidate.
Miért? -
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.
-
bambano
titán
válasz
floatr
#10817
üzenetére
amit mondtam eddig, az érdemi mondanivaló attól, hogy te nem értesz vele egyet. Nem a vita kedvéért csinálom, hanem azért, hogy a kedves kolléga tanulhasson belőle. Ettől egy független tény, hogy mivel te java-val foglalkozol, szerinted mindent java-ban kell megoldani.
abban pedig biztos vagyok, hogy sokkal hamarabb fog érteni valaki vagy talál valakit, aki ért a sedhez, mint egy tök idegen program json konfigjához, amiben pont ugyanazok a reguláris kifejezések vannak, mint amit sedben használsz.
-
bambano
titán
válasz
floatr
#10815
üzenetére
"Nem fog megállni a dolog egy property->insert trafónál": ezt úgy hívják, hogy találgatás. Ha architekt követi el, akkor az főben járó bűn. A feladat szenzoradatok mysql-be töltése. Nem vidámpark, nem csillagháború, egy darab libikóka.
"Rendszerszemlélet zéró.": ez nyilván téves kijelentés több okból is. Egy kétsoros szkriptet összeütök két perc alatt. Tehát ha a találgatás, hogy majd valamikor beláthatatlan időtávban mégis lesz extra kérés, amire a szkript már nem alkalmas, akkor pontosan ugyanennyi idő alatt ki is dobom.
Másrészt a rendszerszemléletben alapvető, első helyen levő pontnak kell lenni, hogy a rendszeredet kicsinek tartod meg. Tehát amíg lehet, nem növeled. Minél kisebb egy rendszer, annál egyszerűbb üzemeltetni. Ja, jáva architektek ezt se szokták figyelembe venni, hogy a lomjukat üzemeltetni is kell. Meg debuggolni.
-
bambano
titán
válasz
floatr
#10812
üzenetére
az a baj a jáva nindzsákkal, hogy ha meglátnak egy új jáva szabványt, azonnal fel akarják használni akkor is, amikor nincs mire. Meg az is, hogy soha nem az előttük levő feladatra koncentrálnak. De ha nem, akkor mire?
De az is látszik a párbeszédből, hogy sokan úgy programoznak linuxon, hogy fogalmuk sincs, mit jelent linuxon programozni. ha linuxon windowsosan akarsz programozni, akkor tegyél fel windowst.
Tele van a padlás olyan jávás szakemberekkel, akik akkor is atomtengeralattjáróról kilőtt interkontinentális ballisztikus rakétával lőnek, ha csak egy veréb a célpont.
Szerinted melyikben valószínűbb, hogy hiba lesz: egy két soros shell szkriptben vagy egy elastic-ban? Melyikre kell több erőforrást felhasználni, kiemelten emberit is: egy szkriptre vagy egy rakás jáva vm-re meg benne futó rakás szolgáltatásra? melyiket kapod meg összességében olcsóbban? hint: nem a jávát, arra mérget vehetsz.
És hiába fikázod a szkript nindzsákat, az objektív műszaki érvek ebben a feladatban nem a jáva mellett szólnak.
-
axioma
veterán
válasz
floatr
#10812
üzenetére
Tetszik a vidamparkos hasonlat
[off, csak errol jutott eszembe, az idei adventofcode feladatainak majdnem fele egy ilyen evolucios dolog: az elejen csak 2 opcode-ot ismero ertelmezo volt a feladat, most mar komplett terkepet uzemeltet a sajat hasaban es azt kell meghajtani kivulrol algoval -- megjegyzem nekem tetszik es viszonylag uj is ez a(z elore nem ismert) funkcionkkent tovabbpockolos munkamodszer - igaz nem is java-ban hanem pythonban csinalom] -
bambano
titán
válasz
floatr
#10807
üzenetére
tökéletesen leírtad, hogy mi a baj egyes java architektekkel.
elk meg logstash meg elastic meg kibana meg a franc se tudja hány cuccot felrakni azért, hogy bekerüljön egy mért érték egy adatbázisba, az durva tévedés. mindegyik szoftver bugos. ha telerakod szoftverrel a rendszert, akkor teleraktad hibával is.amit két sorban meg lehet írni shellben, ahhoz nem rakunk fel akkora architektúrát, hogy csak a0-s lapra lehet kinyomtatni. és ha még valaki a dockert is elkezdi emlegetni, sikítani fogok.
-
bandi0000
nagyúr
-
coco2
őstag
válasz
floatr
#10779
üzenetére
Akkor egy kicsit vakarom a buksit. A bugfix és hasonlók időszakosak - amennyire a hírekből ki tudtam olvasni - akár fizet valaki, akár nem, nem kap gyorsabban semmit, mint a többiek. Frissítés és hasonlók a rendszergazda dolga, az Oracle miért foglalkozna azzal? Szóval nagyon nem értem én, miért is kapna az Oracle pénzt bármelyik cégtől, ha csak nem valami függöny mögötti sumák végett.
-
sztanozs
veterán
válasz
floatr
#10714
üzenetére
public class Dream implements Consciousness {protected List<MindState> inceptors;protected Object thought2Inject;protected Stack<MindState> dreamStates;/* */public String observe(Object o){if (o instanceof Spinner && !dreamStates.empty())return "Spins forever";elsereturn super.observe(o);}} -
Szmeby
tag
válasz
floatr
#10714
üzenetére
// givenUniverse universe = Universe.getInstance();long expectedLivingBeingCount = universe.getLivingBeingCount() / 2;// whenuniverse.getInfinityGauntlet().apply(InfinityStone.MIND).checkStonesAvailable(InfinityStone.values()).snap();// thenAssert.assertEquals(expectedLivingBeingCount, universe.getLivingBeingCount());
Hát, nem túl kényelmes ez a forráskód szerkesztő. -
Szmeby
tag
válasz
floatr
#10708
üzenetére
Oh, az első kérdést nem olvastam, az már tényleg nem lenne egyszerű.
Ilyesmire gondoltál?
Persze ha a pánikkeltés a cél, akkor biztosan cifrázható tovább. String[] arrayOfStrings = { "alma", "körte", "banán", "cseresznye", "áfonya" };
String longest = Arrays.stream(arrayOfStrings)
.collect(Collectors.maxBy(Comparator.comparing(String::length)))
.orElse(null);
(a kedvedért több sorba törtem
)A reduce nekem valamiért testhezállóbb volt, talán azért is, mert ritkán használok spéci collectorokat. Hirtelen nem is tudnám most rövidebben leírni collectorral, és ezt már én is túlzásnak érzem. Ízlés dolga. A for ciklus a tuti, azt mindenki érti és villámgyors.
-
Szmeby
tag
válasz
floatr
#10679
üzenetére
Hú, köszi. A google-nél csak a pricing calculatort találtam meg, ott meg egy falat szót nem ejtettek ezekről a free limitekről. :/ Ígéretesnek tűnik, kipróbálom.
(Nem én fogom majd üzemeltetni, ezért is fontos, hogy ne kezdjen el egy váratlan pillanatban kiszámlázni dolgokat az ingyenes időszak lejártával. Még ha pár dodó is lenne az, akkor se.)
-
disy68
aktív tag
válasz
floatr
#10516
üzenetére
"Az XML vs Java configgal kapcsolatban az a problémám, hogy a konfiguráció karbantartásához/módosításához kódolás kell, CI pipeline."
Ez a konfiguráció nem ugyanaz, mint az alkalmazáshoz tartozó akár környezetenként változó konfig, pl url-ek. Ha itt kell módosítani bármit - magyarul az alkalmazás context-je változik -, akkor újra kell buildelni az alkalmazást, függetlenül a konfiguráció típusától. Innentől ez nem üzemeltetési kérdés, hanem fejlesztés.
Az átláthatóság szubjektív dolog, láttam már 30-40 xml-ből felépülő Spring konfigot, ami nekem minden volt csak nem átlátható, viszont volt kolléga, aki azt preferálta. Azt hittem ez csak az ő fétise, de akkor vannak még mások is ezen a vonalon :-)
"Lombokot szerintem alapvetően pár olyan dologra érdemes használni, ami fordításkor generál le bojlerplét kódot. Ezen az alapon semmilyen nem Java JVM nyelvet nem lenne szabad használni."
Semmi köze a kettőnek egymáshoz, ne keverd a dolgokat. A lombok által generált kódban nem bíznak sokan, valamint java update esetében okozhat/okozott gondot. Van pár issue-juk is. Ettől függetlenül, ahol lehet én is preferálom a használatát, de ettől még megértem, ha máshogy dönt valaki. -
disy68
aktív tag
-
disy68
aktív tag
válasz
floatr
#10498
üzenetére
A körkörös függőség tervezési hibának hangzik. Több függőségnél pedig facade vagy egyéb wrapper megoldások is játszhatnak. Ezt is mondhatjuk workaround-nak, de én még mindig úgy vagyok vele, hogy inkább lássam a konstruktornál mi a függősége egy osztálynak, semmint annotációkat nézegetni. Én spring-nél is jobban preferálom az explicit java config-ot, mintsem a package scan-t meg annotációkat (saját kódnál, nem lib-eknél). Ha van egy konkrét config, ami alapján látom, mi lesz a context, mi-mi alapján épül fel, az nekem mindig szimpatikusabb volt.
-
![;]](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?:))
- Vezeték nélküli fülhallgatók
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Android szakmai topik
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- The Division 2 (PC, XO, PS4)
- Videószerkesztés
- Samsung Galaxy S23 Ultra - non plus ultra
- Xbox tulajok OFF topicja
- ASUS routerek
- OLED monitor topik
- További aktív témák...
- Dell G3 Gamer laptop (2TB SSD, 32GB Ram, 4GB Videókártya, FullHD kijelző, szép állapotban)
- Thinkpad T14 Gen5 14" FHD+ IPS Ultra 5 135H 16GB 512GB NVMe ujjlolv IR kam gar
- Használt gamer/ workstation laptop felvásárlás TÉNYLEG magas áron!
- Intel Core Ultra 7 265 /// Bontatlan, Teljesen Új // Üzletből, Számlával és Garanciával
- Csere-Beszámítás! Ryzen 9 9950X Processzor!
- Bomba ár! HP Elitebook 850 G3 - i7-6GEN I 16GB I 256GB SSD I RadeonI 15,6" FHD I Cam I W11 I Gari!
- BESZÁMÍTÁS! Microsoft XBOX Series X 1TB SSD fekete játékkonzol extra kontrollerrel dokkolóval
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
- Bomba ár! HP ZBook FireFly G8 - i7 I 16GB I 512SSD I 15,6" FHD Touch I Nvidia 4GB I Cam I W11 I Gar!
- Azonnali készpénzes nVidia RTX 3000 sorozat videokártya felvásárlás személyesen / csomagküldéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest