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.

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.

logging vs debugging

Az utóbbi időben több olyan társasággal is találkoztam, akik folyton egy debugger előtt görnyedtek, emellett eléggé hanyagolták a debug szintű loggolást. Nekem nem volt szimpatikus ez a megközelítés. Láttam félrecsúszott helyzeteket is, amikor hatékonysági, többszálú vagy tranzakciós (vagy ezek kombinációi) problémákat akartak megoldani a srácok csupán az IDE-be beépített interaktív debugger segítségével. Persze nem igazán sikerült.

Arról az esetről nem is beszélve, amikor kiment a szoftver élesbe és logok híján telefonon kellett a felpaprikázott ügyféltől kérdezgetni, hogy mi volt pontosan a hibajelenség és mi volt pontosan a tevékenység, amit csináltak. Egy jó log-állomány fekete dobozként vagy önvédelmi eszközként funkcionált volna, mert pontosan fel lehetett volna deríteni a szoftver gyenge pontjait, vagy hogy nem rendeltetésszerűen használták.

Nekem azért sem szimpatikus az interaktív debugolás, mert program státuszának adott pillanatbeli vizsgálata elveszi a figyelmet a dinamikus működésről. Csak előre lehet lépkedni, de ki tudja visszakövetni, hogy mi volt ötven lépéssel ezelőtt és mi lehetett volna, ha egy bizonyos érték valahol máshogy van beállítva? Csak egy keskeny ösvényt járnak be ami egy adott prekoncepció alapján születik, holott inkább a kvantumszámítógép elv követése lenne a hasznos, ahol egy kódrész lefutásainak összes lehetséges variációját figyelembe vesszük. Ezt pedig leginkább sok tapasztalattal, tiszta fejjel és sok intuícióval lehet megcsinálni.

Kíváncsian hallgattam meg a Software Engineering Radio debugolással kapcsolatos részét, vajon mit mond egy olyan ember, akit már érdemes meginterjúvolni a témában.

Meglepődtem mikor ő is azt mondta, hogy rossz megoldás fejest ugrani rögtön az interaktív debugerbe. Előbb nem árt gondolkodni, minél jobban leszűkíteni a hiba lehetséges helyét, ha kell azzal hogy papírra leírjuk a tapasztalatokat. Esetleg hazamenni aludni.

Mesélt még róla, hogy ezek az IDE-be integrált debugerek nagyon kezdetleges eszközök. Viszont vannak olyan automatizált eszközök is amik amellett hogy futtatják a regressziós teszteket, hiba esetén vissza tudják keresni hogy az adott teszt mely verzióval működött jól utoljára és a verzió követő rendszerben milyen modulokban milyen változások történtek azóta. Ezáltal elég jól be tudják azonosítani a hibák lehetséges helyét és elkövetőjét. Érdekes dolgok ezek. Egyszer majd kipróbálom talán, addig is szorgalmasan reszelgetem a debug szintű logjaimat.

Gyertek JUM-ra 19.-én!

Update 2009.08.12: (Ezt azért írom, hogy ha már nem vagyok kinn a Szigeten, legalább valahogy mégiscsak elcsesszem az időt meló helyett.) A bejegyzés első része Enterprise Java alkalmazásokra vonatkozott, amelyek leginkább appszerverek belsejében futnak, de mostanában a Javascript felé sodort az élet, aholis kicsit már más a leányzó fekvése debugolás vs loggolás tekintetében.

Előszöris nem nagyon van hova loggolni. Leginkább alert popup-okat szoktak beszúrogatni ide-oda, amit aztán le kell okézni, vagy a HTML DOM bizonyos helyeire írogatnak be szövegeket. Trükkökkel lehet konzolt csiholni, de ez nem igazi log, tényleg csak egy konzol. De nem is ez a legnagyobb probléma, hanem hogy a java-val ellentétben a Javascript egy gyengén típusos dinamikus nyelv, tehát igen nehéz követni, hogy a program futásának adott pillanatában mi a környezet: milyen változók élnek, azoknak milyen mezői és függvényei vannak és ezek hogyan vannak egymásba ágyazva, egyáltalán mi a scope, mi a this referencia. Ráadásul elég sokat találkozik az ember külső Javascript komponensekkel, amiknek a működését nagy vonalakban nem árt megérteni. Viszont: A javascript-ben egy szálon fut a program, tehát nem eshetek komoly csapdákba debugolás közben a szinkronizációk és időzítések miatt.

Szóval ez az az eset, ahol mégiscsak bőszen használom az interaktív debuggert, nevezetesen a Firebug-ot, de Internet Explorer-re is van valami hasonló csak nem annyira ingyenes. Ennek ellenére Javascript klienseknél sem lenne haszontalan egy debug-log szintet kialakítani, amikor a böngésző Ajax-szal leküld bizonyos logokat a szervernek, de a tapasztalat azt mutatja, hogy olcsóbb szotyoláért egyetemistákat ráküldeni a gui-ra kattintgatni.

Dojo dátumválasztó agyműtét

Még mindig Dojo. Két baj volt a DropdownDatePicker-rel ami miatt bele kellett kicsit másznom a kódba. Az egyik, hogy ha érvénytelen értéket írok bele a HTML-ben, akkor hülyén jelenik meg a dátumválasztó (mindenhol NaN van), márpedig nem ártana ha megjelenítené azt az érvénytelen értéket is a szövegmezőben, a dátumválasztó komponensben meg pl. a mai napot. A másik, hogy a 0.3-0.4 verzióváltás egy kicsit döcögősre sikerült. Megváltoztak mezők nevei (date-value, displazFormat-dateFormat) és senki sem védi meg tőle a doksikkal nem elhalmozott programozót hogy keverve használja ezeket a dolgokat.

Állítólag az első problémát már próbálják orvosolni a 0.4.1-re, de nem nagyon bízom benne hogy úgy sikerül ahogy kellene neki. A repo-ban is olyat olvastam, hogy valaki bekommitolt valamit, a másik kipróbálta és nem működött. Verziók...

Szóval a következőt csinálja ez a dropdowndatepicker:

1. A value mezőből kiolvassa a string értéket és megpróbálja dátummá konvertálni. Próbálja Rfc3339-es (yyyy-mm-dd) formátumban is meg más formátumban is. Közben warningol, mert Rfc3339 lesz a támogatott 0.5-től és senki sem azt használja. Ha sikerül neki a parse-olás akkor a value változóban egy szép érvényes dátum objektum lesz, ha nem sikerül akkor egy érvénytelen dátum. (Ami baj, mert máris elveszett az eredetileg beírt érték.)
2. Ezután a dátum szerint beállítja a dátumválasztó komponenst. Ha érvénytelen volt a dátum, mindenhol NaN lesz.
3. Végül a dátumválasztó állapota szerint visszaírja a szövegmezőbe a dátumot a megadott formátummal. Tehát ha véletlenül megmaradt volna az érvénytelen érték, még itt is felülvágná.

Ráadásul Post-olás előtt, ha érvénytelen dátum van a szövegmezőben, akkor felülvágja a komponensen kiválasztott dátummal, de ez csak a 0.4-es verzióban támogatott displayFormat használatánál jelentkezik. Van is egy szép TODO komment ezzel kapcsolatban a forrásban.

Szóval a következő helyeken nyúltam bele az agyába:

• Ha a kiolvasásnál nem tudja dátummá konvertálni, nem ír vissza érvénytelen dátumot, hanem magát a string-et írja vissza.
• Ha a dátumválasztó komponens beállítása előtt érzékeli hogy a value típusa string, a komponensen a mai napot jeleníti meg.
• Ha a value típusa string, nem frissíti a szövegmezőt a komponens értéke szerint (mai nap).

Ha lenne attach-olási lehetőség, beraknám ide a kódot.

Prototype

A prototype egy jó kis kliensoldali javascript framework ami segít Ajaxozni és matatni a DOM-ban. Itt van róla egy tutorial, meg itt is a
24ways-on, meg itt is. Ezek az infók pedig az Ajaxian-ról származnak.