Heti helyzet

• Kijött a Sonar 1.2. Mostanában nagyon érdekel ez a szoftver és próbálom nyomni a munkahelyemen is. Sajnos maven-hez passzol igazán, ant-tal falábú, meg hát vannak neki egyéb korlátai is :( Viszont kezd nagyon jó cucc lenni, amikor a korlátok nem zavarnak.
  
• Egy kis Drools prototipus projectett tervezgetek. A melóban a kódunk legnagyobb része az üzleti döntési folyamat lekódolva, mint mindenkinek. Majdnem mindenkinek. Persze így is le lenne kódolva, csak legalább nem a flow logikában :)
• AMF data push-hoz kisérletezek valami általánisított megoldást, hogy körülbelül spring applicationContext-ben lehessen megmondani - interceptorral persze-, hogy melyik metódus hívása milyen csatornára küldjön update-t. Ezzel használhatjuk a primitív DAO osztályainkat tovább, amiket esetleg más projectekből vettünk át. Az adatok real-time replikálódnak DAO-t éppen használó a kliensekhez, annélkül hogy ehhez blazeds-specifikus kódot kellett volna belegyűrni a logikába. Na ennek is meglesznek a maga korlátai :)
  

JUM

JUM, 2008 március 19, BIX

Elsőként Sragli Attila beszélt a Java komponens architektúrákról. Nekem ez egy kicsit túl általános volt, semmit nem tudtam meg az OSGi-ről és a SCA-ról, csak hogy vannak ilyenek. Pedig érdekelne, mert hülyének érzem magam a témában.

Aztán én hordtam össze mindenfélét a Flex-ről, az OpenLaszlo-ról és a BlazeDS-ről azzal a kis prototype projecttel kapcsolatban amit feltettem a JHacks-ra, mellesleg itt van a prezentáció anyaga is. Fel akartam venni hogy visszahallgassam. Utálom a saját hangom, de legalább okultam volna belőle. Ez nem jött össze, az összes többi előadást sikerült felvennem, de a sajátomhoz a diktofonomat kellett használni pendrive-ként és sajnos egyszerre csak egy dolgot tud :-( Úgyhogy nem tudom mennyi gondolatot sikerült megmozgatnom és kit mennyire érdekelt, de szerintm belefértem a 10 percembe, úgyhogy nem raboltam sokat az emberek idejét. Nem vagyok biztos abban, hogy a quickie műfajt jól képviselem a JUM-on, de remélem, hogy lassan fejlődgetek benne :)

Sajnos a Appserver Deathmatch nem jött össze teljesen, a SUN-os srác eljött, az IBM-es lemondta, a JBoss-os vagy nagyon késett vagy valami ilyesmi, de nem tudtam megvárni :(
Ennek ellenére amit Karenin és a Sun-os srác mutatott a glassfish-ről az elég frankó volt. Az még igazából nagyon érdekelt volna, hogy sima command line-ból mennyire menő dolog bütykölni a glassfish-t és logging kürüli problémákat nem teljesen értettem, soha nem használtam a java logging apit, log4j vagy muszájból commons-log.

Talán az lenne jó, ha jórészt a rendezvény résztvevői adnák a konferencia tartalmát, legalábbis a vitafórum amit Tvik tartott egy JUM-on az szerintem teljesen feldobta a hangulatot. Csak akkor meg arra kell figyelni hogy ne legyen két ember párbeszéde az egész. Kicsit próbálom húzni a JUM-ot egy inkáb uncfonference találkozó felé. Mondjuk nem vagyok komoly tényező, de átgondolhatnánk hogy kicsit gördülékenyebben menjenek a dolgok. Amúgy mindenkinek otthon van a feleség-félesége, az aranyhalai, a fusimelója, stb, biztos a maxmális mennyiségű infot akarja megkapni a legrövidebb idő alatt.

Flash kommunikációja egy backenddel AMF protokolon

Csináltam egy flex 2.x-es projectet maven-nel, erről a melóhelyemen tartok majd beszámolót, de itthon haxoltam, úgyhogy nyugodtan nézzen bele akit érdekel. Összetargézézve 5K :)

Ez van benne, csak hogy összefoglaljam:

1. Spring inicializál egy POJO-t, ez a greetingDao. Tud egy pár köszönést, mint Hello World, ilyesmi...
2. A spring contextet a BlazeDs egy adaptere segítségével bemutatjuk a BlazeDS konfigjának. Ez idáig csupa móka.
3. Persze a web.xml-ben a BlazeDS egy szervlete be van regisztrálva, ez evidens...
4. Na viszont ott a másik project, a bp-flex, itt van a Flex forrás. Ez egy RemoteObject-kent mutat az 1. pontban említett POJO-ra.
5. Adtam távoli metódusonként 1 callback-et, hogy amikor visszajön az üzenet akkor meghívódjon és updatelődjön (imádom a hunglish nyelvet) a view.
6. Ez pedig persze Flex databinding-gel van odabetonozva, ha bárki fennakadna azon, hogy mi a túró az a [Bindable]
   

Mivel nagyon nem vagyok kliens oldali hegesztőművész, erről az utolsó 3 dologról a következő napokban még kérdezgetem azokat akiket viszont annak tartok :)

Ha akad még időm valamikor kiteszem a hasonlóan vaskos funkcionalítású Web Services (XFire) kommunikációval működö prototípust is.

Amitől continuous az integration

Egy continuous integration szerver -szerintem- ott válik el egy sima nightly build cucctól, hogy nem egyszerűen csak lebuildeli a cuccod, hanem a különböző modulokból amiket fejlesztessz, abból egy éppen aktuális verziót rak össze és azon futtajta a teszteket.
Két megvalósítás...
A teamcity-ben lehet manuálisan beállítni project függőségeket, a build végén az eredményt (a jart) beletolja az új projectbe és azzal is leteszteli azokat a projecteket amik ezen a projecten függenek. Ant projectek esetén ez egyszerűen csak nem lehet jobb. A maven projectek közti függőségeket TeamCity-vel még nem néztem meg, de manuálisan biztosan azt is be lehet állítani ugyanígy.
Na és akkor elmondanám a másik megoldást: Continuum + maven, a continuum a pom alapján felismeri a két project közti függőséget. Ez a rövidebb és egyszerűbb dolog :-) Ant esetén nem tudom mi van, de a saját fejlesztéseimben nem használok antot.

A TeamCity és a Continuum további lényeges különbsége, hogy a TeamCity webes felülete piszok jól néz ki, ezért a munkatársak jobban szeretik. A szép dolgokról könnyebb elhinni hogy hasznos.

A lélek fogaskerekei

Még a javapolison a kedvezményes könyvesboltban halásztam ki SOA, Web Services és Design Patterns könyvhegyek mögül Steve Tallbot Devices of the Soul című könyvét. Magyar nyelven sajnos nem jelent meg, a fenti cím pedig a saját fordításom.

Azt a téveszmét boncolgatja benne, hogy a techikai fejlődés jobbá teszi az életet. Van pár dolog benne amin lehetne vitatkozni az íróval, de összességében véve azt hiszem egy fontos problémát tárgyal érdekesen és részletesen. A könyv információi nem avulnak el párszáz éven belül ha csak ki nem hal az emberiség, ezért inkáb ilyet vettem. Gondolatébresztőnek ajánlom mindenkinek.
Az éppen aktuális buzzword technologies könyvet pedig elolvasom a céges safari accounton :)

Dolgok mostanában

Nem szeretnék senkit sem fárasztani azokkal a kalapálásokkal amikkel életben tartunk rendszereket a munkahelyünkön, mert az többnyire távolabb áll az ideálistól mint az otthoni hobbiprojektek. A web alkalmazások konfigurációja az viszont szerintem közös gebasz a két témában.
Néhány évvel ezelött repült fel nagyon az IoC biznisz, akkor még különcnek számítottam, hogy ilyeneket akartam, hogy ne a saját kódom (azaz én) bajlódjon a konfigurációjával hanem valaki egyszerűen csak adja neki oda. Azóta változott a helyzet, már annyira mainstream, hogy mindenki alapból bénának számít, aki nem használ valamilyen IoC rendszert.
Ezzel a komponensek írói eljutottak a kánaánba és ha nekem is csak ennyi lenne a dolgom, akkor nyugodtan hátradőlhetnék. Csakhogy mostanában a 'testing', 'staging' és 'live' deploymenteket is végig kell küzdjem, ráadásul nem csak a saját projecteimét és igazából nagyon nagy hiányérzetem van a folyamat bizonyos pontjaival kapcsolatban.
Például a spring applicationcontexnél tipikusan be szokás regisztrálni egy PropertyOverrideConfigurer objektumot, amivel már nem az applicationcontext-ben, hanem egy külső properties file-ban tarthatjuk az alkalmazáspéldányonként változó konfigurációs adatokat. Ilyeneket mint JDBC URL, web services backend URL, különböző path-ok... Ezek után ezt hova is tegyük? A legnépszerűbb hely hozzá a classpath.
Egy webapp esetében a classpath lehet a WEB-INF/classes, így tényleg csak erre a webappra vonatkozik az ami benne van és senki más nem is fog hozzáférni. Én ezt azért nem szeretem, mert szeretném úgy odaadni a webapp filet, hogy az egy war, tessék az előző war helyébe odatenni, és a műsor megy tovább.
A problémára megoldás lenne az, hogy a parent classloader alá dobjuk oda a konfigurációs file-t, ez viszont nem lehetséges abban a -ritka- esetben, amikor például ugyanazt a webalkalmazást szeretnénk több példányban más konfigokkal hajtani egy gépen. Az sokkal inkább fáj, hogy meg kell patchelni a futáskörnyezetet, ilyet sem szeretek csinálni.

Végigkérdeztem pár régi kollágát és mindenki a fenti kettő közül az egyikkel dolgozik.

Egy apró szépítés talán ilyesmi lehetne: a parent classloader alá tesszük a properties file-t, mégpedig a context nevével (remélhetőleg a virtual hostokkal nem lesz ütközés) és percek alatt lehet olyan PropertyOverrideConfigurer-t összedobni ami ez alapján keresi ki a properties file-t. Ezzel még közel sem oldottuk meg azt a problémát, hogy mi legyen azokkal a komponenseinkkel amik ragaszkodnak a saját property fileukhoz a classpath-on, de ez már tényleg szarból fellegvár lenne.

Viszont ez még mindig valami saját megoldás keresgetése. Nem kellene az általános problémára valami általános megoldásnak lennie? Vagy csak nekem nem elég jó az, ami van?

Szétnéztem, hogy mivel lehetne betömni ezt a rést. A JMX az talán az lenne, a springnek van is szép JMX supportja, ki lehet vele exportálni a saját MBean-jeinket, utánna pedig tetszőleges JMX felületen keresztül beállítgathatjuk a tulajdonságokat. Ez a startoláskor nem fogja felülírni a bean-ek tulajdonságait, futásidőben nem igazán szeretnénk rajta babrálni, lementeni sem fogja nekünk, szóval ezzel nem vagyunk közelebb.

Búcsú a junit 3-tól

Milyen teszt framework-öt használsz a saját projecteidben?

Volt egy ilyen szavazás is, köszi mindenkinek aki szavazott. Ezek lettek az eredmények:

Junit 3.x	0 (0%)
Junit 4.x	6 (50%)
TestNG	2 (16%)
Ufó-technológia	2 (16%)
Nem junit tesztelek	2 (16%)

Junit 4.x teljesen feljött a testNG-hez képest, pedig a testNG korábban startolt az annotációkkal. Azt hiszem ennyire számít hogy van-e valamihez eclipse support. Persze a testNG-hez is van, csak korántsem olyan frankó mint a junit-é.

A boldogság zöld csíkja.