Hirdetés
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
Robotkart irányított a majom a kínai Neuralink agyi chipjével
it A mindezt lehetővé tévő Neucybert a Neuralink kínai riválisa, a Beijing Xinzhida Neurotechnology fejlesztette ki.
-
Mobilarena
Új hozzászólás Aktív témák
-
inf3rno
nagyúr
Szeretnék (WebGL-ben) összeszórni egy ilyet. Nagyjából arról van szó, hogy van egy csillagrendszer, amiben ha gondolok egyet be tudom görbíteni a teret, és eljutni a-ból b-be egy alagúton keresztül instant (kb 1 sec alatt, hogy legyen ideje betölteni az ottani csillagtérképet). Úgy szeretném, hogy az alagút másik végén már látszana a hely, ahova menni akarok. Nincs tapasztalatom animációk terén, szeretnék tanácsot kérni, hogy egy ilyen effektet hogyan lehet lemodellezni?
Agyaltam rajta pár napot, nézegettem pár tutorialt webgl-ről meg three.js-ról, de nem jutottam semmire ezzel kapcsolatban. Egyébként nem kritikus feature, inkább csak gyakorolgatás, de azért érdekelne, hogy egy animációk terén jártasabb fejlesztő hogyan futna neki... Magát a logikát nem értem, ami szerint ezek a tunnel effektek működnek, pl ez ez első ránézésre (az én limitált tudásommal) valami 2d dolognak tűnik, aminek nincs a térben szerkezete, nem tudok átmenni rajta. Egy ilyenből hogyan lehet egy rendes 3d alagútat csinálni, amibe ha belemegyek, akkor nagyon nagy sebességgel mozgok a csillagtérképen? Eleve az nem fér a fejembe, hogy van az alagútban egy pozícióm, meg van a csillagtérképen is egy pozícióm, és mindkettő ugyanabban a 3d koordináta rendszerben. Egyszerre vagyok két helyen...
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Gyuri16 #8597 üzenetére
Nem teljesen értem, szvsz. annyi a különbség, hogy a nem scriptnél ki tudod írni fájlba a fordítitt programot, scriptnél meg nem. De lehet, hogy csak azért nem értem, mert nem szoktam fordítós nyelvekkel kódolni. A typescriptet minek neveznéd? Az javascript-re fordul le...
Buliban hasznos! =]
-
inf3rno
nagyúr
Nagyjából azt mondanám, hogy script nyelven írt kód. Aztán kifejteném, hogy mi a jellemző a script nyelvekre, pl wikipedia szerint:
"A scripting language or script language is a programming language that supports scripts, programs written for a special run-time environment that can interpret (rather than compile) and automate the execution of tasks that could alternatively be executed one-by-one by a human operator."
Használják még olyan értelemben is, ahogy te írtad, de szerintem ez a hivatalosabb verzió...
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz germinator66 #8581 üzenetére
Szvsz, ha csak teheted gitet használj inkább, nekem ezerszer jobban bevált.
Buliban hasznos! =]
-
inf3rno
nagyúr
Azt nem ismerem, de azt írják az is ugyanolyan jó: What is the Difference Between Mercurial and Git?
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Sk8erPeter #8624 üzenetére
Szvsz. olyasmikre, amikor parancssorból kell behaxolni egy csomó dolgot, hogy működjön, amit akarsz. Néha belefutok én is ilyesmibe nagy ritkán. Általában viszont nagyon jól megvagyok az alap funkciókkal, azok szerintem sincsenek elbonyolítva.
Csak egy példa, így kell lekérni a repo útvonalát:
$(git rev-parse --show-toplevel)
Szvsz, ez egy elég jó példa arra, hogy hogyan nem szabad APIt tervezni. Semmi szükség arra, hogy ismerjem a rev-parse-t ahhoz, hogy egy ilyen szimpla adatot le tudjak kérni. Első ránézésre lövésem sincs, hogy mit jelent:
"git rev-parse is an ancillary plumbing command primarily used for manipulation."
Nekem a show top level is csak közepesen beszélő, inkább valami repo root path, vagy hasonló, ami megszokottabb szóhasználat lenne...
Mindenesetre ez az egész a clean code-tól elég messze van. Én jobb szeretem az IDE-be épített pluginnel használni a git-et, azt hiszem nem véletlen.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Hát én úgy tudom, hogy csak párhuzamosított dolgoknál concurrency megakadályozására jobb többé-kevésbé a funkcionális programozás. Jól jöhet, ha többszálú kódot akarsz írni mondjuk java-ban. De ilyen téren tényleg nincs sok tapasztalatom, js világból jövök event loopból, elkényeztettek, nem nekem való az osztott memória, és hasonló nyalánkságok. :-) Java-s ismerősöm szerint magával a lisp-el nem sokat érsz, kis nyelv, a nagyobb nyelvekre írt adaptációi (ha ez a megfelelő szó), pl a clojure viszont annál piacképesebb. (Többet példát nem is tudok felsorolni, hehe. )
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Doctor46 #8654 üzenetére
Hát nekem ez így elég tág határok között mozog, gondolom azt akarják visszahallani, amit leadtak órán. A gyakorlatban nagyon sok dolog ízlés kérdése, pl hogy milyen dokumentumokat szórsz össze azt szerződésben lehet rögzíteni, de sokszor a megrendelő egyáltalán nem is foglalkozik vele, csak működjön az alkalmazás. Az adatbázis is elég esetleges, tudni kéne, hogy milyenekről tanultatok, SQL/newSQL, ill. noSQL szerepelt az anyagban? Elképzelhető, hogy egy noSQL adatbázis erre a feladatra sokkal jobb lenne, mint egy SQL. Na szóval szerintem még mindig kevés az info, hogy érdemben lehessen válaszolni.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz creation #8657 üzenetére
Nem tudom, ilyen nehéz debuggolni? Vagy az LDAP a hibás vagy valami a HTTP szerverrel van. Próbáld ki LDAP nélkül mondjuk sima PHP array-es példa adattal kimockolva a perzisztenciát (úgy mondjuk elég nehéz, ha nem decoupled az implementációja). Ha úgy megy, akkor valszeg az LDAP lockolja a fájlt, és azért teker a többi. Hogy ennek mi köze az IE-hez, azt ne kérdezd. Persze a bugoknál lehet még sok olyan dolog, amire nem is gondolna az ember, de legalább jó lenne beazonosítani, hogy a szoftver melyik részén bukik el a dolog. LDAP-al és MSIE-vel kapcsolatban nem találtam semmi összefüggést egy gyors kereséssel, úgyhogy valszeg máshol lesz a hiba a rendszeredben.
Egyébként javaslom valamelyik HTTP keretrendszer, pl symfony vagy laravel használatát.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz bambano #8663 üzenetére
Szvsz event sourcing-al lenne a legtöbb értelme, abból később olyan read database-eket csinál, amilyeneket akar. Az immediate consistency meg itt egyáltalán nem szempont, szóval tökéletes lenne ilyen célra. Egy apróbb domain model kell, aminek van egy felülete, ahhoz lehetne szenzoronként eltérő adaptereket írni.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz creation #8660 üzenetére
Még érdekes lehet az is, hogy PHP milyen módban fut, mi van a htaccess fájlokban, milyen verziójú böngészőkkel próbáltad, és mi az, amivel nem megy, illetve, hogy van e kliens oldali script, vagy egy sima HTML echo betöltése nem megy. A doctype és a content-type header is közrejátszhat extrém esetben. Egyébként nekem nem logikus, hogy IE specifikus dolog legyen. Ez így tényleg fura. Össze kellene szedni minél több adatot, aztán rákeresni, hátha dob valamit google. Legrosszabb esetben meg írni egy bug report-ot vagy a HTTP szerver gyártójának vagy microsoftnak (utóbbinak azt mondják nem érdemes, mert nem nagyon foglalkoznak vele).
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz creation #8672 üzenetére
Ha localhost-on teszteled, akkor itt van egy hasonló topic: http://forum.wampserver.com/read.php?2,91207,page=1 Azt mondják, hogy az intranet beállítások rosszak MSIE-n, illetve az Apache 2.4 cseréje 2.2-re megoldja. Hát... Én mondjuk inkább IIS-t (ha már windows) vagy nginx-et használnék, ha amúgy is szerver csere kell, sosem bíztam az Apache-ban. Valahogy az a benyomásom, hogy a verzió váltásaik több új bugot tesznek be, mint amennyit javítanak.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz creation #8683 üzenetére
Próbálj meg betenni egy favicon.ico fájlt, chrome általában azt keresi. De ez session-el kapcsolatos hibákat szokott csak eredményezni, amikor session-be mentesz adatot egy átirányítás erejéig. Ami különbség lehet még az a default doctype, ha nem adsz meg ilyet, illetve, hogy a nem szabványos HTML-t hogyan dolgozzák fel és hogy a karakterkódolás ütközésekre hogyan reagálnak, pl ha meta-ban mást adsz meg, mint header-ben, meg még van egy pár dolog...
Maga az ldap szerintem csak tünet, a probléma a kóddal van. Teszteletlen és átláthatatlan, valszeg hemzseg a hibáktól. Ha nem kenyered az oop, akkor is lehet elfogadható kódot írni procedurálisan. Azt hiszem a wordpress-nek ilyen a kódja.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz creation #8685 üzenetére
Echo helyett jó lenne, ha fellőnétek egy logger-t és csinálnátok egy debug mód-ot, ami loggol dolgokat. Az stdout nem loggolásra van. http://stackoverflow.com/questions/341154/php-logging-framework
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz creation #8685 üzenetére
Ha esetleg később megismerkednél az ojjektum orientált fejlesztéssel, akkor érdemes ezt elolvasni: http://www.libri.hu/konyv/tiszta-kod.html és talán nem lesz olyan a kód utána, mint a falra hányt borsó.
Ami még elgondolkodtató, hogy BDD-t vagy TDD-t lehet e procedurálisan használni. Ha igen, akkor jobb lenne áttérnetek arra, mert a debuggal sokkal több idő elmegy. A gond most az, hogy még csak procedurálisnak sem igen lehet nevezni a kódot, mert függvények sincsenek. Spagetti, ahogy más is mondta. Így viszont max e2e tesztelhető legalább minimálisan.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Sk8erPeter #8686 üzenetére
XDebug-al hogyan fogja megtalálni a hibát? Nekem eddig még sosem sikerült használható infot kifacsarnom belőle, csak egy rohadt nagy log fájlt csinál, amit ha megnyitsz, akkor kiírja, hogy az echot ezerszer hívta, stb. Én már nem PHP-zek, de gondolom neki biztosan segítene ez az info.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Sk8erPeter #8691 üzenetére
Én loggolni szoktam az értékeket a megfelelő helyeken, aztán úgy nézem meg. Tudom, hogy van ennél jobb megoldás is, pl breakpoint-ot, hasonlókat be lehet tenni, de őszintén szólva nem sűrűn van rá szükségem. TDD-vel fejlesztek legtöbbször, ott meg az esetek döntő többségében azonnal tudni, hogy hol a hiba. Az integrációval szoktak gondok lenne, de annak meg jobb úgy nekifutni, hogy integrációs teszteket ír az ember ahelyett, hogy elkezdene dokumentáció alapján kódolni.
A session-nél a flash típusú letárolásokat szokta kitörölni, mert pl chrome minden kérésnél keresi a favicon-t, ha nincs bent neki cache-ben.
Nekem egyelőre egyáltalán nem világos, hogy mi a hiba, csak annyi, hogy valami nem működik, és nem hajlandó debuggolni, inkább csak találgat. Ennyi alapján szerintem nem lehet semmit kijelenteni.
Szvsz, a wordpress-t procedurálishoz képest nagyon szépen megcsinálták (már amit láttam belőle), minden kapott külön függvényt beszélő névvel, szóval ki lehet igazodni rajta. A dokumentációja is jó. Egyébként azért nem oo, mert még php4-en kezdték fejleszteni. Manapság már vannak symfony-ra meg laravel-re épülő cms-ek, azok valszeg egy fokkal összeszedettebbek. Annyira nem követem php-t, a symfony2 kódja az tetszett.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz cech19960320 #8696 üzenetére
Ez szerintem erősen függ attól, hogy milyen nyelven írták a programot.
(Ha esetleg nem bináris, hanem szövegfájl, akkor notepad++-al meg tudod nyitni, ellenkező esetben meg tényleg szükséged van külön programra.)
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz cech19960320 #8701 üzenetére
Még mindig nem írtad, hogy milyen programozási nyelven írták a programot, amit tovább kéne fejleszteni.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Mr Dini #8702 üzenetére
Nem akarok hülyeséget mondani, de nekem az jött le abban a 2 percben, amíg utánanéztem, hogy a c fájlt kell módosítani, aztán a compile után lesz belőle pifm fájl. Hogy ehhez milyen compiler kell, hogy elmenjen rpi-n, azt ne tőlem kérdezd, biztos megvannak az eszközök hozzá.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz cech19960320 #8708 üzenetére
Nagy valószínűséggel nem. Általában csak a gépi kódra átfordított változat van nálad, ami csak a gépnek jó, fejlesztéshez használhatatlan. Talán ha nagyon rövid, és valaki nagyon ért alacsony szintű dolgokhoz, akkor ki lehet nyerni belőle, hogy mit csinál, de nem hiszem, hogy bárki vállalkozna ilyesmire. Egyébként te magad is meg tudod nézni, hogy használható e, egyszerűen megnyitod szövegszerkesztővel a fájlokat, ha csak krix-krax van, nem (többé-kevésbé) értelmes szöveg, akkor nem jó semmire.
Szvsz. meg kellene találnod az eredeti program fejlesztőjét, és vele konzultálni ezügyben, hátha van kedve tovább csinálni. Ha nem, akkor esetleg elkérheted tőle a forráskódot, vagy megkérheted, hogy tegye ki github-ra, ahonnan lehet forkolni.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz olivera88 #8746 üzenetére
Gondolom ezt hiányolja: https://software.ecmwf.int/wiki/display/MAGP/Python+interfaces Pythonhoz nem értek, de a többit szerintem ki tudod találni. Elvileg innen lehet lerántani: https://packages.debian.org/wheezy/amd64/python-magics++ Az amd64 alapján gyanús, hogy intel processzorral ez a változat nem fog menni, de azért egy próbát megér.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz McSzaby #8750 üzenetére
Nem tartom magam valami nagy programozónak, de én úgy oldanám meg, hogy megnézném a file modification time-ot, hogy módosították e, ill. minden felolvasás után lementeném, hogy hányadik karakternél/sorban hagytam abba az előzőt. (Feltéve hogy a fájl mérete csak nőhet, és nem törlődik az eleje.)
szerk: Na ebből látszik, hogy tényleg nem vagyok olyan nagy programozó.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Fejlesztett már valaki közületek firefox plugint? Van egy chrome extension, amiből 3 függvényt szeretnék firefox-ra átírni meg persze a manifest.json-t package.json-ra. Elvileg a maradék kód rendben van. Próbáltam keresgélni, de nehéz copy-paste kódot találni, többszáz oldal dokumentációt meg ezért elolvasni, hát nem éri meg.
Ilyesmik kellenének:
chrome.extension.getURL("relative/path");
chrome.browserAction.onClicked.addListener(function() {
window.open("http://domain.com/", "_new")
});
chrome.webRequest.onBeforeRequest.addListener(function() {
return {
cancel: true
}
}, {
urls: ["*://domain.com/main.js*"]
}, ["blocking"]);A getURL() elsősorban a frontend részéhez kell, hogy be tudjon injektálni egy html meg egy js fájlt xhr-el meg script tag-el.
Az onClicked-nél a toolbar gombra kattintást nézi, annyit csinál, hogy megnyitja az url-t új ablakba, az onBeforeRequest meg letiltja az eredeti oldal betöltését. Ezek mellett a manifest.json-ban van egy match a domain-re, ami beteszi az onClicked-et és az onBeforeRequest-et a background-ba szóval azok a böngésző indításakor futnak, a getURL-es részt meg csak ha stimmel a domain, akkor indítja.
Egyedül a harmadikra sikerült megoldást találnom, de az is vicc kategóriás, hogy mennyire el van bonyolítva:
const Ci = Components.interfaces;
const Cu = Components.utils;
Cu.import("resource://gre/modules/Services.jsm");
Cu.import("resource://gre/modules/XPCOMUtils.jsm");
var observer = {
QueryInterface: XPCOMUtils.generateQI([
Ci.nsIObserver,
Ci.nsISupportsWeakReference
]),
observe: function(subject, topic, data)
{
if (topic == "http-on-modify-request" &&
subject instanceof Ci.nsIHttpChannel)
{
var uri = subject.URI;
if (uri.host == "domain.com" && /main\.js/.test(uri.path))
subject.cancel();
}
}
};
Services.obs.addObserver(observer, "http-on-modify-request", true);Bármi ötlet a másik kettőre meg a package.json-ra?
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Közben találtam a getURL-re is megoldást:
function getURL(relative) {
var wm = Components.classes["@mozilla.org/appshell/window-mediator;1"].
getService(Components.interfaces.nsIWindowMediator);
var recentWindow = wm.getMostRecentWindow("navigator:browser");
var base = recentWindow ? recentWindow.content.document.location : null;
return base + "/" + relative;
}Ez sem egy kellemes valami. Hihetetlen pocsék a firefox API a chrome-hoz képest.
Azt sem értem, hogyha elvileg commonjs alapon megy a dolog, ahogy írják, akkor miért van még egy Components.classes.x.getService(Components.interfaces.y). Egy sima require("nsIWindowMediator") teljesen okés lenne. Eddig úgy látszik nem jutottak el, hát hiába egy normális API tervezésére is rá kell szánni az időt.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz Sk8erPeter #8778 üzenetére
Ez van, nekem se tetszik, de csak pár sorról van szó, úgyhogy elviselem. Közben megtaláltam a hiányzó részeket is a dokumentációban, meg van valami tesztelős plugin, amivel egyszerűbb a fejlesztés, mert nem kell minden módosítás után újratelepíteni, szóval annyira nem kétségbeejtő, legalábbis ennél a projektnél. Amúgy biztosan nem fejlesztenék én sem plugint. Lehet átpörgetem gyorsan egy nap alatt a dokumentációt, csak hogy lássam mik a lehetőségek.
Néhány hasznos link, ha valaki esetleg megpróbálkozna firefox plugin fejlesztéssel:
https://github.com/mozilla/jpm
https://developer.mozilla.org/en-US/Add-ons/SDK/Tutorials/Getting_Started_%28jpm%29
https://addons.mozilla.org/en-US/firefox/addon/autoinstaller/[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Végül nem sikerült összehozni. Maga az injektor működik többé kevésbé, de a chrome pluginban lévő html és js fájlok, amiket a weboldalba injektál úgy néz ki, hogy nem kompatibilisek firefox-al. Debuggolni nem tudom, mert $.html-t használ, ami eval-al szúrja be a scripteket, úgyhogy esélytelen az egész. Elküldtem a kódot a plugin eredeti fejlesztőjének, hátha többre megy vele, mint én. Eltelt kb 20 év, és még mindig ott tartunk, hogy a böngészők közötti különbségek miatt nem lehet normálisan fejleszteni, nem véletlenül utáltam meg a frontendezést.
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz bucsupeti #8795 üzenetére
Most, hogy így mondod, online IDE-t már néztem egyet azt hiszem tavaly, de nekem nem volt szimpi a dolog, valahogy zsigerből idegenkedek tőle. Ilyen irányba esetleg el lehetne menni, hogy egy ehhez tartozó szervert felszórni a céges gépre, aztán otthonról kódolni rá online (már ha erre van lehetőség). [link]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz sunnysys #8846 üzenetére
Én is úgy látom, hogy nincs értelme 40 éves korodra rendesen beletanulnál, de más ilyenkorra már régen középvezető vagy magasabb pozícióban van. Persze próba szerencse, java programozókból meg hiány van úgyhogy még akár össze is jöhet. Papír nem muszáj hozzá. Valami olyasmit kellene keresned, ahol nulláról megtanítanak programozni.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Szvsz, ha oot akarsz tanulni, akkor az élméletet kéne valamennyire elsajátítani, oo alapjai, solid elvek, ddd, rest, soap, tdd, bdd, orm, stb... Ha ezek mennek, akkor már elég könnyen kiigazodsz bármelyik nyelven. Nincsenek olyan hatalmas különbségek közöttük. Én problémának tartom, hogy sokan először a gyakorlatnak futnak neki elméleti tudás nélkül, és feltalálják a spanyol viaszt. Nyilván ez is beletartozik a fejlődésébe valakinek, de éveket el lehet így tölteni anélkül, hogy látványosan fejlődne valaki, a kód minősége, amit produkál meg ugyanúgy alacsony szinten marad.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
válasz bucsupeti #8873 üzenetére
Szerintem érdemesebb struktúráltan elkezdeni oktatni, és ha az már megy, akkor megmutatni, hogy mik a korlátai, és az oo hol egészíti ki, hol add többet nála karbantarthatóság terén, hol meg kevesebbet. [link] Én mondjuk alacsony szinten nem vagyok annyira otthon, js-el kezdtem még 18 éve olvashatatlan spagetti kóddal, az oo elméletet meg hozzáolvastam könyvekből.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
A 3d játékok egész más téma, azoknál shaderek vannak: [link] amiket elsőre elég nehéz felfogni. Ez ugyanúgy egy programozási nyelv független technológia, mint sok más, amivel illik megismerkedni. Amit a programozási nyelvekkel csinálsz, hogy ezeket az algoritmusokat becsomagolod egy jól karbantartható formába, hogyha később hozzá kell nyúlni, akkor gyorsan el tudd végezni a módosításokat.
[ Szerkesztve ]
Buliban hasznos! =]
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- AKCIÓ - TELEFONTOKOK, EGYÉB AUTÓS KIEGÉSZÍTŐK, FÜLHALLGATÓK
- Olympus M.ZUIKO DIGITAL 25mm f/1.8 objektív
- Xiaomi Redmi 9 64GB, Kártyafüggetlen, 1 Év Garanciával
- Dell Latitude E7450 Full i7-5600U, 16GB DDR3, 512GB SSD, FHD IPS, Nvidia, HUN Vil.Bill. Új
- Dell Latitude 7310 i7-10610U, 16GB DDR4, 512GB NVMe, FHD IPS Privacy, HUN Vil.Bill, NBD, Új Állapot