- Feltalálta a Google a keresőmotort
- Samsung Galaxy S25 - végre van kicsi!
- Fotók, videók mobillal
- Megvan a Xiaomi 17 Max bemutatójának dátuma is
- Samsung Galaxy S26 Ultra - fontossági sorrend
- Google Pixel topik
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Apple iPhone 17 - alap
- iPhone topik
- Bemutatkozott az iQOO első T-szériása
Új hozzászólás Aktív témák
-
Aethelstone
addikt
-
-
Aethelstone
addikt
-
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_"
Sikerült, nagyon köszönöm!
-
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. -
-
Foglalt név
addikt
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. -
yossarian14
tag
-
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
Hát igazából, ha már ott implementálja, akkor simán override-olhatja a compareTo metódust, és akkor üresen is hívhatja a sorted() függvényt.
-
Ö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. -
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... -
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... -
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... -
Aethelstone
addikt
-
Aethelstone
addikt
-
Aethelstone
addikt
-
A legtöbbször az a probléma, hogy senki nem akar fizetni egy refaktorért. Nem csak a kliens, de a szerződő oldalon is szívesen spórolnak ezzel.
Aztán jönnek a karbantartási problémák, és mindenki: *surprised Pikachu meme*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. -
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)
-
Aethelstone
addikt
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.
Nah jah, egyelőre nálam is hobbiprojekt. Céges melót nem bíznék rá egyelőre. Főleg úgy, hogy idea/eclipse már csukott szemmel is megy, itt meg sokat kell baxakodni
-
Aethelstone
addikt
-
Aethelstone
addikt
-
Aethelstone
addikt
-
Idea communityvel használom leginkább a gradle-t, de a vscode is elboldogul vele. Az eclipse-hez legutóbb plugint használtam, de az akkor fellelhető 2 érdemi implementáció eléggé használhatatlan volt számomra, pedig korábban eclipse user voltam.
Én már megszoktam egyébként hogy mindent parancssorból a legjobb használni
git-et is úgy nyomom. -
Aethelstone
addikt
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.Ok, de a kotlin, mint jelenség még mindig kisebb százalékát érinti a projekteknek. Egyrészt. Másrészt meg szerintem ha nem szokványos taszkok vannak, azok legtöbb esetben design problémák. De tényleg ugorjunk
-
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
-
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.
-
Sajnos szerintem ez csak akkor fut le, amikor tényleg kihúzták a számokat - viszont találtam a pythonhoz time-machine modult is - azzal biztos működnie kéne
-
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? -
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.
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. -
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. -
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.
-
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
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.
-
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.
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
-
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.Nálam igazán rohadt nagy projektektől kezdve microserviceekig minden van IDEA-ban, de sose crashelt még. Ha bármi mást kellene használnom, falnak mennék
(Pedig fejlesztettem Eclipseben is éveket, meg VSben is) -
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. -
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.
-
-
Nyilván... hosszú éveken át használtam Eclipse-t az összes hülyeségét nem sikerült kiismerni, mert ez is olyan, mint a Skyrim - vég nélküli kihívások. Volt már mindenféle fizetős edition a kezem alatt, egyik rémesebb volt a másiknál. Azt gondoltam, hogy az IntelliJ tényleg tud mást letenni az asztalra, de ez valahol törvényszerű, hogy minél összetettebb valami, annál nagyobb hulladék. Egyik sem érdemli meg, hogy rajongótábora legyen
Akkor marad a NetBeans.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Ne fanboikodjunk, kérem
Nekem az idea a gradle projektektől térdel le, néha azt sem tudja merre van a projekt, a debug tool katyvasz, a docker integráció meg rosszabb mint a command line, a gitet teljesen hazavágja egy merge-el, mate környezet alatt elveszti a menüjét. De legalább amióta van egy vadiúj laposom, egész gyorsan elindul.Mate nem az idea hibája gondolom, a többit meg pont máshogy látom. 1:1, mindenki azt használ amit akar - de ezt már beszéltük korábban. Szarkazmus volt
-
Relatív, hogy mi a csúnya
van egy interface a Data metódusoknak, meg egy custom implementációhoz, már ha kell egyáltalán.Annyit azért nem árt fejben tartani, hogy a @Transactional alap. Nem hozunk létre tranzakciót kézzel, nem nyitunk db kapcsolatot. EntityManager-t a legvéső esetben szabad csak babrálni. Helyette érdemes a projekciókkal csinálni, amit lehet.
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.
-
Namost ez egy elég hosszú téma, de röviden itt van egy példa, ami alapján tudsz hozzácsapni összetetteb dolgokat egy JPA repo-hoz. Ezt most csak egy text editorban dobtam össze, de a lényeg itt van. Van egy JPA repository-d, amit a framework majd implementál magának. Kell egy új interface, amiben a saját új metódusaid vannak. Ezt implementálod egy külön osztályban, valamint az új interface-t hozzácsapod a JPA repo-hoz az extends-ben. Innentől kezdve a PhotosRepo típust injektálod be mindenhová, mert a Spring ez alapján készít saját implementációt.
// létrehozol egy inteface-t a saját metódusaidnak
public interface PhotosRepoCustom {...}// meghagyod a Spring Data repository-dat is, de hozzácsapod a saját interface-t is
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long>, PhotosRepoCustom {...}// implementálod az új interface-t
public class PhotosRepositoryImpl implements PhotosRepoCustom {
@PersistenceContext
EntityManager em;
public List<A> findAllCustom() {
....
}
}De a @Query annotációval használhatsz JOIN FETCH-et is egy query metódusban pl.:
@Repository
public interface PhotosRepo extends CrudRepository<Photo, Long> {
...
@Query("SELECT a FROM A a INNER JOIN FETCH a.b b")
public List<A> find();
} -
Amikor meghívod a lekérdezést a Repository metódusban, az elkér egy aktuális sessiont az EntityManager-től. Mivel lazy, azon a ponton nem oldja fel a hivatkozást, csak egy B proxy-t kap az A objektum. Amikor visszakapod A-t, a session már ment a lecsóba, és hiába hívod meg a gettert, a proxy már nem találja a session-t.
Na többek között erre is való a @Transactional, mert megmondja az EntityManager-nek, hogy hol kezdődik a session lifecycle. Ha nincs @Transactional, akkor a Repository metódusban kéne inícializálni a lazy relációkat. -
-
Őszintén...?
DevOps-os szemmel nézve nem is szerencsés az IDE ilyen szintű integrációja. Ha nem oldható meg egy jól definiálható pipeline/toolchain segítségével automatizáltan még lokálisan is, akkor megette a fene az egészet.
Mondanám, hogy VS Code + gradle FTW, de a Red6 annyira elcseszett most valamit a Java bővítményen, hogy szinte használhatatlan. Addig meg Idea CE... -
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ó.
-
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ó. -
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
-
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
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] -
Ez a formátum YAML-ként is értelmezhető, így egy YAML parser be tudja olvasni, és akkor nem egy igénytelenül gányolt shell-ninja szutyokkal oldod meg, amit 1 év múlva a saját szerzője sem tud már támogatni.
De van rá lényegében kész megoldás is: ELK stack. Azt pont ilyenekre találták ki. Logstash illesztőkön keresztül Elastic-ba tolja a szenzorok adatait, amit később Kibanával meg tudsz jeleníteni. Ezt a shelles babrálást meg felejtsd el -
Egy rakat technológia frameworkje, jobbára nyúlás a kurrens "alternatív" frameworkökből. Ez mondjuk nem lenne baj, legalább ad neki egy standard keretet. A fájó igazság viszont az, hogy kihalóban van, és a "jobbik eset", amikor meglévő kód supportjára keresnek embereket. Amikor kerestem melót, a kapuban fordultam vissza, amint kiderült, hogy EE. Bár ez csak az én hülyeségem...
-
Ebbe most futottam bele teljesen véletlenül
@Getter@AllArgsConstructorpublic class MinMax {Optional<String> min, max;public static MinMax of(String[] arrayOfString) {var length = comparing(String::length);return stream(arrayOfString).collect(teeing(minBy(length),maxBy(length),MinMax::new));}}Ezt nem ismertem... le vagyok ragadva a java 9-10 környékén.
Viszont tetszik, köszi. [link] -
Már rég nem a sebességről szól a dolog
De ha már fun, akkor egy kis kihívás
Adott egy film (vagy bármilyen műalkotás), írjátok meg egy jellegzetes részletét Java-banDeathStar.getInstance()
.getGarbageMashers()
.stream()
.filter(gm -> gm.getLevel().equals(Level.DETENTION))
.forEach(GarbageMasher::shutdown); -
Már rég nem a sebességről szól a dolog
De ha már fun, akkor egy kis kihívás
Adott egy film (vagy bármilyen műalkotás), írjátok meg egy jellegzetes részletét Java-banDeathStar.getInstance()
.getGarbageMashers()
.stream()
.filter(gm -> gm.getLevel().equals(Level.DETENTION))
.forEach(GarbageMasher::shutdown); -
Alakul...
A végén szét lehet szerelni komponensekre, és lehet hozzá majd YAML konfigot írniA reduce a legegyszerűbb, de akkor hadd húzzak lapot 19-re
Arrays.sort(arrayOfStrings, Comparator.comparing(String::length));
String shortest = arrayOfStrings[0];
String longest = arrayOfStrings[arrayOfStrings.length - 1]; -
Szokás enterprise körökben túltolni a legegyszerűbb dolgokat is. Ha reduce helyett egy collectort használtál volna, no meg persze factory-kat, akkor lehetne kelteni kisebbfajta pánikot a juniorok között
Amúgy az első kérdésére csak egy reduce nem fog megoldást adni, vagy két streamet használsz, vagy egy collectorral párban gyűjtöd a min/max értékeket. De akkor meg minek...
Amúgy szerintem nincsen különösebb baj a streamekkel, amíg olvashatóan és ésszerűen van szervezve. A hármas operátort sokan nem szeretik, mert rontja az olvashatóságot. Én egyedül azt a gányolást utálom, amikor mindent be akarnak szuszakolni egy sorba. Na meg az enterprisify kódot
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.
-
-
Ezt a tiltósdi dolgot nem annyira vágom miért kell... Voltam már olyan projektben, ahol az 1.5-ös fícsöröket tiltották, mindenki menekült, semmi értelme nem volt. 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. Amúgy is kényszermegoldás volt, mert a JCP board impotens nyúlbéla volt hozzá, az Oracle meg pénzt akart belőle kifacsarni, nem fejleszteni.
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. Szerintem a legszebben megfogalmazott Java config is nehezebben átlátható, mint akár az XML. Egyik megoldás sem jó tisztán, nekem leginkább az XML+annotáció az, ami leginkább kezelhető.
-
Használtam már XML és Java configot is, de egy jól megtervezett struktúra és lombok használata mellett nekem: annotáció > XML > Java config. Utóbbi még üzemeltetési szempontból is aggályos
A tervezési hibával kapcsolatban meg lehet, hogy igazad van, bár ezzel szerintem csak akkor lehet hatékonyan megküzdeni, ha zöldmezős cuccról van szó.
(#10501) PeachMan én mindenképpen javasolnám. Nem árt ha mögé látsz, de nem attól leszel jó (junior) fejlesztő, hogy látod a biteket suhanni.
-
Használtam már XML és Java configot is, de egy jól megtervezett struktúra és lombok használata mellett nekem: annotáció > XML > Java config. Utóbbi még üzemeltetési szempontból is aggályos
A tervezési hibával kapcsolatban meg lehet, hogy igazad van, bár ezzel szerintem csak akkor lehet hatékonyan megküzdeni, ha zöldmezős cuccról van szó.
(#10501) PeachMan én mindenképpen javasolnám. Nem árt ha mögé látsz, de nem attól leszel jó (junior) fejlesztő, hogy látod a biteket suhanni.
-
Ja hát a split az teljesen gáz erőforrások tekintetében, de kreatív megoldásnak vicces
Menet közben rájöttem, hogy ha elé- és mögé vágok egy-egy mássalhangzót, akkor tökéletesen működik az is. De ha nagyon optimalizálni kell, akkor lehet elég elborult algoritmusokat írni, ami viszont már felveti az egész hasznosságát A reguláris kifejezésekről meg csak annyit, hogy volt már olyan h bekresseltettem böngészőket egy nagyobb szöveg parsolásakor, ha lehet kerülöm
-
Olyant is csinálhatsz amúgy, hogy egy stringbe betolod az összes magánhangzót, és indexOf metódussal ránézel. Ha optimalizálni akarod, akkor sorba rendezett karakterekkel logaritmikus kereséssel is mehet
Amúgy meg:
String text = ...; // a beolvasott cucc
long vowelCount = text.toLowerCase()
.chars()
.filter(c -> "aáeéiíoóöőuúüű".indexOf((char) c) != -1)
.count();
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Mac Pro 6,1 2013 Late
- GAMER PC! i7-14700 / RTX 5080 / 32GB DDR5 / 1TB NVMe / 1000w Gold / BeszámítOK !
- ASUS ROG Strix SCAR 16 / Ultra 9 275HX / RTX5090 / 32GB / 2TB NVMe! BeszámítOK
- 27% - Corsair RMx Series RM1000x 1000W 80 PLUS Gold (CP-9020271-EU) Tápegység!
- White AM4 félkonfig! ASUS ROG B550-A + Ryzen 9 5950X BOX + 32GB DDR4 3600Mhz CL17
- Eladó új állapotban levő Redmi Note 11 Pro 6/128GB kék / 12 hónap jótállás
- 27% - ÚJ - GIGABYTE RTX 5080 AORUS MASTER 16GB GDDR7 Videokártya! BeszámítOK
- BESZÁMÍTÁS! Apple Macbook Neo A3404 A18 Pro 8GB RAM 256GB SSD notebook garanciával hibátlan működés
- 27% - ASUS TUF Gaming X870-PLUS WIFI Alaplap
- AKCIÓ! Philips 223V5LHSB2/00 22 75Hz FHD TN 5ms monitor garanciával hibátlan működéssel
Állásajánlatok
Cég: aiMotive Kft.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest