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.

The Budapest New Technology Meetup

Tegnap előszőr voltam egy ilyen redezvényen. Tapasztalatok:

Az első előadás (Scrum a honlapon nem találom az előadót) tanúlsága az volt, hogy mennyire fel kell készülni egy 5 perces előadásra, és mennyire nehéz valamit összesedetten elmondani 5 percben.

Kelényi Attila (Kiskapu kiado) - Creative Commons - néhány jog fenntartva
Nekem nem mondott sok újat, de én azért ismertem is a témát. Már ebben a prezentációban feltűnt, hogy mennyire terjed az a stílus, amit én előszőr Dick Hardt-tól láttam a prezentáció készítésben (folyamatos beszéd, de a fólián nem vázlat pontok, hanem néha csak egy-egy hívószó). Az előadás kevésbé bolt gördülékeny, de jó volt.

Burgermeister Zsolt - Varga Koppány: Fordítássegítő alkalmazás.
Alapvetően egy új startup ötlete volt elmondva nagy vonalakban. A bevezető szavakkal már eltelt a fél idő. Nem rázott meg. Kívánom, hogy jöjjön be nekik, és térjünk vissza rá.

Vámosi Zsolt (3DBrigade) - 3D grafikai tartalom fejlesztes Next Generacios videojatek platformokon
Pöpec előadás 5 percre hegyezve, bár nem sokat tudtam meg belőle technikából, csak hogy komoly cég nyomja ezt itt Magyarországon. Érdekes képek, jó előadás.

Szalai Ferenc (NIIF) - Indentity 2.0 - a vágy titokzatos tárgya
Szóval én ismeret Dick Hardt alapművét, ahhoz képest nehéz újat alkotni. Kicsit el volt mismásolva a SAML vs. Open ID kérdés (ami persze nem is kifejezetten Identity 2.0-s elméleti téma, inkább már technika). (Az én véleményem kommentben itt).

Neltz Tamás (index.hu) - OpenID
Sok technikai részletet nem tudtam meg, de persze ezt már én ismertem. Az is vicces volt, hogy az előző előadás azt mondta, hogy azért OpenID és nem SAML, mert ez utóbbi nem támogatja jól a propertyk hordozását, bezzeg az OpenID. Ehhez képest ez az előadő azzal kezdte, hogy az OpenID is csak autorizációra való, nem property cserére. Különben jó volt. A privacy-t firtató kérdés is jól elgondolkoztatott. A whitelist/bacllist-re meg nem kaptam megnyugtató választ. (Mi lesz a SPAM-elő IdP-kkel).

Szóval tanulságos volt. Tanultam néhány dolgot, pl. hogy a Java User Meetings-nél is jó lesz az időt jelezni az előadónak, hogy ne fussunk ki az időből, meg határt szabni a kérdéseknek. Meg, hogy jó, hogy egy ilyen technológiailag elkötelezettebb témában nem 5, hanem 15 perc van, mert azért itt kelleni fog valamennyi idő felvezetni a méllyebb rétegeket

ANT, Maven, ilyesmi

Ami egy kicsit is megközelíti a Maven2 képességeit, is ANT-ra épül az az IVY. Jelenleg az Apache inkubátorában pihen, és egy remek jó dependency tool. Mivel ANT-ra épül nagyon jól be lehet passzintani mindenhová (pl. Netbeans, ami kezd jó ANT-ra épülni), ahová Maven2 plugin nincs is. Az API-ja is ígéretesnek tűnik, ki lehet cserélni jól a dependecy kezeléstől a latest verzió algoritmusig elég sok mindent. Ráadásul félig meddig kompatibilis a Maven-nel (pl. tudja olvasni az ibiblio-t).

Csakhogy ez idáig egy dependency management rendszer, és semmi több. A Maven2-t azért szeretik az emberek (vagy: ha szeretik, azért :) mert a definiált konvenciókkal sokkal egyszerűbb minden (erre múltkor volt egy frappáns angol kifejezés), azaz, ha mindig ugyanúgy buildelek, akkor érdemes ezt a részt csak egyszer megírni, és nem mindig implementálni ANT-ban.

Eddig oké. Természetesen ezt meg lehet csinálni IvY+ANT párossal is. Az ANT-nak elég jó API-ja van, az IVY szállítja a csomag és függőség kezelést. Csak azt kell elérni, hogy a letöltött csomagokban lévő osztályok integrálódjanak az ANT-ban (ezt nem lehetetlen), és azok rögtön beleszóljanak az api-ba. Így elérhetjük előszőr is, hogy a szokásos ANT taskok (pl. compile, jar, stb.) sehol se várjanak alapértelmezett paramétert, hanem mondjuk ahelyett valami magic propertyt használjanak. (Szimplán leszármaztatjuk az ANT taskokat), a magic propertyket meg előrde definiáljuk, ez lesz a konvenvió.

Sőt, azt is el lehet intézni, hogy alapértelmezett targetek legyenek (pl. compile, run, deploy), amik az ANT fájlban ugyan nincsenek benne, de meg lehet őket hívni a scriptből. (Feltéve, hogyha a csoda ivy+ant dolgunk a classpathban van). Meg mondjuk azt is megengedjük, hogy az alapértelmezett compile parancsot is felüldeifinálja a user, ha ő mindig más compile-t szeretne.

Ez szép, de akkor mi a kérdés? Hát az, hogy ilyen rendszer nincs. Jelenleg ugyanis Maven2 van, és mindenki (akinek van egy kis esze) azt használja. Amit felvázoltam arra lehetne egy Proof-of-Conceptet írni, de jelenleg nincs ilyen. Márpedig egy nemlétező program architektúrájáról előadást tartani meglehetősen öncélú dolog. Vagy fogom magam, és megírom az egészet, és tényleg komolyan veszem, és fegyverkezési versenybe kezdek a Maven2-vel (sok munkaórát beleölök), vagy hagyom az egészet. Ebben az esetben viszont elég felesleges előadást tartani egy olyan konkrét termékről (a konkrét termékről szól előadások már gyanúsak), ami nem is létezik, csak létezhetne, tehát a hallgatóság részéről gyakorlati haszna semmi nincs. (Kivéve egyetlen trükköt, hogy hogyan lehet automatikusan azzal definiálni ANT taskot, hogy egy jar-t bedobunk a classpath-ába). Sokkal inkább értelme van, egy létező dolog bemutatására konkrét tapasztalatokkal (vér, veríték).

Hát ezért bizonytalanodtam el, hogy érdemes-e megtartani a Maven2-es JUM előadás ANT-os párját. Mert ha az szólna valamiről nem az ANT-ról szólna, mert az egyértelműen nem ellenfele a Maven2-nek (Ezt egyébként a Maven oldal is igyekszik tisztázni, hogy ez nem csak egy másik build tool, hanem valami több annál). És amiről szólna, olyat meg úgy se fog használni senki.

Szerintetek?

JSF sources

Nem ecsetelem, hogy hogy jutottam ide, de jelenleg épp az egyik ablakban az Apache MyFaces forráskódja a másikban a JSF 1.2 Sun-os Reference Implementation forráskódja van. És ezeket böngészem csak úgy saját gyönyörűségre. Tanulságos. Lenyűgöző.

Ugyanarra a speckóra két elég eltérő implementáció, úgy hogy a specifikált részben a Java osztályok felépítése tök ugyanolyan, mégis teljesen különböző filozófiák, a működés meg persze ugyanaz (elvileg)

Megannyi sajátos megoldás. Például, hogy TLD fájlban definiálhatunk Listener-t is nem csak tag-eket. (MyFaces hibakezelése szerint lehet web container, ami nem tud róla) Vagy hogy a RI a WEB-INF/... os kérésekre nem forbiddent (403) hanem 404-et ad vissza. (A MyFaces kommentben csodálkozik, de követnie kell a RI-t, az a referencia). Vagy hogy a RI-ben ilyen frappáns metódus nevek is előfordulnak: verifyFactoriesAndInitDefaultRenderKit. 38 karakter ha jól számolom. Maga a gyönyörűség.

Szóval igen szórakoztató olvasmány, és talán a JSF megértéséhez is közelebb kerülök vele.

Olvassatok forráskódokat ti is, a legjobb olvasmány.

JAX-WS deploy

JAX-WS ugye meg van minenkinek? JAX-RPC utódja, és web service-eket lehet benne varázsolni könnyedén (POJO + Annitationok, ahogy ezt már mások is csinálták, csak most szabvány.) Éppen a 2.1-es van kijövőben.

Meg is írom benne szépen a service-t és deployolnám be, amikor kezdődnek a problémák. Glassfish szépen meg is eszi, de a Sun Java System Web Server (leírni is gyönyörűség ilyen frappáns rövid nevet :) nem. Hamar kiderül, hogy azért nem, mert a JSR-109-et, ami azt biztosítaná, hogy mindenféle plus deployment descriptorozás nélkül hipp-hopp működjön a WS, nem támogatja a Web Server. Persze trükközni lehet. Ez a kedves tutorial például (még a régi Web Serverhez tehát 2.4-es servlet konténert használ) elmondja, hogy milyen com.sun-os osztályokat kell servletként regisztrálni a web.xml-ben, hogy menjen a JAX-WS. Persze, a referencia implementációval. De ennyi erővel ne csináljunk szabványt, csak implementációt és dokumentációt.

A JAX-WS FAQ ezt így fogalmazza meg:
Q. Is the stand alone JAX-WS-based service developed and deployed on Servlet container is portable on all Java EE 5 based platforms ?

No.

Ennyi. Ott tartunk tehát, hogy JAVA 6 SE-ben lehet szabáványos hordozható WS szervert/klienset csinálni. JAVA EE 5-ben (ami tartalmazza a JSR-109-et) lehet szabványos hordozható WS-eket csinálni. Csak épp servlet containerek környékén (ami azért ezen a területen mégis csak a legvalószínübb) nincs rá hordozható megoldás.

Java contests

Nem magyarázom, nekem alapvetően bejönnek ezek. Ha több időm lenne valamelyiken biztos indulnék most is.

Ez a JavaOne-nal fog indulni. Valami jMakijMonkey enginnel kapcsolatban. Felírva az utánanézendők listájára. Érdektelen, csak JavaOne résztvevőknek. Benéztem.

Ez a Jazoon-hoz kapcsolódik, sciriptelés, és csak dikákoknak.

Itt meg az Atlassain kereskedelmi termékeihez lehet plugint írni, és licenszeket és TSS belépőket nyerni.

Hajrá.

Napfényes hétvégék emléke

(Énblog)

Telefonbeszélgetés után emailben kaptam néhány anyagot, ami távolról talán specifikációnak látszott. Meg volt köztük egy konferencia abstract is rengeteg bullshit-tel, meg egy megjegyzéssel, hogy igen, van működő prottípus szoftverük az algoritmushoz, és mennyire jó.

A beszélgetés us lefolyt, ekkor már nem egy hét, de 5 nap is alig volt a konrefenciára való indulásig, és kiderült, hogy az a szoftver, amit még senki sem látott, és nagyon gyorsan kéne. És aztán jött a rapid programozás. Nem mondom, hogy erre a kódra leszek a legbüszkébb, bár azért azt látom, hogy összehasonlíthatatlanul jobb ez a rapid kód is, mint mondjuk a néhány évvel ezelőtti. Hiába, csak tapasztal az ember, és egy Observer minta tényleg már csak izommunka. No meg a Hivatalban is megszoktam már, hogy mindent szépen dokumentálva és codestylolva, itt meg csak egyetlen szempont volt. Gyorsan egy működő demót.

Volt egy olyan rész, amit megírtak nekem előre C-ben, hogy az algoritmuson ne kelljen tökölődni. Copy-paste és kis kozmetika után ment is, majd néhány teszt után több helyen is elszállt. Kiderült, hogy a C-s ugyan működött, de kapásból két puffer túlcsordulás volt benne (nem túl lényeges helyeken), amire persze a Java rögtön dobta az IndexOutOfBondokat.

(Közbe regisztráltam a dev.java.net-re valami JUG szerű oldalt, remélem lassan approvolják is. Azzal is haladni kéne.)

Konferencia turizmus

Jön a a tavasz, majd a nyár is, végleg beindul a javás konferencia szezon. Jó lenne, ha valahová kiküldene a Hivatal. De mit is választanék - ha sikerülne rábeszélni őket - Európán belül. Első körben két potenciális jelölt van:

JAZOON Zürich, Június 24-28. 5 nap (igazából 3,5-4,5 Az első nap only tutorials, szerda csak délelőtt vannak előadások, du. városnézés).

Részvételi díj: (teljes/korai regisztráció 1245/995 (Student 460/370 vs. JUG tag 830/665) euró

Múlt: eltelt egy kis idő míg kiderült számomra, hogy ez az első konferenciájuk.

Tematika: minden Java, konferencia+kiállítás

Előadások: Összesssen 59 abstract, komplexebb kategóriákba sorolva (körülbelül ilyen megosztás: server side, desktop side, mobile és mindeféle más). A Spring jelenlét kicsi alul van reprezentálva, RCP általában Eclipse RCP-t jelen, és AOP, OSGi témakörökbenn is szívesen hallgatnék többet. Persze SOA manapság már kikerülhetetlen, itt is van, de nem annyira hangsúlyos (Igaz, ez nem server side konf). Sok olyan téma van, ami konkrét terméket és nem tehcnológiát jár körül. De azért van néhány érdekes téma, amire beülnék (pl. JAX-RS, Lucene)

THE SERVER SIDE SYMPOZIUM EUROPE Barcelona, Június 27-29. (3 nap)

Részvételi díj: 1516/1436 euró

Múlt: archívum nem, de 2006-os sajtóviszhang be van linkelve. Igazából ez az európai változat, a már lezajlott amerikai után.

Tematika: ServerSide, Konferencia

Előadások: Összessen: 36 abstract, van fent a honlapon, 4 kategóriában, ebből 16 az ARCHITECTURE sessions-ra esik, számomra igazából ez lenne érdekes, viszonylag erős is (pl. OSGi, AOP, ESB témakörök). A többi kategória nem túl említésre méltó. Néhány case study, semmi izgalom.

Összességében azt látom, hogy a konferenciák célközönsége nem elsősorban az a hard core hegesztőmunkás, aki én vagyok, talán inkább magasabb szinteket célozzák meg. Bér a Jazoon minden szinten nagyon nyomult (Student ticket) A TSSSE-nek a programja rövidebb, de erősebbnek tűnik, a Jazoon viszont sokkal agilisebb, nagyon kapaszkodik: ez az első alkalom, kedvezmények vannak, szervezői blog, próbálják bevonni a bloggereket, stb.

Egyszer valaki azt mondta nekem a JavaOne-ról, hogy minden képpen érdemes kimenni oda, ha a cégünk ki tud küldeni minket. Bár nagyon sok újat nem fogunk hallani (azt pedig a Java One esetében utólag meghallgatjuk a honlapon (profi megvalósítás, riszpekt)), de a Java iránti életérzés megtapasztalásához mindenképpen jó eljutni egyszer egy ilyen konferenciára.

Java Klub II.

Összefoglalás:

A kommentek alapján kitapintaható érdeklődést véltem felfedezni a dolog iránt. A következő lépés, hogy elmegyünk Húsvétra sonkát enni.

Aztán visszajövünnk, kiírunk 2-3 potenciális időpontot szavazásra (ötletek jöhetnek kommentbe). Összerakunk valami ingyenes helyen egy rövid oldalt (valami wiki-nek kéne lennie, már elkezdtem nézni), hogy mégse egy blogbejegyzésből kelljen informálódni.

A wiki oldalra ha valakinek jó témája van, azt oda be tudná írni. És el lehetne kezdeni gyűjteni az előadásokat. Kéne egy komolyabb becslés, hogy hány ember jönne el, és keresni kellene helyszínt.

Hát ilyenek jutnak eszembe. Bármilyen segítség, ötlet, megjegyzés jöhet kommentbe.

Klub

Mindenek előtt szeretnék két dolgot leszögezni.

Előszőr is ki nem állhatom az IRL találkozásokat, ha az egy netes ismeretség után következik. Mindennek megvan a maga helye. Ne keverjük.

És legalább ugyanennyire gyanús nekem mindenféle "macskatappancs testvériség". (Vonnegut). Ki fejezetten utálom azokat a társoságokat, amiket csak azért csinálnak mert összetartozunk. Nem tartozunk össze.

Amit viszont szeretnék:

Szeretnék egy olyan dolgot, ahol lehetne Java-ról beszélni, eszmét cserélni, előadást hallgatni, tanulni. Ami csak ezért lenne, erről szólna.

Hogy hogy képzelem el?

Leginkább valami klubnak. Aki részt akar venni, az csinál egy előadást. 
Nem hosszút, 15-20 perc plusz kérdések. Komolyabb mint egy blogbejegyzés, de kevesebb mint  egy konferencia előadás. 
Valami Javas témáról. Lehetőleg legyen minnél advancedebb (ne ott kezdjük, 
hogy mi a JSP vagy az EL) és ne szóljon olyanról, amit az ember egy az egyben elolvas a netről. Izzadságról szóljon, és tapasztalatról. (Ma tanultam erre egy szót: Tacit Knowledge).

Persze nem kell az adott témában teljesen pengének lenni, de ha van izzadság, akkor azért valamilyen szinten már válaszolni tudhat a felmerülő kérdésekre. Legyenek kérdések. És legyen kritika. Szerintem ebben az expozéban ez és ez volt jó, ez és ez volt rossz. Engem ez és ez érdekelne a témával kapcsolatban. Találkoztál a válasszal? Nem? Utánanézünk.

Az előadásokhoz kötelezően kéne tartoznia egy fóliának, és egy prototype alkalmazásnak ( javaalmanach szerű egyszerűségre törekedve), amit aztán szépen tolnánk fel a netre, és neten folytatni lehetne a diszkussziót a legutóbbi előadásról.

Azt hiszem kis hazánkban elég kevés a speciális Java konferencia vagy Workshop, ami hasonlót nyújtana. Múltkor néztem egy külföldit, és a regisztrációnál láttam, hogy JUG tagnak kedvezmény. Akkor kezdtem el nézegetni, hogy mi is egy JUG, és láttam, hogy azért léteznek máshol is hasonló dolgok, úgy hogy talán működhet is a dolog.

Ma reggel olvastam, hogy másoknak is vannak, ha nem is pont ilyen, de hasonló gondolataik. Lelkes lettem, ezért most e bejegyzés. Ha tényleg, néhány emberrel már bele lehetne vágni.

Mit gondoltok? Eljönnétek? Hallgatni? Előadni? Beszélgetni?

Web Konferencia 2007

((A twitter jól működött (technikailag) talán egyszer majd használom valami értelmesebbre is. Bár végig mobillal kellett vezérelni, mert wifi nem volt.))

Szóval egy rövid összefoglaló. 5 előadást láttam:

Simon Géza: Java Business Integration, azaz szolgáltatásalapú architektúra Java EE környezetben Jó összefoglalással kezdte a SOA-tól, hogy miért van erre szükség, és hogy miért pont web servicekkel oldja meg a JBI. Részletekbe nem mentünk bele, és személy szerint nekem sokkal inkább egy workshop hiányozna. De nem aludtam rajta. Tanultam két jó szakszót.

Szeredi Péter: A szemantikus világháló alapjai Ezzel a szemantikus világhálóval csak egy bajom van. Még nem lettam működő üzleti alkalmazást, amiben használták volna jól az ontológiákat, enélkül meg kicsit tét nélküli a dolog. Gondoltam legalább a kérdések között hallhatok ilyesmiről, de sajnos a kérdések helyét elnyomta a szétszéledés hangzavara. Maga az előadás kicsit egyetem jellegű, korrekt, de számomra kicsit lassú és unalmas volt. Nem tanulni akartam, hanem megismerni.

Molnár István: Java Persistence API, azaz szabványos Obejtum-Relációs mapping Java és Java EE környezetben Nagyon sok újra nem számítottam, nemrég az egész speckót el kellett olvasnom (SCBCD rulez). Azt gondoltam, hogy néhány alapozó mondat után, az alap OR mapping lehetőségeket mutatja be, hogy felkeltse az érdeklődést. Ehelyett egy számomra nagyon dinamikus és lehengerlő előadást hallottam, szinta ez összes lehetőséget (optimista lokkolás, öröklődés kezelése az adatbázisban, stb.) felvillantva. Emlékszem előtte egy kávét akartam inni, de utána már egész felvillanyozódtam.

Varga Péter: Webalkalmazás fejlesztés Java EE környezetben NetBeans segítségével: JSP 2.1, JavaServer Faces 1.2, AJAX Nagyelőadó, széles vászon. Az elején rögtönzött közvéleménykutatás, hogy ki mennyire ismeri a technológiákat: Java, Servlet, JSP, JSF. Kiderült, hogy eléggé az elejénél kell kezdeni, úgy hogy nagyon részletes JSF bemutatásra nem is kerülhetett sor. Persze elhangzott, hogy mire jó az egész, meg hogy hogy épül fel, de sok újat számomra nem mondott. Viszont VRG laza stílusban sziporkázott, úgyhogy végig élveztem az előadást.

Tóth Ádám: COMET webalkalmazás fejlesztés A végén úgy jöttem ki, hogy érdemes volt bemennem (ellentétben a szemantikus webbel), mert sok mindent megtudtam, de azért voltak az előadással fenntartásaim. Az elején volt egy fejezet, ahol sokat emlegette az architektúra szót, és mysql táblákat láttunk phpmyadmin-on keresztül, ez a rész talán felesleges volt, mert a későbbiekben nem volt sok szükség rá. Az is tipikus volt, hogy néha PHP kód került elő, hogy ezt így lehet megcsinálni, de nem nagyon merült fel, hogy ez csak egy példa és más nyelveken esetleg nem ob flush-sal kell csinálni, hanem csak az a lényeg, hogy a buffert kiírjuk. Ezt leszámítva a megvalósítások bemutatásai jól felépítve követték egymást, élvezhető volt.

Végül rövid eredményhirdetés hosszú sajnálkozással, hogy a Compo-ra milyen kevesen neveztek. Az egyik kategóriában csak egy induló volt, a másikban egy OpenLaszlos alkalmazás nyert.

Web konferencia Live

Mindjárt átgurulok a webkonferenciára. Meg próbálok közvetíteni, ilyet még úgy sem csináltam. (Ha le nem rohad a twitter, ahogy szokott).

http://twitter.com/karenin

Sun Java System Web Server

"Netbeans 5.5-öm még mindig nem támogatja a Tomcat 6-ot, márpedig kéne egy Glassfishnél kissebb memória igényűbb JAVAEE 5 Servlet container."

Így végződött az előző bejegyzésem, amire commentbe kaptam ötletként a Sun Java System Web Server-t. Első látásra rögtön nagyon szimpatikus volt. Régen próbáltam már egyszer, de akkor csak RHEL-re ment fel, most meg simán vett minden akadályt Ubuntu-n is.

Azt szokták mondani, hogy a SJSWS ugyanazt tudja mint az apache-httpd plusz még néhány mellé felhúzott modul/util együttvéve (pl. logrotate, webdav, reverse proxy). Van hozzá szép webes felület, command line-os tool, és persze xml-ből is konfigurálható. Viszi a legacy php alkalmazásokat, és deployolhatok bele java-t is. (A config felületeinek a kényelmességét jól mutatja, hogy létezik arra külön parancs, hogy selfsigned certificate-et gyártsunk a szerverhez. Apachhoz ehhez mindig rá kellett gugliznom egy howto-ra). A virtual hostokoat is nagyon korrektül kezeli (glassfish-ben pl. ahogy láttam a v2-ben lesz elég erős ez a funkció).

Szóval nagyon jónak tűnt, és a hétvégén úgyis újra húztunk a szerverünket, úgy hogy ez lett a web container. Részletes tapasztalatokkal majd kicsit később, valamennyi idő távlatból. Egyelőre nagyon jól muzsikál, bár vannak még megoldatlan részek (php-ből egyelőre csak a letölthető pluginjét sikerült beüzemelni, ubuntu-s defaultot nem, 80-as porthoz rootként futtatva az admin szervert is a config-deploy még nem működik, stb.). De egyelőre még a doksit se olvastam el, úgy hogy nem panaszkodunk. Jackrabbitot pl. nagyon könnyen sikerült beconfigurálni. (így).

Memória fogyasztást még nem néztem. A szerveren minden cakli-pakli foglal 200 megát (java még nincs nagyon deployolva, de legalább 15 virtual szerver fut), úgy hogy nincs pánik.

A dolgot egy kicsit rontja, hogy a fent idézett mondat nem oldódott meg. Ugyanis a SJSWS 7.0 update 1 Technology Preview, ami tudja a javee5-öt ugyan kezelhető a NetBeans pluginnel, de egyrészt a NetBeans nem hiszi el róla, hogy tudja, amit tud (csak 1.4-es projectet enged bele deployolni) másrészt virtual szervereket rohadtul nem kezel (mármint az NB plugin). Szóval itt még fényezhető lenne egy kicsit a dolog.

Cargo deploy?

A Cargo-val is úgy voltam eddig, hogy láttam, hogy van, és jó, és majd kipróbálom amikor szükgségem lesz rá. Most lenne, mert Netbeans 5.5-öm még mindig nem támogatja a Tomcat 6-ot, márpedig kéne egy Glassfishnél kissebb memória igényűbb JAVAEE 5 Servlet container.

Nosze hegesszük be a NetBeans-be. A NetBeans-ben az szeretem, hogy ANT az egész, ezért viszonylag jól bele lehet nyúlni a build processbe. Be is üzemeltem a cargot a doksi alapján, de sajnos csak azt sikerült elérnem, hogy elindítja az ANT task a tomcat-et, úgy, hogy beledeploy-olja a war-omat. De a lényeg az lenne, hogy a Tomcat fut, és alá hotdeply-al mindig frissíti az alkalmazást. De pont ez a HotDeploy, amit sehol sem találok:

Cargo offers a Deployer interface that container implementations can implement to perform hot deployments. At the moment, the following implementations exist:

* ResinDeployer
* JettyDeployer
* Jo1xDeployer


See the Deployer page for more information on how to perform a hot deployment. You can also deploy Deployables before the container is started using Static Deployment.

Nagyon úgy tűnik, hogy pont ezt nem tudja (ANTból legalább is), szóval közelről már kevésbé fényes a dolog.

Na mindegy, már húzom le a redőnyt, holnap meg megpróbálok egy context-et ráirányítani a build dir-re.

JCP WTF

Átalakult a JCP.org. Lehet pl. rá regisztrálni. Egyelőre amit értek, hogy a kedvenc JSR-eket ki lehet gyűjteni, és figyelni, de nagyon community-nek még nem tűnik az oldal.

Persze egyelőre csak a leírásból lehet tudni, mert kipróbálni nem lehet, mert szinte bárhová kattintok, elszáll, mint a...

    
System Error

There was an error processing your request. If you provided the URL, please check to ensure that it is correct or try to find what you're looking for using one of these methods:

    * Navigation menu on the left-hand side of the page
    * Search field in the header or left navigation menu

We are working on a new infrastructure, so please send us feedback at webmaster@jcp.org for the URLs you are certain are valid.

Thank you,
The jcp.org web team. 

Szóval szerintem ennél azért jobban oda kéne figyelni rá (kb. egy napja vettem észre, azóta nem javult), mert még a JSR-eket sem tudom letölteni.

jLibrary

A jLibrary egy Eclipse alapú kliensből és egy deployolható servlet/szerver alkalmazásból áll. A kliens tud működni standalone módba, vagy kapcsolódik a szerverhez, és JCR-be pakolgatja a dokumentumainkat, indexeli őket, attirbútumokat tárol, verziózik, stb.

A jó: Szép Eclipse-s felület, és mivel nehezen tudok ellenálni az új kütyüknek, rögtön ki is próbáltam. Mivel azonban mostanában olvastam, hogy Subversion-nal mennyire faszagányos verziozható webdav könyvtárat lehet csinálni, elgondolkoztam, hogy mit is ad nekem a cucc ennél többet. Indexelést, meta adatok kezelését. Éppen valami, de lehet, hogy eddig pont ez hiányzott a boldogságunkhoz.

Másrészt a funkciók nagyrészét a Jackrabbit adja. Ami nem baj (ügyes kis kliens attól még az egész stuff), csak jó olyan szemmel is nézni, hogy ez igazából egy JCP demó.

A rossz: Standalone módban ment is a dolog, de a war file-t istennek sem sikerült beüzemelni. Kicsit jobban ránézve a projektre tavaly év közepe óta nincs nagyon mozgolódás a témában.

Sun Web Developer Pack

Gondoltam, ezt meg kell nézni, annál is inkáb, mivel a leírások alapján nem egészen értettem, hogy mit is kapok: librarykat, netbeans plugineket, doksit?

Le is töltöttem (innnen), és rakom fel. Az egyetlen vicces az volt, hogy mondta, hogy kérek-e webcontainer integrációt. Persze kértem, mert olyanom még úgy se volt, és kajánul kiválasztottam a Tomcat 6-omat (igen, ot figyel alul a System Requirement-ben a Sunos app szerver mellett, és én már örültem is, mert a NetBeans 5.5 még mindig nem tud Tomcat 6-ot kezeleni), erre kaptam ezt a szép hibaüzenetet:


Na de azért felment: leginkább egy csomó library, melletük a forrás kódok és példák, tutorial. jMaki, phobos, bloggerapps, wadl, rest-api, ilyenek.

NetBeans plugin nincs benne, helyette fel ugrik egy ablak, ami tájékoztat, hogy használjam az Update Centert. Az Update Center valóban ajánl egy plugin suite-et (valójában csak a jmaki és phobos plugineket rakja fel.), és le is tölti nekem újra azokat a librarykat (illetve sajnos csak egy részüket), amit a SWDP-vel megkaptam. A NetBeans Samples projektjei alá se kerültek fel az SWDP-s minták, pedig az már csak egy lépés lenne.

Végül is a GlassFish integrációt kértem, de ez még nem derült ki számomra, hogy mit jelent (igaz még nem is nyálaztam át nagyon a doksit).

Na jó, de NetBeans és webcontainer integráció nélkül azért kaptam egy szép kupac dokuemntált sample-app ot, és librarykat szép rendben, amik közül sokat már tényleg meg akartam nézni, úgy hogy végül is köszönöm, a szünetre azért jó lesz.

tss link
arungupta bejelentész szerű

Checkstyle plugin

Bár a kódjaim most már kibírják a gyár checkstyle próbáját, néhány kimondatlan szabályoknak nem feleltek meg, és sajnos a checkstyleban nem is voltak hozzá rule-ok. (pl. a javadoc csillagainak a kívánt fajta behúzásának elenőrzése).

Úgy hogy múltkoriban összedobtam néhány Checkstyle extensiont saját használatra. Nem volt nagy flikk-flakk, mindenkinek csak ajánlani tudom, friss és használható doksi volt a honlapon, meg persze néhány példa is.

Antlr fát kapunk vissza, és egy mellékelt alkalmazással meg is lehet nézni a fát.
Ami viszont új volt, hogy se a javadoc-ot se a whitespace-eket nem parseolja. Az utóbbit úgy lehet kitalálni, hogy két token pozicióját megadja, és megnézzük, hogy köztük mi van a fájlban. Az előbbi is hasonló, de szerencsére erre már a Checkstyle is ad apit.

Ezeket kéne kipróbálni a Jackpotban is, és akkor tényleg nem lehetne már fogást találni rajtam.

Másnap

Rövid énblog:
Állítólag Charlie Parker (jazz, bebop, szaxofon) nyilatkozta az egyik lemezéről, amiven 240-es tempóban imporvizál végig, hogy ő azt azért szereti, mert ott nem kell gondolkozni, csak az izmok dolgoznak. Na, ma reggel valahogy én is így érzem, ahogy az IDE-ben rakosgatom odébb a biteket.

És akkor most két elem a reggeli RSS adagból:

Az első bejegyzés a Netbeans 6 Swing Application Framework bemutatásáról ajánl egy nyolc perces flashvideót. Bárki bármit is mondjon, szerintem a NetBeans varázslói elég jól el vannak találva: általában épp csak annyi kódot generálnak, ami még átlátható, és jó alap lehet belőlük bármihez. Szerintem még a hirhedt kéksoros Matisse is jól használható, ha az embert tudja, hogy hol nyuljon hozzá. Persze ritkán használom őket, de pl. a JSF megoldásait studírozva sokat tanultam. Ez a demó is elég szép, bár az ilyenekre mindig azt érzem, hogy szép szép, de majd akkor leszek meggyőzve, ha kezembe vehettem, és kipróbálhatom egy saját prototípusban. (Lassan már NB 6 betához se kell többet aludni egy hónapnál)
A videó külön szépsége, hogy megtanítja azt is az amerikai olvasóknak, hogy mi az a Trabant, és a végén J. Gossling egy zöld BMW-ben próbál versenyre kellni a trabanttal induló fejlesztővel. Drámai verseny.

És egy másik bejegyzés a szarkupacok milyenségéről, és a refaktoringról.

Summer Of (Java?) Code

És ebből vajon hány a java-s projekt?

Yadis

Amiről még nem beszéltem eddig. Tulajdonképpen arról van szó, hogy több URL alapú identity/egyéb szolgáltatás készítője észrevette a hasonlóságot a megoldásaikban. Mindenhol egy URL-t (vagy hasonlót) kellett beírni, és az URL-ről lehúzott dokumentumból (pl a META fejlécekből) megtudta, hogy hol van a tényleges URL, aki a service-t biztosítja.

Nosza egységesítették is a rendszereket. Az eredmény elég egyszerű (Részlet a speckóból):

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"
xmlns:openid="http://openid.net/xmlns/1.0”>
<XRD>
<Service priority="10">
<Type>http://openid.net/signon/1.0</Type>
<URI>http://www.myopenid.com/server</URI>
<openid:Delegate>http://smoker.myopenid.com/</openid:Delegate>
</Service>
<Service priority="50">
<Type>http://openid.net/signon/1.0</Type>
<URI>http://www.livejournal.com/openid/server.bml</URI>
<openid:Delegate>
http://www.livejournal.com/users/frank/
</openid:Delegate>
</Service>
<Service priority="20">
<Type>http://lid.netmesh.org/sso/2.0</Type>
</Service>
<Service>
<Type>http://lid.netmesh.org/sso/1.0</Type>
</Service>
</XRD>
</xrds:XRDS>

Látható, hogy egyszerűen adtak azonosítokat a service-eknek és azokat dobálja vissza, amiket támogat. A LID pl. speckó szerint támogatja az OpenID 2-t is, azaz a LID szerver mindig visszaad a Yadis leíróban egy olyan sort, ahol bevallja, melyik URL-n lehet OpenID-val támadni.

Magát a Yadis XML-t egyébként elég sokféleképpen lehet megszerezni az URL-ből. Lehet, hogy HTML HEAD sorban jön, lehet hogy META teg hivatkozik rá, vagy csak egyszerűen az URL-t meghívva rögtön kiömlik a szekrényből az egész Yadis XML.

Batik

Szeretem az olyan pillanatokat, amikor végre nem kell fanyalognom.

Kellett volna gyorsan rajzolnom egy SVG-t, a gugli kiköpte a Batik-ot. És tényleg. Lenyűgöz feature lista (An SVG DOM implementation, SVG microsyntax parsers, scripting module, a generator that creates an SVG document from Java2D calls, Swing SVG component, transcoder module), és minden megy pöccre, ahogy dokumentálva van, pont úgy.

Én pl. a Graphics2D-n keresztül írtam. Előszőr összelőttem a programot egy Swinges ablakon. (Egyszerűbb volt oda gyorsan összedobni. Aztán egyszer csak a programo szályába az SVG Graphics2D implementációját adtam, és oda ugyanúgy szépen írt mindent.

Apró örömök az életben.

OpenID java libraries

Kocka kérésére :)

Az OpenID.net három java libraryról tud.

IdPrism: Jelenleg én ezzel kísérleteztek, mert ez a legegyszerűbb. OpenID 1.1-et tud, azt viszint ajaxon keresztül is. A letöltött könyvtár tartalmaz egy példa servletet is, ahol mind az ajaxos mind a szerver oldali megoldásra látunk egy egyszerű példát. A kód nem egy nagy durranás, de legaláb könnyen át lehet látni.

OpenID4Java OpenID 2.0-sat is támogat, jól néz ki, ez lesz a következő, amit kipróbálok.

NetMesh InfoGrid LID Java. A legnagyobb baj vele, hogy ez alapvetően LID implementáció. Mivel a LID speckó része, hogy OpenID-ül is kell tudnia, ezért valahol benne van az OpenID támogatás.

LID meg egyelőre megfigyelés alatt. Annyit csak, hogy próbáljuk meg megkeresni az OpenID.net oldalon a letölthető speckót, és a rá vonatkozó licenset, és ugyanezt a LID oldalon. Na ugye. Tegnap írtam egy levelet a LID community levlistájára (az archívum nagyon gyér forgalmat mutatott, de hátha). Az első meglepetés, hogy a lista moderált (szóval ennyit a communityről). Aztán jóváhagyás helyett megkaptam emailben a speckókat, amik CC licensz alatt érhetőek el. De egyelőre maradok az OpenID 2.0-hoz való felzárkózásnál.

OpenID II.

Azt hiszem most egy kicst erről fogok szólni.

Ami még fontos:
Az OpenID elosztott rendszerű. Ha beütsz egy OpenID azonosítót (pl. karenin.myopenid.com) Azt a rendszer elképzeli url-nek. (http://karenin.myopenid.com/ és lekéri az az oldalt. Az oldal fejlécében lesz valami ilyami:

<link rel="openid.server" href="http://www.myopenid.com/server" />

Na erre a címre fog átugrani mindenféle request kérelemmel.

Ezt annyival meg lehet bolondítani, hogy egy delegate nevet is használok

<link rel="openid.server" href="http://www.myopenid.com/server">
<link rel="openid.delegate" href="http://karenin.myopenid.com/">

A fentieket beraktam jelen html fejlécébe. Ezek után már a problemjava.blogspot.com-ot is használhatom OpenId azonosítónak, ami használatkor a www.myopenid.com/server-en keresztül a karenin.myopenid.com-ot fogja autentikálni.

Azaz, ha később létrehozok egy másik OpenId-t egy másik szolgáltatónál, az OpenID-s honlapokat ugyanúgy használom tovább problemjava.blogpost.com névvel, csak a fejlécembe írom át a hivatkozást.

Ami még érdekes, hogy ha nem mondom meg (mondjuk egy reguláris kifejezéssel), hogy milyen OpenID szerver felhasználói jöhetnek be hozzám, akkor alapból mindenkit beengedek. Nem lenne nagy munka egy olyan OpenID szervert összerakni, aki kvázi egyszerhasználatos usereket generálna, és bármilyen requestre azt mondaná, igen ismerem, igen be van lépve. És indulhat is a comment spam.

OpenID I.

OpenID 1.1 nagy vonalaban:

A user regisztrál egy oldalon (pl. myopenid.com), és belép. Jó nagy session-t kap, be lesz lépve 2 hétig.

Az én oldalamon is be akar lépni. Itt beírja az OpenId azonosítóját. Ez alapján az oldalam átdobja redirect-tel a böngészőjét az OpenId oldalára. A requesthez hozzá csap némi információt, pl. hogy hova térjen vissza az autentikáció után.

Az OpenID oldal tudja, hogy a tag belépett (ott van az élő session, ha nincs, akkor belépteti), összerak egy HTTP válasz üzenetet arról, hogy ki ő, és hogy tényleg okés-e, és az előzőleg megadott oldara visszatér a megfelelő paraméterrel.

(Nem tudom világos-e. Azt hiszem valami frappáns hasonlat kéne a módszerre, de még nem jutott eszembe semmi.)

Akkor nézzük tovább. Tehát én átpattintottam a böngészőjét a felhasználónak az OpenID szerverre, és az nekem visszajött némi infóval, hogy okés a srác. Honnan tudom, hogy a visszajövő requestet tényleg a másik OpenID szerver küldte?

Erre két módszer van a speckóban:

A statefull megoldás, hogy előtte az OpenID szerverrel megbeszélek egy titkos kódot, amivel aláírja a választ. (A megbeszélésre a Diffie-Hellman algoritmust használjuk, ami lehetővé teszi, hogy nem biztonságos csatornán keresztül is megállapodjunk egy közös titkos kulcsban.)

A stateless megoldás, hogy miután a böngész visszatért hozzám, a servletemből a háttrében nyitok egy http lekérése, és én is megkérdezem az OpenId szervert: te figyelj, itt van ez a válasz, iyen paraméterei vannak, és ilyen aláírás van rajta, okés? Az OpenID szerver ellenőrzi az adatokat (ehhez már nem kel a felhasználó böngészőjétől függő session, hiszen csak azt nézi meg, hogy tényleg ő írta-e alá a dolgot, azaz, hogy az adott adatokra az ő titkos kulcsa is ilyen aláírást generálna-e. Ha a ugyanazt, akkor a user böngészője nem hazudott, és a requestben megadott OpenId userévvel garázdálkodhat nálam is.

folyt. köv., addig viszont egy kipróbálást ajánlok: regisztrtáljunk pl. a myopenid.com oldalon, kapni fogunk egy karanin.myopenid.com szerű azonosítót, és aztán próbáljunk meg belépni OpenID-sített honlapokon (pl. wikitravel.org). A MyOpenId azért is jó, mert autentikáció előtt mindig kér egy jóváhagyást, ezáltal jól látható a működés.

Proxy mögött

Tudom, hogy elenyésző azon esetek száma, amikor az éles szerver egy proxy mögül zizegne, de a development környezetben ez nagyon is előfordul.

Mert van olyan, amikor egy servlet nyit egy TCP connection-t, és azon próbálna kommunikálni valahová máshová (pl. OpenLaszlo, bizonyos OpenID implementációk). Na már most, ha ennek kommunikációnak a céges proxyn keresztül kéne hogy menjen, de ilyen lehetőségre a fejlesztők nem is gondoltak. (Na jó OpenLaszloban gondoltak, de ott nem izzúlt be.)

Valmi OpenVPN-s dolgot nagyon össze kéne már gyúrni.

servlet 2.5 / jsp 2.1 web container?

Sikeresen portoltam JSF 1.1-ről 1.2-re a picipuha-majd-elkészül alkalmazásomat. Persze a kérdés még mindig ott van, hogy mi fogja hajtani. JSF 1.2, azaz JSP 2.1 kéne.

Tomcatből a 6-os még mindig béta. 5.5 nem tujda. :(

Jetty-hez a fejlesztőeszköz (NetBeans) integráció nem megoldott (bár egy ilyen modult talán össze is dobnék), meg egy kicsit gyanús is, amikor azt írják, hogy 2.5-ös servlet container, de azért a dependency injection nem működik.

Glassfish az igen. Az nagyon szépen muzsikál, a Jackrabbit JCR-t is JCA-n keresztül simán vitte. Kár, hogy egy sima start 50-60 mega Heap-et eszik a Tomcat 5-6-jával szemben. (Jconsole) Ez azt jelenti, hogy a 200 megás szerveren elég necces lenne.

Tovább:
Kideríteni, hogy hogy lehet Glassfish szolgáltatásait szelektíven indítani (pl. ejb/JMS momentán még nem kell nekem.
Vajon ha a Grizzly-t teszem be jetty-be vagy tomcat 5.5-be (jettyhez már láttam nyomokat, hogy lehet), akkor servlet 2.5-öt kapok, vagy egész más szint?

java.text.Normalizer

Itt olvasom: azt hinné az ember, hogy ha UTF-8at használ, akkor már többet nem lesz semmi baj az ékezetekkel, pedig de: mivel az ékezetes karaktereket lehet több karakterből is összrakni az Unicode-ba, de sokszor van egy egy karakteres rövidítés is rá.

A cikk példája, hogy vilálog legyen:

String name1 = "Jos\u00E9";       // José with precomposed é
String name2 = "Jos\u0065\u0301"; // José with combining sequence e + ´

Aze a kettő ugyanúgy jelenik meg

A java.text.Normalizer mindig közös alakra hozza a Stringeket, így kereshetővé és összehasonlóvá teszi. Persze csak 1.6 alatt működik, és azért nekem van egy tippem, hogy mondjuk egy webes alkalmazásnál hány ember fog a beviteli formban composite uncide karaktereket használni.

Vagy lehet, hogy egy tisztességes DB kezelő az egészet lekezeli, és csak mondjuk file műveleteknél kell vele foglalkozni?

Vajon ékezetes domaineknél ez kettő külön domainnek számít? Nyilván ott is kell lennie valami normalizálásnak.

ANT custom selector

Nekem pl. új volt.

<fileset id="activefiles" dir="${workdir}">
<custom classname="net.anzix.ant.ucm.ActFilesSelector" classpath="dist/UCMReporter.jar"/>
</fileset>

Nem taskdef-et használunk, hanem custom selector-t. A fileset végig megy az összes fájlon, és a selectortól megkérdezi, hogy szerinte benne legyen-e a filesetben az a fájl:

public boolean isSelected(File basedir, String filename, File file) throws BuildException {

Nekem azért kellett, mert egy java osztályom visszaad egy file tömböt (ClearQuest-ben érintett fájlok, command line wrapperből szedve), és azt be akaromtam rakni egy filesetbe, úgy hogy később még exlude/includolni lehessen rajta az ANT-ban. Na erre pl. nem túl hatékony a módszer, de ameddig így is 3 mp alatt kijön az eredmény, egyelőre ez lesz.

régi szép napok

Van egy jar könyvtáram (illetve nem az enyém, csak szereztem), szép 1.5-ben megvalósítva (enum, generic, template). Van egy CDC-res szánt alkalmazásom, amit IBM J9-el akarok PocketPC-n futtatni (helyből -source 1.4).

Az egyik megoldásnak a retroweaver-t találtam, amit a lefordított class-okat machinálja át 1.4-es alatt is futathatóvá. Ant taskként működik, kipróbáltam, és működött. Szép. (Persze csak akkor , hogy ha nem használunk csak 1.5 api-jában lévő dolgokat).

A másik megoldás (és sajnos ez lett belőle), hogy kézzel nekiállok gyomlálni, és átírni a dolgokat. Sajnos ez lett belőle, mert kiderült, hogy a CDC/Basic Profile-bül hiányzik néhány awt.geom.*, amit a könyvtár használt, de kellett, úgy hogy úgy is át kellett alakítani.

Viszonylag kis api, de akkor is elég gépies volt visszaalakítani. Egy életre megtanultam, hogy mennyivel szebb 1.5-ben programozni. Sorban butítottam vissza mindent, az enumoktól kezdve az Autoboxingig, sok castolás a generic helyett. Brr...

custom EL

Az van, hogy Java Content Repository lesz a megoldás. A POJO-k (amit JPA-val tudnék pertisztálni)sajnos túl merevek, nem lehet őket kiterjeszteni könnyen, míg a JCR node-jait lehet, mert nincsenek hardcode-olva bele a property nevek és típusok (persze veszítünk a típusossággal, dehát volt már nagyobb veszteségünk is).

Persze a JSF-es Expression Language alapból nem jön rá, hogy a #{name.property}-re egy JCR-es node.getProprty().getString()-et kéne kiadnia.

Viszont lazán lehet definiálni PropertyResolvert:

1. A PorpertyResolvert- leszármaztatom
2. a konstruktor megkap paraméterben egy PropertyResolvert(a defaultot), és minden metódust neki delegálok tovább. Pl.

public Object getValue(Object base, Object property) throws EvaluationException, PropertyNotFoundException {

Ha a base JCR-es Node, akkor castolom és kiszedem a propertyt. Ha nem, delegálom vissza akonstruktorba megkapott resolvernek az ügyet.
3. a faces-configba kell még egy ilyen:

<application>
        <property-resolver>com.valami.OwnPropertyResolver</property-resolver>
</application>

Mindez JSF 1.1-ben, ahol külön value resolver is van. 1.2-ben még egyszerűbb/szebb a dolog.

SOA

(Épp valami zizi van a gépemmel, és addig köhögni sem merek, amíg bootcdről indulva le nem szinkronizál a home partíciom raid1-ben. Az után jöhet a hibakeresés.

A Knoppix bootcdn meg nincs java. Pedig kéne.)

Szóval addig sztori:

A múltkoriban meglátogattuk a gyárat, ahol a cég szoftvere élesben fut (régi c-s cucc, majd javaban újraírjuk.). Érdekes volt látni. Ülnek az operátorok, az egyik monitorban az egyik rendszer, a másik monitoron a másik rendszer, és még egy ablakban a harmadik. Átjárás korlátozottan. Azt hiszem kezdem érteni, miért lett most a SOA olyan nagy divatszó.

A legjobb viszont, hogy az egyik kopott konzolos alkalmazás még egy 286-oson futott. Arra fejlesztették, és azóta megy szépen, pont annyit tud, amit kell. Az egy kérdés, hogy ha elfüstöl benne valami honnan szereznek hozzá alkatrészt. De azt is megnézném, hogy hogyan integrálná a cuccot bárki is.

soros port II.

Na, azért csak meg kell védenem a Sun-t. Ugyanis az RxTx windowson ilyen zamatos hibaüzenettel szál el:

An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_ACCESS_VIOLATION

(Bár furcsa, mert az egyik eszközömmel simán megy, csak a másik akad ki. HyperTerminállal mind2ő szépen pörög.)

A régi Javacomm API val, meg azért megy minden rendben.

AZért felemelő ez, amikor a linux alá minden van, és Windows-os kompatibilitással kell bütykölni :-)

soros port

Soros portot szernék használni. Lehetőségek:

Java Communications API
Sun-os megoldás, (bár ha jól látom nincs rá JSR, ez csak egy megvalósítás). A 3-as változat csak linuxot és Solarist támogat, a 2-es változatot elvileg előbányászható, és abban van windows-os is.

RxTx
Mindent eszik: MaxOSX, Linux, Windows, BSD, stb. Nálam egyértelműen ez a nyerő.

CDC
PocketPC-re elvileg a CDC-be kell lennie.

Az SMSlib (soros porton SMS-eket olvasó API) pl. a sunossal és az rxtx-el is megy. Csupán ANT fordítás előtt ki kell cserléni egy class elején az import javax.comm-ot gnu.io.*-ra. Vicces megoldás.

SWT

Már megint le vagyok maradva a könyveléssel.

Még a hétvégén olvasgattam SWT könyveket, hogy lássam, mit is lehet csinálni vele. Eddig főleg NetBeans (ami ugye Swing) platform környékén jártam, és eddig sikerült elkerülnöm az Eclipse környékét, úgy hogy kicsit kiváncsi is voltam, meg aggódtam is, hogy el fog tartani, amíg egy nagy GUI-t bevágok.

Hát mit mondjak. Valahogy a PHP jutot eszembe. Nyilván a full extrás OOP absztrakciók felől nézve elég szerény a dolog, de az is igaz, hogy az egyszerűségnek is van esztétikája. Nem lehet véletlen, hogy annyi Eclipse plugin van: nyilván a GUI-t is egyszerűbb össze rakni.

Egyelőre nem tudom szeretni fogom-e, ahhoz még konkrét pocket pc-s projektek kellenének, de mindenesetre az SWT-s könyveket hamarább átfutottam, mint hittem.

PDA + Java II.

PDA fronton elértük az első sikereket:

Az AWT el lett doba, helyette SWT. Lejött egy default Eclipse telepítés Visual Editor modullal. (A folyosón azt mondták, hogy bármennyire is Swing pártiak legyünk, PDA-n még igaz (ami PC-n már nem igazán), hogy az SWT gyorsabban fut, úgy hogy mindenképpen használjuk azt).

Az SWT dll-t és jar-t felraktam a PDA-ra a J9 megfelelő könyvtáraiba, és vidáman futnak azóta az SWT-s programok. (A J9-nek van PC-n futtatható változata, oda a PC-s SWT kell, és akkor többé kevésbé a PC-n tesztelhető az alkalmazás.)

A legjobb leírás amit találtam ez, főleg, mert mellékel néhány példa forrást is.

Service Provider Interface

Eredetlieg azt hittem, hogy legalábis egy kiforrott API, de aztán kiderült, hogy maximum egy tervezési minta.

Arról van szó, hogy van egy alap programunk, és szeretnénk kiterjeszteni a funkcionalitást mindössze annyival, hogy bedobálunk a classpathba jar-okat. A(z egyik lehetséges) megoldás:

Van egy interface, ezzel definiáljuk, a kiterjesztési pontot. A bedobállandó jarokban implementáljuk az interface-t. (Eddig minden a szokásos).

Aztán csinálunk a jarokban egy könyvtárat és abban egy sima szöveges fájlt (mondjuk META-INF/services/com.domain.csodainterface) és egy-egy sorban felsoroljuk az implementáló osztályokat. A főprogram fogja a classLoader-ét és a getResources(META-INF/services/com.domain.csodainterface) metódussal szépen megkapja a fájl referenciákat. Ezekből kiolvassa a sorokat (amikben class nevek van) és ezeket reflection api-val szépen meghívogatja.

Azt hiszem ez csak egy módszer, de meglepően sokat találkozom mostanában vele (pl. Így lehet a radeox wiki engine-be új makrókat definiálni).

Linkek:
Ethan Nicolas vázolja a helyzetet
Jar speckóban emlegetve
Ez utóbbi emlegetés különösen kedves, mert nagy bizonyossággal hivatkozik egy Service.providers funkcióra, amit (ahogy számomra kiderült) nekem kell végül is megírni a fent említett módon.

PDA + Java I.

(Azt hiszem, kicsit lemaradásban vagyok, most csak a legutóbbi:)

Szeretnék Java programokat írni PDA-ra. A Sun-nak csak egy csomó speckója rá, de VM-je nincs. (A folyosón azt mondják, hogy volt, csak durván összeveszett az MS-sel, és azóta nincs.)

Az egyöntetű vélemény az, hogy J9-et kell használni (vagy ahogy ők mondják: WebSphere Everyplace Micro Environment). Ez elvileg 5$, de le lehet tölteni és ki lehet próbálni ingyen is. Fent is van.

Már csak a fejlesztő eszköz a kérdés. NetBeans-nek van CDC változatú Mobile Pack-je, de az se ilyen egyszerű. Ove Nordström (kimondani is gyönyörűség a nevet) bolgjából azt vélem kiolvasni, hogy két fajta GUI szabvány létezik az aGUI (Swinges, amit a NetBeans CDC tud és jsr, viszont Norström szerint még nem támogatják a készülékek) és az eSWT (az SWT egy részhalmaza és az IBM-ék nyomják). Ez utóbbit le is lehet tölteni és egy dll-el együt felcopyzni, és akkor menne. De ehhez nincs fejlesztő eszközöm.

A folyosón még azt mondták, hogy csináljak sima java projectet és csak az AWT elemeket használjam. Nem tudom ugyan használni a java.micro csomagokat (ami azért kelleni fog előbb utóbb), de menni fog.

Kipróbáltam és nem ment. Egyszerűen lefut a program, és semmit nem jelenít meg. Rejtély.

Tervek:
* hagyni a netbeans-et és keresni olyan Eclipse plugineket, amikkel megy a CDC és SWT csinál, és azt kipróbálni.
* Esetleg kipróbálni az IBM eclipse alapú csodáját (3 hónap trial, utána ~600$)
* törni a fejem, hogy egy awt miért nem indul el simán, és miért nem szól, hogy elszáll.
* keresni néhány mintát

gosling

Ez a gosling nem az a gosling. Ez egy ant átirat, amit az ant fájlokat használja, de nem xml-ben kell build fájlt csinálni, hanem Javaban. (Érdemes megnézni a példát.)

Egyrészt engem meg lehet győzni. Miért is ragaszkodunk mindig annyira az XML-hez, ha egyszer a kedvenc nyelvünk sokkal intelingensebb nála? A TSS-en épp a minap fanyalogtak az 1.7-es ant kiadásával kapcsolatban, hogy exception kezelés meg if/while elemek mennyire hiányoznak az ANT-ból.

Másrészt, engem mindenről meg lehet győzni, de mindenről csak akkor, ha együttműködik az IDE-mmel (most épp NetBeans). És lehetőleg ne egy ritkán fejlesztett pluginen keresztül, hanem pl. mint az IvY ANT fájlon keresztül teljesen legyen behegeszthető.

Amúgy már rég akarok írni, hogy azt hiszem az IvY lesz a menekülési útvonal a Maven2 elől. Van a fejemben egy lightweight ant+ivy based build környezet, ami azt hiszem pótolni fogja tudni. Csak kéne rá egy kis idő.

vision

Spring RCP-hez kerestem tutorialokat a minap, amikor ebbe akadtam bele. Nem csak azért tetszett, mert a Spring RCP közismerten alul dokumentált (viszont elég igéretes ahhoz, hogy ennek ellenére éremes legyen túrni) és egy jó tutorial nagy érték. Hanem mert ez nem is inkább tutorial, hanem inkább olvasó napló. Nem csak azt írja le, hogy hogynan kell életet lehelni a funkciókba, hanem azt is, hogy hogyan jutott el a megoldásra. Hol és hogyan találta meg a szükséges információkat.

Szimpatikus megoldás. Azt hiszem ezek után én is ezt fogom csinálni. Java olvasónapló. Mindennapi problémáim.

Ajax, Swing, ...

Múltkor az egyik állásinterjún amikor a vezető látta az AJAX szót rögtön az lett a feladat, hogy győzzem meg, hogy miért jó az AJAX, mi többet ad egy Swing alkalmazáshoz képest.

Mondtam neki, hogy rosszul fogja fel a dolgot, épp hogy kárpótol a Desktop alkalmazások feelingjének elvesztése miatt.

Csak arról jutott eszembe, hogy épp egy zseniális webappot csinálunk, illetve annak is most csak a css/js szkript részét. Annó desktop alkalmazás volt, de aztán kitalálták, hogy legyen webes alkalmazás, mert az olyan trendi. (intranetes, tehát kevesen használjk, és simán meg lehetne követelni egy WebStart-ot is a böngészőn kívül.) Meg is épült az első változat, jelenleg a másodikon kell dolgoznom. De ebbe most olyan szép követelmények vannak (itt legyen scroll bar, ott legyen, ezt mutassa, oda popup), hogy egy kicsit kezdek vágyakozni a Swing után. Az legalább egy Java api, és nem kéne itt gányolnom a CSS/JS-t. A böngészőkompatibilitásokról nem is beszélve.

Na megyek is vissza. Köszönöm, hogy elmondhattam.

jalopy

Kódformázó (éjlenek a céges policyk) aminek utsó release februárban jött ki (1.5rc) miközben a sourceforge-olt oldalról belinkelt cég már 1.7-et is árul. (Vajon a szerzőkre nem vonatkozik a GPL és nem kell kiadni a forráskódot?)

1. Előszőr is kiderült, hogy ha 2 sorba kerül a metódusnév, akkor nekem a kapcsos zárójelet a harmadik sorba kell írnom, és ezt semmiképp nem tudta. Sebaj, nyílt a forrás. Kinyitom, hunyorítok.

Interface-ek csak kevesen inkább közvetlen leszármazottak. (lásd Dependency Inversion Principle) már gyanús, hogy nem lehet szépen cserélgetni amit akarok. És valóban. Viszont a forrásban hamar megtaláltam amit nekem kellett és csak egy helyen írtam át. Nosza repacking és minden megy is szépen ANT taskból. (Elfogott a kísértés, hogy csak az újrafordított osztályt másoljam be a régi jarba, ha már tákolunk, csináljuk durván :-) Szegény ember IoC-ja mondja erre egy koléga.)

2. Persze vérszemet kaptam és kb 10 munkaórában össze is raktam egy NetBeans plugint rá. Ha majd letisztázom valahol publikálni is fogom, ha valakinek nagyon kell írjon a commentbe...

Amúgy már régen kísérleteztem NetBeans platformmal, de most valahogy minden összeállt és kezdtem átlátni a dolgokat. Nem OSGi persze, de azért elég szép komponens alapú, ami nekem alapból megdobogtatja a szívem.

1.6

Most már két tizedes választja el a jelenlegi project policyt a kurrens verziótól. Remélem nekik is fel tűnik. És legalább az 1.5ig eljutunk.

(A hírben mintha 60 napos ingyenes supportot írtak volna, amit ki kéne próbálni :-)

WTF

Egyébként a jsr 109-ből van. (És tényleg nincs 125 oldalnál több)

Utóirat

Kedves Jézuska. Szeretném, ha karácsonyra hoznál nekem egy rendes blogmotort, mert ebbe egy kínszenvedés volt beleírni az előző forráskódos cuccost. Átlátható architektúrája legyen (pl. Spring, JPA) és lehet pehelysúllyú, azt könnyebb bütykölni. Ja és egy ip-t is szeretnék, ahová 80-as portra rakhatom fel a glassfish-t, és nem kell közösködni minden mással httpd.apache-csal.

Mikrokernel és kampók

Az álmom továbbra is ugyanat. Egy j2ee-s (de legalább is web kontainerbe futó) mikrokerneles moduláris alkalmazást találni/írni. Néha, ha ez rámjön, akkor elkezdek guglizni, és olyanokról olvasok, mint a HiveMind, vagy az OSGi.

Az OSGi különösen szimpatikus, van benne dependency kezelés, modularitás, futás közben-i deploy. Az egyetlen, ami hiányzik ezekből a rendszerekből, az a hook rendszer, amire szintén ácsingózok.

Aztán belegondoltam és rájöttem, hogy ez teljesen érthető. Ha van lehetőség egy szolgáltatást (interface-t) publikálni, és azt más szolgáltatásokból meghívni, akkor a publish/subscribe minta szerint már vidáman lehet remek hook rendszereket képezni bármelyi felé.

Valahogy így képzelem:
1. van egy HookSystem.java, ahová regisztrálni lehet egy interface konkrét implementációit (akár többet is)
//publish service
public void create(Class interfacez);
//subscribe to service
public void register(Class interfacez,Object o);
//execute the hook
public Object getHook(Class interfacez);

Például:
HookSystem system = new HookSystem();
//publish
system.create(hookertest.Hook.class);
//suscribe
system.register(hookertest.Hook.class,new HookImpl1());
system.register(hookertest.Hook.class,new HookImpl2());
//get the executor
Hook hook = (Hook) system.getHook(hookertest.Hook.class);
hook.print("asdx");
Terménszetesen a két HookImpl* implementálja a Hook-ot.

2. és van egy parancs, ami meghívja az összes implementációt, aki regisztrálvan van. A vicc kedvéért ezt a HookSystem.getHook-on keresztül csinálnám, ami egy proxyt ad vissza a Hook interface-re, de bármit meghívva rajta az összes implementáló osztály végighívja a paraméterekkel (a visszatérési értékek kezelésén még gondolkozom, egyelőre legyen mindenki void, és a paraméterekbe irkálljon. Továbbá az is gyanús, hogy szép generic-kekkel még meg lehetne bolondítani az egészet.)

Hát így. Hook rendszerem van. Már csak valamelyik mikrokernel cuccost kéne átlátni.