[szerintem nem] elszállt ötletek: a VM scheduler

Szóval arra gondoltam az óév pár utolsó napján felrázlak titeket pár ötletemmel, talán pár hasznos dolog is kisül belőle. Kicsit többre gondoltam eredetileg, mint amennyi összejött, de egy hétig otthon voltam, mászkáltam erre-arra.
A legutóbbi ötlet végén utaltam egy megintcsak meló-kategóriás ötletemre az oVirt-tel kapcsolatban: szeretném kicsit okosabbá fejleszteni az oVirt VM-schedulerét. Valamennyire megvan rá a jóváhagyás is és erről a témáról beszéltem idén Barcelonában a Linux confba beágyazott oVirt workshopon.

Mi az a VM-scheduler?

A scheduler az a dolog, ami a vason kiosztja a vason, hogy mi és hol fusson. Egy ilyen nyilván minden operációs rendszer kerneljében fut nagyon frekventáltan, hogy eldöntse hogy melyik processznek adjuk oda egy kicsi időre a CPU-t. Ezek az algoritmusok egészen bonyolultak is tudnak lenni (pl gondolj csak a NUMA architektúrára) ahhoz képest, hogy nagyon gyorsan kell futniuk, tudományos cikkeket írnak róluk, satöbbi-satöbbi. Szerencsére van rá az ember, mert én ezzel nagyon nem akarnék foglalkozni.
A VM scheduler egy kicsit más kategória:

• a feladata a virtuális gép számára egy fizikai szerver kijelölése
• plusz esetenként (kellemetlen esetenként) migrációk ütemezése
• ritkábban fut: minden alkalommal, amikor Vm indul, illetve ha egy szerver terhelése túl nagy
• több erőforrás áll rendelkezésre
• viszont a teljes szerverfarm teljesítménye nagyban függ a döntés minőségétől
• a cefet-nagy sebességgel szemben én többre értékelném a skálázhatóságot és az értelmes eredményeket, persze a sebesség is szép

Mit tud ma az oVirt schedulere:  erről már írtam egy nagyon bosszús pillanatban, ugyanakkor amit írtam fentartom: a scheduler lassú, a kód zavaros és a döntései néha egészen hülyék.

Szóval mi történik ezen a fronton: egy ideje semmi, mert más (tökunalmas marhaság) feladaton kellett dolgoznom, de egyébként elkezdtem írni egy specifikációt és egy patch-et, ami a drools plannert használja fel optimalizációra. Ebből osztanék meg veletek pár alapötletet:

• A drools planner úgy dolgozik, hogy egy bizonyos felálláshoz kiszámítja a pontokat, aztán keresőalgoritmussal nekilát jobb felállást keresni. Szóval a pontszámítás a lényeges pont. A pontszámításra azt találtam ki, hogy külön kiszámítjuk minden esetleges tervhez:
• a szituáció költségeit: ide tartozik az, hogy mennyire fáj a jelenlegi helyzet, olyanok mint CPU-túlallokáció egy kis bünti, memória túlallokáció egy kicsit nagyobb bünti. A tényleges CPU és memória használat is ide kerül, csak azokra sokkal nagyobb böntit szabunk ki.
• az esetleges migráció költségeit: a migrációnak kell legyen egy alapköltsége, hogy ne dobáljuk idiótán pillanatnyi ötletek alapján a virtuális gépeket egyik gépről a másikra. Ezen kívül egyes erőforrásokat is megadóztatunk a migráció során, például a lefoglalt memóriát teljesen át kell másolni a másik gépre, ami idő persze.
  Itt üthetnek be a hard constraint-ek, pl a cél gépnek egyáltalán nincs annyi memóriája, mint amennyire a VM-nek minimum szüksége van.
• a migráció előnyeit (kompenzáció): miután megadóztattuk rendesen az aktuális helyzetet, és mindent ami esetleg kivezet innen, kell egy dolog, amit a kereső megtalálhat esetleg jobb megoldásként. Itt ilyen dolgokat lehet fdelsorolni, mint pl a CPU-overallocation a migráció után kisebb lesz. Illetve ha nagyobb akkor még arra is büntetést teszünk ki a kompenzáció helyett.

•  A schedulernek bizonyos időn belül válaszolnia kell. Egy cluster áttervezésnél én el tudnék viselni akár 4-5 másodpercet is, de kifejezetten értékelném, ha folyamatosan és inkrementálisan tervezne. A VM startnál kicsit izgágább a kedves felhasználó, általában szeretnék, ha a VM felstartolna vagy legalábbis valami választ kapnának egy másodpercen belül.
• Több VM indításakor rettenetes lenne egyenként végigmenni a VMeken és mindegyikre kiválasztani egy szervert, elindítani. Talán 2-3 VM-mel elmegy, de 50-100 VM-mel idegesítő és lassú. Egy terv kell az összes startolt VM-hez, azok szükségleteinek és a hostok képességeinek megfelelően.

Hát ennyi röviden, szóval remélem az újévben erre lesz majd időm. Lenne utánna pár további ötletem, de olyan lépésben haladunk, hogy az már tényleg scifi kategóriába tartozna.

Hát szóval ennyit erre az évre, remélem tetszett ez a pár évvégi ötlet, esetleg megihlet pár sajátot.

A tömörítéssel kapcsolatos dologba belerúgtam egyet, ha érdekel mérések a dummy warhead-en. (tudátok, a "hibás-de-sebaj" angol blogom)

Akkor legyen ennyi erre az évre :)
Boldog újévet!

elszállt ötletek: cloud storage

Nem ittam semmit esküszöm.

Mese: szóval a melóban az oVirt-tel amikor éppen akadt szabadidőm, a virtuális gépeimen a I/O sebességet teszteltem. Az oVirt támogat egy halom tárolótípust (nagyjából ugyanazt mint a libvirt). Sokmindenen múlik az I/O sebesség a tárhelyen kívül is, például egész sokat lassít rajta amikor thin provission, de hát valamit valamiért :-) Szóval kipróbáltam az NFS-t és az iSCSI tárolókat, mindkettő csalódás volt. Oké az olvasási sebességgel nem volt különösebb probléma, hozta azt a sebességet amit a merevlemezeken és a gigabites etherneten kifért. Az írás viszont botrány volt. Thin provision vagy nem, az NFS pocsék sebességet produkált és semmivel nem tudtam jobb sebességre rávenni. A fanok mondták, hogy a netapp storage-gel az NFS is egész gyors, de nem vagyok csilliárdos és éppen most nincs netapp szerverem. A munkatársak mondták hogy az iSCSI sokkal jobb lesz. Tényleg sokkal volt jobb, kereken kétszer jobb írási sebességet tudott, de ilyen kis számoknál a kétszer nagyobb még mindig kevés. Marhára kezdett érdekelni a GlusterFS, de még nem volt időm foglalkozni vele. A képzési keretemet szivesen beleölném :-) A tesztelő srácok, akiknek viszont van idejük nagyon sokat játszani, azt mondták hogy a glustertől se várjak sokkal többet, mert egyelőre egy disk az egy file, egy file az egy bricken és egy brick az egy szerveren van. Logikus, de demotiváló.
És persze a storage csapatnak se vagyok tagja. Nem is tudom van-e köztük java hegesztőmunkás. (és nem tudom kik azok, bajok vannak a nevekkel)
Szóval a kutatás teljesen befejezetlen, de pár saját pofátlan elvárással előálltam magamnak.

Ezen gondolkodtam: Mondjuk van egy szervered, benne egy sata vinyó, van egy gigabites hálózati kapcsolat, a hálózaton van még pár hasonló szerver. Mennyit lehetne kihozni ebből? Szerintem jobbat ki lehetne hozni, mint 200 MB/sec sustained R/W. A helyi sata vinyó elvisz 100-at, a gigabites etherneten keresztül a többo majdnem 100-at, és kicsit kombinálva a múltkori "talán gzip" dologgal, 200 fölé lehetne lökni, "csak" kombinálni kell az erőforrásokat. Olcsó gépen, egész jó teljesítmény. Szintén marha jól tudná javítani a random R/W sebességet, mert nem csak egy merevlemez fejét rázod, hanem amennyi van. Egy ilyet szeretnék a VM alatt. Éppen úgyis karácsony lesz mindjárt.

A másik fontos dolog: a lehetőleg VM fusson ott, ahol az adatai vannak. Nem érdemes átcipelni máshova azért, hogy aztán majd visszacipeljük. Konkrétan ilyesmiken dolgoztam is, mégpedig munkaidőben. Ki hinné hogy néha értelmes dologra is sor kerül :) Hamar le is álltunk...

Ez publikus cloud-ba nem igazán passzoló elképzelés, egy publikus cloud provider nem érdekelt abban, hogy a SLA-ban leírtaknál jobb teljesítményt adjon ha van rá lehetőség. Egy privát cloud-ban simán mehetne, had villogjanabbak vadabbul a ledek.

Ez a terület egyike azoknak, ami baromira érdekelne, ha találnék rá időt hogy foglalkozzak vele.

Legközelebb valami épkézlábabb dologgal jövök, addig megyek megmászok pár hegyet. Igen, talán a vm scheduler, bár azt a poént az elöbb lőttem le.

elszállt ötletek: peer to peer apps

Mindig jön valami legújabb webes dolog, amire rákattan mindenki. Aztán vagy a birkanyáj szellem, vagy a szakmai érdeklődés odavisz minket is. Egy ilyen szolgáltatáshoz egyre több szerverre van szükség, egyre több embert kell foglalkoztassanak, egyre magasabb hierarchiák alakulnak ki a cégben és ezek kiadásokat generálnak. A kiadásokat pedig bevételekkel kell fedezni. Ez természetes egyébként is hozzá vagyunk szokva, de sajnos ezen a ponton kezd a dolog elkurvulni:

• egyre több reklám jelenik meg (pl iwiw, index, origo)
  Aki kicsit is ért hozzá, az adblockert használ, de ez az összes felhasználó alig néhány százalékát teheti ki. Kérdezz körbe a családodban, a legtöbb ember még nem is hallott róla, hogy böngészőkbe pluginokat lehet rakni. Pedig van egy hegesztőmunkás a családban!
• privacy visszaélések jelennek meg, spamelnek (freemail tipikusan)
• a felhasználói felületen megjelennek a dark pattern-ek (kedvenc példám a go daddy)
• A fizető fél tartalmának előretolása (youtube, facebook, twitter, linkedin)
• Földrajzi régiók kizárása a free domainből (last.fm) vagy egyes tartalomból (youtube)
  Persze szerezhetsz egy proxyt, de a nagyközönségnek ez sem megoldás.
• Talán a legkevésbé elcseszett eset az, amikor a nagy felhasználóktól kérnek pénzt. (twitter firehose)

Az eleinte jól kezdődő szolgáltatás használhatósága zuhanórepülésbe kezd, a korai felhasználók menekülnek, 1-2 éven belül követi őket a nagyobb közönség. Az egész csak a pénz miatt, amit a cég és az infrastruktúra fentartására be kell szedniük.

...hogy mi lenne akkor,
na jó, ez csak elmélet...

Mi lenne akkor, ha a probléma alól megpróbálnánk kirúgni a széket úgy, ahogy a bittorrent teszi a filemegosztással. A dologba kicsit belekevernénk egy aszimetrikus titkosítást is, mindenki a rekordját egy saját kulccsal írná alá, egy publikus kulccsal lehetne olvasni, de írni nyilván nem. A hálózathoz csatlakozhatna tetszőleges node, attól függően hogy publikus vagy nem, de mindenki hostolná a saját adatait és valamennyit valaki máséból, csak hogy a redundancia is meglegyen. Az egész annyiban különbözne az elosztott adatbázistól, hogy nem csak az adatok repülnek a dróton, hanem néhány feldolgozásra vonatkozó kérés is: keresések, funkcióhívások, stb.
Nyilvánvaló előnyök:

• Az adat köztulajdon, nincs központi hivatal, ami elveheti, még az állam sem
• A felhasználók számával együtt nő a kapacítás
• A gyakran használt adatokhoz baró gyors hozzáférés
• Nincs központi szerver, ami kieshet. Ha néhány gép kiesik, csak azok az adatok vállnak elérhetetlenné, amik csak azokon a gépeken voltak meg.

Előre látható kihívások és kellemetlenségek:

• Trollok, spam és rongálók. Akár pornó is, mármint kéretlenül
• Hogy a feszegetőkről ne is beszéljünk...

Ezekre valamennyire van megoldás, spamfilterek, felhasználói interakciók a trollok jelölésére és blokkolására, satöbbi... persze a hülyeségre nincs orvosság. Milyen alkalmazásokra gondoltam tipikusan:

• social network akár - amennyiben még mindig meg akarod osztani a barátaid listáját
• akár hirdetési rendszerek is
• akár kereskedelmi rendszerek is
• tulajdonképpen akár csoportmunka jellegű szoftverek is, pl egy prezi-féle dolog, vagy egy , amin a szerver igazán csak púp

Nem fogok egyébként minden nap egy elszállt ötlettel előállni, ez csak ilyen év végi nagytakarítás :-)

elszállt ötletek: powersave license

Arra gondoltam, hogy ha pénzes private cloud-ot fejlesztenék (mint ahogy valójában, csak az ingyen van/support szerződéses), akkor csinálnék egy olyan licenszelési módot, hogy power-saving license. Ez azt jelentené, hogy amennyi áramot megtakarít neked a cluster azzal, hogy a felesleges kapacitást kikapcsolja, na annak a felét kérnénk el licenszdíjként. Nyilán a másik fele az ügyfélé maradna.

Szerintem egész attraktív licenszelési mód, hogy azt mondjuk hogy csak a megspórolt villanyszámládból kérünk egy kicsit. Ugyanakkor valójában nem hozna keveset. Egy PC jellegű gép ha folyamatosan működik, akkor 5-10000 forintnyi villanyszámlát csinál. Akár csak egy kis cég szerverszobájában is pörög ilyenből néhány tucatnyi. Sok múlik azon persze, hogy mennyire van overcommit-olva a szerverfarmod, de kicsit okosan, megtakaríthatod az üzemidő jónéhány százalékát, ebből szerverenként havonta pár-ezer forintnyi zseton jönne, ami nem sok, de sok szerverrel felszorozva már szép. Menj be a szerverszobába és számold meg a dobozokat :)

Szóval a dolog szépsége az lenne, hogy nagyon olcsónak tűnik, de nem az, és ennek ellenére amikor kifizetted akkor még mindig nagyon olcsónak tűnik :-)

elszállt ötletek: ami a tömörítésből még hiányzik

Van egy mondás, miszerint egy rendszerben egy adott pillanatban csak egy komponens a bottleneck. Ezt megfigyelheted akkor is, amikor egyik gépről nagyobb mennyiségű adatot pumpálsz át etherneten: vagy a merevlemez, vagy a hálózat lesz teljesen leterhelve, a processzor meg közben vakarja a tökeit.
Arra gondoltam, hogy ezen kicsit megpróbálok segíteni, de ha egyszerűen csak bedobok egy tetszőleges tömörítő algoritmust a sorba, akkor könnyen lehet, hogy a CPU-t rúgom agyon és ezzel azt nevezem ki új bottleneck-nek, míg innentől a hálózat forgalom lesz alacsony. Minden vason külön ki kellene találnom hogy mennyire jó ötlet egy tömörítést közbedobni, és nem akarom, mert már a másodiknál is nagyon unnám.

Egy olyan InputStream/OutputStream párosra gondoltam, ami egy kellően nagy bufferrel rendelkezik. Az output része az írásra itélt adatokat csomagokra bontaná és egy szálon figyelné hogy melyik mennyi idő tellik el a beérkezés és a bufferből távozás között. Ha úgy becsülné meg, indítana egy szálat, ami a buffer egy részét egy tömörítő algoritmussal betömörítené és hozzátenne egy nagyon rövid headert (pl 1 byte) ami jelezné hogy tömörítve van-e és ha igen milyen algoritmussal. Az input része csak csekkolná ezt a headert és szükség esetén kitömörítené a csomagot. Nyilván ez egy kicsi overhead.

Így a viszonylag gyenge hálózati kapcsolatot kicsit felgyógyíthatnám egy processzorral, de annélkül, hogy esetleg bizonyos esetekben nagyon durván kiszúrjak magammal.

Egy másik kapcsolódó ötlet az az lenne, hogy egy olyan tömörítő input/output streameket próbálnék ki, amelyek ellenőrzik (lehetőleg csak egyszer) hogy az adott rendszeren létezik-e az adott tömörítő algoritmusnak natív változata. Ha van akkor azon átpipe-olva tömörítené az adatokat, ha pedig nincs, akkor egy java implementációra terhelné. A natív implementációk általában véve gyorsabbak, még azzal együtt is, hogy context-switch ésatöbbi.

Szóval ez csak szimpla tuning. Nincs autóm, úgyhogy azt nem tudom brümmögtetni :-) Ja és nem is szeretnék, mert nem szeretem a brümmögést :-D

Hát ennyi lenne az ötlet, jöhetnek a kövek.

BS szótár: upstream és downstream

Egyes open source szoftverek esetében (pl ovirt) gyakran kerül szóba az upstream és downstream verzió, majdnem minden esetben amikor felhasználókkal beszélünk akkor a felhasználó visszakérdez hogy "Az up/downstream vajon mi?"

Cefet egyszerű: az upstream az a "community edition" megfelelője, a downstream meg a pénzes cók. Csak ezt így nem illik mondani :-)

oVirt lecke

Pár dolog, amit az eheti oVirt Workshop-on nyilvánvalóvá vált (legalábbis nekem):

• Az olyan környezetfüggőségek, mint a PostgreSQL és a JBoss nem hozzák közelebb az oVirt-et a felhasználókhoz. Sokan akarnák ez egészet egy kicsi környezetben futtatni, például tomcat-en vagy akár jetty-n. Akárcsak az appszerverből, adatbázisból sem szeretne a felhasználó hat félét a rendszerében. Meg tudom érteni...
  Söt a fejlesztők is így akarják.
• Tavaly ilyenkor még nem volt komoly verseny a nyílt forráskódú cloud management szoftverek között. Az oVirt is éppen publikálás elött állt. Azóta akkora szoftver-ajánlat jött létre, hogy az nagyon megnehezíti a felhasználók döntéseit. oVirt, Openstack, CloudStack, OpenNebula, satöbbi satöbbi. Nem hiszem, hogy ennyi szoftver túlélheti a versenyt, valaki rá fog faragni.
• Az OVirt UI nem rossz elsőre, de néhány helyen kicsit lehetne fejleszteni. A régi design-tól el kellene szakadni.
• A hibaüzenetek nem csak hogy nem elég jók, de néha kifejezetten gebasz.  pl "Nem sikerült elindítani a virtuális gépet" - és vajon miért?
• Feature-szinten azért minden kritikus és bomlasztó hozzáállásom ellenére szerintem egészen jól állunk, de az architektúrát ki kell pofozni, a ganajt ki kell hordani. Csökkenteni kell a fejlesztők extra terheit, különben a kutya sem akar majd beszállni buherálni.

Egyébként a ("rivális") cloudstack forráskódját olvasgatom, próbálgatom. Egyes dolgok marhára tetszenek, például hogy elmegy egy jetty-n, de van egy csomó dolog, ami tiszta marhaság. Pl a saját "IoC" rendszer, a belehegesztett mysql, stb.

subhub @ googlecode

Gondoltam egyet és megosztottam a subhub nevű pubsubhubbub kliensemet a google code-on. Ez a cucc két JMS sorral elintéz mindent. Egy JMS sorban küldöd fel, hogy mire íratkozzon fel, a másikon pedig kapod az feed updateket. Kicsit kezdetleges, de biztosan használható, mert én használom :-)

https://code.google.com/p/subhub/

Kotlin tesztkör

Néhány hónapja a Jetbrains orosz csapata bejelentette hogy új JVM nyelvet fejlesztenek Kotlin néven. Próbálgatom, gondoltam pár dolgot mesélek, hátha érdekes. Nem lesz teljes leírás, csak kedvcsináló. Ha megjött a kedved hozzá, látogass el a kotlin weboldalára! Türelmetleneknek a végén összefoglaló.

var vagy val

Meséltem neketek a beteges final-ozásomról. Nos a magamfajta elvetemülteknek alighanem üdítő feature a kotlin nyelvben az, hogy a változó deklarációjánál meg kell mondani, hogy változhat-e vagy sem. Ami változhat, az var (variable), ami nem, az val (value).
Ez semmi új, a scala is hasonló koncepcióval jött.

A változók deklarációjánál még tréfi az is, hogy nem kell kétszer elmondanod a típust. Kitalálja. Példa:

val kakukk = "kakukk" //nyilván string
val map = HashMap<String, String>()

Azt gondolom észrevetted, hogy new sincs. Nincsen. Mondjuk a melóhelyi projectemen, hogy a metódusok fele nagybetűvel kezdődik többnyire nem érteném, hogy ez most új objektum vagy csak hívás... desebaj, az úgyse nem lesz kotlinban.

Mr Bean

Természetesen property-k definiálása is kapott egy szebb és kompaktabb szintaxist. Elösször is, minden amit var-ként definiál az ember, az egyből property, getterrel, setterrel, tokkal vonóval.

var name : String? = null;

Ennyi, ha nem akarod felüldefiniálni a getter tartalmát. Nagyon ajánlanám, hogy ne akard, vicces dolgokat lehet vele elkövetni. Pl ha a getterből a property-re hivatkozol, akkor simán a kód meghívja önmagát. Ezt gondolom majd kijavítják :)

Null-safety

A null értékektől való para mindig is itt volt, mióta java platform létezik, meg még elötte is, csak szegény emberek elötte egy segmentaiton fault-ot kaptak, nem pedig NPE-t. Azért ha a kettő közül kell választani, akkor én még mindig inkáb a NPE-t választanám, az nem feltétlenül halálos.
Míg a java nyelv esetében erőtlen próbálkozásokat látunk annotációk bevezetésére, az új JRE nyelvek mind valamilyen mehanizmussal jönnek a null értékek kezelésére. A kotlin megkülönbözteti tipusonként, hogy lehet-e null. Például egy funkció, ami esetleg null-t ad vissza, azt így deklarálod:

fun talánNull() : String?

Na ez nagyon kedves, de a sima java-ban nincs ilyen, ezért minden java API minden visszaadott értéke a kotlin szempontjából esetleg null lehet. Na most például a slf4j LoggerFactory.getLogger(akármi.class) soha nem ad vissza null értéket, de a kotlin ezt nem érti, viszont néhány kényelmes operátort ad az esetleges null-támadás kivédésére. Az egyik a !! operátor. Ez a "Hidd el nekem hogy nem null, dögöljek meg itt azonnal ha null!!" operátor :) A log4j esetében például így nézne ki:

LoggerFactory.getLogger(akármi.class)!!

A másik lehetőség, az úgynevezett Elvis operátor. Elvis-szel azokat a helyzeteket tudod röviden megfogalmazni, amikor null értéket valami mással helyettesítenél. Pl ha getFoo() null-t ad vissza, akkor helyettesítsük le inkáb foo-ra:

val foo : String = getFoo() ?: "foo";

Ez a (x == null) ? null : x.getFoo() típusú műveletekre használatos. Így néz ki a fenti példa esetében fél szemű Elvis-szel.

x?.getFoo()

Ez null lesz, ha x null, és a getFoo() értéke, ha x nem null. Egész kompakt.

Nincs static

Ez a dolog nekem már scala-ban is nehezen esett le, de nincsen statikus változó. Első felmerülő kérdés egyből az, hogy akkor hogy a túróba fogok loggert deklarálni. Valahogy így

class object {
    private val logger : Logger = LoggerFactory.getLogger(akármi.class)!!
}

Innetől ugyanúgy használhatod, mintha egy sima statikus logger lenne.

Closure

Minden új JVM nyelv lehetőséget ad closure-ök használatára (különben az érdeklődés hiányával kell szembenéznie), a kotlin sem kivétel. Nézzünk egy gyors példát:

fun kickntimes(int cnt, fn : () - > Unit) {
   for(i in 0 .. cnt) {
      fn();
   }
}
...

kickntimes(100, {print("bla")});

Extension functions

Ez sem új, a groovy is és a scala is mindenféle extrákkal cicomázza fel a java osztályait. Így lesz a java.io.File osztálynak olyan metódusa, aminek például átpasszolsz egy closure-t és minden sorára meghívja. Valahogy így:

val myFile = File("bla");
myFile.forEachLine({ print(it); });

IDE

Mivel Jetbrains, nyilván idea plugin van hozzá. Azért annyira sokat azért ne várj tőle, épp úgy fejlesztés alatt áll, mint a nyelv maga. Szinez, pár helyen kisegíti a szintaxist, kódformáz. Refaktorálni többnyire nem tud, csak az alapokat (osztály átnevezés).

Összevisszafoglaló

Szóval egészen sok új dolga van a kotlinnak, érdekes koncepciók vannak benne és van. (Ellenben a scala IDE mindig elavult eclipse-re epül, amellett hogy nem is tud sokat) kotlint használni kicsit olyan érzés, mintha délután négykor érkeznél a házibuliba: nagyon korai. Majd meglátjuk mi sül ki belőle.

script kalandok

Ha a saját python tudásomat értékelnem kellene 1-10-ig akkor szégyenkezés nélkül 1-est adnék magamnak. A CV-ből is kihagyom, ugyanis nem karrier-cél. Ennek ellenére melóban mostanában az időm túlnyomó részét python gubancolás köti le sajnos, bugfixek, apróbb featurek, takarítgatás. Sokan csinálnák nálam jobban, talán akárki lelkesebben.

Első mese: egy python szál egy félórás tökéletes működés után (valami aszinkron taszkot vezérelt) egyszerűen csak meghalt. Vagy egy napon keresztül néztem azt a pár sor kódot és nem fogtam fel, hogy mi a baja. Aztán leesett: egy ponton a loggert hívta meg a script logging metódus nélkül. Valahogy így:

self._log('szopás')

Erre a python (helyesen) azt mondta ezen a ponton a végrehajtásban, hogy az pedig nem metódus, hanem ojjektum, és dobott egy hibát amit senki sehol nem kapott el. A szál elszakadt, a taszk meg beakadt és azt hiszem van valami timeout valahol 12 óra után, de nekem már ehhez is alig volt türelmem.
Egy szép példa arról, hogy logolás nélkül még elvben jó volt a rendszer, de logolással már nem.

Második mese: valamikor már írtam a pythonos srácok tab vs space, illetőleg 2 space vs 3 space vs 4 space vs N space vitájáról. Persze már akkor is találtam olyat, hogy valahol 13 space volt egy parancs elött. Erre a sonar hívta fel a figyelmemet, amúgy én se számolom. Szóval a 13 hogy jöhetett ki? Azt 2 db 4-spaces, egy 2-spaces és egy 3 spaces pythonos írta együtt? Mindegy, mert valahogy a python egészen idáig tolerálta a dolgot, legalábbis azt hiszem. Ma történt az, hogy megintcsak egy pythonban írt szálban keletkező hibát kellett kutatnom. Az __init__ metódus egy pár feltétel után meghívta a start() metódust, párszáz sorral lejjebb ott volt a start metódus ami elsőre nézve valami értelmes dolgot csinált. (van abban is kis gebasz amúgy, még vita trágya) Okénak tűnt, és mégsem volt az, a start ugyanis soha nem kapta meg a vezérlést. Mintha valami tréfás manó elvarázsolta volna.
Egy csomó lapozgatás után esett csak le: el volt szúrva a spacelés, így a start nem a szál osztály egy metódusa volt, hanem csak egy random funkció ott a levegőben, akit a fene se hív meg. Amúgy a szál meg frankón elindult, de nem csinált semmit se.
Tessék, space-nácik :-)

Az odáig oké, hogy én elcseszem, nyilván mert béna vagyok pythonban, de ezeket az elcseszéseket a project maintainerei csinálták, akik nyilván jobbak nálam, és még ők is ilyen alap dolgokat szúrnak el. Amúgy cefetjó, hogy dynamikus, modern, light, ésatöbbi, leszarom, csak menjen.

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

"oVirt or no virt"

Megint melóval kapcsolatos pár gondolatot szeretnék megosztani magammal, nyugodtan hagyjátok figyelmen kívül. Szóval pár dolog, ami az oVirt-ben nagyon szeretném ha fejlődne, de sajna nem fejlődik akármennyit is túlórázok. Ugyanis teljesen mással vagyok elfoglalva, pl újabban python-ban programozok, legalábbis imitálom, a kedvem viszont rohamosan fogy.

VM ütemező

Ha van egy adatközpontod -és ne valami CERN-Google-fakebook mega-vastelepre kell gondolni, hanem akár a sufniba bevágott 6-8 leselejtezett asztali gépből összefabrikált teszt clusterre- amin elfut 20-30 különböző virtuális gép. Szóval már a 20-30 gépnek is kimérni hogy melyik gépen fusson, hogy ne pont egyszerre kezdjék agyonhajtani az egyik vincsit, a hálózatot, satöbbi... ez túl sok meló. Az oVirtben ezeket a dolgokat, hogy CPU-pinning, hosthoz kötés, ezek enterprise virtualizáció néven oké (gondolom az enterprise az ökörséget jelenti). De akár már néhány VM-en is kikisérletezgetni az optimális konfigot, nekem se lenne hozzá kedvem. Ez had legyen a droidok sportja.

Az oVirt VM-ütemezője viszont a memória pillanatnyi kihasználtságán kívül kb mindent figyelmen kívül hagy. Egy ütemezőnek figyelembe kellene vennie:

• a memóriát természetesen
• CPU kihasználtság
• merevlemez használat
• hálózat használat
• ÉS nem csak az éppen aktuálisat, hanem az azon a gépen futó VM-ek tipikus terhelését. Például van éjfélkor elindul pár job az egyik VM-en ami generál némi aktivítást, vajon odafér-e mellé még egy másik gép által generált aktivítás is?

Persze nem mondom, király, hogy ki tudod jelölni,hogy melyik gépen fusson a szervered. De mennyivel jobb, ha nem kell vele foglalkoznod. Én már akkor a lehetőségről is lemondanék. Miért akarnék én magam migrálgatni VM-eket egyik dobozról a másikra?

Power save

A másik dolog, amivel nehezen tudok megbarátkozni, hogy az oVirt soha nem kapcsolja ki a hostokat. Ott van minden power management-tel kapcsolatos info, és nem. A használatlan hostokat milyen király lenne egyszerűen kikapcsolni. Kevesebb zaj, nyáron az se rossz ha kevesebbet fűtünk, barátibb villanyszámla, meg addig a csapágy se kopik :-)

Ja és persze kiragaszthatod magadra, hogy zöld vagy mint egy mozgalom és egylet.

Majd ha kell a host, akkor bekapcsolhatjuk automatikusan.

Valamint ha egyszer tényleg kikapcsolná a hostokat az oVirt, akkor nagyon királynak tartanám ha nem csak a szokásos IPMI, DRAC, stb interfaceket használnánk, hanem a primitív wake-on-lant is akár. Wake-on-lan a világon mindenben van, amiben van ethernet csatlakozó. Sajnos amennyivel többe kerül egy IPMI-os interface-szel szállított echte Dell szerver, na annyit nem takarítassz meg a villanyszámlán egyhamar.

VM pool

A VM pool szerintem félbehagyott feature. Pedig király lenne. A VM pool jelenleg ezt csinálja: egy template-ből csinál neked annyi VM-et amennyit akarsz, és nyilvántartja, hogy azok a pool-ba tartoznak. A pool létrejöttekor illetve módosításakor létrehozza a konkrét VM-eket. 

• Olyan API hivás sincs, hogy "adjál egy VM-et abból a pool-ból"
• A stabil méret helyett szerintem a maximum és minimum érdkesebb lenne.
• Olyanok is inkább érdekelnének, hogy az oVirt automatikusan elindítson a pool-ból új VM-eket bizonyos kritériumok esetében. Pl ha minden gép legalább 50 % CPU terhelést kap, stb.
• Ha azt mondom pool, akkor olyan dolgok halmazára gondolsz, amik közül mindegy, hogy melyiket kapod meg, mind ugyanazt tudja. Szóval szerintem egy olyan pool esetleg hasznosabb lenne, ami nem hozza előre létre a VM-eket, hanem a template-ből bármikor csinálhat egy újat. Mi a fenének foglalják a helyet addig?

VM Set

Ilyesmi nincs az oVirt-ben, szóval ez egy feature request lenne. Nagyon gyakran van olyan, hogy egy project fejlesztői környezetéhez létrehozol hálózatot, X darab virtuális gépet, amik különböző komponenseket futtatnak a rendszerből. Pl valami load ballancer, X db servlet container vagy app szerver, egy adatbázis szerver, vagy esetleg egy fél tucat NoSQL. Szóval azért lenne őket értelme egyben tartani, mert olyan dolgokat lehetne csinálni velük, mint klónozás, hogy a dev környezet szenvedést ne kelljen megismételni N alkalommal. Vagy akár együtt az egészet learchiválnád és lekapcsolnád, amikor a project végetér. Abban is segítene, hogy a set gépei pl elsősorban egymással kommunikálnak, szóval érdemes lehet őket ennek megfelelően pakolni hostokra.

... és így tovább, még van jónéhány ötletem, csak most mingyá hajnalodik.

Eclipse democamp pénteken

Aki még esetleg nem tudna róla: péntek este budapesti eclipse democamp.

Leginkáb az XTend nyelv érdekel az előadások közül, annak ellenére hogy szerintem nem a nyelv a probléma a java környékén.

Gyárlátogatás: KÓD_KONVENCIÓ

Hali, ismét gyárlátogatáson vagyunk, zsebrevágott kézzel körbevizslatunk az üzemben, megnézzük mit csinálnak a szakik. Gondoltam ma kicsit mesélnék arról, hogy miket láttam kód konvenciók háza-táján, milyen viták zajlanak, hol és mi fáj. Ne várjatok nagyon objektív megközelítést, ez az egész személyes élmények alapján.

A legtöbb kód konvenció csak a fejlesztők életét könnyíti vagy nehezíti meg. A forráskód fordítása után a tárgykódban már nincsenek se szóközök, se kommentek, se tabok, C nyelvben még a változód neve is eltűnik, java-ban is inkáb csak a mezőknek van jelentősége. Szóval ilyen szempontból a dolog kevés értéket jelent az ügyfélnek, aki végülis fizetni fog (reméljük) a termékért.

Nevek

C++-ból és hasonló területekről érkező szoftverfejlesztőktól gyakran láttam hungarian notation-hoz hasonló neveket. pl a mezőket sokan kedték aláhúzással, mint _name, vagy my prefixszel, pl myName. Régebben sokat láttam szigorúbb hungarian notationt java programozóktól is, pl volt olyan munkahelyem, ahol meg a paramétereket is 'a'-val (mint argumentum) kellet kezdeni.

A legviccesebbnek azt a konvenciót találtam, ahol az entitás osztályokat és azoknak a mezőit magyarul kellett elnevezni. Szerencsére ékezeteket nem akartak, de sikerült amolyan kicsi bábelt létrehozni a forráskódban, ugyanis a java többi része és library-k továbbra is angolul vannak.

if(fejleszto.isHulye()) ...

Egyes konvenciókat a java nyelvben én is teljesen figyelmen kívül hagyok, az egyik ezek közül amit a legtöbbször vágnak a fejemhez, a konstansok NAGY_BETŰS elnevezése, helyette a konstansokat is sima mezei camelCase írom. Akkor pár ok:

• A NAGY_BETŰS konvenció a C nyelvből érkezett a java nyelvbe. Ott a prepocesszor makrókat ajánlott nagybetűsen írni, ugyanis komoly gubancok származhatnak belőle ha elfelejted. Java-ban udvariasan szól az eclipse vagy amit hajtassz, hogy "komám, az final". Nem mondod komolyan, hogy vim-ben írsz java kódot? Ja emacs, persze, de kis buta vagyok :-D
• Enum-okat: Igen, ami az enumban van az effektive public static final, de miért kellene mindent nagy betővel írnunk benne? Mint egy állítólagos nigériai tábornok lányának a takarítónöjének a majma egy e-mailben.

Tab vs space

"te tab-bal tabulálsz?
bnzi-e vagy" - beteg-patkány-ember

A másik ilyen kérdés a space vs tab hitvita. Nem szeretnék senkit se rábeszélni arra, hogy áttérjen a másikra, de a harcos space-hívőknek: Ha a space a tabulálásra van akkor a tab vajon mire van?

Ez a tabulálás dolog viszont leginkáb a python fejlesztők között okoz viszályokat, pár hét python buherálás után én így kategorizálom be a python fejlesztőket:

• tab-os pythonos
• 4-spaces pythonos
• 4-től eltérő mennyiségű space-szel tabuláló pythonos

És mind meg van győződve róla, hogy ő vágja a témát és a többi falhozvert lófasz. A projectemen többségében 4-spaces pythonosok vannak, szerintük a pythonnak nagyon fontos, hogy pont 4 legyen. Ennek ellenére a kódban tucat helyen el van cseszve és csak 3 space. Sajnos kb azonnal elfelejtettem az indoklást, az összes python scriptem futott a tabokkal.

Sorhossz

A sorok hossza ami a másik dolog, amivel teljesen értelmetlenül és eredménytelenül lehet vitatkozni egy pár órát. Kezdetekben mindenkinek volt a szép karakteres képernyője, ami képes volt 80x25 karakter megjelenítésére, innen származott az a tradíció, hogy legyünk szivesek 80 karakternél többet ne pakolni egy sorba. Hát azóta eltellt egy kis idő, közben a képernyők közül a 23 colos lett a standard. Amennyiben nem a mobil telefonodon fejlesztessz. A sorok szélessége viszont sok projectben megmaradt 80 karakter.

Kicsit ez a dolog kapcsolódik a space vs tab vitához, mert a tab méretét lehet változtatni a szerkesztőben.

Kommentek

Talán ezzel volt a legkevesebb gubanc, mert áltaáában a fejlesztők beérik kevés dokmentációval. Egy ellenpéldával találkoztam, konkrétan az oVirt projecten dobták vissza az egyik patch-emet egy csillag miatt. Ugyanis egy kicsit bonyolultabb kóddarabhoz odaírtam, hogy mi a fészkes fenét csinál ez az egész, és a többsoros /* */ kommentet használtam. Erre valakinek az volt a kifogása, hogy "mi" csak a /** */ -t használjuk.

Akkor kapd be a patch-em :-)

Egy kis saját: final paraméterek

Á igen, gondoltam a végére csemegének megint egy saját paranoiámat dobnám be. Legalább tudok róla, hogy van :-) sőt már egyszer meg is gyóntam. Szóval amerre járok, hajlamos vagyok főleg a hosszabb metódusok paramétereit átírni final-ra. Ennek funkcionálisan a világon semmilyen következménye nincs: amennyiben lefordul, működni is fog. Azért alakult ki nálam ez a szokás, mert a parameter-reassignment-et teljesen olvashatatlannak tartom.

De én legalább senkivel nem kezdek el cseszekedni, ha nem finalként definiálja a paramétereket a patcheiben :-)

Policy Police

Pár eszközt említenék meg a kód konvenciók betartatásához illetve figyeléséhez:

• nagyon szimpatikus a sonar. Azt is meg lehet oldani vele, hogy elhasaljon a build, ha súlyosabb hibát talál, de ilyen beállítással még nem találkoztam. A sonarral kapcsolatban azt tartom szomorúnak, hogy nagyon kevesen használják ténylegesen, pedig átalában egy csomó dologra hívja fel a figyelmedet, szerintem a használatával tényleg tanulhatsz pár érdekes dolgot, legalábbis én tanultam tőle.
  A legfontosabb, hogy időben láthatod a változást. Szerintem az egésznek nagyon kevés értelme van, ha nem a változást figyeled.
• nagyon idegesítőnek találtam a maven-checkstyle plugint, ami az ovirtben nem csak pazarolja az időmet, de olyan marhaságokon képes eltörni a buildet, mint trailing spaces. Amikor éppen egy kritikus hibát próbálsz javítani el tudod képzelni mennyire örülsz egy ilyennek.

Amúgy nekem végülis 8, mondhatnám. Magyar jelöléses 80 karakteres sorhosszú, dokumentálatlan és akár egysorba írt kódot kapunk és nem ettől lesz az eredmény egy stack trace.

A kód konvenciókban engem az zavart mindenhol, a C/C++-os, Perl-es Python és PL/SQL-es projectekben egyaránt, hogy a kód konvenció személyenként változott. Azaz ha bedobod review-ra a patch-et, akkor attól függően lesz lefikázva vagy elfogadva, hogy ki nézi meg. Kb mint egy vizsgán, hogy melyik tanárnál vizsgázol.

Projectek illetve cégek különböző csoportai között egyre nagyobb véleménykülönbségeket láttam.

Ezzel együt lehet élni persze, a probléma akkor következik, amikor az egyik csoport megpróbálja rákényszeríteni a konvencióit a másik csoportra, illetve meg akar határozni egy globálisabb (pl céges) kódkonvenciót. 

Na, ez az amiből egyetlen egy sikeres próbálkozást nem láttam, de nagyon hosszú és anyázásig elmenő vitát jópárat.

"Persze, hogy benne van a céges policy-ban. Most írtam bele."

Én azt hiszem az lenne egy egyensúly közeli állapot, ha egy-egy projecten együtt dolgozó emberek a nem funkcionális elvárásaikat megbeszélnék nem egy bizottsági üllés keretében hanem inkrementálisan, ahogy jön. Azt is jobbnak hiszem, ha ezeket a szabályokat nem próbálják meg keményen bármi áron betartani. Ha funkconálisan teljesen jó és nem halom ganaj a kinézete, had jöjjön, aztán lesz időnk szépítgetni. 

Nyugdíj után bármire :-)

Ezt én sem tarom univerzálisan bevethető dolognak, a demokrácia nem mindenkivel működőképes, egyre több emberrel pedig egyre kevésbé.

Small is beautiful

Lassanként minden a felhőben szalad, mert az (többnyire, eleinte, állítólag, stb) olcsóbb, és persze a felhőben fogyasztás alapján számláznak. Azaz megkapod havonta a memória fogyasztásodról a számlát minden hónapban újra és újra. Nem csak akkor, amikor leslattyogsz a boltba megvenni a RAM-ot a gépbe.

Szóval vajon ez az újra és újra megjelenő kiadás elegendő motiváció-e arra, hogy kisebb memóriaigényű szoftvereket fejlesszünk és futtassunk?

Például a jetty elfut 256 MB memórián. Még egy DB-nek is akad hely, azaz a legkisebb VM-en is simán elszalad. Egy JBoss-t vagy Glassfish-t nem inditasz el azért 1 GB alatti memórián. Illetve ha megveszed minden hónapban a memóriát, nem-e inkáb valami hasznosra használnád? Még az I/O cache is sokkal hasznosabb, mint egy tucat teljesen kihasználatlan feature a kedvenc JEE szerveredben.

csapatszétszórás

Arra a melóra, amit én csinálok, 4 földrészen lehet jelentkezni. Ennek ellenére a szűkebb csapatból én vagyok az egyetlen, aki nem Tel Avivban dolgozik. A tágabb csapatból se sokan. Néha úgy tűnik, akár maradhattam volna Budapesten is. Egyszer megkérdeztem, hogy miért jó az hogy egy pár ember így a világban elszórva van, de a legtöbb (talán úgy 100 ember) egy városban. Hát, erre nem kaptam kielégítő választ :-) de gondoltam megosztanám mindenkivel a véleményemet erről a csapatszétszórásról általában:

A földrajzilag szétszórt csapatot sokan trendi dolognak tartják, pedig kommunikációs problémák lehetséges forrása. Nem cél, hanem egy probléma.

Például a gerriten, ircen keresztül pötyögni soha nem lesz olyan hatékony, mint odamenni valakihez és ledumálni  az egész problémát. Kicsit olyan, mintha a szervereidet plip-pel kötnéd össze, meg még egy csomót is kötsz rá, aztán csodálkozol hogy lassú meg rossz.

Amúgy ezt is lehet jobban csinálni, de pl az irc elég rendesen múlt századi technológia. Soha nem is irceztem mielött itt dolgoztam volna.

code review

A közhiedelem az, hogy a code review során a problémák nagy részét elkapjuk és kitekerjük a nyakát. Ez igaz is lehet egy bizonyos mértékig, de csak egy bizonyos mértékig. Nekem úgy tűnik, hogy a code review során gyakran új bugokat hozunk létre, az alábbi okokból:

• A reviewer személye mindig más. A mindig más személynek mindig mások a szempontjai. Például van olyan, aki azért dobja vissza a patch-et, mert nem final egy változód benne, van aki azért mert az és neki nem tetszik. "ha van kalapod, azért, ha nincs kalapod, akkor meg azért". Valljuk be, ez a final dolog még bölcsészek között is baszakodásnak számítana.
• A patch-ek szétválasztása és egyesítése tulajdonképpen kódolási tevékenység (azaz idővel és kockázatokkal jár) míg a végeredményhez semmilyen értéket nem tesz hozzá.
• Teljesen beteg vagyok attól, amikor valamit kétszer kell megcsináljak. Na és az még a jó eset :-) Ha elsőre jó volt, másodszor biztosan elcseszem.

Szóval a lefikázás után valami konstruktívat arról, hogy szerintem hogyan kellene használni a gerrit-et:

• Ha egy patch jobb állapotot hagy maga után, mint elötte, akkor had menjen. Lépjünk tovább, ne szarozzunk!
• Ha hiányzik belőle valami (de ugyanakkor attól még jó), akkor esetleg a reviewer hozzáírhat egy patchet és beküldheti, megmutathatja az eredeti patch szerzőjének, hogy ő még ilyesmire gondolt. Lehet vitatkozni, vagy örülni hogy "gyá télleg, köszi!"
• A fast forward policy csak több munkát hoz, gyakorlatban nem védett meg minket semmilyen hibától. Ezt a funkciót egyszerűen kijátszuk, mert nincs más választásunk.

Szóval én inkáb piacnak képzelnék el egy jól működő dolgot, mint vizsgabizottságnak. Lehet ezt is jól csinálni, csak mi nem úgy csináljuk. Megpróbáltam demózni az ötletet és egy pár hétig egy-egy embernek végignéztem a patch-setét egyenként ellenőriztem és ha jó volt egyből be is mergeltem. Szépen haladtunk. Mindenki örült, de aztán senki sem kezdte utánozni a módszert :-(

Amúgy a gerritet továbbra sem komállom, mert:

• A gerrit üzenetei suttyók - pl ezért én soha senkinek nem adok -1-et, mert az olyan bunkó szöveg, hogy inkáb fogalmazok valami barátibbat levélben.
• A felhasználói felülete ótvar. Ki hitte volna hogy GWT-ben is lehet ocsmány weboldalakat szerkeszteni? :-)
• A használhatósága csekély, pl keresés nagyon hiányzik belőle, de a saját lezárt patcheimet sem tudom átnézni benne.

Java Fight Club, Kanban, Smartphone

A JUM-ot sajnos úgy tűnik nem sikerült újraéleszteni.  Elek Márton, az eredeti ötletgazda és szervező twitjeit Svájcból lehet hallani hébe-hóba, sokan mások is elköltöztek és végül ennyi lett. Sajnálom, mert egyébként egy nagyon hasznos dolog volt. Mindenesetre köszi azoknak, akik csinálták!
Nekem csak kérnem kellett, és ti megcsináltátok, bárcsak mindig ilyen könnyen menne.

Nekem azért hiányzott a klub és nekiláttam egy hasonló találkozónak Brno-ban Java Fight Club néven az iroda csodaszép 5. emeletén. Szóval az alapötlet az annyi, hogy aki van olyan jóarc, hogy valamivel felkészül, azt segítsük meg annyival, hogy nem neki kell az időpontot, helyet, kivetítőt és egyéb technikai dolgokat megoldania, a közönséget ne untassuk azzal, hogy valami marha elkezd kötöszködni az előadóval, kezdjük el idejében a prezentációt satöbbi. Nem voltunk nagyon sokan, úgy nyolcan, az az első alkalomra egész jó.

Első prezentációként Jelinek Tamás beszélt a Kanban-ról. Egész idáig nem jött át nekem miért jó a kanban, a termelésleállások az egészen hajmeresztőnek hangzanak, a legtöbb munkahelyemen a managerem szerintem leszarta volna a termelésleállás okát, inkáb kirúgtak volna csak ne kelljen foglalkozni azzal hogy mi a gebasz.

A második prezit Szöcs Vojtech nyomta Smartphone fejlesztésről, ugyanis szeretne egy mobil klienst az oVirt-hez (én is nagyon szeretnék) Piaci összehasonlítás android vs ios, alkalmazásfejleszés költégei, illetve html5 appok.

Egyébként egészen jó szakmai élet van a Vörös Satyesz Vasgyárban, legalábbis ami a linuxereket illeti, de én nem vagyok igazán linuxer. Nekem a linux csak egy az operációs rendszerek között.

iwiw must die

Ma kitudja mennyi idő után elösször jelentkeztem be az iwiw-be, de most is csak hogy megkeressem a regisztráció törlése gombot. (Ugyanis nekiláttak spamelni.) Elszüttyögtem egy kicsit rajta, jól elrejtették a gombot, de nem annyira, mint a faszbook. Ez a kis howto segített, mert totál nem igazodtam ki rajta, hogy mi merre van: http://www.evenorbert.net/2010/10/iwiw-profil-torlese/

esti mese: kicsi mock és a memory leakek

Hol volt, hol nem volt...
Az oVirt engine-ben egészen félelmetes mennyiségű statikus kódunk van, statikus változókkal. Ez önmagában még nem lenne baj, persze egy tipikus Util osztály csak statikus metódusokból áll, ilyet kb mindenki csinál. A gubanc talán ott kezdődött, hogy IoC helyett is statikus metódusokat használunk. Pl ha szükséged van egy Dao objektumra, akkor így kéred el: DbFacade.getKakukkDao(), ami egy statikus metódus. Na most mi van akkor, amikor egy olyan kódot tesztelnél, ami ilyen módon szeretne egy DAO-t használni?
Mondjuk egy dummy DAO-t gyorsan összemockolsz easymock-kal, de hogyan tömöd bele abba a statikus metódusba, amit a tesztelendő kódod meg fog hívni? A válasz általában az az lenne, hogy sehogy, dögöljön meg aki írta.
No itt jön a képbe a PowerMock, ami arra az elvetemültségre képes, hogy a classloadered buherációjával lecseréli a statikus metódust. Ez a dolog tette lehetővé azt, hogy az egyébként tesztelhetetlen kódot módosítás nélkül mégiscsak tesztelni tudjuk unit-tesztekkel. Majdnem mindenki boldog volt, amíg N-nél több tesztig el nem jutottunk. Azt hiszem én vettem észre elsőként, mert én buheráltam a sonar-t az oVirt-en. Erről jut eszembe hogy kitettem egy openshift-es gépre a fél évig gyüjtött kódanalízist, ha kedved szottyan olvasgatni elalvás elött. Csak aztán ne nekem panaszkodj, ha rosszat álmodsz :-)
Szóval a Powermock-nak van egy nagyon rossz szokása: rettenetes memory leak-eket csinál a permgen space-ben. Párat talán kijavítottak a srácok, pár új meg talán jött útközben, de akármire is próbáltam felűberelni a Powermock + Mockito párost, mindi maradt egy szép nagy leak. Én viszont akkor is le akartam futtatni a teszteket, szóval a következőket heggesztettem rá a maven buildre:

• A surefire plugin startolja el a teszteket úgy, hogy mindhez külön VM-et futtasson (forkmode: always)
• A forkolt VM extra paraméterek között kapjon 2.5 GB memóriát, ebből 2 GB a permgen - na ez agyhalott, de kevesebbel nem futott le

Nos, ez idáig gondolom egy kicsit zavaró volt, de még koránt sincs vége :-D Pár munkatárs arról kezdett panaszkodni, hogy a fejlesztőkörnyezetükben nem megy le a teszt, pedig junkins-ban igen, illetve fordítva, ráadásul hol sikerül, hol nem. Totál összevisszaság :) Nos erről az derült ki, hogy a úgy hozzászokott a drága nép a forkmode=always beállításhoz, hogy egyes tesztek összemocskolták más tesztek futás környezetét, ja és persze a surefire alapbeállítása az, hogy a ahogy felszedte a filerendszerről a teszteket, abban a sorrendben fogja végrehajtani. Ez kicsit hülyébb a random sorrendnél :-)

A jelenlegi helyzet az, hogy az embereknek lerúgta az agya a láncot és visszadobják a teszt patcheket, ha powermock van benne. Szopódás, egyre nehezebb patcheket átverni a bürokrácián.

A tanulság: írj tesztelhető kódot, csínján a statikus dolgokkal.

No... itt a vége, fuss el véle. Aludjatok jól, álmodjatok EJB-ket. (vagy mi a f.szt)

komplexitás - röviden

A komplexitás nem az érték része, hanem az áré.

Szerintem. Csak ennyit akartam mondani, kérem kapcsolja ki. Boldog pénteket!

Bzip2 buhera

Az angol wikipedia dump feldolgozásával bíbelődök szabadidőmben, a dump egy egyszerű XML formátumú file Bzip2 tömörítéssel. Csak a legutolsó ellenőrzött oldal szöveg van benne, de még így is 15 GB tömörítve. Az első ötletem az volt, hogy a commons-compress BZip2CompressorInputStream osztályával egyszerűen meghajtom. Az első teszt-futtatásakkor kezdett kiderülni, hogy nem muzsikál valami szépen, elég lassúcska az import. Az első ötletem az volt, hogy akkor többszálúsítom és az egyik szál csak Bzip2 kitömörítést hajt és PipedOutputStream-en keresztül átdobja egy másik szálnak, ami csak XML-t parsol és a mongodb-be mentést egy executor csinálja néhány szállal, hogy ott biztosan ne legyen fennakadás. Hát... nagyon büszke voltam az architektúrális szörnyszülöttemre egészen addig, amíg elösször le nem futtattam ugyanis az elbonyolítás eredményeként csak 3 százalékkal javult a feldolgozás sebessége. A magyarázat egyszerű, a bzip2 tömörítés annyira elviszi a processzoridőt, hogy ahhoz képest az XML feldolgozás és mongodb interanciók szinte semmi. Egészen pontosan összesen a 3 százaléka. Na ekkor töröltem le az elbonyolítást teljesen mert 3 százalékért nem érdemes kétszeresen elbonyolítani.

Azért egy "gyors" összehasonlítás érdekelt a bzip2 implementációk között:

• A linux bzip2 programja 40 perc alatt tömörítette ki a 15 GB-os dumpot
• a pbzip2 (parallel bzip2) 4 szálon meghajtva 20 perc lett (2 core x 2 thread van a laptopomban, szóval ez logikus) Ez nem rossz, de a pbzip2 nem része az alaprendszereknek általában
• Ugyanehhez a commons-compress-nek 100 percre volt szüksége. Véletlenül ilyen szép kerek szám, nem én találtam ki.
• Mennyi lenne ha csak IO lenne az egész: egy sata vincsi általában másodpercenként 100 megát fel tud olvasni szekvenciális olvasásnál, az 150 másodperc lenne elvileg, a gyakorlati teszt hajszál pontosan igazolta az elméletet :-)

Szóval azt találtam ki, hogy akkor beintegrálom a bzip2-t egy InputStream-ként és akkor a feldolgozást lehúztam kereken 40 százalékra. A bzip2-vel érdemes lenne még buherálni, csak ahhoz be kell lőni a procik számát, szóval kicsit komplikáltabb...

A szomorú az, hogy ez így csak linuxon fut, szóval jó lenne egy olyan InputStream, ami elmegy a bzip2-vel és fallbackel commons-collections-ra.

Ennyi lett a kód, és végülis ezzel sikerült kibékülnöm egyelőre.

Na, érdekességként az angol wikipédia adathalmazából azoknak, akik idáig eljutottak:

• 162396 állat és növényfaj, illetve rendszertani akármi
• 239847 település
• 26312 hajó - ez teljesen beteg...
• 11902 tudós, 7762 sportoló, 2679 verekedő, 91871 "egyéb személy"
• 13172 író és 20084 könyv
• 7508 folyó
• 3003 politikai párt - és vajon mennyi korrupció?

Kicsi a patched?

A Belgának van az a zseniális száma "Az a baj" címmel, pár apróbb módosítással tök jól leírja, hogy miért megy lassan az oVirt fdejlesztése. Ezer dolgon akadhat el minden, és persze el is akad. És ezek nem a szoftverfejlesztési kihívások mert az nem lenne gond, azért vagyunk itt.  Egyébként vannak csodák, csak nagyon ritkán, különben nem hívnák őket csodának :-)

Ha nem fetcheltél origint az a baj
Ha nem rebaseltél az a baj
Ha rossz branchen vagy az a baj
Ha kurva sok branched van az a baj
Ha a tököd kivan a gittel az a baj
Ha nem megy a gerrit az a baj
Ha nincs reviewer az a baj
Ha más patchen dependelsz az a baj
Ha túl nagy a patched az a baj
Ha nem írtál junit-tesztet az a baj
Ha rossz patchbe tetted az a baj
Ha az ezredik patchnél elbaszod az a baj
Én ezt a refactort másik patchbe tenném az a baj
Mindenki csak +1-et ad az a baj
Fastforward-policy az a baj
Kezdheted előről az a baj
Ettől nem lesz semmi se jobb az a baj

Szóval mégis mitől lenne gyors?

OFF: meló-sztori

2000-ben és 2001-ben egy C++ fejlesztő cégnél dolgoztam és ott találkoztam egy kezdő programozóval. Hát nem volt fiatal, akkor is már 40 körül lehetett, doktorija volt vegyészetből és egyébként egy nagyon értelmes arc volt. A csákó kapott egy desktop gépet és Bjorne Strostrup C++ könyvét (ami szvsz egy szerencsétlenség) és elkezdte megtanulni azt a csodálatos nyelvet :) merthogy elötte nem C++ban tolta. Egy hét után érdekes kérdéseket kezdett feltenni, két hét múlva érdekes ötletekkel kezdett előállni, fantasztikusan haladt, én zseninek tartottam. Az 1 hónapos próbaidő végén már komolyan a kezét rázogattuk, amikor megjött a főnök a központból (jól hangzik mi? két iroda volt... csak ennyi) és megdöbbenésemre nemcsak hogy kirúgrta az embert, de ocsmány megalázó módon rúgta ki, mindenki elött.

Totálisan semmi lövésem nem volt arról, hogy mi állt a dolog mögött, de pár archiktektúrális kérdés mögötti okot sem értettem (a szoftverünk is egy halom szerencsétlenség volt) szóval munkaadóm egy nagy halom rejtély volt számomra is. Na és akkor pár hónappal később jött egy űber programozó megintcsak a központból, este kimentünk a városban mászkáltunk és közben megkérdeztem tőle hogy tud-e valamit arról, hogy miért rúgták ki a "srácot". Kiderült hogy pont ez a programozó nézte át a munkáját és azt a következtetést vonta le belőle hogy 100 % biztosan összemásolta valahonnan, mert az egyik fele zseniális a másik fele meg tiszta láma, ezt írta vissza a főnöknek és hát ez lett belőle.

A cégről annyit, hogy kb 3-4 hónappal később behalt és kirúgtak mindenkit. Ez nem azt jelenti, hogy mégiscsak van igazság, egyszerűen csak természetes szelekció in action. Addigra kiderült hogy az architektúra kérdésekben is hasonlóan zseniális döntések játszottak.

A nyolcadik hibámat csak nehezen mondom el
Kaptam a központból egy tojást és várni kellett hogy kikel
Kelt és rögtön megvert aztán bedobott egy kútba
Azóta ő helyettesít, ő visz titeket tévútra

- Kispál és a Borz még régen amikor még jó volt

Developer Conference 2012 Brno, második nap

A fedora konferencia második napjáról jelentjük. Ma főleg (de nem kizárólag) JBoss előadásokat hallgattunk meg. Voltunk páran magyarok, többnyire magyarországi magyarok, a brnoiak csak néha tolták elő az orrukat :-)

Swimming Upstream - Jared Smith

A fedora project vezetője arról beszélt, hogy milyen egy ilyen linux disztró fejlesztését irányítani, igen ezzel az opensource dologgal nem zavarnálak titeket, de megemlítette valahol a java-t, beszéltünk az egyik szünetben és azt hiszem hasonlóan látjuk a helyzetet a fronvonal két szembenálló lövészárkából:
A java fejlesztők és a linux fejlesztők valamit kapni akarnak egymástól, de nem értik meg egymást és a végén senki nem kap semmit. Bukó, nem? Nyomozok a dologgal kapcsolatban, vannak fejlemények, majd mesélek egy másik posztban.

oVirt overview - Alan Pavec

Ez a munkám, imádatom és gyűlöletem tárgya, úgyhogy beültem hogy meghallgassam. Majdnem teltház volt a nagyteremben, örültem neki hogy ekkora érdeklődés volt. Sokan kérdeztek is. Remélem a hibákat sikerül kijavítani mielött ők is megtalálják...

RHQ4 - Lukás Krejci

Igen, a JBoss a redhaten belül egy külön ország. A java általában már csak így van. Szóval a RHQ-val java szervereket lehet igazgatni, több platformon keresztül. Lukás csinált jópár demót is, néha volt egy kis izgalom hogy most mi történik, de mindig jól sült el, pedig baromi nehéz live demót csinálni.

Whats new in JBDS 5.0? - Martin Malina

JBoss Developer Studio. Jaja, erről  a srácról csinálták ezt a vicces képet az üresnek látszó teremmel. Senki nem ült közel, mert akkor nagyon felfele kell nézni a kivetítőre. Közben én laptopon próbálgattam amit a srác mutatott (ugyanis nem vagyok pillanatnyilag képben jboss IDE-ből), meg is akadtam kicsit a forge konzolon, nekem ez ugyanaz volt, mint a springsource roo nevű cucca.

HornetQ - fastest JMS provider - Niroslav Novak

Ideje, hogy erdemben foglalkozzak a HornetQ-val. Ahogy néztem, könnyen beágyazható és szépen muzsikál. Igazából nem a sebesség az első és legfontosabb dolog, amit egy JMS szerver előnyei között fel tudok sorolni, de nem árt egyáltalán. Mondjuk nem annyira gyorsabb az ActiveMQ-nál. Érdekes lenne egy friss összehasonlítás, mit tudhat az ActiveMQ csapat új cucca.

Tomcat 7 and Tomcat 8 - Mladen Turk

Mit kaptunk a tomcat 7-től és mit kapunk majd a tomcat 8-tól? Állítólag a tomcat 7 sokkal jobb minőségű, mint a 6-os széria és ez a legfontosabb a legtöbb fejlesztőnek. (még nem találkoztam senkivel aki az async apit használta volna, annak ellenére hogy nagyon nagy dobásnak tartottam) A tomcat 8 olyan dolgokat tartogat, mint websockets... amire semmilyen standard api nincs, de legalább történik valami.

Egyéb...

Egyébként volt kaja, volt innivaló (kólás pohárból kofola, király), esti parti és voltak magyarok is, Magyarországról jöttek hárman. Páran nem mertek elindulni a hazai úthelyzet miatt sajnos. De akik jöttek, azokkal jót vitatkoztunk pár kérdésben :-)

A 'Presentation Skills' tanárnőt láttam mászkálni a kamerájával, aligha a linux kernel érdekelte, szerintem megpróbálja majd a geek-eket kicsit rocksztárosabbra faragni. Nem baj, rájuk fér :-)

Developer Conference 2012 Brno, első nap

Tegnap a brnoi fejlesztői napon voltam, csak pár prezentációról, ami nagyon tetszett...

Towards Unified Messaging - Frantisek Reznicek

A csákó az AMQP protokolról és az apache qpid-ról beszélt. Az AMQP egy szabvány message queue-knak, nekünk a JMS protokol miatt nem volt különösebben fontos, hogy protokol szinten szabványos legyen. Elég volt kicserélni a drivert és kis szerencsével működött. Mindenesetre egy egész tucat JMS szerver implementálja ezt a szabványt most már. Pl az ActiveMQ és a  is.

Richfaces: testing on mobil devices - Pavel Pitonak

Érdekes demó a QE csapattól arról, hogy hogyan automatizálják a tesztjeiket mobil eszközökre virtualizált szerverekkel.

What are Drools, Guvnor and Planner - Geoffrey De Smet

Java témában kb etalonnak számító rules engine és a köré épített projektek. Semmi új nem volt nekem, decemberben elkezdtem egy prototipis projektet az oVirt mellett kisérletezésre és az egészen Drools-ra épül. Geofrey viszont jó előadó és a többiekkel ellentétben nem akadozik és nem dadog. Ja meg cseh akcentusa sincs :)

A drools érdemel talán egy kicsit nagyobb figyelmet, szerintem sok gyakori problémát le lehet vele egyszerűsíteni.

Hibernate OGM - Michal Linhard

Ez egy jelenleg alpha állapotú project arra, hogy sima JPA apival és annotációkkal ne csak hagyományos relációs, hanem NoSQL jellegű adatbázisokba is lehessen perzisztálni. Jelenleg csak az infinispannal megy, de az infinispan mögött lehet akármi is: cassandra, mongo, akár relácis adatbázis vagy filerendszer is.

Ez nagyon tetszett, nem tudom hogy fog elsülni ez a próbálkozás, de marha jó ötletnek tartom. Kiváncsi vagyok tényleg sikerülhet-e a gyakorlatban, hogy kihúzod az appod alól a relációs adatbbázist és kicseréled valami NoSQL-re.

Continuous integration with Jenkins CI - Vojtech Juranek

Trükkök Jenkinssel. Virtuális szervereken futó agentek, egzotikus nyelvek (php például), bug detektor pluginok. Mondjuk a statikus analízisre én a sonar-t tartom a legjobbnak, az nagyon pöpec.

Csak én tartom igénytelennek a jenkins webes felületét? Jó, úgyis csak fejlesztóknek kell, de ha ennyien használjuk, nincs egy designer köztünk?

No, most jön a második nap, ma oVirt, GlusterFS, SPICE további JBOSS előadásokat fogok hallgatni.

Gyárlátogatás: BuzzwordClass

Egy kis lista arról, hogy milyen ködösítő jelzőket szedtem össze, amik nem valami design pattern alkalmazását jelzik, hanem csak valahogy belekerülnek osztályok nevébe.

1. Domain - Ez általában olyasmit akar, hogy sokminden lehet benne és úgy ahogy van egészben van. Hát ezt akármire is mondhatnánk. pl weblogic domain, storage domain, satöbbi...
2. Business - Hát ez fogalmam sincs mit jelent, többnyire semmit, simán behelyettesítem BLF-re.
3. Enterprise - Ez azt jelenti, hogy a józan paraszti logika szerint marhaság-gyanús, de karriercélokkal architektúrális okokkal jól alátámasztható.
4. Manager - Ez néha ugyanaz, mint a valódi életben: konkrétan nem ő oldja meg a problémát, de ismeri azt, aki igen.
5. Entity / Bean - Ez egyszerűen csak azt jelenti hogy ő az adat, de ez sajnos nem jelenti a történet végét.

Mit szólnál ehhez az osztálynévhez: EnterpriseBusinessManagerDomainEntityBean? Kemény bullshit, nem? :-)

mongo - eddig

A hétvégén kipróbáltam a mongodb-t és az igazság az, hogy nagyon tetszik. Írtam rá egy kis java webappot, és kicsit meghajtottam, a webapp 3000 request/sec-et simán elvitt mindenféle tuning és cache nélkül egy 1.5 GB-os adatbázissal. Na jó be volt indexelve, de az mondjuk a minimum... A processzorídő túlnyomó részét a jvm vitte el (nyilván mert neki parsolgatnia kellett, meg serializálnia, ami sebesség szempontjából elég haszontalan). Pedig még egy youtube film is fogott a processzoridőből. Szóval sikerült meglepni, nemgondoltam hogy ilyen jól fog pörögni.
A cassandrához képest az is nagyon tetszik, hogy nagyon könnyen ki lehet deríteni egy collection méretét. Cassandrában nem is tudom hogy lehet...
Aztán a springes API is egész klassz hozzá. A plain API se valami bonyolult, a JDBC-hez képest pedig ultraegyszerű.
Egészen kiváncsi lettem, megpróbálom valamikor a cassandrára írt tesztemet átírni mongo-ra hogy lássam hogy néz ki több node-on.

project reset

Nem egyszer állítottam azt utóbbi X évben, hogy egy bizonyos szoftvert egyszerűbb lenne újraírni, mint debugerrel piszkálgatni nagyon sokáig, hamarabb lenne belőle simán futó rendszer. Biztosan nem volt mindig igazam, de ilyesmi nagyon nagyon ritkán történik, így ez ilyen "mi lenne akkor" maradt jobbára. A parát megértem:

• Mi a garancia arra, hogy az újraírt rendszer jobb lesz? Nem csak valami trendibb izét akarnak a fejlesztők? Pl valami NoSQL-t az Oracle rojszrojsz-adatbázis helyére. (btw éppen mongo-t tanulok)
• Az újraírás idejét miből gazdálkodja ki a fejlesztő cég? (inkáb kiscégeknél)
• Illetve az eddig beleölt időt és pénzt hogyan írjuk le? (tipikisan nagy cégeknél)

Ennek ellenére biztos vagyok benne, hogy

• A legtöbb informatikai project építget olyan komplexitásokat, ami nem kell egy megrendelőnek sem.
  Ide tartoznak azok a feature-k, amiket senki se használ és az olyan kódszervezési megoldások, amik a design patterns könyvben UML diagrammon jól néztek ki de az editorban már kicsit átláthatatlanok.
• A szükségtelen bonyolítások jelentős részétől általában gyakorlatilag nincs lehetőség megszabadulni, a fejlesztést pedig rémesen lelassítják.
• Ebből következőleg egy from scratch project gyorsabban képes fejlődni, ha tanult az elődje hibáiból és nem próbál meg újabb trendi ingyombingyomokból építkezni.

Jó megoldás nincs. Vagy megszabadulsz a technológiai adósságodtól, vagy az egész project alatt fizetheted a költségeit. Egyszerűen kiszámolható. Napi 8 óra munkám 8 kiló banánba kerül, de ebból a nyolc órából 2-t rebuild-redeploy, akkor napi 2 kiló banánért a cég nem értéket kap, hanem a technológiai adósság fizetésére fordít.
Ha így nézzük a jrebel a legtöbb JEE projectben a legfontosabb program a javac után. Azért lehet élni nélküle is, otthon elő nem veszem...

Ötlet megoldásra:

• Ismertesd meg a főnököd a tech debt fogalmával. Nem kell szégyellni, mindenkinek van!
• Tartsátok rajta a szemeteket, tudjátok hogy mi mennyi időbe (tehát mennyi pénzbe) kerül A sonar szerintem klassz kis játék ehhez is, csak persze be kell paraméterezni...

Egy tipushiba, amit megfigyeltem, az az volt hogy amit a beszállító hozott, azt elfogadták amennyiben a funkcionális követelményeknek megfelelt. Így aztán pl groovy-ban írt csoda is érkezett, amikor a srácok többsége még életében nem látott groovy-t. A beszállító elfutott a pénzével, az üzemeltetés meg járkálhatott körbe, hogy "helló, valaki hallott már groovy programnyelvről?" Aztán újraírták más nyelven, de abba se vonták bele cég szoftverfejlesztőit tudtommal. Vajon ismétli magát a történelem? Vagy csak bizonyos problémák időnként jelentkeznek ha egyfajta hibát nem tudunk megérteni? :-)

Egészen pontosan egyszer történt velem az, hogy a management beleegyezett egy újraírásba, de elöbb ki kellett javítanom az előző rendszer kritikus hibáit, hogy legalább az újraírás alatt legyen valami. Ezt mondjuk gondoltam előre, de ez a hibajavítás úgy fél évet vett igénybe, az újraírt verziót is ugyanennyi idő alatt fejlesztettük le, a 6 hónapnyi áthidalt időben viszont senki sem merte használni a régi alkalmazást. Szóval a javítgatással nem nyertünk semmit.

Java Architekt - a gyakorlatban

István múlt heti postjára szeretnék egy kicsit bővebben reagálni, mint ahogy kifér egy pár soros kommentben. Technikailag nagyon korrekt definíció egyébként, de egy két dolgot hiányolok belőle és pár dologban buktatót látok.

Szóval szerintem...

Elösször is azt tenném hozzá, hogy amennyiben valaki - az architekt pl - meghatározza a szoftver archiktetkúrát, amiben a szoftver-fejlesztők dolgozni fognak, akkor annak az embernek a felelőssége az is, hogy a szoftverfejlesztők mennyire tudják hatékonyan végezni a feladatukat. Amikor egy java architekt dolgozik, akkor arra kellene koncentrálnia, hogy minnél egyszerűbb és hatékonyabb eszközöket adjon a fejlesztőknek és minden komplexitást csak valami megfelelő haszonért cserébe (customer-value) engedjen be. Én ezzel szemben nagyon sok fejlesztésben láttam valami totálisan elszállt marhaságot. A 97 things - és István is - ezt javasolja architekteknek: ne az önéletrajzodat fejleszd. Persze nem ez az egyetlen oka annak, hogy egyes java projectek krónikusan halálcsillaggá nőnek, van a dologban némi buta ego-fejlesztés is.

Többmillió java szoftverfejlesztő nevében követelem, hogy amikor kiderül, hogy egy java rendszer elcseszett ökörség lett, az architekt szüleit legalább annyira emlegessék meg, mint a szoftverfejlesztőkét!
A hegesztőmunkás is el tudja cseszni, de általában ezek az hibák általában nagyon könnyen javíthatóak. Ellenben architektúrális hibák többnyire végigkisérik a szoftver életét.

A másik észrevételem az lenne, hogy István definíciója nehezen illeszthető össze egy akármilyen agilis, iteratív szoftverfejlesztéssel. Elösször is azért, mert az architekt a definícióban elvágja a fejlesztőket a klienstől. Láttam már olyan embert, aki egész jól játszotta az információfiltert, de ez nagyon ritka, valamennyi infót mindenki elszór, a delay pedig minden embernél nagyobb, mint a másfél másodperces csúszás a telefonvonalban. Másrészt az agilis szoftverfejlesztés nem különít el hosszú tervezési szakaszt. A tervezési szakasz nálam a waterfall modell szinonímája. Aki ezzel jön elő, az általában valami olyasmit forgat a fejében. Aztán tipikusan a fejlesztés alatt kiderül hogy jajj, az úgy finoman fogalmazva is szuboptimális lesz, de akkor már bukó van, mert implementálni köll.

Aztán a harmadik észrevétel: egy-egy cég szokásait és procedúráit kitanulni időnként évekig is eltart, de legalább hónapokig. Én ha nagycég lennék, inkáb a belső emberek között keresném a leendő architektek legalább egy részét. Persze nagyon jól jöhet a más cégtől érkező tapasztalat is, de annak még jó sok idő, amíg kitapasztalja, hogy mi működik és mi nem működik valójában az új helyén.

Aztán még egy utolsó észrevétel a tanulással kapcsolatban: Nagyon jó, ha valakinek volt rá pár milkája hogy meghallgassa az Oracle/IBM/SAP/RedHat/Anyámtyúkja kurzusát, de az katasztrófa, amikor ezek után a kurzusok után, a fenti cégek technológiáit és termékeit lenyomkodja a fejlesztők, a cég, a kliens és a felhasználók torkán, ha jó, ha nem jó. Ilyet pedig már mindannyian láttunk. Én inkáb olyan emberrel dolgoznék együtt szivesen, aki nem csak az Anyámtyúkja technológiáit és termékeit ismeri, nem nyalta be a marketinget, hanem gyakorlati tapasztalatai vannak, látott elcseszett és pöpec projecteket. És ha ez megvan, akkor az architekt kurzus valószinűleg nem éri meg a pénzét.

Ö... oszt ennyi, na kitomboltam magam :-)

selinux

A selinux-szal kapcsolatban mindig volt egy olyan sejtésem, hogy az emberek többsége csak annyit tud róla, hogyan kell kikapcsolni. Erre utalt az is, hogy a gúglinak ha elkezded beírni, hogy selinux, felkínálja a népszerű keresések között a "selinux disable" lehetőséget. Ma hallgattam egy csákót aki a selinuxról beszélt és meglepetésemre tudott a problémáról. Az azért szimpatikus, hogy nincsenek illúziói... Aztán mutatott olyan selinux parancsokat, amiket 2 másodperccel később már nem tudtam volna leírni mert olyan rohadt hosszú volt.
Cifra szopatásnak vannak kitéve a desktop linux felhasználók, nem csoda hogy olyan ritka faj.