- Samsung Galaxy A56 - megbízható középszerűség
- Samsung Galaxy A52s 5G - jó S-tehetség
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Mobil flották
- Yettel topik
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Motorola Edge 30 Neo - wake up, Jr...
- Tokba kerülnek a Pixel 10 mágnesei
- Xiaomi Mi 11 Ultra - Circus Maximus
- Motorola Moto G72 - a titkos favorit
Új hozzászólás Aktív témák
-
Szmeby
tag
válasz
btraven
#12173
üzenetére
A monad egy magányos lélek, ki csendben, magába fordulva, mindentől elzárkózva lebeg az éteri mezők felett. A monad nem foglalkozik a külvilággal. A monad csak befelé figyel. Ha a monad mondjuk egy gömbként éli életét, bár mélyen legbelül forrong is, ő továbbra is egy gömb formájában létezik. Akkor és csakis akkor mutat változást kifelé, amikor beteljesíti rendeltetését, eljő érte a terminal operator, megszűnik létezni, miközben hamvaiból egy kocka emelkedik fel. Az a kocka már nem feltétlenül egy monad. Általában nem az.
Amikor egy mondjuk stringre ráhívod a parseInt metódusát, ő voltaképpen egy lépésben válik egyikből a másikká. A változás kívül megy végbe, azonnal, szemmel jól láthatóan.
A stream egy monad, a legtöbb operátora a belső lelkivilágát alakítja, kívülről láthatatlan, ezért is tükrözik az elnevezések ugyanezt. A map nem a monad külsejét akarja megváltoztatni, hanem a belsejében található tartalmat alakítja, esetedben egy-egy stringet. A mapToInt úgyszintén. A max operátor ellenben terminálja a monadot és ebből a sejtelmes lényből csinál egy számot, ami már kívülről is láthatóvá válik, miközben a monad meghal.
A java nyelvben nem csak egyféle lény él. A különféle lények eltérően viselkednek és a viselkedésüket csak kontextusukban érdemes értelmezni.
-
Szmeby
tag
válasz
Ablakos
#12154
üzenetére
Valószínűleg azért találja meg a második megoldásod, mert ott explicite kikötöd neki, hogy az src-ben keresse a fájlt, és ugyanezen okból hiszem azt, hogy az az
Excluded: resources/lesz a ludas.Ugyanis ezzel azt mondod az ecplise compilerének, hogy a resources mappát hagyja figyelmen kívül, ne tegye át a bin alá, és amikor futtatod, valószínűleg a kódod a bin-ben keresi a fájlt. Töröld azt az exclusiont, ellenőrizd, hogy átkerültek-e a fájlok a bin-be a fordítás során, és hogy működik-e immáron az első megoldás. Remélem igen, mert ha nem, akkor hülyeséget beszélek.
-
Szmeby
tag
válasz
Taoharcos
#12050
üzenetére
Attól függ, milyen eszközzel olvasod fel a fájlt.
Akárhogy is, a fájlban a szöveg byte-ok halmaza, azt valamilyen karakterkészletre kell alakítani felolvasáskor. Akár bytearrayt, akár inputsreamet, akár valamilyen fancy toolt használsz, ami ezekre épül, mindegyikben kell legyen (az értelmesekben legalábbis) olyan opció, ahol megadhatod a charsetet is. Vegyük például a Files::lines metódust ő is vár egy charsetet, megadhatja az, akinek erre van igénye.
A nio StandardCharsets osztályában megtalálod a gyakran használt charseteket, bár mondjuk a latin2 szerintem nincs köztük, de a nio ismeri azt is. Legrosszabb esetben stringként megadod a Charset::forName factory metódusnak és máris van egy charseted, amit használhatsz az olvasásnál. Csak jól írd be a nevét.
Egyébként, ha lehetőséged van rá, inkább pl. UTF8-ban generáld ki azt a csv-t, az sokkal univerzálisabb.
-
Szmeby
tag
válasz
Steve_Brown
#11978
üzenetére
Tippre azt mondanam, hianyos a spring konfiguraciod, a package scan-ek kozott nezelodnek, hiszen egy annotacio egy bizonyos dolgot konfigural, egy masik meg egy masikat.
De ha nem kotott a package struktura - marpedig miert is lenne kotott egy furcsa package struktura -, en inkabb athelyeznem az Application classt egy application root package-be, ami szerintem nalad a travel package (app nelkul), as akkor megsporolhatod az osszes package scant vegzo annotaciot, nem kell terjengos felsorolasokat irogatni annotaciokba, leven a spring automatikusan scanneli maganak az osszes package-et, amit "beljebb" talal, a peldam szerint a travel.* -ot. Igy nem kell azon filozni, vajon melyik package hianyzik es melyik annotaciobol...
-
Szmeby
tag
Még egy kis kiegészítés a comparator implementációhoz.
Ha nagyon nagy számokkal dolozunk, akkor nem szerencsés a kivonásos módszer használata, pl. ap1.getLiteracyRate() - p2.getLiteracyRate(). Ugyanis ha egy nagyon negatív számból kivonunk egy nagyon pozitív számot, akkor az eredmény túlcsordulhat és átcsap az ellenkező előjelbe, ami nyilván elrontja az egész sorrendezést.
Érdemes inkább a relációs operátorokat (<, >) használni a kivonás helyett. -
Szmeby
tag
válasz
Ablakos
#11888
üzenetére
A
partreferenciája nem szűnik meg, ha arra gondoltál. A belepakolt Stringeket a clear ugyan eltávolítja a listából, de apartél és virul. Egy referencia akkor szűnik meg, amikor semmilyen más élő objektum nem hivatkozik rá (mert mondjuk az utolsó hivatkozást is felülcsapod valami más referenciával).
Na meg a vezérlés kifutott a scope-jából is, ami a part esetén a metódus kapcsos zárójelei között található. (Ha a while ciklus kapcsos zárójelei közé tennéd a part deklarációt, akkor az lenne az ő scope-ja és minden körben új példány készülne belőle, de azt most nem akarod.)A csoda a
listRecipes.add(new Recipe(part));soron történik, apartreferenciáját megjegyzi a recipe ojjektum is - immáron nem csak apartváltozó fog arra hivatkozni -, az ő referenciáját pedig beledobjuk alistRecipeslistába, így az már nem vész el addig, amíg alistRecipeslétezik.Tehát a clear helyett bátran csinálhatsz egy új lista objektumot a
partváltozódnak, sőt illene is, ha nem akarod piszkálni a régi lista tartalmát, ami már alistRecipesbugyraiban pihen. -
Szmeby
tag
válasz
Ablakos
#11866
üzenetére
A
containsteljeskörűen működik. Ha belenézel azObjectosztályba (ami minden osztály őse), láthatod, hogy azequalsmetódus referenciák egyenlőségét vizsgálja - lévén más információja nincs az osztályról. Azt csinálja, mint amit az == operátor.Tehát az
equalsés egyben acontainsalapértelmezett működése az, hogy csak akkor tekint két objektumot egyenlőnek / a lista egy tagjának, ha az az objektum ugyanaz az objektum, mondjuk úgy, hogy ugyanazon a memóriacímen található adathalmaz.Abban a pillanatban, hogy kiadod a
newutasítást, a jvm egy vadonatúj objektumot fog gyártani neked. Még ha ugyanazt a szöveget adod is meg neki a könyv címe paraméterben, még ha ugyanaz az évszám, még ha látszólag ugyanúgy is néz ki az az objektum, mint egy másik, a referenciájuk eltér, hiszen anewutasítással ezt kérted a jvm-től, egy új objektumot.A referencia alapú összehasonlítás időnként hasznos dolog, de a modelljeinkben többnyire nem ez a legjobb megoldás. Ezért készítünk az objektumainknak saját
equalst, amikor azokat egymással össze akarjuk hasonlítani, és azt várjuk el tőle, hogy egyenlőnek tekintsen két könyv objektumot, ahol a cím és az évszám egyenlő. Ezt sajnos meg kell írnod, mert a jáva túl buta, hogy kitalálja a programozó gondolatait, elvárásait.
(És készítünk nekik saját hashcode implementációt is, amikor azokat mondjuk HashSet-ben kívánjuk gyűjtögetni, vagy HashMap kulcsaként akarjuk felhasználni.)Tehát a
Book b1 = new Book("a", 1);és aBook b2 = new Book("a", 1);eltérő referenciával bír, az alapértelmezettequalsszerint ők különböző objektumok. Míg aBook b3 = b1;ugyanazzal a referenciával bír, mint a b1 objektumod, az alapértelmezettequalsszerint ők ugyanazok az objektumok. -
Szmeby
tag
válasz
Foglalt név
#11842
üzenetére
Már bocsánat, de nem mondhatod azt, hogy "fekete ruha". A kommunikációdban légy szíves az afroamerikai - esetleg rövidebben az afro - ruha kifejezést használni, mert ezzel megsértesz embereket. Tanulhatnál egy kis empátiát! (Kappa)
-
Szmeby
tag
válasz
floatr
#11774
üzenetére
Az ilyen kérdések nem segítségkérésre valók, lévén nem konkrétak. Talán együttérzésre vágyik, ventilálni jár ide. Nincs ezzel semmi baj, a lelki támogatás is fontos. Mondjuk én személy szerint nem tudok velük mit kezdeni, de hátha valaki igen.
btraven: Gratula a játékhoz!
-
Szmeby
tag
válasz
floatr
#11690
üzenetére
Szerencsére már megtehetem, hogy a megrendelő arcába mondom, működő kódot egy majom is tud írni... kis túlzással. Szóval rengeteg pénzt spórolhat, ha inkább felvesz egy pár juniort, aki összerakja neki az appot gombokért. Ők ráadásul minden szóra engedelmeskednek, nem jönnek ezzel a nem lesz hatékony / átlátható / felhasználóbarát marhaságokkal. Ő is "jól" jár, és az én idegeimet is megkíméli.
Mindenkit bátorítanék erre, különben sose tisztul a piac, ha a fejlesztő nem áll ki a technológiai oldalért. -
Szmeby
tag
válasz
skoda12
#11688
üzenetére
Részvétem. Mindig nehéz azokkal, akik csak a pénzért csinálják.
Azt mondjuk nem értem, hogy ki másnak kellett volna megtalálni a PR-ben elrejtett dolgokat. Aki hozzáfér a PR-hez, az megtalálhatja. Mondjuk ha csak 1 ember rivjúzik a csapatban, akkor kézenfekvő, hogy ki fogja megtalálni a hibákat. -
Szmeby
tag
válasz
skoda12
#11686
üzenetére
Ezek szerint akkor olyan dolgokba kötöttél bele, amibe felesleges lett volna?
Ha nem, akkor most hagyod elrothadni a kódot?
Mindezt azért, mert a csapatod tagjai nem alkalmazzák a közösen elfogadott kódolási irányelveket. (Gondolom, közösen fogadtátok el. Sőt gondolom, időnként felül is vizsgáljátok azokat.)
És azért is, mert páran nem elég érettek a felnőtt viselkedésre? Akik a tévedésekre való rámutatást nem fejlődési lehetőségnek, hanem személyes sértésnek veszik.Mindezekből következően saját magad és voltaképp még a crybaby csapattársaidat is megszívatod az egyre jobban degradálódó kóminőséggel. Megéri? Azon csapattársaid, akik jó minőséget állíta(ná)nak elő, őket is a gányolás keserédes mezejére száműzöd ezzel. Nem?
Amúgy abszolút egytértek a mondandód első felével, én sem vagyok büszke az 5 éve írt kódomra, hát még az 1997-ben írtakra.
Viszont ez azt is jelenti, hogy ma már sokkal jobbat tudok alkotni, és holnap mégjobbat fogok tudni. A sun is biztosan jobbat írna ma, mint, amit most látunk belőle. -
Szmeby
tag
Én jávás vagyok, de pythonban sokkal könnyebben dobtam össze egy desktop appot. Bár nem is volt olyan szép, mint egy alap javafx cucc, cserébe töredék idő alatt elkészült.
A mobil app szerintem halott. Én a magam részéről biztosan nem telepítenék fel a telefonomra egy huszonharmadik valamit is csináló appot, mert minek. Szerintem más sem. Persze lehet, hogy én vagyok a különc.
Ergo egy javascript, sőtmitöbb egy typescript szerintem többet tud adni egy kezdőnek, mert egyrészt szuper frontendet lehet vele készíteni, és ami elfut egy böngészőben, az "bármilyen" mobilon is elfut. Másrészt a nodejs-sel immáron az ismerős javascript környezetben heggeszthet az ember backendet is az appjának. Egy nyelv ismeretével meg van a fullstack.
Bár a java+vaadin kombóval is egészen szép web appokat lehet gyúrni. De ha java vs python a kérdés,és az egyszerűség fontosabb mint a szépség vagy mondjuk a teljesítmény, akkor a pythont jobb választásnak érzem. Talán ez ízlés dolga is.
És igen, legalább egy sqlite adatbázis ajánlott. Az is egy fájlban tárolja a cuccot, de mégis van egy rendes apija, vannak hozzá eszközök, libek, amik megkönnyítik az ember dolgát. Pythonban néhány sor és kész az egész adakezelés. Fájlba írogatással egy csomó kockázatot húzol magadra, és oda jutsz, hogy feltaláld újból a kereket. Hacsak nem egy faék egyszerűségű, szöveget kiírok - szöveget beolvasok szituációról van szó, akkor nem árt az adatbázis. Egyszerűbb, mint szövegfájlt parzolgatni.
Az "elfogytak az adatbázisok" kiejentést nem nagyon tudom hova tenni, mysql-ben ez egy parancs, ami tulajdonképpen virtuálisan hoz létre egy új db-t. Bár nem értek a hosztolt adatbázisokhoz és hogy ott mit szabad és mit nem.
A meglévő mysql-be új táblát is vehetsz fel, ha a db tulaja / használója ezt nem bánja. Technikailag nem zavar be, csak az átláthatóságot rontja, hogy minden csak be van hányva egy DB-be. -
Szmeby
tag
válasz
btraven
#11495
üzenetére
Normális esetben kompatibilis. Ha valóban CME-t dob, akkor a jelek szerint az Army objektumaid nyilvántartják magukban, hogy a defenderArmies collection részei, és valamelyik remove (gondolom az utóbbi) el akarja távolítani saját magát a defenderArmies collection-ből is.
És ha ez a helyzet, míg az iteratoros példa CME nélkül lefut, akkor szerintem hibázik. Mivel az iterator saját állapotot tart fenn, hogy tájékozódjon a collectionben, őt különösebben nem zavarja, ha menet közben törölsz a listából, de ha ezt nem közlöd az iteratorral, akkor minimum hibás eredményt hoz, pl. nem töröl mindent, vagy nem azt törli, amit kellene, nem tudom.
Az iterator tényleg lefut, míg a foreach elszáll?A helyes iterator használat valahogy így nézne ki:
Iterator<Army> iter = defenderArmies.iterator();
while (iter.hasNext()) {
Army army = iter.next();
// do sth with army
iter.remove();
}
Az iter.remove() mondja meg az iteratornak, hogy itt törlés van, és vissza kell léptetnie a kurzorát. Enélkül, hát, csodálom, hogy nem dob hibát. -
Szmeby
tag
válasz
btraven
#11473
üzenetére
En ugy gondolom, hogy jelentos merteku fejfajastol kimelned meg magad, ha elobb bekonfiguralnad az IDEt ugy, ahogy neked tetszik. Minden valamire valo IDE-ben be lehet allitani, hogy mit tekintsen hibanak es mit ne, hogyan formazzon es hogyan ne. Szerintem ez is kepes ra.
Persze ha csak ventillalni szeretnel, akkor targytalan, folytasd nyugodtan.
Megjegyzem, en szeretem a zarojelet az if-nel, mert igy egyseges, konnyen attekintheto.
-
Szmeby
tag
válasz
btraven
#11462
üzenetére
En amikor csak lehet, csak backendet keszitek javaban. A frontend meg szepen koltozzon at a bongeszobe (angular, react, vue, stb).
Ha tenyleg annyira pici a problema, hogy nem eri meg egy js frameworkkel loni ra, akkor desktopra inkabb raknek ossze egy python appot. Az is benacska, de legalabb gyorsan elkeszul. Azert python, mert szerintem sokkal konnyebb es mert mashoz nem ertek.
Ha meg nagyon ragaszkodnek valamiert a javahoz, akkor +1 a javafx-re. Az a legujabb desktop frontendje, de mar azt sem eroltetik a keszitok.
-
Szmeby
tag
Voltam olyan projekten, ahol már már megszállottságig fajult az új dolgok megtanulása. Hetente cseréltük le a félig magunkévá tett libeket valami fancy újra, és integráltuk bele az alkalmazásba újra és újra és újra, mindig volt valami hot topic. Brr. Na de ez a másik véglet. Talán nem kell mondanom, az alkalmazás elkészülte folyamatosan csúszott. Talás sose készült el, már nem vagyok ott, hogy ezt megtapasztalhattam volna.
Nekem annyit adott az a projekt, hogy megtanultam a világ túl gyorsan változik, hogy minden újat meg akarjak tanulni - nem is lehet - és elveszi az időt az értelmes dolgokban való elmélyüléstől. Persze megértem, hogy másokat meg csak az újdonság érdekel, és nem zavarja őket az a sok zaj a fejükben, aminek a felére holnap már senki sem emlékszik amúgy, mert csak hype volt körülötte. Azt meg végképp nem tudom hova tenni, ha valakit az alapján ítélünk meg (el?), hogy mavent vagy gradlet használ, neadjisten antot. Ha neki ettől jobb, váljon egészségére.
Vagy menjen és vezesse le a feszkót maven irtással, addig sem zavarja a terméken dolgozó népeket. 
Amúgy utálom az xml-t, és szeretem a mavent. Há!
-
Szmeby
tag
válasz
Drizzt
#11387
üzenetére
Úristen, ez már ennyi ideje így működik?
Értem én, hogy kényelmes, de azért na, hát mióta nem antipattern a repository megnyitása a nagyvilágnak?! Legalább egy bekapcsoló annotációt el tudtam volna képzelni ehhez a remek fícsörhöz.
Minden esetre nagyon köszi a linket, ma is okosabb lettem. -
Szmeby
tag
What kind of sorcery is this?
Spring boot 2.4.0, data-jpa és data-rest függőségekkel. Jó, van még egy h2 db, meg egy actuator, de az nem számít. Semmi konfiguráció, sem extra függőség, nem értem.
Szóval csináltam egy hót egyszerű spring boot appot, tettem bele egy City nevű jpa entity-t, meg hozzá egy töküres JpaRepository-t. Zéró REST végpont mutat bárminemű City-vel kapcsolatos dologra, mégis, amikor megkérdezem a root végpontot, akkor ezt a fenti izét nyomja az arcomba.
Az összes végpont, amit csináltam egy "/hello", és a hello world-ön kívül semmit sem csinál.Már átnéztem a spring doksi teljes hateoas szócikkét, de egy falat megjegyzés sincs arról, hogy a spring kitalált nevű végpontokat szór fel nekem az alkalmazásomra csak úgy, expozálva ezáltal az app belső dolgait, konkrétan az entitások neveit. Egyrészt ez felháborító, hogy kérdés nélkül ilyet csinál, másrészt ti találkoztatok ezzel? Miatököm csinálja, és hogyan lehet kikapcsolni?
-
Szmeby
tag
Vannak bizonyos allami projektek, ahol elvarjak, hogy az ember rendelkezzen ezzel, vagy legalabb plusz pontnak minosul.
Nekem sokat segitett abban, hogy jobban megertsem a java furcsasagait, azokat a nuansznyi jellegzetessegeket, amivel az ember vagy egyszer az eletben talalkozik, vagy ugy megszokta mar, hogy fel se tunik neki. De ehhez mondjuk nem feltetlenul adnek ki soksok penzt a vizsgara, mert megtanulni ezeket ingyen is meg lehet, ott a java tutorials weboldala vagy mi a tokom a neve, minden info ott van szepen. Fake tesztekbol is Dunat lehet rekeszteni, ha valaki teszelni kivanja magat.
Jol mutat de hat na. Sok eve mar, hogy megcsinaltam, de ha az ember nem talalkozik azokkal a problemakkal, elfelejtodik, ahogy altalaban a dolgok az eletben. Es akkor megint ott vagyunk, hogy mindenki ahhoz ert a legjobban, amivel aktualisan foglalkozik.
-
Szmeby
tag
válasz
audiophile2!
#11339
üzenetére
Az altalad emlitett absztrakcios szinten (milyen erteket vehet fel a valtozo, mi irja es mi olvassa, hany kozbeiktatott metodushivas van, stb) valoban nincs ertelme a getter setter-szeru megoldasoknak. Csak utban vannak.
Viszont az OOP _nem_ ezen az absztrakcios szinten ad valaszokat. Ez nagyon fontos, mert majd igy tudod csak feltenni a jo kerdest. Az OOP eseten sokkal fontosabb kerdes, hogy mi az osztaly celja, mi a SZANDEK, ami az osztaly letet igazolja. Ez mar filozofia, madafaka!
Szoval egy pelda kedveert ha van egy osztalyod, ami egy teglalapot reprezental, akkor valoszinuleg van neki olyan mezoje, ami a szelesseget, meg egy olyan, ami a hosszusagot tarolja. Adna magat a dolog, hogy legyen public es csokolom. DE ha ennek az osztalynak az a szandeka, hogy segitsen az adott sikidom teruletenek, keruletenek meghatarozosaban, akkor a tobbi osztaly fele' kotelessege csak ezt a infot kommunikalni, es semmi tobbet. Ugyanis, ha ennel tobb infot kommunikalna kifele, akar a szelesseget, hosszusagot, akar ezt meg irhatova is tenne, abban a pillanatban behozna pl azt a kockazatot, hogy ezzel mas osztalyok visszaelnek.
Amivel visszaelhetnek, azzal vissza is fognak elni. Hidd el, nem akarsz egy spagetti kodban konyekig turkalni egy apro kis bug megszuntetese celjabol... mikozben 20000 sort kell modositanod ilyen olyan helyeken, mert minden mindent is hasznal.
Tehat a szoftverfejleszto epelmejusege megorzese celjabol fontos az, hogy egy osztaly kizarolag azt az infot adja ki magabol, amire terveztek, es semmi tobbet. A legtobb esetben pedig ez az info koszonoviszonyban sincs az osztaly tenyleges allapotaval. Hiszen a szandek es az allapot fizikai reprezentacioja elter minden olyan esetben, amikor az az osztaly tenylegesen csinal is valamit. A szoftvereket pedig azert keszitjuk, hogy csinaljanak valamit.
Igy aztan egy eszen jo okolszabaly tud lenni a mezok elrejtese. -
Szmeby
tag
válasz
bggmnd
#11329
üzenetére
BorderPane, VBox, ImageView, GridPane, ...
Nem csak a kinezet szamit, hanem a szandek, hogy az adott komponens milyen problemat old meg, milyen modon, szoval ezt neked kell igazabol tudnod, mibol melyik lesz a megfelelo, a menusort csinalhatod gombokkal, linkekkel, menuitem komponensekkel, es szamtalan mas modon, rajtad all.A dokumentacio mindig jo kiindulopont szokott lenni.
Javaslom, hogy dobd fel a gepre a scene buildert, abban egerrel szepen ossze tudod kattintgatni es kiprobalni a kulonbozo layoutokat.
-
Szmeby
tag
válasz
togvau
#11317
üzenetére
Sajnálattal hallom. Az én emlékezetem is egy aranyhaléval vetekszik. Javaslok egy jelszókezelőt, nekem bevált.
Bizonyára megtehetné, hogy mindkettőt nézi, persze. Csak ez az extra kényelem a háttérben iszonyatos komplexitást generál. A fejlesztők hoztak egy döntést, hogy ez a kényelem nem tesz hozzá annyit, hogy emiatt a framework mondjuk lomha legyen.
Persze ha tudsz egy olyan megoldást, ami nem rontja a framework hatékonyságát, mégis kényelmes, javaslom, beszélgess a hibernate készítőkkel, talán vevők lesznek az ötletre. A hibaüzi mondjuk jól hangzik.
-
Szmeby
tag
válasz
togvau
#11315
üzenetére
Én például onnan tudom, hogy valamikor régen olvastam a hibernate dokumentációjában. Szerintem elég közismert dolog... legalábbis a dokumentációba belelapozó emberek között. Én úgy vagyok vele, hogy ha igényes munkát akarok végezni, akkor érdemes megismerni a használt frameworkot kicsit közelebbről is. Így amikor fikázom, talán kisebb eséllyel teszem magamat nevetségessé.
szerk.: A jelenség a transient módosítótól teljesen független.
-
Szmeby
tag
válasz
bggmnd
#11283
üzenetére
Szerintem is egy spring boot H2 db-vel tökéletesen megfelel a célnak.
Ha valóban a desktop alkalmazás a cél, és csupán a szakdolgozat keretein belül kívánsz maradni, akkor a javafx frontendnél én nem mennék messzebb. (Persze ha fontos az, hogy weben, böngészőből, akár mobilról is elérhető legyen, akkor inkább egy js frameworkot állítanék frontendbe, ami persze újabb komplexitást és eddig számításba nem vett plusz munkát hozna be.) A javafx tud formot, táblázatot, grafikont, egyszerű desktop apphoz megfelelő szerintem.
Ami a kalóriaadatbázist illeti, sose kerestem ilyesmit. Amit más területen tapasztaltam, hogy az amcsik előszeretettel biztosítanak apit, vagy nyitják meg az adabázisukat a közönség számára (akár letölthető csv, akár rest api formájában), főleg a governmental weboldalak. Ez a legegyszerűbb.
Magyar weboldalaknál ez egyáltalán nem jellemző sajnos, ott többnyire marad a webscraping, ha nagy a szükség (és persze a weboldal tulajdonosa a robots.txt-ben ezt megengedi).
Ha kevés adattal indítasz, én lehet inkább feltölteném kézzel, minthogy mások adatbázisait próbáljam számomra emészthető formára hozni. Főleg ha már van mondjuk egy excel táblád (feltételezem van, ha ezt választottad témának), abból nagyon könnyű csv-t kreálni, elé tenni az insert into-t, és hadd szóljon. -
Szmeby
tag
válasz
togvau
#11273
üzenetére
Kicsomagolod, castolod a belét, becsomagolod. Mondjuk, amit az Optional.map() csinál, ha már az Optional a példa.
disclaimer: Remélem azt nem kell mondanom, hogy ha a kalapács nyelével akarod beverni a szöget, akkor ne csodálkozz, ha körülményes. Ha mondanom kell, akkor egy java software design témájú könyv elolvasása szerintem hasznos lenne. Valami a nagyoktól: Josh Bloch, Bob Martin, Kent Beck, Fowler, ...
Ja igen, zavarbaejtően sok állítmány és szleng került a mondataidba, nem vagyok benne biztos, hogy jól értem a problémát, de van egy olyan érzésem, hogy máshogyan illene struktúrálni azt a kódot.
-
Szmeby
tag
válasz
Csaby25
#11227
üzenetére
Én ezzel úgy vagyok, hogy mivel a technológiák úgyis jönnek-mennek, nettó időpazarlásnak érzem bármilyen céleszköz megtanulását.
A java gyermekkorában csak az awt eszközkészlet állt rendelkezésre, hogy az ember desktop guit gyártson jávában, de elég lowlevel volt, platformonként eltért a végeredmény. Aztán évek múltán ráhúzták a swinget, amivel már egészen egységes látványt lehetett rajzolni és elég sokáig életben is maradt ez az eszköz. Bár az awt ismeretek jól jöttek, de azért kellett új kocepciókat újratanulni. Majd néhány (sok) évvel ezelőtt valamilyen megfontolásból - feltételezem, modernizálási célzattal -, készítettek egy másik eszközt desktop gui rajzoláshoz, elnevezték javafx-nek, és ugyanazzal a lendülettel deprecated is lett a swing. Nyilván teljesen más koncepciók mentén készült, így megint kellett rengeteget tanulni. Nem mintha ítélkeznék e fölött, mert egyikhez sem volt túl sok közöm. Aztán néhány (már nem olyan sok) évvel ezelőtt azt mondták, hogy oké, most már a javafx-et sem támogatjuk, halott világ a desktop gui világa, a web a jövő.
És ez csak egy példa a sok közül, egyszerűen nem lehet mindent is életben tartani, így végső soron azok lesznek a túlélők, akik általános megoldást tudnak nyújtani számtalan problémára... vagy ha képesek a készítőik végtelen ideig fenntartani a hype-ot az eszközük körül, esetleg végtelen pénzzel megtámogatva nem jelent nekik gondot a támogatás finanszírozása.A lényeg, amit ki akartam hozni mindebből, hogy desktop gui építésre való eszközzel nem igazán lehet webappot csinálni. Webapp ismeretekkel viszont bármit készíthetek, ami elfut egy böngészőben, és azt a böngészőt akár egy desktopon is lehet üzemeltetni. Van overhead, igen, nem optimális megoldás, igen. Fejlesztőként viszont nekem fontosabb, hogy milyen gyorsan avul el a tudásom. Szívesen tanulok meg egzotikumokat is, ha az feltétlenül szükséges egy munka elvégzéséhez. Már csak azért is, mert adhat egy másfajta nézőpontot, amit a mainstream-től sose kapnék meg. De attól még nem feltétlenül szívatom magam olyan felesleges dolgok megtanulásával, amelyekre néhány éven belül várhatóan csak egy szűk rétegnek lesz igénye.
Annak a megítélését pedig, hogy a desktop mennyire halott és a javafx mennyire felesleges, másra bízom, mert nem áll szándékomban a saját jövőképemet / ízlésemet másra erőltetni. Mindenki döntse el maga, miben látja a jövőt. A zsákutcákat úgy általában én elkerülném. Pláne akkor, ha az embernek erősen korlátozott a rendelkezésre álló ideje. Még egy ok, hogy fókuszáltan, a lehető legrövidebb idő alatt a lehető legszéleskörűbb ismeretetet szedje fel.
Aki meg szeret kockáztatni, az kinézhet magának egy ritka egzotikumot, arra építve, hogy senki sem tanulja, mert mindenki utálja, igény viszont van rá (elavult banki mainframe-en futó szoftverek megvannak?), és majd jó zsíros fizetést lehet elkérni a melóért. Annyira egyénfüggő, hogy mi a jó választás, ki mit szeret.
--- szerk.: Az android / ios ugyanez az általános vs céleszköz téma pepitában. Egy androidon is van böngésző, ergo egy webapp azon is működik, és zéró android ismeret felszedése kell hozzá.
-
Szmeby
tag
válasz
Csaby25
#11220
üzenetére
Minimális. Inkább java és javafx tudás szükséges hozzá.
Javafx-ben is van lehetőség xml-ben felépíteni a gui-t (és abban is ajánlják), de a html ismeretekből itt szinte semmi sem hasznosítható. Legfeljebb a gondolkodásmód.
A css inkább lehet hasznodra, azt támogatja, de ebből is inkább az alap, standard megoldások. Egy desktop app kinézetét nyilván nem befolyásolják a böngészőspecifikus megoldások. Ellenben van benne egy rakás javafx-specifikus megoldás.Bár egy javafx alkalmazáson belül hozhatsz létre WebView-t, ami egy böngészőt emulál, és abba dobhatsz be html, sőt javascript kódot, de ez marginális fícsör. Aki javafx-et használ nem azért teszi, hogy böngészőt futtasson a hasában. Arra ott a natív böngésző.
-
Szmeby
tag
válasz
mateo91
#11212
üzenetére
"Most azt csináltam hogy ezt az eclipse mappát töröltem."
Persze, miért ne, pótalkatrész!
Azt nem tudom, hogy eclipse mappa nélkül hogyan tud működni, mivel az adja a felhasználói felület vázát (ezekszerint mégsem), de örülök, hogy sikerült működésre bírni.eeepc: Az ilyen kompakt cuccokkal óvatosan kell bánni, mert a vas okozhat kompatibilitási problémákat. Nem is olyan régen volt egy NASom, szerettem volna jávát telepíteni rá, amikor is kiderült, hogy ARM proci van benne és max csak valami kiherélt, butított jávát támogat. Az Intel procival szerelt változatot kellett volna vennem, mert azon nagyobb eséllyel működnek a PC-re készült programok.
A másik lazábban kapcsolódó sztori, hogy egy huszonvalahány éves PC-re sem sikerült már bármit telepítenem, sőt egyre kevesebb dolgot, mert annak a procija ugyan intel, de nem támogatja pl. az SSE utasításkészletet, és úgy tűnik az egy rendkívül fontos dolog. Szóval csak azt akarom mondani, hogy kockázatos PC-re írt szoftvert használni egy nem "igazi" PC-n, mert nem biztos, hogy működni fog. -
Szmeby
tag
válasz
mateo91
#11209
üzenetére
Valóban, a program java9-ben íródott, és eclipse guit használ. Ami hibát dobott induláskor. A hiba oka ismeretlen, az egyetlen nyom a screenshoton a rejtélyes 8096-os exit code. Egy gyors keresés nem hozott nekem semmi értékelhető megoldást rá, tulajdonképpen bármi IS okozhatja. A jre-t is hozzá csomagolták, nem valószínű, hogy a rendszerre telepítettet használná, így annak újratelepítése hasztalan.
Azon gondolkozom, vajon ez az ediag program logolja-e működését, mint minden magára valamit is adó szoftver. Én elsősorban az ediag könyvtár bugyraiban keresnék olyan fájlt, ami log fájlra utal. Abból feltehetően kiderül, hogy mivel nem tud megbirkózni a progi. Az oprendszer temp könyvtárának ürítését sok helyen említik, mint lehetséges megoldást, de ezzel értékes nyomokat is elveszíthetsz... például, ha kiderül, hogy az alkalmazás ott gyűjtögette a log fájlokat.
A log fájlok tipikus lelőhelye még a user.home dzsungele lehet. A dokumentációban, használati utasításban illene ilyesmiről tájékoztatást nyújtani, szóval abból kideríthető, hogy hol kell keresni a megoldást.Mondjuk szerintem a legegyszerűbb megkérdezni a szoftver supportot. Mondja meg a gyártó, hogy mi szokta okozni az alkalmazásában az ilyen jellegű hibát, vagy mondja meg, hogyan lehet kideríteni azt.
Esetleg még azon gondolkoznék el, hogy mi változott a gépen azóta, hogy a program működött. Valami új szoftvert telepítettél, vagy valamit frissítettél? Driverek például. Bármi, amit ez az ediag feltehetően használ, potenciális hibaforrás lehet. Ahogy egy hirtelen áramszünet, bad sector, kiskutya füle által okozott sérülés egy kritikus komponensben, vagy magában az alkalmazás fájljaiban is okozhatja. A sérült fájlokat újratelepítéssel lehet orvosolni, ha valóban az a gond. Csak hát sötétben tapogatózva nincs tuti megoldás.
-
Szmeby
tag
válasz
#20238798
#11179
üzenetére
Szia!
A java és a javascript két külön világ. Talán van a javascriptnek is itt topikja, nem tudom.
Mindenesetre, ha ez egy nodejs script (márpedig az), akkor neked először fel kell telepítened a nodejs nevű alkalmazást. Guglizz rá, egyértelmű. Letöltöd, telepíted, és ha már úgyis a weboldalán jársz, javaslom, olvasd el a "hogyan használd a nodejs" dokumentáció első néhány bekezdését, hogy képbe kerülj, hogy tudod a scripted működésre bírni. Feltételezem egy parancssorba kell majd bepötyögnöd néhány parancsot esetleg néhány kapcsolóval díszítve... na meg a script nevét megadni.
Véletlenül feltölteni?
Hogyan? Nem ítélkezem, csak vicces. -- szerk.:
Meg is találtam itt a dokumentációban.
Ez a parancs, rendkívül bonyolult:node az-en-scriptem.js -
Szmeby
tag
válasz
togvau
#11180
üzenetére
Én inkább a Hibernate-re gyanakszom (vagyis az általad választott aktuális JPA implementációra), ő rakja össze az sql-t. A spring csak egy plusz réteget húz köré. Ezért is gondoltam azt, hogy az egyik megoldás egyből a hibernate-et szólítja meg, míg a másik átfolyik még néhány springes optimalizáción. Habár a spring egyik és másik modulja is képes gyökeresen eltérő "optimalizációkat" végrehajtani ugyanabból a kiindulópontból.
Szerintem sem sikerültek a legjobbra a hibernate default működési módjai ilyen-olyan esetekben, de tudod, ez ízlés dolga. A kedvencem, hogy Set, List, Collection, stb típusok esetén ceteris paribus teljesen eltérő lekérdezéseket rak össze végül. Külön öröm volt ezt debugolni.
Más fejlesztő más problémával meg örül neki, hogy pont úgy működik az általa összerakott izé, ahogy azt elvárja. A show_sql-nek nincs oka, hogy hazudjon.Megtanultam már, hogy minden hibernate által összeállított query-t le kell ellenőrizni, mert orbitális hülyeségeket, optimalizálatlan megoldásokat tud összerakni a háttérben. Vagy csak nekem vannak furcsa igényeim, ki tudja.
Örülök, hogy a fetch megoldotta a problémát.
Optimalizálj és jó lesz. -
Szmeby
tag
Azért mindennek van határa!
A stream api és a lambdák nem azért léteznek, hogy másképp is lehessen for ciklust írni.Azért használunk steam apit, mert komplexebb műveleteket is egységbe zár, kis túlzással atomi műveletként tudunk rá tekinteni. Más szóval nincs mellékhatása, ezért szeretjük. Nyilván, ha valaki nem jól használja, akkor lehet mellékhatása, és néhány esetben a fordító meg is fogja ezeket a hibákat, ahogy az látható. Sajnos más esetekben nem fogja meg. Ez szintén látható a legutolsó kinyilatkoztatásból.
Mellékhatásnak tekintünk minden olyan változást a futó program állapotában, ami a monadon (az az egység amin pl. a stream műveleteket alkalmazod) kívül történik. Ezt most jó hülyén fogalmaztam meg, remélem érthető. Tehát az, hogy például a foreach-en (mapen, filteren, stbn) belül egy akármilyen azon kívül eső változó értékét buzeráljuk, az mellékhatás. A lambda nem nyúlhat a saját scope-ján kívül. Elméletben. Gyakorlatban persze meg lehet tenni, csak igénytelen kódot eredményez. Mellékhatásokkal. Értelmét veszti az egész koncepció. Nem véletlenül ragaszkodik a fordító is ahhoz, hogy final dolgok legyenek a lambdában behivatkozva. Final, tehát nem változtatható. Egyszer értéket kap és úgy marad. Ha neked nem így struktúrált a kódod, akkor nem a lambda a jó megoldás. Vagy átstruktúrálod úgy, hogy jó legyen, ez már egyéni preferencia kérdése.
Légyszives ismerkedjetek meg a monad fogalmával, mielőtt ilyen gusztustalan bűnöket követtek el.
Addig meg légyszi maradjatok a for ciklusnál. Az tökéletesen fog működni. Mert annak nem célja a mellékhatások kiküszöbölése. Bár nem néztem át tüzetesen a problémás kódot, de a hiba környékén lévő szándék számomra azt mutatja, hogy ott a for ciklus a gyors megoldás. -
Szmeby
tag
válasz
ReSeTer
#10871
üzenetére
Néhány egyszerű példa:
String[] valami = { "ez", "az", "amaz" };System.out.println(valami[0]); // ezString az = valami[1]; // azSystem.out.println(valami[2]); // amaz
Egy lépésben építettem egy 3 fiókos szekrényt és mindegyik fiókba tettem 1-1 szót. Ezekre a fiókokra a szögletes zárójelben lévő számmal tudok hivatkozni és tudom felhasználni a bennük tárolt szavakat, például értékül adhatom egy másik változónak, vagy kiírhatom konzolra, stbstb. Vedd észre, hogy nullától számozódik. Próbáld ki más számokkal is.String[] masValami = new String[4];masValami[0] = "ez";masValami[1] = "az";masValami[2] = null;
Itt az első lépésben csak létrehoztam egy 4 fiókos szekrényt, de üresen. Ezt követően tettem valamit az első (0) és második (1) fiókjába. A harmadik fiókba (2) explicite null-t tettem, a negyedik fiókhoz (3) nem nyúltam, de annak az értéke is null. Egy üres fiókban null van.String[] megintMas;megintMas = new String[]{ "ezt", "csak", "ilyen", "terjengősen", "lehet" };megintMas[1] = "CSAK";
Itt először csak jelzem, hogy lesz egy fiókos szekrényem, de nem tudom, mekkora. A második sorban jönnek létre a fiókok (5 db), amiket fel is töltök. Az utolsó sorban pedig a második fiókban (1) lévő szöveget lecserélem arra, hogy "CSAK".
Játsz vele, kombináld, nézd meg, hogy mi működik és mi nem. Sok sikert.Ja igen, nem csak Stringgel működik, hanem más típusokkal is:
int[] szamok = { 4, 2, 3, 9 };szamok[0] = 8;int ketto = szamok[1]; -
Szmeby
tag
válasz
ReSeTer
#10871
üzenetére
Jól gondolod, ez a helyes szintaxis. A
String[] valami = {"ez", "az", "amaz"};neve az, hogy tömb, vagy ahogy a művelt francia mondaná: array. Olvass utána, igazán változatos egy jószág.Ha a
String változónéva cipősdoboz, amibe tehetsz egy valamit, akkor aString[] változónévlehetne a fiókos szekrény valahány meghatározott számú fiókkal és mindegyik fiókba tehetsz egy valamit.A te konkrét példádban ez egy 1 db fiókkal rendelkező szekrény, aminek a fiókjában pihen az "értékebetűkkel" String, de attól még nem cipősdoboz.
-
Szmeby
tag
Azt hittem, már valami alter irányzat kezdett kibontakozni clean code-nak csúfolva magát.
Valószínűleg az én angol tudásom kopott meg, de ebben sem látom a tiltást. Persze kiemelhetném a "not to write" kifejezést az egészből, és ignorálhatnám az ezt körbevevő bekezdések tartalmát, de miért is tennék ilyet!Szerintem érdemes elolvasni a teljes fejezetet, ha még nem tetted meg. Különösen azokat a részeket, ahol azt ecseteli például, hogy totálisan felesleges leírni a kód mellé/alá/fölé, hogy mit csinál, mert az olvasó ezt amúgy is látja, viszont például azon ritka esetekben, amikor a miért kérdésre adandó választ kívánja megörökíteni a fejlesztő, a mögöttes szándékot, amit semmilyen más nyelvi eszközzel nem lehetne egyszerűen megmutatni, akkor érdemes ezt megtenni, hogy megkönnyítsük az olvasó dolgát. Persze a gányolást is lehet kommentben magyarázgatni, de a könyv többi része azt szajkózza, hogy ne gányolj, szóval...
Az általad idézett "not to write" arról beszél, hogy ha szépen írod meg a kódot, akkor a kommentek elhelyezése is szükségtelenné fog válni, mivel feltételezzük, az olvasó tud alapszinten jávául és minden szükséges információt megkap a konstansok, változók, metódusok és osztályok elnevezéseiből, struktúrájából.Semmi sem fekete vagy fehér, így tudathasadásról sem lehet beszélni, hiszen értjük az ajánlás mögötti szándékot és aszerint cselekszünk. A clean code szerintem meg amúgy sem szabály, hanem ajánlás.
A public api javadoc meg más tészta, az a feladata, hogy röviden összefoglalja a mögöttes funkció lényegét és tájékoztasson a használat módjáról, megspórolva az olvasónak a forráskód böngészését... de erről a többiek is sokat írtak.
-
Szmeby
tag
válasz
Orionk
#10797
üzenetére
A CV-be mindig az igazat írd, de nem szükséges részletezni a számodra hátrányosnak vélt (pl. 1 év java) dolgokat. Majd az interjún részletezed, ha érdekli őket vagy ha te tartod fontosnak, ahol már amúgy a lelkesedésed is látják.
Plusz a CV-ben szabad helyet szorítani egy pár mondatos bemutatkozásnak, ahol leírod a céljaidat, fejlődés, Spring tudás mélyítése, stbstb.
Persze addig se hagyd abba a tanulást, gyakorlást.
-
Szmeby
tag
SajatClass sajat = new SajatClass();try {sajat.futtat();} finally {sajat.ment();}
Ha kivétel történik a futtás során, a mentés akkor is megtörténik. Ez inkább javallott, mint a finalize() funkció használata. Vagy akár a sima metódus szekvencia. Mondjuk ha hiba esetén mégsem szeretnél menteni, akkor felejtsd el, amit írtam, arra tényleg jó a szekvencia.Neked nem kell kézzel semmit sem takarítani, a garbage collector majd teszi a dolgát, nincs destruktor. De ezt már írták.
-
Szmeby
tag
Java konfigurációk esetén nekem először a properties fájl ugrik be, faék egyszerűségű textfile kulcs-érték párokkal. Lásd mondjuk: [link]
Ennek "modernebb", spórolósabb változata a yaml, de ha neked az ini tetszik, biztos az is jó. Mondjuk ha nem kötött, hogy csak ini lehet, én ezért nem hoznék be egy libet, hogy néhány konfig cuccot tároljak.Nincs az a metódus, ami megfut, ha azt mondod a programnak, hogy kill.
Persze ha normál terminálásra gondolsz, akkor izé... nem értem a kérdést.
A main metódus a be és kilépési pont. Megírod a kezecskéddel, hogy milyen esemény hatására terminálódjon a programod, és előtte azt mentesz, amit akarsz.Esetleg a jvm shutdown hook-ra gondoltál? Lehet haszna, de nézz utána, hogy mikor hogyan működik, mert egy egyszerű programnál én nem biztos, hogy szórakoznék vele.
---
Trubad Úr. Én szívesen megcsinálom neked. 1M HUF lesz.
-
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. -
Szmeby
tag
válasz
#68216320
#10728
üzenetére
Csak annyit tudok a prjektedről, amennyit most leírtál róla, így lehet, hogy valamit félreértek.
1. Én most microservice bűvkörökben élek és a selfcontained alkalmazás a kedvenc, vagyis semmit sem vágok, cserébe viszont pici a cucc, és nincs benne ui. Természetesen a komponensek közti kommunikációt megvalósító DTO-kat, külön, közös projektbe teszem, hogy mindegyik komponens ugyanazt lássa.
Ha látod értelmét a vágásnak (mert mondjuk több egymástól eltérő modul is használná), akkor vágj. Ha nincs értelme, akkor ne vágj. A legrosszabb, amit tehetsz, hogy túl korán vágsz és később szívsz, hogy hát lehet, nem is ott kellett volna, ajaj.
A több UI, több modul felállás szimpi.2. A tesztet. Nincs hibátlan osztály. A tesztet. Leginkább párhuzamosan. TDD. Mondtam már, hogy a tesztet?
Amúgy meg a te dolgod, ahogy jobban esik. Főleg, ha a teszttel kezded.3. Ha valami nem komplex, én nem frameworközök, mert csak megköti a kezet, lassít, bonyolít. Amúgy passzolom a kérdést, nem tartom magam frontend gurunak. Persze lehet az, hogy mondjuk valaki csak az angulart ismeri és semmi mást, neki érezhetően könnyebb dolga lesz abban megcsinálni, mint szenvedni egy fura jsp-vel.
4. Ne származz le.
Oké, hogy a nyelv megengedi, de attól még nem jó.
Én nem osztom azt a nézetet, hogy ami úgy néz ki mint egy kacsa és olyan hangot ad ki, mint egy kacsa, az egy kacsa. [link]
Az egy másik osztály.
Ha mégis van némi közük egymáshoz, akkor még a composition-t tudom elképzelni, vagyis az osztály egy tagja lesz a meglévő cucc, és az osztályod csak az értelmes mezőket engedi ki az apiján. -
Szmeby
tag
válasz
floatr
#10714
üzenetére
// givenUniverse universe = Universe.getInstance();long expectedLivingBeingCount = universe.getLivingBeingCount() / 2;// whenuniverse.getInfinityGauntlet().apply(InfinityStone.MIND).checkStonesAvailable(InfinityStone.values()).snap();// thenAssert.assertEquals(expectedLivingBeingCount, universe.getLivingBeingCount());
Hát, nem túl kényelmes ez a forráskód szerkesztő. -
Szmeby
tag
válasz
floatr
#10708
üzenetére
Oh, az első kérdést nem olvastam, az már tényleg nem lenne egyszerű.
Ilyesmire gondoltál?
Persze ha a pánikkeltés a cél, akkor biztosan cifrázható tovább. String[] arrayOfStrings = { "alma", "körte", "banán", "cseresznye", "áfonya" };
String longest = Arrays.stream(arrayOfStrings)
.collect(Collectors.maxBy(Comparator.comparing(String::length)))
.orElse(null);
(a kedvedért több sorba törtem )A reduce nekem valamiért testhezállóbb volt, talán azért is, mert ritkán használok spéci collectorokat. Hirtelen nem is tudnám most rövidebben leírni collectorral, és ezt már én is túlzásnak érzem. Ízlés dolga. A for ciklus a tuti, azt mindenki érti és villámgyors.
-
Szmeby
tag
válasz
#68216320
#10704
üzenetére
Egy adott fajta kód vagy stílus azok számára nehezen olvasható, akik nem szoktak hozzá. Kezdőként én is nehezen dekódoltam, hogy mi van. Aztán megszoktam és már nem nehéz.
A fenti kód nyúlfarknyi. Ebbe belemagyrázni azt, hogy ez azért nem jó, mert lehet nem nyúlfarknyit is írni, hát, jó, de a fenti kód továbbra is nyúlfarknyi marad, minden más csak a kivetített félelmeid. Vagy valaki más félelmei, nem célom személyeskedni.
A lambda nem egy kalapács, hogy mindenre IS használható, ahogy egyébként semmi sem az, nincs ultimate weapon minden problémára. Természetes, hogy a 200 soros förmedvényt nem egy lambda blokkban kódolja le az ember, hanem elgondolkozik, hogy miért lett ez 200 sor, aztán egyszerűsít, absztrahál, és kitalál egy a probléma megoldására optimálisnak tűnő módszert, stílust, eszközt, stb. Ami nem KELL, hogy egyáltalán tartalmazzon lambdát végül.A lambda (meg lényegében a stream api) azért jó, mert egységet képez, egy komplexebb folyamatot is atomi egységbe zár, nincs mellékhatása, ergo "bugmentes". Ha matekosabb beállítottságúnak érzed magad, olvass kicsit a monad-ról. Ha kevésbé matekosnak, akkor inkább ne, nehogy eret vágj magadon.
Nyilván ezt is el lehet cseszni, ha mondjuk egy a lambdán kívül létrehozott listát piszkálunk a lambda belsejében, annak már lesz mellékhatása, de az nem is a lambda hibája.Én személy szerint azért nem szeretem a stream apit, mert lassú. Egy forEach lassabb egy for ciklusnál, és ez engem időnként zavar.
Nehéz debugolni? A régi eclipse valóban elég körülményesen működött, a closure környezetének csak egy részét látta. Hogy most jól működik-e, nem tudom. Mint mondtam, nem illik 200 soros lambda törzseket produkálni, és akkor nem kell debugolni sem. Problem solved. Érthető, hogy a határidő szűkössége miatt folyamatosan megy a
gányolás... khm... képződik tech dept, de akkor is a fejlesztő felelőssége marad, hogy jól olvasható kódot produkáljon a végén. Ha valaki elég igénytelen arra, hogy egy egyszerű lambda kifejezést túlbonyolítva ott hagy, refakt nélkül, oké, de nem az eszközt kellene ilyenkor hibáztatni az olvashatatlan és debugolhatatlan kód miatt. Gondolom.
Egyébként meg a 200 soros blokk metódusba szervezésével és egy jól irányzott method ref beillesztésével máris nagyot léptünk előre a tisztánlátás útján. Az már más kérdés, hogy sok esetben ez csak a probléma elfedésére jó és nélkülözi az igazi optimalizálást.Az olvashatóságot egyébként tengernyi más dolog is befolyásolja, csak hogy a legkézenfekvőbbet említsem, a nevek. Ha semmitmondó változó és metódus neveket használ a fejlesztő, akkor az olvasó arra kényszerül, hogy belenézzen a metódusba. Ha kifejező neveket használ, akkor erre nincs szükség. Innentől kezdve meg már teljesen mindegy, hogy igazi metódusokat, vagy névtelen metódusokat használunk a megoldásban. De akkor sem illik túlbonyolítani egy lambda kifejezést.
--------
@floatr: Sajnos nem értem a kérdést, kifejtenéd? A reduce egy darab string optional-t ad vissza, azon nem tudok már sokmindent gyűjtögetni. -
Szmeby
tag
-
Szmeby
tag
válasz
floatr
#10679
üzenetére
Hú, köszi. A google-nél csak a pricing calculatort találtam meg, ott meg egy falat szót nem ejtettek ezekről a free limitekről. :/ Ígéretesnek tűnik, kipróbálom.
(Nem én fogom majd üzemeltetni, ezért is fontos, hogy ne kezdjen el egy váratlan pillanatban kiszámlázni dolgokat az ingyenes időszak lejártával. Még ha pár dodó is lenne az, akkor se.)
-
Szmeby
tag
Létezik most a piacon olyan cloud szolgáltató, ami ingyen tud biztosítani egy minimál szolgáltatást?
Gondolok itt olyasmire, hogy mondjuk futtatnék egy java backendet, valamilyen frontendet (jsf, angular, tökmindegy), és legyen mögötte egy akármilyen DB pár MB tartalommal. A frontendre mondjuk havi 1-2000 request eshet be, és szinte zéró processzoridőt vagy memóriát használna. Egy jegyzettömb szintű alkalmazást képzelj el.
Nézegettem az aws-t, de ott a 12 hónapos akció lezárultával mintha esszenciális komponensek válnának fizetőssé. A lambda és a dynamodb marad free, de jól gondolom, hogy ezekkel a frontend már nem lesz elérhető?
A Google AppEngine még a másik kiszemeltem, de basszus, kívülről képtelen vagyok eldönteni, hogy ezzel most meg lehet oldani a free időszak lejárta után is vagy sem.
Akinek van tapasztalata a fenti, vagy akár más cloud szolgáltatók terén, mutasson irányt, melyikkel nem fogok csalódni? Köszi. -
Szmeby
tag
válasz
Vesporigo
#10658
üzenetére
A szortírozós kérdésem inkább elgondolkoztató jellegű volt. Ha tudod, hogy egyéb esetekben milyen díjszabást kell alkalmazni, akkor azt a konstruktort kell meghívnod és az objektumot visszaadnod, ami azt a díjat számolja ki.
De látom, hogy sikerült megoldani, úgyhogy nem ragozom tovább. Grat! -
Szmeby
tag
válasz
Vesporigo
#10652
üzenetére
Ha tudod, hogy az 1 a Kwak, 8 az Iki, és a 9 pedig McChip, akkor azt is illene tudnod, hogy az összes többi esetben (0, 2, 3, stb) micsoda. Nos, ezt a bizonyos
new MicsodaPhoneNumber()-t fogod azokban az esetekben visszaadni.
Mi a célja az első karakter szerinti szortírozásnak?Megj. 1: Stringeket ne hasonlíts össze egymással az
==operátort használva, mert hibás eredményt kaphatsz, aString#equals()javasolt helyette. De akár maradhatott volna char is az a firstLetter. Mindezektől függetlenül aString#startsWith()picit átláthatóbbá tenné a kódot.Megj. 2: A System.exit() nem szép, ne nagyon szokd meg. Majd amikor tanulsz az Exception-ről, egy világ tárul ki előtted.
Megj. 3: Az
== trueelhagyható. Az== falseis, amennyiben használod a!operátorral jelzett tagadást. Vagy egyszerűen else if helyett csak simán az else kifejezést használod (persze ez esetben meg kell cserélni a két külső blokkot, és a végén lesz a hibás formátum jelzése, de ez semmit nem változtat a működésen).Megj. 4: Jávában a változók neveit kisbetűvel kezdjük, ez egy ilyen konvenció.
Megj. 5: Ha megfigyeled, hogy minden if blokkod ugyanúgy végződik (
return phoneNumber;), akkor felmerülhet a gondolat, hogy felesleges annyiszor megismételni azt, elegendő az összes if blokk mögött elhelyezni, csupán egyszer, az eredmény ugyanaz lesz. -
#10405
Szmeby
tag
E.Kaufmann
#10401
Szmeby
tag
válasz
E.Kaufmann
#10401
üzenetére
Vagy megragadod a farkánál a rekurziót.
Mondjuk pont nem tudom, hogy a jáva mit csinál vele, de a skála szereti. -
Szmeby
tag
válasz
#68216320
#10220
üzenetére
Nem igazán így néz ki. A sequence csak egy futósorszám. Tehát tényleg csak egy szám van benne... az éppen aktuális érték. Ha elkéred tőle az értéket, automatikusan növeli magát eggyel (vagy neked kell növelned kézzel... kinézem ezt a mysql-ből). Ha mindenképpen táblaként akarod elképzelni, akkor van egy oszlopa, neve mondjuk legyen value, és van egy sora, abban az érték pedig 6, mert mondjuk a 6 volt az utoljára kiosztott id.
Lásd az oldal alján.Szóval találkoztam már pár helyen ilyen megoldással... bár az oracle volt, nem mysql, de a concept ugyanaz, globálisan egyedi id. Nyilván nem kötelező minden táblán ezt használni, táblák egy csoportján is lehet, meg létrehozhatsz több sequence-t, más-más csoportoknak... ahogy a domain megköveteli.
Bár a hozzászólások alapján úgy látom, ebből 1 fő tábla lesz.
-
Szmeby
tag
válasz
#68216320
#10217
üzenetére
"Viszont ekkor az autoincrement id a mysql-ben csak egy táblára lesz érvényes, azaz lenne 1-es id-val tv és mosógép is."
Nem kötelező a táblákra bízni az id generálást, autoincrement használata helyett csinálhatsz az adatbázisban egy sequence-et (vagy sequence table-t? nem tudom, mysqlnél milyen eszközök állnak rendelkezésre), és az entitásaid abból szedhetik majd a next id-t.
-
Szmeby
tag
Pedig részben de, komoly volt.
Fiatal, frameworkökön nevelkedett fejlesztő, aki még sosem érzett ingerenciát arra, hogy jobban beleássa magát a java nyelvbe, és eddig a munkája során sem szembesült olyan problémával, amihez szüksége lett volna ilyen tudásra... és a nyolcas számrendszer csak egy bugyuta példa volt, nyilván vannak a jávának ennél kevésbe szembeötlőbb furcsaságai. Szóval sem igénye, sem kényszere nem volt még rá, ellenben tudja mi az a solid és mellesleg bármit összedob neked springben fél óra alatt. Nyilván nem ő fog a csapatból beágyazott kódot írni, de bizonyos szinten mindenki csak rétegtudással bír. Van, aki meg a GC lelkét ismeri kívül belül, de szenved a jsf-fel. Ezért nehéz megmondani valakiről, hogy milyen is a tudásszintje, ha nem konkretizálod az igényeket. Főleg, hogy nem is igazán a tudás számít, hanem a szorgalom (szerintem). Annyira változik a világ, hogy többet ér az adaptív mint az okos. -
Szmeby
tag
válasz
b_alazs
#10181
üzenetére
Szia Balázs,
sokféle nézőpontból meg lehet közelíteni a tudásszintet és annak méregetését, esetleg tudnád konkretizálni? Ha nem, akkor parancsolj, itt egy rakás, ami felméri, mennyire vagy járatos a jáva (sötét) lelkivilágában.
Nekem még nem volt igényem a tudásszintem méregetésére, szóval nagyon nem is tudnék mást mondani. Esetleg annyit, hogy járj el állásinterjúkra, a cégek majd felmérik a tudásszinted. Mert attól, hogy valaki kívül-belül érti a jávát, még nem feltétlenül lesz értékes a munkaerőpiacon... ha mondjuk nem látott még springet vagy ee-t. Ellenben magas tudású fejlesztők vakargatják a fejüket olyanon - ha először találkoznak vele -, hogy a System.out.println(013) miért 11-et ír ki a konzolra.
Szóval nehéz a tudásszint meghatározása, mondhatni szubjektív. -
Szmeby
tag
válasz
Victoryus
#9898
üzenetére
Ez a leírás kicsit kaotikus lett számomra. Mi az elvárt eredmény? A "feldolgozni" elég elvont fogalom. A tömb / HashMap vs. típus problémát sem igen értem.
Amúgy meg a szép megoldás olyami lenne, hogy van számla objektumod, ami tételek listáját tartalmazza. Van tétel objektumod, aminek van neve, mennyisége, egységára, nettó összege. A kedvezmény tipikusan külön tételként jelenik meg, de aggregálhatod is az aktuális tétellel, vagy akár bevezethetsz egy kedvezmény típust is (ami kísértetiesen fog hasonlítani a tétel típusra).
Soronként beolvasod a fájlt, létrehozol egy új számla objektumot, minden sornál egy új tétel objektumot, F esetén a számla objektum kész, bedobod egy listába és jöhet a következő friss számla.
Ezt lehet cizellálni, elindulni OOP irányba, hogy nem soronként jön létre tétel, hanem már létező nevű tételnél csak a meglévő mennyiségét növeled eggyel. Vagy elindulhatsz a minimalista irányba, nincs tétel objektum, hanem a számla fenntart egy map-et, a kulcs a tétel neve (String), az érték pedig a darabszám (Integer), és azt növelgeted szükség esetén.
Végül a kedvezményszámítás már könnyen megy, ha előállt a számlán az összes tétel, mennyiségtől függően kiosztasz nekik egy-egy egységárat, és abból már számolható lesz a nettó. Akár on-the-fly, nem nehéz számítás. -
Szmeby
tag
válasz
garage112
#9879
üzenetére
Szia, gyakorolj tovább, mert ez nem java.
Viccet félretéve. Azt már tudjuk, hogy mit kellene csinálnia, viszont nem írtad le, hogy ez helyett mit csinál.
Persze nem is fontos, hogy leírd nekünk, hiszen neked kell megértened. Javaslom, vegyél elő papírt, ceruzát, és szépen, apró lépésekben járd végig az utat egyesével, hogy a változók milyen értékeket vesznek fel, és a while, ill. for ciklusok feltételei igazként vagy hamisként térnek vissza. Minden egyes körben. Nyugi, nem lesz sok.
Legalább egyszer végig kell szenvedned magad ezen, hogy megértsd, mi miért történik. Később már könnyebb lesz.Ha megvan fejben, hogy mit csinál, akkor már csak azt kell kitalálnod, hogy a feltételekben lévő matekot hogyan kell átalakítanod, hogy az elvárásaid szerinti eredményt produkálja. A ciklusokban az a jó, hogy csak az első és a végső állapotot kell jól kimatekoznod, a kettő között az inkrementálás elvégzi a többit. Hajrá!
(Feltételeztem, hogy a nyelvi elemek működésével tisztában vagy, vagyis hogy mit csinál a while és for ciklus , meg az increment úgy általában.)
-
Szmeby
tag
Hogyan lehet vizsgálni, ha egy Objektum példánya létrejött (van, létezik)?
if (myObject != null) {
System.out.println("myObject objektumom létezik, hivogathatom a metódusait");
} else {
System.out.println("myObject objektumom nem létezik, ha ráhívok egy metódusára, NullPointerException a jutalmam");
}vagy
if (myObject instanceof String) {
System.out.println("myObject objektumom létezik, sőt azt is tudom róla, hogy String típusú, így bátran Stringgé castolhatom");
}Ha eleve String típusú a myObject változód, akkor felesleges instanceof-olni.
Pl.:String myObject = "kiskutya";
A bal oldalon jelölve vagyon, hogy ez legalább egy String, és mivel a java erősen típusos nyelv, compile error figyelmeztetne, ha valamit elcsesztél volna.Object myObject = "kiskutya";
Ebben az esetben nem lehetsz teljesen biztos benne, hogy ez egy String (annak ellenére, hogy erről a nyilvánvaló példáról ordít, hogy az), de ha szeretnéd String-ként kezelni, akkor castolnod kell mielőtt meghívod rajta a String osztély metódusait ((String)myObject).isEmpty(); Ha pedig ezt biztonságban szeretnéd elvégezni, akkor a castolás előtt érdemes csekkolni egy instanceof-fal, hogy valóban String van-e benne.
A null nem String, a null nem is Object, a null semmi. Az instanceof mindig false-szal fog visszatérni egy null referenciára, mert a semmiről nem lehet eldönteni annak típusát.És ha létrejött a példány, akkor még lehet null tartalmű, amire hogyan kérdeznétek rá? (azon túl, hogy kiteszed egy lokális változóba, ahogy az előbb írtad (ha nincs más, marad ez a módszer, csak elég bénácskának néz ki a kezdő szememnek))
Ha létrejött a példány, nem lehet null.Kiteheted lokális változóba, ha úgy kényelmes:
String product = info.getProductString();
if (product != null && product.equals("CM STORM INFERNO GAMING MOUSE")) {
System.out.println("match!!!");
}De nem kötelező, használhatod a gettert is újra meg újra:
if (info.getProductString() != null && info.getProductString().equals("CM STORM INFERNO GAMING MOUSE")) {
System.out.println("match!!!");
}De akár meg is mókolhatod a lekérdezéskor, hogy kiküszöböld az API hülyeségeit:
String product = info.getProductString() == null ? "" : info.getProductString(); // ez egy ternáris operátor, egyfajta kompakt if: ha a getter null, akkor üres stringet használ helyette, különben meg a getter által visszaadott nemnull értéket
if (product.equals("CM STORM INFERNO GAMING MOUSE")) {
System.out.println("match!!!");
}A java könyvek, vagy pl. az oracle tutorial relatíve korán elmagyarázza a java objektumok, referenciák, nullitás témakörét, érdemes rászánni azt a kis időt.
-
#9803
Szmeby
tag
Philips103
#9802
Szmeby
tag
válasz
Philips103
#9802
üzenetére
Szia,
linux, windows, micsoda? Amikor azt mondod, hogy letöltötted a javat, akkor jre-t vagy jdk-t töltöttél le? Tök jó, hogy eddig eljutottál, már nem sok van hátra. Ha letöltötted, telepítsd is fel.
A jdk_home nekem egy környezeti változónak tűnik a neve alapján (bár azok nagybetűsek szoktak lenni és nekem JAVA_HOME rémlik), ha az, vedd fel. A jdk1.8.0_171 érzésem szerint nem egy fájl, hanem egy könyvtár, és ott találod, ahova azt a bizonyos javat feltelepítetted. Keress rá. Az elérési utat kell megadni a környezeti változóban.
Bár nem használom, de a Netbeans ugyebár egy fejlesztőeszköz, ami megkönnyíti a java programok írását, és mint olyan, szüksége van a jdk-ra, amivel a kódot lefordíthatja. Tudnia kell, hogy hol találja. Ha csak sima szövegszerkesztőben írnál programot, akkor neked is szükséged lenne a jdk-ra, amivel a java osztályaidat bájtkódra fordíthatod. Nem a Netbeanstől lesz java programod, hanem a jdk-tól, a NB csak egy segédeszköz.A suliban nem mondja el a tanár, hogy hogyan készül a java program? Miért nem? A tanárt kérdezted már a problémádról? Miért nem segített?
Én, amikor kérdést teszek fel, igyekszem nem pongyolán fogalmazni, mert tudom, hogy ha én nem veszem a fáradságot arra, hogy minél jobban megértessem a problémám másokkal, más se veszi a fáradságot, hogy dekódolja a mondandóm.
Amúgy:
https://www3.ntu.edu.sg/home/ehchua/programming/howto/JDK_Howto.html -
Szmeby
tag
válasz
korte73
#9797
üzenetére
A harmadik opció a láncolt lista használata. Magad is összerakhatsz egy primitív implementációt belőle, ha tilos használni a feladathoz a LinkedList és hasonló beépített megoldásokat.
Szerk.: De tény, hogy a leggyorsabb és kézenfekvőbb inicializálni az eredeti tömb méretével... esetleg a végén - amikor már ismert a végleges méret - átmásolni egy pont passzoló méretű tömbbe az eredményeket.
-
Szmeby
tag
válasz
Taoharcos
#9777
üzenetére
A szerző állítása szerint a cikkek dedós szinthez íródtak. Egyetértek. Viszont rendkívül értékesek is.
Ugyan csak felületesen olvastam, de gyorsan megragadott. Visszaköszönnek olyan nyelvi fordulatok, melyeket réges régen egy C64 prog könyvben olvastam, és gyerekfejjel mennyire lebilincselőnek találtam. Szívesen viszontlátnék egy hasonló stílusban íródott gyerekkönyvet mondjuk java vagy python köré építve. -
Szmeby
tag
Na igen, ezek egy könyv példái. Az oldal tetején a könyv címe, ahonnan a példák származnak: "Java Puzzlers: Traps, Pitfalls, and Corner Cases" Bloch bácsi tollából. Egyébként próbálgatással, gondolkozással idővel rá lehet jönni, csak sok idő, tömény szívás főleg egy kezdőnek, viszont az Aha! érzés garantáltan nem marad el.
A magyar kiadás asszem Java fejtörők: Csapdák, buktatók, akármik néven fut. De szakmai könyvből én nem feltétlenül ajánlanám a magyarított változatokat. Túl sok mindent akarnak benne magyarítani. Talán ennél a könyvnél pont nem is számít - bár magyarul nem olvastam -, a példakódok és a belőle levont tanulságok a fontosak. Viszont szerintem ne is ezzel kezdd, ha még nincsenek meg az alapok.
-
Szmeby
tag
A célod, hogy (jó) java fejlesztő legyél, vagy hogy átmenj egy interjún?
Ha már tudod rá a választ, akkor itt van pár hasznos link, hogy megismerd a java nyelv furcsaságait:
java puzzlers
java tutorials
ocp mock tests
Légy kíváncsi és gyakorolj sokat, nem jelenthet problémát egy interjú, ha értesz hozzá.Egyébként google: java interview questions.
-
Szmeby
tag
válasz
#74220800
#9124
üzenetére
Szuper.
Jól gondolod, az && meg a || shortcut operátornak is hívja magát, ha a feltétel eleje önmagában is meghatározza a feltétel kimenetelét a többi része már fel sem hívódik."De miért nem megy úgy, ha előszór a rekurzív képletet hívom meg ..."
Azért mert a rekurzív hívásnak le kell futnia ahhoz, hogy a feltételben ki lehessen értékelni. De nem fut le. Belemegy a metódusba újra új paraméterekkel, majd azon belül is újra megint új paraméterekkel, és így tovább. A végtelen ciklus miatt csak befelé megy, sose jön ki onnan. Valaminek terminálnia kell, csak akkor jut vissza, akkor tudja azt mondani, hogy true vagy false, az if-ben akkor ki tud értékelődni, és lefutna a programod.
Nézd át újra a rekurzióról tanultakat. Vagy tényleg tegyél bele egy breakpointot, és - ha Eclipse-et használsz - nyomogasd az F5-öt a flow hívásnál. Ezzel belelép... megnézheted, miben változtak a paraméterek és hogy a hívás meddig jut el a metódusban, mielőtt újra ráhívna saját magára, F5. Nézd közben a stack-et is, minden egyes rekurzív hívásnál egy új sorral bővül.
Ha már érted, vedd ki a breakpointot és F8-cal engedd el, hadd teljesítse be a végzetét. -
Szmeby
tag
válasz
#74220800
#9121
üzenetére
Hali,
mondjuk én első körben nem egyből egy random mátrixszal indítanék, hanem egy kicsit ellenőrzöttebb körülmények között tesztelném a cuccot. Pl. egy ilyennel:
1 1 1 1 1
1 2 2 2 1
1 2 3 2 1
1 2 2 2 1
1 1 1 1 1És akkor debug módban szépen lépkedve kiderítheted, hogy az a baj, hogy először mindig felfelé próbálkozol kijutni, majd ha nem megy, akkor lefelé. Csakhogy a próbálkozásod előtt nem csekkolod, hogy egyáltalán érdemes-e (<x). Mindenképp megpróbálod, így visszajutunk egy korábbi állapotba, ahonnan nem sikerült felfelé kijutni, így azt megpróbálni sem lenne érdemes, de ő csakazértis újra felfelé próbál. Nem tud, ezért megint lefelé indul el. A lefele ágban először újra felfelé indulna, és... gondolom érted, hogy ez a végtelenségig tart, ide-oda pingpongozik a két sor egymással.
Egy ilyen térképpel például szépen működik a progi, mert mindig csak felfelé kell másznia:
1 1 1 1 1
1 2 2 2 1
1 3 3 3 1
1 4 4 4 1
1 5 5 5 1Rekurzív hívásnál nagyon fontos a sorrend, amint tudod, terminálni kell a folyamatot. Érdemes először ellenőrizni, hogy a szomszédos szám valóban jó irány-e, és csak akkor ráhívni rekurzívan, ha tényleg van esély a kijutásra.
----
Apró adalék, hogy egy kis emlékezet bevezetésével, drasztikusan gyorsítható a program. Ugyanis ha számon tartod (pl. egy kimeneti mátrixban), hogy adott cellából sikerült-e korábban kijutni, akkor nem kell újra és újra végigjátszani a teljes útvonal bejárást. -
Szmeby
tag
Nem mintha le akarnék beszélni bárkit is a képzésekről. Sőt, aki nulláról kezdi a jávát (pláne a programozást), neki még érdemes is megtanulni a terminológiát, és az alapvető módszereket, remélhetőleg a képzésen ezt helyesen adják át. Plusz a képzésen szintén ajánlhatnak neki rengeteg könyvet.
De. Akinek már van rendes tapasztalata, én nem igazán vesztegetném a helyében az időt és a pénzt képzésre, ha egy alacsonyabb fizetési igénnyel valamely céghez bekerülve juniorként többet tanul az ember a kollégáktól (jót és rosszat egyaránt), és pénzt is kap érte. Persze azért teljesíteni is kell.Ha szereted csinálni, és fejlődni akarsz, az nagyon jó. Mindenki így kezdi. Ha megvan mellé a kritikus gondolkodásmód is, akkor csak kitartást tudok kívánni. Könyveket már sokat ajánlottak itt a fórumban, keress rá... ha mindet le akarod zavarni, 4-5 hónapnál több időre lesz szükséged.
Csak olvasással nem fogsz sokat tanulni, nem rögzül, csinálni is kell mellette.Hogy akarod-e folytatni, majd a képzés után döntsd el. Miután megvannak az alapok, otthon is folytathatod a saját magad képzését, az ismeretek elmélyítésével, próbálgatással, és annak kiderítésével, hogy mi miért nem működik, ahogy azt elképzelted. Ez arra is jó, hogy rájöjj, a melóban mit csinálnak rosszul.
Ja és tartsd észben, hogy attól, hogy 4-5 hónap SE után belevágsz az EE-be, még nem jelenti azt, hogy az SE-t készségszinten tudnád használni. Ugyanúgy tanulni kell tovább azt is. Mondjuk, ha bármikor sikeresen meg tudnál írni egy OCA/OCP tesztet (neten találsz pár ingyenes mock test-et), akkor lehet azt mondani, hogy az SE kipipálva. De ehhez szerintem fél évnél jóval többet kell szívni a jávával.
-
Szmeby
tag
válasz
#74220800
#9101
üzenetére
Nem egészen.
Van 2 PolyLine objektumod, amit a Bsp10-ben hozol létre polyLine és polyLine2 néven.
Fogod a polyLine nevűt, és ráhívsz az equals metódusára, paraméterként pedig átadod ugye a polyLine2-t.A történések ezután az equals-on belül zajlanak tovább. A korábban polyLine-nak nevezett objektumot az equals-ban a this kulcsszóval érheted el (amit többnyire nem kötelező kiírni, névütközés esetén viszont kénytelen az ember... na mindegy), míg a polyLine2 most már obj néven érhető el. A csavar ott van, hogy az equals szignatúrája csak Object típusú paramétert enged meg, ezért az obj paramétert kénytelen vagy Object típussal definiálni, erről viszont a java már nem tudja, hogy az valójában egy PolyLine objektum, így a spéci metódusaira sem tud ráhívni, és a field-jeit sem látja.
Úgyhogy castolunk, megmondjuk őnagyságának, hogy ez bizony egy PolyLine:
PolyLine other = (PolyLine) obj;
Megjegyzem, most ez így működik, de ha megpróbálsz egy nem PolyLine objektumot betolni, szétszakad az egész, tehát érdemes az equals-ban előbb megbizonyosodni arról, hogy valóban PolyLine-e (getClass() metódus felhívásával, instanceof-fal).Ezekután az other változóról már tudjauk, hogy PolyLine, elérjük minden metódusát és field-jét, például a hasában lévő points listát is. Egy Object esetén ezt nem tudod megtenni. És ezt a listát össze tudjuk hasonlítani a this objektumunk points listájával.
return this.points.equals(other.points);
Rövidebben:return points.equals(other.points);Tehát listát hasonlítunk listával, ezért működik.
Ez nem castolás, csak meghivatkozzuk az objektum egy field-jét.
Castolásnál a változónév elé zárójelben megadjuk azt a típust, amire castolni akarunk, és ezzel aztán azt kezdünk, amit akarunk. Az "other.points" nem tartalmaz semmilyen zárójelet meg típust, ez csak ráhív a points nevű mezőre az other objektumban.A castolás elhiteti a jvm-mel, hogy az adott objektum valójában egy másik típusú objektum. Itt nem változtatunk a típuson, a this és az other továbbra is PolyLine típusú, és mindkettő hasában van 1-1 lista (points néven), amit felhasználunk az egyezőség megállapításához. A points.equals() tehát az ArrayList-en található equals metódus.
Ha a this-t és az other-t hasonlítanád itt össze egymással, az ugyanabba az equals metódusba hívna bele (rekurzió) újra és újra, amiben eleve vagy, és addig pörögne, amíg el nem fogy a stack, majd lehal az egész. Próbáld ki.
És kérdezz bátran.
-
Szmeby
tag
Remek... letelt az időkorlát. -.-
Szóval azt még elfelejtettem, hogy ha Set-re váltasz, akkor a Point.equals mellett a Point.hashcode-ot is implementálnod kell. Az IDE elvégzi helyetted, de a lényeg:
A HashSet úgy működik, hogy a beletolt objektumra először hashcode-ot számol, ez csak egy szám. Ehhez a hashcode-hoz létrehoz egy izét, nevezzük vödörnek, és ebbe a vödörbe dobja bele az objektumodat.
Ha egy újabbat adnál hozzá, akkor arra is hashcode-ot számol, és csak az adott hashcode-hoz tartozó vödörrel foglalkozik, végigmászik a vödör tartalmán, az equals-szal csekkolja, hogy benne van-e már, és ha talált, akkor nem teszi bele újra.
Ha a hashcode számítást elcseszed, akkor előfordulhat olyan, hogy van 2 objektumod, ami az equals szerint azonos, de a hashcode szerint nem. Mindkettő bele fog kerülni a Set-be (!!), mert a másik az eltérő hashcode miatt másik vödörbe kerül. Ilyet sose csinálj.
Vagy például megváltozik az objektumod állapota (mondjuk most nem, mert minden final, de máskor, mással, másnál igen), és a megváltozott állapot miatt megváltozhat a hashcode is. Na az az objektumod, ha benne volt egy set-ben, akkor ott is marad, sose találod meg. Vicces dolgok ezek.
Gondolhatnád, hogy akkor legyen a hashcode mindig 1, abból baj nem lehet. Jó gondolat, de lassú lesz, épp azért szegmentálunk sok kis vödörre relatíve kis számításigényű megoldásokkal, hogy csak egy kis vödör tartalmán kelljen végigsuhanni, gyorsan el lehet dönteni, hogy valami benne van-e abban a Set-ben avagy sem. -
Szmeby
tag
válasz
#74220800
#9096
üzenetére
Ezért ne kövesd el te azt a hibát, amit a java megalkotói, hogy túl általános típust használsz.
Jó, tudom, csak kompatibilitás, de akkoris.Szóval a probléma a PolyLine.equals-ban van. Mivel a szignatúrája szerint Objectet vár, az ember bármit beadhat. És hidd el, be is fog. Amin aztán az egész cucc megfekszik (pl. ClassCastException-nel), ha nem figyelsz. Rosszabb esetben - mint most is - működik tovább hibásan.
Javaslom, minden equals metódusodban ellenőrizni a bejövő paraméter típusát. Ha nem jó típus, akkor false, ha jó típus, akkor pedig tessék castolni, és aztán hasonlítgatni. Könnyebben kibukik, hogy a beadott PolyLine nem is ArrayList, amivel hasonlítani akarod.
Egyébként az equals, hashcode metódusokat egy IDE szépen ki is generálja neked, van rá menüpont.Szóval listát a listával:
public boolean equals(Object obj){
if (obj == this) {
return true;
}
if (obj == null) {
return false;
}
if (getClass() != obj.getClass()) {
return false;
}
PolyLine other = (PolyLine) obj;
return points.equals(other.points);
}Ha nem kellenek az ismétlődések, miért nem egy rendezett Setet használsz erre a célra? LinkedHashSet, vagy valami ilyesmi. Ő magától megcsinálja.
Pár megjegyzés:
- Osztályon belül felesleges gettereket használnod, simán lehet hivatkozni a field-ekre, pl.:return Math.sqrt(Math.pow(this.x - other.x, 2) + Math.pow(this.y - other.y, 2));- Ha az objektum állapota nem változhat, akkor érdemes a field-eket final-ra állítani, így még véletlenül sem fogod tudni tönkretenni az objektumaidat. Továbbá egy ilyen tipikus value object esetén én még a getterek elhagyását is megkockáztatnám, valahogy így:
public class Point{
public final int x;
public final int y;
public Point(int x, int y){
this.x = x;
this.y= y;
}
public boolean equals(Object other){
// ...
}
public double getDistance(Point other){
// ...
}
public String toString(){
// ...
}
}- Ne félj interfészt használni, ahol lehet, könnyebben cserélgetheted majd mögötte az implementációt. Ha nem akarod cserélgetni, akkor sem árt, mert idővel rááll a kezed, és nem kell folyton törnöd az APIt egy kis módosítás miatt.
Erre gondolok:private ArrayList<Point> points = new ArrayList<Point>();
// helyett
private List<Point> points = new ArrayList<Point>();
// esetleg (attól függ, milyen funkcionalitást vársz el tőle, legyen-e rendezett, stb)
private Collection<Point> points = new ArrayList<Point>();- Ciklusban Stringeket konkatenálni + jellel nem szép dolog, brutálisan pazarló. Minden egyes konkatenáció egy újabb és egy újabb Stringet hoz létre, amit aztán a következő körben el is dob, mert csak átmenetileg volt rá szükség. StringBuilder javallott és annak append metódusa. Vaaagy használod a listák toString metódusát, mert van.
-
Szmeby
tag
válasz
#74220800
#8886
üzenetére
Igen, lehet. Bármit bárhol kiírhatsz a konzolra. Még a metódus neve is azt sugallja, hogy írni fog a konzolra. Meg ez csak egy vacak iskolai feladat. Ha így kérik, hát így kérik. Adj neki!
Az, hogy mivel tér vissza, int, void, kiskutya, ettől teljesen független. Nem fáj neki az a print.Megjegyzem, kicsit zavaró lehet az utolsó szám (j), mivel az nem egy prím, hanem egy darabszám lesz. A kiírásnál én azt jobban elkülöníteném. Akár mondjuk egy külön sorba írva (println), vagy valami extra felvezető szöveggel. Sőt, mivel a metódus ezt a számot ki is adja magából, talán a hívó megoldja a kiírást, nem? Persze ha a feladat kifejezetten azt kéri, hogy a prímek után írd, akkor nincs mese.
Továbbá egy apróság:
Ha olyat látsz, hogyif (valami == true) {
akkor az pontosan ugyanazt jelenti, hogyif (valami) {
mivel a 'valami' egy boolean, és az utóbbi a szebb megoldás.Ugyanez tagadással is:
if (valami == false) {
szépenif (!valami) {A 'valami' tehát egy boolean változó neve, és ezeket úgy szokás elnevezni, hogy egy eldöntendő (igen/nem) kérdést takarjon. Például: isValid vagy hasValue, stb, akkor a teljes feltétellel kiolvasva értelmes mondatot kapsz: if (isValid), vagy if (!hasValue). Jobb nem lesz tőle a kód csak szebb. És ha az olvasható változatot szokod meg, az csak a javadra válik később. Meg a leendő kollégáidnak is több hajszála marad.
-
Szmeby
tag
Ha már amúgy is végigszambázol az összes gombon, akár meg is számolhatnád, hogy melyek enabled flag-je false. Ha létezik setter, akkor csak van rá mód, hogy le is tudjuk kérdezni annak a gombnak az állapotát.
Valahogy így:btn[i].isEnabled()Nem biztos, hogy van ilyen metódus, csak betippeltem. De valamilyennek lennie kéne. Ezekután könnyű megszámolni már lokálisan is, hogy hány gomb esetén false ez az érték. És ha kisebb, mint 5, akkor az eventben érkező gombot már nagyobb magabiztossággal fogod állítgatni.
Persze az is járható út, hogy a false-ra állításkor növelgetsz egy számlálót, ami csak egy sima instance változó a frame objektumon. De ha amúgy is bejárod a tömböt minden event érkezésekor, akkor majdhogynem mindegy.
Ami biztos, hogy neked kell megszámolnod. Vagy így vagy úgy. Vagy a tömb bejárásával vagy egy gombra kattintós event érkezésekor. Amelyiket hatékonyabbnak, biztosabbnak érzed.
-
#8768
Szmeby
tag
Chesterfield
#8767
Szmeby
tag
válasz
Chesterfield
#8767
üzenetére
Továbbá javaslom a datetime api "of" nevű factory metódusait, van belőlük egy rakás, pl.
LocalDateTime.of(localDate, localTime) -
Szmeby
tag
Ha mindenáron le akarod szűkíteni a kört az alapvető dolgokra, Java esetén vedd például az OCA (Oracle Certified Associate) vizsga anyagát. Az Oracle oldalán is egészen jó tutorial van, és önszorgalomból még mélyebbre áshatsz a java elcseszett bugyraiban.
Apró kiegészítés, hogy ehhez azért programozni is tudni kell, tehát az OCA tananyag nem tartalmazza azokat az általános technikákat, hogy mi fán terem az iteráció, a szelekció, ahogy az alapvető algoritmusokat, adatszerkezeteket sem tárgyalja (rendezések, fák, stb).Nagyon alap dolgokat magyaráz, viszont a Java rengeteg irritálóan logikátlan működésére is rávilágít. Már ha igazán beleásod magad. Az OCP egy szinttel tovább lép, de igazából csak még több alap osztály működéséről regél. Véleményem szerint talán túl is tolja ezt, az IDÉk világában nagyon nem érdemes fejből vágni a StringBuilder összes metódusát. Mert minek. Ott a forrás, megnézem, fél másodperc, és ennyi.
De ha nagyon bele akarod ásni magad, hát kezdd a java.lang.* package osztályaival, aztán jöhet a java.util.*, java.util.concurrent.*, stbstb. De totál felesleges.A programozás reál tárgy, nem kell semmit beseggelni, mint a történészeknek. Az összefüggéseket kell ismerned. Nem az a lényeg, hogy fejből vágod, mennyi 4*5, hanem az, hogy ki tudod számolni. Vagy pl. nem kell ismerned, hogy az int -2147483648-tól 2147483647-ig tud számokat ábrázolni, hanem tudod, hogy a byte 8, a short 16, az int 32 biten tárolja az adatokat, amiben egyenlő arányban van negatív és pozitív, a nullát pozitívnak számítva. Kis matek és kijönnek a számok.
Nincs rajz. A szakmánk annyira gyorsan változik, hogy a rajz is folyamatosan változna, emberenként totál eltérő. Arról nem is beszélve, hogy az emberiség nagyon kis százaléka rendelkezik olyan memóriával, ami hiánytalanul visszaadna neked egy korrekt rajzot.
Akik ebből élnek, az általuk használt dolgokat már annyiszor guglizták ki, hogy megjegyezték. Ha idővel kevesebbet használják az adott dolgot, lassan elfelejtik, kikopik, megfeljebb újra rákeresnek, ha újra előjön. Ettől függetlenül nem hátrány, ha mesterien használod a keresőt, mert szükséged lesz rá. Ez így on-demand működik. Képtelenség mindent megtanulni. Az adott projekt dönti el, hogy mit kell használnod. Nekem például totál leépült a java.io tudásom, pedig rendkívül hasznos cuccok vannak benne... viszont évek óta a közelébe sem néztem. Elfelejtem, ennyi. Majd újra előjön, ha használnom kell. Ott a forrás, a javadoc, tutorialok, stackoverflow, google ...És igen, jó ha előre felkészülsz, hogy specializálódni fogsz, nem feltétlenül egy dologra, de fogsz. Mint mondtam, a világ összes ideje sem elég arra, hogy minden területen naprakész legyél.
Ha csak azt nézzük, hogy a youtubera másodpercenként több órányi anyag kerül fel, ugyanilyen rémisztő a helyzet az új programnyelvek, frameworkök, technológiák területén is. Teljesen felesleges megtanulni valamit, amit nem használsz, időt energiát és pénzt pazarolsz vele. Főleg, hogy az összes szinte ugyanaz más köntösben. Kitalálnak egy új nyelvet, ami egy másik hibáit hivatott javítani, cserébe viszont más hibákat hoz be. A hiba alatt inkább a kényelmetlen, körülményes használatot értem. Egyik nap trendi, megismered, megtanulod, másnap már egy másik nyelv a favorit. Unaloműzésnek tökéletes, arra, hogy szélesítsd a látókörödet, kiváló, találkozhatsz érdekes, hovatovább hasznos megoldásokkal, de pusztán azért, hogy majd egyszer talán lesz haszna és használni is fogod, elárulom: nem lesz.Majd a projekt eldönti, hogy mit lesz a jó választás. Adott problémához kell keresned megoldást, és nem a megoldásokat bemagolni. Egyik nap kiderül, hogy Scalaban mennyivel hatékonyabb megoldani xy-t, és lényegében dobhatod a kukába mindazt a java tudást, amit csak azért szedtél fel, mert hátha jó lesz valamire. Ez persze erős sarkítás, de a magolással töltött időt hasznosabban is eltölthetted volna.
Szóval ha megvannak a programozás alapok, akkor már csak egy megoldandó problémát kell keresned / csinálnod, majd arra prezentálni egy jó megoldást, alaposan körüljárva a témát, kisakkozva, hogy mi miért úgy van, ahogy. Meg hogy hogyan lehetne rajta még többet javítani, teszemazt lecserélve az ArrayListet LinkedListre, vajon mennyivel javul vagy romlik a performancia, stb. Bátran használd a keresőt, idővel majd úgyis megtanulod a gyakran használt dolgokat.
Aztán talán felébred benned az igény az igényes kód előállítására is, megismerkedsz a tervezési mintákkal, Bob bácsi clean code irányelveivel, úgy gondolom ezek sokkal időtállóbbak, mint egy 86-ik framework ismerete.
-
Szmeby
tag
Az megvan, hogy a hónap+nap önmagában nem egy dátum?
Nem mindegy, hogy melyik év, már csak a szökőév miatti torzulás miatt sem. Nem tudsz rajta műveletet végezni, ha nem tudod, hogy a február 28 vagy 29 napos. Ha meg nem végzel rajta műveletet, csak nézegetni kell, akkor minek a dátum típus? String is lehet, vagy valami saját készítésű, az évvel megengedőbben viselkedő típus.
Szóval az a kérdés, mi a célod a parzolt értékkel.Szerk.: Most látom csak, a javasolt MonthDay egész használható cucc, még nem volt hozzá szerencsém. A februárt szépen konzisztensen kezeli.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- HiFi műszaki szemmel - sztereó hangrendszerek
- Elektromos rásegítésű kerékpárok
- Drón topik
- Házimozi haladó szinten
- Spórolós topik
- Tőzsde és gazdaság
- Suzuki topik
- Székesfehérvár és környéke adok-veszek-beszélgetek
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- További aktív témák...
- Thinkpad X230 legenda: i7 CPU, IPS kijelző, 12 GB, dupla SSD, magyar villbill, webcam, fingerprint
- Honor X6b 128GB Kártyafüggetlen 1Év Garanciával
- Apple Watch SE2 / 44mm / Midnight / Black Sport / Cellular (99%)
- Iphone 13 Pro Max 128 GB /// 86% Akku // Számlával és Garaniával
- Iphone 12 Pro Max 128 GB /// 88% Akku // Számlával és Garanciával
- BESZÁMÍTÁS! MSI B450 R7 7 5700X 32GB DDR4 512GB SSD RTX 2080 8GB Fractal Design Define R5 FSP 750W
- Eredeti, új Lenovo 330W töltők - ADL330SDC3A
- AKCIÓ! Apple Macbook Air 13" 2020 M1 8GB 256GB SSD notebook garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone i7 14700KF 32/64GB RAM RTX 4070 Ti Super GAMER PC termékbeszámítással
- Lenovo ThinkPad X270 (16) - i5-7300U, 16GB, 512GB SSD, 12" FULL HD
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest