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!