Hirdetés
- Lassan állítjuk a fát, és a hardverek is be vannak csomagolva
- Klasszikus kínai festmények ihlették a Colorful legfrissebb memóriáinak külsejét
- Ultrakompakt Key E SSD-vel jelentkezett a Silicon Power
- Mesterséges intelligenciára kihegyezett mini PC jött az ASUS műhelyéből
- ASUS blog: ExpertBook P5 notebook, a munkagép
- Milyen videókártyát?
- TCL LCD és LED TV-k
- Autós kamerák
- Nem indul és mi a baja a gépemnek topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD GPU-k jövője - amit tudni vélünk
- Lenovo Legion és IdeaPad Y széria
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Apple notebookok
- Milyen RAM-ot vegyek?
Új hozzászólás Aktív témák
-
#9409
floatr
veterán
Aethelstone
#9404
floatr
veterán
válasz
Aethelstone
#9404
üzenetére
JSON RPC, amit az ügyfél kedvéért csak REST-nek hív már mindenki. De már rég nem akadunk fent ilyen apróságokon...
-
#9403
floatr
veterán
Aethelstone
#9397
floatr
veterán
válasz
Aethelstone
#9397
üzenetére
Nálunk a REST sem REST
-
floatr
veterán
Ezek alapján akkor neked az a gondod, hogy közöd sincsen a processinghez. Ha lenne, akkor nem okozhatna gondot egy javaban implementált algoritmus. Így mondjuk tényleg nehéz, mert akkor nem az algoritmus maga okozza neked a problémádat, hanem az egész processing. Ettől függetlenül tartom, hogy két nap alatt összehozható a netes tutorialok alapján.
9386) Aethelstone ez valami olyan rendszer, mint a logo, csak java alapokon. Gondolom az volt a cél, hogy kezdők gyorsan érhessenek el eredményt anélkül, hogy a java swing és rajzolási ökoszisztémáját bemagolják. Ezek szerint a célt nem sikerült elérni...
[ Szerkesztve ]
-
floatr
veterán
Tipikusnak tipikus. Már ne haragudj, de az eddigi hozzászólásaid alapján ne várj mást. Minimális java tudással, némi programozási ismerettel simán össze lehet szedni az információt. Pláne hogy van működő környezeted.
Ezeket az algoritmusokat még annó középiskolában a plus 4 ROM-jában láttam utoljára 25 éve, de youtube-on 10-15 perces gyorstalpalóval megérthető, az legalábbis mindenképpen, hogy milyen lépésekkel jutsz el a megoldáshoz, ha a matematikai háttere nem is érdekel. Ugyanez igaz a processingre is. Lehet h nem elég jó az oktatás, lehet h gagyi a konzultációs lehetőség, de tudhatnál segíteni magadon, csak akarat kérdése a dolog.
-
#9347
floatr
veterán
Aethelstone
#9346
floatr
veterán
válasz
Aethelstone
#9346
üzenetére
Konkrét megoldáshoz kapcsolódó kérdése volt; megkapta a választ. Sőt még javasoltunk is neki két libraryt. Szerintem jól járt velünk
-
#9344
floatr
veterán
Aethelstone
#9342
floatr
veterán
válasz
Aethelstone
#9342
üzenetére
Vagy a jackson, az még sokkaljobbabb
-
#9303
floatr
veterán
Aethelstone
#9302
floatr
veterán
válasz
Aethelstone
#9302
üzenetére
-
floatr
veterán
válasz
Lortech
#9205
üzenetére
Nézd, amikor én ezt web service-nek hívtam, mindenki lehurrogott, hogy REST. Én nem akadok fenn az elnevezéseken.
Ami a strukturálását illeti, az eddigi felhasználási területeken a legkevésbé sem volt szükség CRUD-szerű mechanizmusra. Specifikáció van, ha nem lenne, akkor egy ráerőltetett REST felépítés sem segítene nekik, mert nem pet store példaalkalmazásokról van szó
-
floatr
veterán
Ez az oracle hivatalos hitvallása. Nem olvastad? Most jöttek rá, hogy lehet h erre kéne koncentrálni, nem a SOAP-ot nyomni még ezerrel.
Amúgy kövezzetek meg, de én a REST-ből implementációból csak a service method regisztrációt, és a message convertert használom. Ez a GET/PUT/POST/DELETE annyira felesleges nekem
-
#9183
floatr
veterán
Aethelstone
#9182
floatr
veterán
válasz
Aethelstone
#9182
üzenetére
Régen elég sokat kódoltam assemblyben. A C compiler paraméterkezelését használtam, a C compiler-féle formalizmusokkal, mert kellemes sémát adott a kódnak, viszont sokkal nagyobb kontrollom volt a kód felett, ha kellett. Ugyanez van a JS esetében azzal a különbséggel, hogy a JS lényegesen emberibb.
A másik dolog meg az, hogy itt framework-ökról beszélünk, ahol már -- pl az ExtJS esetében is -- nem a JS kódon van a hangsúly, hanem az API-n, azt kell ismerni. Ha ez a tudás hiányzik, akkor az GWT esetében is gáz, ráadásul sokszor volt már olyan, hogy productionben kellett böngészőn keresztül debugolni/patchelni, ami GWT esetében nekem elég körülményesnek tűnik.
Nem azt mondom, hogy nem jó, csak hogy nekem kevés, és eleget láttam már a kollégákat szívni miatta. Amellett úgy gondolom, hogy nem utópisztikus elképzelés az, hogy az ember rendelkezzen egy API használatához megfelelő JS tudással java dev létére.
-
floatr
veterán
+1 bár jó lenne látni az ES6+ feature-öket is már. Frontenden kár bohóckodni generált cuccokkal. Mondjuk ahonnét indult az egész, desktop-szerű gui gyorsan fejlesztve, ahhoz az említett cuccok egyike sem elég önmagában.
(#9180) Aethelstone
Az Angular2 és az ExtJS épp ilyen embereknek megváltás.[ Szerkesztve ]
-
#9169
floatr
veterán
Aethelstone
#9168
floatr
veterán
válasz
Aethelstone
#9168
üzenetére
meg (#9167) mobal
Korábban próbálgattam ezeket is, de az angular nálam ott vérzett el, hogy erősen épít a hekkelt markupra, a v2 meg fordítást igényel. A GWT meg túl távol áll a "valóságtól"
Nemrég találtam ezt a jQWidgets cuccot, ami elmondás alapján eldöcög angular2-vel is, de ez még mindig nagyon erőltetett.Az a borzasztó ebben az egészben, hogy a fejlesztők 99%-a az ingyenes megoldásokra repül rá, azok meg frontend oldalon elég véleményesek. Az ExtJS/Sencha meg ha nem lopja az ember, kisebb projektekkel nem kifizetődő
-
floatr
veterán
válasz
Cathfaern
#9165
üzenetére
Nekem nagyon régóta etalon az ExtJS, és a kapcsolódó technológiák. Sokan nem szeretik, mert a frontendes szemében szálka az, hogy bonyolult markupot használ, és nagyon ésszel lehet csak beletúrni, a backendes szemében meg azért, mert javascript, amit elvből utálni kell.
-
floatr
veterán
Nem kedvelem én sem a swinget, mert ahogy megírták, az inkább tudományoskodós, mint praktikus. Annál még a python+glade páros is szerethetőbb. Ellenben sok esetben kiváltható a desktop alkalmazás egy embedded szerveres megoldással, és web guival. Utóbbira rengeteg olyan megoldás van, ami akár desktop külsőt is adhat, és programozói szemlélettel közelíti a problémát, nem pedig CSS wizardry.
-
floatr
veterán
válasz
Cathfaern
#9111
üzenetére
Mock használatával ebben az esetben nem tudom, hogy igazán mit tesztelsz. Leginkább a mock konfigurálási képességeidet, bár az sem megvetendő.
Én értem, hogy ha test driven és CI/CD alapú az egész projekt, akkor nagy a késztetés a teljes kód lefedésére ordas mennyiségű unit tesztekkel, de ezen a ponton több hibát lehet véteni a kamuadatok összegereblyézésével, mint anélkül.
-
#9110
floatr
veterán
Chesterfield
#9108
floatr
veterán
válasz
Chesterfield
#9108
üzenetére
Igazából ezt a részt elég nehezen lehetne már unit tesztnek becézni. Én általában egy ilyen teszthez -- nevezzük bárminek is, akár integrációsnak pl -- fel szoktam húzni a teljes környezetet, ami szükséges a futtatásához. Egy DB query futtatáshoz pl kell a teljes perzisztencia-réteg élő kapcsolattal.
Mivel Springet használok leggyakrabban, ott elég annyi, hogy 2 annotációt hozzácsapsz a teszt osztályodhoz, pl
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath:/testContext.xml"})
public class MyTest ...Ha viszont egyéb módon rakod össze az alkalmazást, akkor a JUnit egy másik annotációval fel engedi építeni a szükséges környezetet:
public class MyTest {
...
@BeforeClass
public static void start() {
// itt hozod létre a db kapcsolatot, stb...
}
...
} -
#9083
floatr
veterán
Aethelstone
#9079
floatr
veterán
válasz
Aethelstone
#9079
üzenetére
Gonosz
-
#8998
floatr
veterán
Aethelstone
#8996
floatr
veterán
válasz
Aethelstone
#8996
üzenetére
Maradjunk annyiban, hogy nem rossz.
Most épp az egyik nagyobb megrendelőnket szeretnénk java6-ról upgrade-elni. Majd ha ezzel megvagyunk, és a projektet teleszórt lambdák miatt feleannyi melónk lesz, akkor aszondom h qvajó, bár akit kirakunk emiatt a projektről, az nem fog örülniDe most komolyan. A nyelvi eszköz nem sokat ér, ha nincsen hozzá ütőképes API. Ezt bebizonyította már nagyon sok eszköz a java ökoszisztémában. Sőt már minden rookie tudja, hogy az igazi értéke nem a nyelvnek van, hanem az ökoszisztémának. A 8-as API-k elég jóra sikerültek, bár ez is kissé kétélű, nem szabad mindenkinek a kezébe adni, mert ismerek olyan embereket, akik csak nagyobb bajt okoznának vele, mint nélküle. Persze képzés mindenekelőtt, de úgy látom mindenkinek vannak korlátai sajnos, de ez már csak a gyakorlati hasznosítás problémája, nem az elméleti öröm.
-
#8993
floatr
veterán
Aethelstone
#8992
floatr
veterán
válasz
Aethelstone
#8992
üzenetére
Inkább a hozzá kapcsolódó API, mert önmagában csak egy rövidítés. De részemről ok.
-
floatr
veterán
Elhiszem, hogy van olyan, akinek ez jobban bejön. Meg látom, hogy sokan ráizgultak a lambdára is, mert az megoldja minden problémájukat az életben
Nekem eddig a project lombok volt az egyik leghasznosabb(#8988) Cathfaern egy szavam se lenne, ha lenne egy olyan üzemmódja is, ami nem igényli a lokális repót. Bár csak ezért migrálni nem kezdenék akkor sem...
[ Szerkesztve ]
-
floatr
veterán
Egy kicsit több konkrétum nem ártana
(#8984) emvy mi is lenyomtuk egy 124000+ revision-ös repo migrálását ezernyi branchel az íze kedvéért, meg megteheti bárki, hogy dupla munkát csinál verziókezelés címen, de a kérdés sosem az, hogy meg lehet-e tenni.
Azt is megtehetné bárki, hogy megosztott verziókezelő filerendszeres könyvtárakba dolgozik, de minek. -
floatr
veterán
válasz
Lortech
#8970
üzenetére
Az a probléma, hogy általában nem az a kérdés hangzik el, hogy "mit kezdjünk el használni: GIT vagy SVN?", hanem az, hogy "SVN-t használunk, mi indokolja, hogy GIT-re migráljunk?"
De elmondtam már az indokaimat. Emvy említett egy use case-t, amire jó a GIT. Nekem kicsit erőltetett, de szubjektív, kivéve persze ha az a jellemző munkafolyamata, hogy napi 10 órát utazik és közben fejleszt. Szerintem a projektek túlnyomó része nem elszigetelt fejlesztők részben merge-ölt munkájára épül, sőt... Ehhez képest a GIT csak feleslegesen komplikálja a munkádat, és ez a problémám, hogy nem észérv szól mellette, hanem az, hogy kimaradsz-lemaradsz, mertmindenkiezthasználja.
Nekem a legfájóbb pontja a GIT-nek ez az állandó disconnected feeling, mintha még mindig a dial-up korszakban lennénk. Bárhová megyek a laposommal az esetek 99%-ában, mindenhol legalább 100Mb-es netem van, ami még VPN-en is több mint elég. Semmi nem indokolja, hogy ne tegyem láthatóvá, és minden érintett számára elérhetővé egyből a munkámat. És nem elég az, hogy commit/push, de minden egyes alkalommal, amikor változást sejtek másoktól, még szinkronizálnom is kell külön, mintha nem is egy csapat lennél a kollégáiddal, ahol nem csak azért kell megszenvedned, hogy a te változtatásaid bekerüljenek, hanem külön kis bunkerben élne mindenki lekapcsolt nettel, és az is külön kihívás, hogy a mások változtatásai egyáltalán lejöjjenek hiba nélkül. Nekem ez nem előrelépés, sajnálom.
Mindegy leszállok a témáról, mert értelme nem sok van vitázni róla.
-
#8965
floatr
veterán
Aethelstone
#8964
floatr
veterán
válasz
Aethelstone
#8964
üzenetére
Engem csak az bosszant, hogy számtalanszor hallom puffogtatni, hogy aki SVN-t használ az inkább húzza le magát, mert a GIT istencsászár úgy általában, de értékelhető érveket nem nagyon látni. Amikor meg próbálom tisztázni, hogy mi az az aduász érv, ami ennyire nyilvánvalóvá teszi, hogy az SVN-nek vesznie kell, és GIT még a kenyérpirítóra is, akkor teljes kakukk. Az eddigi egyetlen értékelhető érv az volt most, hogy vonaton utazik és mobilnet. Gondolom nem ez teszi ki az idő nagy részét, de ok. Van már egy speciális eset, amikor esetleg van értelme a hype mellett.
Kicsit ugyanez az összes többi hasonló vita, amikor igazán érvek nem működnek, mert nem is nagyon vannak. Nem hallottam pl. a gradle mellett, hogy hierarchikus build, pedig elvileg mi el vagyunk tájolva az emlékek erdejében.
-
#8958
floatr
veterán
Aethelstone
#8955
floatr
veterán
válasz
Aethelstone
#8955
üzenetére
+1 a sült kolbászra
Ezt a lokális repository-t nem vágom SVNnél sem amúgy, kb arra jó, hogy megtanulja az ember. Vagy hogy a klasszikust idézzem némi módosítással: "Aki szerint ez version control, tegye fel a kezét, tegye fel a kezét, tegye fel a kezét..."
-
floatr
veterán
Épp arra próbáltam rávilágítani, hogy nincsen olyan h nem "mások szeme előtt maszatolsz". Nem vagy kénytelen összevissza másolgatni, mert ha létezik olyan a projektben, ami vakvágány, kivezetett branch, akkor azt megfelelő archív helyre mozgatod a repoban. Aki gyors munka miatt marhaságot csinál, azon a GIT sem segít. Épp ezért mondom azt, hogy szvsz egy totális félreértés a GIT hypetrain, ami egy olyan forrásból indul ki, ami bizonyos körökben fel van magasztalva már-már hites meggyőződéssel, és ezért nézem rossz szemmel azt, amikor erről indítanak, mert többnyire (tisztelet a kivételnek persze) fogalmuk sincsen h miért, csak azt látják, hogy "mindenki GIT-et használ". Elég radikális vélemény, tudom, mert a hype-széllel szemben témázok.
[ Szerkesztve ]
-
floatr
veterán
Nekem meg nem irreleváns, mivel a GIT egy eszközt ad a kezedbe arra, hogy személyes maszatolást csinálj anélkül, hogy nyoma legyen. Local history gyakorlatilag a nullával egyenértékű, ha meg mindent betolsz két lépésben, akkor meg csak feleslegesen bontottad ketté a GIT révén a folyamatot. Mindegy, nem akartam nagyon vitába keveredni, de én csak a divatot látom ebben az egészben az esetek 90%ában.
-
floatr
veterán
Első körben tisztázzuk, hogy céges környezetben, céges fejlesztési policy-val nézem ezt az egészet. Nálam a GIT rögtön ott bukik meg, hogy localhost-on van (lehet) olyan munkád a céges projekten, aminek nincsen nyoma a céges/központi repóban. A branch létrehozása egy mozdulat, ha a céges projekteken bíbelődsz valamit, az nem saját kis mitymuty, tessék létrehozni egy branchet akár kísérleti jelleggel a központi repóban, egy hosting/rendszergazda/devops kollégának meg legyen az a dolga, hogy ennek a feltételeit megteremti.
Minden branch minőségbiztosítási okok miatt meg kell hogy legyen központilag, lefedve egy task management rendszerrel úgy, hogy bármikor bárki tudja folytatni, review-olni, vagy épp merge-ölni DEV/UAT/PROD környezetbe.
#8933) WonderCSabo a másolás egy logikai művelet. Ellentétben néhány más rendszerrel, SVN alatt nincsen olyan speciális művelet, hogy branch, mivel nincsen erős kötöttség arra vonatkozóan, hogy a repoban mit hova teszel. Branch-et úgy csinál, hogy egy másik branch (URL) adott állapotáról egy referenciát készít az új URL-en. Meg kell határoznod a saját workflow-dat, hogy milyen elnevezéseket és kötöttségeket használsz. Ez nyilván lehet az eredeti ajánlás szerinti is, bár az csak egy viszonylag egyszerű munkafolyamatra jó.
(#8937) Aethelstone rebase
[ Szerkesztve ]
-
#8931
floatr
veterán
WonderCSabo
#8928
floatr
veterán
válasz
WonderCSabo
#8928
üzenetére
Nem történik másolás
Ha neked másolás történt, amikor SVN alatt brancheltél, akkor valamit nem jól csináltál.Én pont emiatt akadtam össze egy indiai fejlesztőcsapattal, mert korábban nem használtak VCS-t, de az SVN túl sok volt nekik. Minden egyes branch, amit létrehoztak, előzmény nélküli volt, egy teljesen új artifact, korábbi entitásoktól relációmentesen. Azóta is csak tippelek, hogy mi a bánatot csináltak rosszul.
Egy dolog van, ami sebességbeli probléma lehet. Az SVN közvetlenül a központi repository-ban dolgozik, ott hozza létre a bejegyzéseket. Ez ha rosszul van méretezve, lassú is lehet, értsd itt lassú alatt azt, hogy 2-5 másodperc. GIT esetében a saját gépeden lévő repositoryban hozod létre a branchet, amit csak te használsz, nyilván nincsen érdemi hálózati bottleneck, és más júzerekkel sem kell küzdenek a processzidőért. Ellenben ha feltolod a központi repóba, akkor megcsinálja ugyanazt, amit az SVN (nem másolás). Lehet hogy ez gyorsabb valamilyen oknál fogva a GIT esetében (nem 5 másodperc, hanem 2), de erős túlzásnak érzem azt, hogy ez a 2 vs 5 másodperc valakinek probléma.
(#8930) fordfairlane ha valamit elk.tál, akkor elég nehéz tud lenni. De akkor GIT branch/mergenél meg a push a kellemetlen
[ Szerkesztve ]
-
floatr
veterán
Szerintem feature branchingre inkább való az SVN. Az kétségtelen, hogy programozó sejtekbe csoportosulva a GIT jobban skálázódhat, de finoman szólva nem ez határozta meg a felhasználási területeket egyetlen projektnél sem -- legalábbis nálunk.
(#8924) Lortech Tisztában vagyok vele, hogy a gradle irányába folyik még a Duna is, de egyelőre általános felhasználásra kicsit még kísérleti szaga van. Kell neki még egy kis idő, de hiánypótló az ANT után.
A GIT meg nyilván felhasználás kérdése, ha kell, akkor kell. Én viszont a GIT-tel vagyok úgy, hogy az utóbbi években kialakított workflow-t csak megnehezítené. Nemrég írtam egy scriptet is SVNhez, hogy még azzal se kelljen időt pocsékolni, hogy kattintgat az ember a branchek között, meg a history-ban merge előtt, nem sokból tartana GIT-re átírni, de csak a változtatás kedvéért teljesen feleslegesnek érzem a változtatást. Én inkább érzem arculati tényezőnek, mint valóban hasznos eszköznek. Kicsit olyan érzésem van vele kapcsolatban, mint amikor az ember összekötött kézzel akar úszni, hogy más is láthassa, hogy tud összekötött kézzel is úszni.
-
floatr
veterán
Re maven/gradle: a gradle megítélésem szerint még elég kiforratlan dolog, és elég gyerekcipőben jár a támogatása az egyes IDE-kben. Sajnos én addig nem tudom eléggé komolyan venni a dolgot. Mondom ezt úgy, hogy egy nagyobb projektcsomagot migrálunk most gradle-re. Akinek egy maven-féle XML szerkesztése gondot jelent, az válasszon más pályát
Re SVN/GIT: nagyon menő egy ideje a GIT, és mindenki migrál veszettül, ész nélkül sajnos. A legtöbb projekt ugyanis nem igényli a GIT modelljét, ellenben komplikáltabb a használata. Tapasztalatom szerint még az SVN használata is kihívás sokaknak, nemhogy a GIT. Biztos van helye a GIT-nek is (pl nagy projekt kis, 1-2 személyes, javarészt független alprojektekkel), bár én eddig még sehol nem láttam indokoltnak, leszámítva azt az esetet, amikor egy ügyfél előtt pozicionálunk arculatot.
-
#8894
floatr
veterán
Aethelstone
#8890
floatr
veterán
válasz
Aethelstone
#8890
üzenetére
Én írnék rá két AOP metódust, mivel a várakozás nem része az üzleti logikának. Kéne hozzá egy interfész, két provider implementáció, egy annotáció, konstansok, egy exception, arra megfelelő handler, egy advisor, egy provider factory, és egy spring kontextus. Betenném bootba, és egy docker pluginen keresztül akár 100 node-on is lehetne futtatni, ahogy a felhasználók szerint skálázódik a rendszer.
-
floatr
veterán
Szerintem hagyjuk ezt, mindenkinek más a preferenciája. Ha sorrendeket akarsz nézni, akkor regionálisan és globálisan is eltérő statisztikák vannak, de a lényeg megmarad, hogy a java .net php fejlesztések uralják a piac nagy részét, nagyon nem lehet egyikkel sem mellényúlni.
Én aszondom, hogy mindenki döntse el, hogy mi a személyes kedvence, és dolgozzon/tanuljon aszerint. És tárgyalja meg az adott architektúra problémáit a megfelelő topicban
-
#8817
floatr
veterán
Aethelstone
#8815
floatr
veterán
válasz
Aethelstone
#8815
üzenetére
A kollégáim most migrálnak CVS-ről
(#8816) Chesterfield mindhárom JAR-t letöltötted, és bepakoltad a projektbe? Ez a hiányzó annotáció a 3. fileban van, amit linkeltem
Amúgy ha egy json array a bemenet, akkor inkább
Szemely[].class
kell neked[ Szerkesztve ]
-
#8814
floatr
veterán
Aethelstone
#8813
floatr
veterán
válasz
Aethelstone
#8813
üzenetére
Bár manapság már inkább égő. A gradle a menő, jövőre meg lesz majd valami syntax sugar build system
-
#8811
floatr
veterán
Chesterfield
#8810
floatr
veterán
válasz
Chesterfield
#8810
üzenetére
http://central.maven.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.8.5/jackson-databind-2.8.5.jar
http://central.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.8.5/jackson-core-2.8.5.jar
http://central.maven.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.8.5/jackson-annotations-2.8.5.jarMondjuk én mindenképpen azt javasolnám, hogy egy mavenes projektet csinálj, mert anélkül ez manapság már csak favágás.
[ Szerkesztve ]
-
#8809
floatr
veterán
Chesterfield
#8808
floatr
veterán
válasz
Chesterfield
#8808
üzenetére
Letöltöd innét: [link]
vagy belövöd mavenben pl így: [link] [link]Aztán
new ObjectMapper.readValue(inputStream, MyClass.class);vagy
new ObjectMapper.readValue(inputStream, MyClass[].class);ahol a MyClass tükrözi azt a struktúrát, ami a jsonből jön.
[ Szerkesztve ]
-
floatr
veterán
válasz
F1rstK1nq
#8783
üzenetére
Úgy gondolom, hogy akkor van értelme konténerbe tenni dolgokat, ha ahhoz valamilyen formában kötődne a beaned, vagy az életciklusa. Egy logger szvsz max az osztályhoz kellene hogy kötődjön még csak nem is példányhoz, függetlenül attól, hogy a konténerben singleton. Emiatt én csak private static final loggert használok csak. Lehet ezt nem szeretni, de logikailag számomra tisztább a dolog, és bár marginálisnak tűnhet a dolog, de ennyivel is kevesebb ballaszt van a konténerben és a konfigban.
-
#8752
floatr
veterán
Aethelstone
#8744
floatr
veterán
válasz
Aethelstone
#8744
üzenetére
Ezek az értelmes kérdések
a korábban említett tesztszerű kérdéssor meg az a hely, ahol droidokat keresnek. Szerintem régen rossz, ha egy munkaadó mostanában lexikális tudásra épít, nem pedig rendszerszemléletre. -
floatr
veterán
Ha a kérdés az, hogy metódusok közt változó mennyiségű argumentumot átadni hogyan lehet, akkor itt van a válasz [link]. Ha az a probléma, hogy hogyan változtatod az SQL-t, arra én query builder megoldásokat szoktam csinálni az aktuális framework szerinti eszközökkel. Lehet if-else ágakban összevagdosni a SQL stringet, lehet használni hibernate vagy JPA criteria API-t, van JOOQ vagy QueryDSL, ami szintén támogat feltételes buildelést bizonyos mértékig.
Ezek közül a legpöpecebb szerintem a JPA+Spring Data+QueryDSL kombináció, amit meg lehet támogatni igény szerinti SQL buildeléssel.Ha mindez csupán egy kis feladat, akkor javaslom a legegyszerűbb if-else + StringBuilder megoldást.
-
floatr
veterán
Workaroundként tudom esetleg javasolni, ha a filter nem dobja ki amit kéne, hogy a parancsra keress rá.
A System.in egy stream, a példához kell egy reader, ami a doksi íves fogalmazása egy byte streamet dekódol karakteres streammé a megadott vagy default charset alapján. A pufferes téma meg amiatt lehet jó, hogy soronként tudsz olvasni karakteres streamet, mivel előre olvas a pufferbe és többek közt megkeresi a sorváltásokat.
-
floatr
veterán
Úgy látom a szakmai fórum új szintre lép azzal, hogy másik IDE-t ajánlanak egy key binding probléma megoldására
Ha rendezed a binding-re a listát, akkor láthatod hogy rengeteg Shift+Alt X kezdetű kombináció van. Én korábban a Ctrl+Alt kombinációkkal szívtam, mire rájöttem (IDE váltás szándéka előtt) hogy viszonylag gyorsan meg lehet oldani a problémát, hogy angol ABC-hez szokott kezek gyúrták össze a rendszert.
Az importra nem tudom ismerős-e a Ctrl+Shift+O (organize imports). Bár lehet h nem erre gondoltál.
-
#8603
floatr
veterán
fordfairlane
#8602
floatr
veterán
válasz
fordfairlane
#8602
üzenetére
Azért nem mindegy, hogy hogyan van menedzselve. Anno amikor a WFC-t használtam a MS motorjával, tisztán látszott az, hogy a MS tud JIT compilert írni, tud sebességre optimalizált struktúrát tervezni... szomorkodjunk együtt
-
floatr
veterán
válasz
Amartus
#8591
üzenetére
Springhez én spec egyáltalán nem használok semmit, mert egy idő után rájön az ember, hogy ezek a csiricsáré toolok, amikkel az xml-eket lemodellezik, csak az időpocsékolásra jók. Javascript tekintetében viszont a netbeans volt nekem eddig a nyerő, bár most van pár újabb fizetős plugin JS frameworkökhöz, amit nem akaródzik megvenni, azok lehet h jobban muzsikálnak, mint az alap.
(#8585) mobal viszonylag ritkán debuggolok, így nem érzek nagy különbséget a kettő között. A múltkor az egyik kvázi kollégám, aki liferay bundle-okat gyárt, kidebuggolt valami komponenshibát, de fogalmam sincsen h mit használt hozzá. Egy a problémám ezzel az egész felvetéssel, hogy mint minden ilyen konkurenciaharc esetében itt is van egy erős hype train, divat belekötni hangulati alapon dolgokba, miközben a makacs tény az, hogy az eclipse egyelőre ipari standard, az idea egy második szereplő, a netbeans meg az apache foundation kezei közt fog kimúlni.
-
floatr
veterán
válasz
DarkByte
#8582
üzenetére
Régóta használok már java IDE-ket. A nulla támogatottságtól ('95-'96) a szinte nulla ráfordítási igényig elég szép volt a felhozatal. Használtam VS J++-t, JBuilder-t, JDeveloper-t, Netbeans-t sokáig a felvásárlás előtt és kb 2 évvel ezelőtt is, Eclipse-t (myeclipse, sts, meg valami évi 1000 dolláros szutyok verzió), és volt szerencsém belekóstolni az Idea-ba is részben az android studio révén. Volt olyan is, hogy engedtem ugyanazon projekten belül használni Idea-t is, mivel volt két kiccserkész, akinek ahhoz volt kötve a keze.
A mai napig úgy érzem, hogy a legkorrektebb eszköz az VS volt, és az alap eclipse-hez kapcsolódó - mondjuk úgy - "élmények" vannak még a tűrőképességem határain belül; a többi számomra nem volt elég jó. Ez nyilván egyéni, részben lelkesedés szerinti, néha meggyőződéses. Azt viszont tapasztalom, hogy produktivitásban semmit nem nyer az ember egy ilyen váltással, ha leszámítjuk a szoftver iránt érzett ellenszenvét.
-
floatr
veterán
Az ok, hogy vannak kötöttségek, de abban igaza van, hogy elég elbaltázott dolog az, ha egy rakat alkalmazás fut egy helyen és nem férnek hozzá egy közös adatbázishoz.
Amúgy nem tudom, hogy ennek az általad vázolt szisztémának milyen erőforrásigényei vannak, de kicsit úgy érzem, hogy túllősz a célon. Ennél sokkal kevesebb eszköz-ráfordítással is meg kéne tudni oldani (ami nyilván időben viszont több lenne mint 3 óra). Nálunk jboss clusterek vannak, aminél a jgroups eleve ott van, én azt használnám egy ilyen hálózat kiépítésére, ha nagyon cizelláltan kéne megoldani, de a legtöbbször a cizellált megoldásokat senki nem fizeti ki. -
floatr
veterán
-
#8515
floatr
veterán
Chesterfield
#8514
floatr
veterán
válasz
Chesterfield
#8514
üzenetére
Bár nem kifejezetten java témakör, de a számábrázolás a negatív értékek esetében úgy történik, hogy a 15 biten ábrázolható legnagyobb érték + előjel jelenti a -1-et
1 111 1111 1111 1111 (ha jól emlékszem az előző évezredből)
a -2 így néz ki
1 111 1111 1111 1110
és így tovább csökkenő sorrendbenja és a magyarázat: -1 x (32768 - (40002 - 32768)) azaz 40002 - 2^16, ha az érték túlcsordul
[ Szerkesztve ]
-
-
-
floatr
veterán
válasz
Taoharcos
#8456
üzenetére
Nem ismerem a céget, de majdnem biztos, hogy konkrét cégekkel, vagy fejvadászokkal állnak szerződésben, és a tanfolyam költéségének nagyobbik részét a toborzó cég fizeti, ha sikerül szerződét kötni. Nincsenek csodák, és egy cég sem engedheti meg magának, hogy lényegesen rosszabb szolgáltatást nyújtson, mint bárki más. Ez max igen rövid távon éri meg, utána bukó.
[ Szerkesztve ]
-
floatr
veterán
válasz
MrSealRD
#8436
üzenetére
Nálunk több csapat is fejleszt liferay alá, de az a sajnálatos tapasztalatunk, hogy a liferay API-t inkább használó portletekre épített portál memleakel, és ahogy mondod, azokat is napi szinten ütemezve indítják újra. Fura módon azok a rendszerek, amiket mi custom megoldásra építettünk, nem igénylik ezt a bohóckodást.
Amúgy nálunk New Relic felügyeli a clustereket.
-
floatr
veterán
Én próbáltam, de vállalati rendszert nem építenék rá, már csak a karbantarthatóság miatt is. Meg túl nagy a java ökoszisztéma ahhoz, hogy bármivel is kiváltsad. Specializált dolgokra jó lehet ettől függetlenül.
Amúgy csak megjegyzem, hogy a java EE nem irányadó, csak irány követő. Az ökoszisztéma szereplői húzzák maguk után már nagyon régóta. Az EE-t én inkább egy szabványosítási folyamatnak mondanám, ami mondjuk nem rossz dolog, de nem egy oracle-höz kötelezően kötődő must have valami. Mindenki jobban járt volna, ha anno a google vette volna pártfogásba.
-
floatr
veterán
Amúgy épp most néztem, hogy a MS nagyon belecsapott a lecsóba, és FLOSS témában kezdeményez .NET-tel. Egész trendi technológiákat támogatnak, amivel csak az a probléma, hogy az oracle-t a mostani MS könnyedén lelépi.
Csak akkor lehetne érdemben lépni, ha mindenki kilépne a JCP-ből, otthagynák az OJDK-t, és kiperelnék az oracle-ből az általuk beinvesztált szellemi tulajdont. Bár az gyakorlatilag a java halálát jelentené, mivel az oracle foggal-körömmel ragaszkodik hozzá. Szép világ ez, hogy a java lesz a vendor lock-in.
-
floatr
veterán
Namost megint az van, hogy a felét sem írod le annak, ami kéne információ, hogy jól lehessen válaszolni. Sokféle módon lehet web service endpoint esetében opcionálissá tenni a paramétert. Ha egy @RequestBody paraméter van, ami becsomagol több kisebb értéket, akkor azok lehetnek opcionálisak automatikusan; én az utóbbi időben ezt használtam. Maga a body is lehet opcionális, ahogy írtad. Post paramétereket is használhatsz json-ben formázva, vagy egyszerű értékként küldve; azok a paraméterek is lehetnek opcionálisak. Egyikkel sincsen gyakorlati probléma, leszámítva a null ellenőrzését, bár el tudom képzelni, hogy valaki már erre is faragott egy anti-pattern cikket.
-
floatr
veterán
válasz
Ursache
#8358
üzenetére
Sokkal nagyobb probléma, hogy egy kód elfér a képernyőn, vagy sem. Ha egy metódust nem látsz át scrollozások nélkül, akkor cumi van. Ez persze nem jelenti azt, hogy vég nélkül minimalizált kódot kellene gyártani, de ne okozzon már gondot egy seniornak (elvileg a debug/javítás nem junior feladat) egy ilyen sor.
Ezerszer futottam már bele olyan kódba, ahol a fene sem tudta kibogarászni, hogy mi a rák járt a kolléga fejében, amikor 10 soron keresztül agyament logikával oldotta meg azt, ami 1 sorban elfért volna. Szerintem sokszor át sem tudják igazán gondolni a problémát kicsiben, amikor ilyen elnyújtott marhaságokat lekódolnak. Aztán nem mersz hozzányúlni, mert működik valami csoda folytán, de az ügyfél kis módosítást kért.
-
floatr
veterán
Nem akarnám megkérdőjelezni mások ajánlásait, de nem vesztesz vele semmit, ha a repo támogatja a kereséseket is. A legtöbb specifikáció mindig oda lyukad ki, hogy kell ilyen.
Persze simán el tudom képzelni, hogy egyedi implmentációba teszik sokan ezeket a funkciókat, bár ha a JPA implementáció normálisan támogatja, akkor miért ne használja azt az ember.
-
-
floatr
veterán
válasz
Dave-11
#8193
üzenetére
A getClass() egy metódus, amit akkor tudsz használni, ha van egy példányod futás időben. Pl előszedsz valahonnét egy ismeretlen típusú objektumot, és meghívod ezt a metódust, akkor a runtime viszaadja a típusához kapcsolt metaadatokat. A .class egy operátor, és a fordító fogja feloldani a dolgot
Egy szemléletes példa:
...
Object o = cacheMap.get(id);
if (o != null && o.getClass().equals(User.class)) {
User u = (User) o;
...
} -
floatr
veterán
Barátod a kísérletezgetésben [link]
Én mindig ezt használom, ha valamit össze kell ütnöm.Az általad megadottak alapján ez a pattern a megoldás: "ubuntu.*?amd64.*?iso"
Nincsen szükséged capturing groupra, meg semmi másra, ha csak az a cl, hogy egy olyan stringet találj, amiben ebben a sorrendben megtalálhatóak a megadott szavak úgy, hogy köztük tetszőleges számú bármilyen karakter van. Esetleg a *-ot le lehet cserélni +-ra, és akkor annyi lesz a különbség, hogy a szavak között minimum 1 karakternek mindenképpen lennie kell.[ Szerkesztve ]
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Dell Latitude 5480 laptop (14FHD/I5-G7/8GB/256SSD/MagyarVilágítós/AkkuX)
- PS5 Lemezes 825GB - használt -
- Xbox 360 játékok,akár 1000ft-tól(részletek a leírásban)
- Playstation 3 játékok,akár 1000ft-tól(részletek a leírásban)
- GAMER félgép - GIGABYTE B760M H DDR4 + Intel I5 13400F + Corsair VENGEANCE LPX 2x16GB DDR4 3200MHz
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Axon Labs Kft.
Város: Budapest