Viszlát

A helyzet a következő: Nem nagyon fogok ide már írogatni, bár aki szemfüles észrevehette hogy így van ez már egy ideje. Nem mentem el Vlagyivosztokba halat belezni, vagy Írországba birkapásztornak (ez az utóbbi egyébként jó ötletnek tűnne). Továbbra is kódolok, hackelek, doksit túrok, szart faragok, bugot keresek, fél napokig szakmai emaileket fogalmazok, ez a blog meg itt egy jó kis információforrás lett 7 év alatt. A C#-s bejegyzés például miatt még mindig rengetegen jönnek, ahhoz képest hogy én meg már el is felejtettem dotnetben programozni.

Viszont olvassátok, linkeljétek, kövessétek a kódzaj blogot, az nagyon hasonló tartalomnak ígérkezik.

JUM XVII.

Kicsit égő hogy már szinte csak a JUM-ról írok, de ez van. A tizenhetedik alkalomnál tartunk. A teremben kb. 40 ember volt, ami már majdnem teltház. Az asztalon az Oracle Java Café-ról ismerős szórólapok. Viczi elmondta, hogy az OJC-n is megemlítették a JUM-ot, úgyhogy mi is megemlítjük őket, kölcsönös a szimpátia, stb. Indultak is az előadások:

Verhás Péter - Business Level Testing

A szervezési részéről megfogva a dolgot azt mesélték el, hogyan lehet az ügyfelet bevonni a tesztelésbe. (Nem az ő feladata, nem ért a műszaki dolgokhoz és nincs is rá ideje.)A tesztelés ne műszaki tevékenység és ne “munka” legyen, hanem “játék”. Ne legyen kötelező, viszont érdekes legyen. Így az ügyfél érdekeltté válhat benne. A bevált eszközeiket említették meg: SoapUI, Confluence és Greenpepper. Erről sajnos technikai részleteket nem árultak el. A IX. JUM-on, -amikor egy előadás hangzott el ezzel kapcsolatban- még nem tartozott a jó szokásaink közé bekérni a prezentációkat, úgyhogy technikai részletekkel most nem tudok szolgálni. Egyébként volt Wiki felület, táblázatok és zöld-piros grafikonok.

Auth Gábor – Android SOAP

Gábor egy open source SOAP kiszolgálót írt Android-ra. Elvileg van már egy, de azt igazából MIDP-re csinálták és nem túl bő a funkcionalitása, nem használja ki kódszinten az Android tudását. Ha bárki csatlakozni akar a projekthez, Gábor szívesen látja. A források elérhetőek webes SVN-ből, Maven alapú a projekt egyébként. Illetve szavazzatok rá a StackOverflow-n. :)

Kovács Richárd – Magyar Tamás – EJB3 vs Spring

Szerintem ez egy zseniális előadás volt. Ricsi képviselte az EJB oldalt, mígy Magyusz zöld ingben a Spring oldalán harcolt. Egymásnak néha beszólogatva gyalogoltak végig a mindenféle szempontokon: UI támogatás, biztonság, AOP, DI, rendelkezésre állás, aszinkron hívások lehetősége. A rendelkezésre állással kapcsolatban megemlítették a Terracotta szervert, ami pénzes (drága) és elosztott Spring alkalmzások futtatására szolgál. A visszatérő mondatrészek a “bármit le lehet programozni” és “az XML az ördögtől való” voltak. Megköveztük szegény “evil singleton”-t is néha. A meccs végén nem volt konkért eredményhirdetés, hanem abban maradtunk hogy ha oda kerül az ember úgyis meglesznek a szempontjai ami alapján dönteni kell.

Hiányoltam egy olyan szempontot, hogy a lokális erőforrásokhoz való hozzáférés. Ebben a Spring nyert volna, mert EJB-be ez nem nagyon fér bele. Márpedig néha még szerveren is szükség lehet USB vagy egyéb lokális eszközökhöz, fájlokhoz való hozzáférésre (pl. kulcsok). Elvileg van rá EJB-ben is valami Connector architektúra, de még nem láttam élő embert aki ilyet programozott volna. Hogy olyat is írjak ami kimaradt, de az EJB nyert volna a grafikus adminisztrálhatóság. Tapasztalataim szerint egy rendszergazdát megnyugvással tölt el, ha van egy felület amit nézegethet és pl. form-okon állítgathat be data source-okat screenshot-ok alapján, alkalmazásokat telepíthet, uninstallálhat. Nos, Spring-ben marad az XML bogarászás.

Felmerült olyan kérdés, hogy használt-e valaki együtt Spring-et és EJB-t amire az volt a gyors mondás, hogy az perverz dolog. Nos, én használtam többféleképpen is.

Annó, az EJB2 idejében használtuk a Spring EJB támogatását, de erre már nem nagyon emlékszem. Olyan is előfordult, hogy egy EJB-s alkalmazás teszteléséhez használtunk Spring-et: összeraktunk egy appContext-et a bean-ekből, amit alkalmazás szerver nélkül lehetett meghajtani.A “legperverzebb” dolog viszont az volt, amikor egy Session Bean-en belül akartunk Spring appContext-et létrehozni.Lett volna értelme, de nem valósult meg.

Szóval ez volt a JUM, legközelebb jövőre.

Ma lesz egy Eclipse DemoCamp valami borozóban, amin sajnos nem tudok résztvenni, mert sok lenne már a jóból, de remélem valaki beszámol majd!

JUM XVI.

Amikor az utolsó pillanatban beestem a terembe hirtelen csak annyit tudtam mondani, hogy wow. Jó sokan voltunk, rekordgyanús. Konferálás kutyafuttában, aztán már nyomta is Balogh Zsolt a Liferay előadást és demót.

A hátsó sorok egyikéből nem nagyon láttam a programkódokat, de a Liferay portletek gyors fejlesztésének és deployolásának hangulata átjött. Új alap portletet és service-et tényleg pillanatok alatt össze lehet rakni. Közelebbről még nem találkoztam a témával, mert inkább önálló webalkalmazások fejlesztésével foglalkozom, úgyhogy nem is ismerem a portál motorok legfontosabb karakterisztikáit. Viszont érdekelne, hogy hogyan illik bele a Liferay a legújabb Ajax-os, vastagkliens Javascript-es, HTML5-ös, REST-es trendekbe. Azt még megtudhattuk, hogy belül Spring-re épül. Jó sokan itt voltak a magyar Liferay-tól, vagy az iLogic-tól, vagy is-is. Junior EE fejlesztőt keresnek egyébként.

Csutorás Zoltán visszatérő vendég. Most a Scrum öt alappillérélől nyomta az előadást. Egész jó volt, a forma 1-es képnél még be is lelkesültem. Szó volt mindenféle dologról, ami szorosan és kevésbé szorosan kötődik a módszertanhoz: a laterális gondolkodásról, gondolati sémákról, arról, hogy miért jó sztoripontokkal becsülni embernap helyett, értékfolyamatról, áramlásról, visszaáramlásról -amikor vissza kell pakolni feladatokat a queue-ba, húzóelvről, kiértékelésről. Nehéz lenne ezt így visszaadni. Lényeg, hogy a 40 perces előadás után a kérdésekkel még jól elvoltunk vagy húsz percig. Így a két előadás ki is töltötte a két órát.

Update 2010.09.23: Éppen elindult az Adaptive Consulting honlapja, rajta az előadás anyagával.

Videófelvétel készült, de azt nem tudom hogy mikor hová lesz kitéve. A slide-ok elérhetőek lesznek a JUM honlapjáról.

Mercurial paranccsor alapok

Egyszer már írtam erről a verziókezelőről. Azóta inkább az SVN felé sodort az élet, de most ismét elővettem ezt a remek eszközt. Az online könyv, amit a múltkor említettem még mindig megtalálható, csak az URL változott: Mercurial: The Definitive Guide by Bryan O'Sullivan.

Egy-két alapkoncepció, amit a könyvből tudtam meg:

• Minden fejlesztő gépén van egy history-t tekintve teljes mélységű saját repository. Egy repo-t létrehozhatunk kézzel, de leklónozhatunk egy másikat. Amikor becsatlakozunk egy projektbe, tipikusan leklónozunk valami központi szerveren lévő repo-t. (Mert központi szerver azért itt is lehet.)
• A projekten belül a .hg könyvtárban vannak a Mercurial dolgai, a többi mind a miénk, nem szemetel bele. Ez utóbbit hívják 'working directory'-nak.
  
• A branch-elés nem egy kitüntetett művelet, hanem minden egyes revízió gyakorlatilag egy új branch-pont. Az előző ponthoz visszakanyarodva: tetszőleges revíziót le lehet klónozni, nem csak az utolsót.
• A commit csak a saját repo-ba teszi be a változtatásokat (hg terminológiában: changeset). A push paranccsal lehet kiküldeni a változtatásainkat központi repo-ba és a pull paranccsal lehet behozni másik változtatásait.
• Kétféle revízió azonosító van: egy szigorúan monoton növekvő természetes szám ami csak lokálisan érvényes és egy hexadecimális azonosító, ami globálisan érvényes az adott repo-ban. A szám azért nem lenne elég, mert nem biztos hogy minden repository klón ugyanazon az úton, ugyanannyi változtatással jut el egy állapotig. A hexa kódra kell hivatkozni tehát, ha másokkal kommunikálunk.
• A .hg/hgrc fájlban vannak az adott lokális repository-val kapcsolatos információk.

Van egy futó Maven projektem, amiből akarok csinálni egy Mercurial repo-t. Beállok a projektkönyvtárba és kiadom hogy hg init, majd pedig azt, hogy hg add, felsorolva a repo-hoz hozzáadandó könyvtárakat és fájlokat. Pl. a Maven projektem esetében: hg add src pom.xml. (Maven-nél az src könyvtárban van minden forrás, a pom.xml pedig a buildeléshez szükséges információ. Vannak még egyéb könyvtárak is, pl. target, de azt nem kell a repo-hoz adni.) Végül pedig hg commit.

Ilyenkor feljön egy szerkesztőablak (nálam notepad) amibe beírhatom a commit comment-et. A szerkesztőablakban HG prefix-szel ellátott sorokban eleve látható néhány igen hasznos információ, pl. hogy mely fájlok változtak. A HG-s sorok a comment-ben nem lesznek benne. Ha nem írok semmit, a commit nem fog megtörténni.

A commit-oló user-t egy fallback mechanizmus alapján találja ki. A legerősebb megadási mód, ha -u kapcsolót használok a parancsban és explicite megadom. Meg lehet még adni a hgrc fájlban és a lánc legvége, amikor a bejelentkezett felhasználó nevét használja.

A hg tip mond információt a legfrissebb revízióról (a tip Mercurial terminológia), a hg log pedig history-t írja ki. Satöbbi. A hg help kiírja a lehetséges parancsokat, a hg [parancs] help pedig az adott paranccsal kapcsolatos tudnivalókat.

De mi van ha meggondolom magam és mégsem akarok Mercurial-t használni? Kitörlöm a projekt home-ból a .hg könyvtárat (esetleg előtte kiadom a hg revert -ar 0 parancsot ami visszaállítja a working directory-t az eredeti állapotba, majd egy commit-ot) és kész. Nincs szemét sehol máshol, mindenféle alkönyvtárakban.

Azért mégiscsak írogatok az Eclipse pluginekről is:

A HGE Eclipse plugin is megvan még amit a múltkor próbálgattam, de már átköltözött a SourceForge-ra, összenőtt a MercurialEclipse nevű pluginnel és MercurialEclipse néven fut tovább. Ja és mellesleg az Intland fejleszti, aminek erős magyar gyökerei vannak. Amikor installálom a plugin-t az Eclipse-be, be lehet jelölni hogy Windows binaries-t is hozzon le. Ha nincs külön installálva Mercurial akkor érdemes, mert azt később fel lehet venni a path-ba (az eclipse/plugins könyvtár mélyén van egy közönséges Mercurial disztribúció) és ha a plugin zavarba jön, lehet kézzel kiadni parancsokat. Nekem szükségem is volt rá mindjárt az első kanyarban.

Melegvan

Péntek délutáni szösszenet a hőségriadó tiszteletére, külön dedikálva azoknak a döntési pozícióban lévő vezetőknek, akik légkondícionált helyiségben ülnek, a beosztottjaik viszont nem.

24 fok Celsius Valahol -tökmindegy hol- azt olvastam, hogy nagy átlagban ez az optimális hőmérséklet irodai munkához. Induljunk innen, vegyünk egy átlagos kontinentális éghajlaton élő irodai stábot, legyenek mondjuk szoftverfejlesztők. Mindenki serényen dolgozik relatíve maximális produktivitással. Aztán kezdjük emelni a hőmérsékletet és nézzük meg mi lesz.

25 fok Celsius Nem nagyon történik semmi, talán egy-két ingujj (ingujj?) felgyűrődik vagy egy-két tized százalékkal megnövekszik a folyadék fogyasztása az embereknek, de alapvetően marad a maximális produktivitás. Csattognak a billentyűk, pörögnek az agyak.

26 fok Celsius Gyenge hatékonyság-csökkenés figyelhető meg. Bonyolultabb kódrészek, mint például a párhuzamos szálkezelés, nem sikerülnek olyan jól, vagy kicsivel több idő kell a lefejlesztésükhöz. Az emberek többsége nem foglalkozik a körülmények változásával, de a szűkebb toleranciaküszöbbel rendelkezők szóvá teszik, hogy "gyerekek, nincs itt qrva meleg?"

27 fok Celsius A produktivitás érezhetően hanyatlani kezd, nemcsak azért mert az emberek kezdik kényelmetlenü érezni magukat, hanem a kreativitásuk egy részét a körülmények javítására fordítják, úgymint árnyékoló, légterelő és ablakkitámasztó eszközök barkácsolása irodában fellelhető alapanyagokból (iratok, gémkapcsok, számítógép alkatrészek). Ha van klíma de nem csinálja az elvárt hőmérsékletet, szükségképpen kialakul az eszmecsere a működéséről, elkezdődik a csesztetése, megindul a nyitott ablak vs légkondi vitaparti.

28 fok Celsius Az irodában mediterrán hangulat kezd úrrá lenni a testek kipárolgása és (jobb esetben) a fokozott illatosítók használata miatt, de mivel olyan emberek vannak összezárva, akik között a szexuális vonzódás nem értelmezhető -legalábbis nem egy teljes gráf formájában - ez nem egy szórakoztató környezet. A figyelem elkalandozik, megszaporodnak a beszédtémák: Miért nem működik rendesen a klíma? Miért nincs egyáltalán klíma? Vajon egy klíma, vagy legalább egy ventillátor fogyasztásának költsége hogyan viszonyulna a termeléskieséshez? Elégedett-e az ember a munkájával és a fizetésével? Aki elégedett az még rendesen dolgozik, legalábbis próbál.

29 fok Celsius Tiszteletem a bányászoknak, öntödei munkásoknak, építőmunkásoknak, tűzoltóknak, meg akikek kihagytam és melegben kell dolgozniuk. Szerintem fizikai tevékenyégnél a szervezet valami másik üzemmódba kerül, valahogy jobban el lehet viselni a meleget. Talán azért mert van valami légmozgás. A székbe ragadva viszont érzem ahogy nagy kövér izzadtságcseppek gyülekeznek a hátamon és néha egyik-másik legurul az alsónadrágomba. Izzadás közben azon gondolkodom, hogy vajon büdösebb vagyok-e mint a szomszédom és hogy ilyen hőmérsékleten bizony a kisgatya az adekvát viselet. Otthoni melónál ez nyilvánvaló, azzal a kitétellel hogy ott nem pörgeti magát azon az ember, hogy miért nincs klíma, valamint bármikor vehet egy frissítő hideg zuhanyt. Visszatérve az irodába: már az igazán motivált emberek sem tudnak hatékonyan dolgozni, a többiek meg csak pöckölgetik a feladataikat.

30 fok Celsius Zsírtól csillogó bőrű és csatakos szőrzetű homo sapiens példányok próbálkoznak a rájuk osztott feladatok megoldásával egy trópusi klímájú helyiségben. Produktivitásról nincs értelme beszélni, mert a cél egyre inkább az életfunkcióik fenntartására koncentrálódik, valamint bizonyos egyedeknél elrévedő tekintetek figyelhetőek meg, ahogy az elkövetkezendő hétvégére, szellőre, vízpartra, vagy éppen egy jó hideg fröccsre koncentrálnak igazi szódával, hatalmas buborékokkal, száraz fehérborból, üvegpohárból, fák alatt árnyékban, kockás terítős zöldre mázolt vasasztal mellett fogyasztva.

Egészségünkre!

JUM XV.

A XV JUM-ról gyorsan, késve:
Csúszott is a dátum, nem is jött be a terv, de azért lett két jó előadás.

Bemelegítésnek Kovács Richárd a BTrace-ről nyomta:
Különös alternatívája ez a debug-olásnak. Java-ban lehet megírni a kódot ami végrehajtódik, ha ráfut a vezérlés a megadott metódusokra. A Java-ban megírt kódnak viszont rengeteg kötöttsége van. Nem lehet új objektumot létrehozni, ciklus sem lehet, ilyesmik. Használhatónak tűnt az a felhasználási eset, amikor a JDBC csomagban lévő osztályok bizonyos metódusaira kötöttek debug kódot és kiírták hogy milyen SQL-ek mennek az adatbázis felé. (ORM esetén hasznos.)

Marhefka István a Domain Driven Design-ről beszélt:
Sok embernek talán bullshit-nek tűnhet a DDD. Van róla könyv angolul Eric Evans-tól. Íme a DDD főbb ismérvei:

Tiszta domain modell: A domain modellnek ne legyenek technikai függőségei. Ebbe szőrmentén az a kérdéskör is beletartozik, hogy az entitásokat ellássuk-e JPA annotációkkal vagy inkább XML-be tegyük a perzisztálási információt. De semmiképpen sem jó teleszőni a business logikát mindenféle keretrendszer és kommunikáció specifikus osztályokkal, mert így taligával toljuk a projektbe a kockázatokat: hordozhatatlanság, tesztelhetetlenség, bottleneck-ek, business és licenszelési szintű problémák.

Inversion of Control: A DDD egyik eszköze. Nem esett róla szó, de arra (is) való hogy egy nemkívánt irányú függőséget megfordítsunk. (Bővebben: Robert C. Martin, Agile software Development)

Magyarítás: Egyik blogon éppen megy a bokszmeccs. Én is abba a táborba tartozom, aki nem igazán magyarítana, bár sajnos nem tudok bekommentelni, mert minden magyar blog le van tiltva itt nálunk. (Jó hely...) Annó leírtam már a véleményemet ebben a témában, ami azóta sem változott.

Dual data source: A dolog lényege, hogy nem ugyanazon az úton nyerjük ki a perzisztens adatokat, mint ahogy beletettük őket valahova. Pl. JPA-val perzisztáljuk az adatokat, de SQL-lel szedjük ki őket. Ez jóval hatékonyabb lehet bizonyos esetekben, mert meg lehet spórolni a (java) objektumokra való mappelést. Meghökkentően hangzik, de néha mi is használjuk. Sőt, ha belegondolok ez egy funkcionális megközelítés. A perzisztens tár maga egy függvény, ami egy tranzakción belül konstans értékeket ad vissza. A service metódusaink kimenete, visszatérési értéke pedig egy utasítássorozat (Command Pattern), ami beír majd a perzisztens tárba. Érthető? Nem?

NoSQL: Ami nem azt jelenti hogy NO, hanem hogy NOT ONLY. Cesjava írt róla sokat, úgyhogy nem is részletezem.

DTO: Azaz Data Transfer Object. Nagy viták célpontja hogy legyen avagy ne legyen. Mostanában olyan (RestFul) architektúrákkal találkozom hogy egyértelműen kell hogy legyen és mellesleg nem is Java objektum hanem JSON (JavaScript) vagy XML.

Nagyjából ennyi maradt meg bennem. Nyáron szünet, ősszel találkozunk!

Javascript grafikon rajzolók

Van nekem egy régi Swing-es java programom, ami JFreeChart segítségével grafikonokat rajzolgat. Fejembe vettem hogy átírom ezt egy Ajax-os webes alkalmazásnak, viszont hamar szembesültem vele, hogy a JFreeChart ilyen formájú használata nem lenne túl hatékony. Egyrészt ha a megjelenítendő adatok a kliensen is rendelkezésre állnak akkor fölösleges lemenni a szerverre egy 20-60 kilobájtos PNG-ért, másrészt a JFreeChart nem valami hatékonyan rajzolgat és ez fölösleges processzorterhelést jelentene a szerveren, főleg mert ezeket a grafikonokat még cache-elni sem lehet nagyon. Itt azért megjegyezném, hogy a JFreeChart egy nagyon is jó library, meg vagyok vele elégedve, csak most erre a célra nekem nem jön be.

Ismerem a Google charts szolgáltatását is, itt van éppen oldalt egy grafikon amit azzal rajzoltatok. Tömören: Erre a célra nem bejövős.

Megnéztem hogy vannak-e használható JavaScript megoldások. Kerestem olyan oldalakat, ahol review-szerűen megvizsgálnak néhány library-t, de mindegyik körülbelül azt tudta, hogy felsorolt 4-5-öt és leírta hogy ez szép, ez nem annyira, stb. Egyedül ez szánta rá magát, hogy pár kódpéldát is beszúrjon. Kerestem magukat a library-kat is. Végül ezeket találtam:

• Emprise Charts: pénzes és nem olcsó. Vajon a forráskódját mennyiért adják ki?
• PlotKit: valami MochiKit-re épít, ami elég komolytalannak látszik és halott linkek vannak a honlapján ráadásul 1.5-ös Firefox kompatibilitásra hivatkoznak.
• JsCharts: igényesnek néz ki a belépőoldaluk. Első látásra van valami ingyenes letöltési lehetőség és pénzes használat is.
• HighCharts: Flash-t is használ. Non-profitnak free, amúgy pénzes.
• Grafico: prototype.js -re épít, elég fapados.
• Plotr: A PlotKit alapján csinálták, BSD licenszes és prototype-et használ. Nem túl csilivili. Úgy nézem kb. két éves az utolsó release és kisebb a verziója mint 1.0.
• Bluff: MIT licensz, nem érte még el az 1.0 verziót. Nem túl csilivili, elvileg kicsi.
• dygraphs: Elvileg nyílt forrású, a github-on van a kód. Csak timeseries-eket tud, de azt elég tudományos (nem csilivili) módon.
• graphael: Raphael-re épít, ami egy SVG alapú javascript-es rajzoló motor. 0.4-es verziónál tart.
• JSXGraph: LGPL, SVG-t használ, német egyetemi fejlesztésnek nézem. Tudományos.
• FusionCharts: Flash. Van ingyenes és pénzes verziója is.
• Flot: JQuery plugin

Volt még néhány -főleg JQuery pluginek- de ezeket nem írtam fel, mert nem akarok JQuery-től függeni. (Egyelőre az extjs javascript könyvtár látszik bejövősnek általános GUI és kliensoldali logika célokra. Az extjs-nek is van grafikon rajzoló képessége, de az meg Flash-es amit szintén nem akarok.)

Szóval azok a kritériumaim, hogy legyen a könyvtár jól dokumentált, jól supportált. Nem baj ha fizetni kell érte de azért ne menjen rá a gatyám. XY series-eket akarok majd megjeleníteni, (olyasmit mint ami a post-ban is látható, ha látható) és még mindenféle képet, pöttyöt markert is rá akarok tenni a grafikonra. Tehát ha zárt forrású akkor legyen jól bővíthető, vagy pedig legyen nyílt forrású és akkor majd bővítgetem én. Ha nem találok olyat ami bejön, akkor lehet hogy nekiállok én csinálni egyet, de ehhez biztos kell majd valami alacsonyabb szintű rajzoló komponens. Nem ártana ha menne a cucc a modernebb böngészőkön és alma logós termékeken is. Egyelőre még az sem világos hogy mi a jó irány, egyáltalán milyen irányok vannak. HTML5, SVG, Canvas, ezek közül melyik melyiknek a részhalmaza. Van mit átnéznem.

Valószínűleg frissíteni fogom még ezt a post-ot a library-k felsorolása környékén, ahogy ismerkedem velük és jönnek az újabb tapasztalatok. Ha valaki rá vagy éppen le akar beszélni valamelyik megoldásról az tegye. Egyelőre pártatlan vagyok.

Update 2010.06.09: Inkább csináltam egy Google Spreadsheet-et, amibe töltögetem a Javascript grafikon rajzolókkal kapcsolatos tapasztalataimat. Az mindenképpen aktuálisabb, mint a post-ban lévő lista.

Oracle Sun Java Roadshow Bp

Bár a helyszínen még a Sun nevével voltak fémjelezve az útbaigazító táblák és a névkártyákra is ezt a cégnevet nyomták, a keynote-ban Geoff Morton az EMEA szintű főnök biztosított róla, hogy a felvásárlás megtörtént és ezek már csak adminisztrációs dolgok. Meghallgattuk még a Java történetét, hogy milyen jó és fontos platform, még vagy ötször a felvásárlás tényét. Ami nekem új volt, az a licenszelési politika, vagyishogy a JRE-t ingyen fel lehet tenni általános célú hardverekre, de célhardverekre már pénzért. Később a szünetben egyetértettünk benne, hogy egy szerver nem célhardver. Érdekes volt látni egy diagramot a Java helyéről. Rajta volt már a Blu Ray, TV settop boxok és a szokásos mobil, szerver, desktop. Aztán jöttek az érdemi előadások.

Dr. Rainer Eschrich ismét egy sales ember és a MIDP-ről, az embedded Java-ról beszélt. Például a mobilgyártóknak royalty-t kell fizetniük ha JVM-et tesznek a telefonjukba, de ez eddig is így volt. A különbség annyi lesz, hogy eddig megkapták a forráskódot és belehegesztették amit akartak, ettől aztán telefononként néha kicsit máshogy működnek a MIDP alkalmazások időnként. Ezután az Oracle szándékozik bináris disztribúciókat készíteni mindenféle chipset-re. Na ezt még megnézem. aaaaa

A következő előadás is Rainer-é volt a realtime java-ról. Ez egy gönyörű téma, csak címszavakban: Soft realitme, hard realtime, okos szemétgyűjtés, prioritások, immortal memory, RealTimethread, NoHeapRealTimeThread, aztán a végén megint az a feladat hogy úgy kell programozni mintha C-ben lennénk. Statikus adatstruktúrákat kell használni, vaskalaposan. Még felírtam két nevet akiknek a munkásságát érdemes ebben a témában fellapozni: Greg Bolella és Eric Bruno (nem a színész). Néztünk még videót a sivatagban számítógéppel és RT Java-val driftelő audi TT-ról-ről.

Business Java, következő előadás: Ez nem egy új kódbázis, hanem a meglévő SE-nek a licenszelési módja. (Java EE, Java ME nem.) Pénzért prémium support. Régebbi verziókat is frissítenek majd néha az 1.4-ig bezárólag és a BFJ licenszorok hamarabb megkapják ezeket a frissítéseket, a gondokról pedig hivatalos emailben értesítődnek. Az is mondás volt, hogy ha valaki felíratkozik egy ilyenre X hardverrel és Y oprendszerrel, az Oracle-nél gondoskodni fognak róla, hogy a kijövő release működjön ezen a platformon. No ezt is megnézem. Egy kérdésnél szóba került a Google és az ő saját Java-juk. Geoff felidézte a régi Microsoft-os csetepatét, amikor ki kellett szedniük a Windows-ból a saját Java implementációt és még büntit is kellett fizetniük Bill-éknek. Valójában az Android sem rendes Java, nem megy át a hivatalos teszteken, bele lehetne kötni hogy miért használják mégis a nevet. Van egy minimális félelmem, hogy az Oracle nekimegy a Google-nek, de ez elenyésző. Tényleg mi lenne ha ez a két mammut elkezdeni haragban lenni? Nem jelennének meg a Google-n az Oracle-s Java találatok. Na jó ez egy elég hülye vízió. A szünetben láttam Android alkalmazást és embert, aki valóban keresett már vele pénzt. Update 2010.08.13: És igen. Jönnek a hírek, hogy az Oracle lehet hogy perelni fogja a Google-t az Android miatt. Ahogy Gosling bácsi írja, "a szar végül elérte a ventillátort".

A szünet is elég értékes egy ilyen rendezvényen. A Groowiki-ről, az EPAM-ról és a Liferay hazai fejleményeiről hallottam. Persze nem csak emiatt értékes, hanem a kaja és ital hegyek miatt is.

Simon Géza jött egy JavaFX előadással. Ismét röpködtek az animációk és a deklaratív kódrészek és felhívta a figyelmet rá, hogy akinek Java6u10-e van vagy magasabb, annak ott figyel a gépén a JavaFX. Egyszer már kipróbáltam ezt a technológiát Eclipse-en, de lehet hogy Netbeans-en kellene. Megjegyezte hogy már több éve tart előadásokat a témában, de egyre többet lehet mondani róla, szóval egyre több mindent ki kell hagynia. Ami még érdekes, hogy ugyanaz a kód futhat különböző hardvereken. Például nem kell újraírni az alkalmazást ha desktop és mobilos alkalmazást fejlesztek egyben. Elég utópisztikus gondolatnak tűnik nekem, hogy ez működjön.

Végül Stefan Kolmar a Berkeley DB-ről mesélt. Az igazat megvallva erről még nem hallottam, de ez egy kő egyszerű adatbázis motor, amiben alapból még konkurrencia kezelés és SQL sincs, de szépen fel lehet díszíteni. SQL Lite -ot raktak fölé SQL rétegnek. Nem gyors csak kicsi, elfut adott esetben mobil eszközben is, de nagy szerverekben is használják. Jó tudni róla. A MySQL-ért aggódó emberek is jelentkeztek kérdéssel, hogy mi lesz a jövő, ha az Oracle-nek ennyiféle DB motorja van. Stefan biztosította róla a társaságot, hogy a MySQL élni fog.

A fóliákat egyébként majd valamikor le lehet tölteni valahonnan, ha vége lesz a Roadshow-nak. Londonban lesz az utolsó alkalom.

Csodáltam ezeknek a Sales embereknek a technikai felkészültségét egyébként. Látszott hogy mélyebben is ismerik azokat a dolgokat amikről beszélnek, nemcsak bullshit-eket puffogtatnak.
Tegnap volt a fényűzés, dőzsölés, ma pedig megyek vissza biteket faragni a gyárba.

Java build eszközök

Jelenleg "kisebb" projektekhez Ant-ot, "nagyobbakhoz" Maven-t használunk. Itt a "kisebb" azt jelenti, hogy a projekt outcome-ja viszonylag egyszerű, -pl. egy darab jar fájl-, valamint a függőségi gráf nem túl szövevényes. A függőségeket paraszt módon betesszük verzió kontrollba, mert ezeken a projekteken olyan emberek is dolgoznak, akik nem feltétlenül vérbeli fejlesztők és könnyebb volt így csinálni, mint elmagyarázni a Maven vagy Ivy filozófiáját. Ezek a projektek egyébként főleg kísérletezések, kódkezdemények. Halkan megsúgom hogy olyan projekt is van, amit egy DOS vagy *n*x batch script rak össze.

A nagyobb projekt ott kezdődik, ahol a függőségek mérete megabájtos nagyságrendben mérhető és/vagy az outcome-ba felfedezhető valami hierarchikus szerkezet. Pl. a webalkalmazások tipikusan ilyenek. Itt a Maven jobban bevált.

Egyébként nem vagyok sem Ant sem Maven hívő. Olyan a kettőt összehasonlítani mint a vonalzót és a tolómérőt. Mind a kettő egy eszköz, ami nagyjából ugyanarra, de mégis kicsit másra jó. Van egyébként a Blog Subject Queue-mban egy Maven firkálmány abból az időből amikor ismerkedni kezdtem vele, de hosszú lett és csapongó, nem tetszik - nem publikáltam. Az egyik JUM-mal kapcsolatban viszont egyszer írtam róla. Az egyik probléma a Maven-nel, hogy elég magas a belépési küszöb. Nem lehet lépésről lépésre megismerni. Csak akkor kezdi az ember megérteni a lényegét, ha elolvasott párszor tíz oldalt. A hivatalos weboldalon található irományok engem elég nehezen vittek közel a tudáshoz, viszont a Better Builds With Maven még mindig egy viszonylag jól összeszedett letölthető dokumentum. Háromszáz oldalas.

A javalistán lévő márciusi OSS című thread-ban felfigyeltem néhány alternatív megoldásra. Egyik a Maven-hez készülő Polyglot, ami arról szól, hogy a projekt leírót nem csak XML-ben, hanem egyéb divatos nyelveken (Scala, Groovy, Clojure, Ruby) is össze lehet rakosgatni. Ha divatos nyelvek, akkor már lehet hogy érdemesebb lenne a Gradle-be, vagy az SBT-be belenézegetni, amik nem csak skin-ek a pom.xml-re. Ezekben közös, hogy kölcsönveszik a függőségkezelést és az archetype-ok koncepcióját a Maven-től (vagy az Ivy-től), de több szabadságot próbálnak adni a projekt leírása terén.

A Gradle Groovy-ra épít. Őszintén szólva engem egy pár perces olvasgatás után nem győz meg maradéktalanul. A stackoverflow-on találtam még egy ezzel kapcsolatos kérdést és a hozzá tartozó válaszokat. (Why use Gradle instead of Ant or Maven?) Egyébként nem is tiszta teljesen, hogy ez most deklaratív vagy procedurális eszköz. Ha jól értem ugyanúgy deklaratíve task-ok közötti függőségeket kell megadni mint Ant-ban, csak a task-okon belül van procedurális végrehajtás. Nekem éppen az nem kényelmes, hogy explicite meg kell adnom, hogy egy task mitől függ.

Az SBT (Simple Build Tool) pedig Scala-ra épít. Ugyanúgy nem adja meg azt a késztetést, hogy erőt fektessek egy Ant-projektból való átlépésre vagy egy új projekt SBT-ben való elindítására. Röviden, de viszonylag körmönfontan kell leírni a build-eléshez szükséges információkat, akkor már inkább maradok az XML-nél. De a Brizzled blogban találtam egy érvelést és tapasztalatmegosztást, ami talán később vagy másnak bejön.

Akinek van ezekről -vagy más egyéb build tool-okról- tapasztalata, az kalapálja be ide a kommentekhez bátran.

JUM XIV.

Most kicsivel kevesebben voltunk mint általában, ráadásul jópár régi arcot hiányoltam. Node nézzük az előadásokat.

Brillien
A brillien.org-on elég jó írásokat lehet róla találni angolul és magyarul is, de az igazat megvallva ez nem egy könnyű téma, főleg a Session Bean-ekre beszűkült agyú embereknek. Jó volt élőben is hallani róla. Felvettem a kipróbálandó dolgok listájára, de ahogy most állok lehet hogy az amerikaiak előbb érnek a Holdra (még így is), minthogy én eljussak odáig hogy valóban foglalkozni tudok a Brillien-nel.

Elég invazív egyébként a cucc, tehát eleve olyan osztályokat kell írni, amik Brillien-specifikus ősosztályokból öröklődnek és fel vannak annotálva. Megtudhattuk még, hogy valóban működik production környezetben, mégpedig telemetikai rendszereket szolgál ki, és szimpatikus BSD licenszelésű. Állítólag teljesítményben is jó, még akkor is ha sok JSON szerializációt csinál mélyen a belsejében. Akinek van ideje próbálja ki és írjon tapasztalatokat!

TodoMap

Itt lakik a TodoMap. Kocka nagyon ráment a politikai vonalra, pedig nincs rá szükség szerintem. Engem főleg a belső megoldások érdekeltek, és ebből kaphattunk is egy hosszú listát. JQuery UI-val pl. azok a tapasztalatok ha jól értettem, hogy az alap komponenskészlet nem túl bő, plugineket kell használni. Viszont ahány plugin, annyi verziójú JQuery-re van szüksége, de csak egyet lehet használni. Tehát annyira nem lett nyerő. Az authentikációhoz az OpenId-t használja, tehát nem csinál saját juzer adatbázist. Ez a megoldás engem is érdekelne egyik projektben. No a kormányzati informatikával való összedrótozással kapcsolatban igencsak szkeptikus vagyok. Esetleg kisebb falu vagy utca nagyságú közösségeket el tudom képzelni, hogy rácuppannak, de a kormányzati informatika más szint: Vetítések, baráti kézfogások, aprópénzek, asztal mellé leeső morzsák. És akkor a végén vagy működik a dolog vagy nem. Nem is írok semmit.

SameBug

Ők pedig kivételeket gyűjtenek. Még nem tudni mi lesz belőle pontosan, mert ez egy szakdoga téma, prototípus, proof of concept. Engem mindenesetre érdekelne valami megoldás, hogy ha kiböfög a programom egy stacktrace-t, adott esetben minél értelmesebb választ tudjak találni róla a neten. Erről még biztos hallunk majd. Talán én is írok még majd róla.

Videó ezúttal nem készült, de ha többszázan őrülten keresni fogják, akkor legközelebb nagyobb hangsúlyt fektetünk rá hogy készüljön.

Scala online olvasnivalók

Néhány angol nyelvű online olvasnivaló Scala-val kapcsolatban, hogy ne Neked kelljen összevadásznod:

• Az alap 15 oldalas Scala tutorial for Java programmers, amit a Google elsőre kihoz és a letöltött disztribúcióban is megtalálható. Gyors áttekintésnek jó, de csak a felszínt karcolja.
• A Scala By Example nekem kezdésnek bejött. Az interpreteres megközelítéstől indul, azaz amikor utasításokat írunk konzolra és a Scala válaszol rájuk. Ez már mélyebben belemegy a dolgokba 145 oldalon keresztül, de még mindig hiányoznak belőle részletek. (Névtelen függvények kompakt változata, XML kezelés, kivételek, ...) Egy eléggé friss változata szintén megtalálható a disztribúcióban.
• A harmadik pdf ami lejön a scala-install.jar -ral, a Scala Language Specification, amiben viszont természetesen minden benne van, csak nem földi halandók számára érthető módon. Mindenesetre annak kiderítésére alkalmas hogy milyen funkciók vannak a nyelvben, amikkel aztán valami könnyebben emészthető forrásból meg lehet ismerkedni.
• A letöltött Scala disztróban a doc/scala-devel-doc könyvtárban akadnak példakódok és API doc is. Az API doc-ban vannak linkek a forrásra is, ami egy online SVN repóra mutat.
  
• A HUP fórumban találtam linket egy ingyenes online OReilly könyvre: Dean Wampler, Programming Scala. Sokminden benne van, de az a tapasztalatom, hogy néha (ritkán!) nincsenek teljesen kifejtve a bonyolultabb témák, főleg a különböző funkciók kombinálása terén. Érdemes letölteni lokálisra, mert eléggé lassan jönnek be az oldalai. Olvasói kommentek is vannak az online anyagban. Talán ez a legjobb a felsoroltak közül.
  
• First steps to Scala az Artimánál a kályhától indulva, valamint sok más egyéb komoly írás a Scalazine-ban.
  
• James Strachan blogbejegyzése, ami magát a nyelvet nem részletezi, de tartalmaz néhány érvet és hasznos linket.
• A Tour of Scala nem lineáris online olvasmányt is James linkjei között találtam, ami a scala-lang.org -on, a hivatalos Scala oldalon van. Ez átfutja a nyelv jellemzőit.
  
• Szintén a scala-lang.org -on található a Reference Manuals oldal, ahonnan már az előzőekben is említettem egy-két írást. Ugyanitt papírkönyvek is fel vannak tüntetve.
• Írások az IBM-nél elfoglalt java programozóknak.
• CodeCommit: Scala java-soknak, ami egész jó. Valamint Java Scala együttműködés ugyanitt.

• Topik a jhacks-on, ami egyelőre még eléggé csonk. -Ez magyar.

Más magyar nyelvű bővebb írásokkal nem találkoztam még, halott fa formátumú angol anyagokat pedig még nem vettem a kezembe eddig.

JUM XIII.

Egy-két gondolat lóhalálában szerda estéről:

Verhás Péter Maven plugin írási bemutatója engem meggyőzött. Lehet hogy Maven-ben könnyebb plugin-t írni, mint bekonfigurálni egy projektet? Amire magát a plugin-t írták - statikus weboldalak összerakása - arra én is csak akkor vetemednék ha sajátról lenne szó. Nekik ez a saját céges honlapjuk generáló motorja. A prezi.com ismét jól szuperált.

A JBoss ESB bemutatónál egy régi sztori jutott eszembe a JMS-ről, amit el is mesélek:

6-7 éves csináltunk egy szoftvert, aminek a specifikáció szerint az volt a célja, hogy megbízhatatlan kapcsolaton lógó vastag kliensek között létesítsen kapcsolatot megbízható módon. A vastag kliensek "időnként" lekapcsolódhattak a rendszerről és alapvetően naponta "néhány", "pár kilobájtos" adattömböt küldtek a szerverre, amit el kellett juttatni a címzett másik kliens(ek)nek.

JBoss-t és JMS-t választott erre az akkori architekt ember, mert skálázható, tranzakcionális stb.

Ezzel szemben az éles rendszer valódi karakterisztikája kb. a következőképpen nézett ki: A vastag kliensek nem "néha lekapcsolódtak", hanem hetente egyszer rákapcsolódtak a szerverre, de ekkor már több ezer darab, 10-200 kilobájtos adattömb várt rájuk kiküldésre. Ez persze egyenlő volt egy fejlövéssel a JBoss-nak és a JMS-nek. Kiderítettük például, hogy a JMS válaszideje nagyjából lineárisan nő attól függően hogy mennyi üzenet van a globális queue-ban. A tanulság persze az volt, hogy "a JBoss sz*r", "a jáva lassú" és megoldásként valaki újraírta az egészet mondjuk C++-ban két nap alatt, skálázhatóság és igazi tranzakcionalitás nélkül.

Ennyi a történet. Elvileg az új JMS motor, a HornetQ gyors, nem muszáj adatbázissal használni és nem feltétlenül kell hozzá appszerver. Meglátjuk.

Scala: kíváncsi vagyok hogy valójában mennyire sikerült kedvcsinálónak az előadás, vagy mik voltak a legelrettentőbb részek. Pár dolog kimaradt, de talán a lényeg átjött.

A prezik illetve a scala példakódok elérhetőek lesznek, az előadásokat pedig meg lehet nézni az Ustream-en a JUM oldalról ügyesen odanavigálva. De a felvételeket inkább csak hallani lehet, mert a vetítő képe egyáltalán nem látszik. Erre még ki kellene találni valamit. Ötletek, megoldások welcome.

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.