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...

Az ajax file upload és a gonosz flash

Próbálgattam AJAX-os file upload cuccokat JQuery-hez és elsőre majdnem bedőltem az uploadify-nak. Egy kis időt eltöltöttem azzal, hogy a file feltöltés miért nem látja a szerver oldali session-t, teljesen azt hittem egy ideig, hogy a szerver oldalon szúrtam el valamit. Pedig nem: az uploadify flash-t használ feltöltéshez és a flash figyelmen kívül hagyja a cookie-kat. Ezt már hallottam mástól is, csak nem jutott át az ingerküszöbön.

Gyorsan át is gyergeltem erre a másik ajax upload cuccra, ez teljesen jól működik idáig, nincs benne flash, bár a skineléssel akadt problémám de az valószinűleg inkáb abból származik, hogy CSS-ből még mindig kettes alát érdemelnék.

@Autowired és társai

Mostanában gyakran beleakadok a spring framework @Autowired annotációjába, amit kifejezetten private mezőkre húztak rá, amin nincs setter sem. Pl...

@Autowired

private Datasource datasource;

Az a kifogásom ellene, hogy:

• besettelni sem lehet neki valami mást
• springen kívül nem lehet inicializálni
• elég sok időbe tellik kibogarászni hogy vajon mi lesz ide besettelve

Nem olyan, mint a JdbcTemplate, amit szerintem simán más framework-re is bele lehet tuszkolni, és ráadásul nagyon hasznos. Sikerült portolhatatlanná tenni a kódot, pedig a spring úgy indult annak idején, hogy non-intrusive IoC framework. Másrészt ez olyan, mintha service lookup-ot használnánk, annyi előnnyel, hogy a boilerplate kódot átvette a spring. Viszont akkor már ilyet is csinálhatnánk:

@JndiLookup("jdbc/MyDS")

private Datasource datasource;

A megoldás: TestNG

N alkalommal futottam neki a TestNG használatának eddig, mindig nagyon boldog voltam magával a TestNG-vel, de az IDE integrációjával soha nem tudtam kibékülni és végül inkáb maradtam junit-nál. Az 'új' projectem pár artifact-jába viszont valamiért belecsomagolták a junit egy matuzsálemi verzióját, ami teszt alatt ütközésbe kerül az új verzióval, így nem maradt más választásom, mint testng-t használni.

RIA kalandok

Hát igen, jó hosszú történet, ugyanis a kliens oldaltól mindig próbáltam magam távol tartani. Nyilván a CV-ben sem áll jól, ha valaki nem pöpec a teljes alkalmazás stack minden apró elemében, meg elkezdett érdekelni is a téma.

Szóval a hosszú történet...

OpenLackó

Úgy kezdődött, hogy OpenLackó. Az OpenLaszlo volt nálam az első és eleinte marhára bejött, hogy én is tudok olyanokat csinálni benne, mint a UI guruk.

Előnyök:

1. Tényleg marha gyorsan össze lehet dobni a felületet.
2. Alapértelmezésben is szép.

Hátrányok:

1. Szőrös RPC megoldások. Például minden hívást a laszlo szerveren keresztül akar végrehajtani. Minek? "Java RPC" - public static metódusokat lehet vele hívni. Csúnya dolgokat kényszerített ki a szerver oldalon.
   
2. Horrorisztikus fejlesztési menet. Dobáljuk be a lzx fileokat a laszlo szerverbe? Miért nem lehet inkáb beágyazni az egészet?
3. Nem igazán indult be a komponens-piac, talán éppen a fentiek miatt.
   

Flex + BlazeDS vagy amit akarsz

A flex-ben amit elsőre megszerettem, az az hogy végre normálisan néz ki a RPC. Hívhatunk teljesen szabványos SOAP hívásokat, vagy kicsit cifrább mulatságba is belemehetünk BlazeDS-sel. Extra a lackóhoz képest az is, hogy nem kell a runtime környezetbe beletolnunk semmi flex specifikus dolgot. Egyből 40 megával kissebb a war file, hoppá.
Előnyök:

1. Sokféle és használható RPC. Akár szerver data push is.
2. A data binding szerintem király.
   
3. Nem feltétlenül akar valami spécit a szerver oldalra.
4. Kiválló maven plugin :)
5. Sokféle free UI komponens és library a neten.
   

Hátrányok:

1. Pokolian lassú fordító.
2. Hát van a flexbuilder, ami pénzes windowsos, akkor már egy új gépet is kellene vennem... Valamint összedobtam egy gyors plugint régebben, ami semmi mást nem csinál, csak lefordítja minden módosításra a flex kódot. Ezek nélkül azért meg lehet lenni.
   

ZK

Erre egy volt munkatárs hívta fel a figyelmemet és nagyon örültem is neki. A zk király... bizonyos dolgokra.
Előnyök:

1. Nem kell IDE :) Simán eclipse-ből editálva a zul fileokat háttérbe futó jetty-vel ment minden mint karikacsapás. Nagyon gyorsan lehet vele haladni. Módosítás esetén is villám gyorsan újrafordít.
   
2. Tiszta html.
3. Nagyon egyszerű és működő spring integráció.
4. Akadnak hozzá hasznos kis extra komponensek, egész könnyűnek tűnik sajátot írni. Az alap csomag is rengeteget tartalmaz.
   

Hátrányok:

1. Nekem úgy tűnik, borzasztó sokat nyúl a szerverhez. Nem tudom róla leszoktatni. Mindenért a szerverhez szalad.
   
2. Szerver oldali session-t nyit, egész nagyot. Skálázhatósággal nem tudom hogy állhat.
   

Szóval bekategorizáltam, hogyha egyszer valami csili-vili intranetes dolgot kell majd csinálni, akkor új lehetőségeket kap.

Google Web Toolkit

Hát ezzel odáig jutottam, hogy végigcsináltam egy tutoriált, és amikor oda jutottam hogy lefordít, akkor olyan botrányosan lassú volt, hogy fejvesztett menekülésbe kezdtem és azóta nem merészkedtem vissza. További információk így nem derültek ki.

HTML + JS + jQuery

Végülis feladtam és elfogadtam, hogy meg kell tanulnom javascriptet használni. Kicsit új eszközöket kellett keresgetnem ehhez, tényleg olyan érzés volt, mint gimi után C-ben kalapálni. A jQuery-t egy munkatársamtól lestem el, ő egekig magasztalta.
Előnyök:

1. Még csak nem is jsp. Statikus html. Akármilyen IDE elegendő támogatást ad hozzá. Jó, mondjuk az eclipse javascript képességei tényleg nem tűnik valami nagy pukknak
2. A SOAP-ot nem próbáltam, de a REST hívások simán mennek. Csak az megy át a dróton, amit az ember programoz. Alacsony szintű ajax megszelídítve.
   

Hátrányok:

1. Még felfedezés alatt áll, de a UI library nem olyan nagyon frankó még.
2. Alacsony szintű összeakadások. Például beleraktam egy google map-et egy dialog-ba, és hát voltak vele bajok, kicsit elcsúszott a google map. Nem tudom miért, kicsit erősítenem kell még javascrptből.
3. Szerintem az olvashatósággal vannak problémák, de lehet hogy csak nekem kell még megtanulnom olvasni.
   

Ez a helyzet idáig. A véleményeteket és útmutatásaitokat természetesen örömmel látom.

JAX-RS és JAX-WS

Köszi a hozzászólásaitokat az előző postra, egész sok inspirációt kaptunk ahhoz hogy hogy írjuk át a teszteket!

Igazából most is a véleményetekre lennék kiváncsi.

Szintén munkahelyi projectben azon mesterkedtem, hogy SOAP-os REST-es web service-t is meghagyom egészen addig, amíg teljesen világossá nem válik hogy az adott környezetben melyik a nyerő megoldás. Természetesen spring-gel inicializálom a service bean-eket, CXF-fel exportálom ki, JSR 181 web services és JSR 311 rest annotációkkal látom el a service metódusokat és a beaneket még JAXB annotációval is helyenként. Sikerült is, bár szerintem kicsit szőrös a dolog.

1. Elösször is a JAX-RS a beanjeid Collection (list, map) mezőire megköveteli, hogy legyen mindnek alapértéke és csak gettere. Azaz ne lehessen null soha, legfejebb üres. Viszont a JAX-WS elvárja hogy mindenkinek legyen szép gettere és settere, különben nem számít proprtynek. Ez a kettő nem feltétlenül zárja ki egymást, csak kicsit megcsúfítja a bean-eket.
   
   Például így fog kinézni egy bean:
   
   
   

   
   /**
   * Szerintem gáz, amikor magyar neve van egy osztálynak :)
   * Majdnem mint amikor a javadoc is magyar.
   */
   @XmlRootElement(name="csirke")
   public class Csirke {
   boolean isKopaszNyaku;
   boolean isKendermagos;
   List<Tojas> tojasok = new ArrayList<Tojas>();
   @XmlTransient // Nem ezt a property-t hasznaljuk a rest apival
   public List<Tojas> getTojasok() {return tojasok;}
   public void setTojasok(List<Tojas> tojasok) {this.tojasok = tojasok;}
   @XmlElement(name="tojas")
   @XmlElementWrapper(name="tojasok")
   public List<Tojas> getTojasLista(){ return getTojasok();}
   }

   
   
   Szóval szerintem kicsit összetúrkáltuk az alkalmazás legérzékenyebb részét: az adatmodellt. Ha az adatmodell csúnya, az mindennek rossz alaphangulatot ad.
2. A CXF-nek kicsit nehéz volt megmagyarázni, hogy ha pl a /services/ alá mappeltem a CXFServlet-et, akkor mit kell csinálnia akkor, amikor kap a /services/-re egy kérést. Azt hiszem az lehetett a baj, hogy nem állítottam be at address-t.
   
   
   

   
   <jaxrs:server name="jaxrs-server" bus="rest" address="/rest">
   <jaxrs:servicebeans>
   <ref bean="csirkefarm">
   </jaxrs:serviceBeans>
   </jaxrs:server>
   

   
   
   
   
3. A service interfacekre raktam az annotációkat, hogy ha lecserélem az implementációt, akkor az új service-re már ne kelljen másolgatnom. Hát elég cifrán meg lett annotálva egy-egy ilyen metódus.
   
   
   

   
   @WebService(name = "csirekFarm")
   @Path("/csirkeFarm/")
   public interface CsirkeDAO {
   @WebMethod(operationName = "getCsirke")
   @WebResult(name = "getCsirkeResult")
   @GET
   @Path("/csirke/{csirkeId}")
   public void Csirke getCsirkeById(@Webparam(name="csirkeId") Long id);
   

   
   
   
   

Most, hogy az annotációk legyőzték az XML konfigurációkat, a kódunk tele van konfigurációval :-) A hétvégén összedobok hozzá egy archetype-ot, ha elég időm marad rá.

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"