Command line CI

Friday, September 17th, 2010 | Uncategorized | No Comments

Az elmúlt hetek legjobb híre az volt, hogy megjelent az Amazon EC2 gépek közül a micro méret. Ebben csak 600 MB memória van viszont az ára is ehhez van mérve (2 cent/óra). Ez már elég kedvező, gyakorlatilag pár ezer forintért lehet futtatni teljes értékű szervert.

Jelen blog is éppen egy AWS példányon fut valahol a tengeren túlon (ezt persze az éles szeműek nyilván észrevették az IP címváltozásból is).

A 600 MB viszont bölcs takarékosságra neveli az embert. Apache Httpd helyett lighthttpd + mysql + alaprdendszer, ez körülbelül 100-150 Mb-t eszik. Egy Hudson körülbelül ugyanennyit alapjáraton, de azt gyanítom a pluginekkel és projektekkel még hízik.

A Hudson amúgy szerintem az egyik legjobb Java-s alkalmazás. Nagyon sok részéről süt, hogy ezt használatra találták ki. Pl. webes felületen keresztül frissíthető, telepíthető bele plugin. Tisztára mint egy jó értelemben vett termék.

A 600 MB memóriámnak a negyedét viszont lehet, hogy sajnálnám tőle. Elkezdtem gondolkozni egy command line CI szerveren. A cron töltené be az ütemező szerepét az hívna meg valamilyen (script?) nyelven implementált kis belső magot, ami ellenőrizné, hogy van-e változás az SCM-ben, és ha van elindítaná a fordítást. A fordítás eredményéről értesítéseket küldene, és statikus HTML oldalakat generálna. Végül is a buildek eredménye bőven elég statikusan.

Eddig (kis keresgélés után) találtam is egy ehhez hasonlót Cerberus néven. Igaz egyelőre elég alap funkcionalitással bír, pl. HTML oldalakat nem generál, csak értesít, de talán kiindulásnak jó lesz. Forkolni kéne egy üres órámban.

Tags: aws, cerberus, ci, hudson

Maven, Release, Hudson

Tuesday, July 27th, 2010 | Uncategorized | No Comments

Az ideális releaselés minimum követelményeit így képzelem:

1. A release automatikus (egy gombnyomásra történik) és a CI szerver készíti el
2. hiba esetén újra lehet indítani
3. nem befolyásolja közben a fejlesztést (nincs commit csönd)

Alapvetően sose voltam nagy barátja a Maven release pluginnek, kicsit merevnek tartottam, de hosszas kísérletezés után legtöbb esetben még mindig ez tűnt a legkevésbé problémás megoldásnak. Kicsit kell figyelni a pom-ok felépítésére, de az még jó is, ha tisztább pomokra kényszerít. (Egyébként a forrása is viszonylag kellemes csalódás volt, egész szép, leszámítva a modellos fejlövéstől, amit az előzőekben már felhánytorgattam).

Ha a maven release plugin már adott mint eszköz, akkor még mindig van néhány nyitott kérdés:

1. trunkon vagy branchen?

A kedvenc koncepcióm a tárgyban itt olvasható. (Git-ről beszél, de Mercuriallal ugyanúgy használható). Ez egyértelműen azt javasolja, hogy külön ágon releaseljünk. Ez egy kicsit megbonyolíthatja a release folyamatot, de amellett előnyei is vannak:

1. a hármas pontot alapból kielégíti. A release branchre rámergáljuk a trunkról a stabil változatot, és release közben már senki se ronthatja azt el.
2. lehetőség van arra, hogy ne csak a trunk ágat, hanem más ágakat is releaseljük. Ha egyszer a release ágon működő release-gép tökéletes, akkor csak azt kell elérni, hogy bárhonnan a release ágra mergeljünk bármilyen kódot (akár egyoldalú merge-vel, ahol minden fájlból a külső branchen lévő változatot tekintjük alapnak).

A .2 pont persze már eltér a fenti linken található ábrától, amely ábra külödben sem is használható tisztán maven release pluginnel, mivel pl. a tagelést a plugin egyértelműen a release branchen végzi. A 2-es pont szerint a release branchünk igazából csak egy staging hely, ahová felrakhatjuk a kódot, amíg a release sikerül, és a mikor ténylegesen kész lesz, akkor vissza mergelhetjük.

2. külön release job a hudsonban vagy nem?

Ha használjuk a trunk mellett a release branchet is, akkor rögtön jön a probléma, hogy a hudsonon alapból a trunk branchet akarjuk buildelni, de releasekor a release branchet. Ezt a hudson egy kicsit nehézkesen kezeli. Léteznek workaroundok: pl. m2 extra stepst-ben hg parancsok, vagy paraméterezett build, ahol a paraméter alapján checkoutol, de a gyakorlatban nekem egyik se bizonyult stabil megoldásnak (az átláthatóságról nem is beszélve).

Az egyszerű megoldás, amit épp követünk, új jobot hozunk létre a Hudsonon. Klónozzuk az eredetit, és az új job az előzőekkel megegyezően működik (változás esetén sajnos mindig frissíteni kell a build paramétereket), de a release branchet forgatja (célszerűen private local maven repository-t használva!!).

A külön job-os megoldás arra is jó, hogy a release branchre való merge után még egy utolsó ellenőrzésként egy hagyományos buildet is kérhetünk az ágra, mielőtt a release build-et kérjük a hudsonból

3. M2 release plugin vagy általános release plugin?

A Hudsonban két release plugin is van. Egy általános és egy kifejezett Maven-re szabott. Mindkettő azt nyújtja, hogy megjelenik egy új gomb is a job oldalán: a build now mellet lesz egy start release build opció is.

Az általános release pluginban  pre-steps és post-steps lehetőségek vannak. A release build gyakorlatilag egy rendes build, csak a post f’ázisban tetszőleges múveleteket (pl. release:prepare release:perform) is elvégezhetünk. Sajnos a Hudson korlátai miatt a post lépések mindenképpen lefutnak még akkor is, ha a rendes build elhalt, ami nem túl elegáns.

Az általános release pluginnak viszont kellemes szolgáltatása, hogy a release buildet tartóssá teszi (keep this build forever) és meg is tegeli. Így a job lefutásai között egyértelműen látszik, hogy melyik volt a release.

Egyelőre én mégis a Hudson M2 release plugint használom. Ez kifejezetten Maven releasere lett kitalálva, tehát korlátozottabb tudású, azt viszont jól csinálja, és nem kell trükközi post stepekbe rejtett release logikával. A sikeres release buildet aztán kézzel tartosítom (keep build forever).

4. staging scm vagy éles?

Az egyik problémája a release pluginnek, hogy elosztott SCM esetén nem csak commitol, hanem pushol is. Ha a release mégsem sikerül, akkor is teleszemetelte a repónkat mindenféle saját committal. Erre ad egyfajta megoldást Fabrizio Guiduci. Ennek lényege, hogy a release alatt egy profile/property trükkel az aktuális scm bejegyzést egy temporáls repositoryra állítja át, így oda fog pusholni a release plugin. Amennyiben a release sikeres volt, akkor a staging repositoryból lehet pusholni az élesbe.

Volt, ahol használtam ezt a trükköt, de ma már úgy látom, hogy nincs nagy jelentősége. Egyrészt mivel külön release branchen releaselek, ott nem zavarnak a felesleges commitok annyira. Legrosszabb esetben hg backout-olok (remek parancs, egy adott commit diff-jét invertálja és commitolja újra be.) Git-be meg ugye alapból lehet changeseteket törölni.

Másrészt mivel a Hudson-on a release branchre rá van állítva a release job, amit release előt még sima buildel ellenőrzök, az esetek nagy részében a releasenek már hiba nélkül kell lemennie. (Általában hiba ebben a fázisban már csak akkor merült fel, ha pont a pusholás volt sikertelen)

5. staging repo vagy éles?

Az előbbi linken nem csak a mercurial repositoryból csinált stage-et az író, hanem a cél Maven repositoryból is. Kezdetben csak egy temporális helyre deployolt, és ha minden jól ment, akkor onnan egy maven pluginnel tolta fel a végleges helyére a buildelt artifactokat.

(Egy kicsit kidolgozottabb staging koncepció is létezik, amit a Nexus Pro támogat.)

Eddig az volt a tapasztalatom, hogy ilyenek nélkül elég jó tudok élni. A deploy a release:perform utolsó lépése, tehát ha felmentek az artifactok, akkor a release már jó volt, ha nem ment fel, akkor még gyűrni kell. De olyan eset eddig nem volt, hogy felment, de le akartom volna szedni.

Egyéb tapasztalatok

1. A maven release plugin nem szereti, ha elosztott verzió kezelőt használunk és nem a gyökérben van a pom.xml. A release:perform lépésben ugyanis a target/checout könyvtárba az egész repót klónozza, de arra nem lehet rávenni, hogy a repó egy alkönyvtárát buildelje csak meg. Botrány.

2. A release:prepare lépés során történik egy ellenőrzés. A checkoutolt source-on a maven futtat egy clean verify kombót. Ez kellemetlen meglepetésekkel szolgálhat, ha az alprojektek kézileg össze vannak kötögetve. (Pl. dependencies:unpack). Ekkor a nagyerejű -DpreparationGoals=”clean install” segíthet.

A többi meg már megy magától.

Tags: hudson, maven, mercurial, release

Modello, Maven

Tuesday, July 20th, 2010 | Uncategorized | No Comments

Egyszer már kitaláltuk egy kolegával (talán már le is írtam), hogy csinálni kéne egy kiégett Java blogot, ahol minden bejegyzés keserű kiábrándultsággal ostorozna valamilyen Java terméket vagy technológiát (user name: Thomas Bernhard). Az esetek nagyrészében bármilyen jó is legyen a program, fogást jó eséllyel lehet találni rajta.

A Mavenről pl. kevés ember hiszi, hogy egy jól megtervezett alkalmazást. Roszmájúak szerint csak egy kicsit kellett volna gondolkozni mielőtt elkezdték volna fejleszteni. Reálisabban úgy is lehet fogalmazni, hogy azóta mindenki sokat tapasztalt már a build tool businessben, ma már nyilván ezen tapasztalatok fényében jobb build tool-t lehet írni (hello gradle, hello buildr), de az utat kétségkívül a Maven taposta. És az is érthető, hogy amikor kezd de facto ipari standard lenni a Maven használata, akkor a Sonatype-nak nem érdeke egy nagy nem-kompatibilis refaktor. (Jó ilusztráció pl. a plexus IoC konténer használata, mivel amikor a Mavent elkezdték kalapálni a Spring nem volt még tényező, a Guice-ról még el se gondolkoztak. Viszont néhány ügyes varázslattal elég jó eredményeket értek el a Sonatype-osok a plexus>guice migrációban, úgy hogy minden visszafelé is kompatibilis maradt).

De igazából nem is a Mavenről akartam írni, hanem Modello-ról. Azt is eltudom képzelni, hogy eredetileg volt valami érv a  használata mellett. De így kívülről a partvonalról nehezen tudom elképzelni ezeket az érveket. Azt értem, hogy mindenféle XML writer/reader-t generál, de ezekre azért vannak már dinamikus frameworkok is. És csak ezért felvenni a kód generálás keresztjét, mert akkor dom4j writer-t nem kell írni… Hát, nem tudom.

Ma pedig pont a maven release plugin patchelése közben találkoztam egy szép MDO-val. Na ezt az XML-Java turmixot magyarázzal el nekem valaki.

Tags: maven, modello, wtf

NoSQL házi helyzetjelentés

Tuesday, July 13th, 2010 | Uncategorized | 2 Comments

Az előző posztban vázoltam egy feladatot, amiben NoSQL adatbázisokba dolgozom fel az OSM térképadatait. Az aktuális kód elérhető a bitbucketről, az alábbiakban néhány megjegyzés hozzá, minden rendszer nélkül:

1. Az OSM adatszerkezete egyszerű, három típus van: node (egyetlen pont a térben), way (nodeok halmaza, lehet nyílt és zárt is), relation (nodeok és way-ek halmaza). Persze mindegyikbek van földrajzi koordinátája és kulcs érték pár típusú attribútum halmaza.

2. Jelenleg Magyarország hozzáférhető térképadataival dolgozom. Ebben nagyságrendileg 900 ezer node és 80 ezer way van.

3. Backendnek első körben a MongoDB-t kezdtem el használni. (Ákosnál épp olvasható róla egy rövid bevezető)

4. Betöltéshez az Osmosis programot használom. Ez tud az OSM export XML-ekkel dolgozni, illetve ezeket  transformálni is tudja. Elég ügyesen meg van írva: pipe-ok vannak benne, és ezeket lehet egymás mögé tenni. Én egy egyszerű pipe-ot írtam, ami tetszőleges helyről származó OSM adatokat (nálam egy xml reader pipeból származókat) tölt fel mongodb-be.

5. A forrás XML 100 Mb. A betöltendő adatok nagyságrendjét már írtam. A betöltés néhány másodperet vesz igénybe.

6. A MongoDB szinte az egyetlen olyan NoSQL DB, ahol van geospatial index is. Ez egyszerű feladatokhoz elég jó, de komplexebb lekérdezésekhez már nem elegendő. Mivel más NoSQL adatbázisokat is akarok használni backendnek, ahol még ennyi sincs, ezért kézzel kell implementálni hozzá indexet.(*). Ehhez találtam egy nyílt Java-s rtree implementációt. Az rtree nem a leggyorsabb algoritmus, de egy elég jó alap megoldás, ami kezdetnek jó lesz.

(Megjegyzés: *. A kézzel írt kvázi indexelés nagyon jól mutatja a NoSQL lehetőségeit. A NoSQL csoportba sorolt adatbázisok általában sebességben verik a relációs elődöket, de cserébe  kompromiszumokra kell számítani. Egy jól meghízott RDBMS sok olyat is ad, amire nincs is szükségünk, de az is előfordul, hogy a NoSQL kőbalta szintjére saját magunknak kell valami ottani szolgáltatást implementálni. Pl. programozás technikákkal gondoskodni kell, hogy tranzakció nélkül is konzekvensek legyenek az adatok. Ez persze plusz munka is lehet, meg szemlélet váltás is, de onnantól pedig egyedi megoldásra egyedi program jó eséllyel versenyre kelhet egy sokkal komplexebb és okosabb, de általános megoldással).

7. Az RTree implementáció nem rossz alap, de nincs felkészülve külső adattárolókra, márpedig én MongoDB-be szerettem volna tárolni az rtree-t, hogy lekérdezés esetén annak segítségével találjam meg egy adott területen elhelyezkedő összes elemet. Ezért kicsit átalakítottam. Az átalakításban alapvetően a gyors eredmény számított, nagyon ráférne egy kis optimalizálása (habár az algoritmus eredetileg a memóriában végzett műveletekre nagyon optimalizálva van, már talán túlságosan is. Pl. az Integer osztályok példányosításának a számára is figyelt az alkotó).

8. Az rtree indexelés remekül lefut. A gond ott van, hogy ha egy meglévő adatbázisra (800ezer bejegyzés) futtatom le, akkor a teljes indexelés 4 órát tartott (persze nincs optimalizálva, hanem egyfolytában a MongoDB-hez fordul). Megoldásként első körben a memóriában rakom össze a fát, és utána perzisztálom. A fa kiszámolása fél percet vesz így igénybe, a perzisztálás másodpercnél hamarabb megvan (34 ezer index rekord)

9. A végső próba úgy néz ki, hogy a JOSM nevű grafikus térkép rajzoló programban átállítom a szerver kiszolgálót a saját megoldásra, ami REST alakú lekérdezéseket küldd, és a válaszban érkező pontokat kirajzolja és szerkeszthetővé teszi. (a visszatöltés jelenleg nem célom). A mostani állapotban azt értem el, hogy ez működik, de csak node-okra (a nagyon optimális rtree sajnos még nem tudja kezelni, hogy létezhet node és way ugyanazzal az id-val), és az attribútumokat nem tárolja még.

10. A szerver oldal egy JavaEE6-os JAXRS-es alkalmazás. A JAXRS elég könnyen használható, de kell hozzá stabil JAXB-s ráhangoltság. Ott vannak félelmeim, hogy a nagyméretű adatkiszolgálásnál , hogy az eredményt tudja streamelni. Szerintem nem tud, ami miatt féltem kicsit a memóriát, de ezt még meglátjuk, hogy meg akarom-e oldani.

11.A MongoDB-ről néhány személyes élmény a teljesség igénye nélkül

• elég kényelmes használni, jó a command line interface-e is
• rendszeresen lelőttem futó db alól a laptopomat (érstd az áram kikapcs akkumulátor nélkül) és elég jól túlélte
• nagy szabadság, hogy nincsen séma benne, és mégis elég jól indexel
• valamilyen O(R)M jellegű mappolás nélkül elég fapad a Java API-val használni. Léteznek ilyenek, de én nem használtam, mert 800ezer rekodrnál már számít mennyit refletionözök. Így viszont elég szegényes.
• Clustert még nem próbáltam, viszont a leírás alapjáns csak master-slave replikációt. (helló, magas rendelekzésreállás, helló). Tulajdonképpen ez az, mi miatt leginkább elfordulok felőle. Bár annyit tud, mint amennyit egy MySQL adna, szóval sokszor elég lehet.
• Egy dokumentum írása atomi művelet. Ez még jól jöhet.

A közeljövő feladatai:

• Az rtree implementációt meghackolni, hogy több fajta objektumot is tudjon indexelni
• a nodeok és way-ek attríbutumait is tárolni kéne és a relationokat is kezelni kell
• az Osmosis pluginba beilleszteni az indexelést is
• cassandra backendre is implementáni az interfaceket
• MongoDB-n kipróbálni még:
  • map reduce algoritmus js-ben írva (bár 1 node-on ugye nem várunk csodát tőle)
  • ránézni az ORM-nek megfelelő megoldásokra
  • JS API-val kicsit barátkozni

(Biztos kimaradt valami, de most már olyan fáradt vagyok, hogy az elgépeléseket sincs erőm kijavítani. Peace.)

Tags: mongodb, nosql

Summer of NoSQL nagyházi

Tuesday, June 29th, 2010 | Uncategorized | 1 Comment

Gyakorlati feladat:

Válasszon egy tetszőleges NoSQL alkalmazást. (Tipp: Hazelcast, Voldemort, Cassandra, MongoDB, CouchDB. Lehetőségei szerint minél több termékkel próbálja megoldani a gyakorlati feladatot).

Tervezze meg az Openstreetmap adatainak leginkább megfelelő adatstruktúrát és egy tetszőleges exportból (pl. hugary.osm) töltse fel adatokkal a tárat. (Tipp: használja az osmosis alkalmazást és ahhoz ilessze a NoSQL alkalmazás kliens API-ját).

Tervezzen egy szerver oldali alkalmazást, ami az Openstreetmap API szolgáltatásait valósítja meg (legalább a fontosabb lekérdezéseket) a választott NoSQL backenddel.

Opcionálisan mutassa be, hogy hogy tudna egyéb adatlekérdezéseket megvalósítani (pl. legfrisseb kontributálások listája egy adott területre).

Indokolja döntését, sorolja fel az előnyeit is hátrányait az adott terméknek. Milyen kompromisszumokkal jár a termék bevezetése.

Értékelje a NoSQL alkalmazás használhatóságát az adott feladatra (lehetséges szempontok: tranzakcionalitás, hibatűrés és rendelkezésreállás, indexelés, rendelkezésre álló API). Ajánlaná-e az alkalmazást a feladat elvégzésére.

Végezzen elemi performancia méréseket.

Mutassa be, hogy milyen map-reduce algoritmus futtatási lehetőségeket támogat a választott termék. Ha tud, mutasson rá példát.

A használt forráskódokat töltse fel egy szabadon elérhető helyre (Tipp: bitbucket, github)

Elméleti feladat:

Olvasson, olvasson, olvasson.

Tags: nosql

Android

Friday, April 30th, 2010 | Uncategorized | 3 Comments

Nagyjából jó összegzés volt a DZone-on, mégha nem is értek egyet teljesen mindennel (Pl. a reinventing the weel szerintem abszolút nem számít.). A doksi tényleg csak nagyon alap, sokat kell ásni egy egy probléma után, de alapvetően átlátható. A szétcsatolt felépítés hol szívás, hol áldás. Összeségében a platform nagyon jó buli.

Kísérleti projektjeim:

1. Names

Névnap widget. Már van a marketen hasonló, de ez azzal ellentétben  offline működik (viszont egyelőre csak magyar névnapokkal). Másrészt nem csak kiírja a névnapot, hanem minden nap megnézi, hogy a contactok között van-e olyan keresztnevű mint amilyen névnap van ma, és ha van, akkor küld egy notification-t.

Vannak még hátrányai, pl. mindenképpen fel kell rakni a widgetet, olyat nem lehet csinálni, hogy csak notifiaction legyen, widget ne, de majd talán kalapálom tovább.

2. Call costs

Ez pedig az a program, amire már régóta vágyom, csak a symbianra még nem tudtam jól megírni. Megnézi a call logot, és a kimenő hívások alapján megmondja, hogy melyik magyarországi tarifacsomag lenne a legolcsóbb nekünk. Be lehet állítani egy internet keretet is Mb-ben, és akkor azt is hozzá számítja. Egyelőre a tarifa csomagoknak csak nagyjából a fele van bent, főleg az internet és az előfizetések, de még ez is bővülhet. Alapvetően az volt a stratégiám, hogy minél hamarabb egy használható változatot megosztok, mégha nem is teljes minden szinten.

Mindkettőt csak Desirén (meg emulátoron) teszteltem, aminek elég jó processzora van, ezért nem is nagyon optimalizáltam. Érdekelne, hogy más gépeken hogy fut.

Minden ötlet, feedback, stb. jöhet.

(Forrás a github-on. Főleg azért, mert nagyon sokat (és mélyen) hg-ztem mostanában, és meg akarom ismerni hasonló mélységben a  gitet is.)

Tags: android

hg mq és a ci

Wednesday, February 24th, 2010 | Uncategorized | No Comments

UPDATE: OMG, mennyire felületes voltam. hg help qinit, és ne is olvassátok tovább. Ez mindent megoldott.

A .hgrc-mbe egyretöbb extension szivárog be:

[extensions]
hgshelve=/home/elek/satupad/hgshelve/hgshelve.py
hgext.fetch=
hgext.rebase=
hgext.graphlog =
transplant =
hgext.color =
hgext.purge =
hgext.mq =

Az egyik legújabb játékom az MQ extension. Nagyon nagy vonalakban arról van szó, hogy a rendes changelog tetején még ül egy rakás patch (konkrét patch fájl gyűjtemény egy könyvtárban), amik bár külön álló fájlok, az mq extension a saját parancsaival úgy kezeli, mint a hg changelogon szánkáznál időben előre és hátra.

Két tipikus használata van. Egyrészt el lehet játszani, hogy pullozok regy public repositoryból, és csinálok néhány patchet. Amikor frissítik a public repositoryt, akkor a patcheken időben visszalépkedek, ekkor changesetek helyett csak patch fájlok lesznek belőlük, pullozok egyet, és megint előre lépkedek és applyolom a patcheket.

(Ez így leírva kicsit bonyolultnak tűnik, de ki kell egyszer próbálni, és akkor érthetővé válik, én se nagyon értettem, amíg nem kezdtem el használni.)

Egy másik felhasználási mód, amikor szerkeszteni akarok egy commitot. Ilyenkor convertálom a changeseteket patchekké, a patch fileban szerkesztem (akár a commit message-t is), majd vissza konvertálom a patch changeseteket rendessé. Természetesen fizikailag ezek már más changesetek lesznek, tehát nem érdemes akkor próbálkozni ezzel, ha már pusholtuk is a changeseteket.

És most a probléma. Alapvetően ezt csináltam

1. leszedtem az aspectj maven plugin-t svnből és egy svn hg bridge-en keresztül hg-be konvertáltam
2. csináltam hozzá néhány patchet, hogy kicsit jobban működjön

A patchet ilyenkor a .hg/patches alá kerülnek. Akinek ott vannak a patchek alatt az én fájljaim az tudja buildelni az én változatomat, kinek nincs, az nem. Mivel azt akarom, hogy más is lássa a változtatásokat, ezért a hg qinit -c parancsot használtam, ami a .hg/patches-ben inicializál egy másik hg repót, ahol verziózza a patcheket. (E nélkül a patchek csak nálam lokálisan lennének meg).

A proléma az, hogy a .hg/patches repó természetesen egy másik repó, mint ami a fő kódot tartalmazza, és innentől kezdve egy rendes buildhez (pl. a Hudsonon) nem elég hg clone-t mondanom, hanem a hg clone után még a .hg/patches-hez egy másik hg clone is kéne, amit ugye a Hudson nem fog megcsinálni nekem.

Azt csinálhatnám, hogy a patcheimet átalakítom rendes changesetté, csak ezt meg pont nem akarom, mert akkor elveszik pl. a patch neve mint információ, meg a következő SVN frissítéskor kicsit bonyolult lenne a helyzet.

Tags: hg, mq

Metamodellek

Sunday, January 31st, 2010 | Uncategorized | 1 Comment

Néha hasznos lenne, hogy ha egy objektum struktúra felépítésére tudnék típusosan hivatkozni.

Nem találtam jobb nevet erre, mint a JPA 2.0 zsargonjából kölcsönzött Metamodel kifejezést, de talán egy példán keresztül világosabb lesz, mire gondolok. Tegyük fel hogy szeretnék egy Java Bean to Java Bean mapper-t, hasonlót a dozer-hez, csak egyrészt programmatikusan szeretném konfigurálni (nem XML-ből), másrészt én akarom részletesen megmondani, hogy mit másoljon, és csak azt másolja, amit szeretnék.

Tegyük fel, hogy van egy managed JPA entitás struktúránk, amiből szeretnék egy detached változatot, de úgy, hogy én mondom meg, hogy az egyes objektum kapcsolatokból melyik legyen kifejtve és melyik ne. Ezt a vázolt mapper alkalmazással fogom elérni, belemondom, hogy melyik atribútuomkat másolja, és egy adott entitásból egy ugyanolyan detached állapotú osztályhierarchiát másol.

Hogy mit másol, azt megadhatom mondjuk Expression Language szerű kifejezéssekkel. Pl.:

1
2
3
4
5
6

Mapper m = MapperFactory.create(Partner.class);
m.config("partner.nev");
m.config("partner.cim.varos");
Partner managed = ....
Partner detached = new Parner();
m.copy(managed,detached);

És itt szeretném elérni azt, hogy a 2. és a 3. sorban típusosan adhassam meg a másolási szabályokat.

Jelenleg két ötletem van erre:

APT

Az első az, amit a JPA2.0 is alkalmaz. Generálunk meta osztályokat mondjuk PartnerMeta, CimMeta, stb.néven, és azokba begeneráljuk a típusok leírását. Pl.

1
2
3

Mapper m = MapperFactory.create(Partner.class);
m.config(PartnerMeta.nev);
m.config(PartnerMeta.cim.varos);

A JPA2 mondjuk Partner_-nek hívná metamodel osztályt, és nem lenne rekurzív, tehát a Partner_.cim az nem egy Cim_ a JPA2-ben, ezért a fenti definíciót nem is tudnánk használni. Persze nem egy ördöngősség saját metamodelt kitalálni és az APT eszközzel viszonylag elegánsan lehet generálni ezeket az osztályokat (már ha beszélhetünk eleganciáról bármilyen generált kód esetében): Elég egy jól irányzott jar-t elhelyezni a fordítás idejű classpathba és már generálódnak is az osztályaink (lásd még SPI).

A JPA2 API-ját még nem használtam, de azért idemásolom az íze kedvéért egy cikkből, hogy hogy megy ez:

1
2

Root team = cq2.from(Team.class);
cq2.select(team.get(Team_.name)).where(cb.like(team.get(Team_.name), "Longfellow%"));

cglib

A másik megoldás a futás idejű byte-code generáláshoz vezet. Ezt csinálja pl. a liquidform:

Person p = LiquidForm.use(Person.class, "p");
List people = em.createQuery(
    select(p).from(Person.class).as(p).where(like(p.getSurname(), "Smith%")).toString())
    .getResultList();

és a Mockito:

Partner partner = mock(Partner.class);
when(partner.getNev()).thenReturn("valami");
assertEquals("valami",partner.getNev());

Látható, hogy egyes függvények paraméter gyanánt egy függvényhívást kapnak (pl. partner.getNev()) és nem a függvény hívás visszatérési értéke az érdekes, hanem maga a hívás, mintha egy metamodel egy elemét adnánk meg.

De hogy lehetséges ez? Nem tudom megállni, hogy ne idézzem a Mockito szerőjét Szczepan Faber-t:

…I was asked if Mockito is able to mock concrete classes? The answer is yes, Mockito doesn’t care if you mock an interface or a class. Mockito can do it thanks to primordial voodoo magic only ancient shamans understand these days (you guessed right – it’s the cglib library).

A cglib egy futási idejű bytecode generátor, ami az ASM nevű bytecode manipulátort használja. Gyakorlatilag proxy szerű objektumokat tudunk vele létrehozni, amire mi mondhatjuk meg, hogy az egyes metódusok mit csináljanak. Mindkét megoldás úgy kezdődött, hogy csináltunk egy saját Partner osztályt a Mockito.mock vagy Liquidbase.use factory-val. Na ez az osztály már nem egy rendes Partner, hanem a memóriában összerakott saját bytecode-ból áll.

A mockito ebbe a bytecode-ba azt írja bele, hogy egy ThreadLocal polcra tedd el az adott hívás tényét (pl. partner.getNev meghívodott). Aztán a when metódus már meg se nézi milyen paramétert kapott (partner.getNev() visszatérési értékét), hanem erről a polcról megnézi, hogy épp mi futott le, és ezért már tudja, hogy amikor a mockolt osztályon legközelebb meghívódik a getNev(), akkor mit kell visszaadni. (A when metódus természetesen később hívódik meg, mint a partner.getNev(), mert előszőr a when argumentumait kell kiértékelni).

A liquidform ennél kicsit egyszerűbbet utat választott. A partner.getNev() meghívásakor ő is feljegyzi, hogy milyen hívás történik éppen, és visszaad egy visszatérési típusnak megfelelő objektumot, de előszőr egy globális Map-ben a kettőt összerendelni. A like(p.getNev(), “Smith%”) metódust ezért érdeklik a visszatérési értékek, mert ez alapján megkeresi, hogy a Map-ben van-e rá bejegyzés, és ha van, akkor onnan kimatekolja, hogy a p.nev értéket kell berakni majd String szinten a készülő Querybe.

A liquidform megoldásának azonban van egy nagy hátránya: nem tud primitív típusokat kezelni. Mivel a Map-ben létező objektum referenciákra tudja megmondani az elérési utat, ezért egy visszaadott long értékkel nem tud mit kezelni. Persze meg lehetne a liquidformot is okosítani a Mockito módszerével, de akkor egy másik problémába ütközünk. A like(p.getNev(), “Smith%”) híváskor a polcon az szerepel, hogy egy pszeudó hívás érkezett a bytecode lekvárunkba, aki ezt gondosan feljegyezte. Majd ez után kapunk két String paramétert. Hogy melyik String paramétert kell feloldani a polcunkon lévő hívási információból, azt csak akkor tudnánk megmondani, hogy ha egy kitűntetett String értéket lefoglalnánk annak a jelzésére, hogy az a visszatérési érték nem számít, ehelyett használd a polcon lévő hívási információt. Másik lehetőség, hogy ha a paraméterek minden esetben felcserélhetők, akkor azt mondjuk, hogy a metamodeles hívás mindig az első kell, hogy legyen.

Hát itt tartok éppen a gondolataimban.

Tags: jpa2, liquidform, metamodel, mockito

Robotics

Sunday, January 24th, 2010 | Uncategorized | 2 Comments

Ezt azóta meg akarom írni, amikor is több mint két hete olvastam egy sci-fi regényt: Zsoldos Péter: Ellenpont

A regény eleje táján derül ki az az alapfelállás, hogy egy távoli bolygón éppen robotok dolgoznak. A robotok jól specializáltak: van amelyik energiát tud termelni, van amelyik űrkutatásokat végez, van amelyik szöveget elemez, van amelyik koordinál. Minden robot rendelkezik alrobotokkal, akik a nagy robotnak az inteligens karjai, az adott területért felelős központ irányítja őket (és persze közvetve a koordinátor). A robotok nagyon jól tudnak alkalmazkodni a környezetekhez, szép lassan agy előre írt program szerint kifejlesztik a gyártó sorokat és a technológiát, hogy eljussanak az űrön keresztül a szomszédos bolygókra.

A sztori persze folytatódik tovább, ami engem lenyűgözött, az az egész programozása. Egyszerűen annyira jól működik a dolog, hogy rögtön arra gondoltam, hogy jó lenne egy ilyet leprogramozni.

Valamikor a kilencvenesek években lehetett még, amikor a bátyám egy háziján keresztül ismerkedtem meg valamelyik egyetem projektjével, ahol Java focicsapatokat kellett programozni, majd ezek vívtak meg egymással. A játékosok egy interfacen keresztül látták a tér egy bizonyos szegletét, tudtak hanggal kommunikáli, és persze volt egy futtató környezet, ahol össze mérhették a tudásukat.

Most keresni kezdtem, de már nem nagyon találtam ennek a bajnokságnak. Csak a robocode-ra találtam rá, ahol tankokat kell irányítani egy térben (ahogy néztem a robocode nagy kalsszikus, sajnos nekem ez is kimaradt eddig), és aztán pont másnap olvastam egy versenyről hasonló témában. (El is kezdtem nézegetni, de most úgy látom, hogy a februári leadásig nem nagyon lesz már időm).

Jó lenne egyszer valami kis hazai háziverseny valami hasonlóból. És jó lenne egyszer komolyabban megismerkedni a neurális hálókkal, genetikus algoritmusokkal, és valami éles alkalmazást írni.

Tags: robocode, robot, todo

YAML

Tuesday, December 15th, 2009 | Uncategorized | 3 Comments

Ahogy azt egy kedves szomszéd szokta monda, a törpök élete se mindig csak játék és mese. Ez különösen így van, ha a törpök db4o-t használnak. Ráadásul BigDecimal-t akarnak perzisztálni, amihez tartozó kiterjesztés csak a legújabb SNAPSHOT artifactokban van benne.

És valószínű ennek a folyománya az, ami rendszeresen szembe jön, egy exception (hová is lenne az életünk exceptionök nélkül), ami valahogy így néz ki:

Caused by: com.db4o.ext.InvalidSlotException: id: 5182
        at com.db4o.internal.marshall.UnmarshallingContext.invalidSlot(UnmarshallingContext.java:81)
        at com.db4o.internal.marshall.UnmarshallingContext.read(UnmarshallingContext.java:49)
        at com.db4o.internal.ObjectReference.read(ObjectReference.java:281)
        at com.db4o.internal.ObjectReference.read(ObjectReference.java:267)
        at com.db4o.internal.ObjectContainerBase.getHardObjectReferenceById(ObjectContainerBase.java:956)
        at com.db4o.internal.marshall.AbstractReadContext.classMetadataForObjectId(AbstractReadContext.java:85)
        at com.db4o.internal.marshall.AbstractReadContext.readObject(AbstractReadContext.java:57)
        at com.db4o.internal.marshall.AbstractReadContext.readAtCurrentSeekPosition(AbstractReadContext.java:46)
        at com.db4o.internal.OpenTypeHandler.read(OpenTypeHandler.java:172)
        at com.db4o.internal.Handlers4.readValueType(Handlers4.java:313)
        at com.db4o.internal.marshall.AbstractReadContext.readAtCurrentSeekPosition(AbstractReadContext.java:48)

És így tovább.

A hiba teljesen kiszámíthatatlanul, ugyanakkor jól reprodukálhatóan előjön. Pl. előveszek egy backup db4o file-t, megnyitom, teszek-veszek benne, lezárom az alkalmazást. A következő megnyitáskor már nem nyílik meg az adatbázis. Ha viszont ugyanazt a cselekmény sort újra végigviszem az elmentett db4o file-on ugyanúgy elszáll.

Tehát előszőr is ki kéne dobni a db4o-ból a BigDecimal-okat, amihez át kéne konvertálni a sémát. (Tegyük fel, hogy egy számlázó programban sosem fogok beleütközni a float korlátaiba). Ha nincs több BigDecimal mezőm, akkor használhatom a stabil db4o változatot. A másik meg, hogy szükségem lesz egy dump file formátumra. Egyrészt mivel féltem a már bent lévő adatokat, másrészt mert a mező típus konvertálás is nagy szívás egy meglévő db4o adatbázison, az egyik legegyszerűbb megoldás, hogy kidumpolom az adatbázist, majd típus refaktor után vissza.

Mi legyen a dump formátum. Kapásból a JAXB és Json jutnak eszembe, de ezek ahogy én tudom nem támogatják a referenciák kezelését. (Ha az objektum fában többszőr is előfordul ugyanaz az objektum, akkor visszatöltés után ne két, hanem csak egy objektum legyen, amire két helyről mutat referencia.

És itt jön kébe a YAML, amit pont tudja mindezt.

Előszőr a jYaml-t próbáltam, ami alapból egyszerűen működik, de régóta nem fejlesztik, és túlságosan is elnézően bánt a Yaml fájl hibáival. Aztán jött a Snakeyaml. Ez már tette a dolgát mint a kisangyal.

Objektum mentése:

Yaml yaml = new Yaml();
yaml.dump(eztmentemel, new FileWriter(file));

Objektum betöltése:

Yaml yaml = new Yaml();
DatabaseBackup backup = (DatabaseBackup) yaml.load(new FileInputStream(file));

Maga a Yaml file meg valahogy így néz ki.

!!net.anzix.nona.entity.DatabaseBackup
felhasznalok:
- email: geza@hutira.net
  partner: &id001
    partnerek:
    - &id005
      partnerek: []
      szamlak: []
      torzs: {adoszam: null, bankszamlaSzam: null, nev: Asztal kft., szamlaCim: Sötét út 20.,
        szamlaIrsz: '1111', szamlaVaros: Budapest}
      tulajdonos: *id001
....

Itt már rögtön látszik is a referencia kezelése. A partner objektum instance azonosítója id001, és a partnerek listában található egyik partner tulajdonos mezője pont erre mutat vissza referenciával.

Mivel a db4o-val egy paranccsal elmenti az objektumfát, ezért 3 sorban tudok backupolni és visszatölteni a backupot, és a yaml file-t minimálisan módosítgatva (segít a nagyerejű grep parancs) még a típus konverziókat is sikerült viszonylag kis fájdalom árán meglépni.

Yaml a mi barátunk.

Tags: db4o, yaml