StringBuilder appendelgetős

Szóval ezzel töltöttem a 2008-as év utolsó napját... Hmm, kisérleti project.

Ezt az elején hagyd ki bátran, mert tiszta marhaság saját XML-parsert írni.

Régebben írtam, hogy csináltam egy XML parsert ami NIO-hoz kicsit jobban passzol (azaz nem odadobunk neki egy IO streamet, hanem ahogy jönnek a byte-ok, úgy szépen darabonként dobáljuk a parsernek és amennyi értelmes dologot már beraktunk, arra meghívja a callback-et)

Az első nekifutás az java regexpekkel készült el, ez annyira ocsmányul lassú lett minden szempontból, hogy tulajdonképpen csak a java regexpek gyakorlására volt jó.

A második nekifutás az ma volt, megcsináltam kb korrekt finite state machine-nel, ami karakterenként parsel. A xerces, xpp3, "exmil" teljesítményversenyben az exmil majdnem minden esetben utolsóként szerepelt. Az xpp3 néha fele annyi idő alatt futott le, de még a xerces is helyenként lealázott.
Elővettem a netbeans profilerét (a mai napon néhány pirospontot elkönyvelhet a netbeans, te meg eclipse fiam üljle-egyes profilingból) és kitúrtam hogy mi viszi a legtöbb időt. A futási idő 90+ százalékában a StringBuilder-ben volt a proci. Ebből azt azt a merész következtetést vontam le, hogy a karakterek egymás után appendelgetése volt rossz ötlet.
Erre jött az az ötlet, hogy akkor esetleg nem karakterenként appendelgetek, hanem array-ként, így kihasználva a System.arrayCopy erejét. Persze mielött nekiszaladunk fejjel egy nagyobb módosításnak, elöbb mérünk...

A mérés elsőre nagyon meglepő választ hozott. Annyira meglepő volt, hogy biztos volt, hogy rossz :-) Azt szúrtam el a mérésben, hogy a StringBuildernek nem határoztam meg a kezdeti kapacitást. Az így alkotott kép elég cifra, és egyáltalán nem látszik belőle, hogy nőne a sebesség az arrayCopy-val. A probléma itt az, hogy a procidő túlnyomó részét ebben az esetben a memória allokációja és a régi adatok átmásolása okozza. (Bezzeg ha lenne java-ban realloc, mennyivel, gyorsabban menne, meg mennyivel bonyolultabb lenne programozni.)

A második mérésnél a StringBuildernek átpasszoltam a szükséges kapacitást előre, így nem kellett szegénynek átmásolgatnia egyenként. Meg is látszik az eredményen, és a kép is tiszta lett végre.


Szóval ez alapján, ha a kódomat átírom, hogy ne egyenként StringBufferbe minden darabját, hanem az elérhető mennyiségű adatból annyit dolgozzon fel, amennyit csak tud, akkor elméletileg a StringBuffer appendelgetésből származó többlet futásidőm harmadára vagy akár tizedére is csökkenhet. A többi kárára persze, mert ezt kicsit bonyibb lesz lekódolni.

Meglátjuk az újévben. Mellesleg az említett újévben 2 éves lesz ez a blogom, ebből az alkalomból felktettem egy értékelős szavazást oldalra, csak hogy én is tudjam kicsit hogy ti mit gondoltok arról amit én gondolok. Your feedback is wellcome. A szöveges feedback is.

Köszi, és boldog új évet!

JHacks @ XWiki Screenshots

Próbálgattam ma Karenin snipsnap2xwiki projectjét a jhacks dumpon és gondoltam csinálok egy pár screenshotot biztatásként. Állapot elötte és utánna...

Continuum

Rövid műsorajánlóval jelentkezünk korán reggel...

Szóval ajánlanám figyelmetekbe, hogy a continuum-hoz végre valahára megcsinálják a több agent-es build lehetőségét. Gondolom még sokat kell várni, amíg célba ér. Közben kijött a TeamCity 4.0, csili-vili dolgokkal, szóval munkában valószinűleg marad az...

Cache interszatyor

Nagy csend van nálam mostanában, rendesen el vagyok látva tennivalókkal. Hébe-hóba azért valami olyat is csinálok, ami valamennyire érdekes lehet. Például...

Szóval az alkalmazásunknak van egy halom backendje amiket igen frekventáltan használ (cms meg satöbbi), főleg (de nem kizárólag) web services alapú dolgok. Egy nagy közös jellegzetességük van: döglassú mind. Főleg a network delay sok, mert amikor meghívok egy remote objektumon egy metódust az általában egy még távolabbi metódust hív. Nem túl szerencsés, de ez van.
Erre persze már a kezdetek kezdetén gondoltak a fejlesztők, és egy tucat helyre betettek a hívás elé valamilyen cache-t.
Ez is megoldotta a teljesítmény problémákat, viszont az ilyen kód mennyisége igen szép volt sor-számban mérve, ezért keresni kezdtem más lehetőséget. Az igazából alapötlet volt, hogy a cache és a tulajdonképpeni kód az legyen egymástól elválasztva, azaz pl egy aop interceptor. Van a springmodules cucc, de abban nem találtam meg mindent kellene, úgyhogy összedobtam egy saját AOP interceptort, amit a read-only szolgáltatások elé be lehet szúrkálni a spring applicationcontext-ben.

Ilyeneket tud:

• Persze független attól az komponenstől, amire ráhúzzuk.
• Lehessen konfigurálni hogy mire lockoljon. Például egyes szolgáltatások teljesen befordulnak, ha egynél több kéréssel traktáljuk őket, úgyhogy konfigurálható hogy a hívás paramétereire, vagy az egész instance-re, vagy egyáltalán ne is lockoljon.
  
• Felhasználók speciális felületen keresztül ki is törölhetik, hogy lássák a változtatásaik eredményét. Nagyon türelmetlen népek.
  
• Konfigolható hogy melyik hívás eredménye meddig érvényes a memóriában.
• Egy szál ellenőrzi a "már majdnem" elévült adatokat és frissíti - azaz újra hívja a döglassú backendet, így a néha végrehajtott frissítés nem blokkol le egy user request kiszolgálását és nem rajzol cikk-cakkokat a terhelési teszt egyébként kellemes eredményeire.
  

Balesetek:

• Terhelési teszt közben történt is egy kis baleset: rosszul konfigoltam egy cache-t és megtekertem vele egy szolgáltatást, amiből csak egy van. Azaz live. Ez ilyen szent tehén rendszer, tilos hozzányúlni, szóval nem arattam vele osztatlan sikert.
  

Csúnya de okos

Régebben maven artifactok kereséséhez a mvnrepository.com szolgáltatását használtam. Sajnos ez mostanában rémesen belassult (mainstream lett a maven?) és hébe-hóba egy-egy reklámcsíkkal is megdolgoztatja a firefox adblocker pluginját.
Viszont mostanában bukkantam rá a jaclaz.com oldalra. A kinézete alulmúlja a google designt, viszont egész értelmes dolgai vannak. Lehet osztályokra és packagekre is keresni, megmutatja a javadocot és a forráskódot is. Szóval mindenképpen biztatóbb mint a mvnrepository mostanában.
Egyébként ezt a kereső trükköt a legtöbb maven proxy is tudja, csak nekem nincs ilyen.

JUM

Ez volt tegnap este. A sztakis keverés miatt a Sun-nál. A létszám 15 és 20 között, szerintem a helyszin probléma miatt csak a nagyon elszántak jöttek.

Elösször Elek Márton beszélt a REST-ről és a JSR-311-ről. Elég egyszerű és tréfás megoldásnak tűnik, lehet lenne helye bevetésnek, csak még elöbb körbejárnám. A maven-glassfish megoldás viszont engem meglepett, hogy milyen gyorsan felszállt. Én jetty-t használok mavenben, meg fejlesztéshez inkáb az eclipse WTP-t tomcat-tel.
Aztán Dorothy mesélt nekünk a Jazz-ról, amit már régóta figyelek mert jó ötlet, de IBM cucc és az ilyenekben nincs sok hitem, meg hát elég drága is.
Végül Auth Gábor mutatta be a glassfish v3-at, nekem mondhatni teljesen új volt mert a v2-t se használtam valami sokat. :-)

Legközelebbre bevállaltam egy pár perces előadást a scrum-ról.

Auto mate

Egy rossz élményemet leírnám ide a Continuous Integration témában, hogy erre esetleg vigyázzatok és próbáljátok meg elkerülni.

Abban az esetben, ha nálatok is minden csapat kitalálhatja magának hogy milyen build környezetet használ és esetleg bizonyos speciális dolgokat is beleépítetek (windowsos path-ok a build.xml-ben, exe fileok és más platform függő binárisok valahol a projectben, különleges classpath beállítások, környezeti változók, és a többi mocsokság), akkor a CI szervereteknél hamar felmerül az igény arra, hogy mindenkinek külön beállított build agentje legyen, amin az ő buildjei futnak. Egy kicsivel később már el is tulajdonolja egy-egy csapat ezeket a build agenteket és nem közös erőforrásként tekint rájuk, hanem inkább magántulajdon. Innentől kezdve egyes agentek majdnem teljesen kihasználatlanok lesznek, míg mások egész nap pörögnek, egyes csapatok csak másnap reggel kapják meg az eredményeket, mások azonnal.

Ez szerintem elég rossz irány és nagyon nehéz visszacsinálni ha egyszer megtörtént. Valamennyire le kell rendezni mindenkivel, hogy a buildje nem tartalmazhat speciális külső, hivatkozásokat és nem várhat el különleges beállításokat. Azaz ami kijött a verziókövetőből, annak úgy le is kell fordulnia akármilyen platformon. Persze megfelelő JDK és Ant és vagy Maven persze kell hozzá, de a megállapodás fontos. Talán még a legelején érdemes mindenkivel leüzletelni az egészet.

Szolgálati közlemény: Holnap elvileg JUM, legalábbis remélem mert már régen nem volt és ránk férne egy pár ötletcsere. Aki jó fej, az segíthetne egy 20-40 fős teremmel :-)

Getter és setter tesztelése

Igazából soha nem törekedtem 100 %-os test coverage-re, olyan evidens dolgokat mint getterek és setterek és egyszerű konstruktorok eddig eszembe sem jutott tesztelni. Ma viszont az utamba került egy bean, ami elég izgalmas viselkedést tanúsított ahhoz a rémunalmas dologhoz képest amit elvárok a fajtájától. Arra gondolok hogy ha beállítok egy tulajdonságot, akkor az legyen beállítva és ha utánna kiolvasom, akkor ugyanaz mint amit beállítottam. Egyéni ízlés kérdése, de én aknamezőnek érzem ha egy adat reprezentációra szánt osztály ettől eltérően viselkedik.

Úgyhogy írtam az összes bean-re egy tesztet, ami PropertyUtils-szal végigrohan a tulajdonságaikon és beállít valamit és megnézi hogy az érték be lett-e állítva.

Ennyi, a kód nem érdemel egy copy-pastet sem, inkáb csak ötletet akartam adni a test coverage eredmények szépítésére :-)

További kellemes pénteket mindenkinek!

Egy hónap scrum

Nincs hír. Körülbelül egy hónapja álltunk át scrum metódikára. Lement teljesen két sprint, volt két retrospektív meeting a sprintek végén hogy megbeszéljük a tapasztalatainkat és legnagyobb meglepetésemre még mindig nagyon jól megy és mindenki jól érzi magát.
Csak egy komoly veszély fenyeget: kifogyunk a szines cetlikből, amikre a feladatokat írjuk. Ha a következő egy hónapban valami meteor nem csapódik be, akkor tulajdonképpen szerintem el is fogjuk felejteni hogy ez valaha másként működött.

UI-testing TV

Akadt egy felesleges TFT és kitettük egy helyre, ahol mindenki látja, rákötöttük a selenium szerver gépre és most lehet rajta nézni a UI teszteket. Konkrét haszna csak annyi van, hogy kicsit segít a csapat figyelmét a tesztekre fókuszálni.
Elneveztük TV-nek, aki bebambul az nézheti ahogy pörögnek rajta az oldalak.

Egy kis BDD

Újra itthon, több mint egy hétig mászkáltam mindenfelé és közben tanulgattam dolgokat. A legtöbbnek ezek közül a világon semmi köze nincs programozáshoz a nevükön kívül.

Viszont akadt kis idő arra is, hogy beszélgessek emberekkel az integration test megoldásaikról. Én igazából erre is tök egyszerű junit 4.4-et használok és nem fáj különösebben. Valami fény végre derengeni kezdett viszont arról is, hogy akik fitnesse-t hajtanak, azok miért szeretik. Korábban ugyanis sikerült rendesen félreértenem a dolog lényegét, csak annyit láttam belőle hogy valami furcsa wiki engine-t kell felstartolni érdekesen összehaxolt classpath-szal és majd az lefuttatja a teszteket. Ez a pontja még most is rém ellenszenves, de ez csak esztétikai kérdés.
A lényeg az lenne inkáb, hogy program írása nélkül, wikiből editálva építheted az integrációs tesztjeidet. Ez a wiki nem kell hogy egy központi szerver komponens legyen, felstartolhatod magadnál is, vagy ha nem komállod a felületét, írhatod egy sima text editorból is (ami talán kicsit barátságosabb is mint maga a wiki). Így nem azt írod le, hogy hogyan kell a kódodat letesztelni másik kóddal, hanem egy felhasználói történetet. (Azaz story, csak magyarítok újabban) A történet táblázatokból és kommentekből áll, a táblázatokat úgy nevezett fixture-k mondják meg, hogy hogyan kell őket felhasználni. Például az utolsó oszlop az elvárt eredmény, az többi a paraméterek, legegyszerűbb esetben. Azaz a wiki tartalma a fixture-kkel együt mondja meg, hogy hogyan kell a kódodat letesztelni :-)
A fitnesse-maven integráció a srácok szerint akkora gebasz, hogy jobb róla nem is beszélni. Úgyhogy valami kis custom ant+maven dolog van belőve.

Csak hogy ne legyen az, hogy akármit bekajálok amit vendéglátóim adnak, átfutottam pár könyvet agile testing témakörben és szétnéztem hogy mi a helyzet más megoldásokkal, és a diszkóblogos srác easyb projectjébe már sokadszor botlottam bele, sikeresen túl is jutott az ingerküszöbömön végre és kipróbáltam hogyan műxik. A meséket itt körülbelül groovy-ban írod, ami elég egyszerű szintaxis, még eclipse plugin is van hozzá (bár nem sokat ér szvsz). A webes wikis dolog a fitnesse-ben szerintem nem különösebben nagy érték, ha érték egyáltalán, ugyanis a nem technikai project tagok azt sem fogják tudni csinálni helyettünk. Úgyhogy a maven-integráció (működik) és az IDE support azért egyelőre mégis inkáb ebbe az irányba terel.

Ennyi van most, aztán kiderül később, hogy hogyan és merre tovább. Csinálok pár prototype projectet és megpróbálom beilleszteni más projecteimbe.

Egy hét scrum

Ritkán szoktam ide a munkámmal kapcsolatos dolgokat írni, márminthogy olyat ami konrétan a munkahelyemen történik, most viszont azt hiszem hosszú és érdekes hetünk volt.

Ahogy múltkor írtam, egy munkatársammal közösen dolgoztunk a UI tesztek Seleniumos megvalósításán. Ezután most a tesztelőnknek, aki eddig Visual Basic-ben kalapált egy ezer éves -és többezer dolláros- szoftverbe teszteket, adtunk egy eclipse-t, subersion hozzáférést és a srác még aznap elkezdett teszteket írni nekünk. Söt, tök jól haladt vele. Ez sokkal jobb mint amire számítottam, a learning curve egészen minimális volt. Még ezen a héten vissza is fizette a befektetett időnket a bárki által írható és futtatható automatikus teszt. Beidomítottam a Continuous Integration rendszerünket, hogy automatikus webapp deploy után futtassa le a UI teszteket is, és az aznap elszórt hibáinkat perceken belül megtalálta nekünk. Kézzel egyébként napokba tellene véggellenőrizni az alkalmazásunkat, elég cifrán el van bonyolítva :-D

A csapat felállása is megváltozott, ami már hónapok vagy talán évek óta érlelődött. Átálltunk a scrum metódikára, és egy hét munka után igazából azt lehet mondani hogy nagyon biztató a kezdet. Ez egyébként egy ismert (nem létezik hogy nem ismered) nemzetközi médiacég, az ilyenek nem a fürgeségükről és a rugalmasságukról ismertek, azaz valószinűleg az agile metodikák már majdnem teljesen mainstream dolgok lettek a világ minden részén.
Félig meddig külső segítségkünt kaptunk egy ausztrál srácot egy hétre, aki elmondta mindenkinek hogy miből áll az egész. Tisztáztuk hogy ki csirke és ki disznó (itt a rövid összefoglaló arról hogy miért), és hogy nekik mi a dolguk. Innetől kezdve, mivel disznó besorolást kaptam természetesen, nem kellett résztvennem olyan megbeszéléseken ahol konkrét példát említve valami skandináv országban tervezett marketingkampány részleteiről beszélnek :-) A csirkék egy részének ez úgy láttam kicsit fáj, nekik valamivel több munka az, hogy mi nem szedjük össze magnuknak az információkat a munkánkhoz, de úgy látszik beletörődnek és csinálják ezt a részt helyettünk. Pontosítok: eddig mi csináltuk helyettük. Egyébként a csapat egészén úgy láttam hogy nagyon megszerette az új rendszert és emögött én azt sejtem, hogy mindenki körülbelül azt csinál amit szeret csinálni: kódol, embereket irányít, tesztel, stb. A dologban nagy szerepe van a pozitív motivációnak is, látszott hogy most a project lényegesen jobban halad, több időt tudunk a munkánkra szánni, nem kell kisdobos találkozókra járnunk.
Az ausztrál srác nélkül nem hiszem hogy egy éven belül sikerült volna bármi ilyesmit összehozni, szóval ha van rá lehetőséged hogy külső segítséget kérj scrum bevezetéshez, akkor szerintem sokat segíthet. Egyrészt nagyon jól is adta elő a dolgokat, másrészt azt hiszem szükség volt arra hogy egy nagyjából külsős ember vezesse a cserét. Tőlem lázadásnak vették azt amit mástól reformnak.

Így néz ki a helyzet az első hét után, persze még hónapokba tellhet amíg a véglegesül az új módszer, talán fél év is lehet amíg a többi fejlesztőcsapatnak is megtetszik és követnek minket, akár évek is amíg a rendszergazdák, webmesterek, designerek megpróbálják bevezetni maguknál. Meglátjuk nálunk hogy muzsikál.

Most egy időre megint csend lesz, integrációs teszt megoldásokról fogok tanulni pár dolgot kicsit távolabb a nyolcker otthonos bűzétől. Többek közt.

Notworking networking

A következő tétel matematikai levezetés nélkül, csak úgy:

A határozatlan ideig ismétlődő találkozók, amelyeken kettőnél több különböző szerepkörű munkatárs vesz részt vagy a megbeszélésre szánt témák mennyisége 1-nél több, azok valószínűleg nem fogják a megoldásra váró problémát a megoldódáshoz segíteni.

Hasonló problémakör az alkalmazás szerverek session replikációs megoldásai: az all-to-all replikáció nagyon hamar eléri a korlátait, általában már 2 node-nál, rosszabb esetben 1-nél :-) Ezt hasonlítsuk össze a párokba állított szerverek esetével. Valamint a túl nagy session-méret is közismerten gyilkolja a teljesítményt.

Hiánycikk

Ma keresgettem olyan api-t, ami tud tar (azaz unix tape archive) formátumot olvasni mint stream. Egy közismert van: ant. Nem éppen erre találták ki, de van benne ilyen, egy task is épül rá.
Kicsit kényelmetlenül éreztem magam amikor a pom-ba bedobtam az antot mint függőséget, úgyhogy kicsit körbenéztem hogy mit lehetne helyette. Ezt találtam: commons-compress. Nagyon tetszik az API-ja, eltakarja a archiválás és a tömörtés implementációs részleteit, szép egységes interface mögé rejti, ilyesmi. Talán jó is lett volna, viszont nincs belőle release és incubatorban van jó ideje. Az én cuccomnak viszont pár héten belül szerepelnie kell, úgyhogy talán mégsem.

Viszont az szomorú, hogy az archivum formátumok kezelésére ezek szerint nincs elterjedt, fullos és kiforrott api. Egy ilyen hétköznapi formátum, mint a tar...

Sonar 1.4.2

Nem akarok kicsi freshmeat.net-et indítani a blogomban, de tegnap a sonar fejlesztői kidobták a 1.4.2-es verziót, ami végre javítja a framework furi adatbáziskapcsolati hibáját. A JRuby ugyanis nem szöszöl holmi DataSource-okkal, hanem valami saját megoldása van az egészre. (Ezen a ponton a dolog nekem nem szimpi) Fel is űbereltem és idáig tényleg nem zuhant magába. Melóban már az 1.4.0 verziótól kezdve gyüjti a projecteink coverage adatait, annyi volt vele a probléma, hogy egy cron jobból időnként újra kellett startolni.

Eleinte kicsit lelombozónak tűntek az eredmények amiket produkált -ezt a munkatársak érdeklődésére, a saját stabilítására, sebességére és a generált grafikonok görvéire egyaránt értem- viszont lassan úgy tűnik mind a három valahogy javulgat. Sok-sok türelmet tanulok mostanában.

Selenium bütykölés

Ez a selenium dolog nem új a nap alatt, ha jól látom a jhacks bejegyzés majdnem 2 éve született rá. Akkoriban próbálgattam, igazán rajtam kívül nem sok embert érdekelt körülöttem, el is halódott. Ezzel mondjuk sajnos nem szünt meg az igény arra, hogy az alkalmazásokat a felhasználói felületen keresztül is leteszteljük, csak szerencsére az azóta munkahelyemen van erre dedikált ember, drága pénzért furcsa szoftver, tesztgépekből rakott hegyek, ilyesmi. Azt lehetne hinni, hogy akkor ez már a paradicsom, valami mégsem volt teljesen oké. Ez a drága-pénzért szoftver ugyanis valami elég ütős összegért lett megvéve per seat (hmmm...) emiatt mi -java fejlesztők- nem kaptunk belőle, mindig a QA csapathoz kell tehát rohangálni ha valamit meg akarunk nézetni. Ennél nyilván ideálisabb megoldás lenne, ha az automatikus tesztek tényleg automatikusan futnának le, például minden alkalommal, amikor egy szintén automatikus folyamat bedobja a legfrissebb verziót egy alkalmazás szerverre, valamint a fejlesztők is írhatnának tesztet, nem csak a teszt-fejlesztők.
Erre találtunk ki egy kicsit más felállást, csupa ingyenes/OSS cuccra építve (igazából a CI szerver pénzes, de ez most nem számít, vegyük úgy hogy például hudson)

• Mindenki ír tesztet, a QA team csak annyiban kitüntetett, hogy ők mást se csinálnak :-)
• Minden SVN módosulás elindítja a UI teszteket. Hát igen, kicsit terheli a gépeket, na bummm...
• A CI szerver nyomonköveti a UI tesztek futását és értesít azonnal ha valamit elszúrtunk.
• Illetve mindenki lefuttathatja saját magánál is a teszteket a saját alkalmazás példányán.

Na, ennyi az előnye, nézzük a nehézségeket:

• Keresni kellett egy windows-os gépet, mert senkit nem érdekel hogy linuxon firefoxban jól működik-e a felület. Az már sokkal inkáb hogy az MS-IE bugjai között túléli-e. Egyelőre nem tudom hogyan kéne helyesen beállítani ezt a gépet, hogy például egy áramszünet után automatikusan bejelentkezzen rajta egy felhasználó és elinduljon a selenium szerver.
  
• Jó browser nincs, csak elég jó van. Valahogy a browserek, verziók, beállítások olyan sok hibalehetőséget jelentenek, hogy talán mintha nem is létezne univerzális megoldás. Az IE 7 + hta futtatás egyes gépeken nem megy (egyes gépeken az IE 7 sem például). Az IE 6 se sokkal jobb. Egyes pontokon mintha nem is ugyanazt csinálná, például nem hozza be a megfelelő oldalt. Nincs más kisérletezni kell. (A hta egyébként persze experimental állapotban van seleniumban)
  
• A browser problémákhoz képest a SSL problémák igazán semmiség volt, de rendet kellett tenni, ugyanis eddig nem volt rá motiváció, hogy korrekt https beállításokkal hajtsuk az apache-t.
  

sessionmeter

Tipikus eset, mint amikor a miliomost holtan találják a vitorlásán, Kolombó már onnantól kezdve csak az örökösével beszélget a filmben, mert tudja, hogy ő ölte meg. Ugyanez a helyzet a cluster teljesítménnyel is, az esetek nagyon magas százalékában a session a tettes. Ezt azért bizonyítani is kell általában, erről szokott szólni a hátralevő unalmas akárhány perc.
Gondoltam lerövidítem a következő bizonygatás hosszát és csináltam egy filtert, ami összediffeli a session-öd a kiszolgálás elötti és utáni állapotát.
Megjegyzések:

1. Nem túl processzor-barát, mert ahhoz hogy meg tudja saccolni, hogy változott-e a session attribútum, ki is kell szerializálnia. Ezt a container-ek másként csinálják, megjegyzik, amikor egy adatot elmentessz a session-be és akkor utána a teljes bean-t újra le kell majd replikálni a többi node-ra, csak ezt persze nem kötik az orrunkra. Régen tipikus hiba volt az, hogy valaki módosított egy session változót és aztán nem tette be a session-be újra. Ilyenkor az appszerver nem replikálta le, mert nem tudta hogy kell. 1 node-on elmegy, clusteren furcsa problémákat okoz.
   
2. Simán standard outra írja a kimenetet. Így csak 1 db jart kell bedobni a WEB-INF/lib alá.
3. Ami érdekes az egész kimenetből, az az hogy mennyi adat változott a session-ben, igazából az fogja a teljesítményt. Valami ilyesmit találtam ki neki, hogy minden attribútumra írja ki, az állapotát
   
   • NEW - a request kiszolgálása alatt jött létre,
     
   • DEL - azaz a request alatt a gondviselés megszabadított tőle
     
   • CHG - már megvolt, de változott
   • NOP - megvolt, de nem változott
     
   És persze az objektum kiszerializált méretét az egyszerűség kedvéért csak a kiszolgálás után, kivétel ha DEL persze.
4. Public domain, de igérd meg hogy soha nem felejted benne egy éles alkalmazásban! :-D
5. Még kitapasztalom és kitalálom hogy mi lenne mégjobb...
   

Forrás, konfig, bináris, satöbbi

.* meaning detection

Egyszer megkaptam egy cobol program forráskódját (első és utolsó eset azóta). Alighanem egy mérges vegyész írta, ugyanis a változónevek ilyenek voltak mint shit, fuck és így tovább... Egy ideig gondolkodhattam rajta hogy mi célt szolgálhatnak a változók mire sikerült működésre bírnom a cuccot. Ilyesmivel gondolom mindenki találkozott már. Körülbelül minden környezetben, programozási nyelvben, satöbbin létezik valamilyen konvenció, ami alapján létjogosultságot kap egy osztály, abban egy metódus, a metódusban paraméterek, változók, és a nevét is többé kevésbé meghatározza. Szerencsére ezzel mi nagyjából rendben is vagyunk.
Viszont arra gondoltam, hogy a legalább ennyire fontos lenne a magasabb szerveződési szintekre is érvényesíteni valami konvenciót és a csapatokat, projecteket, szoftvereket satöbbit kicsit kevésbé nagyzó, de sokkal inkább sokatmondó nevekkel kellene ellátni, hogy az embernek a csapat/project nevéből felderengjen hogy körül belül mi is az egész célja. Ezzel a dologgal elég csúnyán állunk :-(

SWT

Éppen mostanában átfutok egy SWT könyvet, hogy kicsit rendbetegyem a fejemben ami eddig az SWT-vel kapcsolatban bele került innen-onnan. Pár dolog, ami első nekifutásra nem tetszik...

• Az SWT konstans interface. Kusza mindenfélék halmaza. Widgetek attribútumai, eventek nevei, minden. Tudom, hogy a java 1.5 elött nincs enum, de akkor is szét lehetett volna robbantani pár kissebb osztályra. Használhatóbb lenne.
  
• A checkSubclass() metódus mindenképpen érdekes módja az örökldésen való akadékoskodásnak.
  

Kiváncsi vagyok mikor dobják el az 1.4-es java stílust és építenek kicsit más felületet.

A közösséggé vállás rögös útjai

A korábbi postban a sonarral kapcsolatban írtam, hogy esetleg egy vitafórumban a fejlesztőcsapat megtárgyalhatja, hogy milyen ellenőrzéseket tart fontosnak. Nos, konkrétan ezt ki is próbáltam, és várnom kellett egy alkalomra, mert elég sok munkánk volt. Mire demohoz értünk, volt már bőven statissztika a sonar adatbázisában a szűkebb csapatom projecteiből. Pár tapasztalat némi emésztés után:

• Az érdeklődés mértéke résztvevőnként elég változatos volt, de jóval 50 százalék alatt, ha lehet így pontozni. Azt hiszem jórészt nem rettenetesen elvetemült java kóderekkel dolgozok együtt mostanában.
• Tök jó lenne egy pozitív és egy negatív példa minden ellenőrzési pontra, csak hogy gyorsabban és kevesebb agymunkával lehessen választani.
• Igazából jó koncepciónak tartom hogy a szabály lehet kötelező, opcionális, vagy figyelmen kívül hagyott, de lehet hogy ez is sokat bonyolít a döntésen.
  
• 300 ellenőrzés nyilvánvalóan túl sok ahhoz, hogy egyszerre végignézzük és mindre szavazzunk, úgyhogy kb 20 %-nál félbehagytuk (tartok tőle elég sok időre, legalábbis érdemes átgondolni hogy ezt így érdemes-e erőltetnem)

Ha hazaérek és még lesznek működő agysejteim, ide fogom vágni Vonnegut ide vonatkozó bejegyzéseit, mert attól műveltnek látszom majd. Tessék:

[...] Félrevezeti az embereket, ha folyton-folyvást óriási sikerekről olvasnak, mivel tapasztalataim szerint még a középosztálybeli és felsőközéposztálybeli fehérek esetében is a kudarc az általános. [...]

Napfogyatkozás

Azt hiszem az ganymede usage data feltöltésre reflexből a legtöbb ember nemet kattint, viszont azok akik bekapcsolják, azok hasznos statisztikai infókkal látják el az eclipse alapítványt. Mellesleg ez publikus is, így megtudhatjuk mit használunk a legtöbbet az Eclipse-ből. Érdekes átnézni, nem meglepő módon a debug parancsok és nézetek igen előkelő helyezést értek el, viszont eléggé ott van a JEE perspektíva is.

JRemoting

Felfedeztem egy nagyon szimpatikus kis RPC csomagot JRemoting néven. Nem kell foglalkozni a RemoteException-bal, ugyanazon az interface-n át látjuk a remote objektumokat mint a lokálisakat (például ez az egyik dolog, amiért nem rajongok az EJB-ért) és cserélhető a transport protokol (mondjuk itt biztosan érdemes kisérletezni).

jhacks outage

Attila épp most szólt hogy a JHacks ~wiki átköltözik új gépre. Új vas, új kernel, új tomi, új postgres... Szóval ma estétől kezdve lehetséges hogy nem fogjátok tudni elérni és valószinűleg a holnapi napon visszatér.

Getter/setter kontra constructor dependency injection

Teljesen esztétikai dolog, de szerintem kb úgy lenne a dolog handy -ha már keverjük a dependency injection típusokat-, hogy konstruktor dependency injectionnal azokat a dolgokat setteljük be egy POJO-nak, ami nélkül semmi értelme nincs és nem tud futni, aztán azokat a dolgokat, amik opcionálisak (azaz futhat úgy is a dolog, hogy az értéke null) vagy van alapértelmezett értékük, azokat getter/setter cuccon keresztül.
Így amit sikerült létrehozni, annak már működnie is kell. Ha mégsem műxik, az vagy egy dependency miatt van, vagy azért mert nem teszteltük...

Sonar update

Kipróbáltam a sonar 1.4RC1 verzióját. Érdemes, mert végre kijavították valamelyik dependency dependency-jében azt a hibát, ami miatt kiakadt a metódusokon belülre tett annotációkon. Nem túl divatos dolog egyébként annotációt tenni a metódusokon belülre, többnyire @SuppressWarnings, aminek nincs különösebb jelentősége. Nekünk van ilyen is :-)

Mindenesetre most ezzel a javítással úgy tűnik lassan bevethetővé válik a dolog. Nem kell hozzá közben kismillió build definícióba beledolgozni a forráskód-ellenőrző éppen aktuális verziójának jar filejait, XML konfigurációját és még a build.xml-be is belegyúrni valamit, hanem csak egy elegáns webes felületen bekattintgatni és felparaméterezni a ellenőrzéseket. Söt, az egész szabályrendszer konfigurálását talán akár egy olyan kis session-ön is meg lehet csinálni közösen az érintettekkel, mint Tvik java 1.7 vitafóruma a JUM-on. Persze ennek biztosan van felső korlátja, például az amerikai barátaink imádják a hungarian notation-t (ami például a How to write unmaintainable code című írásban is szerepel), velük közösen például esélytelen lenne akármiben megegyezni. Ha szűkebb csapaton belül sikerül valami közös megegyezést kihozni, akkor a sonar riportjain keresztül láthatóvá válnak a kódunk szépséghibái és egyszer csak érezni fogunk valami motivációt hogy rendet tartsunk. Remélem...

Flash kereső ?= RIA kereső

Mostanában nagy hírverést kapott, hogy a Google és a Yahoo az Adobe együtműködésével megtanulja indexelni a flash tartalmakat is. Egyrészt vidámság, mert előrelépés, viszont nem hiszem hogy ez olyan nagy dolog lenne. A "web 1.0" webappokban a tartalom belegenerálódik a kimeneti html-be, a keresőmotorok tulajdonképpen még mindig dokumentumokat indexelnek, még ha azok dinamikusan generált cuccok is. A RIA cuccokban viszont a dokumentum kb üres, a kliensen futó scriptek hozzák le a szerver oldalról. Erről már nem szólt a hírverés, de ezeket gondolom nem fogják belevenni az eredménybe, mert Gipsz Jakab scriptjeit nem akarják futtatni a szerver oldalon, soha nem akarták.
Gyanús, hogy a lényeg így egyelőre kimarad...

Vagy generál valaki tartalmat flash kimenetbe?

IDE + csapatmunka

Nézegettem ma az ECF dolgait. Erre épül a cola, amiről a tréfás kis videó készült. Önmagában az ECF talán csak annyit tud mint egy instant messenger. XMPP, MSN, IRC protokolok, esetleg extra, hogy a saját szerverén keresztül tud screenshotokat küldözgetni, browsert meg view-kat indítani. Lassan feljönnek majd a rá épülő pluginok és valószinűleg lesznek érdekes dolgok köztük.

Nem tudom, hogy a piac mennyire mozdul rá az IDE-be ágyazott csapatmunka support témára, de lassanként a gyártók belelendülnek.

Megnéztem hogy mennyire free most a jazz.net. 1200 dolcsi fejenként :-) hát... a béta mindenesetre olcsóbb volt. Remélem a TEAM project hamar hoz valami használhatót ingyen, mert ez az ár teljesen esélytelen.

Off: lassan rendbejön a jobb vállam, ezt már félig jobb kézzel írtam, úgyhogy újra nekikezdek valami kalapálgatásnak hamarosan.

Eclipse Demo Camp log

Tegnap mindannyiunk legnagyobb örömére kijött az eclipse 3.4, amit ma Eclipse DemoCamp-pel ünnepeltünk meg. Én csak az első 3 prezentáción voltam bent, sajnos a hőmérséklet kint legalább 5 fokkal alacsonyabb volt mint bent, és nem volt mindegy az az 5 fok. Lássuk...

1. Bardy Szabolcs - Application model visualization using Eclipse GEF
   Nekem ez segített kicsit fellebbenteni a ködöt, ami az eclipse belső plugin rendszereit fedi. Magamfajta tucatprogramozókat nem érdekli az IDE infrastruktúrája, egész addig amíg valami lehetőséget nem látnak benne. Most már látok :) Volt demó is, ilyesmi. Kicsit az időben talán elcsúszott olyan dolgokon mint az MVC magyarázat, szerintem nincs ember aki nem tudná mi az.
   
2. Szentiványi Gábor - Advances in TEAM
   
   Azzal az alcímmel, hogy hogyan fűzzük szorosabbra a földrajzilag elosztott fejlesztőcsapatunk kommunikációját. Ismerős probléma, aki ezt megoldaná nekem, az megcsinálná a munkám felét :-) Ez valami olyasmi lesz, mint az IBM jazz cucca. Eddig a jó hírek. Rossz hír, hogy a fejlesztés még csak most kezdődget, a weboldal például totálisan semmitmondó és volt itt valami kanyar a .net-tel és a visual studioval.
   
   Azt hiszem az IBM jazz már ingyér van, érdemes talán azzal kezdeni ismerkedni. Az IBM szoftverektől ments meg uram minket.
3. Szántó Iván - Introduction to JBoss tools
   A JBoss eclipse-alapú fejlesztőkörnyezete. Régebben próbálgattam, a hibernate tools csodajó, de mióta JPA-t használunk már az sem rulz, a többi pedig szerintem csupa olyan dolog volt, ami benne van egy mezei eclipse-ben is. (Az "Eclipse for JEE developers" dologban). Viszont láttunk valamit a JBoss Seam-ból, ami első ránézésre handy kis RAD, szép IDE support is volt, viszont azok után hogy Iván cetliről átmásolt egy URL-t egy ajaxos komponensben valahova, nem biztos hogy bele mernék vágni. Nincsenek ilyen varázscetlieim :(
   

Továbbá megtudtam azt, hogy van aki kipróbálta a flexclipse-t :-) Köszi minden visszajelzésért mindenkinek, nagyon örültem, és amint normálisan rendbejön a jobb kezem és a közérzetem, folytatom a hegesztést.
Találkoztam eclipse gurukkal egészen nagy mennyiségben, például egy srác mesélt egy ötletéről amin dolgozik: egy pluginnal méri az időt, amit a kódod bizonyos részein töltöttél, és az alapján logol. Egész hasznos lehet ebből valamilyen riportot csinálni.

Holnap valószinűleg kicsit hittérítek WTP ügyben céges keretek között. Mi még mindig ant-tal buildelünk, a turnaruond nálam úgy 3 perc. Ezen szeretnék kicsit javítani. Például 3 másodperccel kibékülnék.

Ja és köszi a B2I srácoknak a szervezést, nagyon jó volt. Remélem legközelebb is lesz.

Az ördög bal keze

Mostanában kicsit csend volt itt, elég sok meló van mostanában és -mint az közismert- vizsgaidőszak, az meg ultra-aljas egy dolog.

A flexclipse pluginnel kalapáltam kicsit szabadidőmben.
Elmesélem:

1. Ami volt editor benne, azt az eclipse egy varázslója generálta. Első pillanattól biztos volt hogy ki fogom vágni, és ezt meg is tettem. Lecseréltem a WTP XML editorára. Ennek a pluginnak lehet bizonyos konfigurációt is passzolni.
2. Például Hyperlink támogatás, code completion support, quickfix és quick assist.
3. Vannak viszont a téren érdekes dolgok, például nem publikus apiba kell belenyúlni.
4. Egyébként: megcsináltam a libraries támogatást, lehet majd swc library-kat belinkelni.
5. Arra rásejtettem, hogy az eclipse önmagában is hatalmas API halmaz. Legalább olyan komplex mint pl a JEE.
   

Most elhúzok dokihoz, a vicc kedvéért ő fogja megmondani hogy most mi legyen a műsor. Ugyanis tegnap elütött egy barom, elég rondán megzúzta a vállamat. Lehet hogy egy ideig nem dolgozhatok, elég szar így bal kézzel. Viszont egy csomó időm lesz, mivel most sportolni se tudok járni. Olvashatok valamit például...

Sötét felhők

Mostanában a dzone-n, a TSS-en és a javaforumon is, mindenki a java fejlesztésekkel kapcsolatos fájdalmairól beszél. Egyrészt sokan új dolgokat akar beleerőltetni a nyelvbe, másrészt pedig pedig a fejlesztési menet rettenetes dolgaira rázzák az öklüket.

Magánvélemény, észrevétel:

• A problémák, amikkel foglalkozok nap mint nap, csak nagyon nagyon kicsi részben származnak a nyelv és a futási környezet hibáiból vagy korlátaiból. Tipikusan viszont nagyon sok alkalmazás build és deployment procedúrája olyan lassú, hogy egyszerűen alkalmatlan produktív fejlesztésre.
• Érdekes, hogy amíg nem volt GPL a Sun JDK, addig sokkal kevesebb kritika érte a nyelvet.
  

Olvasgattam egy könyvet erről God Wants You Dead címmel (tréfás a címe, a borítója meg főleg), ami ír egy pár érdekes példáról azzal kapcsolatban, hogy a összetett ötletekkel (10 parancsolat, adófizetés, java programozás) kapcsolatban az ember hihetetlenül gyakran követi el azt a hibát, hogy egy csomagban fogadja el vagy utasítja el őket. Pont ugyanez van a java-val kapcsolatban. Össze lehet állítani olyan fejlesztőkörnyezetet, komponenseket, satöbbi, amivel produktívan lehet dolgozni java-ban is. Ingyen, természetesen. Ha valakinek ilyen problémái vannak, szerintem érdemes körülnéznie ebben a témában. Főleg kommunikációs kihívás az egész, valahogy meg kell győzni a munkatársakat az új dolgok előnyeiről.

payware

Melóban olyan continuous integration szerverünk van, ami különböző gépekre telepített agentekkel buildel. Konkrétan teamcity, főleg a perverzió kezelő rendszerünk miatt lett ilyenünk, más nem nagyon akar vele együtműködni, meg persze mert csodaszép felülete van, mindenki szereti.
Mindenesetre van egy Web Service backenddel kommunikáló bean-ünk is (ja, majdnem mind az :-D), amit persze a többivel együtt letesztel. Minden megy mint a zsírozott villám.
Este fél hétig legalábbis, amikor már igazán mennék hazafelé, ha nem lenne a telefon a fülemre tapadva és nem villogna a desktopomon egy piros ikon hogy hibás a build. Hmm, mi baja lehet... Connection reset by peer. Lefuttatom a junit teszteket a saját gépemen, green line of happyness. Belenézek a szerver logokba hogy mi történik, és ekkor derül ki, hogy mivel ez egy ősi weblogic 8, ami csak 5 IP címről enged kapcsolódni a szerverhez (ezt valami memóriában tárolt listában tartja, szóval a restart reseteli a listát). Egy idő után mind a teszt szerver instance-ok (cluster, úgyhogy 2 IP), a build agentek (2 build agent, 2 IP), és a fejlesztők IP címei is bekerültek, onnantól meg a weblogic megtagadta a munkát mindenki másnak. Ennyit a per seat licenszes dolgokról, ezek a srácok arra pazarolták az idejüket, hogy az én időmet pazarolják.
Megoldás: Gyorsan bekonfigoltam egy apache httpd mögé. Mondjuk a mod_wl nem tud egynél több weblogic szervert használni, valahogy a WeblogicHost direktíva csak szerverre globálisan akar működni. Nem tudom miért, nem nagy feladat megoldani egy httpd modulban hogy VirtualHost-ban vagy Locale-ben is menjen.

A licenszelős dolgokkal mindig ez a baj, kifutunk a licenszből és akkor használhatatlanná válik, hazudozik, sztrájkol, ilyesmi. És még alapból is gyérek általában.

JUM hogyistovább

Na, szóval a következőképpen zajlott a JUM "szervezői" gyűlése. Összefutottunk a Moszkva téren abban a kis kertes kocsmában, első körben mindenki elmondta hogy mi az amin változtatna.
Ahogy nekem leszűrődött a nagy összhang, mindenkinek kb ugyanaz volt, ami szúrta a szemét.

• Kicsit elkanyarodtunk az eredeti JUM ötlettől.
  
• Lassú, döcögős, néha minden ok nélkül várunk
• Néha összeszedetlen, néha nem tudjuk hogy ki következik, egyáltalán mi is lesz műsoron.
• Karenin felvetette hogy a honlap nem túl fullos, szerintem ez nem olyan nagy baj.
• Viszont hogy nincs online verzió, az némileg nagyobb probléma
• Az, hogy utólag szedegetjük össze az előadók blogjaiból a prezentációkat, na az is lehetne jobb.
• Szintén Karenintől: nincs név konvenció. JUM versus Java Paláver. A domain JUM, de mindenki másként hívja. Én szeretem a TLA-compliant dolgokat :-)
  

A következő megoldások körvonalazódtak a formára vontakozólag:

• Lesz hoppmester. A személye mindig változik, nehogy megutáljuk. :-) Mindenesetre ő fogja lökdösni az előadókat. Időkeret lesz, de nem volt szó stabil méretről. Majd a téma eldönti. Ennek a pontos hogyanait és mikéntjeit még azért le kellene tisztázni szerintem.
  
• Az előadás anyagát (prezentáció, kód) előre be kell küldeni majd. Egy héttel a JUM elött ebből leszűrődik hogy miről lesz téma. Kérdés: ki fogja leszűrni és pontosan mi alapján?
• Online verzióra pl a ustream.tv
  
• Jobb marketing (logo?)

Tartalom újítások:

• Több részvevői interakció. Lehet minden JUM-on lesz vitázós rész.
• Hazai projectek fejlesztőit meghívnánk
  
• Céges emberek meghívása, például az IBM-es srác előadása nagyon pöpec volt. Motiváció a cégeknek: lehetőség a technológiáik bemutatására, embertoborzásra, kis ismerkedés, ilyenek. Persze marketing nem jöhet szóba. Szakmai tartalom, BS nélkül. Ezért is jó lesz, ha be kell dobni előre az előadás anyagát.
  

Szóval az önszerveződést felváltja egy minimális kontrol, továbbra is bárki jöhet elmondani hogy mivel foglalkozik, végighalgathatja az előadásokat, és továbbra is totál ingyen. Ne igyál higítottsört se a büfében érte, tényleg ingyen van :-)
Ja és hogy mikortól lesz ez? Nyáron talán valószinűtlen, kora ősszel inkáb. Addig szerintem még elég sok dolgot le kellene tisztázni, de -most még- bőven van időnk. Megcsináljuk, aztán meglátjuk. Majd addig talán hoppmesterkedek és kérdezősködök hogy mi hogy megy, csak hogy el ne felejtődjön a lista :-)

Ennyi jutott eszembe így egy héttel utána. Írtam jegyzetet is persze, csak bent hagytam a fiókomban. Úgy a hasznos ám...

Flexclipse update site

Eszembe jutott, hogy van egy szerver accountom még valahol Ámerikában, úgyhogy gyorsan reggel feldobtam rá a flexclipse update site-ot. És itt van:

http://ghoul.fastcrypt.com/~lazlo/flexclipse-update-site/

Az URL egyébként remek példája annak amit mondtam JUM-on a Flex vs Openlackó ügyében. Azaz hogy ezt a László nevet nem igazán tudják leírni külföldiek.

JUM gondol gondol gondol

Ma este JUM megbeszélés. Én akkor összeírnám hogy én milyen problémákat látok. Magánvélemény rovat. (viszonylag sok rendezetlen gondolat következik)

1. Általában nem pörgősek a prezentációk. Szerintem ez az iskolai élményeinkből jön. Unalmas egyetemi előadások, ahol bejött valaki és ledarált valamit. Szerintem ez inkáb időigényes mint hasznos. Majdnem mint egy egyetem. A tartalma viszont jó volt az előadásoknak, meg a felkészültséggel se volt baj, csak cammogós lett.
   
2. Néha nincs elég előadó. Lehet, hogy elöbb össze kellene gyűjteni a témát, aztán kellene időpontot kitűzni. A másik orvosság talán ha többen jönnének egy-egy apró témával. Ezt csináltam az elmúlt egy hónapban, ilyen csúnyaságok voltak benne, így oldottam meg, és az egészből a tapasztalat az hogy.
3. Szerintem az is jó lenne, ha minden prezi és a hozzá tartozó kód fent lenne egy helyen. Hát a JHacks-on elkezdtem... Na majd ezen még rugdosok.
   
4. Önszerveződésből következik hogy nincs házmester. Sajnos mégis lehet kellene valaki aki bevállalja néha a mumus szerepét és megmondja hogy akkor most letellett, az 5 perc szünet, a 30 percen túllépett az előadás, ilyesmi. És akkor este 10 elött hazaérünk, vagy több infót tudtunk bepakolni.
   
5. Tök jó lenne ha a meg neten lehetne nézni azt, amiről lemaradtunk. Ezt nem nehéz megoldani, Karenin említett is pár megoldást. Akkor már csak egy 3000 forintos webkamera kell és egy 2000 forintos mikrofon, gondolom mindenkinek van otthon ilyen, sávszélesség is akad.
6. Természetesen szükséges szocializálódni a lehetséges leendő, jelenlegi és volt munkatársakkal, csak közben ezt úgy kellene csinálni, hogy idegenek idejét ne pazaroljuk. Na itt most egyrészt magamra gondolok, mert közelebbről egyik aktív résztvevőt sem ismerem (annak ellenére hogy mindenkinek olvasom a java blogját akinek tudom hol van), de ha jön közénk bárki aki nem spanunk, akkor ugyanezt látja szerintem. A kocsmázós formációban egyrész ezért nem vagyok benne, meg persze bagószagúan sem akarok hazamenni.
   
7. Néha nem elég összeszedett az előadó. Ez konkrétan magammal kapcsolatban. Mondjuk ezen nem lehet mit rúgni, többet kell készülni, meg gyakorlat teszi. Néha nagyon gyorsan akarok valamit elmondani és nem veszem észre hogy senki nem érti. Na erre kellene például egy protokol, hogy ilyenkor vág egy arcot vagy beszól, megdobál...
   

Körbenéztem a wikipédián a konferencia és antikonferencia stílusok között, csak hogy valamennyire képbe kerüljek. (Mert persze én sem voltam még semmi ilyesmin, én is itt lakok tanyán, Butapesten.)

• Lighning Talk, leginkább ilyesmit próbáltam megvalósítani. Megvannak persze a korlátai. Mondjuk olyan nagy és különleges dolgokkal nem is foglalkozom, amire rá kellene fordítani hosszabb időt. Tucatprogramozó vagyok, ilyen terem minden fán.
• Az OST-ből ajánlanám az alapelveket: akárki jön, akármeddig tart, annak úgy kellett lennie. Mondjuk hogy mikor kezdődik az azért talán mégsem mind1, térjünk a tárgyra és aztán mindenki menjen a dolgára.
  

Remélem hogy valami új és jó dolog sül ki az esti megbeszélésből. Talán egy olyan dolgot ki lehetne hozni, ami folyamatosan a felszinre került újdonságokat segít feldolgozni, ezekkel kapcsolatos ötleteket kicserélni.

Update
Végülis jó hangulatban és elég konstruktívan tellett a megbeszélés. Én nagyon pozitív eredményt várok attól, ha végigcsináljuk azt amit megbeszéltünk.

Hétfő. Azaz kedd...

A hétvégi C++ agyeldobás közben tartottam egy kis szünetet és helyreráztam a flexclipse-ben a pluginek közti függőséget. Happy utalt rá hogy nem lesz egyszerű menet. Nem volt az :) sok helyen el lehet szúrni a dolgot. Még mielött elszúrnám valami új dolog kiépítésével, betageltem 0.1.4 verzióval. A 0.1.5 már túl lesz a belső átalakításokon és lesz hozzá update site. Aztán végre lendítek valamit a funkcionalításon. Hétfőn már ennek nem láttam neki, 7 nap gányolás (munkahelyi ganajazás és ELTE-féle C++) után a legkevesebb kedvem sem volt a szabadnapot gép elött tölteni. OKT, Börzsöny...

Egyébként, ajánlom mindenkinek ezt a kis jME izelítőt, amiben Pali gorillái is ott feszítenek :)

Retrós

Évente egyszer meg kell tanulnom C++-ban gányolni (értsd: egyetemi szinvonalon programozni). Valahogy minden évben összebénázok magamnak valami ilyen tárgyat. A dologban az a vicc, hogy utána minden évben el is felejtem :-) Úgyhogy most szedegetem elő a dolgokat 7 évvel ezelöttről, akkor programoztam aktívan C++-ban. A régi rossz idők...
Néhány élmény:

• Rettenetes reference-k után pointerekkel dolgozni. Nem annyira a garbage collector hiánya miatt, hanem mert állandóan azon kell gondolkodni, hogy amit most nézek az az objektum vagy egy pointer az objektumra. Ezzel kapcsolatban volt egy java.net-es poll.
  
• A GCC hibaüzenetei gyakran elég félrevezetőek.
• A namespace-k használata a java packagek után, hát nem túl barátságos.
  
• Az IDE support jelképes. A Kdevelop szép, de a syntax highlighting-on kívül nem sokat tud adni a forráskód szerkesztéséhez, azt meg a VIM úgyis jobban tudja :-) Az eclipse C++ pluginja ezen a téren valamivel jobb, de sehol sincs a java pluginhoz képest.
  Végül visszatértem a régi jó vim + bash + make környezethez, az legaláb stabil.
• Azzal sikerült megtréfálni, hogy nem dob ArrayOutOfBoundsExceptiont-t amikor túlcímezek egy tömböt :), sőt végre is hajtja, csak valamivel később dob egy hátast. Persze nem kell túlcímezni, meg ő honnan is tudná hogy túl lett címezve, de azért az nem mókás, amikor az ember keresi hogy vajon eddig hol túrhattott el valamit a memóriában.
  
• A fordítási direktívák kivállóan alkalmasak az olvasó megtvesztésére :) remélem ilyen nem lesz soha java-ban.
  
• Végülis én azért tértem át régen C++-ról java-ra, mert tetszett az, hogy mindenhez van szabványos API. JDBC, servlet, swing gui, ilyesmi...
  
• A makefileok még egyszerűek, azt mindig is szerettem, de a gnu automake, autoconf, auto.* + m4 makrók káosza nálam mindig lerúgja a szíjjat. Ant, maven, és bármilyen java-ra írt build eszköz ehhez képest havaj.
  

Szóval kicsit olyan érzés az egész, mint újra felvenni a tegnapi zoknit.

Flexclipse 0.1.3 - araszolós

Remélem jól tellett a hétvégétek, az enyém egész sűrű volt. Nem volt sokmindenre időm, de azt sikerült beledobni a flexclipse-be hogy egy saját file-ba dobálja be a konfigurációját. Eddig a project metaadatokat használtam erre. A project metaadatokat az eclipse a workspace-ben, de a project directory-n kívül tartja (a .metadata könyvtár, gondolom ismerős :) ) Most ez azért jobb, mert verziókezelőben meg lehet osztani, esetleg lehet generálni mondjuk maven pomból. Fel is tettem egy gyors howto-t az egész cuccról. Simán látszik belőle mennyire kezdetleges az egész :)

Most erről a verziókontrol dologról eszembe jutott hogy holnap reggel megint egy perverz verziókövetőt kell rugdalnom. Minden héten háború.

Update: Közben Happy kijavította egy elvetemült dolgomat a kódban, azaz megvan az első contributor :-) mégfontosabb hogy sok hasznos tanácsot kaptam. Hétközben remélem akadgat majd időm javítani a cucc kinézetét, és akkor lesz update site...

Flexclipse 0.1.2 @ googlecode

A flexclipse kódját átmozgattam az otthoni svn-ből a googlecode-ra, és megvan az első tag (0.1.2) is azóta. Ha akad időm ma este, össze ütök egy kis howto-t hozzá. Azok vannak benne amiket eddig felsoroltam, még estére talán ad valami támogatást a skinezéshez (CSS) is.

Meg keresek még helyet update site-nak...

Flexclipse még mindig...

Tegnap este még maradt időm két dologra a Flexclipse prototype projectben:

1. Belerúgtam egyet a project icon decoratorba. Most a flex projecteken gyönyörű (soha ilyen szépet nem rajzoltam) ikon ragyog.
2. Összekötöttem a flex compiler progressmonitorát az eclipse progressmonitorával. Hát értelmes eredményt nem sikerült ezen a téren látni, még utánna kell nézzek hogy vajon jó hívásokat küldök az eclipse felé.

Ennyi ami késznek mondható most. További félkészületek:

1. Átbogarásztam az ASDT-t és próbáltam kitalálni hogy hogyan tudok belőle kiszedni valami hasznosat.
2. Megcsináltam az Outline adaptert a ASDT-hez, legalábbis a dummy implementációt. Most frankón nem látszik az egészben semmi.
3. Elkezdtam utánnanézni az XML editornak. Alapvetően ez az egész csak XML, az lenne frankó, ha egy XML editor kiterjesztésével tudnám az egészet hajtani.
4. Leszedtem a spring IDE forráskódját, hátha abból megvilágosulok az XML editorokkal kapcsolatban. A spring IDE tényleg frankó módon tudja editálni a context XML-eket. Van benne code completion is, hiba highlight, szóval a lehető legjobb dolog ihlet beszerzésére.

Ennyi. Ezek még lassan befutnak, aztán meglátjuk...

Flexclipse helyzet

Nagyon elment az idő sajnos minden mással, de most sikerült egy kicsit összeszednem annyi szabadidőt, hogy kicsit kipofoztam pár hibát a Flex 3 eclipse pluginben (amit időközben elneveztem Flexclipse-nek).
Átkalapáltam a compiler api hívásait, így egy tetszőleges file módsítása után kb 1 - 5 másodperc alatt generálódik ki a SWF. Hmm, hát közelébe sem ér sajnos a java compiler sebességének, de nem annyira sok mint mavennel lefordítani. Most már a hibák is korrekt helyen jelennek meg a fileokon és persze a Problems nézetben is.

Most az jön ezen a szálon, hogy az elhagyott ASDT-ből kiguberált kódot beleépítem, és akkor a mx:Script tageken belül lesz actionscript szinezés és code completion.
Szükség lesz majd idővel egy libraries properties oldalra is, ahol be lehet kattintani a SWC függőségeket.
Meg ki kellene kutatnom azt is hogy milyen formában lehetne publikálni a meglévő kódot.

Ezek a TODO listák olyanok sajnos, hogy csak nyúlnak, mint a régi jó "elszánt vércsiga vs gonosz manó" analízispéldában a kötél. Inkáb taszkot váltok, hátha úgy elmúlik.

BeanPostProcessor reggelire

Reggel kicsit fájt a torkom meg álmos is voltam, ezért a szokásos edzés helyett megírtam a JNDI-s beanpostprocessor ötletemet amit egy múltheti postomban felvázoltam.
Ki is tettem a forrást és a jar filet a JHacks.hu-ra, ide írok egy használati útmutatót is. Elég rövid lesz :) Nagyon kicsi az egész, alig pár sor és még különösebben tesztelve sem volt, a unit tesztet leszámítva.

Most ezen a szálon az következik hogy kipróbálom pár alkalmazás szerverrel, hogy mennyire handy valójában ezt kezelni, beleintegrálom pár webappomba, aztán meglátjuk.

Paypal takarítás

Pár hete eszembejutott, hogy megszabadulhatnék a paypal accountomtól, nem vagyok az a vásárolgatós típus, főleg nem ha American Express kártya áll az egész mögött. Szóval bejelentkeztem PayPal-ékhoz és az account törlésre olyan felszólításokat kaptam, hogy elöbb küldjem el nekik a közüzemi számláim és az útlevelem másolatát. Csak aztán lehet lezárni az accot. Kifejezetten nem akartam ilyesmit csinálni.
Boszankodtam rajta, de ezekkel a dolgokkal már nem akartam terelni amúgy sem túl felhőtlen kapcsolatomat a céggel, ideiglenesen ennyiben hagytam, míg ma reggel ezt kaptam tőlük:

Dear Ügyfelünk,

As part of our security measures, we regularly screen activity in the PayPal system. We recently contacted you after noticing an issue on your account.

We requested information from you for the following reason:

Our system detected unusual charges to a credit card linked to your PayPal account.

Case ID Number: PP-123-456-789

This is a reminder to log in to PayPal as soon as possible.

Be sure to log in securely by opening a new browser window and typing the PayPal URL. Once you log in, you will be provided with steps to restore your account access. We appreciate your understanding as we work to ensure account safety.

In accordance with PayPal's User Agreement, your account access will remain limited until the issue has been resolved. Unfortunately, if access to your account remains limited for an extended period of time, it may result in further limitations or eventual account closure. We encourage you to log in to your PayPal account as soon as possible to help avoid this.

To review your account and some or all of the information that PayPal used to make its decision to limit your account access, please visit the Resolution Center. If, after reviewing your account information, you seek further clarification regarding your account access, please contact PayPal by visiting the Help Center and clicking "Contact Us".

We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account. We apologize for any inconvenience.

Sincerely,
PayPal Account Review Department

unusual charges: Ez alatt valószinűleg azt kell érteni, hogy teszteltük egy csomót a cuccot a live rendszeren és a pénzt visszautaltattam magamnak. Többnyire 10 eurocent körüli összegeket, néhány nagyobb.
account closure: Yes, please do it right NOW!

Javaslat: soha ne regisztrálj Paypal-hoz a saját neveddel! Legyen szépen céges, fájjon miatta más feje :-)

Ötlés a konfiguráció hovatevéséről

Az jutott eszembe, hogy a spring appcontexteinkhez írhatnánk egy olyan BeanFactoryPostProcessort, ami végigmászna az összes bean definíciónkon, és mondjuk valamilyen módszerrel összeállított JNDI resource névvel megpróbálná behelyettesíteni a bean-t, persze csak ha van olyan JNDI resource. Így bedobhatnánk akár teljes bean-eket is a konfigba, ugyanúgy mint egyenként property-ket. Kiadhatnánk az appcontext-et úgy, hogy egy Derby datasource van beleregisztrálva, és azt felülvágnánk egy JNDI DataSource-szal, a hibernate sessionben pedig a Dialect osztály nevét írnánk át, kész is a konfiguráció.

Ehhez persze le kell szoktatnunk arról a szerintem rémes szokásukról a library-jaink fejlesztőit hogy classpath-on lévő propertyfileból szedjék fel a konfigurációjukat.

Ez persze nem egy teljesen friss ötlet, csak ma vetettem fel elösször publikusan. Majd harcolok érte :-)

Az eclipse útvesztőiben

Nézzük, mi az ábra a flex3 eclipse tákolással...

• Nagyjából megy a builder, igaz nem inkrementális, de hát ez van egyelőre.
  
• Pár ikon-dekoráció megtalálta a helyét. Én rajzoltam az ikonokat, mind az eggyet. Esztétikára nem adunk.
  
• Van kettő wizard is, ebből csak az egyik működik :-D

Ami még minimálisan szükséges lenne a használhatósághoz:

• Maven-hez flex3 mojo. Csak flex2-es van jelenleg
• És persze rendesen gatyábarázni
  

Air on linux (Alpha) gyorsteszt

Van Air runtime linuxra is végre, az internet magamfajta, másodosztályú állampolgárainak örömére. Vasárnap fel is húztam az itthoni gépemre hogy megnézzem mit tud.

• A telepítőcsomag mérete tűrhető (16M)
• Alpha létére eddig még nem hasalt el egyszer sem
• Viszont szembetűnően zabálja a processzoridőt. Ezt windowson nem csinálta. Valószinűleg a friss fedorám valami csúnyát csinált a grafikus driverrel, mert más is izzad vele, azt hiszem különösebben ezzel nem lesz gebasz.
• Az határozottan nem tetszik hogy a saját és pedig a air csomagok felinstallálásához is root jelszót kér. Hát ideiglenesen megbíztam ennyire az Adobe-ban, de ebből nem csinálnék rendszert.
  

Lassan, ahogy akad időm kipróbálom hogy mennyire jó dolog rá alkalmazást írni.

Közben lökdöstem tovább a Flex nature implementációmat eclipse-hez, beleakadtam az első eclipse specifikus problémákba is, de azért haladgatok...

Miliméterekben mérhető haladás

...
Megáll akkor várván
Egy tektonikus mozgást
Ami megemeli őt is
...

• Otthon folytatgattam a kisérletezést a Flex+blazeds megoldásokkal. A data push-sal kapcsolatban keresgettem, hogy miért nem lehet megoldani a AMF subscribe-ot ugyanúgy mint a RemoteObject-eknél flex services configuration nélkül. Az adobe igazából egy eléggé összedrótozott megoldás egyik felét adja el ingyért, a másik eladásaiból akar jól megélni. Szerintem nem lesz így jó, de meglátjuk, addig megpróbálom megszelídíteni.
  
• Melóban rémeseket szívtam a Perforce-szal, az MS-SQL-lel és a projectünk beleerőltetésével a WTP-be. Egy sikeres lépés előre, két sikeres lépés hátra.
  

Eclipse WTP furcsaság

Mivel csak munkában használok ant-ot, eddig a maven megkímélt attól, hogy saját magamnak kelljen beállítani a WTP webalkalmazás projecteim másik projecten való függőségeivel járó .

• Első lépés: webalkalmazás magában, egyszerűen csak megy, könnyed és gyors, mellesleg ez az emberek túlnyomó részének meg is felel
• Második lépés: valami egyszerű project dependency, mondjuk egy Foo osztály statikus metódusát meghívni jsp-ből. Ez is megy, a Foo módosulásaira újradeployol az eclipse, frankó.
• Harmadik lépés: legyenek a utility projectben a jar-ok. Atomkatasztrófa. Hol a classpath-szal lesz baj, hol a deploymenttel.
  

Elég kiábrándító :( Na mondjuk olyan is a fejlesztési processzünk, hogy az embernek lenne kedve elmenni messzire birkákat legeltetni. Ant, vár, ant mégegyszer máshol, megint vár, aztán tomi újraindít mert nem sikerült felnyalnia a friss jarokat, megint vár, aztán böngészővel vakarászik mert persze állapotfüggő az egész.

• Alternatív harmadik lépés (gányolás szerintem), átmásolom a WEB-INF/lib könyvtába a utility project jar filejait. Ilyenkor megyeget a dolog az utolsó manuális lépés kivételével persze.
  

Heti helyzet

• Kijött a Sonar 1.2. Mostanában nagyon érdekel ez a szoftver és próbálom nyomni a munkahelyemen is. Sajnos maven-hez passzol igazán, ant-tal falábú, meg hát vannak neki egyéb korlátai is :( Viszont kezd nagyon jó cucc lenni, amikor a korlátok nem zavarnak.
  
• Egy kis Drools prototipus projectett tervezgetek. A melóban a kódunk legnagyobb része az üzleti döntési folyamat lekódolva, mint mindenkinek. Majdnem mindenkinek. Persze így is le lenne kódolva, csak legalább nem a flow logikában :)
• AMF data push-hoz kisérletezek valami általánisított megoldást, hogy körülbelül spring applicationContext-ben lehessen megmondani - interceptorral persze-, hogy melyik metódus hívása milyen csatornára küldjön update-t. Ezzel használhatjuk a primitív DAO osztályainkat tovább, amiket esetleg más projectekből vettünk át. Az adatok real-time replikálódnak DAO-t éppen használó a kliensekhez, annélkül hogy ehhez blazeds-specifikus kódot kellett volna belegyűrni a logikába. Na ennek is meglesznek a maga korlátai :)
  

JUM

JUM, 2008 március 19, BIX

Elsőként Sragli Attila beszélt a Java komponens architektúrákról. Nekem ez egy kicsit túl általános volt, semmit nem tudtam meg az OSGi-ről és a SCA-ról, csak hogy vannak ilyenek. Pedig érdekelne, mert hülyének érzem magam a témában.

Aztán én hordtam össze mindenfélét a Flex-ről, az OpenLaszlo-ról és a BlazeDS-ről azzal a kis prototype projecttel kapcsolatban amit feltettem a JHacks-ra, mellesleg itt van a prezentáció anyaga is. Fel akartam venni hogy visszahallgassam. Utálom a saját hangom, de legalább okultam volna belőle. Ez nem jött össze, az összes többi előadást sikerült felvennem, de a sajátomhoz a diktofonomat kellett használni pendrive-ként és sajnos egyszerre csak egy dolgot tud :-( Úgyhogy nem tudom mennyi gondolatot sikerült megmozgatnom és kit mennyire érdekelt, de szerintm belefértem a 10 percembe, úgyhogy nem raboltam sokat az emberek idejét. Nem vagyok biztos abban, hogy a quickie műfajt jól képviselem a JUM-on, de remélem, hogy lassan fejlődgetek benne :)

Sajnos a Appserver Deathmatch nem jött össze teljesen, a SUN-os srác eljött, az IBM-es lemondta, a JBoss-os vagy nagyon késett vagy valami ilyesmi, de nem tudtam megvárni :(
Ennek ellenére amit Karenin és a Sun-os srác mutatott a glassfish-ről az elég frankó volt. Az még igazából nagyon érdekelt volna, hogy sima command line-ból mennyire menő dolog bütykölni a glassfish-t és logging kürüli problémákat nem teljesen értettem, soha nem használtam a java logging apit, log4j vagy muszájból commons-log.

Talán az lenne jó, ha jórészt a rendezvény résztvevői adnák a konferencia tartalmát, legalábbis a vitafórum amit Tvik tartott egy JUM-on az szerintem teljesen feldobta a hangulatot. Csak akkor meg arra kell figyelni hogy ne legyen két ember párbeszéde az egész. Kicsit próbálom húzni a JUM-ot egy inkáb uncfonference találkozó felé. Mondjuk nem vagyok komoly tényező, de átgondolhatnánk hogy kicsit gördülékenyebben menjenek a dolgok. Amúgy mindenkinek otthon van a feleség-félesége, az aranyhalai, a fusimelója, stb, biztos a maxmális mennyiségű infot akarja megkapni a legrövidebb idő alatt.

Flash kommunikációja egy backenddel AMF protokolon

Csináltam egy flex 2.x-es projectet maven-nel, erről a melóhelyemen tartok majd beszámolót, de itthon haxoltam, úgyhogy nyugodtan nézzen bele akit érdekel. Összetargézézve 5K :)

Ez van benne, csak hogy összefoglaljam:

1. Spring inicializál egy POJO-t, ez a greetingDao. Tud egy pár köszönést, mint Hello World, ilyesmi...
2. A spring contextet a BlazeDs egy adaptere segítségével bemutatjuk a BlazeDS konfigjának. Ez idáig csupa móka.
3. Persze a web.xml-ben a BlazeDS egy szervlete be van regisztrálva, ez evidens...
4. Na viszont ott a másik project, a bp-flex, itt van a Flex forrás. Ez egy RemoteObject-kent mutat az 1. pontban említett POJO-ra.
5. Adtam távoli metódusonként 1 callback-et, hogy amikor visszajön az üzenet akkor meghívódjon és updatelődjön (imádom a hunglish nyelvet) a view.
6. Ez pedig persze Flex databinding-gel van odabetonozva, ha bárki fennakadna azon, hogy mi a túró az a [Bindable]
   

Mivel nagyon nem vagyok kliens oldali hegesztőművész, erről az utolsó 3 dologról a következő napokban még kérdezgetem azokat akiket viszont annak tartok :)

Ha akad még időm valamikor kiteszem a hasonlóan vaskos funkcionalítású Web Services (XFire) kommunikációval működö prototípust is.

Amitől continuous az integration

Egy continuous integration szerver -szerintem- ott válik el egy sima nightly build cucctól, hogy nem egyszerűen csak lebuildeli a cuccod, hanem a különböző modulokból amiket fejlesztessz, abból egy éppen aktuális verziót rak össze és azon futtajta a teszteket.
Két megvalósítás...
A teamcity-ben lehet manuálisan beállítni project függőségeket, a build végén az eredményt (a jart) beletolja az új projectbe és azzal is leteszteli azokat a projecteket amik ezen a projecten függenek. Ant projectek esetén ez egyszerűen csak nem lehet jobb. A maven projectek közti függőségeket TeamCity-vel még nem néztem meg, de manuálisan biztosan azt is be lehet állítani ugyanígy.
Na és akkor elmondanám a másik megoldást: Continuum + maven, a continuum a pom alapján felismeri a két project közti függőséget. Ez a rövidebb és egyszerűbb dolog :-) Ant esetén nem tudom mi van, de a saját fejlesztéseimben nem használok antot.

A TeamCity és a Continuum további lényeges különbsége, hogy a TeamCity webes felülete piszok jól néz ki, ezért a munkatársak jobban szeretik. A szép dolgokról könnyebb elhinni hogy hasznos.

A lélek fogaskerekei

Még a javapolison a kedvezményes könyvesboltban halásztam ki SOA, Web Services és Design Patterns könyvhegyek mögül Steve Tallbot Devices of the Soul című könyvét. Magyar nyelven sajnos nem jelent meg, a fenti cím pedig a saját fordításom.

Azt a téveszmét boncolgatja benne, hogy a techikai fejlődés jobbá teszi az életet. Van pár dolog benne amin lehetne vitatkozni az íróval, de összességében véve azt hiszem egy fontos problémát tárgyal érdekesen és részletesen. A könyv információi nem avulnak el párszáz éven belül ha csak ki nem hal az emberiség, ezért inkáb ilyet vettem. Gondolatébresztőnek ajánlom mindenkinek.
Az éppen aktuális buzzword technologies könyvet pedig elolvasom a céges safari accounton :)

Dolgok mostanában

Nem szeretnék senkit sem fárasztani azokkal a kalapálásokkal amikkel életben tartunk rendszereket a munkahelyünkön, mert az többnyire távolabb áll az ideálistól mint az otthoni hobbiprojektek. A web alkalmazások konfigurációja az viszont szerintem közös gebasz a két témában.
Néhány évvel ezelött repült fel nagyon az IoC biznisz, akkor még különcnek számítottam, hogy ilyeneket akartam, hogy ne a saját kódom (azaz én) bajlódjon a konfigurációjával hanem valaki egyszerűen csak adja neki oda. Azóta változott a helyzet, már annyira mainstream, hogy mindenki alapból bénának számít, aki nem használ valamilyen IoC rendszert.
Ezzel a komponensek írói eljutottak a kánaánba és ha nekem is csak ennyi lenne a dolgom, akkor nyugodtan hátradőlhetnék. Csakhogy mostanában a 'testing', 'staging' és 'live' deploymenteket is végig kell küzdjem, ráadásul nem csak a saját projecteimét és igazából nagyon nagy hiányérzetem van a folyamat bizonyos pontjaival kapcsolatban.
Például a spring applicationcontexnél tipikusan be szokás regisztrálni egy PropertyOverrideConfigurer objektumot, amivel már nem az applicationcontext-ben, hanem egy külső properties file-ban tarthatjuk az alkalmazáspéldányonként változó konfigurációs adatokat. Ilyeneket mint JDBC URL, web services backend URL, különböző path-ok... Ezek után ezt hova is tegyük? A legnépszerűbb hely hozzá a classpath.
Egy webapp esetében a classpath lehet a WEB-INF/classes, így tényleg csak erre a webappra vonatkozik az ami benne van és senki más nem is fog hozzáférni. Én ezt azért nem szeretem, mert szeretném úgy odaadni a webapp filet, hogy az egy war, tessék az előző war helyébe odatenni, és a műsor megy tovább.
A problémára megoldás lenne az, hogy a parent classloader alá dobjuk oda a konfigurációs file-t, ez viszont nem lehetséges abban a -ritka- esetben, amikor például ugyanazt a webalkalmazást szeretnénk több példányban más konfigokkal hajtani egy gépen. Az sokkal inkább fáj, hogy meg kell patchelni a futáskörnyezetet, ilyet sem szeretek csinálni.

Végigkérdeztem pár régi kollágát és mindenki a fenti kettő közül az egyikkel dolgozik.

Egy apró szépítés talán ilyesmi lehetne: a parent classloader alá tesszük a properties file-t, mégpedig a context nevével (remélhetőleg a virtual hostokkal nem lesz ütközés) és percek alatt lehet olyan PropertyOverrideConfigurer-t összedobni ami ez alapján keresi ki a properties file-t. Ezzel még közel sem oldottuk meg azt a problémát, hogy mi legyen azokkal a komponenseinkkel amik ragaszkodnak a saját property fileukhoz a classpath-on, de ez már tényleg szarból fellegvár lenne.

Viszont ez még mindig valami saját megoldás keresgetése. Nem kellene az általános problémára valami általános megoldásnak lennie? Vagy csak nekem nem elég jó az, ami van?

Szétnéztem, hogy mivel lehetne betömni ezt a rést. A JMX az talán az lenne, a springnek van is szép JMX supportja, ki lehet vele exportálni a saját MBean-jeinket, utánna pedig tetszőleges JMX felületen keresztül beállítgathatjuk a tulajdonságokat. Ez a startoláskor nem fogja felülírni a bean-ek tulajdonságait, futásidőben nem igazán szeretnénk rajta babrálni, lementeni sem fogja nekünk, szóval ezzel nem vagyunk közelebb.

Búcsú a junit 3-tól

Milyen teszt framework-öt használsz a saját projecteidben?

Volt egy ilyen szavazás is, köszi mindenkinek aki szavazott. Ezek lettek az eredmények:

Junit 3.x	0 (0%)
Junit 4.x	6 (50%)
TestNG	2 (16%)
Ufó-technológia	2 (16%)
Nem junit tesztelek	2 (16%)

Junit 4.x teljesen feljött a testNG-hez képest, pedig a testNG korábban startolt az annotációkkal. Azt hiszem ennyire számít hogy van-e valamihez eclipse support. Persze a testNG-hez is van, csak korántsem olyan frankó mint a junit-é.

A boldogság zöld csíkja.

Hírek

A hét jó híre: Karenin tolja a JHacks híreit, szóval a régi közösségi események mellé mennyiségi és minőségi technológiai híreket is kaphatunk. Ez alkalomból lecseréltem a régi nagy böszme RSS ikont két kisebb XML ikonra, ott jönnek a hírek és a tartalomváltozások RSS-ben.

A nap első jó híre: a maven régi, sokak szerint elszúrt (szerintem is) XML formátuma, amiben csak tag-ek vannak de nincsenek attribútumok... Na ez most úgy tűnik lassan elmúlik a fejlesztő blogja szerint. A 2.0.9-től kezdve. Ez mondjuk nem holnap lesz, de remélem hamarosan.

A nap második jó híre: ráakadtam a sonar nevű alkalmazásra, ami egy érdekes frontend PMD, checkstyle, cobertura, surefire és stb elé. Nem ugyanaz mint a qalab, ez szerver komponens (viszont időbeli változásokat is figyel). Elösször is: semmit nem kell a project build leírásához hozzáadni, a maven pom.xml-jéből kitalál mindent amit ki kell. Mire nem jó, ugye, a deklaratív build... A statisztikákat egy tetszőleges adatbázisban gyűjti fel. Konkrétan az ami felgyűjti (egy maven plugin) az ennek az adatbázisnak a JDBC kliense. Én jobban szeretném az egészet, ha valami web service-n keresztül menne be az adat, és akkor csak egyet kellene mindenhol bekonfigolni: a sonar server URL-jét meg a firewallt se kellene bütykülnöm. Sebaj, végülis így is jó. CI szerverbe is simán be lehet lökdösni build definíciónak, és akkor van napra kész infónk arról hogy mi az ábra. QAlab done right :-)

Wikipédia - gráf

Szóval sokan meglepődtek rajta, de a wikipédia adatbázis dumpjai tényleg publikusak és letölthetőek (persze nem a felhasználók és jelszavaik). Ez most nem lesz túl tudományos: úgy 1 éjszaka alatt be lehet tölteni a scriptemmel PostgreSQL-be, az indexelés még úgy néhány óra. (Sokkal inkább proc- mint I/O-intenzív művelet, úgyhogy egy jobb géppel simán felezheted ezt az időt) A MySQL-be ennyi idő alatt nem sikerült, mert persze azt is próbáltam, csak nem ismerem annyira mint a postgrest és 3-4 nap után elfogyott a türelmem.
Valahol egy hack is került bele, mert a dumpban egy decimal oszlop méretéből kilóg már az első pár beinsertelendő érték is. Furcsa, ez a MySQL-nek nem tűnik fel?

Méretek:

• ~11millió page, nem sok helyigény, pár giga - Ebbe csak a legfrissebb oldal-verziók értendőek bele
  
• ~208millió pagelink, ez úgy 15 giga helyet zabált fel
  
• ~1.5 millió redirect (itt van némi kavar, a constraint-ek hiánya miatt)
• Valamennyi indexelés után úgy 40 giga lesz az ebből a pár táblából képezett adatbázis

Ennyi mára arról ami bárkit érdekelhet...

Ja és az Amex kiküldte a paypal tesztelésből származó tranzakciós logot postán, a4-es lapokra kinyomtatva. Szép vaskos boríták volt...

PostgresPedia

Kerestem egy scriptet amivel át lehet konvertálni a MySQL dumpokat PostgreSQL által emészthető formátumba. Nem találtam semmit, pedig régen a postgres contrib csomagai között láttam ilyesmit. Van egy perl script is, amit úgy 6 éve nem tartanak karban és úgy látom nem nagyon megy. Most már mindegy...

Hát biztos van még mit pofozni rajta, például hogy insert helyett COPY-val menjen, de a wikipédia január elején kipakolt dumpjait be tudja pakolni postgres alá. Ha van hozzá tárad és türelmed :-)

Tessék.

Valamikor volt egy hamvában holt próbálkozás amúgy a mediawiki betuningolására PostgreSQL-re, a dolog a forkolásig eljutott, aztán sehova. Pedig érdekelne az eredmény.

Ha már úgyis írok: Munkatársat keres nekem a munkaadóm ide Budapestre és rohadtul fontos különben nem írnám oda mindenhova. Szóval ha bárki szereti a szép kilátást, nyugis légkört, ingyenüdítőt és hébe-hóba érdekesebb feladatokat, akkor ott van az email cím...

Hivemind & Spring in da house

Van egy web alkalmazásunk, ami több címen is elérhető. Barátságos a buta felhasználók felé, olyan nyelven beszél a felhasználóhoz, amilyen ország domain-jén megtaláltad. Többnyelvű országok mint Belgium, hát az most mindegy. Mindenesetre ez egy tapestry 4.0.x-es alkalmazás, aki ismeri a tapestry gonosz I18N rendszerét az már biztosan találkozott vele, ilyenkor a hivemind.ThreadLocale és a tapestry.request.RequestLocaleManager szolgáltatásokat kell felülfertőzni a hivemodule.xml-ben valami custom ingyombingyommal.
Cifraság kerül a képbe: ami eddig csinálta az egy spring-be beregisztrált bean szolgáltatásaival oldotta meg a problémát, ha már úgyis ott van, használjuk onnan, legyen ilyen a mi custom ingyombingyomunk.
Ez kicsit olyan mint a gagyiscifiben a dimenziókapu, hogy az egyik IoC konténer által kezelt bean-t kell bepakolni a másik IoC konténer egyik bean-jének. Ez is túlélhető mutatvány egyébként: kell hozzá csinálni egy factory-t, ami a megkapja a tapestry.globals.ApplicationGlobals szolgáltatást (ez ApplicationGlobals interface-t implementál), onnan kitúrni a WebContext-et, abból kiszedni a spring WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE attribútumát, amit már csak át kell castolni ApplicationContext-té és kiszedni belőle a megfelelő beant.

Nem is volt olyan bolonyult. Viszont néhány esztétikai kérdés nekem eszembe jutott:

• A tapestry mi a fészkes fenének wrappeli be servlet api interface-it saját érdekességekkel, amikor teljesen ugyanazt csinálják?
• A hivemind szintaktikája még annyira sem olvasható mint az avalon descriptorok voltak anno, a dokumentáció meg...
  
• Mekkora gáz hogy 2 IoC konténert kell használnunk. Persze a tapestry-nek szüksége van a hivemind-ra, de mi nem akarunk a hivemind-dal menni mert elég rendesen el van dizájnolva.

Ennyi a mai történet, nincs tanulság. Valamint a Paypal mese tényleg utolsó epizódjaként az derült ki, hogy a történelem során senki nem használta azokat az API hívásokat amiket ajánlottak nekünk a srácok. Értsd: velünk teszteltették a saját rendszerüket.
Speciel én mindig megtiszteltetésnek veszem ha egy ilyen nagy cég szivat meg :)

Nyugaton a helyzet

A sun végre valahára kiegészítette alkalmazás stackjét egy adatbázis szerverrel - még ha gagyi is kicsit, míg az Oracle felvásárolta a konkurensét és a piacát.

Csak hárman maradtak versenyben: Oracle, IBM és SUN, mindenkinek teljes saját stackje. Apróbb különbségek:

• az Oracle-nek nincs vasgyára
  
• a Sun adatbázis szervere kicsit alulfejlett (amit a népszerőségével pótol)
• az IBM java szoftverei hírhedtek stabilításukról :)

Viszont talán elöbb-utóbb kiterjed a versengés az offline webapp és más kliens oldali rendszerek témakörre, ahol olyan cápák is vannak már mint a Microsoft, Google, satöbbi.
Ki veszi meg az Adobe-t? :-)

JUM 2008-01-16

Az idei első Java User Meeting aka Paláver. Bevetettem egy kis gerillamarketinget a JHacks ügyében (köszi a lehetőségért :)), mire haza értem már új snippeket láttam. Köszi köszi :)
Szóval ezek voltak...

1. Kuvera: JasperReports
   IReports tervezővel bemutatva a Jasperreports. Elég jól nézett ki a dolog, nekem viszont a BIRT riporttervezője kicsit tökösebbnek tűnik, főleg hogy abba az IDE-be van építve amit amúgy is használok.
   Igen pontos és részletes bemutató volt, szerintem kicsit túl pontos és részletes, pl a classpath beállítások kevésbé lényeges dolgok...
   
2. Balogh Péter: SCA, SDO
   Az első cégember a JUM történetében, az IBM-től. Hát vannak az IBM szoftverekkel előitéleteim, ezt az előadást is így szemléltem, mindenesetre elég szinvonalas összefoglaló volt. Majd az apache tuscany házatáján jól szét fogok nézni.
   A melóhelyi SOAP gebaszolásokkal pont egy fényévre vagyunk ettől a szinttől, de keményen követjük a trendet gyökkettő sebességgel.
   
3. Java 7 vitafórum TVik vezetésével
   Új műfaj a JUM-on, és elég jó indítással szerintem. Nekem nagy megkönnyebbülés volt hogy nem csak én fújolok a java-xml integrációra, hanem minden jelenlevő. Viszont mi lesz a javával?
   Hát ha szabad tippelni, a java 1.5 a csúcs volt, már ebben is volt pár aknamező feature mint pl autoboxing. Lassan kevésbé lényegessé válik a java nyelv, sokkal inkáb lényeges lesz a java runtime.
   Lassan be kell szerezni a Groovy könyveket (nekem már kipipálva), 1-2 éven belül talán már hazai álláshirdetésekben is megjelennek követelményként alternatív JRE-alapú nyelvek ismerete. Majd nosztalgiázva gondolunk vissza azokra az időkre, amikor még volt normális editor ahhoz a nyelvhez, amit használtunk.
   

Paypal minefield összefoglaló

Kérem fáradjon a 3.2-es verziójú pénztárhoz.

A PayPal NVP api szerver oldali működéséről azt sikerült megtudni, hogy a "VERSION" request paramétertől függően a szerver átdobja a kérést a megfelelő verziójú backendre. Ez szerintem tök jó.
A probléma ott jelentkezik, hogy ez a bizonyos szerver egyes verziókra olyan backendre küldi át a kérést, ami valahogy meg is csinálja amit kértél, konkrétan levon a kedves vevőtől egy marék ZS-t, ugyanakkor viszont egy HTTP 500-at kapsz vissza (apache httpd 1.3.x default http 500 oldal, nem vicc), amit mivel nem tud parsolni a NVP kliens api, cefet nagy hibaként kapod vissza.
Ha üzleti szinten nézed az eredményt, igen katasztrófális: te úgy látod hogy nem sikerült a vevőt megvámolni, a PayPal viszont úgy látja hogy dehogynem, ezen a téren a programok között pedig további kommunikáció hijján ennyibenmaradás lesz.
A hibásnak bizonyult verzió a 3.0. A PayPal-es srácok szerint elég, ha a verzió stringet változtatod 3.2-re. Kipróbáltam, úgy látszik tényleg elég.
Ja és ez csak a LIVE rendszeren van, a sandbox ha lassan és kihagyásokkal is, de oké.

Tréfás?
Szerintem se. Remélem nagyon hosszú időre ez a PayPal történeteim vége.

Technotoys. Newtech meetup 2008-01-09

Lassan elkezdődik ez az év is.

• Vomberg István: Kromatográfiás méréstechnika Linux környezetben.
  Vegyészek. A címe alapján nem érdekelt volna, de sikerült felkelteni az érdeklődésemet. Ha egyszer vegyész leszek, biztosan ki fogom próbálni.
• Trencseni Márton: Facebook alkalmazásokról
  A Facebook API röviden. Említette, hogy gonosz alkalmazáok elrabolhatják a szegény ártatlan felhasználók adatait. Ebbe én is belenéztem régebben kiváncsiságból, összegányoltam rá egy "FooBar" alkalmazást, és én úgy tapasztaltam, hogy a facebook szerver nem engedi a 3rd party alkalmazásnak, hogy lekérdezze a barátok barátait. Ha jól emlékszem, a barátokról is csak az ID-t lehet tudni, semmi mást. Persze lehet hogy valami ajaxos hack-kel lehet kötyülni, mint amilyet a google mail ellen is be lehet vetni. A crawlereknek sincs sok mozgásterük, mert csak a saját hálózatuk tagjait láthatják a regisztrált felhasználók is. A facebook talán a legizmosabb adatvédelmű közösségi oldal.
• Maróy Ákos: Zigbee - wirless mesh networking protokol
  Egymással kommunikáló kis embeded rendszerek. Féligmeddig még kitalálás alatt álló dolognak tűnik.
  
• Mónus Ádám: Abaqoos pénztárca - a Felhasználók hatalomátvétele a fizetési megoldásokban is
  Nekem nem jött át a szikra, hogy miért jelent ez hatalomátvételt, de nagyon szimpatikus hogy magyar méretű pénzekért is megmozgassanak drága biteket a szerverek, ilyen 10-20 forintért. Technológiai oldalát nézve semmi új, szerencsére :)
  
• Nagy Ágoston: autoCut
  Az elejéről jobbára lemaradtam, mert a srác bejelentette hogy nem tud programozni és erre nagy hőbörgés támadt körülöttem, kint meg már addig is nagy parti volt. Gyorsan átparkoltam máshova, és nekem igazábol nagyon tetszett amit a nemprogramozó srác kitalált. Találtam ki én is hasonlót, csak persze arra sem volt időm hogy belefogjak. Ha lehetne kalapálni mégjobban tetszene, de nem lehet.
  

Hát ennyi volt...

3D

Gráf megjelenítés téma mégmindig...

Egy olyan gráf megjelenítőn álmodoztam az utóbbi napokban, ami képes 2 vagy 3-dimenziós megjelenítésre, és a csodálatos grafikus menük és toolbar-ok helyett egyetlen command line-szerű kisablakot kapna a kedves felhasználó, ahol olyan utasításokat adhatna ki, mint hogy gráf betöltése, layoutolás, clusterezés, az élek és a csomópontok tulajdonságai alapján valamilyen megjelenítési tulajdonság beállítása, szűrése. A konkrét megjelenítésen csak forgatni és nagyítani lehetne az eredményen.
Például ha egy ország közlekedési hálózata a gráf akkor mondanék egy olyat hogy
HIDE NODES WHERE population < 10000
COLOR 'red' EDGES WHERE type = 'railway'

Ilyesmi, kicsit SQL-szerűen. A nagy méretű gráfok kezeléséhez egyszerűen lényegtelen az, hogy egyenként lehessen a csomópontokat babrálni, a kicsiket meg mégiscsak jobb papíron vagy táblán rajzolni :-) Ehhez nézegetem a java 3D dolgait, ami inkáb Pali szakterülete.

• JMonkeyEngine - kicsit mintha játékra lenne kihegyezve, de nagy hype van körülötte
  
• Java3D - nekem ez elég jó teljesítményű dolognak tűnik. Kicsit régi, de újabban kitettéj java .net projectnek és mintha élne...

Valószinűleg nehézség lesz benne az, hogy maven-nel lebuildeljem, mert mindkettő natív cuccot is tartalmaz. Meglássuk akarok-e mad ilyet a végén, vagy hagyok egy ilyen kakukktojást a kupacban...

WS-Hell

Végignéztem az általam ismert java web service stack-eket (Axis 1-2, CXF, Xfire, JAX-WS) és egyik sem tudja kezelni a soapenc:Array típust. Néhányan azért mégiscsak használják, ezt az adattípust, például a google a SOAP search apiban. Ez kicsit szomorú :-(
Valamit kihagytam esetleg?

String.equals() lelkivilág...

Na jó, ez csak elmélet...

Egyszer valaki mondta, hogy a String.equals() végigellenőrzi az összes karaktert egyenként, persze csak ha ugyanolyan hosszúak. Nem hittem el, de végülis csak egy kattintás megnézni, tényleg ezt csinálja. Pedig milyen okos dolognak tűnik elöbb menézni a hashCode-t, ha az nem passzol, a string sem fog passzolni.
Viszont ha belegondol az ember alaposabban, nem olyan vészes dolog ez. Mióta Collections létezik, nem hasonlítgatunk össze nagy számú String objektumot, hanem a hash kódjuk alapján pillanat alatt megtaláljuk őket. Tényleges összehasonlítás nagyon kevés történik a Collection méretéhez képest.
Érdekes kérdés hogy ha a String.equals() használná a hashCode() metódust, akkor milyen típusú alkalmazások futnának gyorsabban, a hashCode() ugyanis bár cachelve van egy mezőben, a kiszámítása valamivel időigényesebbnek tűnik mint egy equals. Azaz rövid életű string objektumoknál valószinűleg nem térülne meg, így a java objektumfilozófiájával dolgozó alkalmazások talán valamit nyernek sebességben.
Talán mégsincs ez hülyén kitalálva, de biztosan más eredményeket adnának különböző alkalmazások.

OFF: El is felejtettem majdnem mondani hogy boldog BUÉKot kivánok mindenkinek, valamint egy éves az I Will Work For Food!

Pár hét TeamCity-használat tapasztalatai

Még a JavaPolis-on találkoztam a JetBreains embereivel, akik bemarketingelték nekem, hogy a TeamCity most már ingyen is használható 20 projectig és 20 felhasználóig. Ezzel érdemesnek tűnt egy alapos kipróbálásra.

1. Megpróbáltam a régi és az új perverz verziókövetőt is hozzáilleszteni a munkahelyemen. A rémlassú kapcsolatunkkal a verziókövető rendszereinkkel már az elején gebasz volt, erre az Jira-ba nagyon gyorsan adtak egy workaround-féleséget, amivel a Perforce (az új perverziónk) elment, az MS-VSS valami rettenetes összevisszaságot teremtett a filerendszeren. Nem vagyok bizos benne, de úgy látszik file nem maradt épen. Úgy látszik ezt valami natív VSS kliens okozza, amit a TeamCity futtat.
   Ez túlélhető, ásatunk egy csinos kis gödröt a VSS-sel és megkérjük hogy térdeljen a szélére.
2. Itthon persze a finom kis SVN fut, ezzel pillanatig nem volt probléma, ezt mondjuk el is várom :-)
3. Maven multiprojecteim buildelése. Ezzel van egy olyan különbség a continuum-mal szemben, hogy nem dobja be az alprojecteimet külön projectként. A probléma akkor következik, amikor az előző project teszt hibái miatt az új projectek tesztjeit már le sem futtatja. Ez mondjuk logikus, de jobban szeretném ha mindent mindig lefuttatna, SNAPSHOT verziókban mindig vannak törött tesztek. Na erre beállítottam egy -Dmaven.test.failure.ignore kapcsolót a maven paraméterei közé. Ezzel megy. Persze kérdés hogy ez mennyire korrekt.
4. Ezt még nem tudom, hogy miért, de a build agent újrastartolása után újra azonosítani kell a szerveren. Hmm, sebaj.
5. Az egyik eclipse installációban a TeamCity plugin nem működget. Valószinűleg az a baja hogy utólag dobtam utánna a SVN plugint. Nyilván, munkában nem használunk SVN-t, az túl egyszerű lenne. Viszont a windózos teamcity tray icon az csodás dolog, egy ilyet szeretnék én gnome-hoz linuxra.
   

Ennyi, az érdekességekről...