- iPhone topik
- Milyen okostelefont vegyek?
- Xiaomi 15 - kicsi telefon nagy energiával
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy A36 5G - a középső testvér
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Xiaomi Watch S1 - szép az idő
- Honor 200 Pro - mobilportré
- Szerkesztett és makrofotók mobillal
- Sony Xperia 1 V - kizárólag igényeseknek
Új hozzászólás Aktív témák
-
#8765
Aethelstone
addikt
Chesterfield
#8764
Aethelstone
addikt
válasz
Chesterfield
#8764
üzenetére
-
#8759
Aethelstone
addikt
Aethelstone
#8758
Aethelstone
addikt
válasz
Aethelstone
#8758
üzenetére
Egyébként commandLink lenne itt inkább a jó, mint a commandButton. Abból is a h:commandLink változat.
-
#8734
Aethelstone
addikt
Chesterfield
#8731
Aethelstone
addikt
válasz
Chesterfield
#8731
üzenetére
Olyan szeparátort válassz, amit nem akarsz, hogy belekerüljön. Ha pontosan értettem a kérdésed.
-
#8693
Aethelstone
addikt
MasterMark
#8691
Aethelstone
addikt
válasz
MasterMark
#8691
üzenetére
Jelenthet List<List<String>> -et is
Esetleg List<String[]> -et is. -
#8586
Aethelstone
addikt
Aethelstone
addikt
Nálunk céges policy Eclipse. Jó az
-
#8131
Aethelstone
addikt
Szmeby
#8130
Aethelstone
addikt
Ez szerintem attól is függ, hogy éppen van-e aktív tranzakció. A tranzakció a commit-tel lesz sikeres, ergó ebben az esetben kell visszaírni a változásokat. Ha csak simán nyomunk egy close-t a Session-ra, akkor ugye teljesen attól függ(sometimes), hogy éppen van-e valami tranzakció. Mert egy close a commit nélkül eredménytelen elvileg...
A fax se tudja. DB függő is lehet, illetve JDBC implementáció......
-
#8105
Aethelstone
addikt
peterszky
#8102
Aethelstone
addikt
válasz
peterszky
#8102
üzenetére
Ha az alkalmazásod meg ráadásul valami alkalmazás-szerverben fut, akkor az alkalmazás-szerver kiválóan tudja monitorozni. Ha standalone, akkor érdemes lehet valami mbean, mxbean féle, normális cuccot csinálni, a core dumpok hákolása nem fehér embernek való
Vagy kezeld a lehetséges runtime exceptionokat Persze, nyilván nem azokat, amikor elfogy a disk vagy valaki letörli a linux kernelt a futó app alól 
-
#8083
Aethelstone
addikt
kemkriszt98
#8082
Aethelstone
addikt
válasz
kemkriszt98
#8082
üzenetére
-
#8081
Aethelstone
addikt
kemkriszt98
#8080
Aethelstone
addikt
válasz
kemkriszt98
#8080
üzenetére
1000 fölött random, sztenderd portokat kivéve bármi.
-
#8079
Aethelstone
addikt
kemkriszt98
#8076
Aethelstone
addikt
válasz
kemkriszt98
#8076
üzenetére
Marha egyszerű. A checkalive csatlakozáskor ne legyen jelzés.
1. kör checkalive. Küldesz valami stringet, amire ha jön válasz, akkor él a szerver. Ebben az esetben nincs jelzés.
2. kör. Csatlakozol még egyszer, hangjelzés, trallala.
Ugyanaz a port, csak kicsit át kell reszelni a szerver logikáját. Egy körben is le lehet zongorázni, olyasmi módon, ahogy a TLS is működik.
-
#8073
Aethelstone
addikt
bambano
#8072
Aethelstone
addikt
-
#8070
Aethelstone
addikt
bambano
#8069
Aethelstone
addikt
válasz
bambano
#8069
üzenetére
Nem értünk egyet. Nem kell ismerni a mavent és az svn/git/akármit. Egyszer elmondják és utána emlékezni kell rá. És kb. minden új Java technológiánál ezt várják el a juniortól....meg ha valamit nem tud, akkor igenis képes legyen emberi idő alatt kiguglizni vagy tudjon érdemben kérdezni.
-
#8067
Aethelstone
addikt
jetarko
#8063
-
#8057
Aethelstone
addikt
WonderCSabo
#8056
Aethelstone
addikt
válasz
WonderCSabo
#8056
üzenetére
Nem igaz, mert a pythonphpjavascriptcsharp a jövő
-
#8054
Aethelstone
addikt
AsterixComic
#8053
Aethelstone
addikt
válasz
AsterixComic
#8053
üzenetére
Ne izgulj! Junior fejlesztőtől nagyon alap dolgokat várnak el mindenhol. Azt viszont elvárják, hogy tanulékony legyél.
-
#8032
Aethelstone
addikt
Aethelstone
#8031
Aethelstone
addikt
válasz
Aethelstone
#8031
üzenetére
Egyébként kicsit általánosabban, lehet az, hogy implementáció és nem interfész típusú a változód, de csak abban az esetben, ha valami olyan metódust, tulajdonságot akarsz használni, ami az interfész nem biztosít, de az implementáció igen.
-
#8031
Aethelstone
addikt
pvt.peter
#8029
Aethelstone
addikt
válasz
pvt.peter
#8029
üzenetére
Többalakúság.
Problémák:
Ha szeretnéd kicserélni mondjuk egy LinkedList-re az ArrayListet, akkor nem tudod megtenni, mivel az eredeti változód típusa explicit ArrayList. Ha biztosan tudod, hogy az a változó az idők végezetéig ArrayList marad (ezt nem tudhatod), akkor maradhatna.
Másrészt meg nem szép. Kódolási konvenció a Collectionok esetében, hogy nem implementációt, hanem interfészt adunk meg ilyen esetben.
Érdemes "megszeretni" az interface típusú deklarációt, mivel egy csomó framework is így műx, pl. a Spring-es dependency injection esetében is interészekeket injektálsz, nem implementációkat.
Teljesítménygondok nem hiszem, hogy lennének.
szerk: Kolléga megelőzött
-
#8005
Aethelstone
addikt
Sk8erPeter
#8004
Aethelstone
addikt
válasz
Sk8erPeter
#8004
üzenetére
Debug? Úri huncutkodás, az igazi programozó jó kódot ír
Viccet félretéve, igazad van -
#8003
Aethelstone
addikt
Szmeby
#8002
Aethelstone
addikt
Ez igaz, de sok esetben nincs veszélye. Tipikus példa a konténer(DTO) jellegű osztályok.
Ha egymásba vannak ágyazva és engem csak egy érték érdekel, mondjukmyDTO.getSzamlak().getTetelek(0).getValue();
Itt ugye lehetne, hogy a getTetelek(0) esetén egy Tetel objektumot kvázi kiemelek és a getValue() metódust ezen hívogatom a jövőben, amennyiben többször is szükségem van az értékére. Vagy a fent írt sort idézgetem annyiszor, amennyiszer szükségem van rá.
Teljesítmény szempontjából semmiféle hátránya nincs, ha nem emelem ki, viszont megspórolok egy plusz objektumhivatkozást. Nyilván ha egy metódust drága hívogatni, akkor kiemelem, de pusztán annyit próbálok én is már ezer+1 hozzászóláson keresztül magyarázni, hogy a láncban hívás alapvetően lehet jó is. Feladatfüggő.
Nyilván ha nem tudom, hogy pontosan mit csinál a lánc, akkor tartózkodom a használatától, de ismétlem önmagam, a láncolt hívások alapvetően nem az ördögtől valóak és csak azért, mert nemteccik, nem kell elvetni a használatát.Law of Demeter, ha nem akarja egy objektum, hogy ilyen módon hívogassam a metódusait, akkor szervezze már úgy, hogy ne férjek hozzá, ha meg nem szervezi úgy és public, akkor miért ne használjam?
Ennyi. Zárom.
-
#8001
Aethelstone
addikt
floatr
#8000
Aethelstone
addikt
Nos, hogy konkrét legyek.
Első körben a különféle táblákból szerver oldalon összerakjuk tárolt eljárásokkal a CSV-nek megfelelő táblákat. Aztán sima JDBC-vel végigiterálunk az összerakott táblákon és elkészülnek a CSV-k.
Miért nem szerver oldalon? Azért, mert nincs hozzáférésünk a szerver oldali fájlrendszerhez.
Ez kb. 10 query-t jelent, mindenféle JOIN meg hasonlók nélkül, csak SELECT x,y,z FROM d;Én nem lázadok a Hibernate vagy bármilyen ORM réteg ellen, csak ha nem indokolja semmi a használatát, akkor nem használom. Ennyi
-
#7999
Aethelstone
addikt
pecze
#7998
Aethelstone
addikt
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ó.
-
#7997
Aethelstone
addikt
Sk8erPeter
#7996
Aethelstone
addikt
válasz
Sk8erPeter
#7996
üzenetére
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. -
#7995
Aethelstone
addikt
Sk8erPeter
#7992
Aethelstone
addikt
válasz
Sk8erPeter
#7992
üzenetére
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 -
#7990
Aethelstone
addikt
Sk8erPeter
#7989
Aethelstone
addikt
válasz
Sk8erPeter
#7989
üzenetére
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.
-
#7984
Aethelstone
addikt
floatr
#7982
Aethelstone
addikt
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.
-
#7981
Aethelstone
addikt
pvt.peter
#7977
Aethelstone
addikt
-
#7979
Aethelstone
addikt
floatr
#7975
Aethelstone
addikt
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.
-
#7968
Aethelstone
addikt
Aethelstone
#7967
Aethelstone
addikt
válasz
Aethelstone
#7967
üzenetére
Úgy értem zfs+bsd+postgresql.
-
#7958
Aethelstone
addikt
Sk8erPeter
#7957
Aethelstone
addikt
válasz
Sk8erPeter
#7957
üzenetére
Builder pattern. Egyébként amiről írsz, az pusztány egyéni preferencia kérdése.
-
#7956
Aethelstone
addikt
Sk8erPeter
#7954
Aethelstone
addikt
válasz
Sk8erPeter
#7954
üzenetére
Az a buli, hogy a whateveres példád Java-ban egy design pattern
-
#7953
Aethelstone
addikt
PazsitZ
#7950
Aethelstone
addikt
-
#7948
Aethelstone
addikt
Oppenheimer
#7947
Aethelstone
addikt
válasz
Oppenheimer
#7947
üzenetére
A kérdés szempontjából van jelentősége?
-
#7932
Aethelstone
addikt
Oppenheimer
#7927
Aethelstone
addikt
válasz
Oppenheimer
#7927
üzenetére
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...
-
#7931
Aethelstone
addikt
Karma
#7928
Aethelstone
addikt
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......
-
#7926
Aethelstone
addikt
Oppenheimer
#7924
Aethelstone
addikt
válasz
Oppenheimer
#7924
üzenetére
Én sem értem a kérdőjeleket. 7-es Java jobban tetszett volna ?
Egyébként meg azt írtam, hogy minimum. -
#7923
Aethelstone
addikt
bambano
#7919
Aethelstone
addikt
válasz
bambano
#7919
üzenetére
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.
-
#7921
Aethelstone
addikt
floatr
#7920
Aethelstone
addikt
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)
-
#7885
Aethelstone
addikt
Aethelstone
#7884
Aethelstone
addikt
válasz
Aethelstone
#7884
üzenetére
public class Bela {
private String nev;
private Integer fizu;
public Bela(String nev, Integer fizu) {
this.nev = nev;
this.fizu = fizu;
}
public Bela() {
//
}
}
Bela mybela = new Bela();
Field field = mybela.getClass().getDeclaredField("nev");
field.setAccessible(true);
System.out.println(field.get(mybela)); // Ez elvileg null
Bela mybela2 = new Bela("Lajos", 500000);
field = mybela.getClass().getDeclaredField("nev");
field.setAccessible(true);
System.out.println(field.get(mybela2)); // Ez meg elvileg Lajos -
#7884
Aethelstone
addikt
drogery
#7870
Aethelstone
addikt
válasz
drogery
#7870
üzenetére
Nos, azt láttam, hogy nem érkezett túl sok használható megoldás. Nekem személy szerint semmi bajom nincs a "gusztustalan" reflectionnal, ezt én tipikusan azzal oldanám meg. Egy lájtos for iteráció és pár, okosan elhelyezett if/then. Kb. tíz sor.
Szerk: Még iteráció sem kell.
-
#7883
Aethelstone
addikt
Aethelstone
addikt
Nem néztem meg részletesebben ezt a Kotlint, de számomra az a legnagyobb baj ezekkel, hogy van egy kialakult stack(pl nálunk), Spring, GWT, JQuery, JasperServer,stb. tartalommal és ez nem tudom, hogy mennyire szeretne egy ilyen Kotlin féle mókát. Még egy Java verzió emelés vagy egy Spring upgrade is boríthat mindent....
Szóval, max. új projekt, de a learning curve ott sem túl jó egy bejáratott stack-hez képest
Így elsőre..... -
#7844
Aethelstone
addikt
szcsaba1994
#7841
Aethelstone
addikt
válasz
szcsaba1994
#7841
üzenetére
Map<I,Map<K,J>> mymap;
Pl.
Lehet List is. As you wish. Viszont a 3 attributumos Object az igazán korrekt megoldás.
-
#7798
Aethelstone
addikt
floatr
#7797
-
#7759
Aethelstone
addikt
WonderCSabo
#7758
Aethelstone
addikt
válasz
WonderCSabo
#7758
üzenetére
Eclipse swt.
-
#7714
Aethelstone
addikt
Oppenheimer
#7713
Aethelstone
addikt
válasz
Oppenheimer
#7713
üzenetére
A CTRL+SPACE segítő sem rossz. Sok gépeléstől (és gondolkodástól) megkíméli az embert
-
#7601
Aethelstone
addikt
Sk8erPeter
#7600
Aethelstone
addikt
válasz
Sk8erPeter
#7600
üzenetére
Itt az Oracle a legnagyobb troll
-
#7595
Aethelstone
addikt
Oppenheimer
#7594
Aethelstone
addikt
válasz
Oppenheimer
#7594
üzenetére
Nos, ez azért erős túlzás...
-
#7566
Aethelstone
addikt
Lortech
#7565
Aethelstone
addikt
válasz
Lortech
#7565
üzenetére
Jaja, nyilván a natív exe wrapper. Mivel a service egy speciális mód, ezért ott a normál PATH beállítások sajnos nem játszanak. Ebben az egész buliban igazából csak az a vicces, hogy pl. a Windows 2008 szerveren máshogy települ fel a 32 bites és a 64 bites Java...mind1..nem is annyira lényeges, de jó nagy szopók voltak ezzel. Egy standalone jetty-re épülő alkalmazást kellett windows service-ként futtatni
-
#7564
Aethelstone
addikt
Aethelstone
addikt
Plusz infó a PATH-hoz, hogy alkalmazásként indítva működik, de ha Java alkalmazást service-ként kerül indításra, akkor nagyívben szarik a PATH-ra és a rendszernek megfelelő(32 vs. 64) System könyvtárban keresgél.
-
#7459
Aethelstone
addikt
floatr
#7458
Aethelstone
addikt
Nyilván mindenkinek más fekszik. Ezért is nehéz eldönteni adandó alkalommal, hogy melyik nyelv lenne jó arra, hogy a teljesen zöldeket bevezesse a programozás világába. Ezért talán fontosabb az, hogy az a tanár, aki tanítja, milyen képességekkel rendelkezik, hogy elmagyarázza a népeknek. Mert aki zöld, annak olyan tökmind1, hogy melyik lesz az első programnyelv. (kivéve assembly
) -
#7385
Aethelstone
addikt
emvy
#7383
Aethelstone
addikt
A fő gond ezzel a Scalaval az szerintem, hogy a programozás oktatás még nem készült fel erre a nyelvre. Ahogy a linkelt doksi is tartalmazza, nem találnak megfelelő fejlesztőket.
Because it's effectively impossible to hire people with prior Scala
experience (of the hundreds of people we've interviewed perhaps three had Scala
experience, of those three we hired one), this matters much more than it might
otherwise. If we take even the strongest of JVM engineers and rush them into
writing Scala, we increase our maintenance burden with their funky code; if we
invest heavily in teaching new hires Scala they won't be writing production code
for a while, increasing our time-to-market. Contrast this with the default for
the JVM ecosystem: if new hires write Java, they're productive as soon as we can
get them a keyboard.És ez szerintem középtávon nem is fog változni. Ugyanaz a helyzet kb. mint annó, amikor a sok c,pascal,dbase/clipper fejlesztőből akartak OO feljesztőket találni, de egészen egyszerűen egy nemzedéknek "ki kellett halnia" és fel kellett nőnie egy újnak, aki már ezt tanulta célirányosan.
Szerintem...
-
#7372
Aethelstone
addikt
M_AND_Ms
#7370
Aethelstone
addikt
válasz
M_AND_Ms
#7370
üzenetére
Előbb talán elolvasnád amit írtam vagy a kolléga írt. A kolléga konstans stringeket hasonlított egy string tömb elemeihez. "bor" == data[0]. ERRE írtam, hogy itt az equals kell és írtam, hogy pl. egy Long i = 1 (i == 1)-nél nem kell i.equals(1), hanem == is megteszi. Pont. Semmi többet nem írtam, Te meg elővetted az okoskodást és kurvára szétoffoltad a témát. Szerintem. Tehát okosodás első lépcsőjeként leírt szöveg értelmezése. Szó nem volt saját osztályról, equals felüldefiniálásról vagy bármi egyéb ilyesmiről.
És most tényleg befejeztem.
Így elsőre.....
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Makulátlan PlayStation 5 lemezes kiadás + 2 játékkal, garanciával!
- AMD Ryzen 7 7700 - Új, 1 év garancia - Eladó!
- AMD Ryzen 7 5700X - Új, 3 év garancia - Eladó!
- Dell G3 3500 Gamer laptop szép állapotban dobozával. (i7 10750h, Gtx 1660ti, 16GB ram, 1TB ssd)
- Asus F15 FX516PR 15.6" FHD IPS i7-11370H RTX 3070 16GB 1TB NVMe magyar vbill gar
- LG 65C4 - 65" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - 1000 Nits
- Bomba ár! Fujitsu LifeBook E754 - i5-4GEN I 8GB I 256SSD I 15,6" HD I HDMI I W10 I Garancia!
- BESZÁMÍTÁS! ASUS TUF Z390-PLUS GAMING alaplap garanciával hibátlan működéssel
- Bomba ár! HP Elitebook 850 G8 - i5-11GEN I 16GB I 256GB SSD I 15,6" FULLHD I Cam I W11 I Gari!
- Apple iPhone 13 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest