Eclipse Democamp

Ezúttal egy VIII. kerületi vendéglátóipari helyen került sor az Eclipse Democamp-re a b2i szervezésében. Még nem voltam ilyen rendezvényen eddig, de nagyon meglepett a baráti, unconference jellege. Rögtön meg is kérdezték ki vagyok és akarok-e valamit előadni, de nem volt semmi érdekes a tarsolyomban. Magamhoz vettem némi búzasört.

Az első demóban arról volt szó, hogy EMF (Eclipse Modeling Framework) segítségével összerakunk egy modelt (a konkrét példa egy CD adatbázis volt), GMF (Graphical Modeling Framework) -fel pedig csinálunk neki egy grafikus szerkesztőfelületet, amin egy osztálydiagramhoz hasonlóan lehet szerkeszteni a modelt természetesen Eclipse környezetben. Belül a GEF (Graphical Editing Framework) -t használja a program.

Hozzáértő kezek között 10-20 perc alatt össze lehet rakni egy ilyen bonyolultságú modelt és a szerkesztő felületét. Találkoztunk egy-két buggal a demózás közben, amivel viszont nem árt tisztában lenni. Mit mikor kell újrafordítani, újraindítani. A szerkesztett alkalmazás természetesen egy másik Eclipse példányban fut amit minden iterációs körben nem árt újraindítani -bár lehet hogy ezt meg lehetne úszni valahogy. Elmondásuk szerint 6 hónap alatt raktak össze egy komplex egészségügyi adatokat közvetítő rendszert a GMF betanulással együtt. A modell maga nem kell hogy java legyen, köztes típusokat használ.

Ha konkrétan ilyen feladattal találkoznék akkor mindenképpen megfontolnám az eszköz használatát.

Második előadásként a FOT-os srácok mutatták be a teszt framework-üket amit már jópár éve használnak banki alkalmazások tesztelésére. A dolog lényege hogy Eclipse környezetben futtatják a teszt szekvenciákat. Van a banki felületet -a teszteléshez szükséges minőségben- leutánzó GUI, részletes (zöld, sárga, piros) fa/log jellegű eredmény megjelenítés, riport küldési lehetőségek. Ha jól értettem egy bizonyos middleware rendszer tesztelésére csinálták, amit viszont néhány bankban aktívan használnak. Szintén ha jól értettem, közeli-távoli terveikben szerepel, hogy ne csak ezt a konkrét middleware rendszert lehessen vele tesztelni.

A harmadik rögtönzött előadásban Eclipse tippekről és trükkökről volt szó, azaz kedvenc billentyűkombinációkról, funkciókról. Úgy láttam hogy ezen a téren elég kiműveltek az emberek, a jelenlévők között majdnem mindenki ismert már majdnem minden trükköt.

Elvileg nagyjából fél évente van ilyen rendezvény. Megpróbálok elmenni a következőre, tovább maradni, többet cimbizni és esetleg előadni valamit.

A nagy konferencia persze idén is kimarad -ezúttal saját megfontolásból- de majd szorgalmasan olvasom az élménybeszámolókat.

JUM

Három előadás volt a tegnapi JUM-on, ami végülis nem tudom hányadik alkalom. Itt balra pedig a JUM.hu logó látható, ami már a Devoxx-on is kinn van. Hurrá! Szóval a három előadásról:

REST = REpresentational State Transfer

Lényege, hogy a SOAP és CORBA bürökratizmusa helyett törekedjünk lényegretörő agilis (hogy divatos szót is használjak) megoldásra. Szép hogy SOAP menne email-en keresztül de minek ha a legtöbb adott problémánál nincs rá szükség, viszont a HTTP infrastruktúrája tökéletes (?). Sok mindenre ad jól kimunkált és széles körben letesztelet megoldást. Én már az előadás előtt utánaolvastam néhány dolognak, de nem akartam ilyen kérdésekkel kukacoskodni, hogy vannak-e REST-ben (HTTP-ben) lehetőségek push-ra, aszinkron üzenetváltásra, meg amúgyis tudom a választ. Aki még tudni akarja:

• Áttekintő cikk a javaworld-ön
• mp3 Interjú Stefan Tilkovval németes akcentussal angolul. További linkek a címen.
• S.T. gyakorlatiasabb cikke
• Szkeptikusoknak
• Wikipedia
• A JSR-311 home-ja ez a kapcsolódó JSR. (JAX-RS) Meg kell jegyezni, hogy a REST egyáltalán nem nyelv- és platformfüggő. A J2EE1.6 része lesz, de a .net 3.5-ben is akarnak REST supportot. Ezenkívül a szabvány nem akar prezentációs formátumokat -és még sokmindent- lefektetni. Ha jól értettem egy speciális szervlet segítségével már most minden további nélkül használható a megoldás.
• API 1.0 nem bonyolult, nem sok. Annotációkra épít, 1.5 alatti Java-t nem is fogja támogatni.
• Jersey - a referencia implementáció.
  
• Bónusznak RESTful URLs with Wicket

Abszolút pozitívan állok a dologhoz. Egyébként már 5 éve is csináltunk ilyen megoldásokat, igaz csak prototípusnak. HTTP-val kommunikáltunk mindenféle registry és WSDL karbantartása helyett. Vicces lenne ha egy az egyben kimaradna az életemből a SOAP, ami nem is szimpatikus. Fejléc, boríték, nemtudommi... A REST a szemantikus web-et (mégegy divatos szó) is jobban ki tudja szolgálni szerintem, de ebbe most nem akarok belemenni. Jobban be lehet járni és feldolgozni pókokkal, összetársítani tartalmakat, asszociálni, szolgáltatásokat építeni meglévő szolgáltatásokra.

Vannak még nyitott kérdések, pl. hogy a JSR-311-et hogyan fogják összepárosítani valódi prezentációs technológiákkal pl. GWT, JSF, Wicket. Ha elgondolkodnák rajta lehet hogy meg is lenne a megoldás, de az előző postban leírtak miatt nincs lehetőségem erre.

Jazz

Második téma a Jazz volt, ami egy kollaborációs eszköz az IBM háza tájáról. Van benne verziókövető, issue tracker (vajon hogyan fordították?), támogat agilis módszertanokat pl. scrum. Eclipse-ben is működik és azon kívül is valami webes felülettel. Tervezik az integrációját egyéb fejlesztői eszközökbe is. A Jazz fejlesztésére is Jazz-t használnak. Jövőre elvileg kész lesz a magyar fordítás. A Javaposse 211. epizódjában egy interjú hallható Erich Gamma-val Tim Francis-szel az IBM-től. 18 perc környékén a Jazz is szóba kerül.

Glassfish V3 prelude

A mikrokerneles Glassfish pre-béta verziója. Sokminden nincs még benne pl. EJB3 konténer, emiatt inkább egy Tomcat-re hasonlít. Egyelőre az jött le hogy nem kell ezt még igazán komolyan venni, nem kell tőle sokat várni. A koncepciói kicsit ijesztőek, pl. hogy amikor először akarok admin konzolozni akkor jön rá hogy le kéne töltenie a netről az admin konzol csomagját. Hát, hmmm. És ha akkor akarok először használni valami csomagot amikor történetesen csak intranet elérésem van?

Jövő

A következő JUM elvileg 2009 január harmadik szerdáján lesz és valószínűsíthető egy OSGI előadás (ez nem tudom végül bevállalódott-e), egy JPA2 esetleg és egy Scrum, ami egy módszertan csirkékkel és disznókkal.

Kösz a szervezést karenin-nek!

Produktív zörejek

Azért nem írtam semmit októberben, mert a jelenlegi melóhelyem alkalmatlan erre a tevékenységre. Egy dolog hogy a monitorom gyakorlatilag publikus tévé, de ez nem is érdekelne mert a feladatomat rendesen megcsinálom. Az hogy néha elolvasom a híreket, szerintem belefér.

Az jelenti a nagyobb problémát, hogy ez nem kifejezetten egy fejlesztői munkahely, hanem egy telemarketing témával foglalkozó társasághoz vagyok bedobva, ahol folyamatosan csörögnek a telefonok és olyan témák repkednek a fejem fölött amik távol állnak tőlem mint Makótól Jeruzsálem. Permanens beszéd 4 oldaltól 8 órában. Ez abszolút szétforgácsolja a gondolataimat, jobban mint amikor a Boros-Bochkor-t kellett hallgatni reggelente egy másik helyen. Szóval egyrészt a produktivitásom 50%-on ketyeg, másrészt nem tudok figyelmesen elolvasni technikai jellegű írásokat, nem tudok egy k.b. mondatot rendesen megfogalmazni. Némileg segít ha felrakok a fejemre valami zenét, de sajnos néha nekem is válaszolnom kell kérdésekre, nem tehetem meg hogy elszigetelem magamat.

Nekem tökéletes csend vagy enyhe technikai neszek kellenének hozzá, hogy jól tudjak dolgozni. Néha felvet valaki valami programozástechnikai témát -ez kellene nekem. De tudom hogy van akit megöl a csend, kell neki valami zene. Van akinek a Sláger rádió, van akinek az MR2, van akinek a legújabb Metallica album. Neked milyen hangviszonyok kellenek hozzá, hogy produktív legyél? Többet is be lehet jelölni.

logging vs debugging

Az utóbbi időben több olyan társasággal is találkoztam, akik folyton egy debugger előtt görnyedtek, emellett eléggé hanyagolták a debug szintű loggolást. Nekem nem volt szimpatikus ez a megközelítés. Láttam félrecsúszott helyzeteket is, amikor hatékonysági, többszálú vagy tranzakciós (vagy ezek kombinációi) problémákat akartak megoldani a srácok csupán az IDE-be beépített interaktív debugger segítségével. Persze nem igazán sikerült.

Arról az esetről nem is beszélve, amikor kiment a szoftver élesbe és logok híján telefonon kellett a felpaprikázott ügyféltől kérdezgetni, hogy mi volt pontosan a hibajelenség és mi volt pontosan a tevékenység, amit csináltak. Egy jó log-állomány fekete dobozként vagy önvédelmi eszközként funkcionált volna, mert pontosan fel lehetett volna deríteni a szoftver gyenge pontjait, vagy hogy nem rendeltetésszerűen használták.

Nekem azért sem szimpatikus az interaktív debugolás, mert program státuszának adott pillanatbeli vizsgálata elveszi a figyelmet a dinamikus működésről. Csak előre lehet lépkedni, de ki tudja visszakövetni, hogy mi volt ötven lépéssel ezelőtt és mi lehetett volna, ha egy bizonyos érték valahol máshogy van beállítva? Csak egy keskeny ösvényt járnak be ami egy adott prekoncepció alapján születik, holott inkább a kvantumszámítógép elv követése lenne a hasznos, ahol egy kódrész lefutásainak összes lehetséges variációját figyelembe vesszük. Ezt pedig leginkább sok tapasztalattal, tiszta fejjel és sok intuícióval lehet megcsinálni.

Kíváncsian hallgattam meg a Software Engineering Radio debugolással kapcsolatos részét, vajon mit mond egy olyan ember, akit már érdemes meginterjúvolni a témában.

Meglepődtem mikor ő is azt mondta, hogy rossz megoldás fejest ugrani rögtön az interaktív debugerbe. Előbb nem árt gondolkodni, minél jobban leszűkíteni a hiba lehetséges helyét, ha kell azzal hogy papírra leírjuk a tapasztalatokat. Esetleg hazamenni aludni.

Mesélt még róla, hogy ezek az IDE-be integrált debugerek nagyon kezdetleges eszközök. Viszont vannak olyan automatizált eszközök is amik amellett hogy futtatják a regressziós teszteket, hiba esetén vissza tudják keresni hogy az adott teszt mely verzióval működött jól utoljára és a verzió követő rendszerben milyen modulokban milyen változások történtek azóta. Ezáltal elég jól be tudják azonosítani a hibák lehetséges helyét és elkövetőjét. Érdekes dolgok ezek. Egyszer majd kipróbálom talán, addig is szorgalmasan reszelgetem a debug szintű logjaimat.

Gyertek JUM-ra 19.-én!

Update 2009.08.12: (Ezt azért írom, hogy ha már nem vagyok kinn a Szigeten, legalább valahogy mégiscsak elcsesszem az időt meló helyett.) A bejegyzés első része Enterprise Java alkalmazásokra vonatkozott, amelyek leginkább appszerverek belsejében futnak, de mostanában a Javascript felé sodort az élet, aholis kicsit már más a leányzó fekvése debugolás vs loggolás tekintetében.

Előszöris nem nagyon van hova loggolni. Leginkább alert popup-okat szoktak beszúrogatni ide-oda, amit aztán le kell okézni, vagy a HTML DOM bizonyos helyeire írogatnak be szövegeket. Trükkökkel lehet konzolt csiholni, de ez nem igazi log, tényleg csak egy konzol. De nem is ez a legnagyobb probléma, hanem hogy a java-val ellentétben a Javascript egy gyengén típusos dinamikus nyelv, tehát igen nehéz követni, hogy a program futásának adott pillanatában mi a környezet: milyen változók élnek, azoknak milyen mezői és függvényei vannak és ezek hogyan vannak egymásba ágyazva, egyáltalán mi a scope, mi a this referencia. Ráadásul elég sokat találkozik az ember külső Javascript komponensekkel, amiknek a működését nagy vonalakban nem árt megérteni. Viszont: A javascript-ben egy szálon fut a program, tehát nem eshetek komoly csapdákba debugolás közben a szinkronizációk és időzítések miatt.

Szóval ez az az eset, ahol mégiscsak bőszen használom az interaktív debuggert, nevezetesen a Firebug-ot, de Internet Explorer-re is van valami hasonló csak nem annyira ingyenes. Ennek ellenére Javascript klienseknél sem lenne haszontalan egy debug-log szintet kialakítani, amikor a böngésző Ajax-szal leküld bizonyos logokat a szervernek, de a tapasztalat azt mutatja, hogy olcsóbb szotyoláért egyetemistákat ráküldeni a gui-ra kattintgatni.

Egy sima egy fordított

Az utóbbi időben kapcsolatba kerültem néhány fordítási projekttel.

Az egyik a Facebook magyarítása volt, ami azon az elven alapult, hogy a fordítást maguk a felhasználók végzik el a közösségi oldalba integrált felület (minialkalmazás) segítségével. A fordítás szavazás alapú volt, azaz a lefordított kifejezések közül mindenki megszavazhatta a neki tetszőt vagy nem tetszőt. Viszonylag jó fordítást sikerült csinálni. Teljesen tetszik az ötlet. Egy-két szót én is bedobtam a köztudatba, de azt hiszem egyik sem nyert. Viszont jó a tudat, hogy a szavazataimmal legalább hozzájárultam a projekt minőségének javításához. (Vagy rontásához. :))

A másik a Scarab (issue tracker szoftver) fordítása volt, de ahogy tudom ez kicsit lefulladt, vagy legalábbis erősen stagnál az állapota. Részemről azért, mert eléggé el vagyok havazva mostanában melóval és a szabadidőbe pedig nem fér bele. De ha valaki folytatni akarja, akkor ez alapján bekapcsolódhat. Egyébként több érdekessége is volt a dolognak, pl. rögtön elakadtunk ott, hogy az issue-t hogyan fordítsuk magyarra, hiszen a hibákat és a fejlesztési kérelmeket is issue-nak nevezik. Mi feladat-nak fordítottuk. Másik érdekesség -ami nem konkrétan fordítással kapcsolatos- a Scarab disztribúciójának módja, ugyanis nem egy sima war-t vagy ear-t kell letölteni, hanem egy komplett Tomcat-be ágyazott struktúrát kapunk. Hát, nem tudom mennyire ez a követendő példa.

Loggolás: E blogbejegyzés alapján a kommentelők mellett bennem is felmerült hogy mi a franc értelme van lokalizáltan loggolni. Ha szuahéli nyelvű logokat mellékelne nekem valaki egy hibajelentéshez annak bizonyára nagyon örülnék. Az persze igaz hogy nem muszáj használni a funkciót.

A javalistán is tombol egy thread "Tervezési minták" címmel a témában. Előjön az ősi kérdés, hogy ugyebár lefordítsunk-e magyarra valamit vagy ne. Singleton vs. Egyke, Abstract Factory vs. Absztrak Gyár vs. Elvont Gyár, Session Bean vs. Munkafolyamat Bean. Elég sok oldaláról kivesézik a kérdést. Néhány év gyakorlattal az én véleményem az, hogy lehetőleg minél kevesebb szakkifejezést fordítsunk (vagy inkább ferdítsünk) magyarra. Aki komolyan akar programozni az tanuljon meg legalább ennyire angolul.

Megkérdezték a véleményemet egy elég komoly fordítási projekt kapcsán is, hogy milyen technikai kifejezéseket hogyan látnék szívesen az adott szoftverben. Ott is kötöttem az ebet a karóhoz, hogy minél több angol kifejezés legyen arra, amire nincs magától értetődő magyar szavunk.

Blogot írni programozásról jó, mert szabadon keverhetem a kifejezéseket, megválaszthatom a stílust. Könyv írásánál is viszonylag szabad keze van a szerzőnek - gondolom én. Nem elhanyagolandó, hogy aki könyvet ír az viszonylag nagy valószínűséggel érti amit leír. Amikor viszont kiosztják a tonnányi fordítást egy nem kimondottan IT-s végzettségű társaságnak anélkül hogy élesben találkoznának a szoftverrel, na abból lesznek a szörnyűségek.

A Scarab fordításra visszakanyarodva én folyamatosan használtam a szoftvert és csak akkor kezdtem fordításba amikor egy címke szerkezetét és helyét pontosan megtaláltam. Néha 5-10 percet kellett tesztelnem, mire pontosan kitaláltam egy-egy címke funkcióját. Ugyebár vannak ilyen kifejezések, hogy: This {0} is {1} {3}. Na most találd ki hogy ez micsoda, melyik mezőbe mi fog kerülni. Mellesleg hasznos lenne a bundle fájlokat megkommentelni, hogy melyik bejegyzés milyen esetben hol jelenik meg, de ez akkora plusz meló fejlesztés közben, hogy úgysem csinálja meg soha senki. Utána meg már elég nehéz.

Külön öröm lehet, ha a fordításnál rendelkezésre áll egy vállalati policy a felhasználandó kifejezésekkel vagy egy ügyeletes Kazinczy Ferenc aki IT kérdésekben nem kimondottan járatos, ennek ellenére bekiabálja a pálya mellől az okosságait. Értem én hogy foggal-körömmel védeni kell a szép magyar nyelv értékeit, nade pont ezen a területen, ahol a bit-től kezdve minden az angolból jön?

Múltkor belenéztem egy szoftverfejlesztési eszköz vállalati policy-vel és nyelvésszel készült megmagyarított súgójába és komolyan mondom, nem értettem az ott leírtakat. Mintha kódolt Navaho nyelven lett volna leírva. Nem tudtam eldönteni hogy verjem a fejem az asztalba vagy sírva röhögjek. De végülis ezektől a dolgoktól vicces az élet, úgyhogy aki tud valami vicces fordítást az egyébként ne fogja vissza magát, nyugodtan írja a kommentek közé.

Visszatérve a rögvalósághoz, még egyetlen dolgon töröm a fejem a fordításokkal -azon belül a bundle fájlokkal- kapcsolatban. Ha van egy szó vagy kifejezés, ami több (~sok) oldalon ugyanúgy szerepel érdemes-e csinálni neki több bejegyzést. Több bejegyzés esetén a bejegyzéshez tartozó kulcs hierarchikus szerkezetű és lehet tudni hogy az alkalmazás melyik részében, melyik oldalon esetleg milyen funkcióval fog megjelenni a címke. Csakhát egyvalamit tízszer le kell írni. Gondolok itt az általános címkékre, mint "OK", "Mégsem", de gondolok az adott rendszer entitásaira is, mint "Alkalmazott", "Gépjármű", "Kutya", "Termék". Azt gondolnám hogy nem érdemes külön bejegyzést csinálni, de mi minden projektben mégis így csináljuk, mert megvan a minimális esélye, hogy egyik oldalon mégis kicsit máshogy kell majd kiírni az adott dolgot. Ez ha jól emlékszem tíz év alatt egyszer sem fordult elő.

Cloud Computing

Megvan az új Buzzwörd amit a különböző típusú és beosztású managgerek és sáleszesek feljegyezhetnek a noteszükbe a prezentációkon puffogtatható kifejezések közé. Igaz hogy nem történt semmi a világban, marad a kliens-szerver architektúra jó eséllyel cluster-ezett szerverekkel és lazán egymáshoz kapcsolódó szolgáltatásokkal, ennek ellenére némelyek ezt világratörő innovációnak élik meg az MS-től kezdve a G-ig.

A Wikipedia szerint - nagyon nagy vonalakban- onnan jön a kifejezés, hogy a meetingeken az internetet felhőnek szokták ábrázolni. Update: sg.hu-s cikk, idézet belőle: "A számítási felhők hívei szerint a jövő útja központi szervereken futtatni a szoftvereket, és az elérésükért pénzt szedni a felhasználóktól." Jó nem?

A Web 2.0 kifejezés elterjedésénél még éreztem valami paradigmaváltást, hogy a request-reply formok helyére bejönnek a rich client alkalmazások. Mások teljesen a szociális oldaláról közelítették meg a kérdést, tehát hogy a közösség építi a fellelhető tudásbázist, de végülis a lényeg, hogy ha nem is hirtelen, de végbement valami ami az internet felhasználásának az elveit változtatta meg. Mások szerint persze ez is marhaság.

Ezzel az új kifejezéssel kapcsolatban éppen az zavar, hogy nincs szó semmilyen paradigmaváltásról, csak kitaláltak egy szinonímát egy régóta meglévő általános dologra.

Ráadásul a Cloud Computing -ról én az elosztott számítási rendszerekre asszociáltam eddig, mint pl. amelyek a személyi számítógépek üresjáratát kihasználva földönkívüli rádióadásokat keresnek, DNS-t kutatnak, kódokat törnek vagy ütköző részecskéket elemeznek. Ide sorolnám még a p2p fájlmegosztókat is tágabb értelemben. Ezeknél az architektúráknál a kliens aktívan részt vesz a rendszer működésében.

Mint a Wikipedia szócikkből kiderül, ez valójában Grid Computing. A grid-ről viszont inkább egy statikusan összeállított viszonylag homogén és szabályos szuperszámítógépre asszociáltam eddig, a felhő pedig egy olyan rendszer volt nálam, amibe szabadon becsatlakozhatnak különféle munkaállomások, tehát topológiai kérdés.

A Cloud Computing architektúrájában a kliens valójában nem része a felhőnek ami a szolgáltatásokat biztosítja, ad abszurdum nem osztja ki a rendszer a gépemre a feladatot, hogy XYZ emailjait tárolja el.

Boncolgathatnánk még a kérdést, hogy miért Computing, de végülis az emailek vagy dokumentumok tárolása és szinkronizálása is valamilyen szinten "computing", akárcsak a legbonyolultabb matematikai problémák megoldása.

Tehát:

• internet, kliens-szerver architektúra (régi, elavult)
• cloud computing (modern, trendi)

De a kettő ugyanaz.

Update 2009.01.21: Harangoztak a merevlemeznek, cikk az It-Café-n. A Google-nek, a Microsoft-nak és még másoknak is van tervezett megoldásuk személyes fájlok központi helyen való tárolására. Megemlítik a cikkben a problémákat is. Két dolog nekem is eszembe jutott: mit szólnának a kedves szolgáltatók, ha valaki kapásból csinálna egy lokálisan futtatható titkosító eszközt és így a központi tárhelyre csak értelmetlen bithalmazok kerülnének fel, amit nem lehet vizsgálgatni, indexelgetni, mazsolázgatni? Másrészről környezetvédelmi aggályaim is vannak, mert a saját gépemet lekapcsolom amikor nem használom, egy központi szerver viszont folyamatosan pörög, nem is beszélve a hálózati struktúráról és annak a terheléséről amíg az adatok átérnek a felhőből az aktuális eszközömre. Akkor inkább legyen olyan szolgáltatás amivel be tudom kapcsolni és vezérelni, adatokat lekérni az otthon hagyott eszközeimről. Ja és köszi a szamitasifelho.lap.hu-nak hogy belinkeltek!

Mercurialozom

Ideje volt már feltennem a sajátgépemre egy elosztott verziókezelő rendszert. Miért is? Saját használatra Windows-on nem akartam CVS-t vagy SVN-t izzítani, viszont a fejlesztőkörnyezet history szolgáltatása elég Mórickás, ráadásul lehet hogy más is be fog csatlakozni a fejlesztésbe. E írás alapján a Mercurial mellett döntöttem. Dióhéjban: git-re nincs Windows támogatás, Bazaar nem rossz, de a Mercurial mégiscsak ismertebb.

Írás még róluk a Javaworld-ön. Összegyűjtve dolgok még a JHacks-en.

1 perc múlva már ott figyelt az installált Mercurial 1.0.1 verzió a Windows-os gépemen.

A 3.3-as Eclipse-hez pedig lehúztam egy plugint.
E levél szerint Zingo Andersen fejlesztgeti pár éve szabadidejében.
Először nem működött valami jól, mert nem tudtam visszanézni a régi verziókat, de végül uninstall után a béta update site-ről szedtem le a legfrissebbet, ami már jól működik. Az ikonok dekorálását explicit be kell kapcsolni a preferences label decorations-nél. Itt van a plugin fejlesztői oldala, itt van a béta update site URL-je is.

http://home.zingo.org/trac/mercurialeclipse

Megvan az SVN-ből vagy CVS-ből megszokott kellemes funkcionalitás. History, diff, annotation. Ezeket használom én, amikor verziókontrollozok. Persze a commit, update és társain kívül.

De van másik plugin is: Merclipse.
Ezt is kipróbáltam, de 5 perc után leszedtem, mert elsőre nem állt kézre a funkcionalitás. (Valami vagy nem működött, vagy nem találtam meg és nem volt jól ledokumentálva hogy hol keressem.)

Team - Share Project-tel lehet varázsolni hamar a meglévő projektből Mercurial repositoryt. Aztán még add-olgatni kell a fájlokat és kommit-olni. Anélkül hogy ismerném a belső működését kijelenthetem, hogy a verziózott fájlok a projektben a .hg könyvtárban kerülnek eltárolásra. Nem szemeteli össze az összes könyvtárat mint az SVN vagy CVS, csak a gyökeret.

Hogy hogyan kell több gépet együttműködésre bírni azzal egyelőre nem foglalkoztam.

A következőn gondolkodtam el: mivel nincs központi repó és minden fejlesztő gépén fenn van a teljes anyag, elvileg nehezebben vesznek el az adatok. Viszont ha tönkremegy valaki vinyója és senki más nem szedte le az aktuális változtatásait az gáz. (Tapasztalt DVCS júzerek cáfoljanak meg ha nincs igazam.) Szóval elosztott rendszer ide vagy oda, mégiscsak jó ha rávésődnek az adatok egy-két masszív központi vasra is. Nyilván meg lehet oldani valahogy.

Mivel egyelőre saját célra használom egyedül, kiélvezhetem a commit comment-ek és a branch-ek előnyeit, de gondoskodnom kell róla, hogy néha kiírjam a repót CD-re vagy valami hasonlóra.

A Selenic-es Wiki-ben volt egy link egy nagyon jó ingyenes elektronikus könyvre, de már nem él: http://hgbook.red-bean.com/hgbook.pdf

(Zárójelben megemlítem hogy most háromféle verziókezelő plugin működik aktívan az Eclipse-emben gond nélkül. Ebből a Mercurial és a CVS egy workspace-en belül van, de úgy emlékszem az egyéb kombinációk is jól működtek eddig.)

Különben pedig valóban. Amíg intraneten SVN-ezik az ember addig mindegy, mert jönnek az adatok mint az olajozott villám, de ahogy pl. mostanában rákapcsolódtam egy távoli Google-s SVN trunk-re https-sel kicsit kényelmetlen lett hirtelen a sebesség, vagyis annak a hiánya. Intraneten néha passzióból history-t nézek vagy compare to-zok. Távoli trunk-on már jobban meg kell gondolni van-e fél percem és sávszélességem ilyen műveletekre. Szóval ja: hasznos lehet az elosztott verziókezelő néhanapján.

JavaCard Classic

Volt egy projekt egy-két hónapja, amiben JavaCard technológiát használtunk. Most már teljes a skála, JavaCard-tól MIDP-n és Standard Edition-on keresztül a J2EE-ig mindent programoztam Java-ban. Igaz, a JavaCard-nak éppenhogy csak karcoltam a felszínét, de arra ez is elég hogy rálátás legyen. Most csak konyhanyelven írom le hogy megy ez a dolog:

Gyakorlatilag java-t kell programozni, de az osztálykönyvtár irdatlanul le van csupaszítva és csak 2 bytes-os adatszerkezetek vannak, tehát tele van az egész kód short kasztolásokkal és tömbműveletekkel. Úgynevezett javacard appleteket kell programozni, amiknek saját primitív tranzakciókezelésük és belső security managementjük van, lényegében perzisztens szerkezetűek és byte alapú módon kell kommunikálni velük. A kártyában pár kilobájt EEPROM áll rendelkezésünkre a programhoz és az eltárolt adatokhoz. Egy kártyára több appletet is installálhatunk. Sok firkálás után a kártya szépen tönkremegy.

A kártya valójában nem igazi bájtkódot futtat, hanem speckó eszközzel kell lefordítani a java forrást egy jobban megemésztett formátumra. Például a standard java-val ellentétben a linkelési információk nem kerülnek be a lefordított bináris állományba, hanem azokat egy másik állományban tárolják kb. név, index párokként. Az eszköz és a doksik letölthetőek a netről, van valami plugin Eclipse-hez (JCOP) ami szimulálni tudja a kártyát és kommunikálni tud magasabb szinten a géphez csatlakoztatott kártyaolvasókkal.

Az appletnek van egy belépési metódusa, ami egy az egyben megkapja azokat a bájtokat, amiket a kártya vett a külvilágtól akár a felületre integrált csatlakozási pontok, akár egyéb átviteli módszerrel. Pl. vannak RFID-vel vagy NFC-vel kommunikáló kártyák. Az RFID egyébként hasonlóan működik mint egy trafó. Váltakozó áram indukálódik a kártyában, ami egyben magát az adatot is jelenti, emellett a kártya áramellátását is megoldja arra az időre amíg az adatok feldolgozódnak. vicces nem?

Visszatérve a bájt tömbre: van egy viszonylag kötött formátumú fejléce, amit a kártya mini oprendszere kiértékel. Ez az első körben max kb 256 byte hosszú bájtsorozat használható az authentikációra, új applet telepítésére, törlésére, kiválasztására, befixálására. Megfelelő számú partizán kísérlet után a kártyát jól le lehet tiltani örökre. Ugyanezt a bájtsorozatot használhatjuk az appletben a saját protokoll kialakításához. Hosszabb bájtsorozatokra van valami összeillesztős mechanizmus.

A konvencionális java SE programokkal ellentétben a javacard applet mezőváltozói perzisztensek, azaz ha valamit beállítok az úgy is marad magától. Tehát mezőváltozóban lehet tárolni ilyeneket, hogy hányszor használták a kártyát. Ha jól emlékszem van valami commit-szerű művelet is, amivel gondoskodni lehet (kell?) róla, hogy a beírt értékek valóban perzisztálódjanak, és ezt ráadásul egyszerre tegyék. A változtatásokat a javacard egy kb 256 byte-os RAM pufferben gyűjti és a commit-nál beírja az EEPROM-ba. Ha túl sok változtatást akarunk csinálni, a puffer túlcsordul és hibát kapunk.

A kimenet szintén egy bájtsorozat. Össze kell rakni és elküldeni. PC oldalon vannak driverek, amikkel meg lehet hajtani mindenféle csatlakoztatott kártyaolvasókat, de most hirtelen nem is tudom milyen interfész van hozzájuk.

Ahogy a Sun Java Cafés postban írtam, a 3-as JavaCard verzióban bevezetnek egy új programozási módot, amiben magasabb szinten, szervletekkel (ezek sem igazi szervletek) lehet programozni a kártyákat. Ezt nevezik Connected Edition-nek.

Amiről én írtam az még a régebbi spec, amit meghagytak és Classic Edition-nek hívják.

Eredményhirdetés

Köszi hogy 31-en nyilvánítottatok véleményt! A végeredményt idemásolom, hogy akkor is látható legyen, amikor az oldal széléről majd eltűnik és a múlt homályába vész:

• 7 ember (22%) 100%-ban szXrt lapátol.
• 10 ember (32%) 80%-ban szXrt lapátol, de 20%-ban király dolgokkal foglalkozik.
• 9 embernél (29%) fele-fele ez az arány.
• 1 embernél (3%) inkább a király dolgok felé dől a mérleg, 80%-ban ezzel foglalkoznak.
• 3-an (9%) folyamatosan király dolgokat csinálnak profi csapatban.
• 1 szavazó pedig nem szoftverfejlesztő.

Mivel ez egy egyszerű közvéleménykutatás volt, nem derülnek ki bizonyos dolgok, például:

-Milyen szakterületekre koncentrálódik a lapátolás nagy része? Azt gyanítom, hogy főként az ügyviteli és banki szoftverekre. Technológiai és akadémiai/kutatás témakörben készült szoftvereket gondolom jobban összeraknak. Például több idő van a tesztelésre. Emellett úgy gondolom az open source szoftverekben kevesebb a szégyellendő, rejtegetnivaló megoldás.

-Milyen programnyelvre koncentrálódik a gányolás nagy része? Igaz hogy C-ben, C++-ban életveszélyesebb dolgokat lehet összehozni mint Java-ban vagy PHP-ben, de talán pont ezért a C, C++ programozóknál precízebb munkára van szükség. Modernebb nyelveknél/platformoknál, vagy legalábbis a Bábel torony felsőbb emeletein nagyvonalúbban dobálóznak rétegekkel, konverziókkal, magasszintű komponensekkel. Felhígul a társaság, divat van, nincs meg az elhivatottság. Nem utolsósorban műszakilag műveletlenebb megrendelőkkel konfrontálódnak ezen a szinten a fejlesztők és jobban beleszól a politika a tervezésbe ami kimondja mikor mit kell használni -függetlenül attól hogy az eszköz alkalmas-e az adott feladatra. Itt már visszakanyarodunk lassan a szakterületekre.

-A válaszok nyilván szubjektívek és önkritikán alapulnak. Az is lehet hogy valaki bepipálta hogy király dolgokat csinál profi csapatban, közben pedig a TheDailyWTF-nek kimeríthetetlen témaforrást tudna biztosítani. A fordítottját nehezebben tudom elképzelni, hogy egy elégedetlen munkásember valójában egy nagyon irigylésre méltó team-ben dolgozik. Ki mennyire becsüli meg a melóját? Erről is szólt ez a szavazás.

-Ha valaki szXrt lapátol, miért nem koccol le? Ez csak költői kérdés. Pár dolog közrejátszhat a maradásban. Pl. lojalitás (muhaha), pénz, van aki hisz benne hogy jobbra fordul a helyzet, a következő projekt jobb lesz és ne titkoljuk: van aki belekényelmesedik a helyzetébe.

-Végül ahol király csapatban profi dolgokat csinálnak az emberek az vajon melyik cég lehet és keresnek-e mostanában náluk munkaerőt? És vajon lehet-e itt a blogon privát üzenetet küldeni nekem ezügyben? :)

Eclipse J2EE támogatás

Kipróbáltam az Eclipse 3.3 J2EE edition J2EE alkalmazás támogatását. Nem nagyon találtam róla épkézláb leírást és csak 1-2 órányi kísérletezés után sikerült kitalálni, hogy milyen sorrendben kell csinálni a dolgokat és tulajdonképpen mi micsoda. A help-ben sokminden van, de egy lényegretörő leírás nincs, hogy "figyelj, így kell összerakni egy móricka-szintű J2EE alkalmazást", ezért most lepötyögöm ide.

Figyelj, így kell összerakni egy móricka-szintű J2EE alkalmazást:

Először is az Eclipse J2EE edition támogatja appszerverek vezérlését az IDE-n belül. Glassfish V2-t választottam játszásra, ami alapból nincs a támogatott szerverek között, de le lehet tölteni a modult. A konzol view-eknél van egy új fül Servers névvel. Lokális és távoli szervert is fel lehet venni, én lokálban próbálom. Gyakorlatilag elindítani és leállítani tudja a szervert, nem veszi észre a fenn lévő alkalmazásokat és ha Eclipse-n kívül indítom el akkor is zavarba jön. Azt hiszi hogy nincs elindulva és nem találtam olyan funkciót amivel frissíteni lehetne az állapotot - pedig nagyon meg tudnám becsülni. Szóljon aki tud ilyet! Ezen kívül megjelenik az appszerer logja egy konzol ablakban. Ja igen és debugolni is lehet az enterprise alkalmazást.

Leírom nagyjából hogyan néz ki egy ilyen J2EE alkalmazás belülről. EAR-ban vannak JAR-ok, WAR-ok és különböző XML-ek. (EAR, WAR, JAR: kb zip formátum.) Ezt kell bedobni az alkalmazás szerverbe. Ezenkívül lehet külső kliens, ami sima Java, csak még gondoskodni kell egy közös osztálykönyvtárról ami a külső kliens és az Enterprise App közti interfészeket tartamazza. Ez tipikusan egy jar, ami a kliensnél és a szerveren is megvan az EAR fájlban.

Csináljunk J2EE alkalmazást!

New J2EE application project
Target runtime, configuration - maradhat default, de később is még felajánlja. EJB3-as alkalmazást akarok csinálni.
J2EE modules to add - ha vannak más moduljaink. Generate deployment descriptor - csekkeljük be jól jön az.
Van itt egy olyan gomb hogy New module. Érdemes megnyomni mert rögtön felajánlja hogy csináljon-e client, ejb, web és connector modulokat. Engem most a web és a konnektor nem érdekel, azt nem csekkeltem be.
Rögtön létre is hozza a két projektet. (XXXEARClient, XXXEAREjb) Az EAR kliens alatt az én értelmezésemben pl. egy desktop alkalmazást értek *, ami cseszeregteti az EAR-t. JUnit teszteknek kiválóan alkalmas.
Finish. Megcsinálta az EAR-t is, átváltódunk J2EE perspektívába. Ha jól látom nem csinált szabványos ejb-jar-t, -hiába ikszeltem be- csak sun-ejb-jar-t.

Az EJB projekt context menüjében a J2EE menüpont alatt ki lehet választani a create EJB Client jar-t. Ezzel létrehozunk egy újabb projektet, amiben az EJB interfész osztályait tároljuk: business interfészek, kliens és szerver között mozgatott adatszerkezetek, utility osztálok kerülnek ide. Az EAR kliens projektben a J2EE module dependencies-ben be kell állítani, hogy lássa az EJB kliens projektet.

Új EJB3-at csak kézzel lehet létrehozni jelenlegi tudásom szerint.

-Az EJB kliensbe kell felvenni tehát egy interfészt ami a lokális vagy remote interfész lesz. Alaphelyzetben az ejbModule a forrásfolder. Tessék egy business interfész:

public interface ISample51 { //51: ötödik próbálkozásom első interfésze
String helloWorld();
}

-Az EJB projektben új osztály létrehozása Session Bean-nek. A felajánlott interfészeknél láthatóak az EJB kliensben létrehozott interfészek. (Ha elkezdjük írni.)
-Implementálni kell a metódusokat és fel kell annotációzni az osztályt pl. így: @Stateless @Remote public class SLSB1 implements ISample51 { ... } Azért remote, mert az appszerveren kívülről szólítjuk meg.
-Csinálni kell egy kliens osztályt. Már lehet hogy csinált egy Main-t a default package-be, ezt is használhatjuk. Egy ejb megkeresés és hívás így néz ki, ez kerül mondjuk a main belébe:

javax.naming.Context ctx = new javax.naming.InitialContext();
ISample51 hw = (ISample51)ctx.lookup(ISample51.class.getName());
System.out.println(hw.helloWorld());

Ha most futtatjuk a kliens osztályt jól elcsattan NameNotFoundException-nel, mert nem találja a bean-t. Miért is találná, nem deployoltuk. Ha nem lett volna elindítva az appszerver indítsuk el az Eclipse-en belül. Servers fül, play gomb. Deployoljuk: server view, context menü, add and remove project. Átnyomjuk az EAR projektünket a bal oldalról a jobbra, finish. A konzolon egy rövid Ant log jelenik meg. Nálam átlagos gépen 7 másodpercig tart a fenti bonyolultságú alkalmazás telepítése. Ha mindent jól csináltunk hibaüzenetek nélkül ÉS "Application Deployed at..." üzenettel. Vigyázat, ha valójában nem sikerült a deploy, akkor is képes kiírni a deployed üzenetet. Ha most futtatjuk a kliens osztályt, akkor már csinálja a dolgát.

Változtassunk bele az EJB-be minimálisan, buildeljünk újra. Ilyenkor az alkalmazás automatikusan újradeployolódik.

Ha az automatikus buildet beállítjuk, akkor kb. minden mentésnél megtörténik az újradeploy, ami nem valami szerencsés úgyhogy ezt az opciót érdemes kikapcsolni. Vannak még további lehetőségek is a build-deploy kapcsolatban, de ez most ezen a szinten nem érdekes.

Ha az interfészt megváltoztatjuk mondani kell egy olyat az EJB projeknek (a context menü J2EE részében) hogy update EAR libraries. Úgy emlékszem hogy bizonyos beállítások mellett erre nem volt szükség. Igen: Az EJB projektben a J2EE module dependencies-ben ki kell ikszelni a client-jar projektet.

* A Wizard által generált EARClient nem biztos hogy az aminek gondoltam, mert ha beleváltoztatok az maga után von egy újradeployolást. Márpedig ha a külső klienset változtatom miért kellene újra deployolni a szerver alkalmazást? Inkább csináltam egy új sima java projektet a külső kliensnek, amibe beimportáltam a J2EE library-t és felvettem függőségnek az EJBClient projektet. Így már jobban működik.

Dióhéjban ennyi. Közben még találtam egy hasonló -képekkel is illusztrált- leírást itt, JBoss-hoz. Ha pedig kinyitom a csapot, az jön belőle hogy hogyan kell Netbeans-szel Glassfish alá J2EE alkalmazásokat csinálni. Homokozásra jó ez az Eclipse-be integrált módszer, de semmiképpen nem ajánlanám komolyabb alkalmazások fejlesztéséhez. Többször is okozott meglepetéseket az IDE ha véletlenül összekavartam a dolgokat, pl. nem volt hajlandó buildelni. Tekintve hogy integrált buildelésről volt szó, nem tudtam mit csinálni csak találgatni vagy új workspace-t nyitni. Ant-os fejlesztésnél ilyenkor megjavítom a build scriptet és kész. Az Eclipse-ből kiemelve a projektek használhatatlanok, mert nincs bennük semmiféle build script. Próbáltam így importálni külső J2EE projekteket igazán kevés sikerrel. Ha már itt tartunk meg kell említeni a Maven plugint, amit viszont lehet használni komolyabb J2EE alkalmazásokhoz és a hierarchikus Maven projektek importálása is kiválóan működik.

A javalistán is éppen lett egy hasonló témájú thread az elmúlt napokban, konkrétan JBoss-ra kihegyezve.

EJB3 szakirodalom

Elkezdtem foglalkozni a címben említett témával és hogy értsem és ismerjem a lehetőségeket utánanéztem a fellelhető anyagoknak.

Tudomásom szerint nincs magyar nyelvű nyomtatott EJB3-mal foglalkozó könyv. A híres zöld-sárga J2EE útikalauz az EJB2-t tárgyalja, ami a hasonló alapelvek ellenére határozottan elavultnak számít az EJB3-hoz képest. Részletesebb netes írásokról sem tudok magyarul, legfeljebb mindenféle fórumokról és kiegészítésre váró wiki bejegyzés-ekről. Update 2008.06.23: Ahogy a kommentek között írtátok mégiscsak van magyar nyelvű könyv a témában. Imre Gábor: Szoftverfejlesztés Java EE platformon.

A szoftverfejlesztők szerencsére tudnak angolul.

Szinte minden angol nyelvű netes java médiumnak megvan a saját kis bevezető EJB3 cikke, így például: Javaworld, dev2dev (BEA), developer.com (Packaging EJB3 application), stb. Az alapkoncepciókat gyorsan bemutatják ezek az irományok, alapvető HelloWorld programokat meg lehet írni a segítségükkel, de az EJB3-nak nagyon nagy mélységei vannak. Ezeknek a mélységeknek a megismeréséhez elő kell venni vaskosabb anyagokat is.

A speckókat (JSR-220 egyébként a másik neve) a Sun-tól lehet leszedni. Aki online akarja a javadoc-ot böngészni az itt megtalálja, aki pedig a deployment descriptor xsd-jéért lelkesedik az ide kattintson. De nem a Javadoc-ban és az XSD-ben vannak az igazán nagy okosságok, hanem a JSR220 pdf dokumentumokban. Egyből három doksit kapunk: Az ejb3_0-fr-spec-simplified.pdf 59 oldalon futja át az EJB3 tulajdonságait. EJB2 tudás előnyt jelent az olvasáskor. Az ejb3_0-fr-spec-ejbcore.pdf egy bő lére eresztett 500+ oldalas szárazanyag, aminek persze az eleje 30 oldal rizsa. Meglepő módon szerintem hiányos is, legalábbis bizonyos információkat indirekte, másokat pedig egyáltalán nem tudtam megszerezni belőle. A perzisztencia a harmadikban, a ejb3_0-fr-spec-persistence.pdf-ben van taglalva.

A Mastering EJB3 4th Edition-t éppen most töltöttem le (ServerSide regisztráció szükséges hozzá, ingyenes 721 oldalas pdf, forráskód külön letölthető). Még csak éppen beleszagoltam. Egyes témák nincsenek túlzottan kifejtve benne, például az interceptorokról szégyenletesen kevés írást találtam, de egyébként nagyon impresszívnek és részletesnek látszik. Ez és a ejb3_0-fr-spec-ejbcore.pdf látszik a befutónak. Ezeket kéne olvasgatnia szvsz egy tisztességes EJB3 J2EE fejlesztőnek.

Sun Java Café

Update 2008.05.19 Ahogy írtam az eredeti post-ban, kiegészítettem még néhány link-kel, sőt néhány gondolattal is ami azóta jutott eszembe. Dőlt betűsek.

Leugrottam ma a címben nevezett rendezvényre. Leírom miket hallottam / láttam mielőtt elfelejtem, aztán később kiegészítem majd a post-ot linkekkel is. Alapvetően JavaOne-os és CommunityOne-os mesélésből és videónézésből állt a meeting. A videók a netről voltak, azonkívül blogok meg ilyen lab session-ök, amik leírják hogy egy adott technológáit hogyan kell összerakni, dolgozni vele nagyjából.

Szóval a Sun-os srácok kinn voltak, mesélték hogy rengeteg holland volt, Amszterdamban tele volt a helyi JUG-osokkal a reptér. Brazilok voltak még sokan, mert Brazíliában államilag rákattantak az open source szoftverekre. A hely monumentális. JavaCard technológiát használtak a beléptetéshez, az előadásokra már jó előre (1 hét) kellett jelentkezni, mert a jobbakra beteltek a helyek. Jelentkezés nélkül is be lehetett jutni ha maradt még hely, de ott komoly sorbanállások voltak. Éjszakába nyúltak az előadások.

Bemelegítésnek egy videón bemutatták a ZFS (fájlrendszer) hibatűrő képességeit egy kalapács és egy kézifúró segítségével.

Volt néhány SOA-s, workflow engine-es téma de azok engem nem annyira fognak meg, vagy legalábbis addig a szintig érdekelne, hogy én rakjak össze egy ilyen rendszert az alapjaiból. Amikor már dobozokat kell összehúzogatni, XML-eket, bean-eket összepároztatni, de leginkább formokat kitöltögetni ott már kezdem fölöslegesnek érezni a programozástechnikai tudásomat. Ez egy másik szint, nem tudom.

Volt még látványos és meggyőző JavaFX hájpolás. 3D-ben transzformált filmeket mutattak sokat egyszerre, mondjuk százat, immár kihasználva a videókártya képességeit. JavaFX-es alkalmazás böngészőben, ami kicsit lefagyott néha, mert nem tesztelték a valósan leterhelt környezetben. A JavaFX alkalmazást ki lehetett emelni a böngészőből. Volt JavaFX Androidon -hohó! Kitalálták hogy csinálnak JavaFX támogatást MIDP-re és így nem mittudomén 3 milló JavaFX-es mobilt csinálnak, hanem 1 milliárdot. Én csak azért vagyok szkeptikus, mert rengetegszer találkoztam már a 64k-s problémával, mármint hogy sok telefonban 64kbyte áll rendelkezésre a midletek futtatásához ami néha igencsak kevés. Namost ha eleve betuszkolunk egy JavaFX motort az alkalmazás mellé az eleve elfoglal elég sok helyet. Kíváncsi vagyok a megoldásra. Egyébként meg a Java SE is fog tartalmazni JavaXF supportot. Update 2007.05.21: Említettek még olyan magic-et, hogy Adobe Photoshop-pal rajzolt képekből lehet JavaFX kódot konvertálni egy bizonyos eszköz segítségével. Erre itt is utalnak.

Neal Gafter closure proposal-ját néztük meg. Engem meggyőzött róla hogy hasznos dolog, bár a példa (mérjük meg a metódusok mennyi idő alatt futnak le) inkább valami AOP-os megoldásért kiáltott érzésem szerint. De itt most nem az volt a cél. Exception | Exception szintaktika, Map iteráció, egyebek.

Megemlítették, hogy az új portlet specifikáció már kicsit bonyolult lesz. Hát ja.

Valami D-vel kezdődő technológia, (DTrace, köszi!) ami Java programok követését teszi lehetővé. Az elmondás szerint egyik gépen ott Space Invaders-ezett a tag, a másik gépen pedig trace-elték a programot. Eddig ez nem nagy kunszt, sima Remote Debug is lehetne, de külön Java API lesz a trace-eléshez amivel nem tudom mit lehet majd megcsinálni, de biztos izgalmas dolgokat.

Szó volt a desktop alkalmazás vs. webalkalmazás témáról egy hamvába halt vitaindítóval. "Szégyenlős voltam", ezért nem jelentkeztem, de van egy véleményem a dologról: Mostanában a böngészők egyre jobban kezdenek hasonlítani egy menedzselt alkalmazás futtató környezethez. Gondoskodnak az alkalmazások frissítéséről, a sandbox modelről, security-ről, plugines a szerkezetük. Ha értelmes desktop alkalmazást akar írni valaki, igazából majdnem ugyanazokat a funkciókat meg kell csinálni mint amit egy browser nyújt. Csak az a fránya javascript ne lenne. De nem is kell, mert a browser szerepe ma már, hogy futtatókörnyezetet nyújtson a különféle plugineknek, pl. Flash, Java. Sőt, ha valahogy kiütöm a toolbar-okat a böngészőn, vizuálisan nem is lehet megkülönböztetni egy desktop alkalmazástól.

Megjelent a JavaCard technológia 3-as verziója -illetve meg fog jelenni- ami valami embedded webszerveres téma már. Volt egy verseny, hogy tankokat kellett vezérelni ilyen JavaCard-ra írt programokkal. Kétféle megközelítés van: a classic a v2-es spec hagyományait viszi tovább, azaz embedded applet-ek, aminek semmi köze nincs a browser-es appletekhez biteket vadásznak byte tömb alapú I/O segítségével. Erről lehet hogy majd írok még majd egyszer. A másik megközelítés a connected, amiben egy szervlet motor dolgozik és nagyjából szervleteket kell írni az igencsak megnyirbált Java SE osztályrendszert használva. Nincs floating point support meg ilyesmik.

Ami nagyon tetszett, az a toll, ami speciális pöttykóddal ellátott papírt használva rögzíti amit írok, felveszi a hangomat, vissza tudja játszani és ilyesmik. Volt olyan program (demószinten) ami leírt szöveget visszamondott mindenféle nyelven. Hoztak is a srácok egy ilyen tollat meg füzetet hozzá.

Java-t futtató kis lapka ami rádióval kommunikál. A videón labdákat dobáltak a teremben, a kivetítőn pedig mutatták hogy hol vannak éppen a labdák. Gondolom háromszögeléssel és időméréssel oldották meg a feladatot, de ilyeneket használtak széndioxid szint mérésre, JavaCard leolvasásra és mindenfélére.

Néztünk pár JavaOne újságot és voltak könyvek mutatóban. Biztos kihagytam valamit, de majd megírják. Addig is itt egy tűzközeli blog. És akkor jövök még majd linkekkel. -Akkor ez letudva.

Június 16.-án lesz a Sun-os fejlesztői konferencia külföldi előadókkal, gondolom sok SOA-val.

JSF 1.1 Basic

Az alap JSF tudásomat frissítettem fel mostanában kicsit. A témában korlátlan mennyiségű változatos terjedelmű és minőségű anyag lelhető fel a neten. Maga a technológia viszonylag ódivatú a többi egyre jobban vastagkliens-irányba haladó framework-höz képest. Talán azért vettem rá magamat az átnézésére, hogy megadjam neki a végtisztességet.

Egyelőre ennyi link:
GuessNumber tutorial Egynek jó példaprogram, bár kicsit régi.
www.coreservlets.com API-k, mindenféle.

JSF-ről egyébként nem post-ot, hanem könyvet kéne -kellett volna- írni (nem is tudom hogy van-e jó magyar könyv), mindenesetre az alábbiakat véstem fel magamnak ad hoc, abszolút a teljesség igénye nélkül. Update 2008.07.23: A Szoftverfejlesztés J2EE Platformon című könyvnek van egy egész használható, JSF-fel foglalkozó fejezete. Azt hiszem mostanában elég sokat fogom ajánlgatni J2EE fejlesztéshez ezt a könyvet, pedig nem fizetnek érte. Ez egy kicsit szétszórt és dinamikus post lesz, szóval ha van valami amit nagyon megjegyeznivalónak találok, akkor azt beszúrom ide valahova. Meglehet hogy némelyik témát meg sem említem, némelyikbe pedig nagyon belemegyek. Ez van. Ez nem cikk hanem jegyzet.

Webalkalmazás konfiguráció

Sima szervlet technológiára épít, tehát a web.xml-ben kell megadni a Faces servlet-et, a mappingjét és a faces config fájlokat a javax.faces.CONFIG_FILES paraméterben, vesszővel elválasztva. Legjobb megnézni egy példát. Ha van /WEB-INF/faces-config.xml, azt nem kell explicite megadni, az magától betöltődik utoljára. Elvileg ezt nem is _szabadna_ megadni, de ki kell próbálni mi történik.

A JSF paraméterek prefixe javax.faces. Meg lehet még adni a JSF fájlok kiterjesztését (DEFAULT_SUFFIX), valamit az életciklusról (LIFECYCLE_ID) és azt, hogy az állapot a szerveren vagy a kliensen legyen lementve (STATE_SAVING_METHOD). értéke 'server' vagy 'client'.

Ha a STATE_SAVING_METHOD értéke 'client', akkor Base64 enkódolással, a com.sun.faces.VIEW hidden változóban van eltárolva a view a HTML-ben. Ebben az esetben a session timeout nem probléma. Meggátolja a form repost-ot. Ha server, akkor megadható a com.sun.faces.NUMBER_OF_VIEWS_IN_SESSION. A FacesContext-ben tárolódik el a state.

Itt van még némi infó a szabványos JSF konfigurációs paraméterekről.

Alkalmazhatók még saját, nem-standard paraméterek is.

JSF életciklus

Bő lére eresztett leírás a JSF életciklusról itt.
Összefoglalva:

• Restore view postback esetén előkeresi az elmentett view-t, init esetén felépíti a view-t és elmenti
• Apply request values a request paramétereket beteszi a view-be ha meg van adva UI komponensben immediate, itt fog megtörténni a validálás események képződnek
• Process validations validációk lefutnak a beírt értékekre. Ha elbukik error msg-k kirakódnak és render response hívódik.
• Update model values A Managed Bean-ekbe itt történik meg az értékek visszaírása. Ha nem sikerül konvertálni egyből a render response fázisba megy error msg-kkel.
• Invoke application Form submit és egyebek lekezelése.
• Render response HTML Renderelés.

Managed Bean-ek

faces-config fájlokban kell őket összehegeszteni a JSP lapokkal. Alapvetően POJO-k, de tartalmazhatnak akció és eseménykezelő metódusokat is, tehát nem csak egy oldal állapotának hordozására, hanem az eseményeinek lekezelésére is ezek a Managed Bean-ek használhatóak. Managed Bean lehet Map vagy List leszármazott is. Publikus default konstruktor kell. Setterek csak akkor kellenek, ha a faces-configban inicializálni akarjuk.

Navigáció

Jóanyag.

Összefoglalva: Meg lehet adni, hogy melyik oldalról milyen 'outcome' hatására melyik oldalra menjen. Az 'outcome' String típusú értéket a Managed Bean-ekben lévő action metódusok adják. Pl. ha egy save() sikerült az outcome lehet "success", ha nem akkor "failed".

• Egy from-view -hez meg lehet adni több outcome-t és egy default-ot.
• From-view -t meg lehet adni pattern-nel, ami azt jelenti hogy a végén lehet wildcard (*).
• Az egész form-view lehet egy darab wildcard, sőt a form-view tag ki is hagyható, üresen viszont nem hagyható. Ilyenkor 'global outcome'-okról beszélünk.
• Ha ütközés van mindig az utolsó szabály érvényesül.
• #{beanName.beanActionMethod} : meg lehet adni, hogy csak
• erre az egy action-ra érvényesüljön a navigációs szabály.
• NavigationHandler az invokeApplication fázisban hívódik.
• to-view -be külső url is megadható.

Akciómetódusok

(ActionListener, validator és valueChange metódusokkal nem foglalkozom most.)
Publikus, paraméter nélküli metódusok Object visszatérési értékkel.
Pl. Enum-ot is visszaadhat, amit String-gé alakítva kijön az outcome.
Ha null-t ad vissza marad az aktuális nézeten.

JBB Q#20588: megmondja hogyan lehet oldalak között információt áramoltatni.

Nem lehet paramétert átadni (legfeljebb trükkösen).
Ha van több azonos nevu metódus automatikusan kiválasztja az action metódust, aminek nincs paramétere és Object a visszatérési értéke.

Implicit objektumok

• applicationScope : egész alkalmazásra vonatkozó
• cookie : cookie, requestre
• facesContext : FacesContext példány requestre
• header, headerValues : HTTP header, request
• initParam : az alkalmazásra vonatkozó init paraméterek
• param, paramValues: request paraméterek
• requestScope
• sessionScope
• view : gyökér UIComponent

Ha van egy images könyvtárunk a WEB-INF-en kívül, így tudunk benne hivakozni egy képre JSF-ből:
image="#{facesContext.externalContext.requestContextPath}/images/picture.gif"/>

Value Binding Syntax

#-vel kezdődik nem $-vel mint JSP-ben. Megpróbál nem elszállni NPE-vel, akkor inkább üres értéket ír ki. Input-oknál viszont simán elszáll, ha nem találja a Managed Bean-t vagy a property-t amibe be kéne írni valamit. Általában String-gé konvertálgat kiírásnál.

Egyebek

A h:form-nak van egy 'prependId' atributuma, ami alapállapotban true és ennek hatására a formban lévő input elemek id-it prefixeli a form nevével. Ezt érdemes false-ra állítani, ha a managed bean-eket post paraméterekhez akarjuk bind-olni. Viszont érdemes true-ra állítani ha több -esetleg iterációval előállított- form van az oldalon.

Lehet választani, hogy az f:loadBundle-t írjuk a jsp-be, vagy a message-bundle, resource-bundle -t a faces-config-ba. A standard validátorok üzeneteit a message-bundle alkalmazásával lehet felülírni. Pl. ilyesmi nevű MessageFormat-okat kell definiálni:

javax.faces.validator.LengthValidator.MAXIMUM

A requiredMessage-t pedig egyedileg megadhajtuk EL-lel így: #{msg.myMessage}, de valami bug miatt csak a resource-bundle alkalmazásával fog működni, f:loadBundle-lel nem.

Appszerver deatmatch Part 1

Van még egy elmaradásom. Szóval a legutóbbi Java User Meeting-en lement az Appserver deatmatch első része, azaz a Sun ingyenes Glassfish v2 szerverét nyüstöltük. Azaz nyüstölte két hozzáértő ember, egy előregyártott "vendégkönyv" ejb-webes alkalmazással, mi pedig figyeltük a kivetítőn ténykedéseiket. Nézzük a nyolc feladatot:

1. Egy EJB3 + JPA alapú egyszerű webes vendégkönyv alkalmazás beüzemelése a gépre telepített adatbázissal, bónuszként a benne lévő webszolgáltatás WSDL-ének letöltése.

Hamar ment, rögtön a második részt is kipipálva. Belenéztünk a WSDL-be (csúnya nagy XML, lényeg hogy automatikusan generálódott) és csináltunk egy teszthívást a Glassfish admin konzol segítségével. A teszthívás azt jelenti, hogy kitöltögettük a Glassfish WSDL alapján dinamikusan generált HTML formját és submitáltuk.

2. Build script-ből (távoli) deploy.

Netbeans-ből nyomták Ant-tal egy speciális Glassfish task-kal. Tehát nem sima másolási műveletről volt szó, bár úgy hallottam támogatja a hot-deploy-t is, azaz pár másodpercenként szkennel egy könyvtárat és ha talál változást benne akkor újradeployol.

3. Loggolási konfig megváltoztatása egy alkalmazás alatt futásidőben.

Ezt is az admin konzolon lehetett megcsináli és a logot is ott néztük csilivili táblázatban. Szokásosan loggerenként lehet severity level-t állítgani. A példaalkalmazás ilyen szempontból hazabeszélős volt, mert épített arra, hogy a Glassfish admin konzolja a Java Logging API-t támogatja (és csak azt). log4j konfigot gondolom a log4j.xml kézzel való szerkesztésével lehetett volna állítgatni és a csilivili html táblázatról is le kellett volna mondani, de ennek mégis jobban örültem volna.

4. A vendégkönyv távoli debug-olása.

Ez is simán ment, de a Glassfish-t újra kellett indítani a Debugolás megkezdése előtt. Úgy rémlik a JBoss-t nem szoktuk újraindítgatni, fixre be van állítva neki egy kapcsoló hogy engedélyezi a debug kliensek csatlakozását. A kapcsolót persze nem lehet menet közben váltogatni. Netbeans volt a debugoló kliens, de más is lehetett volna, mert standard debug portot használ.

5. Adatforrás megváltoztatása futásidőben.

Ez nem ment (exception), bár nem is vártuk el. Szerintem semmelyik alkalmazásszervernél nem működik. Az alkalmazás újraindításával viszont már simán ment. Ezt is az admin felületen állítgatták.

6. Appszerver leállítása majd újraindítása a deployolt alkalmazással.

Ezt észre sem vettem. Nem mértünk időt, de 10 másodperc körül lehetett sacc per kábé.

7. LDAP azononosítás (ha belefér az időbe)

Ez sikerült volna, de már kezdtünk kicsit kicsúszni az időből. Az mondták 10 perc alatt megvan általában, még 2 perc kéne (8 perc eltelt akkor).

8. Terheléses teszt (JMeter)

Terheltünk, 1700 request/sec-en ketyegett egy átlag notebook-on. Már nem emlékszem a pontos számokra, de tuningolással talán fel tudták vinni 2200-re. (JVM paraméterek.) A terhelésnél a loggolás ki volt kapcsolva és a debug mód sem működött. Ennek a pontnak akkor lett volna értelme, ha azonos hardveren van mivel összehasonlítani, így magában nem sokat mond.

Nagyon jól felkészültek voltak a srácok. Kíváncsi vagyok a többi versenyzőre 2 hónap múlva. Remélhetőleg felveszik a kesztyűt és ők is komolyan veszik a dolgot. Továbbá előtte kipróbálják azért a tesztalkalmazást, esetleg megcsinálják benne a szükséges változtatásokat, hogy fusson a saját appszerverükön is.

Közvélemény kutyatárs

Még tavaly kitettem egy közvéleménykutatást, miszerint:

what's this language / legyen már vége a napnak / infót sokat

Köszi a válaszolóknak! Az eredmény az lett hogy az 'infót sokat' nyert orrhosszal hat szavazattal. A 'legyen már vége a napnak' ezüstérmet érdemelt négy szavazattal, és volt egy poénos vagy magyarul nem beszélő válaszadó, aki a 'what's this language'-nek is szerzett egy becsületpontot.

Most arról tettem ki klikkelnivalót, hogy ki mennyire érzi profinak a munkáját. Egy régebbi cikkben olvastam, hogy a programozók a hobbyprojektjeiket -ha vannak olyanok- sokkal jobban megcsinálják, a munkahelyen pedig általában megy a gányolás az időkényszer és az inkompetens döntések miatt. Néha úgy érzed, jobb lenne elmenni birkát legeltetni? Vagy minden reggel úgy mész be a munkahelyre, hogy aznap is kicsit hozzájárulsz a világmegváltáshoz? A határidő júni 30, a válaszadók között kisorsolunk 5db Eclipse Ganymede fejlesztőkörnyezetet.

JUM VI.

Ismét volt JUM.

Az első előadáson a komponensmodellekről hallgattunk egy elég általánosan induló prezentációt, miközben az alábbiak jutottak eszembe:

• A komponens-orientáltság az objektum orientáltsághoz hasonlóan nem minőségi jelző, hanem csak egy módszer, amit mellesleg lehet jól és rosszul csinálni.


• Keretrendszer használata nem cél hanem eszköz. Mostanában egyre jobban kezdem értékelni azokat a szoftver megoldásokat, amik nincsenek teledobálva buzzword kompatibilis komponensekkel, viszont működnek.


• Problémamegmaradás törvénye: 'A probléma nem vész el csak átalakul'.

Ennek ellenére szoktunk használni framework-öket, pl. a Spring-et elég sokszor, egészséges felfogásban. (Szóba került hogy egy Magyarországon nemrég tanyát vert igen neves pénzügyi nagyvállalat is elég komolyan használja a Spring-et.)

Azért leírom mely versenyzőkről volt szó:
Spring, Guice statikus IoC frameworkök.
OSGi, Java Moduling System azaz JSR-277. Az utóbbit a Sun hozta létre az OSGi ellenében. Az előbbi pedig már jó régóta létezik és az embedded device-ok környékéről indult.
Valamint SCA, ami általánosabb, ha jól emlékszem az IBM nyomja.

A második előadáson kocka mutatott be egy Flex-es alkalmazásról szóló prezentációt. A jhacks-ról le lehet tölteni a prezit és a példaprogramot is.

XML-ben és ActionScript-ben kell összetolni az oldalt. Az IDE támogatás nélküli scriptelés már kicsit fájt a syntax highlight-hoz és auto completion-hoz szokott fejemnek. Elvileg a Parleys-t full Flex-szel húzták fel. A buildelés itt sem tart kevés ideig, 1-2 percekről beszéltünk, mint ahogy GWT-nél is. Elvileg az OpenLaszlo buildelése gyorsabb, de annak nem túl szerencsés az RPC modellje, mert statikus függvényeket használ és mindenképpen a saját proxy-jával akar kommunikálni.

Továbbá volt még egy Appserver deatmatch című történet, ahol Geronimo, JBoss és Glassfish szerverekkel csináltunk volna meg 8 műveletet, úgymint távoli deployolás, alkalmazás beüzemelése, log konfig megváltoztatása, jMeter-es terheléses teszt, újraindítás, datasource megváltoztatása, LDAP azonosítás, valamint távoli debugolás. Sajnos a Geronimo-s ember lemondta, a JBoss beüzemelése pedig nem sikerült, de a Glassfish demót nagyon hozzáértően tolták. Kicsit rövid volt az idő a tesztalkalmazás publikálása és a demó között, ezért én némileg megértem a technikai nehézségeket, de remélhetőleg 2 hónap múlva láthatunk majd más versenyzőket is. A Glassfish mutatványt egy másik postban írom le nemsokára.

Azon kívül láttam még szép színes notebook-okat, pingvines játékot és szóba került, hogy el kell menni birkát legeltetni. Sörözés most nem volt.

Google jobs

Az elmúlt időben a felröppent pletykák miatt figyelemmel kísértem a Gugli aktivitását kishazánk környékén. Az első blogbejegyzéseket 2006 májusából találom a témában.

Az Utazás kiállításon volt egy Google egyetem, ahol láthatóan nagyon a reklámozásra gyúrtak. Peresztegi Zoltán beszélt arról, hogy mit akar a Google Magyarországon. Egyelőre nem sok válasz volt a kérdésre. Volt Interjú Dennis Woodside-dal a Google kelet-európai piacokért felelős igazgatójával. Mégegy, ami elég béna és mégegy, részletekbe menő. A magyar emberek még: Hegyi Péter (Dublin), Stekkelpak Zoltán, Baloghy Réka, Bódis Attila, aki az Official Google Blog-ba ír. dLux pedig Zürichben nyomja (lásd később).

2007 májusában volt Londonban Google fejlesztői napok: Beszámoló róla.

Aztán úgy folytatódott, hogy írták a zindexen és az sg.hu -n, amikor nálunk járt Vint Cerf, hogy a Google próbafelvételiket tartott egyetemisták körében. Olyasmi lehetett, mint a Morgan Stanley-s téma, hogy logikai feladatokkal traktálták a delikvenseket, plusz "mitírki" feladatokat kellett megoldani. Állítólag előny volt, ha valaki több programozási nyelvben is otthon volt. Ez a Felkeltette az érdeklődésemet, bár lemaradtam az előadásról.

Gondoltam, mindenesetre érdemes lesz nézegetni néha a google.jobs -ot, ahol Magyarországot illetően már volt néhány állásajánlat, de még egyik sem fejlesztői. Konkrétan ezek:
• Account Manager - Budapest
• Account Strategist - Budapest
• Associate Product Marketing Manager - Budapest
• Country Business Manager - Hungary
• Emerging Markets Strategy Associate - Europe
• Global Deployments Project Manager - Budapest
• Product Marketing Manager - Budapest

Láthatóan Lengyelországban jobban nyomultak, vagy legalábbis előbbre tartottak ebben az időben. Fejleszőket kerestek és tanulóknak is voltak lehetőségeik. Romániában semmi, Szloviban country consultant-ot kerestek, a cseheknél valamivel mögöttünk voltak. Októberre eltűnt a szlovák country consultant ajánlat.

A fenti állásajánlatok közül július közepére kettő ki lett lőve. (Associate Product Marketing Manager és Product Marketing Manager.) Viszont Dublinba kerestek magyarul beszélő Editor-t és Online Sales and Operations coordinator-t. Emellett sokféle nyelven beszélő embereket. Az SG-n ismét volt egy cikk, hogy ez a Google egy milyen marhajó hely, de voltak olyanok is, akik némileg objektívebben összehasonlítottak több mammutcéges munkahelyet is (MS, Yahoo, G).

Augusztus elejére Dublinban elkeltek az állások és az Emerging Markets Strategy Associate is eltűnt, tehát ezek maradtak:
• Account Manager - Budapest
• Account Strategist - Budapest
• Country Business Manager - Hungary
• Global Deployments Project Manager - Budapest

Augusztus közepére a Country Business Manager állás is gazdára talált, vagy pedig feladták.

Szeptember 19.-én publikáltak egy Hardware Operations Team Manager állást, ami arról szól hogy infrastruktúrát kell tudni összedrótozni, illetve gondolom a későbbiekben egy ilyen csapatot el kell tudni vezetni. Mindenféle Linux-Unix ismeret előny. 27-én pedig a Webisztánon volt egy bejegyzés a Reuters hírei alapján affelől hogy látszólag Európában akarnak fejleszőket toborozni.

Október elején pedig kinevezték Nelson Mattos-t az európai, közel-keleti és afrikai (EMEA) térség mérnöki tevékenységekért felelős alelnökének. A cikk leírja még, hogy hol vannak a térségben fejlesztőközpontok. Van pl. Krakkóban, ami meglepett. (Varsóban nincs.) Közben volt a TV-ben egy film, a "Google kulisszatitkai" címmel, de jól lemaradtam róla.

Egyébként pedig végzős fejlesztőket kerestek Prágában, Krakkóban, Zürich-ben és még több helyen. Nálunk nem. Svédországban pedig rengeteg állásajánlat van.

2007 Október 8: Data Center Technician (Temporary). Linux cluster összepakolásához.

További mozgások:
2008.01.15, Magyarország:
Account Manager - Budapest
Country Business Manager - Hungary
Data Center Technician (Temporary) - Budapest
Hardware Operations Team Manager - Budapest
2008.02.06
+Account Strategist - Budapest
2008.02.22
+Senior Financial Analyst - Budapest
(Közben Prágában 10 ajánlat van, közte Senior SD, szlovák-cseh-angol.)

Most pedig megnyitott a Zürich-i iroda, ami világossá tette, hogy nem lesz Magyarországon fejlesztés. A Webisztános cikk elég sokmindent leír három részben, nem is kell tovább ragozni.

Update 2009.01.22: A Google magyar munkatársai elindítottak egy blogot -sajnos keresőmarketing kategóriában. A bloggolók között van néhány fentebb említett név. Egyébként kismillió blogot találok mostanában, ami az online marketing témával foglalkozik. De minek.

Mobilhelyzet, Android

Lassan közeledik az Android Developer's Challenge névleges határideje, most van Barcelonában a Mobile World Congress (cikk róla magyarul) amin biztos bemutatnak pár Androidos prototípust, ráadásul januárban volt egy Sun Mobile Embedded Developers Days is (ahol inkább nyilván a JavaME-t és a JavaFX-et hájpolták, de elhangzott egy olyasmi mondat, hogy az "Android mindenesetre kiváló bizonyíték rá, hogy a mobil technológiában lenne mit jobban csinálni"), úgyhogy íme néhány link az Androidról és a mobil technológiáról, ami összegyűlt az utóbbi időben.

Megjelent egy könyv "Nehogy már a mobilod nyomkodjon téged!" címmel. Tartalomjegyzéke megtekinthető itt. Van szó benne Androidról is (kb 10 oldal), de alapvetően MIDP-re és Netbeansre épít.

Itt pedig egy szerintem kifejezetten ronda, ráadásul valószínűleg kamu Android kütyü látható élőben. A kanadai La Mobile egy HTC Qtek 9090-esbe tett Andriodot. Ugyanerről a Webisztánon.

Cikk a Webisztánon arról, hogy elkésett-e az Openmoko. Ugyanitt videó a Bp Meetup-os Android előadásról. A meetup-on előadó Kis Gergely elérte, hogy egy Zaurus SL-C760-on fusson a Google Android (ezt is a Webisztános Openmoko cikk kommentek között találtam.)

Developer Podcast, amit meg akartam nézni de elnapolódott, úgyhogy nem tudom mi van benne.

Javafórumról link egy blogra, ami azt fejtegeti, hogy megéri-e nevezni az ADC-re, valamint egy másik, hogy kinek hoz pénzt. A Részvételi feltételek hivatalos oldala. Egyébként a március 1-es határidőt meghosszabbítják április 14-ig. Jó ötlet, bár nem érint.

Sok Android hír mp3-ban még decemberből. Nem muszáj meghallgatni, a fontosabb linkek kinn vannak az oldalon. Ha már JavaPosse, itt van egy interjú a JavaME-ről.

NetBeans plugin Roumen-nél, hogy ne csak az Eclipse-esek örüljenek.

Futtassunk Scala-t az Androidon!

Az Androidra visszakanyarodva, decemberben elméletben még foglalkoztatott az ADC-n való indulás, de aztán más melók miatt elkallódott ez a törekvés. Szerintem olyanoknak volt érdemes ezzel foglalkozni, akik egyébként is mobil (MIDP) alkalmazásokat csinálnak és viszonylag kevés plusz munkával át tudják portolni Androidra a cuccot. Ezzel viszont az a gáz, hogy a G-nek át kell adni a szoftvert, legalábbis a kliens oldalt. Ahogy a fenti linkek valamelyike említi nem túl jó biznisz anyagilag az ADC, legfeljebb hírnév szempontjából.

Egy olyan alkalmazáson gondolkodtam, ami a mobil kameráját (majdnem mindben van már) vonalkód leolvasására használja. Sima kereskedelmi vonalkódokat és speciális vonalkódokat tudna leolvasni, amik pl. URL-eket tartalmaznának.

A kockázatelemzésig nem jutottam el, szóval nem tudom, hogy egy mobilos kamera egyáltalán be tudna-e fókuszálni rendesen egy szokásos méretű kereskedelmi vonalkódot. Lehet hogy nem. Az URL-es vonalkód viszont spanyolviasznak bizonyult, mert már létezik ilyen és Semacode néven fut, csak sehol sem használják. Legalábbis sehol sem láttam még.

Pedig jó buli lenne rányomni plakátokra, hirdetésekre, menetrendekre, buszmegállókra, bögrékre, pólókra, kocsira, sportolókra, járdára, házfalra a szokásos nyomtatós, matricázós technológiával (micsoda kampánylehetőségek!), aztán lehetne böngészni, letölteni, vásárolni, rendelni, belenézni, utánanézni, belehallgatni, játszani, tippelni, fogadni az URL bepötyögése nélkül.

A szokásos vonalkódokat leolvasva pedig árösszehasonlító, vélemény megmondó, statisztikai oldalakon lehetne lekérni az adott termékről az információkat, nem azt amit helyben a boltban hazudnak róla.

Na, ti örülnétek ilyen alkalmazásoknak?

Update 2008.12.09: Közben ahogy a megjegyzésekben is írtam, az ADC-n is igen jó helyezést ért el egy ilyen vonalkódolvasó szoftver, és a sima mobilgyártók is kezdik felnyitni a szemüket.
Update 2009.01.23: Ismét egy sg.hu cikk. Ahogy látom Japánban már több éve használják a 2D vonalkódot. Olyan is van, hogy Semapedia.

JUnit 3.8 Intermed

Azt gondolná az ember hogy tesztesetek írása csupa unalmas ujjgyakorlat.
Itt most ismét JUnit 3.8-as dolgokról lesz szó + általános elvekről.

Failures vs Errors

Alapvetés: A failure és az error is elbuktatja a tesztesetet. A failure-re számítunk, az error-ra nem.

A failure AssertionFailedError-t eredményez. Hogyha a teszt amiatt bukik el, hogy a setUp()-ban vagy a tearDown()-ben exception keletkezett, az pl. error-t eredményez.

Figyelem: A fail()-t és az elbukott assert-eket elkapja a catch(Error), mivel ezek AssertionFailedError-t dobnak. Úgyhogy ha valami (különös) oknál fogva Error-t kell elkapnunk vagy ellenőriznünk, az AssertionFailedError-t tovább kell dobnunk, mert különben szépen csendben elnyelődik. (Pl. külön catch ágat adhatunk az AssertionFailedError-nak.)

A teszt metódusokat el lehet látni throws kitétellel. Ha bekövetkezik az exception, Failure lesz a teszt eredménye. Az a mondás, hogy jobb throws kitételt írni a teszt metódushoz, mint a metóduson belül catch-sel elkapni és kézzel fail-t hívni. "Sosem kapjunk el nem várt exception-öket."

Text test runner kimenetei:
. pass, F:failure, E:error

Assertions

Az asserteknél általában mindig az első paraméter a várt, a második a kapott érték. Ha message is tartozik az assert-hez, az ezeket mind megelőzi.

assertNotNull: van ilyen, nem kell assertEquals(true, obj==null)-t használni.

Az assertSame szolgál a referenciaegyenlőség vizsgálatára.

Az assertEquals nem használható tömbök egyezőségének vizsgálatára. Tömbök egyezőségének vizsgálatához ez ajánlott:
assertTrue(java.util.Arrays.equals(expected, actual));

Redundant assertion antipattern: pl. assertTrue(true)-t betenni olyan helyekre (több helyre), ahova szerintünk elér a vezérlés.

Egyebek

junit.extensions package: A test decorator-ok, mint például a RepeatedTest arra valók, hogy különféle kiegészítő viselkedéseket vezessünk be a tesztek futása előtt illetve után. A test decoratorok tehát nem test suite-ok.

Nem lehet párhuzamosan (szimultán) teszt metódusokat futtatni egy TestCase-en belül. Az ActiveTestSuite-tal lehetőség van tesztek futtatására oly módon, hogy minden hozzáadott TestCase külön szálban indul el párhuzamosan, de a TestCase-eken belül a teszt metódusok továbbra is egymás után hajtódnak végre valamilyen sorrendben.

Interfészekkel tesztelni egyszerűbb. Emiatt (extrém megközelítés) a tesztelés szempontjából elónyösebb, ha a tesztelendő komponensben minden interfész. (A lokális változók, a visszatérési értékek és a függvény paraméterek.)

Hogyan győződhetünk meg róla, hogy a tesztjeink függetlenek egymástól:
-Ugyanazokat a teszteket futtassuk kétszer egymás után.
-Futtassuk a teszteket különböző sorrendben.
-Néhány tesztet üssünk ki mesterségesen és győződjünk meg róla, hogy a többi teszt továbbra is rendben lefut.

A TestSetup osztállyal lehetőség van a normál setUp és tearDown működést kiegészíteni pl. így:

 public class TestBigClass extends TestCase {
      public void testMethod1() {
          System.out.print("A");
      }
      
      public void testMethod2() {
          System.out.print("B");
      }

      public static void customSetUp() {
          System.out.print("C");
      }
      
      public static void customTearDown() {
          System.out.print("D");
      }
      
      public void setUp() {
          System.out.print("E");
      }
      
      public void tearDown() {
          System.out.print("F");
      }
      
      public static Test suite() {
          TestSuite suite = new TestSuite();
          suite.addTestSuite(TestBigClass.class);
          
          TestSetup setup = new TestSetup(suite) {
              public void setUp() {
                  customSetUp();
              }
              
              public void tearDown() {
                  customTearDown();
              }
          };
          return setup;
      }
  } 

A futtatás eredménye: CEAFEBFD vagy CEBFEAFD, mivel A és B sorrendje elvileg véletlenszerű, tehát a custom setup és teardown közrefogja a teszteket a normál setup és teardown-okkal együtt.

A JUnit a lelke mélyén nagyjából a következő template metódust használja a tesztek futtatásához:

public void runBare() throws Throwable {
     setUp();
     try {
         runTest();
     } finally {
         tearDown();
     }
} 

Fontos megállapítás, hogy mindent dobhat (throws Throwable) és a tearDown() mindenképpen lefut.

Minták

Mock object: stub (static return)- fake (not yet implemented) - mock (valamit csinál) Bővebben.
Self-shunt: A tesztosztály egy callback jellegű interfészt implementál, ahol magukba a callback metódusokba írjuk az assert-eket.
Crash test dummy: Hibakezelés tesztelésére. Szándékosan hibát idézünk elő. Elkapjuk a várt kivételt és esetleg megvizsgáljuk a paramétereit vagy a környező változókat.
AbstractTestCase: Az absztrakt teszt eseteket is a TestCase osztályból örököltetjük, csak teszünk bele absztrakt metódusokat, például különféle factory metódusokat amelyek a tesztekhez szükséges objektumokat gyártják le. Az absztrakt tesztosztályban csak a közös vonásokat teszteljük le.
Extract repetitive setup code to fixture: Ne ismételjünk fölöslegesen a teszt metódusokon belül. Emeljük ki az ismétlődő dolgokat a fixture-ökbe: setUp(), tearDown().
Collecting Parameter Pattern: Amikor több tesztmetóduson keresztül kell összegyűjteni az eredményeket, akkor a metódusnak átadhatunk egy paramétert, amibe az eredményt belepakolhatja. A junit.framework.TestResult egy olyan osztály, amit erre felhasználhatunk. Tárolja hogy mennyi teszt futott összesen, tárolja az error-ral és failure-rel elbukott tesztek referenciáit.
Parameterized test case: Egy előző postban már írtam ilyesmiről, JUnit4 témában. Nem tudom 3.8-ban hogyan működik.
Base test case: Erről nem találtam semmit, de biztos köze van az öröklődéshez.
Good test naming: Nevezd el ésszel a teszteseteidet.

Linkek

• A JUnit mélyebb lelkivilágáról.


• Javadoc


• JUnit Best Practices a Javaworld szerint. Hasznos okosságok.


• Antipatterns az IBM-nél.


• Egy előadás shownote-jai. Nem túl hasznos.


• A JUnit recipes című papírkönyv, amiben sokminden benne van.

JUM V.

Megvolt az ötödik is. Kocka leírta hogy mi volt, az éppen építgetés alatt lévő Javafórumon pedig született egy-két topik a találkozó után. Egyik a JasperReports-ról, másik a Java 7 vitafórumról. A régi általános paláver topik pedig itt van.

A fórumon leírtakon kívül még szóba került, hogy a Windows (Vista?) eléggé .NET alapú, ami érdekes helyzetbe hozhatja a JVM-eket. Márminthogy .NET-re kell írni a JRE-t. Jobban belegondolva nem hiszem hogy ez akkora gond lesz.

Érdekes dolgok történnek mostanában, annak ellenére hogy a Java halott.

Ha jövőre véletlenül a Javapolis felé vetődnék: Sajnos elfelejtettem, hogy Antwerpenben drága vagy olcsó a tömegközlekedés és a belvárosban vagy a külvárosban érdemesebb szállást foglalni. Arra emlékszem, hogy nem szép hely, viszont jövőre is ugyanott lesz a JP.

A következő JUM március 19.-én lesz és elvileg GWT-re, SOA-ra már lehet számítani. Sörözés közben még súgtak izgalmas ötleteket a következő vagy az azutáni JUM-ra, de nem tudom mennyire publikus úgyhogy nem írom le.

Swing GUI trükkök

Éppen Swing-gel tolom. Íme néhány szépség, csak hogy látható legyen, hogy nemcsak a webes GUI készítésnek vannak meg a szépségei.

-A JFileChooser nagyon lassú Java 1.6_02-vel és 1.6_03-mal Windows-on, ha a megnyitott könyvtárban nagy zip fájlok vannak. Van róla bug report is. Több percig is eltarthat, mire megjelenik a dialógus ablak. Addig a hívás blokkolva van. 1.6_01-gyel nem lassú és ahogy nézem az 1.6_04 release notes-jában szerepel hogy javították.

-Swing komponens konstruktorába továbbra sem érdemes bepakolni a setVisible(true) hívást. Főleg modális dialógus konstruktorába, mert akkor a konstruktor hívása után már nem lehet semmit hozzádrótozni, mivel a setVisible(true); utáni kódrész csak a dialógus lezárása után hívódik meg. Modális dialógust átírni nem modálisra (és visszafelé) eléggé termékeny a hibalehetőségek szempontjából. Különben sem jó ötlet túl sok mindent bepakolni a konstruktorba, ez általános szabály két dolog miatt: 1. Biztos nem lenne hasznos valahol máshol a konstruktorba került inline funkcionalitás egy külön függvényként? 2. Öröklésnél a szuperosztály konstruktorának hívásánál még nincsenek beállítva a leszármazott osztályok mezői. Emiatt konstruktorban nem szerencsés a leszármazott osztályban (felül)definiált metódust hívni, főleg ha az a leszármazott osztály mezőit is használja.

-A JScrollPane-be ágyazott JPanel-eknek van egy rettentően kényelmetlen tulajdonságuk, mégpedig hogy amikor az egérrel görgetjük a külső scrollpane-t és ráfut az egér egy belső panelre, a görgetés hirtelen abbamarad. Erre lehet leleményes workaround-okat csinálni, kérdés hogy melyik Look and Feel-en hogyan működik.

-Look and Feel-eket cserélgetni programfutás közben -bár csábító a lehetőség- nem igazán ajánlatos. Nem mindig sikerül minden úgy ahogy kéne. Nálam néha beragadtak komponensek, azaz a GUI nagy része lecserélődött, de egy-két gomb megmaradt a jól megszokott metál stílusban. Különben -ahogy a JavaPosse-ben megmondták, a Swing Look and Feel-ek kicserélhetősége csak egy elméleti dolog, mert nem skin-ekről, hanem komponensekről van szó. Ha egyik készletben egy komponens így működik másikban meg úgy, az zavart okozhat. Említettek valami okosságot a témában, majd utánanézek. Egyelőre nem találtam meg, csak egy oldalt, ahonnan sokféle L&F letölthető. (JavaPosse 103)

-A JLabel és JButton kényelmetlen tulajdonsága, hogy többsoros szöveget csak HTML tag-ek segítségével tud megjeleníteni. Ez nem is lenne baj, viszont ilyen többsoros szövegnél már nem működik a setEnabled(false). Ajánlanak különféle megoldásokat, de egyik sem nagyon elegáns. Az alapprobléma az, hogy nem mindig elég egyszerűen kiszürkíteni a feliratot, mert némelyik look and feel-ben a bevésett halvány szöveg jelenti a letiltott label-t. Próbáltam azt is, hogy egy JEditorPane-t konfiguráltam úgy, hogy labelnek nézzen ki, de az meg a fókuszt kavarta el az oldalon és ezt nem is tudtam kiküszöbölni a setFocusable-vel és társaival. Végül úgy csináltam meg, hogy HTML-es labelt használtam, aminek setEnabled(false)-nál mondtam egy szürke színt és kész.

-A Swing komponensekhez a setClientProperty()-vel objektumokat lehet rendelni, amit aztán a getClientProperty()-vel vissza lehet olvasni.

-A Swing eseménykezelését továbbra is érdemes tanulmányozni. Legrosszabb megoldás ha egyáltalán nem foglalkozunk vele (eseménykezelőben, pl. actionPerformed semmi új szál, hanem csak az akciókód - ilyenkor hosszabb műveleteknél a GUI úgy néz ki mintha lefagyna), közepesen rossz megoldás ha mindig külön szálat indítunk az eseménykezelőkben. Jó megoldás az invokeAndWait és az invokeLater használata.

-A fest-tel nagyon jól lehet Swing-es GUI-kat tesztelni. Töltögeti a szövegmezőket, nyomogatja a gombokat szorgalmasan ahogy beprogramoztuk, csak legyen beállítva a Swing komponensek neve és legyen úgy görgetve a scrollbar, hogy látszódjon az ablakban amire klikkelni kell. Egyszerre egy klienst lehet tesztelni és jól lefogja az egész desktopot, úgyhogy ilyen jellegű tesztelésnél érdemes újságot, könyvet vagy másik számítógépet kéznél tartani, vagy elmenni kávézni.

-Ezt is beraktam a csőbe, majd valamikor elolvasom: WebCream 6.0 Swing alkalmazásokból AJAX-os webalkalmazásokat csináló medzsik (lásd még: Javaposse 137).

Amíg az embernek nincsenek túl nagy extra igényei egész jól el lehet lenni Swingben. Azonkívül ez még mindig igazán szórakoztató ahhoz képest, mint amikor JSF-ben (GWT-ben, Tapestry-ben vagy akármilyen webes GUI keretrendszerben) kell percenként aknákat kerülgetni.