Új hozzászólás Aktív témák

• floatr veterán

  #12164

  #12163 Aethelstone

  2024-11-16 23:24:45

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #12163 Aethelstone

  #12163 Aethelstone

  Persze, ez is egy vélemény, van is benne némi igazság, de most nem releváns a téma szempontjából Btw, jó Java fejlesztőt is alig találni a piacon, a Kotlin kompetencia méginkább szűkíti a kört.

  Csináltam egy kis "piackutatást" állásinterjúkon. Azért nem használnak kotlint, mert kevés a fejlesztő, azért kevés a fejlesztő, mert nem használnak kotlint

• floatr veterán

  #12162

  #12160 Aethelstone

  2024-11-16 13:17:46

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #12160 Aethelstone

  #12160 Aethelstone

  Igen, így teljesen pontos. Érdemes egyébként full 1.8-as JDK-t is felrakni, ha full 1.8-as kompatibilitás kell. Az a tuti.

  Kotlint kell használni, az még tutibb

• Ablakos addikt

  #12161

  #12160 Aethelstone

  2024-11-16 12:37:26

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Ablakos

  addikt

  #12160 Aethelstone

  #12160 Aethelstone

  Igen, így teljesen pontos. Érdemes egyébként full 1.8-as JDK-t is felrakni, ha full 1.8-as kompatibilitás kell. Az a tuti.

  Igen, erre jutottam végül. Ha 15 felett kikerült a javascript a jdk-ból, hiába kérek 1.8-as kódot a 23 -asban.

  Köszönöm mindenkinek.

• Lortech addikt

  #12159

  #12158 Aethelstone

  2024-11-16 11:54:27

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Lortech

  addikt

  #12158 Aethelstone

  #12158 Aethelstone

  Az 1.8-as kód azt jelenti, hogy 1.8-ig értelmezett nyelvi elemeket fogad csak el a compiler. Az nem ugyanaz, hogy 1.8-as JDK/JRE-n is pöccre futni fog. Szerintem.

  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.

• floatr veterán

  #11815

  #11805 Aethelstone

  2022-05-30 08:38:28

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #11805 Aethelstone

  #11805 Aethelstone

  Másrészt én speciel az intern használatáért kurva nagyot csapnék a fejlesztő kezére

  Nekem ez már a bitb.szás kategóriába tartozik. A legtöbben tervezni sem tudnak elégséges szinten, nem hogy még erre optimalizáljanak.

• sztanozs veterán

  #11812

  #11811 Aethelstone

  2022-05-29 16:42:24

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #11811 Aethelstone

  #11811 Aethelstone

  Lehet én vagyok oldschool, de lognak márpedig lennie kell

  attól függ, mit fejlesztesz... egy Match-3 játékhoz nem feltétlenül kell logot generálni

• sztanozs veterán

  #11810

  #11800 Aethelstone

  2022-05-29 12:01:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #11800 Aethelstone

  #11800 Aethelstone

  Uh. Ha cmd-ben indítod, akkor a konzolon megjelenik. Ha nem, akkor ha az exe kimenetét egy fájlba irányítod, mint > log.txt akkor ott. Viszont ez vérgagyi megoldás.

  mondjuk ha nem kell neki, akkor jólvanazúgy

• Drizzt nagyúr

  #11806

  #11805 Aethelstone

  2022-05-28 20:58:53

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Drizzt

  nagyúr

  #11805 Aethelstone

  #11805 Aethelstone

  Másrészt én speciel az intern használatáért kurva nagyot csapnék a fejlesztő kezére

  Mit javasolsz helyette? Nekem van saját preferenciám, de kíváncsi vagyok mit mondanál rá.

• Ablakos addikt

  #11802

  #11801 Aethelstone

  2022-05-28 11:40:12

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Ablakos

  addikt

  #11801 Aethelstone

  #11801 Aethelstone

  Engedjük el a string == -t :)

  Megjegyeztem.

  Persze jobb lenne, ha jeleznéd az OCP szerzői felé is, hogy kapják össze magukat. A prohardveren nem szeressük az ilyent.

• btraven őstag

  #11799

  #11798 Aethelstone

  2022-05-28 09:46:03

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  btraven

  őstag

  #11798 Aethelstone

  #11798 Aethelstone

  A mindenkori standard out-ra kerülnek a logok.

  Nem tudom hogy az hol van Windows 10-en. Én mondjuk nyomát se látom az én gépemen.

• Aethelstone addikt

  #11766

  #11765 Aethelstone

  2022-05-06 10:30:01

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #11765 Aethelstone

  #11765 Aethelstone

  Üdv!

  A probléma.
  Adott egy Linux alatt fordított so, amit Java-ba JNA-val húzunk be. Vamn egy kvázi kliens és egy kvázi szerver oldal, ami ugyanazt az so-t használja, két interfészt csináltunk rá. Az so mögötti C kódban van egy csomó static hivatkozás, ami azt eredményezi, hogy az so működése rendkívül hektikus, nem is mennék bele a részletekbe. Az van, hogy ha az alkalmazást két VM-ben indítjuk, kiválóan működik, de egy VM-ben meg gatya. Ezt a részét értem, hogy miért, a kérdés az lenne, hogy van-e lehetőség szerintetek JNA-ban arra, hogy az so-t izoláltan töltsük be, custom classloader vagy bármi? Mert by design a JNA singletonként húzza be az so-kat.

  AE

  Forget it! Solved

• floatr veterán

  #11581

  #11580 Aethelstone

  2021-06-14 14:07:11

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #11580 Aethelstone

  #11580 Aethelstone

  Valami logja csak van

  Van persze, de még lusta voltam utána menni. Egyszer rászántam kb 10 percet, hogy egy hobbiprojektet megreszeljek, de nem ment egyből, aztán azóta úgy maradt. Csak amiatt mondom, hogy hajlamos ilyen problémákba belefutni.

• floatr veterán

  #11579

  #11578 Aethelstone

  2021-06-14 10:38:55

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #11578 Aethelstone

  #11578 Aethelstone

  Hogy babrálta el?

  Nem ismeri fel java projektként. Pontosabban a java kiegészítő elhasal, amikor beolvassa a projektet, és nem működnek a java IDE funkciók.

• floatr veterán

  #11577

  #11576 Aethelstone

  2021-06-14 09:13:21

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #11576 Aethelstone

  #11576 Aethelstone

  Btw, szoktam kisérletezni a vscode-dal, meglepően jó cucc java fejlesztéshez, csak még szokni kell, de kb minden működik, ami a nehézsúlyú ide-kben :)

  Nálam a vscode most valamiért elbabrálta a régebben létrehozott projekteket, mert gradle verziót frissítettem. Egyelőre még nem sakkoztam ki, hogy mi a baja

• btraven őstag

  #11572

  #11571 Aethelstone

  2021-06-13 15:05:39

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  btraven

  őstag

  #11571 Aethelstone

  #11571 Aethelstone

  Nem. Az van, hogy általában Java alkalmazást Enterprise környezetbe telepítünk, ahol is leírjuk, hogy milyen környezetre van szükség, hogy fusson a cucc, amit a devopsok majd jól előállítanak

  Őrület határán voltam. Ez a jpackage nem akart működni sehogy se a Hello world alkalmazással.
  De aztán a gradle-s projectemben meg ment.
  Eclipse-ből lehet futtatni gradle task-ot?
  Nekem csak Command prompt-ból sikerült "gradlew.bat tasknév' módon.

• floatr veterán

  #11441

  #11440 Aethelstone

  2021-03-02 11:42:41

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #11440 Aethelstone

  #11440 Aethelstone

  De. Régen attól féltem, hogy olyan leszek, mint apám. Aztán rájöttem, hogy én vagyok az apám

  Nézd, kezdetektől fogva javazom, és család mellett sem okozott problémát a gradle, bár az ant-et szerettem a legjobban. Nyilván mindenkinek más az "egyszerű", de az XML tömöttsége eleve kevésbé áttekinthető, mint egy DSL, bármilyen jó code highlightot használsz. Karbantarthatóság szempontjából is nyilván jobb
  Ami a design-t illeti, a legtöbb esetben nincsen papírforma, mindig van valami olyan körülmény, amihez alkalmazkodni kell. Amellett egy mostani CI migráció miatt jött elő, hogy a gradle build előnyben van a mavenessel szemben a deployment miatt, mivel több olyan dolgot implementáltunk benne, ami mindenhol tud futni, de a mavenes projekt ezt a CI-ra bízta.

• mobal nagyúr

  #11439

  #11438 Aethelstone

  2021-03-02 11:02:22

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #11438 Aethelstone

  #11438 Aethelstone

  Ez emberi tulajdonság, ha odajutsz, Te is ilyen leszel

  Remélem nem, most full komolyan.

• mobal nagyúr

  #11437

  #11436 Aethelstone

  2021-03-02 10:54:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #11436 Aethelstone

  #11436 Aethelstone

  Ez is egy elég sarkos megfogalmazás és Te is tudod, hogy nem így van. A maven nem egy rusztikus, már senki által nem használt technológia, aminél leragadtak a vének. Innentől fogva tényleg csak egyéni/projekt preferencia, hogy mit használunk.

  Én általánosságban értettem, de bizonyos kor felett egytől egyig akivel dolgoztam nem akart változtatni a szokásain. De ez más téma.

• mobal nagyúr

  #11435

  #11434 Aethelstone

  2021-03-02 10:44:12

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #11434 Aethelstone

  #11434 Aethelstone

  Ez egyáltalán nem igaz. Inkább azt mondanám, hogy a tapasztaltabbak kétszer is meggondolják, hogy érdemes-e beleölni egy csomó effortot, minimális előnyökért....amik talán nem is léteznek.

  Persze. Erre rengeteg példát láttam az élet folyamán. Maradjunk a régi dolgoknál mert akkor nem kell nekem változtatni és ez a lényeg. Te is tudod jól, hogy töbségében ez van...

• mobal nagyúr

  #11433

  #11432 Aethelstone

  2021-03-02 10:01:48

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #11432 Aethelstone

  #11432 Aethelstone

  De pont ezt mondom én is Én egyébként cirka 2010 óta mavenezek, 3-4 éve meg van gradle projektünk is. Mindkettőt elismerem, de azt tényleg ne mondja senki (itt le lett írva), hogy a maven a vén szaroknak való és kuka és mindenre a megoldás a Groovy. Faszt, már bocsánat. Mindkettőnek kurvára megvan a helye

  Senki nem vén szarozik, de a nagyobb problémát egy másik build toolra való átállás nekik jelenti.

• Drizzt nagyúr

  #11431

  #11429 Aethelstone

  2021-03-02 09:53:12

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Drizzt

  nagyúr

  #11429 Aethelstone

  #11429 Aethelstone

  Ok, de a kotlin, mint jelenség még mindig kisebb százalékát érinti a projekteknek. Egyrészt. Másrészt meg szerintem ha nem szokványos taszkok vannak, azok legtöbb esetben design problémák. De tényleg ugorjunk

  Mostmar ha elorangattad, ne hatralj ki.
  Erre en csak annyit akartam irni, hogy eddig olyan 5 eves maven hasznalatom alatt egyszer sem jott szembe olyan dolog, amire nem lett volna letezo plugin, ami megoldotta a problemat. Oke, vannak azert olyanok, amitol jobbat is el tudnek kepzelni, de egyutt lehet vele elni. Van amugy joval hosszabb programozoi tapasztalatom(ossz. ~15 ev), de OOP/Java az legyen inkabb 5 ev. Ezert 5 ev a maven is.
  Illetve ami pl.: Gradle-re atteressel problema lenne, hogy van egy jo szazas nagysagrendu microservice, ami azert jelenleg elegge hasonlit build projektileg. De ettol fuggetlenul mindegyikben johet fejlesztesi igeny. Ha meg hirtelen a projektek egyik fele maven, a masik fele meg gradle lenne, bevinne egy szep kis extra komplexitast.

• floatr veterán

  #11428

  #11426 Aethelstone

  2021-03-02 09:31:00

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #11426 Aethelstone

  #11426 Aethelstone

  Ha "Groovy / Kotlin dsl gradle file" ilyen van a listában, akkor ide tényleg nem jó a maven
  A Spring Boot alkalmazásokra, yaml fájlokra, java konfigokra teljesen jó

  De tényleg zárható, pro és kontra el lehet sokmindent mondani, egyéni preferencia kérdése. Azzal viszont tökre nem értek egyet, hogy a maven őskövület lenne....

  Teljesítményben jobb, de clean coding miatt is preferálják. A mavenben nem szokványos taszkokat, ami filekelezés/deployment témában befigyelhet, csak custom osztályokkal oldhatsz meg, ami rendkívül jó kódrejtésben
  A groovy mondjuk nem a kedvencem, de ha kotlinos a projekt, akkor eleve adja magát.

• mobal nagyúr

  #11427

  #11426 Aethelstone

  2021-03-02 09:23:02

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #11426 Aethelstone

  #11426 Aethelstone

  Ha "Groovy / Kotlin dsl gradle file" ilyen van a listában, akkor ide tényleg nem jó a maven
  A Spring Boot alkalmazásokra, yaml fájlokra, java konfigokra teljesen jó

  De tényleg zárható, pro és kontra el lehet sokmindent mondani, egyéni preferencia kérdése. Azzal viszont tökre nem értek egyet, hogy a maven őskövület lenne....

  Jó, nyilván szarul fogalmaztam de remélem átment amit akartam, hogy az xml ebben az esetben szarul nézne ki Groovy / Kotlin dsl helyett!

• mobal nagyúr

  #11425

  #11424 Aethelstone

  2021-03-02 09:08:11

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #11424 Aethelstone

  #11424 Aethelstone

  No offense, de mondjatok már egy olyan use-caset, amit csak gradle segítségével lehet megoldani....hogy kicsi visszamenjek...

  Fordítsuk meg. Olyan use case van amit csak mavennal lehet xml nélkül?

  Egy use case ahol ugyan jó a maven, de:

  - Spring Boot alkalmazás
  - Groovy / Kotlin dsl gradle file
  - Yaml konfigurációs fileok
  - Java konfigok

  Nekem ebben a körneyezetben egy XML nagyon elütne / nem illene bele. De mint fentebb is beszéltük egyéni preferencia kérdése és semmi több.

• mobal nagyúr

  #10967

  #10966 Aethelstone

  2020-03-01 18:53:15

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #10966 Aethelstone

  #10966 Aethelstone

  Nyilván. Ezért nem lehet kijelenteni, hogy az egyik jobb, mint a másik. Viszont pont emiatt kiváló flamewar alapanyag

  Stíluson és Java IDE-n nem vitatkozunk!

• mobal nagyúr

  #10962

  #10959 Aethelstone

  2020-03-01 10:01:40

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #10959 Aethelstone

  #10959 Aethelstone

  Azért a vi és az Eclipse összehasonlítása erős túlzás ugyancsak Pont ugyanolyan hatékonysággal lehet Eclipse-ban dolgozni, mint Idea-ban.

  Te lehet, én nem lennék rá képtelen. Ízlések és pofonok - nekem az Eclipse-szel való munka olyan lenne mintha a fogamat húznák.

• mobal nagyúr

  #10957

  #10956 Aethelstone

  2020-02-28 18:05:59

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #10956 Aethelstone

  #10956 Aethelstone

  Azért ez a de facto erős túlzás

  Nyilván vi-ban is meg tudod csinálni ugyanazt, de minek szivasd magad?

  Szerk.: hozzáteszem az idea ce egy zseniális húzás.

• E.Kaufmann veterán

  #10628

  #10627 Aethelstone

  2019-08-29 11:21:54

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  E.Kaufmann

  veterán

  #10627 Aethelstone

  #10627 Aethelstone

  Ez egész jó.

  https://deeplearning4j.org/

  Ahogy nézem, a Maven-es feltételnek pont nem felel meg, de úgy is ismerkednem kellene vele és az új NetBeans is a Maven projekteket tette alapértelmezetté. Köszönöm.

• #68216320 törölt tag

  #10621

  #10620 Aethelstone

  2019-08-28 17:15:51

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  #68216320

  törölt tag

  #10620 Aethelstone

  #10620 Aethelstone

  Jó. Nyilvánosan megkövetem a kartársat, amiért ilyen hangnemben írtam neki. Nem fog előfordulni többet.

  Ettől függetlenül ha már kér valamit valaki, amit egyébként 5 perc guglizással ki lehet túrni, ráadásul az optikája olyan volt, hogy sürgős lenne, akkor egy köszi jól esett volna. Nem kötelező, de jól esett volna. Mivel sürgősnek tűnt, ezért vélelmeztem, hogy nem kíván reagálni semmit.

  Elnézést, hogy ennyire felhúztam magam a dolgon. Valóban sürgős lett volna vagy legalábbis mihamarabb szerettem volna a témával foglalkozni, de másképp alakult és ezért csak ma néztem rá. Tehát jól érzékelted. A guglizással igazad van, de a címszavak nem ugrottak be ezért nem vezettek akkor eredményre a találatok.
  A segítséget köszönöm, megnéztem a linket is és kerestem a címszavakra is. Pontosan ilyesmire lenne szükségem. Át is nézem mihamarabb a talált oldalakat.

  mobal: Tőled is elnézést szeretnék kérni, a sértettség és a tanácstalanság beszélt belőlem. Máskor próbálok mérsékeltebb lenni.

  Ha van erre lehetőség és nektek is megfelel javasolnám a problémás hozzászólások törlését, mivel egyáltalán nem vág a témába és 10 év múlva nem akarom újraolvasni.

• walgud6 tag

  #10609

  #10608 Aethelstone

  2019-08-24 19:57:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  walgud6

  tag

  #10608 Aethelstone

  #10608 Aethelstone

  Napi több hívást említ, alkalmanként 20k+. Igen, ez sem mindegy, de az adatok mérete sem, ahogy írtam. Szóval, infó ismét nulla Csak kérdés

  Az a 20k+ adat szinte fix ugyanaz (maximum 1-2 új várható naponta). A feladat az, hogy az egyes adatok (nevezzük terméknek) egyik tulajdonsága változhat. Ezt a változást kell mindig ellenőrizni az API hívásnál, majd eltárolni. Az adatbázisbam van egy tábla a terméknek egy pedig, ahol tárolva vannak a tulajdonságok dátummal ( statisztika miatt). Szóval minden hívásnál össze kell hasonlítani az adatbázisban lévő termékeket az API-tól érkezőkkel. Az újakat eltárolni, a meglevőknek pedig a tulajdonságát összehasonlítani, ha van változás azt tárolni.

• sztanozs veterán

  #10607

  #10606 Aethelstone

  2019-08-23 14:21:33

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #10606 Aethelstone

  #10606 Aethelstone

  Relációs is lehet optimalizálva beszúrásra. Sőt, optimalizálás nélkül is.20k adatnál asszem tökmindegy.

  Mondjuk nem mindegy, hogy a 20000+ az összesen 20k+, vagy pl óránként/naponta 20k+... és ebből mennyit meddig kell megtartani. Persze ha összesen ennyi, akkor mindegy. Ennyit file alapon vagy memcache-elve is el lehet kezelni. Viszont ha tényleg ennyi, egy sql adatbázis erre azért nem kicsit overkill...

• Aethelstone addikt

  #10604

  #10603 Aethelstone

  2019-08-23 08:29:57

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #10603 Aethelstone

  #10603 Aethelstone

  A 20000+ nem sok. Persze kérdés, hogy pár skalár vagy több kilóbájtos json-ok. Első körben funkcionálisan írd meg és teljesítmény teszteld. Ha jó, akkor jó. Ha nem, akkor lehet tuningolni. Első körben legyen állapotmentes az api és ha gyenge, fusson 2-3 lábon, előtte load balancer.

  Persze, van egy rakat más tuning lehetőség is ofkóz CQRS design pattern, cache technikák, asszinkron feldolgozás, stb.

• E.Kaufmann veterán

  #10595

  #10594 Aethelstone

  2019-08-14 08:18:37

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  E.Kaufmann

  veterán

  #10594 Aethelstone

  #10594 Aethelstone

  Láttál már jó ERP-t? Nem véletlenül találták ki egyébként a microservice architektúrát. Ami nyilván nem teljeskörű megoldás, vannak kurva nagy gyengeségei, de alapvetően tiszta DB helyzetet teremt.

  Jájjjj, még egy technobullshit. Mint annó a web 2.0.
  Az ábrákat elnézve nem egy nagy közös adatbázis van, hanem több kicsi , adott részterületenként egy, de ugyanúgy egy részterületet egyszerre többen is elérhetnek és el is kell érniük, szóval a lényeg ugyanaz szvsz, pláne az eredeti kérdés szempontjából.
  Ez max az ERP rugalmasságát biztosítja.

• bambano titán

  #10590

  #10587 Aethelstone

  2019-08-13 20:30:37

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  bambano

  titán

  #10587 Aethelstone

  #10587 Aethelstone

  Szerintem ez itt még kicsit korai. A közös adatbázis meg szerintem erős antipattern a legtöbb esetben

  van adatbázisos megoldásod két program kommunikációjára úgy, hogy az adatbázis nem közös?

• E.Kaufmann veterán

  #10588

  #10587 Aethelstone

  2019-08-13 16:05:47

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  E.Kaufmann

  veterán

  #10587 Aethelstone

  #10587 Aethelstone

  Szerintem ez itt még kicsit korai. A közös adatbázis meg szerintem erős antipattern a legtöbb esetben

  Viszont működik és naplózhatóvá válhatnak a kommunikációk, amivel pl könnyebben visszaállítható egy előző állapot, valamint ha kettőnél több fél vesz részt a kommunikációban, akkor a konkurencia kezelés is könnyebb adatbázissal. Persze lehet, hogy adott feladathoz ágyúval verébre.

• MrSealRD veterán

  #10565

  #10564 Aethelstone

  2019-07-31 20:09:00

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  MrSealRD

  veterán

  #10564 Aethelstone

  #10564 Aethelstone

  Gondolom, hogy voltak korábban a ctornak paraméterei. Ha privát lett, kéne, hogy legyenek publikus setterek a korábban ctorban inicializált adattagoknak...egyáltalán mit csinált a ctor? És statikus metódusok esetén miért kell publikus ctor? Sok itt a kérdés

  Konkretizálom a dolgot.
  Ez itt az új verzió aminek már private ctor van. A 6.2-es verzióban még nem volt private. Van egy saját ComponentUtils osztályunk amit vagy 5 éve írtak és ebből a fent linkelt osztályból került származtatásra. Mivel akkori verzióban még nem volt private a ctor így ebből nem volt gond... Most, hogy új verziót húztam be...szembesültem a változással... Tehát valamikor régen kiterjesztésre került ennek az osztálynak a funkcionalitása és azért kapott azonos nevet, hogy ez legyen használva mindenhol. Ugyanúgy static metódusok vannak benne... Viszont a fenti változás miatt ez a helyzet már nem tartható, de a korábbi funkcionalitásra is szükség lenne, meg a mostanira is. De ezt öröklődéssel már nem lehet biztosítani...

• floatr veterán

  #10556

  #10553 Aethelstone

  2019-07-29 10:34:02

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #10553 Aethelstone

  #10553 Aethelstone

  Udemy? Volt egy kollégám, fizikus végzettséggel. Fél év után feladta, hogy a programozás nem megy neki. Azóta Udemy-n oktat......programozást.

  Attól még taníthatja...
  Nekem is volt egy kollégám, aki inkább oktatni ment végül. Nem gondolnám h nem jól csinálja, bár nem tudom lecsekkolni

• E.Kaufmann veterán

  #10554

  #10553 Aethelstone

  2019-07-28 06:13:45

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  E.Kaufmann

  veterán

  #10553 Aethelstone

  #10553 Aethelstone

  Udemy? Volt egy kollégám, fizikus végzettséggel. Fél év után feladta, hogy a programozás nem megy neki. Azóta Udemy-n oktat......programozást.

  Itt a fórumon eddig öten is ajánlották a Udemy-t, nekik is szólj már légyszi, köszönöm.

• mobal nagyúr

  #10541

  #10539 Aethelstone

  2019-07-17 07:37:14

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #10539 Aethelstone

  #10539 Aethelstone

  A raw típus manapság csak a probléma kikerülése. Nyilván a full típusosság több tervezést igényel, de meg szokta érni.

  Lustaság*

• axioma veterán

  #10540

  #10539 Aethelstone

  2019-07-16 23:17:58

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  axioma

  veterán

  #10539 Aethelstone

  #10539 Aethelstone

  A raw típus manapság csak a probléma kikerülése. Nyilván a full típusosság több tervezést igényel, de meg szokta érni.

  Az a baj h legyinthetnek de az mar kiveri a biztositekot hogy irracionalis megoldast csinalnak. Atterveztek, full tipusos [eddig jo], de ehhez 'en' a szamolo rutin mondjam meg melyikkel akarom hasznalni [implnev.class]. Mert hogy csak igy lehet. Magyarul, atnezve az atalakitast, csak nem akarjak h naluk legyen default. Ez mar reg nem a tipusossagrol szol... Megmodositottam offline ugy [azaz lehetseges, szoval vegulis +1 nap alatt kiderult a valasz, h o"k erveltek rosszul -- bar tovabbra is randa, rosszabb mint volt, karbantarthatalanabb], hogy jojjon 'toluk' default, mi a velemenyuk - a vicc hogy azt meg egy darab if miatt [hogy jofej legyek es ne null-t adjak at ha a default-ot kerem] le-felesleges-bonyolitasozta. Ja ok Londonban ulnek csak en Mo-on...
  Mind1, egyelore dokumentalom az egyet nem ertesemet, mar ha benne marad nalam az implementacio megadasa a calc-os osztalyban, aztan ha telik a pohar [mert kozben a manager fonoknek meg en vagyok lasu mig ok ezen ulnek] akkor aktivalom a linkedin-emet...
  Viszont sokat javult a generic-ekrol a tudasom, eddig ahhoz hasonlitanam mint nyelvtudasnal a passziv szokincset, hat most beaktivaltak ;-)

• E.Kaufmann veterán

  #10526

  #10524 Aethelstone

  2019-07-10 10:40:35

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  E.Kaufmann

  veterán

  #10524 Aethelstone

  #10524 Aethelstone

  Hétfőn tudok majd

  
  Na mindegy, eddig müxeni látszik a B megoldás, csak próbáltam a 8.0-ásról 8.1.1-re frissíteni a docx4j-t, de elrontja a docx-et, szóközöket von egybe. Úgyhogy visszaálltam 8-ra.

• E.Kaufmann veterán

  #10525

  #10524 Aethelstone

  2019-07-06 08:45:46

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  E.Kaufmann

  veterán

  #10524 Aethelstone

  #10524 Aethelstone

  Hétfőn tudok majd

  
  Csak jobb lenne patkolás nélkül. Várom.

• E.Kaufmann veterán

  #10522

  #10520 Aethelstone

  2019-07-05 07:45:57

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  E.Kaufmann

  veterán

  #10520 Aethelstone

  #10520 Aethelstone

  Csinálj előbb egy template docx-et. Úgy szerintem gyorsabb lesz. Nyisd meg és abba írkálj. Vagy próbáld meg az apache poi-t, ha a stack-be belefér.

  Szia! Köszönöm a választ, POI-t használom az XLSX-ekhez, de nem találtam működő példát docx-hez. Nem tudnál egy linket dobni egy egyszerűbb docx kitöltésről POI-val?

• mobal nagyúr

  #10457

  #10456 Aethelstone

  2019-06-17 09:45:56

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #10456 Aethelstone

  #10456 Aethelstone

  Jesszusom. Itt a világ vége, ha Visual Studióval fogunk Java kódot csinálni

  Szerintem marha jó kis ide. Ha nincs szükséged egy IDEA-ra pl. tökéletes.

• Drizzt nagyúr

  #10326

  #10325 Aethelstone

  2019-04-06 15:17:33

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Drizzt

  nagyúr

  #10325 Aethelstone

  #10325 Aethelstone

  A Request teljes egésze kellene. Ami még működik.

  En azt igy szoktam: [link]

• Drizzt nagyúr

  #10309

  #10308 Aethelstone

  2019-03-02 18:33:59

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Drizzt

  nagyúr

  #10308 Aethelstone

  #10308 Aethelstone

  A Reflection elsőre nagy mágia, de aztán az ember elkezdi mindenre (is) használni

  Runtime reflectionnel a feldolgozasa, meg Beandescriptor/Introspectorral az mar nagyuzemben megy, de a compile time osztaly generalas AbstactProcessor extendalassal az meg ujdonsag nekem. De hat nagyon elirigyeltem a Jaxb-tol meg a JPA-tol a metadata definialast annotaciokkal. Most kb. ahhoz hasonlot csinalok, mint amit a JPA modelgen csinal az Entity metamodel generalasakor. A zavart pont az okozza, hogy compile time a reflectionnel nem lehet kb. semmit cainalni, hanem AnnotatedConstruct, Element, meg Type, TypeMirror es tarsaik allnak rendelkezesre.

• XP NINJA őstag

  #10285

  #10284 Aethelstone

  2019-01-29 17:08:37

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  XP NINJA

  őstag

  #10284 Aethelstone

  #10284 Aethelstone

  Relációs? Vannak relációk vagy csak egy "tábla"?

  Több txt-ből lenne több tábla, és lennének relációk

• M_AND_Ms veterán

  #10267

  #10266 Aethelstone

  2019-01-23 15:05:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  M_AND_Ms

  veterán

  #10266 Aethelstone

  #10266 Aethelstone

  Az a stacktrace-ből látszik, hogy a Vector firstElement() metódusa hányja el magát. Ami ugye a 0-ás indexű elemet venné ki. Ez nekem azt jelenti, hogy a Vector üres. Olyan szerintem nincs, hogy a GC kiürít egy Vector-t. Viszont a másik gondolatod sanszosabb. Lehet, hogy valaminek be kellene töltődnie, ami nem történik meg és ettől üres. Jó lenne látni a full stacket.

  Olyasmi lehet, hogy működik, használják, miközben a kód kiüríti a Vector-t, ami utána a kód másik része olvasna belőle és hibát dob - tehát, én azt mondom, ez programozói hiba: vagy nem kéne üríteni a Vectort, vagy az olvasáskor kéne figyelni, mert lehet jogosan üres, csak éppen kezelni kéne azt.

• sztanozs veterán

  #10265

  #10264 Aethelstone

  2019-01-23 14:17:12

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  sztanozs

  veterán

  #10264 Aethelstone

  #10264 Aethelstone

  A NoSuchElement exception nem éppen memory leak. Legalábbis én olyat nem láttam, hogy memory leak ilyen problémához vezet.

  Valóban - viszont ha hosszabb idő után jön elő, akkor valamelyik függvényben van valahol egy rész, ami eldob valami erőforrást (vagy valamiért a kukába kerül és előbb-utóbb a GC kiüríti). Illetve az is lehet, hogy valami rosszul mentett/betöltött vagy inkompatibilis resource fájl a gond (bár az alapján amit a kolléga leírt, nem tűnik konzekvensen reprodukálhatónak a probléma).

• orc88 őstag

  #10254

  #10251 Aethelstone

  2019-01-22 13:37:33

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  orc88

  őstag

  #10251 Aethelstone

  #10251 Aethelstone

  Elvileg amikor beolvasol egy vonalkódot, akkor a vonalkódhoz tartozó számsort kapod. Ez valami input mezőben megjelenik. Eddig stimt? Utána ezzel a számsorral azt csinálsz, amit akarsz.

  És tényleg működik nélküle is Hétvégén foglalkoztam vele, csak mivel napi használatban van az olvasó így nem tudták ideadni, de most kipróbáltam és príma. Köszi!

  RexpecT: Igen ezeket megtaláltam, szívtam is vele pár órát mert már gyakorlatilag a linkek fele nem élt, de így igazából már nem is nagyon van rá szükségem, mindenesetre köszönöm!

• Aethelstone addikt

  #10252

  #10251 Aethelstone

  2019-01-22 12:34:03

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Aethelstone

  addikt

  #10251 Aethelstone

  #10251 Aethelstone

  Elvileg amikor beolvasol egy vonalkódot, akkor a vonalkódhoz tartozó számsort kapod. Ez valami input mezőben megjelenik. Eddig stimt? Utána ezzel a számsorral azt csinálsz, amit akarsz.

  Ha meg input mező nincs, akkor az alkalmazásod úgy veszi, mintha sorban megnyomtad volna azt a tizenakárhány számot, tehát valami keypress/down listenerrel kell feldolgoznod. Ezek mindenféle api nélküli működések. Aztán ha találsz valamit, akkor abban minden lehet, callbacktól elkezdve...

• axioma veterán

  #10243

  #10242 Aethelstone

  2019-01-18 22:50:08

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  axioma

  veterán

  #10242 Aethelstone

  #10242 Aethelstone

  Konkrét kód nem ártana, de egyébként elsőre nem antipattern.

  Kosz. Kodot max. geprol morickazok, ceges kod sehogy nem hozhato ki, barmilyen artatlan... [volt h munkatars a ceg altal fizetett kezdo, szamara uj prog.nyelv kulsos kurzusara nem tudta a 'vizsgakodot' elkuldeni...]

• orc88 őstag

  #10227

  #10226 Aethelstone

  2019-01-12 16:36:00

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  orc88

  őstag

  #10226 Aethelstone

  #10226 Aethelstone

  Huh, ez a kód több sebből is vérzik. Érdekel?

  Természetesen
  (ezért is akartam először privátban segítséget kérni valakitől, sejtettem, hogy nem lesz egyszerű menet)

• axioma veterán

  #10209

  #10208 Aethelstone

  2019-01-11 11:35:29

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  axioma

  veterán

  #10208 Aethelstone

  #10208 Aethelstone

  Én nem érzem, hogy sokat dobna rajta, de nyilván ha kétségeid vannak, akkor mérni kell.

  Meglatjuk. Koszi az infokat!

• axioma veterán

  #10207

  #10206 Aethelstone

  2019-01-11 10:51:46

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  axioma

  veterán

  #10206 Aethelstone

  #10206 Aethelstone

  Szerintem jni felesleges. A Java is gyors, a szűk keresztmetszet nyilván a választott algoritmus lehet. Bár egy elimináció 70x70 esetén lassú lesz, akármiben, akárhogy írod Az apache egyébként korrekt, én is azt választanám.

  Hat, me'g ha flat-kent is kezelem es final, azert egy indexeles me'g akkor is van per elem, ha siman vegigfutok az osszesen. C-ben meg mehetne pointer aritmetikaval. Mivel ez suru muvelet, sok matrixon, lehet rajta kulonbseg, erre gondoltam.
  Pont eliminalas nem kell, nem linearis egyenletrendszerrol van szo, hanem mindenfele matrixszorzasok, osszegzesek sorra/oszlopra, siman vagy negyzetesen, meg ilyesmik... csak sok.

• axioma veterán

  #10205

  #10204 Aethelstone

  2019-01-11 08:04:59

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  axioma

  veterán

  #10204 Aethelstone

  #10204 Aethelstone

  Annyira specifikus nem nagyon lesz. A Java általános célú nyelv, nem speciálisan matematika problémák megoldására találták ki. Ha nagyon speckó valami kell, meg köll írni, nincs mese.

  OK, koszi. En orulok ha nincs es megirhatom Csak azert probaltam guglizni meg kerdezni, hatha van valami, mert ki tudja. Es hat ugye a cegnek se mindegy, hogy dolgozom rajta vagy csak hasznaljuk. (Bar amennyit az nd4j-nek a sikertelen approve-jaba belefektettek, mar reg keszen lehetnek...)
  Az egyetlen kerdes, hogy probaljam meg java-ban, vagy egybol C es JNI. A cucc csak nalunk fog futni (inputot general a userek altal hasznalt programhoz), nem baj ha platformhoz kotjuk. Na majd meglatjuk, nem csak rajtam mulik, koltoi kerdes volt. Sot me'g az is lehet hogy meregetjuk, hogy a mi specko felhasznalasunknal (tipikus matrixmeret 70x70 es 70x250, nem oriasi, csak a muveletek vannak sokan) mennyit hozna a C, ha adnak arra is idot.
  (A fonok elsosorban egy nagyon basic matrix-muveletes interface-t akar es alarakni most az apache-ost, hatha kesobb lesz olyan nd4j verzio ami atmegy es/vagy elokerul valami jobb. Csak hat az jelenleg minden lesz csak nem gyorsabb, sot, attol hogy a lepeseket elemibbre bontja, szebb a kod de lassabb lesz, van ami 2-3x menne igy vegig az elemeken, mig a jelenlegi nativan, for ciklusokkal megirtban egyben benne lehet egy osszetettebb muveletsor. De szerencsere egyelore ugy latszik, hogy nyitott az egyeb megoldasokra.)

• smallmer őstag

  #10165

  #10164 Aethelstone

  2018-12-11 01:00:25

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  smallmer

  őstag

  #10164 Aethelstone

  #10164 Aethelstone

  Ha látnánk a lejatszas metódust is....

  public void lejatszas(String message) {
try {
String selected = showMusicNames.getSelectedValue().toString();
System.out.println(selected);
FileInputStream fileInputStream = new FileInputStream(location + selected);
Player player = new Player(fileInputStream);
if (message.equals("start")) {
player.play();
}else if(message.equals("stop")){
player.close();
}
} catch (FileNotFoundException e) {
System.out.println("fail");
} catch (JavaLayerException e) {
System.out.println("fail2");
}
}

• Miertvansote tag

  #10127

  #10126 Aethelstone

  2018-11-26 13:27:45

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Miertvansote

  tag

  #10126 Aethelstone

  #10126 Aethelstone

  Rakd össze a kezed vidéken, 1 év gyakorlattal a 600 br. miatt. Nem fogsz komplett projektet kapni, azt jellemzően még seniorok is csapatban csinálják. Max. szabadúszóként tudsz ilyet elhozni, ha behazudod a több éves gyakorlatot

  Rendben, köszönöm az információkat.

• Miertvansote tag

  #10119

  #10118 Aethelstone

  2018-11-25 22:31:18

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Miertvansote

  tag

  #10118 Aethelstone

  #10118 Aethelstone

  Nos, kb. a szarlapátolást, amit a magukat seniornak gondolók rangon alulinak tartanak megcsinálni

  Mennyit lehet elkérni ezért a szarlapátolásért ? 650 bruttó ?

  Egy másik kérdés, gondolkodom, most hogy nekiállok a németnek. Van bármi haszna az IT szektorban ? Villamosmérnökként, talán multiknál lehet haszna egyébként nem gondolnám, nálatok mi a helyzet ?

• Zsoxx őstag

  #10117

  #10116 Aethelstone

  2018-11-25 22:00:33

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Zsoxx

  őstag

  #10116 Aethelstone

  #10116 Aethelstone

  Aktuális elvárás..ilyen nincs. Egyébként Java/Kotlin/c# kombóval nem nagyon tudsz mellélőni.

  JAVA junior pozícióban kb. melyek a követelmények? Milyen jellegű (rész)projekteket bíznak junior programozókra?

• floatr veterán

  #10089

  #10088 Aethelstone

  2018-11-15 09:27:21

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #10088 Aethelstone

  #10088 Aethelstone

  Nem. A jól bevált, de egyáltalán nem elavult technológiák használatában nincs igazából akkora kockázat, mint egy tök újban. K+F. Igen. Nem éles projektben kell K+F-elni. Az önálló történet szerintem. Mindig csak keveset változtass, ez az én egyik alapelvem.

  A kotlin igazából pont erre jó. Vegyesen is lehet használni, java fejlesztőket könnyű ráállítani, ha valami nem stimmel, viszonylag elég könnyű visszalépni. Nem is értem az ellenérveket. A legtöbb java projektet rá lehet állítani, hogy kotlint is használjon.

  Amúgy meg annyira tök új, hogy 8 éves sztori már, és alaposan felhasználják a korábbi tapasztalatokat (java, c#, scala). Nem akarok kampányolni, csak kicsit értetlenül állok a jelenség előtt. Jó persze a megszokott, ha elég, de a technológia ebben az irányban menetel tovább.

• floatr veterán

  #10087

  #10081 Aethelstone

  2018-11-14 16:05:05

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #10081 Aethelstone

  #10081 Aethelstone

  Értem én és tök igazad lenne, ha csak hobbiprojektekből állna a világ. Viszont a világ nem csak hobbiprojektekből áll. Egy cég, ahol dolgozik tizen, huszon, mittomény mennyi fejlesztő, 10szer is meggondolja, hogy mondjuk holnaptól Java helyett Kotlinban áll neki egy zöldmezősnek. Határidők, stb.

  És ez független attól, hogy a Kotlin mennyivel jobb, mint a Java. (vagy nem)

  Az a gond legtöbbször, hogy a költségvetésbe nem kalkulálnak bele ilyen tényezőket. K+F nuku, tanfolyamok semmi, tanulóprojektek zéró.

  Ezen bukik sokszor el minden, mert képtelenek sokan tartani a szintet, csak a jól ismert dolgokat merik használni.

• floatr veterán

  #10080

  #10079 Aethelstone

  2018-11-14 10:53:14

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #10079 Aethelstone

  #10079 Aethelstone

  Nem, mivel a penetrációt jól mutatja, hogy mekkora az igény. Ha nincs igény, nincs fejlesztő. Más oldalról ha belekezdek egy zöldmezősbe, rohadtul nem mindegy, hogy találok-e kompetenciát vagy a projekt első fele azzal telik, hogy kutatgatom a választott technológiát vagy kilóra veszek elérhető embereket a piacon

  Ez egy rendkívül jó érv arra, hogy sose kezdj bele semmibe, ami eltér a szokásostól.

• emvy félisten

  #10078

  #10076 Aethelstone

  2018-11-14 08:09:45

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #10076 Aethelstone

  #10076 Aethelstone

  Ez mondjuk abban az esetben igaz, ha nincs családod. Mert ha van és el kell tartanod őket, marha nagy szerencse kell, hogy abból tartsd el őket, amit élvezel. Saját tapasztalat. Másrészt ha sok a feladat és változatos, Java-ban is élvezem, nem kell a joy faktort még Kotlinnal is spékelni

  Eleve rossz metrikat hasznalsz. Onmagaban az allasok szama nem erdekes -- az a kerdes, hogy az allasok szama hogy viszonyul az allaskeresokhoz.

  Az erdekes melot meg azert is kell csinalni, mert jobban fog menni es jobban el tudod tartani a csaladod. Persze ez kozel sem fekete-feher, es van igazsag abban, amit mondasz.

• floatr veterán

  #10073

  #10069 Aethelstone

  2018-11-13 10:19:51

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #10069 Aethelstone

  #10069 Aethelstone

  Nekem az a véleményem, hogy amíg az indeed.com-on a Kotlin keresésre alig 1000 találat van, a Java-ra meg 60k, nem érdemes foglalkozni vele. Főleg nem munkaidőben, éles projekten. Lehet, hogy sokkal jobb nyelv, nem kétlem, de mire a penetrációja eléri a kritikus értéket, az ide írogatók már nyugdíjasok lesznek.

  Nagyjából ilyen arányban találsz zöldmezős kontra legacy fejlesztéseket feladatképpen ezeknél a cégeknél. Melyiket csinálnád szívesebben?
  Én '98 óta javazok, amikor még a trend sem nagyon látszott, nemhogy a piaci igény. A koltinban bőven van már perspektíva, ideje rájönnie sokaknak, hogy érdemes továbblépni.

• Froclee őstag

  #10072

  #10069 Aethelstone

  2018-11-12 20:24:56

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Froclee

  őstag

  #10069 Aethelstone

  #10069 Aethelstone

  Nekem az a véleményem, hogy amíg az indeed.com-on a Kotlin keresésre alig 1000 találat van, a Java-ra meg 60k, nem érdemes foglalkozni vele. Főleg nem munkaidőben, éles projekten. Lehet, hogy sokkal jobb nyelv, nem kétlem, de mire a penetrációja eléri a kritikus értéket, az ide írogatók már nyugdíjasok lesznek.

  Miért nem érdemes olyan nyelvvel foglalkozni, amire kisebb a kereslet? Szerintem ellenkezőleg.

• Cathfaern nagyúr

  #10071

  #10069 Aethelstone

  2018-11-12 20:04:55

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Cathfaern

  nagyúr

  #10069 Aethelstone

  #10069 Aethelstone

  Nekem az a véleményem, hogy amíg az indeed.com-on a Kotlin keresésre alig 1000 találat van, a Java-ra meg 60k, nem érdemes foglalkozni vele. Főleg nem munkaidőben, éles projekten. Lehet, hogy sokkal jobb nyelv, nem kétlem, de mire a penetrációja eléri a kritikus értéket, az ide írogatók már nyugdíjasok lesznek.

  Kb. 35 evem van nyugdijig. Kb. 23 evvel ezelott jelent meg az elso java verzio. Szoval szerinted meg 12 ev mire a java penetracioja eleri a kritikus erteket?

• emvy félisten

  #10070

  #10069 Aethelstone

  2018-11-12 19:38:49

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #10069 Aethelstone

  #10069 Aethelstone

  Nekem az a véleményem, hogy amíg az indeed.com-on a Kotlin keresésre alig 1000 találat van, a Java-ra meg 60k, nem érdemes foglalkozni vele. Főleg nem munkaidőben, éles projekten. Lehet, hogy sokkal jobb nyelv, nem kétlem, de mire a penetrációja eléri a kritikus értéket, az ide írogatók már nyugdíjasok lesznek.

  Szerintem meg fejlesztokent azt csinald, amit elvezel, piac ugyis van ra.

  Siman lehet Clojure, Elm, Haskell, Elixir allasokat talalni, ha valakinek ahhoz van kedve. Erdekes dolgot csinalni meg jobb, mint kevesbe erdekeset.

• floatr veterán

  #10039

  #10038 Aethelstone

  2018-11-07 09:40:38

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #10038 Aethelstone

  #10038 Aethelstone

  Én ezt nem így tapasztalom. Legalábbis kis hazánkban nem. Állami megrendelők még mindig csak EE-ben tudnak gondolkodni, a Spring maximum szitokszóként fordul elő, hogy az "hé, nem enterprááájzzz..." És ha még mellé standalone Spring Boot...nah akkor aztán világvége

  Állami megrendelők... ne viccelj

  Komoly piaci szereplők, amikor szóba kerül, hogy állami megrendelők milyen követelményekkel állnak elő, körberöhögnek. Liferay... oracle... valami kakás MVC... eszement clusterek

  Spring boot + kotlin vagy node + express, docker, mongo, react/angular, cloud, mobil app... ez a minimum, ha labdába akarsz rúgni. Az összes többi múlt idő, mint a lyukkártya

  BTW amikor megemlítjük, hogy néhány fejlesztőnek windows-os gépe van, akkor is van mosolygás

• floatr veterán

  #10037

  #10036 Aethelstone

  2018-11-06 10:46:22

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #10036 Aethelstone

  #10036 Aethelstone

  Igen, itt a lényeg. Kompetencia nincs manapság EE-re, mindenki beleesett ebbe a Springbootos őrületbe, ami persze n em baj, mert jó cucc alapvetően.

  Maradjunk annyiban, hogy mindenki menekül az EE környékéről, amióta kuka lett.

• Drizzt nagyúr

  #10031

  #10029 Aethelstone

  2018-11-05 20:43:11

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Drizzt

  nagyúr

  #10029 Aethelstone

  #10029 Aethelstone

  A springhez elég egy servlet konténer, nem igényel egy böszme alkalmazás-szervert. Pl.

  Java EE-hez is tudsz fat jart gyártani. Igaz a minimális méret ami szükséges így is jóval nagyobb, mint a minimális Spring boot csomag. Többet is nyújt out of the box, de tény, hogy nagyobb. Mondjuk 50 MB alatti méretről beszélünk, ami vagy számít, vagy nem.

  (#10030) mobal: Java EE-ben ez pont ugyanennyi, csak más annotációkat kell használni. Egy dolgot leszámítva: A JpaRepository-nak megfelelő ősosztály nincs külön benne a Java EE-ben, azt csinálni kell egyet magadnak.

• mobal nagyúr

  #9999

  #9995 Aethelstone

  2018-10-04 21:35:18

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #9995 Aethelstone

  #9995 Aethelstone

  8-ban. Linuxos változat. OpenJDK-ban kevesebb van. Végül is majdnem lényegtelen. 11-es egyelőre nem kívánom megismerni

  Pedig vannak jó dolgok 8 felett.

• emvy félisten

  #9998

  #9997 Aethelstone

  2018-10-03 20:13:06

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #9997 Aethelstone

  #9997 Aethelstone

  Nekem az a tippem, hogy ebben a 11 is eltér, font licenc problémák miatt.

  Dehat leirtam, hogy 11-ben nem lesz kulonbseg. A font renderert is atallitjak Freetype-ra T2K-rol.

• emvy félisten

  #9996

  #9995 Aethelstone

  2018-10-03 19:30:14

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #9995 Aethelstone

  #9995 Aethelstone

  8-ban. Linuxos változat. OpenJDK-ban kevesebb van. Végül is majdnem lényegtelen. 11-es egyelőre nem kívánom megismerni

  Végig a 11-ről volt szó. A 8 még kicsit eltér, senki sem állította, hogy nem.

• emvy félisten

  #9994

  #9993 Aethelstone

  2018-10-03 18:10:53

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #9993 Aethelstone

  #9993 Aethelstone

  Ez mondjuk nem teljesen igaz, de tény, hogy nagyonicikepicike eltérés van csak. Nem VM szintű. Fontok pl.

  11-ben eltérnek a fontok a két kiadás között?

• Lortech addikt

  #9935

  #9934 Aethelstone

  2018-09-03 08:16:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Lortech

  addikt

  #9934 Aethelstone

  #9934 Aethelstone

  Pontosan, ahogy a kolléga írta. Jackson, Json, Gson témakörben nézelődj.

  Szerk, hogy webservice. Hmm. Rest vagy webservice? Nem jó keverni. A rest alapvetően json (ez a szokás), a webservice xml.

  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.

• Atapi senior tag

  #9926

  #9925 Aethelstone

  2018-08-31 08:56:49

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Atapi

  senior tag

  #9925 Aethelstone

  #9925 Aethelstone

  Azért kell példányosítani, mert a main metódus nem része az osztálynak.

  szvsz inkább azért kell példányosítani, mert nem csak osztályszintű metódusokhoz és változókhoz szeretne hozzáférni (prrint(), tandij). Példányváltozója pedig egy adott példánynak van (aka objektum állapot), illetve példány metódust is csak adott példányon lehet meghívni (aka objektum állapot változás, viselkedés). Ha csak az alapTandij értékéhez szeretne hozzáférni, akkor nincs szükség példányosításra, mivel az static (osztályszintű).
  a main helye ebből a szempontból szerintem irreleváns, jogosultsági kérdések esetén lenne jelentősége.

• Lortech addikt

  #9918

  #9917 Aethelstone

  2018-08-26 20:49:58

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Lortech

  addikt

  #9917 Aethelstone

  #9917 Aethelstone

  Ezért írtam, hogy ízlés dolga A könyvekben található dolgokat meg nem véletlenül hívják ajánlásnak

  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.

• estro csendes tag

  #9916

  #9915 Aethelstone

  2018-08-26 14:55:26

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  estro

  csendes tag

  #9915 Aethelstone

  #9915 Aethelstone

  Hát jah. Ennek ellenére pl. a Sonar a &-et simán kifügyöli, hogy Te biztos &&-t akartál használi Egyébként én aránylag gyakran használom...ahogy írtam is, validálásra, amikor is azt akarom, hogy lefusson mindegyik, mert nem csak le kell futnia, hanem a lefutáskor mondjuk false esetén be is kell pirosozni vmit...nyilván ezt lehet &&-el is, de ez már ízlés dolga.

  Hát az elég átláthatatlan kód, nem? Egy feltétel vizsgálatnál szerintem legtöbben nem számítanánk állapot változásra. Ha jól emlékszem valamelyik könyvben volt is írva, hogy nem ajánlott használni.

• Lortech addikt

  #9914

  #9913 Aethelstone

  2018-08-25 11:45:29

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Lortech

  addikt

  #9913 Aethelstone

  #9913 Aethelstone

  A && és & közötti különbség nem csak hatékonyság kérdése. Egyszerűen másra való. & akkor kell, ha mindenképpen végig akarod tolni a láncot, pl. több érték validálása. Logical vs. Conditional

  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.

• emvy félisten

  #9877

  #9876 Aethelstone

  2018-07-16 17:39:22

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #9876 Aethelstone

  #9876 Aethelstone

  .

  ?

• MrSealRD veterán

  #9871

  #9870 Aethelstone

  2018-07-14 19:48:15

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  MrSealRD

  veterán

  #9870 Aethelstone

  #9870 Aethelstone

  Ilyet a github is tud. Hogy miben van hátrányban? Nem tudom, hogy milyen spec igényeitek vannak. Release, snapshot, artifactory tuti van. Maven, gradle support, minden szar

  Nagyon röviden, most van egy SVN + Jekins + Sonar + Jfrog artifactory kombó, amit használunk a fejlesztés során. De ez 3rd party üzemeltetés most amivel sok a baj... Ezért az egészet lokálba hozzuk át. És ha már 0-ról építjük akkor újragondoltuk meg verziót frissítettünk. SVN kuka, helyette lesz Git. Jfrog helyett meg Nexust néztük. Így jött ki ez a kis probléma. Még erősen a pilot szakaszban vagyunk...

  Ha a gitlabbal megoldható, hogy kidobjuk a Jenkinst akkor az üzemeltetés lehet örülni fog, hogy kevesebb rendszerrel kell foglalkozni.

• MrSealRD veterán

  #9869

  #9868 Aethelstone

  2018-07-14 17:46:38

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  MrSealRD

  veterán

  #9868 Aethelstone

  #9868 Aethelstone

  Jenkinst gitlabbal ki lehet váltani.

  Hm. Ez nem jutott eszünkbe. Most nem vagyok még képben teljesen mennyire használjuk ki a Jenkinst, de amit én tudok az a klasszikus SNAPSHOT és RELEASE build készítés, ami utána artifactoryba pakol... Ettől függetlenül lehet olyan képessége a Jenkinsnek amiben a Gitlab le van maradva?

• Lortech addikt

  #9844

  #9841 Aethelstone

  2018-06-25 19:10:24

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Lortech

  addikt

  #9841 Aethelstone

  #9841 Aethelstone

  Nem igaz. A primitív típusoknak van konkrét default értékük.

  byte 0
  short 0
  int 0
  long 0L
  float 0.0f
  double 0.0d
  char '\u0000'
  boolean false

  (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.

• Sokimm senior tag

  #9842

  #9840 Aethelstone

  2018-06-25 19:07:44

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Sokimm

  senior tag

  #9840 Aethelstone

  #9840 Aethelstone

  Van egy kis kavar. Egy String az instanceof-ra akkor is true, ha nincs inicializálva, azaz null értékű.

  Ha igaz lenne amit mondasz, akkor az első if-em true-ként értelmezné a feltételt, és az AskDeviceName kezdő értékét (asd) beállítaná mondjuk null-ra, elvégre true a feltétel. (és kiiratná a 2_AskDeviceName.isEmpty()? sort...)
  Ha String AskDeviceName-et vizsgálom, hogy.equals-e, akármire, akkor nincs hibaüzenet, de ha a .getProductString-re, akkor van....)
  Ergo valami nem stimmel...

  import java.awt.BorderLayout;
import purejavahidapi.*;/*
http://nyholku.github.io/purejavahidapi/javadoc/index.html
https://github.com/nyholku/purejavahidapi */

import java.util.List;

public class HID_joy {
public static void main(String[] args) {

String AskDeviceName = "";

List<HidDeviceInfo> devList = PureJavaHidApi.enumerateDevices();
for (HidDeviceInfo info : devList) {

System.out.println("1_AskDeviceName.isEmpty()? " + AskDeviceName.isEmpty());
if (info.getProductString() instanceof String) {
AskDeviceName = info.getProductString();
System.out.println("2_AskDeviceName.isEmpty()? " + AskDeviceName.isEmpty() + " mert: " + AskDeviceName);
}
System.out.println("3_AskDeviceName.length()" + AskDeviceName.length());


if (info.getProductString() instanceof String && AskDeviceName.equals("CM STORM INFERNO GAMING MOUSE")) {

System.out.println("mach!!!");
VendorID = info.getProductId();
ProductID = info.getProductId();
} else {
System.out.println("Nem a keresett eszköz");
}
}

  így néz ki ez konzolon:
  1_AskDeviceName.isEmpty()? true
  3_AskDeviceName.length()0
  Nem a keresett eszköz
  1_AskDeviceName.isEmpty()? true
  2_AskDeviceName.isEmpty()? false mert: USB Joystick
  3_AskDeviceName.length()12
  Nem a keresett eszköz
  1_AskDeviceName.isEmpty()? false
  3_AskDeviceName.length()12
  Nem a keresett eszköz
  1_AskDeviceName.isEmpty()? false
  2_AskDeviceName.isEmpty()? false mert: CM STORM INFERNO GAMING MOUSE
  3_AskDeviceName.length()29
  mach!!!

  De ha nyersen ráengedem az info.get-re a .equals-t, akkor jön a hibaüzi...

  System.out.println(info.getProductString().isEmpty());
//vagy erre is hibát dob:
System.out.println(info.getProductString().length());
  Exception in thread "main" java.lang.NullPointerException

• updog őstag

  #9826

  #9825 Aethelstone

  2018-06-14 15:56:38

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  updog

  őstag

  #9825 Aethelstone

  #9825 Aethelstone

  Estleg base64 enkódolva is berakhatod és akkor nem kell az útvonallal bohóckodni.

  Köszi mindenkinek a válaszokat!

  A lényeg ugye az lenne, hogy az applikációtól független path-on elérhető képeket rakjak ki (tehát pl. ide a relative path nem igazán értelmezhető).

  Az most mindegy, hogy honnan szedem a fájlok elérési útjait, a problémám konkrétan az, hogy azok most is jók (külön beírva akár böngészőbe ezeket, megjelennek a képek, míg az oldalon beágyazva ugyanezzel az elérési úttal nem). Először ezt a bagatellnek tűnő hibát próbálom megoldani.

  Nyilván tök ugyanezzel a kóddal - ha a webapp saját folderébe teszem a képeket és így relatív pathszal hivatkozok rájuk, megjelennek, tehát nem a megjelenítő kóddal lesz a baj.

• <Lacy85> addikt

  #9811

  #9809 Aethelstone

  2018-05-22 14:20:39

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  <Lacy85>

  addikt

  #9809 Aethelstone

  #9809 Aethelstone

  Üdv. Szerintem EE+Jsp nem ideális elmélyedni. Javaslom, hogy inkább SE+Spring, valami Ajaxos cuccal, mint GWT/Vaadin vagy esetleg valami JS frontend.

  Hmmm. Lehet, hogy rosszul fogalmaztam.
  Nem a JSP-t akarom megtanulni elmélyedés címszó alatt, hanem majd a későbbiekben szeretnék pár weboldalt összedobni JSP alatt.
  Előtte természetesen végigrágom magam kb. a HelloWorld-től a Spring-ig.
  Csak az érdekelne, hogy szerintetek mennyire lehet alapozni az EE + JSP-re most, hogy dobja az Oracle.

• zmb668 csendes tag

  #9741

  #9739 Aethelstone

  2018-03-05 06:35:49

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  zmb668

  csendes tag

  #9739 Aethelstone

  #9739 Aethelstone

  UTF8 is lehet, de akkor máshogy kell beolvasni.

  Igy van. Viszont a kod valszeg ResourceBundle-t hasznal, az pedig iso-8859-1-ben olvassa a filet.

• gojko.m senior tag

  #9740

  #9739 Aethelstone

  2018-03-04 17:31:35

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  gojko.m

  senior tag

  #9739 Aethelstone

  #9739 Aethelstone

  UTF8 is lehet, de akkor máshogy kell beolvasni.

  Ha jól gondolom ez a programkód módosítását igényelné. Ha így van, akkor nem bolygatom tovább a dolgot, az előző megoldás is megfelelő.

• floatr veterán

  #9710

  #9709 Aethelstone

  2018-02-14 10:17:47

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #9709 Aethelstone

  #9709 Aethelstone

  Nos, amennyiben a zöldmezős projektnek nincs konkrét határideje, illetve fejlesztői erőforrás igénye, én is elgondolkodnék rajta

  Azért ennyire nem vészes a dolog. Első lépésben simán át lehet térni rövid idő alatt anélkül, hogy kotlin stdlib-et meg DSL-eket használnál. Később meg jönnek maguktól a specifikus részletek

  Egy apróság, amin hümmögtem valamelyik nap. Spring Boot 2 HATEOAS controllernél javasolt módszer
  linkTo(methodOn(this.getClass()).findById(1L))
  elhasal valószínűleg implementációs hibával, mivel a methodOn egy proxy-t gyártana, ami nem megy final típusú paraméterek, visszatérési értékek esetében sem.
  Ez
  linkTo(this::findById.javaMethod, 1L)
  viszont tökéletesen működik, és a reflection is jobb, mivel a compiler oldja meg, nem a runtime név alapján.

• floatr veterán

  #9698

  #9696 Aethelstone

  2018-01-30 08:52:55

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #9696 Aethelstone

  #9696 Aethelstone

  Nyilván a trend tagadhatatlan. Ami vita tárgya, az a mérték.

  Az androidnak köszönhetően már most népszerűbb, mint a scala valaha

  Eleinte egyébként nekem sem volt túl szimpatikus a dolog, mert valahogy javas fejlesztőként élből elutasítok minden gyanús alternatívát, de valamiért rávettem magamat, hogy nézzek utána, és elég meggyőző. Most kerül RC1-be a kotlin DSL-re épülő spring boot, kiderül h mit ér el. Talán a korral jár, de néha már fáraszt, ahogy újabb dolgok jönnek-mennek, de némi belátással el kellett ismernem, hogy ez túl jó ahhoz, hogy elsikkadjon. Én azt látom benne, hogy a javanak kellett volna ilyenné válnia.

• emvy félisten

  #9697

  #9696 Aethelstone

  2018-01-30 08:39:28

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #9696 Aethelstone

  #9696 Aethelstone

  Nyilván a trend tagadhatatlan. Ami vita tárgya, az a mérték.

  Mivel egyenekrok van szo, ezert a kerdes az, hogy lehetne-e talalni allast, ha ragaszkodnal a Kotlinhoz. Szerintem igen.

• floatr veterán

  #9694

  #9691 Aethelstone

  2018-01-25 20:14:32

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #9691 Aethelstone

  #9691 Aethelstone

  Tényleg nem akarnék belevau, de pl. a profession.hu egy darab eredményt sem ad ki arra, hogy "kotlin". Java-ra viszont rengeteget. Peace!

  Bármi lehetséges. Ez egyelőre csak most kezdődött igazán, és nem hiszem, hogy csak én látom a trendet benne.

• G.Zs. senior tag

  #9692

  #9691 Aethelstone

  2018-01-25 16:35:16

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  G.Zs.

  senior tag

  #9691 Aethelstone

  #9691 Aethelstone

  Tényleg nem akarnék belevau, de pl. a profession.hu egy darab eredményt sem ad ki arra, hogy "kotlin". Java-ra viszont rengeteget. Peace!

  Rossz helyen keresed.

• emvy félisten

  #9685

  #9684 Aethelstone

  2018-01-24 20:23:03

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  emvy

  félisten

  #9684 Aethelstone

  #9684 Aethelstone

  Nyilván EE-nel kell kezdeni..könnyű leckék sorozata

  Ne kezdjünk bele az idióta trollkodásba megint.

• togvau senior tag

  #9640

  #9639 Aethelstone

  2017-12-05 20:41:07

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  togvau

  senior tag

  #9639 Aethelstone

  #9639 Aethelstone

  Felejtsd el ezt a jsf témát....valami ajaxos frameworkkel sokkal többre mégy...

  igen, el kéne felejteni, mert elavult, nagyon régi dolog, és ahogy látom 9 év alatt minimális fejlődés jött össze, de maximális mennyiségű új bug. De sajnos sok helyen ragaszkodnak a régi dolgokhoz, mert a mánáger kitalálta.

• mobal nagyúr

  #9604

  #9602 Aethelstone

  2017-11-26 12:20:46

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  mobal

  nagyúr

  #9602 Aethelstone

  #9602 Aethelstone

  Az a helyzet, hogy ha a vitákat letiltod, akkor továbbra is olyan témák lesznek, amiket 5 perc guglival el tud bárki intézni

  Az a baj, hogy ennek nem vita lett volna a vége. Az vita, hogy pl. Maven vs. Gradle de a kolléga teljesen ignorálta a dolgot.

• MrSealRD veterán

  #9603

  #9602 Aethelstone

  2017-11-26 10:25:14

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  MrSealRD

  veterán

  #9602 Aethelstone

  #9602 Aethelstone

  Az a helyzet, hogy ha a vitákat letiltod, akkor továbbra is olyan témák lesznek, amiket 5 perc guglival el tud bárki intézni

  Nem az összes vitát tiltotta le, csak ezt. Ez meg teljesen jogos volt. Akinek ilyen extrém véleménye van az nem hajlik arra, hogy vevő legyen más felvetésekre...Ebből egy parttalan vita lenne csak. Érdemi eredmény nélkül a végén személyeskedésbe fordulna.

• Taoharcos aktív tag

  #9597

  #9596 Aethelstone

  2017-11-25 15:12:13

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Taoharcos

  aktív tag

  #9596 Aethelstone

  #9596 Aethelstone

  Azt hittem, hogy az ilyen arcok, mint Te, már rég kihaltak...szórakoztató olvasni a gondolataid

  +1

Új hozzászólás Aktív témák