Hirdetés
- Meggyi001: Kórházi ellátás: kuka vagy finom?
- Luck Dragon: Asszociációs játék. :)
- sziku69: Szólánc.
- sziku69: Fűzzük össze a szavakat :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- eBay-es kütyük kis pénzért
- sh4d0w: Kalózkodás. Kalózkodás?
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- sh4d0w: StarWars: Felismerés
- gban: Ingyen kellene, de tegnapra
Új hozzászólás Aktív témák
-
#68216320
törölt tag
Springet még hagyom, sima JDBC-t használok majd és alap funkciókat.
Viszont megkeveredtem, azt hittem DAO-t kizárólag perzisztens rétegben használunk.
Azt hiszem kellene keresnem valami megfelelő MVC alapú alap funkcionalitású (FW nélküli) kódrészletet, hogy a helyére kerüljenek a dolgok.Elnézést a bugyuta kérdésekért.
vissza a padba...Még egy gyors kérdés, akkor elvben valahogy így nézne ki?
View <- (Model) -> Service <- (DAO) -> Persistence
-
#68216320
törölt tag
Öööö... úgy kellene? Akkor megkeveredtem.
Nálam ott full SQL adatok vannak. Többek között az ID is.(#10482) floatr:
Most még nem használok keretrendszert, előbb megpróbálom teljesen átlátni a dolgot. (Ezután gondoltam Spring komponensekkel lecserélni amit lehet, aztán menne az egész JavaEE vonalra)
Nálam a terv az lenne, hogy maga a perzisztens réteg egy külön maven modulban van és kifelé interfészként van jelen. Emiatt én úgy gondoltam, hogy a DAO csak ebben a modulban létezik, vissza már modelt ad a szerviz rétegnek. A cél az lenne esetemben, hogy egy mozdulattal a perzisztens réteg modult lecserélve akár más tárolást lehessen használni. Már, ha ez nem hibás koncepció részemről.
A service réteg szintén külön maven modul. Arra gondoltam, hogy ő pedig csak model-t lát, számára a DAO nem létezik. -
floatr
veterán
Ja hát a split az teljesen gáz erőforrások tekintetében, de kreatív megoldásnak vicces
Menet közben rájöttem, hogy ha elé- és mögé vágok egy-egy mássalhangzót, akkor tökéletesen működik az is. De ha nagyon optimalizálni kell, akkor lehet elég elborult algoritmusokat írni, ami viszont már felveti az egész hasznosságát 
A reguláris kifejezésekről meg csak annyit, hogy volt már olyan h bekresseltettem böngészőket egy nagyobb szöveg parsolásakor, ha lehet kerülöm
-
Lortech
addikt
Lehet force-olni egy windowsos ablak átméretezhetőségét (ResizeEnable util pl), de ettől önmagában még nem fog skálázódni a layout is, vagy igen, vagy nem, vagy jól vagy nem. Sokszor azért veszik fixre az ablak méretet, mert nem tudták rendesen megcsinálni a layout skálázódását.
De ez igazából nem javás kérdés. -
#68216320
törölt tag
Rendben, köszönöm a bíztatást, meglesem a tutorial-t
Ja még egy dolog, ami most merült fel bennem. Utánnajárok majd a témának, de érdekelne, hogy Spring konfigurációkban annotációkat vagy XML-t szoktál inkább használni? Nekem tetszenek az annotációk. Ha esetleg valaki xml-el konfigurál akkor könnyebben felhasználható a kód a keretrendszeren kívül? Vagy mi az előnye/hátránya személyes tapasztalatod alapján?
(#10415) Drizzt: Értem amit mondasz és megfontolandó. Bár esetemben nem maga a project elkészítése lett volna a cél, az csak egy eszköz lenne a tanulásra, hogy mégse 100 darab "Hello world" szintű nyúlfarknyi kód legyen.
De kicsit körbejárom a dolgot akkor még1x.És köszi mindkettőtöknek a válaszokat. Nagyon felpörögtem a témára...
-
#68216320
törölt tag
Köszönöm az info-kat.
Volt már saját project-em Java-ban, a felsorolt fogalmakkal is tisztában vagyok. Én a maven-t ismerem és használtam, illetve perzisztens rétegben MySQL-t és mintapéldáknál (lustaságból) a Derby-t. Az MVC sem probléma, próbálok interfészeket használni és szép kódot írni. ORM-et még nem használtam Java-ban, kizárólag PHP vonalon a Laravel-ben találkoztam vele. Szóval az új lesz. SOLID alapelvek rendben, értem és próbálom helyesen alkalmazni őket, DI-re is törekszem, bár néha ott még bakizom.
Marad akkor az a felállás, hogy megcsinálom a tervemet Spring nélkül, refaktor amíg rendben lesz és ezután ugyanazt elkezdem a Spring-et és megpróbálom majd azzal megcsinálni.
-
#68216320
törölt tag
-
floatr
veterán
Végül is xterm/vnc is van, ha remote akarsz fejleszteni
de... akkor mire van a fejlesztői gép.
Mondjuk én ezt a maces őrületet sem értem. Nyilván jobban kézre áll az első hónapban egy windowsos környezet, de kicsit erőltetett dolognak érzem akkor, amikor már lassan minden az aws/docker/k8s és tsai körül forog.
Mindegy igazából ez a része, mindenkinek megvannak a preferenciái, csak megjegyeztem, hogy távolról sem optimális -
benyo513
tag
Ez engem is érdekelne. Legtöbb helyen, ahol dolgoztam/dolgozok (rendszermérnökként) ott mind windows van és ötvenből, ha ketten használtak linuxot (pedig bármikor feltelepíthették volna maguknak vagy megkérhettek minket, hogy telepítsük fel, ha annyira szerettek volna abban dolgozni)
-
Drizzt
nagyúr
Ebből a példából ezt egy több éves projekt esetében elég nehéz lenne azért kijelenteni. Egy ennek megfelelő általános osztályt azért pár perc alatt java EE-hez is össze lehet dobni. Ebből a példádból az látszott, hogy könnyebb egy bonyolultabb alkalmazás alapjait összerakni. De arra nem lehet belőle extrapolálni, hogy bonyolultabb use case-ekben van-e olyan eset, amiben esetleg a Java EE-ben van egyszerűbb megoldás. Nem azt állítom, hogy van, csak az érveléseddel szállok vitába.
Ui.: REST szerver funkcionális tesztelésére mit javasoltok? REST assured-t nézem most, elsőre tetszik amit látok, de kíváncsi vagyok van-e jobb javaslat. Az, hogy Java alapú, előnynek számít most nálam. Főleg ha a webszerver is Java alapú. Vannak dolgok, amit így kis fájdalommal újra lehet használni.
-
Lortech
addikt
Ez elég nyilvánvaló. De eddig is lassan mozgott a Java EE. Aminek nem csak hátránya van azért.
Meglátjuk a következő 1-2 évben, hogy mi lesz a Jakarta EE-vel.Szerintem nem nehezebb EE-ben dolgozni, napi szinten használom mindkettőt évek óta és még mindig a specifikus igényektől függene, hogy melyikhez nyúlnék, ha valami zöldmezőset kellene csinálni.
Springben talán egyszerűbb kezdőként eredményeket elérni, de ha megvan a tudás Springben és Java EE-ben is, valamint egy jól összerakott, bejáratott architektúra, akkor elég jól lehet haladni mindkettővel. -
Lortech
addikt
Én. JDK-bol azert kerultek ki a Java EE interfeszek tobbek kozott, hogy egyszerubb legyen a JDK/JSE kiadas. Lasd motivation resz itt [link]. Eleve nem kellett volna belerakni Java EE reszeket.
Eddig sem volt resze a Java EE modulok tobbsege a JDK-nak, onmagaban a JDK nem volt elegendo (Java EE) fejlesztesre.
Ezeket csak azért tartottam fontosnak leírni, mert a hozzászólásodat továbbgondolva arra a következtetésre juthatnak a témában kevésbé járatosak, hogy most lényegesen nehezebb lesz Java EE-re fejleszteni vagy hogy halott a történet, pedig a szóbanforgó változások nem jelentenek ilyet. -
floatr
veterán
Az megvolt már, hogy az Oracle nem engedélyezte a "Java" név használatát az általa kukázott és az EF által széttaknyolt JEE projektjeiben?
Na eddig csak ásta a sírját a java-nak, de most elkészült a fejfával is.És a support plan is volt már...? Kínomban már csak röhögök
Ez miiii? Java 9 tavasszal megszűnik? Java 10 ősszel??? A Java runtime letöltései közt elsőre meg sem találja az ember a java 9-et. Marad a 8 talán 2020-ig, aztán bedől az is, mint minden, ami a Suntól jött?
-
Orionk
senior tag
Szia!
Igen, JavaFX-et szeretnék, ami Desktop-on is és Androidon működik.
A Gluon átfordítaná az Android SDK Manager segítségével a Desktop-ra írt kódot Androidra is.Te foglalkoztál már ezzel?
IntelliJ-be telepítettem be a Gluon plugint, de további segítségre lenne szükségem és az internet, Stackoverflow elég szegényes válaszokat ad.
köszönöm
-
Lortech
addikt
Valóban nem írtál. So last year ugye annyit tesz, hogy "lejárt lemez", emvy sejtésem szerint legalább részben viccnek (van ilyen szólás, mém). A +1-et már viszont nem tudtam máshogy értelmezni, minthogy tényleg elavultnak tekinted, és reméltem hátha van valami _új_ alternatíva, amiről lemaradtam.
RESTful egyébként jó téma, jönnek az arcok hozzám interjúzni, szinte már minden szenior javás CV-ben ott van a REST API tervezés és/vagy implementáció, de az alapelveit nem tudja szinte senki elmondani, arról pedig végképp fogalma nincs a többségnek, hogy az alapelvek mit jelentenek megvalósításban. A HTTP-t alig ismerik. RMM-ről senki nem hallott. Addig jutunk el, hogy spring mvc vagy jax-rs annotációk, és GET POST PUT DELETE meg json, azt' jó napot.
-
Lortech
addikt
-1
Mit használsz az említett Angular mellé, ha nem REST API-t? Springet említettél, gondolom akkor Spring MVC.
Én most React + Redux kombóval prototipizálok és alapozok egy projektet, de még nincs kőbe vésve. Egyelőre Typescript mellett nem köteleződtem el, ahogy Angular 2 mellett sem. Ha valaki ráérez a JavaScriptre, és elfelejti a javaizmusokat, akkor statikus típusok nem sokat adnak hozzá a munkához, vannak hátrányai is, nálam elsősorban a tooling szempontjából lenne érdekes.
Előtte Angular 1-gyel töltöttem jelentősebb időt, azelőtt pedig klasszikus Java webes megoldásokkal mint JSF *faces, Struts/2, Wicket, de volt közben némi Backbone, GWT, Vaadin és még Extjs is.
-
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. -
F1rstK1nq
aktív tag
Megértem. Tényleg embere válogatja.
Egyébként Spring Boot olyan szépen autoconfigolja, hogy öröm belekezdeni.Ránéztem, nem rossz dolog ez a Mustache sem.
Viszont, most ez az AngularJS 2 + Spring keltette fel az érdeklődésem, hogy megemlítettétek, biztos kipróbálom valami hobbiprojektben a közeljövőben.(#9158) Aethelstone: Nekem sincs jó véleményem Vaadin-ról, sőt nagyon megutáltam a projekt végére, pedig még a Vaadin Spring integrációt is használtuk. CustomLayout-tal még hagyján, de amit kigenerál magából néha enélkül, az vicc. Mindegy, egy Vaadin Certification-re jó volt a tudás, projekt után, de nem igazán tervezek rá visszatérni, ha nem muszáj.
-
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
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. -
disy68
aktív tag
Lehet csk nekem, de nem egészen egyértelmű. Ez a helper osztály nekem egy service-nek hangzik, aminek van egy vendor dependency-je. A service-nek ezt a dependency-t illene konstruktorban átadni, mivel a funkcionalitásához nélkülözhetetlen (azaz ne is jöjjön létre példány anélkül, hogy működne). Nem tudom milyen az architektúra, de ha Java EE, akkor van context. A service valószínűleg valami singleton bean, amit újra lehet hasznosítani (figyelemmel a szálkezelésre, ha szükséges). Maga a vendor object is egy bean lesz ebben az esetben, amit szintén át lehet adni bárminek, ami igényli.
-
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.
-
#8919
Aethelstone
addikt
mobal
#8918
-
Karma
félisten
Érdekes ez a lib, de amit leírtál, ahhoz nem sok köze van szerintem. Egy mezei @RestController-rel is mindent meg lehet csinálni. Ha csak az elindítás fontos és az eredmény nem érdekel, a service beaned metódusára rakhatsz @Async annotációt, így a HTTP kérés azonnal visszatérhet. Ha meg kell az eredmény, akkor ugyanez, plusz a DeferredResult.
-
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. -
-
#8014
Sk8erPeter
nagyúr
mobal
#8006
Sk8erPeter
nagyúr
Amikor a céges környezet, és/vagy konkrétan Eclipse-re épülő UI* miatt Eclipse-hez vagy kötve, akkor nem fogsz Ideát használni.
*: vágod, van ilyen lehetőség, hogy az Eclipse modularitását kihasználva, saját plugineket készítve lehet az Eclipse API-t kihasználva készíteni arra épülő alkalmazásokat. Maga az Eclipse, mint fejlesztőkörnyezet, nem meglepő módon ugyanerre épít.
Egyébként szerintem is fasza az Idea, de a munka nem mindig úgy van, hogy azt használsz, ami neked tetszik.
(#8007) M_AND_Ms:
És akkor, amikor rácsodálkoztál, azt reagálta, hogy ő mindig hibátlan kódot ír, és a kollégái is?
Amúgy ez elég durva, gondolom akkor ha mégis valahol hibát fedez fel, kiírogatással próbál szerencsétlenkedni, vagy fogalmam sincs, de azért ugye az ilyenek is az átlagnál magasabb fizetéssel elég jól elvannak, miközben finoman szólva nem emelik a szakma színvonalát...(#8011) ToMmY_hun:
Köszi, végre nem csak én képviselem ilyen határozottan ezt az álláspontot. -
Szmeby
tag
Ha egy taskot küldesz be, akkor ezt szépen időzítve hajtja végre.
Közelítsük meg empirikus úton:
service.scheduleWithFixedDelay(task, 500, 1000, TimeUnit.MILLISECONDS);Szerintem első körben töröld azt az i++; sort a ciklusod közepéből, csak zavar.
Majd vedd le a max értékét 1-re, hogy lásd, mit csinál az executor 1 taskkal.
Fél másodpercet vár, majd 1 másodpercenként meglöki ugyanazt a taskot.Ha a max értékét felhúzzuk 2-re, akkor egyértelművé válik, mi történik. A két task azonnal bekerül az executorba, mindkettő vár fél másodpercet, majd egymás mellett elindulnak. És persze az executor mindkettőt 1 másodpercenként meglöki újra, továbbra is egymás mellett futnak, hiszen ugyanakkor, ugyanolyan időzítéssel készültek el.
Ha a pool méretét nem a procik száma alapján határozod meg, hanem lehúzod 1-re, majd a max értékét felnyomod 10-re, akkor is úgy tűnik, mintha egyszerre hajtódnának végre. Valójában csak 1 szálon teszik egymás után, de a task nem csinál semmit, így villámgyorsan megtörténik, az időzítésük ugyanaz, tehát továbbra is egymáshoz nagyon közeli időpontban fognak megfutni.
Megteheted azt, hogy
service.scheduleWithFixedDelay(task, i * 200, max * 200, TimeUnit.MILLISECONDS);, de lehet erre szofisztikáltabb megoldás is. Mivel ez esetben ismerned kell azt, hogy összesen hány taszkot bízol a service-re, ami nem feltétlenül ismert az első taszk indításakor.
Nem vagyok otthon ebben a szálkésleltetésben, de csak van rá valami megoldás. A többi metódusát már nézted? 3rd-party library-ket?Jobban belegondolva, nem biztos, hogy ez ennyire egyértelmű, mert a magok száma borítja a dolgot. Egy egymagos gépen evidens. De egy 4 magos gépen, 4 szálon futtatva mit vársz tőle? 4 szál párhuzamosan futtat 1-1 taskot, majd x idő múlva indulna újabb 4 task? Mi van, ha a 4-ből 1 túl hosszú, és jönne a következő kör? Olyankor csak 3 új szál induljon? Vagy egy se, és 1 kör kimarad? Ha minden egyes taskot x idővel eltolva indítanál, akkor mi értelme több szálat használni? Sőt extrém hosszú taskoknál ugyanúgy előjöhet a fentihez hasonló probléma. Vagy olyankor nem kell várni, azonnal induljon a következő task, amíg van szabad szál?
Legrosszabb esetben csinálhatsz egy custom executorService implementációt.
vissza a padba...
A kód jópofa, meg vannak hasonló parserek is, de alapvetően a formátum nem elég frappáns egy YAML vagy JSON mellett.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Teljes elbizonytalanodás...még jó, hogy csak az elején vagyunk. Bedobom az ötletet kedden, hogy maradjunk Artifactoryn, de kb máglyára dobnak. 
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- BESZÁMÍTÁS! Intel Core i7 4790 4 mag 8 szál processzor garanciával hibátlan működéssel
- GYÖNYÖRŰ iPhone 13 mini 256GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3904, 100% Akksi
- HP Dell, Lenovo, Fujitsu, üzleti kategóriás notebook kiárusítás
- Telefon felvásárlás!! Samsung Galaxy A13/Samsung Galaxy A33/Samsung Galaxy A53
- GYÖNYÖRŰ iPhone 14 Pro Max 256GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS3766, 100% Akksi
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő