Új hozzászólás Aktív témák
-
beleszólok
senior tag
válasz
Aethelstone #6499 üzenetére
Na ja... anno még tanultuk a goto használatát. (COBOL, PL/I, BASIC)
Később azt mondták rá, hogy az ördögtől való. Minap olvastam valahol egy kis írást, amiben azt fejtegették, hogy mégsem, sőt...[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
beleszólok
senior tag
Na, hogy kötekedjek is: de, lehet jó alap, csak megfelelő feladatot kell hozzá találni.
A fenti feladvány nem ilyen, de ha valamiért a Thread-be kellene belepiszkálni? - nem tudnék életszerű példát rá, de sokszor ért már meglepetés.(szóval ez kötekedés - csak hogy lásd a különbséget)
[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
floatr
veterán
válasz
beleszólok #6503 üzenetére
Ha olyan feladatod lenne, ami miatt a Thread-be kellene piszkálni, akkor nem java-ban kell implementálni. Nem is értem h miért nem final az osztály. Illetve értem ("that would break backward compatibility"), mert a legelső könyvek tele voltak Thread subclass-okkal.
A vitával kapcsolatban meg azért mondom h kötekedés, mert ugyanarról beszélt, mint te
-
beleszólok
senior tag
Nagy különbség:
- kötekedés: lásd fenn, semmi gyakorlati jelentősége.
- nem kötekedés: amellett, hogy egyetértettem vele, volt egy apró nézetkülönbség. Nevezetesen az, hogy szerinte vallási kérdés, hogy extends Thread vagy implements Runnable, szerintem meg amíg tartjuk magunkat az elvekhez, addig csak az utóbbi jöhet szóba. Ez szerintem nem kötekedés, csak kiegészítés. Hogy hosszabban is írtam, az meg azért volt, hogy talán sikerül az eredeti kérdezőt meggyőzni, hogy bármilyen apró, jelentéktelen feladatról legyen is szó, nem szabad az ilyen dolgokat félvállról venni, mert évek múlva lesznek csúf következményei...Tiszavirág: http://youtu.be/YdcsiW0kfso
-
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.
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
floatr
veterán
válasz
beleszólok #6505 üzenetére
Nem javasolta, mert felülcsaphatná a start metódust, te meg nem javasoltad mert felülcsaphatná a start metódust. Most hogy mondod, télleg lehet h van gyakorlati jelentősége...
-
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.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
válasz
Aethelstone #6508 üzenetére
Mindenkinek az a normalis, amit megszokott. Gondolom a topicban senki nem haborodik fel azon, hogy a Java-ban van null erteku referencia, pedig talan a legrosszabb design hiba az egesz C/Java/C#/etc. nyelvi hagyomanyban, minden nap milliok futnak bele, pedig tipusos nyelvben siman el lehetett volna kerulni a letezeset (es akkor egyszeruen nem lenne NullReferenceException...).
[ Szerkesztve ]
while (!sleep) sheep++;
-
válasz
Aethelstone #6510 üzenetére
Itt szepen es erthetoen leirjak (az elso valaszban).
De akkor roviden en is leirom -- egy klasszikus pelda a megoldasra: Option tipus.
Ha van pl. egy fuggvenyed, ami Integer ertekkel ter vissza, akkor a fordito garantalja, hogy az Integer lesz, es nem null. Ha egy masik, alapvetoen Integert visszaado fuggvenyed nem mindig tud visszaterni Integerrel, mert pl. kivetelt dobhat, vagy ilyesmi, es nincs mit visszaadni, akkor a fuggvenyed visszateresi erteke legyen egy Option ertek, amit viszont nem tudsz Integerkent hasznalni, csak ugy, ha mindenkepp ellenorzod, hogy van-e erteke vagy sem.
Option ret = enFuggvenyem();
switch ret {
case None: print "Nincs visszateresi ertek"
case Integer(i): print "Az Integer ertek: " + i.toString()
}Sokfele megoldas van, a lenyege az, hogy nem kerulhetsz olyan szituacioba, ahol elfelejted ellenorizni, hogy valami null-e vagy sem, mert a compiler garantalja, hogy vagy tuti van ervenyes ertek, vagy leellenorizted.
Ahogy Hoare is mondja (akit gondolom nem kell bemutatni):
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement.A lenyeg, hogy a nullreferencia nem egy szukseges rossz, hanem igazabol tok felesleges, amit a korai nyelvekbe raktak bele, hogy kicsit egyszerubb legyen megirni a compilert, es itt ragadt velunk. Csomo nyelvben (akar JVM alapu nyelvekben is) megoldottak, hogy ne legyen.
while (!sleep) sheep++;
-
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..
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
axioma
veterán
válasz
Aethelstone #6512 üzenetére
Szerintem itt elvi uton van elteres; a lenyeg nem a case-en van, hanem hogy case nelkul nem tudsz erteket adni a celvaltozonak kozvetlen -- azaz hogy tevedesbol se tudod leirni, hgoy enOsztalyom=enFuggvenyem() es utana rad van bizva, hogy case-elsz vagy sem null miatt, hanem a visszateresi erteked muszaj vizsgalnod, azzal tudod kiszedni a valodi erteket belole.
-
floatr
veterán
Nem igazán tudok egyetérteni ezzel az egész nullptr savazással. Van most is optional, de sztem amennyi energiát ráfordít az ember, annyival a null-t is lehet kezelni.
Az viszont kétségtelen, hogy egy gyakorlatlan ember könnyen benézi, de ugyanez az ember az optional-be is is belezavarodik.
(#6514) Cathfaern nullptr hibák kihasználásával konkrétan rövidebb kódot lehet írni, ha tudja mit csinál az ember
[ Szerkesztve ]
-
beleszólok
senior tag
Engem érdekelne ez a téma, de itt úgy érzem, túlságosan off.
Átmehetnénk vele ide: http://itcafe.hu/tema/programozas_forum/friss.html ?Tiszavirág: http://youtu.be/YdcsiW0kfso
-
beleszólok
senior tag
Java multithreading: mit szokás használni a szálak közti kommunikációra, ha nem akarok egy komplett keretrendszert beüzemelni miatta?
Saccra 50-100MB-os csomagokat küldözgetnék egy producerből több consumer szálnak.Pythonban egyszerűen a multithreading.Queue-t használtam (illetve a multiprocessing.Queue-t, miután kiderült, hogy létezik a GIL, ezért nincs használható multithreading a cPythonban, de nagyjából ugyanaz).
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
floatr
veterán
Belezavarodsz, aztán hülyeséget csinálsz, mindkét esetben ugyanannyi haszna van a terméknek.
(#6516) beleszólok itt egy elég jó magyarázat az optional-ről [link] A funkcionális matyik imádják ezt is, de ha átfutsz az api nyújtotta lehetőségeken, akkor rengeteg körítés van ugyanazon probléma más megoldásához.
-
válasz
beleszólok #6518 üzenetére
Hat, attol fugg, hogy es mit akarsz kommunikalni, szinkron vagy aszinkron, etc. Ott vannak pl. a ConcurrencCollection-ok, de akar hasznalhatsz sima osztott referenciakat is alapveto szinkronizacios mechanizmusokkal (lock, condition, stb.) -- mindegyik problemas, mas-mas szinten..
while (!sleep) sheep++;
-
beleszólok
senior tag
Funkcionális nyelvektől hülyét kapok, de komolyan.
Változónak hívják a konstansokat, miközben változó nincs bennük... Ott adtam fel, mikor megpróbáltam megérteni, hogy lehet egy számlálót létrehozni erlang/haskell nyelvek valamelyikében. (sikerült, de valami iszonyatos)Tiszavirág: http://youtu.be/YdcsiW0kfso
-
beleszólok
senior tag
Most, konkrétan csak annyit akarok, hogy az említett szövegfájlt végigolvasom egy szálon, több másikon meg feldolgozom a beolvasott adatokat. A feldolgozás abból áll, hogy megnézem, illeszkedik-e egy adott reg.exp.-re a kapott sor, ha igen, akkor növelek egy számlálót.
Egyelőre csak puszta kíváncsiság: sikerül-e java-ban gyorsabbra megírni ugyanazt, ami pythonban elég rendesen felgyorsította a számolást a soros, egyszálú feldolgozáshoz képest. (a regex illesztés cpu igényes művelet, nélküle 3-4sec, vele 22-24sec mire benyalja a teljes fájlt)
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
válasz
beleszólok #6521 üzenetére
Nem hivjak valtozonak, erteknek hivjak. Mindegy.
while (!sleep) sheep++;
-
válasz
beleszólok #6522 üzenetére
Ez konkretan ugy nez ki, hogy van egy concurrentlinkedqueue, amibe a file reader tolja a sorokat, a masik oldalon meg van egy executorservice thread pool, ami szedegeti ki az elemeket, es egy AtomicInteger novelgetsz.
Ez kb. a Concurrency 101 elso hetenek consumer-producer peldaja egyebkent.
while (!sleep) sheep++;
-
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.
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
beleszólok
senior tag
Köszi.
(mondom: nagyon rég és nagyon keveset foglalkoztam ilyesmivel, most meg csak úgy felszínesen tesztelgetem, szóval nem lesz belőle komoly szoftver)
Az az atomic integer érdekes egyébként... ez ugye elvileg egy globális változó lenne, amire sokan fújnak. (vagy rosszul értem?)
A másik érdekesség, amit minap fedeztem fel: az int, az atomic, a long (állítólag) nem az. Vajon miért?
Na mindegy...[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
válasz
beleszólok #6526 üzenetére
Java-ban nincs igazabol globalis valtozo, talan a szingleton all hozza legkozelebb, de neked meg erre sincs szukseged. A main-t tartalmazo osztalyodban legyen egy publikus AtomicInteger, aztan kesz.
Bar tuti jon valaki, aki elmondja, hogy dependency injectionnel lesz igazi enterprajz megoldas
Masik kerdesedre: az int az tuti atomic, a long az vagy atomic, vagy nem. Az int 32 bites, a long 64, a VM implementacionak garantalnia kell az intek atomikus irasat/olvasasat, a longoket nem. Belemehetunk abba, hogy ez miert van -- elsosorban azert, mert 32 bites architekturakon a 64 bites ertekek atomikus irasa teljesitmenyvesztessel jar.
[ Szerkesztve ]
while (!sleep) sheep++;
-
beleszólok
senior tag
DI-t említeni sem mertem.
Különösen, hogy anno, PHP-vel játszadozva rövid úton oda jutottam, hogy ehhez már keretrendszer kell.(és most megint valaki azt fogja mondani, hogy kötözködök)
Szerintem a main-be tett publikus változó, az nagyjából megfelel a globális változónak, de OK, valóban, a javanak nincs olyan nyelvi konstrukciója, ami valódi globálist valósítana meg.long vs 64 bit... jellemzően már eszembe sem jut, hogy még léteznek 32 bites rendszerek is. Bennem csak annyi volt, hogy a java long = 64 bites int, az meg már processzor szinten is elemi adat.
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
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.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
beleszólok
senior tag
válasz
Aethelstone #6530 üzenetére
No igen, ez megint vallási téma?
Egyik oldal: getter/setter, másik oldal: inkább publikus, de legalább protected.
(bár ez lehet, hogy python specifikus volt, amiben nincs igazán protected... kicsit bizonytalan vagyok)Tiszavirág: http://youtu.be/YdcsiW0kfso
-
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
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
fordfairlane
veterán
válasz
beleszólok #6529 üzenetére
Szerintem a main-be tett publikus változó, az nagyjából megfelel a globális változónak, de OK, valóban, a javanak nincs olyan nyelvi konstrukciója, ami valódi globálist valósítana meg.
Egy public static változó vagy metódus szerintem tekinthető globálisnak.
x gon' give it to ya
-
axioma
veterán
válasz
Aethelstone #6525 üzenetére
A listas peldaddal nem ertek egyet. Mert lehet, hogy ervenytelen, lehet hogy ervenyesen ures, es lehet hoyg nem ures. Ha az ervenytelent az uressel jelzed, akkor nem tudod megkulonboztetni a vegen, hogy ez most egy hasznalhato adatsor vagy sem... (mint amikor rarakjak egy meresi adatsorra a -1 -et ervenytelennek, de amikor az utolso 100 adatbol statisztikat kell csinalni, bamban azt is beleatlagoljak... lattunk ilyet kiszallitott kodban, nem java volt, de nem kis rendszer resze). Termeszetesen a listat is tovabb lehet fejleszteni, hogy tudja magarol hogy ervenyes-e, de azzal csak technikailag szuntetted meg a null-t, az ertekadas le fog futni ervenytelen ertekre is - ott is ahol nem figyelsz ra, mert nem lathatoan jon vele az info, hogy itt me'g hiba is lehet, vagy ez mar lecsupaszitott tuti ertek. Az meg nyilvan abnormalis, hogy minden egyes hasznalat elott megprobalod kicsomagolni.
Jelzem hogy en nem akarom a null-t szamuzni mindenaron, csak megertem azt a fajta logikat is, es nem tartanam problemanak atterni ra, kicsit jobban absztraktalva lenne mar a fuggveny megirasakor, hogy van-e hibaag. Vagyis belatom, hogy meg lehetne azt nagyon jol es megszokas utan kenyelmesebb programozast biztositoan csinalni. (Nagyon absztraktul nezve ez kivalthatja az exception dobasi rendszert is, a visszateresi ertekbe is becsomagolhato, mondhatnank csak az exception vagy a valos ertek lehet benne, a try-catch meg oly mindegy hogy honnan kihamozott adat alapjan mukodik.) -
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
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
floatr
veterán
válasz
Aethelstone #6532 üzenetére
Én ezt springgel oldanám meg egy felhasználási területtől függő scope-ban élő beannel
(#6531) beleszólok globális változó mint olyan nem is szabad h legyen, mert nem menne át a kód review-n
A VM egyébként is moduláris a classloader tekintetében; szóval relatív a globális. Egy kontextusban lehet alkalmazásra nézve globális valami, de nem szabad elfelejteni, hogy több kontextus is szaladgálhat egy VM alatt. Workaroundként a public static változókat szokták néha használni, de nem bátorítanálak erre.
-
Cathfaern
nagyúr
válasz
Aethelstone #6535 üzenetére
"Üzleti logika szempontjából az üres lista pont annyit ér, mint a null referenciával rendelkező."
Nem igazán. Üzleti logika szempontjából az üres lista azt jelenti, hogy pl. egy lekérdezésnek nincs találata, a null referencia pedig azt, hogy valami programhiba történt. Előbbi esetben elég megjeleníteni az üres listát, utóbbi esetben viszont figyelmeztetni kell a usert, hogy nem az történt, mint amit szeretett volna.[ Szerkesztve ]
-
WonderCSabo
félisten
Lehet, hogy ehhez a beszélgetéshez is vagy át kéne menni a Programozás topikba, vagy egy új topikot létrehozni, mert eléggé túlmutat a Java keretein.
-
-
floatr
veterán
válasz
Aethelstone #6541 üzenetére
Hogy egy ismerősömet idézzem az ilyen kiindulási alapoknál: "ebből még bármi lehet"
De ahogy érzedAzért ez a "heavyweight" kissé molesztáló a springre nézve
ahhoz képest h a j2ee-nek annó ez volt a light alternatívája
[ Szerkesztve ]
-
floatr
veterán
válasz
Aethelstone #6543 üzenetére
Hú megint hitvita...
-
floatr
veterán
válasz
Aethelstone #6543 üzenetére
Attól függ. Ha private adattagokkal smúzolsz, akkor kell egy kis dinamikus proxy (cglib, asm), és már megint lelépi a kiccsákókat.
-
axioma
veterán
válasz
Aethelstone #6535 üzenetére
OK, amennyiben exception-nel kiegeszited a null helyet, akkor igaz. Mas kerdes, hogy egy egysoros try-catch csak az IllegalArgumentException elkapasara (mondjuk) mennyire felelsleges bonyolitasa (=rosszabb olvashatosaga) a kodnak. Ha visszaterunk az adatsor kiertekelesre, ahol jonnek az ertelmes adatok 1..99, a hiba meg a -1, es az osszes feladat mindossze az atlagolas, akkor inkabb irnek egy if-et (persze nem a -1-re hanem megfelelo beszedes konstansra), hiszen a cel nem az hogy lealljunk es tovabb ne is csinaljuk a lekerdezest, hanem a jelolt adatot ne vegyuk figyelembe, kezeljuk mashogy (akar az meg egy statisztikai szamlalot novel). Ezt hiaba lehet leirni exception-nel is, en erosen agyuval verebre esetnek ereznem.
Sot, az exception eroltetese a hibajelzo visszateresi ertekkel szemben szerintem csokkenti a kod fuggvenyekre bontasi hajlandosagat. Azt elismerem, hogy igy meg a kepernyore is kikerulo nullpointerexc.-k jellemzoek tulsagosan... az arany kozeputat kene megcelozni. -
floatr
veterán
Alapvetően üzleti logikára koncentrálok a legtöbbször. Nekem kifejezetten jó, ha nullptr van, mert az exception megszakítja a tranzakciókat. Ha optional-t használnék akkor egy if-ben kéne eldobni a kivételt. A kapcsolódó rétegben try-catch néha szokott lenni, de legtöbbször azt is rábízom a konténer hibakezelésére, amit delegálok egy konkrét komponensnek. Ehhez képest az optional csak gurigázás a pamutgombolyaggal
Nem mondom, néha jobb választás lehet, mivel a kivételek kezelése nem feltétlenül cél. Ilyenkor a mechanizmus teljesítménye jobb tud lenni egy if-else megoldással, de ez inkább szépészeti megoldás. Ha valakinek ez problémát okoz, akkor el tudom képzelni ahogy egy merészebb JS frameworktől kifolyik a szeme.
-
bucsupeti
senior tag
Milyen notebook-ot javasoltok Java fejlesztéshez?
Proci? memória? (SSD meg úgyis alap).
Ha írnátok konkrét típusokat az jó lenne."Nem gond ha nem vágod a párologtatók bináris nyelvét..."
-
beleszólok
senior tag
válasz
bucsupeti #6549 üzenetére
Azt kihagytad, hogy nagyságrendileg mennyi rá a keret.
Így elég nehéz.
Nekem a kis játszadozásaimhoz elég egy virtualboxban futó linux 2-3GB RAM-mal (eclipse + xubuntu), egy több mint három éves Dell Latitude gépen, i5-2520m procival.
Ennél sokkal erősebb talán nem kell, ha nem valami extrém dologra fejlesztesz, de kiindulva az esetleges későbbi igényekből:min i5 kategóriájú, hardveres virtualizációt támogató processzor (nem vagyok képben, hogy most mik vannak, az i7 szerintem felesleges - a hardveres virtualizáció azért fontos, mert előbb vagy utóbb, de rákényszerülsz, hogy virtuális gépe(ke)t is futtass.
RAM-ból 16G azt hiszem, mostanság már majdhogynem alap.
Amit fontosnak tartok: minél nagyobb felbontású kijelző/monitor. Ha nem akarod sokat hurcolni, akkor valahol 15" körüli méret, ha hurcolni is akarod, akkor inkább külső billentyűzet és monitor a mindennapos munkára.
A kijelző lehetőleg matt - ez úgy vettem észre, nem egyedi igény részemről, sokan utálják a csillogó képernyőt.Típust nem mernék ajánlani. Régebben Thinkpad-re szavaztam volna (T60, T61 még jó gépek voltak), amíg nem volt Dell gépem, addig második helyen a Dell állt (Latitude vagy... asszem, precision ami fölötte van), mióta van, azóta nem tudom szeretni őket.
(egy elfogadható Latitude konfig közel fél milla!)
Tiszavirág: http://youtu.be/YdcsiW0kfso
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Autós topik
- Kerékpárosok, bringások ide!
- Huawei P30 Pro - teletalálat
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Elite: Dangerous
- Politika
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Rezsicsökkentés, spórolás (fűtés, szigetelés, stb.)
- Assassin's Creed Odyssey
- További aktív témák...
- Intel I3-9100f
- AsRock B365M Phantom Gaming 4
- ÉRKEZETT Legújabb Bontatlan Új M4 Chipes IPAD PRO 2024 11 13 1év gar Azonnal Deák Térnél Átvehet
- ÚJ Apple Pencil 1 - 2 első és második generációs BONTATLAN AZONNAL ÁTVEHETŐ DEÁK TÉR
- AKCIÓ ÚJ Bontatlan Macbook Pro 14 M3 Pro MAX 14 30GPU 36GB 1TB Magyar billentyűzet Azonnal átvehető.