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.