- Samsung Galaxy A56 - megbízható középszerűség
- iPhone topik
- Azonnali navigációs kérdések órája
- Motorola Edge 50 Neo - az egyensúly gyengesége
- MIUI / HyperOS topik
- Google Pixel topik
- Milyen okostelefont vegyek?
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Yettel topik
- Xiaomi 14T - nem baj, hogy nem Pro
Új hozzászólás Aktív témák
-
#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.
-
DarkByte
addikt
Tippre valami ilyesmi Xeon workstation gép
Egyébként ez most az én fejemben is elültette a bogarat.. ba***a meg
-
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. -
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. -
Karma
félisten
A szó amit keresel: rate limiter. És itt egy kulcsrakész megoldás rá.
-
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.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Lenovo ThinkPad X13 Yoga i5-10310U 16GB RAM 512GB SSD 13.3 FHD Touch 2in1
- Apple iPhone 14 Plus 128GB, Kártyafüggetlen, 1 Év Garanciával
- BESZÁMÍTÁS! ASUS Z390 i7 9700 32GB DDR4 240GB SSD 1TB HDD RTX 2070 Super 8GB NZXT H510 ADATA 600W
- Lenovo ThinkPad 40AF docking station (DisplayLink)
- BESZÁMÍTÁS! Asus TUF B360-Pro i7 9700 16GB DDR4 512GB SSD RTX 4060 8GB ZALMAN S3 TG Zalman 500W
Állásajánlatok
Cég: FOTC
Város: Budapest