Sonar 1.4.2

Nem akarok kicsi freshmeat.net-et indítani a blogomban, de tegnap a sonar fejlesztői kidobták a 1.4.2-es verziót, ami végre javítja a framework furi adatbáziskapcsolati hibáját. A JRuby ugyanis nem szöszöl holmi DataSource-okkal, hanem valami saját megoldása van az egészre. (Ezen a ponton a dolog nekem nem szimpi) Fel is űbereltem és idáig tényleg nem zuhant magába. Melóban már az 1.4.0 verziótól kezdve gyüjti a projecteink coverage adatait, annyi volt vele a probléma, hogy egy cron jobból időnként újra kellett startolni.

Eleinte kicsit lelombozónak tűntek az eredmények amiket produkált -ezt a munkatársak érdeklődésére, a saját stabilítására, sebességére és a generált grafikonok görvéire egyaránt értem- viszont lassan úgy tűnik mind a három valahogy javulgat. Sok-sok türelmet tanulok mostanában.

Selenium bütykölés

Ez a selenium dolog nem új a nap alatt, ha jól látom a jhacks bejegyzés majdnem 2 éve született rá. Akkoriban próbálgattam, igazán rajtam kívül nem sok embert érdekelt körülöttem, el is halódott. Ezzel mondjuk sajnos nem szünt meg az igény arra, hogy az alkalmazásokat a felhasználói felületen keresztül is leteszteljük, csak szerencsére az azóta munkahelyemen van erre dedikált ember, drága pénzért furcsa szoftver, tesztgépekből rakott hegyek, ilyesmi. Azt lehetne hinni, hogy akkor ez már a paradicsom, valami mégsem volt teljesen oké. Ez a drága-pénzért szoftver ugyanis valami elég ütős összegért lett megvéve per seat (hmmm...) emiatt mi -java fejlesztők- nem kaptunk belőle, mindig a QA csapathoz kell tehát rohangálni ha valamit meg akarunk nézetni. Ennél nyilván ideálisabb megoldás lenne, ha az automatikus tesztek tényleg automatikusan futnának le, például minden alkalommal, amikor egy szintén automatikus folyamat bedobja a legfrissebb verziót egy alkalmazás szerverre, valamint a fejlesztők is írhatnának tesztet, nem csak a teszt-fejlesztők.
Erre találtunk ki egy kicsit más felállást, csupa ingyenes/OSS cuccra építve (igazából a CI szerver pénzes, de ez most nem számít, vegyük úgy hogy például hudson)

• Mindenki ír tesztet, a QA team csak annyiban kitüntetett, hogy ők mást se csinálnak :-)
• Minden SVN módosulás elindítja a UI teszteket. Hát igen, kicsit terheli a gépeket, na bummm...
• A CI szerver nyomonköveti a UI tesztek futását és értesít azonnal ha valamit elszúrtunk.
• Illetve mindenki lefuttathatja saját magánál is a teszteket a saját alkalmazás példányán.

Na, ennyi az előnye, nézzük a nehézségeket:

• Keresni kellett egy windows-os gépet, mert senkit nem érdekel hogy linuxon firefoxban jól működik-e a felület. Az már sokkal inkáb hogy az MS-IE bugjai között túléli-e. Egyelőre nem tudom hogyan kéne helyesen beállítani ezt a gépet, hogy például egy áramszünet után automatikusan bejelentkezzen rajta egy felhasználó és elinduljon a selenium szerver.
  
• Jó browser nincs, csak elég jó van. Valahogy a browserek, verziók, beállítások olyan sok hibalehetőséget jelentenek, hogy talán mintha nem is létezne univerzális megoldás. Az IE 7 + hta futtatás egyes gépeken nem megy (egyes gépeken az IE 7 sem például). Az IE 6 se sokkal jobb. Egyes pontokon mintha nem is ugyanazt csinálná, például nem hozza be a megfelelő oldalt. Nincs más kisérletezni kell. (A hta egyébként persze experimental állapotban van seleniumban)
  
• A browser problémákhoz képest a SSL problémák igazán semmiség volt, de rendet kellett tenni, ugyanis eddig nem volt rá motiváció, hogy korrekt https beállításokkal hajtsuk az apache-t.
  

sessionmeter

Tipikus eset, mint amikor a miliomost holtan találják a vitorlásán, Kolombó már onnantól kezdve csak az örökösével beszélget a filmben, mert tudja, hogy ő ölte meg. Ugyanez a helyzet a cluster teljesítménnyel is, az esetek nagyon magas százalékában a session a tettes. Ezt azért bizonyítani is kell általában, erről szokott szólni a hátralevő unalmas akárhány perc.
Gondoltam lerövidítem a következő bizonygatás hosszát és csináltam egy filtert, ami összediffeli a session-öd a kiszolgálás elötti és utáni állapotát.
Megjegyzések:

1. Nem túl processzor-barát, mert ahhoz hogy meg tudja saccolni, hogy változott-e a session attribútum, ki is kell szerializálnia. Ezt a container-ek másként csinálják, megjegyzik, amikor egy adatot elmentessz a session-be és akkor utána a teljes bean-t újra le kell majd replikálni a többi node-ra, csak ezt persze nem kötik az orrunkra. Régen tipikus hiba volt az, hogy valaki módosított egy session változót és aztán nem tette be a session-be újra. Ilyenkor az appszerver nem replikálta le, mert nem tudta hogy kell. 1 node-on elmegy, clusteren furcsa problémákat okoz.
   
2. Simán standard outra írja a kimenetet. Így csak 1 db jart kell bedobni a WEB-INF/lib alá.
3. Ami érdekes az egész kimenetből, az az hogy mennyi adat változott a session-ben, igazából az fogja a teljesítményt. Valami ilyesmit találtam ki neki, hogy minden attribútumra írja ki, az állapotát
   
   • NEW - a request kiszolgálása alatt jött létre,
     
   • DEL - azaz a request alatt a gondviselés megszabadított tőle
     
   • CHG - már megvolt, de változott
   • NOP - megvolt, de nem változott
     
   És persze az objektum kiszerializált méretét az egyszerűség kedvéért csak a kiszolgálás után, kivétel ha DEL persze.
4. Public domain, de igérd meg hogy soha nem felejted benne egy éles alkalmazásban! :-D
5. Még kitapasztalom és kitalálom hogy mi lenne mégjobb...
   

Forrás, konfig, bináris, satöbbi