Hogyan is csináljam?
2016-11-17T22:55:06+01:00
2016-12-07T21:22:37+01:00
2022-07-21T17:26:50+02:00
  • Ami növeli a valószínűségét hogy ha külföldre dolgozó cégben dolgozol, akkor előbb utóbb belefutsz a 90%-ba.
    Mutasd a teljes hozzászólást!
  • Amerika lakossága 90%-nak hobbija a pereskedés.
    Mutasd a teljes hozzászólást!
  • Viszont egy 3-6 soros teljesen általános területről származó copy-paste-ről senki meg nem mondja, hogy azt te implementáltad, miután megértetted az elméletet, vagy copy-paste. Az nem bizonyíték, hogy máshol is megtalálható az a 2 for ciklus..

    A Google meg az Oracle simán elvitázgattak a bíróságon pár évig sokkal piszlicsárébb dolgok miatt.

    És lehet hogy meg nem mondja senki a kódról, hogy te implementáltad vagy copy paste. De a StackOverflow-tól nagyon szívesen megkérdik, hogy a munkahelyed letöltötte-e a SO-ról azt a kódrészletet, és onnantól kezdve nálatok a labda hogy bizonyítsátok hogy nem történt jogsértés. Ezek miatt inkább olyat sem vállal be senki ami védhető lenne, de sokba kerülne a pereskedés. Inkább azt mondják, hogy ha elhasaltál a BlackDuckon, akkor írd újra.

    Ezekben az esetekben te egy külön specifikációt írnál a megvalósítandó algoritmusról (egy viszonylag jól optimalizált verziójáról, hogy hogyan kerüljön implementálásra) és kiadnád egy másik kollégának hogy írja meg neked, mert te már 'csaltál', láttad az eredeti implementációt, ami megtetszett. Mindezt csak azért hogy nehogy felmerülhessen valamilyen jogi probléma a jövőben?

    Attól függ, hogy milyen licenccel találsz hozzá kódot. Ha a BlackDuck panaszkodik, akkor teljesen mindegy hogy neked mi a véleményed.

    3 soros 2 for ciklus esetén nincs értelme ilyesmiről beszélni, komplex

    Szégyellje el magát aki két for ciklust a SO-ról copy pastel mert magától nem tudja megírni.

    Egy kezdő 3-4-8 soros copy-paste kódjából meg soha nem lesz jogi probléma szerintem.

    Országa válogatja. Amerikában volt már rá példa. Úgy is, hogy aki perelt annak nem volt igaza. Egy per sokba kerül. Mindenki szereti minden körülmények között elkerülni.
    Mutasd a teljes hozzászólást!
  • A StackOverflow nem vállalja a felelősséget a kódért amit valaki más postolt. Te nem tudod, hogy ki postolta a kódot, tehát akit elő tudnak venni, ha szerzői jogi vagy licenc probléma van, az a te munkahelyed, onnantól kezdve pedig te.

    Ebben teljesen igazad van.
    Viszont egy 3-6 soros teljesen általános területről származó copy-paste-ről senki meg nem mondja, hogy azt te implementáltad, miután megértetted az elméletet, vagy copy-paste. Az nem bizonyíték, hogy máshol is megtalálható az a 2 for ciklus..

    Természetesen egy összetett több 100 soros dolgot nem szabad copy-paste-elni, sőt a kisebb dolgokat is jobb újra írni. Viszont abban nem látok semmi kivetni valót (még jogilag sem), hogy miután megértettél egy apró kódrészletet, akkor onnan a releváns rész copy-paste módon kerül át saját kódbázisba.

    Vegyünk egy egyszerű példát. Egész osztás, vagy gcd algoritmus C-ben.
    gcd-function-for-c
    integer-division-algorithm-analysis/34458338
    Ezekben az esetekben te egy külön specifikációt írnál a megvalósítandó algoritmusról (egy viszonylag jól optimalizált verziójáról, hogy hogyan kerüljön implementálásra) és kiadnád egy másik kollégának hogy írja meg neked, mert te már 'csaltál', láttad az eredeti implementációt, ami megtetszett. Mindezt csak azért hogy nehogy felmerülhessen valamilyen jogi probléma a jövőben?
    (Egy ideális világban ez lenne a helyes megoldás szerintem is, mint ahogy az a hosszabb hozzászólásodban kifejtetted, viszont nem életszerű). 

    Hogy ilyen probléma van-e arra pedig vannak automatikus eszközök

    Nem ismerek igazán ilyen eszközöket, de szerintem általában gyengébb képességű programozók szoktak copy-paste-lni (vagy nagyon idő hiányban szenvedők). Az ő esetükben kétlem, hogy akármilyen speciális eset szóba kerülhet, hogy copy-paste kód.. egy 3 soros programrészletre, vagy egy copy-paste-lt constructorra (mert nem tudta, hogy úgy is lehet használni, mert nem ismerte a keretrendszert) pedig nem fog bejelezni semmi.
    Direkt visszanéztem az előzményekbe a korábbi stack overflow-os kereséseimet és találtaimat, valamint szándékosan próbáltam olyan algoritmusokat/témákat keresni, ahol femlerülhet valamilyen jogi copy-paste probléma egy esetleges licence miatt (mert mondjuk 6 sornál összetettebb a válasz..) Nem igazán találtam első nekifutásra szándékosan sem hasonlót.

    Ergo te elkezdesz valami kódot copy-pastelni, arról könnyen kiderülhet hogy azt nem lett volna szabad felhasználnod.

    3 soros 2 for ciklus esetén nincs értelme ilyesmiről beszélni, komplex rendszerek/algoritmusok saját több 100 soros implementációt meg keresve sem találtam stack-overflow-n. Biztos van azért, ilyet nem is szabad copy-paste-lni.

    Ha ez sorozatosan megtörténik, akkor nem jósolok hosszú jövőt a munkaviszonyodnak.

    Nem támogatom a copy-paste kódok írását, valamint magam sem szoktam használni. Jobb megérteni és magadnak implementálni. Viszont továbbra is ágyúval verébre megoldás tovább delegálni másnak egy feladatot, csak mert te rákerestél és láttál egy tök jó kódrészletet, ami megtetszett. Egy kezdő 3-4-8 soros copy-paste kódjából meg soha nem lesz jogi probléma szerintem.
    Mutasd a teljes hozzászólást!
  • akkor máris specifikálni kell és kiadni egy másik belső fejlesztőnek, hogy írja meg a specifikáció alapján.

    Azt mikor leszel hajlandó elfogadni, hogy a megrendelő adott (minden) esetben kötelezi a te cégedet, hogy a te céged felelősséget vállaljon azért, hogy a kód amit leszállít a megrendelőnek, az teljesen ő általuk készült, és megfelel a licencfeltételeknek amivel szállítjátok? Értsd a te munkahelyed rendelkezik a kód copyright-jával vagy ha nem, akkor a kód licencével megegyező feltételek mellett terjeszti? A te munkaszerződésedben pedig benne van, hogy ugyanezt te is biztosítod a munkahelyed felé.

    Ha te a StackOverflow-ról pastelsz be kódot, akkor 

    1. Nem rendelkezel a copyright-tal
    2. Nem tudod milyen licenccel rendelkezik az eredeti kód vagy ki a copyright tulajdonos
    3. Nem tudod, hogy aki a SO-ra felrakta, az jogosult volt-e a kód terjesztésére.

    A StackOverflow nem vállalja a felelősséget a kódért amit valaki más postolt. Te nem tudod, hogy ki postolta a kódot, tehát akit elő tudnak venni, ha szerzői jogi vagy licenc probléma van, az a te munkahelyed, onnantól kezdve pedig te.

    Hogy ilyen probléma van-e arra pedig vannak automatikus eszközök (pl. az említett BlackDuck) amik automatikusan átvizsgálják a kódot, hogy megfelel-e az általatok terjesztés licencfeltételeinek, valamint adott esetben megpróbálják azt is megállapítani, hogy a kód nem egyezik-e valami olyan kóddal amiről az eszköz adatbázisában az szerepelt, hogy az ilyen és ilyen üzleti kód.

    A nagyobb informatikai szolgáltatók ilyen eszközöket általában saját maguk is futtatnak, egyrészt hogy bizonyítsák a megrendelőnek hogy a szerződésileg és szabályozásilag kötelező (due diligence) copyright ellenőrzéseket elvégezték, másrészt hogy le járassák le magukat az ügyfélnél.

    Ergo te elkezdesz valami kódot copy-pastelni, arról könnyen kiderülhet hogy azt nem lett volna szabad felhasználnod.

    Ha ez sorozatosan megtörténik, akkor nem jósolok hosszú jövőt a munkaviszonyodnak.

    Jogilag az egyetlen támadhatatlan védekezés egy ilyen esetre az, ha bizonyítható, hogy aki írta a kódot az nem láthatta az eredeti kódot ergo nem másolás hanem véletlen egyezés illetve jóhiszemű vagy legális tevékenység.
    Mutasd a teljes hozzászólást!
  • Én azt gondolom, hogy nem az a lényeg, hogy a SO-ról származik-e egy kód, hanem hogy megfelelő ismerete van-e róla a fejlesztőnek. Ha megérti a tartalmát, akkor mindegy, hogy SO-ról származik, vagy sem. A dokumentáltság és specifikáltság erre merőleges probléma. Van olyan domain/project, sőt, akár aktuális feladat a projectben, ahol a formális specifikáció elvárt, vagy előnyös, meg van, ahol nem. Ez helyzete válogatja. A formális szót nem véletlenül emeltem ki. Specifikáció mindig van. Legfeljebb nem elég részletes és nincs leírva, hanem emberek fejében oszlik meg. Ez utóbbi meg a csapat/cég saját kockázata és helyzethez való hozzáállása, ami vagy működik, vagy nem.  Mobilos játéknál jobban működik, mint turbinavezérlésnél. Ha pedig van egy időpont, amikor van kód is és dokumentáció is, onnantól aztán édesmindegy, hogy melyik keletkezett előbb. Doksit írni akkor is tudni kell, ha utólag írod és ha nincs gyakorlatod benne (mert pl. soha nem csináltál ilyesmit), akkor szinte biztos, hogy rossz doksit fogsz írni. Regényt sem tud írni mindenki. Amikor egyetemen mérési jegyzőkönyvet íratnak, az maximálisan gyakorlati tanulás, de az is, amikor nagyházihoz írsz dokot. Aztán végül az önlab dok és a diploma is arra szolgál, hogy legalább egyszer életedben küzdj ki magadból össz. 100 oldalt (kinek több, kinek kevesebb), mert bizony azt is gyakorolni kell.
    Mutasd a teljes hozzászólást!
  • Ezzel tisztában vagyok és tudom. Másról beszélünk. Mégpedig arról, hogy csak azért, mert SO-n alapul egy kód/algoritmus részlet és nem saját kútfőből pattant ki, akkor máris specifikálni kell és kiadni egy másik belső fejlesztőnek, hogy írja meg a specifikáció alapján.
    Mutasd a teljes hozzászólást!
  • Amelyik cég így fejleszt az vagy nagyon szerencsés (mert kifizeti ezt is az ügyfél), vagy nagyon hamar befog csődölni, mert 3-4x-eres overheaddel dolgozik.

    Autó-, repülő-, energetika-, stb. iparban előírások vannak (vagyis minősítési feltétel, a megfelelő minősítés meg annak feltétele, hogy piacra kerülhessen a termék) ott, ahol balesetveszélyes lehet egy hiba. Ráadásul egy rakás CASE eszközt használnak, köztük olyanokat, amik automatikus validálást csinálnak. De a processzek is agyon vannak szabályozva. Ha minősítést akarsz, akkor az auditor végigjárja az egész fejlesztést, a legapróbb "csavarról" is doksit kér, a doksit leíró doksit, a leíró doksi processzét, a processz stratégiát, teszt lefedettséget, teszt stratégiát, stb. Direkt azért van ennyi szereplő az egészben (3-4x-es simán megvan), hogy egyrészt ne egy ember hibáján múljon egy baleset, másrészt - kicsit rosszmájúan nézve - ne lehessen megnevezni egy felelőst egy balesetnél.
    Mutasd a teljes hozzászólást!
  • Az erre a kérdésre adott válasz teljesen korrekt volt. Viszont egyáltalán nem életszerű. :)
    Amelyik cég így fejleszt az vagy nagyon szerencsés (mert kifizeti ezt is az ügyfél),

    Nem értek egyet. A kérdés és a tárgyalt példa arról szólt, hogy hogyan kell teljesen korrekten lekezelni a StackOverflow-ról copy-paste-ezést. Előtte kitárgyaltuk már, hogy valószínűleg sehol nem fizetik ki a ráfordított energiát, hogy jól csináld. És nyilvánvalóan hipotetikus eset.

    De hol állította bárki is, hogy kötelező tudatlan drone-ok által StackOverflow-ról össze-copy-pastelni amit leszállít az ember? Nem kell copy-pastelni ha nem érted, és máris nem merül fel a felesleges munkaráfordítás problémája.

    És mellesleg, ha tudatlan drone-okkal dolgoztat, akkor igenis csődöljön be, ne rontsa a becsületes és hozzáértő fejlesztők üzletét. Vagy pereljék be őket copyright sértés miatt. Nem fogom sajnálni.
    Mutasd a teljes hozzászólást!
  • Szerinted milyen a teljesen helyes hozzáállás?

    Az erre a kérdésre adott válasz teljesen korrekt volt. Viszont egyáltalán nem életszerű. :)
    Amelyik cég így fejleszt az vagy nagyon szerencsés (mert kifizeti ezt is az ügyfél), vagy nagyon hamar befog csődölni, mert 3-4x-eres overheaddel dolgozik. Persze vannak helyek, ahol a minőség mindenek felett áll, de a piacon azért nem ez a jellemző.
    Tegnapra és fele ennyiért..
    Mutasd a teljes hozzászólást!
  • Ez kiváló megoldás, ha az ember űrsiklót

    Nem. Az űrsiklóhoz ez nem elég szigorú. 

    Ott igenis meg fogják neked előre a NASA-s vagy Rockwell-es tudósok mondani, hogy pontosan mit kell csinálni a kódodnak, és milyen tesztvektorokat kell kielégítsen... mondjuk use case-enként egy tonnányi teszt eset specifikációval, és egyesével végig fog melletted menni három QA engineer az összes teszten és egyenként ki fogja pipálni a papíron, hogy ő X.Y. tanúsítja, hogy látta, hogy lefutott és helyes eredményt adott.

    És még így is egy csomó műholdat elvesztettek szoftver hiba miatt. De embereket még durvább lett volna szoftverhiba miatt. Az nem is történt meg soha az amerikaiakkal.
    Mutasd a teljes hozzászólást!
  • Ez kiváló megoldás, ha az ember űrsiklót vagy bankközi elszámolórendszert fejleszt, de minden máshoz ágyúval verébre.

    Meg bárhol, ha az embernek fontos, hogy ne zaklassák mindenféle copyright problémák miatt, ha netán a SO-n lévő megoldást valaki olyan kódból másolta ki ahonnan nem lett volna szabad. Ezt rengeteg megrendelő igenis elvárja, hogy bizonyítani tudd, hogy a kód amit nekik eladsz, azt te jogosan adtad el nekik, afelett te rendelkeztél (amíg át nem ruháztad rájuk a szállítással és általuk a számla kifizetésével), ergo nem fog náluk senki kopogtatni copyright perrel. Vigyázz, mert elkap a FeketeKacsa

    Ezenkívül a teljesen jó megoldást kérdezted. Ez a teljesen jó megoldás, ami bárhol megállja a helyét még copyright szempontból is, mert aki írta az nyugodtan mondhatja, hogy ő csak specifikációból dolgozott, nem látta más kódját, valamint az algoritmus le van dokumentálva cégen belül, és a kód illeszkedik a belső szabályokhoz.
    Mutasd a teljes hozzászólást!
  • Ez kiváló megoldás, ha az ember űrsiklót vagy bankközi elszámolórendszert fejleszt, de minden máshoz ágyúval verébre.

    Nehogy azt hidd ám, hogy erőmű, mozdony, autó v. ilyesmi programozásánál nem fordul elő az igen mély dokumentáció (mivel ipari szabvány írja elő a processzeket adott minősítéshez). Az olyan agile megközelítés, amit te vázolsz, remekül működik webes appoknál, meg mobil appoknál, ahol nincs betartandó biztonsági protokoll, szabvány, vagy processz.
    Mutasd a teljes hozzászólást!
  • Az biztos, hogy gyakorlati szempontból többet nyújt, mint az egyetemi képzés. Ott fejleszteni nem tanít meg senki.

    Mindig ez a misztikus "fejleszteni tanítás", ugyanabból a forrásból jövő "fejleszteni tanulni csak gyakorlattal lehet" mondattal. De ha az utóbbi igaz, akkor mi a gond az elsővel? Az a baj, hogy egy intézmény nem teszi meg a lehetetlent? Meg mi a "fejleszteni tudni"? Megtanulni egy Git-et? Vagy elolvasni a GOF design pattern könyvet? De azt minek tanítaná, vagy miért tenne ilyet bármilyen intézmény, ha egyszer önállóan is meg lehet tanulni. Sok az ellentmondás.
    Mutasd a teljes hozzászólást!
  • Ez kiváló megoldás, ha az ember űrsiklót vagy bankközi elszámolórendszert fejleszt, de minden máshoz ágyúval verébre. De valóban biztosabb, mint utólag megírni a teszteket, ott mindig megvan a veszélye, hogy a teszt hibás, ennél meg a specifikáció alapján lehet tesztvezérelten fejleszteni.
    Mutasd a teljes hozzászólást!
  • Hoppá, csak nem egy légbőlkapott állítás? Hát ezt bizony akkor nem lehet elfogadni. Affranc. Niacinnak biztos nem fog tetszeni. Jajj, mi lesz?!

    Az, hogy látványosan nem szándékozol konstruktívan részt venni a vitában, próbálsz trükközni és megoldani okosba', de hát érvek kellenek, nem trükközések, meg hangulatkeltés. Majd amikor arról lesz szó, hogy én indokoljam a saját állításaimat, megteszem. Egyelőre maradjunk a tiédnél.
    Mutasd a teljes hozzászólást!
  • Gondoltam, ha már statisztikát kérsz az egyetemeken végzett és az önerőből tanulók közötti különbségekre, akkor erre is tudsz mutatni. Érdekelt volna, de ha nem, hát nem.
    Mutasd a teljes hozzászólást!
  • Szerinted milyen a teljesen helyes hozzáállás? A kérdés ártatlan, tényleg kíváncsi vagyok.

    Clean room reverse engineering és újraimplementáció a Stackoverflow-s megoldásra.

    Az algoritmus dokumentálása és esetleges hibáinak kijavítása után mással/másokkal (tehát nem az aki a Stackoverflow-s algoritmussal foglalkozott) megíratni nulláról a cég belső processzeinek megfelelően csak a dokumentált algoritmus mint követelményspecifikáció alapján, az eredeti StackOverflow-s kód teljes figyelmen kívül hagyása mellett.

    Ha a specifikáció nem elégséges, akkor egyirányú feedback a reverse engineering team-nek, hogy egészítsék ki a specifikációt.

    Ez amennyire lehet biztosítja, hogy nem marad ki olyan amit a reverse engineering alatt elfelejtettek ledokumentálni.

    Nyilván ez több erőfeszítésbe kerül mint egy sima copy paste plusz tesztek, de biztosítja hogy a tudás is megvan a házon belül és legalább annyira karbantartható a kód mint ami házon belül készült, hiszen házon belül készült.
    Mutasd a teljes hozzászólást!
  • Ezzel a nagyjából helyes hozzáállással sajnos a kisebbség vagytok a copy-pastelők között.

    Szerinted milyen a teljesen helyes hozzáállás? A kérdés ártatlan, tényleg kíváncsi vagyok.
    Mutasd a teljes hozzászólást!
  • Ezzel a nagyjából helyes hozzáállással sajnos a kisebbség vagytok a copy-pastelők között.

    A többség odáig hogy egyáltalán megpróbálja megérteni, el sem jut. Innentől kezdve sajnos ők is "programoznak" algoritmizáló képesség nélkül.
    Mutasd a teljes hozzászólást!
  • Copypaste-elni én is szoktam, pl stackoverflow-megoldásokat, de csak akkor, ha értem, hogy mit és hogyan csinál a példa. Ilyenkor legalább annyira mindig személyre szabom, hogy átírom a változó/metódusneveket, hogy konzisztens legyen a sajátaimmal, vagy a csapatéival. Ez segít a megértésben is.

    Én ilyenkor még annyit szoktam csinálni, hogy lefedem unit tesztekkel, ebből kiderül, hogy tényleg jó-e a megoldás, és odateszem kommentbe a linket a Stack Overflow-s válaszra.
    Mutasd a teljes hozzászólást!
  • Igen, a következő bekezdést már átugrottam, bocsi.

    Semmi gond.

    Visszanézve, szerintem nem igazán lehet eldönteni abból amit írt, hogy funkcionális vagy procedurális amit csináltak.

    Igen, én is csak tippeltem, hogy procedurális, abból, amit ír, nem derül ki.
    Mutasd a teljes hozzászólást!
  • Pontosan így értem én is, és szerintem dubitoergosum értette félre, ezért írtam neki. De lehet, hogy tévedek, és funkcionális stílusban kezdték a Pythont használni.

    Igen, a következő bekezdést már átugrottam, bocsi.

    Visszanézve, szerintem nem igazán lehet eldönteni abból amit írt, hogy funkcionális vagy procedurális amit csináltak.
    Mutasd a teljes hozzászólást!
  • Köszi, az ilyen tanácsoknak mindig örülök. Egyébként van olyan ismerősöm, aki juniorként sikeresen bevezette a Git használatát a munkahelyén :)

    Nem azt mondom, hogy lehetetlen, de nem fog az első percben menni az átállás, minél nagyobb a cég annál nagyobb a tehetetlensége a meglévő infrastruktúrának. Szóval érdemes a SVN-t is megtanulni... pl. már csak azért is, hogy értsd mit is jelentenek az áttérés lépései.
    Mutasd a teljes hozzászólást!
  • lásd copy paste-el összehányt dolgok, aztán elkezd kisérletezgetni hogy ha ezt módosítom, hátha jó lesz.

    Copypaste-elni én is szoktam, pl stackoverflow-megoldásokat, de csak akkor, ha értem, hogy mit és hogyan csinál a példa. Ilyenkor legalább annyira mindig személyre szabom, hogy átírom a változó/metódusneveket, hogy konzisztens legyen a sajátaimmal, vagy a csapatéival. Ez segít a megértésben is.

    Egy tanács: nagyon érdemes megtanulni az SVN-t is.

    Köszi, az ilyen tanácsoknak mindig örülök. Egyébként van olyan ismerősöm, aki juniorként sikeresen bevezette a Git használatát a munkahelyén :)
    Mutasd a teljes hozzászólást!
  • Pontosan így értem én is, és szerintem dubitoergosum értette félre, ezért írtam neki. De lehet, hogy tévedek, és funkcionális stílusban kezdték a Pythont használni.
    Mutasd a teljes hozzászólást!
  • Szerintem nem.

    A funkcionális programozás nem azonos sem a procedurális sem a strukturált programozással.

    Olyan dolgokra gondolj, mint Scala vagy SML vagy F#, olyan nyelvek ahol egy függvény önmagában lehet egy változó értéke, és a függvény literál paraméterei is lehetnek függvény literálok, és még több egyéb szabály is biztos van.
    Mutasd a teljes hozzászólást!

  • Szerintem ez elég alap dolog, nem is nagyon lehet programozni nélküle,

    Szerintem se nagyon lehet, de mégis rengeteg példát láttam hogy megpróbálják... (ez most teljesen függetlenül értve az oktatási intézményektől, tehát nem állítom azt hogy egyetemista vagy cc-s csinálja) lásd copy paste-el összehányt dolgok, aztán elkezd kisérletezgetni hogy ha ezt módosítom, hátha jó lesz.

    Gitet használunk.

    Egy tanács: nagyon érdemes megtanulni az SVN-t is. A git szerintem jelenleg még kevésbé gyakori cégeknél még mint az SVN, szóval hiába jobb technikailag (szerintem legalább is), a SVN tudásra általában esélyesebb hogy szükség van. És nagyon fontos, hogy mindkettőnél tudja az ember hogy kell egy merge-et megcsinálni úgy, hogy a verziókezelő is tudjon róla, hogy a merget megcsináltad (SVN-el pl. tudd, hogy a svn:mergeinfo attribútumokat is be kell commitolni, és hogy az milyen műveleteknél hogy változik).
    Mutasd a teljes hozzászólást!
  • Vszeg igazad van, mondom, hogy rosszban vagyok a nevekkel :)
    Mutasd a teljes hozzászólást!
  • Szerintem a "funkcionális vagy lineáris" megközelítés alatt a procedurális vagy strukturált programozást érted.

    A funkcionális programozás mást jelent.
    Mutasd a teljes hozzászólást!
abcd