- Hamarosan megkezdődik a nubia 2,8K-s táblagépének szállítása
- Barátokká váltak az eddig rivális AI-óriások
- ASUS blog: Ideális olcsó utazós gép lett az új Vivobook S14
- Az Aura Displays hordozható monitorhármasa jól felturbózhatja a produktivitást
- Dual Mode-os IPS monitorral adott magáról életjelet a Gigabyte
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Everest / AIDA64 topik
- Azonnali alaplapos kérdések órája
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- A Microsoft átépítette a ROG Ally-t
- SSD kibeszélő
- TCL LCD és LED TV-k
- Milyen belső merevlemezt vegyek?
- Épített vízhűtés (nem kompakt) topic
- Milyen széket vegyek?
Új hozzászólás Aktív témák
-
togvau
senior tag
válasz
M_AND_Ms
#11271
üzenetére
projekt összehasonlításra a Meld-et találtam közbe, annak már nem voltak hamis találatai.
Most a nyomorék projektben, bigdecimmal szenvedek. Vaadinos felület, a numberfieldnél ,-re van állítva a decimal separator, és a ,-t is veszi tizedesvesszőnek ha írok be valamit.
De fordított iránynál, amikor a mezőt állítja be a kód, .-ot rak tizedesvesszőnek.
pl így állítja be: mennyisegMe3.setValue(me3.doubleValue());
Pont jelenik meg. Próbálkoztam locale-t is beállítani, semmi hatás. -
Szmeby
tag
válasz
M_AND_Ms
#10742
üzenetére
Értelek, egy 20 éves tapasztalattal rendelkező jelentkezőnél valóban béna dolog a kódminőség felől érdeklődni, tiszta sor. Ezer ennél relevánsabb kérdést is feltehetnének. Ugyan korrigálhatnám a neked feltett kérdésemet úgy, hogy mit válaszolnál a kérdésre akkor, ha junior lennél egy junior pozira, de érzem, hogy a válaszod ugyanaz lenne.
Nekem nincs ennyi év a hátam mögött, de úgy vélem 20 éves múlttal sem feltétlenül sértődnék meg egy ilyen kérdésen, szerintem ha ez érdekli az interjúztatót a legjobban, akkor szíve joga rákérdezni. Nyilván annak is tudatában van a HR (ha meg nincs akkor így járt), hogy egy ilyen kérdés feltevése milyen színben tünteti fel őket. Szerencsére az állásinterjún a felvételizőnek is van lehetősége arról beszélgetni, amiről konkrétan ő szeretne, és én jelöltként is ugyanúgy elvárom a felvételiztetőtől, hogy készséggel válaszoljon a kérdésemre, mint fordított helyzetben. Nem kellemes, amikor megítélik az embert a feltett kérdése alapján. De legalább hamar kiderül, hogy nincs meg az összhang, próbaidő sem kell ennek a megállapításához.
Talán azért ez a véleménykülönbség, mert sokat szívtam legacy kóddal, és sokkal jobban megérint a kódminőség (hiánya), mint másokat. És mivel eddig szinte minden kollégámmal jól kijöttem, annyira nem szokott érdekelni, mennyire jól tudok velük együtt dolgozni... eddig mindig sikerült jól együtt dolgoznunk. Esetedben meg talán máshol vannak a hangsúlyos pontok.
Ez az oka annak is hogy ráugrottam a hozzászólásodra, mert mérhetetlenül sajnálatosnak tartom, hogy a menedzserek mellett sok fejlesztő is tesz a minőségre (szinte lényegtelen összetevőnek tartják), és nem látják, hogy ezzel a saját vagy sorstársaik életét teszik pokollá hosszú távon. Azt hiszem a válaszaimmal igazából csak keresem a megerősítést, hogy valóban az a jó irány, ha a határidőt, a rövid távú sikereket tartja az ember szem előtt. Egyelőre nem sikerült meggyőznöm vagy meggyőzetnem magam, de igyekszem.
----
PeachMan:
Hogy ON is legyek, nálam a model az entitás réteget jelenti - vagy perzisztens réteget, ahogy te fogalmazol. POJOk, amelyek már jávául íródtak, de közvetlenül a DB-be mentjük őket és DB-ből töltjük fel őket. Az ORM akítvan használja őket, lévén ők képezik az O-t az ORM-ben.
A DTO (Data Transfer Object) pedig adatok továbbításáért felel a komponensek között, ez jellemzően magasabb rétegekben jelenik meg (ha a perzisztens réteg van alul és a view felül).Hogy mennyire szép elfelejteni a DTO-kat és mindenhol csak a modelt használni, nos, szerintem ez komplexitás kérdése. Egy szép világban nem lenne szükség DTO-ra, mert minek lekopizni valamit pusztán azért, hogy 2 service beszélgetni tudjon egymással. De van egy rakás oka, amiért mégis van létjogosultsága.
Lehet technológiai oka, mondjuk az ORM meg tud zavarodni, ha egy entitásban több collection is van, DTO-k bevezetése jó workaround tud lenni. Te is említetted, hogy a view-nak nincs szüksége minden mezőre, ez is egy valid ok. Főleg akkor, ha nemcsak nincs szüksége, hanem egyenesen tilos egy view-nak látnia minden adatot. Lehet ok a sebesség optimalizálás. Ha egy view-nak csak 1-2 mező kell egy 20 oszlopos táblából, nagyon nem mindegy, hogy mind a 20 mezőt áttolod-e egy microservice-ből a másikba, vagy csak a szükségeseket. Egy DTO-t létre lehet hozni azzal a 2 szükséges mezővel és azt passzolgatni. Az sem mindegy, hogy egy entitásban a kapcsolódó táblák adatai is feltöltésre kerülnek vagy sem, és erre a view-nak szüksége van-e vagy sem. Van, hogy az ORM-et megkerülve jpql vagy akár natív sql végrehajtásával kell felszívni bizonyos adatokat, mert annyira tetü lassú lenne máskülönben, hogy a user megunja az életét. Ez már egy optimalizációs indok lehet, és nem is a fejlesztés legelején kell erről gondolkodni, hanem a végén, de akkor marha nehéz lesz átállni DTO-ra, ha eddig végig az entitásokat passzolgattuk a komponensek között.
Gondolom vannak érvek a model használata mellett is, de most nem jut eszembe ilyen, és biztosan jön valaki, aki arról is tud mesélni. Ja igen, az ORM is nyújthat megoldásokat az általam fentebb felvetett indokokra, csak nem ismerem annyira mélyen őket, hogy mindegyikre tudnék mondani valami dögös annotációt.
DTO-t használni nekem könnyebbség. Nagyobb rugalmasságot ad. Ha változik a model, nem feltétlenül kell a service rétegen keresztülverni a változásokat pl. -
Szmeby
tag
válasz
M_AND_Ms
#10740
üzenetére
Hmm. Azt hiszem, te többet láttál bele a kérésbe, mint én.
Ha neked tennék fel a kérdést egy interjún, hogy szerinted milyen egy jó, minőségi java osztály implementációja, akkor mit válaszolnál?---
A felhozott példákat én egy lehelletnyit túlzónak tartom, a vas rácsszerkezetét inkább hasonlítanám mondjuk a gépi kódhoz, mintsem a kódminőség megítéléséhez. Az meg igazán örvendetes lenne, ha az IT iparban is olyan képzésük lenne az embereknek, mint orvosi fronton, mentoring, sokéves rezidenskedés, stb. Én se kérdezném meg tőle az adagolást, mert feltételezném, hogy pontosan tudja. Na meg a beteg halálozások száma is jó indikátora a hozzáértésnek. -
Drizzt
nagyúr
válasz
M_AND_Ms
#10734
üzenetére
Nem, én ezt rendkívül fontos dolognak tartom. Ha ez nincs végig az ember fejében, amikor kódol, akkor jó eséllyel gányolt minőséget fog kiadni. Az meg most, hogy konkrétan a SOLID betűit feloldja-e valaki, vagy a lényegét elmondja a mozaikszónak, igazából mindegy, de számomra mozaikszót megjegyezni és felidézni sokkal egyszerűbb, mint bármi más módszer.
Juniortól nem ezt kérdezném, mert szinte biztos, hogy nem fogja tudni. Ott nyomatnám az egyszerűbb adatstruktúrák kérdéseit. Senior szinten viszont szerintem ez alapelvárás, akármikor.
-
#10401
E.Kaufmann
veterán
M_AND_Ms
#10400
E.Kaufmann
veterán
válasz
M_AND_Ms
#10400
üzenetére
Jaja, fa struktúrájú adatok bejárásánál tud jól jönni, ugyanakkor túl kiterjedt szerkezeteknél nem biztos, hogy jó ötlet, marha sok memóriát fel tud emészteni, valamint egzotikus memóriahibákat dobhat a jvm, még ha a gépben van is elég memória, csak épp a programverem, vagy minek hívják, túlcsordul: [link]
Érdemes ciklusokra visszavezetni a megoldást rekurzió helyett. -
-
sztanozs
veterán
-
Orionk
senior tag
válasz
M_AND_Ms
#9456
üzenetére
Igen, le volt írva rendesen, hogy mi a Fibonacci sorozat és hogyan épül fel. Abból te találtad ki, hogy hogyan kell kiszámolni a sorozat egyik elemét.
A 20 percből szerintem 5-6 perc csak arra megy el, hogy megértsd és kitalálj egy megoldást. Nekem annyi szerencsém volt, hogy régebben már megoldottam ezt és emlékeztem rá.
-
sztanozs
veterán
válasz
M_AND_Ms
#9451
üzenetére
mennyire tudja összekötni az üzleti igényt az adott eszközzel, programnyelvvel. Mennyire képes egy üzleti specifikációból valós és jól működő kódot alkotni.
Ez egy nagyobb cégben azért két szerepkör:
- egy technology designer vagy business analyst - aki az üzleti igényből technikai specifikációt csinál
- egy fejlesztő - aki a technikai specifikációból kódot csinálEgy normális helyen egy fejlessztő sosem ül le (egyedül) az üzlettel megbeszélni, hogy mi az igény. Az ilyenekből lesznek azok a fejlesztések, amitől a tech kontrol vagy az infosec osztályon mindenki évekig a haját tépi (már ha van ilyen).
-
ToMmY_hun
senior tag
válasz
M_AND_Ms
#8743
üzenetére
Voltam már pár multinál tesztet írni, és az ottani tapasztalataim alapján írtam ezt. Nemrég például egy prímtényezős felbontó programot kellett írni a teszten egyik feladatként. Ez sem túl életszagú, mégis ez volt a kérdés. Szerintem egy juniornál nem az a célja a tesztelésnek, hogy az eddigi szakmai ismereteit visszakérjék - erre tökéletes volt az egyetem -, sokkal inkább az a cél hogy kiderítsék képes-e logikus, szisztematikus gondolkodásra. Erre tökéletesen jó a láncolt listás kérdés.
-
#8691
MasterMark
titán
M_AND_Ms
#8690
MasterMark
titán
válasz
M_AND_Ms
#8690
üzenetére
Ja nem úgy értem, elméletben tudom mi az. A kérdés hogy java-ban is olyan ez mint C++ -ban, hogy ezt előre fixen meg kell mondani mekkora?
Csak mert inkább használnék ArrayList-et de akkor meg értelmetlen a feladat szövege, vagy ezt is jelentheti a kétdimenziós String tömb?
-
ToMmY_hun
senior tag
válasz
M_AND_Ms
#8346
üzenetére
Nem az a lényeg hogy tudd, hanem hogy megértsd és algoritmizáld. A palindrom szót én is a interjún hallottam először, de ez nem jelenthet gondot az algoritmus megírásában. Abban igazad van, hogy ez nem nyújt elegendő információt a jelentkezőről, de olyan dolgokat kideríthet, amit a papíron való tesztelés nem.
-
pvt.peter
őstag
válasz
M_AND_Ms
#7946
üzenetére
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. -
-
Lortech
addikt
válasz
M_AND_Ms
#7644
üzenetére
Nyilván nem keverendő össze, ha ugyanaz lenne a kettő, akkor nem lenne két alapvetően különböző megoldás a nyelvben (interface vs class, implements vs extends).
Az "öröklődés téma része", de nem állítottam, hogy implementációt örökölsz az interfésszel. Lásd pl. [Multiple Inheritance of State, Implementation, and Type] vége. Ez tovább bonyolódik a java 8 default interfész implementációkkal. Állapototot ezzel legyütt sem lehet örökölni. -
#7638
WonderCSabo
félisten
M_AND_Ms
#7637
WonderCSabo
félisten
válasz
M_AND_Ms
#7637
üzenetére
Ezzel természetesen teljesen egyetértek. Szerintem sincs értelme direktben megkérdezni a láthatóságok felsorolását, hanem használtatni kell egy feladatban.
Szimplán annyit mondok, hogy ezt attól még kötelező tudni egy Java fejlesztőnek, álmából szilveszteri buli után felébresztve is. -
-
#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.
-
#7363
Aethelstone
addikt
M_AND_Ms
#7361
Aethelstone
addikt
válasz
M_AND_Ms
#7361
üzenetére
Tehá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.
Nos, ez nem ilyen egyértelmű. 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.....
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.
Pongyolán fogalmaztam, ez tény
-
Lortech
addikt
válasz
M_AND_Ms
#7054
üzenetére
Belepörgettem én is kíváncsiságból, mivel már sokszor előkerült itt is, de csak az első részbe.
Szerintem ez a "leegyszerűsített" magyar nyelvezet nem igazán segíti elő a későbbi továbbfejlődést. A magyar volta miatt is vannak benne olyan se füle, se farka meghatározások, kifejezések, amik szerintem csak félreviszik a dolgot a későbbiekben. Ha valaki komolyan java-t, programozást akar tanulni, megkerülhetetlen az angol nyelvű szakszöveg megértésének képessége, ezt el kell fogadni, és ne is legyen cél a megkerülése, mert később csak hátránya származik belőle.
Azt se mondanám rá, hogy biztos alapokat ezzel a könyvvel kell lerakni. Sok mindent próbál érinteni programozás témakörben, és még azon is túl, de éppen ezért sok mindent felületesen tárgyal csak, sem a JAVA rész nem erős benne, sem a bevezető részek. Nem helyettesít egy rendes bevinfót, egy rendes programozás alapozót, OOP alapozót.
Tele van olyan rövid, felsorolásszerű meghatározással, amik közül némelyik önmagában is meg tudna tölteni fejezeteket, és csak azért szerepel egy néhány soros meghatározás róla, hogy majd be lehessen vasalni.
Ez egy tankönyv, ez a legpozitívabb, amit el tudok mondani róla. -
Atke
senior tag
válasz
M_AND_Ms
#7027
üzenetére
Szerintem félreértetted a dolgot...
Itt leírtad hogy melyik az a könyv,amit ajánlasz..
itt megköszöntem és reagáltam floatr hsz-ére
Ha nem erre gondolsz, akkor azért nem kerestem rá a szerzőre mert fogalmam sincs hogy kiírta azt a könyvet, aminek a nevét sem tudom -
Atke
senior tag
válasz
M_AND_Ms
#7025
üzenetére
Köszi, sikerült már beszerezni.
A fórumot tudom használni, csak nem tudtam, mit keresek ( 24 óra, könyv, illetve a kezdő szóra kerestem) A legtöbb találatot 200X. évben hozta a kereső,így inkább rákérdeztem
Bár nem értek a dologhoz, de elég felszínesnek éreztem a könyv leírását. Mivel hosszú távú terveim vannak vele így az elejétől, szájbarágósan akarom az egészet tanulni.
Köszönöm még egyszer a segítséget
-
válasz
M_AND_Ms
#6997
üzenetére
Lehet, hogy en dolgozom rossz (jo?) helyen, ilyennel meg nem talalkoztam. 100%-os specifikacio ugyebar nem letezik. A modern professzionalis fejleszteshez lenyegeben arra van szukseg, hogy a programozo domain expert is legyen.
Vagy legalabbis en csak olyan helyeken dolgoztam meg, ahol az uzleti logikat a fejlesztok jobban ertettek, mint a felhasznalok. (Ebben voltak neurobiologusok, market makerek, mittudomen.)
-
#6892
Sk8erPeter
nagyúr
M_AND_Ms
#6874
Sk8erPeter
nagyúr
válasz
M_AND_Ms
#6874
üzenetére
"Csókoltatom a könyv íróját!"
Nem lőttél mellé, nem akarok szemét lenni, de szegénykém egy kókler. Sok tekintetben megragadt a tudása valahol a kilencvenes évek végén, kétezres évek elején, szerintem nem igazán képzi már magát. Ezt onnan tudom, hogy BME-n még régebben felvettem nála egy webfejlesztéssel kapcsolatos tárgyat (kellett a kredit, gondoltam akkor már érdekeljen), és az előadásain a kínok kínját éltem át, amikor például megmutatta a JavaScript-kódjait, és a saját maga által sok-sok éve írt tákolmány fos kódot nem értette, látszott, hogy elakad, agyalnia kellett rajta, hogy az mit is csinál, már nekünk, a hallgatóknak volt égő, készültem rá, hogy jelentkezem, és elmagyarázom neki, mit csinál a saját kódja (de türelmesen vártam, mert így is elég kínos volt a helyzet), de 5 perces hümmögés után valahogy rájött, vagy skippelte a diát. Ősrégi, elavult módszereket alkalmazott, a kódok összecsapottak voltak... na most ennek fényében el lehet képzelni, mennyire lehetnek jók a Java-kódjai és -feladatai. Igazából megdöbbentő számomra, hogy BME-n taníthat (na nem mintha nem lehetne még sok nevet dobálni, akinek finoman szólva nem up-to-date a tudása).Szerk.: az egészből a következtetés igazából annyi, hogy szerintem azt a könyvet nem érdemes komolyan venni, így tanulni sem belőle, bár sosem olvastam, de az előbbi példa lehet, hogy elég is volt rá.
-
sunnysys
tag
válasz
M_AND_Ms
#6176
üzenetére
Köszi!
Na, igen, többek között ezért is szeretnék valakit találni, aki ezzel foglalkozik, és akivel kontrollált körülmények között tudok haladni. Eddig általában mind az Arduino (C++ alapú) programozása, mind a Java programozása során megtaláltam az adott nyelvben, az adott feladathoz szükséges megoldásokat, de fogalmam sincs, hogy azok a legjobb megoldások, vagy csak jó megoldások voltak-e, vagy esetleg "épp, hogy megoldások" voltak, de semennyire nem voltak pl. elegáns megoldások. Pl. pár hete leprogramoztam egy egyszerű számológépet Javaban, ami úgy működött, hogy a TextField, getText által adott értékeket alakította át ParseFloat utasítással, amelyekkel aztán matematikai műveleteket végzett, majd az eredményt ismét String-ként jelenítette meg a TextField-en. Mivel csak magamtól, innen-onnan szedegetem össze a tudásomat, ilyen - gondolom nem túl szerencsés - megoldásokat találok ki. Tehát az alapvető programozási szemléletet (vagy hogy is nevezzem) is meg kellene tanulnom. Ezt is el lehet sajátítani önállóan?(#6178) axioma:
Én is sokat merítek mások kódjából. Ha volt valami feladat, amire sehogy nem jöttem rá magamtól, megkerestem egy hasonlót a neten, és felhasználtam. Ha működött, átolvastam sokszor, memorizáltam, magamévá tettem, így legközelebb, hasonló esetben már tudom használni.Szóval, érzem én, hogy ma már szinte mindent meg lehet tanulni a neten elérhető anyagokból, csak szeretnék minél gyorsabban haladni.
-
Skroll
csendes tag
válasz
M_AND_Ms
#6173
üzenetére
Az Angster-féle könyvek valóban jók. Az első könyv itt érhető el PDF-ben: Objektumorientált tervezés és programozás - Java 1
A második könyvet nem tették ki (még) ingyen, kapható is újonnan. (Bár találkoztam már szkennelt PDF-fel abból is)Szintén jók a Lynda.com féle anyagok, ezek videó tutorialok angolul, rengeteg témában, többek között jávában, több szinten, illetve magáról az objektumorientáltságról, a tervezésről is vannak videók. Az oldal fizetős (25$/hó), de megéri, ha ilyesmivel foglalkozol, azonban az anyagokba való betekintésre másutt is van mód.
Egyébként itt egy egyhetes ingyenes kipróbálási lehetőség, ha ezen keresztül regisztráltok Ja, nem fűződik hozzá anyagi érdekeltségem. 
-
floatr
veterán
válasz
M_AND_Ms
#5856
üzenetére
Komoly cég megbíz olyanokat, akik bárhol keresnek.
Egyébként nem csodálkozok ezen, mert nem túl jó irányban alakult a piac az utóbbi években a furcsa felhozatal révén. Érdekes elvárások vannak mindkét fél részéről, közben csak hígul a szakma. Emiatt az értékesebb emberek gyakran elszállnak (többnyire emberileg), sokan kivándorolnak... Ez van.
Sok szerencsét a keresőknek! Szükségük lesz rá.
-
#5590
Aethelstone
addikt
M_AND_Ms
#5589
Aethelstone
addikt
-
#5298
WonderCSabo
félisten
M_AND_Ms
#5297
WonderCSabo
félisten
válasz
M_AND_Ms
#5297
üzenetére
A Singletonnak - ha normálisan akarja megírni az ember - privát konstruktora van, nem véletlenül. Én nem normálisan írtam meg. Singletonból örököl egy osztály, csak baj van belőle.
Egyébként a static metódusokat simán lehetne örökölni, túlterhelni subclassban, csak a Java nem támogatja ezt. Anno a híres "java sucks" cikkben (http://www.jwz.org/doc/java.html) ezt is felrótták Neki (about the language itself rész).
-
#5271
WonderCSabo
félisten
M_AND_Ms
#5270
WonderCSabo
félisten
válasz
M_AND_Ms
#5270
üzenetére
Némi magyarázat ehhez az egészhez.
-
Lortech
addikt
válasz
M_AND_Ms
#5017
üzenetére
Szerver oldalon titkosítva illik tárolni, és titkosítva is illik továbbküldeni a kliensnek a szerver felé, de kliens oldalon mivel a kliensnek nem ártana tudnia a jelszót a szerver felé elküldeni autentikációra, ezért még ha nem is plain textben van valahol tárolva a mentett jelszó, a kliens oldalon akkor is rendelkezésre kell álljon minden információ az eredeti jelszó visszanyeréséhez vagy legalább a sikeres autentikáció reprodukálásához (pl. ha közbe van iktatva egy hash és a szerver is hasht vizsgál).
Ezek szerint a böngészők sem biztonságosak ilyen szempontból, mert tárolják a jelszavakat, nem plain textben, de visszanyerhető formában. Pl. chromeban ilyen egyszerű: chrome://settings/passwords Egyébként tényleg nem biztonságos a jelszó megjegyeztetése kb. sehol, ez egy kényelmi feature. Ha egyszer az alkalmazásnak is vissza kell tudnia nyernie a mentett jelszót vagy annak lenyomatát, akkor ugyan lehet bonyolítani a dolgot a tárolásnál és autentikációnál, de ha helyileg hozzáférsz a géphez, ahol meg van jegyeztetve a jelszó, akkor mindig meg lehet szerezni a jelszót vagy azt a tokent amit autentikációhoz használ az alkalmazás.
Abban viszont egyetértek, hogy az elfelejtett jelszóra a gyógymód az, hogy fel kell venni a kapcsolatot a gyártóval / szolgáltatóval az új jelszó igénylése érdekében. Amúgy sem célszerű senkinek ilyen dolgokban segíteni egy névtelen fórumon, ahol nem lehet meggyőződni arról, hogy az illető tényleg jogosult-e a jelszó megismerésére, a szolgáltatás használatára.
-
-
floatr
veterán
válasz
M_AND_Ms
#4724
üzenetére
és (#4725) WonderCSabo
Egyszerűbb esetekben hasznos, mert nem akar senki sem vájkálni a felszín alatt. Amikor viszont egy kicsit összetettebb dologra kerül a sor, eleinte csak vakarod a fejedet, de már futottam bele megoldhatatlan problémába.
A konkrét kódra nem emlékszem már, de a lényege annyi volt, hogy annotációs SQL-el működő perzisztencia motor leszármaztatott interfészeknél elvesztette a fonalat, amikor a metódusokat override-oltam. Ennek az oka a felszín alatt lévő tényleges kompatibilis implementáció, hogy egyszerűen Object-et használ a típusparaméter helyett. Ez meg letarolja az OOP-alapelveket.
Ha lesz egy kis időm rá, megpróbálom rekonstruálni a dolgot.
-
floatr
veterán
válasz
M_AND_Ms
#4716
üzenetére
Vannak teoretikusok, akik mindenbe belekötnek, amikor megírják a könyveiket. Az ellenőrzött kivételek a saját kódodat erősítik, közvetlen megoldásokkal. A RuntimeException származékok pedig pl. egy konténert címeznek meg valami fatális tévedéssel. Az egyik legjobb példa erre, amikor SOA backended van, és központosított hibakezeléssel akarsz kommunikálni a kliens felé. A nagyobb problémákat egyszerűen nem lehet vagy nem éri meg ellenőrzött kivételekkel visszavezetni, amikor a konténer ezt automatikusan elvégzi egy kis testreszabással.
De ha már itt tartunk, akkor a generics inkább egy baromi nagy tervezési hiányosság, mint ez
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Megvan, milyen chipet használ a Pura 80 Ultra
- TP-LINK routerek
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Háztartási gépek
- EAFC 25
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Everest / AIDA64 topik
- Azonnali alaplapos kérdések órája
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- További aktív témák...
- MSI RTX 4070 SUPER 12GB GAMING X SLIM WHITE - 20 hónap garancia
- GIGABYTE RTX 4070 SUPER WINDFORCE OC 12GB - 20 hónap garancia
- iKing.Hu - Samsung S25 Ultra - Titanium Black - Használt, karcmentes
- Apple Ipad 10.generáció
- Új HP Pavilion x360 14-ek Érintős hajtogatós Laptop Tab 14" -35% i5-1335U 8/512 FHD IPS Iris Xe
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest