Csúnya de okos

Régebben maven artifactok kereséséhez a mvnrepository.com szolgáltatását használtam. Sajnos ez mostanában rémesen belassult (mainstream lett a maven?) és hébe-hóba egy-egy reklámcsíkkal is megdolgoztatja a firefox adblocker pluginját.
Viszont mostanában bukkantam rá a jaclaz.com oldalra. A kinézete alulmúlja a google designt, viszont egész értelmes dolgai vannak. Lehet osztályokra és packagekre is keresni, megmutatja a javadocot és a forráskódot is. Szóval mindenképpen biztatóbb mint a mvnrepository mostanában.
Egyébként ezt a kereső trükköt a legtöbb maven proxy is tudja, csak nekem nincs ilyen.

JUM

Ez volt tegnap este. A sztakis keverés miatt a Sun-nál. A létszám 15 és 20 között, szerintem a helyszin probléma miatt csak a nagyon elszántak jöttek.

Elösször Elek Márton beszélt a REST-ről és a JSR-311-ről. Elég egyszerű és tréfás megoldásnak tűnik, lehet lenne helye bevetésnek, csak még elöbb körbejárnám. A maven-glassfish megoldás viszont engem meglepett, hogy milyen gyorsan felszállt. Én jetty-t használok mavenben, meg fejlesztéshez inkáb az eclipse WTP-t tomcat-tel.
Aztán Dorothy mesélt nekünk a Jazz-ról, amit már régóta figyelek mert jó ötlet, de IBM cucc és az ilyenekben nincs sok hitem, meg hát elég drága is.
Végül Auth Gábor mutatta be a glassfish v3-at, nekem mondhatni teljesen új volt mert a v2-t se használtam valami sokat. :-)

Legközelebbre bevállaltam egy pár perces előadást a scrum-ról.

Auto mate

Egy rossz élményemet leírnám ide a Continuous Integration témában, hogy erre esetleg vigyázzatok és próbáljátok meg elkerülni.

Abban az esetben, ha nálatok is minden csapat kitalálhatja magának hogy milyen build környezetet használ és esetleg bizonyos speciális dolgokat is beleépítetek (windowsos path-ok a build.xml-ben, exe fileok és más platform függő binárisok valahol a projectben, különleges classpath beállítások, környezeti változók, és a többi mocsokság), akkor a CI szervereteknél hamar felmerül az igény arra, hogy mindenkinek külön beállított build agentje legyen, amin az ő buildjei futnak. Egy kicsivel később már el is tulajdonolja egy-egy csapat ezeket a build agenteket és nem közös erőforrásként tekint rájuk, hanem inkább magántulajdon. Innentől kezdve egyes agentek majdnem teljesen kihasználatlanok lesznek, míg mások egész nap pörögnek, egyes csapatok csak másnap reggel kapják meg az eredményeket, mások azonnal.

Ez szerintem elég rossz irány és nagyon nehéz visszacsinálni ha egyszer megtörtént. Valamennyire le kell rendezni mindenkivel, hogy a buildje nem tartalmazhat speciális külső, hivatkozásokat és nem várhat el különleges beállításokat. Azaz ami kijött a verziókövetőből, annak úgy le is kell fordulnia akármilyen platformon. Persze megfelelő JDK és Ant és vagy Maven persze kell hozzá, de a megállapodás fontos. Talán még a legelején érdemes mindenkivel leüzletelni az egészet.

Szolgálati közlemény: Holnap elvileg JUM, legalábbis remélem mert már régen nem volt és ránk férne egy pár ötletcsere. Aki jó fej, az segíthetne egy 20-40 fős teremmel :-)

Getter és setter tesztelése

Igazából soha nem törekedtem 100 %-os test coverage-re, olyan evidens dolgokat mint getterek és setterek és egyszerű konstruktorok eddig eszembe sem jutott tesztelni. Ma viszont az utamba került egy bean, ami elég izgalmas viselkedést tanúsított ahhoz a rémunalmas dologhoz képest amit elvárok a fajtájától. Arra gondolok hogy ha beállítok egy tulajdonságot, akkor az legyen beállítva és ha utánna kiolvasom, akkor ugyanaz mint amit beállítottam. Egyéni ízlés kérdése, de én aknamezőnek érzem ha egy adat reprezentációra szánt osztály ettől eltérően viselkedik.

Úgyhogy írtam az összes bean-re egy tesztet, ami PropertyUtils-szal végigrohan a tulajdonságaikon és beállít valamit és megnézi hogy az érték be lett-e állítva.

Ennyi, a kód nem érdemel egy copy-pastet sem, inkáb csak ötletet akartam adni a test coverage eredmények szépítésére :-)

További kellemes pénteket mindenkinek!

Egy hónap scrum

Nincs hír. Körülbelül egy hónapja álltunk át scrum metódikára. Lement teljesen két sprint, volt két retrospektív meeting a sprintek végén hogy megbeszéljük a tapasztalatainkat és legnagyobb meglepetésemre még mindig nagyon jól megy és mindenki jól érzi magát.
Csak egy komoly veszély fenyeget: kifogyunk a szines cetlikből, amikre a feladatokat írjuk. Ha a következő egy hónapban valami meteor nem csapódik be, akkor tulajdonképpen szerintem el is fogjuk felejteni hogy ez valaha másként működött.

UI-testing TV

Akadt egy felesleges TFT és kitettük egy helyre, ahol mindenki látja, rákötöttük a selenium szerver gépre és most lehet rajta nézni a UI teszteket. Konkrét haszna csak annyi van, hogy kicsit segít a csapat figyelmét a tesztekre fókuszálni.
Elneveztük TV-nek, aki bebambul az nézheti ahogy pörögnek rajta az oldalak.

Egy kis BDD

Újra itthon, több mint egy hétig mászkáltam mindenfelé és közben tanulgattam dolgokat. A legtöbbnek ezek közül a világon semmi köze nincs programozáshoz a nevükön kívül.

Viszont akadt kis idő arra is, hogy beszélgessek emberekkel az integration test megoldásaikról. Én igazából erre is tök egyszerű junit 4.4-et használok és nem fáj különösebben. Valami fény végre derengeni kezdett viszont arról is, hogy akik fitnesse-t hajtanak, azok miért szeretik. Korábban ugyanis sikerült rendesen félreértenem a dolog lényegét, csak annyit láttam belőle hogy valami furcsa wiki engine-t kell felstartolni érdekesen összehaxolt classpath-szal és majd az lefuttatja a teszteket. Ez a pontja még most is rém ellenszenves, de ez csak esztétikai kérdés.
A lényeg az lenne inkáb, hogy program írása nélkül, wikiből editálva építheted az integrációs tesztjeidet. Ez a wiki nem kell hogy egy központi szerver komponens legyen, felstartolhatod magadnál is, vagy ha nem komállod a felületét, írhatod egy sima text editorból is (ami talán kicsit barátságosabb is mint maga a wiki). Így nem azt írod le, hogy hogyan kell a kódodat letesztelni másik kóddal, hanem egy felhasználói történetet. (Azaz story, csak magyarítok újabban) A történet táblázatokból és kommentekből áll, a táblázatokat úgy nevezett fixture-k mondják meg, hogy hogyan kell őket felhasználni. Például az utolsó oszlop az elvárt eredmény, az többi a paraméterek, legegyszerűbb esetben. Azaz a wiki tartalma a fixture-kkel együt mondja meg, hogy hogyan kell a kódodat letesztelni :-)
A fitnesse-maven integráció a srácok szerint akkora gebasz, hogy jobb róla nem is beszélni. Úgyhogy valami kis custom ant+maven dolog van belőve.

Csak hogy ne legyen az, hogy akármit bekajálok amit vendéglátóim adnak, átfutottam pár könyvet agile testing témakörben és szétnéztem hogy mi a helyzet más megoldásokkal, és a diszkóblogos srác easyb projectjébe már sokadszor botlottam bele, sikeresen túl is jutott az ingerküszöbömön végre és kipróbáltam hogyan műxik. A meséket itt körülbelül groovy-ban írod, ami elég egyszerű szintaxis, még eclipse plugin is van hozzá (bár nem sokat ér szvsz). A webes wikis dolog a fitnesse-ben szerintem nem különösebben nagy érték, ha érték egyáltalán, ugyanis a nem technikai project tagok azt sem fogják tudni csinálni helyettünk. Úgyhogy a maven-integráció (működik) és az IDE support azért egyelőre mégis inkáb ebbe az irányba terel.

Ennyi van most, aztán kiderül később, hogy hogyan és merre tovább. Csinálok pár prototype projectet és megpróbálom beilleszteni más projecteimbe.