Sun Certified Enterprise Architect minősítés ingyen: itt
Ez egy Beta vizsga, azaz valószínű hosszabb lesz mint az igazi, viszont ingyen van, de teljes értékű certificate-et ad.
2007/08/30
2007/08/29
Jazoon fóliák
2007/08/27
Vissza a gyalupadhoz
Holnaptól újra meló. Ma még csak eszmélkedés: az olvasatlan RSS bejegyzések számát már sikekerült 50 alá szorítani.
TODO list őszre:
* használhatóra hegeszteni az ANT alapú Build Systememet (project Merevaik)
* JCR + OSGi + Wicket (esetleg JSF) alapú egyszerű honlap motort kalapálni (akár saját build systemmel)
* a jum.hu domain regisztrációt elintézni, Confluence-t kidobni, és bármi mást helyette (akár PHP is szóba jöhet (Drupal), csak ne keljen vele egyelőre szarozni. Persze PHP is Quercus + Glassfish alatt menne).
* a JUM-ra angol leírást tenni, és regisztrálni Java User Groups-nak
* letenni a Sunos Web Service Certificate-t (véletlenül van egy ingyen voucher-em és el kell használni).
* fényezni az angol tudásom
* előadókat szerezni a JUM-ra. (pl. kereseni olyan embereket, akik OS java projekteken dolgoznak, és megkérni hogy beszéljenek róla. Ha tudtok ilyet, kommentbe jöhetnek.)
* DJL projectet kitalálni (egyelőre nem publikus, de a J betű Javát fog jelenteni).
ps: itt egy fasza Wicket vs. JSF bejegyzés. Csak azt nem értem miért nem kommentelhető :(
TODO list őszre:
* használhatóra hegeszteni az ANT alapú Build Systememet (project Merevaik)
* JCR + OSGi + Wicket (esetleg JSF) alapú egyszerű honlap motort kalapálni (akár saját build systemmel)
* a jum.hu domain regisztrációt elintézni, Confluence-t kidobni, és bármi mást helyette (akár PHP is szóba jöhet (Drupal), csak ne keljen vele egyelőre szarozni. Persze PHP is Quercus + Glassfish alatt menne).
* a JUM-ra angol leírást tenni, és regisztrálni Java User Groups-nak
* letenni a Sunos Web Service Certificate-t (véletlenül van egy ingyen voucher-em és el kell használni).
* fényezni az angol tudásom
* előadókat szerezni a JUM-ra. (pl. kereseni olyan embereket, akik OS java projekteken dolgoznak, és megkérni hogy beszéljenek róla. Ha tudtok ilyet, kommentbe jöhetnek.)
* DJL projectet kitalálni (egyelőre nem publikus, de a J betű Javát fog jelenteni).
ps: itt egy fasza Wicket vs. JSF bejegyzés. Csak azt nem értem miért nem kommentelhető :(
2007/08/01
messze.net
Bár a posztok már megritkultak, de most a függőnyt is behúzzuk. Holnaptól augusztus végéig max 2 napot vagyok online, úgy hogy addig nem frissülünk.
Mine metsa. Menj erdőbe.
Mine metsa. Menj erdőbe.
2007/07/17
Java Content Repository Browser
A JCR egyik hibájának szokták felróni, hogy nincs hozzá jó admin eszköz (~pgAdmin, Toad). Kezdemények azért szerencsére már vannak. Ma kettő került az utamba: A JCR Controller és a JCR Browser.
Minkettő elég jó funkcionalitást biztosít, írni olvasni, exportálni importálni lehet mindent. A JCR Controller webstartról indítható standalone program (screenshot), de sajnos 1280x87.. ra optimalizálták. Ezt azt jelenti, hogy 1024x768-as felbontásban egyes mezők nem is láthatóak, nem érthetőek el. Ez azért eléggé lecsökkenti a használhatóságot. (Már aki szintén sajnálta a pénzt, monitorra).
A JCR Controller, szintén friss fejlesztés, egy war file-t kell deployolni, tehát webes, és belépéshez a repository JNDI címe és egy login név kell. A kedves dolog az benne, hogy mivel tudja ugyanazt a repositoryt használni, amit a webalkalmazásom, ezért nem kell JCR-RMI-t feltelepítenem, hogy megnézzem mi van épp a repositoryban. Még elég nyers (pl. idiot-sicher validálások sokszor hiányoznak), de működő és használható. Egyelőre ez marad.
BTW, kijött a JCR 2.0-ből a Public Review.
Minkettő elég jó funkcionalitást biztosít, írni olvasni, exportálni importálni lehet mindent. A JCR Controller webstartról indítható standalone program (screenshot), de sajnos 1280x87.. ra optimalizálták. Ezt azt jelenti, hogy 1024x768-as felbontásban egyes mezők nem is láthatóak, nem érthetőek el. Ez azért eléggé lecsökkenti a használhatóságot. (Már aki szintén sajnálta a pénzt, monitorra).
A JCR Controller, szintén friss fejlesztés, egy war file-t kell deployolni, tehát webes, és belépéshez a repository JNDI címe és egy login név kell. A kedves dolog az benne, hogy mivel tudja ugyanazt a repositoryt használni, amit a webalkalmazásom, ezért nem kell JCR-RMI-t feltelepítenem, hogy megnézzem mi van épp a repositoryban. Még elég nyers (pl. idiot-sicher validálások sokszor hiányoznak), de működő és használható. Egyelőre ez marad.
BTW, kijött a JCR 2.0-ből a Public Review.
2007/07/16
Széljegyzetek process killezéshez
Még a múlt hétvégéről maradt itt egy cetli, amin két dolog áll:
Egyrészt a Runtime.getInstance().addShutdownHook() Ami egy elindítatlan szállat ad a JVM-nek, hogy amikor meggyilkolja valaki a programunkat, a JVM becsukása előtt még lefutassa a szálunkat. (ctrl+c vagy kill esetén még lefut, de kill -9 esetén persze nem). Nagyon szép lehetőség fusizásra, és nyilván szép megoldásokra is.
A másik, hogy kill -3 parancsra a Sun (gyanítom, ez nincs specifikálva általánosan) JVM kiadja a futó java thread-ek stack trace-ét. Szegény ember JConsol-ja. Valamikor még hasznos lehet.
Egyrészt a Runtime.getInstance().addShutdownHook() Ami egy elindítatlan szállat ad a JVM-nek, hogy amikor meggyilkolja valaki a programunkat, a JVM becsukása előtt még lefutassa a szálunkat. (ctrl+c vagy kill esetén még lefut, de kill -9 esetén persze nem). Nagyon szép lehetőség fusizásra, és nyilván szép megoldásokra is.
A másik, hogy kill -3
2007/07/13
Java User Meetings II.
Ezzel a beszámolóval még adós vagyok:
Az első előadás az enyém volt, JBI-ról szólt. Egy kicsit lelkiismeret furdálásom volt utána. Miután végig fikáztam a TSSJS EU előadásait, aztán pedig észrevettem, hogy én is ugyanazt csinálom, ami máshol nem tetszett (pl. elcsúszok az idővel). Mindegy, azért remélem legalább néhány embernek hasznos volt.
A Dojo és Wicket előadásokról együtt: nekem mindkettő nagyon bejött. Jó fáradt voltam, de ébren tartottAK, mindkettő sok kódot mutatott, de nem tévedtünk el benne, de kaptam valami érzést, hogy milyen is belül kb. a felépítése a két dolognak. És átjött pl. hogy a javascriptnek igen is lehet szépsége az, amikor aspektus orientált dolgokat csinálunk kihasználva a kevsébé típusosságát, vagy hogy egy keretrendszer, ami nem akarja megváltani a világot, csak egyszerű és jól használható akar lenni, szépen megírva, az igen is perspektíva. (Tegnap este le is ültem Wicket-ezni, hogy kipróbáljam).
Szóval, ha voltak még az első alkalom után kétségeim, akkor most teljesen elszálltak. Jó arcok voltak, és jó értő kérdések. Számomra a megszerzett tapasztalat verte a sokszor szokásos marketinges-evangelizációs előadások információs tartalmát.
Az első előadás az enyém volt, JBI-ról szólt. Egy kicsit lelkiismeret furdálásom volt utána. Miután végig fikáztam a TSSJS EU előadásait, aztán pedig észrevettem, hogy én is ugyanazt csinálom, ami máshol nem tetszett (pl. elcsúszok az idővel). Mindegy, azért remélem legalább néhány embernek hasznos volt.
A Dojo és Wicket előadásokról együtt: nekem mindkettő nagyon bejött. Jó fáradt voltam, de ébren tartottAK, mindkettő sok kódot mutatott, de nem tévedtünk el benne, de kaptam valami érzést, hogy milyen is belül kb. a felépítése a két dolognak. És átjött pl. hogy a javascriptnek igen is lehet szépsége az, amikor aspektus orientált dolgokat csinálunk kihasználva a kevsébé típusosságát, vagy hogy egy keretrendszer, ami nem akarja megváltani a világot, csak egyszerű és jól használható akar lenni, szépen megírva, az igen is perspektíva. (Tegnap este le is ültem Wicket-ezni, hogy kipróbáljam).
Szóval, ha voltak még az első alkalom után kétségeim, akkor most teljesen elszálltak. Jó arcok voltak, és jó értő kérdések. Számomra a megszerzett tapasztalat verte a sokszor szokásos marketinges-evangelizációs előadások információs tartalmát.
2007/07/11
Száz
Kicsit több mint egy éve kezdtem el ezt a blogot írni, és most elértem a századik bejegyzést. Szeretnék most valami nagy és ünnepélyes dologt írni, de nem tudok igazán mit. Hétköznap van, egész éjjel hegesztettem az előadásomat, a meló meg megy tovább. Mindenesetre köszönök minden visszajelzést/látogatást/olvasást.
Vannak terveim a jövőre is, ennek az első jele, hogy a domain megváltozott (jtechnics.anzix.net alatt érhető el mostantól az oldal, meg persze a régi URL is működik). Ez (amellett hogy a mivel a problem szó kikerült a címből, a problémamentesség illúzóját adja nekem), egy régi terv első lépése, amikor is előbb utóbb át fogok állni egy saját JCR alapú blog motorra. (Tudom sok ingyenes is van, de én szeretnék JCR-es oldalt írni). Meg talán más dolgok is lesznek, de ezeket majd szeptemberben, ha visszajövök a szabadsáról.
Stay tunned, és köszönök mindent.
ui: Nem szeretem a bejegyzéseket, ahol nincs szó Javaról, úgy hogy itt egy link OSGi+Guice összeházasításáról. Bár ahogy én tudom service registry jelegű dolog az OSGi van, de talán nem elég injektálós. Nem tudom, de egyszer még utána kéne nézni, most nincs időm véigi bogarászni.
Vannak terveim a jövőre is, ennek az első jele, hogy a domain megváltozott (jtechnics.anzix.net alatt érhető el mostantól az oldal, meg persze a régi URL is működik). Ez (amellett hogy a mivel a problem szó kikerült a címből, a problémamentesség illúzóját adja nekem), egy régi terv első lépése, amikor is előbb utóbb át fogok állni egy saját JCR alapú blog motorra. (Tudom sok ingyenes is van, de én szeretnék JCR-es oldalt írni). Meg talán más dolgok is lesznek, de ezeket majd szeptemberben, ha visszajövök a szabadsáról.
Stay tunned, és köszönök mindent.
ui: Nem szeretem a bejegyzéseket, ahol nincs szó Javaról, úgy hogy itt egy link OSGi+Guice összeházasításáról. Bár ahogy én tudom service registry jelegű dolog az OSGi van, de talán nem elég injektálós. Nem tudom, de egyszer még utána kéne nézni, most nincs időm véigi bogarászni.
2007/07/09
AntUnit
Az AntUnit egy viszonylag friss projekt (pl. nekem csak 1.7-es ANT-tal ment rendesen). Célja, hogy ha ant taskokat csinálunk, (vagy mindenféle antot kiterjesztő varázslatot) egyszerű legyen tesztelni. A dolog nagyon egyszerű:
Ha a fájlt egy egy másik ant xml fájlból au:antunit taskkal hívjuk meg, akkor a test kezdetű targatek fognak lefutni. (meg persze a setUp, tearDown), és az assertek nek igaznak kell lenniük. Ami miatt viszont nagyon jó a dolog, az az ért van, mert ha csak úgy minden flikkflakk nélkül lefuttatjuk az xml-t, akkor lefut hagyományos módon. Pont mint a javaban a (sose használt) assertionok: ha bekapcsolom beszól, ha nem nem.
Annál mindenesetre szebb, mint amilyen Junit-os hackeket csináltam eddig.
<project xmlns:au="antlib:org.apache.ant.antunit">
<!-- is called prior to the test -->
<target name="setUp">
<property name="foo" value="foo"/>
</target>
<!-- is called after the test, even if that caused an error -->
<target name="tearDown">
<delete file="${foo}" quiet="true"/>
</target>
<!-- the actual test case -->
<target name="testTouchCreatesFile">
<au:assertFileDoesntExist file="${foo}"/>
<touch file="${foo}"/>
<au:assertFileExists file="${foo}"/>
</target>
</project>
Ha a fájlt egy egy másik ant xml fájlból au:antunit taskkal hívjuk meg, akkor a test kezdetű targatek fognak lefutni. (meg persze a setUp, tearDown), és az assertek nek igaznak kell lenniük. Ami miatt viszont nagyon jó a dolog, az az ért van, mert ha csak úgy minden flikkflakk nélkül lefuttatjuk az xml-t, akkor lefut hagyományos módon. Pont mint a javaban a (sose használt) assertionok: ha bekapcsolom beszól, ha nem nem.
Annál mindenesetre szebb, mint amilyen Junit-os hackeket csináltam eddig.
2007/07/05
OSGi server-side
Még rég volt utoljára, amikor az OSGi-vel foglalkoztam, akkor még amikor a Server-side OSGi szóba került, a FAQ-k általában azt mondták, hogy ne kelljen nekem olyan, mert úgy is van OSGi webserver bundle, és na akarjam meglévő appszerveremet használni. Ami azért nem annyira szimpatikus hozzáálás.
Most a TSSJS EU-n láttam egy bemutatót, hogy az Equinoxra (az Eclipse alatt lévő OSGi implementációra) elkészült egy servletes bridge is.
A dolog nagyon egyszerű:
Ha deployolni akarsz bele OSGi dolgokat, arra is ott van a példa. Persze csak Eclipse-el fordítható (Ant?, Maven?), de utána a kapott jar-t már deployolhatjuk az OSGi konténerbe:
install file:///home/user/samplehttp.jar
Utána ss paranccsal látjuk, hogy megette-e, és start number paranccsal indíthatjuk is (a number az ss-sel kiírt sorszámot jelenti.) Még egy ss és látjuk, hogy a sample.http_1.0.0 Active. Nézzük is meg a http://localhost:8080/bridge/helloworld címet, és működnie kell a szervernek.
Ezek után, ha a JAR-t újra fordítjuk a konzolból újra tölthetjük anélkül, hogy a servletünk leállna, ami teljesen rendben van.
Belenézve a samplehttp forrásába két érdekes dolgot látunk. Egyrészt az Activator (ami betöltéskor hívódik meg) regsiztrálja a servletünket a context alá:
httpService.registerServlet("/helloworld", new HelloWorldServlet(), null, null);
Logikusnak hangzik, mivel innentől egy szerverünk van, ami alatt komponensek és a fő szervletnek a web.xml-éhez már nem nyúlhatunk, hogy a servlet mappinget piszkáljuk.
A másik, hogy az egész kódban sehol se hivatkoznak eclipse.org osztályra. Azaz az egész servletes regisztrálós dolog az OSGi szabvány része, valamint valószínű a szabvány további szolgáltatásai is (pl. Logging services) konkrét interfacek megadását is jelentik. (Ez még ellenőrizendő).
Mindenesetre pazar cucc az egész moduláris web alkalmazások írására, mivel a class loader nyűgöket rendesen kezeli az OSGi, és alapból neked csak annyit kel csinálni, hogy ésszerűen modulokba rendezn a kódot és szétcsapni részekre. És akkor persze majd lehet csinálni az extension pontokat, (erre is van benne támogatás, csak még nem láttam).
(BTW megalakult a JSR-316 néven a JAVAEE 6, ami újra felkavarta a JSR-277 vs. OSGi vitát, mivel egyértelműen leszögezte, hogy mivel a JAVAEE 7 JSR-277-re fog épülni, ezért szó sem lehet OSGi-ról. )
Most a TSSJS EU-n láttam egy bemutatót, hogy az Equinoxra (az Eclipse alatt lévő OSGi implementációra) elkészült egy servletes bridge is.
A dolog nagyon egyszerű:
- Töltsd le innen a bridge.war-t.
- Deployold egy web containerbe.
- Indítsd el a webcontainer-t úgy, hogy a standard input megmaradjon (defaultból da kapod az OSGi konzolt). Tomcat-ben pl. a ./catalina.sh run a nyerő megoldás.
Ha deployolni akarsz bele OSGi dolgokat, arra is ott van a példa. Persze csak Eclipse-el fordítható (Ant?, Maven?), de utána a kapott jar-t már deployolhatjuk az OSGi konténerbe:
install file:///home/user/samplehttp.jar
Utána ss paranccsal látjuk, hogy megette-e, és start number paranccsal indíthatjuk is (a number az ss-sel kiírt sorszámot jelenti.) Még egy ss és látjuk, hogy a sample.http_1.0.0 Active. Nézzük is meg a http://localhost:8080/bridge/helloworld címet, és működnie kell a szervernek.
Ezek után, ha a JAR-t újra fordítjuk a konzolból újra tölthetjük anélkül, hogy a servletünk leállna, ami teljesen rendben van.
Belenézve a samplehttp forrásába két érdekes dolgot látunk. Egyrészt az Activator (ami betöltéskor hívódik meg) regsiztrálja a servletünket a context alá:
httpService.registerServlet("/helloworld", new HelloWorldServlet(), null, null);
Logikusnak hangzik, mivel innentől egy szerverünk van, ami alatt komponensek és a fő szervletnek a web.xml-éhez már nem nyúlhatunk, hogy a servlet mappinget piszkáljuk.
A másik, hogy az egész kódban sehol se hivatkoznak eclipse.org osztályra. Azaz az egész servletes regisztrálós dolog az OSGi szabvány része, valamint valószínű a szabvány további szolgáltatásai is (pl. Logging services) konkrét interfacek megadását is jelentik. (Ez még ellenőrizendő).
Mindenesetre pazar cucc az egész moduláris web alkalmazások írására, mivel a class loader nyűgöket rendesen kezeli az OSGi, és alapból neked csak annyit kel csinálni, hogy ésszerűen modulokba rendezn a kódot és szétcsapni részekre. És akkor persze majd lehet csinálni az extension pontokat, (erre is van benne támogatás, csak még nem láttam).
(BTW megalakult a JSR-316 néven a JAVAEE 6, ami újra felkavarta a JSR-277 vs. OSGi vitát, mivel egyértelműen leszögezte, hogy mivel a JAVAEE 7 JSR-277-re fog épülni, ezért szó sem lehet OSGi-ról. )
2007/06/29
Summary: TheServerSide Java Symposium Barcelona 2007
Osszefoglalasul:
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:
- Jevgeni Kabanov: Aranea-rol
- Stephene Colebourne: Java Closures
- Ola Bini: JRuby
- Alexander Popescu: JCR
- Cliff Click: Java Performance Myths
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.
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.
2007/06/28
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.
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.
2007/06/27
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.
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.
2007/06/22
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.
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.
2007/06/14
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).
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).
2007/06/05
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.
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.
2007/06/02
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))
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))
2007/05/30
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.
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.
2007/05/25
Feliratkozás:
Bejegyzések (Atom)