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.

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.

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 :-)


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 :)