A következő címkéjű bejegyzések mutatása: jpa. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: jpa. Összes bejegyzés megjelenítése

2012. február 18., szombat

Developer Conference 2012 Brno, első nap

Tegnap a brnoi fejlesztői napon voltam, csak pár prezentációról, ami nagyon tetszett...

Towards Unified Messaging - Frantisek Reznicek

A csákó az AMQP protokolról és az apache qpid-ról beszélt. Az AMQP egy szabvány message queue-knak, nekünk a JMS protokol miatt nem volt különösebben fontos, hogy protokol szinten szabványos legyen. Elég volt kicserélni a drivert és kis szerencsével működött. Mindenesetre egy egész tucat JMS szerver implementálja ezt a szabványt most már. Pl az ActiveMQ és a  is.

Richfaces: testing on mobil devices - Pavel Pitonak


Érdekes demó a QE csapattól arról, hogy hogyan automatizálják a tesztjeiket mobil eszközökre virtualizált szerverekkel.

What are Drools, Guvnor and Planner - Geoffrey De Smet

Java témában kb etalonnak számító rules engine és a köré épített projektek. Semmi új nem volt nekem, decemberben elkezdtem egy prototipis projektet az oVirt mellett kisérletezésre és az egészen Drools-ra épül. Geofrey viszont jó előadó és a többiekkel ellentétben nem akadozik és nem dadog. Ja meg cseh akcentusa sincs :)
A drools érdemel talán egy kicsit nagyobb figyelmet, szerintem sok gyakori problémát le lehet vele egyszerűsíteni.

Hibernate OGM - Michal Linhard

Ez egy jelenleg alpha állapotú project arra, hogy sima JPA apival és annotációkkal ne csak hagyományos relációs, hanem NoSQL jellegű adatbázisokba is lehessen perzisztálni. Jelenleg csak az infinispannal megy, de az infinispan mögött lehet akármi is: cassandra, mongo, akár relácis adatbázis vagy filerendszer is.
Ez nagyon tetszett, nem tudom hogy fog elsülni ez a próbálkozás, de marha jó ötletnek tartom. Kiváncsi vagyok tényleg sikerülhet-e a gyakorlatban, hogy kihúzod az appod alól a relációs adatbbázist és kicseréled valami NoSQL-re.

Continuous integration with Jenkins CI - Vojtech Juranek

Trükkök Jenkinssel. Virtuális szervereken futó agentek, egzotikus nyelvek (php például), bug detektor pluginok. Mondjuk a statikus analízisre én a sonar-t tartom a legjobbnak, az nagyon pöpec.
Csak én tartom igénytelennek a jenkins webes felületét? Jó, úgyis csak fejlesztóknek kell, de ha ennyien használjuk, nincs egy designer köztünk?

No, most jön a második nap, ma oVirt, GlusterFS, SPICE további JBOSS előadásokat fogok hallgatni.

2010. november 28., vasárnap

Annotation hell

Gyorsan még az is eszembe jutott, hogy elmagyarázzam, miért gondolom azt, hogy az annotációkkal átestünk a ló túloldalára. Úgyis mindjárt reggel van, már jár a villamos.

A nagy XML konfigurációk helyett csodálatos dolog annotációt használni, amikor úgyis csak az az egy konfiguráció lett volna értelmes. Például JPA és más ORM annotációk. Még soha olyat nem láttam, hogy meggondolod magad és nem jó az a név annak a táblának. Kutyát nem érdekelnek a táblák nevei. Persze konkrétan a JPA lehetőséget ad arra, hogy felülbíráld XML konfigurációval az annotációkat.
Hasonlóan lelkesedek azokért az egyszerűsítésekért, amiket a JSR-181 REST annotációk, a JAXB annotációk ésatöbbi hoztak. Az így felannotált osztályokat és interfaceket az ember tipikusan egy pacakge-be dobálja. Igen, helyenként kicsit cifrán néznek ki az osztály-, metódus- és paraméterannotációk. Sebaj, az XML se lett volna kevesebb.


A másik esetben pont a szétszórtsággal van a probléma. Például a non intrusive IoC-nek pont az volt az előnye, hogy nem összeintegrált komponenseket gyártsunk, elég ha POJO, ennek megfelelően tradícionálisan szét lettek szórva a service osztályok, és nincs is nagyon remény a rendszerezésükre. Szóval ezért nem szeretem az annotált IoC-t, beleértve a spring annotációkat is, és tartok tőle hamarosan a servlet 3.0 annotációival is lesz problémám. Képzeld el így a problémát: átveszel valakitől egy spring annotált projektet, nem a dokumnetációtól működik a szoftver tehát dokumentáció nincs, a fejlesztőtől se várhatsz segítséget. Melyik projectet látod át hamarabb? Szerintem az XML-hell egy-két helyen jobb abból a szempontból ott legalább minden egy helyen van. Nyilván ettől lett hosszú. Attól, hogy szétkentük az XML file tartalmát csillió osztályba, attól nem lett se kevesebb, se átláthatóbb, csak az XML lett rövidebb. Sovány vígasz.

2010. február 22., hétfő

todomap 0.5.10

Te szavaztál már? :-)

Szóval, ez a verzió csak kevés újdonságot hoz a kliens oldalon:
  • Szavazatösszesítés a TODO kisablakában, így már kicsit egyértelműbb talán, hogy a fel és le nyil nem lapozgatás, hanem értékelés. Még az lenne jó, ha mondjuk a lefelé nyil piros lenne. Vagy nem is nyil talán hanem hüvelykőj fel vagy le.
  • Kicseréltem a upload plugint. A különbség az, hogy most ez nem csak firefoxban működik :) Viszont benne hagytam a javascript alertet :( Következő lépésben megcsinálom Dani ötletét és a térképről is lehet majd képet csatolni.
  • Még egy chrome gubanc javítása: a rich text editor hajlamos volt újra előmászni, miután lelőttem. Most kicsit hatékonyan lövöm le és nem mászik elő újra.
Az integrációs frontról jelentjük:
  • Írtam egy kis AOP kódot arra, hogy a szerver oldali adatmódosító hívások (törlés, új adat, módosítás) után elküldje egy sorba (JMS) a módosult adatot. Így aki majd figyel a drót végén, az kapja az arcába az infókat. Nos egyelőre nem figyel ott senki, de arra sem kell sokáig várni, remélem.
  • Összetúrkáltam egy külön API-t is a magyarorszag.hu hivatalkeresőjének gépi hasznosítására, ez a kód egy darabja lesz annak a nagyobb rendszernek, ami az imént említett drót végén figyelni fog. Lásd előző bejegyzés...
  • És hogy pontosan mi lesz a drót másik végén, arról még nincs pontos elképzelésem. Csak megyek előre, aztán majdcsak lesz valahogy. Tanulgatom az camel frameworkot, servicemix-szel ismerkedek, mindenféle ESB-k után szaglászom, ilyesmi. Ez jön most egy ideig.
  • Ismerkedek sok más technológiával is, pubsubhubbub, opensocial, social search, undroid...
Az első verzió, amit a szép új desktopomon csináltam. Az új gép egy 64 bites dual core AMD Athlon II x2, 2 GB 1600 mhz memóriával. Ezt a nevet kapta: dummywarhead. Döbbenetesen gyorsabb rajta a todomap, mint az előző gépen. Mondjuk mert több mint négyszer annyi a számítási teljesítménye... Még 3D-gyorsítós videókártyát is pakoltam bele, pedig amúgy nem szoktam játszani. Egy este alatt meg is untam az összes linux-szal jövö 3D játékot. Ideje újra kpróbálni Pali processzorgyilkosát.

2009. november 7., szombat

Mosatanában elkövetett mini-projecteim

Kicsit elhanyagoltam mostanában ezt a blogot és inkább otthon hegesztgetek. Pár némileg újrafelhasználható dolgot is összekopácsoltam az utóbbi pár hétben.

MiniGeoIP

Szóval próbálkoztam azzal, hogyan tudom bemérni a kliens földrajzi helyét. Nem holmi öncélú marketingdolog miatt, hanem egyszerűen hogy az alkalmazás számára releváns infóval tudjon indítani. Egyébként a IP-blokkolás szerintem rasszizmus. Próbálkoztam a Google JSAPI-jával, a tapasztalatok viszont azt mutatták, hogy a Google vagy megmondja hogy hol vagy, vagy nem... Ami azért bár nagyon baráti, de mégsem 100%-os telitalálat. Söt, sajnos úgy tűnt az ismerőseim többségének IP címére nem mond semmit. Keresgetni kezdtem szerver oldalra beágyazható IP feloldást de nem sok használható dolgot találtam, úgyhogy a felgyűlt ihletből gyorsan összedobtam egyet. Ez az implementáció egy 100.000 soros adatbázist épít fel magának. Az még a memóriában is elférne talán, viszont én JPA-n keresztül keresem. Sajnos kényelmes voltam és spring JpaDaoSupport-ra építettem, szóval most totál spring-függő, de ez most még nem fáj nekem. Cucc. Ja és itt ki is lehet próbálni, hogy jó országba tesz-e.

GeoCoder

Hasonlóan föcis téma, egy adott koordinátából szeretnénk megkapni a postai címet amennyire lehet. Unalmas. Google reverse geocoder. Köszi gúgli. Cucc.

Jetty-gzip-plugin

Ez szerintem vicces téma, a jetty default servlete tud olyat (és alapból be is van kapcsolva), hogy ha egy statikus file mellett ott van a .gz tömörített változata, ÉS a kliens nem IE :-D, akkor a tömörített változatot küldi el, ezzel megtakarítva sávszélességet és egy kis időt is. Pl a javascript library-k egészen hatalmasra nőttek. Ez a kis maven plugin egyszerűen packageléskor létrehozza a .gz fileokat. Akár kézzel is megcsinálhatná az ember, ha nem felejtené el mindig. Nekem kicsit több mint 100Kb-t takarít meg egy oldalmegjelenéskor, ennyiért úgy gondoltam, hogy már megéri. Cucc...

Google Translate Java kliens

Hát ez annyit tud, hogy megmondja, milyen nyelven van a szöveg. Teljesen minimalista, de ennyivel beérem. Ismét köszi gúgli. Kicsit már zavar hogy mennyi mindent ráépítek google szolgáltatásokra. Cucc...

Ennyi, köszi ha eddig eljutottál, akkor most megint pár hét lapátolás...

2009. június 25., csütörtök

Logging

Belekeveredtem egy problémába a OpenJPA unenhanced osztályaival és úgy döntöttem hogy inkább visszatérek kicsit Hibernate-re. Nos magában a visszatérés nem lett volna nagy ügy: kiszedni az OpenJPA-t a pom.xml-ből, betenni a hibernate-entitymanagert, kicsit módosítani a jpa konfiguráción és kész is lenne...
Viszont a hibernate időközben nagyon szépen áttért a log4j logolásról a slf4j logolásra. Őszintén szólva teljesen lusta voltam egész idáig akár belenézni is, hogy mit kínál az új logging api. Nos a Simple Logging Facade 4 Java azt találta ki, hogy az régi logging apik helyére tesz egyetlen loging rendszert. Azaz kidobtak egy halom jar file-t, amiben például benne lehet a jó öreg org.apache.log4j.Logger, és emiatt nem tűri meg maga mellett az eredeti log4j-t. Dependency hell. Akármelyik csomagom is hozott be log4j függőséget, azonnal ki kell vadásznom a teljes dependency fából. Most még be kell dobálni a slf4j api-t, majd a log4j-over-slf4j csomagot...

A végeredmény az, hogy a JPA implementáció cseréje sokkal kevesebb időt vett igénybe mint a logging api cseréje. A logging az a dolog amitől azt várnám hogy nem zavarhat semmit, nem romolhat el és nem okoz semmiképpen sem futási hibát.

"Lassan haladunk, de nem baj, mert rossz irányba"