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.

Hírek

A hét jó híre: Karenin tolja a JHacks híreit, szóval a régi közösségi események mellé mennyiségi és minőségi technológiai híreket is kaphatunk. Ez alkalomból lecseréltem a régi nagy böszme RSS ikont két kisebb XML ikonra, ott jönnek a hírek és a tartalomváltozások RSS-ben.

A nap első jó híre: a maven régi, sokak szerint elszúrt (szerintem is) XML formátuma, amiben csak tag-ek vannak de nincsenek attribútumok... Na ez most úgy tűnik lassan elmúlik a fejlesztő blogja szerint. A 2.0.9-től kezdve. Ez mondjuk nem holnap lesz, de remélem hamarosan.

A nap második jó híre: ráakadtam a sonar nevű alkalmazásra, ami egy érdekes frontend PMD, checkstyle, cobertura, surefire és stb elé. Nem ugyanaz mint a qalab, ez szerver komponens (viszont időbeli változásokat is figyel). Elösször is: semmit nem kell a project build leírásához hozzáadni, a maven pom.xml-jéből kitalál mindent amit ki kell. Mire nem jó, ugye, a deklaratív build... A statisztikákat egy tetszőleges adatbázisban gyűjti fel. Konkrétan az ami felgyűjti (egy maven plugin) az ennek az adatbázisnak a JDBC kliense. Én jobban szeretném az egészet, ha valami web service-n keresztül menne be az adat, és akkor csak egyet kellene mindenhol bekonfigolni: a sonar server URL-jét meg a firewallt se kellene bütykülnöm. Sebaj, végülis így is jó. CI szerverbe is simán be lehet lökdösni build definíciónak, és akkor van napra kész infónk arról hogy mi az ábra. QAlab done right :-)

Wikipédia - gráf

Szóval sokan meglepődtek rajta, de a wikipédia adatbázis dumpjai tényleg publikusak és letölthetőek (persze nem a felhasználók és jelszavaik). Ez most nem lesz túl tudományos: úgy 1 éjszaka alatt be lehet tölteni a scriptemmel PostgreSQL-be, az indexelés még úgy néhány óra. (Sokkal inkább proc- mint I/O-intenzív művelet, úgyhogy egy jobb géppel simán felezheted ezt az időt) A MySQL-be ennyi idő alatt nem sikerült, mert persze azt is próbáltam, csak nem ismerem annyira mint a postgrest és 3-4 nap után elfogyott a türelmem.
Valahol egy hack is került bele, mert a dumpban egy decimal oszlop méretéből kilóg már az első pár beinsertelendő érték is. Furcsa, ez a MySQL-nek nem tűnik fel?

Méretek:

• ~11millió page, nem sok helyigény, pár giga - Ebbe csak a legfrissebb oldal-verziók értendőek bele
  
• ~208millió pagelink, ez úgy 15 giga helyet zabált fel
  
• ~1.5 millió redirect (itt van némi kavar, a constraint-ek hiánya miatt)
• Valamennyi indexelés után úgy 40 giga lesz az ebből a pár táblából képezett adatbázis

Ennyi mára arról ami bárkit érdekelhet...

Ja és az Amex kiküldte a paypal tesztelésből származó tranzakciós logot postán, a4-es lapokra kinyomtatva. Szép vaskos boríták volt...