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.
2013. május 17., péntek
2013. április 19., péntek
code review (anit)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.
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 :)
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.
- 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.
- 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. - 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.
- 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) - Ú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. - 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. - 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 :)
2013. április 1., hétfő
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!
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!
2013. március 22., péntek
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.
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.
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.
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? :)
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? :)
2013. március 18., hétfő
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.
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:
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.
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.
Azt hiszem itt mindenfélére talál az ember példát. A wordpress-t még jobban szeressük, mint eddig :-)
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
- 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.
- 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 |
2013. március 16., szombat
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 :)
2013. február 27., szerda
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.
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ő...
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.
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.
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.
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.
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.
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.
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.
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.
Feliratkozás:
Bejegyzések (Atom)