- One mobilszolgáltatások
- iPhone topik
- Íme az új Android Auto!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Szívós, szép és kitartó az új OnePlus óra
- Samsung Galaxy Fit 3 - keveset, de jól
- Honor Magic6 Pro - kör közepén számok
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Fotók, videók mobillal
Új hozzászólás Aktív témák
-
Aethelstone
addikt
Üzleti logika szempontjából az üres lista pont annyit ér, mint a null referenciával rendelkező. Viszont üres lista esetén le tudod spórolni az if (list!=null&&!list.isEmpty()) vizsgálatot egy sima list.isEmpty()-vel, sőt iterátor for ciklusban sem fog szétszállni nullpointerexceptionnal.
Egyébként jelen pillanatban egy kézenfekvő, bár kurvára idegesítő megoldása lenne a problémának, ha a nullpointerexception nem runtime lenne, hanem checked. Persze, az összes, jelenlegi kód összefosná magát tőle
-
Aethelstone
addikt
válasz
beleszólok #6531 üzenetére
Ha már nekem tudtál stackoverflow linket adni, akkor magadnak is kereshetnél.
http://stackoverflow.com/questions/4646577/global-variables-in-java
-
Aethelstone
addikt
válasz
beleszólok #6529 üzenetére
Nos, bármelyik osztályban található public változó (property, adattag, kinek hogy tetszik) globálisnak tekinthető. Az más kérdés, hogy ha nem muszáj, márpedig sosem muszáj, nem definiálunk public változókat. Szerintem.
-
Aethelstone
addikt
Tervezési minta kérdése.
Pl. ha List<?> a visszatérési típus, akkor ugyan fektessük már le, hogy ha üres, akkor nem null, hanem pl. new ArrayList<?>() és így tovább. Vagy pl. default értékek használata a privát propertyk esetén és sorolhatnám.
Sokan nem szeretik az ilyen kvázi felesleges tervezési mintákat, hanem a compilertől várják, hogy a slendrián kódokat tegye helyre...alapvetően sok igazságuk van, de ugyan, az emberi hülyeséget miért kellene már javítani?
Kedvencem egyébként, amikor pl. C-ben vagy Pascalban szól a compiler, hogy hiányzik a ";". Bassza meg, akkor rakja oda, ne dumáljon, az miért nem zavar senkit?
Az a baj, hogy a konkrét problémában valamit mindenképpen vizsgálni kell. A null az valóban rendszeridegen, egy olyan kvázi mittoménmilyen érték, aminek semmi köze az üzleti logikához.
-
Aethelstone
addikt
Végigolvastam és értem is a koncepciót. Nyilván teljes nyelvi támogatás kell ahhoz, hogy igazán jó legyen.
Viszont csak megjegyzésképpen:switch ret {
case None: print "Nincs visszateresi ertek"
case Integer(i): print "Az Integer ertek: " + i.toString()
}switch ret {
case null: print "Nincs visszateresi ertek, mivel null"
case Integer(i): print "Az Integer ertek: " + i.toString()
}Nos, maximum itt annyi van, hogy a "rendszeridegen" null kerül eliminálásra..
-
Aethelstone
addikt
válasz
beleszólok #6502 üzenetére
Rossz a példa. A goto az ördög találmánya olyan nyelvekben, amelyekben lehet mellőzni a használatát. Ahol viszont nem lehet, ott jó. Ennyi.
-
Aethelstone
addikt
válasz
beleszólok #6505 üzenetére
Csak ismételni tudom magam. Nomen est omen...ha érted, hogy mire gondolok.
Arra próbáltam utalni, mégha nem is fejtettem ki az ominózus hozzászólásban, hogy alapvetően nem kérdés, de egyesek képesek vallási kérdést csinálni belőle, pont úgy, mint a politikából vagy a fociból. (Pedig csak az Arsenal
)
Kb. 2 hozzászólással utána kifejtettem pontosan, hogy mire gondolok, de Te azt ignoráltad és azóta is ezen lovagolsz. Részemről zártam.
-
Aethelstone
addikt
válasz
beleszólok #6498 üzenetére
Lehet hitvita, mivel alapvetően a feladat határozza meg, hogy melyiket kell vagy érdemes használni, de ad abszurdum az is lehet, hogy mindkettő jó tud lenni. A programozásban sincsenek kizárólagos igazságok.
-
Aethelstone
addikt
válasz
beleszólok #6496 üzenetére
Most komolyan. Olvasd már el kérlek, amit írtam! Ugyanazt írtam, amit Te. Nomen est omen?
-
Aethelstone
addikt
válasz
beleszólok #6494 üzenetére
-
Aethelstone
addikt
válasz
Oppenheimer #6489 üzenetére
Csatlakozom. Ha ugyanazzal az energiával lehet jót csinálni, akkor miért csinálnánk rosszat?
-
Aethelstone
addikt
válasz
beleszólok #6485 üzenetére
Igazából max annyi, hogy én speciel csak akkor használom a származtatást, amikor a szülő osztálynak valóban felül akarom valami tulajdonságát, metódusát definiálni vagy szeretnék default implementációkat használni a szülőből. A Thread run metódus szerintem nem ilyen történet.
Plusz, inkább implements mint extends
-
Aethelstone
addikt
válasz
Oppenheimer #6479 üzenetére
Teljesen OFF a téma szempontjából, de nem lenne jobb a Thread leszármaztatás helyett egy Runnable-t implementálni? Tudom, ez hasonló politikai/vallási/foci vita, de talán mégis
-
Aethelstone
addikt
válasz
fordfairlane #6465 üzenetére
Ez most komoly?
-
Aethelstone
addikt
válasz
fordfairlane #6455 üzenetére
Egyrészről nem ártana, másrészről meg ártana, mert esetleg nem olyan irányban fejlődik, ami a nyelvnek jó, hanem a konkurrencia hülyeségeit próbálnák beépíteni....lásd lambda....grrr
-
Aethelstone
addikt
válasz
SirRasor #6451 üzenetére
Bármelyik jó a felsoroltak közül. Azt kell választanod, ami jobban tetszik....
(Nekem az Eclipse a személyes kedvencem)
Mi kvázi enterprise környezetben dolgozunk, van itt Eclipse, NB, JIdea....a közös pont a maven project(meg sok egyéb más, de az most nem ide tartozik)
-
Aethelstone
addikt
válasz
Oppenheimer #6445 üzenetére
Ne a Java-t féltsd, hanem magadat, ha még nem találtad ki
-
Aethelstone
addikt
Aztán még kb. 10 év, amíg mögé raknak egy olyan ökoszisztémát, mint amilyen a Java mögött van. Persze, az eddig Java-ban fejlesztett és használt alkalmazások tömegével lesznek eldobálva és pánikszerűen elkezdi mindenki újrairatni az opensource .netben. És persze tömegével fognak a Java fejlesztők is beállni a .net mögé
Mindeközben az Oracle csak a szemöldökét kötögeti
-
Aethelstone
addikt
Tök mind1, hogy mire van kitalálva és milyen a struktúrája, file-okból áll az is, amiket nyugodtan lehet szinkronizálni ha nem használják párhuzamosan a példányokat.
Változáskövetés?
másrészt plusz munka a repo remote belövése,
Azon kívül, hogy regisztrálsz valahol(Dropboxra is kellett) és add source vagy valami hasonló...?
-
Aethelstone
addikt
válasz
WonderCSabo #6410 üzenetére
Plusz céges forrást nem szívesen pakolnék dropboxra.
-
Aethelstone
addikt
válasz
TheProb #6399 üzenetére
Meg ne haragudj, de ez nem szoftverfejlesztés, hanem NB felhasználói ismeret...legalábbis számomra. Mi lesz, ha eladod magad valahova Java/JavaFX fejlesztőként és első nap beraknak egy Eclipse vagy egy JEdit elé? Neadjisten notepaddel vagy nano-val kell hirtelen egy konzol környezetben patchelned egy rossz kódot?
-
Aethelstone
addikt
válasz
jetarko #6394 üzenetére
Ezt a "minden oldalon" megfogalmazást nem értem.
Általános szabály, hogy az adatbázis kezelését és az ehhez kapcsolódó hibakezelést 1 helyen oldjuk meg, az esetleges hibákat továbbdobjuk és a használat helyén csak ezeket kezeljük valamilyen módon. Nyilván ha Exception-t dobsz, akkor azt minden helyen kezelni kell, ahol használod.
-
Aethelstone
addikt
válasz
jetarko #6390 üzenetére
Hát nem igazán értem, hogy ez mitől jobb annál, mint ha simán kiírnám, hogy pl: /home.
Kb. azért, amiért a konstansok használata jobb, mint a kódba égetett szöveg. Másrészt 15 kontroller összes path-ja mondjuk egy osztályból módosítható.
@Override azért van, mert nincs bemásolva az egész osztály, ami egyébként implementál egy interfészt, ami a jelen probléma szempontjából indifferens.
-
Aethelstone
addikt
válasz
jetarko #6385 üzenetére
Persze.
Itt egy darab kontrollermetódus:
@Override
@RequestMapping(value=RestConstants.AppInfo.SERVICE_NAME, method = { RequestMethod.GET, RequestMethod.POST })
protected HttpEntity<byte[]> processRequest(HttpServletRequest request) {
return super.doIt(RestConstants.AppInfo.SERVICE_NAME, request);
}és a hozzátartozó interfész:
public interface RestConstants {
@RestApiFunction(name = "Application info", description = "Provides information about the application", responseClass = RestAppInfoBean.class)
public interface AppInfo {
@RestApiRequestParameter(service = true, description = "")
static final String SERVICE_NAME = "appinfo";
}
}Ez egy restapi implementáció darabja, pár saját annotációval megspékelve.
Mondjuk ez egy régebbi megvalósítás, ami még nem Enum-ot használ, azt éppen keresem a projektben -
Aethelstone
addikt
De itt konkrétan az MVC-t említettem, ahol pl. konstansok az útvonalak.
Hát jah. Ez az, amikor az élet úgy hozza, hogy teljesen más dolgokkal kell xopni a projektekben. Én spec. el nem tudom képzelni, hogy mikor kellene azt a remek MVC-s útvonalat dinamikussá tenni. Már teljesen. Mert a köv. pl. szerintem bőven elég.
@RequestMapping("/foo/bar/{param1}/{param2}
public String getFooBar(@PathVariable(value = "param1") String param1,etc, etc.
Oszlopot cserélni?
Jaaaaaaj.....neeee. Oszt mivégre?
Megint előhúzhatnám a tervezési hiba+gányolás dumámat, de pontosan tudom, hogy egyrészt így működik, másrészt meg már unalmas. A fejlesztőeszközöknek nyilván nem a gányolást kell támogatniuk elsősorban.
Nos, tényleg elkanyarodtunk. Ami nem baj, mert én speciel kifejezetten szeretem az efféle beszélgetéseket
Ördög ügyvédje
-
Aethelstone
addikt
Könyörgöm, mi a bajod a Spring annotációkkal? Csak nem fogsz menet közben két futás között egy dependency injectiont megváltoztatni? Vagy hirtelen @Service lesz egy @Controller osztályból?
Netán tegnap még @Transactional volt, ma meg már nem?
Hibernate dettó. A @Table(name="Users") miért változna két futtatás között? Netán egy @OneToMany?
Azért írtam, hogy ésszel.....
-
Aethelstone
addikt
Nos, nyilván ésszel kell használni az annotációkat.
Mert ugye a nyelv arra is lehetőséget biztosít, hogy egy alkalmazásnál a forráskódba égessük bele az egyébként lokalizálandó szövegeket, de mégsem teszünk ilyet.
Ergó, ha valamit, valahogyan el lehet baxni, akkor ezzel tisztában kell lenni és nem szabad bemenni abba a bizonyos utcába
Amit pedig konfigurálhatóvá kell tenni, azt azzá kell tenni. Ezt viszont a tervezés folyamán kell kialakítani és nem utólag. Ha pedig utólagos igényként lép fel, akkor fejlesztési igény, build és ennyi
-
Aethelstone
addikt
válasz
WonderCSabo #6371 üzenetére
Jah sajnos. Elnézést
-
Aethelstone
addikt
válasz
WonderCSabo #6368 üzenetére
Jó, érted, hogy mire gondolok
Arra gondoltam, hogy ha pl. nem "BELA" a static final változó értéke, hanem mondjuk egy context.xml bejegyzés, akkor én úgy szoktam, hogy nem rakok "közé" még egy static final változót, hanem a kiolvasott bean mezőértéket közvetlenül felhasználom. Persze, nekem könnyű, hülye Springes vagyok, tudok innnyektálni
-
Aethelstone
addikt
Gyakran fordul elő az, hogy egy külső erőforrásból adsz értéket egy static final változónak, ami "konstans"
Nyilván mindenkinek más a szokása, de static final változónak én ott adok értéket, ahol a deklaráció van. Ha nem, akkor nem veszem static final-ra. Azt hiszem, hogy ez tényleg ízlés dolga. Hasonló ez az interfészben deklarált public static final konstansok vs. Enumok esete között. Aki az Enumok előtt is Java-zott, az szereti az interfészt ilyesmire használni. Nem hiba ez, a nyelv és a fordító is megengedi, de az Enumok idejében én konkrétan lábrázást kapok tőle. Ízlés és mószertan kérdése
Ha pl egyszer XML-ben konfigurálsz egy hibernate modellt, másszor meg annotációban, akkor az annotáció lesz az a gyenge pont, ahol a kódba beégetett pl. táblanevet nem fogod tudni változtatni, miközben az XML-ben azt csinálsz, amit akarsz két futtatás közt.
Nos, ez tervezési hiba vagy inkább katyvasz. Mivel benne van az az akna, amit Te is leírsz. Vagy XML-ben konfigurálok entitást, beant, akármit vagy annotációval. Nyilván ha vegyes megoldás van, akkor nem baszok az annotációk alá XML konfiggal két futás között. Mint ahogy a @Table(name="bela") annotációt sem baszom agyon egy DROP TABLE vagy a @Column annotációt egy ALTER TABLE segítségével. Analóg a két eset...mármint az XML vs annotáció és a DROP/ALTER.
Eh, nemtom, hogy érted-e, mire célozgatok?
-
Aethelstone
addikt
Persze, az értelmétől el lehet vonatkoztatni, de minek?
szerk:
A statikus metódust is értem, de az is legalább ennyire fából vaskarika. A statikus metódus visszatérési értéke is változhat, attól függően, hogy milyen üzleti logika van benne. Innentől konstansnak értékül adni szerintem hibás tervezési minta.
-
-
Aethelstone
addikt
válasz
WonderCSabo #6218 üzenetére
A DISTINCT-nek akkor van szerintem értelme, hogy a a lekérdezésben egy konkrét mezőt akarsz visszakapni, az idézett problémakörben mondjuk egy nevet, de csak egyszer
Órákat, napokat lehetne beszélni a témáról
-
Aethelstone
addikt
válasz
WonderCSabo #6216 üzenetére
Nos, úgy látom, hogy kezdenek itt keveredni a dolgok. Nyilván valamiféle ID-ben el kell térniük, különben alapvető relációs adatbázis kezelési elvek sérülnek. Ha van egy Szemely táblám, amiben két személy csak a személyi számban tér el, akkor a Hibernate/MySQL szempontjából az két eltérő entitásként lesz "objektumizálva", függetlenül attól, hogy a többi metaadat ugyanolyan koppra. A korábban tárgyalt probléma eddig terjed.
Hogy a Java kódban a személyi számot az equals() metódusnál nem veszem figyelembe, az működhet, de ez ebben az esetben a konkrét adatbázis logika lábbal tiprása és semmi köze az ORM implementációhoz.
Hivatalos doksi nincs erről, legalábbis én nem találtam, de az egyik kolléga korábban említette, hogy a hivatalos Hibernate fórum milyen színvonalú. Ott a Hibernate fejlesztők workaroundként javasolják a DISTINCT és a Set használatát, ami kvázi hivatalos álláspont. Ráadásul mi a 3.x-es Hibernatet használjuk, aminél bőven van újabb is, de különféle okok miatt nem tudunk/akarunk egyelőre upgradeolni.
Ettől függetlenül simán lehet, hogy van ennek a problémának rendes megoldása, de ezt én eleddig nem találtam meg, főleg azért nem, mert éppen ma futottam bele ebbe én is és még nem volt időm bővebben kivesézni
-
Aethelstone
addikt
válasz
Aethelstone #6213 üzenetére
Lejárt a módosítás. Ha nem unique sorok vannak, akkor ott a normalizálás sérül....azt meg a kukába kell vetni ilyenkor.
-
Aethelstone
addikt
válasz
WonderCSabo #6212 üzenetére
Akkor használsz List-et, ami a szükséges és a szükségtelen duplikációkat is kezeli. Aztán majd "kézzel" kiszeded. Semelyik ORM nem tud 100%-os lenni.
Másrészről ez a hivatalos Hibernate álláspont, tehát szándékosan ilyen ez látszólag. A Hibernate sokszor nem úgy viselkedik, mint a tiszta JDBC. Ezekkel együtt kell élni.
Harmarészt miért lennének nem unique sorok? Azt hibás tervezés eredménye lehet max.
-
Aethelstone
addikt
válasz
Mukorka #6195 üzenetére
Régi. Még a 3.x-es széria
Bár, http://stackoverflow.com/questions/18753245/one-to-many-relationship-gets-duplicate-objects-whithout-using-distinct-why szerint ez a normális.
-
Aethelstone
addikt
válasz
Mukorka #6195 üzenetére
Nem
Alapvetően ez egy évek óta működő, tesztelt struktúra. Csak a kolléga felvetésére írtam, hogy ez nem egyedülálló eset, máshol is előfordul duplikáció, amit vagy DISTINC-tel vagy Set használatával List helyett lehet kifejelni. Nálunk List van, ahogy látszik, de nem kívánom módosítani, ezért lett DISTINCT.
-
Aethelstone
addikt
Azért, mert az annotációk szerint LAZY, viszont ha kell minden, akkor azt EAGER-ben kell ugyi. A sima JOIN meg ugyancsak LAZY, ahogy én tudom. Attól lesz EAGER , hogy kap egy FETCH-et is.
Forráskóddal:
@NamedQuery(name = "correlationRuleSet.eager", query = "select distinct crs from CorrelationRuleSet crs left join fetch crs.correlationRules")
})
public class CorrelationRuleSet extends AbstractAclEntity {
private static final long serialVersionUID = -9143224663183869606L;
@Column(name = "name", length = 256)
private String name;
@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "correlationRuleSet")
@Cascade(org.hibernate.annotations.CascadeType.DELETE_ORPHAN)
@LazyCollection(LazyCollectionOption.EXTRA)
private List<CorrelationRule> correlationRules = new LinkedList<CorrelationRule>(); -
Aethelstone
addikt
válasz
Aethelstone #6190 üzenetére
Nos, a Hibernate doksi szerint teljesen normális, hogy duplikátumok vannak. A Set használatát javasolják.
-
Aethelstone
addikt
válasz
jetarko #6179 üzenetére
Eh, pont most ütköztem bele egy hasonló problémába
Duplikált eredmény. Egy DISTINCT megoldotta, de nekem még nem tetszik így.
szerk:
Pontosabban NamedQuery-t használunk. Az OneToMany alapból Lazy, de Eagerhez írtunk egy FETCH JOIN-os queryt, ami a rohadt életbe duplikál. Egy SELECT DISTINCT megoldotta. Nézegetem a netet, hogy mi lenne a szebb megoldása....
-
Aethelstone
addikt
A beolvasás valszeg sima get. Nekem az adattartalom sokkal gyanúsabb....mert az annotációk elvileg jók és a Set-tel hibamentes, akkor ott olyasmi lehet, hogy a DB-ben valami kaki adat van. Bár ha az jól van felépítve, nem is lehetne....constraintek, unique indexek, stb.
-
Aethelstone
addikt
válasz
sunnysys #6180 üzenetére
Tehát az alapvető programozási szemléletet (vagy hogy is nevezzem) is meg kellene tanulnom.
Ezt hivatalosan tervezési mintának vagy design patternnek nevezik. Rengeteg ilyen témájú cikk van a neten, azokból lehet kiválóan tájékozódni. Egyébként ez a számológépes dolog szerintem így rendben van. Nem hiszem, hogy egy ilyen kvázi egyszerű feladatot nagyon el kellene bonyolítani. Persze lehet. Csinálhatsz JTextFieldből származtatott saját TextField-et, ami már elvégzi alapból a parseolást, de nem biztos, hogy a befektetett munka megéri. Ha viszont tanulni akarsz, akkor érdemes lehet belevágni
Gyorsan haladni? Alapvető szabály, hogy akkor lehet igazán hatékonyan megtanulni programozni, ha van értelmes feladat. Nem telefonregiszter és nem DVD kölcsönző nyilvántartás. Viszont komolyabb, életszagú, szopós feladatok csak éles munkahelyi környezetben szoktak adódni
-
Aethelstone
addikt
Elnézést, én értettem félre a hozzászólást! Nem volt jó estém! Üdv!
-
Aethelstone
addikt
Egyébként az elkészült Java termékek nagyobb része *nix rendszereken fog futni produkítve, így a Linux jobb választás lehet. Más valóban nem szól mellette vs Window ellen, max a személyes preferenciák.
-
Aethelstone
addikt
Azért, mert Windows-on egyesével fel kell telepíteni, Linuxon meg egy
apt-get install subversion maven2 mc eclipse etc...
Mondjuk az elég baj, ha a netről kell összevadászni. Mi egy fájlrepóban tároljuk az összes szükséges cuccot. Persze csak Windows-hoz. Linuxhoz meg egy emailben a szükséges apt-get parancsot
A konfigurálás meg doksi alapján.
-
Aethelstone
addikt
válasz
WonderCSabo #6064 üzenetére
Nem nekem lett szegezve a kérdés, de azért megpingetem. Igazából semmi, de az igazi férfi Linuxon fejleszt
Csak egy adalék, nem akarok flémet.
Egy német fejlesztővel dolgoztam pár hétig, aki világ életében Windows-on fejlesztett. GWT alapú volt a projekt, ugyanolyan gépeink voltak csak ő W7-en, én Ubuntu 12.04-en toltam. Meglepődve jelentette ki pár nap után, hogy Mein Gott, a Te rendszereden sokkal gyorsabban fordul a cucc, mint az enyémen
Nyilván sokmindentől függ, de jó kis történet
-
Aethelstone
addikt
-
Aethelstone
addikt
A fájlrendszer nyilván adott. Csak neadjisten lehetne egy olyan is, hogy mondjuk az A1 class a /a/b/c/B1.class fájlban van, azt tőőőőcsed be
Most max. annyi, hogy ugyan az A1 class keresed meg a /a/b/c/<class neve>.class fájlban
Persze, nem kell sokat emögé gondolni, konvenció és kész. Olyat is lehetne kérdezni, hogy miért main() metódus a belépési pont? Miért ne lehetne megadni, hogy teszem azt az init() vagy start() vagy pistike1986() legyen
Ez van és kész
-
Aethelstone
addikt
válasz
fordfairlane #6003 üzenetére
Ezt máshogy is meg lehetett volna oldani. Ehhez nem kellett volna feltétlenül ugyanolyan néven lennie az osztálynak és az őt tartalmazó fájlnak.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- exHWSW - Értünk mindenhez IS
- IGP nélküli processzorokkal készül az Intel és az AMD
- Trollok komolyan
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Épített vízhűtés (nem kompakt) topic
- One mobilszolgáltatások
- Fejhallgató erősítő és DAC topik
- iPhone topik
- Rágyúr a macOS-re a 3DMark
- Counter-Strike: Global Offensive (CS:GO) / Counter-Strike 2 (CS2)
- További aktív témák...
- Eladó konfig! Ryzen 7 7800X3D 2TB SSD 64GB DDR5 RX9070XT 16GB!
- Új, makulátlan állapotú Samsung Galaxy Buds FE, fehér, fél év garancia
- Új, makulátlan állapotú Samsung Galaxy Watch7 44mm ezüst, 2 év garancia
- Új, makulátlan állapotú Samsung Z Fold 6 256GB Tengerészkék, független, 2 év garancia
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- AKCIÓ! GIGABYTE AORUS MASTER RX 6800 XT 16GB videokártya garanciával hibátlan működéssel
- Samsung Galaxy A14 64GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7600X 32/64GB RTX 5070 12GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Lenovo ThinkPad T14 Gen 4 üzleti notebook - i7 1360P 24GB DDR5 RAM 512GB SSD Iris Xe W11
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged