2010-06-25

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!

2010-06-03

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.