- Nem indul és mi a baja a gépemnek topik
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Samsung QN800D: Neo QLED 8K tévét teszteltünk
- 3D nyomtatás
- TCL LCD és LED TV-k
- Milyen TV-t vegyek?
- Fejhallgató erősítő és DAC topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- HiFi műszaki szemmel - sztereó hangrendszerek
Hirdetés
-
Felfordul a windowsos piac: az Arm megszerezné a PC-s piac 50 százalékát
it Az Arm arra készül, hogy a windowsos piac átalakulása közben 5 éven belül megszerzi a PC-s piac 50 százalékát.
-
Továbbra is Dél-Korea uralja a tévékbe szánt OLED kijelzők piacát
ph Viszont a kínai riválisok óriási erőfeszítéseket tesznek, és kisebb méretkategóriában már ledolgozták korábbi hátrányukat.
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
Új hozzászólás Aktív témák
-
pvt.peter
őstag
válasz M_AND_Ms #7946 üzenetére
Tlképpen csak egy O(1) -el van több műveletem a 2. -ban, nem?
Ez pedig a hash kód alapján való elem lekérés a getKey segítségével.
Bár lehet hogy ugrálni kell majd a hash táblában mert a hasítófüggvény nem elég precíz ahhoz, hogy olyan kódot tudjon gyártani amihez biztos, hogy nem tartozik még semmi se.
(fix me, de asszem vmi ilyesmin alapszik a map ... )Ettől függetlenül igen, az elsőt célszerű használni.
A kérdésemet csak azért raktam fel, mert mindig csak egy elemet rakok bele abba a listába és kicsit csúnya volt, hogy mindig létre kell hoznom egy temp listát ehhez.Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
pvt.peter
őstag
válasz Oppenheimer #7947 üzenetére
ahogy @Aethelstone is írta, a kérdés szempontjából nem releváns
csak az egyszerűség kedvéért írtam Object -et[ Szerkesztve ]
Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
Aethelstone
addikt
válasz PazsitZ #7950 üzenetére
Meg kellene nézni, hogy milyen bájtkód lesz belőle, de tippem szerint a jvm szénné optimalizálja a collectionos cuccokat. Illetve nyilván by definition lehet tudni, hogy miben gyors a map, a list vagy a többi...
Meg az elemszám. Kis elemszámnál legyen inkább szép a kód
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
Sk8erPeter
nagyúr
válasz pvt.peter #7951 üzenetére
Szerintem egyáltalán nem csúnya, hogy külön sorba rakod, hogy mit művelsz azzal a listával, amit majd be szeretnél rakni a HashMapbe. Sőt, gyorsan olvasható, egyértelmű, tiszta, és elkerülsz vele egy tök felesleges plusz metódushívást. A második is jól olvasható, de tény, hogy pazarlóbb. Így egy elemnél aztán tényleg totál mindegy teljesítmény szempontjából, meg láthatóság szempontjából is, de én meg attól kaparom az arcom, amikor olyan kódot kell olvasnom, amikor láthatóan a fejlesztő célja az volt, hogy vagányan mindent minél rövidebbre tömörítsen. Az sem számít, hogy hányszor ismétel azonos metódushívásokat, hány plusz műveletet igényel, de milyen jól mutat, hogy legalább tömör. Hát nem, nem lesz feltétlenül gyorsabban olvasható a kód (persze nyilván bőven vannak kivételek, de ne fossuk már le ennyire a teljesítményt). Tényleg valakinek attól lesz olvashatatlan a kód, mert külön sorban ki van fejtve, hogy mi történik? Az már régen rossz. Magasszintű nyelveknél egyébként nagyon divat(tá vált?) az is, hogy a metódushívásokat egymás után is ismételgetjük, mondván, "nem kell túlpörögni optimalizáció szempontjából", mint a kolléga mondta, ez itt abszolút igaz, de általában ezzel nagyon nem értek egyet. Egyrészt ha ennyire leszarjuk, hányszor történik meg egy-egy metódushívás, akkor az már zsigeri szintű igénytelenséghez vezethet hosszabb távon a teljesítmény rovására, meg azért szépen lehet halmozgatni az ilyen tök felesleges overheadeket, na de minek. (Persze ebben az is szerepet játszik, hogy ebből a szempontból mai napig bennem van a C, C++ tanulásának korszaka, amikor az ilyesmi nem volt menő.)
Pl. ilyesmi:
whatever.doStuff().veryCool().blahblah();
whatever.doStuff().veryCool().wow().great();
whatever.doStuff().veryCool().notCool();
Na itt pl. a whatever.doStuff().veryCool() eredményét el lehetett volna tárolni egy változóba. De nem, ez így tök menő. Ja várjunk csak, mégsem.Szerk.:
Persze simán lehet, hogy az ilyeneket a fordító úgyis optimalizálja. Mindegy, bennem az van, hogy abból baj nincs, ha egyértelműen láthatóvá teszem, mi történik, nekem a pár sorral bővebben hablatyolós kód nem lesz olvashatatlanabb, az agyontömörített kód viszont annál inkább. (Meg a debuggolást is nehezebbé teheti. )[ Szerkesztve ]
Sk8erPeter
-
M_AND_Ms
addikt
válasz Sk8erPeter #7954 üzenetére
Egyetértek. A kód valamelyest az emberi gondolkodást is reprezentálja.
Aki tejszínhabot szeretne, az inkább verje ki a fejéből!
-
Aethelstone
addikt
válasz Sk8erPeter #7954 üzenetére
Az a buli, hogy a whateveres példád Java-ban egy design pattern
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
Sk8erPeter
nagyúr
válasz Aethelstone #7956 üzenetére
Mármint milyen design pattern? Ez a "How to produce spaghetti code and waste resources" design pattern? Vagy inkább nevezzük egy rossz begörcsölődésnek?
(#7955) M_AND_Ms:
Jaja. És mennyivel gyorsabb sorban feldolgozni az infókat, és látni egyenként, hogy mi történik, mint kódátfutás során értelmezni az egybedobált sorokat, ahol ki tudja, még hány egyéb metódushívás vagy más művelet történik. Egyszerűen mész végig a sorokon, és még mindig tudod követni. Amikor viszont agyon van tömörítve a kód, és a szemnek ugrálnia kell, az agynak pedig megjegyeznie egyetlen sor értelmezése közben csomó infót, az fárasztó - és az ember azért elég sűrűn olvashatja munkakörnyezetben másnak a kódját.Amúgy ez az egész kettős: az előző hsz.-emben lévő whateveres példa pont, hogy túl szószátyár és még pazarló is. Számomra sokkal olvashatóbb is lenne az a kód, ha az ismétlődő metódushívások eredményét eltárolnánk egy változóba - amit eleve így illik -, és onnantól kezdve tudnám, hogy kifejezetten azzal akarunk valamit kezdeni, nem kellene mindig végigfutnom a sort odáig, amíg ugyanaz történik, hogy tudjam, hogy most pont ugyanazt babráljuk, csak nem raktuk az eredményt külön válltozóba. (Az ilyennek a lerövidítése egyébként Eclipse-ben annyi, hogy kijelöljük az ismétlődő kódrészt, egy Alt+Shift+L, és létrehozható belőle egy lokális változó, és meg van oldva.)
[ Szerkesztve ]
Sk8erPeter
-
Aethelstone
addikt
válasz Sk8erPeter #7957 üzenetére
Builder pattern. Egyébként amiről írsz, az pusztány egyéni preferencia kérdése.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
PazsitZ
addikt
válasz Aethelstone #7958 üzenetére
A builder pattern az egy pattern, ahol van egy buildered és azon hívsz metódusokat. Amit még csak nem is kötelező, de célszerű/kézenfekvő láncolva hívni. Jah és a végén ugye build()-et hívsz nem foo()-t.
Nem arról szól, hogy ha metódusokat láncolva hívsz akkor builder pattern-t használsz.Konkrétan a whatever példában számomra is az a természetesebb, ha kiemeled változóba a kérdéses részt, de az a példa szerintem egész eltérő a kiinduló kérdéstől.
[ Szerkesztve ]
- http://pazsitz.hu -
-
Sk8erPeter
nagyúr
válasz PazsitZ #7959 üzenetére
"az a példa szerintem egész eltérő a kiinduló kérdéstől"
Tök igazad van, igazából csak annak kapcsán jutott eszembe ez a másik téma, hogy beszélgettünk arról, hogy mi az, ami "szép", és mi az, ami pl. nekem személy szerint nem bejövős, az eredeti kérdéshez a whateveres példának már tényleg nincs köze. Szóval röviden a lényeg, hogy sokan szeretik agyontömörítgetni a kódot, amikor attól nem lesz jobb vagy olvashatóbb a kód, sőt, jobb lehet inkább szétdobálni, illetve hogy másik oldalról viszont sokan szeretik újból és újból leírni ugyanazokat az ismétlődő kódrészletet, ezzel pont, hogy túlzottan bőlére eresztik a kódot, illetve ez a módszer erőforrások pazarlására is alkalmas (overhead).Sk8erPeter
-
Sk8erPeter
nagyúr
válasz Sk8erPeter #7833 üzenetére
Most jutott eszembe, hogy elfelejtettem megírni, hogy erre sikerült megtalálni a megoldást, hátha valakinek kell, ha a példában a TreeViewert szeretnénk lecserélni CheckboxTreeViewerre, és azt szeretnénk, hogy még működjön is, és ne kapjunk StackOverflowErrort, akkor saját check state providert kell beállítanunk, és a probléma meg is van oldva:
v.setCheckStateProvider(new ICheckStateProvider() {
/**
* TODO: provide complete solution
*/
@Override
public boolean isGrayed(Object element) {
return false;
}
/**
* TODO: provide complete solution
*/
@Override
public boolean isChecked(Object element) {
return false;
}
});Persze az isGrayed és isChecked metódusok visszatérési értékét nekünk kell a saját alkalmazáslogikánk szerint beállítani.
[ Szerkesztve ]
Sk8erPeter
-
MODERÁTOR
válasz Aethelstone #7943 üzenetére
Ez oké. Használtam már így is-úgy is. De a kérdés lényege - lehet félreérthetően írtam -, hogy ha tehetem ragaszkodjak a JPA-hoz, vagy adott esetben jó nekem a Hibernate nem így implementálva.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
nagyúr
Distributed random-access read-ot biztosító blob storage-ra lenne szükségem. HDFS-en kívül van ötlet? Ez sem ad rendes random accesst, de legalább blokkhatarokra tudok seekelni.
Replikáció, HA alapkövetelmény. POSIX felület nem.while (!sleep) sheep++;
-
Aethelstone
addikt
válasz Aethelstone #7967 üzenetére
Úgy értem zfs+bsd+postgresql.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
MODERÁTOR
válasz Aethelstone #7965 üzenetére
OpenJPA a kiszemelt. Van jobb?
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
nagyúr
válasz Aethelstone #7968 üzenetére
Ezekbol egyelore nem latom, hogy lenne elosztott, random-access blob store, ami egyebkent konnyen replikalhato, etc. Postgresunk van mar, az nem annyira kenyelmes fajlok tarolasara.
while (!sleep) sheep++;
-
MODERÁTOR
válasz Aethelstone #7971 üzenetére
Értem, köszi.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
nagyúr
válasz Aethelstone #7972 üzenetére
- torles lenyegeben nincs, soha
- egy adott fajlt jellemzoen nem olvasunk vissza tobbszor, mint par tucat alkalom
- a fajlok lehetnek akar nagy videok is, amikbe bele kene tudni tekerni
- az egesz tetejen egy massziv titkositas ulValoszinu, hogy HDFS-sel fogok inditani, aztan majd meglatjuk.
[ Szerkesztve ]
while (!sleep) sheep++;
-
floatr
veterán
válasz Aethelstone #7971 üzenetére
Van nagyon jó hibernate performance oktatásunk, ha érdekel
Ha egyszer ebben az életben még lesz valaha egy kis szabadidőm, akkor majd írok is róla. -
pvt.peter
őstag
válasz Sk8erPeter #7954 üzenetére
Köszönöm a részletes válaszodat.
Ez egy .50-es rombolópuska, elég szép visszarúgással.
-
pvt.peter
őstag
Sziasztok!
Lenne egy érdekes kérdésem.
Adott egy rendszer amelyben az egyik igen csak teljesítményigényes végrehajtó részt, kísérleti jelleggel több komponens is megvalósítja.
A lényeg, hogy ezeknek a komponenseknek a teljesítményét szeretném mérni.
Nem bonyolítom túl az egészet, egyszerűen csak futási időt fogok mérni a System.nano() hívással.long start = System.nanoTime();
...
long end = System.nanoTime() - start;Mennyire valós dolog az, hogy a Java lassan "melegszik" be.
Tehát ha én egy adott függvény teljesítményét akarom lemérni, akkor az első 5-6 futás eredményét tényleg érdemes-e eldobni?A válaszokat előre is köszönöm,
PetiEz egy .50-es rombolópuska, elég szép visszarúgással.
-
floatr
veterán
válasz pvt.peter #7977 üzenetére
Létezik az, hogy a VM memóriát pucol, betölt, lefordít, becache-el dolgokat, de az elméletileg első futtatáskor megtörténik. Ez a jelenség más infrastruktúrán is jelentkezik.
Azt viszont a teljesítményteszteknél érdemes megjegyezni, hogy mindig lesznek kiugróan rossz, vagy jó eredmények, ami nem igazán tükrözi a normál körülményeket. Használnak emiatt sokféle statisztikai mutatót, de nekem eddig a legjobban a medián jött be, az egyszerű átlagolás könnyen elvisz a málnásba.
Ja és természetesen lehetőleg kellően sok futtatás kell ahhoz, hogy valós képet kapjál. Ha az elsőt mondjuk eldobod, után mondjuk 10 mérés már sok esetben elég tud lenni.
[ Szerkesztve ]
-
Aethelstone
addikt
Nos, nyilván lehet ide-oda reszelgetni, de alapvetően sosem lesz olyan gyors, mint egy pure JDBC(max kényelmesebb). Nyilván a feladattól és a programozótól is függ....láttam egyébként pár DEBUG módban kiírt Hibernate query-t......hajamat téptem tőlük. Ha ORM kell, akkor nem kérdés, de kérdés mindig az, hogy kell-e ORM.
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
veterán
-
Aethelstone
addikt
válasz pvt.peter #7977 üzenetére
Meg azt sem árt tudni, hogy ezek a komponensek mit csinálnak. Adatbázis kapcsolat pl. elsőre kissé le tudja fogni a teljesítményt, de ha mondjuk pool van kötve a végére, akkor a második és sokadik futás értelemszerűen már sokkal gyorsabb...és sorolhatnám.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
floatr
veterán
válasz Aethelstone #7979 üzenetére
Lehet rajta pörögni, de egyrészt a valódi bottleneck nem az ORM lesz, hanem a hálózati adatkapcsolat. Másrészt lehet jól és rosszul is használni, alacsony és magas absztrakciós szinten. Van olyan eszköze, amivel egy jdbctemplate sem lesz érdemben gyorsabb. viszont többféleképpen tud egyazon projekten belül is viselkedni, amire egy jdbctemplate nem képes.
Amúgy meg lehet nézni, hogy mekkora overhead egy projekt esetén, ha nem használnak épkézláb perzisztenciát. Ezt a legtöbb kliens ma már nem lenne hajlandó kifizetni. De ha annyira a data layer nanoszekundumain kell gondolkodni, akkor miért nem tárolt eljárásokban implementálja az, akinek ez fáj? Komolyan...
-
pvt.peter
őstag
válasz Aethelstone #7981 üzenetére
hálistennek db kapcsolat nincs benne,
"egyszerű" objektumokon való műveletvégzést valósít meg minden komponensEz egy .50-es rombolópuska, elég szép visszarúgással.
-
Aethelstone
addikt
Az a baj, hogy ezek általánosságok. Feladattól és programozótól függ az egész. Nekem pl. most van egy adatmigrációs projektem, JDBC alapokon megy, isten mentsen meg, hogy bármiféle ORM-hez nyúljak...viszont egy mezei 3 rétegű web alkalmazásnál már mindenképpen indokolt lehet ORM használata.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
floatr
veterán
válasz Aethelstone #7984 üzenetére
Feltételeztem, hogy vannak olyan elemek, amiket entitásként lehet kezelni. Ettől függetlenül tartom a dolgot, hogy két adatmodell közti átjárást is elég jól meg lehetne vele oldani, bár a DBA-k nálunk a migrációt scriptekben látják, amiben mondjuk van is valami, ha milliós nagyságrendű rekord csúszik át, az hálózaton elég lassú tud lenni.
-
floatr
veterán
válasz Aethelstone #7986 üzenetére
Hasonló cipőben járunk, bár a CSV két teljesen különböző adatmodell közti átjáráshoz kell, és a DBA önkezűleg futtatja a generátort.
Mindegy, a kulcsszavak: stateless session, report query, native query meg hasonlók. Ezekkel egy migráció sem probléma, de ha egy nagyobb projekt része, akkor nem kell megőrülni a többi usecase esetében az alacsony szintű eszközöktől.
-
Sk8erPeter
nagyúr
válasz Aethelstone #7962 üzenetére
Tényleg nem, de érted, nem attól lesz builder pattern egy kód, hogy láncolva hívogatsz metódusokat (ahogy a kolléga is írta). Igazából a lényege a példának itt a felesleges "önismétlés" hibájába esés volt, hogy bizonyos - "menetközben" nem változó értéket visszaadó - metódusok visszatérési értékét akár el is tárolhatnánk, hogy spóroljunk némi overheadet, de nem tesszük, mer' nem tom mé'.
Sk8erPeter
-
Aethelstone
addikt
válasz Sk8erPeter #7989 üzenetére
Azért írtam, mert metódusok hívogatása láncban nem az ördög műve. Annyira nem, hogy pattern is épül rá, amit buildernek hívnak. Erre gondoltam.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
fatal`
titán
válasz Aethelstone #7990 üzenetére
A láncban hívása nem. Az említett példával viszont nem az volt a probléma, hanem az, hogy a lánc nagyrészét többször is hívja egymás után.
-
Sk8erPeter
nagyúr
válasz Aethelstone #7990 üzenetére
Most kicsit nehéz eldönteni, hogy tényleg nem érted, miről vakerászok, vagy csak szívatsz.
Sk8erPeter
-
WonderCSabo
félisten
Hogy a VM bemegeledegese ne adjon fals eredmenyt, ahhoz ezt szoktak hasznalni.
-
Lortech
addikt
Már csak azért is érdemes különbséget tenni a sima "láncban hívás" meg builder API-k között, mert előbbi potenciálisan LoD sértés, utóbbi meg többnyire nem.
Thank you to god for making me an atheist
-
Aethelstone
addikt
válasz Sk8erPeter #7992 üzenetére
Megsérteni nem akarlak, ezért inkább azt választom, hogy nem értem, hogy miről vakerálsz Persze, nyilván van még opció, de mint említettem, nem akarlak megsérteni Peace
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
Sk8erPeter
nagyúr
válasz Aethelstone #7995 üzenetére
Nem tudom, mire célozgatsz, de ha még mindig tényleg nem érted, én sem akarlak megsérteni, de próbáld meg talán értően elolvasni még egyszer, amire reagálgatsz már egy ideje, hogy eljuss odáig, ahova a többiek már jól láthatóan eljutottak...
De most tényleg, nem tudom, mit nem lehet felfogni azon, hogy a metódusok visszatérési értékét tároljuk már el a bánatba nyomorult változókba, és ne hívogassuk már ugyanazokat a fostos metódusokat újból és újból az eltárolt visszatérési érték felhasználása helyett.Sk8erPeter
-
Aethelstone
addikt
válasz Sk8erPeter #7996 üzenetére
Igazad van, mindenkinek igaza van, nekem nincs igazam. Így jó?
Ami meg a konkrét problémát illeti, pontosan értem, hogy mit akarsz mondani, mégis azt mondom, hogy kinek a pap, kinek pedig a papné. Részemről lezárva.MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
pecze
aktív tag
Sziasztok
Lehet amatőr kérdés, van egy osztályom, amiből ha készítek egy példányt egy másik osztály egy tömbjében szeretném eltárolni.
Pl. egyik osztály
public class dolgozo {
private String nem;
private String nev;
private String cim;
private int kor;
}
Konstruktor és setter getter is van minden létező módon beállítva.
Másik osztály, ebben kéne egy tömböt létrehozni, amiben el tudom tárolni a példány során megadott dolgokat, így gondoltam
public class ceg {
private dolgozo[] dolgozotomb;
}
Példányosításnál pedig
dolgozo elso = new dolgozo("férfi","XY","Budapest",26);
ceg cegBT = new ceg();
ceg.setdolgozotomb(new dolgozo[10]);Itt akadtam el, mert bármilyen értékadásra hibaüzenetet kapok, illetve az se biztos, hogy eddig jó
-
Aethelstone
addikt
Hali.
Első körben célszerűbb lenne a tömb helyett valamiféle listában tárolni a dolgozókat, mivel a listához dinamikusan lehet elemeket hozzáadni.
Tehát dolgozo[10] helyett lehetne mondjuk List<dolgozo>
Aztán kellene egy metódus a ceg osztályban, ami mondjuk lehetne addDolgozo(dolgozo d), ami is lazy inittel adná hozzá a listához a dolgozókat.
public class ceg {
List<dolgozo> dolgozok;
public void addDolgozo(dolgozo d) {
if (this.dolgozok==null) {
this.dolgozok = new ArrayList<dolgozo>();
}
// Itt lehetne mindenféle ellenőrzés, hogy van-e már ilyen, stb.
this.dolgozok.add(d);
}
}
// A feltöltés kb. így nézne ki..
dolgozo elso = new dolgozo("férfi","XY","Budapest",26);
ceg cegBT = new ceg();
cegBT.addDolgozo(elso);Még valami.....Java-ban osztálynév nagybetűvel kezdődik...elnevezési konvenció.
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
floatr
veterán
válasz Aethelstone #7988 üzenetére
Mert egy csak JDBC-s megoldásnál csak JDBC-t tudsz használni mindenre Ha két qeryből áll a projekt akkor még vállalható, de efölött kezd kissé kellemetlenné válni a dolog.
Régebben én is lázadoztam a hibernate használata ellen, találtam különféle félmegoldásokat, aztán be kellett látnom, hogy felesleges a széllel szemben cuccolni, pláne úgy, hogy azt is tudja, amiért lázadoztam, csak sokan nem tudják használni az eszköztárát megfelelően. Az élet kegyetlen...
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- MOBILTELEFON / TARTOZÉK / OKOSÓRA / OKOS KIEGÉSZÍTŐ beárazás
- Milyen légkondit a lakásba?
- iPhone topik
- Nem indul és mi a baja a gépemnek topik
- Skoda, VW, Audi, Seat topik
- LEGO klub
- Kerti grill és bográcsozó házilag (BBQ, tervek, ötletek, receptek)
- Cyberpunk 2077
- Futás, futópályák
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- További aktív témák...
- Apple iMac 27" 5K 2015 i5"-6500 , 5120x2880, 16GB / 256GB SSD, Radeon R9 M390 garanciával ,üzletből
- Eladó! GA-Z170X-Gaming 3 (rev. 1.0) alaplap+i5 6400+2 8gb 3200mhz ddr4 (Foxpost az árban!)
- PowerColor Red Devil RX 6600 XT - garancia 2024 november - eladó!
- Lenovo Thinkpad T420, 14" HD+ Kijelző, I5-2520M, 12GB DDR3, 256GB SSD, WIN 10, Számla, garancia
- Lenovo Thinkpad L440, 14" HD+ Kijelző, I5-4200M, 8-16GB DDR3, 500GB HDD, WIN 10, Számla, garancia
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs