Új hozzászólás Aktív témák
-
Drizzt
nagyúr
Kérdés:
- Addott egy osztály, aminek főleg beépített osztályok az adattagjai. Van benne 1-2 Set is, amiket nyilván addAll-lal szeretnék összeuniózni. Erre van-e valami jó library, ami generálhat ilyet? Szóval olyat, mint lent az incrementBy.public class Example {
private Double value;
private Integer count;
private Set<String> stringSet;
public void incrementBy(Example other) {
value += other.value;
count += other.count;
stringSet.addAll(other.stringSet);
}
}
I am having fun staying poor.
-
Drizzt
nagyúr
Nekem se volt még vele sose ilyen probléma. És nálam is meg van nyitva vagy 5-6 Spring microservice, 2-3 JavaEE app, meg néhány devops repo állandó jelleggel. Maven mind. Mondjuk amúgy a maven részét annyira nem szeretem az IDEA-nak, bár összehasonlítási alapom nem nagyon van, mert mást 10+ éve nem használtam(Javara).
I am having fun staying poor.
-
Drizzt
nagyúr
Talan az a legszebb, ha csinalsz egy masik osztalyy, ahol az emlitett valtozo osztalyvaltozo, s az ot cseszegteto metodusok is az uj osztalyban vannak.
De fejtsd ki jobban a problemat. Remelem olyan dolgok nincsenek, hogy meghatarozott sorrendben kell meghivogatni a dolgokat.
Vagy ha ez valami seged metodus, ami mindenfele muveleteket tud vegezni a parameterrel, akkor mehet egy utility osztaly static metodusanak.
Konkretabb pelda tenyleg sokat segitene.
[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
Egyszerubbnek egyszerubb. Ha viszont valamiert tobben is hasznalnak ugyanazt a peldanyt, abbol meg baj is lehet. En csinalnek egy osztalyt, aminek a konstruktora letrehozza a textfieldeket, de nincsenek setterei. De van metodusa amivel a mezoket meg lehet szerezni. Ez mar igy kvazi egy immutable osztaly lesz, s akkor tobb szalon is jol mukodhet. Mezoben eltarolni azert veszelyes szerintem, mert nem garantalhato sorrendiseget varsz el. Lesz fv-d, ami beallitja a mezot, meg lesz ami lekerdezi. Mi van ha elobb hivjak meg a lekerdezot, mint a letrehozot? Az en javaslatomban ez nem fordulhat elo, mert letrehozni csak egyszer tudod a peldanyt, es amig az nincs meg, addig nem nem tudod meghivni. A te esetedben meg nem garantalja semmi a helyes meghivasi sorrendet.
I am having fun staying poor.
-
Drizzt
nagyúr
Ezerintem local classt nem lehet. De mibe tart kiprobalni? En most tableten vagyok, azert nem tudom. Inner class elerheto kivulrol, hacsak nem private, de a local class definicioja csak a definialo blokkon belul ervenyes. Annyira nem hasznalok ilyeneket soha, hogy nagyon nem vagyok bennuk biztos.
I am having fun staying poor.
-
Drizzt
nagyúr
Igen. Leszamitva, hogy azert a Composite nem tul gyakori. Singletont, factoryt altalaban ugyis ad a framework, buildert a Lombok. Strategy szerintem elegge gyakori a jo kodokban ahol tipusfuggoen kell algoritmust valasztani. A java8, meg a Spring eleg sokat segit, hogy az oldschool modon kevesebbszer kelljen patternt implementalni.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz javamonk #11280 üzenetére
Spring/Spring boot erzesre joval fenyesebb jelen/jovo elott all. Meg weboldalakat kesziteni azert nagyon sokfele modon lehet, de szerintem erdemes a weboldalt es a serveroldalt teljesen fuggetlenul fejleszteni. De attol is fugg, hogy mit akarsz az egeszbol kihozni. Nagyon elterjedt a single-page webapp valamelyik js frameworkben + Spring boot server alkalmazas.
Java ee-ben szerintem a legnagyobb baj az uzemeltetesevel, meg a java EE app serverekkel van. Bar letezik oda is uber/fat jar megoldas.I am having fun staying poor.
-
Drizzt
nagyúr
válasz disy68 #11307 üzenetére
En a newClass helyett inkabb Supplier<T>-t hasznalnek. Akkor nem vagy megkotve, hogy csak 0 parameteres konstruktoru osztalyokkal mukodjon.
Az se teljesen vilagos, hogy ez miert egy static method, elso erzesre siman lehetne az AbstractInvoiceEntity-nek egy tagmetodusa.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Aku-Aku #11344 üzenetére
Ranezve a @RestController komponensre gondol konfiguracio alatt. Nem vilagos, hogy miert igy hivja.
Mindenestre annyi az egesz, hogy a HellowWorldExampleApplication.java melle csinalj egy ApplicationConfiguration.java nevu fajlt, a kepen megadott tartalommal, s ennyi. Rakhatod olyan package-be is, ami melyebben van, mint az HelloWorldExampleApplication, mert a component scanninggel azt is meg fogja talalni.I am having fun staying poor.
-
Drizzt
nagyúr
válasz Aku-Aku #11349 üzenetére
Erre biztosan nem lesz szükséged. Ez beállítja aktív profilnak a @spring.profiles.active@-at, ami nagyon valószínű, hogy nem létezik. Szóval nyerni nem nyersz vele.
A logban hiba nincs. Viszont hiányzik belőle, hogy a Tomcat elindulna a 8080-as porton, mint ahogy a példa screenshotján is van.
Annyit látok a logodban, hogy a "D:\eclipse_workspaces\java_coding_exercises\HelloWorld_Example\target\classes" könyvtár biztosan rajta van a classpathon. Mik vannak ebben a könyvtárban? Benne van a ApplicationConfiguration.java? Illetve egyáltalán a Spring MVC-s dependency-k ott vannak? Távolról ezt elég nehéz diagnosztizálni.I am having fun staying poor.
-
Drizzt
nagyúr
válasz Szmeby #11386 üzenetére
Ez a Spring Data Rest default viselkedese. Convention over configuration, mint megannyi mas helyen a spring bootban.
Megfeleloen uj Spring verziokkal o lesz a baratod: [stackoverflow: set exposed repositories to annotated only. ]I am having fun staying poor.
-
Drizzt
nagyúr
Ha keresztbe-kasul ismersz valamit, s atlagban egy problemat 3mp megoldani neked benne, akkor nagyon nyomos erv kell ahhoz, hogy lecsereld valami masra, amiben ugyanez a folyamat a kompetenciad hianya miatt eltartana vagy 1 napig.
Nalunk minden regi es minden uj projekt is maven, szimplan azert, mert van par emberunk, aki nagyon ert hozza. Ok tenyleg kb. 5 perc alatt a legkomplexebb projekteket is atlatjak, mig Gradle-hez nincsen ilyen emberunk. A build time meg nem kritikus.
Persze lenne haszna gradle-zni, legalabb lenne eselye kialakulni benne mely kompetencianak. Ha ma kezdenek Javazni, biztos azzal kezdenek. Igy viszont, hogy teljesen otthonos terep a maven, foleg ezt hasznalom, itthon is. Volt projekt amit gradle-lel kezdtem, de semmi nem vitt ra utana, hogy a kovetkezot is azzal csinaljam. Van boven mas szakterulet, ahol tobb hasznot hoz a raforditott tanuloido.
I am having fun staying poor.
-
Drizzt
nagyúr
Alapvetoen van, de elsosorban business case-ekhez kototten. Meg igyekszunk mindig uj dolgokat behozni, ha hasznos, vagy hosszan tarto megoldast adhat. De nalunk mindenki erosen devops/automated tester/data magus is egyben, s legkevesbe izgalmas/lenyeges resz az egeszben a java build. Nyilvan a magussal tuloztam, de inkabb a szeles tudas az, ami nalunk a fokusz, nem pedig a reszletekbe meno tudas egyes alteruleteken.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz floatr #11410 üzenetére
"A megfelelő build alap összerakása elhanyagolható erőforrásigényű egy átlagos projekt többi feladatához képest." Nem ertek egyet. Ez csak akkor igaz, ha az adott build rendszerhez es az azzal szembeni kovetelmeneykhez is valaki nagyon ert. Igazabol aztan utana tok mindegy, hogy pipeline-bol mavent, vagy gradle-t hivok meg.
Projektek atlagos build ideje ket perc mavennel. Intellij meg ugyis feldolgozza az egeszet belso projekt formatumra, ami sokkal gyorsabb, foleg ha szelektiven akarsz valamit futtatni. Kiprobalnam en is elesben a Gradle-t, de nem igazan varok tole semmi valos hasznot a mi use case-unkben. Ha nagyon nem lesz semmi dolgunk, akkor majd rakerul arra is a sor. A mostani maven service template-jeink tokeletesen megfelelnek az elvarasainknak, a lecserelesukben sokkal tobb lenne a potencialis risk, mint a potencialis benefit.I am having fun staying poor.
-
Drizzt
nagyúr
válasz floatr #11417 üzenetére
Remek, de ezekre nincs szuksegunk. Egyszer jo lenne atterni, de joval nagyobb annak az ara, mint amit itt sugallsz. Mindenkeppen eltart egy ideig, mig egy programozo csapat atszokik egy masik build tool-ra. Nyilvan van az a helyzet, amikor a relativ koltsege az atallasnak kisebb, mint a relativ haszna. Nalunk jelenleg nem az.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz btraven #11422 üzenetére
De, szabad hasznalni. Viszont ha nem valamilyen factory metodusban hasznalod, akkor gyanus, hogy lenne helyette szebb, biztonsagosabb, bovithetobb OOP megoldast talalni a problemara. Nyilvan nem mindig. Akkortol jon a gond, ha tobb metodusban ugyanazon ertekkeszlet alapjan kell kulonbozo dolgokat csinalni, mert konnyen el lehet cseszni, ha bovul az ertekkeszlet.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Aethelstone #11429 üzenetére
Mostmar ha elorangattad, ne hatralj ki.
Erre en csak annyit akartam irni, hogy eddig olyan 5 eves maven hasznalatom alatt egyszer sem jott szembe olyan dolog, amire nem lett volna letezo plugin, ami megoldotta a problemat. Oke, vannak azert olyanok, amitol jobbat is el tudnek kepzelni, de egyutt lehet vele elni. Van amugy joval hosszabb programozoi tapasztalatom(ossz. ~15 ev), de OOP/Java az legyen inkabb 5 ev. Ezert 5 ev a maven is.
Illetve ami pl.: Gradle-re atteressel problema lenne, hogy van egy jo szazas nagysagrendu microservice, ami azert jelenleg elegge hasonlit build projektileg. De ettol fuggetlenul mindegyikben johet fejlesztesi igeny. Ha meg hirtelen a projektek egyik fele maven, a masik fele meg gradle lenne, bevinne egy szep kis extra komplexitast.I am having fun staying poor.
-
Drizzt
nagyúr
válasz Csaby25 #11446 üzenetére
Jdk SE eleg. En mondjuk inkabb Intellij community-val allnek neki, meg ha joval baratsagtalanabb is, mint az Ultimate. De azert arra meg nem vettem ra magam, hogy otthonra is megvegyem az Ultimate-et. Nehany pluginnal a community is eleg jo a Springhez.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Csaby25 #11464 üzenetére
Meg kell mondani az alkalmazasnak inditaskor, hogy melyik profilokat hasznalja. Application.properties by default mindig beolvasasra kerul, a - dev-hez aktivalni krll a dev profile-et. Asszem ha jar-kent inditod, akkor - Dspring.profiles.active=dev a megfleelo kulcsszo, de fejbol irom, lehet rossz.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz bambano #11483 üzenetére
Vagy ha eleg annyi, hogy a rooton kivul mas ne tudja elerni, akkor lehet egy csak a programot futtato linux user altal olvashato fajlban tarolni.
Ezernyi jobb es rosszabb megoldas letezhet, ismerni kellene hozza a kornyezetet, meg a lehetseges tamadasi vektorokat.I am having fun staying poor.
-
Drizzt
nagyúr
válasz btraven #11512 üzenetére
Nem poolozva vannak, hanem egyszeruen az osztaly/interface tipusu valtozok gyakorlatilag pointerek. Szoval ezekkel a sorokkal kb. az alabbit csinaltad:
A heapen letrehoztal egy A tipusu peldanyt. A kis a valtozot letrehoztad a stacken, ami az elobb letrhozott heapen levo peldany cimere mutat. Letrehoztad az a2 valtozot a stacken, ami ugyanarra a cimre mutat az ertekadas miatt, mint a.Emiatt van az is, hogy nyelvi alapelem lett az equals, hogy latvanyosan megkulonboztetheto legyen az ertek szerinti osszehasonlitas a cim szerintitol.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz btraven #11514 üzenetére
Ja igen. A helyzet az, hogy az a2 nem módosulhatott. Valami más miatt tűnik úgy, mintha ez történt volna. Hogy néz ki az A class? Nem véletlen valami static field-et állít át a konstruktora? Mi alapján gondolod, hogy a1, meg a2 is "hi"?
Itt egy példa, hogy ennek a fajta értékadásnak az a2(, a példában s2) által mutatott címet nem szabadna mósodítania.
@Test
void assignment() {
String s1 = new String("Hello");
String s2 = s1;
s1 = new String("hi");
System.out.println(s1);
System.out.println(s2);
System.out.println("s1 default hashcode: " + System.identityHashCode(s1));
System.out.println("s2 default hashcode: " + System.identityHashCode(s2));
}
Output:
hi
Hello
s1 default hashcode: 1366025231
s2 default hashcode: 1427889191I am having fun staying poor.
-
Drizzt
nagyúr
válasz Csaby25 #11536 üzenetére
Az elkészülő - feltétlezem JAR-ban is benne van? Ha igen, ott, ahol lennie kellene?
Ha nincs felülírva, akkor a /static, vagy /public mappában kellene lennie a classpathon futási időben.
Ha nincs ott, akkor maven, vagy gradle setup lesz a probléma. Vagy ha esetleg csak IDE-ben nem megy java -cp-s futtatással, akkor az IDE-ben kell megkeresni azt, hogy miért nem olyan classpathot rak össze futtatáskor, mint amit kellene.I am having fun staying poor.
-
Drizzt
nagyúr
-
-
Drizzt
nagyúr
válasz btraven #11585 üzenetére
"Nem lett bonyolult a helyzet ezzel a lambda meg stream-ekkel?"
Nem, sokkal egyszerűbb lett. Egyébként lambdát nem kötelező használni, ahol tudok inkább method reference-et használok. A streamnek meg fontos képessége a lazy eval, meg a concurrency support. Bizonyos problémákat tök egyszerűen, szépen, elegánsan és hatékonyan meg lehet oldani funkcionális eszköztárral, amit amúgy bonyolultan/csúnyán lehet megoldani nélküle.
"Annak idején egy fejlesztőnyelv/eszköz-ben csak az volt ami nagyon kellett. Minden le volt dokumentálva és minden úgy működött ahogy a doksiban volt."
Ez ma is így van. Maximum 1-2 szinte már sosem használt nyelvi elem léte lenne megkérdőjelezhető, de azok meg maradnak némi backward compatibility miatt. Az meg ha esetleg azért kérded ezt, mert szerinted a Stream felesleges, akkor egyszerűen még nem éreztél rá. Nélküle nagyon szar lenne az élet, ezt pár évi gyakori Stream használóként mondom. Nézz végig valamilyen alap fukncionális progamozást traininget, után egyértelműnek kellene lennie miért ilyen fontos dolog.
"Most már nehéz a programozó élete. A sok nyílt forráskódú, ingyenes cuccban az egyik fele nincs dokumentálva a másik fele meg hibásan működik vagy éppen sehogy. Ugye azért nyílt, mert majd kijavítod magad ha nagyon kell. Csak nem képzeled hogy ingyen még hibátlan is legyen?"
Ez megint nincs így. A lefontosabb, legnépszerűbb framework/libek leggyakrabban használt funkciói eléggé stabilak, ritkán kell körbebástyázni őket. A probléma az esetek 95%-ban abból adódik, hogy valaki megspórolja az alapjaik megismerését és anélkül kezdi őket használni valami olyan célra, amire nem feltétlenül alkalmasak. Még ha elő is fordulnak bugok, sokkal előrébb jársz, ha valami libet használsz rájuk, mintha 0-ról kezdenéd megírni. Sokkal tovább tartana, s a minősége is szinte borítékolhatóan rosszabb lenne.
Az utóbbi évekből pár dolog, aminek én nem voltam elégedett a dokumentációjával: annotation processor, Spring boot property source használat belsőségei. De az is lehet csak nem a megfelelő dokumentációt olvastam. Ráadásul Java-ban az se megy ritkaságszámba, hogy korábbi open source lib a nyelv részévé válik, pl.: Joda-time.I am having fun staying poor.
-
Drizzt
nagyúr
válasz bambano #11597 üzenetére
Pedig tok egyszeru a dolog.
Van kiindulaskor valamennyi(n) darab bucket. A bucketek gyakorlatilag tombok. Tehat van egy n elemu tombod. Minden bucketben van egy linkelt lista, vagy valamilyen annak megfelelo struktura.
A hash fuggvenyen nem modositanak semmit, mivel azt Javaban a user-nek szokas megadnia(oke, altalaban a Lombok irja meg helyette, meg lehet hasznalni a default implementaciot is, de az lehet lassu bizonyos esetekben).Kereses kulcs alapjan:
- Meghivod a kulcsra a .hashCode metodust. Igy kapod az x erteket.
- Kiszamolod , hogy x mod n = z alapjan mi a z.
- A z. bucketet kikeresed(ez egy lepesben megvan).
- A z. bucket osszes elemen vegigiteralsz, s megnezed, hogy a kulcs equals-e az eppen iteralas alatt levo elemmel. Ha igen, akkor az ott szinten eltarolt erteket visszaadod.Mikor lesz ez az egesz lassu?
- Ha a hashCode ugy van megirva, hogy minden kulcs ugyanabba a bucketbe keruljon, vagy legalabbis a bucketek egy kis reszebe. Ilyenkor abban a bucketben egy hosszu lista lesz, ami miatt nem o(1) lesz a lookup, hanem kozeliti az o(n)-et.
Ugyanez akkor is igaz lenne, ha a map-ben levo elemek szama joval nagyobb lenne, mint n. Mit csinal ez ellen a Java? Figyel egy toltottsegi szintet. Ha a toltottsegi szinte egy hataron tul van, akkor fogja, s csinal 2*n uj bucketet, s a meglevo elemeket belerakja, a regi n bucketet meg eldobja.Ebbe a pogramozo is bele tud szolni, van olyan konstruktor, amiben meg tudod adni a kezdeti n-t, s a toltottsegi tenyezot. Szoval ha tudod, hogy rohadt sok elemet fogsz belepakolni, akkor rogton csinalhatsz egy HashMap-et jo nagy n ertekkel, s akkor meguszol par rehash-t. Alapbol 16 bucket lesz, amit akkor ujrahashel, ha legalabb 13-ra no a size. Ekkor 32 bucket lesz, majd ha size legalabb 25 lesz, akkor ujrahashel 64 bucketbe, stb.
A LinkedHashMap az egy specibb valtozat, ahol az egesz HashMap-en tul egy LinkedList is fenn van tartva, ami az osszes elemet tartalmazza a hozzaadas sorrendjeben. Akkor kell hasznalni, ha fontos a hozzaadas sorrendjet tudni.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Csaby25 #11646 üzenetére
Igen, JavaFX-et nem valószínű, hogy egy átlag Java fejlesztői munkakörben fogsz látni a közeljövőben. Egyébként azért van értelme hallani róla, de túl sok enrgiát beleölni talán nem.
Spring boot meg hasznos és végtelen kereslet van rá, úgyhogy érdemes arra ráfeküdni.I am having fun staying poor.
-
Drizzt
nagyúr
válasz btraven #11666 üzenetére
Koszi a peldat!
Igy egyszerubb valaszolni a kerdesedre.
[Javadoc] : "Exceptions are thrown for problems with the OutputStream and for classes that should not be serialized. All exceptions are fatal to the OutputStream, which is left in an indeterminate state, and it is up to the caller to ignore or recover the stream state."
Szoval nincsen kulonosebben specifikalva, hogy mi fog tortenni Exception eseten. Elofordulhat, hogy kulonbozo JVM-eken es kulonbozo javaverziokon is kulonbozokeppen viselkedik, de a leirasaban benne van, hogy az esetleges szemetet a hivonak kell feltakaritani. Szamomra meglepo, hogy igy van. Szoval a catch agban zard a Streameket, majd torold a fajlt, ha van.
Ha atirod a peldadat "try with resources" alapon, akkor a close-et nem kell sehol meghivnod, mert a ket outputstream autoClosable.I am having fun staying poor.
-
Drizzt
nagyúr
válasz fatal` #11680 üzenetére
Attol, hogy nyitva marad a stream, random adat nem fog belekerulni.
De direkt debugban vegiglepkedtem az idezett kodon, az Exception kiirasat az ObjectOutputStream.writeFatalException metodus vegzi az OutputStream-be.
A writeObject maga igy nez ki:public final void writeObject(Object obj) throws IOException {
if (enableOverride) {
writeObjectOverride(obj);
return;
}
try {
writeObject0(obj, false);
} catch (IOException ex) {
if (depth == 0) {
writeFatalException(ex);
}
throw ex;
}
}
11.0.11-es Oracle JDK-val neztem.[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
válasz fatal` #11682 üzenetére
Nem sok gratulalni valo van az Oracle-nek, mert a JDK 1.1-es verzio, 1997. februar ota van az ObjectOutputStream, akkor meg nem volt koze az Oracle-nek a Javahoz. Ehhez a reszehez az implementacionak meg kb. senki nem is nyult hozza azota(Oke, csak 7-es OpenJDK-ban latom, hogy mar az initial load commitban ugyanez volt 2007-ben). Az Oracle meg 2010-ben vette meg a Sunt.
I am having fun staying poor.
-
Drizzt
nagyúr
válasz Lortech #11709 üzenetére
Remek kérdés, hogy egyébként mit ért floodon? Csak annyit, hogy ne tudjon mondjuk 5 másodpernél gyakrabban post-olni valami endpoint-ra és elég ha eldobja a requestet, amennyiben az túl friss?
Mert akkor valahol simán el kell tárolni, hogy mikor jött a legutolsó sikeres request userenként és ha túl gyorsan, akkor eldobni. Erre is lehet persze csomóféle megoldás, a singleton beanben levő maptól a redisen át az adatbázisba eltárolt lastUpdateDate-ig. Függően attól, hogy mi a cél, hány instance van, etc.
Ha meg DDoS-tól kell védekezni, az nem a Spring boot alkalmazás feladata lenne ideális esetben valóban.I am having fun staying poor.
-
Drizzt
nagyúr
String[] lastNames = {"Nagy", "Kovács"};
String[] firstNames = {"Júlia", "Béla"};
for (String lastName: lastNames) {
for (String firstName: firstNames) {
System.out.println(lastName + " " + firstName);
}
}Nagy Júlia
Nagy Béla
Kovács Júlia
Kovács Béla[ Szerkesztve ]
I am having fun staying poor.
-
Drizzt
nagyúr
Foglalni kell egy új tömböt, aminek a mérete a két tömb méretének a szorzata, a cikluson belül pedig egy indexet kell növelgetni és arra a poziícióra kell elhelyezni az éppen megalkotott elemet, ahol tart az index.
String[] lastNames = {"Nagy", "Kovács"};
String[] firstNames = {"Júlia", "Béla"};
String[] combinedNames = new String[lastNames.length * firstNames.length];
int i = 0;
for (String lastName: lastNames) {
for (String firstName: firstNames) {
combinedNames[i++] = lastName + " " + firstName;
}
}
System.out.println(Arrays.toString(combinedNames));I am having fun staying poor.
-
-
Drizzt
nagyúr
válasz Aethelstone #11805 üzenetére
Mit javasolsz helyette? Nekem van saját preferenciám, de kíváncsi vagyok mit mondanál rá.
I am having fun staying poor.
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Autóápolás, karbantartás, fényezés
- Milyen videókártyát?
- Politika
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Kávé kezdőknek - amatőr koffeinisták anonim klubja
- exHWSW - Értünk mindenhez IS
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Google Pixel topik
- Xbox Series X|S
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen