Hirdetés

Keresés

Új hozzászólás Aktív témák

  • Felvenném a fonalat az eszement framework-el.
    Próbálnék összehozni egy Spring Cloud Config szervert AWS backend-el. A dolog egész jól működik, ameddig a saját bejelentkezésemet használja. Azonban hozzá kéne adnom egy Role-t, hogy lássa a felhőt magától is.
    A 2.26-os aws sdk egy generált trutyinak tűnik és nem látom, hogyan tudnám elhiteteni vele, hogy a Primary Bean-nek megadott StsAssumeRoleCredentialsProvider-t használja.
    Az egész kód úgy néz ki, hogy csak a Default-ot tudja, használni és persze annyira "szolid", hogy minden private, nehogy bele tudjak nyúlni szépen.
    Mivel Spring, gondolom van egy nem dokumentált paraméter, függvény valahol, amivel egy sorból meg lehet oldani és nem kell a fél SDK-t újraírni hozzá. Vagy a Bootstrap registry-be behekkelni. Minél "tisztább" az ötlet, annál jobb. Köszi előre is!

    Utálom, ha valaki nem írja be a választ, ha megtalálta egy kérdésre.
    Az EnvironmentRepositoryConfiguration-ben ConditionalOnMissingBean babok, amikkel ki lehet váltani valami értelmessel a gyári implementációt.
    Biztos én vagyok vak, de egy vak hangot nem találtam erről (sem) a dokumentiációban.

  • floatr
    veterán

    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.

    Ilyen méretű és életciklusú projektek esetében megéri saját repot üzemeltetni. Nem gondolom h az ultimate build tool az ant lenne

  • floatr
    veterán

    Projektje válogatja, de ha egyszer szaladtál bele abba, hogy a local cache törlés után jöttél rá, hogy lelőtték a server-t, ami hostolta a lib-ed, akkor azért lehet futottak ki cifra dolgok a szádon.

    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.

  • BE4GLE
    senior tag

    Ettől féltem. (Próbálok többek, több kérdésére is választ adni, nem csak neked.)
    Amin dolgozom, az egy céges JAVA backend library. A valós feladat, hogy az ügyfél listákat tudjon létrehozni egy adott parent-child business object-ből (listánként vagy csak az egyik, vagy csak a másik). A listáknak azonban különböző saját tulajdonságaik lehetnek (jó lenne ha dinamikusan lehetne őket kreálni és nem kéne folyton a CD-t dolgoztatni), sőt maguk a kapcsolatok is változó változókkal bírnak. Tehát egy BO többször is szerepelhet a listában, ha a kapcsolatnak mások a paraméterei.
    Az egyszerűen menne, hogy lepéldányosítok egy közös interfészt, de az nem oldja meg, hogy minden új típusú listára új osztályt kéne csinálnom. Ha csinálok egy lista osztályt és abba dobok egy "tömböt" a plusz paraméterekről, akkor viszont azokat folyton cast-olnom kellene. Ezért gondoltam, hogy inkább csinálok ahhoz is egy marker interfészt, plusz bele az említett függvényt a lehetséges értékekkel és akkor a kliens oldalon nulla tudással lehet kezelni a dolgot.
    A backend-nél arra gondoltam, hogy ha foreign key-t szeretnék a különböző paraméterekre, akkor az macerásabb. Listatípusonként tudok csinálni egy táblát, a típusleíróba meg beírom a hozzátartozó tábla nevét, de kicsit mókolásnak érzem.
    De bármennyire is keresek, nem találok rá elegáns megoldást.

    Én ugyan mobil fejlesztő vagyok, de az a tapasztalatom, hogy az öröklődéssel szemben sokszor ésszerűbb kompozíciót használni. Nem tudom, hogy ez segít-e, de talán ötletet ad ahhoz, hogy másként közelítsd meg a problémát. Persze miután Google-öztél egy picit a témában. :B

  • btraven
    őstag

    Nem teljesen java, inkább OOP kérdés, amiben kicsit elveszve érzem magam.
    Vannak állataink, legyen mondjuk kenguru és tigris. Szeretnénk építeni egy cirkuszt, több ilyen állattal.
    A cirkusz igazgató le tud hívni egy állatlistát, amiben látja mindkét fajt és az adataikat, pl. születési év. Illetve ha kiválaszt egyet, akkor utasítást adhat pl. egy gombbal. Mindkét állat tud a farkán ugrálni, viszont a kenguru el is tud rejteni valamit az erszényében.
    A problémám, hogy sokak szerint egy instanceof mindig code smell. Akár leszármazást, akár kompozíciót használok, valahogy meg kell tudnom a lista egy adott elméről, hogy milyen többlet képessége.
    Hogyan lehet ezt szépen megoldani?
    Illetve lehet-e dinamikussá tenni az egészet, hogy kódváltoztatás nélkül új fajokat kreáljon az igazgató, amik saját "képességekkel" rendelkeznek?

    Ezt nem értem miért a java topikba írtad.
    De nézzük csak, kell egy oroszlánszelídítő. Artista meg bűvész is lehet. Meg kardnyelő. Bolhacirkusz.
    Bohóc viszont mindenképpen kell, akár kettő is.

  • BE4GLE
    senior tag

    Nem teljesen java, inkább OOP kérdés, amiben kicsit elveszve érzem magam.
    Vannak állataink, legyen mondjuk kenguru és tigris. Szeretnénk építeni egy cirkuszt, több ilyen állattal.
    A cirkusz igazgató le tud hívni egy állatlistát, amiben látja mindkét fajt és az adataikat, pl. születési év. Illetve ha kiválaszt egyet, akkor utasítást adhat pl. egy gombbal. Mindkét állat tud a farkán ugrálni, viszont a kenguru el is tud rejteni valamit az erszényében.
    A problémám, hogy sokak szerint egy instanceof mindig code smell. Akár leszármazást, akár kompozíciót használok, valahogy meg kell tudnom a lista egy adott elméről, hogy milyen többlet képessége.
    Hogyan lehet ezt szépen megoldani?
    Illetve lehet-e dinamikussá tenni az egészet, hogy kódváltoztatás nélkül új fajokat kreáljon az igazgató, amik saját "képességekkel" rendelkeznek?

    Az OOP-vel könnyű átesni a ló túloldalára és túlkomplikálni egy egyszerű problémát. Pl. ha a kenguru el tud rejteni valamit azt lehet simán relációs adatszerkezetként is értelmezni. X elrjeti Y-t. Ez akár tárolható egy táblában is. A kengurunak nincs szüksége "elrejt" metódusra. Az lehet egy tőle független metódus. Az ugrás szintén egyszerű. Hiszen olyankor mozgatod és animálod az állat objektumot. Nem feltétlenül kell tudnia magáról, hogy ő képes e ugrani. Az ugrás metódus majd eldönti, hogy az adott faj képes e rá. Mozgatja és keres hozzá egy animációt, ha van. Ez mind megoldható faj azonosítóval. Nem kell instanceof. Próbáld az adatszerlezeteidet minél egyszerűbre írni. Egy állat nagyon sok mindenre képes. Hatalmas osztályaid lesznek, kismillió őssel, ha ilyen szemléletben tervezed őket. És az végül mindig visszaüt.

  • Drizzt
    nagyúr

    Ráadásul ugyanezt meg tudom változókkal is csinálni, ugye?. Csinálok egy marker interface-t(AnimalAttribute), amihez hozzádobok esetleg egy getPossibleValues()-t és legrosszabb esetben kap az adott class egy wrapper-t. Így akár egy dinamikus listát is tudok csinálni, ahol a tigriseknek lesz Csíkvastagsága a kengurunak meg Erszénynyúlásiegyütthatója.
    "Szabad" ilyet?

    Szabadni szabad, de nem tul szep. Interface moge viselkedest illik rejteni, igy pl. azt, hogy miket tudnak csinalni az allatok, szivesen kiszerveznem interface-be, de azt, hogy milyen tulajdonsagai vannak az allatoknak, inkabb nem.
    A backend dolgot nem tudom itt hogyan erted.

  • Ráadásul ugyanezt meg tudom változókkal is csinálni, ugye?. Csinálok egy marker interface-t(AnimalAttribute), amihez hozzádobok esetleg egy getPossibleValues()-t és legrosszabb esetben kap az adott class egy wrapper-t. Így akár egy dinamikus listát is tudok csinálni, ahol a tigriseknek lesz Csíkvastagsága a kengurunak meg Erszénynyúlásiegyütthatója.
    "Szabad" ilyet?

    Belegondoltam és a változóknál bejön egy új aspektus, a backend.

  • BE4GLE
    senior tag

    Nem teljesen java, inkább OOP kérdés, amiben kicsit elveszve érzem magam.
    Vannak állataink, legyen mondjuk kenguru és tigris. Szeretnénk építeni egy cirkuszt, több ilyen állattal.
    A cirkusz igazgató le tud hívni egy állatlistát, amiben látja mindkét fajt és az adataikat, pl. születési év. Illetve ha kiválaszt egyet, akkor utasítást adhat pl. egy gombbal. Mindkét állat tud a farkán ugrálni, viszont a kenguru el is tud rejteni valamit az erszényében.
    A problémám, hogy sokak szerint egy instanceof mindig code smell. Akár leszármazást, akár kompozíciót használok, valahogy meg kell tudnom a lista egy adott elméről, hogy milyen többlet képessége.
    Hogyan lehet ezt szépen megoldani?
    Illetve lehet-e dinamikussá tenni az egészet, hogy kódváltoztatás nélkül új fajokat kreáljon az igazgató, amik saját "képességekkel" rendelkeznek?

    Szerintem az insteanceof önmagában még nem code smell. Kotlinban sem code smell az is operator. Sőt, ha használod, még smart cast-olja is az objektumot. A java azért más picit, mert ott neked kell cast-olni. Inkább azt mondanám, hogy könnyű code smell-t csinálni vele javaban. Például figyelni kell, hogy csakis final pointerre hívd meg, mert hiába csekkolod, hogy instanceof ha később változhat az object amire a pointer mutat.

  • Drizzt
    nagyúr

    Nem teljesen java, inkább OOP kérdés, amiben kicsit elveszve érzem magam.
    Vannak állataink, legyen mondjuk kenguru és tigris. Szeretnénk építeni egy cirkuszt, több ilyen állattal.
    A cirkusz igazgató le tud hívni egy állatlistát, amiben látja mindkét fajt és az adataikat, pl. születési év. Illetve ha kiválaszt egyet, akkor utasítást adhat pl. egy gombbal. Mindkét állat tud a farkán ugrálni, viszont a kenguru el is tud rejteni valamit az erszényében.
    A problémám, hogy sokak szerint egy instanceof mindig code smell. Akár leszármazást, akár kompozíciót használok, valahogy meg kell tudnom a lista egy adott elméről, hogy milyen többlet képessége.
    Hogyan lehet ezt szépen megoldani?
    Illetve lehet-e dinamikussá tenni az egészet, hogy kódváltoztatás nélkül új fajokat kreáljon az igazgató, amik saját "képességekkel" rendelkeznek?

    Tobbfele megoldas lehet, de talan a legegyszerubb az, ha csinalsz egy Activity osztalyt, ami leirja, hogy mit es hogyan tud csinalni az az Activity.
    Az allat osztalyban meg eltarolsz egy Activity Collection-t, amire csinalsz egy getter-t.
    Aztan az Activity-bol csinalhatsz mondjuk egy KangarooHidingActivity-t, ami a konstruktoraban megkap egy Kangaroo-t. A Kangaroo konstruktoraban meg megcsinalod a KangarooHidingActivity-t, meg a masikat es belerakod oket egy collection-be.
    Igy amikor vegigmesz egy Animal Collection-on, le tudod kerni az egyes Activity-k kollekciojat allatoktol fuggetlenul, azok az Activity-k meg megis kepesek lesznek allat specifikus dolgokat csinalni, az eppen megadott allaton.
    Azt nem tudom, hogy ez egy ismert pattern-e, meg van-e neve, de egyszeru esetben valami ilyesmit csinalnek. A Command pattern nagyjabol ez, de talan nem pontosan.

  • Szmeby
    tag

    Ettől egyáltalán nem kevesebb lesz az alapfeszültség, hanem pont hogy feltépi ezt a sebet szerintem. Kb. fél éve váltottunk pont rendszert amikor szembesültem az új névvel. A mai napig egy pillanatig nem merült fel bennem, hogy egy ilyen abszurd baromság lenne a háttérben. Azt a majmot amelyik kitalálta, hogy sikerüljön frissen megbélyegezni egy csoportot a nevükben mindenkire rámért többlet szívás miatt, beállítanám, hogy az összes HDD és ODD jumpert pingálja át kézzel.
    De jövő héttől, akkor majd légyszíves ne lehessen fekete ruhát kapni a boltokban, mert az egy általam nem ismert barátomat a nagymamája halálára emlékezteti és ettől traumatizált lesz. Ebben pedig "potenciálisan" a föld népességének 100% érintett, hiszen nagymamája még szegény Dollynak is volt.
    Baszki lemaradt: tátsz end préjörsz. Így már biztos minden rendben lesz!

    Már bocsánat, de nem mondhatod azt, hogy "fekete ruha". A kommunikációdban légy szíves az afroamerikai - esetleg rövidebben az afro - ruha kifejezést használni, mert ezzel megsértesz embereket. Tanulhatnál egy kis empátiát! (Kappa)

  • nevemfel
    senior tag

    Ettől egyáltalán nem kevesebb lesz az alapfeszültség, hanem pont hogy feltépi ezt a sebet szerintem. Kb. fél éve váltottunk pont rendszert amikor szembesültem az új névvel. A mai napig egy pillanatig nem merült fel bennem, hogy egy ilyen abszurd baromság lenne a háttérben. Azt a majmot amelyik kitalálta, hogy sikerüljön frissen megbélyegezni egy csoportot a nevükben mindenkire rámért többlet szívás miatt, beállítanám, hogy az összes HDD és ODD jumpert pingálja át kézzel.
    De jövő héttől, akkor majd légyszíves ne lehessen fekete ruhát kapni a boltokban, mert az egy általam nem ismert barátomat a nagymamája halálára emlékezteti és ettől traumatizált lesz. Ebben pedig "potenciálisan" a föld népességének 100% érintett, hiszen nagymamája még szegény Dollynak is volt.
    Baszki lemaradt: tátsz end préjörsz. Így már biztos minden rendben lesz!

    Dehogy tép fel ez sebeket. Semmi másról nem szól ez, csak a mostanában divatos nyelvi rendőrködésről. Mastercard, Master of Science, Master Chief ezekkel mi lesz?

    Jah, és ugye az intézményesült képmutató álszentkedés nem csak a mastert -> mainre akarja megváltoztatni, hanem a blacklist/whitelistet, blackbox, blackhat/whitehat , man hours -> person hours, sanity check -> coherence check, dummy value -> placeholder value, a megmentendő elnyomottak csoportja végtelen hosszú.

  • axioma
    veterán

    Itt nem arról van szó, hogy valaki mimóza-e, hanem hogy elfelejtettük Babitsot és egyre több a néma.
    Ha valakinek akkora lelki törése van, hogy egy reál szakon nem képes absztrakt fogalmakról személyes érzelmi befolyáltság nélkül társalogni, akkor kezeltesse magát. Nem hiszem, hogy az megoldás, hogy holnaptól átírjuk a halmazelméletet, mert Kolompár Eszmeraldát a kisebbségi hovatartozására emlékeztetik a részhalmazok.

    En szerintem eleg absztrakt gondolkodasu vagyok, de baromira nem latnek szivesen egy olyan nevezektant, amiben ami jo az pasis, ami rossz az noi megjelolest kap. Hidd el, abbol is lesz szovicc, me'g azoknal is akik amugy respektalnak, de kozben "csak a moka kedveert" viccbe csomagolva me'gis gunyolodik kicsit. Ez pont nem szakmai nevezektan, de tenyleg olyan mondta kozvetlen nekem aki "ferjen bele, ertse jol, ismer annyira hogy tudja nem gondolom komolyan" elv menten indokolta: a "mernokno"-vel az a problema, hogy az se nem mernok, se nem no.
    Vagy elozo munkahelyemen mikor kitort a covid, csinaltak egy kepregeny stilusu "tajekoztato anyagot", hogy letezik a cegnel mentalhigieniai segitseg, csakhogy a rossz pelda az egy no volt rozsaszinben macskaval, a jo pelda aki kisegitette az infoval/url-lel meg egy tesztoszteronbomba... holott a teljes ceg pasi-tultengeses volt (nem csak IT), megis ezzel abrazolta'k... eloiteletek erositesere tokeletes, kozben meg masik szalon ment ezerrel a DEI trening.

  • Ablakos
    addikt

    Ez egész jó ki feladat.
    Szóval a programban nem szerepel a 4. sorig "alma", ezért a közös String poolban sem.
    Mivel az 1. és 2. parancs a new kulcsszavat használja, ezért mindkét String a heapbe kerül.
    Az intern, amíg a pool-ban nem szerepel az érték, átrakja oda. Ergo az s1 átkerül, az s11 nem, az s2 pedig az intern után van, ez csak rámutat az s1-re.
    Ha felcseréled a 3. és 4. parancsot, az s2 már az s1.intern előtt megcsinálja az almát a pool-ban, így az intern nem fogja az s1-et átmozgatni, ergo 3 különböző memóriacímet foglalsz (1-et a pool-ban kettőt pedig a new-k miatt a HEAP-ben).

    Ki tudod próbálni ha az s11 és s2 közé is raksz "=="-t ;)

    Köszönöm szépen a magyarázatot! Az OCP-ben hasonlókkal szórakoztatnak. :(( Lesz vele küzdelem.

Új hozzászólás Aktív témák

Hirdetés