- M0ng00se: Hardvert áruhitelre?
- droidic: EA GAMES – élő emberrel a supportban 2025 ben
- sziku69: Szólánc.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- Elektromos rásegítésű kerékpárok
- sziku69: Fűzzük össze a szavakat :)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- eBay-es kütyük kis pénzért
- bambano: Bambanő háza tája
Új hozzászólás Aktív témák
-
#68216320
törölt tag
Milyen megoldással lehetne egy külső program konzolba írt tartalmát parse-olni?
Van egy linux-os programom, ami bizonyos szenzorok adatait az alábbihoz hasonló módon adja vissza a konzolba kiírva:
... (néhány sor sima text elötte)group1.data1.value1: 123456group1.data1.value2: valamiszoveggroup1.data1.value3: 123.01group1.data2.value1: valamiszoveggroup1.data2.value2: 123456group2.data1.value1: 123456group2.data1.value2: 123456group2.data2.value1: 123456group3.data1.value1: 123456...A lényeg, hogy minden tag új sorban van, a variable neve pontokkal van, a value lehet string, int, float.
Szeretném bizonyos időközönként (30 másodpercenként) lefuttatni ezt a külsős exe programot és a visszakapott értékeket db-ben tárolni.
Mivel volna érdemes nekikezdeni?
Az exe futtatásban, a visszakapott értékek parsolásában kellene segítség.
Db kezelés nem gond. -
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.
-
-
Orionk
senior tag
válasz
fatal`
#10796
üzenetére
Sziasztok,
Elnézést kérek, ha ez nem pont ehhez a topichoz kötődik, ezért off-ba teszem.
Segítséget szeretnék kérni, tanácsot a tapasztaltabb Java fejlesztőktől, interjú jelentkezéssel kapcsolatban.
Szoftverfejlesztésben 2.5 év tapasztalatom van, ebből ipari környezet 2év.
Ebből Java fejlesztésben 1 - 1.5 év tapasztalat. Karrieremet mostantól Java fejlesztéssel és ahhoz kötődő technológiákkal képzelem el.
Most nyit a városunkban irodát egy szoftverfejlesztő cég, akiknek Budapesten már van irodájuk ~350 fős fejlesztő részleggel.
Java és azon belül Spring fejlesztőket keresnek. A Seniorok után már kevesebb tapasztalatú embereket is elkezdtek keresni. Springgel még nem foglalkoztam, de 1 hete már elkezdtem tanulni és szeretnék sokat fejlődni, Standard Java tudásom folyamatosan fejlődik, angol nyelvvel pedig folyékony tárgyaló szinten vagyok.
Felhívtam a HR részlegüket és azt mondták, hogy adjam be a CV-t, de kicsit azt éreztem, hogy csak azért mondják, hogy minél több emberről legyen adatuk és azzal nem veszítenek, ha plusz egy ember beadja, mert az a biztos.
Mit javasolnátok, hogyan lenne érdemes érzékeltetni a CV-ben, hogy bár nem látnak tapasztalatot Springről, de tényleg érdekelne és fejlődni szeretnék benne és így Java-ban is ?
Azon aggódok, hogy ha nem érzékeltetem a CV-ben, akkor fel sem hívnak, nem hívnak be, mert nincs Spring tapasztalatom és alap Java-ból is kicsit több tapasztalat kellene.
köszönöm szépen. -
aquark
tag
Sziasztok!
Szeretném könyvekből meg a netről megtanulni a Javat profi szinten. Még nem tudok programozni semmilyen nyelven, és az angollal is eléggé hadilábon állok. Sikerült több Magyar nyelvű könyvet, jegyzetet is beszereznem, de ezek legalább 10 éves kiadványok, szerintetek ezek mennyire használhatóak?
-
floatr
veterán
válasz
bandi0000
#10788
üzenetére
Egy rakat technológia frameworkje, jobbára nyúlás a kurrens "alternatív" frameworkökből. Ez mondjuk nem lenne baj, legalább ad neki egy standard keretet. A fájó igazság viszont az, hogy kihalóban van, és a "jobbik eset", amikor meglévő kód supportjára keresnek embereket. Amikor kerestem melót, a kapuban fordultam vissza, amint kiderült, hogy EE. Bár ez csak az én hülyeségem...
-
Drizzt
nagyúr
válasz
bandi0000
#10788
üzenetére
Ja, a Java EE egy framework. Egy jó nagy adag specifikáció halmaz, amit különféle app szervereknek kell implementálnia, hogy Java EE compliant-ek legyenek. Régen elég kínszenvedés volt a Java EE, orrba-szájba kellett örökölgetni mindenféle framework classból. Viszont idővel megjelent az annotation based configuration, elkezdtek egyre szeparáltabbak és önmagukban is életképesek lenni a komponensek. Így ma szerintem egyébként egy nagyon jó framework a Java EE, de tény, hogy a Spring mellett nem valószínű, hogy hosszú távon túlélő lesz. Én nem örülnék neki, ha eltűnne. De ennek főleg az az oka, hogy jelenleg ebben vagyok a leginkább otthon. Springet még csak tanulom. Illetve most főleg Kubernetest, meg Helmet, mert most épp az kell a melóban, de igyekszem visszanyergelni a java-ra.
Szóval az hátránya a Java EE-nek, hogy heavyweight runtime környezet kell hozzá, de ebben is fejlődik.
De érdekes, pl. szerintem a CDI event handling sokkal szebb, mint a Springes.
-
bandi0000
nagyúr
-
#10786
-Faceless-
őstag
-Faceless-
#10785
-Faceless-
őstag
válasz
-Faceless-
#10785
üzenetére
Semmi, kár volt éjszakázni.
Ha gondoljátok lehet törölni -
#10785
-Faceless-
őstag
-Faceless-
őstag
Sziasztok!
Nem javaztam már évek óta, de most egy projekthez csináltam egy Kerteshaz.java fájlt ami benne van a Haz package-ben, és le kellene fordítanom a varos.jar fajllal együtt.javac -cp -g varos.jar Kerteshaz.java
fordításra viszont mindenhol "package does not exist"-et kapok. Nem tudom, hogy én csinálok valami nagyon basic dolgot rosszul, de az éjszaka már megpróbáltam egy Windows-os, egy Linux-os gépen a szükséges java verzióval, google keresésre elolvastam az első 3 oldalnyi találatot, és legalább 10-szer átnéztem elírás után, de semmit nem találtam.Rendkívül hálás lennék, ha valaki tudna esetleg segíteni
-
aDtG
tag
Sziasztok!
Adott egy könyvtár/mappa, ahol fájlok találhatóak. Szeretném a mappában található fájlok nevét, méretét, esetleg még más adatait is tárolni. Fontos lenne, hogy a névhez tudjam párosítani a többi adatot.
Miután feldolgoztam őket, szeretnék velük dolgozni is, tehát a JAVA programomban használnám is ezeket az adatokat.
Mit ajánlanátok leginkább? Mivel a legcélszerűbb ezt megoldani?Köszönöm szépen
-
bandi0000
nagyúr
Sziasztok
Kicsit belezavarodtam ebbe az EJB-be, hogy mire is való, mire is használják ,valaki el tudná mondani nagy vonalakban?
Néztem udemy-s videót róla, ez valamiféle dependency injection lenne?
+ Van ez a Lokal és a Remote? annotáció, magyarázta a különbséget köztük, de nem nagyon jöttem rá, hogy valós alkalmazásba mire való
-
coco2
őstag
válasz
floatr
#10779
üzenetére
Akkor egy kicsit vakarom a buksit. A bugfix és hasonlók időszakosak - amennyire a hírekből ki tudtam olvasni - akár fizet valaki, akár nem, nem kap gyorsabban semmit, mint a többiek. Frissítés és hasonlók a rendszergazda dolga, az Oracle miért foglalkozna azzal? Szóval nagyon nem értem én, miért is kapna az Oracle pénzt bármelyik cégtől, ha csak nem valami függöny mögötti sumák végett.
-
coco2
őstag
Sziasztok!
Van itt valami, amit mindig tudni akartam a java-ról, de sosem mertem megkérdezni. Vagy valami olyasmi.
A java-nak már van fizetős verziója is. Azzal az sdk-val felépítek egy alkalmazást. Utólag a jvm vagy a felhasznált offici libek vonatkozásában olyasmi derül ki, hogy trojan jutott be az alkalmazásba. Üzleti károkozás is történik annak kapcsán. Vállalni fog azért az Oracle üzleti felelősséget? Konkrétan kártérítés. Igen / Nem ?
-
A praxisomban ilyesmivel még nem találkoztam. Standard nyelvi eszközről nem tudok (legalábbis Java 8-ig bezárólag) - ettől persze még létezhet. A probléma viszont nyilván nem megoldhatatlan. Az első lehetőség a java fordító meghívása (lásd az előző hozzászólást), majd a gyártott osztály dinamikus betöltése (mint a JDBC driver-nél) és végrehajtása. Lásd pl. itt. Ennél a megoldásnál az a korlát, hogy a fordítási egység az osztály. A másik lehetőség, ami eszembe jut, a byte kód manipuláció (bytecode instrumentation), amivel lehet turkálni a már lefordított osztályok belsejében (új eljárásokat hozzáadni, meglévőeket kiegészíteni, stb.) Lásd pl. itt. Elképzelhető, hogy vannak ezekre alapozva kész megoldások is, bár én egy gyors kereséssel nem találtam ilyet.
Én nem vetném el teljesen a script nyelveket sem. (Bár nem tudom, hogy pontosan mi a feladat...
) A Groovy nagyjából felülről kompatibilis a Javával (azaz a Java forráskód érvényes Groovy forráskód is), legalábbis kb. a 7-es nyelvi szintig, bár a szemantikában vannak apróbb eltérések. A script nyelvek és a java kölcsönösen hívhatják egymást (azaz egy programon belül keverhetők). A script nyelvek mellett szól még, hogy tömörebbek (elhagyhatók a változó deklarációk, stb.), azaz pár soros kódokhoz alkalmasabbak. -
válasz
Szmeby
#10764
üzenetére
A finalize általában nem fog működni:
public class T {
static void p(String msg) { System.out.print(msg); }
public static void main(String[] args) {
p("started"); T t = new T(); t = null; p(" finished");
}
private T() { p(" constructed"); }
@Override protected void finalize() { p(" finalized"); }
}
(Kimenet: started constructed finished)Ha a teszt JVM-emen beszúrok egy GC-t, akkor javul a helyzet:
p("started"); T t = new T(); t = null; System.gc(); p(" finished");
(Kimenet: started constructed finished finalized)De azon túl, hogy egy normális programot nyilván nem lehet telehinteni GC hívásokkal, az egész viselkedés még a garbage collector implementációjától is függ, szóval a finalize egyáltalán nem megoldás a problémára.
-
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.
-
Destruktor nincs. Finalizálás van, de az a garbage collector futásához kapcsolódik, és nincs garancia arra, hogy egy adott objektum esetén valaha is lefut - program exit-kor meg pláne, hiszen akkor majd az oprendszer úgyis takarít...
Nem teljesen értem, hogy minek az exit hook. Egy java programnak jól meghatározott exit pontjai vannak: pl. a
main()return pontja, vagy aSystem.exit()hívás, ezért ha kilépéskor akarsz menteni, akkor ezek elé kell elhelyezni a megfelelő kódot. Ha a program interaktív, akkor nyilván lesz valahol egy "exit" menüpont, vagy window close hook, ahová a mentés ugyancsak beköthető. Ha valamilyen egyéb keretrendszert használsz (pl. servlet engine), ami saját maga intézi a startup és shutdown tevékenységet, akkor ott lesznek specifikus exit hook-ok (pl. a servletnek vaninit()megdestroy()eljárása, vagy ott aServletContextListener).Mint arra fentebb már felhívták a figyelmet, ha a program abnormális módon terminál (kilövik az oprendszerből, vagy pl.
OutOfMemoryErrorkivétel keletkezik), akkor semmilyen exit hook nem fog működni. Ha erre is fel szeretnél készülni, akkor érdemesebb inkább minden alkalommal automatikusan menteni, ha az ini fájlban tárolt adatok változnak. (És ebben az esetben a kilépéskori mentés eleve felesleges is.) Persze nem tudom mi lenne itt az adatkör: az inicializációs fájl mint fogalom, néhány kilobájtnyi ritkán változó adatot sugall. -
Keem1
veterán
válasz
Szmeby
#10760
üzenetére
Nem-nem, egyáltalán nem ragaszkodom az ini-hez (elsőre platformfüggetlenként ez ugrott be), ezt a properties-t is meg fogom nézni (
). Alapvetően ilyenre a registry-t használnám alapesetben, de ugye mint írtam, linuxon is futtatni kéne a cuccost.Szerintem az lesz, hogy:
main(){kezdő();.... // tényleges metódusokvégző();}Alternatíva:
main(){SajatClass sajat = new SajatClass();sajat.Futtat();}
Ahol a külső osztály destruktorába tenném esetleg, vagy valami finalize.Nem bonyolítom túl. Abból akartam kiindulni, hogy hátha lehetne a main-t tartalmazó osztálynak egy destruktort írni, ami felszabadít mindent, és egyúttal a konfig adatokat is fájlba írja. De ahogy olvastam, ilyen nincs. Ugye, nincs?
-
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.
-
Keem1
veterán
válasz
sztanozs
#10755
üzenetére
Nem muszáj, csak javasolt. Olyan ez, mintha a Google-nél nem Google eszközöket használnának
PHP-ban is gondolkodtam, de vannak bizonyos policy-k, amik nem teszik lehetővé a webszerver futtatását a szervereken. Nem vagyok benne biztos, hogy Python környezet van-e. Java tutira van, így emiatt választottam azt.
-
Keem1
veterán
Üdv! Kényszerűségből ugyan, de ismerkednem kell a Java nyelvvel. Készítenem kell egy kis toolt, ami szervereken futna.
Kronológia:
- Java-t tanultam a suliban, kb. 15 évvel ezelőtt
- PHP-t és C#-ot használok viszonylag rendszeresen (nem vagyok programozó, de időnként szükség van rá, munkahelyen különböző toolokat készítek)
- alap programozási tudás megvan, de a Java-t nem ismerem nagyon
- miért kell nekem most mégis Java? Vannak Win és Linux alapú szervereink is, és a toolnak futnia kéne mindegyiken anélkül, hogy rendszerenként kellene fejleszteni a toolt.A készülő mini tool adatait ini fájlban tárolnám, ehhez a ini4j library lesz a segítségemre. Nem biztos, hogy jó ötlet, de indításkor betöltöm a tárolt adatokat, futás közben dolgozom velük. A program futásának végén pedig diszkre írnám az ini adatait.
Kérdés:
- milyen metódus fut le mindenképpen a program terminálása előtt, amit felhasználhatnék azini.store(configfile)futtatására?
- van-e jobb megoldás arra, hogy a konfigurációs adatokat másképp mentsem, az előző kérdésben foglalt helyett?Előre is köszi!
-
válasz
Taoharcos
#10749
üzenetére
Ha van olyan oszlophalmaz, amiből lehet kulcsot képezni (azaz pl. lehet(ne) rájuk unique indexet definiálni az adatbázisban), akkor az ezen oszlopoknak megfelelő objektumváltozóból lehet összetett kulcsot (composite key) gyártani. (Pl. az
@EmbeddedIdannotációval.)Ha Oracle az adatbázis, akkor lehet próbálkozni azzal is, hogy a ROWID-et rámapeljük valamilyen dummy változóra:
@Id @Column(name="ROWID") String id;
(Magam sohasem próbáltam, de lekérdezésnél akár működhet is... Persze a hordozhatóságnak ilyenkor annyi.) -
axioma
veterán
válasz
Szmeby
#10743
üzenetére
Egy kicsit a kodminoseghez. Ez is olyan, hogy at lehet esni boven a lo tuloldalara. Lassan mar hulyenek nezes esete forog fent, amikor rankeroltetik a 16-os complexity-t (vayg mennyire van allitva), nem beszelve az abbol adodo extra feladatokrol (a complexity miatt letrehozott kulon fuggvenynek vajon kell-e ujra parameter-ellenorzest csinalnia, es a unit test-jenek kell-e olyan eseteket is lefednie, ami az egyetlen hivasi helyen nem fordulhat elo?). Szoval en egyetertek az elvekkel altalaban, de nagyon durva amikor valaki nem azt nezi hogy milyen egy masik - az adott feladattal megbizhato! ha valami komplex cucc kozepe, akkor nem egy most esett ki a bootcamp-bol - fejleszto megerti-e, hanem hogy a szintetikus pontozassal mibe tud belekotni.
Nyilvan ez nem jelenti azt, hogy nincs szarul megirt kod. Csak hogy neha annyira de annyira tullihegik... en 20+ ev multtal pont nem tudnam felsorolni a solid betuszo feloldasat, ettol fuggetlenul azert lehet megis annak megfeleloen dolgozni. Kicsit olyan mint a torvenyek betartasa: egyreszt a torveny a tarsadalmi normak osszegyujtese, megfogalmazasa; masreszt meg senki nem tudja beteve a BTK-t, megis tud esetekrol zsigerbol jo ertekelest adni. A solid is nem csak ugy kinott es tanitjak, hanem a "termeszetesen" kialakult best practice-nek egy szaraz, es megis gumiszabaly osszefoglaloja. Kb. arra jo hogy indokolni tudd, hogy a masiknak (vagy plane kezdonek) az elkepzelese miert nem jo, de nem ugy adsz ki tervet a kezedbol hogy elotte gyorsan leellenorzod, hogy vajon stimmel-e minden betu.
Szerintem. YMMV. -
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. -
M_AND_Ms
veterán
válasz
Szmeby
#10741
üzenetére
"Hmm. Azt hiszem, te többet láttál bele a kérésbe, mint én."
Ez igaz....én csak a vaskalapos, merev és felesleges kérdéseket nem szeretem...
"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?"
Megkérdezném a kérdést feltevőt, hogy valóban, ezt az interjúra szánt 10 percet akarja arra felhasználni, hogy megtárgyaljuk, mitől lesz szép egy java kód? Vagy inkább ténylegesen ki akarja deríteni fogok-e tudni hatékonyan együtt dolgozni abban a csapatban, vagy annak az élén ahova épp embert keresnek. Mert pl én azért vagyok épp ott, hogy megtudjam ezt (a java kódkonferenciára ki se öltöztem volna).
Hála égnek, ilyen interjún nem voltam soha, és nem is voltam kényszerhelyzetben, hogy bele kellet volna mennem ilyenbe...Eddig mindig egy kötetlen, informális beszélgetésbe csöppentem, ahol a szűk szakmai dolgokról nem volt szó. Alapértelmezett volt, hogy ha kovácsnak jelentkezem és ők kovácsot keresnek, akkor nem kérdés, hogy mindketten tudjuk, milyen a felpattanó szikrába belenézni (ha ez nem így volna, úgyis kiderülne, egy héten belül)
20 éves tapasztalattal a hátam mögött pedig az a véleményem, hogy egy IT projekt legutolsó, szinte lényegtelen része, hogy mennyire szépen, mennyire jó minőségben (sic) vannak implementálva a java osztályok. (nyilván számít a kód milyensége, de nem ezen fogunk elbukni... mielőtt valaki visszadobná a labdát)
"A felhozott példákat én egy lehelletnyit túlzónak tartom"
A példák, mindig valami túloznak... -
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. -
M_AND_Ms
veterán
válasz
Szmeby
#10736
üzenetére
"Konkrétan a hozzászólás melyik részét tartod bullshitnek és miért"
Azt, amit kérnek, hogy felmondjon a jelentkező a hr-esnek, mint a leckét az iskolában. Ez számomra a tudás hibás és teljesen felesleges visszakérdezése: fejből tudni és visszamondani az elméleti anyagot, még "ha álmodból keltenek is fel. " Az ilyen tudás megszerzése jön a "magolásból", és nem a gyakorlatból, vagy a rátermettségből. Ez alapján tuti nem a megfelelő és alkalmas embert fogják felvenni.
A tapasztalatom (20 aktív IT, + 10 év egyéb terület) az, hogy az elméleteket halmozó emberek aszok, akik a megbeszéléséken a szót viszik, az elveket hangoztatják és az időt rabolják, de a tényleges munkát már képtelenek elvégezni.
Az ilyen szintű elméleti alaptéziseket nem kell hangoztatni, hanem azoknak megfelelően kell dolgozni. Egy kovács se tudja fejből elsorolni, hogy mi a helyes kalapálás alapelmélete és hogy milyen rácsszerkezetű a vas...egy kovács alkalmazásakor se kell ilyeneket kérdezni ... Vagy egy anesztes orvosnál se kérdeznek az állásinterjún olyat, hogy miből, mennyit adagol a lumbális érzéstelenítésnél és azt milyen szempontok alapján dönti el. -
#68216320
törölt tag
Azt hiszem megkeveredtem picit a Model és DAO/DTO fogalmakkal. Ha DTO-t használok a perzisztens rétegem és a service között, akkor azt csak ott használhatom? Például nincs értelme mondjuk view-nak küldeni, igaz? Hiszen tartalmaz számára nem publikus adatokat is. Oda kellene a model, ami csak a user számára érdekes adatokat tartalmazza?
Service-ek között mivel viszek át adatokat? Ott DTO vagy Model van?
És mi van ORM esetén?Picit segítenétek átlátni a dolgot? Keresgélek infot magam is, de csak belekeveredtem eddig
-
Drizzt
nagyúr
Persze hogy nem. De az mas kerdes, hogy erdemes-e, illetve miert. Az esetek nagy tobbsegeben akkor is kell refaktoralni, ha amugy a kod jo. Pl. ha jon valami olyan uj feature, vagy meglevo modositasa, ami a refaktoralas eredmenyekeppen sokkal egyszerubb lesz, dinamikusabb, kivulrol konfiguralhato, vagy neha epp fixebb, merevebb. Nem veletlenul van tele a refaktoring katalogus olyan lepesekkel, aminek az inverze is benne van. Az egesz refaktoring az agilehoz hasonloan azert terjedt el es lett fontos modszer, mert az it ipar rajott, hogy feature stability szinte semmilyen realis szoftverfejlesztesi projektben nincs.
-
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.
-
#68216320
törölt tag
válasz
axioma
#10732
üzenetére
Nagyon hasonlóan kezelném őket, de még csakbaz egyik van meg. A különbség köztük annyi lenne, hogy az egyik saját projecten belüli adatokkal jön létre, a másik külső (request) és egyben néhány másik adattal jön létre. A perzisztens rétegben is külön vannak tárolva. Ezen kívül közösen kezelem. Például együtt listázom, stb.
Ennek ellenére semmi akadálya nincs, hogy teljesen külön osztály legyen, hamár külön is tárolom őket.
-
axioma
veterán
válasz
#68216320
#10731
üzenetére
Biztos kozos ososztaly kell neked, nem lenne jobb a kozos interface? Mar persze ha arrol van szo hogy azert szeretned oket valahogy kozositeni, mert kesobb egyforman kezelned a kettot (az egyforma tulajdonsagokkal). Ha most sehol nem kezeled egyutt, akkor meg siman ket osztaly, az nem akadalyozza hogy kesobb kozos interface is legyen, ha valos indok lesz ra.
-
#68216320
törölt tag
válasz
Szmeby
#10730
üzenetére
Köszönöm a válaszokat
1. Akkor lehet annál maradok, hogy minden marad egy projectben. Igazából pont azért kérdeztem, mert jelenleg tényleg nem indokolja semmi, hogy szétszedjem. Csak valahol láttam egy ilyen project-et és gondoltam, hátha ... de akkor nem csinálom egyelőre.
2. Akkor hogy is? A tesztet?
3. Az igazság az, hogy nem ismerek egy framewörköt sem. Tudom, kellene csak próbáltam elodázni. De nagyon úgy tűnik, hogy nincs mese... Angular? Meglesem.
4. Nem túl komplex. Anno úgy olvastam még, hogy ilyenkor ezt kell tenni. Persze tényleg megoldás a 2 külön osztály. Vagy gondoltam, hogy barkácsdolom picit:
- átnevezném az eredeti osztályt
- absztrakt lenne az eredeti osztály
- kivenném az eredeti osztályból azokat a tulajdonságokat, amik nem közösek
- leszármaznék 2 osztállyal belőle. az 1. kapná az eredeti nevet és megkapná a saját tulajdonságát. a 2. kapna egy új nevet és a saját tulajdonságaitÍgy az eredeti néven meglenne az osztályom az eredeti member-ökkel és lenne egy új az új member-ökkel de csak azokkal amik neki kellenek.
Persze lehet marhaság amit akarok, sajnos kuka vagyok még a programozáshoz.Vagy túlkombináltam valamit megint
-
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. -
#68216320
törölt tag
válasz
#68216320
#10728
üzenetére
4. Ha van egy már meglévő model amiből leszármaznék, mert mert az új model tartalmaz még pár tulajdonságot, de van olyan is amit a parent igen, de a child nem, akkor azt hogyan szokás megoldani? Obj esetén mondjuk lehet NULL, de például int vagy boolean esetében mit csinálok vele? Ha adok értéket akkor azt hihetem, hogy az valós.
-
#68216320
törölt tag
Egy saját hobby project kapcsán merült fel pár kérdés, amiben szeretném a közösség véleményét kérni.
1. Maven build-et használok. Mikor szokás parent-child project-et csinálni?
Most van egy parent pom.xml-em, amiben jelenleg két child pom.xml van. Perzisztens réteg és üzleti réteg, de harmadikként menne majd a WebUI még ide (esetleg más UI ha lesz)2. Mit szoktatok előbb elkészíteni? Az osztályt vagy a unit tesztet? Mert ugye ha a tesztet írom előbb, kevesebb esélye van szerintem, hogy bizonyos elemek tesztelése kimarad. Tudom mit akarok csinálni, mik lesznek a funkciói, mik lesznek a paraméterei és ez alapján mik lesznek a buktatók. Ez alapján meg tudnám csinálni az osztályt ami hibátlanul elvégzi a feladatokat. Vagy célszerűbb sorban? Osztály aztán hozzá a teszt?
3. Servlet-WebUI elkészítéshez mit ajánlotok? Nem lenne komplex a feladat, HTML/CSS/JS ismeretem van. Framework vagy inkább valami saját JSP?
-
Drizzt
nagyúr
válasz
Orionk
#10725
üzenetére
Tömör, egy felelőssége van, se többet, se kevesebbet nem csinál mint ami a célja. Magas a koherencia a az adattagok és a metódusok között, meg az összes SOLID principle felsorolása, kifejtése, 1-2 design patternen keresztüli elmagyarázása. Én ezt várnám el egy interjúzótól. Bár juniortól lehet nem ilyet kérdeznék, hanem inkább alapvetőbb algoritmus kérdéseket, adatstruktúrákat.
-
Orionk
senior tag
Sziasztok,
Java junior fejlesztő pozíció interjún azt kérdezték, hogy szerintem milyen egy jó, minőségi Java Osztály implementációja?
Szerintetek mi a minél tömörebb, jó válasz erre? Milyen a jó felépítésű Java Osztály? Ha van köztetek nagyobb tapasztalatú, Senior fejlesztő, akkor milyen felépítésű, tartalmú választ szeretnétek hallani?köszönöm
-
axioma
veterán
Abban a blokkban ervenyes, ahol letrehoztad. Ha bezarod a blokkot, eltunik, es ez pont igy van jol.
Ha kivul is akarod hasznalni, akkor ket dologra van szukseged:
1. kint deklaralni - nyilvan a felhasznalas helyetol fuggo mertekben "kintebb" (ez me'g ugye nem jelent feltetlen ertekadast is)
2. ezutan vagy csak olyan helyzetben lekerdezni, mikor ugyanazon feltetelben vagy (de egyreszt ezert minden normalis IDE kiabalni fog, hogy lehetseges hogy inicializalatlan valtozo, masreszt valoban lehet hogy itt-ott kicsit modositgatva kesobbi igenyek miatt pl. az if-eket ez nem fog mar fennallni), vagy pedig kell neki valami ertelmes ertek akkor is, ha nem az if-en beluli erteket kapja (ugy ertve hogy olyan amit feltetelezve valoban jol fog vegigmenni minden lepes). -
floatr
veterán
válasz
Szmeby
#10709
üzenetére
Ebbe most futottam bele teljesen véletlenül
@Getter@AllArgsConstructorpublic class MinMax {Optional<String> min, max;public static MinMax of(String[] arrayOfString) {var length = comparing(String::length);return stream(arrayOfString).collect(teeing(minBy(length),maxBy(length),MinMax::new));}} -
sztanozs
veterán
válasz
floatr
#10714
üzenetére
public class Dream implements Consciousness {protected List<MindState> inceptors;protected Object thought2Inject;protected Stack<MindState> dreamStates;/* */public String observe(Object o){if (o instanceof Spinner && !dreamStates.empty())return "Spins forever";elsereturn super.observe(o);}} -
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ő. -
floatr
veterán
válasz
sztanozs
#10713
üzenetére
Már rég nem a sebességről szól a dolog
De ha már fun, akkor egy kis kihívás
Adott egy film (vagy bármilyen műalkotás), írjátok meg egy jellegzetes részletét Java-banDeathStar.getInstance()
.getGarbageMashers()
.stream()
.filter(gm -> gm.getLevel().equals(Level.DETENTION))
.forEach(GarbageMasher::shutdown); -
#68216320
törölt tag
Remek végigolvasni ezt a refactor-t
Esküszöm jobb tapasztalat, mint egy tanfolyam.A lambda témához:
Ezek szerint nem ördögtöl való...
Csak tudnám a régi melóhelyemen miért ellenezték annyira? Akkor sem értettem. Azt mondjuk soha nem vizsgáltam, h mondjuk egy forEach lassabb a for-nál. Sajnos nálam kényelmi beidegződés a forEach, használom. -
floatr
veterán
válasz
Szmeby
#10709
üzenetére
Alakul...
A végén szét lehet szerelni komponensekre, és lehet hozzá majd YAML konfigot írniA reduce a legegyszerűbb, de akkor hadd húzzak lapot 19-re
Arrays.sort(arrayOfStrings, Comparator.comparing(String::length));
String shortest = arrayOfStrings[0];
String longest = arrayOfStrings[arrayOfStrings.length - 1]; -
-
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.
-
floatr
veterán
válasz
Szmeby
#10707
üzenetére
Szokás enterprise körökben túltolni a legegyszerűbb dolgokat is. Ha reduce helyett egy collectort használtál volna, no meg persze factory-kat, akkor lehetne kelteni kisebbfajta pánikot a juniorok között
Amúgy az első kérdésére csak egy reduce nem fog megoldást adni, vagy két streamet használsz, vagy egy collectorral párban gyűjtöd a min/max értékeket. De akkor meg minek...
Amúgy szerintem nincsen különösebb baj a streamekkel, amíg olvashatóan és ésszerűen van szervezve. A hármas operátort sokan nem szeretik, mert rontja az olvashatóságot. Én egyedül azt a gányolást utálom, amikor mindent be akarnak szuszakolni egy sorba. Na meg az enterprisify kódot
-
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. -
Lortech
addikt
válasz
#68216320
#10704
üzenetére
A best practice az olvasható kód.
Ez persze bizonyos mértékig szubjektív.
Az olvashatóság lambda esetében még inkább az, erősen függ attól, hogy ki az olvasó. Ki mihez van szokva, kinek már állt rá jobban az agya. Már csak azért is, mert a lambda nem volt mindig alap nyelvi elem, és máig rengeteg kódbázis van, ami nem ilyen szemléletben íródott. Ha a csapat, aki a kódot írja és karbantartja, lambdát preferálja, akkor menjen a lambda, de azért ne ész nélkül.
Az adott problémától függ, hogy lambdával olvashatóbb lesz-e a kód, esetleg hatékonyabb vagy elegánsabb. -
axioma
veterán
válasz
#68216320
#10704
üzenetére
Engem meg code review-n (prod.code) direkt felszolitottak, hogy lambda-sitsak. Szerintem attol fugg, hogy hol mi a szokas, en egyebkent nem tartom olvashatatlanabbnak (csak az adott esetben kovettem a korabbi kodstilust). Szerintem nem art megszokni, peldaul a sonarlint ezt nem veszi elagazasnak es extra bonyolitaspontnak ha jol remlik
-
#68216320
törölt tag
válasz
Szmeby
#10701
üzenetére
Ez mennyire BestPactice? Én még úgy tanultam, hogy próbáljuk kerülni a lambda-t, mert a forráskód nehezebben olvasható majd. Nem "nyúlfarknyi" példákra, gondolok, hanem nagyobb osztályokra például. Persze most nem azt mondom, hogy 1-1 forEach vagy hasonló nem kerülhet bele csak például nálam egy-egy komplexebb sor átláthatósága debug esetén nehezebb/lassabb.
Persze tény, hogy elegánsabbVagy ez teljesen rendben van és marhaságot tanultam?
-
axioma
veterán
Én .NET-ezek, de végülis mindegy.
)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Sütés, főzés és konyhai praktikák
- Windows 11
- Steam Deck
- Az adatközpontok szolgálatába állítja a nap- és szélenergiát a Meta
- Android játékok topikja
- Milyen okostelefont vegyek?
- Bluetooth hangszórók
- Bittorrent topik
- FEJHALLGATÓ / FÜLHALLGATÓ / DAC beárazás
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- További aktív témák...
- Dji Mavic Pro fly more combo
- iPad Pro 11" M4 wifi Silver hibátlan akku 100% 3 hónap jótállás!
- ASUS ROG Strix GeForce RTX 4070 Ti OC 12GB GDDR6X 192bit Videokártya
- RX570-es, RX580-as és RX5500XT eladó videó-kártyák - Garancia
- Canon EOS 1300D gép szettek, objektívekkel, kiegészítőkkel (1400 - 7900 expos gépek, újszerűek! )
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
- LG 32SQ700S-W - 32" VA Smart - 3840x2160 4K UHD - 62Hz 5ms - WebOS - Wifi + BT - USB-C - Hangszórók
- Bomba ár! HP Elitebook 8560W - i7-2GEN I 8GB I 500GB I 15,6" FHD I Nvidia I W10 I Garancia
- BESZÁMÍTÁS! 4TB Samsung 870 EVO SATA SSD meghajtó garanciával hibátlan működéssel
- Csere-Beszámítás! AMD Ryzen 7 9800X3D Processzor!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest