2008-11-20

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:

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!

2008-11-17

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.

2008-11-10

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.