JavaFX Eclipse kipróba

Kitaláltam hogy beleszagolok a JavaFX-be.

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

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

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

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

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

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

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

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

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

Kódlefedettség-mérés

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

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

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

Node mire jó ez?

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

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

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

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

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

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

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

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

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

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

Sun Java Café

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

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

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

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

JUM X.

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

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

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

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

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

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

Deszantos programozás

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

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

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

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

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

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

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

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

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

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

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

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

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