- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Mr. Y: Motoros sztorik #06
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- NASsoljunk: ZyXEL NSA-310 és az FFP
- Magga: PLEX: multimédia az egész lakásban
- Őskoczka
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- GoodSpeed: Samsung Galaxy SmartTag2-esek a tolvajok ellen!
Új hozzászólás Aktív témák
-
#12159
Lortech
addikt
Aethelstone
#12158
Lortech
addikt
válasz
Aethelstone
#12158
üzenetére
Ezért van külön source, target és release compiler beállítás. A source az, amit te írtál, a target és a release (9-es verziótól) pedig az, amire Ablakosnak van szüksége, ha 1.8-as runtime-mal kompatibilis (és azon is futni képes) kódot szeretne kapni úgy, hogy 23-as verzión buildel.
-
Lortech
addikt
válasz
Ablakos
#11899
üzenetére
Itt a gc egy példányszintű metódus (instance method), ami késői kötést (late/dynamic binding) használ, így a Counter futásidejű típusa határozza meg, hogy melyik gc() metódus implementáció hívódik meg (polimorfizmus). Ha SubCounter újradefiniálta (override) a gc()-t, akkor ha a list változód futás idejű típusa SubCounter, akkor az override-olt változat fog hívódni, nem tudod meghívni a Counter gc() metódusát azon a példányon keresztül.
(azért írtam zárójeleket, hogy jobban utána tudj nézni ezeknek a fogalmaknak)
-
-
Lortech
addikt
válasz
togvau
#11714
üzenetére
Egy spring alkalmazásban (is) a session életciklusa beállítás kérdése. Amit írsz, azt szerintem benézed, vagy spéci beállításod van (tehát nem szűz spring boot app ), nem ez a default működés.
Egy request feldolgozás viszonyában a session (id) alapvetően attól függ, hogy a böngésződ küldött-e a requestben session id-t (JSESSIONID cookie (default)) , és hogy mi a spring appod sessionCreationPolicy-je, ezektől függően fogja a Spring (újra)használni a kapott sessionid alapján a meglévő sessiont (az objektumot, nem az id-t) vagy újat gyártani vagy nem gyártani vagy teljesen ignorálni a sessiont (springen kívül továbbra is létrehozható session).a session.setAttribute-ban állított dolog pedig mindegyik globális, mindegy milyen böngészőről/kliensről van a beállító kérés, mindegyiknek ugyan az lesz a getattribute valami értéke amit az egyik legutoljára settelt
Ez nem így működik, pont az a session lényege, hogy egy session példányhoz és állapothoz (így a session attribútumaihoz) csak azok a kliensek férnek hozzá, amelyek azonos session id-val rendelkeznek.
Szerinted téged a spring session fixation védelme zavarhat meg, emiatt látsz különböző session id-kat és emiatt tűnik úgy, hogy a sessionök különbözőek (valójában ugyanazok a sessionök különböző session id-val), mégis ugyanazok az attribútumai. -
Lortech
addikt
válasz
togvau
#11708
üzenetére
Magától értetődően legegyszerűbb maga a session (HttpSession), ha tényleg van... Ugye ez nem egyértelmű RESTful API-nál és JWT authentikációnál, aminek statelessnek kéne lennie.
Komolyabb alkalmazásnál floodot még az alkalmazás előtt célszerű megfogni, api gatewayen, proxyn, load balanceren stb. -
Lortech
addikt
válasz
togvau
#11442
üzenetére
Áh, mavenes a projekt, ott a bibi, használj gradle-t, az ezt is megoldja.
Nyilván pontos válaszhoz kéne egész pontos infó, hogy a TLS handshake melyik ponton döglik, pl. openssl s_client kimenet, de ágyúval verébre megoldás itt:
https://stackoverflow.com/a/45444355 -
Lortech
addikt
Nagyon beakadt ez az XML. Így pár száz maven projekt és modul (és jópár plugin megírása) után azt tudom mondani, hogy az XML-t éreztem a legkevésbé problémásnak a mavenben. Csak a felszínt karcolgatod.
Én sem szeretem az XML-t különösebben, de nem érzem problémának, mert ha mavent is használ a projekt, ez nem jelenti azt, hogy egész nap ezt kell hegeszteni az egész fejlesztő cspatnak, nem olyan fajsúlyú kérdés, mint mondjuk egy frontend template, amiben egész nap hegeszt a fél társaság. A kezdeti project setup után kb. heti rendszerességű, hogy a buildünk változik, leginkább új dependency vagy verzió update miatt, ami teljesen automatikus és fájdalommentes változtatás, bármi érdemi változás ennél ritkább.
Most megnéztem egy kisebb-közepes projektet, van kb. 20 pom.xml össz. 150KB, aminek a 90+%-a copy paste-elt <dependency>, nincs mind module submodule viszonyban, tehát nem mindenhol van öröklődés, ezért a viszonylag nagy méret.Nem XML alapján döntünk, hogy maven vagy gradle.
Saját döntési szempontok:
-mi a probléma, amit meg akarunk oldani, mit kell tudnia a buildnek és mit akarunk azon kívül kezelni.
-van-e bármi nem szokványos körülmény, amiért testre kell szabni a buildet, kell-e egyedi plugint írni hozzá, ez a néhány fajsúlyosabb probléma viszi el az idő 90%-át általában.
-hol fog futni, hova és hogyan kell illeszkednie, mivel kell integrálódnia, gondolok itt meglévő projektekre, IDE-re, teszt keretrendszerre, futtatókörnyezetre, CI/CD-re, konténerekre stb.
-karbantarthatóság, mennyire egyszerű bővíteni, vagy teljesen átalakítani
-olvashatóság, átláthatóság: pl. a konvenciók, ha ismered őket, sokat segíthetnek egy projekt megismerésében egy új résztvevő számára, míg a flexibilitás, hogy kódot tudsz írni a buildben, nem mindig előny, ha a fejlesztő csapat tényleg elkezd nagy mennyiségű kódot beleütni a buildbe.
-várható fejlesztői élmény, pl. mennyire egyszerű vele belőni a fejlesztői környezetet, milyen a tooling támogatás
-megoldás erőforrás igénye (esetleges traininggel együtt)
egyszerű használni, mennyire gyors, kiszámítható és problémamentes
-csapat meglévő kompetenciája, tanulási görbe, community, dokumentáció
-megoldás várható performanciája, ha nagyobb a projekt és számít bármit
...
...
és valahol itt egy kilométerrel lentebb van az, hogy XML-e -
Lortech
addikt
Na, ki tud nagyobbat mondani a fentieknél, szakmaiságban és megalapozottságban?
Viccet félretéve, egy okból váltanám le a mavenes projektjeinket gradle-re, ha olyan jellegű performancia problémánk lenne, amin a gradle segítene, és a probléma elérne olyan szintet, hogy megérné kidobni kb. 1 hónapot az egyébként jól működő, maintenance és problémamentes projektjeink migrációjára.
-
Lortech
addikt
Ja. Ne keverjük már a kommentet egy javadoc (API) leírással. API leírás kell, ha például 3rd party használja az API-dat, aki nem tudja/akarja elolvasni a forrásodat, hogy megismerje a belső működését.
Olyan komment nem kell, ami a kódot szemeteli tele. Normális esetben a clean code egyúttal jól strukturált és jól olvasható kód is, tehát könnyű megérteni, így nem kell lépten nyomon teletűzdelni olyan kommentekkel, hogy "ez azért van, mert..", vagy "ezt ne változtasd meg mégha nagyon fura is, mert behány tőle a rendszer stb". Ugyanakkor ilyen kód nem létezik, és sokszor jól jön egy-egy magyarázó sor. -
Lortech
addikt
válasz
#68216320
#10704
üzenetére
A best practice az olvasható kód.
Ez persze bizonyos mértékig szubjektív.
Az olvashatóság lambda esetében még inkább az, erősen függ attól, hogy ki az olvasó. Ki mihez van szokva, kinek már állt rá jobban az agya. Már csak azért is, mert a lambda nem volt mindig alap nyelvi elem, és máig rengeteg kódbázis van, ami nem ilyen szemléletben íródott. Ha a csapat, aki a kódot írja és karbantartja, lambdát preferálja, akkor menjen a lambda, de azért ne ész nélkül.
Az adott problémától függ, hogy lambdával olvashatóbb lesz-e a kód, esetleg hatékonyabb vagy elegánsabb. -
Lortech
addikt
válasz
axioma
#10670
üzenetére
Nem látom át teljesen a problémádat, a streamektől nem egyértelmű, hogy mi történik. Egy működő példa talán segítene, hogy pontosan lehessen vizsgálni, mire gondoltál.
Nekem úgy tűnik, hogy a lambdák type inference limitációjába ütköztél.
Néhány link, ami indulásnak jó lehet, Brian Goetz kommentjeit érdemes olvasni:
[link]
[link]
[link]
Ha nagyon beleásod magad, javac-vel debug paraméterezéssel (utolsó link) ki lehet vsz. deríteni, hogy mi történik pontosan. -
Lortech
addikt
válasz
#68216320
#10668
üzenetére
Jonak nez ki.
Annyi megjegyzes, hogy ImageIO es a beepitett javas kepfeldolgozo megoldasok nagyon eroforraspazarloak mind memoria, mind cpu szempontjabol, es a vegeredmeny minosege sem feltetlenul a legjobb, szoval ha komoly megoldas kell, akkor erdemes ezeket kikerulni es valami nativ celeszkozt hasznalni (Pl convert (imagemagick) parancs linuxon), majd a vegeredmenyt direktben kiirni az outputstreamre. -
Lortech
addikt
válasz
#68216320
#10663
üzenetére
Kissé összemosódik a kép "nevének" (fájlnév / uri ? ) és magának a képnek a dinamikussága.
Nem világos az sem, hogy jön ide a header. Mindegy, kezdjük el és hátha kiderül, mire gondoltál./kepstream-re mappelsz egy servletet web.xml-ben vagy annotációval, request.getPathInfo-ból kiparse-olod a /kepstream utáni részt, megvan a path paramétered, amivel a képet azonosítod szerver oldalon.
Aztán a httpservletresponse outputstreamedre azt írsz dinamikusan, amit csak akarsz, akár on-the-fly generált képet, akár fájlból beolvasottat.
Plusz content-disposition, content-type headert nem árt kitölteni a céljaidnak megfelelően. -
Lortech
addikt
Az emlitett reszletek (single thread pool) nelkul nem oldja meg a problemat, a felteves az volt, hogy van ket async task, tehat a szal inditas megvolt, a kolcsonos kizaras volt a kerdes, amit az executorservice onmagaban nem old meg.
Legegyszerubb fapad megoldas elhangzott, 2-3 threadnel teljesen ok egy kozos eroforrasra lockolni. Ha nem nagyon gyors lefutasuak a szalak, ebben az esetben jobb sorbarendezni a futtatasukat. -
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. -
Lortech
addikt
Már mindegy elvileg, de azért tegyük tisztába, hogy nem a Derby használ JDBC-t, hanem a Java programod JDBC-t használva kapcsolódik a Derby adatbázishoz, már ha úgy írtad meg. A JPA (hibernate, eclipselink stb) leggyakoribb esetben egy relációs adatbázishoz való csatlakozáshoz a motorháztető alatt szintén JDBC-t használ, csak ezt magasabb absztrakció lévén elfedi előled.
Derby és JPA minden további nélkül összebarátkoztatható, egy ilyen egytáblás projekt összerakása egy tutorial alapján 10 percekben mérhető ([link]), legyen az akár standalone, vagy webes, konténeres megoldás.
Ha már telefonkönyv adatot tárolunk - nem konfigról volt szó, akkor nem látom értelmét (fájl alapon) JSON-nel vagy XML-lel szüttyögni, egy derby vagy akármilyen embedded sql/nosql megfelel a célra JPA-val kombinálva.szerk: Szvsz nincs baj az XML-lel sem, csak a megfelelő feladatra kell használni, ugyanúgy ahogy a JSON-t, Yaml, protobufot stb. Ilyen leegyszerűsítésnek, hogy XML-t úgy általában felejtsük el, szerintem nem sok értelme van, mint ahogy a 2000-es évek XML fetisizmusának se volt sok.
Ismerjük az eszközeinket és használjuk mindig a megfelelőt a megfelelő célra. [law of the instrument] -
Lortech
addikt
Nem írtam, hogy lenne baj a magyar könyvekkel, de általában minden témában vannak jobbak, nemzetközileg elismert szerzőktől. De főleg azért nem javaslom őket, mert ha valaki professzionálisan akar Javát tanulni, akkor jó, ha az angol terminológiát szokja meg. Legtöbb érdemi anyag, cikkek, szakmai fórumok, tananyagok angolul elérhetőek.
-
Lortech
addikt
válasz
XP NINJA
#10298
üzenetére
Illetve ez így gép specifikus lesz?
Ez így java runtime specifikus lesz, a cacerts ahhoz tartozik, ez egy sima fájl a lib/security mappában.
Nálam letölti a fájlt a FileUtils.copyURLToFile. openjdk-8/11 cacertsben benne van a netlock ca certje. Nincs előttem windows éppen, oracle jre ezek szerint nem tartalmazza. Tuti ugyanazzal a java runtime-mal futtatod a programodat, mint aminek a cacertsébe beimportáltad a certet? -
Lortech
addikt
válasz
Drizzt
#10214
üzenetére
Ha azt csinálod, akkor azzal meg tudod akadályozni, hogy a "impl1.add(impraw);" illetve a "impl2.add(impraw);" leforduljon.
De azt is megakadályozza, hogy az
impl1.add(impl1);
impl2.add(impl2);
forduljon. De ja, igazából nem vagyunk sokkal beljebb az IF1<T> fordítási idejű típussal sem az Imp1 / Imp2 helyett. IF1<T> -vel mind a két imp típuskompatibilis - nem úgy a Matrixtype és Vectortype egymással -, ezért nem kapsz classcastexceptiont, ahogy a példádban viszont igen. Fordítás időben kéne tudni kiküszöbölni ezt az esetet, de a generikusok erre nem jók javában. -
Lortech
addikt
válasz
axioma
#10211
üzenetére
Röviden: tényleg nincs.
Csinálhatsz generikus interface-t:
public interface IF1<T extends IF1> {
void add(IF1<T> other);
}
public class Imp1 implements IF1<Imp1> {
@Override
public void add(IF1<Imp1> Other) {
}
}
public class Imp2 implements IF1<Imp2> {
@Override
public void add(IF1<Imp2> other) {
}
}
{
IF1 impraw = new Imp2();
IF1<Imp1> impl1 = new Imp1();
IF1<Imp2> impl2 = new Imp2();
impraw.add(impraw);
impraw.add(impl1);
impraw.add(impl2);
impl1.add(impl1);
impl1.add(impraw);
impl2.add(impl2);
impl2.add(impraw);
pass(impraw, impl1);
pass(impl1, impraw);
pass2(impl2, impl1);
}
private static void pass(IF1<Imp1> one, IF1 other) {
one.add(other);
other.add(one);
}
private static void pass2(IF1 one, IF1 other) {
one.add(other);
other.add(one);
}De ez jobbára csak bohóckodás, mert ha használni akarod, úgyis meg kell adnod a típus paramétert fordítás időben, hogy garantáltan *csak saját magával tudd átadni neki, vagy típus paraméter nélkül hagyod és unchecked leszel. Valamint raw IF1 (impraw-t) IF1 példányt oda vissza tudod passzolgatni futási és fordítási hiba nélkül.
-
Lortech
addikt
Szerintem ha alapszinten programozni akarsz megtanulni akár java-ban, vagy akár másban, akkor először ne ui-ra, grafikára koncentrálj, mert nem ez a lényeg. Alkoss egy (állapottér) modellt fejben a játékodhoz, azonosítsd a különböző entitásokat, azok tulajdonságai, lehetséges állapotváltozásait, a játék logikáját. Vesd papírra, majd kezdj el gondolkodni rajta, hogyan lehet ezt Javába átültetni.
Ha kész a "motor", akkor érdemes a megjelenítésen elkezdeni dolgozni. -
Lortech
addikt
Ha engem kérdezel, 1 óra alatt szerintem nem lehet, és nekem nem is célom. Reális cél számomra annak eldöntése, hogy együtt akarok-e dolgozni a jelölttel, ennek egy - fontos, de nem mindenek felett álló - összetevője a szakmai tudás.
Junioroknál szoktam javasolni inkább, hogy tesztsor vagy kódolós feladat legyen.
Senior esetén nálam szakmai beszélgetés jellegű az interjú, nem kérdezz felelek. Persze ehhez kell az, hogy a másik fél partner legyen ebben és jól tudjunk együtt gondolkodni, kommunikálni. -
Lortech
addikt
válasz
axioma
#10185
üzenetére
Lehet ilyeneken szörnyülködni, de ezek tudása / nem tudása pont nem mond el semmit arról, hogy az illető milyen szoftverfejlesztő.
Sok-sok interjún túl számtalan példát tudnék hozni, hogy ki mit nem tudott interjún, olyanok is akiket később felvettünk és tök jó kollégák lettek. Valószínűleg tőled is lehetne java témában 5/5-öt kérdezni, amit nem tudnál, ~mindenkitől. -
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. -
Lortech
addikt
válasz
bambano
#9975
üzenetére
"Fizetős lesz a java az Oracle-től": igen.
Nem.
Még úgy sem állja meg a mondat a helyét, hogy a frissítések lesznek fizetősek.
Azzal a kitétellel állja meg a helyét, hogy bizonyos főverziók frissítései és támogatása és bizonyos idő után.
Mondhatná azt is, hogy lófütyit nektek, EOL után nem csinálok frissítést, helyette megpróbál pénzt csinálni belőle. Tetszik nem tetszik, nekem ugyan nem tetszik, de maradjunk a tényeknél egy szakmai topikban, a riogatást, félinformációk terjesztését, térítést meg hagyjuk.szerk: itthagyom, de áthúzom, mert félrevezető. Tévedtem, az állítás a 10-es verzióig bezárólag állja meg a helyét, az Oracle JDK használata a 11-es verziótól kezdve valóban nem ingyenes "üzleti célú" felhasználásra.
-
Lortech
addikt
válasz
Amartus
#9971
üzenetére
Nem olvastam a cikket, de vagy hülyeséget írtak, vagy félrevezetően írták, vagy féltreértelmezted (valószínűleg utóbbi). A "java" használata továbbra is teljesen ingyenes. A 8-as verzió támogatása szűnik meg 2019-ben, a támogatásért kell fizetni onnantól kezdve, ha igénybe szeretnéd venni. Tehát továbbra sem akadályoz meg semmi abban, hogy 8-as verzió legutolsó kiadását használd az ingyenes támogatás lejárta után is. De ajánlott gyorsabban átállni újabb verziókra.
-
#9935
Lortech
addikt
Aethelstone
#9934
Lortech
addikt
válasz
Aethelstone
#9934
üzenetére
Ha restcontroller, akkor feltetelezhetjuk, hogy spring @RestController, default jackson, es @RequestBody automatikusan deszerializalodik (sajat típus is), ha lehetseges. Tehat nem feltetlenul kell egyedi (de-) szerializaciot faragni hozza.
REST(-ful webservice) pedig ugyancsak webszerviz ebben a kontextusban, ahogy a SOAP, en nem szeretem ezt a megkulonboztetest. -
#9918
Lortech
addikt
Aethelstone
#9917
Lortech
addikt
válasz
Aethelstone
#9917
üzenetére
Ez oké, amikor egyedül toljuk a saját garázs projektben, viszont csapatban illik a standardek, konvenciók, ajánlások szerint fejleszteni, mert jó esetben ez az, ahogyan a többi csapattag is fejleszt, egy új csapattagot így lehet legkönnyebben beilleszteni. Volt szerencsem mar sokfele tragya munkahoz sajnos, ahol a tragya megoldasok valtak konvenciokka, es igen kellemetlen tud lenni, mikor mindenki hulye a csapatban, csak en vagyok helikopter.
Nalam az & PR-nel azért menne a levesbe boolean operandusok eseten, mert a fejlesztok tobbsege szerintem csak a bitenkenti ES jelenteset, egeszeken ertelmezve ismeri es dobna egy exceptiont, ha ilyet lat, es ez netto kidobott ido, ha egy sima feltetelen gondolkodni kell. -
#9914
Lortech
addikt
Aethelstone
#9913
Lortech
addikt
válasz
Aethelstone
#9913
üzenetére
Jól mondod, de én még tovább mennék: nem nem csak, hanem egyáltalán nem hatékonyság kérdése. Ha ugyanarra volna való a két operátor, csak az egyik hatékonyabb lenne, akkor nem is létezne a kevésbé hatékony.
Abban a nagyon ritka esetben, mikor &,|,^ valamelyikét írod boolean operandusok esetén és nem elírtad, akkor 99,99..%, hogy a rövidzár/nem rövidzár különbséget akarod valamiért kihasználni. -
Lortech
addikt
válasz
bambano
#9848
üzenetére
Jaj istenkém, hát így hívják az exceptiont, béna, inkonzisztens elnevezés. És akkor mivan?
Historikusan (pl. C és társai esetén) mutató típushoz olyan többletjelentést (pointer aritmetika) társítunk, ami Java referenciáknak nincs, ezért szoktuk különválasztani a kettőt. -
-
#9844
Lortech
addikt
Aethelstone
#9841
Lortech
addikt
válasz
Aethelstone
#9841
üzenetére
(bocs, válaszra nyomtam, de nem csak neked írtam)
-Null-ra instanceof String false-t ad természetesen. Null az null típusú.
-Pointerezést hagyjuk már, nincs pointer javában, referencia van. Nem ugyanaz a kettő, úgyhogy nem csereszabatos a két fogalom.
-Az eredeti példában AskDeviceName null, és mivel isEmpty egy példány szintű metódusa a String oszálynak, ezért kapsz nullpointexceptiont, mert null referencián próbálod hívni a metódust. Objektum példányod viszont nincs.
-primitív típusoknak van default értékük, ha mezők. Lokális változokként inicializálatlanok by default, compile time error rájuk hivatkozni. -
-
Lortech
addikt
válasz
<Lacy85>
#9813
üzenetére
Java EE-ben JSF van, használható, de nincs benne túl sok perspektíva szerintem. Ahogy úgy általában a Java alapú frontend fejlesztésben.
Elhangzott már a GWT és Vaadin, előbbi alacsonyabb szintű, jól kiforrott megoldás, utóbbival gyorsan lehet használható frontendet készíteni.
Van még sok egyéb, pl. a Play fw, vagy az Apache webes frameworkök mint Struts/2, Wicket, Tapestry, Stripes.
Ott van a Spring (web) MVC pl. thymeleaffel.
Én már nem tervezek/fejlesztek új projekten java alapokon frontendet, a legtöbb esetben java az API-kat szolgáltatja, valamint a middleware-t, backendet, a frontend pedig böngészőben fut valamelyik javascript alapú frameworkön/libraryben megvalósítva, pl. React, Vue.js vagy Angular valamelyikében. -
Lortech
addikt
válasz
<Lacy85>
#9811
üzenetére
Új frontend fejlesztésre JSP-t nem javaslom, egyáltalán nem. Függetlenül az Oracle és Java EE viszonyától, mert ez itt irreleváns. JSP már nem fog fejlődni érdemben, ha Oracle diktál Java EE fronton, ha nem.
Érdemes lehet max pár órát rászánni, megnézni, hogy ilyen is volt, hozzátartozik az evolúcióhoz címszóval, kipróbálod, megérted, pipa, next. Servlet speccel azért érdemes lehet tisztában lenni.A "dobja az Oracle" lehet pozitív vagy negatív is, én inkább pozitívumként élem meg, hogy hátralép egyet és átengedi a communitynek az irányítást, a tényleges következményeket utólag lehet majd értékelni. A jelenlegi állapotában a Java EE egy használható platform. Amire nincs jelenleg Java EE spec, és reális igény, azt belegózhatod majd külső libraryként a stackbe, mint ahogy teheted most is. Én akkor se aggódnék néhány éves távlatban, ha nem volna egyáltalán Java EE fejlesztés. De erről nincs szó.
-
Lortech
addikt
Most tényleg kérdőjel van az exceptionben, vagy csak nem akartad leírni a konkrét hibát?
Én először megnézném, hogy az adott requestre adott válasz érvényes-e a wsdl-re.
Pl. Soapui megmondja a response-on jobb klikkre.
Aztán leellenőrizném, hogy a wsdl nem változott-e időközben, ugyanazt a wsdl-t implementálja-e a végpont, mint amiből a kliens lett generálva (?).
Ha már muszáj debuggolni, akkor IDE-ben be tudsz állítani exception breakpointot az exception típusra. -
Lortech
addikt
válasz
Vesporigo
#9701
üzenetére
Amikor deklarálsz egy metódust, mindig meg kell adni a visszatérési értékének típusát vagy a voidot.
Vegyünk két metódust:
void m1() {
}String m2() {
return "visszatérési érték";
}m1 void, ami azt jelenti, hogy nincs visszatérési értéke, azaz a metódus hívás nem használható olyan kontextusban, ahol egy értéket várunk.
pl.
String x = m1(); //hibás, mert m1 nem tér vissza értékkel.
System.out.println(m1()); //hibás, mert m1 nem tér vissza értékkel.
x = m2(); // ok, x értéke "visszatérési érték" leszUgyanígy m1 metódus törzsében nem adhatsz meg pl. return "xyxy"; utasítást, mert nem térhetünk vissza értékkel, ellenben megadhatunk return; utasítást, amivel jelezzük, hogy adott ponton térjen vissza a metódus (visszatérési érték nélkül).
pl.void m1() {
return "xyxy"; //hiba
return; //ok, de nem kötelező, itt felesleges
} -
Lortech
addikt
Ez javascript, nem java.
Alábbi példából talán ki tudod hámozni, ami neked kell, a screenshot alapján készült a struktúra, nem tudtam pontosan azonosítani.
var sampleObj = { cid: 'genBasic',
data: {
xiaomiStruct:
[
{ index : 100, data: 0 },
{ index : 150, data: 2205 }
]
}
}
var indexToLookFor = 150;
var dataObj = sampleObj.data.xiaomiStruct.find(function(e) {
return e.index == indexToLookFor
});
console.log(dataObj.data); -
Lortech
addikt
Pedig a standalone/domain.xml-ben kell beállítanod a security domainedet. A security domain / realm az nem 1:1 egy alkalmazáshoz kapcsolt, hanem alkalmazások fölött álló koncepció. JAAS infrastruktúra és Java EE pedig nem ad standard megoldást arra, hogy hogyan kell az alkalmazáshoz security domaint rendelni. Ezért van az, hogy jboss-web.xml-ben kell megadni. Vagy standalone/domain.xml-ben default security domainnek beállítani.
jboss-web konfiguráció itt van említve: [link]
security subsystem pedig itt van leírva: [link]
Ebből látszik, hogy a Database / DatabaseUsers modul a webes admin konzolon
a org.jboss.security.auth.spi.DatabaseServerLoginModul-t jelenti.
Tutorial: [link]Fontos, hogy wildfly 11-től elytron alrendszer van és önmagában kevés a fenti legacy konfiguráció.
Migráció: [link] -
Lortech
addikt
UsersRolesLoginModule az egy fapad login module, property fájl alapú, nem tud db-ből authentikálni.
Amit én linkeltem, az direktben a datasource-on keresztül jdbc-zik, de simán lehet írni JPA alapú login module-t, írtam is már wildflyra, weblogicra.. Nem triviális, de nem is ördöngősség.
Pl. csinálsz egy EJB szolgáltatást ami JPA-n keresztül elvégzi az authentikációhoz szükséges ellenőrzést. A loginmodule-ból pedig JNDI-n keresztül lookupolod az EJB-det. A loginmodule-t csomagolhatod az alkalmazásodhoz is, nem muszáj külön modulként telepíteni.
Belépés után httpservletrequestből (JSF-ben facescontexten keresztül) elérhető a felhasználó a getUserPrincipal metódussal (getName normálisan a felhasználó nevét adja vissza), ezzel bekérdezhetsz az adatbázisodba. Van még isUserInRole is ugyanitt. -
Lortech
addikt
Nem definiáltál az entitásaidba relációkat, legalábbis nem látszik. Anélkül nem nagyon fog menni és FK be fog utagni, meg nyilván generátor se fog tudni jó db sémát generálni így. Ajánlott olvasmány: JPA relációk, de úgy általában JPA.
EntityManager em= getFactory().createEntityManager();
em.getTransaction().begin();
Event evt= new Event(new Date(),em.merge(getGod()),event, success);
em.persist(evt);
em.getTransaction().commit();
em.close();Ezzel itt az (lehet) a baj, hogy amint lezárod az EntityManagert, az összes managed entitás példányod, amit a persistence contextben használtál, detached lesz. Ennek pedig az a következménye, hogy a még be nem töltött, lazy load relációk nem tudnak majd betöltődni, ill. az objektumok módosítása esetén nem lesznek automatikusan perzisztálva sem.
-
Lortech
addikt
Azt értettem alatta, hogy az entitásban/db-ben a probléma mezőt/oszlopot nem jól definiáltad.
Pl. nem jó oszlopnevet adtál meg.
Detached entity passed to persistnek számos oka lehet. Kézzel állítasz be kulcs mezőket mentés előtt? Másodjára persisttel már nem fog menni, mert már létezik adott kulcsú mező, viszont az entity detached állapotban van, mivel még a persistence contextedbe nem töltődött be (pl. merge-dzsel tudod manageddé tenni). Látatlanban okosabbat nem tudok mondani. -
Lortech
addikt
-
Lortech
addikt
Na ez az az irány, amit nem kéne erőltetni.
Javaslom, szervezd EJB-be az üzleti logikádat és az adathozzáférést, és azt injektáld a JSF managed beanbe. Mert az nem arra való, hogy direktben JPA-zz és tranzakciót kezelj benne.
AZ EJB-be pedig injektáld az entitymanageredet pl. az általam fentebb írd módon. Így nem kell foglalkoznod az entitymanager létrehozásával, életciklusával (pl. hogy többször létrehozod a factory-t, mint ahogy tetted).
BalusC tutorialjait, megoldásait érdemes olvasni, ő jó forrása a JSF-fel kapcsolatos megoldásoknak: [link]JAAS-hoz: a login-config.xml az jboss szerinti leíró, wildfly-on máshogy néz ki.
wildfly login module pl (standalone.xml vagy domain.xml megfelelő profiljában):<security-domain name="xysecdomain">
<authentication>
<login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
<module-option name="dsJndiName" value="ds jdni név"/>
... többi opció ...
</login-module>
</authentication>
</security-domain>De mindez megtehető webes admin konzolból is.
Aztán jboss-web.xml-ben kell egy <security-domain>xysecdomain</security-domain> hivatkozás, ami a webalkalmazásodat összekapcsolja a security domainnel wildfly-ban.selectItem vs enum passz, szerencsére már rég JSF-eztem.
-
Lortech
addikt
Wildfly picketboxot használ jaasra, van olyan login module, hogy
DatabaseServerLoginModule.
Meg lehet adni neki datasource-ot paraméterként és jdbc-vel hozzáfog férni a db-dhez. Nem tudom, friss-e a leírás, de bele lehet nézni a login module forrásába. -
Lortech
addikt
Kézzel úgy tudtad feloldani helyesen a jsf-et, hogy a wildfly-odban lévő verziót (az appszerverben lévő verzióval pontosan megegyező) adtad hozzá, bármely más jsf lib hozzáadása lehet, hogy elfedi a hibaüzenetet, de problémát okozhat (és semmiképp se csomagold bele az elkészült artifactodba függőségként)
Hibernate a jpa implementáció wildflyban. Provider helyére: org.hibernate.ejb.HibernatePersistence kell.
A Wildfly szervereden definiálsz egy datasource-ot (standalone/domain.xml-ben kézzel
![;]](//cdn.rios.hu/dl/s/v1.gif)
, vagy jboss-cli-ben vagy webes admin konzolon), majd a persistence.xml-ben (ear-ban META-INF könyvtárba, war-ban WEB-INF/classes/META-INF könyvtárba) beállítod a datasource-ot.<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"
version="2.1">
<persistence-unit name="mysqlpu" transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:jboss/datasources/mysqlds</jta-data-source>
<properties>
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect"/>
</properties>
</persistence-unit>
</persistence>Ezután a managed beanekből már tudod injektálni az em-et:
@PersistenceContext(unitName = "mysqlpu")
protected EntityManager em; -
Lortech
addikt
-
Lortech
addikt
A maven nem bloatware, a Javás világ jelentős része használja, nem azért, hogy szívassa magát, hanem hogy megkönnyítse vele a saját életét.
Az elkészült artifactok méretét nem befolyásolja érdemben (opcionális maven leírókat leszámítva), hogy mavent használsz, ellenben 2 perc alatt lehet egy működő webalkalmazás vázad egy megfelelő archetípusból generálva, ami azonnal telepíthető, war/ear release-t készít. Sőt 1 perc bekonfigurálni egy maven plugint, ami deployol is neked a wildflyra. Csak érteni kell hozzá.
De a te kézzel összevadászott librarys gányolásod biztos gyorsabb, hibamentesebb, profibb lesz. -
Lortech
addikt
Vagy TomEE, ha már...
mobal: egyszerűnek egyszerű, de csak egy servlet konténer, így nem alternatívája egy Java EE alkalmazásszervernek.
Amúgy a wildfly is tök egyszerű, alapból is, de elég jól testre is szabható, moduláris.
Productionben pedig leginkább ugyanazon kell futni, mint fejleszteni (persze lehet egy lightosabb profilon), különben tökönlövöd magad, Java EE kompatibilitás ide vagy oda. -
#9553
Lortech
addikt
Aethelstone
#9552
Lortech
addikt
válasz
Aethelstone
#9552
üzenetére
Bár nem rólam van szó, de ha már ... Igen, abszolút kódolok és reviewzok. Nem ilyen enterprise architect vagyok aki meetingekre jár és ott okoskodik. De, elég részletesen bele tudok merülni a technológiákba igen, hiszen ez a munkám, hogy meghatározzam az irányokat. Azért felelek, hogy jó döntéseket hozzak és jó irányba tereljem a projektet és csapatot, sőt a cég stratégiáját.
Dev környezetet, infrát,, db-t, CI-t, fejlesztői teszt alap struktúráit, integrációt, az alap framewörk megoldások elsőprő többségét, a fejlesztési folyamatot, a branchelési stratégiát meg még ki tudja mit én rakom össze. Csapattagok többnyire feature-t fejlesztenek.Írtál pár dolgot, mi az, ami miatt Spring, de semmit arról, hogy mi az, ami miatt nem Java EE.
JSF-hez hozzá sem nyúltam pár éve, előtte sem saját elhatározásból.
Java EE nem azt jelenti, hogy akkor JSF-et kötelező használni webre. Eleve nem csak webalkalmazás létezik, másrészt meg hülye lennék JSF-et választani, sőt bármilyen Java alapú webes frameworköt.
Nem volt "JSF vs gwt/vaadin", csak a te fejedben, Már csak azért sem, mert Java EE és gwt / vaadin semennyire sem zárja ki egymást. A JSF-fel csak tippeltem, hogy az biztos nem szíved csücske. Nekem se, de a Vaadint is hasonló baromkodásnak tartom.Alkalmazás-szerver vs Servlet Container. Szerintem erről ne nyissunk vitát.
Hát a semmivel nem tudok vitatkozni.Spring Data - Deltaspike, két saját projekten eddig bevált.
Spring Boot - ezzel mit szeretnél? Ezért használjon valaki Springet? Enélkül nem élet az élet? Csak így lehet?
Spring Rest - egy REST API az valami olyasmi, amire csak a Spring lenne képes 2017-ben? Lehet, hogy csak álmodtam, hogy ma is vagy 5db REST API-t implementáltam A-Z-ig (wildfly / resteasy).Satöbbi. Igen, rühellem az EE-t. Pont. Befejeztem.
El se kezdted, de oké, nem is számítottam többre. -
#9549
Lortech
addikt
Aethelstone
#9545
Lortech
addikt
válasz
Aethelstone
#9545
üzenetére
Spring fanboykodáson felülemelkedve amúgy érdekes vita lehetne - bár nem valószínű
- , ha írnál valami releváns szakmait is azon kívül, hogy gyűlölöd a Java EE-t. Nem téríteni szeretnék, nekem se a Spring, se a Java EE nem a drágaszágom.
JSF ami zavar? Mást igazából nehéz elképzelnem, hogy mitől viseltetsz ekkora ellenszenvvel Java EE felé. Van megalapozott szakmai alapja vagy csak valami berögződés? Netán előző életedben EJB 1.1-et kellett használnod glassfish 1.0-n és azóta is rémálmokat okoz?
Elmúlt 4 évben többségében architektként 10+ Java EE projektem volt , de több Springes is, sőt most van egy OSGi leváltás is, volt zöldmezős, brownfield, meg totál legacy is. Sosem éreztem, hogy Spring az húde, Java EE meg blee.
Amikor tech stacket mérlegelünk architekt boardon, akkor általában sokadik szempont, hogy a Spring jellegéből fakadóan néhány lépéssel Java EE előtt jár.
GWT-t használsz meg Vaadint, közben írod, hogy IT-ban az évek az örökkévalóságot jelentik, holott ezek sem éppen jövőbe mutató technológiák finoman szólva és a trendek nem efelé mutatnak. Hogy van ez? -
#9534
Lortech
addikt
Aethelstone
#9532
Lortech
addikt
válasz
Aethelstone
#9532
üzenetére
Mitől lenne temető? Ennyi erővel az iparág 90%-ára rá lehet mondani, hogy temető. Pl a Javára is úgy általában.
Ha most azt mondta volna az Ora, hogy Java EE 8 volt az utolsó, és beszántja a francba, akkor is alaphangon egy évtized mire tényleg kikopik. -
Lortech
addikt
Egyszer már kérdezted ezt. "Hagyományos értelemben" vett többszörös öröklődés nincs, ha pl. a C++-szal összevetésben vizsgáljuk a kérdést. Ha egy tesztben látod ezt a kérdést, akkor a tesztíró fejével kellene gondolkodni, mert nem biztos, hogy a hosszú válaszra kíváncsi. DE a nincstől bonyolultabb a téma.
Az interface, ahogy emvy anno rámutatott, gyakorlatilag egy abstract class csak publikus metódusok body nélkül (+final static mezők és static metódusok implementációval). Többszörös öröklődés van Javában a saját terminológiája szerint, viszont megkülönbözteti az állapot (ilyen nincs Javában, az interface esetleges statikus mezőit nem tekinti annak, hiszen osztály szintűek), implementáció (default interface Java 8-tól, +esetleg static interface method, szintén Java 8-tól) és típus (interface) szerinti többszörös öröklődést. -
Lortech
addikt
válasz
sztanozs
#9452
üzenetére
Normális helyen nem szakbarbár fejlesztők vannak, hanem intelligens emberek, akik a fejlesztésen túl egyéb
kapcsolódó területeket is képesek megismerni, átlátni a szükséges mértékig.Business analyst semmiképp sem csinál technikai specifikációt az üzleti igényből. Üzleti igényből készíthet pl. funkcionális specifikációt, user storyt vagy bármit, ami már közelebb áll ahhoz, ami közös alapot képezhet a fejlesztőkkel. De egyáltalán nem szokatlan normálisan helyen sem, hogy egy fejlesztő csapat dolgozza fel az üzleti igényt és talál ki megoldást rájuk, hiszen a szoftverekhez sokkal jobban ért mint az üzlet. Pl. az üzlet nem fogja neked megmondani, hogy milyen egy modern ergonomikus, jól használható webes felület.
Persze az értelmes vitát úgy kéne kezdeni, hogy ki mit ért technikai specifikáció alatt, üzleti elemző alatt, üzleti igény alatt, mert ezek cégenként, területenként mást és mást jelenthetnek. -
Lortech
addikt
válasz
Cathfaern
#9407
üzenetére
Már linkelték a nem pollozós, eseményalapú megoldást. Ez ha lehetséges, akkor az OS funkcióját veszi igénybe, amely értesíti a változásról, amikor az történik.
A pollozás általában kerülendő, ha van más megoldás, és itt van. Nem is biztos, hogy bármennyire is megoldás a pollozás, az eredeti igényben szerepelt az azonnaliság. Továbbá nem biztos, hogy értesülsz egyáltalán egy változásról, pl. létrehozás és rögtön utána törlés esetén, ha az két poll közé esik. Ez vagy releváns az adott probléma szempontjából, vagy nem. De egy nagyobbacska (több ezer elemet tartalmazó) mappa is meg tudja nehezíteni az ilyen naiv megoldások működését, ha folyamatosan pollozni kell. -
Lortech
addikt
válasz
#74220800
#9392
üzenetére
Kell nekik egy közös ős, interface vagy base class, pl.
public interface Queue<E> {...}
aztán
public class QueueArray<E> implements Queue<E> {}
végül
public static <E> long counter(Queue<E> c, int r) {Persze nem írtad, hogy néz ki az általad kreált két class és hol lenne ez a metódus, illetve nem tudni pontosan mit akarsz ezzel, de gyanús, hogy érdemesebb lenne eleve az interface-be vagy base-be tenni ezt a countert, példány szinten.
-
Lortech
addikt
A segítségkérésed itt offtopik. Nem csak a processing vs java miatt, hanem az "oldja már meg valaki helyettem a beadandómat" is.
Ez itt egy fórum, aminek az az értelme, hogy tudást, véleményt osszunk meg.
Te meg privátban kértél segítséged, konkrétumot nem írva, kvázi arra utalva hogy oldja meg helyetted valaki. Hülye lesz bárki minimum órákat beletenni és téged pátyolgatni, csak azért, hogy neked jó legyen.
Van álláshirdetés kategória. Ha azt akarod, hogy csinálja meg valaki helyetted, akkor tedd fel oda a hirdetésed.
Az meg, hogy neked áll feljebb, szánalmas. Magyar ugar? Tanulj, olvass el egy könyvet esetleg, ne másoktól várd a megoldást.
Amúgy meg levelező szakon alapvetés, hogy nem fogják neked szájbarágósan leadni az összes szükséges tudást, azért levelező. Azt feltételezi, hogy a hiányzó részt te rakod mellé. Lehet, hogy tájékozódni kéne mielőtt minden szar, csak a szegény diák nem, akinek dolgoznia kell a tudásért. -
Lortech
addikt
-
Lortech
addikt
válasz
smallmer
#9299
üzenetére
Az alapokat azért nem ártana elsajátítani mielőtt nekiállsz egy hello worldnél komolyabb feladatnak. Az értékadás pl. elég alap.
A kliensek.get(i) egy függvényhívás. Függvényhívás mint bal oldali kifejezés azt jelentené, hogy a hívás visszatérési értékének akarsz értéket adni. Ennek nincs értelme nyilván javában. Értéket adni változónak lehet. Egy lista adott elemét a set metódussal tudod lecserélni.
szerk: mindegy, már itt marad. -
Lortech
addikt
válasz
smallmer
#9292
üzenetére
A lista nem tömb, ha a listából törölsz egy elemet, akkor csökken a lista hossza.
Tehát az utolsó for ciklusodban, ha jól látom i=4-nél már csak 3 elemed lesz a listában, és nem tudsz megcímezni a get(4) hívással 4-es indexű elemet. Ha minden elemet törölni akarsz, akkor MyList.clear(); Ha egyesével akarod, akkor mindig az elsőt a MyList.remove(0) hívással, vagy inkább iterator.remove. -
#9226
Lortech
addikt
Aethelstone
#9224
Lortech
addikt
válasz
Aethelstone
#9224
üzenetére
Jasperreports is Apache POI-t használ xlsx generálásra (JRXlsxExporter).
Ill. használhat még jexcelt, de az csak xls-re jó (JExcelApiExporter).
Szerintem Apache POI-nál jobb ingyenes alternatíva nincs jelenleg. -
Lortech
addikt
Kő!
Akkor kvázi json-rpc-szerűséget csinálsz?
Azért pl. cache-elhetőség és az api-d könnyű megismerhetősége, akár dokumentáció nélkül fontos szempont lehet. Főleg, ha nem nálad van a frontend, hanem másik csapatnak, beszállítónak kell kommunikálni resource-onként (vagy nálad inkább végpontonként), hogy mi hogy működik. A HTTP metódusok szemantikája lehet közös pont. -
#9199
Lortech
addikt
Chesterfield
#9198
Lortech
addikt
válasz
Chesterfield
#9198
üzenetére
Ha már 4 félév, akkor már miért nem 6 és van egy szakirányú diplomád. Nagy az átfedés a két képzés között, sok esetben ugyanazok az oktatók tanítanak, de az elvárások alacsonyabbak lehetnek - amik amúgy sem túlságosan magasak a példaként felhozott helyen.
Interjú másik oldaláról nézve én biztosan "nagyon megkérdezném" a jelöltet fejlesztői pozícióra, ha ilyen végzettséggel jelentkezik, de a végén úgyis a tudás döntene. Ha a képzés mellett egyénileg képzed magad és elhelyezkedsz gyakornokként közben, akkor van esély ledolgozni a kisebb értékű papírból eredő hátrányokat.Egyébként ha a tudás megvan, egy nem szakirányú műszaki diplomával is simán felvesznek. Pl. vannak/voltak villanyos, gépész, matematikus, fizikus, vegyész, közgazdász fejlesztő / tesztelő kollégáim. Az elején kompromisszumot kell kötni, és bárhogy bejutni valahova, ahol releváns tapasztalatot tudsz szerezni.
-
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
válasz
Taoharcos
#9190
üzenetére
Nem tőlem kérdezted, és csak részben válaszolok.
Számomra a Vaadin (és hasonló megoldások) legnagyobb hátránya az egész megoldás alapfilozófiája, ami egyébként legnagyobb előnye is volna egyben. Az, hogy megpróbálja a webet elfedni a Java programozó elől a webalkalmazásokkal kapcsolatos általános problémákat és technológiákat, html-t, css-t, javascriptet. Kapsz egy keretet és előre meghatározott eszközkészletet (pl. komponenseket), amiből össze tudsz legózni egy webalkalmazást anélkül, hogy igazán értenél a webhez, nem sűrűn kilépve a Java adta komfortzónádból. Ezt kínálja elméletben. A gyakorlat természetesen nem ilyen egyszerű, mert vannak a fránya ügyfelek, felhasználók, akik nem uniformizált szoftvereket akarnak, hanem egyedit, a nekik legmegfelelőbbet, testreszabottat, pont olyat, amilyet elképzeltek.A gond ott kezdődik, amikor ki kell lépned a készen kapott megoldások keretei közül és bővítened kell az eszközkészletet egy saját megoldással, vagy hibába futsz bele, vagy a kapott keretek szűkösnek bizonyulnak egy adott probléma megoldásához. Ez pedig fájdalmas lehet, elviheti azt a produktivitásbeli előnyt, amit korábban megnyertünk.
Az én munkám - sajnos vagy szerencsére - olyan, hogy sokféle, teljesen különböző projektünk van, és teljesen egyedi igényeknek kell megfelelni, ritkán tudjuk egy komponens halmaz által szabott lehetőségekhez igazítani az igényeket, ezért nincs csak egyféle megoldás, amit mindig használunk, pl. egy extjs, ami egyébként tök oké a licencelését és a releaselésüket leszámítva.
Egyébként azt gondolom, hogy 2017-ben gyors, modern, igényes, reszponzív webalkalmazásokat aligha lehet erős webes frontend tudás és némi designer véna nélkül fejleszteni, ehhez képest pedig igencsak kompromisszumos megoldásokat nyújtanak az ilyen előre definiált komponensekkel operáló frameworkok, mégha a megjelenítésük jól testre szabható is. Én azt mondom, hogy aki nem frontend fejlesztő, és nem érdekli a frontend annyira, hogy a szükséges dolgokat megtanulja hozzá, annál felesleges a frontend fejlesztést erőltetni. /Persze nyilván teljesen mások lehetnek az igények egy enterprise intranetes webalkalmazásnál, mint egy csillivilli, milliós végfelhasználói bázist különböző eszközökre optimalizáltan kiszolgáló alkalmazásnál./ -
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.
-
#9118
Lortech
addikt
Chesterfield
#9117
Lortech
addikt
válasz
Chesterfield
#9117
üzenetére
Ahogy elhangzott, előbb eldöntendő, hogy unit tesztet vagy integrációs tesztet akarsz írni.
Mivel nem írtál konkrét kódot, nem tudható, hogy van-e olyan metódus az osztályában, ami tartalmaz olyan logikát, amit érdemes unit teszttel lefedni. Ha van, a 9114 jó irány. Ha integrációs tesztet szeretnél írni, az a 9110-es irány.
Ha csak gyakorolni szeretnél, érdemes mindkettőt kipróbálni. -
#9084
Lortech
addikt
Aethelstone
#9079
Lortech
addikt
válasz
Aethelstone
#9079
üzenetére
Erre poénból rákerestem, és lám: [link]
-
Lortech
addikt
Ok, ha megfordítod, SVN mellett mi szól? Egyet tudok mondani, az egyszerűséget, ami abból fakad, hogy nem dvcs. Talán még a részleges checkout, ha valakinek ez szempont.
A git szerintem a legtöbb dolgot jobban tudja, flexibilisebb, rengeteg parancs van, végtelenségig paraméterezhető, gyors, hatékony, mindenre ráhúzható. Komplex problémákat lehet vele megoldani viszonylag egyszerűen. Egyszerűen git > svn.
A szakma SVN-nel szemben ezt preferálja egy ideje, legalább is az a rélsze, amivel én találkozom. Enterprise nyilván lassabban mozdul. Open source közösség egyre inkább ezt preferálja, github kb. megkerülhetetlen manapság, ha kimaradsz, lemaradsz - az eredeti kérdés szempontjából ezt tartom lényegesnek.
Konkrét előnyét is éreztem mostanság az elosztottságnak, normálisan tudtam dolgozni olyan ügyfélnek, akinek a repójához VPN kell (ez a VPN elég trükkös, és igencsak megnehezíti az életet, ha megy). Házon belül több fejlesztővel (folyamatos) VPN elérés nélkül tudtunk dolgozni, egymásnak reviewzni a saját workflownkban, saját eszköztámogatással az ügyfél dolgaitól teljesen függetlenítve magunkat, minden probléma nélkül, elegáns megoldással.
Egyébként most kéne presaleselnem egy svn > git átállást ügyfélnek, az anyagot lehet, hogy megcsinálom, de simán nem erőltetem (nem támogatom), mivel kis, központosított csapatuk van, erőforráshiánnyal, és mást tartok magasabb prioritásúnak. Szóval azért nem vagyok git hívő, csak használom, és látom, hogy jó.
Arról meg szó sem volt, hogy húzza le magát valaki, mert SVN-t használ, eredeti felvetés az volt, hogy érdemes-e git-et tudni.
Én Gradle mellett nem érveltem, mert nem érzem szükségét, ős Mavenes vagyok amúgy. Még a hello worldöm is multimodule maven projekt. -
#8962
Lortech
addikt
Aethelstone
#8959
Lortech
addikt
válasz
Aethelstone
#8959
üzenetére
Azért nem kell szándékosan félreérteni. Nálam simán előfordul, hogy egy adott branchre csak commitolok és remote-ba sosem jut el ( csak a commitok, de azok már másik branchen, vagy a commitok sem).
Sőt egyébként olyan dolgokra is használom a git-et, amiknél nincs is remote, csak az a lényeg, hogy verziókat vissza tudjam követni. Pl. saját doksik, lokális fejlesztői környezetek bizonyos részei, toolok, konfigok verziózása. Bár ez is megoldható svn-nel, csak nem áll már kézre. -
Lortech
addikt
SVN-nel ugyanúgy lehet olyan munkád, aminek nincs nyoma a központi repóban (egyszerűen nem tolod fel, ha nem akarod), a GIT viszont segít abban, hogy ha ezt akarod, kényelmesen meg tudd oldani, akár központi repóhoz fordulás nélkül, de úgy, hogy commitok (vagy stashben a változások) meglegyenek.
Nálam van, hogy 5+ feature branch között váltogatok napon belül, ha segítek vagy reviewzok kollégáknak. Eközben a saját munkám 1-2..n branchen van, amiket vagy feltoltam a remote-ba vagy nem, nincs jelentőségük, lényeg, hogy az infó megvan, és könnyen tudok váltani köztük. Van egy csomó olyan köztes állapota az elvégzendő munkának, aminek vcs historyban nincs különösebb keresnivalója, mert a végeredmény szempontjából nem hordoz értéket, mégis a köztes állapotnak is meg kell lennie, hogy később vissza tudjak rá váltani, ha folytatom a munkát rajta. Ugyanakkor más számára nem mindig hordoz értéket és így teljesen felesleges a feltöltésével időt vesztenem. A kész feature / javítás / akármi pedig úgy fog visszakerülni a masterbe / egyéb protected branchbe, hogy az csak azokat a commitokat és olyan üzenetekkel tartalmazza, ami a módosítás egésze szempontjából lényeges, és a historyban megőrzendő információ.
Ez nem azt jelenti, hogy nálunk a kollégák 2 hétig a saját kis játszóterükben szórakozhatnak, és ha elüti őket az autó, akkor annyi a munkának. Már csak a CI miatt is sokkal rövidebb életciklusú (vagy folyamatos integráció) branchek szükségesek. Erről git-nél és SVN-nél is le lehet szoktatni őket, ebből a szempontból én nem látok nagy különbséget. Pl. ha látom, hogy kolléga egyik remote branchre sem commitolt egy hete (van róla stat), akkor azért megkérdem, hogy mi a hasfájása. -
Lortech
addikt
Gradle Android/studio-nál megkerülhetetlen.
Git akkor komplikáltabb, ha komplikáltabb dolgokra használod. Sokaknál azt veszem észre, hogy git előtt csak egyszerű dolgokra használta a vcs-t, git után ráérez és elkezdi jobban érdekelni a dolog.
Nagyon egyszerű felhúzni új repót, gyors, hatékony, jól skálázódik, jól testreszabható, tök jó támogató eszközök épültek köré, jól üzemeltethető.
Az SVN a jelenlegi workflowt, amit használunk, nehezen tudná jól támogatni, legalábbis az én munkámat dev leadként. Mondhatnám én is, hogy akinek gondot jelent pár nap alatt belerázódni a GIT-be, az válasszon más pályát. Sima alkalmazásfejlesztőknek kb. három mondatban le tudom írni adott projekten az össz teendőjét gittel. Kb. 6 éve az összes projektemen git mellett döntök, SVN-ről váltottam, azóta soha eszembe nem jutott SVN-t használni, ha nem adottság. Ha SVN-t, neadjisten CVS-t, vagy CC-t látok (ügyfélnél), hamar idegrángásom lesz tőle és általában felrakok fölé egy GIT-et.#8908 eredetire: igen, mind a 4-re szükséged van, de ha nem senior pozíció, akkor alap szinten ismerni elég ezeket. Komolyabban úgyis munka közben tudod megtanulni.
-
Lortech
addikt
válasz
szucstom
#8841
üzenetére
12 év és 8xxx hozzászólás után elhangozhatott-e a topikban már legalább hasonló kérdés?
Mit jelent a teljesen kezdő? Informatikai, matematikai, logikai, algoritmizálási, programozási alapjaid vannak és csak n+1. nyelvként akarod megtanulni, vagy semmi alapod nincs?
Ha előbbi, a Head First (Agyhullám) Java könyvet szokták javasolni, régi, de talán még manapság is jó alapnak.
Ha utóbbi, akkor nehezebb dolgod van, kezdő nyelvként nem a Javát szokták ajánlani, de igazából nem is a Java vagy nem Java lesz a legnagyobb problémád, hanem az, hogy azt a minimális alapot megszerezd, amire már érdemes építeni egy konkrét nyelvet. Ez kemény dió. Ha komolyan gondolod a dolgot, akkor talán valamelyik prog infó szak első évi kurzusainak jegyzeteivel kellene kezdeni. Csak baromi nehéz kiszűrni, hogy mi a tényleg releváns, hasznos rész. -
Lortech
addikt
A concurrent-xy már nem a datasource-hoz tartozik, hanem az EE alrendszer JSR 236-hoz kapcsolódó beállításai.
Amibe pedig belefuttottál az az, hogy Java EE 7-ben meg kell adni default datasource-ot (wildflynál ee alrendszer default-bindings-nál), aminek validnak kell lennie, ez wildflynál az alap disztibúcióban az ExampleDS, ami egy dummy h2 db, amit wildfy alapból tartalmaz.harylmu: még nem látok ki a fejemből rendesen, de nem az van, hogy resource filteringet eresztesz rá a libre, ami ha tényleg elvégzi a resource filteringet, akkor jól elrontja azt? Kivételt kéne felvenni a binárisokra, vagy a resourceokat két részre osztani (include/exclude halmaz).
-
Lortech
addikt
standalone_xy.xml-ben vagy domain.xml-ben (attól függ hogyan fut a wildflyod) nézd meg, hogy nincs-e ott feleslegesen hivatkozás egy nem létező datasource-ra.
A <subsystem xmlns="urn:jboss:domain:ee:4.0"> alrendszeren belül a <default-bindings \ datasource-t kell nézni, valamint
valamint a <subsystem xmlns="urn:jboss:domain:datasources:4.0"> alrendszeren belül a datasource definíciókat. -
Lortech
addikt
Nyilván minden függőséget oda kell tenni mellé, hogy forduljon. Kiexportálod a teljes jar forrását, behúzod IDE alá egy projekt forrásaként. Ekkor a jaron belüli függőségekkel megvagy, ha egyéb libtől is függ a lefordítandó osztály, akkor azt is build pathhoz adod. A cannot find symbol hibák hiányzó típusokat jelentenek, ha nem tudod, hol a hiányzó függőség, rá kell keresni az alkalmazás/konténer egyéb csomagjaiban (jar,war,ear), ha vannak.
-
Lortech
addikt
Persze, jadolod (pl. jd-gui), módosítod, és újrafordítod, a classt kicseréled a jar-ban.
(Feltéve, hogy a licence megengedi.
)
Közben figyelj, hogy a class verzió (major/minor) egyezzen, azaz lehetőleg ugyanazzal a jdk-val fordítsd, amivel eredetileg fordítva lett. Ebben a MANIFEST.MF segíthet, ha rendesen ki van töltve, de javap-vel érdemes leellenőrizni. -
Lortech
addikt
válasz
MrSealRD
#8355
üzenetére
Szerintem nem hogy ok az alsó, de számomra az a jobb. Nyilván nem azért, mert a kevesebb sor jobb. Számomra olvashatóbb, ez persze attól is függ, hogy az ember milyen kódhoz van szokva.
Szmeby javaslata is jobb, bár erre egy metódus hívás már határeset, és valóban kontextustól függ, de ha egy ismétlődő, üzletileg jelentéssel bíró logikai kifejezés vizsgálatáról van szó, akkor metódus is indokolt lehet.
Ez persze bizonyos mértékig szubjektív.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- AMD Ryzen 7 5700X processzor eladó /Garanciás/
- Xbox Series S + 2 kontroller
- Dell laptop eladó i5 11. gen, 8GB RAM, 512GB SSD, újszerű állapotban!
- Bomba ár! HP EliteBook Folio 1040 G1 - i5-G4 I 8GB I 256GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Bomba ár! HP Elitebook Folio 9470M - i5-3GEN I 8GB I 256GB SSD I 14" I DP I Cam I W10 I Garancia!
- DDR5 8/ 16/ 32GB 4800-5600MHz SODIMM laptop RAM, több db- számla, garancia
- AKCIÓ! Dell Latitude 5440 14 FHD üzleti notebook - i5 1335U 8GB RAM 256GB SSD Intel Iris Xe
- Bomba ár! Dell Latitude 5430 - i7-1255U I 16GB I 512SSD I HDMI I 14" FHD I Cam I W11 I NBD Garancia!
- 35" ASUS ROG Swift PG35VQ curved GAMER monitor
- iKing.Hu - Motorola Edge 50 Ultra - Nordic Wood - Használt, karcmentes
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest