pubsubhubbub - a fagyi visszanyal

Ebben a hosszabb írásban a (nem új) pubsubhubbub protokolról írok egy összefoglalót, valamint a végén egy saját (még nem publikált) szoftverem alapötletét is felvázolom. Remélem valamennyire hasznosnak találod majd.

Rövid feed-történelem

Eleinte volt a sima RSS és Atom formátum. Végre valami gépileg értelmezhetőt kapott a programod és nem html-ből vagy valami hasonló dzsuvából kellett kibogarászni a tartalmat. Egész kis műfaj épült az RSS streamek rendszeres ellenőrzésére és megjelenítésére. Többet nem kellett a felhasználónak hetente végiglátogatnia a kedvenc blogjait, ott volt a kedvenc RSS olvasójában minden, mindig. Mikor volt az utoljára, hogy elkezdted begépelni a firefoxnak, hogy "iwillworkforfood.blogspot.com"? Soha? Sebaj, nincs harag :-)
Olyan mainstream szoftverek támogatták ezt, mint a Microsoft Outlook.

Az RSS és Atom egyetlen apró hátulütője persze az, hogy időnként rá kell nézni, és ilyenkor le kell tölteni az egészet akkor is ha semmi új nincsen benne már egy éve. A másik apró gebasz az, hogy a friss tartalom csak egy újabb poll után kerül a felhasználóhoz. A harmadik pedig az, hogy amikor többtízezren olvasnak egy fontosabb "stream"-et, akkor az jelentős extra terhelést és forgalmat jelent a weboldalnak. Ez olyan, mintha a munkahelyeden nem csak a főnököd kérdezné, hogy "mikor leszel már kész az atomreaktorvezérlő szoftverrel", hanem mindenki akinek eszébe jut. Persze a számítógépek kicsit jobban kezelik a megszakításokat, mint az emberek.

Ezek persze nem túlélhetetlen esetek, párszáz olvasónál még mindig inkáb hagynánk had pollozzon mindenki, mint hogy törődjünk ezzel az apró problémával, extrakiadást nem jelentene, és valjuk be teljesen jó az is, ha a jövő héten amikor éppen akad időd (egy fordítás alkalmából például) elolvasod ezt a bejegyzést.

Azonban a kiszolgálónknak, a blogger.com-nak pármillió ilyen blogot kell kiszolgálnia. Így nekik már komoly terhelést jelent az, hogy örökké kérdezgetik az RSS csatornákat, és nem csak akkor, amikor a felhasználónak eszébe jut, hanem amikor az RSS olvasójának eszébe jut. Olyan oldalak, mint a google news, és társai kifejezetten szeretnék a híreket a lehető leghamarabb megkapni, azaz lehetőleg poll nélkül.

Alighanem sóhajtoztak a szolgáltatások mögött álló programozók, hogy milyen szép is lenne, ha nem kellene pollozni -mert az az összes fenti gebasszal rendelkezik- hanem egyszerűen csak elküldené neked valaki a friss tartalmat. Két megoldás született az álomból:

• a cloud - ilyen támogatását én még nem láttam
• a google pubsubhubbub specifikációja - ez annál inkáb széles támogatottságot élvez

Nézzük néhány nagyobb halat, akik pubsubhubbubbal (jajj de szép név) turbóztak fel:

• a blogger.com nyilván az elsők között, tekintve hogy google kézben van
• hamar megjelent a támogatás a wordpress-ben és a nagy wordpress.com is bekapcsolta úgy 7.5 millió náluk hostolt blogra
• a nagy nemzetköziek mellett had említsem meg, hogy a magyar blog.hu is támogatja
• A "long tail" blogok mellett nagy halak feedjeiben is megjelent: CNN, BBC, és pár egyéb nagyobb

Ugyanakkor viszont nem mind, a magyar hiroldalak például tipikusan nem kaptak a lehetőségen és pár nagyobb nemzetközi is kimaradt (nytimes, satöbbi) A pubsubhubbub még így is használató valamennyire velük, simán megkérheted a google rendszerét hogy amikor ők találtak friss tartalmat, akkor küldjék tovább neked is a pubsubhubbub protokolon keresztül. Nem lesz gyors, mert a google ilyenkor valójában poll-ozik, de azt se neked kell. Kérdés persze, hogy ez így mennyire megbízható, mert ha csak annyira, amennyire a google apik, akkor felejtős :-D

No, ennyit a történetről, jöhetnek a...

Technikai részletek

Nézzük hát, a specifikáció maga nem valami bolonyult. A pubsubhubbub 3 szereplős játék:

1. a publisher - aki az RSS vagy Atom feedet kiszolgálja
2. subscriber - aki szeretné megkapni a friss tartalmat
3. hub - aki a kettő között áll. Ő leginkáb olyan mint az újságosfiú.

Elösször is, az RSS-t vagy Atom-ot publikáló weboldalnak tudtára kell adnia valahogy a klienseivel, hogy őt nem csak poll-ozni lehet, hanem ő támogat ennél okosabb megoldást is. Ez úgy történik, hogy egy atom linket kell betenni a kimenetbe, ezt megnézheted például itt akár ennek a blognak az atom feedjében is:

<link href="http://pubsubhubbub.appspot.com/" rel="hub">

Innen tudhatja a kliens, hogy melyik hub-nál kell szólnia, hogy őt érdekelné.

A publisher ezen kívül, amikor új tartalmat tesz a feed-be, szól is a hub-nak: nesze fiam, szólj mindenkinek! Ennyit kell tudnia a publishernek.

Nézzük, a subscribernek most már tudhatja a feed-ből, hogy nem kell örökké a publisher-hez ellátogatnia, hanem a publisher újságárús srácai fogják megkeresni. Neki ehhez annyit kell tennie, hogy megadja neki a címét. A kézbesítés, akárcsak a poll és a publish, http protokolon keresztül történik.

A felíratkozásra azért tettek egy kis hurkot, ugyanis ha a szerveredet felíratnám néhánymillió hiperaktív RSS csatornára, a google app engine böszme nagy szerverfarmja verné halálra a géped, illetőleg termelne neked szép nagy számlát a forgalommal. Ez pedig kimeríti a "más farkával történő csalánverés" tényállását, így mindkét fél érdekelt abban, hogy egy harmadik ilyet ne csináljon. Ebből a célból a hub visszakérdez a megadott címre, hogy tényleg innen jött-e a kérés. Miután a kérés megerősítést kap, a felíratkozás kész.

A publish nagyon nagyon egyszerű: http POST requestet kapsz a megadott címre, aminek request body-ja a friss tartalom.

Mennyire gyors? Nem nehéz kipróbálni, egy blogger.com blog kell hozzá és egy tetszőleges publikus webcím. dyndns, portforwarding, ingyenhosting, akármi játszhat. Általában mire sikerül ablakot váltanom, már ott van benne a tartalom, amit a blogger.com-ra került. Nem nevezném realtime-nak, de a pollhoz képest cefetgyors.

A fejlesztők álma az volt, hogy ez az egész elosztott lesz, azaz soksok hub lesz és mint a postahivatalok között áramlik majd a sok sok update. Hááát... ez nem lett egészen így. Természetesen csinálhatsz saját hub-ot, és a wordpress blogjai valóban tartalmaznak egy beépített hubot, ez nekem úgy tűnik a ritka kivételek közé tartozik inkáb, mint a meghatázozó szabály lenne. A pubsubhubbub-ot támogató feed-ed legnagyobb része a google hub-jára mutat. Azaz bár van lehetőség arra, hogy ez máshogy legyen, mégiscsak egy nagy hal viszi az egészet. Ha valamiért elakad egy pár órára a google rendszere (ilyen pedig minden cloud rendszerrel történt eddig), akkor még úgy se fog muzsikálni a rendszer, mint pollozással. Ezt azért szerintem érdemes belekalkulálni.

Egy kicsi extra: subhub

Majdnem elérkezett a boldogság, mert nem kell fölöslegesen böszme nagy sávszélességet vásárolni, időnként végignyalni a fél internetet, satöbbi. Amikor jön valami anyag, akkor megkapod, ezzel végülis egyszerűbb lehet a rss-feldolgozás menete.
Viszont arra gondoltam, mennyire természetesebb lenne, ha valamilyen csatornán keresztül érkeznének az RSS updatek, nekem talán egy JMS csatorna tűnik a legegyszerűbbnek. A feldolgozásról eldönthetem, hogy egymás után vagy párhuzamosan. A feldolgozást nem terheli agyon egy hirtelen forgalomhullám reggel, amikor mindenki tweet-el és updatel ésatöbbiésatöbbi. Ezzel el is tudom különíteni az feldolgozástól a pubsubhubbub-specifikus kódot, és a feldolgozás csak szin tiszta RSS/Atom xml-eket kap. Ezt az egy komponenst dobtam fel egy kívülről elérhető szerverre, a feldolgozás egy JMS queue-n keresztül tartja vele a kapcsolatot. A feldogozást akár tehetjük saját meglévő farmunkra is, ott olcsóbb a tárhely és a CPU idő is. Söt a felhőben szerintem elcseszett drága általában véve.

Ezt majd egyszer papírsárkány design pattern néven fogom szabadalmaztatni és abból leszek csilliárdos.

Hát ennyi tényleg. Boldog Szent Vencel napot :-)

gondolom

Nézzük csak, a következő lehetőségek állnak rendelkezésre a munkahelyed elhagyására:

1. Melózolamíg meg nem halsz - nem hangzik nagyon biztatóan.
2. Nyugdíjba mész - elvi lehetőség, gyakorlatban inkább az 1. lesz, de ezt hivatalosan még senki sem merte bevallani.
3. Kirúgnak - előfordul, ezer lehetséges okból, és csak az egyik lehetséges ok vagy te.
4. Felmondassz - ez a legjobb: már többre értékeled az idődet, mint azt a pénzt, amit adnak cserébe. Vagy csak mégtöbbet akarsz kapni érte...

Szóval ha kirúgnak, az nem a legrosszabb lehetőség hanem az a második legjobb. Gondoltam ezt felítom ide, hátha egy véletlenszerű pillanatban valaki hasznosnak találja.

A nap pozítív gondolata a Piros Satyesz bt támogatásával.

Egyébként mostanában nagyon kevés szabadidőmben mongodb-ről olvasgattam, tovább kínoztam a drools planner-t mindenféle irányokban, meg wikipédiát szerkesztgetek. Egy csomó ötletem van, de nagyon nehéz időt keríteni rá.

csapatelmélet röviden

Úgy tartja a mondás, hogy a pokolba vezető út jószándékkal van kikövezve. Ehhez hasonlóan már évek óta van egy olyan elképzelésem, hogy sok project kudarcáért felelős az, hogy nagyon-nagyon-cefetjó embereket vettek fel rá, akik képtelenek voltak együttműködni és alkudni.

A "jó" legveszélyesebb ellensége a "tökéletes".
Nem a legjobb kell, hanem elég jó.

NagyÁltalánosKeletiZenKonfuciuszButhistaBölcsesség csapatunk eheti jelentését olvashattátok.

Drools, Planner

Mostanában eltöltöttem egy kis időt egy prototipus projecten ami a drools planner integrációját késziti elő az oVirt-be. Ez még nem azt jelenti, hogy valaha benne is lesz, csak azt, hogy megpróbálom feltakarítani a környéket és beintegrálni. Gondoltam pár tapasztalatot megosztanék vele kapcsolatban.

Ha még nem találkoztál a drools projecttel, ez egy szabály-motor. Leírsz szabályokat, bedobálod a tényeket és bizonyos következtetésekre jut a drools, a következtetésekből pedig további következtetésekre. Egyrészt nagyon egyszerű és szerintem elegáns módja a szabályok leírásának, másrészt bizonyos bonyolult feladatokat egészen egyszerűen oldhatsz meg vele. Pl N királynő, labirintus, satöbbi iskolafeladatok. Na ezeken az iskolafeladatokon túl egész hasznos dolgokra is lehet használni a hétköznapi életben, most például az oVirt-ben (ami egy private cloud rendszer lenne, csak ahhoz még kicsit béna) virtuális gépek szerverekre való kiosztására próbálom használni.
(felemelő dolog szabadidőben is a melón pörögni, biztosan hősi gödörbe fognak elkapálni, ha beledöglök)

IDE

Szóval a szabályokat egy speciális nyelven írod le, erre van több opciód is. Ez végül sima plain java bytecode-dá fog lefordulni. Szóval ez forráskód, ha tetszik, ha nem. A forráskód, amit írnod kell java-jellegű. Éppenséggel én nem szeretnék ilyeneket írni vim-ben, szóval az IDE támogatásnak utánna kellett járnom.
Eclipse marketplacen ha szétnézel, a JBoss IDE állítja magáról, hogy van benne Drools support. Ez sima mezei hazugság marketing, nincsen benne :-) A drools csomagok közűl kellett letölteni egy lefordított verziót és felinstallálni. Pár varázslót és egy editort kapsz, az editorban van syntax highlighting és egy kevés code completion. A vim-élménynél azért lényegesen jobb, de el tudnék képzelni barátságosabbat.

Pár tapasztalat

Első alapszabály a drools-hoz általában: bármilyen szabályt írsz is, ne legyen benne hálózati/adatbázis interakció! A drools kegyetlenül elkapja és nagyon lassú lesz vagy agyonterheli az adatbázisod. Valószinűleg mindkettő. Csinálj szépen in-memory modelt. Elösször tölt, aztán kiértékel. Sajnos ez nem mindig egyszerű.

Aztán pl én néha nem szégyellek egy loggert bedobni a drools szabályaimnak, csak hogy meggyőzödjek róla, hogy tényleg kiértékelődnek. Érdemes csak debug szinten hajtani, mert komoly mennyiségű logot le tud termelni.


Aztán unit-tesztek: igen, mindenképpen unit-tesztelj! A szabályok csak futásidőben fordulnak le (első futás), szóval az hogy nem kiabált a build, az még a világon semmit sem jelent. És nagyon ajánlott ellenőrizni az eredményeket, mert könnyen előfordul, hogy elírtál egy feltételt a szabálynál és mégsem értékelődött ki.

A szabályok kiértékelési sorrendjáról pedig ennyit lehet tudni: javaslatot tehetsz rá (salience paraméter) de amúgy a drools nem enged beleugatni senkit se.

Planner

No nézzük mi ez a planner. A planner optimalizációs feladatokra segít adni valamilyen megoldást, a drools expertre építve. Ez konkrétan úgy történik, hogy pontozási szabályokat írhatsz le drools szabályokkal, írsz hozzá pár sor XML konfigurációt (ne aggódj, java config is van ha még nagyobbat akarsz szívni) és ráengeded a megoldó algoritmust. Visszakapsz egy megoldást jó esetben, és a hozzá tartozó elért pontszámot.

A pontozásnál több féle pontozást használhatsz, nekem a soft and hard tetszett legjobban.

Körülbelül ezer módon rúghatod tökön magad a drools plannerrel, kb 20 különbözőképpen nekem is sikerült, ebből párat nektek. Ha esetleg meg akarnátok próbálni :-)

Kiválló kiindulópont Geoffrey de Smet drools példagyüjteménye, ami a drools csomagok között letölthető. Szerintem a példagyüjtemény nélkül az elején feladatam volna. A dokumentáció az helyenként alulról közelíti a kettes érdemjegy határait. Pl az XML konfiguráció pontos leírását sehol se találtam, végül a forráskódból jöttem rá, hogy mit rontottam el.

Az egyik fájó különbség a példák és a rögvalóság között, hogy egyes példák egészen sokáig tart, amíg lefutnak. Sokkal tovább tart, mint a felhasználók türelme. A szerencse viszont az, hogy a legjobb megoldás a felhasználók túlnyomó részét teljesen hidegen hagyja, egyszerűen csak egy elég jó megoldást akarnak és persze tegnapra. Ezt sikerült olyan paraméterekkel elérni, mint

• maximumUnimprovedStepCount, azaz ha egy ideig nem talál jobb megoldást, akkor itt hagyjuk abba.
• scoreAttained, azaz egy bizonyos minimális szintnél tovább már nem kell tovább menni.

Azért a terminációs szabályokhoz én el tudnék képzelni jobb döntési logikát is, legalábbis az adott feladathoz én valami pontosabbat szeretnék. Majd bizonyíthatom, hogy tényleg van jobb ötletem, mert a drools planner-rel megetethetem a saját implementációmat.

Aztán nézzük mivel szívtam még meg... Igen, a probléma tények (facts)-hoz például első nekifutásra nem a megfelelő listát adtam vissza. Pár kört lefutottam, mire rájöttem, hogy ennek következtében a pontozási szabályok egyszerűen nem kerülnek kiértékelésre.

Aztán a ConstraintType.POSITIVE-ra nem jöttem még rá, hogy hogyan kell használni, a példák között nincs egy se. Pár dolgot viszont eleinte pozitív állítások formájában próbáltam megfogalmazni. Na erről leszoktam, és csupa negatív pontozás van jelenleg. Nekem furcsa, hogy csak büntetéseket osztok a szabályaimmal, de megszokom. Majd a politikai pályafutásom alatt biztosan sok hasznát veszem ezeknek a tapasztalataimnak.

Egyébként, ha kicsit belejön az ember, úgy tűnik egészen komplex feladatok optimalizására is egészen könnyen lehet megoldást gyártani vele. A futási ideje igazán nem vészes, amennyiben jól paraméterezted a termináló feltételeket :-)

Integráció - röviden

Minden integrációs projectnél végül oda jut a párbeszéd, hogy az integráló fél/kliens felteszi a kérdést: Hogyan oldjuk meg azokat a problémákat, amelyek az én rendszeremben jelentkeznek és a te rendszeredből jönnek?
Erre ez az általános válasz a szolgáltatók részéről: Azok a problémák, amik a te rendszeredben jelentkeznek, azok a tieid.

Cluster - magánvélemény + ötlet

Azok a clusterezési technológiák és szoftverek, amik uniform szervereket várnak el futtatókörnyezetként, komoly hátrányban vannak azokkal szemben, amelyek képesek a hardware különbségeit (pl memória méret, elérési sebesség, sustainable és random IO, CPU-k száma és sebessége, hálózat, satöbbi) kezelni. Ugyanis az ügyfelek nem szeretnék évekkel vagy akár csak hónapokkal előre megvenni a hardware kapacítást. Pl egyes projectek esetében nem nagyon lehet kitalálni, hogy mekkora kapacításra van szükség. Meg hát nem is tudják, kapnak egy adott összeget egy üzleti évre és legközelebb majd a következő üzleti évben lehet hardware-t vásárolni. Akkor már más lesz a kinálat. Még ha mindig a listán is van a régi szerver tipus, akkor is valószinűleg más hardware fogja akkor megérni, más az akciós, satöbbi.

Például nekem a cassandra, amikor teszteltem nagyon makacsul ragaszkodott ahhoz, hogy egyenlően ossza fel a keyspace-t minden alkalommal, amikor új node-t csatlakoztatok.

Ezt gondoltam csak azért írom ide fel, mert nem olvastam egy könyvben sem eddig, ez amolyan magánvélemény.

Ötlet: Csak példaként egy private cloud-ba érdekes lehetne olyan logikát írni, ami felstartol mégegy mongodb szervert, ha a cluster átlagos terhelése X főlé nő, lekapcsol egyet, ha Y alá csökken, megtart tartalékba Z-t mindig. Nyilván nem csinál ilyet az oVirt, de más rendszerek biztosan igen. Bocsi, hogy megint oVirt lett belőle...
Ez persze a fizikai vasakon futó rendszereken nem segít, nem "silver bullet", de egy egyszerű megoldás lenne a probléma java részére.

oVirt or oVirt

Néhány további a múltkori dolgokhoz az oVirt-tel kapcsolatban, most nem annyira felhasználói oldalról, kicsit inkáb belülről.

Poll

Az oVirt hogy bármilyen információt beszerezzen a futó VM-ekről, poll-ozgatja a host-gépeken futó agentet (ennek VDSM a neve). Az agenttel csak két problémám van:

• Új szoftvert írni XML-RPC-re? Ez komoly? Akkor már miért nem CORBA? :)
• Néha úgy tünik az alatta levő libvirt-tel hamarabb szótértenék. Például oda lehet callback-eket is regisztrálni.

A pollozás mellett amit nem szeretek, az az, hogy a leszedett információt egyszerűen belecsapjuk az adatbázisba és nem csinálunk semmit, várjuk hogy valaki megkérdezze. Ezzel kapcsolatban borzasztóan kiváncsi vagyok, hogy vajon miért. Egy tranzakciós adattárolóban tartunk valamit, ami tökre nem tranzakciós. Minden alkalommal amikor kellene tudni, egy Host-on mennyi szabad memória van, az adatbázisból kérdezzük le.
Szóval szerintem:

• A host éppen aktuális állapotát nem adatbázisban kellene tartani, hanem a memóriában vagy elosztott cache-ben. Az adatbázis nem cache!
• A hostot lehet hogy kell poll-ozni időnként, hogy életben van-e még, de sokkal hatékonyabb lenne ha streamelné az adatokat, ha már van agent
• A streamelt eseményeket akár JMS sorban priorítási sorrendben lehetne feldolgozni, tetszőleges szálon. Ezeknek az eseményeknek kellene elindítania a döntési folyamatokat. (pl hogy a host túlterhelt, valamelyik Vm-et át kell migrálni máshova)

Kereső

A kereső egy tipikus szent tehén, senki sem mer hozzányúlni. Nagyjából úgy van most, ahogy átportolták .net-ből. A másik nehézség, hogy jó részét megosztv használja a GWT frontend és a backend, így aztán tényleg nehéz is hozzányúlni, de azért egyszerűsítgetni simán lehet benne mert nagyon cifrán redundáns.
A kereső egy apró baja az, hogy SQL lekérdezéseket gyárt, nem holmi lucene vagy hasonló okoskodás. Az SQL se rossz persze, de a postgres-nek rettenetes bajai vannak a generált lekérdezéseivel. Degeneráltak a lekérdezései. Szóval a kereső is jól tökönrúgja az adatbázist, de a kód ami a lekérdezést generálja tényleg nehéz eset, elösször kicsit egyszerűsíteni kellene rajta, de azt nem lehet, mert így "működik".

Kompenzációs tranzakciók

Hallottál már olyanról, hogy kompenzációs tranzakciók? Én csak véletlenül futottam bele régebben, de soha nem láttam alkalmazva. Ez a megoldás azért lett bevezetve, mert a kommunikáció a hostokkal lassú, közben lockolunk rekordokat és a postgresql-nek nincs read uncommited tranzakció izolációs szintje. Mondjuk még mielött tiltakozni kezdenél, hogy azért van más épkézláb megoldás: persze van. De mindenesetre valahogy úgy jött ki, hogy egy bizonyos táblába tol az oVirt mindent, és lezárja az adatbázis tranzakciót, egy tranzakciók feletti tranzakciót csinál. Aztán ha N adatbázis tranzakció után belefut egy hibába, akkor megpróbálja visszacsinálni ezek alapján a rekordok alapján.

1. Ez kézzel hímzett megoldás, rettenetesen sok kódsor szolgálja
2. Nem biztos hogy sikerül a kompenzációs tranzakció, és akkor megakadunk ott, ahova nem akartunk eljutni
3. Ha kompenzáció nem sikerül az engine indításakor, akkor az engine el se indul. A felhasználó meg néz hogy mivan.
4. Bár a tranzakciókat igazán egyidejű hozzáférésre találták ki, a kompenzációs tranzakcióknál teljesen para az egyidejű hozzáférés.

Nem lenne nehéz megoldani, hogy a Host műveleteket az oVirt asszinkron kezelje. Küldözgessen JMS üzeneteket, vagy akármi. Én egyébként szivesebben barátkoznék a gonosz MySQL-lel is akár, mint hogy egy tranzakciós rendszer tetejébe workaroundként mégegy tranzakciós rendszert húzzak.

Adatbázis

Á igen, rendesen tökönrúgjuk az adatbázist a HOST/VM státusz adatok örökös írogatásával, a hülye kereső lekérdezésekkel, de ez nem fáj nagyon, amíg nincsen sok VM-ed. (Mondjuk miért használnál olyasmit, mint az oVirt, ha nincs sok VM-ed?)
Viszont helyenként rendesen tökön rúgjuk szegény PostgreSQL-t olyanokkal is, hogy egy ciklusban kérdezünk le valamit belőle, ahelyett, hogy egy értelmes lekérdezést írnánk. Ez nekem az egyik legfájdalmasabb dolog, mert ez direkt van így és nem értem miért kell hogy így legyen. Nemrég kellett egy bugot kijavítsak és első nekifutásra kicsit okosítottam a lekérdezésen, de ezt nem fogadta el a reviewer (aki szerintem beletette a bugot). Az elfogadott megoldásban kénytelen voltam iterációban kérdezgetni az adatbázisból. Ez a rendszered növekedésével exponenciális terhelésnövekedéshez vezet. Baromi zavaró, amikor ilyeneket csináltatnak velem.

"Mindenki más faszával szereti verni a csalánt"
- ZTutto