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ő.