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.

Megölni Lacit egy Flex-szel...

Túl vagyok az első gyors hegesztésen FLEX-szel, igazából azt kell mondanom hogy így elsőre sokkal jobban passzol a képbe mint az OpenLaszlo. Nagyon tréfás kis dolog, és doko is akad hozzá. 600 oldalas nyomtatott könyv, hogy a nem-IT-emberek azt hihessék hogy komoly tudomány az amit csinálunk.
Hát a UI nem lett olyan csili-vili mint OpenLaszlo-val, engem kb ez érdekel a legkevésbé, viszont felmerülnek további érdekes kérdések. Szóval van még merre bóklászni.

Alapanyagok: maven, xfire, flex
Egy alap-recept: itt

OpenLaci @ jhacks

Igazából nem lehet panaszkodni az OpenLaszlo dokumentációjára, opensource project létére egész jó :) Persze az is meglátszik a doksi határain hogy a supportból és az oktatásból él a cég. Na ez az, amire egy jó magyar munkásembernek soha nincsen pénze, még ha szoftverfejlesztő is.
Amire igazán kiváncsi lennék az inkáb valós életbeli példák, hogy ki hogyan integrálja spring frameworkkel, hogy használja a data bindinget, hogy ír benne formokat, ilyesmi.
Az első openlaszlo felhasználói találkozón sikerült pár PHP-s sráccal gondolatokat cserélni, bár az nekem kicsit távoli, de semmiképp sem haszontalan. Azóta csend van, mondhatni a magyar OpenLaszlo közösség szép start után elpárolgott.

Úgyhogy elkezdtem a jhacks-on összeírni az OpenLaszlo-ról amit eddig kibányásztam belőle. Majd haladgatok ahogy van időm. Na igen, mostantól kicsit több időm lesz mint eddig. Ha valakinek van kedve nyugodtan szóljon, adok accot és lehet belenyúlni.

OSFlash konferencia neten

Akinek van ideje ilyesmire egy deathmatch-pénteken (konkrétan holnap), az ugorjon be bátran egy OSFlash konferenciára, webes persze. Olyan dolgokról beszélnek majd mint flex, red5 és openlaszlo, többek közt.
Lesz róla felvétel is persze, így legalább én is meghallgathatom egy hullaszombaton.

A war overlay és a jetty plugin nehézségei

Egyes esetekben (pl OpenLaszlo alapú hegesztések) kénytelen az ember egy másik project war filejába belegyömöszölni a saját cuccát. Erre a maven tök jó megoldást kínál, egyszerűen csak adjuk meg dependency-ként a külső war file-t és a scope legyen runtime, a típus pedig persze war. Ekkor a war plugin tudja majd a dolgát és jól összemergeli a kettőt, persze itt még van mit paraméterezni. Ezt hívják war overlay-nek.
A gegasz már ott elkezdődik amikor a mindenki kedvence 'mvn jetty6:run' parancsot kiadjuk, mert a jetty6 plugin figyelmen kívül hagyja ezt a dependency-t, futtathatunk viszont egy 'mvn jetty6:run-exploded' parancsot, ez összeállít egy war-t a war pluginnel, kicsomagolja és végül elindítja rajta a jetty-t. A dolog két fájó pontja:

1. Nagyon lassan indul el, főleg ha a war file mérete nagy
2. Nem updateli a tartalmat

Erre az elegáns megoldás az lenne, ha a jetty6 plugin tartalmazna egy background thread-et, ami szinkronban tartja a jetty kicsomagolt war fáját a forráskóddal. Ezt viszont egy bash parancsból is egyszerű megoldani. Ilyesmi:

while true; do cp -ru src/main/webapp/* target/${artifactId}; cp -ru target/classes target/${artifactId}/WEB-INF/classes; sleep 1; done

Kicsit sem elegáns, legkevésbé sem portolható (de hát a vindózerek élete amúgy se játék és mese), de a túlélésre elég. A második bajt workaroundolja, az elsőt meg túléljük mert innentől már csak egyszer kell elstartolni.
Ki lehetne pofozni ezt a jetty plugint, például még mindig 6.0-beta17 verzióval megy a legfirssebb kiadás, pedig a fejleszés lassan már 6.2-nél tart. Miért hagyhatják ilyen elhanyagolatan a webfejlesztéshez leghasznosabb plugint?

OpenLaszlo 4.0.0

Nocsak, ma jött ki az OpenLaszlo 4.0.0. Tovább nem is bíbelődök a 3.x-es szériával talán.

CAFEBABE

Remélem a jó programozó definícijóában nincs benne az hogy szereti a kávét.
(Lásd: igazi programózó (definíció), önmarcangolós percek első és második rész.)

Mostanában sereg érdekes új technológiát találok a neten, de ilyen ZH és leadandó dolgaim miatt csak kapkodok össze-vissza.
A leadandók egyetlen tanulsággal szolgálnak: általában nem a tulajdonképpeni munka viszi el az időt hanem az apró új techológiákkal vívott csata. Esetemben ez a TEX formátum, amiben a doksit írom.

A nem leadandó queue-ban legelöl:
- Az openlaszlo 3.4 audio/video streaming supportja es a red5
- struts 2 migracio
- appfuse meg mindig

HOPLA - Hungarian OpenLaszlo Community

A találkozóról egy beszámolót feltettem a jhacks.hu-ra.

NEM, NEM, SOA!!!

Ilyen buzzword nap van.

Piszokul keresem az OpenLaszlo plugint az eclipse-hez, mert nekem az volt az utolsó infóm hogy inaktív volt a fejlesztés és az eclipse foundation archiválta. A OpenLaszlo community találkozón viszont esküdött rá egy srác hogy azt használja. Nekem meg itt csupa 404 minden, csak azt találom ami az archívum maga... OpenLaszlo 3.0-hoz az egész. Hümmm...

Na, a talákozóról meg majd írok valami összefoglalót a jhacks-ra, csak kicsit szét vagyok csúszva most.

OpenLaszlo közösség Budapesten

Végre OpenLaszlo felhasználói közösség alakul Budapesten. A hét első tényleg jó híre. Már most készítem rá az agyamat hogy hasznos információból minnél többet belegyűrjek péntek este.

Openlaszlo 4.0 béta bekukkantás

Még jó hogy csak béta, mert nálam tökre nem ugyanaz történik a flash-es runtimeban mint a dhtml-esben. Fedora 6, firefox. Mondjuk linuxon ez a flash plugin is büntet időnként egy memory leakkel.

Az ajaxosok élete se csak játék és mese, mást nem tudok mondani biztatót. Kérem kapcsolja ki.

Ötletelős percek - Maven RAD

Csináltam egy friss blogot, konkrétan ezt olvasod, írogatok majd ide mindenfélét technikai dolgokról. Java főleg, linux, clusterezés, open source projectek, villanydemokrácia, meg ami jön. Utálni fogtok érte :) Na, vágjunk egy "in medias res"-t a lovak közé!

Elmentem ma mérni, és mivel ez különösebben nem egy intellektuális tevékenység, azon gondolkodtam hogy összeállítani egy korrekt architektúrát web alkalmazásokhoz igencsak időigényes dolog, de vannak dolgok amivel meg lehet gyorsítani a fejlesztést.

Itt van például a grails. Beírod hogy ant create-project, ott is vagy, megvan a projected. Az acegit mondjuk kicsit kalapálni kellett, de legalább jobban képbekerültem groovy-ban meg acegiben. A friss grailsben viszont ott van az amin én is mennyit vacakoltam, openlaszlo integráció. Szóval közelebb hozza az álmot hogy a webapp-fejlesztés gyorsan elstartolható, meg ilyesmi. Feketemágia akad az ilyen *rails dolgokban bőven, nem csak a fejlesztőkörnyezetbe veszi be magát, hanem a futási környezetbe is, kiszedni meg nehezebb mint teljesen újraírni az egész cuccot.

Egy érdekes próba lenne maven alapra tenni egy RAD projectet, ami két részből állna.

1. Egy maven archetype, amivel gyorsan létre lehet hozni egy hiperkorrekt, bár üres projectet
2. Egy plug-in amivel gyorsan le lehetne generálni DAO interface-ket és implementációkat, valamint a view oldalból is létrehozna egy templatet.

És akkor definiálom hogy mi a hiperkorrektség nálam mostanság.

• külön projectekre elválasztva a modell, az alkalmazáslogika és a különböző felhasználói felületek (webes felület, web service, swing, portlet, ilyesmi), integrációs projectek
  
• deklaratív tranzakciókezelés alapból, mert tranzakciókezelés úgyis mindenhova kell, ha meg nem akkor úgyis könnyebb kivenni mint beletenni :)
  
• Azonosítás, dettó, bár ezen még azért érdemes lenne okoskodni
• Persze mindez korlátokkal, mert a tökéletes ember és szoftver még amerikai szuperhősfilmben sincs. Acegi, spring, alapból JPA-ra generált DAO-k. JPA mögé persze Hibernate, mert úgyis boldog boldogtala lecserélni meg elméletileg könnyű. Nem próbáltam még.
• Generált tesztek a DAO objektumokhoz, alapból például Derby-n, de persze opcionálisan bármi máson.
• Alapból beleintegrált riportok minden alprojecthez,
  

Az hogy a view dolgokat milyen framework-re generálja, azt nevezhetjük lényegi kérdésnek. Ezt jó lenne pluginelni.

Szóval elbonyolítani már sikerült, mindenesetre teszek egy próbafúrást a területen, hátha feltör az olaj és én leszek a Bobi Juing. Vagy a Dzsoki inkább, mer` ő gonosz.