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.