Summary: TheServerSide Java Symposium Barcelona 2007

Osszefoglalasul:

Nehez lehet jo konferenciat szervezni. A resztvevok egy resze egy csomo technologiaval ott talalkozik eloszor, nekik csak bevezeto eloadsokat lehet szervezni. Egy masik resze hardcore developer, ok hamar megunjak az altalanos bevezetoket. Talan savokat kine csinalni ilyen szempontbol is, beavato es boncolgato eloadasokbol.

A TheServerSide Java Symposium Eur szervezes korrekt volt, vegul is rutinosak a sracok, de nem volt benne az az agilitas, ami pl. a Jazoon oldalairol nagyon lejott (ok nagyon dolgoztak, hogy bloggereket bevonjanak, mindenfele ujjitast talaltak ki a programba, stb.). Itt alig volt olyan, ahol be akartak volna a resztvevokat vonni a buliba (volt egy tabla a folyoson olyan kerdesekkel, hogy pl. ORM-re alternativak, es oda lehetett firkalni, de nem nagyon haraptak ra az emberek).

Az eloadasok szinvonala eleg valtozo volt, de persze ez miattam is van, vannak nalam kevesbe fanyalgobbak is. Ugy tunik a rutinba eso szervezes dacara is a TSS nevnek volt annyi vonzereje, hogy eleg komoly embereket elhivjanak. Ennek ellenere nalam megis foleg kis emberek voltak akik bejottek.

A TOP5 eloadas nalam:

1. Jevgeni Kabanov: Aranea-rol
2. Stephene Colebourne: Java Closures
3. Ola Bini: JRuby
4. Alexander Popescu: JCR
5. Cliff Click: Java Performance Myths

A tobbi vagy kifejezetten rosz volt, vagy csak unalmas, csagy nekem nem mondott sok ujjat. A fent emlitett embereken kivul meg szimpatikus volt Burce Johnson a GWT fomuftija, o is eleg jo spielernek tunt. Ja es Neal Ford-ot is ertelmesnek tartom.

Osszessegeben en egy sesblog fele 0-7es skalan egy 4-essel ertekelem ay esemenyt. Ha lesz meg alkalmam elmenni konferenciara, biztos nem ide mennek ujra, hanem kiprobalnek valami mast, es csak akkor jonnek ide vissza, ha a tobbi sem bizonyul jobbnak.

DAY 3: TheServerSide Java Symposium Barcelona 2007

A harmadik napra elfogyott a lendulet, nagyon gyengere sikerult a felhozatal:

Meeraj Kunnumpurath, Jim Marion, Jeremez Boynes: SCA/Fabric 3 - Not the Same Olda Architecture Yet another Apache JCA implementation (lasd meg Tuscany). Harman tartjak. Az elejen bo lere eresztett bevezeto, de igen, tudjuk miert es mire jo az integracio. Aztan egy nem tul latvanyos demo. Valami olyasmit lattunk, hogy a Fabric3 clusterszeru kepesegekkel bir, de hogy mi az SCA tetje, es pl. egy PHP componenttel hogy tarsalgunk, az nem derult ki.

Ted Goddard: Ajax Security Smackdown Itt elkovettem azt a hibat, hogy beultem egy olyan ficko eloadasara, akinek a cege szponzor volt. Ti sohase tegyetek. Akinek van penze, az lehet, hogy okos embereket foglalkoztat, de nem feltetlenul jo eloadokat.

Jevgeni Kabanov: Step-by-Step Legacy Migration With Arena Ez a nap fenypontja, es talan a 3 nape is. Nagyon jo volt. Pont megfeleloen tomor bevezeto, a trivialis peldakat nem mutatja meg eloben, csak pont jo output kivagasokkal, de demo is van. Nagyon jo eloadas fejlesztoi szemmel. Jol felvazolta mi a tetje a dolognak, es hogy a kodban kb. milyen buktatok voltak, es kb. milyen megoldasrol van szo, hogy mukodik.
Maga a temara amugy csak jobb hijjan ultem be, de vann benne ertelem amugy is. Egy komponens alapu (naluk Widget) webframeworkot csinaltak (Aranea). Ez eddig meg mindenkivel megesik, nem nagyon izgalmas. De kitalaltak, hogy legacy alkalmazasokat ugy migralnak, hogy csinaltak olyan specko Widget komponenset, amibe pl. egy egesz Struts-os alkalmazast be lehet tenni. A regi alkalmazast reszekre bontottak, es a reszeket egyenkent tudjak atmigralni JSF, GWT, vagy akarmire (mihez Widget ragaszto osztaly kesz van, de ki fog jonni sok). A regi reszek a frameworkon belul Widgetek, es az uj reszek is. Azt hiszem nem tudtam jol elmondani, de erdemes vele foglalkozni, mert nemcsak hogy okos, de eleg lightweight megoldasnak is tunt.

Kirk Pepperdine: Mesauring up Performance Nyilvan tele volt a konferencia menedzserrel, de en hegesztomunnkas vagyok. Ha fel oraig csak folyik a mese, hogy igen merni kell, es nem tok mas rendszeren, mert akkor lehet, hogy nem jon ki a hiba, szoval ilyet hallgatva egy kicsit elszall az ihlet.

Thomas Watson: Server-side Equinox/OSGi and You Neztem az orat 1+1/4 oras eloadas, es 3/4 ora elteltevel meg csak Equinox-rol es Eclipsrol volt szo. Meg kicsit OSGi-rol, amit mar hallottunk tegnap. Szoval jo tema, lassu eloadas. Amugy arrol van szo, hogy vegre Servlet kontenerbe is behegeszttenek OSGi kontenereket. Kb 1,5 eve, amikor ez iranyba nezegettem valakik meg azt irtak, hogy ne kelljen nekem WAR fileban OSGI kontener, inkabb deplozoljak webszerver OSGi komponenst a standalone OSGi kontenerbe. Na ez azert eleg sovany, kb azt jelenti, hogy hasznalj Jettyt es kesz. Most vegre lathato, hogy megoldottak a dolgot, ami figyelemre melto. De ezt szebben is lehett volna mondani.

DAY 2: TheServerSide Java Symposium Barcelona 2007

Mielott teljesen elaludnek a gep elott egy gyors vazlat:

Cliff Click: Java Performance Myths: What Lurks Deep Inside a JVM? Az eloado a tipikus szaki, aki mar nem is tud a temajarol beszelni, mert csak azon morog, hogy micsoda szart latott megint. Nem egy karizmatikus figura, es sok slide arrol megy, hogy milyen hibakat latott mar publikalt C vs. Java microbenchmarkok olvasasakor. Azert nehany vicces dolog is kiderult:
Hogy melyik a gyorsabb, az sokban fugg az adott alkalmazastol +-10%-os peldat fel sorolt (egyet asm vs. bytecode szintjen elemezgetett is, hogy miert), de o kiotlott olyan specialis problemat is, ahol a Java 50%-ban gyorsabb volt (persze arra ment ra, hogy kibabraljon a gcc-vel). Elmentdta, hogy a final kulcsszo hasznalat tok mindegy, es hogy ugy lehet jo eredmenyt elerni, ho "common code"-t irunk. Magyarul olyat, amire van optimalizalo a JIT-ben :). Elmagyarazta, hogy a GC-tol nem kell felni (object poolingnak alapbol nincs ertelme, csak koltseges inicializalaskor: pl db conn). Sokat valtozott a GC-is ugyanis es 100Mb-os heapnel elenyeszo. A problema az 1-4G-s heapeknel jon elo. Ott tenyleg lesz. Alapvetoen nem volt szerintem kifejezetten jo eloadas, de most hogy irom a jegyzeteket, talan ebbol az eloadasbol tudtam meg ezen a napon a legtobbet. (Itt a blogja is).

Gregor Hohpe: Programming without a Call Stack - Event Driven Architecture A google izgaga eloadoja. Szerintem kb. 10 percben ossze lehetett volna foglalni a lenyeget, egy jo abra volt, az mindent elmagyarazott. Az EDA-t egyebken kb arra a szinte raknam, ahol az ESB-s orchestration vagy coreography van. Ez is egy tervezesi minta, ahogy a service-eket osszekapcsoljuk, csak mas a filozofiank az osszekapcsolas mogott.

Jonas Boner: Pojo Scalability and Large Workloads with Open Terracotta Vagy az ebed hianyzott, vagy az eloadas volt kicsit lankadt, de nem tudtam mindig kovetni, hogy mit miert ervel. Mutatott sok kodot, meg szep abrakat. A vegen osztott Terracotta bemutato cikket, ami kb. hasonlo szemben elmondta a lenyeget mint o, gondolom ez a cikk letoltheto a Terracottarol. Ebbe bele nezve azert kb. tudom pozicionalizalni. Megosztott JVM gepek kozott. Van egy szerver es annak jelentik le a kliensek az allapotot. A flikk-flakk kivulrol csak annyi, hogy deklaralni kll XML-ben, hogy mely osztalyok allapotat ossza meg a JVM-ek kozott (egy csomot felesleges alapbol). Meg persze nyilvan kod szinten belul dol el a dolog.

Az ebed alatt a Sun beszel. Glassfish, WS stack, sok ujdonsag nincs. Elmegy az ido, a vegen mar csak epp megvillogtatni van ido ket SunSpot-ot.

Adrian Coyler: OSGi - A New Foundation for Enterprise Applications A tag a Spring-OSGi vezetoje, igazablo errol beszel. Az OSGi-rol csak bo lere eresztett bevezeto (de azt nem tudom meg, hogy az alapveto versioninig-classhiding-en kivul mit tud az OSGi, pedig remlik, hogy vannak ott meg security meg mindengele kiegeszitok). Azt lattuk, hogy mi lesz belole a Spring 2.1-en. Hat jo. Szep munka.

Eric Lu: Getting Started with JSR-208 - JBI Azt nyujtja, amit vallal: Getting started. Ezt a reszt kibekkeltem. Ami miatt erdekes volt szamomra, hogy a szokasos Hello World peldat (Amihez NetBeans tutorial van, OpenESB-hez), o a sajat ChainBuilder cuccaval mutatja be. Varazsol egy Service Componentet (nem csak drotoz!), aztan Eclipse alapu vizualis huzigaloval beizzitja. Szolid eloado, de a termekuket (szinten OS) meg kene nezni.

Es innentol BOF sessionok kovetkeznek:

Bruce Johnson: Making GWT Better Annak ellenere bementem ra, hogy az elozo GWT-s eloadason nem voltam, es nincs tul sok GWT tapasztalatom. Az eloado nagyon meggyozo, ugyesen keverte a beszelgetest es a prezentalast, sok kerdes elhangzott. Jozan ember, teljesen jol latja a termekuk elonyeit, es a kompromisszumokat, amiket emiatt bevallaltak.

Attila Szegedi: Using the Java 6 Scripting API Hazankfia (sajnos nem tudtam vele beszelni, mert utana lecsapott ra valami oltonyos kerdezoskodo) szolid eloadast tart a Scripting API-rol. (Egyszer najdnem en is tartottam, ezert emiatt en mar atneztem az amugy eleg szimpla API-t). O persze azert mas kaliber, a Java 6-ban alapbol szamitott JS motort a Rhino-t tartja karban. Egy kicsit kevesbe ereztem rutinosnak, es ez sajnos kicsit ratelepedett az eloadasra, de a kerdeseknel mar sokkal felszabadultabb volt, es mondott meg ezt-azt.

Alexandru Popescu: JCR in the Real World A JCR-rol rovid bemutatas (kozepesen izgalmas). Aztan beszelgetesbe megy at, elmond ezt-azt InfoQ.com-rol, ami mogott JCR-van. Egy finn fickoval aztan parttalan vitaba bonyolodik a tarsasag, az absztrakciorol. Eleg szimpatikus ficko, es jo megerzesei vannak, es erdekesen mondta el. Habar azt nem mondta el, amit en tudok, hogy miert ultimate eszkot a JCR, de most nincs helyem mar ide irni a margora (hi, F.).

A nap folyaman nehany magyarral beszeltem, ok alapvetoen csalodottak voltak az eloadas szinvonalait illetoen. En kellemesen csalodtam azert, egy kicsit rosszabbat vartam, ha jo erzekkel helyezkedett az ember, kibekkelte a nagy hulysegeket, es akadt ertekelheto is jocskan.

Holnap utso nap.

DAY 1: TheServerSide Java Symposium Barcelona 2007

Akkor nezzuk:

Martin Fowler, Neal Ford: Language-oriented Programming and Language Workbanches Reggeli Keynote eloadas, azaz teljese tomeg elott prezentalnak, viszonylag altalanos dolgokat. Ennek ellenere meglepoen jo. Azon elmelkednek, hogy a programozasi nyelvek mennyire kovetik az eggyes problemakorok DSL (Domain Specific Language) leirasat. Pelda a Starbucks kavceg eloirasa volt, ahogy megmondjak hogy hogy csinalj lattet (szep angol mondat) es ennek a Java-s atfogalmazas volt, amiben persze egy csomo felesleges dolog is volt (a szintaktika miatt sok mindent ismetelni kellett, a lenyeg tekinteteben ez csak noise) Aztan beszeltek internal DSL es external nyelvekrol, az utobbi pl. az XML, mert kozelebb van a termeszetes nyelvhez, de igazabol azt majd leforditja maganak a Java.
A Ruby es mas dinamikus nyelvek eloretoreset is ha jol ertettem azzal magyaraztak, hogy a nyelv tomorebb, es termeszetesebb, az uzletemberek szamara is jol olvashat. Ami lehet, de szerintem a managereknek nem hiszem, hogy az lenne a bajuk, hogy a Java code-ot olvasni akarjak, es nem tudjak. (Lasd: specko Vision fejezet definicio: Vision az, amit a liftben el tudsz mondani a managernek.)

Stephen Colebourne: Java Closures: Kevesbe profetikus magavalragado stilus, de nagyon okosan osszeszedett. El mondja miert kell nekunk (lasd elozo temat, hogy egyszerubb kodot kapjunk, ami csak a lenyeget mondja meg). Es elemzi a closures proposalokat. Az egyiket o irta felig. Ha lessz idom leirom reszletesen a jhacksen, addig csak, hogy tudjatok kire kell szavazni:
CICE - nagyon primitiv syntax sugar proposal, az inner classokat egyszerusiti, sok mindent nem old meg. BGGA - nagy nevek adtak be (Az egyik G belole Gosling), a tobbi programnyelv alapjan alkottak meg. Ezert aztan minden franko dolgot tud, a szintakszisanak viszont semmi koze a Javahoz: rettentes (pl. az hordoz jelentest, hogy kirakod-e az utolso sorban a pontosvesszot a sor vegere). FCM - kisemberek irtak (az egyik az eloado), es engem meggyozott. Tudja azt amit a nagyoke, csak sokkal emberibb szintakszisa van, es sokkal magatol ertetodobb. A Sun allitolag egyelore kivar, megvarja a developerek mit mondanak. Szoval amig nincsen sajat tapasztalatom, addig en az FCM-re szavzok.

Erik Doernenburg: Taking Test-driven Development to the Next Level Erre eleg kivancsi voltam, hogy valami hiper test frameworkot mutat be, de nem. Kiderult ugyan is, hogy a prev. level a unit test mock objectek nelkul, a "next-level" meg mock objectumokkal (esetleg dinamikus mock keret rendszerekkel). Kicsit csalodtam. Lattunk sok kod peldat, es bebizonyosodott, hogy a decoupling jo dolog.
Tanulsag: ha nem hasznaltok mocks keretrendszert (pl. jMocks), akkor nezzetek utana mit tudnank.

Doug Clarke: Going to Extreme: kis markenting, az ebed tamogatoja, az Oracle reklamozza nekunk a termekeit. A kola melle elment, neha meg szep Eclipse+JPA demokat is lattunk.

SOA Industry Leaders Technology Panel. Ez egy kerekasztal beszelgetes, a nevekre nem emlekszem, es valtoztak is, ugy hogy nem is tudom kiirni. Amugy semmi ujjat nem tudtunk meg. JBI-rol azt mondtak, hogy persze egy megoldas Java-ban, adott esetben szukseg lehet ra, de mivel konkret esetekben kellhet, nem lesz o a fokolompos, csak egy a valasztekbol. A IONA-s ficko azt mondta, hogy az SCA es a JBI szerinte nem konkurensek, mert eltero szinteken vannak.

Ola Bini: JRuby - Ruby on the JVM. Nagyon magaval ragado eloadas, szamomora a nap egyik legjobbja. Bar eleg alapozo: Ruby alapok, miert jo a Java implementacio, a hibakra is jol felhivta a figyelmet, majd hogy milyen megoldasokat gondol ra. Nagyon gordulekeny stilus. (A ficko fanatikussagat jellemzi, hogy amikor megkerdeztek tole, hogy egy ilyen dinamikus nyelvet mennyire tamgatnak az IDE-k annyira mint a Java-t, o azt mondta, hogy hat, o Java-hoz is emacs-ot hasznal :) Na jo aztan komolyan is valaszolt (BTW az ot masik Core deeloper meg NetBeans-t)).
Nem vagyok meggyozve, hogy ez az udvozito nyelv, bar szep tomor, de en jobban szeretem a tipusasbb nyelveket. Azert mindesetre annzira meggyozo volt, hogy valamennyire meg kell neznem. Izgalmas lehet Java-ban nyelv interpretert irni.

Heinz Kabutz: Productive Coder: Onnan kezdtuk, hogy hasznaljuk billentyuzetet eger helyett, es aztan mindenfele code metrics fogalomfele huzott att. Fent tudta tartani az erdeklodest a kesei oran is. Ugyes pelda volt, hogy a semmit mondo getter javadoc-ra a Java SDK-bol hozott peldat, es megmutatta, hogy mennyire javult a helyzet a verziokban, es neha milyen buta komment van a Java forrasaban is (az idok soran sokat javult). Szoval nem volt rossz, csak valahogy az hianyzott, hogy miert nem emlitette meg a PMD-t vagyz a FindBugs-ot. Egy csomo dolog amit mondott tok igaz, de nekem az IDE-be agyazott PMD-m mar akkor ki irja, hogy az hulyeseg, amikor meg le se irtam.

ui1: amugy tobb embrre szamitottam. kb akkora az egesz, mint a magyarorszagi webkonf.

ui2: Csokoltatom a spanyolokat a billentyuzetert, meg a Guglit, aki feltetelezi, hogy ha eddig az osszes bejegyzest angol vagy magyar feluleten irom, csak azert mert az IE nyelve spanyol, azert megtanultam spanyolul.

TSSJS

Nyár van, mindenki nyaral. Újdonságok is alig, max, hogy elneveznek szép néven projekteket (pl. JAX-WS RI -> Metro), meg hasonlók. (Na jó a Java System Web Serverból kijött a stabil update, javaee5-ös servlet támogatással, ez mégis csak hír.)

Jövő héten megkezdődik két európai Java konferencia is a Jazoon és a TSS Java Symposium Europe. Jómagam a Hivatal jóvoltából az utóbin veszek részt jövő héten. Holnap reggel át is teszem a székhelyem Barcelonába, hogy szokjam a klímát. Mivel laptopom nincs (de már gyűjtöm a 100$-t), és a konferenciák elsősorban wifizett fotelekkel vannak felszerelve, nem internetkávézókkal, nem tudom mennyire tudok közben beszámolni, de utólag mindenképpen hírt adok az eseményekről.

DOM, SAX, StAX

XML-t parsolni rengeteg féle képpen lehet, a legismertebb módszerek mégis a fent említett apik. A DOM berántja az egész fájlt a merióba és viszonylag kényelmesen lehet utána kutakodni benne. A Sax egy sokkal kevésbé erőforrás igényesebb push parser: a feldolgozó megy végig az elemeken és közben a találta elemeknek megfelelő földolgozó függényeink (startElement, startDocument,...) szájába nyomja bele az adatokat. a StAX ezzel szemben remek pull parser. Szintén kevés erőforrsát eszik (nem tartja a memóriában az egész fájlt), és nem ő dirigál, hanem a programunk. Ha én azt mondom, hogy kérem a következő XML elemet, akkor megy tovább csak a parsolásban.

Hogy melyiket válasszuk, az a szokásos attól függ kérdés. Rövid segítség a döntésben pl. a java tutorialban.

Nálam a konkrét példa ez volt: viszonylag kicsi XML-ek zúdulnak rám eszméletlen sebességgel (JMS). Meg kell keresni mindegyikben két teget (kb. az első negyedben vannak) és az alapján kell megnézni, hogy akarok-e e velük kezdeni valamit. Amivel akarok, az kevesen van, azt már bárhogy feldolgozhatom.

Mivel gyorsnak kell lennni, egyértelmű hogy StAX vagy SAX. A StAX feldolgozását könnyen meg lehet szakítani (mivel én dirigálom, mikor jöjjön a feldolgozás bármikor abbahagyathatom), a SAX feldolgozásból legfeljebb exceptionnal lehet kijönni (ami azért nem egy szépségdíjas megoldás). Legyen tehát StAX. Illetve legyen mind3, és mérjem meg, hogy tényleg annyival gyorsabb-e a SAX/StAX mint a DOM, és hogy a konrét esetben a StAX/SAX sebesség mennyire vethető össze.

Nosza gyorsan összedobtam a kódokat, és rájuk eresztettem 3000 XML fájlt. Az eredmény: DOM ~ 100% sec, SAX ~ 80-90% sec, StAX 50 ~ sec. Érdekes, hogy a nagy szakadén nem a Stax/SAX vs. DOM között van, hanem a a StAX és az öszes többi között.

A történet szépsége az persze, hogy kiderült, hogy 3000 fájl feldolgozása is max 2-4 sec, és mivel adatbázisba is kell írni belőlük az adatokat, ezért valószínű tök mindegy mit használok, mert nem a parzolásnál fogok elvérezni. (Ráadásul háttér procesz, ahol 1-2 mp nem számít).

SCA vs. JBI

A JBI-t azzal szokás reklámozni, hogy bár SOA megvalósítás sok van, de milyen jó, hogy lesz nekünk egy szabványos, Java alapú. Úgy tűnik itt sincs azért kolbászból a kerítés.

A JBI 2.0 Review Ballot eredményi között (BTW csak ajánlani tudom a JCP szavazások commentjeit. Tiszta bulvár, jobb mint a Blikk) az IBM és a BEA az SCA-ra hivatkozva nemmel szavazott.

Azóta az SCA-ról próbálok guglizni, itt is egy cikk róla JDJ-ből. Kb. hasonló dologról van szó: hogyan kössünk össze komopnenseket egy SOA rendszerben, ráadásul itt különböző platformokat (Java, C++, stb.) is rögtön támogatnak. (Nem mintha WS-ekkel ezek nem lennének JBI-n keresztül összeköthetőek).

Ez a cikk (nem egy mai darab) arról beszél, hogy igazából a JBI meg az SCA nem zárják ki egymást, az egyik alacsony szintű implementációra, a másik általánosra szabvány, de én ezt még nem látom át. Mindenesetre a BEA és az IBM "No"-ja azt sugalja, mégis csak lehet némi átfedés a kettő között.

Házi feladat, kideríteni a két speckó közötti lényegi különbségeket.

Java előadások

A JBI-t továbbra is bogózgatom, mellé még érkezett kb. 800 oldal könyv is Java témában, de addig is link ajánló következik:

http://parleys.com

Igazából a BeJUG (Belgian Java Juser Groups) csinálja, és az előadásaiknak a fóliái/videói vannak fent igen használható formátumban. És mivel a BeJUG a Spring One és a JavaPolis rendezvényelben is benne van, azoknak az előadásaiba is bele nézhetünk. Jó anyagok vannak.

(Egyébként érdekes, hogy ahogy nézek más JUG formációkat, ott általában az az elv, hogy meghívnak külsős előadásokat (Sun, Oracle, stb.) és nagy előadásokat tartanak. Ehhez képest a mi megoldásunkban sok kissebb előadás van és a résztvevők adnak elő egymásnak. (Legalábbis az egy alkalommal így volt.) Érdekes az utóbbi megoldás is, hogy hívni valami Technology Evangelistet, de egyrészt szerintem egy ilyenhez még kevesen vagyunk, másrészt a fejlesztők előadásainak konkrét tapasztalatokról is olyan előnyei vannak, ami miatt szerintem mindenképp igény van rá. (Tacit knowledge-nek hívják, ahogy múltkor Kockától megtanultam))