JUM XVII.

Kicsit égő hogy már szinte csak a JUM-ról írok, de ez van. A tizenhetedik alkalomnál tartunk. A teremben kb. 40 ember volt, ami már majdnem teltház. Az asztalon az Oracle Java Café-ról ismerős szórólapok. Viczi elmondta, hogy az OJC-n is megemlítették a JUM-ot, úgyhogy mi is megemlítjük őket, kölcsönös a szimpátia, stb. Indultak is az előadások:

Verhás Péter - Business Level Testing

A szervezési részéről megfogva a dolgot azt mesélték el, hogyan lehet az ügyfelet bevonni a tesztelésbe. (Nem az ő feladata, nem ért a műszaki dolgokhoz és nincs is rá ideje.)A tesztelés ne műszaki tevékenység és ne “munka” legyen, hanem “játék”. Ne legyen kötelező, viszont érdekes legyen. Így az ügyfél érdekeltté válhat benne. A bevált eszközeiket említették meg: SoapUI, Confluence és Greenpepper. Erről sajnos technikai részleteket nem árultak el. A IX. JUM-on, -amikor egy előadás hangzott el ezzel kapcsolatban- még nem tartozott a jó szokásaink közé bekérni a prezentációkat, úgyhogy technikai részletekkel most nem tudok szolgálni. Egyébként volt Wiki felület, táblázatok és zöld-piros grafikonok.

Auth Gábor – Android SOAP

Gábor egy open source SOAP kiszolgálót írt Android-ra. Elvileg van már egy, de azt igazából MIDP-re csinálták és nem túl bő a funkcionalitása, nem használja ki kódszinten az Android tudását. Ha bárki csatlakozni akar a projekthez, Gábor szívesen látja. A források elérhetőek webes SVN-ből, Maven alapú a projekt egyébként. Illetve szavazzatok rá a StackOverflow-n. :)

Kovács Richárd – Magyar Tamás – EJB3 vs Spring

Szerintem ez egy zseniális előadás volt. Ricsi képviselte az EJB oldalt, mígy Magyusz zöld ingben a Spring oldalán harcolt. Egymásnak néha beszólogatva gyalogoltak végig a mindenféle szempontokon: UI támogatás, biztonság, AOP, DI, rendelkezésre állás, aszinkron hívások lehetősége. A rendelkezésre állással kapcsolatban megemlítették a Terracotta szervert, ami pénzes (drága) és elosztott Spring alkalmzások futtatására szolgál. A visszatérő mondatrészek a “bármit le lehet programozni” és “az XML az ördögtől való” voltak. Megköveztük szegény “evil singleton”-t is néha. A meccs végén nem volt konkért eredményhirdetés, hanem abban maradtunk hogy ha oda kerül az ember úgyis meglesznek a szempontjai ami alapján dönteni kell.

Hiányoltam egy olyan szempontot, hogy a lokális erőforrásokhoz való hozzáférés. Ebben a Spring nyert volna, mert EJB-be ez nem nagyon fér bele. Márpedig néha még szerveren is szükség lehet USB vagy egyéb lokális eszközökhöz, fájlokhoz való hozzáférésre (pl. kulcsok). Elvileg van rá EJB-ben is valami Connector architektúra, de még nem láttam élő embert aki ilyet programozott volna. Hogy olyat is írjak ami kimaradt, de az EJB nyert volna a grafikus adminisztrálhatóság. Tapasztalataim szerint egy rendszergazdát megnyugvással tölt el, ha van egy felület amit nézegethet és pl. form-okon állítgathat be data source-okat screenshot-ok alapján, alkalmazásokat telepíthet, uninstallálhat. Nos, Spring-ben marad az XML bogarászás.

Felmerült olyan kérdés, hogy használt-e valaki együtt Spring-et és EJB-t amire az volt a gyors mondás, hogy az perverz dolog. Nos, én használtam többféleképpen is.

Annó, az EJB2 idejében használtuk a Spring EJB támogatását, de erre már nem nagyon emlékszem. Olyan is előfordult, hogy egy EJB-s alkalmazás teszteléséhez használtunk Spring-et: összeraktunk egy appContext-et a bean-ekből, amit alkalmazás szerver nélkül lehetett meghajtani.A “legperverzebb” dolog viszont az volt, amikor egy Session Bean-en belül akartunk Spring appContext-et létrehozni.Lett volna értelme, de nem valósult meg.

Szóval ez volt a JUM, legközelebb jövőre.

Ma lesz egy Eclipse DemoCamp valami borozóban, amin sajnos nem tudok résztvenni, mert sok lenne már a jóból, de remélem valaki beszámol majd!

JUM XVI.

Amikor az utolsó pillanatban beestem a terembe hirtelen csak annyit tudtam mondani, hogy wow. Jó sokan voltunk, rekordgyanús. Konferálás kutyafuttában, aztán már nyomta is Balogh Zsolt a Liferay előadást és demót.

A hátsó sorok egyikéből nem nagyon láttam a programkódokat, de a Liferay portletek gyors fejlesztésének és deployolásának hangulata átjött. Új alap portletet és service-et tényleg pillanatok alatt össze lehet rakni. Közelebbről még nem találkoztam a témával, mert inkább önálló webalkalmazások fejlesztésével foglalkozom, úgyhogy nem is ismerem a portál motorok legfontosabb karakterisztikáit. Viszont érdekelne, hogy hogyan illik bele a Liferay a legújabb Ajax-os, vastagkliens Javascript-es, HTML5-ös, REST-es trendekbe. Azt még megtudhattuk, hogy belül Spring-re épül. Jó sokan itt voltak a magyar Liferay-tól, vagy az iLogic-tól, vagy is-is. Junior EE fejlesztőt keresnek egyébként.

Csutorás Zoltán visszatérő vendég. Most a Scrum öt alappillérélől nyomta az előadást. Egész jó volt, a forma 1-es képnél még be is lelkesültem. Szó volt mindenféle dologról, ami szorosan és kevésbé szorosan kötődik a módszertanhoz: a laterális gondolkodásról, gondolati sémákról, arról, hogy miért jó sztoripontokkal becsülni embernap helyett, értékfolyamatról, áramlásról, visszaáramlásról -amikor vissza kell pakolni feladatokat a queue-ba, húzóelvről, kiértékelésről. Nehéz lenne ezt így visszaadni. Lényeg, hogy a 40 perces előadás után a kérdésekkel még jól elvoltunk vagy húsz percig. Így a két előadás ki is töltötte a két órát.

Update 2010.09.23: Éppen elindult az Adaptive Consulting honlapja, rajta az előadás anyagával.

Videófelvétel készült, de azt nem tudom hogy mikor hová lesz kitéve. A slide-ok elérhetőek lesznek a JUM honlapjáról.

JUM XV.

A XV JUM-ról gyorsan, késve:
Csúszott is a dátum, nem is jött be a terv, de azért lett két jó előadás.

Bemelegítésnek Kovács Richárd a BTrace-ről nyomta:
Különös alternatívája ez a debug-olásnak. Java-ban lehet megírni a kódot ami végrehajtódik, ha ráfut a vezérlés a megadott metódusokra. A Java-ban megírt kódnak viszont rengeteg kötöttsége van. Nem lehet új objektumot létrehozni, ciklus sem lehet, ilyesmik. Használhatónak tűnt az a felhasználási eset, amikor a JDBC csomagban lévő osztályok bizonyos metódusaira kötöttek debug kódot és kiírták hogy milyen SQL-ek mennek az adatbázis felé. (ORM esetén hasznos.)

Marhefka István a Domain Driven Design-ről beszélt:
Sok embernek talán bullshit-nek tűnhet a DDD. Van róla könyv angolul Eric Evans-tól. Íme a DDD főbb ismérvei:

Tiszta domain modell: A domain modellnek ne legyenek technikai függőségei. Ebbe szőrmentén az a kérdéskör is beletartozik, hogy az entitásokat ellássuk-e JPA annotációkkal vagy inkább XML-be tegyük a perzisztálási információt. De semmiképpen sem jó teleszőni a business logikát mindenféle keretrendszer és kommunikáció specifikus osztályokkal, mert így taligával toljuk a projektbe a kockázatokat: hordozhatatlanság, tesztelhetetlenség, bottleneck-ek, business és licenszelési szintű problémák.

Inversion of Control: A DDD egyik eszköze. Nem esett róla szó, de arra (is) való hogy egy nemkívánt irányú függőséget megfordítsunk. (Bővebben: Robert C. Martin, Agile software Development)

Magyarítás: Egyik blogon éppen megy a bokszmeccs. Én is abba a táborba tartozom, aki nem igazán magyarítana, bár sajnos nem tudok bekommentelni, mert minden magyar blog le van tiltva itt nálunk. (Jó hely...) Annó leírtam már a véleményemet ebben a témában, ami azóta sem változott.

Dual data source: A dolog lényege, hogy nem ugyanazon az úton nyerjük ki a perzisztens adatokat, mint ahogy beletettük őket valahova. Pl. JPA-val perzisztáljuk az adatokat, de SQL-lel szedjük ki őket. Ez jóval hatékonyabb lehet bizonyos esetekben, mert meg lehet spórolni a (java) objektumokra való mappelést. Meghökkentően hangzik, de néha mi is használjuk. Sőt, ha belegondolok ez egy funkcionális megközelítés. A perzisztens tár maga egy függvény, ami egy tranzakción belül konstans értékeket ad vissza. A service metódusaink kimenete, visszatérési értéke pedig egy utasítássorozat (Command Pattern), ami beír majd a perzisztens tárba. Érthető? Nem?

NoSQL: Ami nem azt jelenti hogy NO, hanem hogy NOT ONLY. Cesjava írt róla sokat, úgyhogy nem is részletezem.

DTO: Azaz Data Transfer Object. Nagy viták célpontja hogy legyen avagy ne legyen. Mostanában olyan (RestFul) architektúrákkal találkozom hogy egyértelműen kell hogy legyen és mellesleg nem is Java objektum hanem JSON (JavaScript) vagy XML.

Nagyjából ennyi maradt meg bennem. Nyáron szünet, ősszel találkozunk!

JUM XIV.

Most kicsivel kevesebben voltunk mint általában, ráadásul jópár régi arcot hiányoltam. Node nézzük az előadásokat.

Brillien
A brillien.org-on elég jó írásokat lehet róla találni angolul és magyarul is, de az igazat megvallva ez nem egy könnyű téma, főleg a Session Bean-ekre beszűkült agyú embereknek. Jó volt élőben is hallani róla. Felvettem a kipróbálandó dolgok listájára, de ahogy most állok lehet hogy az amerikaiak előbb érnek a Holdra (még így is), minthogy én eljussak odáig hogy valóban foglalkozni tudok a Brillien-nel.

Elég invazív egyébként a cucc, tehát eleve olyan osztályokat kell írni, amik Brillien-specifikus ősosztályokból öröklődnek és fel vannak annotálva. Megtudhattuk még, hogy valóban működik production környezetben, mégpedig telemetikai rendszereket szolgál ki, és szimpatikus BSD licenszelésű. Állítólag teljesítményben is jó, még akkor is ha sok JSON szerializációt csinál mélyen a belsejében. Akinek van ideje próbálja ki és írjon tapasztalatokat!

TodoMap

Itt lakik a TodoMap. Kocka nagyon ráment a politikai vonalra, pedig nincs rá szükség szerintem. Engem főleg a belső megoldások érdekeltek, és ebből kaphattunk is egy hosszú listát. JQuery UI-val pl. azok a tapasztalatok ha jól értettem, hogy az alap komponenskészlet nem túl bő, plugineket kell használni. Viszont ahány plugin, annyi verziójú JQuery-re van szüksége, de csak egyet lehet használni. Tehát annyira nem lett nyerő. Az authentikációhoz az OpenId-t használja, tehát nem csinál saját juzer adatbázist. Ez a megoldás engem is érdekelne egyik projektben. No a kormányzati informatikával való összedrótozással kapcsolatban igencsak szkeptikus vagyok. Esetleg kisebb falu vagy utca nagyságú közösségeket el tudom képzelni, hogy rácuppannak, de a kormányzati informatika más szint: Vetítések, baráti kézfogások, aprópénzek, asztal mellé leeső morzsák. És akkor a végén vagy működik a dolog vagy nem. Nem is írok semmit.

SameBug

Ők pedig kivételeket gyűjtenek. Még nem tudni mi lesz belőle pontosan, mert ez egy szakdoga téma, prototípus, proof of concept. Engem mindenesetre érdekelne valami megoldás, hogy ha kiböfög a programom egy stacktrace-t, adott esetben minél értelmesebb választ tudjak találni róla a neten. Erről még biztos hallunk majd. Talán én is írok még majd róla.

Videó ezúttal nem készült, de ha többszázan őrülten keresni fogják, akkor legközelebb nagyobb hangsúlyt fektetünk rá hogy készüljön.

JUM XIII.

Egy-két gondolat lóhalálában szerda estéről:

Verhás Péter Maven plugin írási bemutatója engem meggyőzött. Lehet hogy Maven-ben könnyebb plugin-t írni, mint bekonfigurálni egy projektet? Amire magát a plugin-t írták - statikus weboldalak összerakása - arra én is csak akkor vetemednék ha sajátról lenne szó. Nekik ez a saját céges honlapjuk generáló motorja. A prezi.com ismét jól szuperált.

A JBoss ESB bemutatónál egy régi sztori jutott eszembe a JMS-ről, amit el is mesélek:

6-7 éves csináltunk egy szoftvert, aminek a specifikáció szerint az volt a célja, hogy megbízhatatlan kapcsolaton lógó vastag kliensek között létesítsen kapcsolatot megbízható módon. A vastag kliensek "időnként" lekapcsolódhattak a rendszerről és alapvetően naponta "néhány", "pár kilobájtos" adattömböt küldtek a szerverre, amit el kellett juttatni a címzett másik kliens(ek)nek.

JBoss-t és JMS-t választott erre az akkori architekt ember, mert skálázható, tranzakcionális stb.

Ezzel szemben az éles rendszer valódi karakterisztikája kb. a következőképpen nézett ki: A vastag kliensek nem "néha lekapcsolódtak", hanem hetente egyszer rákapcsolódtak a szerverre, de ekkor már több ezer darab, 10-200 kilobájtos adattömb várt rájuk kiküldésre. Ez persze egyenlő volt egy fejlövéssel a JBoss-nak és a JMS-nek. Kiderítettük például, hogy a JMS válaszideje nagyjából lineárisan nő attól függően hogy mennyi üzenet van a globális queue-ban. A tanulság persze az volt, hogy "a JBoss sz*r", "a jáva lassú" és megoldásként valaki újraírta az egészet mondjuk C++-ban két nap alatt, skálázhatóság és igazi tranzakcionalitás nélkül.

Ennyi a történet. Elvileg az új JMS motor, a HornetQ gyors, nem muszáj adatbázissal használni és nem feltétlenül kell hozzá appszerver. Meglátjuk.

Scala: kíváncsi vagyok hogy valójában mennyire sikerült kedvcsinálónak az előadás, vagy mik voltak a legelrettentőbb részek. Pár dolog kimaradt, de talán a lényeg átjött.

A prezik illetve a scala példakódok elérhetőek lesznek, az előadásokat pedig meg lehet nézni az Ustream-en a JUM oldalról ügyesen odanavigálva. De a felvételeket inkább csak hallani lehet, mert a vetítő képe egyáltalán nem látszik. Erre még ki kellene találni valamit. Ötletek, megoldások welcome.

JUM XII.

Elsőnek Viczián István beszélt a JAX-WS mélyvízről. Számomra elég elrettentő hatása volt az előadásnak. Eddig nagyjából megkímélt a sors a SOAP technológiától és remélem ezután is így lesz. Találkoztam olyan projekttel, amiben szerepelt, de nem nekem kellett foglalkozni vele, vagy amikor hasonló megoldást kellett alkalmaznom találtam más módszert. Az előadás végén említésre került még pár hasonló SOA technológia. Ezek közül a REST-tel már volt dolgom és úgy érzem hogy az egészen használható egyszerűen azért, mert nem akartak mindent helyben megoldani, hanem az a mondás, hogy az üzenetek topológiája MásValaki Problémája, azaz ha akarom XML, ha akarom JSON, ha akarom akármi. És tényleg: én éppen JSON-nal használtam, ahol más formában szintén előjönnek hasonló dolgok amire JAX-WS és JAXB-nél figyelni kell. Cirkularitás, ilyesmik.

A második előadáson Csutorás Zoltán beszélt az agilis módszertanokról. Az elején az autógyáraknál és a közgázos diagramoknál nem értettem hogyan fogunk eljutni a szoftverfejlesztésig, de aztán szépen összeállt a kép. Kiderült számomra, hogy a Scrum nem egy levegőbe kitalált buzzwörd (mint a Cloud) hanem egy tanulmányokon és tapasztalatokon alapuló szigorú módszertan amit nem csak IT technológiában használnak. A Toyota gyárrendszere is hasonló elveken épül (Lean Management, bármit is jelentsen). Végülis engem a pipeline feldolgozásra emlékeztet ez az egész. RISC processzorok makrószinten. Három dolog biztos: Egyik hogy pár ügyféloldali managgert a környezetemből is elküldenék agilis módszertanokkal ismerkedni, mert az tényleg nem járja hogy először kiköpünk ezer oldal doksit az igényeik szerint, aztán leprogramozzuk vízesésben a hülyeséget. Másik dolog, hogy bebookmarkolom az előadó blogját és amint lesz időm rá olvasgatom. Harmadik dolog, hogy nem hallottam az előadáson csirkékről és disznókról, úgyhogy még biztos nagyon sokmindent nem tudok a Scrum-ról.

Uccsó előadás az Google Androidról szólt, amit nem kell senkinek bemutatni. Kiss Gergely a Linuxos oldaláról közelíti meg a dolgokat. Régebben egyébként már találkoztam vele egy Bp Newtech Meetup-on. Ő volt az, aki egy ősrégi kütyün életre lehelte az Android-ot, amikor még a fasorban sem voltak direktben ilyen telefonok. Az előadás legfontosabb hozama számomra a Hundroid portál és a magyar Android közösség bemutatása volt. (Van még ilyen is, nem tudom hogy ez ellenség-e vagy barát. Úgy látom PZ is kommentel úgyhogy ez valami hivatalos valami lehet.) Megkérdeztem tud-e magyar fejlesztésekről. Mondta hogy tud egy angol tanuló szoftverről, az Ustream-eseknek van Android implementációja, (Ustream-mel felvettük az előadásokat, utólag is megnézhetőek. Könnyen kezelhető, jó cucc! Valahol itt vannak a videók. Persze a minőség pocsék, van még min javítanunk.) és persze rögtön le is demózott egy kis alkalmazást: a saját OpenOffice prezentációját egy saját készítésű Androidos alkalmazással vezérelte bluetooth-on keresztül.

Jó sokan voltunk, a rendelkezésre álló időkeretet kicsit átléptük, sörözés úgy tudom most elmaradt, következő alkalom jövőre.

JUM XI.

Nézőcsúcs született a tegnapi JUM-on. Mondjuk így könnyű, hogy nem két nappal az esemény előtt derül ki hogy mik lesznek az előadások és mi a helyszín. Az új Számalk épület igazán trendi, letisztult helyszínt szolgáltatott Wifi eléréssel.

Néhány szó az előadásokról:

PMD, Checkstyle - statikus kódanalízis
Ha arra vetemednél, hogy saját szabályok szerint akard ellenőrizni a Java kódodat (vagy másét) akkor ezek közül kell használnod valamelyiket. Az egyikben Java-ban kell vizsgálgatni az Absztrakt szintakszisfát-t, a másikban pedig XPath-tal kell bűvészkedni. A kód duplikációk is könnyen kibújnak a zsákból ezekkel az eszközökkel, mert nem lehet átverni őket megváltoztatott változónevekkel, kommentekkel és whitespace beszúrásokkal. Az előadáson nagyvonalúan átsiklottunk fölötte, hogy mi az az Antlr és Javacc, ami a PMD-ben ill. a Checkstyle-ben dolgozik. Nos, az utóbbi parser generátor és az előbbi is valami olyasmi. Lényeg hogy ha ezekbe betoljuk egy nyelv (jelen esetben a Java) formalizált szintaktikai szabályait, akkor tudnak olyan parser-t generálni, ami fel tudja építeni egy forrásfájlból a szintakszisfát. Aztán ezt lehet interpretálni, elemezni, compilálni. Talán egyszer ezekről a parser generátorokról is lehetne előadás.

Oktech profiler
Sok olyan kérdésre rávilágított az előadó, amin eddig nem is gondolkodtam el. Hogyan lehet profájlolni? Instrumentálni lehet a kódot, vagy mintavételezni a stacktrace-t. Mindkettőnek megvannak az előnyei és a hátrányai. Ők az utóbbi irányba indultak el és nyílt forrásúvá tették a kódot. A jelenlegi formában még elég száraz a kimeneti formátuma, de van benne perspektíva. Mivel a mintavételezéses profiling főleg kilóra tudja megmondani hogy mikor mi fut én olyan bővítéseket tudnék elképzelni, amik színes grafikonokat rajzolnak.

Google App Engine
Ez is jó előadás volt. Átjöttek a Google App fejlesztő legnagyobb szívfájdalmai: olyan a fejlesztés mint egy akadálypálya, ha tényleg akar valami komolyat csinálni az ember, hamar megtalálja a falakat. Van egy hosszú lista, hogy mely java frameworkök támogatottak, melyek részben és melyek nem. Alapvetően szervlet technológia, nagyjából van JPA, de vannak bizonyos korlátok, pl. max ezer fájl lehet egy alkalmazásban. Ha pl. Dojo-t akarok használni vagy más Javascript keretrendszert ami sok kis képet használ, akkor máris bajban vagyok. A GAE folyamatosan fejlesztés alatt áll, néha bejönnek új feature-ök, néha megjelenik valami új bekezdés a honlapon. Egy bizonyos forgalmi határig ingyenes, aztán pedig fizetős. Ez az ingyenes forgalmi határ sok kritériumból tevődik össze kezdve a napi processzoridőtől a napi max deployolások számáig. Ennek ellenére szeretjük a Google-t, mert még mindig látszik a törekvés hogy adni is akarnak valamit nem csak lenyúlni. Fontos még, hogy eredetileg Python-ra volt támogatás. Java csak idén tavasszal lett, ezért még mondhatni gyerekcipőben jár.

A JUM utáni sörözéseket kellene még komolyabban venni. Legközelebb akkor novemberben!

JUM X.

Kocka és Viczi már megelőzött a beszámolóval, de azért írogatok ezt-azt. Kicsit az utolsó pillanatra sikerült mindent összeszervezni, ennek ellenére nagyon jól sült el a dolog. Az előadások is jók voltak, ahhoz képest emberből sem volt kevés és ezúttal az időtervet is sikerült betartani.

Az első előadásból nekem az jött le, hogy SOAP-os szervizek teszteléséhez a Grovvy és a SOAPUi egy elég alapvető megoldás, mivel már a második független forrásból ajánlják a használatukat. A Netbeans 6.5 Groovy támogatását láthattuk élőben. A refactor és a kódkiegészítés kicsit döcögős, de ez egy dinamikus nyelvnél mindig is sarkalatos pont.

Corsin Decurtins az Objektum Orientált adatbázisokat mutatta be. Hozott egy jó hasonlatot: "Objektumokat relációs adatbázisba pakolni olyan, mintha az autódat minden este úgy tennéd be a garázsba, hogy előtte darabokra szeded." Azóta eszembe jutott egy riposzt erre a hasonlatra: "Az autókkal kapcsolatban viszont nincsenek olyan igények, hogy kérném az összes csavart az autóból méret szerint rendezve." Végülis abban maradtunk, hogy az OO adatbázisok egyelőre egyetemi kutatások témái, éles ipari környezetben még nem állják meg a helyüket, hacsaknem a Bajor Motorgyár Rt (a.k.a BMW) termékeiben. Végülis az előadás még a gyors prototípus készítésről szólt. Szerintem a JPA-val és az EJB3-mal már elég gyorsan lehet prototípusokat készíteni, de biztos vagyok benne hogy meglesz az OO adatbázisok helye is. Még a Jazoon konferenciát reklámozta Corsin, ami júniusban lesz, tavaly ha jól emlékszem 850-en voltak. Ezt az előadást egyébként tavalyelőtt ott is prezentálta. Lehet hogy valahol van is link róla. Említett még design patterneket, pl. az Active Record-ot, ami szerintem anti, a Transaction Script-et és a Domain Model-t. Ja és a db4o egy ilyen OO DB.

A harmadik előadás az Amazon Web Services-ről szólt, ami egy számítási felhős vagy inkább virtualizációs téma (v12n). Pénzért bérelhetsz a számítási teljesítményt, sávszélességet és tárhelyet, valamint vannak előregyártott image-ek, pl. mindenféle Linux-ok, telepített appszerverek. Pár kattintással lehet csinálni egy Websphere környezetet -példának okáért- ha jól értettem. Az jött ki hogy olcsó, olcsóbb mintha szerver hostelbe betennél egy gépet, ráadásul az időszakos terheléseket jobban le lehet kezelni úgy hogy arra az időre bérelsz még egy kis virtuális teljesítményt. A múltkor nagyon kutyáztam a cloud computing-ot, de ez az AWS egy jó dolog akárhogy is nézzük. Java-val is volt némi kapcsolódási pont, mégpedig hogy vannak valami java API-k ennek az AWS-nek az elérésére (jets3t, quillen és jclouds). Valamint a Szantog szokott még erről írkálni elvileg, de nem néztem bele.

Aztán kocsmáztunk még egy kicsit (10-ig ugye), ami szerintem nagyon hasznos volt. Bár nem sokra emlékszem miről beszélgettünk, a cetlit meg elhagytam amire felírtam pár betűszót aminek utána akartam nézni. Nem baj, majd eszembe jut.

Egyébként lehet hogy megint átmegyek egy darabig ilyen meeting tudósító oldalba, mert lesz egy-két esemény amire elmegyek előreláthatólag. Pl. lesz a Sun Java Café és az Eclipse Democamp a Galileo megjelenésének alkalmából, plusz a Newtech Meetup-ok, ami ha jól látom fizetős lett. Abban maradtunk hogy nyáron nem lesz JUM -legalábbis a klasszikus előadásos fajta- tehát szeptember a következő időpont.

JUM IX.

Egészen sokan gyűltünk össze tegnapelőtt a Számalk épületében. Az első eladás a Maven-ről szólt Verhás István tolmácsolásában. A gyors közvéleménykutatás alapján jelenlévők nagy százaléka használ Ant-ot, kis része Maven-t is, Ivy-vel pedig egy ember foglalkozott.

Ahelyett hogy az előadást részletezném inkább leírom a saját fogalmazásomban bullshitek nélkül, hogy miért érdemes Maven-t használni Ant helyett:

-Ant esetén a függőségeket (egyéb jar-ok) a verziókontrollba szoktuk pakolni. hogy ne kelljen mindenkinek kézzel összevadásznia. Ez azért aggályos, mert ezeknek függőségeknek a mérete elég nagy magához a forráskódhoz képest. Fölösleges branch-elésnél kópiát készíteni belőlük, fölösleges minden egyes archiválásnál elmenteni őket. Ha több projekt ugyanazokat a jar-okat használja, fölösleges többször letárolni őket. Gyorsabban fogy a DAT kazetta, gyorsabban pusztulnak az esőerdők. Update 2009.06.21: Kommentekre is reflektálva, természetesen nem az a Maven elsőrendű célja hogy takarékosabb legyen, ráadásul ahogy megtudtam az internetes Maven repository-k elég sok téves/fölösleges letöltési kérést kapnak, úgyhogy megint csak rosszul jönnek ki a dologból szegény fák a nagyobb hálózati forgalom miatt. Viszont ha valaki internetes sourcecontrol-ba akarja tenni a forráskódját, pl. Google Code vagy SourceForge, oda tényleg nem szerencsés betenni a függőség jar-okat, mert egyszerűen elfogy a kvóta.
-A projekt kialakításakor a függőségeket készzel kell összevadászni. Ha ezt a jar-t használom akkor kell ez is meg emez is, és akkor melyik verzió is kellene?
A Maven megoldást ad erre azzal, hogy csak a függőségek nevét kell megadni, amit letölt magától a kapcsolódó egyéb függőségekkel a netről egy lokális repository-ba a gépre. Sőt, ha kell letölti a függőségek függőségeit ügyelve a megadott verziószámokra. Ha már egyszer letöltött valamit, nem megy újra neki. Szoktak használni vállalati repository-t is: ilyenkor a fejlesztők Maven-jei nem közvetlenül az internetről szedik le a jar-okat, hanem a vállalati repo-ból. Ilyen pl. az Archiva. Update 2009.06.21: Ahogy a legutóbbi Eclipse DemoCamp-en Jason van Zyl előadásán megtudtam, a Nexus az a repó menedzser amit igazán érdemes használni. Így csökkenthető a forgalom, növelhető a sebesség, ráadásul saját privát "artifact"-okat (=termék: jar, war, ear, ilyesmi) is fel lehet oda tenni. Az előadó szerint vállalati repó nélkül gondok szoktak lenni a Maven használattal komolyabb környezetben, pl. ha egy artifact-ot kézzel kell letölteni, mert privát vagy a licenszelése miatt nincs fenn publikus repo-ban a neten.

-Ant esetén ki szokott alakulni egy szilárd build.xml és könyvtárstruktúra mindenféle projekt őstípushoz, pl. webalkalmazás, J2EE alkalmazás, amit aztán csak mindig gépiesen másolgatunk az új projektekbe és átírjuk a könyvtár és projekt neveket, esetleg beleírunk egyéb extra task-okat. A build.xml igazából fölösleges is, csak azt kellene tudni hogy ez milyen őstípus és mivel akarjuk kiegészíteni.
A Maven pont ezt csinálja. A pom.xml-ben csak azt kell leírni, hogy miben térünk el az eredeti őstípustól (archetype), pl. használunk valami saját annotáció feldolgozó eszközt. Ugyanitt kell megadni a függőségeket is. Őstípust pedig roppant egyszerű létrehozni. Íme egy példa egy Wicket alkalmazás létrehozására. Egy parancssorból letölti a szükséges jar-okat, megcsinálja a könyvtárstruktúrát, buildel, csomagol, futtat teszt üzemmódban saját Jetty szerverrel, itt most éppen Eclipse projektet csinál csatolt böngészhető Wicket javadoc-cal és forrással. Ez azért nem rossz nem?

Ezenkívül tud még javadoc-ot csinálni, sőt szabványos szájtot is tud generálni a projektnek. Ez a titka az Apache és Sourceforge oldalakon található Built with Maven matricáknak. Még annyi, hogy a hivatalos Maven oldalon rengeteg a bullshit és általában szeretik nagyon túlmisztifikálni a dolgokat, de van egy elektronikus könyv Better Builds With Maven címmel, ami egy nagyon hasznos olvasmány. Mert attól hogy automatikus build eszköz, a projektgazdának nem árt érteni hozzá.

Mondták még nekem a Gradle-t ami egy még újabb build eszköz. Ahogy néztem ez valóban procedurális, mint ahogy az Ant nem az. Egyelőre nem fog meg hogy script-eket írhassak buildeléshez, mint a régi szép időkben.

Második előadás Verhás Pétertől SOAP tesztelésről szólt. Nem ez az álmaim melója, de ha muszáj akkor fel kell majd keresni a SOAPui, a Greenpepper és a Confluence honlapját. A SOAP tesztelés abból áll, hogy lapáttal hányjuk be az XML-eket egy fekete színű doboz bal oldalán, majd a jobb oldalon kijövő több tonnányi XML-t nagyítóval nézzük át. Nem árt ha ehhez van némi integrált júzerbarát környezet ami tudja mi az a WSDL és a táblázatban leírt tesztadatokból SOAP üzeneteket generálgat, valamint zöld csíkokat rajzolgat.

A harmadik előadás Viczián Istvántól az adattárházakról: A Prezi-t használta a bemutatóhoz, ami nagyon kúl volt! A blogján elvileg fog ebből írni egy cikket, úgyhogy nagyon nem is megyek bele, csak bevezetem: Ha egy -alapesetben adatbázisban lévő- adattömegről dinamikusan változó igények alapján riportokat, kimutatásokat szeretnénk csinálni hisztorikus módon (akkor is ha az eredeti adatbázisban az adatok nincsenek hisztorikusan tárolva), akkor a kerék újrafeltalálása helyett esetleg érdemesebb az OLAP (Online Analytical Processing) megoldások felé kacsintgatni. Gyorsan belátható, hogy egy ilyen feladathoz speciálisan felépített adattárolásra van szükség: Ritkák az update-ek, sokféleképpen kell indexelni, előre aggregálni kell adatokat hogy gyorsabb legyen a lekérdezés, nem igazán jellemző a tranzakionális, sokfelhasználós működés. Nem biztos hogy SQL a legalkalmasabb lekérdezési mód, sőt lehet hogy nem is relációs adatbázis az optimális tároló eszköz! Az adatokat tudni kell összesítve megjeleníteni, lefúrni a részletekbe, más szempontok szerint megjeleníteni. Erre vannak kész -leginkább fizetős- eszközök. Sajnos az előadás hamar véget ért időkorlát miatt, de még az is lehet hogy a következő JUM-on lesz folytatás. A cikket pedig kíváncsian várom!

Ismét volt videózás, de azt nem tudom hogy az elaőadások hová és mikor lesznek feltöltve. Következő alkalom pedig május 20.

JUM 09.01.21

Ismét konf. beszámolót írok, de azért nem cél a témára való teljes rácuppanás. Nézzük csak: a tegnapi Java User Meeting a Számalk épületében kapott helyet, ami a hazai számítástechnika 20-30 évvel ezelőtti temploma. Az épület emiatt inkább hasonlít egy ódon főiskolára mint egy modern irodaházra.

OSGi

Az első előadás az OSGi-ról szólt, ami egy dinamikus modularizációs keretrendszer (óeszdzsíáj, ezt mindig le akartam így írni, hát most tessék). Talán legközismertebb működő példa az Eclipse, ami ilyen alapokon fut, ugyanis a benne használt Equinox is egy OSGI implementáció.

Volt rövid elméleti bevezető aztán gyakorlatiasabb demó. Egy Eclipse-ben láthattuk először egy HelloWorld bundle (így nevezik az alapegységet) létrehozását nullából, aztán némileg összetettebb példák működését. Kb. úgy lehet létrehozni mint egy plugin-t, tehát new project, ... és ki kell választani hogy nem Eclipse hanem standard OSGi környezetben akarjuk futtatni. Ha jól sejtem nem árt ha benn van az IDE-ben a Plugin Development Environment installálva. A rendszer classloader filozófiája elég kifinomult, emiatt lehetőség van verziózott modulfüggőségek megadására a megfelelő helyeken - azt hiszem a manifest fájlban. Meg lehet adni verzió intervallumokat, egy környezetben működhet többféle verzió is egy adott egységből, satöbbi. Nekem úgy tűnt, hogy ez hasonlít a .net Assembly kezelésére. Felmerült egy kérdés, hogy ez vajon kiküszöböli-e a "bundle-hell"-t, a bundle függőségek összekuszálódását, hogy pl. a log4j-t beteszem a saját bundle-mba hogy ne váljon külső függőséggé. Ha értelmesen használják akkor kiküszöböli. Megemlítették, hogy van Maven plugin vagy bundle vagy mi, ami magától lehozza a szükséges függőségeket. (Van valakinek linkje, tapasztalata erről?)

A bundle-eket lehet futtatni, próbálgatni az IDE-n belül. Kapunk egy OSGi konzolt, amin különböző parancsokat bepötyögve tudjuk elindítgatni, leállítgatni és monitorozgatni a különböző bundle-okat. Hasonlít egyébként a Windows service-ekre első ránézésre: ott figyelnek a bundle-ek, vannak állapotaik miszerint el vannak indítva, installálva vannak de nincsenek elindítva, illetve az installálásuk nem sikerült teljesen. Némi infó még itt.

Volt szó eseménykezelésről, ami első látásra hasonlít a JMS-re, viszont lényegesen lightweightebbnek tűnik.

Az előadók elmondása szerint jobban bejön nekik mint alkalmazásszerverek és J2EE/EJB-k használata, mert egy ilyen OSGi konténer nagyon hamar - a másodperc törtrésze alatt - újraindul, kevés gond van vele. (Hát én azért vállalati alkalmazásoknál eléggé meg vagyok elégedve az EJB3-mal, szóval ezek után még nem váltanék. Megbecsülöm az EJB appszerver admin konzolokat, realm és resource konfigurációs szolgáltatásokat amiket egy-egy appszerver ad.) Szó volt még Spring integrációról, de ez enyhén szólva nem hangzott jól. A bundle-n belül van applicationContext vagy a bundle-k vannak egy nagy applicationContext-ben benne, vagy a kettő egyszerre? Kínzó kérdés.

Adobe Flex

Cornel Creanga az Adobe bukaresti irodájából jött el evangelizálni. Az elején megijedtem, hogy a mainframe-ektől indul az előadás, de szerencsére hamar eljutottunk a Flash-ig és annak jelentőségéig. A demók mindenképpen meggyőzőek voltak, de nagy bánatom hogy nincsenek Flash és az erre épülő Flex fejlesztéshez ingyenesen használható eszközök, csak az Eclipse alapú Flex Builder. Említésre került az AIR, ami egy desktopos flash futtatásra alkalmas platform Webkit alapokon.

A számunkra legérdekesebb dolgok az előadás végén hangzottak el a java integráció kapcsán. Alapvetően a Flash HTTP, SOAP és mindenféle socket alapokon tud kommunikálni a szerveroldallal, de van lehetőség olyan elérésre, ami a JavaScript JSON mechanizmusához hasonlóan automatikusan elvégzi a távoli metódushívásokat és az eredmények továbbítását a szerverről a kliensre. Van hibernate integrációs szerveroldali komponens, ami gondoskodik a kliensről leküldött objektumok megfelelő perzisztálásáról.

Demózásra kerültek olyan használati esetek, amikor a szerver push-olja az adatokat a kliensre, vagy amikor egy A kliensen átírt adatok rögtön megjelentek a B kliensen reload nélkül (kliens = web böngésző). Láttunk példát Flash pdf dokumentumba való beépítésére is. Talán a legfontosabb, hogy van egy Tour de Flex példaalkalmazás amit érdemes lehet nézegetni. Elvileg sok érdekes példát tartalmaz.

Kaptunk egy mini O'Reilly könyvet Getting Started With Flex 3 címmel. Villamoson való olvasgatáshoz tökéletes.

Előadások után elmentünk páran a Bajor Sörözőbe a Móriczra, ahol egyszer ki kell próbálni a sztrapacskát. Megbeszéltük a nagy nemzetközi helyzetet Cornel-lel. Náluk is Microsoft-ot használnak az állami szektorban, a bundáskenyeret bundáskenyérnek hívják és így tovább.

A legközelebbi JUM alkalom márciusban lesz, ahol jó lenne behajtani a most elmaradt JPA 2.0-t. Többször is elhangzott az a szó, hogy Groovy és hogy többeket is érdekelne egy ezzel kapcsolatos eszmefuttatás.

JUM

Három előadás volt a tegnapi JUM-on, ami végülis nem tudom hányadik alkalom. Itt balra pedig a JUM.hu logó látható, ami már a Devoxx-on is kinn van. Hurrá! Szóval a három előadásról:

REST = REpresentational State Transfer

Lényege, hogy a SOAP és CORBA bürökratizmusa helyett törekedjünk lényegretörő agilis (hogy divatos szót is használjak) megoldásra. Szép hogy SOAP menne email-en keresztül de minek ha a legtöbb adott problémánál nincs rá szükség, viszont a HTTP infrastruktúrája tökéletes (?). Sok mindenre ad jól kimunkált és széles körben letesztelet megoldást. Én már az előadás előtt utánaolvastam néhány dolognak, de nem akartam ilyen kérdésekkel kukacoskodni, hogy vannak-e REST-ben (HTTP-ben) lehetőségek push-ra, aszinkron üzenetváltásra, meg amúgyis tudom a választ. Aki még tudni akarja:

• Áttekintő cikk a javaworld-ön
• mp3 Interjú Stefan Tilkovval németes akcentussal angolul. További linkek a címen.
• S.T. gyakorlatiasabb cikke
• Szkeptikusoknak
• Wikipedia
• A JSR-311 home-ja ez a kapcsolódó JSR. (JAX-RS) Meg kell jegyezni, hogy a REST egyáltalán nem nyelv- és platformfüggő. A J2EE1.6 része lesz, de a .net 3.5-ben is akarnak REST supportot. Ezenkívül a szabvány nem akar prezentációs formátumokat -és még sokmindent- lefektetni. Ha jól értettem egy speciális szervlet segítségével már most minden további nélkül használható a megoldás.
• API 1.0 nem bonyolult, nem sok. Annotációkra épít, 1.5 alatti Java-t nem is fogja támogatni.
• Jersey - a referencia implementáció.
  
• Bónusznak RESTful URLs with Wicket

Abszolút pozitívan állok a dologhoz. Egyébként már 5 éve is csináltunk ilyen megoldásokat, igaz csak prototípusnak. HTTP-val kommunikáltunk mindenféle registry és WSDL karbantartása helyett. Vicces lenne ha egy az egyben kimaradna az életemből a SOAP, ami nem is szimpatikus. Fejléc, boríték, nemtudommi... A REST a szemantikus web-et (mégegy divatos szó) is jobban ki tudja szolgálni szerintem, de ebbe most nem akarok belemenni. Jobban be lehet járni és feldolgozni pókokkal, összetársítani tartalmakat, asszociálni, szolgáltatásokat építeni meglévő szolgáltatásokra.

Vannak még nyitott kérdések, pl. hogy a JSR-311-et hogyan fogják összepárosítani valódi prezentációs technológiákkal pl. GWT, JSF, Wicket. Ha elgondolkodnák rajta lehet hogy meg is lenne a megoldás, de az előző postban leírtak miatt nincs lehetőségem erre.

Jazz

Második téma a Jazz volt, ami egy kollaborációs eszköz az IBM háza tájáról. Van benne verziókövető, issue tracker (vajon hogyan fordították?), támogat agilis módszertanokat pl. scrum. Eclipse-ben is működik és azon kívül is valami webes felülettel. Tervezik az integrációját egyéb fejlesztői eszközökbe is. A Jazz fejlesztésére is Jazz-t használnak. Jövőre elvileg kész lesz a magyar fordítás. A Javaposse 211. epizódjában egy interjú hallható Erich Gamma-val Tim Francis-szel az IBM-től. 18 perc környékén a Jazz is szóba kerül.

Glassfish V3 prelude

A mikrokerneles Glassfish pre-béta verziója. Sokminden nincs még benne pl. EJB3 konténer, emiatt inkább egy Tomcat-re hasonlít. Egyelőre az jött le hogy nem kell ezt még igazán komolyan venni, nem kell tőle sokat várni. A koncepciói kicsit ijesztőek, pl. hogy amikor először akarok admin konzolozni akkor jön rá hogy le kéne töltenie a netről az admin konzol csomagját. Hát, hmmm. És ha akkor akarok először használni valami csomagot amikor történetesen csak intranet elérésem van?

Jövő

A következő JUM elvileg 2009 január harmadik szerdáján lesz és valószínűsíthető egy OSGI előadás (ez nem tudom végül bevállalódott-e), egy JPA2 esetleg és egy Scrum, ami egy módszertan csirkékkel és disznókkal.

Kösz a szervezést karenin-nek!

Appszerver deatmatch Part 1

Van még egy elmaradásom. Szóval a legutóbbi Java User Meeting-en lement az Appserver deatmatch első része, azaz a Sun ingyenes Glassfish v2 szerverét nyüstöltük. Azaz nyüstölte két hozzáértő ember, egy előregyártott "vendégkönyv" ejb-webes alkalmazással, mi pedig figyeltük a kivetítőn ténykedéseiket. Nézzük a nyolc feladatot:

1. Egy EJB3 + JPA alapú egyszerű webes vendégkönyv alkalmazás beüzemelése a gépre telepített adatbázissal, bónuszként a benne lévő webszolgáltatás WSDL-ének letöltése.

Hamar ment, rögtön a második részt is kipipálva. Belenéztünk a WSDL-be (csúnya nagy XML, lényeg hogy automatikusan generálódott) és csináltunk egy teszthívást a Glassfish admin konzol segítségével. A teszthívás azt jelenti, hogy kitöltögettük a Glassfish WSDL alapján dinamikusan generált HTML formját és submitáltuk.

2. Build script-ből (távoli) deploy.

Netbeans-ből nyomták Ant-tal egy speciális Glassfish task-kal. Tehát nem sima másolási műveletről volt szó, bár úgy hallottam támogatja a hot-deploy-t is, azaz pár másodpercenként szkennel egy könyvtárat és ha talál változást benne akkor újradeployol.

3. Loggolási konfig megváltoztatása egy alkalmazás alatt futásidőben.

Ezt is az admin konzolon lehetett megcsináli és a logot is ott néztük csilivili táblázatban. Szokásosan loggerenként lehet severity level-t állítgani. A példaalkalmazás ilyen szempontból hazabeszélős volt, mert épített arra, hogy a Glassfish admin konzolja a Java Logging API-t támogatja (és csak azt). log4j konfigot gondolom a log4j.xml kézzel való szerkesztésével lehetett volna állítgatni és a csilivili html táblázatról is le kellett volna mondani, de ennek mégis jobban örültem volna.

4. A vendégkönyv távoli debug-olása.

Ez is simán ment, de a Glassfish-t újra kellett indítani a Debugolás megkezdése előtt. Úgy rémlik a JBoss-t nem szoktuk újraindítgatni, fixre be van állítva neki egy kapcsoló hogy engedélyezi a debug kliensek csatlakozását. A kapcsolót persze nem lehet menet közben váltogatni. Netbeans volt a debugoló kliens, de más is lehetett volna, mert standard debug portot használ.

5. Adatforrás megváltoztatása futásidőben.

Ez nem ment (exception), bár nem is vártuk el. Szerintem semmelyik alkalmazásszervernél nem működik. Az alkalmazás újraindításával viszont már simán ment. Ezt is az admin felületen állítgatták.

6. Appszerver leállítása majd újraindítása a deployolt alkalmazással.

Ezt észre sem vettem. Nem mértünk időt, de 10 másodperc körül lehetett sacc per kábé.

7. LDAP azononosítás (ha belefér az időbe)

Ez sikerült volna, de már kezdtünk kicsit kicsúszni az időből. Az mondták 10 perc alatt megvan általában, még 2 perc kéne (8 perc eltelt akkor).

8. Terheléses teszt (JMeter)

Terheltünk, 1700 request/sec-en ketyegett egy átlag notebook-on. Már nem emlékszem a pontos számokra, de tuningolással talán fel tudták vinni 2200-re. (JVM paraméterek.) A terhelésnél a loggolás ki volt kapcsolva és a debug mód sem működött. Ennek a pontnak akkor lett volna értelme, ha azonos hardveren van mivel összehasonlítani, így magában nem sokat mond.

Nagyon jól felkészültek voltak a srácok. Kíváncsi vagyok a többi versenyzőre 2 hónap múlva. Remélhetőleg felveszik a kesztyűt és ők is komolyan veszik a dolgot. Továbbá előtte kipróbálják azért a tesztalkalmazást, esetleg megcsinálják benne a szükséges változtatásokat, hogy fusson a saját appszerverükön is.

JUM VI.

Ismét volt JUM.

Az első előadáson a komponensmodellekről hallgattunk egy elég általánosan induló prezentációt, miközben az alábbiak jutottak eszembe:

• A komponens-orientáltság az objektum orientáltsághoz hasonlóan nem minőségi jelző, hanem csak egy módszer, amit mellesleg lehet jól és rosszul csinálni.


• Keretrendszer használata nem cél hanem eszköz. Mostanában egyre jobban kezdem értékelni azokat a szoftver megoldásokat, amik nincsenek teledobálva buzzword kompatibilis komponensekkel, viszont működnek.


• Problémamegmaradás törvénye: 'A probléma nem vész el csak átalakul'.

Ennek ellenére szoktunk használni framework-öket, pl. a Spring-et elég sokszor, egészséges felfogásban. (Szóba került hogy egy Magyarországon nemrég tanyát vert igen neves pénzügyi nagyvállalat is elég komolyan használja a Spring-et.)

Azért leírom mely versenyzőkről volt szó:
Spring, Guice statikus IoC frameworkök.
OSGi, Java Moduling System azaz JSR-277. Az utóbbit a Sun hozta létre az OSGi ellenében. Az előbbi pedig már jó régóta létezik és az embedded device-ok környékéről indult.
Valamint SCA, ami általánosabb, ha jól emlékszem az IBM nyomja.

A második előadáson kocka mutatott be egy Flex-es alkalmazásról szóló prezentációt. A jhacks-ról le lehet tölteni a prezit és a példaprogramot is.

XML-ben és ActionScript-ben kell összetolni az oldalt. Az IDE támogatás nélküli scriptelés már kicsit fájt a syntax highlight-hoz és auto completion-hoz szokott fejemnek. Elvileg a Parleys-t full Flex-szel húzták fel. A buildelés itt sem tart kevés ideig, 1-2 percekről beszéltünk, mint ahogy GWT-nél is. Elvileg az OpenLaszlo buildelése gyorsabb, de annak nem túl szerencsés az RPC modellje, mert statikus függvényeket használ és mindenképpen a saját proxy-jával akar kommunikálni.

Továbbá volt még egy Appserver deatmatch című történet, ahol Geronimo, JBoss és Glassfish szerverekkel csináltunk volna meg 8 műveletet, úgymint távoli deployolás, alkalmazás beüzemelése, log konfig megváltoztatása, jMeter-es terheléses teszt, újraindítás, datasource megváltoztatása, LDAP azonosítás, valamint távoli debugolás. Sajnos a Geronimo-s ember lemondta, a JBoss beüzemelése pedig nem sikerült, de a Glassfish demót nagyon hozzáértően tolták. Kicsit rövid volt az idő a tesztalkalmazás publikálása és a demó között, ezért én némileg megértem a technikai nehézségeket, de remélhetőleg 2 hónap múlva láthatunk majd más versenyzőket is. A Glassfish mutatványt egy másik postban írom le nemsokára.

Azon kívül láttam még szép színes notebook-okat, pingvines játékot és szóba került, hogy el kell menni birkát legeltetni. Sörözés most nem volt.

JUM V.

Megvolt az ötödik is. Kocka leírta hogy mi volt, az éppen építgetés alatt lévő Javafórumon pedig született egy-két topik a találkozó után. Egyik a JasperReports-ról, másik a Java 7 vitafórumról. A régi általános paláver topik pedig itt van.

A fórumon leírtakon kívül még szóba került, hogy a Windows (Vista?) eléggé .NET alapú, ami érdekes helyzetbe hozhatja a JVM-eket. Márminthogy .NET-re kell írni a JRE-t. Jobban belegondolva nem hiszem hogy ez akkora gond lesz.

Érdekes dolgok történnek mostanában, annak ellenére hogy a Java halott.

Ha jövőre véletlenül a Javapolis felé vetődnék: Sajnos elfelejtettem, hogy Antwerpenben drága vagy olcsó a tömegközlekedés és a belvárosban vagy a külvárosban érdemesebb szállást foglalni. Arra emlékszem, hogy nem szép hely, viszont jövőre is ugyanott lesz a JP.

A következő JUM március 19.-én lesz és elvileg GWT-re, SOA-ra már lehet számítani. Sörözés közben még súgtak izgalmas ötleteket a következő vagy az azutáni JUM-ra, de nem tudom mennyire publikus úgyhogy nem írom le.

JUM IV.

20-30 fős társaság gyűlt össze a novemberi paláveren. Szerintem ez nem kevés, illetve nem lenne rossz, ha a következőn is lennének ennyien. Érdemes eljönni, nem messze van a Lehel tértől. Bp-n, persze.

Android: Rövid, pörgős előadást terveztem, éppen ezért kissé felületes lett. A végén a kérdezős-vitázós-beszélgetős részben viszont elhangzottak azok a fontos részletek is (mástól), amelyek a prezentációba nem kerültek bele. Az előző postban már sokmindent leírtam az Androidos témával kapcsolatban, de még annyi, hogy Midorinál is van néhány hasznos link. A decemberi Budapest Tech Meetup-on pedig szintén lesz egy előadás erről a csodáról.

Glassfish: Megtudhattam, hogy a GF a szabványt maximálisan követő appszerver a JBoss-sal és egyebekkel ellentétben. (A JBoss nem kapta meg a minősítést.) Kommerciális verziója a Sun Java System Application Server. Szép és ingyenes, JSF-en alapuló management konzolja van. Még nem a GFv2, hanem csak a GFv3 lesz a mikrokerneles, gyorsan induló változat. Elhangzott, hogy mégis elég sok helyen JBoss-t használnak. Mi is, viszont én szívesen kipróbálnám a GF-et fejlesztésre. Nem tudom, hogy támogatja-e a következő dolgokat:

• robbantott ear és war fájlok hot deployolása.
• van egy log4j.xml amit szerkesztgetve könnyen befolyásolható a loggolás.

(Tipp: nyilván tudja ezeket.)
Ennyi nagyjából elég is lenne a fejlesztéshez. Az előadás közben elgondolkodtam rajta, hogy mennyire más igények merülnek fel fejlesztés és üzemeltetés közben. Fejlesztés közben nem érdekel a fürtözhetőség, a grafikus konzol felület, hanem inkább az, hogy az iterációs körök minél rövidebbek legyenek. Erre nagy segítség, ha nem kell becsomagolni az ear-t, (hogy az appszerver aztán kicsomagolja magának egy munkakönyvtárba). Esetleg az appszerver csak a valóban megváltoztatott komponenseket nyalja fel újra. Ez még akár azt is jelentheti, hogy a fejlesztés közben nem kell kilépnünk a webes vagy egyéb kliens alkalmazásból, mert megmaradnak a session-ök. Ha jól értettem a Glassfish-Netbeans páros nagyon szépen tudja ezt. Nem hátrány az sem, ha a szervert lehet rángatni Ant taskokkal.

MDA: Azt hittem, hogy az AndroMDA -ban benne foglaltatik az UML diagramok megrajzolása is, de nem. Arról van szó, hogy szabványos UML rajzoló eszközzel megrajzolunk valamit, amiből ez a program különféle sémák alapján legenerálja a programkódot. Sémákat (vagy cartridge-eket) mi is gyárthatunk (Velocity ), viszont mindenkinek megvannak a saját jól bejáratott sémái a fiókjában, amit nem oszt meg másokkal. Mint kiderült, kevés a jó és szabványos UML generáló eszköz. Felmerült az OmondoUML Eclipse plugin, amivel már régen találkoztam, de annó annyira nem tett rám mély benyomást, hogy huzamosabb ideig használjam. Az AndroMDA végső soron egy konzolos eszköz, amit Maven -nel lehet működtetni. A kódgenerálás utáni változtatások itt is problémát jelentenek, mint mindenhol. Ha átírjuk a kódot, ő új kódgenerálás után szépen felülírja. Persze vannak olyan részek, amiket elvileg nem ír felül. Java mellett bármilyen nyelvre tud fordítani, ami a sémáktól függ -ennyivel több az integrált eszközöknél. Eclipse-szel, Hibernate-tel és JBoss-sal a legérdemesebb használni de a demó során éppen Netbeans-Glassfish-Toplink(?) használatot láthattunk -akadtak is emiatt kisebb gondok. A javakocsma, avagy a javaforum2.0 is ezzel az eszközzel és az imént említett technológiákkal készül. (A Glassfish-nek gondot okoz a javaforum2.0.ear fájlnév.) Az a véleményem is megerősödött, hogy hatékony UML szerkesztéshez iszonyat nagy monitor kell.

Szóba jött még, hogy mi itt egymás között szépen pajzsra emeljük a szimpatikus java-s eszközöket, miközben a "nagyok" hazai terjesztői többnyire arra törekszenek az általuk avanzsált termékek népszerűsítésénél, hogy minél kevesebb munkabefektetéssel megszabaduljanak a feladattól -legalábbis néha úgy tűnik.

JUM III. Shownotes

Mivel lettem okosabb a JUM III-on?

• A Webservice-ek írásához többféle lehetőség létezik. Az egyik ilyen az Axis 1.x, aminek a használatához kicsit sokat kell java-t és xml-t gépelni, néha sztochasztikusan működik a meglepetésekre nem vágyó fejlesztő szemszögéből, viszont gyors. Az Axis 2 sokat változott az 1.x-hez képest. Kulcsszavak még: WSDL, SOAP. Webservice-ek nemcsak java-ban írhatóak. Elvileg van szabvány, gyakorlatilag vannak súrlódások.
• Az XFire egy webszervice-es SOAP provider. Állítólag gyors és sokkal egyszerűbb mint az Axis 1.
• A JMaki az N-edik webes framework, aminek a lényege, hogy mindenféle másik keretrendszerből (pl. Dojo) adoptálták a komponenseket és egy saját XHTML-ben, (JSF?) kell összedobálni a GUI-t mérsékelt Javascript, HTML és JSON tudást felhasználva. Netbeans plugin van hozzá. Ahogy sejthető, érhet meglepetés fejlesztés közben. Nem túl takarékosan bánik a kliensoldali erőforrásokkal sem. Pl. egy táblázat JSON-ban kapja meg az adatokat amiből még DOM-ot kell csinálni és ez párszáz soros táblázatoknál súlyos 10 másodpercekig eltarthat.
• A Flash immáron valós konkurenciája vagy alternatívája a Javascript+HTML-nek bizonyos esetekben. Flex Openlaszlo . Kocka fel is teszi a kérdést, hogy mi az előnye a HTML-Javascript-nek a flash-sel szemben.
• A MINA egy apache-os, NIO-val kapcsolatos framework, ami valamiféle vékony logikát tesz még a meglévő java szolgáltatások fölé. Ha NIO-val kell dolgoznom, mindenképpen meg kell nézni a MINA-t.
• A NIO "egy nagyságrenddel" gyorsabb az IO-nál (InputStream) ha sok kliens folyamatosan nyomja az adatokat, mert a hagyományos IO-nál sok erőforrást igényelnek a szálak közti váltások.
• Van egy JCRPG (?) nevű blog vagy ember, akinek érdemes lenne megnézni az írásait. Java 3D-ben munkálkodik. Azt hiszem ez lesz az.
• Mostanság úgy is szoktak webes grafikákat, pl. táblázatokat rajzolni, hogy pixeles nagyságú színes div-eket tesznek ki pontosan pixelre pozícionálva. Pl. a G. grafikonjai is így működnek. Ez aztán a hányás nem mondom.
• JUM-ot nem érdemes péntekre szervezni, viszont érdemes jobban, többször, több helyen meghirdetni, mert könnyen elkallódik az információ és az emberek.
• Létezik egy Budapest New Technology Meetup Group ami szintén egy jópofa dolog lehet. Érdemes lenne benézni majd egyszer-kétszer-többször. A honlapon elvileg vannak régebbi videók, itt pedig egy előadó beszámolója van. A következő alkalom Október 3. Meglátjuk.
• A Belga sörözőben a Vígszinház mögött sokféle egzotikus sör és étel kapható. Az árak nem túl diszkontjellegűek, de a hely hangulatos.

Paláver (a.k.a Java User Meeting)

Volt egy összeröffenés a Victor Hugo utcában, amit a javaforum-on szerveztek össze. Néhány előadás 7-től 10-ig este, nagyon hasznos volt. Igazából leírták róla páran amit akartak és amivel nagyrészt egyet is értek, úgyhogy itt vannak a linkek:

• A paláver úgynevezett home-ja. Java User Meeting-nek is nevezi
  
• Javafórum, topik
• Egyik előadó blogbejegyzése, blogja
• kozka blogbejegyzése, szintén előadott

Lesznek majd fóliák és talán videók is elvileg. Na és remélhetőleg lesz még paláver.