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

JBI I.

Binding componentek és Service Componentek csücsülnek egy buszon, ahogy azt mindenki tudja (ha nem, akkor itt olvasható).

Amit még nem értek, hogy lesznek ezek példányosítva? Egy BPEL SC van, de akár több BPEL xml-t is deployolhatok, és akkor külön futnak. BC-kben, meg akár egy SMTP BC két külön konfigurációját használhatom. Szóval ez még nem tiszta, de nyomon vagyok.

Amúgy ServiceMix és OpenESB egyik se felel meg még tökéletesen nekem, de mindkettő ígéretes, és elég jó dokumentáció van mindkettő oldalán.

Ne menjen sehová, hamarosan újra jelentkezünk.

JavaOne fóliák

A PDF-ek már elérhetők. (A videókat jövő hétre ígérik.)

Sun fejlesztő konferencia

Na akkor lássuk:

Pat Pruchnickyj: A Sun Open Source stratégiája Alapvetően marketinges előadás, de nem vészes. Megtudtam pl. hogy az átlagos OS contributor 30 éves és 11 éves fejlesztői tapasztalata van. Ami tényleg izgalmas, mert ha körül nézek a projektemben, azért egy kezemen meg tudom számolni az ilyen tapasztalattal rendelkező fejlesztőket. Két dolog érdekelt volna még: az egyik (ezt lehet, hogy megkérdezem majd az előadót emailben), hogy létezik-e statisztika, hogy a megnyitott projektek hány százaléka külsős contributálás és mennyi továbbra is Sun munka. A másik a Sun bevételei. Valószínű egy nagy cég tulajdonosának kéne lenni, hogy lássam, hogy tényleg van üzleti model az OS-ben, és meg lehet élni supportból.

Nicolas Leszek: Sun partner programja fejlesztők részére: Ezt már igaz porszívó ügynök marketinges tartja. Elvileg a Sun partneri programról beszélt, de a Solarisra is nagyon rá akart beszélni. Azt hiszem ő azért volt itt, hogy ha véletlenül nem csak fejlesztők jöttek volna el a fejlesztői konferenciára, hanem vállalati vezetők is, akkor őket jól megekézze.

Vértes Miklós: Újdonságok a Java világából Ennek az előadásnak az egyetlen előnye az volt, hogy olyannyira gyenge volt, hogy az már szórakoztató. Az előadó elvileg a JavaOne-on bejelentett újdonságokról beszélt volna, szar viccek közepette, de még én is jobban képben voltam a JavaOne-on történtekről, pedig ott se voltam. Meg tudtam, hogy a JRuby azért jó, mert "raileken is fut" továbbá, hogy a JMaki és a Phobos "azt teszi, amire ki lett találva". ROTFL.

Alexis Moussine-Pouchkine: GlassFish, a Sun nyílt forráskódú alkalmazás szervere Ez egy ügyes összefoglaló GlassFish-ről, jól váltakoztatva a rövid gyakorlati bemutatókat a fóliákkal. Jól koncert a figyelemfelkeltő dolgokra (clusterezés, PHP futtatás Quercuson keresztül, HK2). Persze ezeket már nagyrészt kipróbáltam, sőt a hk2 forráskódjához is volt már szerencsém, de azért izgalmas.

Roman Strobl: NetBeans: nyílt forráskódú fejlesztőkörnyezet és ennél is több Az ő blogjának rendszeres olvasója vagyok, de előadni még nem láttam. Nagyon vidám fickó, és nagyon profi előadó (nem hiába evangelist). Két előadáson keresztül mutatta be a NetBeans 6.0 újdonságait, gyakorlati példákkal. Profi munka.

Simon Géza: Open ESB projekt A (saját magam által) vártnál sokkal tömörebb elméleti összefoglalót kaptunk, ESB, JBI, SOA szinten, ami nagyon jó volt. A demó gyakorlatilag abból állt, hogy megnyitottunk egy kész JBI-s alkalmazást és lefutattuk a tesztet. Én néztem volna részleteket is, mert éppen én is ezzel kísérletezek. Ami számomra új volt, hogy állítólag az OpenESB 2 már futni fog standalone is, és hogy a hármasra fog integrálódni a felvásárolt JCAPS-ból jövő mindenféle jó bele.

Zsemlye Tamás: Open SSO projekt Utolsó előadás, főleg elmlélet és termékismertető. Az OpenSSO-val már sokszor szemeztem, de az hiányzik hogy lássak egy ilyet élőben műköni. Sajnos Hello World itt sem volt, viszont nagyon meglepődtem, hogy mennyire pluginelhető kiterjeszthető az egész. Sokkal monolitikusabbnak látszott messziről. Még is csak meg kéne néztem.

A Glassfish előadásközben jutott eszembe a hasonlat, hogy egy kicsit olyan ez, mint a blogok és a nyomtatott média viszonya. Mivel naponta olvasva a híreket a neten, a hétvégi hetilapban lévő kis színes hírek már egy kicsit réginek tűnnek. Itt is azt volt, hogy a NetBeans és Glassfish demók és jóságok egy részét már rég olvastam a megfelelő forrásokból és láttam screencaston (sőt további jókat Jackpot, Schliemann). És mint a nyomtatott újságokat olvasva itt se az újdonság az amit ad az újság nekem (az már megvolt nekem RSS feedből), hanem az alaposság, ami révén olyan partikuláris dolgokat is megtudok, ami eddig elkerülte a figyelmemet, és amit miatt érdemes elolvasni az újság cikket. Ezért a néhány új dologért, no meg azért a 3 tényleg jó előadásért érdemes volt ott lenni.

OpenESB I.

Holnap Sun Tech Day Budapesten. Nosza gyorsan megint nekiálltam kísérletezni az OpenESB-vel, mert most majd lehet az illetékesektől kérdezni róla.

Tutorialokat már néha csináltam vele, de semmi komolyat. Most is valami egyszerűvel kezdtem, de sehogyan sem akart működni. A hibajelenség pont az volt, amit itt leírt valaki, csak én ellenőriztem, hogy a komponenesek meg vannak-e, meg a logot is felnyomtam finest-re, de semmi. Érdekes módon két különböző gépen is ugyanezt kaptam, és már nem is csak a saját programommal, hanem a a Sample-k közöl a SynchronousSampleApplication is ezt csinálta.

Nem baj, biztos valamit elkonfiguráltam az appszerverben valami múltkori játék folyamán, ezért letöltöttem újra és feltettem a teljesen friss NetBeans 5.5 + Glassfish párost. Újra megpróbálom a példát: most már megy szépen, de a Runtime > Servers fül alatt a JBI fában semmilyen komponens nem látható. (Valószínűleg az zavarta meg, hogy már volt fent egy Glassfish a gépen, és az újat is ugyanazon a "Sun Java System Application Server 9" néven rakta fel a Runtime > Servers alá. Igaz a régit kitöröltem utóbb, és nem javult).

Nosza bedühödtem és letöltöttema Java Application Platform SDK Update 3 Preview 2 hangzatos névre keresztelt cuccot. (Netbeans 6 M9 + OpenESB 2 + Glassfish 2). Felraktam, és láss csodát minden tökéletesen ment. Sőt még az SMTP binding komponenes is pöccre működött.

Tanulság: sose használjatok szar stabil dolgokat, ha kijött már valamilyen preview/beta.

JSF 2.0 Mit vennél bele?

Még a JavaOne-os hírek között volt, csak eddig nem sikerült írni róla. Tartottak egy rövid KickOff meetinget szerűséget a JSF 2.0 speckórol. Ed Burn rögzítette a 15 leggyakrabban hiányolt feature-t és mindegyikhez hozzárendelt egy becsült erőforrás összeget. A résztvevők alapján vásároltak egy fix keretösszegből, hogy nekik milyen feature kéne leginkább.

Sajnos nem tudom, hogy mennyi volt a keret összeg, de az én bevásárló listám valahogy így nézne ki:

• Mostly Get (80)
• Facelets (165)
• Skinks (60)
• Errors (80)

Csupán 385$, igazán szerény lista. További részletek itt.

Egyébiránt A JCP-t leginkább azért szokták kritizálni, hogy nem elég nyílt és átlátható. Ezt egyelőre minden projekt a maga módján és egyéni eszközökkel próbálja megoldani (Ahelyett, hogy a JCP.org végre elmenne egy kicsit communitysebb irányba) A JSF 2.0 specifikáció nyílt projektje itt található, de pl. a JSR-277-hez is bejelentettek egy nyílt, readonly levlistát a minap.

EP function

Lehet, hogy mindenki ismeri, de nekem új volt: a kérdés az, hogy hogy lehet EL-ben függvényt használni. És láss csodát, simán:

<c:when test="${f:isValid(param1,param2)}" >

Azért ez szépen néz ki. Persze a prefix az egy tld, amiben function teggel definiálható az isValid függvény. De inkább nézzétek meg a tutorialt, az teljesen egyértelmű. (scroll a végére).

Ti tényleg ismertétek?

NetBeans profiler

Azt még nem is írtam, hogy múltkor kb. egy napot ellötyögtem vele. Egy ANT alapú (freeform) külső tomcet-et használó NetBeans projecthez kellett belőnöm. Mielőtt neki kezdtem valaki fenyegetett is, hogy ő már próbálta és szétfagyott az egész.

Ehhez képest egész kellemesen csalódtam. Nagyon hamar működött, és tényleg kezelte az ANT alapú projektemet is.

Kissebb problémák voltak:

• Az IDE-ből indítva a tomcat-et profile módban úgy tűnt, mintha nem kapná meg a környezeti változók értékeit (ami pl. orakli eléréshez kell). Szerencsére volt lehetőség manual attach-ot is játszani, és azzal végül ment, csak command lineból kellett indítgatni az IDE-t.
• 1.4-est nem szereti nagyon (igaza van, én se szeretem), módosított JVM kell hozzá. Ez letölthet NB plugin formájában, csak a dependency rosszul van a pluginben definiálva, és ezért a legújabb profilerrel nem megy (persze nem volt túl nagy feladat a jarban megtalálni a descriptor-t és átírni a dependecyt, és utána már megy is.).

Ezt leszámítva tényleg szép színes szagos, és egész jól használható volt. Rögtön találtam is néhány furcsa dolgot (reflection api szokásos lassúsága) a projektben, ami miatt már megérte.

Rögvalóság

Két könyvre lenne szükségem, ami egyrészt jó lenne papíros formájában, a márészt meg elhatároztam, hogy becsületes leszek, és megvenném őket pénzért.

Az egyik a NetBeans RCP-ről most megjelent könyv, és a legjobb könyvnek tűnik a témában (konkrét RCP-re kihegyezett más ilyen könyvről nem is tudok). Valamint már a 6.0-t is figyelembe veszi, ami ősz előtt biztos nem jön ki, úgy hogy valamennyire biztos aktuális marad.

A másik egy régi alapmű, szerintem egy jó része már túlhaladott, de szintén egyetlen, amit ajánlanak SCDJWS témakörben.

Namármost mint mondtam papíroson kéne az egész, úgy hogy irány az amazon. Az amazonon 83$ ért hozná át nekem a tengeren. Ami némileg drága a hazak könyvárakhoz képest, dehát a tudásba be kell fektetni. A probléma csak az, hogy van esély rá, hogy itthon még ezt meg is vámolják és hozzá csapják az áfát, ami már jól megdobja.

Persze még mindig jobb, mint az amazon.de, ami csekély 100 euróért akarná kihozni (persze arra nem jön vám), ami már egy olyan combos 25 rugó környékén van

(A kiskapu-t is megkérdeztem, ők 28700-ért hoznák meg nekem a cuccost).

Persze, persze, tudom, hogy milyen a törpök élete, meg hogy ez kelet európa, de akkor is. Elkeserítő. És akkor még a magyar postán uralkodó állapotokról nem is beszéltem.

JUM 1.

Akkor lássuk:

Zsiga Péter: Java és SAP integráció Jco segítségével SAP elérése Javaban. Konkrét eset, de valahogy nem dobott fel. Nincs dolgom SAP-pal. Nincs is lehetőségem rá, ezért nem volt sok tétje számomra.

Hornyák László, én: Maven2 vs. Ant + Ivy Ezek mi voltunk. Kocka a Maven2 dependency maganementjéről szólt, tényleg csak röviden vázolva a lényegét (ő némileg kritikus magával szemben, én, aki használok néha Maven2-t azért elég jól értettem). Az én előadásomat kicsit kapkodósnak éreztem, talán kevesebről kellett volna beszélnem, és jobban elmagyarázni, hogy mi a tét. El is felejtettem ezt-azt mondani (JSR-277 kapcsolatok, Xavier Hanin az alkotó, stb.) Majd megnézem magam videón, és akkor még próbálok tanulni belőle.

Auth Gábor: ZK AJAX keretrendszer, AJAX JavaScript tudás nélkül. Számomra is a legkellemesebb meglepetés, tényleg jó előadás. Jól felkészült, és az előre legyártott screencasttal együtt jó ütembe tudta mondani az előadást, ami jó megoldás volt (pedig ugye én utálom a csilli villi bemutatásokat :-). Másrészt azért volt még nagyon szimpatikus, mert nem arról szólt, hogy a ZK milyen überdolog, és mindenki azt használja, hanem arról, hogy próbálkozott vele egy csomót (izzadtság), és talált egy csomó előnyt meg egy hátrányt. Kérdezte is valaki a végén, hogy akkor mire jó az egész, ha ennyi hibáját felsorolta? Pont ez volt a lényeg, hogy pontosabban megismertük a ZK-t és a korlátait is. A lehetőségeket sokszor el tudom olvasni a termék leírásában is, de hogy hol vannak a gyenge pontok, ahhoz tapasztalat kell.

Karóczkai Krisztián: Portlet konténerek AJAX csapdája Elég hosszúra nyúlt előadás. Én magam nem vagyok portlet hívő, ezért megint kevésbé hatott meg. Két dolgot tudtam meg. Hogy portlet konténerekkel általában nehéz Ajaxot használni (ez nem lepett meg), és hogy "egy erős hétvége" alatt meg lehet írni egy portlet konténert. Ez viszont nagyon meglepett, és nagyon izgalmas információ volt. Talán érdekeltek is volna ennek az implementálásnak a részletei, tapasztalati.

Czimmermann Gábor: Milyen hosszú az út az EJB2.0 és az EJB3.0 között? Vagy a késői időpont miatt, vagy mert az utolsó pillanatban készült az előadás, kevésbé volt pörgős. Meg persze én majdnem az egész speckót elolvastam a vizsga miatt, meg JPA-t is használok, úgy hogy kevéssé rázott meg. Az jó volt, hogy a JBoss-ról nagyon konkrét tapasztalatokat osztott meg (Elég döcögős az EJB3 támogatása, konkrét probléma injektálások), és ez indukált némi diskurzust is személyes tapasztaltokról.

Ami a szervezést illeti: Nagyon elhúzódott, akik siettek, azok el is mentek a szünetben. Szerintem kéne egy hoppmester alkalmanként, aki felvezeti a programot, és figyel az időre és figyelmeztet, ezáltal mindenképpen feszesebbre lehetne húzni. 4 előadás talán még szünet nélkül is lemenne, talán elég lenne annyi.

Persze itt két szemlélet van. Előttem egy meetup jellegű dolog (gyors esti program) lebeg, de Gábor pl. aki Pécsről jött fel csak ezért, (érthetően) nagyobb kaliberű dolgokban gondolkozik (már ahogy én látom).

Összességében (elfogult értékelés következik) nagyon ígéretes kezdetnek látom, és bár voltak olyan pillanatok, amik kevésbé kötöttek le, mindenképpen tanultam belőle.

Java One & JUM

Van ebben valami szépség. Miközben mindenki a nagy Java One-re készül, a Sun-osok gyorsan mindenből kiadnak egy milestone-t, és a aki számítónak érzi magát már mind elment San Franciscoba (regisztráció kb fél millától), szóval közben mi itt a magyar ugaron készülünk a hazai java-s előadásainkra. Kicsit kevesebb csillogás, kicsit kevesebb napfény, kicsit kevesebb résztvevő, de... (és ezt majd holnap este folytatom.)

De hogy valami hasznos nélkül ne zárjuk le ezt a bejegyzést se, ajánlom mindenkinek Xavier Hanin blogját. Ő az alkotója az Ivy-nek ennek folyamán van benne a JSR-277 (Java7-ben bemutatkozó modularity rendszer) EG-ben is, amiről néhány egész jó infó olvasható nála (bár egyébként elég ritkán frissít.)

Inglis

Előre bocsátom, hogy nagyon is tudatában vagyok, hogy mennyire ráférne az angolomra a fejlesztés. Habár angolul olvasok szakkönyveket és irodalmi könyveket egyaránt, és a Hivatalban is a mítingek (meg szinte minden) angolul folyik, angolul ugyanolyan szedett-vedett nyelvtannal fogalmazok néha, mint sokszor magyarul.

Hanem nézem az oldal statisztikáit, és látom, hogy sokan jönnek a gugliból egy konkrét kérdéssel, és valószínűleg elég lehervadnak, ha látják, hogy itt valaki magyaráz SSL-ről és Xfire-ről, de egyáltalán nem lehet érteni. Ilyenkor arra gondolok, hogy az lenne az illendő, hogy legalább a howto jellegű bejegyzéseket angolul kéne írnom, akár szar nyelvtannal is, ha eljutok valahová sok munkaóra árán, akkor legalább osszam meg az eredményt.

Hát nem tudom, talán nagyképűség. Régen is gondolkoztam ezen, és még nem jutottam semmi jó megoldásra, mert azért mégis csak a magyar nyelven érzem magam otthon, meg ebben a környezetben. Most mindenesetre lehet, hogy a JUM-ra készülő fóliáimat angolul fogom megírni. Úgy is magyarul fogunk beszélni, és legalább kevésbé lesz zavaró, ha néha ugyanazt magyarázom ami a fólián van. :-)

JVM bug

Néhány koléga mesélte múltkor, hogy az új cégükben van egy nagy régi legacy rendszer, aféle szent tehén. Kicsit rozsdás, kicsit döcög, de működik. Általában. Néha azonban elszáll, olyankor neki állnak hibát keresni. Mondják is a régieknek, hogy bugos a szent tehén. Nem, olyan nincs. Biztos a használt API a bugos. Megnézték, az jól működött. Akkor a JVM bugos. (Na persze, gondolták, majd pont az.) Azért elcsesztek vele egy napot, hogy bebizonyítsák, hogy a szent tehén betegeskedik és nem más. Persze ez többszőr is egymás után, és mindig ezzel az első reakcióval, hogy bugos a JVM.

Ez csak azért jutott eszembe, mert a minap előszőr találkoztam olyannal, hogy kaptam egy bug reportot, és végül kiderült, hogy nem én csesztem el valamit, hanem a JVM a hibás, és majd talán ki lesz javítva, addig meg van rá workaround, szépen leírva a bug adatbázisban, ami persze meg is oldotta a problémát.

No lám, ilyen is volt.