- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: Samsung Galaxy S24 FE - tapasztalatok
- sziku69: Fűzzük össze a szavakat :)
- Argos: PH!arckép
- weiss: Pant* rant
- sziku69: Szólánc.
- Ndruu: Segíts kereshetővé tenni a PH-s arcképeket!
- borg25: Kórházi beszámoló
- MasterDeeJay: Natív 3Dfx Glide Windows11 alatt Voodoo1 és Voodoo2-vel.
Új hozzászólás Aktív témák
-
floatr
veterán
Nézd, én nem mondtam soha senkinek, hogy könnyű. Meg kell ezt is tanulni, és kell hozzá tapasztalat. Ha a "könnyebb" utat választanád, akkor vehetsz hozzá designer-t is, de azt is tanulni kell. Lehet jól csinálni, és lehet nagyon rosszul is. Több szintje van a frameworknek: class management, core, alap komponensek, összetett komponensek; utóbbit nem mindig érdemes használni épp hasonló okok miatt, mint ami a vaadin problémája is.
Debugolni, és pofozgatni szerintem lényegesen jobb, mint a többit, csak sajnos nem tudsz odaülni egy 2 órás gyorstalpaló után LHC-vezérlő GUI-t gyártani/debugolni. Megint csak sajnálatos - amitől sokan fáznak - hogy a JS-fejlesztésnek sok buktatója van a laza típusosság miatt. Ez van, ezekből tudsz gazdálkodni.
Mihelyst egy összetettebb UI-ra van szükséged, meg vagy lőve, bármilyen frameworköt használsz, mert vagy elrejt tőled olyan dolgokat, ami idővel kelleni fog, vagy rádönti. Nincs bölcsek köve - itt sem.szerk.: az MVC részét nem feltétlenül érdemes erőltetni, mert kiszervezi a komponensekből a működést, ami szerintem megint egy olyan hiba, ami a hagyományos frontend fejlesztés megszokásaiból ered.
-
floatr
veterán
Webes kliensnél? Erre nem fogsz jó választ kapni. Mindenki elmondja a véleményét
A generálás szvsz egyáltalán nem követendő. Manapság van pár divatos frontend platform: AngularJS, JQuery, Sencha Touch/ExtJS, Dojo, meg még sok más hasonló framework. Nekem ezekkel kapcsolatban az a meglátásom, hogy az első kettő elég ingatag, állandó pletykák keringenek a támogatásukkal kapcsolatban. A Dojo egy kicsit komolyabb háttérrel rendelkezik, de a Sencha-hoz képest kevésbé teljes termék.
A Touch/ExtJS nem egyszerű eset, ha tanulni kell, mert a tipikus frontendes számára érthetetlen, hogy szoftveres logikára épül (Java/PHP fejlesztők számára készült inkább), ezért sokan kerülik, bár nálunk ez van majd minden projektben. Sokakat az riaszt, hogy nem GPL felhasználáskor fejlesztői licenc kell hozzá, bár amennyi emberórát elpocsékoltak itt páran JQuery komponensek keresésével/illesztésével, abból kijönne pár licenc. -
floatr
veterán
Véleményem szerint egy webapp - akár tetszik, akár nem - saját kliens alkalmazást érdemel. A generált frontendekkel rengeteg probléma lehet, amit képtelenség kezelni akár egy böngésző/framework bug, vagy helytelen API használat miatt. Ha böngésző a kliens célplatform, akkor célravezetőbb, ha HTML/JS framework-öt használsz, abban felépíted a klienst, és SOA-ként használod a szerver komponenseit.
Egy GWT-t használó kollégám folyamatosan panaszkodott arra, hogy a generált kód böngészőspecifikus, és ráadásul sokszor hibás is, amit egy CSS ninja sem tud meggyógyítani.
Ha mindenáron Java-t akarsz használni, akkor applet/JFX/JaWS, bár őszintén szólva nagy luxusnak, önbecsapásnak vagy akár önhittségnek érzem azt, ha valaki képtelen kilépni a Java fejlesztői szerepéből.
-
#5687
floatr
veterán
Aethelstone
#5685
floatr
veterán
válasz
Aethelstone
#5685
üzenetére
Eddig erről volt szó. Hol voltál?
Mostanáig csak a liferay okozott problémát, bár az más területen is.Amúgy a scan vissza tud ütni nagyon, amikor az alkalmazás konfigurációja szét van szórva a csomagot forrásaiban. Sokkal könnyebb egy jól strukturált XML-t kézben tartani, mint egy sokemberes csapat annotációs munkáját. Persze ott vannak a review-k, de néha az sem véd meg az így eldugott dolgoktól. Arról nem is beszélve, ha menet közben kell gyógyítani valamit, akkor egy szövegszerkesztő hamarabb találódik egy szerver node-on az XML-hez, mint egy komplett build rendszer. Most nálunk egy ilyen épp aktuális volt.
-
#5684
floatr
veterán
Aethelstone
#5683
floatr
veterán
válasz
Aethelstone
#5683
üzenetére
Nézd, nekem az is megfelel, ha egy projekt indításakor egyszeri alkalommal összerakott 20-30 soros spring konfigurációért a csapat és a cég istenként tisztel, miközben azt motyogják, hogy "úriiiisten, ez hogyan működik"
-
floatr
veterán
Találhatsz ehhez hasonló rövid összefoglalókat, de teljes képet a referencia doksiból kapsz.
Saját tapasztalat alapján a konfigurációt érdemes XML-ben hagyni, a további dolgokat pedig a component scan-re bízni. Épp most futottunk bele egy olyan problémába, hogy liferay alatt néha elvesznek a bean-ek közti függőségi információk, ha annotációval vannak összedrótozva a hivatkozások, szóval óvatosan.
-
floatr
veterán
A NoSQL és az angular nagy divat mostanában, bár a divathullám végével visszakerülnek a helyükre. 70e rekord esetében max failover miatt kellhet DB cluster, de még az esetleges feature bővülésekkel számolva akár 70m rekord sem indokolná az elosztott tárolást. Viszont egy lucene esetleg jól jöhet és akkor random kulcsszó alapján is lehetne választani.
Mennyi pénzt el lehetne ezért kérni...
-
#5647
floatr
veterán
szcsaba1994
#5645
floatr
veterán
válasz
szcsaba1994
#5645
üzenetére
Bedobod egy beágyazott adatbázisba, és kiolvasod ID szerint
-
#5576
floatr
veterán
WonderCSabo
#5575
floatr
veterán
válasz
WonderCSabo
#5575
üzenetére
Nehéz váltani 10+ év SVN után. Egyrészt a megszokás, másrészt az SVN-ben már meglévő projektek irgalmatlan mennyisége.
-
floatr
veterán
Ez az egyetlen előnye a többiekkel szemben, meg hogy az eclipse artifact-okat automatikusan kizárja a kezelt adatok köréből. A merge-el kapcsolatban nemtom, hogy ez mennyire függ a klienstől, de futottam már bele cifra dolgokba. Ilyenkor a pesszimista branch-always nem a barátom.
Már régóta várom, hogy készüljön egy szemantikus verziókezelő
-
#5569
floatr
veterán
Aethelstone
#5567
floatr
veterán
válasz
Aethelstone
#5567
üzenetére
Azért bárki bármit mond, egy maven build shortcut 3%-al csökkenti az idegrángás okozta szemráncokat
-
#5566
floatr
veterán
WonderCSabo
#5565
floatr
veterán
válasz
WonderCSabo
#5565
üzenetére
Hát lehet h én néztem be valamit. Mindenesetre ehhez képest a maven plugin betonstabil.
-
#5564
floatr
veterán
WonderCSabo
#5563
floatr
veterán
válasz
WonderCSabo
#5563
üzenetére
Én azon buktam ki, amikor a subclipse már egy natúr branch/copy műveletnél is elhasalt. Nem akartam hinni a szememnek. Most azt csinálta legutóbb, hogy a menüpontjai 3-4 példányban szerepeltek a context menüben. Az azért elgondolkodtató, hogy ha ekkora kihívás az SVN csapatnak a saját kliensüket elkészíteni, akkor mennyire lehet megfelelő minőségű maga az SVN.
-
#5562
floatr
veterán
WonderCSabo
#5556
floatr
veterán
válasz
WonderCSabo
#5556
üzenetére
Szerintem egy ilyen projekt kezeléséhez elég a plugin. A subclipse-ről már nem mondanám el ugyanezt
-
#5561
floatr
veterán
Aethelstone
#5558
floatr
veterán
válasz
Aethelstone
#5558
üzenetére
Jajjmá, vegyed magadra
Gondoltam itt többek közt arra, amikor a plugin megoldja a problémád, aztán mégis van olyan, aki a kattintás helyett csak megnyit egy konzolt, hogy mvn package.
-
#5484
floatr
veterán
WonderCSabo
#5482
floatr
veterán
válasz
WonderCSabo
#5482
üzenetére
Odáig hirtelen el sem jutottam, ahogy rámömlött a forráskód, szori
(#5483) Aethelstone ebben a topicban hiénák vannak. Amit hibázol, szétkapnak
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#5480
floatr
veterán
Aethelstone
#5478
floatr
veterán
válasz
Aethelstone
#5478
üzenetére
Egyébként ha csak a logikáját átgondolod, akkor sem stimmelne a dolog. Ha csak megjelölné, akkor nem tudhatod, hogy mikor lesz 100%-osan az a pont, amikor lezárhatja a műveletet. Az iterációt bármikor meg lehet szakítani, nem csak a végén.
-
#5461
floatr
veterán
WonderCSabo
#5459
floatr
veterán
válasz
WonderCSabo
#5459
üzenetére
Ezekkel nekem csak az a problémám, hogy a "forradalmi" változásokat nehezen követi a kapcsolódó technológia, perzisztencia, szerializáció meg a többiek. A projektek meg még lassabban alkalmazkodnak.
Anélkül meg eléggé magának való -
#5444
floatr
veterán
WonderCSabo
#5433
floatr
veterán
válasz
WonderCSabo
#5433
üzenetére
Nem igazán hozzáállásnak mondanám. Ahol megfordultam, mindenhol az volt a probléma, hogy egyrészt ostomba tölteléktárgyakkal volt az időnk elcseszve, másrészt meg nem volt sok köze az anyagnak (oktatónak?) a valósághoz.
Emellett apró tényező, hogy sokan simán hozták a megfelelő szintet, amit elvártak, de nem sok közük volt a szakmához.Voltunk páran, akik magunktól tanultunk gyakorlatilag mindent. Kiszemeltünk pár tanárt akikkel együtt lehetett dolgozni, aztán annyi. Közülünk sokan dolgozni kezdtek fősuli/egyetem mellett.
-
#5401
floatr
veterán
Oppenheimer
#5400
floatr
veterán
válasz
Oppenheimer
#5400
üzenetére
Épp hogy a pénz miatt problémázik, mert elesett a semmirevaló j2me bevételeitől. Hogy mi lesz, azt egyelőre csak találgatja mindenki.
-
#5398
floatr
veterán
dangerzone
#5397
floatr
veterán
válasz
dangerzone
#5397
üzenetére
Csak tippelni tudok, de az utóbbi időkben belefutottam egy olyan hibába, hogy egy biztonsági szigorítás volt 1-2 hónappal ezelőtt a java egy automatikus frissítésével. Aki frissítette, az mind beszippantotta azt, hogy a NAV nem csomagolta újra a letölthető nyomtatványait. Ha ez a gond, akkor hozzá kell adni a NAV szerverét a megbízható források közé:
Start menü/Configure Java/Security/Edit Site List
és ide beírod, hogy http://nav.gov.hu
Ez akkor nekem segített pár site esetében. Remélem ennyivel megúszod te is. -
#5396
floatr
veterán
Aethelstone
#5395
floatr
veterán
válasz
Aethelstone
#5395
üzenetére
Nem a nyelv a probléma, hanem a kapcsolódó API-k. Itt pl. a java.lang csomag, és tsai. Ugyanez megvan természetesen a C#-al is. Mindennel
-
#5389
floatr
veterán
minimumgame
#5384
floatr
veterán
válasz
minimumgame
#5384
üzenetére
Első körben nem ártana tudni, hogy mit értenek szerver alatt. Saját készítésű szerver alkalmazást, vagy alkalmazásszerveres (servlet/EJB konténeres) alkalmazást?
-
#5376
floatr
veterán
WonderCSabo
#5374
floatr
veterán
válasz
WonderCSabo
#5374
üzenetére
Ja default implementációk és tsaik. Gondolom valakinek b...ta a csőrét, hogy sokat kell gépelni, ha több interfészt használt, vagy nem ment a többszörös abstract öröklés. Az élet kegyetlen. Kéne írni egy C++ szerű nyelvet, ami olyan szintaktikát és nyelvi elemeket használ, mint a C++, és úgy is viselkedik, mint a C++. Csak lassabb
Értem én, hogy húúú meg hááá, de amikor egy Project Lombok is hasznosabb dolgokat hoz, mint maga a main stream, ott azért már el kéne gondolkodni, hogy mit kéne újítgatni. Mindegy, legalább permgen space már nincsen
-
#5373
floatr
veterán
WonderCSabo
#5371
floatr
veterán
válasz
WonderCSabo
#5371
üzenetére
Természetesen a megváltó lambdára. Már épp azon gondolkodtam, hogy felhagyok a mesterséggel, és favágónak állok, de szerencsére megmentett a dolog...
-
#5370
floatr
veterán
WonderCSabo
#5369
floatr
veterán
válasz
WonderCSabo
#5369
üzenetére
Mennek az űrgammák?
-
#5337
floatr
veterán
Aethelstone
#5336
floatr
veterán
válasz
Aethelstone
#5336
üzenetére
Hát nem rossz az a C, ha az embert órabérben fizetik
-
#5334
floatr
veterán
kemkriszt98
#5333
floatr
veterán
válasz
kemkriszt98
#5333
üzenetére
Ha rám hallgatsz, akkor applet tutorial - skip
-
#5331
floatr
veterán
kemkriszt98
#5328
floatr
veterán
válasz
kemkriszt98
#5328
üzenetére
Az applet témakör nagyon speciális (meg elavult). Ha nagyon nem akarsz droidos emulátorral, meg kóddal próbálkozni, akkor írj először egy egyszerű AWT/Swing-es alkalmazást, vagy csak egy natúr java-s valamit. De ha android a cél, akkor szánd rá az időt, és ott kezdjed.
-
#5303
floatr
veterán
WonderCSabo
#5296
floatr
veterán
válasz
WonderCSabo
#5296
üzenetére
Ha választanom kéne static és singleton között, akkor inkább az utóbbi. Annyi problémát tud okozni a nem moduláris classloader miatt a static. Igazság szerint nem is a singleton mellett kardoskodok, inkább csinálnék egy bean kontextust, amiben az objektumok singletonként viselkednének, és saját számlálókkal/flagekkel kezelnék a dolgaikat.
Nem tudom, hogy a minta honnét jön, de nem tartom igazán jó ötletnek ebben a formában.Ha meg az egész logikáját nézed, akkor nem szimmetrikus a dolog. Amikor "létrehozod" az objektumodat, akkor a helper/manager/factory igazítja a számlálót. Amikor meg "zárod", akkor maga az objektum gondoskodik róla, hogy megfelelő értéke legyen. Ez így eleve nem kerek.
-
floatr
veterán
-
#5283
floatr
veterán
WonderCSabo
#5273
floatr
veterán
válasz
WonderCSabo
#5273
üzenetére
Értem én, hogy hogyan működne, csak azt nem, hogy miért. Mert tegyük fel, hogy a sUsageCounter is adattag, és nem statikus. Akkor a getHelper-nek adattagként kéne babrálnia, vagy hívhatna egy open() metódust is, ami ezt az értéket kezeli. Sakko szimmetrikus is a dolog, pláne ha van valami szemaforos cucc is a két metódus körül.
Nem szabad halmozni a statikus dolgokat singleton esetében. Sőt, amióta springgel írom a hello world-öt is, azóta nem is nagyon használok igazi singletont sem. Itt persze más a dolog, de sztem hagyni kéne, hogy a singleton a nyitáskor is gondoskodjon magáról, ne csak a záráskor. -
#5272
floatr
veterán
WonderCSabo
#5267
floatr
veterán
válasz
WonderCSabo
#5267
üzenetére
Namost lehet h én értelmezem félre a kódot, de ha factory metóduson keresztül létrehozva az osztály egy singleton, akkor a példányváltozón kívül egyetlen további változónak sem kéne statikusnak lennie. Neme?
Vagy a példánnyal van a gondod? Mert arra olyan példákat láttam, hogy ahány osztály, annyi változó. Ha külön maganer van típusonként, akkor abban vannak a példányok tömbben, mapben miegymás
-
floatr
veterán
A hírverésre gondolok. Amikor a java 8 kerül szóba, akkor általában a lambdát tolják előtérbe, pedig az csak ~3 sornyi rövidítés. Az ebből profitáló API-k, mint pl a stream, csak sokadlagos tényezők, pedig ennek több értelme van, mint egy anonim osztály shortcutnak.
Mindegy, nem akartam ebbe belefolyni, mert felesleges vita. Csak sokan teljesen becsavarodnak ettől a lambdás dologtól, mintha valami olyan történt volna, amitől más irányba kering a Hold.
-
floatr
veterán
Persze, az api egy dolog, de nem azt tolják, hanem a lambdát. Az meg csak ennyi; lett pár új operátor, meg egy kicsit rövidebb a kód, cserébe könnyebben bele lehet zavarodni.
Ez a default cucc is elég érdekes, amikor többszörös öröklés jön elő. Veszélyes vizekre tévedtek ezzel.
-
floatr
veterán
válasz
tothpetya
#5230
üzenetére
Ennél lényegesen gyorsabb szvsz intézőben sem lesz, max ha másik file rendszert használsz. Másoláskor csak annyit tehetsz, hogy bejárod a fát. Mozgatáskor van annyi előnyöd, hogy egyazon partícióba nincsen fizikai mozgatás, csak a megfelelő bejegyzés(ek) átírása.
Kis file-ok másolásakor nem az USB3 teljesítménye igazán a szűk keresztmetszet, hanem a filerendszerbeli módosítások okozta pozicionálások. Sokszor a puffert sem olvassa tele az első lépésben sem.
-
#5224
floatr
veterán
Aethelstone
#5221
floatr
veterán
válasz
Aethelstone
#5221
üzenetére
Az az egyetlen probléma, hogy nem látom, mit csinál az ő kódjában a Files.copy(). Ami nálam a meglévő library-kben van, egy JBoss-féle implementáció, és nem foglalkozik azzal, ha ott van valami.
public static void copy(File source, File target, byte[] buff)
throws IOException {
BufferedInputStream in = new BufferedInputStream(new FileInputStream(
source));
BufferedOutputStream out = new BufferedOutputStream(
new FileOutputStream(target));
try {
while ((read = in.read(buff)) != -1) {
int read;
out.write(buff, 0, read);
}
} finally {
Streams.flush(out);
Streams.close(in);
Streams.close(out);
}
int read;
}Ha sok kicsi file-t kell másolni, akkor az feltételes végrehajtás érezhetően gyorsabb, mint a kivételkezelés. Lehet h ugyanezt megteszi, így egy kicsit nehéz saccolni. Mindenesetre a size() könyvtárakra nem működik, max a módosítás dátumával okoskodhat, de az sem tud normálisan működni, ha túl mély a fa.
Szerk.: Ah látom 1.7-es NIO.
-
floatr
veterán
válasz
tothpetya
#5218
üzenetére
Ilyesmire gondoltam, nem teszteltem:
private static void prepare(File src, File dest, List<File> from, List<File> to) {
File f, d;
for (String p : src.list()) {
f = new File(src, p);
if (f.isDirectory()) {
d = new File(dest, p);
d.mkdir();
prepare(f, d, from, to);
} else {
from.add(f);
to.add(new File(dest, p));
}
}
}
private void copy(List<File> from, List<File> to) {
Iterator<File> itrFrom = from.iterator();
Iterator<File> itrTo = to.iterator();
File ff, ft;
int size = from.size();
for (int i = 0; itrFrom.hasNext() && itrTo.hasNext(); i++) {
ff = itrFrom.next();
ft = itrTo.next();
if (ff.length() != ft.length() || ff.lastModified() < ft.lastModified()) {
Files.copy(ff, ft);
}
// show progress: i/size
}
} -
floatr
veterán
válasz
tothpetya
#5215
üzenetére
Amikor egy alkalmazás lekérdezi a könyvtár méretét, akkor vagy shell parancsot használ (ami nem túl hordozható megoldás), vagy szépen végignyálazza rekurzívan a belsejét. A leggyakrabban azt szokták csinálni, hogy a megadott útvonalat első körben beolvassák egy nagy listába, és minden elemhez tárolják a méretét, és az utolsó módosítás dátumát. A könyvtárakat nem is feltétlenül szükséges ebben a listában tárolni, mert az mkdirs rekurzívan létrehozza azokat, vagy esetleg a feltérképezéskor érdemes lehet már eleve létrehozni őket. Aztán második menetben összehasonlítod a méret/dátum értékeket, és ha nem stimmel, akkor másolsz. Akkor már csak a lista elemein kell végigfutni, és tudsz becsülni végrehajtási időt is.
-
#5200
floatr
veterán
WonderCSabo
#5197
floatr
veterán
válasz
WonderCSabo
#5197
üzenetére
Az van, hogy kidobnak egy új verziót, ami kvázi használhatatlan, ha egy hello world-nél összetettebb projektet akarsz kezelni. Aztán fél évre rá már tarthatatlan a sok bugreport miatt a helyzet, és kiadnak egy javítást SR1 néven, majd később a megmaradt nem kritikus hibák javításaira is adnak ki egy második javítást SR2 néven. Közben elkezdik összerakni a következő release-t. Szóval ha stabil Eclipse-re vágysz, akkor ahhoz az SR2 kiadások állnak a legközelebb, bár kicsit elgondolkodtat ez a frissen felbukkant java 8 támogatás.
Az a bosszantó, hogy az első kiadást soha nem tudtuk munkára fogni, mert annyira hemzsegett a hibáktól. Nem is értem, hogy ezt is miért nem hívják publikus bétának.
-
#5192
floatr
veterán
WonderCSabo
#5188
floatr
veterán
válasz
WonderCSabo
#5188
üzenetére
Kétségtelen, hogy a smiley lemaradt a végéről, akként kéne kezelni is. Azért mondom, hogy RC, mert eddig minden új verzió hemzsegett a hibáktól. Az 1.7 realease fordítója alatt összeszakadt pár apache eszköz
A lambdáról meg vagy jót vagy semmit, így inkább hallgatok
-
floatr
veterán
válasz
LonGleY
#5178
üzenetére
Most néztem meg, hogy említetted. Kb fél napja dobták ki, de még nem mindenhol lehet leszedni
A gépemre egyelőre biztos hogy nem szedem le, de a másik laposon könyvelés fut, ott biztos hogy vár egy darabig. A múltkori frissítés is odavágott neki többek közt valami újonnan bevezetett hiányzó policy file miatt az abevjava-nak. Azt hittem, hogy leszúrom magam, amikor benyaltam.
szerk: akkor írd oda, hogy frissítése nem javasolt
-
#5164
floatr
veterán
WonderCSabo
#5163
floatr
veterán
válasz
WonderCSabo
#5163
üzenetére
Szvsz ez az ECJ szempontjából nem hiba, egyszerűen csak gördülékenyebbé akarja tenni a folyamatos fordítást.
Télleg, ha ant buildet indítasz Eclipse alatt, akkor melyik fordítót használja? Elvileg a beállított JDK-ét, nem?
-
#5157
floatr
veterán
WonderCSabo
#5155
floatr
veterán
válasz
WonderCSabo
#5155
üzenetére
Nincs mese, kell egy különálló sebzés manager
No de viccet félretéve a toronynak nem sok köze van elvileg a találat pontosságán kívül az elért hatáshoz. -
#5153
floatr
veterán
Aethelstone
#5152
floatr
veterán
válasz
Aethelstone
#5152
üzenetére
Sőt. Egy igazi torony tud hibázni is. Lőjön mellé
És a mozgó támadók meg kapjanak becsapódási eseményeket, és aszerint döntsenek a sérülésről.
Ilyen szimulációt simán elbírnak a mai procik. -
floatr
veterán
Hát nehéz ehhez így bármit is írni kapásból. A PATH és JAVA_HOME változókat be kell állítani, hogy minden tudjon normálisan működni. Az osztály nevének és a file nevének egyeznie kell, meg sok ilyen apróságnak tűnő dolgon tud elcsúszni az egész.
Ott látom inkább a legnagyobb problémát, hogy normális IDE nélkül már nem is dolgozik senki. Nem is érdemes. Vagy egy Eclipse, vagy egy Netbeans a minimum, amiket sajnos alapszinten meg is kell tanulni használni. Érdemes egy hétvégét rászánni, ha tényleg akarsz vele érdemben foglalkozni.
-
#5135
floatr
veterán
Aethelstone
#5134
floatr
veterán
válasz
Aethelstone
#5134
üzenetére
C/C++ esetében az IDE nem volt az embernek annyira barátja, hogy volt értelme használni. Java esetében már nem sokat tesz hozzá az életminőség javulásához...
-
#5118
floatr
veterán
Aethelstone
#5117
floatr
veterán
válasz
Aethelstone
#5117
üzenetére
He...?
Az egyik rendszerünk egy rugalmas DM eszköz, ami többek közt emaileket is kezel. Kicsit besokalltam már az emailhez kötődő RFC-ktől, meg az olyan API-któl, amiket úgy raktak össze, hogy a fejlesztők nem tudtak kibukni az RFC-ben megfogalmazottak bűvköréből. Tény h lehetne még ennél is alacsonyabb szintű
Ezt a springes dolgot meg nemtom miért akarod a számba adni. Már jó ideje azt használom mindenhez.
-
#5097
floatr
veterán
WonderCSabo
#5096
floatr
veterán
válasz
WonderCSabo
#5096
üzenetére
Én sem szívesen írom meg, amire már van megoldás, de sokadszor futok bele abba a problémába, hogy egy futó projekt ~100MB libet tartalmaz, és egy új feature-höz csak amiatt be kéne dobni egy újabb MB-nyi valamit. Pláne hogy már egy másik implementáció benne van, de épp azt nem tudja, ami kéne.
A legszebb az volt, amikor egy volt kollégám egy ilyen alkalommal gondolkodás nélkül bevágott egy 20MB-os megoldást arra, hogy megállapítsa, hogy milyen mobilról érkezik-e felhasználó. -
floatr
veterán
A specifikusságot illetően nem feltétlenül értünk egyet. Amiről beszélek egy minimalista eszköz, de saját binding van mögötte, és egy kis átalakítással általános célra is lehetne használni. Inkább ott van nekem ezzel az egésszel problémám -- ami viszont igaz a legtöbb ilyen eszközre -- hogy annyira sokrétű felhasználásra akarnak megoldást adni egy csomag formájában, hogy a library 90%-a sokszor csak felesleges ballaszt. Ez a maximalista hozzáállás nagyon rossz ötlet, mert ha ilyen elemekből építesz egy alkalmazást, akkor csúnyán elszalad az erőforrás használattal a ló. A Jackson is gázos ilyen szempontból, és az az érzésem, hogy maga a J2ME runtime is ebbe a zsákutcába futott bele.
-
floatr
veterán
A Jackson2 kicsit jobban illeszkedik a JRE-ben meglévő JAXB implementációhoz, meg lehet h elég lesz a core pár dologra.
Mondjuk én egy kicsit elborultam, amikor láttam, hogy mekkora böszme csomagokat építenek fel a feladatra. Egyszer régebben gyúrtam egy specifikus bindingot, és a forrása volt ~20kB, itt meg a jarok rúgnak többszáz kB-ra
-
#5082
floatr
veterán
WonderCSabo
#5078
floatr
veterán
válasz
WonderCSabo
#5078
üzenetére
Még azért egy darabig győzködnötök kéne, hogy ne húzzam a számat, viszont 30 soros String literálok/konstansok esetében már nem morognék.
-
#5077
floatr
veterán
WonderCSabo
#5073
floatr
veterán
válasz
WonderCSabo
#5073
üzenetére
Mondjuk ez nem rossz. Elég sok helyen látok ilyen összefűzős dolgot lecserélve StringBuilderes megoldásra, lp. SQL query esetén. Nyilván nem ver oda neki, lévén a DB és a kommunikáció jóval szűkebb keresztmetszetet produkál, de ezek szerint akkor kár lecserélni.
-
#5076
floatr
veterán
WonderCSabo
#5068
floatr
veterán
válasz
WonderCSabo
#5068
üzenetére
igaz
(#5069) [rvilike] nem akarom megvédeni, mert részben csak egy poén volt. A lényege annyi, hogy sokszor lehet belefutni ebbe gagyi konverzióba, amikor String összefűzés előtt implicit konverziót hív meg nem String típusokra, ami kicsit hibatűrőbb és több esetre is kiterjed, mint egy natúr toString hívás.
Viszont valós alkalmazásokban gyakoribb, hogy nem sysout-ot használsz, hanem valami logot, ami általában String paramétereket vár.(#5071) Karma volt egy olyan csoporttársam fősulin, akinek pokoli volt a kézírása, viszont ő maga simán el tudta olvasni. Aztán megláttam, hogy milyen kódot gyárt, és az is hasonlóan olvashatatlan volt
(#5070) Superhun ez egy kicsit amolyan semmirekellő optimalizáció, nem?
-
#5062
floatr
veterán
WonderCSabo
#5058
floatr
veterán
válasz
WonderCSabo
#5058
üzenetére
De ha nagyon siet, akkor az is megteszi, hogy
"" + km[i] -
floatr
veterán
válasz
MrSealRD
#4992
üzenetére
Első blikkre több dolog is az eszembe jutott. Mondjuk itt leírják, hogy hogyan lehet subnet mask-ot találni, az alapján meg végigszkennelheted a LAN-t.
De vannak olyan rendszerek, ahol az a bevált módszer, hogy egy központi szerverre jelentkezik be az össze kliens, hogy feladatokat kaphasson
-
floatr
veterán
válasz
Ablakos
#4987
üzenetére
Az ritkán szokta hozni az elvárt eredményt. Konkrétum nélkül annyit tudnék a dologhoz tenni, hogy GUI builder-ek nem szokták szeretni, ha belepiszkálsz, vagy más builder kódját akarod megetetni vele. Olyan is van, ami metaadatokat tárol a kódban, vagy járulékos fájlokban, és ha ezeket babrálod, kiesik a szinkronból.
-
#4984
floatr
veterán
WonderCSabo
#4980
floatr
veterán
válasz
WonderCSabo
#4980
üzenetére
Meg lehetne Spring-et is használni
-
floatr
veterán
-
floatr
veterán
válasz
MrSealRD
#4967
üzenetére
Őszintén szólva sosem rajongtam az újratöltésért. Párszor belefutottam abba a pofonba, hogy a classloader nem szabadított egy rakás dolgot, és 3-4 alkalom után bedöglött az egész. Ezt meg nem nehéz eljátszani gyorsan, mert pl módosítod a web.xml-t, elgépelsz valamit, és még gyorsan kétszer rámentesz.
A Tomcat mellé mindenesetre vedd fel a listára a Jetty-t is, nem tudom észérvekkel magyarázni, de nekem az jobban bejött. Talán annyi, hogy régebben kerestem web socket támogatást, és csak a Jetty-ben volt. Most már a Spring-ben is van
Mondjuk a két servlet konténer gyakorlatilag bármikor cserélhető, úgyhogy inkább tényleg azt kéne eldönteni, hogy EJB vagy servlet konténer kell. Spring mellé nem nagyon kell EJB, bár a JBoss-nak egy kicsit már összetettebb a management része. Tudtommal van valami diagnosztikai cucca is, de nem sikerült ezt még megtapasztalnom, az adminokkal meg nem vagyunk beszélőviszonyban
-
-
floatr
veterán
válasz
MrSealRD
#4939
üzenetére
Megpróbálom összeszedni majd a dolgokat hozzá pár napon belül
A spring MVC már nagyon nem az a fajta állat, amikor a java kódnak bármi köze is lenne a html-hez. A legegyszerűbb felállás az -- ahogy struts esetében is van -- hogy egy adott URL-en van egy osztályod, ami reagál valami interakcióra, vagy listákat készít (bármi), meg egy JSP, ami a művelet eredményei megjeleníti. Az osztály az adatokat request-ben tárolja, az oldal meg onnét veszi ki, esetleg használhatsz hozzá taglib-et, de a magam részéről már régóta kerülök minden ilyent, max ha nagyon ostomba browserre kell optimalizálni.
pl ki akarod listázni a felhasználókat:
http://szerverem/users.html --> a spring mappeli a requestet a megadott osztály egyik metódusára, az kipréseli a listát adatbázisból, requestbe pakolja, majd a megmondja, hogy melyik JSP jeleníti meg. A spring megkeresi a JSP-t, onnantól meg rajtad múlik, hogy mennyire használsz java kódot. Ehhez képest a REST WS csak egy kicsit egyszerűbb: a metódus objektumot ad vissza, amiből beállítástól függően a spring pl. Jackson-nal JSON-t tol át, aztán egy kliens összerak belőle egy listát.
Szépen el van választva egymástól minden. Én is utálom, amikor kavarodnak a dolgok. -
#4937
floatr
veterán
WonderCSabo
#4934
floatr
veterán
válasz
WonderCSabo
#4934
üzenetére
Amúgy nem értem miért ódzkodnak a spring MVC-től. Annyira egyszerű összerakni vele egy REST-es alapot, és bármikor jól jöhet az MVC egyéb képessége is, amikor a hagyományos JSP-alapú megoldás kerül elő néha, amolyan biztonsági tartalék. (nemtom mi ez a html-t generálni javaból)
-
floatr
veterán
válasz
MrSealRD
#4923
üzenetére
Egy ideje ezen az architektúrán fejlesztek, úgyhogy csak ajánlani tudom. Ha a cél egy olyan vékony kliens, ami mobilon is életképes, akkor érdemes még fontolgatni az MVC-t, bár az újabb telefonok már az ExtJS/Sencha Touch elemekkel is jól kijönnek. Spring MVC-t nem feltétlenül kell használni egy ilyen projektben, mert sokkal több dolog van benne, mint ami kellhet. Adatkapcsolati eszközként én DWR-t használom.
JQuery: gyakorlatilag ipari standard bár verziófüggőségi problémákkal én rengeteget szoptam. A korábban frontenddel foglalkozó fejlesztők szeretik, mert közelebb áll az ő gondolkodásmódjukhoz, de ha komplexebb dolgot kell benne megvalósítani, akkor a pluginekkel elég nagy problémákat vesz a nyakába az ember, mivel elég sovány a támogatásuk. Ha az ember nem expert, akkor csak a pluginek közti turkálás lesz belőle.
ExtJS: én ezt használom régóta, és a legtöbbször ezt is javaslom. Jó a supportja, és elég sokrétű felhasználási lehetőségei vannak. Egyrészt a magja közelebb áll a Java-s fejlesztőkhöz, és kellően testreszabható ahhoz h saját komponenseket használj tetszőleges felületi elemekhez. Másrészt van egy elég komoly adatkezelési mechanizmusa, aminek szvsz még a dojo sem ér a nyomába. Aztán ott van a komponenskészlete, ami desktop alkalmazások építőelemeire hajaz, és ráadásul még az ie6 is támogatott.
DWR: ha nem ismered, akkor nosza rajta. Írni is akartam egy kisebb cikket ezzel kapcsolatban, mert sokaknak teljesen ufó a dolog. A lényege annyi, hogy egy webservice-szerű szolgáltatási réteget a szerveren bekonfigurálva generál egy javascript csomagot, amiben megtalálod a szolgáltatásaid metódusait, és az adathordozó osztályokat. Magyarán JS-ből közvetlenül eléred a Java szolgáltatásaidat úgy, hogy még a bean-jeidet is létre tudod hozni a kliensnél. ExtJS-hez pár bővítmény kell, hogy az adatkapcsolat kezelhető legyen (én írtam ilyent
)Spring MVC: a DWR nem egy szabványos rendszer, ezért gyakran előfordul, hogy a spring RESTful webservice eszköztárára van szükség. Mondjuk ez sem teljesen szabványos, mint implementáció, de ezt legalább tudod használni bármilyen servlet konténerrel, nem kell hozzá vaskos JBoss. Jackson2-vel használva egy JS library számára az egyik legkezesebb eszköz. Tudok hozzá adni olyan komponenst ExtJS-hez, amivel majdnem DWR-szerű hívások szintjére lehet felhozni a kezelhetőségét.
Spring konténer: én enélkül el sem indulnék egy projektben
elsősorban XML-alapú konfigurációval.Hibernate: próbáltam szabadulni tőle, de mindig ide jutottam vissza. Amikor hierarchikus adatmodelled van, nem mondom h megkerülhetetlen, de erősen ajánlott. Főként a komplexebb lekérdezéseknél jól jön a HQL és a natív SQL-binding. Spring-gel együtt használva érdemes a Spring Data/JPA oldaláról támadni, mert az mégiscsak modernebb, mint a HibernateTemplate. Kísérleteztem még QueryDSL-el is, de azt csak egyszerűbb lekérdezésekig érdemes használni -- mondjuk azokra mindenképpen érdemes.
Mostanáig csak a liferay okozott problémát, bár az más területen is.
![;]](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?:))
- Amazfit Active 2 NFC - jó kör
- Xiaomi 14T Pro - teljes a család?
- Allegro vélemények - tapasztalatok
- Nem nyílnak a Foldok?
- alza vélemények - tapasztalatok
- EAFC 25
- Villanyszerelés
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Kertészet, mezőgazdaság topik
- Kínai és egyéb olcsó órák topikja
- További aktív témák...
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7600X 32/64GB DDR5 RTX 5060Ti 8GB GAMER PC termékbeszámítással
- Honor 400 Lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Dell Precision M4800 i7-4800MQ I 16GB I 256SSD I 15,6" FHD I K1100M I Cam I W10 I Gari!
- Erdély története I-II-III egyben 3990 ft
- AZONNALI SZÁLLÍTÁS Eredeti Microsoft Office 2019 Professional Plus
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest