Archiver wanted

Időnként backup-ot szoktam csinálni a notebook-om vinyójáról, de -hogy is mondjam- elég kezdetleges módszerrel: Simán átmásolom a partíciókat egy külső USB-s HDD-re. Illetve most már csináltam egy kezdetleges szoftvert, ami nem akad el ékezetes fájloknál (mint a windows vagy a Total Commander néha), normálisan előre összegyűjti a különbségeket amiket másolni kell, viszonylag értelmesen kiírja hogy mennyi van még hátra, nem zabálja a procit és a memóriát és tudom hogy mi van ha a művelet közben leállítom. Viszont még nagyon sok funkció hiányzik belőle. Talán érdemesebb lenne választanom a meglévő archiváló szoftverek közül, minthogy ezzel pepecselek, de semmi ingerenciám használhatatlan programokkal való szíváshoz és (un)installálgatáshoz. Megmondom őszintén, a legkevésbé kedvelt elfoglaltságaim közé tartozik Google alapján találomra letöltött programok kipróbálgatása, úgyhogy inkább megkérdezem: Tudtok jó archiváló/másolat készítő szoftvert ami teljesíti az alábbiakat?

• Fusson Windows XP-n és Vista-n, de ne akarjon nagyon beépülni a rendszerbe. Ne másszon bele a registrybe, ne indítson service-t, ne rakjon bele új menüpontokat a könyvtár explorerbe. Nem gond ha Java.
• Értelmes GUI-ja legyen, amihez nem kell pilótavizsga.
• Tudjon külső USB-s vinyóra archiválni. (Ez nem egy nagy igény.)
• Meg lehessen mondani neki, hogy mely könyvtárakat archiválja, melyeket hagyja ki.
• Természetesen támogassa az incremental backup-ot. A régi fájlokat felülírhatja, nem gond.
• Legyen nagyon reszponzív: Mindig tudjam hogy hol tart. Normálisan írja ki hogy mennyi idő és hány kilobájt van hátra a másolásból. Az sem árt ha az átviteli sebességet kiírná.
• Bármikor para nélkül le lehessen állítani. Archiválás közben is lehessen használni a gépet.
• Jó lenne ha tudna olyat, hogy eleve titkosítva írja ki az archívot, és akkor kellene egy olyan szoftverkomponens is, amivel ebbe a titkosított archívba bele tudok nézni. Ezt a szoftverkomponenst jó lenne ha nem kellene installálni, hanem akárhova bepottyantva működne. (Tipikusan az archív mellé tenném be a külső vinyóra és onnan futtatnám.)
• Ha jelszó alapú titkosítást tud már az is jó, de szuper lenne ha valami kulcsos megoldást is támogatna.
• Legyen ingyenesen letölthető, korlátozás- és köcsögségmentes.

Ezek az igényeim. Tudtok valami olyan szoftvert ami ezeket biztosítja? Vagy kénytelen leszek tovább reszelgetni a sajátot?

JUM XII.

Elsőnek Viczián István beszélt a JAX-WS mélyvízről. Számomra elég elrettentő hatása volt az előadásnak. Eddig nagyjából megkímélt a sors a SOAP technológiától és remélem ezután is így lesz. Találkoztam olyan projekttel, amiben szerepelt, de nem nekem kellett foglalkozni vele, vagy amikor hasonló megoldást kellett alkalmaznom találtam más módszert. Az előadás végén említésre került még pár hasonló SOA technológia. Ezek közül a REST-tel már volt dolgom és úgy érzem hogy az egészen használható egyszerűen azért, mert nem akartak mindent helyben megoldani, hanem az a mondás, hogy az üzenetek topológiája MásValaki Problémája, azaz ha akarom XML, ha akarom JSON, ha akarom akármi. És tényleg: én éppen JSON-nal használtam, ahol más formában szintén előjönnek hasonló dolgok amire JAX-WS és JAXB-nél figyelni kell. Cirkularitás, ilyesmik.

A második előadáson Csutorás Zoltán beszélt az agilis módszertanokról. Az elején az autógyáraknál és a közgázos diagramoknál nem értettem hogyan fogunk eljutni a szoftverfejlesztésig, de aztán szépen összeállt a kép. Kiderült számomra, hogy a Scrum nem egy levegőbe kitalált buzzwörd (mint a Cloud) hanem egy tanulmányokon és tapasztalatokon alapuló szigorú módszertan amit nem csak IT technológiában használnak. A Toyota gyárrendszere is hasonló elveken épül (Lean Management, bármit is jelentsen). Végülis engem a pipeline feldolgozásra emlékeztet ez az egész. RISC processzorok makrószinten. Három dolog biztos: Egyik hogy pár ügyféloldali managgert a környezetemből is elküldenék agilis módszertanokkal ismerkedni, mert az tényleg nem járja hogy először kiköpünk ezer oldal doksit az igényeik szerint, aztán leprogramozzuk vízesésben a hülyeséget. Másik dolog, hogy bebookmarkolom az előadó blogját és amint lesz időm rá olvasgatom. Harmadik dolog, hogy nem hallottam az előadáson csirkékről és disznókról, úgyhogy még biztos nagyon sokmindent nem tudok a Scrum-ról.

Uccsó előadás az Google Androidról szólt, amit nem kell senkinek bemutatni. Kiss Gergely a Linuxos oldaláról közelíti meg a dolgokat. Régebben egyébként már találkoztam vele egy Bp Newtech Meetup-on. Ő volt az, aki egy ősrégi kütyün életre lehelte az Android-ot, amikor még a fasorban sem voltak direktben ilyen telefonok. Az előadás legfontosabb hozama számomra a Hundroid portál és a magyar Android közösség bemutatása volt. (Van még ilyen is, nem tudom hogy ez ellenség-e vagy barát. Úgy látom PZ is kommentel úgyhogy ez valami hivatalos valami lehet.) Megkérdeztem tud-e magyar fejlesztésekről. Mondta hogy tud egy angol tanuló szoftverről, az Ustream-eseknek van Android implementációja, (Ustream-mel felvettük az előadásokat, utólag is megnézhetőek. Könnyen kezelhető, jó cucc! Valahol itt vannak a videók. Persze a minőség pocsék, van még min javítanunk.) és persze rögtön le is demózott egy kis alkalmazást: a saját OpenOffice prezentációját egy saját készítésű Androidos alkalmazással vezérelte bluetooth-on keresztül.

Jó sokan voltunk, a rendelkezésre álló időkeretet kicsit átléptük, sörözés úgy tudom most elmaradt, következő alkalom jövőre.

Megoldás

Szóval ott tartottam hogy Scala és Java programkódokat hasonlítgatok össze, ami egy tömbben egy adott karakter előfordulásait számolja meg. Egy szerény 30 millió karakteres tömbön próbálgattam a négyféle programkódot, amit az előző post-ban fabrikáltam össze tegnapelőtt: Volt sima for ciklusos és rekurzív algoritmus Java-ban és Scala-ban is.

Nézzük hogyan muzsikáltak:

Az első sima Java megoldás (1.) kb 160 ezredmásodperc alatt birkózik meg a feladattal. A Scala program, amibe a Java imperativizmusát másoltam le (2.), 1200 ezredmásodpercig dolgozik ugyanezen. Ez egyáltalán nem elhanyagolható különbség, de mégegyszer hangsúlyoznám, hogy ész nélkül írtam át a Java kódot Scala-ba: Egyszer talán majd pörgök egy post-ot ezen a különbségen is, de alapvetően "nem érdekel ez most engem".

Következőnek a (4.) Java programkódot tárgyalom ki, amit kvázi funkcionálisan írtam meg, rekurziót használva, viccből. Na ez már hatezer karakteres bemeneti karaktertömbnél is csúnyán elcsattan StackOverflowError-ral. Ha ismerjük a rekurzió működését, -azaz hogy a program minden egyes függvényhívásnál felépít egy stack frame-et- ez nem is túl meglepő. Ahány karakter, annyi stackframe: a verem hamar felzabálja a memóriát.

Végül jöjjön a (3.) funkcionális Scala program, ami a 4.-eshez hasonlóan rekurziót használ. Ez viszont nem száll el StackOverFlowError-ral, sőt egész jó időt hoz, kb. 160 ezredmásodpercet. Csak kicsivel lassabb mint a legelső kód. Hogyan lehet ez?

A megoldás kulcsa a farokrekurzió és annak kioptimalizálása. A dolog lényege, hogy a rekurzív függvény legutolsó művelete saját magának a meghívása. Még általánosabban, ha egy függvény utolsó művelete egy másik függvény meghívása (Tail Call). Ilyenkor levezethető, hogy a legutolsó stackframe újrafelhasználható, vagy legalábbis eldobható a következő függvény meghívása előtt. A jelenlegi Java-t futtató JVM implementáció nem támogatja ezt a feature-t. Vannak rá törekvések, ami talán új bájtkód prefixet is szükségessé tenne, de ez nem a közeljövőben fog megvalósulni. Biztonsági kérdések is felmerülnek, mert a Java nem optimalizálhatja ki csak úgy a stack frame-eket. Kivétel dobásánál vagy hozzáférési jogosultság ellenőrzésnél nem szerencsés ha hiányoznak frame-ek. A ScalaByExample.pdf -ami külön fejezetet szán ennek a magyarázatára- megemlíti hogy a Scala esetében farokrekurzió optimalizására lehet építeni, de a stackoverflow-n találtam még két kitételt ezen felül: Csak lokális vagy final függvények esetében.

Aki arra is kíváncsi hogy a Scala (valószínűleg) hogyan oldja meg, illetve hogyan oldható ez meg magas szinten egy nyelv meglévő elemeivel a program átírásával de az algoritmus jellegének megtartásával, az itt találhat egy kimerítő leírást róla. Elég messziről indul és körmönfont példát hoz, de egyébként nem egy bonyolult dolog. Hasonlít a Command Pattern-re.

Egyébként ezzel az egésszel csak arra akartam megnyugtató választ kapni, hogy a Scala-ban előszeretettel használt tail rekurzió megállja-e a helyét gyári környezetben. A válasz: igen.

Scala fejtvény

Ahogy beleolvasgattam egy-két Scala ismertetőbe az volt az érzésem, hogy folyton túl kézreálló példákat próbálnak hozni a nyelvhez. Arra gondoltam, csinálok egy olyan példát, ami nem annyira kézreálló. Számoljuk meg egy karakter tömbben a paraméterben megadott karaktereket. Sokkal kreténebb példákat is lehetne kitalálni, de én most megelégszem ezzel. Java-ban elég kézenfekvő a megoldás (1.):

public int count(char a, char[] array) {
  int ctr = 0;
  for(char ch : array) if(ch==a) ctr++;
  return ctr;
}

Ezt tükörfordításban ész nélkül kb. így lehet átírni Scala-ba (2.):

def count(a: Char, array: Array[Char]) : Int = {
  var ctr = 0;
  for(ch <- array) if(ch==a) ctr = ctr + 1;
  ctr;
}

Viszont a Scala funkcionális nyelv és ha ezt a paradigmát kihasználva szeretnénk megírni a programot, nem tehetjük meg, hogy ezt mondjuk: ctr = ctr + 1. Ez az a dolog, ami miatt ezt én "nem kézreálló példának" tartom. Ehelyett valami olyasmit kell elkövetnünk, mintha fél lábon állva a bal fülünket a jobb kezünkkel a fejünk mögött átnyúlva vakarnánk meg (3.):

def count(a: Char, array: Array[Char]) = {
def count_(i : Int, ctr : Int) : Int =
  if(i == array.length) ctr else
    count_(i+1, if(array(i)==a) ctr+1 else ctr)
  count_(0, 0)
}

Bár nem tartozik szorosan a témához, azért néhány Scala jellegzetességet gyorsan kiemelek: A külső függvénynek nincs meghatározva visszatérési értéke, mert kikövetkeztethető. Nem írtam pontosvesszőket a sor végére, mert a fordító így is érti miről van szó. Ja és ezek egymásba ágyazott függvények, ráadásul a belső függvény látja a külső bemenő paramétereit.

Csak a vicc kedvéért, ezt az utóbbit visszaírom java-ba, úgyhogy ha az előző megoldás nem volt érthető, talán ez tisztába teszi a dolgokat némileg a Java-s emberek számára is. Itt viszont már két függvényre van szükségem (4.):

public int count(char a, char[] array) {
  return count_(a, array, 0, 0);
}
    
private int count_(char a, char[] array, int i, int ctr) {
  return i==array.length ? ctr :
    count_(a, array, i+1,
      a==array[i] ? ctr+1 : ctr);
}

Namost a kérdés a következő: Szerintetek a négy megoldás mennyire gyors és mi történik (és miért - főleg ez a lényeges) ha egy jó nagy -de még nem akkora nagy hogy azonnal OutOfMemoryErrort okozzon- karaktertömböt adok meg bemeneti paraméterként? A megoldást megírom pénteken. Ha addig valaki bekommenteli a megfejtést, kap tőlem egy sört vagy ezzel egyenértékű élvezeti cikket a következő JUM-on.

JUM XI.

Nézőcsúcs született a tegnapi JUM-on. Mondjuk így könnyű, hogy nem két nappal az esemény előtt derül ki hogy mik lesznek az előadások és mi a helyszín. Az új Számalk épület igazán trendi, letisztult helyszínt szolgáltatott Wifi eléréssel.

Néhány szó az előadásokról:

PMD, Checkstyle - statikus kódanalízis
Ha arra vetemednél, hogy saját szabályok szerint akard ellenőrizni a Java kódodat (vagy másét) akkor ezek közül kell használnod valamelyiket. Az egyikben Java-ban kell vizsgálgatni az Absztrakt szintakszisfát-t, a másikban pedig XPath-tal kell bűvészkedni. A kód duplikációk is könnyen kibújnak a zsákból ezekkel az eszközökkel, mert nem lehet átverni őket megváltoztatott változónevekkel, kommentekkel és whitespace beszúrásokkal. Az előadáson nagyvonalúan átsiklottunk fölötte, hogy mi az az Antlr és Javacc, ami a PMD-ben ill. a Checkstyle-ben dolgozik. Nos, az utóbbi parser generátor és az előbbi is valami olyasmi. Lényeg hogy ha ezekbe betoljuk egy nyelv (jelen esetben a Java) formalizált szintaktikai szabályait, akkor tudnak olyan parser-t generálni, ami fel tudja építeni egy forrásfájlból a szintakszisfát. Aztán ezt lehet interpretálni, elemezni, compilálni. Talán egyszer ezekről a parser generátorokról is lehetne előadás.

Oktech profiler
Sok olyan kérdésre rávilágított az előadó, amin eddig nem is gondolkodtam el. Hogyan lehet profájlolni? Instrumentálni lehet a kódot, vagy mintavételezni a stacktrace-t. Mindkettőnek megvannak az előnyei és a hátrányai. Ők az utóbbi irányba indultak el és nyílt forrásúvá tették a kódot. A jelenlegi formában még elég száraz a kimeneti formátuma, de van benne perspektíva. Mivel a mintavételezéses profiling főleg kilóra tudja megmondani hogy mikor mi fut én olyan bővítéseket tudnék elképzelni, amik színes grafikonokat rajzolnak.

Google App Engine
Ez is jó előadás volt. Átjöttek a Google App fejlesztő legnagyobb szívfájdalmai: olyan a fejlesztés mint egy akadálypálya, ha tényleg akar valami komolyat csinálni az ember, hamar megtalálja a falakat. Van egy hosszú lista, hogy mely java frameworkök támogatottak, melyek részben és melyek nem. Alapvetően szervlet technológia, nagyjából van JPA, de vannak bizonyos korlátok, pl. max ezer fájl lehet egy alkalmazásban. Ha pl. Dojo-t akarok használni vagy más Javascript keretrendszert ami sok kis képet használ, akkor máris bajban vagyok. A GAE folyamatosan fejlesztés alatt áll, néha bejönnek új feature-ök, néha megjelenik valami új bekezdés a honlapon. Egy bizonyos forgalmi határig ingyenes, aztán pedig fizetős. Ez az ingyenes forgalmi határ sok kritériumból tevődik össze kezdve a napi processzoridőtől a napi max deployolások számáig. Ennek ellenére szeretjük a Google-t, mert még mindig látszik a törekvés hogy adni is akarnak valamit nem csak lenyúlni. Fontos még, hogy eredetileg Python-ra volt támogatás. Java csak idén tavasszal lett, ezért még mondhatni gyerekcipőben jár.

A JUM utáni sörözéseket kellene még komolyabban venni. Legközelebb akkor novemberben!

JavaFX Eclipse kipróba

Kitaláltam hogy beleszagolok a JavaFX-be.

javafx.com a hivatalos kiindulóoldal ahol vannak csilivili demók, de engem a rögvalóság érdekel, úgyhogy utánanézek mit kell letölteni ahhoz hogy én is tudjak ilyen szépségeket programozni. Ezt az oldalt találom, ami azt mondja van SDK, Eclipse plugin és a downloads-okra visz. A Netbeans is támogatja, de nekem most nem az van kéznél.

JavaFX Installálás: Kicsit le voltam már maradva a java verzióval is. Mondja hogy JDK6u13+ kell. Letölti, installálja 5 percig. Felhoz SUN regisztrációs oldalt, de nem kell tölteni. JavaFX install gyorsabb. Alapból Program Files-be akarja installálni (ja mert Windowson vagyok), de átállítom. Nem történtek nagy dolgok szerencsére, megjelent a Start menüben, plusz az install helyen. bin könyvtár, ilyesmik.

Eclipse plugin:
update site: http://javafx.com/downloads/eclipse-plugin/
Verzió: 1.2.0.20090528....
Az ajánlott 3.4.2 ganymede-re installálom néhány másik plugin mellé, mint pl. m2, SVN, WTP, Findbugs.

Sikerül az install. Új projekteknél megjelenik a JavaFX projekt. Néhány prototípusból tudok választani. Fotónézegető, 3D-s polc megjelenítő. A Spring (pattog két labda) példát választom - fordul, működik. Ha az lenne a célom, játszhatnák vele hogy változtatgatom itt ott a kódot, de most nem ez a célom. Lehet új külön JavaFX fájlot létrehozni, megjelenik a JavaFX perspektíva és egy külön Run opció a futtatáshoz.

Viszont nem túl komoly a támogatás.

Jobboldalt van egy Drag and Drop-os komponenskészlet kevés komponenssel, de grafikai szerkesztés nincs, csak bedobja a kódrészt ész nélkül oda ahova viszem az egérrel, akkor is ha szintaktikai hibát eredményez. A context assist működött egy darabig, de rövid használat után elromlott, azóta csak ClassCastException-t hoz fel az IDE újraindítása után is. A javafxdoc hover működik, de nekem nem tetszik a formátuma. Túl nagy betűk, ha böngészőben nézem szerencsétlen az elrendezése. Folyton scrollozni kell le-fel, le-fel, le-fel.

Egy egyszerű Swing-es GUI-t akarok átültetni próbaképpen JavaFX-re, ismerkednék a layout-okkal. Alapkövetelmény lenne, hogy az ablak tartalma némileg intelligensen kövesse az átméretezést. Ez Swing-ben igen egyszerű a BorderLayout vagy a GridBagLayout segítségével. Negatív meglepetés: nagyon gyér a layout támogatás. Ráadásul régebbi verziókhoz képest sokmindent visszavettek. Pl. nem lehet GridBagPanel-ozni. Ráadásul a túl sok változtatás miatt, a net tele van használhatatlan példákkal.

Találok egy ígéretes layout menedzsert, DigLayout néven. Letöltöm a jar-t, hozzáadom a projekthez, de nem reagál rá, nem találja meg az osztályt hiába importálom. No ez már azért kicsit durva, úgyhogy be is rekesztem a kísérletezést.

A nyelv maga az oké. A szintakszis kicsit a JSON-ra hajaz bár semmi köze hozzá. Tetszik a deklaratív megközelítés, és látom hogy sok szépet és jót lehet csinálni vele -és bízom benne hogy egyszer majd fogok is- , de egyelőre a 2-3 órás ízlelgetés után, ebben a formában "nem vettem meg".

Kódlefedettség-mérés

A jtechlog-ban volt egy írás a code coverage-ről ahova be is böfögtem egy kommentet. Na most én is írok róla.

Az Emma is egy ilyen kódlefedettségmérő eszköz, ami mindenféle riportokat tud csinálni XML és HTML formában. De én nem szeretek build scriptből és command promptból bűvészkedni ha kódlefedettséget akarok nézegetni, szóval beérem az Eclipse plugin változatával, az EclEmma-val. Europa környezetben használtam eddig és most felraktam a Gánymedvére is (by czimi). Azon is megy szépen.

Tud package, osztály, metódus, blokk és utasítás lefedettséget. Szépen fában jeleníti meg és lehet nyitogatni, odaugrik a kódra ha klikkelek, valamint kiszínezi a kódot, szóval meg lehet nézni hogy mi hajtódott végre teljes egészében és mi részlegesen végül mi az ami kimaradt a szórásból. El lehet tenni régi riportokat, előszedni de ezt sosem használtam. Be lehet jelölgetni a kapcsolt jar-okat, hogy azoknak is mérje a lefedettségét. Az EclEmma-s honlapon van screenshot, több infó.

Node mire jó ez?

Legalapvetőbb célja az lehet, hogy a unit tesztek a kód hány százalékát hajtják meg. Első közelítésben ez egy szám ami nem sokat mond. Kényelmes test driven fejlesztésnél nálam 70-80 százalék jön ki. Fel lehet tornázni 95, sőt 100%-ra is, de ez már néha igen sok melóval jár, főleg a szoftver határai közelében (I/O). Mindenféle mock-okat kell csinálni, le kell tesztelni mi a helyzet, ha egy stream close() metódusa elszáll IOException-nel, le kell tesztelni az UnsupportedEncodingException-t akkor is ha statikusan megadtuk az encoding-ot. (Checked exception, de minek.)

Akkor kezd izgalmassá válni a dolog, ha megnézzük hogy miért nem 100%, miért csak 70, elkezdjük lenyitogatni a fát, látjuk hogy egyes metódusoknak 0% a lefedettségük. Ilyenkor érdemes megnézni (CTRL+ALT+H) a metódus fordított hívási fáját, azaz hogy használja-e egyáltalán valaki. Nem használja, akkor meg miért van ott? Ha szükséges lesz az a metódus a jövőben akkor érdemes rá valami tesztesetet írni, hogy legyen valami contract-ja, ha nem akkor pedig ki lehet törölni. Ezzel is javul a lefedettség.

Más esetekben a metódusokon belül nem hajtódnak végre bizonyos ágak. Igazi TDD-nél ennek nem nagyon szabadna előfordulnia, de ha mégis akkor pótolni kell a hiányosságot mihamarabb.

Ad hoc tesztelésről feltornázni a teszt lefedettséget -próbáltam- egy rendkívül unalmas és szélmalomharcnak tűnő feladat. Az eredmény sem lesz olyan jó, mintha már az elejétől folyamatosan készülnének a tesztesetek. Update: De TDD nélkül is használható egy ilyen eszköz. Ilyenkor tesztesetek nélkül, egyszerűen azt kell megnézni, hogy némi működés -némi kattintgatás- után a program mely részei kapnak vezérlést. Az összes funkción végigzongorázva a holtággá vált kódrészeket végülis ki lehet így szűrni, egy adott funkció megpendíténél pedig meg lehet találni kilóra hogy a funkció a kód mely részeit hajtja meg.

Másik, nem túl triviális célja annak jelzése, hogy az összes teszt lefuttatása során a tesztkód hány százaléka fut le. Ennek 90-100 százalék közelében kell lennie. Ha ennél alacsonyabb akkor vagy ki vannak ütve tesztesetek -amit illik megindokolni- vagy valamiért nem kerül bele az összes teszteset a suite-be, vagy a tesztkód szerkezete nem megfelelő. Unit teszteknél nem szabad körmönfont vezérlési szerkezeteket használni, nem elfogadható hogy egy adott teszteset kódja nem fut le teljes egészében (100%). If-nek például elvileg egyáltalán nem szabadna tesztkódban lennie, legfeljebb utility osztályban. Egyébként az 5-10 százalék veszteség is valószínűleg a utility osztályokban kell hogy legyen.

1-2% veszteséget a lefedettségmérő eszköz is csinál mérési hibaként. Majd ideírom amikor megint találkozom vele, de úgy emlékszem a finally blokkban lévő kódot nem számolja, valamint az inicializáló blokkokkal is mintha meggyűlt volna a baja. Szóval a 98-99 százalékot néha lehet 100-nak venni már.

Reverse engineering-nél lehet érdekes azt megnézni, hogy egy adott teszteset vagy adott funkció a kód mely részeit hajtja meg. Ránézésre látni kilóra, hogy mely package-ek osztályok és metódusok kaptak vezérlést, miket érdemes a későbbiekben figyelemmel kísérni. Nekem hasznos volt ez a felhasználási mód is néhány alkalommal, amikor más kódjával ismerkedtem.

És végül amiért most ismét elővettem ezt az eszközt: 3rd party komponensek lefedettségét is meg lehet vizsgálni. Éppen egy webstart alkalmazáson dolgozom hobbiszinten, ami használ egy-két külső könyvtárat, de csak egy-két funkció erejéig. Az egyszerűség kedvéért az egész hóbelevancot egy jar-ba csomagolom és arra gondoltam ki fogom ütni a nem használt osztályokat a külső könyvtárakból a buildelés során. Most 1.3 mega a jar, jó lenne lemenni a harmadára. Bár az az érzésem hogy van erre jobb céleszköz is.

Egy-két régi Ant-os projektünket is szívesen végigbogarásznék egy ilyen lefedettségmérővel, mert ott már a világ összes jar-ja benne volt a lib könyvtárban. A Maven-nel már más a helyzet, mert az már ügyel a függőségek kezelésére -mondhatná egy Maven-hívő- de azért ott sem ilyen egyszerű a kép. Néha azért csattogtatni kell a exclusion-okat, mert pl. a log4j-hez is összeszed minden szutykot amit nem is akarok használni.

Remélem sikerült lefednem a kódlefedettségmérés felhasználási lehetőségeit. Jó pénteket!

Sun Java Café

A munkát félretéve elmentem a Sun Java Café-ra csütörtök délelőtt. A Sun igazán jó vendéglátó, mert az asztalok csurig voltak szendviccsel, ásványvízzel és kávéval. Jó sok ember gyűlt össze, -kb. megtelt a terem- egyre több ismerős arccal. Két előadás volt, amelyeket jövő héten a JavaOne-on is bemutatnak San Fransisco-ban.

Az első előadást a Sun-os emberek prezentálták és arról szólt, hogy hogyan rakták le egy nehézsúlyú nagyvállalati SOA projekt alapköveit Glassfish OpenESB-vel (Enterprise Service Bus). Lehet hogy azért mert nem vagyok járatos az ESB-ben, de nekem ez az előadás nem jött át teljesen. Elmondták hogy különböző Proof of Concept-eket dolgoztak ki a megoldásokra, de engem pont ezek a PoC-k érdekeltek volna. A jtechlog-ban Viczi írt több infót az előadásról. Nekem csak ilyen kérdések keringtek a fejemben, hogy "milyen tényezők határozzák meg egy WAN-os ESB-s szoftverrendszer működési karakterisztikáját? Pl. kell/lehet-e foglalkozni az esetleg földrészeken átívelő elosztott tranzakciók optimalizálásával, lehet-e üzeneteket vagy adatokat cache-elni?" Stb.

A második előadás számomra jóval izgalmasabb volt. Tavaly az Indexen lehetett olvasni egy cikkben ("Műegyetemisták hódítják meg Las Vegast"), hogy a CES kiállítás környékén -miközben odabenn a NavNGo villogott- mutogattak privátban magyar egyetemisták egy mobil telefonra készült BitTorrent klienst. Nos az egyik egyetemista, illetve a BME automatizálási tanszékén működő Applied Mobile Research Group tagja, Ekler Péter jött el bemutatni a néhány projektjüket. Többek között a közepes kategóriájú Java ME-t futtató mobiltelefonokra csinálnak szoftvereket. Például a telefon kameráját használó mozgásérzékelőt, speciálisan mobilra optimalizált szociális hálót, stb. Meglepődtem mennyi funkciót el lehet már érni a mobilokban a Java platformmal. Ezek az alkalmazások nem feltétlenül mindennapi használatra készülnek, hanem inkább afféle prototípusoknak, a mobiltelefonok képességeinek bemutatásának céljából.

Bejelentették, hogy a JavaOne után valószínűleg lesz mégegy Java Café, ahol a konferenciáról hallhatunk majd beszámolókat. Nagyszerű! Remélem ismét el tudok menni.

JUM X.

Kocka és Viczi már megelőzött a beszámolóval, de azért írogatok ezt-azt. Kicsit az utolsó pillanatra sikerült mindent összeszervezni, ennek ellenére nagyon jól sült el a dolog. Az előadások is jók voltak, ahhoz képest emberből sem volt kevés és ezúttal az időtervet is sikerült betartani.

Az első előadásból nekem az jött le, hogy SOAP-os szervizek teszteléséhez a Grovvy és a SOAPUi egy elég alapvető megoldás, mivel már a második független forrásból ajánlják a használatukat. A Netbeans 6.5 Groovy támogatását láthattuk élőben. A refactor és a kódkiegészítés kicsit döcögős, de ez egy dinamikus nyelvnél mindig is sarkalatos pont.

Corsin Decurtins az Objektum Orientált adatbázisokat mutatta be. Hozott egy jó hasonlatot: "Objektumokat relációs adatbázisba pakolni olyan, mintha az autódat minden este úgy tennéd be a garázsba, hogy előtte darabokra szeded." Azóta eszembe jutott egy riposzt erre a hasonlatra: "Az autókkal kapcsolatban viszont nincsenek olyan igények, hogy kérném az összes csavart az autóból méret szerint rendezve." Végülis abban maradtunk, hogy az OO adatbázisok egyelőre egyetemi kutatások témái, éles ipari környezetben még nem állják meg a helyüket, hacsaknem a Bajor Motorgyár Rt (a.k.a BMW) termékeiben. Végülis az előadás még a gyors prototípus készítésről szólt. Szerintem a JPA-val és az EJB3-mal már elég gyorsan lehet prototípusokat készíteni, de biztos vagyok benne hogy meglesz az OO adatbázisok helye is. Még a Jazoon konferenciát reklámozta Corsin, ami júniusban lesz, tavaly ha jól emlékszem 850-en voltak. Ezt az előadást egyébként tavalyelőtt ott is prezentálta. Lehet hogy valahol van is link róla. Említett még design patterneket, pl. az Active Record-ot, ami szerintem anti, a Transaction Script-et és a Domain Model-t. Ja és a db4o egy ilyen OO DB.

A harmadik előadás az Amazon Web Services-ről szólt, ami egy számítási felhős vagy inkább virtualizációs téma (v12n). Pénzért bérelhetsz a számítási teljesítményt, sávszélességet és tárhelyet, valamint vannak előregyártott image-ek, pl. mindenféle Linux-ok, telepített appszerverek. Pár kattintással lehet csinálni egy Websphere környezetet -példának okáért- ha jól értettem. Az jött ki hogy olcsó, olcsóbb mintha szerver hostelbe betennél egy gépet, ráadásul az időszakos terheléseket jobban le lehet kezelni úgy hogy arra az időre bérelsz még egy kis virtuális teljesítményt. A múltkor nagyon kutyáztam a cloud computing-ot, de ez az AWS egy jó dolog akárhogy is nézzük. Java-val is volt némi kapcsolódási pont, mégpedig hogy vannak valami java API-k ennek az AWS-nek az elérésére (jets3t, quillen és jclouds). Valamint a Szantog szokott még erről írkálni elvileg, de nem néztem bele.

Aztán kocsmáztunk még egy kicsit (10-ig ugye), ami szerintem nagyon hasznos volt. Bár nem sokra emlékszem miről beszélgettünk, a cetlit meg elhagytam amire felírtam pár betűszót aminek utána akartam nézni. Nem baj, majd eszembe jut.

Egyébként lehet hogy megint átmegyek egy darabig ilyen meeting tudósító oldalba, mert lesz egy-két esemény amire elmegyek előreláthatólag. Pl. lesz a Sun Java Café és az Eclipse Democamp a Galileo megjelenésének alkalmából, plusz a Newtech Meetup-ok, ami ha jól látom fizetős lett. Abban maradtunk hogy nyáron nem lesz JUM -legalábbis a klasszikus előadásos fajta- tehát szeptember a következő időpont.

Deszantos programozás

Már régen össze akartam szedni a gondolataimat ezzel a témával kapcsolatban és most ahogy közeledik a munka ünnepe, meg is ragadom az alkalmat. Egy régi főnökömtől hallottam a kifejezést azokra a programozókra, akiket ledobnak "ejtőernyővel" egy idegen irodában / idegen városban, esetleg idegen országban és szoftvert fejlesztenek. Lassan 6 éve én is ilyen formán nyomom az ipart és megtapasztaltam az előnyeit és a hátrányait. Ennek az ellentéte, amikor valaki be van betonozva egy adott irodába évekre. (Ott néha az ülésrendet szokták megvariálni, hogy ne forduljon be teljesen az alkalmazott az évek alatt.) Ebben is volt részem egyébként.

De miért is van szükség rá, hogy "odamenjen valahova" a programozó, miért van szükség onsite fejlesztésre, amikor ez a szakma elvileg távolról is jól végezhető lenne a modern kommunikációs formák használatával. Bizonyos esetekben szerintem is indokolt összejönni, hogy mindenki beszéljen mindenkivel, használhassa a gesztusait, ugyanabban a környezetben létezzen. De bizonyos esetekben -úgy érzem- csak a bizalom hiánya vagy a hatalmi helyzet kifejezése az ok. "Ha nem itt vannak ezek a rövidujjú pólós gyerekek, lehet hogy nem is dolgoznak csak egész nap CS-znek. Így legalább rajtuk tartjuk a szemünket. Van itt egy üres sarok, végülis tudunk nekik helyet szorítani. Sokat fizetünk, ennyi pénzért megmondhatjuk hol dolgozzanak."

És meg is van az első sarokpont, az iroda: egy ilyen helyen sosem a legjobb helyre ültetik az idegenlégiósokat. Biztos hogy a legrosszabb széket és asztalt kapod meg. Biztos azt a helyet kapod ahova eddig senki más nem akart ülni. Ha gép is kell akkor meglehet hogy valami összeguberált vacakot kapsz, de mostanában azért már illik mindenhova notebook-kal odamenni (erre még visszatérek), mert a programozáshoz nem mindig elég egy ad hoc összeszedett gép. Vannak speciális esetek, pl. ha clean desk policy van. Akkor akárhova leülhetsz, főleg ha te érsz be leghamarabb. Úgy láttam ott is kialakulnak a szokásos kedvenc helyek, "nem illik" olyan helyre ülni ahol más szokott, különben szikrázó tekintet van. Nem mindegy hogy mivel foglalkoznak az adott helyen. Ha szoftverfejlesztéssel az jó, mert jó eséllyel hasonló munkakörülményekre van szükségük az embereknek, de olyan helyre kerülni szívás, ahol folyamatosan dumálnak, jönnek-mennek az ügyfelek, csörögnek a telefonok.

Kis kitérő: múltkor feltettem egy kérdést, hogy "Neked milyen hangviszonyok kellenek hozzá, hogy produktív legyél? Többet is be lehet jelölni. " Az eredmények:

• Tökéletes csend 75%
• Enyhe IT témájú neszek 37%
• Rádió slágerek hírek 12%
• Metál, rockzene 50%
• Szociális párbeszédek 0%
• Nem technikai zsibongás 0%
• Telefoncsörgés, telefonálás 0%
• Ki-be mászkálás 0%

Magáért beszélnek az eredmények. (Érdekes mennyien szeretik a rockzenét.)

Visszatérve: Néha alkalmazkodni kell a helyi dress code-hoz, ami néha sajnos öltöny-nyakkendő. Találkoztam olyannal ahol beszóltak, hogy ez a külsősökre is vonatkozik. Ha meetingelni vagy reprezentálni kell akkor oké, de így elég nehéz volt beletörődnöm, hogy majom jelmezben kell kódolnom. Pénzintézeteknél külön szépség lehet a paranoid belső internet használat, pedig programozáshoz szerintem internet ma már elengedhetetlen. Nem lehet kiguglizni egy ismeretlen hibaüzenetet, egy idegen API dokumentációt. Az időnyilvántartó rendszerrel szintén jól kell manőverezni. Mennyire szeretnek túlóráztatni, hétvégézni és ezt az anyacég mennyire honorálja?

Következő pont a tágabb környezet. Ha az épület lepukkantabb mint a saját céges iroda vagy történetesen egy építkezés folyik a szomszédban az ciki. Annak is kicsi az esélye, hogy közelebb van a kiszállós hely mint a saját iroda, vagy jobbak a közlekedési viszonyok. Ha kocsival vagy arra ne nagyon számíts, hogy biztosítanak neked egy parkolóhelyet a sajátok között. Vannak viszont pozitívumok: ha távolabbra kell menni. A fizetett utazás és a hotelek, városnézés (ez már saját zsebre) nekem eddig bejött. Lehet hogy ha mindig ezt kellene csinálnom már nem tetszene, de két-három hét erejéig szerettem.

A társaság is lehet pozitív tényező: rengeteg emberrel meg lehet ismerkedni. Ha szoftverfejlesztők közé kell beülni az külön jó az eszmecserék szempontjából. De ha másfélékkel kell keveredni, az nem mindig szórakoztató. Pl. banki alkalmazottakkal nem nagyon tudok egy húron pendülni. Nem lehet velük beszélgetésbe elegyedni arról, hogy az Oracle felvásárolta a Sun-t, engem viszont nem érdekelnek a kamatlábak. A legnagyobb közös érdeklődési halmaz kb az időjárás. Azért ezzel együtt is szórakoztató: nem mindennap ugyanazt a munkatársat kell néznem, hanem jönnek-mennek, vannak lányok-asszonyok.

Szakmai szempontból egyértelmű pozitívum, hogy nem ragadok le egy dolognál. Hallottam olyanokról akik évek óta ugyanazt a projektet nyűvik. Panaszkodnak hogy nagyon unalmas és félnek, hogy ha váltani akarnak nem lesz versenyképes tudásuk. Deszantos programozásnál ahány projekt, annyi webes keretrendszer, annyi adatbázis, annyi architektúra - még jó ha J2SE-n vagy J2EE-n belül maradunk. Kicsit zavar hogy elég ritkán vagyok ott a kickoff-oknál, amikor leteszik a projekt alapjait, így meglehet hogy ki kell tolatni egy-két zsákutcából, félretervezésből. Sőt nem ritka, hogy eleve egy elcsúszott projekthez hívnak plusz embernek, "problémamegoldónak". (Ezek a melók a Daily WTF-nek korlátlan mennyiségű anyagot jelentének.) Rendszerint a pezsgőbontásból is kimaradok a projekt lezárásánál, bár elég kevés ilyen van a gyakorlatban, mert "egy szoftver sosincs készen".

Mivel sokféle komponenst kell használni és illik saját gépet használni, a sajátgép nyakig meg van tömve mindenfélével. Nálam most pl. van négyféle adatbázismotor és négyféle Eclipse különféleképpen felpluginezve. A régi projekteket sem lehet letörölni, mert bejöhet még javítási vagy fejlesztési kérelem. Minden helyen alkalmazkodni kell a saját policy-khoz, néha fell kell tenni valami speckó szoftvert. De végülis nem vészes, eddig még bírja a gép.

Akartam még olyanokról írni, hogy a fix belsős fejlesztők tudásának karbantartására jobban odafigyelnek, de jobban belegondolva ez egyáltalán nem törvényszerű. Illetve tudok ellenpéldákat mondani, illetve olyan példákat amikor beülős embereket küldenek el szakmai tréningekre.

Azt hiszem kiveséztem a témát. Nagy megmondást nem akarok a végére: a negatívumok ellenére nekem tetszik ez a munkamódszer. Legközelebb viszont már valami technológiaközelibb dologról próbálok majd írni.

JUM IX.

Egészen sokan gyűltünk össze tegnapelőtt a Számalk épületében. Az első eladás a Maven-ről szólt Verhás István tolmácsolásában. A gyors közvéleménykutatás alapján jelenlévők nagy százaléka használ Ant-ot, kis része Maven-t is, Ivy-vel pedig egy ember foglalkozott.

Ahelyett hogy az előadást részletezném inkább leírom a saját fogalmazásomban bullshitek nélkül, hogy miért érdemes Maven-t használni Ant helyett:

-Ant esetén a függőségeket (egyéb jar-ok) a verziókontrollba szoktuk pakolni. hogy ne kelljen mindenkinek kézzel összevadásznia. Ez azért aggályos, mert ezeknek függőségeknek a mérete elég nagy magához a forráskódhoz képest. Fölösleges branch-elésnél kópiát készíteni belőlük, fölösleges minden egyes archiválásnál elmenteni őket. Ha több projekt ugyanazokat a jar-okat használja, fölösleges többször letárolni őket. Gyorsabban fogy a DAT kazetta, gyorsabban pusztulnak az esőerdők. Update 2009.06.21: Kommentekre is reflektálva, természetesen nem az a Maven elsőrendű célja hogy takarékosabb legyen, ráadásul ahogy megtudtam az internetes Maven repository-k elég sok téves/fölösleges letöltési kérést kapnak, úgyhogy megint csak rosszul jönnek ki a dologból szegény fák a nagyobb hálózati forgalom miatt. Viszont ha valaki internetes sourcecontrol-ba akarja tenni a forráskódját, pl. Google Code vagy SourceForge, oda tényleg nem szerencsés betenni a függőség jar-okat, mert egyszerűen elfogy a kvóta.
-A projekt kialakításakor a függőségeket készzel kell összevadászni. Ha ezt a jar-t használom akkor kell ez is meg emez is, és akkor melyik verzió is kellene?
A Maven megoldást ad erre azzal, hogy csak a függőségek nevét kell megadni, amit letölt magától a kapcsolódó egyéb függőségekkel a netről egy lokális repository-ba a gépre. Sőt, ha kell letölti a függőségek függőségeit ügyelve a megadott verziószámokra. Ha már egyszer letöltött valamit, nem megy újra neki. Szoktak használni vállalati repository-t is: ilyenkor a fejlesztők Maven-jei nem közvetlenül az internetről szedik le a jar-okat, hanem a vállalati repo-ból. Ilyen pl. az Archiva. Update 2009.06.21: Ahogy a legutóbbi Eclipse DemoCamp-en Jason van Zyl előadásán megtudtam, a Nexus az a repó menedzser amit igazán érdemes használni. Így csökkenthető a forgalom, növelhető a sebesség, ráadásul saját privát "artifact"-okat (=termék: jar, war, ear, ilyesmi) is fel lehet oda tenni. Az előadó szerint vállalati repó nélkül gondok szoktak lenni a Maven használattal komolyabb környezetben, pl. ha egy artifact-ot kézzel kell letölteni, mert privát vagy a licenszelése miatt nincs fenn publikus repo-ban a neten.

-Ant esetén ki szokott alakulni egy szilárd build.xml és könyvtárstruktúra mindenféle projekt őstípushoz, pl. webalkalmazás, J2EE alkalmazás, amit aztán csak mindig gépiesen másolgatunk az új projektekbe és átírjuk a könyvtár és projekt neveket, esetleg beleírunk egyéb extra task-okat. A build.xml igazából fölösleges is, csak azt kellene tudni hogy ez milyen őstípus és mivel akarjuk kiegészíteni.
A Maven pont ezt csinálja. A pom.xml-ben csak azt kell leírni, hogy miben térünk el az eredeti őstípustól (archetype), pl. használunk valami saját annotáció feldolgozó eszközt. Ugyanitt kell megadni a függőségeket is. Őstípust pedig roppant egyszerű létrehozni. Íme egy példa egy Wicket alkalmazás létrehozására. Egy parancssorból letölti a szükséges jar-okat, megcsinálja a könyvtárstruktúrát, buildel, csomagol, futtat teszt üzemmódban saját Jetty szerverrel, itt most éppen Eclipse projektet csinál csatolt böngészhető Wicket javadoc-cal és forrással. Ez azért nem rossz nem?

Ezenkívül tud még javadoc-ot csinálni, sőt szabványos szájtot is tud generálni a projektnek. Ez a titka az Apache és Sourceforge oldalakon található Built with Maven matricáknak. Még annyi, hogy a hivatalos Maven oldalon rengeteg a bullshit és általában szeretik nagyon túlmisztifikálni a dolgokat, de van egy elektronikus könyv Better Builds With Maven címmel, ami egy nagyon hasznos olvasmány. Mert attól hogy automatikus build eszköz, a projektgazdának nem árt érteni hozzá.

Mondták még nekem a Gradle-t ami egy még újabb build eszköz. Ahogy néztem ez valóban procedurális, mint ahogy az Ant nem az. Egyelőre nem fog meg hogy script-eket írhassak buildeléshez, mint a régi szép időkben.

Második előadás Verhás Pétertől SOAP tesztelésről szólt. Nem ez az álmaim melója, de ha muszáj akkor fel kell majd keresni a SOAPui, a Greenpepper és a Confluence honlapját. A SOAP tesztelés abból áll, hogy lapáttal hányjuk be az XML-eket egy fekete színű doboz bal oldalán, majd a jobb oldalon kijövő több tonnányi XML-t nagyítóval nézzük át. Nem árt ha ehhez van némi integrált júzerbarát környezet ami tudja mi az a WSDL és a táblázatban leírt tesztadatokból SOAP üzeneteket generálgat, valamint zöld csíkokat rajzolgat.

A harmadik előadás Viczián Istvántól az adattárházakról: A Prezi-t használta a bemutatóhoz, ami nagyon kúl volt! A blogján elvileg fog ebből írni egy cikket, úgyhogy nagyon nem is megyek bele, csak bevezetem: Ha egy -alapesetben adatbázisban lévő- adattömegről dinamikusan változó igények alapján riportokat, kimutatásokat szeretnénk csinálni hisztorikus módon (akkor is ha az eredeti adatbázisban az adatok nincsenek hisztorikusan tárolva), akkor a kerék újrafeltalálása helyett esetleg érdemesebb az OLAP (Online Analytical Processing) megoldások felé kacsintgatni. Gyorsan belátható, hogy egy ilyen feladathoz speciálisan felépített adattárolásra van szükség: Ritkák az update-ek, sokféleképpen kell indexelni, előre aggregálni kell adatokat hogy gyorsabb legyen a lekérdezés, nem igazán jellemző a tranzakionális, sokfelhasználós működés. Nem biztos hogy SQL a legalkalmasabb lekérdezési mód, sőt lehet hogy nem is relációs adatbázis az optimális tároló eszköz! Az adatokat tudni kell összesítve megjeleníteni, lefúrni a részletekbe, más szempontok szerint megjeleníteni. Erre vannak kész -leginkább fizetős- eszközök. Sajnos az előadás hamar véget ért időkorlát miatt, de még az is lehet hogy a következő JUM-on lesz folytatás. A cikket pedig kíváncsian várom!

Ismét volt videózás, de azt nem tudom hogy az elaőadások hová és mikor lesznek feltöltve. Következő alkalom pedig május 20.

Wiw, OpenSocial

Az elmúlt hetekben/hónapokban a csapból is az folyt, hogy a Wiw támogatni fogja az OpenSocial-t, azaz a Facebook-hoz hasonlatosan minialkalmazásokat lehet majd fejleszteni a népszerű közösségi portál felületére. Sőt, fejlesztői verseny is indult, ahol fél millát lehet nyerni és már meg is hosszabbították a február közepei határidőt március végére. Még nem késő a mezőny után eredni, itt a kitűnő lehetőség a megemelkedett frankhitel-törlesztőrészlet kipótlására. Tessék egy kis útravaló:

JavaScript: A Dinamikus HTML oldalak és egyben az OpenSocial alapnyelve. Van sok tutorial a neten, de a amelyik csak az alapokat és a browser API-t taglalja anélkül hogy belemenne a prototipizálásba és az egyéb szintaktikus eszközökbe, az használhatatlan. Néhány információforrás:

• Wikipedia történet, alapkoncepciók.
• Szintakszis leírás a wikipediában. Viszonylag részletes. A JavaScript egy prototípus alapú programozási nyelv.
  
• Module pattern: A wiw-OpenSocial példaalkalmazásban említik mint követendő példát (lásd később). Próbálgattam: okosnak tűnik, de megvannak a kényelmetlenségei. Talán erős IDE támogatással használhatóbb.
• Angol nyelvű könyv, jónak néz ki. Magyar nyelvű könyv, elvileg jó.
  
• Hasznos oldalak:
  
• http://www.javascripter.net
• http://www.w3schools.com/jsref/

JavaScript keretrendszerek és megoldások:
Kb. ezer van, de kettő elég fontos általában és az OpenSocial szempontjából is:

• JSON a Yahoo-nál: Data Transfer Object formátum, azaz adattovábbításhoz használható.
  
• Prototype framework. API doc pdf: sokszor használt funkciók shortcutjai, böngészőfüggő funkciók egységesítése. Kell.
  

OpenSocial: A dolog lényege, hogy a szolgáltató (pl. Wiw) által biztosított webes felületbe integrálva jelenik meg a saját minialkalmazás, alkalmanként felhasználva a szolgáltató által rendelkezésére bocsátott személyes adatokat. A minialkalmazás leginkább Javascript, így a kliens gépen fut és felhasználhat távoli szerver erőforrásokat. Fejlesztői szempontból ez azt jelenti, hogy csinálhatunk saját PHP, Java, ASP backend-et. Vannak az OpenSocial-tól különböző API-k is, mint például a Facebook-é. És hogy milyen alkalmazásokat lehet csinálni? Ahogy a FB-példájából látszik leginkább haszontalanokat. (Én egyébként hiszek a hasznos közösségi alkalmazásokban is.)

• Leírás a Wikipedián: történet, alapkoncepciók. A Google Gadgets -re épül, ami így magában nem jelent túl sokat. A G.Gadgets is XML-HTML-Javascript alapú. A linken vannak infók spreadsheet és maps mashup-ok készítésére.
  
• Dokumentáció a Google-nél: alapkoncepciók, kiindulópont sok egyéb hasznos információhoz.
• 0.8 API dokumentáció. 20-30 nem túl bonyolult osztály.
  
• A Shindig egy Apache-os referencia implementáció, ami elvileg a Wiw-ben is működik.
  
• Hallgatnivaló: Google Developer Podcast Episode Eleven: OpenSocial with Patrick Chanezon (hossz: 27:10, nagy csodákat nem mondott.)
• Néznivaló:
• Sorban mondja a srác egy alkalmazás elkészítését a code.google.com-on. 1-3 perces videók egymás után. Orkut-ra épül. Elvileg Orkut-on nagyon egyszerű az alkalmazás telepítése.
• 1. Hogyan kell nekiindulni egy Orkut HelloWorld alkalmazás írásának, mik kellenek hozzá.
• 2. Barátok kilistázása az alkalmazásban.
• 3. Barátnak "ajándék" küldése. Funkció beépítése az alkalmazásba.
• 4. Eddig adott ajándékok listázása.
• 5. Eddig kapott ajándékok listázása.
• 6. Egy egyórás előadás az OpenSocial jövőjéről. Innentől kezdve mindenféle hosszabb konferencia előadások vannak.
  
• Google Campfire és egyebek, inkább manager szemszögből közelítik meg a témát.
• Van egy template-ező rendszer, ami megkönnyíti az OpenSocial programozást és ami be van építve a Shindig-be, de a wiw-esetében nem működik valamiért, ahogy Bergengotian írja. "Külső forrásból kell behúzni."
• Google App Engine - ha szerveroldali funkcionalitás kell, de nincs saját szerver. Python-ban kell programozni ha jól sejtem. Biztosítják ingyen a szerveroldali kódvégrehajtó funkcionalitást és némi perzisztens tárhelyet. Update 2009.04.16: Már java-ban is lehet programozni a Google App Engine-t. Ez egy olyan dolog amit az opensocial-tól függetlenül is át kell majd néznem.
  
• Python alapok, wikipédiában magyarul.
  

Wiw-OpenSocial: Jelenleg a 0.8-as verziót támogatja, de készülnek a 0.9-esre.

• Példaalkalmazás, gyorstalpaló: egy működő példán keresztül mutatja be a koncepciókat. Valóban működik és jól érthető.
• Fejlesztői blog. Érdemes be RSS-ezni, hasznos információkat ír. A kommentekben is vannak hasznos információk.
• Bergengotian blogbejegyzése a témában néhány technikai részlettel. Megemlíti az OpenSocial DevApp-ot, mint lehetséges fejlesztőkörnyezetet és azt is, hogy a 0.8-asat nem sikerült beizzítania csak a 0.7-est.
• A fejlesztői portál belépő oldala. A regisztrációhoz szükséges egy működő magyar mobilszám.

JavaScript/OpenSocial fejlesztői környezetek: Hasznos segítség, ha van javascript kódkiegészítés és szintakszis szerinti színezés, esetleg helyben lehet tesztelni az alkalmazást, automatizálni lehet a szerverre való feltöltést.

• Google Group a témában összesen 5 hozzászólással. Leginkább Eclipse-t és OpenSocial DevApp-ot ajánlanak.
• OpenSocial DevApp-ról itt van egy tutorial -de lehet hogy ez jobb. Ez egyébként maga is egy openSocial alkalmazás, amivel lehet próbálgatni kódrészleteket. OpenSocial DevApp installálása - írás a wiw fejlesztői blogon. Használható az iWiw esetében is, sikerült installálni. Az alapvető funkciója látszólag működik.
  
• Az alap Eclipse WST-ben (web standard tools subproject) van JavaScript támogatás (JSDT), kérdés hogy milyen minőségű. További anyagok róla: Írás az Eclipsepedia-ban. Videocast. Eclipse Ganymede-vel érdemes használni, régebbi Eclipse verzióval nem barátok. (Kis kitérő: Ha Ganymede-val SVN-t akarsz használni, ne felejtsd el installálni a JavaHL adaptert is a Subclipse mellé.) A rövid próbálgatás során nem voltam a Javascript támogatással maradéktalanul megelégedve. Mivel a JavaScript dinamikus nyelv, nincsenek előre definiált típusok, nehezebb kideríteni szerkesztés közben egy objektumon hívható lehetséges függvényeket, nincs argumentumlista- és típusellenőrzés. Néhányszor nem tudott segíteni az autoComplete. Kíváncsi lennék milyen szoftvereket használnak a profi JavaScript fejlesztők / milyen a projekt elrendezésük.
  
• A JSEclipse is egy Eclipse plugin, nagy reménnyel indult régen, még az Adobe is megvette, de ma már felejtős.
  
• JavaScript editorok összehasonlítása, de ezek inkább Microsoft Visual Studio-hoz tartozó pluginek.
  
• Firebug - plugin Firefox-ra, amivel a JavaScript és a HTML oldal működését lehet nyomon követni. Régebben -még a 3-as Firefox előtt- használtam, de permanensen 100%-ra tette a processzor kihasználtságot úgyhogy töröltem. A 3-as Firefox-on eddig gond nélkül működik. Érdemes elolvasgatni a doksiját, vagy legalább megnézni a screencast-okat. JavaScript Debugging screencast 16 perc, fölöttébb hasznos!
  
• Tesztelés! Mert Javascript-et is kell tesztelni, természetesen Javascript-ben. A Yahoo-nak vannak is erre ötletei: YUI test blogbejegyzés. Van videó is, 48 perc és egész friss, 2008 októberi.

Nos, ennyit firkálgattam magamnak.

A holnapi Bp Newtech Meetup-on is lesz elvileg egy villámelőadás a témában. Még nem tudom hogy megyek-e, mindenesetre a feltett kérdések érdekelnének. Vajon hányan neveztek a versenyre, milyen minőségű munkákkal? Abban biztos vagyok hogy fel fog lendülni tőle a Wiw forgalma, ha majd egyszer élesbe megy.

JUM 09.01.21

Ismét konf. beszámolót írok, de azért nem cél a témára való teljes rácuppanás. Nézzük csak: a tegnapi Java User Meeting a Számalk épületében kapott helyet, ami a hazai számítástechnika 20-30 évvel ezelőtti temploma. Az épület emiatt inkább hasonlít egy ódon főiskolára mint egy modern irodaházra.

OSGi

Az első előadás az OSGi-ról szólt, ami egy dinamikus modularizációs keretrendszer (óeszdzsíáj, ezt mindig le akartam így írni, hát most tessék). Talán legközismertebb működő példa az Eclipse, ami ilyen alapokon fut, ugyanis a benne használt Equinox is egy OSGI implementáció.

Volt rövid elméleti bevezető aztán gyakorlatiasabb demó. Egy Eclipse-ben láthattuk először egy HelloWorld bundle (így nevezik az alapegységet) létrehozását nullából, aztán némileg összetettebb példák működését. Kb. úgy lehet létrehozni mint egy plugin-t, tehát new project, ... és ki kell választani hogy nem Eclipse hanem standard OSGi környezetben akarjuk futtatni. Ha jól sejtem nem árt ha benn van az IDE-ben a Plugin Development Environment installálva. A rendszer classloader filozófiája elég kifinomult, emiatt lehetőség van verziózott modulfüggőségek megadására a megfelelő helyeken - azt hiszem a manifest fájlban. Meg lehet adni verzió intervallumokat, egy környezetben működhet többféle verzió is egy adott egységből, satöbbi. Nekem úgy tűnt, hogy ez hasonlít a .net Assembly kezelésére. Felmerült egy kérdés, hogy ez vajon kiküszöböli-e a "bundle-hell"-t, a bundle függőségek összekuszálódását, hogy pl. a log4j-t beteszem a saját bundle-mba hogy ne váljon külső függőséggé. Ha értelmesen használják akkor kiküszöböli. Megemlítették, hogy van Maven plugin vagy bundle vagy mi, ami magától lehozza a szükséges függőségeket. (Van valakinek linkje, tapasztalata erről?)

A bundle-eket lehet futtatni, próbálgatni az IDE-n belül. Kapunk egy OSGi konzolt, amin különböző parancsokat bepötyögve tudjuk elindítgatni, leállítgatni és monitorozgatni a különböző bundle-okat. Hasonlít egyébként a Windows service-ekre első ránézésre: ott figyelnek a bundle-ek, vannak állapotaik miszerint el vannak indítva, installálva vannak de nincsenek elindítva, illetve az installálásuk nem sikerült teljesen. Némi infó még itt.

Volt szó eseménykezelésről, ami első látásra hasonlít a JMS-re, viszont lényegesen lightweightebbnek tűnik.

Az előadók elmondása szerint jobban bejön nekik mint alkalmazásszerverek és J2EE/EJB-k használata, mert egy ilyen OSGi konténer nagyon hamar - a másodperc törtrésze alatt - újraindul, kevés gond van vele. (Hát én azért vállalati alkalmazásoknál eléggé meg vagyok elégedve az EJB3-mal, szóval ezek után még nem váltanék. Megbecsülöm az EJB appszerver admin konzolokat, realm és resource konfigurációs szolgáltatásokat amiket egy-egy appszerver ad.) Szó volt még Spring integrációról, de ez enyhén szólva nem hangzott jól. A bundle-n belül van applicationContext vagy a bundle-k vannak egy nagy applicationContext-ben benne, vagy a kettő egyszerre? Kínzó kérdés.

Adobe Flex

Cornel Creanga az Adobe bukaresti irodájából jött el evangelizálni. Az elején megijedtem, hogy a mainframe-ektől indul az előadás, de szerencsére hamar eljutottunk a Flash-ig és annak jelentőségéig. A demók mindenképpen meggyőzőek voltak, de nagy bánatom hogy nincsenek Flash és az erre épülő Flex fejlesztéshez ingyenesen használható eszközök, csak az Eclipse alapú Flex Builder. Említésre került az AIR, ami egy desktopos flash futtatásra alkalmas platform Webkit alapokon.

A számunkra legérdekesebb dolgok az előadás végén hangzottak el a java integráció kapcsán. Alapvetően a Flash HTTP, SOAP és mindenféle socket alapokon tud kommunikálni a szerveroldallal, de van lehetőség olyan elérésre, ami a JavaScript JSON mechanizmusához hasonlóan automatikusan elvégzi a távoli metódushívásokat és az eredmények továbbítását a szerverről a kliensre. Van hibernate integrációs szerveroldali komponens, ami gondoskodik a kliensről leküldött objektumok megfelelő perzisztálásáról.

Demózásra kerültek olyan használati esetek, amikor a szerver push-olja az adatokat a kliensre, vagy amikor egy A kliensen átírt adatok rögtön megjelentek a B kliensen reload nélkül (kliens = web böngésző). Láttunk példát Flash pdf dokumentumba való beépítésére is. Talán a legfontosabb, hogy van egy Tour de Flex példaalkalmazás amit érdemes lehet nézegetni. Elvileg sok érdekes példát tartalmaz.

Kaptunk egy mini O'Reilly könyvet Getting Started With Flex 3 címmel. Villamoson való olvasgatáshoz tökéletes.

Előadások után elmentünk páran a Bajor Sörözőbe a Móriczra, ahol egyszer ki kell próbálni a sztrapacskát. Megbeszéltük a nagy nemzetközi helyzetet Cornel-lel. Náluk is Microsoft-ot használnak az állami szektorban, a bundáskenyeret bundáskenyérnek hívják és így tovább.

A legközelebbi JUM alkalom márciusban lesz, ahol jó lenne behajtani a most elmaradt JPA 2.0-t. Többször is elhangzott az a szó, hogy Groovy és hogy többeket is érdekelne egy ezzel kapcsolatos eszmefuttatás.

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.