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

• floatr veterán

  #8000

  #7988 Aethelstone

  2015-12-09 09:46:09

  Ú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

  #7988 Aethelstone

  Mert egy csak JDBC-s megoldásnál csak JDBC-t tudsz használni mindenre Ha két qeryből áll a projekt akkor még vállalható, de efölött kezd kissé kellemetlenné válni a dolog.

  Régebben én is lázadoztam a hibernate használata ellen, találtam különféle félmegoldásokat, aztán be kellett látnom, hogy felesleges a széllel szemben cuccolni, pláne úgy, hogy azt is tudja, amiért lázadoztam, csak sokan nem tudják használni az eszköztárát megfelelően. Az élet kegyetlen...

• Aethelstone addikt

  #7999

  #7998 pecze

  2015-12-09 09:40:10

  Ú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

  #7998 pecze

  Hali.

  Első körben célszerűbb lenne a tömb helyett valamiféle listában tárolni a dolgozókat, mivel a listához dinamikusan lehet elemeket hozzáadni.

  Tehát dolgozo[10] helyett lehetne mondjuk List<dolgozo>

  Aztán kellene egy metódus a ceg osztályban, ami mondjuk lehetne addDolgozo(dolgozo d), ami is lazy inittel adná hozzá a listához a dolgozókat.

  public class ceg {
  
  List<dolgozo> dolgozok;
  
  public void addDolgozo(dolgozo d) {
  if (this.dolgozok==null) {
  this.dolgozok = new ArrayList<dolgozo>();
  }
  // Itt lehetne mindenféle ellenőrzés, hogy van-e már ilyen, stb.
  this.dolgozok.add(d);
  
  }
  
  }
  
  // A feltöltés kb. így nézne ki..
  
  dolgozo elso = new dolgozo("férfi","XY","Budapest",26);
  ceg cegBT = new ceg();
  cegBT.addDolgozo(elso);

  Még valami.....Java-ban osztálynév nagybetűvel kezdődik...elnevezési konvenció.

• pecze aktív tag

  #7998 2015-12-09 09:22: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

  

  pecze

  aktív tag

  Sziasztok
  Lehet amatőr kérdés, van egy osztályom, amiből ha készítek egy példányt egy másik osztály egy tömbjében szeretném eltárolni.
  Pl. egyik osztály
  public class dolgozo {
  private String nem;
  private String nev;
  private String cim;
  private int kor;
  }
  Konstruktor és setter getter is van minden létező módon beállítva.
  Másik osztály, ebben kéne egy tömböt létrehozni, amiben el tudom tárolni a példány során megadott dolgokat, így gondoltam
  public class ceg {
  private dolgozo[] dolgozotomb;
  }
  Példányosításnál pedig
  dolgozo elso = new dolgozo("férfi","XY","Budapest",26);
  ceg cegBT = new ceg();
  ceg.setdolgozotomb(new dolgozo[10]);

  Itt akadtam el, mert bármilyen értékadásra hibaüzenetet kapok, illetve az se biztos, hogy eddig jó

• Aethelstone addikt

  #7997

  #7996 Sk8erPeter

  2015-12-09 09:04: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

  

  Aethelstone

  addikt

  #7996 Sk8erPeter

  Igazad van, mindenkinek igaza van, nekem nincs igazam. Így jó?
  Ami meg a konkrét problémát illeti, pontosan értem, hogy mit akarsz mondani, mégis azt mondom, hogy kinek a pap, kinek pedig a papné. Részemről lezárva.

• Sk8erPeter nagyúr

  #7996

  #7995 Aethelstone

  2015-12-09 08:56: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

  

  Sk8erPeter

  nagyúr

  #7995 Aethelstone

  Nem tudom, mire célozgatsz, de ha még mindig tényleg nem érted, én sem akarlak megsérteni, de próbáld meg talán értően elolvasni még egyszer, amire reagálgatsz már egy ideje, hogy eljuss odáig, ahova a többiek már jól láthatóan eljutottak...
  De most tényleg, nem tudom, mit nem lehet felfogni azon, hogy a metódusok visszatérési értékét tároljuk már el a bánatba nyomorult változókba, és ne hívogassuk már ugyanazokat a fostos metódusokat újból és újból az eltárolt visszatérési érték felhasználása helyett.

• Aethelstone addikt

  #7995

  #7992 Sk8erPeter

  2015-12-09 08:43: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

  

  Aethelstone

  addikt

  #7992 Sk8erPeter

  Megsérteni nem akarlak, ezért inkább azt választom, hogy nem értem, hogy miről vakerálsz Persze, nyilván van még opció, de mint említettem, nem akarlak megsérteni Peace

• Lortech addikt

  #7994 2015-12-09 07:59: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

  

  Lortech

  addikt

  Már csak azért is érdemes különbséget tenni a sima "láncban hívás" meg builder API-k között, mert előbbi potenciálisan LoD sértés, utóbbi meg többnyire nem.

• WonderCSabo félisten

  #7993 2015-12-08 22:41:52

  Ú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

  

  WonderCSabo

  félisten

  Hogy a VM bemegeledegese ne adjon fals eredmenyt, ahhoz ezt szoktak hasznalni.

• Sk8erPeter nagyúr

  #7992

  #7990 Aethelstone

  2015-12-08 22: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

  

  Sk8erPeter

  nagyúr

  #7990 Aethelstone

  Most kicsit nehéz eldönteni, hogy tényleg nem érted, miről vakerászok, vagy csak szívatsz.

• fatal` titán

  #7991

  #7990 Aethelstone

  2015-12-08 21:51: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

  

  fatal`

  titán

  #7990 Aethelstone

  A láncban hívása nem. Az említett példával viszont nem az volt a probléma, hanem az, hogy a lánc nagyrészét többször is hívja egymás után.

• Aethelstone addikt

  #7990

  #7989 Sk8erPeter

  2015-12-08 21:39: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

  

  Aethelstone

  addikt

  #7989 Sk8erPeter

  Azért írtam, mert metódusok hívogatása láncban nem az ördög műve. Annyira nem, hogy pattern is épül rá, amit buildernek hívnak. Erre gondoltam.

• Sk8erPeter nagyúr

  #7989

  #7962 Aethelstone

  2015-12-08 19:41: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

  

  Sk8erPeter

  nagyúr

  #7962 Aethelstone

  Tényleg nem, de érted, nem attól lesz builder pattern egy kód, hogy láncolva hívogatsz metódusokat (ahogy a kolléga is írta). Igazából a lényege a példának itt a felesleges "önismétlés" hibájába esés volt, hogy bizonyos - "menetközben" nem változó értéket visszaadó - metódusok visszatérési értékét akár el is tárolhatnánk, hogy spóroljunk némi overheadet, de nem tesszük, mer' nem tom mé'.

• Aethelstone addikt

  #7988

  #7987 floatr

  2015-12-08 18:10: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

  

  Aethelstone

  addikt

  #7987 floatr

  Ok, de miért native query, ha van jdbc Ráadásul zöldmezős projekt és a jelszó keep it fuckin' simple

• floatr veterán

  #7987

  #7986 Aethelstone

  2015-12-08 17:13: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

  #7986 Aethelstone

  Hasonló cipőben járunk, bár a CSV két teljesen különböző adatmodell közti átjáráshoz kell, és a DBA önkezűleg futtatja a generátort.

  Mindegy, a kulcsszavak: stateless session, report query, native query meg hasonlók. Ezekkel egy migráció sem probléma, de ha egy nagyobb projekt része, akkor nem kell megőrülni a többi usecase esetében az alacsony szintű eszközöktől.

• Aethelstone addikt

  #7986

  #7985 floatr

  2015-12-08 17:05: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

  #7985 floatr

  Ez ennél nehezebb. DB-->CSV-->DB. Ne kérdezd miért, köze van hozzá a SAP-nak is

• floatr veterán

  #7985

  #7984 Aethelstone

  2015-12-08 16:51:09

  Ú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

  #7984 Aethelstone

  Feltételeztem, hogy vannak olyan elemek, amiket entitásként lehet kezelni. Ettől függetlenül tartom a dolgot, hogy két adatmodell közti átjárást is elég jól meg lehetne vele oldani, bár a DBA-k nálunk a migrációt scriptekben látják, amiben mondjuk van is valami, ha milliós nagyságrendű rekord csúszik át, az hálózaton elég lassú tud lenni.

• Aethelstone addikt

  #7984

  #7982 floatr

  2015-12-08 16:39: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

  

  Aethelstone

  addikt

  #7982 floatr

  Az a baj, hogy ezek általánosságok. Feladattól és programozótól függ az egész. Nekem pl. most van egy adatmigrációs projektem, JDBC alapokon megy, isten mentsen meg, hogy bármiféle ORM-hez nyúljak...viszont egy mezei 3 rétegű web alkalmazásnál már mindenképpen indokolt lehet ORM használata.

• pvt.peter őstag

  #7983

  #7981 Aethelstone

  2015-12-08 15:59: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

  

  pvt.peter

  őstag

  #7981 Aethelstone

  hálistennek db kapcsolat nincs benne,
  "egyszerű" objektumokon való műveletvégzést valósít meg minden komponens

• floatr veterán

  #7982

  #7979 Aethelstone

  2015-12-08 15:49: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

  

  floatr

  veterán

  #7979 Aethelstone

  Lehet rajta pörögni, de egyrészt a valódi bottleneck nem az ORM lesz, hanem a hálózati adatkapcsolat. Másrészt lehet jól és rosszul is használni, alacsony és magas absztrakciós szinten. Van olyan eszköze, amivel egy jdbctemplate sem lesz érdemben gyorsabb. viszont többféleképpen tud egyazon projekten belül is viselkedni, amire egy jdbctemplate nem képes.

  Amúgy meg lehet nézni, hogy mekkora overhead egy projekt esetén, ha nem használnak épkézláb perzisztenciát. Ezt a legtöbb kliens ma már nem lenne hajlandó kifizetni. De ha annyira a data layer nanoszekundumain kell gondolkodni, akkor miért nem tárolt eljárásokban implementálja az, akinek ez fáj? Komolyan...

• Aethelstone addikt

  #7981

  #7977 pvt.peter

  2015-12-08 15:45: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

  

  Aethelstone

  addikt

  #7977 pvt.peter

  Meg azt sem árt tudni, hogy ezek a komponensek mit csinálnak. Adatbázis kapcsolat pl. elsőre kissé le tudja fogni a teljesítményt, de ha mondjuk pool van kötve a végére, akkor a második és sokadik futás értelemszerűen már sokkal gyorsabb...és sorolhatnám.

• #39560925 törölt tag

  #7980

  #7978 floatr

  2015-12-08 15:39: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

  

  #39560925

  törölt tag

  #7978 floatr

  + JIT van és futás közben optimalizál

• Aethelstone addikt

  #7979

  #7975 floatr

  2015-12-08 15:37: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

  

  Aethelstone

  addikt

  #7975 floatr

  Nos, nyilván lehet ide-oda reszelgetni, de alapvetően sosem lesz olyan gyors, mint egy pure JDBC(max kényelmesebb). Nyilván a feladattól és a programozótól is függ....láttam egyébként pár DEBUG módban kiírt Hibernate query-t......hajamat téptem tőlük. Ha ORM kell, akkor nem kérdés, de kérdés mindig az, hogy kell-e ORM.

• floatr veterán

  #7978

  #7977 pvt.peter

  2015-12-08 15:07: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

  

  floatr

  veterán

  #7977 pvt.peter

  Létezik az, hogy a VM memóriát pucol, betölt, lefordít, becache-el dolgokat, de az elméletileg első futtatáskor megtörténik. Ez a jelenség más infrastruktúrán is jelentkezik.

  Azt viszont a teljesítményteszteknél érdemes megjegyezni, hogy mindig lesznek kiugróan rossz, vagy jó eredmények, ami nem igazán tükrözi a normál körülményeket. Használnak emiatt sokféle statisztikai mutatót, de nekem eddig a legjobban a medián jött be, az egyszerű átlagolás könnyen elvisz a málnásba.

  Ja és természetesen lehetőleg kellően sok futtatás kell ahhoz, hogy valós képet kapjál. Ha az elsőt mondjuk eldobod, után mondjuk 10 mérés már sok esetben elég tud lenni.

• pvt.peter őstag

  #7977 2015-12-08 14:43: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

  

  pvt.peter

  őstag

  Sziasztok!

  Lenne egy érdekes kérdésem.
  Adott egy rendszer amelyben az egyik igen csak teljesítményigényes végrehajtó részt, kísérleti jelleggel több komponens is megvalósítja.
  A lényeg, hogy ezeknek a komponenseknek a teljesítményét szeretném mérni.
  Nem bonyolítom túl az egészet, egyszerűen csak futási időt fogok mérni a System.nano() hívással.

  long start = System.nanoTime();
  ...
  long end = System.nanoTime() - start;

  Mennyire valós dolog az, hogy a Java lassan "melegszik" be.
  Tehát ha én egy adott függvény teljesítményét akarom lemérni, akkor az első 5-6 futás eredményét tényleg érdemes-e eldobni?

  A válaszokat előre is köszönöm,
  Peti

• pvt.peter őstag

  #7976

  #7954 Sk8erPeter

  2015-12-08 14:11: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

  

  pvt.peter

  őstag

  #7954 Sk8erPeter

  Köszönöm a részletes válaszodat.

• floatr veterán

  #7975

  #7971 Aethelstone

  2015-12-08 09:01:42

  Ú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

  #7971 Aethelstone

  Van nagyon jó hibernate performance oktatásunk, ha érdekel
  Ha egyszer ebben az életben még lesz valaha egy kis szabadidőm, akkor majd írok is róla.

• emvy félisten

  #7974

  #7972 Aethelstone

  2015-12-07 21:42: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

  

  emvy

  félisten

  #7972 Aethelstone

  - torles lenyegeben nincs, soha
  - egy adott fajlt jellemzoen nem olvasunk vissza tobbszor, mint par tucat alkalom
  - a fajlok lehetnek akar nagy videok is, amikbe bele kene tudni tekerni
  - az egesz tetejen egy massziv titkositas ul

  Valoszinu, hogy HDFS-sel fogok inditani, aztan majd meglatjuk.

• mobal nagyúr

  #7973

  #7971 Aethelstone

  2015-12-07 20:21: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

  #7971 Aethelstone

  Értem, köszi.

• Aethelstone addikt

  #7972

  #7970 emvy

  2015-12-07 19:52:31

  Ú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

  #7970 emvy

  Nem írtál sokat Mire kell? Read inkább? Vagy write?

• Aethelstone addikt

  #7971

  #7969 mobal

  2015-12-07 19:50:17

  Ú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

  #7969 mobal

  Nem a Hibernate a gond, hanem az ORM. Overhead.

• emvy félisten

  #7970

  #7968 Aethelstone

  2015-12-07 19:39: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

  

  emvy

  félisten

  #7968 Aethelstone

  Ezekbol egyelore nem latom, hogy lenne elosztott, random-access blob store, ami egyebkent konnyen replikalhato, etc. Postgresunk van mar, az nem annyira kenyelmes fajlok tarolasara.

• mobal nagyúr

  #7969

  #7965 Aethelstone

  2015-12-07 19:11: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

  

  mobal

  nagyúr

  #7965 Aethelstone

  OpenJPA a kiszemelt. Van jobb?

• Aethelstone addikt

  #7968

  #7967 Aethelstone

  2015-12-07 18:48: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

  

  Aethelstone

  addikt

  #7967 Aethelstone

  Úgy értem zfs+bsd+postgresql.

• Aethelstone addikt

  #7967

  #7966 emvy

  2015-12-07 18:27: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

  

  Aethelstone

  addikt

  #7966 emvy

  Valami bsd, zfs-sel?

• emvy félisten

  #7966 2015-12-07 18:21: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

  

  emvy

  félisten

  Distributed random-access read-ot biztosító blob storage-ra lenne szükségem. HDFS-en kívül van ötlet? Ez sem ad rendes random accesst, de legalább blokkhatarokra tudok seekelni.
  Replikáció, HA alapkövetelmény. POSIX felület nem.

• Aethelstone addikt

  #7965

  #7963 mobal

  2015-12-07 18:16: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

  

  Aethelstone

  addikt

  #7963 mobal

  Egyébként akkor járnál a legjobban, ha nem kellene Hibernate-t használnod.

• floatr veterán

  #7964

  #7963 mobal

  2015-12-07 10:32: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

  

  floatr

  veterán

  #7963 mobal

  JPA

  A hibernate is cseréli lefelé az API-ját a JPA-s megfelelőkre, ahogy halad az idő. De csak azon múlik, mire kell a projekt neked.

• mobal nagyúr

  #7963

  #7943 Aethelstone

  2015-12-07 07:10: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

  #7943 Aethelstone

  Ez oké. Használtam már így is-úgy is. De a kérdés lényege - lehet félreérthetően írtam -, hogy ha tehetem ragaszkodjak a JPA-hoz, vagy adott esetben jó nekem a Hibernate nem így implementálva.

• Aethelstone addikt

  #7962

  #7959 PazsitZ

  2015-12-06 21:36: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

  

  Aethelstone

  addikt

  #7959 PazsitZ

  Pffff....nem a megnevezésen volt a hangsúly.

• Sk8erPeter nagyúr

  #7961

  #7833 Sk8erPeter

  2015-12-06 20:43: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

  

  Sk8erPeter

  nagyúr

  #7833 Sk8erPeter

  Most jutott eszembe, hogy elfelejtettem megírni, hogy erre sikerült megtalálni a megoldást, hátha valakinek kell, ha a példában a TreeViewert szeretnénk lecserélni CheckboxTreeViewerre, és azt szeretnénk, hogy még működjön is, és ne kapjunk StackOverflowErrort, akkor saját check state providert kell beállítanunk, és a probléma meg is van oldva:

  v.setCheckStateProvider(new ICheckStateProvider() {
  
  /**
  * TODO: provide complete solution
  */
  @Override
  public boolean isGrayed(Object element) {
  return false;
  }
  
  /**
  * TODO: provide complete solution
  */
  @Override
  public boolean isChecked(Object element) {
  return false;
  }
  });

  Persze az isGrayed és isChecked metódusok visszatérési értékét nekünk kell a saját alkalmazáslogikánk szerint beállítani.

• Sk8erPeter nagyúr

  #7960

  #7959 PazsitZ

  2015-12-06 20:39:04

  Ú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

  

  Sk8erPeter

  nagyúr

  #7959 PazsitZ

  "az a példa szerintem egész eltérő a kiinduló kérdéstől"
  Tök igazad van, igazából csak annak kapcsán jutott eszembe ez a másik téma, hogy beszélgettünk arról, hogy mi az, ami "szép", és mi az, ami pl. nekem személy szerint nem bejövős, az eredeti kérdéshez a whateveres példának már tényleg nincs köze. Szóval röviden a lényeg, hogy sokan szeretik agyontömörítgetni a kódot, amikor attól nem lesz jobb vagy olvashatóbb a kód, sőt, jobb lehet inkább szétdobálni, illetve hogy másik oldalról viszont sokan szeretik újból és újból leírni ugyanazokat az ismétlődő kódrészletet, ezzel pont, hogy túlzottan bőlére eresztik a kódot, illetve ez a módszer erőforrások pazarlására is alkalmas (overhead).

• PazsitZ addikt

  #7959

  #7958 Aethelstone

  2015-12-06 20:07: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

  

  PazsitZ

  addikt

  #7958 Aethelstone

  A builder pattern az egy pattern, ahol van egy buildered és azon hívsz metódusokat. Amit még csak nem is kötelező, de célszerű/kézenfekvő láncolva hívni. Jah és a végén ugye build()-et hívsz nem foo()-t.
  Nem arról szól, hogy ha metódusokat láncolva hívsz akkor builder pattern-t használsz.

  Konkrétan a whatever példában számomra is az a természetesebb, ha kiemeled változóba a kérdéses részt, de az a példa szerintem egész eltérő a kiinduló kérdéstől.

• Aethelstone addikt

  #7958

  #7957 Sk8erPeter

  2015-12-06 19:37: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

  

  Aethelstone

  addikt

  #7957 Sk8erPeter

  Builder pattern. Egyébként amiről írsz, az pusztány egyéni preferencia kérdése.

• Sk8erPeter nagyúr

  #7957

  #7956 Aethelstone

  2015-12-06 19:25:42

  Ú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

  

  Sk8erPeter

  nagyúr

  #7956 Aethelstone

  Mármint milyen design pattern? Ez a "How to produce spaghetti code and waste resources" design pattern? Vagy inkább nevezzük egy rossz begörcsölődésnek?

  (#7955) M_AND_Ms:
  Jaja. És mennyivel gyorsabb sorban feldolgozni az infókat, és látni egyenként, hogy mi történik, mint kódátfutás során értelmezni az egybedobált sorokat, ahol ki tudja, még hány egyéb metódushívás vagy más művelet történik. Egyszerűen mész végig a sorokon, és még mindig tudod követni. Amikor viszont agyon van tömörítve a kód, és a szemnek ugrálnia kell, az agynak pedig megjegyeznie egyetlen sor értelmezése közben csomó infót, az fárasztó - és az ember azért elég sűrűn olvashatja munkakörnyezetben másnak a kódját.

  Amúgy ez az egész kettős: az előző hsz.-emben lévő whateveres példa pont, hogy túl szószátyár és még pazarló is. Számomra sokkal olvashatóbb is lenne az a kód, ha az ismétlődő metódushívások eredményét eltárolnánk egy változóba - amit eleve így illik -, és onnantól kezdve tudnám, hogy kifejezetten azzal akarunk valamit kezdeni, nem kellene mindig végigfutnom a sort odáig, amíg ugyanaz történik, hogy tudjam, hogy most pont ugyanazt babráljuk, csak nem raktuk az eredményt külön válltozóba. (Az ilyennek a lerövidítése egyébként Eclipse-ben annyi, hogy kijelöljük az ismétlődő kódrészt, egy Alt+Shift+L, és létrehozható belőle egy lokális változó, és meg van oldva.)

• Aethelstone addikt

  #7956

  #7954 Sk8erPeter

  2015-12-06 19:02:23

  Ú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

  #7954 Sk8erPeter

  Az a buli, hogy a whateveres példád Java-ban egy design pattern

• M_AND_Ms veterán

  #7955

  #7954 Sk8erPeter

  2015-12-06 18:38:19

  Ú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

  #7954 Sk8erPeter

  Egyetértek. A kód valamelyest az emberi gondolkodást is reprezentálja.

• Sk8erPeter nagyúr

  #7954

  #7951 pvt.peter

  2015-12-06 18:11: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

  

  Sk8erPeter

  nagyúr

  #7951 pvt.peter

  Szerintem egyáltalán nem csúnya, hogy külön sorba rakod, hogy mit művelsz azzal a listával, amit majd be szeretnél rakni a HashMapbe. Sőt, gyorsan olvasható, egyértelmű, tiszta, és elkerülsz vele egy tök felesleges plusz metódushívást. A második is jól olvasható, de tény, hogy pazarlóbb. Így egy elemnél aztán tényleg totál mindegy teljesítmény szempontjából, meg láthatóság szempontjából is, de én meg attól kaparom az arcom, amikor olyan kódot kell olvasnom, amikor láthatóan a fejlesztő célja az volt, hogy vagányan mindent minél rövidebbre tömörítsen. Az sem számít, hogy hányszor ismétel azonos metódushívásokat, hány plusz műveletet igényel, de milyen jól mutat, hogy legalább tömör. Hát nem, nem lesz feltétlenül gyorsabban olvasható a kód (persze nyilván bőven vannak kivételek, de ne fossuk már le ennyire a teljesítményt). Tényleg valakinek attól lesz olvashatatlan a kód, mert külön sorban ki van fejtve, hogy mi történik? Az már régen rossz. Magasszintű nyelveknél egyébként nagyon divat(tá vált?) az is, hogy a metódushívásokat egymás után is ismételgetjük, mondván, "nem kell túlpörögni optimalizáció szempontjából", mint a kolléga mondta, ez itt abszolút igaz, de általában ezzel nagyon nem értek egyet. Egyrészt ha ennyire leszarjuk, hányszor történik meg egy-egy metódushívás, akkor az már zsigeri szintű igénytelenséghez vezethet hosszabb távon a teljesítmény rovására, meg azért szépen lehet halmozgatni az ilyen tök felesleges overheadeket, na de minek. (Persze ebben az is szerepet játszik, hogy ebből a szempontból mai napig bennem van a C, C++ tanulásának korszaka, amikor az ilyesmi nem volt menő.)
  Pl. ilyesmi:
  whatever.doStuff().veryCool().blahblah();
  whatever.doStuff().veryCool().wow().great();
  whatever.doStuff().veryCool().notCool();
  Na itt pl. a whatever.doStuff().veryCool() eredményét el lehetett volna tárolni egy változóba. De nem, ez így tök menő. Ja várjunk csak, mégsem.

  Szerk.:
  Persze simán lehet, hogy az ilyeneket a fordító úgyis optimalizálja. Mindegy, bennem az van, hogy abból baj nincs, ha egyértelműen láthatóvá teszem, mi történik, nekem a pár sorral bővebben hablatyolós kód nem lesz olvashatatlanabb, az agyontömörített kód viszont annál inkább. (Meg a debuggolást is nehezebbé teheti. )

• Aethelstone addikt

  #7953

  #7950 PazsitZ

  2015-12-06 17:59: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

  

  Aethelstone

  addikt

  #7950 PazsitZ

  Meg kellene nézni, hogy milyen bájtkód lesz belőle, de tippem szerint a jvm szénné optimalizálja a collectionos cuccokat. Illetve nyilván by definition lehet tudni, hogy miben gyors a map, a list vagy a többi...

  Meg az elemszám. Kis elemszámnál legyen inkább szép a kód

• pvt.peter őstag

  #7952

  #7947 #39560925

  2015-12-06 16:28: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

  

  pvt.peter

  őstag

  #7947 #39560925

  ahogy @Aethelstone is írta, a kérdés szempontjából nem releváns
  csak az egyszerűség kedvéért írtam Object -et

• pvt.peter őstag

  #7951

  #7946 M_AND_Ms

  2015-12-06 16:28:17

  Ú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

  

  pvt.peter

  őstag

  #7946 M_AND_Ms

  Tlképpen csak egy O(1) -el van több műveletem a 2. -ban, nem?
  Ez pedig a hash kód alapján való elem lekérés a getKey segítségével.
  Bár lehet hogy ugrálni kell majd a hash táblában mert a hasítófüggvény nem elég precíz ahhoz, hogy olyan kódot tudjon gyártani amihez biztos, hogy nem tartozik még semmi se.
  (fix me, de asszem vmi ilyesmin alapszik a map ... )

  Ettől függetlenül igen, az elsőt célszerű használni.
  A kérdésemet csak azért raktam fel, mert mindig csak egy elemet rakok bele abba a listába és kicsit csúnya volt, hogy mindig létre kell hoznom egy temp listát ehhez.

• PazsitZ addikt

  #7950

  #7945 pvt.peter

  2015-12-06 16:26: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

  

  PazsitZ

  addikt

  #7945 pvt.peter

  Az első esetnél egy temp referencia van, a második esetnél van a Map get és egy cast művelet.
  Nem hiszem, hogy ilyeneket szintű dolgokat kellene túlpörögni optimalizáció szempontból.

  Ha nagyon rövidíteni akarsz, ezek is használhatóak:

  objects.put(actualKeyObject, new ArrayList<Object>() {{ add(actualValueObject); }});
  objects.put(actualKeyObject, Arrays.asList(actualValueObject));

  Egyébként inkább abba az irányba gondolkodnék, hogy ha több elemet pakolunk a listába, akkor azt külön metódusba kiszervezni és az első példa szerint hozzáadni érdemesebb/átláthatóbb szerintem.

  Egy elemű lista esetén viszont számomra inkább az inline megoldások a szimpatikusabbak.

• #39560925 törölt tag

  #7949

  #7948 Aethelstone

  2015-12-06 15:59:19

  Ú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

  

  #39560925

  törölt tag

  #7948 Aethelstone

  nincs, de érdeklődöm. habár el se olvastam rendesen a kérdését, utólag elolvasva tényleg felesleg volt feltennem.

• Aethelstone addikt

  #7948

  #7947 #39560925

  2015-12-06 15:50:04

  Ú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

  #7947 #39560925

  A kérdés szempontjából van jelentősége?

• #39560925 törölt tag

  #7947

  #7945 pvt.peter

  2015-12-06 14:30: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

  

  #39560925

  törölt tag

  #7945 pvt.peter

  Miért Object-eket tárolsz?

• M_AND_Ms veterán

  #7946

  #7945 pvt.peter

  2015-12-06 14:20:52

  Ú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

  #7945 pvt.peter

  Az első, mivel a kész listával még van dolgod (hogy belerakd, amit akarsz), ezért jó, ha az megvan. A második esetben rögtön berakod a listát a Map-be, így azt egyből vissza is kell keresned, ami mégiscsak idő és energia

• pvt.peter őstag

  #7945 2015-12-06 14:14: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

  

  pvt.peter

  őstag

  Sziasztok!

  Szerintetek melyik konstrukciót célszerűbb használni?
  Pl. olvashatóság, performancia szempontjából.

  Map<Object, List<Object>> objects = new HashMap<Object, List<Object>>();
  List<Object> temp = new ArrayList<Object>();
  temp.add(actualValueObject);
  objects.put(actualKeyObject, temp);

  vagy:

  Map<Object, List<Object>> objects = new HashMap<Object, List<Object>>();
  objects.put(actualKeyObject, new ArrayList<Object>());
  objects.getKey(actualKeyObject).add(actualValueObject);

  Előre is köszi,
  Peti

• Lortech addikt

  #7944

  #7943 Aethelstone

  2015-12-06 12:48: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

  #7943 Aethelstone

  Nem egészen. A Hibernate valóban JPA implementáció is, de a JPA még fasorban sem volt, már akkor Hibernate-eztem. Használhatod JPA-val is, meg a natív API-ján keresztül is.
  Az eredeti kérdésre a válaszom az, hogy nem muszáj JPA, de hacsak nincs valami különös oka (valamilyen JPA korlát) az esetedben, ami miatt hanyagolnád a JPA-t, én maradnék a JPA-nál.

• Aethelstone addikt

  #7943

  #7941 mobal

  2015-12-06 12:32: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

  #7941 mobal

  Nos, a Hibernate egy JPA implementáció. A kérdés úgy helyes, hogy kell-e neked JPA/Hibernate vagy elég a sima JDBC is.

• xTc aktív tag

  #7942

  #7941 mobal

  2015-12-06 09: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

  

  xTc

  aktív tag

  #7941 mobal

  Elegánsabb lenne, ha használnál, de nem létszükséglet, viszonylag ritkán cserél az ember JPA implemntációt egy projekt alatt, feltéve ha nincs egetverő nagy probléma a már létező verzióval.

• mobal nagyúr

  #7941 2015-12-05 18:32: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

  

  mobal

  nagyúr

  Java SE esetén kell nekem a JPA feltétlenül, vagy elég csak egy "mezei" hibernate?

• M_AND_Ms veterán

  #7940

  #7936 Karma

  2015-12-04 20:32: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

  

  M_AND_Ms

  veterán

  #7936 Karma

  Az én hozzászólásomban meg volt egy idézett mondat, tehát az én hozzászólásomban arról volt szó.

• bambano titán

  #7939

  #7923 Aethelstone

  2015-12-04 20:10: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

  

  bambano

  titán

  #7923 Aethelstone

  miért tomcat?

• #39560925 törölt tag

  #7938

  #7937 Aethelstone

  2015-12-04 19:27:30

  Ú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

  

  #39560925

  törölt tag

  #7937 Aethelstone

  Dehogynem ugyanaz a téma. Bambano új projektet kezd, és erre öntökönrúgás nem Java 8-at használni.

  "Az 1.7-es javaval ugyanolyan jól lehet dolgozni felteszem, mint az 1.8-al."

  Ez pedig nem igaz, hisz nincsenek funkcionális elemek az 1.7-ben.

• Aethelstone addikt

  #7937

  #7936 Karma

  2015-12-04 19:15: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

  

  Aethelstone

  addikt

  #7936 Karma

  Nem ugyanaz a téma. Az 1.7-es javaval ugyanolyan jól lehet dolgozni felteszem, mint az 1.8-al. Hogy az oracle nyugdíjazta? Tudjuk miért. Ettől openjdk formában él és virul.

• Karma félisten

  #7936

  #7934 M_AND_Ms

  2015-12-04 18:48: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

  

  Karma

  félisten

  #7934 M_AND_Ms

  COBOL programozókra is szükség van még a világban, és minden tiszteletem az övéké. De most egy új projekt indításáról volt szó, nem a legacy-ről.

• Aethelstone addikt

  #7935

  #7934 M_AND_Ms

  2015-12-04 18:43: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

  

  Aethelstone

  addikt

  #7934 M_AND_Ms

  Pontosan.

• M_AND_Ms veterán

  #7934

  #7931 Aethelstone

  2015-12-04 18:28: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

  

  M_AND_Ms

  veterán

  #7931 Aethelstone

  "Sajnos azonban a mai senior Java fejlesztő brigád 1.6-1.7(1.5??) környékén leragadt."

  Mert ezek fejlesztők általában elő, működő és aktívan használt projekteken dolgoznak, amikbe hosszú évek üzleti tudása van berakva. És erre nagyon vigyáznak. Nem fognak Java verziót váltogatni, mert az megjelent.
  A kísérletező kedvű ifjú titánok persze megtehetik, hogy mindenfélét kipróbálgassanak, de majd bekerülnek az "életbe" és örülnek, ha nem kell meglévő funkciókat vagy, projekteket piszkálgatni.

• Karma félisten

  #7933

  #7931 Aethelstone

  2015-12-04 17:13: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

  

  Karma

  félisten

  #7931 Aethelstone

  Az OpenJDK8 is GA lett 2014 áprilisában, úgyhogy már az is elég régi ahhoz, hogy begyepesedett berkekben is "meg lehessen kockáztatni használni". Én se hobbiprojektekben használom.

  A nyelv újításai miatt szerintem egy kezdőnek is bőven megéri foglalkoznia vele - a lambdák és a streamek a legalapvetőbb mórickapéldákban is már kézzelfogható előnnyel bírnak. Na meg ha Görögországba mész, ott se ógörögül tanulsz meg először. Persze ez szubjektív, mások meg notepadban kínoznák a kezdőket, hogy hadd szokják az ipart.

  Egyébként update 66-nál jár az Oracle JDK8. Biztos, hogy a rendszerkomponenseid rendben vannak biztonságilag, ha ennyire véres kérdéseket vetnek fel?

• Aethelstone addikt

  #7932

  #7927 #39560925

  2015-12-04 17:10: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

  

  Aethelstone

  addikt

  #7927 #39560925

  Szerintem meg egy olyan terméknek kell lennie az alapnak minden projektnél, ami már bizonyított és kb. 50 update-n már túl van. Nem bíznám a produktív, kritikus rendszerem egy 1.8-as Java-ra. Majd 2 év múlva...amikor már minden disznóság kiderült róla és a rendszerkomponenseimen sem kell minimum 2 főverziót emelni, hogy működjenek vele rendesen...és még sorolhatnám...

• Aethelstone addikt

  #7931

  #7928 Karma

  2015-12-04 17:00:34

  Ú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

  #7928 Karma

  Nos, 1.8-as Java-val igazából csak akkor érdemes foglalkozni, ha az ember valóban ki is használja. Sajnos azonban a mai senior Java fejlesztő brigád 1.6-1.7(1.5??) környékén leragadt. Jah, hogy 1.8-on kívül nincs support? A világ nem csak Oracle Java-ból áll, hanem *nix környezetben van OpenJDK is, ami ott kvázi szabvány és egyáltalán nem elhagyott. Hivatalosan a RedHat még mindig supportálja a 7-es OpenJDK-t.

  Szóval, nem csak hobbiprojektek és 1.8-as Oracle Java van a világon.

  És komolyan kérdezem, aki most kezd el Java-val foglalkozni, annak miért is nem jó egy 7-es verzió? Vagy akár a 6-os is......

• MrSealRD veterán

  #7930

  #7929 #39560925

  2015-12-04 16:35: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

  

  MrSealRD

  veterán

  #7929 #39560925

  Így már világos, az érvelés érthetővé teszi a dolgot, de a kérdőjelekből ez nem kitalálható... érted...

• #39560925 törölt tag

  #7929

  #7928 Karma

  2015-12-04 16:28: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

  

  #39560925

  törölt tag

  #7928 Karma

  ezzel csak egyet tudok érteni.

• Karma félisten

  #7928

  #7927 #39560925

  2015-12-04 16:25: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

  

  Karma

  félisten

  #7927 #39560925

  Egyébként az Oracle szerint is, ugyanis 2015. április óta nincs supportja, hacsak nem köt külön szerződést az ember a céggel.

  A Tomcat 7-et is felesleges archaizálásnak érzem, mondjuk nem is állnék neki kézzel Tomcatet telepíteni, amióta van Spring Boot.

• #39560925 törölt tag

  #7927

  #7926 Aethelstone

  2015-12-04 16:20: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

  

  #39560925

  törölt tag

  #7926 Aethelstone

  szerintem 1.8 kéne legyen a minimum minden új projektnél.

• Aethelstone addikt

  #7926

  #7924 #39560925

  2015-12-04 15:52: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

  

  Aethelstone

  addikt

  #7924 #39560925

  Én sem értem a kérdőjeleket. 7-es Java jobban tetszett volna ? Egyébként meg azt írtam, hogy minimum.

• MrSealRD veterán

  #7925

  #7924 #39560925

  2015-12-04 15:49: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

  

  MrSealRD

  veterán

  #7924 #39560925

  Miért a sok kérdőjel?

• #39560925 törölt tag

  #7924

  #7923 Aethelstone

  2015-12-04 15:46: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

  

  #39560925

  törölt tag

  #7923 Aethelstone

  1.7????

• Aethelstone addikt

  #7923

  #7919 bambano

  2015-12-04 13:59: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

  #7919 bambano

  Nos a tervezett rendszer mélyebb ismerete nélkül.

  - Java 1.7 minimum
  - Tomcat 7
  - Spring Framework (Security, MVC)
  - Ha kell ORM, akkor Hibernate
  - Kliens oldalon JQuery a dinamikus formkezelés miatt. A JQuery ELVILEG! böngészőfüggetlen.

  Elsőre ezekből létre lehet hozni egy aránylag könnyűsúlyú cuccot.

• bambano titán

  #7922

  #7920 floatr

  2015-12-04 12:53: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

  

  bambano

  titán

  #7920 floatr

  "Na majd erre fogsz olyan válaszokat kapni, hogy nem győzöd kapkodni a fejed.": nem baj, hagy jöjjön
  a személyes tapasztalatot nem találok meg a gugliban.

• Aethelstone addikt

  #7921

  #7920 floatr

  2015-12-04 09: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

  

  Aethelstone

  addikt

  #7920 floatr

  magyarán ne legyen olyan hibrid megoldás, ami keveri a szerveroldali és kliensoldali technológiát (pl gwt).

  Bátorkodnám megjegyezni, hogy nem a gwt, hanem a gwt-t használó fejlesztők egy része, illetve bizonyos gwt-re épülő frameworkok keverik (szándékosan, mert az milyen jó?!) a kliens és szerveroldalt

  Ha csak standard gwt és az ember azért betartja a szabályokat, akkor nincs keveredés. Főleg ha még tudja is a fejlesztő, hogy mit csinál(ő és a gwt egyaránt)

• floatr veterán

  #7920

  #7919 bambano

  2015-12-04 09:21:04

  Ú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

  #7919 bambano

  Na majd erre fogsz olyan válaszokat kapni, hogy nem győzöd kapkodni a fejed. Nekem olyan szempontjaim vannak hasonló problémákra, hogy legyenek az egyes rétegek teljesen különválasztva, magyarán ne legyen olyan hibrid megoldás, ami keveri a szerveroldali és kliensoldali technológiát (pl gwt). Legyen egy kliens oldali framework, és egy SOA backend. Nekem a Spring backend és az ExtJS jött be eddig a leginkább. Utóbbit azért használom szívesebben, mert nem dizájnerek találták ki.
  Dinamikus formokat saját megoldással raktunk össze, akármilyen technológia is volt a frontenden. Ha a dizájn nem az egyedi brandelés irányába menne el, akkor ennél gyorsabb eszközt nem nagyon találsz. Már nem farokméregetésiből, csak eddig ezt tapasztaltam

• bambano titán

  #7919 2015-12-03 19:16:50

  Ú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

  nagy help kellene nekem
  a helyzet: az eddig használt kedvenc fejlesztői eszközeim atom mód elavultak és kimentek a divatból. a másik pontja a helyzetnek, hogy nulláról el kellene kezdenem írni egy alkalmazást.
  a kettő következménye, hogy úgy döntöttem, az egész kóceráj megy a kukába, és (majdnem) teljes platformot váltok. a kérdés, hogy mire a felhasználói felület és környéke a segítségkérés tárgya
  megváltoztathatatlan feltételek:
  - jáva (nyilván, ha ide írok)
  - webes kliens szerver cucc
  - appszerver glassfish
  - netbeansben menjen a fejlesztés.
  - aktuális firefoxszal működjön

  változtatható feltételek, álmok:
  - ehhez az alkalmazáshoz jó lenne, ha futásidőben változtatható formokat tudnék csinálni.

  a megálmodott ideális válasz a kérdésemre:
  - használj icefaces-t
  - használj x.y keretrendszert,
  stb.

  tia

• Atlantisz48 őstag

  #7918

  #7917 Szmeby

  2015-12-03 12:38: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

  

  Atlantisz48

  őstag

  #7917 Szmeby

  Köszönöm a részletes magyarázást,
  Netbeans-ben sikerült működésre bírni.

• Szmeby tag

  #7917

  #7916 Atlantisz48

  2015-12-02 22:19: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

  

  Szmeby

  tag

  #7916 Atlantisz48

  Ha komolyabban szeretnél foglalkozni a dologgal, telepíts egy IDE-t magadnak (IntelliJ Idea, Eclipse, Netbeans, akármi), sok szenvedéstől kímél meg, ha ebben írod a programod.

  Ugyanis fordítási hibád van, és ezek azonnal jelzik neked. Időnként még használható javítást is tudnak prezentálni. Bár az üzenet egyértelmű: a Thread.sleep() metódus ellenőrzött kivételt dob, amivel neked kezdened kell valamit.
  Vagy elkapod, és "kezeled":

  try {
  while (idozito < 5){
  System.out.print("*");
  Thread.sleep(500);
  idozito = idozito + 1;
  }
  } catch (InterruptedException e) {
  // a te esetedben ilyen amúgyse fog történni, de kezelni kötelező
  System.err.println("Bajci van! Valami kilőtte alólam a szálat.");
  e.printStackTrace();
  }

  Vagy továbbpasszolod a kivételt a hívónak a stacken eggyel feljebb, vagyis a ciklust tartalmazó metódusod végére a paraméterek után odabiggyeszted a throws InterruptedException szavakat. Ilyenkor viszont a hívóban kell kezelned a problémát... vagy onnan is továbbküldöd... teheted ezt egészen addig, amíg el nem éred a main metódust, de ha az sem kezeli, akkor a programod a kivételdobás pillanatában rövid úton le fog állni (mivel a kivételt senki sem kezelte le).

  Kis szösszenet az InterruptedExcpetion-ről.

• Atlantisz48 őstag

  #7916

  #7915 WonderCSabo

  2015-12-02 21:57:19

  Ú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

  

  Atlantisz48

  őstag

  #7915 WonderCSabo

  Ezt a hibát írja ki:

  

• WonderCSabo félisten

  #7915

  #7914 Atlantisz48

  2015-12-02 21:02: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

  

  WonderCSabo

  félisten

  #7914 Atlantisz48

  Define "hibat jelez".

• Atlantisz48 őstag

  #7914 2015-12-02 20:50: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

  

  Atlantisz48

  őstag

  Üdv!

  A segítségeteket szeretném kérni, mert sajnos nem boldogulok.

  while (idozito < 5){
  System.out.print("*");
  Thread.sleep(500);
  idozito = idozito + 1;
  }

  Azt szeretném összehozni, hogy várjon a program a továbbfutással minden ciklus ismétlődésnél fél percet. De sajnos folyton hibát jelez.
  Jól használom ezt a metódust, vagy erre ezt nem lehet használni?

  Előre is köszönöm.

  Üdv:
  Zoli

• WonderCSabo félisten

  #7913

  #7909 Orionk

  2015-12-01 15:56: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

  

  WonderCSabo

  félisten

  #7909 Orionk

  Tehát azt nem értem, hogy pl. miért lesz az első elem típusa string, amikor mind a kettő byte.

  Harom elem van. Az elso string "a+b=". A masodik ket elem egy-egy byte.

  Vagy, ha így lenne: System.out.println("a+b="+(a+b));
  akkor kerülne kiírásra ez: "a+b=7" ?

  Igen.

  "+ karakterpáros egymás melletti használata

  Itt egy felreertes lesz. Ennek a ket karakternek egymas mellett semmilyen specialis jelentese nincsen. A + operator tul van terhelve, es ha barmelyik oldalan egy String van, akkor nem az alapveto osszeadast vegzi el, hanem string osszefuzest. Eloszor persze ehhez azt az elemet ami nem string volt, stringge alakitja. Ez tortenik a pelda eseteben is.

• Aethelstone addikt

  #7912

  #7909 Orionk

  2015-12-01 15:43:50

  Ú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

  #7909 Orionk

  Azért, mert itt az első elem nem az a, hanem az "a+b= " String.

• Aethelstone addikt

  #7911

  #7903 Orionk

  2015-12-01 15:42: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

  

  Aethelstone

  addikt

  #7903 Orionk

  Nem jó a kérdés. Nem az a kérdés, hogy miért jobb, hanem az, hogy miért az.

• floatr veterán

  #7910

  #7909 Orionk

  2015-12-01 15:25: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

  

  floatr

  veterán

  #7909 Orionk

  Mert az összeadás precedenciája szerint úgy értékeli ki a kifejezést, hogy elősör elvégzi az első összeadást, aminek String a vége, majd hozzáadja a második számot is szövegesen.

• Orionk senior tag

  #7909

  #7908 WonderCSabo

  2015-12-01 15:09:23

  Ú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

  

  Orionk

  senior tag

  #7908 WonderCSabo

  Nem értem, hogy miért.
  Tehát azt nem értem, hogy pl. miért lesz az első elem típusa string, amikor mind a kettő byte.

  A kiíratásban a "+ karakterpáros azt jelenti, hogy összefűzzük az általunk kiírandó stringet az összeadással, nem?

  Vagy, ha így lenne: System.out.println("a+b="+(a+b));
  akkor kerülne kiírásra ez: "a+b=7" ?

  Tehát azt nem értem, hogy ha a "+ karakterpáros egymás melletti használata azt jelenti, hogy fűzze össze, akkor mitől jelenti ezt. Én eddig mindig így fűztem a kiírandó szöveg mellé az összegeket.

  köszönöm

• WonderCSabo félisten

  #7908

  #7907 Orionk

  2015-12-01 14:34:04

  Ú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

  

  WonderCSabo

  félisten

  #7907 Orionk

  A valasz: "a+b= 43"

  Talan 7-et varna az ember. Azert lesz megis 43, mert itt nem osszeadas lesz, hanem az elso elem tipusa miatt (ami String), string osszefuzes. Ebben az esetben minden elemet elosszor stringge alakit, majd osszefuzi oket.

• Orionk senior tag

  #7907

  #7906 WonderCSabo

  2015-12-01 14:19:19

  Ú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

  

  Orionk

  senior tag

  #7906 WonderCSabo

  köszi
  ---

  Egy másik buta kérdésem:
  byte a=4;
  byte b=3;
  System.out.println("a+b= "+a+b);

  Mit fog kiírni? és miért?
  Állásinterjún egy abszolút kezdő juniornak volt ilyen kérdés és ezért kérdezem.

  köszi

• WonderCSabo félisten

  #7906

  #7905 Orionk

  2015-12-01 14:11: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

  

  WonderCSabo

  félisten

  #7905 Orionk

  Ez minden tipusnal igy van, kiveve a primitiveket. Az int primitiv tipus.

• Orionk senior tag

  #7905

  #7904 emvy

  2015-12-01 14:03: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

  

  Orionk

  senior tag

  #7904 emvy

  De akkor ez csak String-eknél van?

  Mert, ha pl. vannak
  int a,b; változóim, akkor azokra tudom használni az == operátort, pl. így:
  (a==b)
  és az 'a' és 'b' változók sem egy helyen vannak a memóriában.

  köszi

• emvy félisten

  #7904

  #7903 Orionk

  2015-12-01 13:57: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

  

  emvy

  félisten

  #7903 Orionk

  A == az nem erteket hasonlit ossze, hanem a referencia erteket (kb. azt, hogy hol van a memoriaban).

• Orionk senior tag

  #7903 2015-12-01 13:48: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

  

  Orionk

  senior tag

  Sziasztok !

  Javaban stringek összehasonlításánál miért jobb a "string".equals("string"); -et használni mint hogy így vizsgáljam (string == "string")

  Tehát azt kérdezném ilyenkor mindig az EQUALS függvényt kell használni? Ha nem mindig akkor mikor? És miért jobb az equals?

  köszönöm szépen.
  üdv.,

• mobal nagyúr

  #7902

  #7900 Karma

  2015-11-30 14:33: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

  

  mobal

  nagyúr

  #7900 Karma

  Amúgy a document filter működik webes java alkalmazásoknál is?

• zulu_mester tag

  #7901

  #7900 Karma

  2015-11-30 14:10: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

  

  zulu_mester

  tag

  #7900 Karma

  Köszi az útbaigazítást és bocsi, hogy rossz helyre írtam

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