Törött ablakok és hitelek

Az utóbbi időben volt szerencsém elolvasni néhány érdekes írást programozástechnikáról. Ez nem arról szól, hogy a Java/C#/C++/Lisp nyelven jó programokat írni (noha az is hasznos olvasnivaló lehet), hanem inkább afféle ötleteket mutat, amik a programozási munka menedzsmentjéhez tartoznak.

Igen, erről nem véletlen, hogy egyeseknek a [[A programozás technológiája|PT]] jut eszébe, de szerintem annál jóval gyakorlatiasabb dologról van szó. 🙂 Persze ezt az én erőteljesen elfogult véleményem mondatja csak velem, nyilván másnak ugyanolyan használhatatlan dologról van szó.

Az utóbbi időben volt szerencsém elolvasni néhány érdekes írást programozástechnikáról. Ez nem arról szól, hogy a Java/C#/C++/Lisp nyelven jó programokat írni (noha az is hasznos olvasnivaló lehet), hanem inkább afféle ötleteket mutat, amik a programozási munka menedzsmentjéhez tartoznak.

Igen, erről nem véletlen, hogy egyeseknek a PT jut eszébe, de szerintem annál jóval gyakorlatiasabb dologról van szó. 🙂 Persze ezt az én erőteljesen elfogult véleményem mondatja csak velem, nyilván másnak ugyanolyan használhatatlan dologról van szó.

Nem tudom, mennyire ismert a „törött ablakok elmélete” (Broken Window Theory), ezért megpróbálom röviden összefoglalni. A fő gondolata, hogy ha egy civilizált környéken betörik egy ablak (lehet autóé, házé), és senki nem foglalkozik vele – itt most nem arra gondolok, hogy aki betörte, annak bűntudata lesz tőle, de azt beleértem, hogy a javítás idejére bedeszkázzák, – akkor ez közepesen hosszú távon (akár néhány hónap alatt) az egész környéken a környék leromlásához, illetve a(z akár súlyosabb) bűnesetek számának növekedéséhez vezethet.

Ez a hatás nagyjából úgy keletkezhet, hogy az emberek azt látják, hogy más nem foglalkozik a problémákkal, ezért nem érzi úgy, hogy neki is tennie kell valamit. Ha valaki kételkedik az állítás igazságában, gondoljon bele, hogy hol szedne fel nagyobb eséllyel véletlenül elejtett papírzsebkendőt: a Nyugatinál a metróaluljáróban vagy egy öt csillagos hotelben a francia Riviérán.

Hogy ez hol jön a programozáshoz? Az elv ott is alkalmazható: ha nem foglalkozol a kis hibákkal, akkor aki később kapcsolódik, azt fogja látni, hogy az elődje sem gondoskodott róla, hogy elkerülje ezeket, ő sem fog vele foglalkozni (annyira). Aki dolgozott már ilyen kóddal, az tudja, miről beszélek. 🙂

Mik ezek a kis hibák? Warningok, hiányzó dokumentáció, nem kifinomult hibakezelés, gányolás… Lehetne még sorolni. És ezeket többnyire csak akkor lehet megfelelően kezelni, ha mindenki az első pillanattól fogva odafigyel ezekre, különben annyira elszaporodnak, hogy a kezelésük szinte reménytelen (próbált már valaki 1000-es nagyságrendben warningokat javítgatni?).

Jó, mi a teendő olyankor, amikor közeleg a határidőt, és még rengeteg mindent implementálni kell? Nos, ekkor jön a Brute Force Development: kódolunk, gányolunk, és reménykedünk, hogy működni fog. Gondolhatnánk, hogy ez rossz, de a gyakorlatban elkerülhetetlen. Ez nagyon gyakran „törött ablakokhoz” vezethet (nem, most kivételesen nem arról beszélek, hogy a legálisan beszerzett Windows-unk crackeltté válik 🙂 ).

Természetesen ez rossz, de mivel elkerülhetetlen, ezért kénytelenek vagyunk kezelni. Erre a kezelésre ad egy módszert a technológiai tartozás (Technical Debth) fogalma.

Ez a valós életbeli adósságok fogalmához kapcsolódik: felveszünk hitelt, hogy valami lehetőséget időben kihasználjunk (nem kell 20 évet várnunk egy lakásra, és közben albérletben élni, hanem most beköltözünk), de ez nincs ingyen (20 évig fizetjük a részletet). Akkor ne vegyünk fel hiteleket? De, ha van valami helyzet, amit így értelmesen kihasználhatunk, hosszabb távon pénzt spórolhatunk meg, akkor fel lehet venni, de ésszel. Nagyon oda kell figyelni a hitelek visszafizetésére (lásd még: válság 🙂 ).

A programozásban ehhez hasonlóan, ideiglenesen nem a legjobb, legügyesebb, legszebb megoldást választjuk, hanem rosszabb megoldást választunk, tákolunk, gányolunk. És mondjuk magunknak dokumentáljuk, hogy mik ezek a részek, és ezzel foglalkozni kell. Mi lehet ennek az értelme? Határidő, esetleg azt mondani, hogy ha működik, akkor kiadjuk, és utána belül foltozzuk a következő verzió fejlesztésének első lépéseként.

De természetesen itt is figyelni kell, ugyanis ha túl sok efféle dolgot hagyunk benne a rendszerben, akkor később ennek az lehet a következménye, hogy ahhoz, hogy új funkciót adjunk hozzá, nagyságrendekkel több munkát kell befektetni, mint az ideális lenne.

Saját tapasztalataim alapján is igazolni tudom ezt az elvet: az elmúlt héten a saját kódomat próbáltam nagyságrendekkel javítani, hogy új funkciókat adjak hozzá. Ok, vettem a fáradtságot, hogy +20% munkával javítsam azt, amit a TDK előtt BFD-vel befejeztem (visszafizettem a technológiai tartozás egy részét), annak érdekében, hogy a rendszer jobban használható legyen.

Remélem, hasznos/érdekes, amit most felvetettem, ha másnak van véleménye, kiegészítése, nagyon szívesen veszem bármilyen formában, más tapasztalataiból tanulni igenis jó dolog. 🙂

Jelenlét-érzékelés infravörös fény segítségével

Végre hosszú idő után előkerült a PICkit a fiókból. Az [intlink id=”559″ type=”post”]el%u0151z%u0151 PIC[/intlink]-es próbálkozásom után most egy kicsit bonyolultabb probléma megoldására vállalkoztam. Konkrétan arra, hogy a kütyü képes legyen érzékelni valakinek a jelenlétét. Erre a leggyakrabban alkalmazott módszer infravörös fényt vetít a vizsgált térrész felé, és méri a visszaverődött fény mennyiségét. Minél több fény verődik vissza, annál közelebb van a tárgy, amiről visszaverődött. Az elmélet egyszerű, és mint azt a továbbiakban olvashatjátok, a gyakorlat se sokkal bonyolultabb.

Az első probléma ami felmerült, az a jelentős háttérzaj kérdése. Az infravörös tartományban a nap és a legtöbb mesterséges fényforrás is sugároz, ráadásul sokkal erősebben, mint egy ilyen alkalmazásban szóba jöhető infra-led. A háttérzaj és az infra-led jelét szétválasztani csak úgy lehet, ha modulált jelet sugározunk a térbe, és ezt a modulált jelet keressük a mért értékekben is. Léteznek olyan infra-vevők, melyek hardveresen támogatják a modulált jel érzékelését (pl. TSOP), de hasonló alkatrészt tucatnyi boltot körbejárva sem találtam (ha tud valaki olyan boltot, ahol vásárolható ilyen, kérem írjon). Ilyen célezköz hiányában a modulációt szoftveresen oldottam meg.

A szoftveres moduláció miatt a hardver rendkívül egyszerű lett, a következő alkatrészekre volt szükségem:

  • Pic16F690
  • 1db infra led
  • 1db fotodióda
  • 1db npn tranzisztor
  • 4db 1kOhm ellenállás
  • 2db vörös led (egy a bekapcsolt állapotot jelzi – folyton világít, egy pedig a végeredményt adja meg, hogy érzékel-e jelenlétet az eszköz)

A munkát minimalizálandó felhasználtam a programozóhoz adott próbapanelt, amin beépített ledek állnak rendelkezésre, ezeket felhasználtam az állapotjelzések számára, így csak a fotódiódát és az infraledet kell hozzákötni, ami egy breadboard segítségével könnyedén kivitelezhető. Az infra-ledet a PIC rc0 kimenete fogja meghajtani, egy ellenállással bekötve ez a rész készen van. A kimenetet jelző led az rc1, a power-led az rc2-re van kötve hasonló módon. A fotódiódát a tranzisztorral erősítve kötjük a beépített A/D konverter bemenetére, hogy erősebb jelet kapjunk, ezzel megnövelve az érzékelés felbontását. A további félreértések rövidre zárásához felraktam egy kapcsolási rajzot:

pdetector.png

A szoftver ezzel a következő módon tud együttműködni: az alapötlet az, hogy kikapcsolt infra-leddel lemérjük a bejövő fény mennyiségét, majd bekapcsoljuk az infrát, és újra mérünk. A bekapcsolt illetve kikapcsolt infra-led melletti mérések különbsége adja meg az infra-led által leadott és visszavert fény mennyiségét. Ha ez a különbség több iteráció után is meghaladja a küszöbértéket, akkor a kimeneten jelezzük az érzékelt jelenlétet. Azaz két paraméter a küszöbérték (mekkora különbséget várunk el kikapcsolt és bekapcsolt infra-led melletti mérések között), és a kitartás (hány iteráción át kell tartani ezt a különbséget).

És íme, a kód. A dolog nehézségét jelzi, hogy a legtöbb időt két érték összehasonlítása vette el. A kódban szereplő makrót a Microchip MPasm leírásából vettem, én egy kétszer olyan hosszú megoldást csináltam elötte.


#include __config (_INTRC_OSC_NOCLKOUT & _WDT_OFF & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _BOR_OFF &
_IESO_OFF & _FCMEN_OFF)

;presence detector code.
;assumed peripheres:
; infra-led on RC0
; photo-diode connected to AN0
; detected proximity output on RC1
; power led on RC2
;
;we measure input on photo diode, while infra-led is turned off.
;then we measure again with turned on infra-led.
;if the infra-ray is reflected from anything, the second measurement
;should return a higher value

;=================================================
;========VARIABLES================================
;=================================================

cblock 0x20
offmeasure ;stores measurement without infra led
onmeasure ;stores measurement with infra led
output ;output bits
waitcount ;wait count
surecount ;make sure that something is there and not moves
endc

OUT_ILED EQU H’0000′ ;bit for infra led
OUT_RES EQU H’0001′ ;bit for output
OUT_POWER EQU H’0002′ ;power led

THRESHOLD EQU H’0002′ ;threshold for measurment gain

SURENESS EQU H’000C’ ;number of measurements before we’re sure in the result

;===================================================
;==============macros for selecting banks
;====================================================
SELECT_BANK0 macro
bcf STATUS,RP0
bcf STATUS,RP1
endm

SELECT_BANK1 macro
bsf STATUS,RP0
bcf STATUS,RP1
endm

SELECT_BANK2 macro
bcf STATUS,RP0
bsf STATUS,RP1
endm

SELECT_BANK3 macro
bsf STATUS,RP0
bsf STATUS,RP1
endm

;==============================================
;=====MACRO TO WAIT=============================
;==============================================

WAIT macro us
local a = 0
while a < us
nop
a += 1
endw
endm

;============================================
;========EXECUTE A MEASUREMENT===============
;============================================

MEASURE macro
WAIT 5
bsf ADCON0,GO ; start conversion
btfsc ADCON0,GO ; this bit will change to zero when the conversion is complete
goto $-1

movf ADRESH,w

btfsc output,OUT_ILED
goto $+3
movwf onmeasure
goto $+2
movwf offmeasure
nop
endm

;========================================
;=======SWITCH output led================
;========================================

SWITCH_ILED macro
movlw 0x01
xorwf output,F
endm

;========================================
;========REFRESH OUTPUT==================
;========================================

REFRESH_OUTPUT macro
movfw output
movwf PORTC
endm

;======================================================
; compare file to constant and jump if file
; >= constant.
;======================================================
cfl_jge macro file, con, jump_to
movlw con & 0xff
subwf file, w
btfsc STATUS, C
goto jump_to
endm

;===============================================
;==============MAIN PROGRAM=====================
;===============================================
org 0
Init:
;set variables to zero
movlw 0x00
movwf output
movwf onmeasure
movwf offmeasure

;set powerled on
bsf output,OUT_POWER

;initialize devices
SELECT_BANK1
movlw 0xFF
movwf TRISA ; Make PortA all input
clrf TRISC ; Make PortC all output
movlw 0x10 ; A2D Clock Fosc/8
movwf ADCON1
SELECT_BANK2
movlw 0xFF ; we want all Port A pins Analoge
movwf ANSEL
SELECT_BANK0
movlw 0x01
movwf ADCON0 ; configure A2D for Channel 0 (RA0), Left justified, and turn on the A2D module

Loop:
MEASURE ;measure with light off
SWITCH_ILED ;turn light on
REFRESH_OUTPUT
call SubWait ;wait a bit

MEASURE ;measure with light on
SWITCH_ILED ;turn light off
call DecideOutput ;decide output
REFRESH_OUTPUT
call SubWait ;wait a bit
goto Loop

;==============================================
;=====Decide output============================
;==============================================
DecideOutput:
;onmeasure-offmeasure >= threshold
movfw offmeasure
subwf onmeasure,F
cfl_jge onmeasure,THRESHOLD,DecideYes
goto DecideNo
DecideYes:
;bsf output,OUT_RES
incf surecount,F
goto DecideOutputReturn
DecideNo:
clrf surecount
bcf output,OUT_RES
DecideOutputReturn:
cfl_jge surecount,SURENESS, SwitchOn
goto SwitchOff
SwitchOn:
bsf output, OUT_RES
return
SwitchOff:
bcf output, OUT_RES
return

;===========================================
;===========Subroutine for long wait========
;===========================================
SubWait:
movlw 0xFF
movwf waitcount
StartWait:
WAIT 100
decfsz waitcount,F
goto StartWait
return

;===============================================
;=====PROGRAM END===============================
;===============================================
end

A kütyüt felprogramoztam, a perifériákat megépítettem, és pár iteratív hibajavítás/paraméterfinomítás után eljutottam arra az állapotra, amit elégségesnek neveztem a koncepció működésének a bizonyítására.

dscf1957_small.jpeg

A fenti köntörfalas megfogalmazás nem költői önkifejezés, és nem is véletlen. Az eszköz működik, de épp hogy. A környezet által kifejtett fényerő fehérzajként adódik a rendszerhez, és csak magas “kitartás” és “küszöbérték” paraméter mellett lehet kiszűrni a téves jelzéseket. Ennek az az eredménye, hogy kb. két másodperc után jelzi ha 5cm-nél közelebb teszem a kezemet az infra-led+fotódióda pároshoz. 10cm-nél már bizonytalan a mérés, és akkor is előfordul egy-egy téves jelzés, ha nincs semmi a közelben.

Ezen problémák orvoslására több ötletem is van, egy részük azonnal megoldódna, ha találnék egy rendes infra adó-vevőt. Persze ötleteket, javaslatokat, hasonló problémákban szerzett tapasztalatokat szívesen fogadok.

http://ww1.microchip.com/downloads/en/DeviceDoc/33014g.pdf

Színbeállítások Eclipse-ben – javított megoldás

Ahogy tegnap is írtam, [intlink id=”623″ type=”post”]Eclipse-hez beállító ablakokat[/intlink] könnyen lehet készíteni. De ez még mindig bonyolultabb, mint az optimum, ha csak színeket (és esetleg betűtípusokat) akar az ember beállíthatóvá tenni.

Hogy miért is mondom ezt? Azért, mert így teljesen úgy beállításlapot kell csinálni, amikor az Eclipse már tartalmaz egy színbeállítással foglalkozó oldalt (General/Appearance/Colors and Fonts). És ha az ember jobban megnézi, akkor itt bizony jó néhány olyan beállítás is szerepel, ami semmilyen hivatalos Eclipse csomagban nincs benne, innen kezdve adódik a következtetés: kiterjeszthető. 🙂

És valóban: az [cci]org.eclipse.ui.themes[/cci] kiterjesztési pont az, amit mi keresünk. Ami lényeges előrelépés az általános beállításpanelhez képest, hogy itt a beállításokat mindössze a plugin.xml megfelelő kitöltésével megoldhatjuk, és ez rögtön legenerálja a megfelelő felhasználói felületet. Lustaság fél egészség.:D

De a lényeg az egészben, hogy ez oda kerül, ahol a többi hasonló beállítás van, ezért talán a felhasználó is könnyebben megtalálhatja (nem szabad elfelejteni, hogy az Eclipse környezetnek a célközönsége nem a mezei felhasználó, hanem annál hozzáértőbbek, legalább poweruser-ek, de egyelőre még inkább programozók, így megengedhető, hogy az összes beállítás így jelenjen meg).

A kiterjesztéshez definiálhatok különböző paramétereket: ami az én esetemben lényeges volt, az a [cci]themeElementCategory[/cci] és a [cci]colorDefinition[/cci] attribútumok: az előbbivel egy kategóriát definiálhatok, míg a másodikkal színeket (a betűtípusok definiálásához a [cci]fontDefinition[/cci] attribútumot lehet használni, hasonlóan a colorDefinitionhöz).

A színekhez meg lehet adni egy alapértelmezett színt (nem kódban, hanem az XML-ben), ezt a value elemhez érdemes tenni, egy színazonosítót (a későbbi hivatkozáshoz), valamint egy categoryId-t (itt lehet megadni a korábban definiált kategóriát). A plugin.xml grafikus szerkesztőjén teljesen magától értetődő a kezelés.

A kategóriának meg egy Id-t és egy feliratot kell megadni.

Ha ezeket az elemeket megadtuk, akkor már késznek is tekinthető a beállítási felület, és nincs más hátra, minthogy a kódból elérjük a színeket. Ez hasonló bonyolultsággal, de kicsit eltérő kóddal kezelhető, mint a beállítások esetén. Kicsit konkrétabban:
[cc_java]IThemeManager themeManager = PlatformUI.getWorkbench()
.getThemeManager();
ITheme theme = themeManager.getCurrentTheme();
ColorRegistry colorRegistry = theme.getColorRegistry();
ENTITY_BG = colorRegistry
.get(“org.eclipse.viatra2.visualisation.entity.background”);[/cc_java]

Betűtípus lekéréséhez pedig a getFontRegistry hívással kell a témától elkérni a betűtípus-tárat, és annak a get metódusával a betűtípusokat lehet megkapni. Az így megkapott Color, ill. Font objektumokat nem kell felszabadítani, ezt a rendszer elvégzi helyettünk.

Ennyi munkával már össze lehet rakni egy jól működő beállításablakot, ezt képekkel illusztrálva a következő oldalon is lehet látni (angol nyelven): http://blog.eclipse-tips.com/2008/08/adding-color-and-font-preferences.html. Így ennyit se nagyon kellett volna írni, de egy aprósággal ezt is kiegészítettem még: a kiterjesztés megengedi, hogy egy előnézetet hozzak létre az így elkészült beállítási ablakhoz. Hogy megmutassam, ezzel mire gondolok, megmutatom az elkészült panelt.

Az elkészült színbeállítóablak grafikus képe
Az elkészült színbeállítóablak grafikus képe

Röviden: összerakhatok egy tetszőleges SWT formot, ami megjeleníti a beállítások eredményét. Ehhez a kategória class nevű attribútumát kell beállítani egy általunk létrehozott osztályra. Az interfész két metódus megvalósítását követeli meg: egy [cci]createControl[/cci] és egy [cci]dispose[/cci] metódust. A megvalósítás magától értetődő(nek tűnik): a createControl mindig meghívódna, amikor a beállítások módosulnak.

De sajnos nem. Az csak egyszer hívódik meg. Ezért a [cci]createControl[/cci] futása során fel kell iratkoznunk a téma változásaira az [cci]addPropertyChangeListener[/cci] metódus segítségével, és amikor ott befut az eredmény, akkor frissíteni kell az előnézetet.

Az előnézetet tényleg tetszőleges módon meg lehet valósítani, én például simán hozzácsaptam egy Zest Graph Viewert, és azt paramétereztem fel némi “dummy” adattal, és az eredmény a fenti képen látható (és a gyakorlatban tényleg azonnal frissül 🙂 ).

Ez az kiterjesztés láthatóan arra van kihegyezve, hogy egységes módon lehessen színbeállításokat tenni, és ennek a legjobb módja, hogy ne adjuk ki a kódot a kiterjesztő kezébe, hanem csak lehetőséget adjunk a felparaméterezésre. Ugyanakkor ez kellően rugalmasan sikerült megoldani, és a dokumentáció alapján tényleg magától értetődő a kitöltés. De nem szabad elfelejteni, hogy ez nem egy teljes körű megoldás, például vonalvastagságot vagy vonaltípust itt beállítani nem lehet, noha grafikus pluginek témabeállításaihoz ez is hozzátartozik.

Eclipse Preference Page készítésről röviden

A héten egy „egyszerű” problémát kellett megoldanom: egy Eclipse-pluginhoz konfigurációs lehetőségként kellett lehetővé tennem színek kiválasztását. Elhangzott ötletnek, hogy csináljak akár Java properties fájlokat vagy valami hasonlót (értsd: kódold le kézzel), de ha már Eclipse házinak készül a dolog, inkább úgy döntöttem, nézzük meg, hogy az Eclipse mit kínál.

Egyik természetes megoldásnak tűnik egy saját Property page létrehozása, amin be lehet állítani a megfelelő színeket. Ehhez kiderült (némi keresgélés után, ez tényleg gyorsan megvan), hogy az org.eclipse.ui.PreferencePages kiterjesztési ponthoz kell kapcsolódni. És még további próbálkozás után kiderül, hogy érdemes legeneráltatni a mintát az Eclipse-ből, mert lényegesen okosabb kódot rak össze, mint ami az interfész naiv implementációjából kijönne. De erről egy kicsit később.

Az extension point igényli, hogy megadjuk, milyen névvel illetve milyen másik Page alá szeretnénk betenni az új lapunkat, ami lehetővé teszi a kényelmes hierarchikus beállításszervezés összeállítását. Nice.

Ami meglepően egyszerűvé teszi az oldal tervezését, hogy a JFace API tartalmaz beépített FieldEditor osztályokat, így a beállítások lap tervezéséhez egyszerűen annyira van szükség, hogy ezeket (esetleges SWT konténerekkel együtt) kidobálok egy API-tól kapott konténerre. Triviális. És ami még fontosabb, egy percig sem kell azzal szórakoznom, hogy mikor/hogyan mentsem ki az adatokat a háttértárra, hogyan olvassam ki a mezőkből, mert ezt automatikusan elvégzi a rendszer. Nekem csak minden egyes mezőhöz egy azonosítót kell rendelnem, és a többi már gyorsan megy. Ha valami speciális feltételek vannak a kitöltéshez, ahhoz pedig a legtöbb komponens validator hozzátételével működik – ezzel az egyszerű struktúrával a legtöbb gyakorlatban előforduló eset kezelhető (szerintem).

A FieldEditor osztályok nagyon könnyen kezelhetőek: van köztük színválasztó, fontválasztó, egyszerű szöveges beviteli mező, checkbox, könyvtárválasztó és még sok minden más, egyszóval a gyakorlatban előkerülő legtöbb igényt le lehet fedni velük. És ami igazán fontos: ezek a megfelelő natív dialógusokat hívják be (pl. OSX-en a natív színválasztót, nem valami Javaból összetákolt valamit…).

A generált mintakód igazából három fájlból áll: a PreferenceConstants.java fájlban konstansokat lehet felvenni, amellyel később azonosíthatjuk az elmentett adatokat, a PreferenceInitializer.java fájlban a kezdőértékeket, míg az általunk választott nevű harmadik fájlban lehet összerakni a tényleges adatokat. Ezeket a fájlokat tovább nem is elemezném, ha valakit jobban érdekel, nézze meg, ennyi ismerettel könnyen érthető és módosítható igény szerint. Vagy meg lehet nézni a http://www.eclipsepluginsite.com/preference-pages.html oldalon a részletesebb kifejtést.

Inkább csak azt írom le, hogy ebbe hogyan lehet betenni a színkezelést (amit nem ír le az eredeti forrás). A form összerakásakor egyszerűen ColorFieldEditor-t kell létrehozni, hasonló paraméterezéssel, mint a mintában, míg az inicializálásnál a következő módon lehet gondolkodni:
PreferenceConverter.setDefault(store, PreferenceConstants.P_ENTITY_BG_COLOR, new RGB(216,226,248));

Azaz egy RGB értéket példányosítok, és ezt töltöm be alapértelmezésként. Ettől a pillanattól kezdve van egy kész színbeállító komponensem, menti is az adatait. Zsír. Akkor már csak egyszerűen be kell tudni olvasni. Szerencsére ez sem túl bonyolult. Ha egyszerűen Stringként akarom beolvasni a beállítást, és a stringet átadni a Color konstruktornak, akkor a következő kód jöhet számításba:
IPreferenceStore store = RmpPlugin.getDefault()
.getPreferenceStore();
String colorCode = store.getString(PreferenceConstants.P_ENTITY_BG_COLOR);

De lehet egyszerűbben is: a JFace tartalmaz egy PreferenceConvertert, aminek segítségével ez még egyszerűbben elintézhető.
RGB color = PreferenceConverter.getColor(store, PreferenceConstants.P_ENTITY_BG_COLOR);

Röviden összefoglalva ez is egy kényelmesen használható API, jól illeszkedik az Eclipse filozófiájába, aminek az az előnye, hogy gyorsan megtanulható, ráadásul kellően rugalmas is. Az előre megírt FieldEditorok pedig tényleg egyszerűvé teszik az egységes (ráadásul ugyanakkor platformfüggő!) kinézet összerakását a beállítópanelen is.

Ugyanakkor a végleges megoldásom nem ezt a menetet követi, helyette egy másik beépített megoldást használtam, de arról majd inkább legközelebb írok egy kicsit.

Debug vizualizáció Eclipse-hez

Kicsit féltem a feladattól, mikor Stampie előállt az ötletével, hogy mit adjak be házi feladatnak Nyilt Fejlesztőrendszerekre. Sőt, akkor ő is csak viccelt vele. Akkor egyikünk se gondolta volna, hogy ennyire jól fog elsülni. A néhány hetes projekt eredménye egy eclipse nézet, ami a debug folyamatban az aktuálisan elérhető változókat jeleníti meg egy gráfban. Ehhez a [[http://www.eclipse.org/gef/zest/|Zest]] keretrendszert használtam, ami egy az egyben megoldja a gráf megjelenítését, és keretrendszert ad a csomópontok automatikus elrendezéséhez. A feladat innentől csak annyi, hogy összekanalazzuk a debug folyamatból az adatokat és a megfelelő formában beleszórjuk egy Zest megjelenítőbe.

Kicsit féltem a feladattól, mikor Stampie előállt az ötletével, hogy mit adjak be házi feladatnak Nyilt Fejlesztőrendszerekre. Sőt, akkor ő is csak viccelt vele. Akkor egyikünk se gondolta volna, hogy ennyire jól fog elsülni. A néhány hetes projekt eredménye egy eclipse nézet, ami a debug folyamatban az aktuálisan elérhető változókat jeleníti meg egy gráfban. Ehhez a Zest keretrendszert használtam, ami egy az egyben megoldja a gráf megjelenítését, és keretrendszert ad a csomópontok automatikus elrendezéséhez. A feladat innentől csak annyi, hogy összekanalazzuk a debug folyamatból az adatokat és a megfelelő formában beleszórjuk egy Zest megjelenítőbe.

Sokáig nem tudtam hogy álljak neki, hetekig bogarásztam az eclipse forrását, mire megtaláltam hogyan is juthatok hozzá a megfelelő adatokhoz. A megoldás végül is egyszerűnek bizonyult. Eclipse-ben a debug folyamat diszkrét lépésekre oszlik, mint például indítás, breakpointhoz érkezés, léptetés, folyamat befejezése, stb.. Minden lépés végén triggerelődik egy esemény a folyamat állásáról, ezt kell figyelni:

[cc_java]
public class DebugContextListener implements IDebugContextListener {

public void debugContextChanged(DebugContextEvent event) {
if ((event.getFlags() & DebugContextEvent.ACTIVATED) > 0) {
contextActivated(event.getContext());
}
}

private void contextActivated(ISelection context) {
if (context instanceof StructuredSelection){
Object data = ((StructuredSelection) context).getFirstElement();
if (data instanceof IStackFrame) {
//itt megkaptuk a StackFrame-et
}else{
//véget ért a debug folyamat
}
}
}

}
[/cc_java]
A Listener-t a következő módon tudjuk beregisztrálni a rendszerbe:

[cc_java]
DebugUITools.getDebugContextManager().addDebugContextListener(new DebugContextListener(this));
[/cc_java]

A fent látható módon várhatunk a debug állapotot reprezentáló IStackFrame adatstruktúrára. A struktúra többek között tartalmazza a Variables nézetben is látható változókat. Ezeket a változókat akarjuk megjeleníteni. Érdemes leszögezni, hogy ebben a kontextusban a változók (IVariable) csak referenciák a tényleges adatokra (IValue). Tehát az értékek felelnek meg a csomópontoknak, míg a változók az éleknek. Ez alapján már igazán gyerekjáték volt az adatokat bedobálni egy Graph-ba (persze elöbb érdemes felépíteni egy modellt, amin megjelenítés elött elrendezhetünk pár hasznos műveletet, mint a gráf “lusta” megjelenítése, vagy a csomópontok szűrése). Ami további nehézséget okozott, az a Zest kritikán aluli dokumentáltsága, így többnyire csak próbálgatásokkal sikerült megértenem a működését.

Lényeg a lényegben, hogy ma (azaz már tegnap) elfogadták házi feladatként, és így terv szerint pár apró csiszolással kiadtam a 0.5.0 verziót. A projektnek létrehoztam egy oldalt a Google Code-on, onnan leszedhető a forrás is, egy telepíthető bináris csomag és további információk a projektről. Végezetűl egy kis felsorolás arról, hogy mit is tud a cucc, azaz fícsörz:

  • Változók és referenciék gráf alapú megjelenítése, a gráf automatikus elrendezése választható algoritmus alapján
  • A gráf lusta módon van megjelenítve, az egyes csomópontok gyermek-csomópontjai csak akkor jelennek meg, ha a felhasználó dupla kattintással kinyitja a csomópontot. A csomópontok hasonló módon be is zárhatóak
  • A gráf-rendező algoritmusok extension-point-on csatlakoznak a nézethez, ami lehetővé teszi, hogy bárki hozzácsatoljon egy saját, Zest-tel kompatibilis algoritmust.
  • A Zest-ben beépítetteken kívül csináltam egy szimulált hűtésen alapuló algoritmust is, ami ugyan lassú, de az esetek nagy hányadában jobb elrendezést biztosít, mint a többi.
  • Típusfüggő szűrést végzek a csomópontokon, így pl. egy ArrayList-nél csak a releváns gyermekelemek (A listában tárolt elemek) jelennek meg.
  • Természetesen a szűrők is extension-point-tal vannak csatlakoztatva, hogy ezen a ponton is tetszőlegesen kiegészíthető a cucc.

Még néhány link: