java 1.8 hash

A java 1.8-ra egy egész halom érdekességet hoz, talán a legnagyobb változások a java 1.5 óta. Az emberek mégis igen lassan mozdulnak rá, a cégek meg még lassabban. Ez a szokásos dolog. Az Oracle, hogy kellemes pozitív motivációval noszogasson minket, fejbelövi a java 1.7-et, pár hónap múlva nem több lesz frissítés. A Fedora project fejlesztői kicsit erőszakosabban modernizálnak és a fedora 21 új feature-i közé betették azt, hogy nincs java 1.7 rajta. Micsoda spártai (és balfasz) feature. Akárhogy is, lassan mozdulni kell és az élő projecteket át kell rángatni java 1.8-ra.

Ez egy igazán naiv idealista szemében rohadtul egyszerű lehet: Csere, restart, jónapot.

A probléma, amibe többszörösen beleakadtam, tulajdonképpen egy nem különösebben nagy dobra vert újdonság: új hash algoritmus, amely egész szépen muzsikál. Király, jobb teljesítmény ingyen. Mi baj lehetne?
A probléma ott van, hogy bár nagyon nem jó ötlet arra fogadást kötni, hogy a HashMap-ba tuszkolt adatok milyen sorrendben fognak kijönni amikor iterálsz rajtuk, nos ennek ellenére explicit módon egy csomóan mégiscsak fogadást kötöttek rá, általában tudtukon kívül. Egész idáig mindig nyertek, mert mindig ugyanúgy jöttek ki az adatok. Most szépen kipukkan a lufi, de még nem igazán látom, hogy mekkora a lufi.

A probléma ott van, hogy:

1. Nagyon sok helyen használunk HashMap-et vagy HashSet-et
2. A hibás feltételezéseket nehéz megtalálni, nem holmi grep-pelés, hanem el kell a nyomorult kódot olvasni, tesztelni kell
3. Nagyon sok kódot
4. Nagyon kevés időnk van rá

Szóval jó kis meló lesz ez, hajrá :)

"Hash, alkoss, gyarapíts"

Websüket

2006 körül minden az AJAX-ról szólt. Mindenki dinamikusan generált HTML-ből állított kezdett weboldalakat összeállítani, de azért még jónéhány full-page reload volt benne. A kommunikáció többnyire tényleg XML volt, néha jöttek-mentek html darabok is.

2010 körülre már megint mosogatószert meg focicsapatot jelentett az AJAX. Az XML látványosan veszített népszerűségéből, elkezdték egyéb formátumok átvenni a helyét, főleg JSON de láttunk már olyan perverziókat is mint a BSON és társai. A formátumok káoszában a REST homályos útmutatásai teremtettek hébe-hóba rendet.


Itt a történelemórát had szakítsam félbe, hogy azt is elmondhassam közben, hogy milyen elégedett voltam azzal, hogy a rémesen túlbonyolított és szemellenzős szerveroldali MVC rendszereket itt ezen a ponton jórészt elavulttá tették az egyoldalas webalkalmazások. Ez nem azt jelenti, hogy nincs többé aki használja őket, hanem csak egyszerűen COBOL-völgyi bányászoknak tartja őket a sok nagyvárosi okostojás.
De nem csak ez okozott kárörömet rothadó lelkemben, hanem az is, hogy a javascript programozók komoly lehetőségeket kaptak arra, hogy bizonyítsák, nagyon egyszerű, könnyű és stabil rendszereket tudnak építeni kedvenc platformjukra, a böngészőkre. A pofáraesésen csak azért nem tudtam szívből derülni, mert nekem is fájt.Ez egy nagy adag komplexítást levett a java backendről és tulajdonképpen ma egy java backend fejlesztő élete akár rettentő egyszerű is lehetne egy végletekig idealizált esetben. Csak olyasmikkel kellene foglalkoznia, mint megbízhatóság, kiválló válaszidők, skálázhatóság és mindenek elött persze (hmm...) egyszerűség. Hát azért nem egészen itt állunk, de őszintén úgy gondolom, hogy ez a lehetőség adott. Csak hát elkú ugye, már megint.

Nade félre ezekkel.

2014 van és miután évekig vártunk hogy leülepedjen és letisztuljon a webfejlesztés, végre ovisokra és nyugdíjasokra bízhassuk amíg mi szebb kihívásokat keresünk magunknak, tartok tőle hogy ismét csalódás fog érni. Bár már évekkel ezelött is írtam a websüket szabványról, azóta kidobták, mégis visszaengedték, megszületett végre a java api, satöbbi. Szóval úgy tűnik, végre itt van a websocket, nagyon lassan de elhárulnak az akadályok előle. (Nem tudom miről beszélnek amikor gyors fejlődést emlegetnek az emberek, szerintem tüttyögésről meg pöcsölésről lehetne beszélni.)
De nekem felmerül a kérdés: ha van egy folyamatos full duplex kapcsolatod a szerverrel, ugyan mi a fenének akarnál REST-et használni. A webalkalmazások egy jelentős részének új paradigmára, új eszközkészletre van szüksége.

No ennyi. Vár a gyár.

Hron, remélem megválaszoltam a kérdésedet legalább részben :)

MongoDB - pár tapasztalat

Mostanában szabadidőmben MongoDB-re írogatok mindenfélét, gondoltam írok egy kicsit alaposabb beszámolót arról hogy milyen marhaságokat csináltam eddig vele. A legutóbbi régen volt és nagyon felületes.

Bosszantó apróságok

Nyugodtan kezdhetjük a rossz hírekkel, nem lesznek nagyon rosszak, inkább csak bosszantó apróságok.

Az egyik ilyen az, hogy 32-bites rendszeren a mongodb behúzza a kéziféket és max 2 GB méretű adatbázist enged. Ez lófüffy, fogalmazzuk talán inkáb úgy, hogy 32-bites rendszereken a mongodb röpképtelen.

A másik apróság, amibe belefutottam még az elején, az az hogy a OpenVZ virtuális gépeken valami okból memóriaszivárgás van a MongoDB szerverben és ettől teljesen használhatatlan. Bevallom nem néztem igazán utánna, de itt került fel az OpenVZ a ganajlistára. Miféle virtualizációs technológia az, amivel egy adott szoftver a vendég operációs rendszerben behal? Gubancos, gondolom.

Sokkal inkáb bosszantó a MongoDB hanyag viselkedése a tárhellyel. Az alapbeállításokkal  folyamatosan logolja az összes adatmódosítást, ami rettenetes méretű logokat eredményez nálam. Kicsit kellett keresgetnem hogy hogyan lehet kikapcsolni.

A másik tárhely-kellemetlenség 3 GB-os journal, amit az adatbázis inicializálásakor létrehoz. Bár a memóriafogyasztása egyébként nagyon frankó lenne, ez a 3 GB journal kicsi adatbázisokhoz nagyjábol diszkvalifikálja. Ki lehet kapcsolni, akkor kicsit visszavesz a sebességből és egy esetleges crash teljesen hazavágja. Akkor most gondolkozzunk el rajta hogy mit szeretnénk inkáb.

Klassz dolgok

Szóval az egyik klassz dolog amit igazán kedvelek a MongoDB-ben, az UPSERT, ami az "insert or update"-re egy rövidítés. Ez pl log feldolgozáskor marha gyors tud lenni és az alkalmazáson is nagyon sokat egyszerűsíthet. Az upsert egyszerűen úgy működik, hogy megmondod a keresőfeltételt és egy dokumentumot. Ha talál a keresőfeltételnek megfelelő dokumentumot, akkor ahhoz hozzávágja az új dokumentumot, tehát azokat a kulcsokat, amik a régiben voltak, azokat felülírja (itt lehet trükközni), ha nincs ilyen kulcs, akkor hozzáteszi a dokumentumhoz. Amennyiben nem talált ilyen dokumentumot, akkor csinál egyet, ami megfelel ennek a keresésnek, azaz benne lesz a keresett kulcs és a bedobott dokumentum.

Nézzük a fent említett okosítást: például nekem hasznos az, hogy egy dokumentumban egy tömbhöz fűzök hozzá értékeket illetve érték párokat. Erre jó a PUSH, amivel a régi doksiban nem írja felül a régi értéket, hanem csak hozzáappendel. Ez upsert esetében is teljesen jól muzsikál.

Az marha sokat segít, hogy nem kell csekkolni, hogy egy dokumentum létezik-e már a feldolgozás során.

A sebesség a másik baró dolog. Eleinte voltak olyan tévhiteim, hogy az adatmennyiséggel egy beágyazott derby is el fog boldogulni. A derby hozta is a formáját az első pár órában, amikor azonban a memória méreténél nagyobbra nött az adatbázis mérete, beleállt a földbe a teljesítménye.

Trükkök

Relációs adatbázishoz szokott barátaim: egy pár dolgot át kell gondoljunk, amikor mongodb országba települünk.

Például relációs adatbázisokban nagyjából magánügy, hogy hogy nevezed a tábláidat és az oszlopokat, a teljesítményre aligha van hatással, mert nem kerül bele minden rekordba, legfeljebb amikor lekérdezést küldünk az adatbáziszervernek akkor kicsit több byte-ot küldünk. Nem nagy ár, ezért inkáb érthetőre próbáljuk faragni a relációs sémát szép oszlopnevekkel. A különbség egy dokumentum-alapú, séma-nélküli adatbázisnál az, hogy minden dokumentumban benne vannak a kulcs-nevek, így a rövidebbet jobb sebességgel jutalmazza az adatbázis szerver.
Én pofátlanul mindent egy-két betűsre rövidítettem. Ezt a dolgot ha valaki átvenné tőlem, nagyon gyűlölne.

Ezzel kapcsolatban jut eszembe az _id kérdése. A mongoDB minden dokumentumba beletesz egy _id nek nevezett, 12-byte hosszú azonosítót, amiben a szerver azonosítója, egy random szám, valami sorszám, a heti lottó nyerőszámok és ilyesmi tlálható. Az én alkalmazásomhoz nem volt igazán hasznos, de egy databig nem jöttem rá erre:
A dokumentumodnak amúgy is kell valami, ami amolyan elsődleges kulcs. Egyszerűen ezt a dolgot hívd _id-nak. Még akkor is, ha az "id", az "azon", és a "customerid" elsőre jobban tetszik. Az _id ugyanis nem kell, hogy a fenti szám legyen. Lehet szöveg, szám, akármi. Értelmesnek tűnik saját ID-t csinálni.

Emellett persze az _id az a dolog, ami mindig indexelve van, nem is kell kérni és nem is lehet kikapcsolni.

Indexek: meg tudom erősíteni, hogy amit nem indexelsz, arra a lekérdezés egészen lassú lesz. Ezt gondolom gondoltad :) Az indexek viszont rendesen meglendítik a memóriahasználatot, szóval okosan azzal az indexel.

Még egy trükk, amiért lehet hogy máglyára küldenétek. Olyanra is volt szükségem, hogy egy dátumokhoz számértékeket rendeljek. Eleinte így csináltam:
[{k: Date(), v: 1}, {k: Date(), v: 3}, {k: Date(), v: 4}]

Ez kicsit terjengős dolog, úgyhogy azt találtam ki, hogy a dátumot szöveggé alakítom, mégpedig egy nagyon tömör szöveggé (amire összeütöttem egy 75 vagy 76 digitből álló számrendszert, az még könnyen olvasható) és az így adott dátumokhoz simán csak a számot rendelem. Ilyen lett:

[{"8V3": 1}, {"8V4": 3}, {"8V5": 4}]

Ennél én sajnos nem tudok tovább egyszerűsíteni, de ha egy dátum csak egyszer fordulhat elő, akkor csinálhatnám így is:

{"8V3": 1, "8V4": 3, "8V5": 4}

Ez ocsmány trükknek tűnhet, de nagyon sokat segített az adatbázis  méretének redukálásában. Illetve vehetek nagyobb gépet is persze. Vagy kérhetek karácsonyra.

DAO kérdések

No utolsó beteg design patternem következik így vasárnap este...

Relációs adatbázisoknál a resultset-eket tipikusan egy listává alakították át a DAO-k, ehhez az egész resultsetet elösször végigolvasták és objektumokká formálták. Na ez nagy adathalmazokhoz soha nem volt jó ötlet, de olyan ritkán kellett ilyesmit csinálni. És most mintha mást se kellene.

Szóval én meg akartam tartani a listát mert olyan egyszerűen lehet vele bánni, viszont eszem ágában sem volta teljes eredményhalmazt berángatni a memóriába. Szóval a megoldás egy olyan lista lett, ami Closable is. Így viszont a DAO metódosukat hívó kódnak be kell zárnia a listát. Ez a része szokatlan és kicsit bizonytalan vagyok a kérdésben. A problémát azért megoldotta.


Kotlin nyelven azért egészen egyszerű a dolog a (szerényen dokumentált) use funkció segítségével.

dao.getBlaList().use { it.each{ ... } }



Ezt nyugodtan fikázzátok le, nem garantálom hogy átírom de garntáltan érdekel a véleményetek! No ennyi mára, boldog hétfőt!

Tartozom még egy beszámolóval a linux konferenciáról, nem éppen java de volt java is.

elszállt ötletek: ami a tömörítésből még hiányzik

Van egy mondás, miszerint egy rendszerben egy adott pillanatban csak egy komponens a bottleneck. Ezt megfigyelheted akkor is, amikor egyik gépről nagyobb mennyiségű adatot pumpálsz át etherneten: vagy a merevlemez, vagy a hálózat lesz teljesen leterhelve, a processzor meg közben vakarja a tökeit.
Arra gondoltam, hogy ezen kicsit megpróbálok segíteni, de ha egyszerűen csak bedobok egy tetszőleges tömörítő algoritmust a sorba, akkor könnyen lehet, hogy a CPU-t rúgom agyon és ezzel azt nevezem ki új bottleneck-nek, míg innentől a hálózat forgalom lesz alacsony. Minden vason külön ki kellene találnom hogy mennyire jó ötlet egy tömörítést közbedobni, és nem akarom, mert már a másodiknál is nagyon unnám.

Egy olyan InputStream/OutputStream párosra gondoltam, ami egy kellően nagy bufferrel rendelkezik. Az output része az írásra itélt adatokat csomagokra bontaná és egy szálon figyelné hogy melyik mennyi idő tellik el a beérkezés és a bufferből távozás között. Ha úgy becsülné meg, indítana egy szálat, ami a buffer egy részét egy tömörítő algoritmussal betömörítené és hozzátenne egy nagyon rövid headert (pl 1 byte) ami jelezné hogy tömörítve van-e és ha igen milyen algoritmussal. Az input része csak csekkolná ezt a headert és szükség esetén kitömörítené a csomagot. Nyilván ez egy kicsi overhead.

Így a viszonylag gyenge hálózati kapcsolatot kicsit felgyógyíthatnám egy processzorral, de annélkül, hogy esetleg bizonyos esetekben nagyon durván kiszúrjak magammal.

Egy másik kapcsolódó ötlet az az lenne, hogy egy olyan tömörítő input/output streameket próbálnék ki, amelyek ellenőrzik (lehetőleg csak egyszer) hogy az adott rendszeren létezik-e az adott tömörítő algoritmusnak natív változata. Ha van akkor azon átpipe-olva tömörítené az adatokat, ha pedig nincs, akkor egy java implementációra terhelné. A natív implementációk általában véve gyorsabbak, még azzal együtt is, hogy context-switch ésatöbbi.

Szóval ez csak szimpla tuning. Nincs autóm, úgyhogy azt nem tudom brümmögtetni :-) Ja és nem is szeretnék, mert nem szeretem a brümmögést :-D

Hát ennyi lenne az ötlet, jöhetnek a kövek.

subhub @ googlecode

Gondoltam egyet és megosztottam a subhub nevű pubsubhubbub kliensemet a google code-on. Ez a cucc két JMS sorral elintéz mindent. Egy JMS sorban küldöd fel, hogy mire íratkozzon fel, a másikon pedig kapod az feed updateket. Kicsit kezdetleges, de biztosan használható, mert én használom :-)

https://code.google.com/p/subhub/

Kotlin tesztkör

Néhány hónapja a Jetbrains orosz csapata bejelentette hogy új JVM nyelvet fejlesztenek Kotlin néven. Próbálgatom, gondoltam pár dolgot mesélek, hátha érdekes. Nem lesz teljes leírás, csak kedvcsináló. Ha megjött a kedved hozzá, látogass el a kotlin weboldalára! Türelmetleneknek a végén összefoglaló.

var vagy val

Meséltem neketek a beteges final-ozásomról. Nos a magamfajta elvetemülteknek alighanem üdítő feature a kotlin nyelvben az, hogy a változó deklarációjánál meg kell mondani, hogy változhat-e vagy sem. Ami változhat, az var (variable), ami nem, az val (value).
Ez semmi új, a scala is hasonló koncepcióval jött.

A változók deklarációjánál még tréfi az is, hogy nem kell kétszer elmondanod a típust. Kitalálja. Példa:

val kakukk = "kakukk" //nyilván string
val map = HashMap<String, String>()

Azt gondolom észrevetted, hogy new sincs. Nincsen. Mondjuk a melóhelyi projectemen, hogy a metódusok fele nagybetűvel kezdődik többnyire nem érteném, hogy ez most új objektum vagy csak hívás... desebaj, az úgyse nem lesz kotlinban.

Mr Bean

Természetesen property-k definiálása is kapott egy szebb és kompaktabb szintaxist. Elösször is, minden amit var-ként definiál az ember, az egyből property, getterrel, setterrel, tokkal vonóval.

var name : String? = null;

Ennyi, ha nem akarod felüldefiniálni a getter tartalmát. Nagyon ajánlanám, hogy ne akard, vicces dolgokat lehet vele elkövetni. Pl ha a getterből a property-re hivatkozol, akkor simán a kód meghívja önmagát. Ezt gondolom majd kijavítják :)

Null-safety

A null értékektől való para mindig is itt volt, mióta java platform létezik, meg még elötte is, csak szegény emberek elötte egy segmentaiton fault-ot kaptak, nem pedig NPE-t. Azért ha a kettő közül kell választani, akkor én még mindig inkáb a NPE-t választanám, az nem feltétlenül halálos.
Míg a java nyelv esetében erőtlen próbálkozásokat látunk annotációk bevezetésére, az új JRE nyelvek mind valamilyen mehanizmussal jönnek a null értékek kezelésére. A kotlin megkülönbözteti tipusonként, hogy lehet-e null. Például egy funkció, ami esetleg null-t ad vissza, azt így deklarálod:

fun talánNull() : String?

Na ez nagyon kedves, de a sima java-ban nincs ilyen, ezért minden java API minden visszaadott értéke a kotlin szempontjából esetleg null lehet. Na most például a slf4j LoggerFactory.getLogger(akármi.class) soha nem ad vissza null értéket, de a kotlin ezt nem érti, viszont néhány kényelmes operátort ad az esetleges null-támadás kivédésére. Az egyik a !! operátor. Ez a "Hidd el nekem hogy nem null, dögöljek meg itt azonnal ha null!!" operátor :) A log4j esetében például így nézne ki:

LoggerFactory.getLogger(akármi.class)!!

A másik lehetőség, az úgynevezett Elvis operátor. Elvis-szel azokat a helyzeteket tudod röviden megfogalmazni, amikor null értéket valami mással helyettesítenél. Pl ha getFoo() null-t ad vissza, akkor helyettesítsük le inkáb foo-ra:

val foo : String = getFoo() ?: "foo";

Ez a (x == null) ? null : x.getFoo() típusú műveletekre használatos. Így néz ki a fenti példa esetében fél szemű Elvis-szel.

x?.getFoo()

Ez null lesz, ha x null, és a getFoo() értéke, ha x nem null. Egész kompakt.

Nincs static

Ez a dolog nekem már scala-ban is nehezen esett le, de nincsen statikus változó. Első felmerülő kérdés egyből az, hogy akkor hogy a túróba fogok loggert deklarálni. Valahogy így

class object {
    private val logger : Logger = LoggerFactory.getLogger(akármi.class)!!
}

Innetől ugyanúgy használhatod, mintha egy sima statikus logger lenne.

Closure

Minden új JVM nyelv lehetőséget ad closure-ök használatára (különben az érdeklődés hiányával kell szembenéznie), a kotlin sem kivétel. Nézzünk egy gyors példát:

fun kickntimes(int cnt, fn : () - > Unit) {
   for(i in 0 .. cnt) {
      fn();
   }
}
...

kickntimes(100, {print("bla")});

Extension functions

Ez sem új, a groovy is és a scala is mindenféle extrákkal cicomázza fel a java osztályait. Így lesz a java.io.File osztálynak olyan metódusa, aminek például átpasszolsz egy closure-t és minden sorára meghívja. Valahogy így:

val myFile = File("bla");
myFile.forEachLine({ print(it); });

IDE

Mivel Jetbrains, nyilván idea plugin van hozzá. Azért annyira sokat azért ne várj tőle, épp úgy fejlesztés alatt áll, mint a nyelv maga. Szinez, pár helyen kisegíti a szintaxist, kódformáz. Refaktorálni többnyire nem tud, csak az alapokat (osztály átnevezés).

Összevisszafoglaló

Szóval egészen sok új dolga van a kotlinnak, érdekes koncepciók vannak benne és van. (Ellenben a scala IDE mindig elavult eclipse-re epül, amellett hogy nem is tud sokat) kotlint használni kicsit olyan érzés, mintha délután négykor érkeznél a házibuliba: nagyon korai. Majd meglátjuk mi sül ki belőle.

Drools, Planner

Mostanában eltöltöttem egy kis időt egy prototipus projecten ami a drools planner integrációját késziti elő az oVirt-be. Ez még nem azt jelenti, hogy valaha benne is lesz, csak azt, hogy megpróbálom feltakarítani a környéket és beintegrálni. Gondoltam pár tapasztalatot megosztanék vele kapcsolatban.

Ha még nem találkoztál a drools projecttel, ez egy szabály-motor. Leírsz szabályokat, bedobálod a tényeket és bizonyos következtetésekre jut a drools, a következtetésekből pedig további következtetésekre. Egyrészt nagyon egyszerű és szerintem elegáns módja a szabályok leírásának, másrészt bizonyos bonyolult feladatokat egészen egyszerűen oldhatsz meg vele. Pl N királynő, labirintus, satöbbi iskolafeladatok. Na ezeken az iskolafeladatokon túl egész hasznos dolgokra is lehet használni a hétköznapi életben, most például az oVirt-ben (ami egy private cloud rendszer lenne, csak ahhoz még kicsit béna) virtuális gépek szerverekre való kiosztására próbálom használni.
(felemelő dolog szabadidőben is a melón pörögni, biztosan hősi gödörbe fognak elkapálni, ha beledöglök)

IDE

Szóval a szabályokat egy speciális nyelven írod le, erre van több opciód is. Ez végül sima plain java bytecode-dá fog lefordulni. Szóval ez forráskód, ha tetszik, ha nem. A forráskód, amit írnod kell java-jellegű. Éppenséggel én nem szeretnék ilyeneket írni vim-ben, szóval az IDE támogatásnak utánna kellett járnom.
Eclipse marketplacen ha szétnézel, a JBoss IDE állítja magáról, hogy van benne Drools support. Ez sima mezei hazugság marketing, nincsen benne :-) A drools csomagok közűl kellett letölteni egy lefordított verziót és felinstallálni. Pár varázslót és egy editort kapsz, az editorban van syntax highlighting és egy kevés code completion. A vim-élménynél azért lényegesen jobb, de el tudnék képzelni barátságosabbat.

Pár tapasztalat

Első alapszabály a drools-hoz általában: bármilyen szabályt írsz is, ne legyen benne hálózati/adatbázis interakció! A drools kegyetlenül elkapja és nagyon lassú lesz vagy agyonterheli az adatbázisod. Valószinűleg mindkettő. Csinálj szépen in-memory modelt. Elösször tölt, aztán kiértékel. Sajnos ez nem mindig egyszerű.

Aztán pl én néha nem szégyellek egy loggert bedobni a drools szabályaimnak, csak hogy meggyőzödjek róla, hogy tényleg kiértékelődnek. Érdemes csak debug szinten hajtani, mert komoly mennyiségű logot le tud termelni.


Aztán unit-tesztek: igen, mindenképpen unit-tesztelj! A szabályok csak futásidőben fordulnak le (első futás), szóval az hogy nem kiabált a build, az még a világon semmit sem jelent. És nagyon ajánlott ellenőrizni az eredményeket, mert könnyen előfordul, hogy elírtál egy feltételt a szabálynál és mégsem értékelődött ki.

A szabályok kiértékelési sorrendjáról pedig ennyit lehet tudni: javaslatot tehetsz rá (salience paraméter) de amúgy a drools nem enged beleugatni senkit se.

Planner

No nézzük mi ez a planner. A planner optimalizációs feladatokra segít adni valamilyen megoldást, a drools expertre építve. Ez konkrétan úgy történik, hogy pontozási szabályokat írhatsz le drools szabályokkal, írsz hozzá pár sor XML konfigurációt (ne aggódj, java config is van ha még nagyobbat akarsz szívni) és ráengeded a megoldó algoritmust. Visszakapsz egy megoldást jó esetben, és a hozzá tartozó elért pontszámot.

A pontozásnál több féle pontozást használhatsz, nekem a soft and hard tetszett legjobban.

Körülbelül ezer módon rúghatod tökön magad a drools plannerrel, kb 20 különbözőképpen nekem is sikerült, ebből párat nektek. Ha esetleg meg akarnátok próbálni :-)

Kiválló kiindulópont Geoffrey de Smet drools példagyüjteménye, ami a drools csomagok között letölthető. Szerintem a példagyüjtemény nélkül az elején feladatam volna. A dokumentáció az helyenként alulról közelíti a kettes érdemjegy határait. Pl az XML konfiguráció pontos leírását sehol se találtam, végül a forráskódból jöttem rá, hogy mit rontottam el.

Az egyik fájó különbség a példák és a rögvalóság között, hogy egyes példák egészen sokáig tart, amíg lefutnak. Sokkal tovább tart, mint a felhasználók türelme. A szerencse viszont az, hogy a legjobb megoldás a felhasználók túlnyomó részét teljesen hidegen hagyja, egyszerűen csak egy elég jó megoldást akarnak és persze tegnapra. Ezt sikerült olyan paraméterekkel elérni, mint

• maximumUnimprovedStepCount, azaz ha egy ideig nem talál jobb megoldást, akkor itt hagyjuk abba.
• scoreAttained, azaz egy bizonyos minimális szintnél tovább már nem kell tovább menni.

Azért a terminációs szabályokhoz én el tudnék képzelni jobb döntési logikát is, legalábbis az adott feladathoz én valami pontosabbat szeretnék. Majd bizonyíthatom, hogy tényleg van jobb ötletem, mert a drools planner-rel megetethetem a saját implementációmat.

Aztán nézzük mivel szívtam még meg... Igen, a probléma tények (facts)-hoz például első nekifutásra nem a megfelelő listát adtam vissza. Pár kört lefutottam, mire rájöttem, hogy ennek következtében a pontozási szabályok egyszerűen nem kerülnek kiértékelésre.

Aztán a ConstraintType.POSITIVE-ra nem jöttem még rá, hogy hogyan kell használni, a példák között nincs egy se. Pár dolgot viszont eleinte pozitív állítások formájában próbáltam megfogalmazni. Na erről leszoktam, és csupa negatív pontozás van jelenleg. Nekem furcsa, hogy csak büntetéseket osztok a szabályaimmal, de megszokom. Majd a politikai pályafutásom alatt biztosan sok hasznát veszem ezeknek a tapasztalataimnak.

Egyébként, ha kicsit belejön az ember, úgy tűnik egészen komplex feladatok optimalizására is egészen könnyen lehet megoldást gyártani vele. A futási ideje igazán nem vészes, amennyiben jól paraméterezted a termináló feltételeket :-)

Eclipse democamp pénteken

Aki még esetleg nem tudna róla: péntek este budapesti eclipse democamp.

Leginkáb az XTend nyelv érdekel az előadások közül, annak ellenére hogy szerintem nem a nyelv a probléma a java környékén.

Gyárlátogatás: KÓD_KONVENCIÓ

Hali, ismét gyárlátogatáson vagyunk, zsebrevágott kézzel körbevizslatunk az üzemben, megnézzük mit csinálnak a szakik. Gondoltam ma kicsit mesélnék arról, hogy miket láttam kód konvenciók háza-táján, milyen viták zajlanak, hol és mi fáj. Ne várjatok nagyon objektív megközelítést, ez az egész személyes élmények alapján.

A legtöbb kód konvenció csak a fejlesztők életét könnyíti vagy nehezíti meg. A forráskód fordítása után a tárgykódban már nincsenek se szóközök, se kommentek, se tabok, C nyelvben még a változód neve is eltűnik, java-ban is inkáb csak a mezőknek van jelentősége. Szóval ilyen szempontból a dolog kevés értéket jelent az ügyfélnek, aki végülis fizetni fog (reméljük) a termékért.

Nevek

C++-ból és hasonló területekről érkező szoftverfejlesztőktól gyakran láttam hungarian notation-hoz hasonló neveket. pl a mezőket sokan kedték aláhúzással, mint _name, vagy my prefixszel, pl myName. Régebben sokat láttam szigorúbb hungarian notationt java programozóktól is, pl volt olyan munkahelyem, ahol meg a paramétereket is 'a'-val (mint argumentum) kellet kezdeni.

A legviccesebbnek azt a konvenciót találtam, ahol az entitás osztályokat és azoknak a mezőit magyarul kellett elnevezni. Szerencsére ékezeteket nem akartak, de sikerült amolyan kicsi bábelt létrehozni a forráskódban, ugyanis a java többi része és library-k továbbra is angolul vannak.

if(fejleszto.isHulye()) ...

Egyes konvenciókat a java nyelvben én is teljesen figyelmen kívül hagyok, az egyik ezek közül amit a legtöbbször vágnak a fejemhez, a konstansok NAGY_BETŰS elnevezése, helyette a konstansokat is sima mezei camelCase írom. Akkor pár ok:

• A NAGY_BETŰS konvenció a C nyelvből érkezett a java nyelvbe. Ott a prepocesszor makrókat ajánlott nagybetűsen írni, ugyanis komoly gubancok származhatnak belőle ha elfelejted. Java-ban udvariasan szól az eclipse vagy amit hajtassz, hogy "komám, az final". Nem mondod komolyan, hogy vim-ben írsz java kódot? Ja emacs, persze, de kis buta vagyok :-D
• Enum-okat: Igen, ami az enumban van az effektive public static final, de miért kellene mindent nagy betővel írnunk benne? Mint egy állítólagos nigériai tábornok lányának a takarítónöjének a majma egy e-mailben.

Tab vs space

"te tab-bal tabulálsz?
bnzi-e vagy" - beteg-patkány-ember

A másik ilyen kérdés a space vs tab hitvita. Nem szeretnék senkit se rábeszélni arra, hogy áttérjen a másikra, de a harcos space-hívőknek: Ha a space a tabulálásra van akkor a tab vajon mire van?

Ez a tabulálás dolog viszont leginkáb a python fejlesztők között okoz viszályokat, pár hét python buherálás után én így kategorizálom be a python fejlesztőket:

• tab-os pythonos
• 4-spaces pythonos
• 4-től eltérő mennyiségű space-szel tabuláló pythonos

És mind meg van győződve róla, hogy ő vágja a témát és a többi falhozvert lófasz. A projectemen többségében 4-spaces pythonosok vannak, szerintük a pythonnak nagyon fontos, hogy pont 4 legyen. Ennek ellenére a kódban tucat helyen el van cseszve és csak 3 space. Sajnos kb azonnal elfelejtettem az indoklást, az összes python scriptem futott a tabokkal.

Sorhossz

A sorok hossza ami a másik dolog, amivel teljesen értelmetlenül és eredménytelenül lehet vitatkozni egy pár órát. Kezdetekben mindenkinek volt a szép karakteres képernyője, ami képes volt 80x25 karakter megjelenítésére, innen származott az a tradíció, hogy legyünk szivesek 80 karakternél többet ne pakolni egy sorba. Hát azóta eltellt egy kis idő, közben a képernyők közül a 23 colos lett a standard. Amennyiben nem a mobil telefonodon fejlesztessz. A sorok szélessége viszont sok projectben megmaradt 80 karakter.

Kicsit ez a dolog kapcsolódik a space vs tab vitához, mert a tab méretét lehet változtatni a szerkesztőben.

Kommentek

Talán ezzel volt a legkevesebb gubanc, mert áltaáában a fejlesztők beérik kevés dokmentációval. Egy ellenpéldával találkoztam, konkrétan az oVirt projecten dobták vissza az egyik patch-emet egy csillag miatt. Ugyanis egy kicsit bonyolultabb kóddarabhoz odaírtam, hogy mi a fészkes fenét csinál ez az egész, és a többsoros /* */ kommentet használtam. Erre valakinek az volt a kifogása, hogy "mi" csak a /** */ -t használjuk.

Akkor kapd be a patch-em :-)

Egy kis saját: final paraméterek

Á igen, gondoltam a végére csemegének megint egy saját paranoiámat dobnám be. Legalább tudok róla, hogy van :-) sőt már egyszer meg is gyóntam. Szóval amerre járok, hajlamos vagyok főleg a hosszabb metódusok paramétereit átírni final-ra. Ennek funkcionálisan a világon semmilyen következménye nincs: amennyiben lefordul, működni is fog. Azért alakult ki nálam ez a szokás, mert a parameter-reassignment-et teljesen olvashatatlannak tartom.

De én legalább senkivel nem kezdek el cseszekedni, ha nem finalként definiálja a paramétereket a patcheiben :-)

Policy Police

Pár eszközt említenék meg a kód konvenciók betartatásához illetve figyeléséhez:

• nagyon szimpatikus a sonar. Azt is meg lehet oldani vele, hogy elhasaljon a build, ha súlyosabb hibát talál, de ilyen beállítással még nem találkoztam. A sonarral kapcsolatban azt tartom szomorúnak, hogy nagyon kevesen használják ténylegesen, pedig átalában egy csomó dologra hívja fel a figyelmedet, szerintem a használatával tényleg tanulhatsz pár érdekes dolgot, legalábbis én tanultam tőle.
  A legfontosabb, hogy időben láthatod a változást. Szerintem az egésznek nagyon kevés értelme van, ha nem a változást figyeled.
• nagyon idegesítőnek találtam a maven-checkstyle plugint, ami az ovirtben nem csak pazarolja az időmet, de olyan marhaságokon képes eltörni a buildet, mint trailing spaces. Amikor éppen egy kritikus hibát próbálsz javítani el tudod képzelni mennyire örülsz egy ilyennek.

Amúgy nekem végülis 8, mondhatnám. Magyar jelöléses 80 karakteres sorhosszú, dokumentálatlan és akár egysorba írt kódot kapunk és nem ettől lesz az eredmény egy stack trace.

A kód konvenciókban engem az zavart mindenhol, a C/C++-os, Perl-es Python és PL/SQL-es projectekben egyaránt, hogy a kód konvenció személyenként változott. Azaz ha bedobod review-ra a patch-et, akkor attól függően lesz lefikázva vagy elfogadva, hogy ki nézi meg. Kb mint egy vizsgán, hogy melyik tanárnál vizsgázol.

Projectek illetve cégek különböző csoportai között egyre nagyobb véleménykülönbségeket láttam.

Ezzel együt lehet élni persze, a probléma akkor következik, amikor az egyik csoport megpróbálja rákényszeríteni a konvencióit a másik csoportra, illetve meg akar határozni egy globálisabb (pl céges) kódkonvenciót. 

Na, ez az amiből egyetlen egy sikeres próbálkozást nem láttam, de nagyon hosszú és anyázásig elmenő vitát jópárat.

"Persze, hogy benne van a céges policy-ban. Most írtam bele."

Én azt hiszem az lenne egy egyensúly közeli állapot, ha egy-egy projecten együtt dolgozó emberek a nem funkcionális elvárásaikat megbeszélnék nem egy bizottsági üllés keretében hanem inkrementálisan, ahogy jön. Azt is jobbnak hiszem, ha ezeket a szabályokat nem próbálják meg keményen bármi áron betartani. Ha funkconálisan teljesen jó és nem halom ganaj a kinézete, had jöjjön, aztán lesz időnk szépítgetni. 

Nyugdíj után bármire :-)

Ezt én sem tarom univerzálisan bevethető dolognak, a demokrácia nem mindenkivel működőképes, egyre több emberrel pedig egyre kevésbé.

Bzip2 buhera

Az angol wikipedia dump feldolgozásával bíbelődök szabadidőmben, a dump egy egyszerű XML formátumú file Bzip2 tömörítéssel. Csak a legutolsó ellenőrzött oldal szöveg van benne, de még így is 15 GB tömörítve. Az első ötletem az volt, hogy a commons-compress BZip2CompressorInputStream osztályával egyszerűen meghajtom. Az első teszt-futtatásakkor kezdett kiderülni, hogy nem muzsikál valami szépen, elég lassúcska az import. Az első ötletem az volt, hogy akkor többszálúsítom és az egyik szál csak Bzip2 kitömörítést hajt és PipedOutputStream-en keresztül átdobja egy másik szálnak, ami csak XML-t parsol és a mongodb-be mentést egy executor csinálja néhány szállal, hogy ott biztosan ne legyen fennakadás. Hát... nagyon büszke voltam az architektúrális szörnyszülöttemre egészen addig, amíg elösször le nem futtattam ugyanis az elbonyolítás eredményeként csak 3 százalékkal javult a feldolgozás sebessége. A magyarázat egyszerű, a bzip2 tömörítés annyira elviszi a processzoridőt, hogy ahhoz képest az XML feldolgozás és mongodb interanciók szinte semmi. Egészen pontosan összesen a 3 százaléka. Na ekkor töröltem le az elbonyolítást teljesen mert 3 százalékért nem érdemes kétszeresen elbonyolítani.

Azért egy "gyors" összehasonlítás érdekelt a bzip2 implementációk között:

• A linux bzip2 programja 40 perc alatt tömörítette ki a 15 GB-os dumpot
• a pbzip2 (parallel bzip2) 4 szálon meghajtva 20 perc lett (2 core x 2 thread van a laptopomban, szóval ez logikus) Ez nem rossz, de a pbzip2 nem része az alaprendszereknek általában
• Ugyanehhez a commons-compress-nek 100 percre volt szüksége. Véletlenül ilyen szép kerek szám, nem én találtam ki.
• Mennyi lenne ha csak IO lenne az egész: egy sata vincsi általában másodpercenként 100 megát fel tud olvasni szekvenciális olvasásnál, az 150 másodperc lenne elvileg, a gyakorlati teszt hajszál pontosan igazolta az elméletet :-)

Szóval azt találtam ki, hogy akkor beintegrálom a bzip2-t egy InputStream-ként és akkor a feldolgozást lehúztam kereken 40 százalékra. A bzip2-vel érdemes lenne még buherálni, csak ahhoz be kell lőni a procik számát, szóval kicsit komplikáltabb...

A szomorú az, hogy ez így csak linuxon fut, szóval jó lenne egy olyan InputStream, ami elmegy a bzip2-vel és fallbackel commons-collections-ra.

Ennyi lett a kód, és végülis ezzel sikerült kibékülnöm egyelőre.

Na, érdekességként az angol wikipédia adathalmazából azoknak, akik idáig eljutottak:

• 162396 állat és növényfaj, illetve rendszertani akármi
• 239847 település
• 26312 hajó - ez teljesen beteg...
• 11902 tudós, 7762 sportoló, 2679 verekedő, 91871 "egyéb személy"
• 13172 író és 20084 könyv
• 7508 folyó
• 3003 politikai párt - és vajon mennyi korrupció?

Developer Conference 2012 Brno, második nap

A fedora konferencia második napjáról jelentjük. Ma főleg (de nem kizárólag) JBoss előadásokat hallgattunk meg. Voltunk páran magyarok, többnyire magyarországi magyarok, a brnoiak csak néha tolták elő az orrukat :-)

Swimming Upstream - Jared Smith

A fedora project vezetője arról beszélt, hogy milyen egy ilyen linux disztró fejlesztését irányítani, igen ezzel az opensource dologgal nem zavarnálak titeket, de megemlítette valahol a java-t, beszéltünk az egyik szünetben és azt hiszem hasonlóan látjuk a helyzetet a fronvonal két szembenálló lövészárkából:
A java fejlesztők és a linux fejlesztők valamit kapni akarnak egymástól, de nem értik meg egymást és a végén senki nem kap semmit. Bukó, nem? Nyomozok a dologgal kapcsolatban, vannak fejlemények, majd mesélek egy másik posztban.

oVirt overview - Alan Pavec

Ez a munkám, imádatom és gyűlöletem tárgya, úgyhogy beültem hogy meghallgassam. Majdnem teltház volt a nagyteremben, örültem neki hogy ekkora érdeklődés volt. Sokan kérdeztek is. Remélem a hibákat sikerül kijavítani mielött ők is megtalálják...

RHQ4 - Lukás Krejci

Igen, a JBoss a redhaten belül egy külön ország. A java általában már csak így van. Szóval a RHQ-val java szervereket lehet igazgatni, több platformon keresztül. Lukás csinált jópár demót is, néha volt egy kis izgalom hogy most mi történik, de mindig jól sült el, pedig baromi nehéz live demót csinálni.

Whats new in JBDS 5.0? - Martin Malina

JBoss Developer Studio. Jaja, erről  a srácról csinálták ezt a vicces képet az üresnek látszó teremmel. Senki nem ült közel, mert akkor nagyon felfele kell nézni a kivetítőre. Közben én laptopon próbálgattam amit a srác mutatott (ugyanis nem vagyok pillanatnyilag képben jboss IDE-ből), meg is akadtam kicsit a forge konzolon, nekem ez ugyanaz volt, mint a springsource roo nevű cucca.

HornetQ - fastest JMS provider - Niroslav Novak

Ideje, hogy erdemben foglalkozzak a HornetQ-val. Ahogy néztem, könnyen beágyazható és szépen muzsikál. Igazából nem a sebesség az első és legfontosabb dolog, amit egy JMS szerver előnyei között fel tudok sorolni, de nem árt egyáltalán. Mondjuk nem annyira gyorsabb az ActiveMQ-nál. Érdekes lenne egy friss összehasonlítás, mit tudhat az ActiveMQ csapat új cucca.

Tomcat 7 and Tomcat 8 - Mladen Turk

Mit kaptunk a tomcat 7-től és mit kapunk majd a tomcat 8-tól? Állítólag a tomcat 7 sokkal jobb minőségű, mint a 6-os széria és ez a legfontosabb a legtöbb fejlesztőnek. (még nem találkoztam senkivel aki az async apit használta volna, annak ellenére hogy nagyon nagy dobásnak tartottam) A tomcat 8 olyan dolgokat tartogat, mint websockets... amire semmilyen standard api nincs, de legalább történik valami.

Egyéb...

Egyébként volt kaja, volt innivaló (kólás pohárból kofola, király), esti parti és voltak magyarok is, Magyarországról jöttek hárman. Páran nem mertek elindulni a hazai úthelyzet miatt sajnos. De akik jöttek, azokkal jót vitatkoztunk pár kérdésben :-)

A 'Presentation Skills' tanárnőt láttam mászkálni a kamerájával, aligha a linux kernel érdekelte, szerintem megpróbálja majd a geek-eket kicsit rocksztárosabbra faragni. Nem baj, rájuk fér :-)

Java Architekt - a gyakorlatban

István múlt heti postjára szeretnék egy kicsit bővebben reagálni, mint ahogy kifér egy pár soros kommentben. Technikailag nagyon korrekt definíció egyébként, de egy két dolgot hiányolok belőle és pár dologban buktatót látok.

Szóval szerintem...

Elösször is azt tenném hozzá, hogy amennyiben valaki - az architekt pl - meghatározza a szoftver archiktetkúrát, amiben a szoftver-fejlesztők dolgozni fognak, akkor annak az embernek a felelőssége az is, hogy a szoftverfejlesztők mennyire tudják hatékonyan végezni a feladatukat. Amikor egy java architekt dolgozik, akkor arra kellene koncentrálnia, hogy minnél egyszerűbb és hatékonyabb eszközöket adjon a fejlesztőknek és minden komplexitást csak valami megfelelő haszonért cserébe (customer-value) engedjen be. Én ezzel szemben nagyon sok fejlesztésben láttam valami totálisan elszállt marhaságot. A 97 things - és István is - ezt javasolja architekteknek: ne az önéletrajzodat fejleszd. Persze nem ez az egyetlen oka annak, hogy egyes java projectek krónikusan halálcsillaggá nőnek, van a dologban némi buta ego-fejlesztés is.

Többmillió java szoftverfejlesztő nevében követelem, hogy amikor kiderül, hogy egy java rendszer elcseszett ökörség lett, az architekt szüleit legalább annyira emlegessék meg, mint a szoftverfejlesztőkét!
A hegesztőmunkás is el tudja cseszni, de általában ezek az hibák általában nagyon könnyen javíthatóak. Ellenben architektúrális hibák többnyire végigkisérik a szoftver életét.

A másik észrevételem az lenne, hogy István definíciója nehezen illeszthető össze egy akármilyen agilis, iteratív szoftverfejlesztéssel. Elösször is azért, mert az architekt a definícióban elvágja a fejlesztőket a klienstől. Láttam már olyan embert, aki egész jól játszotta az információfiltert, de ez nagyon ritka, valamennyi infót mindenki elszór, a delay pedig minden embernél nagyobb, mint a másfél másodperces csúszás a telefonvonalban. Másrészt az agilis szoftverfejlesztés nem különít el hosszú tervezési szakaszt. A tervezési szakasz nálam a waterfall modell szinonímája. Aki ezzel jön elő, az általában valami olyasmit forgat a fejében. Aztán tipikusan a fejlesztés alatt kiderül hogy jajj, az úgy finoman fogalmazva is szuboptimális lesz, de akkor már bukó van, mert implementálni köll.

Aztán a harmadik észrevétel: egy-egy cég szokásait és procedúráit kitanulni időnként évekig is eltart, de legalább hónapokig. Én ha nagycég lennék, inkáb a belső emberek között keresném a leendő architektek legalább egy részét. Persze nagyon jól jöhet a más cégtől érkező tapasztalat is, de annak még jó sok idő, amíg kitapasztalja, hogy mi működik és mi nem működik valójában az új helyén.

Aztán még egy utolsó észrevétel a tanulással kapcsolatban: Nagyon jó, ha valakinek volt rá pár milkája hogy meghallgassa az Oracle/IBM/SAP/RedHat/Anyámtyúkja kurzusát, de az katasztrófa, amikor ezek után a kurzusok után, a fenti cégek technológiáit és termékeit lenyomkodja a fejlesztők, a cég, a kliens és a felhasználók torkán, ha jó, ha nem jó. Ilyet pedig már mindannyian láttunk. Én inkáb olyan emberrel dolgoznék együtt szivesen, aki nem csak az Anyámtyúkja technológiáit és termékeit ismeri, nem nyalta be a marketinget, hanem gyakorlati tapasztalatai vannak, látott elcseszett és pöpec projecteket. És ha ez megvan, akkor az architekt kurzus valószinűleg nem éri meg a pénzét.

Ö... oszt ennyi, na kitomboltam magam :-)

One RSS to rule them all

Csináltam egy yahoo pipe-ot, ami összeönti a magyar java blogok tartalmát egybe. Ez van most kint, oldalt, csak van belőle egy változat, amiben nincs benne a saját blogom RSS feedje. Nyilván azt minek ide kitenni :-)

• pipe (ha esetleg clone-oznád)
• rss - ha olvasnád vagy kitennéd valahova
• twitter acc - ha az rss nem elég trendi

Ha valaki blogját kihagytam, szóljatok! Sajnos nem sok az aktívítás, sok blog vált inaktívvá az utóbbi 2-3 évben :-(

Java kétségek

A múlt héten két ismertebb java podcast, elösször a basement coders, majd a java posse is azzal a kérdéssel foglalkozott, hogy vajon van-e jövő a java programozásban. A basement coders egyszerű választ adott, had fordítsam le magyarra:

Java programozással több pénzt lehet keresni, mint python vagy ruby programozással. Ebből a pénzből lehet piros ferrárit venni, ti meg python köcsögök biciklizzetek...

Söt -ezt is elmondta az arc- a legkirályabb cobol programozónak lenni mert abból már nemcsak ferrárit, de akár űrhajót is vehetsz, saját parkolóval az ISS-en. Szivesen pofánvertem volna, ha lehetne remoteból is, viszont sajnos jól mondta. A pénz jelentős motiváció ha munkáról van szó, és pedig munkáról van szó. Azt azért nagyon sajnálom, ha egyeseknek ez az egyetlen motivációjuk.
A java posse azért kicsit intelektuálisabban közelítette meg a kérdést, ennek megfelelően a véleményüket nem tudnám pár sorban összegezni.

De a lényeg elég pofonegyszerű. A java közösség nagyon elbizonytalanodott az utóbbi 2-3 évben. Ez nem is igazán most kezdődött:

• Az utóbbi 2-3 évben elterjedt egy csomó alternatív JRE nyelv: groovy, scala, clojure. A groovy persze itt van már jó 6-7 éve.
• Már korábban elterjedt egy alternatív alkalmazásfejlesztési módszer az Enterprise cimke nélkül. Ez a lightweight és az enterprise nem nagyon fér meg egy cimke alatt.
• Az Oracle opensource stratégiája nem mindenkinek tetszik. Meg hát nem csak az opensource stratégiája nem, de a Sun alkalmazottak jó része is elmenekült az egyesülés után. Az Oracle pereket és jogvitákat hozott, nem valami olyasmit, ami nagyon hiányozna bárkinek is.
• A java nyelv fejlődése nem a régi, a java 7-re 5 évet kellett várni (és még mennyit kell majd) és ami benne van az hát elég szerény. Azért remélem ezen a téren lesz még javulás, ha az Oracle nem vágott volna ki egyes speckókat a java 7-ből, még ennyi se lenne. 5 évig vártunk a clojure-kre és nem lett belőle semmi. Hatalmas meglepetés lesz ha valaha egyszer meglesz.

Java vs Oprendszer

Ma a gerrit-ről volt szó ebéd elött egy megbeszélésen, az egyik srác itt keményen próbálja betolni a fedora fejlesztői infrastruktúrára, hogy lehessen használni, de nagyon nehéz dolga van. Az előadás második felében tulajdonképpen egy vita bontakozott ki, hogy miért ilyen rohadtul nehéz java szoftvereket a linux disztrókba bejuttatni. Annyit elmondtak, hogy nekik újra kell fordítaniuk a forrásból a szoftvert. Ugyanaz a jar/war file lesz a végeredmény, de nekik akkor is újra kell fordítaniuk. Ezzel eleve van problémájuk, mert a GWT-hez van valami speciális dependency, amit alig tudnak megoldani. - kicsi flame szál a gonosz gúgliról. Aztán meg a fedorának nincs is policy-je a java war fileok telepítésére. Szóval egyhamar nem is lesz ilyen.

No eddig az, hogy a linuxosoknak mi a problémájuk a java programokkal. Nézzük csak nekem mi bajom van a linux-szal, annak ellenére hogy önként évek óta semmi mást nem hajtok...
A linuxokba örökké idióta kiherélt java futáskörnyezeteket telepítenek. A gcj egy tragédia, körülbelül semmi sem működik korrekten vele, az icedtea kicsit jobb, de konkrétan pár jboss termék is anyázik rá, ha azon indítják el. Egy új gépet mindig úgy kezdek használni, hogy leszedek egy használható sün/oracle jdk-t és mavent. Az már nem is érdekel érdekel , hogy yum-mal vagy apt-tal telepítsek jetty-t.

A java úgy indult el, hogy egy teljesen oprendszertől föggetlen nyelv és futáskörnyezet. Persze a linuxos rendszergazdák jobb szeretnének oprendszerbe integrált csomagokkal foglalkozni. A java viszont még mindig oprendszerfüggetlen és a szoftverfejlesztők nem igazán foglakoznak azzal, hogy akármilyen operációs rendszer vagy disztribúcióhoz csomagolják a cuccukat. Valljuk be elég sok meló lenne solarisra, debianra, ubuntura, fedorára ésatöbbi  linuxra is külön csomagokat legyártani.

Kicsit megpróbálok elmerülni a rpm/deb packagelés és a linuxerek lelki világába, hátha meglátom a fényt az alagút végén. Ehhez valószinűleg most vagyok a legjobb helyen :-)

Egyébként visszatérve a gerritre: hogy lehet hogy GWT-vel csinálják és mégis ilyen szarul néz ki?

Gyárlátogatás: Logging

A logging megintcsak egy érdekes és gubancos kis szál a java történetben. Nagyon szerény elvárásaim ezek lennének:

• Legfontosabb: Ha a logging el van csűrve, azért az alkalmazás még csak menjen!
• Lehessen konfigurálni a logging szintet
• Lehessen konfigurálni azt, hogy hova menjen a log - többnyire file, valami archiválós megoldással vagy méret vagy idő bontásban, fejlesztőknek stdout, had kapjuk az arcunkba :) Vannak egzotikusabb megoldások is
• Az nagggyon jóóó, ha nem kell újraindítani az appot a logging konfigurálása után. Ugyanakkor belátom, hogy egy évben csak egyszer van karácsony.

Mostanra sikerült odáig is eljutni, hogy a Logger-t kb így deklaráljuk:
private final static Logger logger = ...kakukk...

Ezt várja el a checkstyle, a PMD és a satöbbi. Nem tűnik nagy dolognak, de pl az avalon framework implementációi még bedobálták volna a komponenseknek egy setLogger metóduson keresztül. Persze nem kötelező így használni :-D

Nekem igazából nagyon szimpatikus ez a private final static dolog. A logger legyen a kód számára elérhető mindig. Ne írhassa felül semmi és ne lehessen null se. Amennyiben sikerült az osztályt betölteni, alighanem loggered is van. Innentől már nagy baj ezzel nem lehet.

Mit kellene logolni?

Hát kicsit izlés-codestandard-hitvita tárgya az, hogy mit mikor és hogyan kell logolni. Én nem hiszek a policy-kben, azt hiszem a józan paraszti ész valami ilyesmit diktálna, ha kellene a parasztoknak bármi ilyesmivel foglalkoznia: logolni azt érdemes, ami érdekelni fog hibakeresés közben, és persze csak olyan szinten, amilyen szinten keresni fogsz. Minden más csak a helyet fogja zabálni a szerveren. A logging frameworkok között enyhe eltérés van a szintek tekintetében. Azt hiszem van, ahol nincs trace szint, hanem debugnál kezdődik. Nekem a nagyon sok szint használata nem tetszik, nem tűnik praktikusnak.

Ja igen, bonyolult és anyázásig menő viták tárgya az is, hogy ha esetleg valami stringet hozunk létre a loggernek, amit logolunk, akkor csekkoljuk-e körülötte a debug szintet egy if-fel. Erre gondolok:

if(logger.isDebugEnabled()) {
  logger.debug("Baromira fajt osszerakni ezt a stringet: "+getTerribleString());
}

Szerintem ezzel a legtöbb alkalmazásban nem lehet mérhető teljesítményjavulást elérni. Inkáb csak a kód komplexitásának növekedését. Illetve akinek tényleg már csak ez segített, annak had gratuláljak a kiválló termékhez.

System.[out|err].println()

Na ez a logging elötti logging volt. Már rég megástuk a sírját, már rég ott térdel a szélén, de még mindig nem húztuk meg a ravaszt. Nagyon sokan használnak még ma is ilyesmit. Ezt azt hiszem korrekt tudatlanságnak és/vagy igénytelenségnek nevezni.
Na jó, szóval ez trehányság, de akkor mit kellene használni helyette? A válasz erre kb 2-3 évente változik akár még egyetlen fejlesztő esetében is.

log4j.properties - köszi Bocinak a megosztásért :)

Log4j

Ha jól emlékszem a log4j volt az első komolyan elterjedt logging api.
A log4j-ről tudni érdemes dolgok 99 százalékát tudod, ha tudsz egy log4j.properties file-t írni. Na, ez az a dolog, ahol kiválló alkalmak adódnak a dolgok elcseszésére: illik nem belecsomagolni a log4j.properties file-t a csomagodba. Ezt azért a mainstream opensource libraryk tudják, de enterprise körökben frekventált elcseszés tárgya. Ez még mehetne a multkori konfigurációs kérdéskör boncolgatásához.

Ennyi: Igen, kell a log4j.properties file - pontosabban jó ha van. De ez a konfiguráció része, nem csomagolhatjuk a kódhoz.

Alternatív...

A log4j sikere után sok alternatív logging api jött. Az alternatívok közül legtöbbet a commons-logging projectet lehetett látni. Ha jól tudom a sikerének oka az, hogy az apache projectekben kötelező (volt?). Ez elég sovány ok :-) Mindenesetre a commons-logging már végülis facade jellegű. Azaz az API mögött végülis valamibe logol bele. Valamelyik másik logging frameworkbe.

java.util.logging

A java.util.logging így visszatekintve rá egy szomorú példa a JCP töketlenségére. Aki ragaszkodik a szabványokhoz, az biztosan használja is, de más okot nem is tudnék rá. Az az egy nagyon tetszett benne, hogy a jconsole-n keresztül lehet babrálni a logging szinteket. Még talán akkor veszi az ember használatba ha valamilyen oknál fogva nem akar semmilyen dependency-t. Ultra-minimalista cuccokhoz, aminek nem kell semmi, csak egy JRE, és megy.

slf4j

Simple Logging Facade for Java. Itt tart a történet. Ma kb mindenki slf4j-vel logol, én is. Egyszer valami podcastot hallgattam ennek az előnyeiről, és ilyeneket említett a csákó, hogy végre Loggernek hívják a loggert, nem Log-nak, mint a commons-logging. Hát ez elég sovány ok azért, ebben azt hiszem egyetértünk :)
A slf4j-nél tipikus elba, amikor valakinek az APIja nem csak a slf4j-api-n dependel, hanem berántja valamelyik logging rendszerhez kötő részét (pl tipikusan slf4j-log4j13-at amikor te már berángattad a slefn-log4j12-t). Ugyanis nem, ezek a dolgok nem férnek meg békésen egymással a classpathon. Természetesen ez egy gyógyítható betegség (pl maven dependency exclude), de néhány bosszús pillanatot sikeresen össze tud hozni.

...és végül: log4j :-)

Akárhogy is, de az összes konfigurációban, amit eddig láttam a facadeken keresztül a végén a logging üzeneteidet a log4j kapja meg, és file-be nyomja be. Az üzemeltető csapatok a log4.properties-t keresik, ha debugolni kell valamit. Ennyi.
Szóval ebből a szempontból a történet marha hosszúra nyúlt, de a lényege nagyon keveset változott.

A java elött

Nem tudom mennyire rendelkeznek a java elődei logging apival, amennyire emlékszem amit a CGI scriptekben stderr-re írtunk, na az volt a log, a stdout-ra, na az meg a kimenet. Nem túl kultúrált. A C kultúrám megintcsak félelmetesen alacsony, C/C++-ban úgy logoltunk, hogy precompiler direktívaként megadtuk a log szintet. Nyilván újrakonfignál újra kell fordítani, ezt nem nevezném valami baráti megoldásnak.

Update: átneveztem ezt a postot, hogy kicsit kiemeljem azt hogy nem arról szól, hogyan kell logolni, hanem arról, hogy miket láttam tényleg. Többi ilyen.

Gyárlátogatás: konfiguráció

A következő dolog, amit mindenki totál máshogy csinál a java/j2ee/jee környezetben az a szoftver konfigurációja. A téma sajnos nem annyira "egyszerű" mint az a képesség, hogy a verziószámot meg tudjad mondani, így hát igen szép számban van rá megoldás. Ezek a megoldások még csak nem is diszjunktak, simán átfedik egymást. Egészen biztos, hogy nincsen két ugyanúgy konfigurálható java szoftver. Illetve csak ha pont ugyanaz az ember írta mondjuk 1 héten belül. Szóval oltári buhera zajlik a téren. Mint mindig.

Elvárások a konfigurációval kapcsolatban

Ha én lennék az admin, most így fejből ezeket várnám el az appoktól és fejlesztőiktől:

1. Legalább az minor release-k között őrizze meg integrítását. Azaz a 1.0-hoz bütykölt konfig had menjen már el a 1.0.1-gyel is.
2. Ne az alkalmazásba legyen belebuherálva (WEB-INF/classes, satöbbi), hogy amikor az upgrade során rm -rf paranccsal kezeled a régi verziót (ja, backup, csókolom!) ne vesszen el a régi bugokkal együt a konfiguráció is. Legalább a környezet-specifikus konfiguráció ne az appban legyen!

Mint fejlesztő, nagyon szeretem azt, ha nem kell a fél életemet a fejlesztői környezet összebuherálásával töltenem. Értelmes alapértékek (akár pl egy beágyazott DB), könnyű felülcsűrhetőség.
Illetve ezt csak nagyon szeretném, baromi ritka az ilyen. Remélem nem úgy képzelitek el a halálcsillag építését, hogy kiszedik a dobozból, bekapcsolják és működik.

Plain Property file-ok

A property fileok ősi java feature és a legtöbb rendszer még mindig felhasználja a konfiguráció tárolására. Ezzel persze nem rossz dolog. Máig ez a legtöbb konfigurációs megoldás alapja, de persze a tiszta és legalapabb formája az, amikor pl a konstruktorban megkapod a Properties ojjektumot magát és bányásszad ke belőle azt, ami köll. Volt egy ennél kicsit szofisztikáltabb megoldás, ami csak a teljes konfig egy részét passzolta oda... lényegtelen. Ezek tipikusan az IoC-nélküli rendszerek.

Á igen, IoC

Az IoC egy olyan ötlet volt, amiért jópárszor leégettem magam azzal hogy próbáltam megmagyarázni a főnökeimnek valamikor régen, és néha még mostanában is. Ötlet: "Do not call me, I will call you!" Azaz az IoC konténer majd beállítja neked a konfigot, összekapcsolja az ojjektumaidat, elindítja az appod ha kész, illetve elhasal ha nem sikerült (ez esetben az jó, hogy hülyeséggel nem indult el). Ebből eleinte még két faj létezett, az intrusive (pl Avalon) és a non-intrusive, tipikusan POJO jellegű. Az elöbbit mára csak CVS-múzumokban találod. Az utóbbiból se a spring volt persze az első, csak a legnépszerűbb. Volt még elötte picocontainer, nanocontainer, és már a fene se emlékszik mik. Ma Spring, Guice, és az EJB is sok inspirációt kölcsönzött a téren ezektől a projectektől. Vitatkozhatnánk róla, hogy eleget-e vagy sem, de igazából nem érdekelne.

Még itt szeretném megemlíteni azokat a böszme nagy XML fileokat amiket írunk az IoC frameworknek és együt jönnek az appal szinte minden verzióban kicsit úthuzalozva és átkombinálva. Szerintem ne akarjátok, hogy az admin ebben matasson! Az merge-hell! Sírás-rívás, jajjveszék, rollback, cancel, és hasonló kulcsszavak jutnak róla eszembe. (Egy külsős fejlesztő szívatott ilyennel éveken át)

Spring, PropertyOverrideConfigurer és PropertyPlaceholderConfigurer

Ezt a két dolgot igazából nagyon szerettem a spring-ben. Ez megoldás arra, hogy az appcontext-ben összeállított konfigurációt felülcsűrd egy property file tartalmával. Tehát ide lehet tenni az X-et ennek én nagy rajongója vagyok még most is. A különbség a két dolog lehetőség között, hogy az override configurerrel mindent felül lehet csapni (söt, olyat is ami az appcontextben nem is volt benne), míg a placeholder configurer csak a placeholdereket helyettesíti be. Azért gyanús, hogy az előre kigondoltakon kívül jól jöhet, ha időnként más beállításokat is megváltoztathatsz. Természetesen az a placeholder configurerben viszont szimpatikus, hogy az éles rendszerektől megköveteli az előre definiált placeholderek értékének beállítását, különben nem indul el. Ugyanakkor még mindig jobban szeretem, ha a rendszer értelmes defaultokkal jön, és bármít felül lehet benne csapni.

Mindkettőnek van némi hiányossága. Pl listákat és map-eket nem kezelnek. Na erre mindenkitől láttam valami saját szintaxist és saját megoldást.

Jó, de hova?

Azt a kérdést, hogy hova tegye a rendszergizda a konfig fileokat, illetve az app hol keresse, az izlés és hitviták tárgya. Volt egy melóhelyem, ahol a unix filerendszerhez kellett igazítani a struktúrát. A konfig az etc-be, a program kód meg a usr-be (usr-be?!?!?!), felhasználókkal kapcsolatos dolgok talán a home-ba, adatok a var-ba. Igen, még mindig java szoftverfejlesztésről van szó. Vicces volt egész addig amíg rá nem jöttem hogy komolyan gondolják. Utánna már nem :-D

Mindenesetre a legtöbb program egyszerűen csak a classpath-on keresi a konfigját, többnyire {appnév}.properties alatt. Ez talán a legértelmesebb dolog, de minden appszerveren máshova kell dobni, hogy a classpath alatt legyen. Had sírjon aki migrálni merészel!

JMX!

A JMX még belerúg ebbe a témába kicsit. JMX-en keresztül beállíthatod az alkalmazásod konfigurációját, meghívhatsz rajta maintenance metódusokat, stb. A JMX király dolog, de arról nem gondoskodik, hogy a container újraindítása utánra is megmaradjanak ezek a beállítások. Az az app gondja. Valószinúleg ez lehet az oka annak, hogy hibakeresés közben láttam csak JMX-et, konfiguráció beállításhoz soha. Nevezhették volna inkább java debugging extensionnak.

JNDI?

Ha már a container szolgáltatásainál tartunk. Sokat tűnődtem rajta, hogy a JNDI miért csak annyi lett, amennyi lett. Semmi mást nem csinálsz vele, csak java.sql.Datasource és java.mail.Session objektumot halászol ki belőle, többnyire hardcode-olt címről. Az innen kihalászott objektumok előre fel vannak konfigolva a környezet beállításaival: hol az adatbázis, milyen adatbázis, hány kapcsolatot nyithatok rá, satöbbi, hasonlóan az smtp szerverrel. Na jó, még arra is használjuk néha, hogy a LDAP szervereken kurkásszunk valamit. Ennyi?
Tehát akkor az adatbázis és SMTP eléréssel kapcsolatos infókat akkor ott tartjuk. A többit miért nem? És ha a többit nem ott, akkor azt miért? Nem lenne jobb egybe tartani?
Kipróbáltam pár appszervert, a GUI/web-es felületeken keresztül egyik sem volt hajlandó a fenti kettőtől eltérő ojjektumot elhelyezni a JNDI fában. Kézzel be lehet haxolni.

Adatbázis

Remélem mindenki érzi, hogy egy komoly robosztus ACID-compliant replikált és backupolt nagy teljesítményű, 24/7 365 felügyelt RDBMS a legrojszrojszabb hely a világon, ahova a konfigját az ember berakhatja. Szóval legkevésbé sem ritka, hogy az appok az adatbázisban tartják a konfigjukat. Akkor már csak az a kérdés, hogyan éred el az adatbázist, de ezt többnyire a JNDI megválaszolja.

Én nem érzem a késztetést :-) Csupán technikai oldalról, nem értem mi haszna van az ACID viselkedésnek akkor, amikor olyan adatokról van szó, ami csak akkor változik, amikor éppen bütyküljük a rendszert. Sokkal hasznosabb ha gyorsan és egyszerűen hozzá lehet férni, mindig. Továbbá nagyon nagyon szép ha pl valami verziókövetőben tárolhatjuk, hogy tudjuk ki buherált rajta és mit, mikor hogy nézett ki. Egy text-file sokkal szimpatikusabb. Na ezt talán inkáb oda kellett volna írnom a propertyfile-hoz. Na mindegy, úgyis elcsesztem már pár helyen ezt a cikket.

Gyárlátogatás: verziószám

Tipikus igény a szoftverekkel szemben, hogy meg tudják mondani a saját verziószámukat. Ez főleg azért kell, hogyha a kedves felhasználó meglát egy bogarat benne, meg tudja mondani, hogy melyik verzióban látta. Legalábbis hogy esélye legyen rá. Erre szedtem össze az általam eddig látott és használt megoldásokat, azzal együt hogy mi a tipikus elba**** velük kapcsolatban. Nemcsak hogy egyik sem tökéletes megoldás, de mindegyik szerintem elég töketlen. Persze a sajátját mindenki szereti :-)

Build script

Ez volt a leggyakoribb. Az ötlet annyi, hogy amikor buildelsz, akkor generáljon neked egy számot bele egy file-ba, amit valószinűleg besúvaszt utánna a classpath-ra. Ezt persze csak inkrementálgatni kell. Láttam olyat, hogy ez a file csak úgy "floating around" azaz akik release-t csináltak azok tudták a számozást, aztán volt olyan hogy visszakommitolták legalább időnként a verziókövetőbe. Ja még ezen belül is két különböző műfaj van, van aki verzió számot tart számon, van aki build számot. Szóval a kombinációk száma igen magas.
A tipikus elba:

• Amikor nincs meg a file a classpathon, akkor valami törik
• Elfelejted inkrementálni a build számot
• Elfelejted a verziószámot bepakolni a verziókövetőbe, mielött tegelsz

Database, config

Olyat is láttam, hogy az emberek a konfigurációba, vagy gyakrabban az adatbázisba írják bele, hogy mennyi a szoftver verziószáma. Az egyébként tetszik, hogy az adatbázisban valahol benne legyen az, hogy milyen patcheket hajtottak végre rajta és milyen verzió satöbbi a jelenlegi schema, de akkor most az operátorra bíztuk, hogy felülbuherálja a verziószámot.
Elba:

• Azon felül hogy anyukádat emlegetik közben, még rizikó tényező hogy az operátor valamikor visszacsinálja vagy átírja, vagy éppen ellenkezőleg: elfelejti átírni.
• Az fenti elfelejtések simán ide is passzolnak

SVN-way


Ezt én találtam ki és hát primitív mint a szerzője: Csinálj egy osztályt pl Version néven, tegyél bele egy final static String mezőt, aminek az értéke legyen ennyi: "$HeadURL: http://svn.blf.hu/fubar/trunk/src/main/hu/blf/Version.java $", plusz egy metódust, ami fubar és az src közül kibányássza neked ami ott van: pl ennyi: StringUtils.substringBefore(StringUtils.substringAfter(version, "/fubar/"), "/src/"), ne felejtsd el a végén az svn property-k között a keywords-be beleírni azt hogy "HeadURL".
A build numebert nyilván hanyagolja. Csak azt adjuk oda bárkinek is, amit szépen betegeltünk.
Jó, a nyilvánvaló hátrányok elött felsorolnám hogy miért szerettem ezt:

• Soha nem sikerült elszúrnom :) A Version osztály mindig valami értelmeset ad vissza. Pl azt hogy "trunk". A legdurvább elcseszés esetén semmit, de nem NullpointerException-t.
• A release során simán meg lehet róla feledkezni. A release nálam ennyi: mvn release:prepare release:perform (így "howto release" manuált se írtam soha)
• Ja és ez az egész substringes dolog csak a cicoma rajta, sima statikus text/html fileokkal is működhet, ha érti a felhasználód a HeadURL-t hogy mi az.

Akkor jöjjön a hátrány:

• Totálisan SVN függő - azért volt ilyen a CVS-ben is, de arra már kiemlékszik
• Az SVN-re meg most úgy fintorgunk mint a CVS-re úgy 6-7 évvel ezelött. Valahogy akkor jött ki az SVN, nem?

Még annyit a megoldás portolhatóságáról, hogy a git pl nemcsak hogy nem csinálja, de elvben is ellenzi. Linus Torvalds szerint írjál scriptet. Szerintem meg ... :-) Na mindegy, nekem ez nem tetszik, túlságosan könnyen elcseszhető. Meg bújja a git elba manuálját az, akinek nincs jobb szórakozása.

Ennyi... részemről

De kiváncsi lennék a ti tapasztalataitokra, linkeljétek vagy írjátok ide nyugodtan! Köszi előre is!

Firewall vs JDBC

Ma egy egész érdekes dologot találtunk meló közben. Érdekes egybeesésként ez ugyanaz a gubanc, mint amiről az egyik előadó is beszélt a 33degree konferencián, csak ő valami légiközlekedéssel foglalkozik. (hmmm, biztonságban érzitek magatokat?) A probléma alapja az, hogy a firewall-ok eltépkedik időnként a TCP kapcsolatokat. Egészen vicces, a szerver nem kapja meg a kérést, a kliens meg azt hiszi hogy elküldte, köztük a firewall röhög a markába, te meg nem érted miért áll a kliens, miért nem csinál semmit a szerver, és egyáltalán mi a rák történik. Ne tőlem kérdezzétek, hogy miért annyira fontos firewall-t telepíteni például az adatbázisod és az appszerver közé, szerintem ha valaki felhakkolta az appszervered és megvan az adatbázis kapcsolat akkor már régen rossz, de...
Ennek a problémának általában áldozatul esik néhány protokol, a lényegesebbeket említve RMI és valószinűleg minden adatbázis kapcsolat, általában a hosszú JMS kapcsolatok is, LDAP. Amit nem üt, az a HTTP nyilván, mert az bontódik amint lement a kérés és a válasz. Más most nem jut eszembe, ami jól működik vele :-)

Minden protokolra nem tudok orvosságot, de a commons-dbcp képes csekkolni az adatbázis kapcsolatot mielött odaadná a alkalmazás kódnak. Az 1.2-es verzió csak annyit tud, hogy elküld egy dummy kérdést a szervernek (tipikusan egy "select 1") és ha sikeresen válaszolt az adatbázis, akkor adja csak oda a kapcsolatot. Nem láttam még olyat, hogy a validation query elhasaljon, tulajdonképpen kicsit haszontalannak tűnik. Viszont amikor a fenti firewall gubanc beüt, akkor fentakadsz már a validation query-nél is, a kódod meg se kapja a vezérlést. Na erre a problémára ad megoldást a DBCP 1.3-tól kezdve a validationQueryTimeout paraméter. A DBCP 1.4 is már jó egy éve kint van, de amennyire látom még a legfrissebb cuccokban is az 1.2 van. Szóval egyéb hijján, akinek ez probléma, az kénytelen felülbuherálni.

Hát csak ennyi, remélem átérzitek :)

33 degree konferencia, Krakkó

A héten TVik-kel ketten elugrottunk a 33 degree java konferenciára Krakkóba. Csak mi ketten voltunk magyarok és talán egyéb külföldiből sem volt túl sok, ha leszámítjuk az előadókat. Viszont egy percre sem bántuk, hogy elmentünk, mert az előadók tényleg nagyon jók voltak. Nagy szükségem volt már egy ilyen pár napos cuccra, ahol kicsit távol a mindennapi munkámtól foglalkozhatok végülis a munkámmal :)
Az egész teljes költsége ha jól számoltam a végére úgy 80ezer forint lett utazással, szállással és regisztrációval együtt. Magyar fizetéshez kitalált összeg.

Alapelvek az előadások kiválasztásához: nem érdekel az "enterprise" és a "standard", ezek lejártak és beégtek. Más irányokban keresek tudattágítót.

Vettem pár papíros könyvet is:

• Javascript Patterns - hát igen, sajnos szükség van arra, hogy rendre szoktassam magamat ezen a téren
• The Myths of Innovation - a nálam szokásos tech-szkeptikus kategóriában
• 97 Things Every Software Architect should know - fogalmam sincs lesz-e ilyen szép címem valaha, túl nagy pofám van hozzá, de azért megpróbálok okosodni arról, hogy milyen egy jó architekt

No nézzük, előadások...

Linda Rising: Deception and Estimation

Linda Rising arról beszélt nekünk bemelegítőként, hogy az ember totálisan nem alkalmas hardver matematikailag pontos becslésekre. Egyszerűen az evolúciós multunkból adódóan.

Házi feladat nekem: A groupthink probléma megelőzését lökdösni a melóban, amíg nem működik.

Matt Raible: Comparing JVM web frameworks

A legfrissebb web-framework helyzetértékelés és összehasonlítás. Igazából, én nem használok web frameworköt, csak MVC-t és bár utálom kézzel hímezni a html-t, rájöttem arra, hogy ezekkel nem lehet ugyanazokat a trükköket megoldani, amiket a kézzel hímzett html-ben. A kedves ügyfél meg addig nem boldog, amíg pontosan az meg nincs, amit megbeszéltünk. Szóval ebből a szempontból ez a sok framework csak akkor érték, ha az ügyfelet le tudod beszélni a sok ökörségről és jópár értelmes dologról is.

Nathaniel Shutta: Hacking your brain for fun and profit

Rövid howto az emberi agyhoz, hogyan kell használni ahhoz, hogy optimális teljesítményt adjon egész hosszú időn át. Például érdemes aludni, esetleg egyet szunyókálni délután (amennyiben nem lép fel a kirúgás kockázata, de egyébként a legtöbb meeting pont ilyenkor van), sport, satöbbi.
Az ürégnek nagyon érdekes előadóstílusa van, biztos sokat gyakorol :)

Nathaniel Shutta: Going Mobile with JQuery

Ismét ugyanaz az előadó, de ezúttal valami hasznosabb dologgal. Ötlet: miért akarnál külön IPhone-ra,  Windows7-re és Android-ra is külön klienst fejleszteni. Megtehetnéd ugyanezt szimpla HTML-lel is, és ebben segít a JQuery mobile. Úgy tűnik nagyon könnyen lehet vele összedobni kis webappokat és alighanem működni fog offline módban is...

Házi feladat: kipróbálni mit tud.

Shang Shin: Android Programming

Kemény 3 órás Android fejtágító, amin Tvik már majdnem elaludt (a vonaton alvás nem a legpihentetőbb dolog) de nekem nagyon jól jött, mert elég szegényes az android tudásom. Komolyan tetszett az egész. A csóka egyébként Sun-os volt, de az Orékülből nem kért, csinált inkáb egy saját kis java okosítócéget.

Ennyi volt az első napon, a többit megírom máskor mert holnap meló és addig még aludni is kellene, mint arra Schutta úr is rámutatott :-) Fogok is aludni, csak elöbb kipróbálok ezt-azt...