- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- iPhone topik
- Apple Watch
- Mi nincs, grafén akku van: itt a Xiaomi 11T és 11T Pro
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Telekom mobilszolgáltatások
- Yettel topik
- 6 év biztonsági támogatást ígér a Motorola
- Ilyen lesz a Fairphone 6
- Íme az új Android Auto!
Új hozzászólás Aktív témák
-
#6609
floatr
veterán
WonderCSabo
#6608
floatr
veterán
válasz
WonderCSabo
#6608
üzenetére
Értékadáskor derülne ki a turpisság, nem olvasáskor.
-
#6604
floatr
veterán
WonderCSabo
#6595
floatr
veterán
válasz
WonderCSabo
#6595
üzenetére
Igazad van, az ilyen példányoknál teljesen eldobja a részleteket.
Mentségére legyen mondva (#6599) emvy a fordító rátalál minden olyan pontra, ahol hibát követsz el, ezért ez a része nem zavar túl sok vizet. Sőt engem még zavar is az, hogy mindenbe bele tud kötni. Az meg már a te dolgod, hogy figyelmen kívül hagyod, vagy SupressWarning-ot aggatsz rá.
-
#6594
floatr
veterán
Aethelstone
#6592
floatr
veterán
válasz
Aethelstone
#6592
üzenetére
Mondjuk engem azért végtelenül bosszant az, ahogy mostanában alakulnak a dolgok a való életbeli projekteken: a legdurvább bleeding edge technológia Liferay alatt struts. Kicsit tényleg olyan fortran 77-es feelingje van az egésznek
-
#6593
floatr
veterán
Aethelstone
#6592
floatr
veterán
válasz
Aethelstone
#6592
üzenetére
És ez saccra a lambdával is így lesz. Ettől függetlenül gagyi...
-
floatr
veterán
-
#6580
floatr
veterán
beleszólok
#6577
floatr
veterán
válasz
beleszólok
#6577
üzenetére
Amit nem látsz más nyelvekben az az, hogy hogyan van ténylegesen implementálva a "tömb". Javaban az ArrayList és tsai alacsony szintig követhetően implementált dinamikus tömb. Hogy most beírhatsz-e olyat, hogy list[2578] = "foo"; az egy dolog, a hátterében működhet sokminden:
-- pl operátor overloading, ami egy saját metódust hív, amikor [] operátort talál
-- egy automatikus memóriafoglalás a háttérben 2578 + buffer méretig
-- máshol egy hash-alapú map jön létreEz az egész rajtad áll vagy bukik, de elvárni sok automatizmust a nyelvtől azt fogja eredményezni, hogy vagy a fordító, vagy a végrehajtás lassú lesz. Az meg a másik, hogy sok értelmét nem látom egy ilyen műveletnek, bár lehetnek specifikus esetek nyilván; ide specifikus ötletek kellenek, pl. treemap.
-
#6570
floatr
veterán
beleszólok
#6566
floatr
veterán
válasz
beleszólok
#6566
üzenetére
Ez is csak szépészeti beavatkozás lenne, hogy operátor vagy metódus. Az mondjuk tény, hogy c++ alatt ott kezdődik a probléma, hogy a new is operátor, amit át lehet definiálni. Mondjuk én nem kuporodtam miatta sírva a sarokba, mert a java-féle heap-kezelést lehetett vele utánozni osztály - pointer osztály párosokkal, de részletkérdés, hogy a[5] vagy a.get(5). Iterátorokat többet használja az ember, nekem sem rémlik h mikor címeztem direktbe pozíciót utoljára.
-
floatr
veterán
válasz
bucsupeti
#6549
üzenetére
Minimum egy i5-ös, 8+GB RAM, egy jobb intel integrált video és 6+ cellás akku. Ez eléggé energiatakarékos is, hogy kábel nélkül pár órát tudd használni. SSD-ről nem tudok nyilatkozni, de kicsit még tartok az élettartamától -- nagyobb rendszerek, alkalmazásszerverek esetén jól jöhet
-
floatr
veterán
Alapvetően üzleti logikára koncentrálok a legtöbbször. Nekem kifejezetten jó, ha nullptr van, mert az exception megszakítja a tranzakciókat. Ha optional-t használnék akkor egy if-ben kéne eldobni a kivételt. A kapcsolódó rétegben try-catch néha szokott lenni, de legtöbbször azt is rábízom a konténer hibakezelésére, amit delegálok egy konkrét komponensnek. Ehhez képest az optional csak gurigázás a pamutgombolyaggal
Nem mondom, néha jobb választás lehet, mivel a kivételek kezelése nem feltétlenül cél. Ilyenkor a mechanizmus teljesítménye jobb tud lenni egy if-else megoldással, de ez inkább szépészeti megoldás. Ha valakinek ez problémát okoz, akkor el tudom képzelni ahogy egy merészebb JS frameworktől kifolyik a szeme.
-
#6546
floatr
veterán
Aethelstone
#6543
floatr
veterán
válasz
Aethelstone
#6543
üzenetére
Attól függ. Ha private adattagokkal smúzolsz, akkor kell egy kis dinamikus proxy (cglib, asm), és már megint lelépi a kiccsákókat.
-
#6544
floatr
veterán
Aethelstone
#6543
floatr
veterán
válasz
Aethelstone
#6543
üzenetére
Hú megint hitvita...
-
#6542
floatr
veterán
Aethelstone
#6541
floatr
veterán
válasz
Aethelstone
#6541
üzenetére
Hogy egy ismerősömet idézzem az ilyen kiindulási alapoknál: "ebből még bármi lehet"
De ahogy érzedAzért ez a "heavyweight" kissé molesztáló a springre nézve
ahhoz képest h a j2ee-nek annó ez volt a light alternatívája -
#6536
floatr
veterán
Aethelstone
#6532
floatr
veterán
válasz
Aethelstone
#6532
üzenetére
Én ezt springgel oldanám meg egy felhasználási területtől függő scope-ban élő beannel
(#6531) beleszólok globális változó mint olyan nem is szabad h legyen, mert nem menne át a kód review-n
A VM egyébként is moduláris a classloader tekintetében; szóval relatív a globális. Egy kontextusban lehet alkalmazásra nézve globális valami, de nem szabad elfelejteni, hogy több kontextus is szaladgálhat egy VM alatt. Workaroundként a public static változókat szokták néha használni, de nem bátorítanálak erre. -
floatr
veterán
Belezavarodsz, aztán hülyeséget csinálsz, mindkét esetben ugyanannyi haszna van a terméknek.
(#6516) beleszólok itt egy elég jó magyarázat az optional-ről [link] A funkcionális matyik imádják ezt is, de ha átfutsz az api nyújtotta lehetőségeken, akkor rengeteg körítés van ugyanazon probléma más megoldásához.
-
floatr
veterán
Nem igazán tudok egyetérteni ezzel az egész nullptr savazással. Van most is optional, de sztem amennyi energiát ráfordít az ember, annyival a null-t is lehet kezelni.
Az viszont kétségtelen, hogy egy gyakorlatlan ember könnyen benézi, de ugyanez az ember az optional-be is is belezavarodik.
(#6514) Cathfaern nullptr hibák kihasználásával konkrétan rövidebb kódot lehet írni, ha tudja mit csinál az ember
-
#6507
floatr
veterán
beleszólok
#6505
floatr
veterán
válasz
beleszólok
#6505
üzenetére
Nem javasolta, mert felülcsaphatná a start metódust, te meg nem javasoltad mert felülcsaphatná a start metódust. Most hogy mondod, télleg lehet h van gyakorlati jelentősége...
-
#6504
floatr
veterán
beleszólok
#6503
floatr
veterán
válasz
beleszólok
#6503
üzenetére
Ha olyan feladatod lenne, ami miatt a Thread-be kellene piszkálni, akkor nem java-ban kell implementálni. Nem is értem h miért nem final az osztály. Illetve értem ("that would break backward compatibility"), mert a legelső könyvek tele voltak Thread subclass-okkal.
A vitával kapcsolatban meg azért mondom h kötekedés, mert ugyanarról beszélt, mint te
-
#6500
floatr
veterán
Aethelstone
#6499
floatr
veterán
válasz
Aethelstone
#6499
üzenetére
A Thread semmiképpen nem lehet jó mint leszármaztatási alap, trust me
Amikor egy osztály olyanokkal van tele, hogy "native", és le akarod származtatni, akkor villog a felkiáltójel.Bár ettől függetlenül nem értem a kötekedését, teljesen értelmetlen.
-
#6487
floatr
veterán
beleszólok
#6485
floatr
veterán
válasz
beleszólok
#6485
üzenetére
Mert nem szálat akarsz létrehozni, hanem egy futtatható feladatot. A szálnak saját állapotai vannak, amihez a feladatnak semmi köze sincsen, ráadásul tervezési mintának is elég törékeny
-
floatr
veterán
Nekem hiányzik az operátor overloading, ha arra próbáltál célozni. Sőt a friend mechanizmus, és a valódi template-ek is. De ez a funkcionális bohóckodás -- mert ebben a formában az -- nem annyira. A javascript-féle closure is arra jó, hogy elkavard magad a scope-okkal. Nagyon észnél kell lenned, hogy nem rontsd el, és a supportja pedig sokkal drágább, mint a "hagyományos" megoldásoké. Egy épeszű PM nem szereti az ilyen kockázatokat.
-
floatr
veterán
-
floatr
veterán
válasz
Lortech
#6439
üzenetére
Amikor ellopták a java-t a J#-tól kezdve, az volt a cél, hogy mindenkit windows-ra terelnek. Ez a törekvés most tört meg, amikor az office-t kiadták ios-re, és ahogy látom folytatódik. De jól mondta anno trey, hogy 10 év múlva az lesz majd a jelmondat a ms-nál, hogy "mi vagyunk az open source"
-
floatr
veterán
Mehhehe. Kezdődhet a harc
![;]](//cdn.rios.hu/dl/s/v1.gif)
Microsoft starts to open source .NET and take it cross-platform to Mac, Linux
"The end goal for Microsoft and the Mono group is to jointly deliver an open-source, enterprise-ready .NET server implementation to Windows, OS X, and Linux."
-
floatr
veterán
-
#6383
floatr
veterán
Aethelstone
#6382
floatr
veterán
válasz
Aethelstone
#6382
üzenetére
MVC esetében kifejezetten problémás, hogy az útvonalak az osztályokban szétszórva vannak deklarálva. Ez baromira megnehezíti akkor a supportot, amikor egy útvonalat adnak a hibajegyben - mert mást nemigen tudnának. Lehetnek ütközések a projektben, két projekt komponenseiben, összeolvasztáskor; ezt egy külső konfig meg tudhatná oldani.
Az adatbázis kókányolás meg tűzoltás volt, nem tervezési hiba. Tervezni sok mindent lehet, de nem mindent. Ezért mondom, hogy nagy öngól az annotáció - konstans páros hosszú távon. Persze lehet nem egyetérteni, de eddig ezt tapasztaltam.
-
#6381
floatr
veterán
Aethelstone
#6380
floatr
veterán
válasz
Aethelstone
#6380
üzenetére
Transactional és függőség esetében is volt már, hogy konfiguráción kellett változtatni az éles környezetben - szerencsére XML-ben. De itt konkrétan az MVC-t említettem, ahol pl. konstansok az útvonalak. És bármennyire is nehéz elképzelni, volt olyan helyzet, hogy egy milliós méretű tábla esetében oszlopot kellett cserélni átmenetileg.
A kérdés csupán annyi, hogy kell-e ehhez a fejlesztő és egy fejlesztői környezet, egy teljes telepítés vagy a patchelés kockázata, ha este tízkor jön az email.
Szerk.: de nagyon elkanyarodtunk a témától. Nem vitatom, hogy kényelmesebb fejlesztéskor, de ugyanennyire szívás a későbbiekben.
-
#6379
floatr
veterán
Aethelstone
#6378
floatr
veterán
válasz
Aethelstone
#6378
üzenetére
Nomost itt kanyarodunk akkor vissza az hibernate marhaságaihoz, az annotált osztályokhoz. Ugyanezért nem csípem a Spring MVC annotációkat, meg a többit, mert mindent beéget a kódba, és a fenti példával élve esély sincsen rá, hogy ez bármennyire is kiszervezhető lenne anélkül, hogy eldobnád az annotációkat totálisan, miközben a szintaktika gyakorlatilag átver.
-
#6377
floatr
veterán
Aethelstone
#6367
floatr
veterán
válasz
Aethelstone
#6367
üzenetére
Az első felvetésben egyetértünk h kinek mi fekszik.
A második témában viszont úgy tűnik h elbeszélünk egymás mellett. Arra gondoltam első sorban, hogy az önmagában egy bődületes hiba, hogy egy kód fixen beégetett konfigurációt tartalmaz fordítás-idejű (de idétlen szó ez) konstansokat használó annotáció formájában.
Azt viszont nem tudnám megmondani, hogy hányszor fordult elő az, amikor a supporttal kellett vérre menően csatázni, és telepített alkalmazások alatt a konfigot és/vagy a DB-t változtatni. Véleményem szerint nem valóban enterprise-ready egy ilyen annotált kód. (függetlenül attól, hogy néha ráviszi a szükség az embert). Azon meg végképp nem segít semmi elmélet, hogy a nyelv szintaktikája és a fordító trükkjei nem kompatibilisek.
-
#6365
floatr
veterán
WonderCSabo
#6364
floatr
veterán
válasz
WonderCSabo
#6364
üzenetére
Tisztában vagyok a különbséggel, meg szerintem aki eljut arra a minimumra, hogy literál és metódus eredménye között van különbség, az is tudhatja, de épp a specifikáció, vagy annak hiánya a gond. Meg hogy nincsen olyan, hogy konstans.
(#6355) Aethelstone egyébként visszatérve arra, hogy mi számít tervezési hibának:
Gyakran fordul elő az, hogy egy külső erőforrásból adsz értéket egy static final változónak, ami "konstans" (Hogy most ez egy map-ben vagy közvetlen változóban van, az lényegtelen) Szintén static final "konstansokat" lehet használni az említett módon annotációban. Nemtom miért érzel ezzel kapcsolatban tervezési problémát.Ha pl egyszer XML-ben konfigurálsz egy hibernate modellt, másszor meg annotációban, akkor az annotáció lesz az a gyenge pont, ahol a kódba beégetett pl. táblanevet nem fogod tudni változtatni, miközben az XML-ben azt csinálsz, amit akarsz két futtatás közt. De ez csak egy példa a sok közül.
-
#6363
floatr
veterán
WonderCSabo
#6360
floatr
veterán
válasz
WonderCSabo
#6360
üzenetére
Ez nem lenne probléma, ha a nyelv meg tudná ezeket a dolgokat különböztetni. De nem a nyelv és a szintaktika tesz különbséget, hanem a megpatkolt fordító.
Mert lehetne egyszerű konstansokat implementálni a nyelvben, meg read-only (akár statikus) változókat, de ilyen nincsen, viszont van félig implementált generics (type erasure és agyonvágott öröklődés), felemás annotáció (a runtime annotáció vs fordításkor történő rendelkezésre állás), nyakatekert enumok (egyedi struktúrának álcázott Enum osztályok), lambdának álcázott Runnable osztályok, meg a többi ilyen nyomorult dolog. A tervezők persze védhetik a dolgot, mint az agresszív kismalac (kuss, én így szállok le), de valójában csak bénáztak a jelenlegi osztály leírók keretein belül.
-
#6358
floatr
veterán
Aethelstone
#6357
floatr
veterán
válasz
Aethelstone
#6357
üzenetére
Elcseszett dolgokat műveltek az 1.5-től kezdődően a java-val, függetlenül attól, hogy mit tervez az ember.
A múltkor egy olyan bakiba futottam bele, ami miatt a generic-es metódusok öröklése akadt össze, pedig a nyelv szabályai szerint működnie kellett volna, de megint csak a hakkolt fordítási procedúra összegányolt mindent. Szvsz ki kellett volna dobni a régi leírókat, és hagyni a kompatibilitást a vérbe, mert most tele van tervezési hibával az egész.
-
#6356
floatr
veterán
Aethelstone
#6355
floatr
veterán
válasz
Aethelstone
#6355
üzenetére
Ott a problémám ezzel, hogy így a konstans field a nyelv szerint ugyanaz, miközben kétféleképpen kezeli a fordító.
De FYI egy régebbi lib elrontott tervezési mintáját próbáltam átvágni -- mint kiderült -- sikertelenül
-
#6354
floatr
veterán
Aethelstone
#6353
floatr
veterán
válasz
Aethelstone
#6353
üzenetére
Most egyelőre vonatkoztassunk el az értelmétől
A nyelv elvileg megengedi, de a fordító hakkolás nem.
Amúgy szenvedtem valamivel, és ebbe futottam bele. De ha egy bárakármilyen statikus metódussal adsz neki értéket, akkor ugyanide lyukadsz ki.
private static final String BAR = FooUtil.getBarNameFromResource();
-
floatr
veterán
Öröm és boldogság. Néha olyan szép dolgokra akadok rá, hogy szinte elsírom magam tőle
@Foo("Bar")
tökéletesen működhet konstansokkal, pl.:
public class FooType {
private static final String BAR = "Bar";
}
...
@Foo(FooType.BAR)megoldással. Viszont ha a konstans másképpen kap értéket pl.:
public class FooType {
private static final String BAR = FooEnum.Bar.name();
}Akkor a fordító hanyatt esik az annotációnál. Gyönyörűen megoldották az enumok kezelését a visszafelé kompatibilis okossággal, hogy már majdnem működik is.
-
#6318
floatr
veterán
WonderCSabo
#6314
floatr
veterán
válasz
WonderCSabo
#6314
üzenetére
Mert rossz tervezési minta egy számlálót a magban babrálni, és nálam nem megy át a kód review-n
Egy számlálós iterációnál a supportos hajlamos átlépni afelett a tény felett, hogy a deklarált számláló a ciklus törzsében is írható. Emiatt is inkább célszerű iterátorokat, for-each megoldásokat használni
-
#6303
floatr
veterán
kemkriszt98
#6302
floatr
veterán
válasz
kemkriszt98
#6302
üzenetére
Sokféle megoldás van. A webapp hozzáférhet a filerendszerhez; feltöltheted http multipart-os file upload-dal könyvtárakba, amit a szerver szolgál majd ki. Tárolhatod adatbázisban is, ha elég erős DBMS van mögötte, akkor viszont neked kell gondoskodni arról, hogy kiszolgáld a kéréseket (kiszeded a képet, visszaírod a response-ba). Tárolhatod JCR-ben, de ha nagyon kigyúrtad magad a témában, akkor használhatsz valamilyen CMS-t (pl liferay
) is.Én az első kettővel megoldással barátkoztam a leggyakrabban.
-
-
floatr
veterán
Ha a krém a továbbiakban is hasonlóan akarja megoldani az 5-10%-ot érintő problémákat, ahogy eddig, akkor annak sokan nem fognak örülni. Minden egyes alkalommal, amikor valami forradalmit pakoltak bele a java-ba, vagy szabványosítottak valamit, mindig elővettek valami alapot (loptak), amiből ki tudtak indulni, és a végeredmény egy teljesen elborult, butított, kompromisszumos szutyok lett, de legalább tudományos volt, mintha egy egyetemi tanár akarta volna az élete oktatási anyagát összerakni.
A másik probléma, hogy a java-ba az eddigi koncepcionális újítások legtöbbször zavaróak voltak, és ha haladni is akartál volna vele, akkor a framework-ök tartottak vissza. Sajnos, vagy sem - tudomásul kéne venni azt, hogy a java nem nyelvi bravúrkodások miatt kapott eddig is ekkora hangsúlyt, hanem a rengeteg framework miatt.
-
#6241
floatr
veterán
Aethelstone
#6240
floatr
veterán
válasz
Aethelstone
#6240
üzenetére
Régebben én is szkeptikus voltam, de ahogy látom ahogy hígul a szakma, és kik mondják magukat java fejlesztőnek, neadjaég senior-nak, azóta úgy érzem, hogy az egyik legjobb ötlet volt a minták nyomatása.
-
#6239
floatr
veterán
Aethelstone
#6238
floatr
veterán
válasz
Aethelstone
#6238
üzenetére
És egy C/C++ fejlesztő ismerős kérdezte, hogy mi a fenéért nyomják ezeket a tervezési mintákat... hát ezért.
-
#6237
floatr
veterán
Aethelstone
#6236
floatr
veterán
válasz
Aethelstone
#6236
üzenetére
Ja, hát ez a kézimunka elég nagy marhaság a példákban, pláne hogy mindenki ebből tanulna a zinternetrül. Épp most tépem a hajam, hogy egy olyan projektbe ugrottunk be, amit olyan "szakik" készítettek elő, akik netes példákból ollózták össze a tudásukat.
-
#6235
floatr
veterán
Aethelstone
#6233
floatr
veterán
válasz
Aethelstone
#6233
üzenetére
JTA vagy sem, ha már Spring-et használ, akkor ott van a @Transactional(propagation=Propagation.SUPPORTS) vagy REQUIRED
-
floatr
veterán
A filter annyit csinál, hogy egyazon session-t fog visszaadni a request idejére. Ez akkor kellhet, ha lazy collection-öket használsz, de nem inicializálod őket a betöltéskor. Ilyenkor session hibával hanyatt esik az egész.
A tranzakció egy kicsit más, azt definiálhatsz többet is pl. annotációval a business layer-ben. Ha egy controller több business metódust használ, akkor több tranzakció is kifuthat menetközben.
(#6230) jetarko nem lassabb lesz, hanem néha feleslegesen végzi a munkát, több memóriát ehet stb. Amikor EAGER-nek definiálsz egy kapcsolatot, akkor a tulaj betöltése nem egy szimpla select lesz, hanem hozzáfűzi az összes kapcsolatot, és egy menetben tölti be az adatokat.
Amikor a size() metódust használod LAZY-vel, akkor külön SQL fut le a collection-re.Ami duplikálódást illeti, asszem itt már azért látszódik, az oka az egésznek. EAGER az összes kapcsolatod, ezért szépen sorban hozzáfűzi JOIN-nal a TEAM táblához a lekérdezésnél. 1 join esetében a TEAM duplikálódik, minden további join esetében viszont a hozzáfűzött táblák rekordjai is. Itt lehet kutya elásva. Valószínűleg több collection is duplikált adatokat fog tartalmazni emiatt az összesített SQL miatt. Amikor a példámban néztem, nekem csak egy one-to-many kapcsolatom volt, amiben a tulaj szűrve volt, a collection elemei pedig egyszer jöttek a select-ből. Ha több ilyen van, akkor a select egyszerűen ilyen hulladék eredményt ad.
Emiatt is érdemes lenne subselect-eket használni valamilyen módon. Mondom, én a filtert javaslom LAZY-vel
-
floatr
veterán
válasz
jetarko
#6225
üzenetére
Pedig nekem is van hasonló mapping pár, és nem látok benne hibát. Kipróbáltam a saját alkalmazásban átírni a collection-t EAGER-re, de akkor sem csinálta ezt. Azt még esetleg megpróbálhatnád, hogy egy teszt erejéig kiszeded az EAGER-t, és a korábban bemásolt kódrészletet kibővíted így:
public Team getTeamById(int id) {
Session session = this.sessionFactory.getCurrentSession();
Team t = (Team) session.get(Team.class, new Integer(id));
// ha lazy collection, akkor így betölti az elemeit egy második query-ben
t.getDrivers().size();
return t;
}Még esetleg azt tudom elképzelni, hogy dialect-függő a dolog. Én eddig mssql, postres és derby adatbázisokkal használtam, de csak elcseszett join-ok esetében találkoztam hasonlóval.
Annyit még érdemes megfontolni, hogy az EAGER típusú kapcsolatok nagyon oda tudnak vágni az alkalmazásnak, ezért is alapértelmezett a LAZY. Én mindenhol ezt használom, és inkább egy OpenSessionInViewFilter-t teszek a web.xml-be. Oda akkor viszont már kelleni fog tranzakció is meg egyebek.
-
#6221
floatr
veterán
Aethelstone
#6194
floatr
veterán
válasz
Aethelstone
#6194
üzenetére
Mondjuk sok támpontom nem volt, csak a kolléga kódja, ő meg égert használt annotációban
-
#6193
floatr
veterán
Aethelstone
#6190
floatr
veterán
válasz
Aethelstone
#6190
üzenetére
Eager-hez minek fetch?
Egyébként erre gondoltam, igen
-
#6183
floatr
veterán
Aethelstone
#6182
floatr
veterán
válasz
Aethelstone
#6182
üzenetére
Nomeg azt, ahol beolvassa az adatokat
-
#6155
floatr
veterán
PumpkinSeed
#6154
floatr
veterán
válasz
PumpkinSeed
#6154
üzenetére
Mondjuk ezek azért eléggé fontos dolgok, hogy hogyan definiálsz egy metódust, mik a kivételek. Ezek nélkül el sem érdemes kezdeni egy sort sem írni. Javaslom, hogy kapj elő egy könyvet java témában, vagy fuss végig az oracle gyorstalpalóján.
(#6146) jetarko szerintem nyugodtan végigfuthatsz azon a szálon, mert ezek a frontendek nem igazán kötődnek a springhez amúgy sem. Van aki a GWT-t és tsait favorizálja, van akinek az AMF jön be, van aki a tisztán JS alapú frameworkökre esküszik. De olyan is van, amikor a legjobb az AJAX és DHTML mentes megoldás, olyankor pl a bootstrap lehet a barátod.
(#6147) M_AND_Ms lassan írni kéne már egy összefoglalót, az ilyen kérdésekhez
-
#6145
floatr
veterán
WonderCSabo
#6144
floatr
veterán
válasz
WonderCSabo
#6144
üzenetére
Épp írni akartam, hogy
new StringBuilder(20).append(i).append(j);
-
floatr
veterán
Szerintem meg az amatőr, amikor a saját környezete szerint ítél meg mindent az ember anélkül, hogy megpróbálná elfogadni, hogy van olyan helyzet, amit nem látott még.
Az OS náciságról meg csak annyit, hogy a legtöbben nem imádnak egy OS-t, hanem problémásnak látnak egy másikat adott szempontok szerint. Adott szempontok szerint a win a legjobbabb, mert megy rajta a skyrim. Tapasztalatom szerint java alkalmazások, servlet és bean konténerek, de még egy szimpla AMP stack is észrevehetően pörgősebb binugzon - pláne 64-biten - de szerintem is felesleges ezen a témán pörögni, pláne ebben a stílusban.
-
#6088
floatr
veterán
Aethelstone
#6085
floatr
veterán
válasz
Aethelstone
#6085
üzenetére
Sun-os JDK volt.
(#6086) kispx ebben mondjuk van valami, főleg a sok kis file esetében, de az MSE is később került fel a gépre.
(#6087) Cathfaern ugyanaz a lapos, nem dual boot-os, egy későbbi ügyfél miatt kellett a win.
-
-
#6056
floatr
veterán
WonderCSabo
#6055
floatr
veterán
válasz
WonderCSabo
#6055
üzenetére
Én a google SVN-jét használom, az se pilótavizsgás...
-
-
-
#6029
floatr
veterán
PumpkinSeed
#6027
floatr
veterán
válasz
PumpkinSeed
#6027
üzenetére
Egyrészt érdemes használni akár netbeans, akár eclipse alatt az Organize Imports eszközt. Ha elfelejtettél valamit importálni, akkor megtalálja, és behúzza helyetted.
Másrészt a kód egyébként is sántít, mert String-et olvasol be, de már int típust adnál vissza. A Scanner-nek van olyan metódusa, hogy nextInt(). Inkább azt használd, vagy át kéne alakítani int típusúvá a beolvasott szöveget, mondjuk Integer.parseInt(input) metódussal.
Így a kód akár ennyi is lehetne:
return new Scanner(System.in).nextInt(); -
#6017
floatr
veterán
Aethelstone
#6016
floatr
veterán
válasz
Aethelstone
#6016
üzenetére
Eszembe jutott, hogy mekkorát szoptam a "Noun"-ok közvetlen definíciójának hiánya miatt, amikor egy JavaScript (of Verb) alkalmazásban funkcionálisan raktam össze egy szekciót. Amikor a funkció keres magának kontextust, ha nem talál -- na az már programozás
-
floatr
veterán
Ez azért nem menne át a review-n, mert az eredeti felvetés szerint (yyyy-)MM-dd formában van a dátum
Amúgy lehet h gyorsabb egy kicsit több aritmetikai művelet, mint néhány elágazás a pipeline miatt, de a cél szempontjából kevéssé releváns a teljesítmény többlet szemben az érthetőséggel és karbantarthatósággal. Amikor hasonlókat irkáltam, és később valakinek bele kellett túrnia, mindig az lett a vége, hogy újraírta, mert nem értette, pedig bazi büszke voltam arra a pár órajelre, amennyivel gyorsabb volt. -
#6005
floatr
veterán
Aethelstone
#6004
floatr
veterán
válasz
Aethelstone
#6004
üzenetére
Sokkal egyszerűbb ez, mint bármilyen másik nyilvántartás. Ott a file rendszer
-
#5965
floatr
veterán
Aethelstone
#5964
floatr
veterán
válasz
Aethelstone
#5964
üzenetére
Szvsz ez az alapvető problémája a GWT-nek, hogy nem az a vége, amiből elindulsz.
-
#5955
floatr
veterán
Aethelstone
#5954
floatr
veterán
válasz
Aethelstone
#5954
üzenetére
Vagy szerver, alkalmazásszerver, servlet konténer, struts, spring, hibernate
-
#5950
floatr
veterán
Aethelstone
#5949
floatr
veterán
válasz
Aethelstone
#5949
üzenetére
+1
Anno én is a sun tutorialokból szedtem össze a legtöbbet. Könnyen-gyorsan emészthető. Szerencsére sok framework követi ezt a dokumentációs példát.
-
floatr
veterán
Nagyjából ez, annyival kiegészítve, hogy ha az intervallumba beesik egy év vége, akkor a && helyett || kell. De én odáig is elmerészkednék, hogy a dátumból levágnám az évet, és még nyers formában stringként hasonlítanám őket össze MM-dd formában
(#5923) [rvilike] ha most egy soros kifejezéssel írja le, jobban tetszene?
-
floatr
veterán
Korábban főleg SQL-t, HQL-t és JPQL-t használtam, mivel én olyan sql-matyi vagyok. Amikor egy üzenet transzfer alkalmazást építettünk, kibukott, hogy a hibernate által biztosított elemi műveletektől megdöglik az egész, azért visszaálltunk SQL/HQL-re.
A criteria API-val kapcsolatban nekem annyi a nyűgöm, hogy egyszerű lekérdezéseknél nem sok értelme van. Összetettebb esetekben meg kezd a karbantartása vállalhatatlanná válni.
A QueryDSL kicsit átmenet a kettő közt. Algoritmikusan kezelhetőbb, mint stringet vagdosni, miközben a típusokra vigyáz, helper osztályokat on-the-fly generál, és nem utolsósorban szép kódot lehet vele gyártani.
-
floatr
veterán
Kb 40 sor formázott XML révén kaphatsz egy olyan környezetet, ahol ORM van, deklaratív a tranzakciókezelés, az egyszerűbb DB műveletek I/F metódus nevek alapján készülnek el, nem kell a példányosítással foglalkoznod, deklaratív az RPC, stb. Ja persze a web.xml-be is kell még vagy 10 sor
Ez a bazinagy XML 10+ évvel ezelőtt volt kifutó érv. Manapság egy valamirevaló alkalmazás saját konfigurációja terjengősebb, mint a kontextussal kapcsolatos infó együtt.Nem akarom ezt senkire ráerőltetni, de 17 év után nekem ide állt be az optimum. Még ha desktop jellegű fejlesztés is kellene, akkor is egy embedded stack-et rakok inkább össze, ha már DB kell, mert sokkal rugalmasabb, és végül az igények mindig meglódulnak a hálózatos/többfelhasználós irányba előbb vagy utóbb. Sajnos vagy sem, nagyon kevés a kivétel.
(#5897) raggg mindennek megvan a maga oka. Néha az, hogy szar az egész
-
floatr
veterán
-
floatr
veterán
Épp a gyakorlás az, amikor érdemes mindent kipróbálni.
Részemről:
- Gradle vagy Maven
- Spring
- legalább egy Derby szerver módban
- Hibernate/JPA
- Spring Data JPA
- QueryDSL
- Spring MVC REST controllerekkel, Security
- szigorúan csak embedded Jetty
- JQuery vagy Sencha ExtJS -- utóbbinál a vektorgrafika sem kihívás a nézőtér összerakásánálAbban mondjuk egyetértünk, hogy érdemes a tanulás miatt iteratívan újra átdolgozni a megoldást, de a desktopos részt én kerülném, mint a leprást.
-
-
#5860
floatr
veterán
Aethelstone
#5859
floatr
veterán
válasz
Aethelstone
#5859
üzenetére
Ha multi, akkor távbabrálásban jönnek a román, majd indiai kollégák. Ez van. A 10 órás marhaságra meg csak annyit lehet mondani, hogy tehetségtelen PM/architekt emberekkel is tele van a piac, emiatt van ez, meg hogy leprásként tekintenek sok helyen a 30+ családosakra, mintha az lenne a normális, hogy az ember bent éli az életét.
-
floatr
veterán
válasz
M_AND_Ms
#5856
üzenetére
Komoly cég megbíz olyanokat, akik bárhol keresnek.
Egyébként nem csodálkozok ezen, mert nem túl jó irányban alakult a piac az utóbbi években a furcsa felhozatal révén. Érdekes elvárások vannak mindkét fél részéről, közben csak hígul a szakma. Emiatt az értékesebb emberek gyakran elszállnak (többnyire emberileg), sokan kivándorolnak... Ez van.
Sok szerencsét a keresőknek! Szükségük lesz rá.
-
-
#5821
floatr
veterán
Aethelstone
#5820
floatr
veterán
válasz
Aethelstone
#5820
üzenetére
Framework-függő, de ha lombokot használsz, akkor tagonként 2 annotációval letudhatod a getter/setter metódusokat is
-
floatr
veterán
válasz
Lortech
#5817
üzenetére
Az osztály szerepétől függ, hogy mennyire kell Bean/POJO-szerűnek lennie. Ha adathordozó, akkor akár lehetnek publikus tagjai is akár set/get nélkül. Ha szolgáltatásokkal foglalkozik, akkor kevesebb set/get kellhet, de privát adatokkal. Ha egy komponens, akkor gyakorlatilag az interfész használatához szükséges set/get metódusokat szabad csak implementálni.
Egy ismerősöm c/c++ fejlesztőként sokat ekézte a tervezési mintákat, de épp az ilyen esetekben jól tud jönni a tanulási időszakban -- mint egy karate szakágban a kata.
-
-
floatr
veterán
Nálunk vannak belső téma-specifikus oktatások, de hasonló alapokon megy a dolog, mint az előbb említettek.
A legjobbat akkor teszed magaddal, ha a maradék idődben gyártasz magadnak egy példát, amiben végigviszel pár tutorialban leírt dolgot. Szeretik az aktív embereket, és kevesebbet kell majd másokat nyaggatnod egy idő után.
-
floatr
veterán
Tudom ajánlani az ExtJS kitchen sink oldalát és a Dijit demót, ha a részletekre vagy kíváncsi.
A core, az adatkezelés, a kommunikációs eszközök sokkal kidolgozottabbak az ExtJS esetében. A komponensek tekintetében a Dijit-nél az összkép elég lehangoló -- olyan mintha félbehagyta volna a tervező, és nem figyeltek volna az eseménykezelésnél a megfelelő sorrendekre.
Az ExtJS-nek nagyon erős a komponens modellje, és eléggé rágyúrtak az OOP-szerű programozási modellre. A Dojo az eseménykezelésre gyúrt rá, de nagyon nem mentek tovább. Az ExtJS komponensek tudása lényegesen nagyobb, és nem elhanyagolható az sem, hogy a Dojo dokumentációja messze elmarad az ExtJS-étől.
Az ExtJS gyengéje a custom design. Ha sajátot akarsz készíteni az összetett komponensekre, akkor az nagy meló. Amennyire látom a Dijit esetében ez kevésbé időigényes, bár az ExtJS alapkomponenseiből elég gyorsan lehet építeni saját összetett elemeket is.
-
floatr
veterán
Szerepkörről beszéltem, nem két főből álló teamről, és nem egy teljes projektről, de még csak modulokról sem. A projekten belüli egységnyi feladatok szerepköreinek felosztását próbáltam a felvetés szerint elmondani.
Mi most egy 19-fős projekten dolgozunk egy 3 + 2 modulra bontott projektben, osztott munkában két ismeretlen létszámú fejlesztőcsapattal dolgozó (khm) partnerrel. A feladatok leosztása specifikáció és interfészek mentén van bontva. A belsős csapat ráadásul földrajzilag is osztott. Van 1-2 frontendes, aki a kereteket adja meg, és utómunkákat végez. A feladatok jellege szerint vannak olyanok, akik csak backenddel foglalkoznak, de olyanok is, akiknek a backend + funkcionális frontend egyformán feladata. A helyzetet tarkítja, hogy más projektekbe is be vannak kisebb óraszámok szerint szervezve néhányan. Szóval ha erre vagy kíváncsi, igen kipróbáltam, és arról beszélek, nem amiről álmodok.
szerk: egyébként pont ERP-rendszereknél lehet jó választás az ExtJS, ha van olyan, aki ért hozzá.
-
floatr
veterán
Nem az én elméletem. Gyakorlatban nálunk ez úgy működik, hogy
- vagy egy ember hegeszti a backendet és a frontend funkcionális részeit, és egy "designer" előkészít/utánaigazít
- vagy két ember dolgozik egy specifikált interfész alapján. Az interfész alapján először egy "mockup" backend készül, így egy kis plusz melóval tudhatnak párhuzamosan dolgozni.
Előfeltétel a specifikáció, és hogy mindenki ért ahhoz, amit csinál. Ha a kettőből akár az egyik nincs meg, az nagyon fájó hiányosság tud lenni.
-
floatr
veterán
Ezzel már mi is sokat kínlódtunk, de egyelőre mindig oda jutottunk, hogy kicsit fel van hígulva a szakma manapság, és sok a töltelékember.
Amúgy pont amiatt mondtam az ExtJS-t, mert az inkább szól programozásról, mint kígyóbűvölésről. Akinek ez sem elég jó, annak ott vannak a generálós megoldások, meg a JSP-s szutykok (bár szvsz a JSP még rosszabb is mint bármelyik tisztán JS-framework)
(#5726) M_AND_Ms az elmélet nem rossz
-
floatr
veterán
Luxus, mert most láthatod, hogy valamire szükséged lenne, amit nem tudsz megkerülni. Persze játszhatod azt, hogy ameddig tudod, másra tolod, vagy ilyesmi, de mostanában egyre népszerűbbek azok, akik több dologhoz is értenek (vagy akarnak érteni).
Szerintem a javafx IS döglődik a többi plugines technológiával együtt. Gyakorlatilag mindenki JS-t használ.
ahhoz képest h a j2ee-nek annó ez volt a light alternatívája
![;]](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?:))
- Bundle topik
- Előrendelhető a OnePlus Pad 3
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Kompakt vízhűtés
- Hardcore café
- Milyen billentyűzetet vegyek?
- Rábólintott az EU, eltakarítja az illegális termékeket az AliExpress
- iPhone topik
- btz: Internet fejlesztés országosan!
- További aktív témák...
- 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
- Új, makulátlan állapotú Samsung Z Fold 6 256GB Tengerészkék, független, 2 év garancia
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- Telefon felvásárlás!! Samsung Galaxy S24/Samsung Galaxy S24+/Samsung Galaxy S24 Ultra
- BESZÁMÍTÁS! Gigabyte B450 R7 5700X 32GB DDR4 512GB SSD RX 6700XT 12GB Rampage SHIVA be quiet! 650W
- LG 65QNED87T / 65" - 164 cm QNED / 4K UHD / 120Hz & 3ms / HDR 10 Pro / FreeSync Premium / HDMI 2.1
- LG 42C4 - 42" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
- Beszámítás! Oculus Rift virtuális valóság szemüveg garanciával hibátlan működéssel
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest