- Yettel topik
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Garmin Fenix 7 és 7S - profi sport megszokásból
- Honor Magic6 Pro - kör közepén számok
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Samsung Galaxy A56 - megbízható középszerűség
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Samsung Galaxy Watch7 - kötelező kör
- Garmin Venu X1 - vékony, virtuóz, váltságíjas
- Kikristályosodik a Razr 60
Hirdetés
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!
-
Mobilarena
Új hozzászólás Aktív témák
-
Gyakorlatilag bármilyen backend, amire eddig közvetlenül a karrierem során ráláttam nagyvállalatoknál. Ha kell egy új microservice, vagy komplex alkalmazás, akkor by default Javaban állnak neki. Mobilon pedig Kotlin, illetve Kotlin Multiplatform tör előre (ez szerintem a natív IOS fejlesztést ki fogja szorítani idővel), amelyek szintén erős Java-kompatibilitással üzemelnek.
-
válasz
martonx
#20535
üzenetére
Szerintem a kolléga arra gondol, hogy nagy általánosságban hamarabb jut eszébe az embereknek a Java-világhoz kötődő implementáció, mint a .NET. És ezt én is megerősíthetem, enterprise környezetben csak előbbivel találkoztam, .NET-nek hírét-hamvát nem láttam sehol.
Egyetlen helyen, az is egy kis KKV volt.
-
Ha jól emlékszem, az Apple a szimulátort nem fogadja el, csak fizikai eszköz screenshotját. Mintha ez rémlene, de lehet, hogy hülyeség, akkor sorry.
Szerk: pénzügyi appról van szó (bank).
Anno tanultam én is Delphi-t, szimpatikus cucc volt. Jobban tetszett, mint a Java-alapú szarok desktopon, de mégis kikopott. Hogy mi volt az oka...fene se tudja.
-
válasz
bucihost
#20367
üzenetére
Kicsit konstruktívabban, mint a kollgák:
- ilyen kis mennyiség esetén valószínűleg egyszerűbb manuálisan javítani
- ha hobbi projekt, akkor érdemes most belecsapni olyasmibe, mint verziókövető rendszer használata, CI/CD folyamat kialakítása. Egy GIT repo önmagában megoldás lehet ilyen helyzetekre egyéb backup nélkül is. -
Ehhez képest jó UI-t készíteni az iszonyat nehéz.
Ezzel egyetértek, de ez nem is fejlesztői feladat, hanem a UI/UX dizájneré, ami egy másik szakma. Frontenden is vannak komplex programozási feladatok, de átlag weboldal nem ilyen. Arról nem beszélve, hogy tipikusan kész komponenseket reciklálnak. -
válasz
totron
#20308
üzenetére
Ez a frontendet mindig is kiemelten érintette, ezért nem fizették meg korábban. Viszont arra ő sem tért ki, hogy mit is csinál pontosan. A portfóliója alapján inkább Wordpress-monkey-nak tűnik, mint olyannak, aki keni-vágja az Angular/React fejlesztést. Az mondjuk beszédes, amikor azt említi, hogy az algoritmusokat nagyon ritkán használja a munkája során.
Wtf. -
#20280
Vision
veterán
BUZZLGHTYR
#20267
válasz
BUZZLGHTYR
#20267
üzenetére
Szerintem érdemes. Ha nem is leszel programozó, az IT-n belül rengeteg helyen tudsz még elhelyezkedni. Ilyenkor viszont nem árt már a legalább olvasási szintű angol. Ha esetleg van valamilyen értelmezhető diplomád is mellé, akkor szinte garantált a siker.
Arra viszont készülj fel, hogy az IT a közhiedelemmel ellentétben nem könnyű kenyér. Folyamatosan tanulnod kell majd munka közben/mellett is, különben végleg lemaradsz. Ez nem olyan, mint mondjuk egy ács szakma, hogy elpötyögsz a megszerzett szaktudásoddal évtizedekig.
-
#20076
Vision
veterán
VikMorroHun
#20071
válasz
VikMorroHun
#20071
üzenetére
Megszűnt a kàrtyaregisztrációs fizetés, tehát mostantól csak eseti topup van, vagy direktben kártyás fizetés. Nem kell új kártyát regelned.
-
válasz
martonx
#20043
üzenetére
Én most konkrétan a mobilra gondoltam (IOS/Android).
...ha state-of-the art appot akarsz, ami az adott platform legapróbb újdonságait is kihasználja
Ez igaz, kérdés, hogy ez mennyire valós igény. Ami szempontot még hallottam, az a performancia. Például egy számításigényes játék nem nagyon lesz soha multiplatform, miközben egy mobilbank simán lehetne. -
válasz
pmonitor
#20035
üzenetére
Ha ezt a nebulók olvasták, akkor nem tudom, hogy kit szidnak, hogy őket meg ezekkel a vezérlési szerkezetekkel szívatják. És még meg is buknak, ha nem csinálják...
Szerintem félreérthető voltam. Egy munkahelyről beszéltem, ahol alapnak veszik, hogy a belépő kolléga ezeket ismeri. Az egyetemen nyilván buktatnak azért, ha még ezt se ismered. -
válasz
pmonitor
#20023
üzenetére
Most speciel nem hülyeség, amit kapizsgálsz. Ettől függetlenül sajnos de, kőkemény tudás kell, mert hiába húzol be rengeteg libet, attól még vannak specifikus fejlesztési feladatok. Ezek egy részét kikönnyítik a külső modulok, de azok megismerése is időt/tudást igényel.
Ez nem mond ellent annak, amit a kolléga írt, sőt! Ő arról beszélt, hogy senki sem ír már meg 0-ról mondjuk egy CRM rendszert, mert nem rentábilis/hülyeség. Ettől függetlenül az üzleti logikákat implementálni kell. Csak mondjuk egy SSO-ra bízzák a jogosultság kezelést, mert tök felesleges ezt is házon belül megvalósítani, van rá a piacon több stabil, kiforrott megoldás is. Ugyanez igaz mondjuk a networkre, securityre, franc se tudja még mikre.
Enterprise környezetben még az is piszok nehéz, hogy millió korlátot kell figyelembe venni. Egyrészt már mindenhol domain szemlélet van. Nem az van, hogy csak odatoszod a kódot, ahova akarod, kőkeményen szervezve van domainek szerint, ami amúgy újabb megoldandó problémákat szül.
Összefoglalva: a mezei, klasszikus programozó feladatok átalakulnak (itt többen is utaltak rá). Ma már nyilván nem az a kihívás, hogy jó vezérlési szerkezetet írjál, hanem hogy ismerd a framework lehetőségeit/korlátait, értsd és betartsd a vállalati patterneket, jól átlásd a business feature-t, stb. És akkor még nem beszéltünk a devops szemlélet meghonosodásáról, CI/CD problémákról, amik már ugyanúgy fejlesztői feladatok.
-
válasz
#01881923
#20014
üzenetére
Vagy még a frontend webfejlesztés, de az meg gondolom borzasztó telített lehet és a 3 közül az érdekel a legkevésbé. Viszont megtanulni valószínűleg azt lenne a legegyszerűbb.
Ha ez alatt HTML-CSS mókolást értesz, akkor az teljes vakvágány, gyakorlatilag már nem is létezik ebben a formában. Ha valamilyen JS keretrendszert, akkor az piacképes, viszont egyértelműen nem a "legegyszerűbb" kategória.A három közül én az Androidot választanám Java-Kotlin vonalon.
-
Hja, sok igazság van abban, amit írsz. Viszont azt is látni kell, hogy a programozási feladatok olyan méretűre nőttek, amelyeket már csak kooperációban lehet megoldani, ezért szétszakadt a szakma ezekre a részterületekre. Egy ideális világban nyilván mindenki piszok jó üzleti és technikai skillekkel rendelkezne, de azt te is tudod jól, hogy ez nem a jelenkor realitása. És így jutunk el oda, hogy én már örülök annak, ha egy BA-nak IT végzettsége van, ha egy architect ténylegesen dolgozott is az iparban, és ha egy fejlesztő képes komplex üzleti problémákat legalább alap szinten megérteni. Ez már egy elég jó alap az értékteremtéshez.
-
válasz
#79484416
#19885
üzenetére
Én azt hittem, az automatizálásnak a rendszergazdák lesznek az első áldozatai, nem a fejlesztők.
A rendszergazda szakma reneszánszát éli, csak ma már devopsnak hívják.Tényleg kihal a programozó szakma és géppel helyettesítik?
Ahogy emvy is írta, a programozás jobb esetben nem arról szól, hogy kódsorokat írunk, hanem értelmezünk üzleti problémákat, amelyekre elég jó megoldásokat szállítunk. Erre az AI nagyon-nagyon sokáig, sőt, talán sohasem lesz képes. Egy tool, amit lehet használni, és kész. -
Meglepődnél, hogy mennyire hitvány a fejlesztői dokumentációk minősége, már ha egyáltalán készül. És oké, abban a lehetetlen helyzetben, amikor az egész cég kipusztul, és csak egy repo marad utána, onnan nehéz újjáépülni. De ha maradnak még bőven kompetens szakértők, akkor simán megoldható.
-
Nagyvállalatoknál erre standardok vannak (ezek lokális karbantartása pl. része a munkakörömnek).
Egyébként nem hülyeség, amit pedzegetsz, lásd: Synergon vezetőségének halála. Vannak olyan szervezetek, ahol például a topmenedzsment nem utazhat együtt, pont ilyen okokból. De mezei fejlesztőkre ez természetesen nem él, nem is lenne értelme. Normál esetben a cég tudásvagyona georedundánsan kerül tárolása. Akár a teljes fejlesztő csapat kiesése sem szabad, hogy csődbe vigye a vállalatot.
-
Köszi. 2xx-et van értelme túlcizellálni? Ugye siker esetén default 200-at adnék vissza, de ha igazán szépet akarok, akkor lehetne 201 is, hiszen feltétel, hogy egy rekord perzisztálódjon.
A 409-es duplikáció csupán elméleti lehetőség, elvileg sosem jöhet ilyen kérés, mert kliens oldalon is le van státuszolva. De most szépen le akarok kezelni mindent, mert az implementáló csapat igazi kókány brigád.
-
-
válasz
Marky18
#19633
üzenetére
Felesleges, 2 service fog kommunikálni. Erre behozni egy message brokert kicsit ágyúval verébre. Már ez a fajta hibakezelés sem volt eredetileg tervben, csak a szépérzékem eszembe juttatta. Alapvetően nem számítunk arra, hogy a 2 service közötti kapcsolat bármikor is megszakad (egy infrán, sőt, egy szerveren belül csücsülnek).
-
Nem igazán ismerem a nodejs ökoszisztémát. Meg lehet ott valósítani alkalmazáson belül egy ütemezőt/q-t/bármi hasonlót? Például lekezelni azt, hogyha egy REST végpontról nem érkezik válasz, vagy nem olyan, amit szeretnénk, akkor bizonyos időközönként újrapróbálkozzon?
-
válasz
pmonitor
#19431
üzenetére
Amúgy te tanultál felső matematikát? Csak azért, mert az általad vázolt optimalizációs probléma nem újkeletű, hanem évszázados története van, kész modellekkel, algoritmusokkal. Anno még 7 éve dolgoztam egy cégnél, ott ennél sokkal-sokkal bonyolultabb peremfeltételek mentén dolgoztak ilyesmin. Csak azt akarom kihozni a dologból, hogy kételkedem a megoldásod egyediségében/innovatív mivoltában.
-
Üzleti appoknál ez kritikus. Biztos vagyok benne, hogy ez kényszerítette ki ezt az egész Typescript átállást. A JS benyomult az enterprise világba, ott pedig tarthatatlan lett volna a régi módi.
Én már régesrég foglalkoztam kódolással, akkor a TS még tervben sem volt, de már akkor szembesültem a JS ezen hiányosságával. Nyilván le lehetett ezt kezelni, de külön figyelni kellett rá. A hozzám hasonló koca programozóknak ez első körben nem volt triviális. Automata teszteket hírből sem ismertük, azoknál is fontos.
De majd a profi kollégák jönnek, és kifejtik jobban.
-
Haha, tudok olyan pszichológusról, aki az SAP-nál kötött ki pár év után. Nyilván nem hardcore coder, de valami IT-közeli dolgot csinál. A férje is ott melózik, biztosan így sodródott bele. De már az asszony is mondogatta, hogy átképzi magát IT-ssá. Egészen jó frontendes lenne belőle. UI/teszter fronton egészen sok nő tevékenykedik, illetve a határterületeken is. Ismerek olyanokat, akik pénzügyi modelleket építenek, és nyilván programoznak is ehhez. Szóval maga a helyzet változik, csak lassan.
-
-
Az aránytalanság mértékében tartom kizártnak a biológiai okot. Miért választja az egyébként matekos-reálos területet sokkal-sokkal több nő, mint a szintén matekos-reálos másikat? Sok helyen még a felvételi tantárgyak is azonosak.
Nem a férfi/női különbségeket tagadom, erről szó nincs.
-
Érdekes ez a vita, nem is akarok egyesével reagálni. Azért dobtam be a témát, mert szemmel láthatóan más reál jellegű területeken jóval magasabb a nők aránya, mint az IT-ban, vagy a gépész/villamosmérnököknél. Közben biomérnök, vegyészmérnök, közgázelemző, pénzügy szakok tele vannak nőkkel. Pedig ezek is matekos területek vastagon. De említhetném az asszonyt is, aki építészmérnök lett, és matekból emeltezett, plusz fizika volt a másik tárgya érettségin. Nyilván a szaktársainál ugyanez volt a helyzet jellemzően, szóval nem buta lány egyikük sem.
Azt kizártnak tartom, hogy fiziológiai okok állnának a háttérben. Egészen biztosan a neveltetésben, környezeti tényezőkben kell keresni a választ. De hogy mi az, arról fogalmam sincs.
-
Nem értem, hogy a gyakorlatban miért van ez. A Közgáz matekos közgáz szakjai tele vannak nőkkel, még a biztmat/közgázelemző is, pedig attól sok mérnökinfós is vért hugyozna. Érdekes.
Aztán persze a szaktáraim egy része az IT-ban kötött ki. Egyik németben az SAP-nál fejlesztési osztályvezető, másikuk Blackrocknál programoz, és van még pár ilyen sztori. Nőből vannak.
-
Na jah. Én kapásból az Apple ökoszisztémájából indultam ki, ahonnan azért ez parádé lenne. Viszont tényleg tele van a piac olyan konzumer cuccokkal fillérekért, amelyek gyűjtik az ujjlenyomatodat, és nyilván könnyen törhetőek. Ismerősöknél láttam múltkor okoskilincset a kapun, szintén ujjlenyomatos beengedéssel. Valami Aliexpress csoda volt. Hát, én nem raktam volna fel, az tuti.
-
Ezt viszont jó lenne tisztázni, mert kulcskérdés. Ha a banki appoknál tényleg az van, hogy az authentikáció a készülék által történik, akkor gyakorlatilag megvalósult a 0. pontban általam felvázolt scenario. Innentől már tényleg csak egy lépés az, hogy ne a készülék legyen a szolgáltató, hanem bármi más.
-
-
válasz
fatal`
#18892
üzenetére
Én ezt úgy képzelem el, mint ahogy mindenhol máshol is: lehet választani FB, Google, Apple, akármi közül, de nincs saját auth. a rendszerben. Alig várom, hogy többen meglépjék ezt, mert a tököm kivan a mindenhol saját auth, saját password policyvel.
A kérdés nem hipotetikus, ugyanis éppen szívunk egy saját SSO-val (amit az EMEA központ erőltet ránk), de 1+ év alatt nem sikerült használható állapotra hozniuk.
-
-
Enterprise szinten a nettó erőnél vannak sokkal fontosabb szempontok is. Ha egy auditon elhasalna a provider, akkor nyilván csak az árral tud versenybe szállni. Nem véletlen, hogy az AWS és az Azure hasít a nagyvállalatoknál, nem pedig noname cloud szolgáltatók (hiába olcsóbbak).
-
válasz
sztanozs
#18420
üzenetére
Háát, az ilyen szerver log típusú dolgokat nem sorolnám ide. Nem mindig éles a határvonal, de például egy proxy esetében biztosan. Plusz ezeket nem is db-ben szokás tárolni, hanem fájlrendszeren plain textben. És ne gyere most azzal, hogy nálatok esetleg pont nem így van, mert akkor a kardomba dőlök!
-
Persze, tudom. Ezért csaptam oda a retailt is (most pont ilyen helyen dolgozom), ahol megdöbbenek, mennyire szabályozatlan minden, mégis mindent megőriznek.
Egyébként az általános hozzáállás az, hogy az adat tárolása olcsó, szóval inkább őrizzük meg, hátha jó lesz még valamire. A szelekció önmagában egy rakás architect munkaóra lenne. A storage meg filléres tétel már.
-
Amikre ráláttam nagy rendszerek (telco, finance, retail), ott szó sem lehetett arról, hogy ne tároljanak le nyers adatokat. Egyrészt azért, mert az adat a legnagyobb kincs (ez már sok-sok éve ki lett mondva mindenhol), másrészt az aggregáció logikája nem stabil soha, ezért sosem szabad a legalsó szintre rakni. A big data módszerek terjedésével ez hatványozottan igaz.
Nincs 100%-os rendelkezésre állás, soha senki sem állította ezt magáról. A tizedesvessző utáni 9-esek számán szokott megmutatkozni a minőség, és persze az ár is.
-
Még annyit hozzátennék, hogy a nagyon komplex olvasási műveleteket jellemzően kiszervezik az adattárház rétegbe. Ott meg aztán mindenki úgy buzul az adatokkal, ahogy akar.
Mondjuk arra kíváncsi vagyok, hogy a blockchain olvasási sebessége miért gyorsabb, mint egy centralizált rendszeré. Ugyanis ilyen állítás is elhangzott előbb.
-
A hitelesség biztosításához - a technológiából adódóan - nagyságrendekkel több erőforrást éget el, mint egy centralizált rendszer. Valódi előnye pedig nincsen. Nem véletlen, hogy a nagy blockchain láz idején is a csillogó szemű hívőknek semmilyen konkrét érvük nem volt mellette, csak az olyan abszurditások, minthogy: vége az eddig létező pénzrendszernek, kormányok fognak megdőlni, és társai.
-
emberek jo resze igazabol lofaszhoz se ert
A most már kvázi CTO - aki btw a legjobb fejlesztő, akivel valaha dolgoztam - haverommal szoktunk azon keseregni, hogy a fejlesztők nagy része objektív hülye és/vagy nem hajlandó gondolkodni. Agyatlanul lefejleszt valamit, ami le van írva, és még véletlenül sem gondolja végig, hogy van-e értelme.
-
...ne lehetne egy villanyszerelő is profi abban, amit csinál, és egy programozó ne lehetne középszerű, vagy csak szimplán szar.
Ez nem cáfolja azt, amit írtam. Simán csak arról van szó, hogy a villanyszerelőség csúcsához messze gyengébb skillek kellenek, mint a programozóság csúcsához. Én végeztem hobbiból szakmunkás képzéseket, ott számtalanszor elhangzott, hogy a szaki NEM tervez semmit, hanem kivitelezi azt, amit a mérnök megtervezett. A kivitelezés nem kreatív szakma, szabványokat kell betartani, és kész. Persze ott is fontos az önképzés, de közel sem olyan szinten, mint az IT-ban.
egy sql lekérdezést megcsinálásában
Az SQL-tákolás nem programozás by definition. Ettől függetlenül ez is igényel szaktudást, főleg komolyabb riportok esetén.
Pont ugyanolyan nehéz, mint megtervezni egy ház elektromos hálózatát és bekábelezni.
A ház elektromos hálózatát nem a villanyszerelő tervezi, hanem villamosmérnök a gépészeti kiviteli terv részeként. És de, sokkal egyszerűbb jól bekábelezni egy épületet, mint megírni jól egy webáruházat. Mindkettőt csináltam már nem is egyszer. Nem véletlen, hogy a melósok nagy része ostoba jobbágy. Azért a programozók többségéről ez nem mondható el!
És akkor most a morális kérdésekbe bele se menjünk (a szakik nagy része úgy hazudozik össze-vissza, mint a vízfolyás)!
-
....persze más skillek kellenek hozzá
Azért na! Ez most olyan, mintha azt mondanád, hogy az árokásó cigány munkája == egy atomfizikus munkájával. Hiszen csak más skillek kellenek hozzá.Szóval de, bonyolultabb programozónak menni, mint lakatosnak, vagy burkolónak. Előbbi jó esetben egyetemi végzettséggel jár együtt, utóbbiakhoz még érettségi sem kell.
És akkor most ne menjünk bele a kell a programozónak diploma/nem kell utcába!
-
...enélkül a fejlesztők nem fognak közös nyelvet beszélni.
Ez amúgy minden szakterületen fontos. Ha nem ismered a szakzsargont, akkor hülyének fognak nézni, hiába vagy amúgy tök jó képességű. Lehet erre azt mondani, hogy felszínesség, de egy munkahelyen nem nagyon van arra idő, hogy körmondatokban fogalmazz.
Mondjuk ezek át tudnak menni egészen abszurdba. Vannak kifejezések, amik elterjednek, és aztán mindenki elkezdi használni őket 2-pofára. Az egyik helyemen ilyen volt a "perzisztens" szó, ami egy tök jó kifejezés, de gyakorlatilag felesleges használni a fejlesztési feladatok nagy részében. Mégis minden meetingen repkedett a perzisztens, én meg nem értettem, hogy minek kell ezt állandóan mondogatni, hát mindenki tudja, hogy mi ez.
-
De mondjuk egy bonyolult sql lekérdezést van, hogy nem tudsz megoldani 1000 sor alatt, ha meggörbülsz sem.
Abban egészen biztos vagyok, hogy ez nem jó. Ilyen esetben át kell variálni a DB-t, kiforgatni, köztes absztakciós réteget beiktatni, bármit. 1000 soros, de akár 100 soros SQL is kerülendő.
Nem attól lesz egy kód rossz, hogy hosszú, hanem ha spagetti, felesleges köröket tartalmazz.
Semmi konkrétumot nem mondtam a kódminőségről . Sőt, igazándiból gyakran a hosszabb kód az egyszerűbb. És persze, emvy leírta, hogy az egyszerű fogalom milyen nehezen megfogható. -
Uhh, nem akartam én ennyire mélyen belemenni.
Tömören próbáltam megfogalmazni alapvető trendeket, amiket látok. Nyilván nem a gányolásra gondoltam az egyszerűség alatt, hanem arra, hogy az üzleti igényre nem a pmonitor által folyamatosan pedzegetett elv a válasz, hanem a peremfeltételek mellett (fenntarthatóság, stabilitás, fejleszthetőség, biztonság, stb.) az egyszerű és gyors implementáció. Egy AI leletező szoftver kódbázisa nyilván komplexebb lesz, mint egy random Java weboldalé. De amúgy nincs köztünk vita semmiben. -
A programozásnak pont a lényege komplex kódok alkotása...
Kis szőrözés, és lehet, hogy amúgy erre gondoltál, de szerintem a programozás lényege a legegyszerűbb működő megoldás szállítása az adott - jellemzően üzleti, de nem feltétlenül - problémára. Amennyire látom, a fejlődés pont abba az irányba megy, hogy minél kevésbé legyen komplex a kód. Ugye a magas szintű nyelvek éppen erről szólnak. De cáfoljatok meg, én már csak a pálya széléről ugatok.
Persze most nem a pmonitor által elképzeld dolgokról beszélek, hanem a ténylegesen leszállított kódok 99,99%-áról.
-
válasz
K1nG HuNp
#17878
üzenetére
Az, ami a krétánál történt védhetetlen. Eleve hogy lehet hozzáférése a fejlesztő cégnek produktív rendszerhez? Hogy lehet teljes hozzáférése egy szaros PM-nek produktív rendszerhez? Hogy lehet az, hogy meg tud nyitni fertőzött URL-t? Megannyi kérdés, és sehol egy válasz.
Ez a legdurvább adatvédelmi incidens az ország történetében, és megy a nagy maszatolás. Mert a NER-es haveré a cég. Őrület.
A pentestet meg kell rendelni. Ezt nyilván nem tette meg a kréta fejlesztője, mert akkor régesrég kiderültek volna ezek a problémák. Mégis hogyan derült volna fény ezekre a sebezhetőségekre törvényes módon? Ettől még azok a srácok, akik megcsinálták bűncselekményt követtek el.
Wtf.
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- eBay-es kütyük kis pénzért
- Kerékpárosok, bringások ide!
- Yettel topik
- Call of Duty: Black Ops 6
- Milyen egeret válasszak?
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Miért álltak az oldalak egy hétig, mi történt?
- Milyen videókártyát?
- Garmin Fenix 7 és 7S - profi sport megszokásból
- ASUS routerek
- További aktív témák...
- LG 32GS95UE - 32" OLED / UHD 4K / 240Hz - 480Hz & 0.03ms / 1300 Nits / NVIDIA G-Sync / AMD FreeSync
- Bomba ár! Dell Latitude 7320 - i5-11GEN I 8GB I 256SSD I HDMI I 13,3" FHD I Cam I W11 I Garancia!
- Fujitsu LIFEBOOK E449 i5-8250U 12GB 512GB 14" FHD 1 év garancia
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- Bomba ár! HP Elitebook 850 G3 - i7-6GEN I 16GB I 256GB SSD I RadeonI 15,6" FHD I Cam I W11 I Gari!
Állásajánlatok
Cég: FOTC
Város: Budapest