Hirdetés
- gban: Ingyen kellene, de tegnapra
- Szevam: ChatGPT: Bizonytalansági jelölés funkció bekapcsolása
- Parci: Milyen mosógépet vegyek?
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- potyautas: Levél gyermekemnek
- eBay-es kütyük kis pénzért
- localhost: Hatvan időegység. [Update 65]
- btz: Internet fejlesztés országosan!
Új hozzászólás Aktív témák
-
válasz
Aethelstone
#8756
üzenetére
Ezt hogy érted?
-
floatr
veterán
válasz
Aethelstone
#8744
üzenetére
Ezek az értelmes kérdések
a korábban említett tesztszerű kérdéssor meg az a hely, ahol droidokat keresnek. Szerintem régen rossz, ha egy munkaadó mostanában lexikális tudásra épít, nem pedig rendszerszemléletre. -
Orionk
senior tag
válasz
Aethelstone
#8739
üzenetére
Arra gondolsz, hogy túl könnyű lenne és nagyon nehéz lenne ez után a betanulási időszak?
Ez egyébként csak az 1. körös feladat lesz. Ez után lesz egy 2. kör, ahol komolyabb feladatokat kapok szerintem.
-
ToMmY_hun
senior tag
válasz
Aethelstone
#8739
üzenetére
Én ezzel nem értek egyet. Sok helyen ugyanaz a feladatsor van senior és junior mérnököknek, a különbség pedig annyi, hogy senior több feladatot tud jól megoldani. Szerinted mit kellene kérdezni egy juniortól, ha nem ilyesmiket?
-
Chesterfield
őstag
válasz
Aethelstone
#8734
üzenetére
Köszi, közben megoldottam a feladatomat másként.
De ha jól értem, olyan (egyszerű) megoldás nem létezik, ami magát a szeparátort is beteszi a tömb elemei közé. -
M_AND_Ms
veterán
válasz
Aethelstone
#8131
üzenetére
"A tranzakció a commit-tel lesz sikeres, ergó ebben az esetben kell visszaírni a változásokat."
Általános adatbázis működést feltételezve nem a COMMIT-nál kell kiírni a változásokat, hanem az utasítás végrehajtásakor egyből. A COMMIT-nál érvényre jutnak a már kiírt változások, vagyis a többi db session számára is elérhetők lesznek. Pl tudni kell olyat is, hogy vannak bizonyos adatbázis-kezelőkben olyan típusú objektumok, amik csak a COMMIT-ig tartalmazzák a beléjük írt adatot, és pont a COMMIT után tűnnek el onnét (pl Oracle-ben a global temporary táblák ). Ezeknél kifejezetten rosszul jönne, ha egy perzisztenciakezelő csak a COMMIT-nál írná ki a változásokat a DB-be.
"Mert egy close a commit nélkül eredménytelen elvileg"
Hogy egy close a COMMITnélkül mire megy? Ez JDBC függő, ill., ennek viselkedése szabályozható. Pl: Connection-ben az autoCommit : true / false -
peterszky
őstag
válasz
Aethelstone
#8105
üzenetére
Egy OPatch cucc halt meg, Windows alatt, mint kiderült, az egyik fajta windows linket (van link, junction, meg nem tudom még mi...) nem szerette.
-
válasz
Aethelstone
#8092
üzenetére

-
válasz
Aethelstone
#8086
üzenetére
linux. akkor használjam 8.1-es netbeanshez a debian jessie beépített jdk-ját?
$ java -version
java version "1.7.0_85"
OpenJDK Runtime Environment (IcedTea 2.6.1) (7u85-2.6.1-6+deb8u1)
OpenJDK 64-Bit Server VM (build 24.85-b03, mixed mode)kösz
-
kemkriszt98
tag
válasz
Aethelstone
#8081
üzenetére
OK, köszönöm a türelmet

-
kemkriszt98
tag
válasz
Aethelstone
#8079
üzenetére
Értem, szerencsére a szerver logika még nem túl bonyolult...
Viszont akkor is kellene 1 port ami még mindíg nem tudom, hogy mi legyen... Kicsit kezd aggasztani, hogy nem találok ilyen jellegű kérdést a neten... Valami elkerüli a figyelmem? -
válasz
Aethelstone
#8067
üzenetére
te kínálati oldalról nézed, az nng meg keresleti oldalról fogja nézni.
ahhoz, hogy egyetlen elgépelést ki tudjon javítani egy kommentben, ahhoz kell netbeans, verziókezelő, maven ismeret. ahhoz, hogy readonly módon elkezdhesse érdemben tanulmányozni a kódot, ahhoz kell full java meg ee ismeret is.interjúra egyébként nem árt alaposan átnézni a portáljukat is, meg utánanézni, hogy mi az a connected autó és gps. az állás jó eséllyel a portál mögötti cuccok fejlesztése (ami nem csak a portálmotort és a webshop fejlesztése, hanem egy rakás más cucc is).
-
jetarko
csendes tag
válasz
Aethelstone
#8061
üzenetére
Mert akkor szerinted hol a határ? Hány évtől nem junior valaki java területen?
Mert szerintem semmi extra nincs a leírtakban, sőt még hiányoznak dolgok.
Meg ma már elég ritka csak az hogy java. Én is java fejlesztő címszó alatt lettem felvéve és js-t is használni kell rendesen. Ahogy nézem álláshirdetéseket olyan, hogy valaki csak java vagy csak frontend fejlesztő már elég ritka, inkább mindenhez kell valamit érteni és nem kardodba dőlni, ha netán kapsz egy kis frontend feladatot is vmi mai fw-ben -
válasz
Aethelstone
#7999
üzenetére
köszi, most volt időm foglalkozni vele
-
F1rstK1nq
aktív tag
válasz
Aethelstone
#8032
üzenetére
Így van, én is erre szántam a "még legmagasabb értelmes interfészt megadni" részemet, de lehet a tiéd jobb megfogalmazás.

-
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.
-
pvt.peter
őstag
válasz
Aethelstone
#8028
üzenetére
jogos észrevétel, elnézést a megfogalmazásért

és mi a magyarázat erre?
kevesebb overhead?
egyszerűbb, kevesebb bájtkód jön létre?
vagy esetleg jobban tud optimalizálni a VM? -
floatr
veterán
válasz
Aethelstone
#8001
üzenetére
Rendben

A mi esetünk annyiban speciális, hogy a DBA megszabta h mivel exportálhatunk.
(#8006) mobal Ezeket a hipszter dolgokat sosem szerettem
-
ToMmY_hun
senior tag
válasz
Aethelstone
#7997
üzenetére
Ez nem egyéni preferencia kérdése. Letárolva jobban olvasható, gyorsabb és szebb. Nincs miről beszélni.
-
M_AND_Ms
veterán
válasz
Aethelstone
#8005
üzenetére
Nevetni fogsz! Én beszéltem (évek) óta programozóval, aki teljes természetességgel mondta, nem szokott debugolni.
-
Sk8erPeter
nagyúr
válasz
Aethelstone
#8003
üzenetére
Viszont gyorsabbá teszi a debuggolást, ha változóba van kirakva, amikor odateszed a breakpöttyöt.
(Már szinte várom előre is a "dehülyevagy-hádeménemdebuggolsz rendesen, az Expressions fület használva, meg mé' nem használod a Ctrl+Shift+D-t Eclipse-ben, a megfelelő kifejezést kijelölve", meg hasonló okosságokat.
) -
Szmeby
tag
válasz
Aethelstone
#7997
üzenetére
Bocs, hogy én is felhozom, csak szeretnék rávilágítani a különbségre.
Az, hogy mindkét esetben láncban hívogatjuk a metódusokat, csak egy aspektusa a problémának. Valaki korábban említette, hogy pusztán a metódusok láncban hívása az un. "Law of Demeter" megsértése. Én ugyan nem nevezném törvénynek, de nem tényleg ajánlanám. Annak ellenére, hogy nekem is sokszor rááll a kezem.

Viszont a builder pattern ettől gyökeresen különbözik, és ezért "veszélytelen". Leginkább abban tér el, hogy a Builder mindig ugyanazon az objektumon dolgozik, a metódusok ugyanazzal a típussal térnek vissza. Egy nem builder esetén viszont ez korántsincs így, a hívó nem ismeri, nem ismerheti azt az osztályt, amit egy metódushívás visszaad, amit pedig annak a metódusa adna vissza, azt mégúgyse, és így tovább. Persze lehet szeretni, meg használni, legrosszabb esetben megtanulod a magad kárán.
-
floatr
veterán
válasz
Aethelstone
#7988
üzenetére
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...
-
Sk8erPeter
nagyúr
válasz
Aethelstone
#7995
üzenetére
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...
![;]](//cdn.rios.hu/dl/s/v1.gif)
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. -
Sk8erPeter
nagyúr
válasz
Aethelstone
#7990
üzenetére
Most kicsit nehéz eldönteni, hogy tényleg nem érted, miről vakerászok, vagy csak szívatsz.

-
fatal`
titán
válasz
Aethelstone
#7990
üzenetére
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.
-
Sk8erPeter
nagyúr
válasz
Aethelstone
#7962
üzenetére
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é'. -
floatr
veterán
válasz
Aethelstone
#7986
üzenetére
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.
-
floatr
veterán
válasz
Aethelstone
#7984
üzenetére
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.
-
pvt.peter
őstag
válasz
Aethelstone
#7981
üzenetére
hálistennek db kapcsolat nincs benne,
"egyszerű" objektumokon való műveletvégzést valósít meg minden komponens -
floatr
veterán
válasz
Aethelstone
#7979
üzenetére
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...
-
floatr
veterán
válasz
Aethelstone
#7971
üzenetére
Van nagyon jó hibernate performance oktatásunk, ha érdekel
![;]](//cdn.rios.hu/dl/s/v1.gif)
Ha egyszer ebben az életben még lesz valaha egy kis szabadidőm, akkor majd írok is róla. -
válasz
Aethelstone
#7972
üzenetére
- 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 ulValoszinu, hogy HDFS-sel fogok inditani, aztan majd meglatjuk.
-
válasz
Aethelstone
#7971
üzenetére
Értem, köszi. -
válasz
Aethelstone
#7968
üzenetére
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.
-
válasz
Aethelstone
#7965
üzenetére
OpenJPA a kiszemelt. Van jobb?
-
Aethelstone
addikt
válasz
Aethelstone
#7967
üzenetére
Úgy értem zfs+bsd+postgresql.
-
válasz
Aethelstone
#7943
üzenetére
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.
-
PazsitZ
addikt
válasz
Aethelstone
#7958
üzenetére
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.
-
Sk8erPeter
nagyúr
válasz
Aethelstone
#7956
üzenetére
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.)
-
#39560925
törölt tag
válasz
Aethelstone
#7948
üzenetére
nincs, de érdeklődöm. habár el se olvastam rendesen a kérdését, utólag elolvasva tényleg felesleg volt feltennem.
-
Lortech
addikt
válasz
Aethelstone
#7943
üzenetére
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. -
válasz
Aethelstone
#7923
üzenetére
miért tomcat?
-
#39560925
törölt tag
válasz
Aethelstone
#7937
üzenetére
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.
-
M_AND_Ms
veterán
válasz
Aethelstone
#7931
üzenetére
"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
válasz
Aethelstone
#7931
üzenetére
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?
-
#39560925
törölt tag
válasz
Aethelstone
#7926
üzenetére
szerintem 1.8 kéne legyen a minimum minden új projektnél.
-
#39560925
törölt tag
válasz
Aethelstone
#7923
üzenetére
1.7????
-
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 -
floatr
veterán
válasz
Aethelstone
#7798
üzenetére
Nem tudom másol hogyan kalkulálnak a betanulási fázissal, meg a többivel. Ha full kezdőt vesznek fel és betanitják ~ fél év alatt, akkor sokszor jobban jön ki a ktgkeret, mintha egy elvileg kézett embert vennének fel. A másik része meg az, hogy itt is van egy szűrő, amin ha átmegy, akkor jobban jár mindenki egy jól kiképzett emberrel, mint évekig szívni egy problémás tudású fejlesztő kezét fogva.
-
WonderCSabo
félisten
válasz
Aethelstone
#7759
üzenetére
Tudom. A társai alatt a JetBrains termékeket értettem, ha félreérthető volt.
Oppenheimer: Jogos. Mondjuk az egyetemeken mindenhol (itthon) SWT-t tanítanak, mi is. Nem túl elterjedt cucc a JavaFX.
-
#39560925
törölt tag
válasz
Aethelstone
#7714
üzenetére
persze, de az az IDE kezelésben még csak a level 1.

-
RexpecT
addikt
válasz
Aethelstone
#7661
üzenetére
Igen Oracle az adatbazis. Köszi megnézem
. -
F1rstK1nq
aktív tag
válasz
Aethelstone
#7656
üzenetére
Természetesen meglehet és teljesen jó az a megoldás is, csak az hivatalosan nem típusbiztos és nem refactor barát.
(én idea zom az is megtudja amúgy
)@ ComponentScan(basePackages={"package1", "package2"})
Kinek mi? Én egyszerűbbnek tartom a marker interfacet.

Egy elméleti példával be is bizonyítom, hogy miért:
-van egy top level package-ed (hu.somebody.main)
-ez alatt lesz 3 package-ed ahol a component-ek leszek definialva:
(hu.somebody.main.package1, hu.somebody.main.package2, hu.somebody.main.package3)
-a marker interface-t beteszed a top level pakage-edbe:package hu.somebody.main;
public interface Application {}Ez az alap felállás. Akkor a 2 opció scannelésre:
@Configuration
@ComponentScan(basePackageClasses = Application.class)
class ApplicationConfig {}vagy
@Configuration
@ComponentScan(basePackages={"hu.somebody.main.package1", "hu.somebody.main.package2", "hu.somebody.main.package3"})
class ApplicationConfig {}Melyik tűnik egyszerűbbnek?

-
Sk8erPeter
nagyúr
válasz
Aethelstone
#7595
üzenetére
Szerintem a kolléga szándékosan trollkodott.
(legjobb flamewar-keltő megjegyzések az ilyenek, amikor valaki komolyan veszi
)Hogy a cikkhez is szóljak:
"It started when Oracle sued Google and accused it of infringing on some of its application programming interfaces, including their names (such as the name "max" for the maximum function)."
Az Oracle érintett emberei most megsimogathatják a saját idióta kis buksijukat. -
#39560925
törölt tag
válasz
Aethelstone
#7593
üzenetére
a Java halott
-
Lortech
addikt
válasz
Aethelstone
#7564
üzenetére
Ha windows service-re gondolsz, akkor ugye a java alkalmazásodhoz kell egy natív exe wrapper, ami scm-hez illeszkedik, erre vannak kész megoldások, vagy te is készíthetsz ilyen wrappert, ami vagy sima processz indítással vagy akár parancssoron keresztül indítja a java alkalmazást. A kész megoldások, amikkel én dolgoztam, lehetőséget adnak java path beállításra, hogy egy előre definiált helyen lévő jvm-mel indíthasd az alkalmazást. De írtam már olyan wrappert is, ami csak egy batchet indít (ami indítja a javát), ilyenkor természetesen annak a felhasználónak a környezeti változóival (including PATH) fog futni, aki a service indításhoz be van állítva. Ergo az amit írsz, bizonyos esetben igaz lehet - pl. ha a service-t futtató felhasználónak nincs a PATH környezeti változójában java elérési út (a \system-en kívül), vagy a natív wrapper a \system-ben lévő java.exe-hez ragaszkodik -, de nem szükségszerűen van így.
-
bucsupeti
senior tag
válasz
Aethelstone
#7517
üzenetére
exchange levelezést szeretném elérni. küldeni nem akarok, csak olvasni a postafiókot.
A lényeg hogy figyleni szeretném hogy jött-e levél, és ha jött akkor a levél body-ját le szeretném menteni fájlba. -
válasz
Aethelstone
#7508
üzenetére
Ezt nem igazán értem.
Az IDEA nem hajlandó buildelni egy projektet, ha nem engedem ki a tűzfalon...
-
floatr
veterán
válasz
Aethelstone
#7459
üzenetére
Szerintem az assembly tökre elfogadható. Láttál már forth kódot?

-
válasz
Aethelstone
#7456
üzenetére
Na de Javában MINDEN pointer

(Nálam a C az assembly után jött, én akkor azt nem értettem, hogy mit nem lehet nem érteni a pointereken
) -
válasz
Aethelstone
#7451
üzenetére
"Szerintem kifejezetten könnyen tanulható a C++."
Höhö. (A Java se az, hogy ontopik maradjak.)
-
floatr
veterán
válasz
Aethelstone
#7451
üzenetére
Uhh. A fősulin egy félévig gyúrták az évfolyam agyát C++-ra. A zemberek 90%-a meg sem értette, hogy mi ez az egész. Azok tudták követni, akiknek volt megfelelő előképzettsége (intézményesített/autodidakta)
-
floatr
veterán
válasz
Aethelstone
#7444
üzenetére
Teljesen mindegy milyen nyelvet választanak hozzá. Csak nem mindegy, hogy hogyan kezdik el. Pascal-t és C-t elkezdeni elég könnyű, a C++ és Java viszont kicsit nagyobb előkészületet igényel. Lehet h páran felhördülnek, de én akár JS-t is el tudnék képzelni első nyelvnek ilyen feladatokra. HTML-es babrálásokat már általánosban is tanulgatnak.
-
Gyuri16
senior tag
válasz
Aethelstone
#7386
üzenetére
hat akkor nevetni fogsz: nalunk a kod legnagyobb resze meg 5-os es egyelore nem lehet updatelni. szerencsere utobbi evben en nagyreszt egy uj projekten dolgozok amit 8-assal kezdtunk, de aztan vissza kellett lepni 7-esre (mert JET nem tamogatja meg a 8-ast)
-
M_AND_Ms
veterán
válasz
Aethelstone
#7372
üzenetére
Köszönöm példát, bár ott az egyik egy primitív, amelynél ugye alapból nincs értelme semmilyen függvény meghívásáról beszélni. A példádban amúgy outboxing történik, vagyis a Longból veszi ki automatikusan a longot és így már primitívek között persze, hogy csak a == működik.
Más. Látom csak nekiálltál alpári stílusban írni. Jelzem amiről beszélünk az nem offtopic, még akkor sem, ha te mindenképp azt hajtogatod, hogy én "kurvára szétoffolom". Sajnálom, ha egy szakmai topikban nem vagy képes megmaradni a szakmaiságon belül, sőt kifejezetten zavar téged.
-
M_AND_Ms
veterán
válasz
Aethelstone
#7368
üzenetére
Azért, hogy okosodjunk, mutass egy példát - de most komolyan, hisz ez itt ontopic
-
floatr
veterán
válasz
Aethelstone
#7365
üzenetére
Basszus ilyen nyakatekert példákon veszem észre, hogy mennyire sokat kell ahhoz tanulni, hogy készség szintjén tudja ezeket a dolgokat valaki. Ha jobban belegondolok a kollégám is hónapok óta képzi a juniorokat, és most értek el odáig, hogy servlet...
-
M_AND_Ms
veterán
válasz
Aethelstone
#7363
üzenetére
"Az autoboxingos osztályoknál pl. szükségtelen az equals, mivel gyárilag meg van írva, hogy pl. a Long i-nél az i.longValue()-t hasonlítja a megadott longhoz....."
Ezt nem értem.Ha két Long-ot == jellel akarsz összehasonlítani, akkor megint csak a két referenciát vizsgálod. Amúgy persze, hogy a Long equals függvénye úgy gondolkodik, hogy a longValue()-t veti össze a a saját value mezőjével De ez nem az autoboxingból jön, hanem ez is ugyanaz a logika, mint amit már leírtam (ahogy a String-nél meg a saját value[]-ból dolgozik)."Persze, saját osztályoknál nyilván az equals a célszerű és a követendő, de itt konkrétan a String-ről volt szó és itt mindenképpen az equals kell."
Mindig equals kell, fogadd el!(#7362) Ursache
Mivel osztályokról beszélünk, ezért nem kell egyértelműsíteni, hogy csak a nem primitíveknél van így. Az osztály eleve NEM primitív. -
floatr
veterán
válasz
Aethelstone
#7357
üzenetére
Vagy építene egy kontextust, benne map-be rendezett handlerekkel, sakko nincsen ilyen melléfogás

-
M_AND_Ms
veterán
válasz
Aethelstone
#7357
üzenetére
"Java-ban a Stringeket equals-sal hasonlítunk össze, nem ==."
Ez kicsit sántít ill. félrevezető.
Java-ban a == -nal nem a két objektumot hasonlítjuk össze, hanem a két referenciát. Vagyis akkor kapunk igazat ha mindkettő ugyanarra az objektumpéldányra mutat.
Az equals-nél pedig meghívjuk az adott objektumpéldány equals függvényét, ami az objektumra jellemző összehasonlítást végzi és megmondja, hogy a paraméterként megadott másik objektumpéldányt azonosnak tekintjük-e, vagy sem. Ebben az equals-ben lehet megírni az objektumra jellemző logikát, ami az azonosságot kimondja. String-nél természetesen ezt már megírták és akkor mondja azonosnak, ha pontosan ugyanaz a a karakterliterál van mindkét String példányban.
De pl. írhatok az Alma osztályomba egy saját equals függvényt, ami az én logikám szerint akkor ad igazat ha a méret, a szín és a súly tulajdonságai megegyeznek a két összehasonlítandó Alma osztályból létrehozott példánynálTehát, NEM CSAK Stringnél kell az equals a == helyett az azonosság eldöntésére, hanem minden osztály példányánál.
-
PumpkinSeed
addikt
válasz
Aethelstone
#7357
üzenetére
El is felejtettem
Köszönöm az útmutatást. -
norbert1998
nagyúr
válasz
Aethelstone
#7350
üzenetére
Most mit lehet tenni? Ezúttal éppen ez a feladat
-
WonderCSabo
félisten
válasz
Aethelstone
#7294
üzenetére
Ez mondjuk az IDE consoljára nem biztos, hogy hatássas lesz. Rondábbnak tűnő, de platformfüggetlen megoldás jó sok új sort kiírni.
norbert1998: Ha System.err -re írsz System.out helyett azt remélhetőleg pirossal írja.
-
norbert1998
nagyúr
válasz
Aethelstone
#7294
üzenetére
Köszi, holnap megnézem

-
floatr
veterán
válasz
Aethelstone
#7282
üzenetére
Bár nem mai, de ha már igazi programozó: [link]

-
#39560925
törölt tag
válasz
Aethelstone
#7274
üzenetére
Durvának hangzik, mert leírva, hogy label, az ember az assemblyre asszociál, de sima for-ból kiugrásra is oda lehet tenni, hogy még egyértelműbb legyen az amúgy is triviális ciklustörés, amikor valaki ránéz.
-
floatr
veterán
válasz
Aethelstone
#7272
üzenetére
Én inkább vagyok híve egy olyan megoldásnak, ahol inkább a ciklus feltételeinek kiértékelésénél próbálod megoldani a kilépést. Nyilván lesz olyan eset, amikor nagyon nyakatekert lenne break nélkül, de sokszor csak rontja a support-ot.
-
#39560925
törölt tag
válasz
Aethelstone
#7272
üzenetére
szerintem is inkább egy break, mint még 1 feltétel a ciklusfejlécben. főleg, hogy javában lehet labelt tenni, úgy pláne nem olvashatatlan szerintem.
-
floatr
veterán
válasz
Aethelstone
#7232
üzenetére
Amit eddig láttam, az alapján azt tudom mondani, hogy amint a projekt megéri a telepítési fázist kiderül, hogy bármilyen generált kódról is van szó, a fejlesztők csak becsapják magukat, hogy majd sokkal kevesebbet kell kódolni. Hihetetlenül észnél kell lenni, mert elég egy legyintés, hogy ez így majdnem jó, és oda minden előnye a generált cuccoknak. Ezt a legtöbben nem is látják, mert valamiért nem foglalkoznak a release utáni életciklussal. Ugyanez igaz a DTO-ra is, hogy leszámítva azt az 1%-ot, amikor tényleg kellene, csak felesleges karbantartási köröket, és kockázati tényezőt vezetnek be a projektbe. Az ember hajlamos elsiklani olyan problémák felett, amiket nem lát rögtön, mert kényelmes nem szembesülni vele.
Hibernate-tel már odáig jutottunk, hogy az összes előnye leredukálódott a bean alapú row mappingre, és az öröklődés kezelésére. Nem 1% az, amit kézimunkával kell megoldani, de erről már a múltkor beszéltünk a lazy-eager-dto témában.
Nálunk a legtöbb szívás a GWT-vel a frontend hibái miatt voltak. Még csak nem is a generált kód és a backend közti szakadék miatt. A frontendesek annyira sokat dolgoztak a minimális hibákon, hogy a végeredmény az lett, hogy vagy sikerült megalkudni a megrendelővel, vagy addig hegesztették böngészőnként a dolgot, hogy az összköltsége elszaladt egy bootstrap/foundation alapokra épülő jquery/sencha kliens + SOA backend mellett. Sajnos vagy sem, de eddig mindig ide lyukadtunk ki, akármi is volt a kiindulási alap.
-
floatr
veterán
válasz
Aethelstone
#7228
üzenetére
Hát, bárhogy is nézzük a végeredmény ugyanaz, hogy kevesen tudnak jól bánni vele (már he lehet ilyenről beszélni
)Ilyen dolgokkal már sokszor találkoztunk, hogy jó valami, de senki nem tudja használni. Ergo, akkor mégsem annyira jó valami. Lehet h túl komplex, túl nagy a betanulási igénye, akármi... Arról mindenesetre meg vagyok győződve, hogy egy olyan team, ahol megfelelően le vannak osztva a szerepkörök, hatékonyabb tud lenni egy csak javas GWT-s csapatnál, ahol könnyen becsapják magukat az emberek, hogy nem kell frontendes.
-
floatr
veterán
válasz
Aethelstone
#7224
üzenetére
Figy, én eddig azt láttam, hogy valaki vagy az egyikhez ért, vagy a másikhoz. Az már fehér holló kategória, aki valamennyire konyít mindkettőhöz, és ez nem csak hazai jelenség. Irtózatosan híg a szakma, és nem biztos hogy csak a képzéssel van a baj (bár a kollégám, aki elég húzós tanfolyamokat tart, erről meg van győződve). A legtöbb gyíkarc meg sem érti, hogy mitől gurul az egész, vagy ha elcsípi, akkor menekül tőle, mert a JS nem elég tudományos. Erre mondom, hogy kliens oldali technológiát, csak arra megfelelő emberekkel szabad gyártani, és ezek az emberek nem feltétlenül kell h backendet is tudjanak gyártani. Ezek a hibrid megoldások olyanok, mint a 4 évszakos gumi.
Vagy használjanak jfx-et, az tudományosabbabb. (bár az is halódik elfelé)
Szerk.: amit generálásképpen említettél, az metaadatokat/leírókat generál, nem kódot.
-
M_AND_Ms
veterán
válasz
Aethelstone
#7220
üzenetére
"pagert"? Mármint egy lapozós listát? Laponként 4-5K rekorddal?
Mert ugye a lapozósnak pont az a lényege, hogy a 4-5K rekordból mindig csak mondjuk 50-et jelenít meg. Az meg nem egy mennyiség -
floatr
veterán
válasz
Aethelstone
#7218
üzenetére
Ezért mondom h dead end. Csak olyan frameworknek van értelme, ami nem új kódot generál, egyébként átveri a saját fejlesztőit is, mert kiveszi a kezükből a kontrollt.
-
M_AND_Ms
veterán
válasz
Aethelstone
#7218
üzenetére
Máris megkérdem, mi értelme van 4-5K rekordot kirakni a képernyőre. Ki az aki azzal bármit is kezd? Görgeti fel-s-alá, mást nem nagyon tud vele kezdeni.
-
floatr
veterán
válasz
Aethelstone
#7215
üzenetére
Szerintem a GWT-t is hozzáadhatod a dead end kategóriához

Sok technológiával volt már dolgom, de az ügyviteli felhasználásnál, és az újabb fajta webes alkalmazásoknál a SOA-jellegű backend + "natívan" fejlesztett erős kliens volt a leghatékonyabb. Az csak plusz, ha a kliens oldal olyan framework-ökre épít, amivel napok alatt lefejleszted azt, amihez MVC-vel hónapok munkája kellett.
(#7216) Oppenheimer Ha valami beadandó cuccról/szakdolgozatról van szó, akkor én nem erőltetném a finomságokat
Nekem sem tudták értékelni, amikor én agyaltam rajta. Diplomamunkaként egy GIS alapú facility management megvalósíthatósági tanulmányt adtam le, ami még ráadásul az egyetem munkáját is megkönnyítette volna, és egy rakat diákot rá lehetett volna robbantani a témára szervezetten, mire a vizsgabiztos csak annyit kérdezett, hogy mi ez az egész 
-
#39560925
törölt tag
válasz
Aethelstone
#7203
üzenetére
Már megírtam a DTO konverziót, nagyon szép lett.
Ezt azért elrakom könyvjelzőkbe, hátha kell még. -
M_AND_Ms
veterán
válasz
Aethelstone
#7164
üzenetére
Nem is ellenvetésként írtam.
-
M_AND_Ms
veterán
válasz
Aethelstone
#7161
üzenetére
Az épitőipari iskolában a diákok két méter hosszú és egy méter magas téglafalakat építgetnek, majd elbontják azokat. Tök értelmetlen!
Mégis, milyen példákon tanuljanak a diákok? Egy mintapélda mégse lehet, egy nagyvállalati ügyviteli rendszer. Ezek a példák a gondolkodást és annak adott nyelven történő megvalósítását tanítjak, ez a konkrét példa is pont ilyen. Szépen látszik, hogy egy ciklus az egész, melynek magjában változók értékadása, majd azok következő ciklusbeli felhasználása történik. Szép, frappáns feladat.
-
Ursache
senior tag
válasz
Aethelstone
#7159
üzenetére
Ez minősítheti a NIK-et? ELTE-IK után pedig oda akartam/akarok menni, mondjuk csak a referencia NIK-es... + a tárgyat úgy is beszámíttatnám...
Továbbá ha valamit shell-ben meg tudok oldani 2 sorban, akkor nem kezdem el C#-ban megírni.
Az jó nagy marhaság lenne, ha numerikus analízist java-ban erőltetik

-
Sk8erPeter
nagyúr
válasz
Aethelstone
#7138
üzenetére
Így van.
De vágod, nem nekem kell magyarázni, pont emiatt szóltam a kollégának. 
-
válasz
Aethelstone
#7075
üzenetére
Nekem elojottek a kvaterniok, PCA, SVD, Bayes, mittudomen. (Pedig egy jo ideje nem kutatasban dolgozom.)
-
floatr
veterán
válasz
Aethelstone
#7039
üzenetére
(#7040) Sk8erPeter
10+ évvel ezelőtt váltottam netbeansről eclipse-re céges policy miatt. Az megkönnyebbülés volt. Ez alatt a pár hét alatt alatt egész egyszerűen semmi sem működött úgy ahogy kellett volna. Kiszámíthatatlan volt, néha működött valami, néha nem. Egy maven projekt összeállításánál a spring lib függőségek verzióit összekavarta. A projektben a beágyazott javadb-t néha nem tudta elindítani. Néha nem fordított... nem egy production ready dolog..Nem mondom h az eclipse tökéletes lenne, de jobb. Netbeansben vannak jópofa "varázslások", amik marhajók, ha az ember nulláról tapasztalat nélkül kezd hozzá valamihez. Cserébe viszont instabil.
-
floatr
veterán
válasz
Aethelstone
#7037
üzenetére
Most februárban egy hónapig használnom kellett a netbeans-t... hát basszus, megőszültem tőle. Nemtom kinek írják ezt, de nem nekem való.
-
floatr
veterán
válasz
Aethelstone
#7033
üzenetére
Két lépés vissza?

-
thon73
tag
válasz
Aethelstone
#6988
üzenetére
Konkrétan, használom, azért kellett felfedeznem

Egy speciális szöveget (egyfajta programnyelvet) szeretne feldolgozni a program. A beolvasás minden adat-elemnél közel azonos, csak éppen pl. a String String-ként, a numerikus érték Long-ként érkezik. Az érkező adatelemekről egyébként elég sok mindent tudok, pl. azt is, hogy a numerikusak milyen pontosságúak kell legyenek. Nem csupán java értelemben, hanem pl. ha egy szín jön, az unsigned 32 bittel írható le (ami egyébként belefér egy signed int-be).
Az eredeti megvalósítás ellenőrizte a pontosságot, aztán visszaadott egy - a kívánt pontosságnak megfelelő - Long értéket. Csakhogy, egyszerűbb ha pl. pont a szineknél kapásból egy Integer pontosságú értéket ad vissza, mert akkor nem kell tovább bonyolítani a dolgot az adatot tároló változók szintjén.
Egyébként az egész teljesen prímán működött, amíg a különböző típusokat különböző metódusok szedték elő. Viszont egy közös Object-tel egyetlen átlátható metódusra egyszerűsödött az egész - éppen csak ide-oda kellett volna konvertálnom az adatokat. Na, ez nem ment. Utána meg már az érdeklődés is hajtott.
Bocs, ez kicsit leegyszerűsítette a problémát, de remélem, érthető maradt.
(Mivel nem vagyok profi programozó, azt sem igazán tudtam, hogy mire keressek a googliban. Végül aztán sikerült megtalálni.)
-
PumpkinSeed
addikt
válasz
Aethelstone
#6974
üzenetére
Gyakorlatban itt a kód, hogy lehet ezeket a referenciákat megoldani? Még nem halottam róluk.
-
válasz
Aethelstone
#6935
üzenetére
Termeszetesen arra a helyzetre gondolok, amikor az adott tipust nem tudod megvaltoztatni, mert pl. egy 3rd party libraryben van. Ugye ez az un. 'expression problem', azaz ha van
- N tipusod
- es M funkcionalitasod (fuggenyed)
(tehat van egy N*M-es matrixod, aminek minden elemet ki kell toltened).. akkor a klasszikus OOP nyelvekben konnyu uj tipust hozzaadni (barmikor implementalhatsz egy interfeszt), de nehez uj fuggvenyt hozzaadni (egy adott tipust nem biztos, hogy meg tudsz valtoztatni ugy, hogy implementaljon egy interfeszt). FP nyelvekben konnyu uj funkciot hozzaadni, de nehez uj tipust hozzaadni (mert meg kell valtoztani az osszes letezo fuggvenyt). Aztan persze van nyelv, ahol mindketto egyszeru.
@Wondercsabo: okes, csak megemlitettem.
-
WonderCSabo
félisten
válasz
Aethelstone
#6930
üzenetére
Nem is akarok.
-
WonderCSabo
félisten
válasz
Aethelstone
#6927
üzenetére
Kivéve természetesen a primitív típusokat, azokat a generikusok nem támogatják

De szerencsére van autoboxing, emiatt ugyanúgy fog működni, ha primitíveket adsz át neki.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Milyen videókártyát?
- exHWSW - Értünk mindenhez IS
- LEGO klub
- One otthoni szolgáltatások (TV, internet, telefon)
- Azonnali fáradt gőzös kérdések órája
- PlayStation 5
- Kormányok / autós szimulátorok topikja
- Lexus, Toyota topik
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- További aktív témák...
- Xiaomi 14T 12/256GB, Újszerű, Kártyafüggetlen, Töltővel, 1 Év Garanciával!
- Logitech G51 5.1 hangrendszer / megkimélt állapot / tökéletesen működik / szép hangzás
- Dell Latitude 5570- 15,6" - I7 6820HQ 16Gb - Radeon 8670
- ZBook Fury 15 G7 15.6" FHD IPS i7-10850H RTX 3000 32GB 1TB NVMe magyar vbill ujjlolv IR kam gar
- T14 Gen1 27% 14" FHD IPS Ryzen 5 PRO 4650U 16GB 512GB NVMe új akku gar
- Apple iPhone 16 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- HATALMAS AKCIÓK! GARANCIA, SZÁMLA - Windows 10 11, Office 2016 2019 2021,2024, vírusírtók, VPN
- Nikon D3500, Tükörreflexes (DSLR) fényképező
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9700X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Apple iPhone 14 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Laptopműhely Bt.
Város: Budapest
a korábban említett tesztszerű kérdéssor meg az a hely, ahol droidokat keresnek. Szerintem régen rossz, ha egy munkaadó mostanában lexikális tudásra épít, nem pedig rendszerszemléletre.




(Már szinte várom előre is a "dehülyevagy-hádeménemdebuggolsz rendesen, az Expressions fület használva, meg mé' nem használod a Ctrl+Shift+D-t Eclipse-ben, a megfelelő kifejezést kijelölve", meg hasonló okosságokat.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
.
(én idea zom az is megtudja amúgy 
(legjobb flamewar-keltő megjegyzések az ilyenek, amikor valaki komolyan veszi




