- sziku69: Fűzzük össze a szavakat :)
- sellerbuyer: Milyen laptopot vegyek? Segítek: semmilyet!
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- sh4d0w: Árnyékos sarok
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Magga: PLEX: multimédia az egész lakásban
- sziku69: Szólánc.
- Lalikiraly: Sencor SMC BS30 aktív hangfalszett bemutató
-
LOGOUT
Új hozzászólás Aktív témák
-
Szerintem senki sem replikálja a DB-t kliensoldalon, az tisztán szerveroldali cucc (már csak a szinkronizációs problémák miatt is, de a jogosultságok kezelése, adatforgalom meg hasonló tényezők is emellett szólnak), a kliens meg tényleg csak azt kapja meg, amit meg kell kapnia (az update-ek mehetnek websockettel, long pollinggal, server sent eventekkel) és csak azt küldi vissza, amit változott.
(Szerveroldalon meg nyers SQL-ezés helyett inkább ORM-ek vannak, bár persze van olyan kis feladat, aminél nem érdemes vessződni vele.) -
válasz
bandi0000
#17129
üzenetére
Nálunk ez úgy néz ki, hogy az emberünk, aki úgy nagyjából admin szinten ismeri a szoftverünket meg elég jól a területet, ahol alkalmazzák, elmegy tárgyalni az ügyféllel és kiszedi belőle vagy együtt kitalálják hogy tulajdonképpen mit is akar (van, akinek csak halvány elképzelései vannak meg van, aki hosszú követelménylistával jön) és összerak velük egy olyan követelménylistát, ami nagyjából illeszkedik a mi szoftverünk logikájához.
Aztán átvesszük vele mi, fejlesztők ezt a listát, megnézzük, hogy mi az, amit tudunk gond nélkül, mi az, amihez esetleg vmi ravaszabb konfiguráció vagy script kell meg mi az, ami tényleg új fejlesztés.
Következő kör nálunk fejlesztőknél, hogy mit hogyan tudunk megoldani.
Aztán a fejlesztési feladatokat szétszedjük kisebb, nagyjából belátható részekre, függőségek alapján csoportosítjük őket, aztán az egyes részeket planning pokerrel megbecsüljük.
(Fontos lenne itt még egy plusz rész, ahol a tényleges fejlesztési idők alapján megnézzük, hogy mennyire voltunk pontosak és ha nagyon félrement valami, akkor miért, de ezt nehéz megvalósítani: az igényfelméréstől a konkrét megvalósításig viszonylag sok idő tud eltelni, szóval nem feltételnül emlékszünk már, hogy mit miért gondoltunk, illetve az időfelhasználást se trackeljük igazán.)
Ennyiből szerintem látszik, hogy ami igazán fontos, az az első lépésben lévő ember munkája, szerintem azon bukik vagy áll az egész. -
A logikája az elosztott volta miatt némileg különbözik (pl. ilyen root lista nem létezik a gitben, viszont vannak mindenféle egyéb, gitre épülő cuccok, mint a GitHub, GitLab, Gogs meg ezer más, amik tudnak ilyet) meg néha utána kell nézni dolgoknak, mert amúgy csak a wtf ül ki az ember arcára, de alapvetően nem nagy macera átállni.
Én a Visual Studio Code beépített git kliensét használom, az rendben van. A GitKraken jó (bár amikor én használtam akkor erősen memleakesnek tűnt), de abból az ingyenes verzió mostanra már nagyon korlátozott (csak nyilvános github repókkal lehet használni), a fizetős meg drága (60 usd/év) otthoni bohóckodásra.
-
válasz
bambano
#17076
üzenetére
nem emlékszel a google első felhasználói szerződésére?
Szerintem valamivel kevered, de most nem hoz elő semmit a google-fum, mindenesetre az az eset se tudná nagyon alátámasztani azt, amivel riogatsz.
szerk: ja, közben jutott eszembe: meltdown. spectre.
Ennek mi köze a githubhoz? -
válasz
bambano
#17071
üzenetére
jaja, rakd csak publikus cloudba, majd hirtelen kapsz egy üzenetet, hogy mostantól minden, ami a cloudban van, az a cloud szolgáltatóé.
Ennél röhelyesebb, átlátszóbb, nyilvánvalóan megvalósíthatatlanabb szcenárióval riogató FUD nem jött össze?
ha nem fontos, akkor mehet githubra, cloudba, stb. ha fontos, akkor saját vas, backuppal, stb.
Itt azért azt kellene valahogy demonstrálni, hogy mondjuk a Github az kevésbé megbízható, mint az, amit egy kis- vagy mikrovállalkozás saját erőből össze tud rakni. Sok szerencsét!
-
Szerintem itt nem igazán köcsögösködés ment, inkább nagyon mély meglepetés.
2022-ben nem egy, hanem három olyan fejlesztő, akik nem hagy nem használnak, hanem láthatóan még nem is hallottak a gitről (vagy legalább az SVN-ről vagy bármi verziókövető rendszerről), az nagyon meglepő.
(És mégmielőtt: én is nagyon kis cégnél dolgozok, saját kezűleg deployoltam a Jira containert, és az otthoni hobbyprojektjeim (amikkel aztán tényleg csak én szöszölök) is git repoban vannak) -
válasz
pmonitor
#16886
üzenetére
Elég szomorú, hogy az évtizedek alatt senkinek sem jutott eszébe optimalizálni az alapvető függvényeket/metódusokat sem.
Mert mindenki hülye és csak te vagy helikopter.
Egyébként sikerült már olyan atoi()-t írni, ami megcsinálja azt, amit a szabvány elvár tőle? Nem? Hát akkor meg mire ez a nagy arc? -
#16879
dabadab
titán
Netszemete
#16877
válasz
Netszemete
#16877
üzenetére
Épeszű(!) programozó nem kezdi újraírni a glibc-t, ha nincs rá nagyon jó oka. ;) De előfordulhat, hogy van rá ok.
És azért előfordul, hogy van rá ok. Épp a múltkor csodálkoztam rá arra, hogy hányféle hashmap implementáció van C++-hoz, pedig ott van az std::unordered_map: [link]
-
válasz
pmonitor
#16771
üzenetére
Éppen most készítem ezt a dolgot(még nincs teljesen kész). De az látszik, hogy a stringet számmá konvertáló beépített függvények C-ben ~19, míg C#-ban ~68 sec. alatt futnak le, miközben könnyedén lehet ~10 sec. körüli futásidőt elérni ugyanarra a feladatra(inputra).
Ja, gyorsabban lefut, csak nem működik meg baromira nem azt csinálja, amit a C szabvány (ez a draft, a végleges csak fizetős formában elérhető, de abban is ugyanez van) előír. Érdemes megnézni a szabványt meg mondjuk a GNU C lib forráskódját aztán összehasonlítani a tieddel, amiből pl. teljesen hiányzik a locale-kezelés.
Szóval igen, érdemes nem azt gondolni, hogy rajtad kívül mindenki hülye, mert kiderülhet, hogy pont fordítva van. -
#16760
dabadab
titán
Atomantiii
#16759
válasz
Atomantiii
#16759
üzenetére
Ilyesmi felhasználásra van az SQLite. Persze ennek is megvan a saját SQL-dialektusa, szóval a queryket valószínűleg át kell egy kicsit faragni meg az on-disk formátuma nem kompatibilis, szóval mindenhol SQLite-ot kell használnod, MySQL adatbázist nem fog tudni olvasni.
-
#16754
dabadab
titán
Netszemete
#16753
válasz
Netszemete
#16753
üzenetére
a dBase mióta programnyelv? Én úgy tudtam, az egy adatbáziskezelő.
A dBase nem csak egy adatbáziskezelő program, hanem van egy saját programnyelve is.
Egyébként a dBase III leszármazottja a FoxPro, amivel a korai kilencvenes években rengeteg ügyviteli szoftver készült, mivel az már tudott .exe-t is produkálni, szóval pont a dBase teljesen jó helyen van ott. -
#16704
dabadab
titán
Netszemete
#16703
válasz
Netszemete
#16703
üzenetére
Hogy a "hiszti" szót használod egy egyébként szakmai témában, az csak téged minősít.
Szerintem nem szakmai témában használta, hanem az általad itt rendezett... hisztit nevezte meg.
-
#16669
dabadab
titán
böng ész ő
#16668
válasz
böng ész ő
#16668
üzenetére
A Liskov-féle helyettesítési elv arról szól, hogy ha van egy függvényed, amit meg tudsz hívni egy A osztályú objektummal, mint paraméterrel, akkor az A-ból származtatott B osztályú objektumot is átadhass neki paraméterként és működjön, akkor is, ha az adott függvény azt se tudja, hogy az az adott objektum nem A osztályú vagy hogy egyáltalán létezik B osztály.
Ez annyira alap és magától értetődő dolog bármelyik modern objektumorientált nyelvnél, hogy valószínűleg azért lehetett nehéz megérteni, mert eszedbe se jutott, hogy ezt így külön le kellene írni, hiszen ez a természetes
-
#16666
dabadab
titán
böng ész ő
#16665
válasz
böng ész ő
#16665
üzenetére
nem olyan agyoncenzúrázott, mint a stackexchange oldalak
Wut?
-
válasz
ReSeTer
#16598
üzenetére
Igazából ilyen feladatoknál szerintem érdemes körbenézni, hogy van-e valami létező program, amit lehet használni erre a célra, ahelyett, hogy te magad írnál valamit.
Amúgy meg ha tényleg kicsi meg tényleg meg kell írni, akkor inkább Pythont néznék, az tök jó ilyesmire.
-
válasz
pmonitor
#16575
üzenetére
Nálam itt az sprintf(...) stabilan 6 sec felett, az assembly kód stabilan 2 sec. alatt teljesített.
Mert nem ugyanazt csinálták: az sprintf() egy elég nagy tudású, rugalmas függvény, a te assembly kódod meg csak 32 bites inteket tud kiírni mindenféle formázás nélkül. Nyilván ha ugyanezt megírod C-ben, az is gyorsabb lesz, mint az sprintf, vagy ha az sprintf()-et megírod assemblyben, az meg minden bizonnyal lassabb lesz, mint az, ami a gyári stdlibben van (az alapján, hogy a mostani assembly kódod is elég szuboptimális).
Sőt, itt van C-ben egy még gyorsabb megoldás, ami a te assembly kódoddal ellentétben még csak nem is bugos
int int_ToString(int num, char* dest) {
memcpy(dest, "-2138\n", 7);
} -
válasz
pmonitor
#16566
üzenetére
Gondolom azért, mert kevés komponenst telepítettél.
Igen, mert nem fejlesztek egyszerre harminc nyelven - ahogy egyébként kb. senki sem.
Amúgy meg azt a 4 GB teljesen érdektelen, maga a forráskód, amivel dolgozok, szintén akkora, ha meg még le is fordítom, akkor meg 60 GB.#16568 Ispy:
Én is csak azért tudom, mert most direkt megnéztem -
válasz
zsolti_20
#16539
üzenetére
Igen, de ehhez a böngészőben telepíteni kell a Tampermonkeyt + a konkrét scriptet is.
Azt mondjuk nem látom, hogy ez miért segítene neked, hiszen ez kliensoldali script, ez nem fogja látni azt az Excel file-t, ami nálad van.A konkrét weboldalhoz mennyire férsz hozzá? Konkrétan át tudod írni a html-t vagy csak vmi indirekt módon?
-
válasz
don_peter
#16500
üzenetére
Hogy oldják meg azt, hogy mondjuk egy adatbázis kapcsolati adatok ne kerüljenek ki?
Úgy, hogy az a szerveren van
Az ilyen webes cuccoknál a frontend-backend architektúra a normális, a szerveren fut a backend, az kapcsolódik az adatbázishoz, csinálja az autentikációt meg a lényegi dolgokat, a kliensnél meg csak egy kis minimál rész van, ami a megjelenítést meg az inputot csinálja.
A kettőt meg tipikusan vmi REST API-val kötik össze.Ami a kliensnél van, arról nyugodtan feltételezheted, hogy ahhoz hozzá lehet férni, illetve arra is számítsál, hogy a klienstől érkező adatokba belepiszkáltak, szóval a backend rendes input validációt meg hasonlókat kell csinálni, mert különben úgy jársz, hogy a T Systems a BKV bérletekkel
-
válasz
don_peter
#16481
üzenetére
Ha ilyet akarsz csinálni, akkor nem igazán programnyelvet, hanem egy cross platform app development frameworköt kell választanod, mert az kell neked.
Amíg ide nem téved egy mobilos fejlesztő, csak így idehánynám az ismertebbeket, zárójelben a használt programnyelvvel:
Flutter (Dart)
Xamarin (C#)
React Native (JS + HTML)
NativeScript (JS + HTML)
Ionic (JS + HTML) -
válasz
btraven
#16438
üzenetére
Egyébként a korai Commodore C64 zenék kb. pont így készültek (kb '86 tájáig), csak nem Pythonban, hanem 6502 assemblerben, illetve mégígyebb, mert az egyes hangszerek nem sima hangmintalejátszásból álltak, hanem a hangchip regisztereit kellett real-time bizergálni.
Most meg bytebeat van, az külön agybaj
Dokumentáció meg játszótér: [link]
Egy durvább darab: [link] -
-
-
-
-
-
válasz
Demertin
#15880
üzenetére
Hát, ha katona nem akarsz lenni, akkor csak a gyártásnál tudsz lövöldözőgépekkel
foglalkozni, ott meg aztán tényleg az adott cégtől függ, hogy konkrétan mit és hogyan használnak szoftveres téren. (Magyarországon van egyáltalán bármi ilyesmi a tervezett Lynx gyáron kívül? Mondjuk külföldre menni lehet, hogy kisebb megrázkódtatás, mint Zalaegerszegre ![;]](//cdn.rios.hu/dl/s/v1.gif)
)Mondjuk Pythonnal nem nagyon tudsz melléfogni, egyrészt elég népszerű ahhoz, hogy jó eséllyel belefuss, másrészt nagyon hasznos tud lenni akkor is, ha amúgy nemm kell semmi konkrét szoftveres dolgot csinálnod, csak a saját munkádat akarod részben automatizálni.
-
-
#15865
dabadab
titán
MostaPista
#15862
válasz
MostaPista
#15862
üzenetére
de meg azzal se foglalkozott senki, hogy milyen programmal lehet ezt megcsinalni
Dehogynem, írták, hogy vmi ticketing v project managment rendszerre van szükséged, nem naptárra és arra kaptál példákat is.
-
#15841
dabadab
titán
MostaPista
#15840
válasz
MostaPista
#15840
üzenetére
Ugye, ezek a javaslatok mind megfelelnek az ingyeneses off-line hasznalhato alapfelteteleknek.
Azt nem teljesen értem, hogy ha van tízmilliós nagyságrendű pénzed arra, hogy újat készítess, akkor a meglévők pár dolláros havidíja miért gond?
-
válasz
Weareus
#15816
üzenetére
Van két szólistám, amit notepad ++-ban szeretnék összerakni egybe
Itt ezen a ponton nem értettem, hogy hogyan jön össze egy szövegszerkesztő két zenésszel.
Ilyenkor azokat a sorokat, (minden sorban pontosan egy szó van), amik kétszer v. többször fordulnak elő, kitörli, de egyet meghagy belőle.
A kérdés az, hogy melyiket?Az elsőt hagyja meg.
-
válasz
Livius
#15782
üzenetére
Ezt a template programozást arra érted, hogy előre fel van töltve pár típus struktúra különböző SPI controllerek fv pointereivel meg konfigjaival?
Nem, hanem pl. az MXC_SPI_BUF_RX makróra, ahol a makróparaméter egy típus.
Más kernel forrásban úgy emlékszem van olyan postfix sokszor a változóknak, hogy _u64, _s32, ez itt egyáltalán nincs, pedig nálunk erre nagyon lenne majd igény.
NE!
Szerintem rosszul emlékszel, mert Linus véleménye erről az, hogy "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer" - és ez nyilván érvényes a változókra is és pont ez a félreértett hungarian notation, amiről az elején beszéltem - Simonyinak esze ágában sem volt ilyen hülyeséget kitalálni. Amit ő kitalált, az az, hogy szemantikus típusjelentést rakjon bele a változónévbe. Primitív és némileg erőltetett példa, de mondjuk koordinátáknál az X és az Y koordináta is int (vagy float vagy akármi), szóval a fordítóprogram szempontjából tök egyforma típus, de mégis teljesen más a jelentésük, amit érdemes jelezni a programozónak, szóval a pos_x és a pos_y az legitim használata a HN-nek - a s32_pos viszont nem.Figyelmes olvasók itt rámutathatnak a hozzászólásom elejére, ahol az a makro olyan függvényeket generál, mint spi_imx_buf_rx_u8 meg spi_imx_buf_rx_u32. Igen, ez itt a kivétel, ahol van értelme belekódolni a függvénynévbe, mert a függvény lényege (és megkülönböztető eleme) az, hogy milyen értékkel dolgozik, az soha, semmilyen körülmények között nem merülhet fel, hogy az spi_imx_buf_rx_u8 mégis inkább egy előjeles 16 bites integerrel dolgozzon.
-
válasz
Livius
#15771
üzenetére
de azért én erre nem merném kimondani, hogy annyira patent, közelebb áll a vacakhoz mint a tökéleteshez
Pedig ha megnézed, van benne template programozás is, az szerintem jópofa.
A nevezéktannál meg jól látszik, hogy a következő szabályok vannak:1. nincs camelcase, underscore van
2. minden függvény neve az a scope, ahol érvényes
3. a függvénynevekben csak tök elterjedt (tx, rx, clkdiv, buf) illetve a domainspecifikusan egyértelmű (pl. wml) rövidítéseket használ, minden más ki van írva
4. ha boolt adnak vissza, akkor eldöntendő kérdés a függvény neveMost így gyorsan ránézve a kódra nem nagyon látszott, hogy lenne benne különösebben nehezen érthető dolog.
-
válasz
Livius
#15768
üzenetére
De nektek egyébként muszáj C-t használnotok? Nem tudom, hogy a libraryk milyen formátumban vannak, de alapvetően C++-ból tök simán lehet C-s libeket használni, de ha valami nagyon elborult saját bináris formátum, akkor az is létező opció, hogy C++-ból C kódot generáltok (clang biztosan tud ilyet, meg szerint g++ is) és azzal etetitek az ő fordítójukat.
-
válasz
Livius
#15765
üzenetére
Szerintem nagyon kevés benne a kernel-specifikus cucc, a nagyobb része általános C programozás.
A változónevek meg... hát annyi, hogy értelmes ÉS rövid legyen, ennél sokkal specifikusabban nem nagyon lehet semmit sem mondani, mert ami ennél többet mond, az mind olyan változónevezési módszertan, ami plusz infókat rak a változónévbe valamilyen rendszer szerint (mint pl. a rettenetesen félreértett Hungarian notation), itt meg arról van szó, hogy ne legyen benne ilyen. Ha meg példa kell, akkor ott a komplett kernelforrás (és ez a guide egyébként ezért is jó, mert egy valós, több évtizedes, több ezer ember által írt hatalmas kódbázisra működik, amiben nagyon-nagyon sok dologra van példa, méghozzá jó példa, mert ide vacak kód nem kerül be).
-
válasz
pmonitor
#15734
üzenetére
Szerintem az állandó nyavalygásoddal elérted, hogy senki nem akar neked segíteni.
Eleve úgy jöttel erre a fórumra, hogy a saját oldaladat promóztad, ahol amiatt nyavalyogtál, hogy milyen emberek vannak itt és azóta is úgy viselkedsz, hogy semmi köszönet nincs abban, ha valaki segíteni próbál neked.
Ki mint vet, úgy arat. -
Erre vannak a verziókezelő rendszerek (ezekből manapság a git az, amit szinte mindenki használ).
Némileg leegyszerűsítve ez arra való, hogy a file-ok különböző változatait eltárolja, látszódjon, hogy melyik módosítást mihez kapcsolódóan csináltad, melyik fileverziók tartoznak egy kiadott verzióhoz meg sok egyebet is tudnak, de azt majd menet közben úgyis megérted. -
válasz
K1nG HuNp
#15580
üzenetére
Semmi gond, ha elég sokat magyarázom, akkor lehet, hogy a végén én is megértem
Alapvetően read-only lesz, szóval az a terv, hogy ami adat kell, azt beolvasom a memóriába és utána már csak azzal dolgozom, szóval a REST onnantól kezdve tulajdonképpen játszik.
Akkor tulajdonképpen azt mondod, hogy ne aggódjam túl a dolgot?
-
-
válasz
K1nG HuNp
#15564
üzenetére
Néhány ezernyi számla listában, bennük kb 5-10 sor, ezek között kellene navigálni, kinyitni, becsukni, osztályozni, szűrni, kipipálni, ilyenek
És gyorsaság alatt nem a mostani mobilok gyorsaságát értem, ahol 100-200 ms után történik valami, addig meg eljátszik az átmenetekkel, hanem a hardcore, 386-oson futó Foxpro stílust, ahol az ember nyom egy gombot és a következő frame-en már megtörtént
-
REST API-ra csinálok egy webes felületet, ami elég sok adatot kezel. Dolgozáshoz lesz, vagyis elsődleges szempont az, hogy gyors legyen és mindent meg lehessen csinálni csak billentyűzettel.
Mit javasoltok hozzá? (Angularral van tapasztalatom, de az ilyesmihez túl nagy késleltetést produkál)
-
válasz
bambano
#15548
üzenetére
nagy mátrixot elég gáz lehet tárolni egy ilyen feladatra...
Nyilván vmi sparse reprezentációban.
a probléma még mindig az, hogy gagyi véletlenszámgenerátor esetén nem tudod kizárni a végtelen ciklust.
Ez az, ami tényleg teljesen elméleti kérdés. Azt lehet mondani, hogy nincs garancia a válaszidő nagyságára, de végtelen ciklustól tartani az nem igazán életszerű.
-
válasz
bambano
#15545
üzenetére
Ilyenkor látszik, hogy az elméleti matematikusok miért rossz megmondóemberek, ha valamit ténylegesen meg is kell csinálni
Egyrészt az ordó nem fordul le automatikusan gyorsabbra - adott feltételek között egy O(n^2) algoritmus simán gyorsabb tud lenni, mint akár egy O(1).
Nagy mátrixnál, amiben kevés elem van, a random lerakás + ellenőrzés szinte biztosan gyorsabb lesz, mintha az ember szépen eltárolgatná a szabad helyeket és azokból választana.
-
-
#15451
dabadab
titán
RudiLicenc
#15449
válasz
RudiLicenc
#15449
üzenetére
Amit martonx mondott, amellé még hozzáraknám azt, hogy a C# szerintem jobban megtervezett nyelv (egyrészt alapból nagy rajongója vagyok Anders Hejlsberg munkásságának (Turbo Pascal, C#, Typescript), másrészt volt alkalma okulni a Java (és a C++) hibáiból), én már csak emiatt is azt választanám.
-
-
válasz
btraven
#15425
üzenetére
A JRPG-kben (meg visual novelekben) ez valamiért hagyomány, szerintem is rettenetesen idegesítő.
Egyébként ilyet utoljára tényleg a teletype-oknál lehetett látni, vagy nagyon régi terminálokat, ahol 300 bit/másodperc sebességgel száguldott az adat, de igazából ilyesmit leginkább mégis csak filmekben lehet látni, mert a filmesek valamiért azt gondolják (gondolták), hogy ez így menő (pl. az Alienben nem csak, hogy egyesével jelentek meg a karakterek, de mindegyik még bippent is egyet
) -
válasz
Tigerclaw
#15349
üzenetére
Eleg szabadon fejlesztik a Reactot es ahhoz kepest hogy viszonylag friss nyelv, nem feltetlenul ugyelnek a visszamenoleges kompatibilitasra.
Ez egyébként a hosszú távú karbantartást nagyon viccesé teszi, tiszta Vörös Királynő: "Minálunk, ha teljes erődből rohansz, az épp csak arra elég, hogy egy helyben maradj."
-
-
![;]](http://cdn.rios.hu/dl/s/v1.gif)
(némileg leegyszerűsítéve a Chrome JS engine a Chrome nélkül)
Új hozzászólás Aktív témák
● olvasd el a téma összefoglalót!
- Gusztusos, 11 literes térfogatú Jonsbo ház jött a kompaktabb vasakat kedvelőknek
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Azonnali fáradt gőzös kérdések órája
- Minecraft
- Gyúrósok ide!
- Windows 11
- Merész dizájn és új teleobjektív az iPhone 17 Pro mobilokban
- Az Apple bemutatta az iPhone 17-et
- PlayStation 5
- A magas vérnyomást is felismerheti az Apple Watch Series 11
- További aktív témák...
- HIBÁTLAN iPhone 13 mini 128GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3285
- Telefon felvásárlás!! Samsung Galaxy A22/Samsung Galaxy A23/Samsung Galaxy A25/Samsung Galaxy A05s
- Samsung 213T 4:3 1600x1200 VA monitor eladó
- Olcsó Notebook! Dell Latitude E7280! I5 7300U / 8GB DDR4 / 256GB SSD!
- Eredeti Lenovo USB-C 135W töltők
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest