Új hozzászólás Aktív témák
-
floatr
veterán
válasz
bambano
#8148
üzenetére
Ha az üzemeltetés hozzáértő, akkor tudja, hogy melyik gépen mi van, és éppen mi fut
(#8147) RexpecT
Jaja, régebben scriptek halmaza gondoskodott az automatizált telepítésről, frissítésről. Most continuous integration a varázsszó. Projektet eleve így érdemes elkezdeni, mert anélkül mindenki csak szenved vele. -
#8143
floatr
veterán
WonderCSabo
#8141
floatr
veterán
válasz
WonderCSabo
#8141
üzenetére
A hiányos specifikáció egyedi megoldásokat szül
Napi szinten probléma -
#8140
floatr
veterán
WonderCSabo
#8139
floatr
veterán
válasz
WonderCSabo
#8139
üzenetére
Nekem épp ez jött le, hogy 5-ben maximalizálná a threadek számát. Nem is értettem ezt az 5 elemű iterációt
-
floatr
veterán
Bár csak hibernate-es projektjeink vannak, de ezt most próba nélkül én sem vágom. Jártam már vele úgy, hogy mentette a változásokat, meg úgy is, hogy nem.
(#8132) M_AND_Ms
A hibernate session egészen más állat. Nem szabad azt gondolni, hogy egy ORM művelet egyből DB művelettel is jár. Max a stateless session és a natív query az, ami garantáltan egyből elvégzi a feladatát DB-ben is. -
#8026
floatr
veterán
Aethelstone
#8001
floatr
veterán
válasz
Aethelstone
#8001
üzenetére
Rendben
A mi esetünk annyiban speciális, hogy a DBA megszabta h mivel exportálhatunk.
(#8006) mobal Ezeket a hipszter dolgokat sosem szerettem
-
#8000
floatr
veterán
Aethelstone
#7988
floatr
veterán
válasz
Aethelstone
#7988
üzenetére
Mert egy csak JDBC-s megoldásnál csak JDBC-t tudsz használni mindenre
Ha két qeryből áll a projekt akkor még vállalható, de efölött kezd kissé kellemetlenné válni a dolog.Régebben én is lázadoztam a hibernate használata ellen, találtam különféle félmegoldásokat, aztán be kellett látnom, hogy felesleges a széllel szemben cuccolni, pláne úgy, hogy azt is tudja, amiért lázadoztam, csak sokan nem tudják használni az eszköztárát megfelelően. Az élet kegyetlen...
-
#7987
floatr
veterán
Aethelstone
#7986
floatr
veterán
válasz
Aethelstone
#7986
üzenetére
Hasonló cipőben járunk, bár a CSV két teljesen különböző adatmodell közti átjáráshoz kell, és a DBA önkezűleg futtatja a generátort.
Mindegy, a kulcsszavak: stateless session, report query, native query meg hasonlók. Ezekkel egy migráció sem probléma, de ha egy nagyobb projekt része, akkor nem kell megőrülni a többi usecase esetében az alacsony szintű eszközöktől.
-
#7985
floatr
veterán
Aethelstone
#7984
floatr
veterán
válasz
Aethelstone
#7984
üzenetére
Feltételeztem, hogy vannak olyan elemek, amiket entitásként lehet kezelni. Ettől függetlenül tartom a dolgot, hogy két adatmodell közti átjárást is elég jól meg lehetne vele oldani, bár a DBA-k nálunk a migrációt scriptekben látják, amiben mondjuk van is valami, ha milliós nagyságrendű rekord csúszik át, az hálózaton elég lassú tud lenni.
-
#7982
floatr
veterán
Aethelstone
#7979
floatr
veterán
válasz
Aethelstone
#7979
üzenetére
Lehet rajta pörögni, de egyrészt a valódi bottleneck nem az ORM lesz, hanem a hálózati adatkapcsolat. Másrészt lehet jól és rosszul is használni, alacsony és magas absztrakciós szinten. Van olyan eszköze, amivel egy jdbctemplate sem lesz érdemben gyorsabb. viszont többféleképpen tud egyazon projekten belül is viselkedni, amire egy jdbctemplate nem képes.
Amúgy meg lehet nézni, hogy mekkora overhead egy projekt esetén, ha nem használnak épkézláb perzisztenciát. Ezt a legtöbb kliens ma már nem lenne hajlandó kifizetni. De ha annyira a data layer nanoszekundumain kell gondolkodni, akkor miért nem tárolt eljárásokban implementálja az, akinek ez fáj? Komolyan...
-
floatr
veterán
válasz
pvt.peter
#7977
üzenetére
Létezik az, hogy a VM memóriát pucol, betölt, lefordít, becache-el dolgokat, de az elméletileg első futtatáskor megtörténik. Ez a jelenség más infrastruktúrán is jelentkezik.
Azt viszont a teljesítményteszteknél érdemes megjegyezni, hogy mindig lesznek kiugróan rossz, vagy jó eredmények, ami nem igazán tükrözi a normál körülményeket. Használnak emiatt sokféle statisztikai mutatót, de nekem eddig a legjobban a medián jött be, az egyszerű átlagolás könnyen elvisz a málnásba.
Ja és természetesen lehetőleg kellően sok futtatás kell ahhoz, hogy valós képet kapjál. Ha az elsőt mondjuk eldobod, után mondjuk 10 mérés már sok esetben elég tud lenni.
-
#7975
floatr
veterán
Aethelstone
#7971
floatr
veterán
válasz
Aethelstone
#7971
üzenetére
Van nagyon jó hibernate performance oktatásunk, ha érdekel
![;]](//cdn.rios.hu/dl/s/v1.gif)
Ha egyszer ebben az életben még lesz valaha egy kis szabadidőm, akkor majd írok is róla. -
floatr
veterán
válasz
bambano
#7919
üzenetére
Na majd erre fogsz olyan válaszokat kapni, hogy nem győzöd kapkodni a fejed. Nekem olyan szempontjaim vannak hasonló problémákra, hogy legyenek az egyes rétegek teljesen különválasztva, magyarán ne legyen olyan hibrid megoldás, ami keveri a szerveroldali és kliensoldali technológiát (pl gwt). Legyen egy kliens oldali framework, és egy SOA backend. Nekem a Spring backend és az ExtJS jött be eddig a leginkább. Utóbbit azért használom szívesebben, mert nem dizájnerek találták ki.
Dinamikus formokat saját megoldással raktunk össze, akármilyen technológia is volt a frontenden. Ha a dizájn nem az egyedi brandelés irányába menne el, akkor ennél gyorsabb eszközt nem nagyon találsz. Már nem farokméregetésiből, csak eddig ezt tapasztaltam -
#7799
floatr
veterán
Aethelstone
#7798
floatr
veterán
válasz
Aethelstone
#7798
üzenetére
Nem tudom másol hogyan kalkulálnak a betanulási fázissal, meg a többivel. Ha full kezdőt vesznek fel és betanitják ~ fél év alatt, akkor sokszor jobban jön ki a ktgkeret, mintha egy elvileg kézett embert vennének fel. A másik része meg az, hogy itt is van egy szűrő, amin ha átmegy, akkor jobban jár mindenki egy jól kiképzett emberrel, mint évekig szívni egy problémás tudású fejlesztő kezét fogva.
-
floatr
veterán
Szerintem meg egyszerűen óvatosabban kéne bánnia mondatokkal, mert akik most jönnek, azoknak már halvány gőzük sincsen azokról az időkről, amikor a C++ modern nyelv volt. Már abba is beletörik a bicska, amikor elhangzik az, hogy "referencia szerint".
Az meg hogy egyes cégek hogyan interjúztatnak és vesznek fel embereket, nekem egyre viccesebbnek tűnik. Ezért elégeltük meg azt, hogy fél(re)képzett állítólagos fejlesztők jönnek csőstül (lehet a multik lehalásszák a piacot), és van saját képzésünk inkább.
-
floatr
veterán
Nagyon egyszerű a válasz: a @Component annotáció nem örökölhető, ellentétben a @Transactional-lel. Ha azt akarod h a leszármazott osztályod is a kontextusba kerüljön, akkor annak is meg kell adni az annotációt.
Ennek az az egyszerű oka, hogy a komponensek nem kerülhetnek be "véletlenül" a konténerbe, vagy csinálhatsz absztrakt osztályokat, amibe beletörne a CGLib bicskája
Bár lehet h félreértem a problémádat. Ha másra gondoltál, akkor szólj.
-
-
floatr
veterán
Na csak sikerült rombolnia a porszívóügynökéknek. Remélem ezzel sikerült szétzavarni a JCP-t is...
Oracle Wins Major Victory Against Google In API Copyright Case
-
floatr
veterán
válasz
RexpecT
#7555
üzenetére
A tanusítvány eleve gond lehet, de még azt is el tudom képzelni, hogy a tanusítványban az URL más, mint amit meghívnál, pl www van az elején.
Ha végképp nem boldogulsz, akkor a tanusítvány ellenőrzését ki lehet iktatni fejlesztés/tesztelés idejére:
// Create a trust manager that does not validate certificate chains
TrustManager[] trustAllCerts = new TrustManager[]{new X509TrustManager(){
public X509Certificate[] getAcceptedIssuers(){return null;}
public void checkClientTrusted(X509Certificate[] certs, String authType){}
public void checkServerTrusted(X509Certificate[] certs, String authType){}
}};
// Install the all-trusting trust manager
try {
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, trustAllCerts, new SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {return true;}
});
} catch (Exception e) {
;
}de ez csak tüneti kezelés
-
#7536
floatr
veterán
Oppenheimer
#7535
floatr
veterán
válasz
Oppenheimer
#7535
üzenetére
A Spring Data JPA önmagában kényelmes, de nézd meg a QueryDSL bővítményeit [link]
Ha egy kis időm lenne, valamit még írnék is róla...
-
floatr
veterán
Igaza van a többieknek a Writer osztályokkal kapcsolatban a doksi alapján, de:
public abstract class Writer implements Appendable, Closeable, Flushable {
...
abstract public void close() throws IOException;
...
}garancia nincsen rá h az implementációk meg is fogják csinálni.
public class FileWriter extends OutputStreamWriter {
...
}a FileWriter egy OutputStreamWriter "wrapper"
public class OutputStreamWriter extends Writer {
private final StreamEncoder se;
...
public void close() throws IOException {
se.close();
}
...
}namost a StreamEncoder nálam egy sun csomagos implementáció, a bytekód szerint úgy látom h meghív két flush jellegű metódust
void implClose() throws java.io.IOException;
0 aload_0 [this]
1 aconst_null
2 iconst_1
3 invokespecial sun.nio.cs.StreamEncoder.flushLeftoverChar(java.nio.CharBuffer, boolean) : void [64]
6 aload_0 [this]
7 getfield sun.nio.cs.StreamEncoder.encoder : java.nio.charset.CharsetEncoder [39]
10 aload_0 [this]
11 getfield sun.nio.cs.StreamEncoder.bb : java.nio.ByteBuffer [41]
14 invokevirtual java.nio.charset.CharsetEncoder.flush(java.nio.ByteBuffer) : java.nio.charset.CoderResult [71]tehát elvileg jó a cucc, ha a sort lezárod. Ennek ellenére én továbbra is aszondom, hogy ártani nem árt, ha használod a flush-t, ráadásul ha netán Writer helyett OutputStream-et használsz valahol, akkor megkíméled magad egy sunyi problémától.
-
#7478
floatr
veterán
WonderCSabo
#7476
floatr
veterán
válasz
WonderCSabo
#7476
üzenetére
public abstract class OutputStream implements Closeable, Flushable {
...
public void close() throws IOException {
}
...
}public
class FileOutputStream extends OutputStream
{
...
public void close() throws IOException {
synchronized (closeLock) {
if (closed) {
return;
}
closed = true;
}
if (channel != null) {
channel.close();
}
fd.closeAll(new Closeable() {
public void close() throws IOException {
close0();
}
});
}
...
}public
class FilterOutputStream extends OutputStream {
...
public void close() throws IOException {
try (OutputStream ostream = out) {
flush();
}
}
...
}A BufferedOutputStream az utóbbit terjeszti ki.
Ezért mondom azt, hogy kötelező a flush, mert van olyan implementáció, ami megcsinálja, van olyan, ami nem. Könnyű benézni. -
#7460
floatr
veterán
Aethelstone
#7459
floatr
veterán
válasz
Aethelstone
#7459
üzenetére
Szerintem az assembly tökre elfogadható. Láttál már forth kódot?
-
#7458
floatr
veterán
Oppenheimer
#7454
floatr
veterán
válasz
Oppenheimer
#7454
üzenetére
Nem csak most, régebben is.
(#7455) Aethelstone én ezt ebben a sorrendben toltam: többféle basic, assembly (z80), pascal, c, assembly (x86), c++, java. Aztán a többi sallang. A C++ okozott sokaknak fejtörést, láttam ahogy vért izzadnak, pedig akkor a template-ek még sehol nem voltak. Egyszerűen elvesztek az absztrakcióban, és nem tudták készség szinten használni. Ahhoz képest a pointerek nélküli C gyerekjáték volt
-
#7452
floatr
veterán
Aethelstone
#7451
floatr
veterán
válasz
Aethelstone
#7451
üzenetére
Uhh. A fősulin egy félévig gyúrták az évfolyam agyát C++-ra. A zemberek 90%-a meg sem értette, hogy mi ez az egész. Azok tudták követni, akiknek volt megfelelő előképzettsége (intézményesített/autodidakta)
-
#7450
floatr
veterán
Oppenheimer
#7449
floatr
veterán
válasz
Oppenheimer
#7449
üzenetére
Ne mondd ezt. Én GTK alatt maszatoltam pythonnal, és elég gyorsan lehetett látható dolgokat csinálni. Ha valaki nagyon bele akar kapálni a dolgokba, úgyis utána megy.
Praktikussági alapon nekem a JS talán az, ami minden szempontból jó lehetne, bár nyilván mindenkinek más áll jobban kézre.
-
floatr
veterán
válasz
dabadab
#7446
üzenetére
Ja, a python is elég jó kezdésnek. Vagy ruby
Amúgy pascalban is ott vannak a pointerek, de nem muszáj egyiknél sem használni, mint ahogy C-ben sem a malloc-cal kezd az ember.
(#7447) Oppenheimer kicsit feleslegesnek érzem az alacsony szintű dolgokat kezdésképpen. Egyből elmenne a kedve a kezdőnek mindentől. Kell valami, aminél kis ráfordítással látványos eredeményeket lehet elérni. Ezért is használták régen a BASIC-et assembly helyett
-
#7445
floatr
veterán
Aethelstone
#7444
floatr
veterán
válasz
Aethelstone
#7444
üzenetére
Teljesen mindegy milyen nyelvet választanak hozzá. Csak nem mindegy, hogy hogyan kezdik el. Pascal-t és C-t elkezdeni elég könnyű, a C++ és Java viszont kicsit nagyobb előkészületet igényel. Lehet h páran felhördülnek, de én akár JS-t is el tudnék képzelni első nyelvnek ilyen feladatokra. HTML-es babrálásokat már általánosban is tanulgatnak.
-
#7443
floatr
veterán
norbert1998
#7440
floatr
veterán
válasz
norbert1998
#7440
üzenetére
Mondjuk ezt az egészet én sem értem, hogy miért kell ezt így. Amikor gimis voltam az előző évezredben pascal-ban gyártottunk max 100 soros kódot, de ott már mindenféle algoritmus volt, amikell az alapokhoz. Jó hogy Javat használtok, de nem értem, hogy akkor először miért nem tanítják meg nektek azokat az alapokat, amivel nem csak gányoltok, hanem kezelhető minőségű kódot tudtok csinálni.
-
#7400
floatr
veterán
WonderCSabo
#7396
floatr
veterán
válasz
WonderCSabo
#7396
üzenetére
-
floatr
veterán
Elég gáz, hogy ez van:
new Long(1) == new Long(1); // false
new Long(1) == 1; // true
new Long(1).equals(new Long(1)); truevérgagyi
Akkor már oldják meg az operátor overloadingot, mert még az is jobb lenne.A servlet meg nyilván manapság nem cél, hanem az érthetőség miatt egy kis kitérő. Senki nem fog ma már servletet gyártani. A mostani projektben is amikor egy 10 évvel ezelőtti servletet akart valaki portolni, inkább REST WS-t ajánlottam, mert a framework miatt csak szopás lenne vele.
(#7379) jetarko semmi gond ezzel. Socket/RMI: hagyjuk; szálkezelés: fontos
De az alapok inkább fontosak, meg hogy mennyire mész utána egy problémának, ha belefutsz. Van olyan, aki csak ül és vár... -
#7374
floatr
veterán
Oppenheimer
#7369
floatr
veterán
válasz
Oppenheimer
#7369
üzenetére
Nem tudom, de szerintem mindenen végigmennek sorra, amitől érthetővé válik az enterspájz. Azzal a juniorral nekem kifejezetten jó tapasztalataim vannak, aki a csapatomba került.
-
#7367
floatr
veterán
Aethelstone
#7365
floatr
veterán
válasz
Aethelstone
#7365
üzenetére
Basszus ilyen nyakatekert példákon veszem észre, hogy mennyire sokat kell ahhoz tanulni, hogy készség szintjén tudja ezeket a dolgokat valaki. Ha jobban belegondolok a kollégám is hónapok óta képzi a juniorokat, és most értek el odáig, hogy servlet...
-
#7364
floatr
veterán
Aethelstone
#7357
floatr
veterán
válasz
Aethelstone
#7357
üzenetére
Vagy építene egy kontextust, benne map-be rendezett handlerekkel, sakko nincsen ilyen melléfogás
-
#7288
floatr
veterán
Sk8erPeter
#7286
floatr
veterán
válasz
Sk8erPeter
#7286
üzenetére
Sajnos láttam már miket műveltek a forrásban
Látszik hogy nagy code wariorok voltak a szerzők, de nem is a hosszútávú támogatás járt a fejükben, amikor megszülték a művüket. De ez elmondható elég sok frameworkről is. -
floatr
veterán
Hát néha a klingonos sem az. Nemrég fordult elő, hogy valaki addig kavart az SVN branch-ekkel, hogy olyan is LIVE-ba ment, aminek nem kellett volna. Szó szerint nem release volt, de még csak nem is szabadjára engedték, hanem megszökött. A QA csoport véres hullái rész meg csak azért maradt el, mert mire fizikailag odaért volna a PO, addigra lecsillapodott
-
#7283
floatr
veterán
Aethelstone
#7282
floatr
veterán
válasz
Aethelstone
#7282
üzenetére
Bár nem mai, de ha már igazi programozó: [link]
-
#7281
floatr
veterán
Sk8erPeter
#7277
floatr
veterán
válasz
Sk8erPeter
#7277
üzenetére
Bár emiatt mondtam, hogy megoldás kérdése, elsőre lehet h vacakul hangzik, de ha jön egy break-es megoldás, könnyen jöhet egy későbbi CR, aztán jön a többi break is. Ha az első beteszi a lábát a ciklusba, akkor megette a fene, én átírom inkább valami iterátoros cuccra, sakko lesz feltételed.
De nem akartam kötekedni, csak megjegyeztem, hogy a break rontja a kódot.
szerk: olyanok ezek a dolgok, mint a petárda. Kicsit pukkangatnak, sokan nem értik, aztán egyszer leviszi a kezed.
-
#7275
floatr
veterán
Aethelstone
#7272
floatr
veterán
válasz
Aethelstone
#7272
üzenetére
Én inkább vagyok híve egy olyan megoldásnak, ahol inkább a ciklus feltételeinek kiértékelésénél próbálod megoldani a kilépést. Nyilván lesz olyan eset, amikor nagyon nyakatekert lenne break nélkül, de sokszor csak rontja a support-ot.
-
#7271
floatr
veterán
norbert1998
#7268
floatr
veterán
válasz
norbert1998
#7268
üzenetére
A wildcard-os import egyszerűen bad practice. Néha gyorsabb megoldani valamit vele, de a mai IDE-k támogatják az import sorok generálását is; beírsz valamit, aztán vagy magától megtalálja, hogy mit kell beszúrni, vagy rákérdez, hogy melyiket a sok közül szeretnéd.
Viszont a break-es témában igaza volt, hogy azzal össze lehet kócolni a kódot rendesen.
(#7270) Sk8erPeter háááát... nálam a kódreview-n nem menne át
-
#7248
floatr
veterán
Oppenheimer
#7247
floatr
veterán
válasz
Oppenheimer
#7247
üzenetére
lyaly
Itt azért elkövettél pár olyan dolgot, amivel alá lehet vágni egy kitervelt rendszernek. Egyrészt - bár ismétlem magam - ez a generált kód... szerintem jobban jársz, ha egy kicsit veszed a fáradtságot, és megtanulod magad legyártani a kódot a táblák alapján, vagy fordítva.Ha már generáltál valamit adatbázis valami alapján, akkor nagyon észnél kell lenni, hogy mibe túrsz bele. Itt épp azzal babráltál, amivel nem kéne. Mellesleg nekem amiatt gyanús a metódusra akasztott annotációval, mert olyan, mintha félig, vagy egyáltalán nem értené, hogy máshogy akarod elnevezni. Ha már annotálod a cuccot, akkor az átláthatóságot is növeli, ha a mezőkre aggatod őket.
Az@Id mellé még odatenném a @GeneratedValue-t is, mert ezzel a legtöbb adatbázisnál tud auto increment-es típust használni.
-
#7243
floatr
veterán
Oppenheimer
#7242
floatr
veterán
válasz
Oppenheimer
#7242
üzenetére
Nekem a hibaüzenetből eleve az gyanús, hogy a táblában más néven keresi az ID-t, mint ahogy deklaráltad volna. A helyedben én az @Id és @Column annotációkat nem a metódusokra tenném.
Az meg a másik, hogy ha csak nem muszáj, én nem babrálnám a hibernate saját elnevezési stratégiáját.
Az org.hibernate.cfg.DefaultComponentSafeNamingStrategy nekem eddig minden problémámat megoldotta -
#7234
floatr
veterán
Aethelstone
#7232
floatr
veterán
válasz
Aethelstone
#7232
üzenetére
Amit eddig láttam, az alapján azt tudom mondani, hogy amint a projekt megéri a telepítési fázist kiderül, hogy bármilyen generált kódról is van szó, a fejlesztők csak becsapják magukat, hogy majd sokkal kevesebbet kell kódolni. Hihetetlenül észnél kell lenni, mert elég egy legyintés, hogy ez így majdnem jó, és oda minden előnye a generált cuccoknak. Ezt a legtöbben nem is látják, mert valamiért nem foglalkoznak a release utáni életciklussal. Ugyanez igaz a DTO-ra is, hogy leszámítva azt az 1%-ot, amikor tényleg kellene, csak felesleges karbantartási köröket, és kockázati tényezőt vezetnek be a projektbe. Az ember hajlamos elsiklani olyan problémák felett, amiket nem lát rögtön, mert kényelmes nem szembesülni vele.
Hibernate-tel már odáig jutottunk, hogy az összes előnye leredukálódott a bean alapú row mappingre, és az öröklődés kezelésére. Nem 1% az, amit kézimunkával kell megoldani, de erről már a múltkor beszéltünk a lazy-eager-dto témában.
Nálunk a legtöbb szívás a GWT-vel a frontend hibái miatt voltak. Még csak nem is a generált kód és a backend közti szakadék miatt. A frontendesek annyira sokat dolgoztak a minimális hibákon, hogy a végeredmény az lett, hogy vagy sikerült megalkudni a megrendelővel, vagy addig hegesztették böngészőnként a dolgot, hogy az összköltsége elszaladt egy bootstrap/foundation alapokra épülő jquery/sencha kliens + SOA backend mellett. Sajnos vagy sem, de eddig mindig ide lyukadtunk ki, akármi is volt a kiindulási alap.
-
#7230
floatr
veterán
Aethelstone
#7228
floatr
veterán
válasz
Aethelstone
#7228
üzenetére
Hát, bárhogy is nézzük a végeredmény ugyanaz, hogy kevesen tudnak jól bánni vele (már he lehet ilyenről beszélni
)Ilyen dolgokkal már sokszor találkoztunk, hogy jó valami, de senki nem tudja használni. Ergo, akkor mégsem annyira jó valami. Lehet h túl komplex, túl nagy a betanulási igénye, akármi... Arról mindenesetre meg vagyok győződve, hogy egy olyan team, ahol megfelelően le vannak osztva a szerepkörök, hatékonyabb tud lenni egy csak javas GWT-s csapatnál, ahol könnyen becsapják magukat az emberek, hogy nem kell frontendes.
-
floatr
veterán
Bizonyos fokig a compiler is átver. Még az elmúlt évezredben volt egy olyan hardveres problémája az x86-os prociknak, amikor bejött a pipeline, hogy bizonyos kódegyüttállás esetén az egymást követő utasításokat x lépésen belül egyszerűen nem tudta feldolgozni. Ezt a legtöbb C fordító korrigálta úgy, hogy te nem tudtál róla. Ez a pozitív része az átverésnek, ha jól csinálta. Volt azonban olyan C fordító, ami úgy optimalizálta a fordított kódot, hogy éppen belefutott ebbe a pipeline/cache hibába.
Itt viszont egyik nyelvről a másikra generál egy kódot, amit egy framework keresztimplementáció igyekszik elfedni. A dolog már ott sántít, hogy eltérő implementációkról van szó.
A hibernate/JPA által generált SQL-re inkább nem mondok semmit. Nem véletlen, hogy nagyon kevés a jó HQL/JPQL szakember, mint ahogy az sem, hogy a kritikus query-k mind natív SQL-ben készülnek, vagy tárolt eljárásban. Amit meg a proxy-kkal, ASM/CGLIB meg egyéb témával generálnak, az nem ugyanaz a nagyságrend, amivel egy Java-JS fordításnál szembesülsz.
(#7227) Aethelstone Ja hogy a parse-oláshoz beaneket, milyen igaz. Úgy szar ahogy van
)
Kézzel jobbat gyártottam, és ráadásul tudtam, hol kell a sallangot kicsapni.
De mondhatnád a spring boot-ot is, a hibernate entitás/schema generátorát, meg ilyenek. Nem akarom elvinni a témát a nagyzolás irányába, de ezeket ha tehetem kerülöm, mint a pestisest. Még talán a schema generátor elmegy, de azon is sokat kell utólag szöszölni, mire összeáll úgy, ahogy szeretném, mert nem lehet eléggé teletűzdelni metaadatokkal, hogy mindent normálisan megcsináljon. Sajnizom, hogy rossz véleményem van róla -
#7225
floatr
veterán
Aethelstone
#7224
floatr
veterán
válasz
Aethelstone
#7224
üzenetére
Figy, én eddig azt láttam, hogy valaki vagy az egyikhez ért, vagy a másikhoz. Az már fehér holló kategória, aki valamennyire konyít mindkettőhöz, és ez nem csak hazai jelenség. Irtózatosan híg a szakma, és nem biztos hogy csak a képzéssel van a baj (bár a kollégám, aki elég húzós tanfolyamokat tart, erről meg van győződve). A legtöbb gyíkarc meg sem érti, hogy mitől gurul az egész, vagy ha elcsípi, akkor menekül tőle, mert a JS nem elég tudományos. Erre mondom, hogy kliens oldali technológiát, csak arra megfelelő emberekkel szabad gyártani, és ezek az emberek nem feltétlenül kell h backendet is tudjanak gyártani. Ezek a hibrid megoldások olyanok, mint a 4 évszakos gumi.
Vagy használjanak jfx-et, az tudományosabbabb. (bár az is halódik elfelé)
Szerk.: amit generálásképpen említettél, az metaadatokat/leírókat generál, nem kódot.
-
#7221
floatr
veterán
Aethelstone
#7218
floatr
veterán
válasz
Aethelstone
#7218
üzenetére
Ezért mondom h dead end. Csak olyan frameworknek van értelme, ami nem új kódot generál, egyébként átveri a saját fejlesztőit is, mert kiveszi a kezükből a kontrollt.
-
#7217
floatr
veterán
Aethelstone
#7215
floatr
veterán
válasz
Aethelstone
#7215
üzenetére
Szerintem a GWT-t is hozzáadhatod a dead end kategóriához
Sok technológiával volt már dolgom, de az ügyviteli felhasználásnál, és az újabb fajta webes alkalmazásoknál a SOA-jellegű backend + "natívan" fejlesztett erős kliens volt a leghatékonyabb. Az csak plusz, ha a kliens oldal olyan framework-ökre épít, amivel napok alatt lefejleszted azt, amihez MVC-vel hónapok munkája kellett.
(#7216) Oppenheimer Ha valami beadandó cuccról/szakdolgozatról van szó, akkor én nem erőltetném a finomságokat
Nekem sem tudták értékelni, amikor én agyaltam rajta. Diplomamunkaként egy GIS alapú facility management megvalósíthatósági tanulmányt adtam le, ami még ráadásul az egyetem munkáját is megkönnyítette volna, és egy rakat diákot rá lehetett volna robbantani a témára szervezetten, mire a vizsgabiztos csak annyit kérdezett, hogy mi ez az egész -
#7214
floatr
veterán
Oppenheimer
#7202
floatr
veterán
válasz
Oppenheimer
#7202
üzenetére
A JSON generálásra céloztam. És így van, ha adatokat adsz-veszel, akkor több kommunikációval jár, ami hálózati probléma lehet.
Másik oldalról viszont ott van a fejlesztés és karbantartás. A Java legnagyobb előnye az előtte lévő nyelvekkel/rendszerekkel szemben, hogy gyorsan tudsz eredményt produkálni, pláne ha ilyen irgalmatlan nagy ökoszisztéma jár vele. Ha lábon lövöd magad egy olyan implementációval, amivel időt veszítesz, és rugalmatlanná teszed az alkalmazásodat, és mindezt a hálózati forgalom miatt aggódva, akkor pont a Java előnyeit áldozod be. Néha erre szükség van, amikor nagyon kritikus a teljesítmény egy adott vason, de nem minden áron.
Tegyük fel, hogy a kommunikáció régebbi MVC-szerű alapokra épül. Oldalak jönnek le sokszor feleslegesen, mire a teljes adatkészletet megkapod. Ha már valami ajaxos megoldást is használsz, akkor az overhead sokkal kisebb lesz; akkor bukik ki a leginkább, amikor egy eseményre több kérést kell lezavarnod. A teljesítmény a hálózat teljesítőképességén, és a protokollon is múlik. Ha viszont már websocket/STOMP klienst használsz, akkor megint eltűnik az overheadből egy elég nagy rész, mert a kapcsolat felépítésének a költsége nem terheli a további requesteket; gyakorlatilag eljutsz odáig, mintha egy ESB/JMS integrációs megoldást használnál, aminek a másik végén egy repository jellegű szolgáltatás ül.
Szóval ha engem kérdezel, csak magadat szívatod meg a DTO-kkal.
-
#7199
floatr
veterán
Oppenheimer
#7198
floatr
veterán
válasz
Oppenheimer
#7198
üzenetére
Legjobban akkor jöttem ki hasonló dolgokból, amikor az efféle collection-öket letiltottam a serialization-ből, és külön húztam le, amikor szükség volt rá. Ha egyből használnád is, ahogy ez nem éppen a legoptimálisabb, akkor is lehet callback/promise lánccal hívogatni a service-eket. Nekem ettől a DTO-s konvertálgatástól hidegrázásom van...
-
floatr
veterán
válasz
Ursache
#7135
üzenetére
Visszakanyarodva az eredeti felvetéshez -- mielőtt elmegy a topic a PH fórum szabályai irányába -- még ha van egy perzisztencia motorod, az is bele fog gabalyodni az oszlop nevekbe, mert nem fog tudni kötni semmilyen objektumot a resultset-hez jól, ha abban két azonos nevű oszlop van, pl.:
SELECT * FROM User u
INNER JOIN Company c ON c.id=u.company
WHERE ...Ha a User és a Company táblában is van egy name oszlop, akkor a visszakapott eredményben a User és a Company nevek értékei kavarodnak. Ha már csak egy natív SQL-t hajtasz végre, és egy Object[]-be kéred az eredményt, akkor is az egyik táblában lévő name értéke lesz mindkét pozícióban. Ezért van az, hogy minden mezőt felsorolnak és mindegyiknek egy aliast adnak.
-
#7115
floatr
veterán
Oppenheimer
#7113
floatr
veterán
válasz
Oppenheimer
#7113
üzenetére
Találtam neked egy persistence unitos összetettebb példát: [link]
-
#7105
floatr
veterán
Oppenheimer
#7102
floatr
veterán
válasz
Oppenheimer
#7102
üzenetére
[link] Egy válasz a sok közül
Amúgy a load-time weaving nem fog működni tomcat alatt. Egy kollégám hónapokig kesergett miatta. JUnit tesztben ment tomcat 8 alatt nem. Ha jól emlékszem 7-essel még ment a dolog.
De ha nem akarsz métereseket szívni a persistence.xml és tsai konfigurációjával, akkor miért nem csak springben rakod össze a datasource + JPA EMF csomagot?
<!-- setting up JPA EMF -->
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
p:dataSource-ref="dataSource"
p:packagesToScan="com.movietime.entities" >
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter" />
</property>
<property name="jpaProperties">
<props>
...
</props>
</property>
</bean>
<!-- Transaction Manager -->
<bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager"
p:entityManagerFactory-ref="entityManagerFactory" />
<tx:annotation-driven />
<bean id="persistenceExceptionTranslationPostProcessor"
class="org.springframework.dao.annotation.PersistenceExceptionTranslationPostProcessor" /> -
#7074
floatr
veterán
WonderCSabo
#7072
floatr
veterán
válasz
WonderCSabo
#7072
üzenetére
Bármi lehetséges egy adott szakterülettel kapcsolatban. Csak tudod az a baj, hogy a felsőoktatás arról szól, hogy mindenkit keresztbe-kasul szívatnak az adott tantárgyakkal. Én is vehettem volna hasznát sok dolognak az ilyen utility tantárgyakból (GIS, valódi informatika, digitális tervezések, logisztika stb) csak sajnos az általam látott életutak igen nagy részénél ez a szükséges tudomány megáll a középiskolai emelt szint végénél. Sőt...
Innentől kezdve azt tudom mondani, hogy eltekintve attól a ~10%-tól, az emberek nagy része az ablakon dobta ki az ideje nagy részét, mert nem terveznek algoritmusokat, nem gyártanak semmi olyant, ami az emelt szintű matematika, fizika, vagy az általános biológia, kémia, történelem tudásanyagát igényli. Sőt a hétköznapokban még csak ennyire sincsen szükségük. Nem azért mert tudatlan tuskók, hanem mert nem arról szól az élet, és a szakma java, amit szeretnének hinni ott, ahol oktatják.
A magam részéről a legdurvább gyakorlati matematikai feladvány az utóbbi időkben az ellipszis kerülete volt. Babzsákot hegesztettünk...
-
#7041
floatr
veterán
Aethelstone
#7039
floatr
veterán
válasz
Aethelstone
#7039
üzenetére
(#7040) Sk8erPeter
10+ évvel ezelőtt váltottam netbeansről eclipse-re céges policy miatt. Az megkönnyebbülés volt. Ez alatt a pár hét alatt alatt egész egyszerűen semmi sem működött úgy ahogy kellett volna. Kiszámíthatatlan volt, néha működött valami, néha nem. Egy maven projekt összeállításánál a spring lib függőségek verzióit összekavarta. A projektben a beágyazott javadb-t néha nem tudta elindítani. Néha nem fordított... nem egy production ready dolog..Nem mondom h az eclipse tökéletes lenne, de jobb. Netbeansben vannak jópofa "varázslások", amik marhajók, ha az ember nulláról tapasztalat nélkül kezd hozzá valamihez. Cserébe viszont instabil.
-
#7038
floatr
veterán
Aethelstone
#7037
floatr
veterán
válasz
Aethelstone
#7037
üzenetére
Most februárban egy hónapig használnom kellett a netbeans-t... hát basszus, megőszültem tőle. Nemtom kinek írják ezt, de nem nekem való.
-
#7036
floatr
veterán
Aethelstone
#7033
floatr
veterán
válasz
Aethelstone
#7033
üzenetére
Két lépés vissza?
-
floatr
veterán
Azért mert a tömbváltozó által megcímzett területen módosítasz, ami metóduson kívül és belül is ugyanaz marad. Viszont amikor a tömbváltozót nullázod ki, megint belefutsz ugyanabba a problémába, hogy a paraméter mint változó csak a másolata az eredeti változónak, ami referencia. Na
Jobban nem fogom tudni elmagyarázni
-
#6896
floatr
veterán
Aethelstone
#6894
floatr
veterán
válasz
Aethelstone
#6894
üzenetére
A jboss-deployment-structure.xml file-ban lehet definiálni, de talán van rá valami szabványos megoldás is a MANIFEST.INF-ben megadható dependency formájában.
Nem fogok most ennek utánajárni asszem, de én itt keresgélnék.
-
floatr
veterán
JBoss tud olyant, hogy egy közös war-ba lehet telepíteni a közösen használt libeket. Mondjuk az sem sokkal jobb megoldás, de kicsit furcsállom ezt a classloader összeakadást. Most nézem, hogy maven plugin is van arra, hogy egy konkrét war-ból kimásolja a libeket az újba jettyhez.
Én mondjuk tutira kitesztelném ezt a dolgot egy saját jarba forgatott singletonnal, ami logol mindent, ami az életciklusával kapcsolatos.
-
#6889
floatr
veterán
Aethelstone
#6882
floatr
veterán
válasz
Aethelstone
#6882
üzenetére
Akkor egy mongodb elég lesz alá. Vagy clusterben gondoltad?
-
#6881
floatr
veterán
Aethelstone
#6876
floatr
veterán
válasz
Aethelstone
#6876
üzenetére
Én első körben egy springet húznék alá, és a garázs management-et egy megfelelő perzisztenciával támogatott szolgáltatás végezné, a garázst elhagyó járműveket a fizetési felszólítás státuszba rakná, vagy archiválná
-
floatr
veterán
válasz
jetarko
#6859
üzenetére
Sajnos a szabadidőm érdeklődés hiányában egy ideje elmaradt, így nem tudok írni. Ha most sikerülne megoldani, hogy háromfelé osztódjak, akkor sem lenne elég, és ráadásul össze is vesznék magammal úgy, hogy egy ideig nem beszélnénk egymással
(#6858) Aethelstone naja, volt hogy dBase-ben ment az "ügyviteli" alkalmazás. Abban az időben a réteg a nikotin volt a billentyűzeten, amit kézhez kaptam.
-
#6857
floatr
veterán
Aethelstone
#6856
floatr
veterán
válasz
Aethelstone
#6856
üzenetére
Szerintem az a gányolás, amikor összevissza kell konvertálgatni, hogy kiküszöböljük az egyik rétegben a másik rétegből adódó problémákat
-
#6855
floatr
veterán
Aethelstone
#6854
floatr
veterán
válasz
Aethelstone
#6854
üzenetére
Lehet h nem jött le, de szabályozott init-re gondoltam, nem AS módszer szerint.
Annyi felesleges kört futottunk már ezekkel a dolgokkal, és mindig csak magunkat szívattuk meg azzal, hogy még ezt is optimalizálni akartuk. Ha annyira teljesítménykritikus az alkalmazás, hogy nem bír kivárni egy connection-nel annyit, hogy a jsp legyártja az output-ot -- ugye lefordított classról beszélünk itt is, akár egy controller/service esetében -- akkor ott már nem ezen fog múlni a dolog, hanem már magán a perzisztencián és az adatbázison. A jsp nagyságrendileg hamarabb végez, mint amennyi ideig tart az adat előállítása.Ha most egymás után lerajzolgatod egy grafikonra, hogy mi mennyi ideig tartott: pl. entity lekérdezés, 2-3 külön init, beanmap/reflection alapú konverziók kontra entity, 1-2 init, rakat println meg még 1-2 init, akkor az esetek nagy részében azt fogod látni, hogy a grafikonon a 100%-ból elég kis szeletet harap ki a JSP, akárcsak a konverziók. Ismerek olyanokat, akik képesek nagyon lassú JSP-ket gyártani, de ez szerencsére a ritkábbik eset. Még a velocity/freemarker feldolgozás is lényegesen gyorsabb, mint az IP alapú adatműveletek.
-
#6839
floatr
veterán
Aethelstone
#6836
floatr
veterán
válasz
Aethelstone
#6836
üzenetére
Magyarán DTO-t használsz két réteg közt a backenden. Nálam a review-n nem menne át
Mostanában legtöbbször SOA alapú rendszereket fejlesztünk, ahol web service-szerű cuccokig utazik az entitás. Ott a serialization-nel le van szabályozva, hogy mi mehet tovább. Szerintem bűn másodlagos, harmadlagos adatábrázolást ráhúzni egy működő struktúrára, ha van eszközöd normális módon kezelni a meglévőt, ráadásul épp ezzel csapod agyon az ORM-et, hogy a service-ig nem jut el a lényeg.
A teljesítményproblémákra azt tudom mondani, hogy persze hogy gyorsabb a háttérben egy SQL végrehajtása, mint többé (eager kontra lazy init), de csak mondom, hogy a hibernate/jpa önmagában egy nagy teljesítményprobléma.
A prezentációs réteggel kapcsolatban viszont nem értem mire gondolsz. Ha a kliens oldalra, akkor nyilván, de JSP-ben simán elfér egy implicit lazy init, amikor oda jut a sor.
-
floatr
veterán
válasz
jetarko
#6831
üzenetére
OpenSessionInViewFilter?
Már látom a tiltakozó kezeket, mert vannak rá elméletek, hogy ez miért nem tudományos, de nálunk majdnem mindegyik projektben ez van, vagy az EntityManager-es párja.
Sokat próbálkoztunk olyan paraméterekkel, ahol megadod, hogy melyik collection-t kéne szintén betölteni a dao-ban, de aztán mindig belefutottunk olyan esetekbe, ahol nem lehetett előre tudni, hogy melyikre lesz szükség, és melyikre nem, aztán betöltöttük mindegyiket - elég tudományos ez is.
-
#6798
floatr
veterán
Aethelstone
#6794
floatr
veterán
válasz
Aethelstone
#6794
üzenetére
in memoriam Donnie Brasco
(#6796) WonderCSabo random guglizással
http://mprabhat.com/2012/09/30/full-text-search-with-hibernate-search-4-1-lucene-and-jpa/De mysql natív query-vel is működhet a dolog. A LIKE meg csak akkor gáz, ha wildcarddal is kezdődik a kifejezés. De meg lehet oldani ezt úgy is, hogy pl elosztott nosql adatbázisban kérdezel körbe.
-
-
#6713
floatr
veterán
kornyiktamas
#6712
floatr
veterán
válasz
kornyiktamas
#6712
üzenetére
Akkor itt az ideje, hogy a kezedbe vegyed a dolgok irányítását, és nem hagyj mindent a tanárra, aki - elmondásod szerint - többet követel, mint amennyit ad. Az itt lévők nagy része vagy az alapoktól, vagy egy bizonyos szinttől kezdve autodidakta. Isten hozott a valóságban.
-
floatr
veterán
válasz
jetarko
#6639
üzenetére
FYI a message tag-en keresztüli adatkezelés úgy működik, hogy a properties állományt a classloader beolvassa egy map-be. Mivel semmi nem indokolja a dolgot, nem is tölti újra, de a memóriában tartja az adatokat. Ha "valami" megoldaná, hogy a map újratöltse magát, akkor teljesen mindegy hol tárolod kiindulásképpen.
Mint pl ez a megoldás: [link]
-
#6620
floatr
veterán
Aethelstone
#6619
floatr
veterán
válasz
Aethelstone
#6619
üzenetére
Höhö, indítsunk mozgalmat...
-
#6618
floatr
veterán
Aethelstone
#6615
floatr
veterán
válasz
Aethelstone
#6615
üzenetére
Nekem a generics példányoknál nem fáj az, hogy nincsen runtime generált osztály. Ami fáj, az az öröklési elvek sérülése, ami megint ilyen fordító hekkelés miatt van, mint amit a múltkor bedobtam az enumokkal, konstansokkal kapcsolatban. A nyakát szegik a nyelvnek.
-
#6614
floatr
veterán
Aethelstone
#6613
floatr
veterán
válasz
Aethelstone
#6613
üzenetére
De egész jól. Kéne még pár komment a témában
Mindenesetre nekem ez a fajta féltípusosság kicsit olyan nesze semmi fogd meg jól. A parametrizált osztályok és metódusok még az öröklődési szabályokat is átírják, ami azért gáz egy ennyire deklaráltan OOP nyelv esetében.
-
#6611
floatr
veterán
WonderCSabo
#6610
floatr
veterán
válasz
WonderCSabo
#6610
üzenetére
Bármit csinálsz, konverziókat kell majd használnod; akár hagyományos serialization-t, akár saját megoldást, akár perzisztenciát használsz. Mivel a runtime csak Objectet tud kezelni, a listába helyezéskor, értékadáskor nem tud hibát találni, csak amikor használnád az Objectet valamilyen típusként, amire nem lehet castolni.
Napi szinten probléma
![;]](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?:))
- Hp Elitebook 840 G8 CSAK 1DB POFÁTLAN ÁRON ÚJ KIJELZŐ!!!!
- Apple iPhone 16 Pro 1TB Fekete Titán Színben Bontatlan 12 Hó Garanciával
- Eladó konfig! Ryzen 7 7800X3D 2TB SSD 64GB DDR5 RX9070XT 16GB!
- Új, makulátlan állapotú Samsung Galaxy Buds FE, fehér, fél év garancia
- Új, makulátlan állapotú Samsung Galaxy Watch7 44mm ezüst, 2 év garancia
- AKCIÓ! ASROCK H310CM i5 9600K 32GB DDR4 500GB SSD RTX 3050 8GB DeepCool Tesseract SW 500W
- Xiaomi Redmi Note 10 Pro 128GB Kártyafüggetlen, 1Év Garanciával
- REFURBISHED - HP USB-C Universal Dock G1 docking station (DisplayLink)
- Samsung Galaxy S23PLUS 256GB Kártyafüggetlen 1Év Garanciával
- DELL Precision 7540 - Intel Core i9-9980HK, RTX 3000 (nagyon erős GPU-val)
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest