Bp Newtech Meetup

Elég dinamikusan alakult a januári Bp. Newtech Meetup programja. A blog szerint az volt az alapfelállás, hogy megismerkedhetek majd végre a l3onardo-val (a.k.a 3dForAll) és a Google App Engine-nel, amit az OpenSocial fejlesztésekhez használhatnak szerveroldalnak azok, akiknek nincs saját szerverük vagy környezetük. (Ha jól tudom Python-ban kell programozni.) A l3onardo lemondódott, helyette viszont bejött egy Microsoft-os hardver -a Surface- bemutatása (interaktív asztal), ami szintén hamar lemondódott. Mindegy, maradt még a TurulMeme, ami érdekelt valamennyire, meg a többi előadás is "szőrmentén". Egyébként is régen voltam már.

Velvárt András (Response) - Zoomery - Anything Zooms!

Microsoft Silverlight technológiára épülő, DeepZoom technológiát használó, weboldalba is ágyazható alkalmazás. Vannak dokumentumaink amiket képpé konvertál és a Google Earth-hoz hasonló módon jól belenagyíthatunk a felületen szétszórt esetenként több száz oldalba. Lehet rendezgetni, keresgélni benne. Képalbumok készítéséhez is jó. Lényegretörő előadás jó demóval gond nélkül a szervezői Macintoshon, ami a MS-es technológia miatt nagy szó hogy pöccre működött. Apropó, a notebook képe a vetítővászonra volt kirakva, ami elég jól nézett ki a Bem moziban. Szóval jó képet csinál egy ilyen Mac. Csak sajnos elég kicsi volt ez a mozi és állítólag sokan nem fértek be a terembe, kinn ragadtak. Kb. 130-an regisztráltak, kb voltak is annyian. Kifelé jövet a pultnál sem lehetett egykönnyen forralt borhoz jutni. Node visszakanyar az előadásokra:

Bíró Tamás (SenseNet) - Hibrid open source - azaz nyílt forráskód Microsoft alapon

Ahogy a címből nem derült ki ők ECMS (Enterprise Content Management System) fejlesztéssel foglalkoznak. A cég immár több mint 10 éve megvan, 40 fős, 400 milliós az éves forgalmuk ami főleg a bemutatott termékre épül. C#-ben írják a szoftvert, eddig nem volt nyílt forrású mostantól pedig az lesz. Pár viszonylag nagyobb hal használja a terméket, pl. tv2. Valamennyire konkurenciájuk a SharePoint és ha nem kötött a platform, az Alfresco (java). Érdemes tudni róla, hogy van egy ilyen alternatíva.

Hodicska Gergely - Ustream Watershed API

Az UStream egy szilícium-völgyi cég akik saját elmondásuk szerint nagyjából egyeduralkodóak a live video streaming területen. Ezek szerint van magyar vonatkozásuk is. Gyakorlatias előadás volt ahol megmutatták, hogyan lehet egy mobiltelefon kamerájáról élőképet sugározni a weben. Ez látványos volt: a mobilról 3G-n bement a kép az internetre, egyenesen USA-ba, valamelyik szerverükre (használhattak volna Magyarországon lévő tesztszervert is, de valamiért nem így jött ki). A böngészőbe az URL-t beírva az élőkép megjelent a mozivásznon. Kicsit szaggatott és keveset késett, de egy mobilról ennyi belefér. Az üzlet a dologban, hogy (pézért) bárki használhatja a szolgáltatást, felteheti a saját logóját a sarokba, lehet mindenfélét konfigurálni, max hányan nézhessék egyszerre, beágyazható saját weboldalba, stb. Kíváncsi lettem volna a technológiákra és hogy mi a magyar csapat szerepe - nemrég valami fejlesztőket is kerestek ha jól emlékszem. Legfeljebb majd emailben megkérdezem.

Séra László - TurulMeme

Ahhoz képest hogy a baráti társaságom nagy része magasan képzett informatikus, a mai napig szeretnek "FW: király", "vicces!" című egylinkes leveleket küldözgetni kézzel összerakott címlistára vagy levelezési listára. Amellett hogy nem vagyok lusta nyomogatni a delete gombot, bizonyos linkekre kíváncsi lennék néha attól függően hogy ki küldte és milyen témában. Van erre már kismillió megoldás a digg-től a delicious-on keresztül az furl-ig. Annyira érdekel a téma, hogy még én is elgondolkodtam egy ilyen rendszer fejlesztésén -ami a meglévőek hiányosságait pótolja, sőt valami kis prototípust össze is dobtam magamnak. (Lehet hogy egyszer majd írok róla.) A TurulMeme-re visszakanyarodva kíváncsi lettem volna rá 5 percben, hogy miben jobb ez az említett rendszereknél és miért lesz nekem nagyon jó ha csatlakozom. Sajnos ezekre a dolgokra nem kaptam választ. Az előadó inkább csak azokkal a témákkal foglalkozott egy prezentáció pontjaiban amiket ő tart érdekesnek. Az idő is gyorsan elszaladt, úgyhogy csak egy kérdésre maradt idő. "Miért?" Ami mégiscsak nekem is érdekes volt: szintén MS technológia, MSSql, C#, Lucene (azt hittem ez java-s!), 2 nap alatt fejlesztették ki, legalábbis az alapjait. Közben rápillantottam a turulmeme.com-ra és első ránézésre úgy néz ki mint egy sima híraggregátor szájt, amiket általában nem szeretek. Azon kéne dolgoznia valakinek, hogy ez a véleményem megváltozzon. Végül a névről: szerintem elég röhejes még akkor is ha Turulmém-nem kell ejteni.

Megemlítették még a szervezők hogy a rendezvényt a Virgo Systems szponzorálta, ha jól hallottam. Ja igen, osztogatásra került még egy kis könyecske: Startup Guide, vagy Üzleti Tanácsok Kisvállalkozók részére a pressonline támogatásával. Innen is letölthető egyébként, még nem olvastam bele.

+1, ami nem előadás volt, hanem csak úgy hallottam: AutoHotkey. Érdekes script-eket lehet csinálgatni mindennapi használatra, állítólag hasznos / jópofa. Open Source.

Sajnos alig volt ismerősöm az eseményen, úgyhogy nem tűnt annyira jó bulinak ottmaradni toporogni a tömegben. Na majd legközelebb, a 2 éves szülinapon.

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.