Kicsi felhőt!

Azt, hogy otthagytam a fizetett oVirt maintainer állást és ingyen dolgozok a CloudStack-en, azt lehet amolyan kritikaféleségnek felfogni? Vagy pofátlanságnak? Mindegy, ez történt. Most a CloudStack-en foltozgatok apróságokat, főleg teszteket írok és leak-eket foltozok, remélem lesz időm kicsit jobban belemélyedni és pár új feature-t implementálni. Persze plusszok és minuszok mindkét oldalon vannak.

Tiszta aljasság részemről, de nagyon sokat töröm a fejem egy kutatási célú felhő projecten, ami ezeket az ötleteket demózná:

1. No Host Agent. Az oVirt egy VDSM nevű python programot használ host agentnek. A CloudStack egy java programot hajt. Mindkettő http protokolon keresztül beszélget a management szerverrel. Illetve a szerver beszélget vele.
   Vajon erre szükség van? Szerintem meg lehet csinálni sima SSH kapcsolattal is, így megszabadulunk a poll-tól, folyamatosan folyó információk jönnek a host és a VM-ek állapotáról, valamint nincs szükség pár másodpercenként újra SSL handshakelni. Az oVirt-et teljesen halálra lehet szívatni 20-30 hosttal. SSH kapcsolattal akár egy Raspberry PI is képes többszáz host-tal egyszerre folyamatos kapcsolatot tartani, miközben adatok áramlanak róluk. Ezt már kipróbáltam. Nincs szükség külön szoftver fejlesztésére, az openssh mindenhol ott van és az overhead minimális.
2. Scheduler. Az oVirt schedulere volt az, ahol végleg feladtam a reményt. A régi tervemhez szeretnék visszatérni és optaplanner segítségével egy optimalizációs algoritmusra bízni a cloud terheléselosztását. Mint ahogyan már meg is tettem, még csak nem is elsőként.
3. Event driven. Már sokszorosan sikerült kiakasztani azzal, hogy minden eseményfeldolgozást cron/quartz jobokként futtatunk. Felhasználóként sem tudom élvezni, amikor minden gombnyomásra várnom kell több másodpercet. Lásd SSH, lásd websocket, lásd long poll, halálfaszaakármi. Utálok számítógépekre várni.
4. Flyweight. Az az ötetem, hogy a rendszernek futnia kell tudni emberileg elfogadható válaszidőkkel egy Raspberry PI B modellen. Nem az az ötlet, hogy az egy megfelelő célhardware, hanem hogy kicsi belépési küszöb legyen a használatához. Host rendszernek minnow board, legányolt desktop gépek. Bármi, amiben van egy ethernet csatlakozó.
5. Primitív. 1 db war file. Jetty vagy Tomcat.
6. Új koncepció: Követelmény. Az oVirt és a CS is szép webes GUIk, ahol megcsinálhatod a storage domain-t, megmondhatod, hogy melyik VM melyik hoston és processzoron fusson, migrálhatod, megmondhatod hol legyen a storage, satöbbi. Ha nekem akár csak 10 hostot kellene eligazgatnom, legkevésbé sem akarnék ilyesmivel foglalkozni. Ez a droidok sportja. Én a követelményeket akarnám meghatározni a rendszernek: Az X VM reggel 8 és du 4 között mindenképpen menjen! A "tomcat" VM poolból legalább 4 gép legyen folyamatosan elérhető és különböző hostokon fussanak (failover). Ilyesmi.
   Cserébe pár koncepciót szivesen kinyírnék. Ilyen pl a cluster fogalma. A cluster olyan hostok halmaza, amelyek egy adott minimális processzor kompatibilitásnak megfelelnek és így képesek az arra a processzoron futó VMek futtatására. Ezt a koncepciót is a követelmény venné át illetve a processzormodellt simán meg tudjuk vizslatni (/proc/cpuinfo)
7. Kérdés: Szükség van-e tranzakciókra? Az oVirt tranzakció workaroundjaitól mindenkinek lerúgja az agya a láncot, ha elmesélem, javítása pedig nincs napirenden. A CS-nek is vannak vicces dolgai, de működik és az egyszerűsítése folyamatban van. Viszont egyáltalán: van szükségünk tranzakciókra? Az adatbázis az egyetlen tranzakcionális erőforrás az egész rendszerben, a hostok, a hálózat, a storage, a virtuális gépek, mind totál figyelmen kívül hagyják.
8. Scale out. Van pár ötletem arra, hogy az optimalizációs feladatokat hogyan futtatnám több gépen, de még kiróbálásra várnak.

Ennyi, nagyon lerövidítve. Ez elég drasztikusan térne el a jelenlegi IaaS szoftverektől, így nem hiszem, hogy lenne értelme megpróbálni bármelyikbe is beletuszkolni.

Szavazz Seamplex-re!

Idén sem regisztráltam a blogot a gloden blog-ra, úgyhogy gondoltam megkérlek titeket: ha szavaztok, támogassátok Bakai Balázs blogját, a seamplex-et.

Két OOM Design Pattern

Van pár dolog, amiért nem szól se a checkstyle, se a findbugs, de egyébként nagyon egyszerű megtalálni és csillió van belőle, legalábbis melóban.

Az egyik az, amikor deklarálsz egy HashMap-et és úgy hívod, hogy cache, vagy odakommentezed, hogy ez egy cache. Ez sajnos nem igazán cache lesz, sajnos nagyon gyakran inkább egy OOM. Tipikusan amikor vagy egy singletonban találod, vagy eleve a "cache" statikus. Ilyenkor általában nem gondol az ember azokra a dolgokra, amik megkülönböztetnek egy igazi cache-t a HashMap-től: weak reference, TTL, méret korlátok, stb.

A másik ilyen tipikus gebasz, amivel találkozni szoktam forráskódban, az az amikor valaki felfertőzi a finalize metódust (amikor ilyet találok, mindig elkezdem keresni hogy erre vajon mi oka lehet) és odakommenteli rá, hogy "destructor". A finalize metódus nem destruktor. Ha nem olvastad a javadoc-ot, akkor erre akkor jössz rá, amikor a finallize metódusba valami lassú műveletet pakolt az elkövető. Szerintem ilyenkor leginkáb a HIV vírushoz hasonlít a hatása, lelassítja annyira a GC-t, hogy ne tudjon takarítani és természetesen OOM lesz a vége.

Ez ilyen könnyű győzelem, amennyiben megengedik hogy kijavítsd.

"Ennyi volt a Design Pattern mára,
fiatalember vigyázzon, rádzsael a paprikára!"

Master Bean Design Pattern

Master Bean, a google szerint

A Master Bean pattern az, amikor akár EJB, akár spring, akár valami custom házitechnológia bevetése esetén van egy központi ojjektum, ebben található hivatkozás minden DAO, manager, service satöbbi objektumra és minden egyéb kód, a DAO, manager, service satöbbi objektumokat is beleértve ebből az objektumból keresi meg amire szüksége van.
Láttam különböző implementációkat, ezt a Master Bean-t van amikor injektálják, van amikor ősi singleton patternként getInstance()-elik és van olyan is amikor valami izgalmas módszerrel lookup()-olják.

Egyéb elnevezések és hasonló koncepciók: God Object, registry

A Facade nem keverendő a Master Bean-nel, mert a Facade a hívásokat delegálja általában több service objektum több metódusának, a Master Bean pedig csak visszaad egy hivatkozást magára a service objektumra.

Ennyi lenne a design pattern mára. Légkondi megy?

többnejű programming

Egyik nap ebéd közben azt mondtam a munkatársaimnak, hogy szerintem ahhoz hogy valamiből igazán jó legyél, ahhoz erősen fókuszálni kell arra a területre. Emiatt pedig csak 1 dologból lehetsz igazán jó, a többiből csak tűrhető. Például Albert Einstein fantasztikusan jó volt fizikából, emellett még egész tűrhetően hegedült. Ha több dologból is igazán jó akarsz lenni, akkor több dologra is fókuszálnod kellene, ez viszont ütközik a fókusz definíciójával. Milyen fókusz az, hogy fókuszálsz a ruby, a python, a linux kernel és a java technológiákra?

Nos az eredmény az volt, hogy leüvöltöttek. Mint amikor gimiben megkérdeztem hogy a kereszténység miért egyistenhit, amikor van egy rakás szent, angyal, ördög, satöbbi, teljesen kiakadt tőlem a tanár.
Azt mondják az egész csak idő-management kérdése. Ezt én nem értem, megfelelő idő-managementtel ki lehet bővíteni még 8 órával a napot?
Ez a dolog a red hat-nél valószinűleg azért van, mert a java programozónak is egész jelentős bash és linux teszten kell keresztülmenni felvételikor, ellenben szerintem a vizsgáztatók elég keveset tudnak kérdezni java témakörben. A legtöbben tehát a bash rémes szintaxisán és a python követhetetlen csomagrendszerén véreznek el, nem pedig a JPAQL részletkérdésein.

Elhiszem, hogy tűrhető python programozó lesz valaki, míg java programozásban igazán jó, de nem lehet valaki Rambó és Batman egyidejűleg. Még ha agymunkával bírná is, nem fér bele a napba.

MongoDB - pár tapasztalat

Mostanában szabadidőmben MongoDB-re írogatok mindenfélét, gondoltam írok egy kicsit alaposabb beszámolót arról hogy milyen marhaságokat csináltam eddig vele. A legutóbbi régen volt és nagyon felületes.

Bosszantó apróságok

Nyugodtan kezdhetjük a rossz hírekkel, nem lesznek nagyon rosszak, inkább csak bosszantó apróságok.

Az egyik ilyen az, hogy 32-bites rendszeren a mongodb behúzza a kéziféket és max 2 GB méretű adatbázist enged. Ez lófüffy, fogalmazzuk talán inkáb úgy, hogy 32-bites rendszereken a mongodb röpképtelen.

A másik apróság, amibe belefutottam még az elején, az az hogy a OpenVZ virtuális gépeken valami okból memóriaszivárgás van a MongoDB szerverben és ettől teljesen használhatatlan. Bevallom nem néztem igazán utánna, de itt került fel az OpenVZ a ganajlistára. Miféle virtualizációs technológia az, amivel egy adott szoftver a vendég operációs rendszerben behal? Gubancos, gondolom.

Sokkal inkáb bosszantó a MongoDB hanyag viselkedése a tárhellyel. Az alapbeállításokkal  folyamatosan logolja az összes adatmódosítást, ami rettenetes méretű logokat eredményez nálam. Kicsit kellett keresgetnem hogy hogyan lehet kikapcsolni.

A másik tárhely-kellemetlenség 3 GB-os journal, amit az adatbázis inicializálásakor létrehoz. Bár a memóriafogyasztása egyébként nagyon frankó lenne, ez a 3 GB journal kicsi adatbázisokhoz nagyjábol diszkvalifikálja. Ki lehet kapcsolni, akkor kicsit visszavesz a sebességből és egy esetleges crash teljesen hazavágja. Akkor most gondolkozzunk el rajta hogy mit szeretnénk inkáb.

Klassz dolgok

Szóval az egyik klassz dolog amit igazán kedvelek a MongoDB-ben, az UPSERT, ami az "insert or update"-re egy rövidítés. Ez pl log feldolgozáskor marha gyors tud lenni és az alkalmazáson is nagyon sokat egyszerűsíthet. Az upsert egyszerűen úgy működik, hogy megmondod a keresőfeltételt és egy dokumentumot. Ha talál a keresőfeltételnek megfelelő dokumentumot, akkor ahhoz hozzávágja az új dokumentumot, tehát azokat a kulcsokat, amik a régiben voltak, azokat felülírja (itt lehet trükközni), ha nincs ilyen kulcs, akkor hozzáteszi a dokumentumhoz. Amennyiben nem talált ilyen dokumentumot, akkor csinál egyet, ami megfelel ennek a keresésnek, azaz benne lesz a keresett kulcs és a bedobott dokumentum.

Nézzük a fent említett okosítást: például nekem hasznos az, hogy egy dokumentumban egy tömbhöz fűzök hozzá értékeket illetve érték párokat. Erre jó a PUSH, amivel a régi doksiban nem írja felül a régi értéket, hanem csak hozzáappendel. Ez upsert esetében is teljesen jól muzsikál.

Az marha sokat segít, hogy nem kell csekkolni, hogy egy dokumentum létezik-e már a feldolgozás során.

A sebesség a másik baró dolog. Eleinte voltak olyan tévhiteim, hogy az adatmennyiséggel egy beágyazott derby is el fog boldogulni. A derby hozta is a formáját az első pár órában, amikor azonban a memória méreténél nagyobbra nött az adatbázis mérete, beleállt a földbe a teljesítménye.

Trükkök

Relációs adatbázishoz szokott barátaim: egy pár dolgot át kell gondoljunk, amikor mongodb országba települünk.

Például relációs adatbázisokban nagyjából magánügy, hogy hogy nevezed a tábláidat és az oszlopokat, a teljesítményre aligha van hatással, mert nem kerül bele minden rekordba, legfeljebb amikor lekérdezést küldünk az adatbáziszervernek akkor kicsit több byte-ot küldünk. Nem nagy ár, ezért inkáb érthetőre próbáljuk faragni a relációs sémát szép oszlopnevekkel. A különbség egy dokumentum-alapú, séma-nélküli adatbázisnál az, hogy minden dokumentumban benne vannak a kulcs-nevek, így a rövidebbet jobb sebességgel jutalmazza az adatbázis szerver.
Én pofátlanul mindent egy-két betűsre rövidítettem. Ezt a dolgot ha valaki átvenné tőlem, nagyon gyűlölne.

Ezzel kapcsolatban jut eszembe az _id kérdése. A mongoDB minden dokumentumba beletesz egy _id nek nevezett, 12-byte hosszú azonosítót, amiben a szerver azonosítója, egy random szám, valami sorszám, a heti lottó nyerőszámok és ilyesmi tlálható. Az én alkalmazásomhoz nem volt igazán hasznos, de egy databig nem jöttem rá erre:
A dokumentumodnak amúgy is kell valami, ami amolyan elsődleges kulcs. Egyszerűen ezt a dolgot hívd _id-nak. Még akkor is, ha az "id", az "azon", és a "customerid" elsőre jobban tetszik. Az _id ugyanis nem kell, hogy a fenti szám legyen. Lehet szöveg, szám, akármi. Értelmesnek tűnik saját ID-t csinálni.

Emellett persze az _id az a dolog, ami mindig indexelve van, nem is kell kérni és nem is lehet kikapcsolni.

Indexek: meg tudom erősíteni, hogy amit nem indexelsz, arra a lekérdezés egészen lassú lesz. Ezt gondolom gondoltad :) Az indexek viszont rendesen meglendítik a memóriahasználatot, szóval okosan azzal az indexel.

Még egy trükk, amiért lehet hogy máglyára küldenétek. Olyanra is volt szükségem, hogy egy dátumokhoz számértékeket rendeljek. Eleinte így csináltam:
[{k: Date(), v: 1}, {k: Date(), v: 3}, {k: Date(), v: 4}]

Ez kicsit terjengős dolog, úgyhogy azt találtam ki, hogy a dátumot szöveggé alakítom, mégpedig egy nagyon tömör szöveggé (amire összeütöttem egy 75 vagy 76 digitből álló számrendszert, az még könnyen olvasható) és az így adott dátumokhoz simán csak a számot rendelem. Ilyen lett:

[{"8V3": 1}, {"8V4": 3}, {"8V5": 4}]

Ennél én sajnos nem tudok tovább egyszerűsíteni, de ha egy dátum csak egyszer fordulhat elő, akkor csinálhatnám így is:

{"8V3": 1, "8V4": 3, "8V5": 4}

Ez ocsmány trükknek tűnhet, de nagyon sokat segített az adatbázis  méretének redukálásában. Illetve vehetek nagyobb gépet is persze. Vagy kérhetek karácsonyra.

DAO kérdések

No utolsó beteg design patternem következik így vasárnap este...

Relációs adatbázisoknál a resultset-eket tipikusan egy listává alakították át a DAO-k, ehhez az egész resultsetet elösször végigolvasták és objektumokká formálták. Na ez nagy adathalmazokhoz soha nem volt jó ötlet, de olyan ritkán kellett ilyesmit csinálni. És most mintha mást se kellene.

Szóval én meg akartam tartani a listát mert olyan egyszerűen lehet vele bánni, viszont eszem ágában sem volta teljes eredményhalmazt berángatni a memóriába. Szóval a megoldás egy olyan lista lett, ami Closable is. Így viszont a DAO metódosukat hívó kódnak be kell zárnia a listát. Ez a része szokatlan és kicsit bizonytalan vagyok a kérdésben. A problémát azért megoldotta.


Kotlin nyelven azért egészen egyszerű a dolog a (szerényen dokumentált) use funkció segítségével.

dao.getBlaList().use { it.each{ ... } }



Ezt nyugodtan fikázzátok le, nem garantálom hogy átírom de garntáltan érdekel a véleményetek! No ennyi mára, boldog hétfőt!

Tartozom még egy beszámolóval a linux konferenciáról, nem éppen java de volt java is.

Google Compute Engine árak

A Google Compute Engine-n ha csinálsz egy 1 TB-os merevlemezt, akkor az a mai árazás szerint az havi 102 USD-be fog kerülni. 102 USD az ma 23.000 forint vagy úgy 2.000 korona. Ebben még nincs benne az ÁFA - ami Magyarországon a legkevésbé sem elhanyagolható tényező.
Ezért az árért a sarki hardver boltban alkudozás nélkül kapsz egy 1 TB-os merevlemezt 2 év garanciával, ebben már benne van az ÁFA is.

A GCE minden I/O műveletet kiszámláz. A bevásárolt merevlemez ilyet nem csinál, viszont áramot zabál.

Sebesség: Egy GCE gépemen kipróbátam egy dd paranccsal felszívni egy 20 GB-os lemez tartalmát a /dev/null-ba. Elsőre 90 MB/sec sebesség jött ki, de aztán egy másik diskről próbáltam ugyanezt és azzal csak 30 MB/sec jött. Az írási sebességben voltak hasonló eltérések, de az persze egy kategóriával lassabb volt. A Compute Engine SLA egy szóval nem említi, hogy mennyivel kellene jönnie. Bízzuk a szerencsére.
Ugyanez egy sima merevlemeznél mondjuk elég egyszerű, egy sima bolti SATA vincsitől számíthatsz 100 MB/sec sustained read, és úgy 80-90 MB/sec sustained write sebességre.

Ha már GCE SLA: Jól értem hogy 5% unplanned downtime esetén visszakapom az ár felét? Több mint egy nap havonta és csak a fele? Ez nem hangzik jól, annyinál már az egészet hagynám a fenébe. És havi fél óra downtime belefér? Nem tűnik úgy, hogy nagy megbízhatóság lett az árba belekalkulálva.

A GCE csak egy példa. Sokkal olcsóbban is lehet virtuális szervert szerezni a sufni webappjainknak, de szerintem még sokat kell hogy alakuljon a publikus felhők árazása.

code review (anti)patterns

Egyik nap néhány munkatársammal beszélgettünk arról, hogy hogyan haladunk és egyetértettünk abban, hogy ahogyan a code review történik, az nem csak hogy nem segít a minőség javításában, de néha teljesen hülye hibákoz is vezet. Én a hiba okát abban látom, hogy a reviewer soha nem tesztel. Túl sok dolga van. A reviewer minnél hamarabb túl akar lenni az egészen, ezért megkeresi az első hibát, lefikázza és otthagy. Ez általában a commit comment, amit átírsz és majd a későbbi patchek során hetekkel később kiderül hogy mégse volt az olyan rossz.
Mindenesetre a patch írói az első verziót szokták tisztességesen letesztelni. A második verziót talán. Mindegy, X idő és Y review után már a tökük televan ezzel a patch-el, szánják-bánják hogy hozzákezdtek és a végül elfogadott patch-en könnyen lehet hogy a kutya se futtatott teszteket, ha ugyan vannak még benne. A manuális tesztekről inkáb ne is beszéljünk :) Az nyilvánvalóan csak az első pár patch-nél történt és a véglegesnél nagy valószinűséggel nem. Gyakran van az, hogy a végleges verziót már marhaságnak tartom, de mindegy, csak menjen már.
(Szakirodalom: Boris Vian: Venyigeszú és a plankton)

Szóval erre halmoztunk fel pár zavaró megoldást amit felváltva és kombinálva használunk. Ezek nagyban növelik a káoszt, de kicsit javítják a teljesítményt, minket persze az utóbbi érdekel.

1. Küldj patchet akkor, amikor a csapat meetingen van. Tréfi, de ez van. Szükséged van valakire nyilván aki elfogadja neked gyorsan, de a legjobb ha nem adsz időt a trolloknak, meg a hatszáz rebaselést is elkerülöd.
2. Spameld a reviewereidet.
   
   A legegyszerűbb kommentbe írogatni hogy "ping". Rossz esetben blokkolva leszel, ekkor változtass e-mail címet. (gúgliban a gipsz.jakab+1@gmail.com pl műxik) Naponta vagy másnaponta egy email nekem elegendő középútnak tűnik egy kultúrált úriember és egy nigériai tábornok között, de persze volt már aki teljesen kiakadt és sikítozni kezdett. Nem lettem érte lecseszve, a CÉG majomként kezeli a szoftverfejlesztőket. Ez szerintem sem áll távol a valóságtól.
3. Ha csinálsz junit teszteket, soha ne pakold ugyanabba a patchbe, mint amibe a kódot. A patch-sor végén elég lesz. Ha eljutsz odáig, akkor bekerül, ha nem akkor meg nem tart fel. De tipikusan egy olyan tényező, ami csak feltart. Az egyik oka annak, hogy nem igazán vannak junit tesztjeink az az, hogy mindig az kerül utoljára hogy legalább valamennyire haladjunk.
4. Racionalizáj: dobd ki a reviewereket egy adott létszám felett! Az inkatívakat mindenképpen, mert rájuk csak várnak. Az akadékoskodókat csak ha lehet.
   
   Próbáld ki, írj egy közös akármit (levelet a nagymamának, főnöködnek, a köztársasági elnöknek vagy a halál pöcsének) úgy hogy 8 embernek egyet kell értenie minden szavával és senki nem akar még hozzátenni valamit. Amit valaki hozzá akar tenni, azt más majd el akarja venni. 8 ember nem tud egyetérteni valamiben. (Szakirodalom: 12 dühös ember)
5. Újra ugyanazt
   
   Teljesen működő megoldás mégegyszer más címen vagy akár csak más ID-val elküldeni ugyanazt mégegyszer és esetleg valaki mást kérni review-re. Lebukás-veszély persze van, de szerencsére úgyse tudják megjegyezni a nevemet.
6. Szép dolog maintainernek lenni, de haszontalan
   
   Ez megint egy érdekes csavar a történeten, de egy rémegyszerű dolgot nem sikerült sehogy sem átverekednem a többi maintaineren, senki sem merte bevállalni. Egy idő után eldobtam a patch-et, úgy gondoltam elég időt pazaroltam rá. Pár hónappal később egy új kolléga küldte el tejesen ugyanazt a változtatást. Csak leellenőriztem és be is lett mergelve.
7. Dobd ki az ablakon.
   
   Ezt sajnos gyakran csinálom, de ha 2-3 hétig a noszogatás ellenére se csinál senki semmit, akkor kidobom a patchet. Ez a legtöbb reviewernek nem probléma. Néhányan szoktak csak felháborodni hogy "de hát jó volt". Lehet hogy jó volt, de sehova se haladtunk vele. Rémesen sok időt elvesztegettünk rá és végül sehova se jutottunk, de még mennyi időt elvesztegethettünk volna arra, hogy sehova se jutunk a végén? Egy újraírás talán csak 5 perc. Teszttel együtt egy óra :D De ez semmi ahhoz képest hogy mennyi baszakodás lesz vele.

Szóval a rendszer elég egyszerű lenne, de valahogyan mindig kisebb-nagyobb csalásokra kényszerül az ember. Nem egzakt tudomány, inkáb számvitel és politikatudomány mint matek és fizika. Valami ilyen lehet földhivatalban dolgozni.

Tudom kurvára utáltok amiért képtelen vagyok a marketinglófaszt elénekelni nektek, de gondoltam ez valamivel hasznosabb lehet :)

Atom / RSS feed test tool

Van a w3c feed validátor, ami király, de a leghétköznapibb RSS feedre is azt mondja, hogy törött. Sajnos igaza van, de nem állhatunk meg tökölni amikor kiderül hogy az internet fele sz*r, hanem megtanuljuk szépen tolerálni a hülyeséget. Másrészt a technikai minőségéről semmit nem mond, csak a formátumáról.


Szóval csináltam egy saját feed test eszközt, amivel a legutóbbi teszt szintén elég szomorú (de legalább szines) eredményeit hoztam ki. Tessék ehun van e. A kis edit boxba kell bedobni az RSS/Atom feed-ed címét és kidobja az eredményt. Nem túl felhasználóbarát felület. Ha gondolod próbáld ki a saját feed-jeiden és szólj vissza ha valamivel nem értessz egyet!

Crowdsourcing antipatterns

Pár tapasztalatomat szeretném megosztani meló és hobbi területéről. Nem szeretném arra pazarolni a figyelmeteket, hogy N-edik alkalommal lebasszam a gerritet, hanem kicsit általánosabban, ugyanakkor nem tudok ellenálni neki hogy bele ne rúgjak ha éppen arra tévedek, pedig nem a gerrit a hibás.

Azt hiszem az utóbbi néhány évben a crowdsourcing dolgot úgy tárgyaltuk, mint az atomenergiát, ami kimeríthetetlen és végtelen, mindent megold, kb ingyen van és pofonegyszerű. Ilyen kellemes bullshit szag lengte körbe mindig ezt a témát, de sajnos nem ilyen egyszerű. Ugyanis az hogy bárki közreműködhet, nem jelenti azt hogy tényleg lesz akár 1 ember is. Kezdjük mondjuk azzal a problémával, ami nekem az egyik legszomorúbb.

Wikipédia

Nagyjából 6 éve írok a magyar wikipédián cikkeket. A kezdeti visszajelzések, amiket a szerkesztőktől kaptam totálisan demotiválók voltak. Kifogások formai dolgokban, személyeskedés, fikázás. viszont alig volt, aki valami használhatót mondott, kiegészített, vagy kijavított volna.
A magyar wikipédia ráadásul eléggé túlpolitizált légkörben ázik, emberek egyszerűen politikai meggyőződésből cseszegetik egymást. Ez egyrészt a legkevésbé sem vonzó, másrészt pedig oda vezetett, hogy a vandalizmus visszaszorítására korlátozásokat vezettek be: minden cikket egy adminnak kell ellenőriznie. Ez a demotiváció a köbön, mert nagyon hosszú ideig nem néz rá senki a cikkedre, ugyanis admin csak nagyon kevés van. Így lehet az, hogy bár Tvik kb 2 hete kijavított egy tucat hibámat egy cikkben, jónéhány szerkesztés után még mindig a régi verzió az elfogadott.

A megoldás elvileg az, hogy megbízható szerkesztő jogosultságot kell szerezned. Kérvényezel, szavaznak és előfordul, hogy elutasítanak. És akik ezt teszik, azoknak szerintem gyakran fingjuk nincs, hogy milyen hibát követnek el. Mindenesetre a magyar wikipédia mottójának ezt adnám ma: "Zárt körű rendezvény"
Megszabadultunk a trolloktól, de a szerkesztők nagy részétől is is. Így lehetséges az, hogy amikor írok egy cikket, a robotokat leszámítva néha évekig senki nem nyúl hozzá. Kényelmesebb, mint amikor ezer troll volt, de teljesen kihalt. Hálóval kell fogni a szerkesztőket, miközben lenne azért hova haladni, ha például az informatikai részt nézzük.

Egy kicsit visszatérnék ahhoz, hogy ezt a sok embert végülis csak így egyedül hagyták az internet kies pusztáján, és egyébb híjján egymást verik agyon. Szóval ezt a wikimédiás srácok is észlelték és valamit biztosan tanultak a szociális hálókból, ötletelésük eredménye egy kicsi piros sziv ikon mögé rejtett lehetőség lett, amely arra hivatott, hogy egymásnak elismerésünket kifejezzük. Ez szerintem nagyon nem talált, ugyanis az ember soha nem kattint egy kicsi piros szívre, ha egy idegenről van szó. A barátnőmmel ketten kisérleteztük ki, hogy ez mit csinál. Mögötte valójában úgynevezett barnstar-ok vannak, ilyeneket küldözgethetsz.
Talán egyedül vagyok a barnstar-ok osztogatásában a magyar wikipédián. Régi, nagyon aktív szerkesztő is írt olyat, hogy még ilyet nem kapott.

Gerrit vs Review Board

Jó akkor gerrit, de nem a technikai részleteit szeretném kritizálni. Söt, meg fogom dicsérni. Legyen az. Tavaly ősszel voltam egy konferencián, ahol teljesen véletlenül belefutottam az Apache CloudStack kis standjába. Konkurens cég által szponzorált konkurens termék, de elötte nem hallottam róla. Jó fejek voltak, mutattak valami demót, baromira tetszett, érdekelt az egész, leszedtem hát a forráskódot. Hazafelé a repülőn játszottam vele, mire hazaértem 4 apróbb javítást csinltam. Hát mi legyen, elküldtem nekik. Ez volt első találkozásom a review board nevű gönccel, azóta tudom becsülni a gerritet, mert tudom hogy van nála sokkal nehézkesebb felület.

De a review board-ot leszámítva, a csákók a következő néhány napban megnézték a változtatásaimat és elfogadták. Nem kellett keresgetni embert, hogy legyen már szives. Nem mondták, hogy rebaseljek. Nem mondták, hogy írjam át a commit commentet. Egyszerűen csak küldtek egy levelet hogy "köszi". A CloudStack-es élmény után alig várom hogy legyen egyszer elég időm és vissza tudjak térni hozzá.

A saját házunk tája... nekem mindig volt egy olyan érzésem, hogy szívatjuk azt a szegény contributorokat. Keress valakit, aki megnézi a változtatásaidat... Gyakran hetekbe tellik mire embert találok rá. A legtöbb reviewer (szerintem lustaságból) teljesen az első hibánál leáll, ez rendszerint a commit comment. Egy tipikus feature általában 10-20 különböző verzió után kerül be. Ez nem a gerrit hibája. Ez a mi csapatunk hibája, de évek alatt sem sikerült változtatni a szituáción.

Szóval az apacsék gagyibb technológiával dolgoznak, de jobban használják.

Szóval...

Ezt a dolgot régen, gimi alatt a Megdonácban tanultam. Tanulhat az ember valami hasznos dolgot sepregetés közben is :) Szóval megdonácban amikor a legidiótább legmechanikusabb munkát az ember megcsinálta és jelentkezik a managerénél, akkor a manager megnézi pl a padlót és azt mondja: "Nagyon szépen feltakarítottad az éttermet, köszi" és következő feladat... de úgy látsz hozzá hogy nem csak a fizetésedet kapod, hanem egy köszit is. Ezt éles különbségnek tartottam a magyar munkaadókkal szemben. Diákként dolgoztam jónéhány helyen Budapesten, a tipikus hazai munkaadótól jó ha a pénzt megkapta az ember, nem hogy még valami elismerést vagy biztatást, pedig egy fillérbe se került volna.

A másik, hogy ha az ember szabadidejéből szán rá időt, hogy valami közhasznút csináljon, akkor igazán nem jó ötlet sok bürökrácia elé állítani. Erre a fenti két példa is jó, de most dolgozok egy zanata nevű fordító rendszerrel, na az talán a legjobb példa értelmetlen bürokráciára. A szükséges bürokráciát rövidítsd le és rejtsd el a lehető legjobban! Egy usablity expert minden webes fejlesztésbe kellene szerintem, de ha nincs legalább amatőr szinten foglalkozni kell vele.

Harmadik dolog: nagyon fontos, hogy könnyen lehessen elkezdeni. Például a wikipédia szerkesztőfelülete annak olyan, hogy pár év alatt megszokod és akkor jó :) Új szerkesztők borzasztó nehezen boldogulnak vele.

Aztán még egy negyedik és utolsó anti-pattern: a rangok és hierarchiák. Példul ismerek egy csákót, aki god-mode-ban üzemel, senkitől nem fogad el kritikát és megállíthatatlan, ezzel semmi baj, de gyorsabban termeli a bugokat mint ahogy ki tudnánk javítani. Ilyenkor kicsit reménytelennek tartom a helyzetet. Hasonlóan tud viselkedni a wikipédia szerkesztői hierarchia is, azt leszámítva hogy az elvileg demokratikus. De akárhogy is, szerintem a hierarchia nem vonzó.
Ennyi a lényeg: Szabad idejében ki a franc akar közlegényként slozit pucolni fogkefével a kínai néphadseregben? Ki akar inkáb gerillaként harcolni egy jó célért? :)

Posztnukleáris RSS tájkép

A weboldalak nagy része ad valamilyen RSS/Atom feed-et. Az RSS és az Atom két meseszép példa arra, hogy open standard, csillió teljesen különböző implementációval. Szóval pár dologot gondoltam mesélnék a feed-ek technológiai minőségéről.

Poll

A poll az a dolog, amit szinte mindig utálok, de van egy elvi előnye: elég egyszerű két szereplős játék. A hátránya szintén közismert: fölösleges forgalom. Ezeket a hátrányokat egész tűrhető szintre lehet hozni pár nagyon egyszerű aprósággal:

• Szabványos HTTP cache mehanizmus: ETag és Last-Modified headerek
• Tömörítés használata 

A gyakorlatban gyakori problémák velük kapcsolatban:

• Meglepő módon bár a weboldalak nagy része küldd HTTP cache headereket, a kérdésnl teljesen figyelmen kívül hagyja. Vajon minek küld ETag headert valaki ha utánna figyelmen kivül hagyja a hozzá tartozó If-None-Matched headert?
• Számomra szintén meglepó, de a tömörítést szinte minden rendszer hanyagolja. Tipikusan ezek a hírcsatornák nem updatelődnek nagyon gyakran, például az index RSS 3-5 percenként. Egy csomó forgalmat megtakarítanának vele, ha az ezt elfogadó klienseknek tömörítve küldenék el. A tömörített verzió pedig be lehetne cachelni, nem egy nagy meló. Amikor új tartalom, akkor vagy flush cache, vagy felfrissíthetjük akármi.

Még a pollozáshoz tartozik, de pár formátum-kérdés is igazán bonyolult a gyakorlatban:

• Gyakran fut bele az ember olyan rss-ekbe, amiknek nincs pl GUID-ja. Persze ez opcionális az RSS-ben.
• Vannak sokkal viccesebb srácok, akik például minden alkalommal más publikációs dátumot ragasztanak rá a kiexportált híreikre, tipikusan a rendszeridőt

Pubsubhubbub

Pubsubhubbub-ot csak nagyon kevés rendszer támogat, nyilván a felkapottabbak, akik adtak a tuningra és próbálnak gyorsabban a felhasználóikhoz eljutni a friss tartalommal. Magyar híroldalak közül ilyet nem is találtam, a pár nagyobb ismert rendszer a blogger, a wordpress.

Pár példa

Szóval gondoltam akkor nézzük meg a pár példát a hétköznapi közismert hírforrások közül, amit ezrek, vagy milliók olvasnak.

Egy kis gyüjtemény

Azt hiszem itt mindenfélére talál az ember példát. A wordpress-t még jobban szeressük, mint eddig :-)

OFF ötlet

Gondoltam összeírnám, hogy mivel rúghatná tökön felhasználóit a google, de aztán mégsem... Kétségtelenül lekapcsolhatnak ezt is azt is, meg le is fognak, de a leghatékonyabb terheléscsökkentést szerintem azzal lehetne elérni, ha googlplus regisztrációhoz kötnék a gmail használatát. Akkor indulna csak meg a fejvesztett menekülés :)

Gyárlátogatás: az adatbázis

Rég voltunk gyárlátogatáson, gondoltam ismét belerúgok a műfajba, ezúttal az adatbázisok és használatuk területéről írok pár személyes élményemet. Mint mindig, nem arról lesz szó, hogy hogyan kellene, hanem arról, hogy mit csinálnak a szakik a gyárban.

Fellegvár

97 Dolog, amit minden Architektnek tudnia köllene (és mégse tudják), 23. bejegyzés: Legyen erőd az adatbázisod!
Ezt a sírjára vésném azoknak, akik nem tartják be :-) Az adatbázist nem bíznám az izgága programozókra. A DBA egy külön szakma, más mentalítást és más egyéniséget igényel, mint a szoftverfejlesztés. A legjobb tapasztalatom adatbázisokkal annál a munkahelyemnél volt, ahol külön DBA csapat volt. Ezek a csákók vágták az adatbázis minden paraméterét és rendesen lecsesztek mindenkit, akinek az alkalmazása nagy mennyiségű hülyeséget csinált. Persze nem klassz, amikor az embert lecseszik, de néha hasznos.

Az profi üzemeltető csapatból következik még egy dolog: nem akarnak sokféle adatbázis szervert üzemeltetni. Ha elöjössz azzal, hogy neked KakukkSQL kellene, mert a hétvégén kipróbáltad és most az a kedvenced, őseid legkevésbé sem magasztaló kontextusban kerülnek megemlegetésre.
Többnyire 1 cég 1 adatbázishoz ragaszkodik, de legalább abból az egyből elég jó szolgáltatást kapsz.

Ha így nézed a dolgot, marha fontos, hogy az alkalmazásod több adatbázissal is jól szaladjon, amennyiben nem csak 1 ügyfélnek akarod eladni, illetve nagy ügyfeleket is szeretnél célozgatni, akik nem akarnak holmi közös felhőben lakni. Oké, talán ez egyre kevésbé tényező...

Szamócából fellegvár

Egy régi főnökömtől származik a mondás, ami mindig eszembe jut, amikor egy adatbázist rendesen tökön rúg egy alkalmazás:
"Ne aggódj, az Oracle végtelenül skálázható." Én meg kérdeztem mint egy hülyegyerek hogy "Tééélleg? És mennyiért?"

Ezt általában el lehet mondani, hogy kevés elképzelése volt az embereknek eleinte arról, hogy mennyit bír egy adatbázis szerver és a hardver mérettel ez hogyan változik, illetve az adatbázis mérete hogyan befolyásolja a teljesítményt. A fenti dologgal ma már nem hiszem, hogy bárki előjönne, de nekem úgy tűnik továbbra is kevesen tudnak arról bármit is, hogy az adatbázisuk miből mennyit bír. Konkrétan számszerűen, mert az akármennyi az nyilván baromság.

Indexelés és optimizálás

Sajnos nagyon kevés java fejlesztő néz bele akármikor is, hogy a lekérdezései mit is csinálnak konkrétan, pedig minden adatbázisban van valami query debugger funkció, többnyire explain-nek hívják. Ez azért lenne fontos, mert az adatbázis a munka nagy részét elvégzi, amit a hétköznapi ügyviteli rendszereink csinálnak, az valójában csak minimális feldolgozás rajta. Ha kicsit jobban bánunk az adatbázissal, az valószinűleg kategóriákkal többet fog javítani az alkalmazás teljesítményén, mintha felűberelnél a JLophas AS legeslegújabb verziójára, vagy mint ha a teljes alkalmazásban levadásznád a hülye "ez" += "az" konkatenációkat, a temp objektumokat, satöbbi. Sajnos ez van.

 

JPA&Co

Sajnos a perzisztencia frameworkok csak tovább növelik ezt a távolságot a fejlesztők és az adatbázis között. Annyi azért viszont biztos, hogy a JPA implementációk nem generálnak olyan idióta lekérdezéseket, mint egyes alkalmazások JPA nélkül. Most inkáb kihagynám a példát :-D de biztosan találsz a házad táján.

Kétségtelenül nagy előnye a portolhatósága és a gyors fejlesztés, de néhány dolgot néha optimalizálni kell, különben agyonveri az alkalmazásodat. Erre javasolnék egy patternt: csinálj egy általános JPA DAO-t, ebből származtass le szükség esetén DB-specifikus implementációkat és bíráld felül (gyakorlom a magyar nyelvet, az override-ra gondoltam) azokat a lekérdezéseket futtató metódusokat, amiket optimalizálni akarsz. A DAO-kat egy factory-val gyártsd le, ami az adatbázis típusától függően ad vissza egy implementációt.

Mégegy dolog: az automatikus séma generálás nem jó, mert az említett "erődítmény" tétellel ellentétes. Prototypinghoz természetesen kiválló, de az adatbázis adminisztrátorod megöl érte. Talán érdemes írni egy listát, hogy mit kell tenni amikor már komolyan gondolod az alkalmazás fejlesztését, és mondjuk így kezdeni: automatikus séma generálás kikapcs.

 

Cache vagy MQ

Egy gyakori probléma, amivel találkoztam, hogy az adatbázist cache-ként vagy üzenetek küldésére használták. Ennek az oka valahol az egyéb infrastruktúra hiánya és az ismeretek hiánya között volt általában, kicsit mindkettő.
Talán ida tartozik, hogy a Quartz is használ relációs adatbázist Job storeként és elosztott lockoláshoz. Határeset...
Mondjuk a Quartz-ról ma hajlamos vagyok azt gondolni, hogy antipatternek gyüjteménye.

 

Tárolt eljárások

Ez egy rettenetesen vitás téma az adatbázis adminisztátorok és a fejlesztők között. Több DBA-val találkoztam, akik megkövetelték vagy elvárták a tárolt eljárások használatát.
A java fronton ellenben a tárolt eljárásoknak nem igazán népszerűek. Illetve igazán nem népszerűek. Ennek több oka is lehet: elösször is egyetlen egy tárolt eljárás nyelv sem portolható. A java tárolt eljárások inkáb az előző évtized közepe tájám volt egy próbálkozás, csak a DB2 és az Oracle támogatta, PostgreSQL-re ketten írtunk rá támogatást, de őszintén egyikünk sem lett nagyon népszerű vele, évek óta leálltunk a fejlesztéssel.
Portolhatóság szempontjából a tárolt eljárás inkább akadály, mint segítség, a legtöbb persistence framework nem tud velük mit kezdeni.
A népszerűtlenség nagyobbik oka viszont nem a portolhatóság hiánya, hanem egyszerűen az, hogy a tárolt eljárásoknak az esetek nagy részében egyszerűen nincsen semmi előnyük, de nehezeben áttekinthetővé teszik a rendszert. Példának sajnos az oVirt-et fel tudom hozni, a legegyszerűbb lekérdezést is bele kell csomagolnunk egy tárolt eljárásba.

Igazából én egy csomó lehetőséget látnék tárolt eljárásoknak olyan téren, mint az interakciók számának csökkentése az adatbázis és az alkalmazás között. Pl insertOrUpdate, insertAndReturnId. Ilyesmi használatát nem emlékszem hogy láttam volna valakitől.

Tranzakciók

A tranzakciókkal is láttam pár buherát. Egyes rendszerek (pl ovirt is sajnos) egyenesen problémaként élik át a tranzakciók létét és bonyolult, bizonytalan kimenetű dolgokat csinál a kicselezésére.
A kedvenc trükk, amit láttam, mégis az volt, hogy az app egy bizonyos lekérdezésre nyitva hagyta a tranzakciót és a kapcsolatot, meg egy ResultSet-et is, és a következő http requestre tolta ki az eredményt html-be. Néha, amikor a második http request mégsem ütött be, akkor kicsit elakadtak a dolgok. Erre adta a rendszergazda azt a diagnózist, hogy "A program egyébként jó, de a tomcat egy rakás sz.., naponta újra kell indítani"
Ezek a trükközések elég hajmeresztőek, de nem ritkák.

A NoSQL forradalom

Nincs antipattern tapasztalatom a NoSQL adatbázisokkal, mert sajnos munkában még soha nem használtam őket, de alig várom. Talán oda jutott a dolog a tradícionális RDBMS modellel, hogy néhány dolgot, például a tranzakciókat (lásd fent) egyáltalán nem találunk hasznosnak egy olyan alkalmazásban, mint egy chat, alkalmazás logok, vagy szociális háló. Egy évtized kellett hozzá, hogy az internet ipar saját ötlettel áljon elő és elrugaszkodjon az inkáb a pénzintézetek igényeihez igazodott modelltől. Jelenleg annyi NoSQL adatbázis van, hogy nem tudom felsorolni őket és nem tudok mindegyikkel lépést tartani. Azt hiszem még évekbe fog telleni, amig letisztul a terep, pár kellemetlen élmény keletkezik elötte. Például a mongodb-ről hallottam pár forrásból, hogy végül felhagytak vele. Én még mindig hajtom, persze nem atomreaktort vezérlek vele. Egyébként nem hiszem hogy a mongo végül a kiesők között lenne, de pár másik ott lesz.

pubsub humbug

A Google pubsubhubbub szolgáltatásához 2011 óta senki sem nyúlt, látszólag megint egy frontvonal, amiről a google visszavonta a harcoló alakulatait. Ez viszont nem jelenti azt, hogy nincs semmi változás a szolgáltatásban. Ez talán bug volt, de olyan RSS csatornára is fel lehetett íratkozni, ami egyébként nem küldött a pubsubhubbub-nak értesítést, azaz nem publikált megfelelően. Ebben az esetben a pubsubhubbub csak pollozta. Ez egy nagyon kellemes kis bug volt, mert nem kellett pollozni az RSS csatornát, elég volt, hogy a google pollozza, és tovább küldte. Nos február elejétől kezdve nem küldi tovább.

Egyébként a pububsubbub tipikus félbehagyott forradalom, a legtöbb RSS csatorna egyszerűen még mindig a gúgli pubsubhubbub szerverét használja, a wordpress az egyetlen legnagyobb kivétel, ők szép sajátot csináltak és működtetnek.

Lásd még:

• előző bejegyzésem a pubsubhubbub protokolról.
• egy mérésem a pubsubhubbub hubok használatáról

6

Teljesen OFF, csak eszembe jutott, hogy 6 éve kezdtem írni ezt a blogot. Köszi mindenkinenkinek a kommentjeit!


6 év alatt marha sok minden változott. Közben írogatok néha a Dummy Warhead-re, valamint idén (igérem) el fogok kezdeni egy az Example Driven Development-be is írogatni.

Emellett akad időm néha a magyar wikipédia cikkeiben javítgatni. Sajnos bőven van mit, szóval ha van egy kis időtök fussátok át, küldjetek pár megjegyzést vagy akár írjatok bele a cikkekbe, ne legyen a cloud computing téma ilyen rettenetes állapotban!