Először is szeretném leszögezni, hogy nem az OpenOffice fejlesztőinek munkája az egér, hanem az egeret készítő cég készített nyílt forrású, OpenOffice-t támogató drivert a cucchoz. Ezt azért éreztem fontosnak, mert ugyan az OpenOffice nem az ergonomikus szoftvertervezés csúcsa, de ez messze alulmúlja azt a szintet.

A leírás első körben bizalomgerjesztő: sok gomb (18), külön joystick az egéren, különböző módok, és mindez szoftveresen testreszabható.

Viszont ezután jött a fotó az egérről: a gombok az egér tetején helyezkednek el, rács mentén elhelyezve. Mi is ezzel a gondom?

Egy egyszerű, fehér egér 18 gombbal, görgővel és joystickkel

Egyrészt a gombok mérete feltehetőleg viszonylag kicsi: a görgő két oldalán 3-3 oszlopnyi gomb van (és gyk. 3-3 sornyi is). Ha ennyi a gomb, akkor hogyan oldják meg, hogy nehéz legyen mellényúlni?

A másik fő problémám az, ami miatt a távirányítón is megszüntették a rács szervezést: ha sok a gomb, akkor jobb, ha a gyakran használt gombok egyedi formájúak, és nagyok, mert akkor anélkül tud a felhasználó választani, hogy odapillanata, merre van (igen, a billentyűzetek “f” és “j” gombjain levő jelzés – tipikusan kidomborodás vagy bemélyedés is erre való – ezek segítségével az ember tudja, hogy hol van az ujja).

Ha megnézzük, a joystick helye is érdekes: a hüvelykujjnál, egy gomb(!) mellett. Jó kérdés, hogy ez a kilógó elem mennyire piszkálja az ujjamat, amivel az egeret kell irányítanom, illetve mennyire könnyen tudom véletlenül megnyomni. A mellette levő gomb meg érzésre teljesen használhatatlan – nem férek hozzá.

Mielőtt valaki megvádolna, hogy Apple-fanként csak egygombos egérrel boldogulok, kijelentem, hogy volt dolgom többgombos egérrel – olyan 5-6 gombig. Alapvetően nem volt gondom vele, eltekintve attól, hogy a 4-5-6. gombokat nagyon ritkán sikerült kihasználni. A tapasztalatom az, hogy a bal gomb, jobb gomb, görgő (aminek lenyomása lehet a harmadik gomb) triónál többet nagyon kevés alkalmazás támogat, és viszonylag kellemetlen is használni. Az egyetlen, aminek látnám értelmét, az 1D mozgást leíró görgő helyett valami 2D-s eszközt betenni (mint az Apple Mighty Mouse eszközében a golyó – most már Magic Mouse).

És ami a legszebb, az ára: $74.99. Vezetékkel. Ezzel szemben az Apple új, vezeték nélküli, érintőfelületű egere $69. Amit szintén sokallok azért az egérért… De ez már az én egyéni, szociális problémám.

Amikor a múltkor felhasználói felületekről írtam, akkor is hasonló mennyiségű kritikát írtam – de szemben azzal ez a kritika határozottan negatív.

Összességében: az egér elképesztően bonyolult. Sok gomb, sok mód, sokféle operációs lehetőség. A szoftverét nem láttam, az lehet, hogy a legkirályabb cucc a szeletelt kenyér óta, de a hardverről egy képet látva nagyon nem bizakodom.

Körkérdés: kedves olvasók, ti látjátok értelmét ennek a 18 gombos egérnek?

Mondjuk ha csak annyi lenne a véleményem róla, hogy érdemes elolvasni, akkor egyszerűen fognám magam, és én is feltenném a deliciousre, hogy az a kevés ember, aki véletlenül odatéved, megtalálja. De a helyzet az, hogy egyfelől érdekesnek tartom, másrészt nem értek vele (mindenben) egyet.

Ami feltétlenül tetszett az írásban, és ami miatt minden, programozásban érintett embernek ajánlom elolvasásra, hogy konkrét példán bemutatja a különböző programfejlesztési elveket. Ráadásul mosóporreklám stílusban, azaz ilyen volt és ilyen lett összehasonlítással.

Előrebocsátanám még (egyszer), mielőtt elkezdek belemenni egyes részletkérdésekbe, hogy a cikkel alapvetően egyetértek, de néhány dolog érdemes továbbgondolásra. Az egyik, hogy ezeket a tervezési elveket szabálynak állítja be, szerintem viszont legfeljebb ökölszabálynak lehet tekinteni. Azaz alapvetően érdemes követni őket, kivéve, ha nem jók az adott helyzetben.

Miért lehetnek rosszak ezek az elvek? Például ha minden egyes funkciót külön osztályba teszünk, az osztályok, interfészek száma könnyen kezelhetetlen méretűre duzzadhat. Szóval amit megnyerünk a réven (áttekinthetőbbek és szerkeszthetőbbek a lokális kódok), elveszíthetjük a vámon (struktrurálisan nehezen áttekinthető a rendszer, nagy a betanulási idő).

Emellett a sok indirekció és absztrakciós szint teljesítményproblémákhoz vezethet. Például egy hívásnak nem elhanyagolható költségei vannak (stackelés, stb.). Vagy éppen hivatkozhatnék arra a nem túl régi tapasztalatomra, hogy egy algoritmusnál a legtöbb időt az vitte el, hogy a memóriából ismételten lekért adatokat. Ezt profilerrel derítettem ki, és lokális változóba áttöltve az adatokat és újra felhasználva kb. felére csökkentettem a futási időt. Vicces dolog az a cache miss (legalábbis szerintem ez történhetett).

És a legkomolyabb, kimutatható probléma (szerintem): a “tell, don’t ask” elvet jelenleg piszkosul nem szokás adatmodellre alkalmazni. Legalábbis Java környékén az aktuális state of the art marhára nem teszi – kivéve, ha rosszul látom, hogy mi a legfejlettebb. Aminek akár még oka is lehet.

A “tell, don’t ask” elv mit is jelent? Mondd meg az objektumnak, hogy mit csináljon (állapotfüggően), ne lekérd az állapotát, és ez alapján te döntsél helyette.

Érdekes módon viszont az adatmodellek manapság egyre inkább mennek a nagyon buta, csak getter/setterekből álló modellek felé. Miért is? Én úgy tippelem azért, mert

1. Ez a rész jól generálható. Az EMF alaptechnológia tipikusan arról szól, hogy valahogy összeklikkelgetsz egy EMF modellt, beállítod a genmodellt, és kapsz egy gyönyörűséges Java osztályhalmazt. Ami persze nem tud semmit azon túl, hogy getter, setter és factory hívásokkal felépíthető és bejárható.
2. J2EE technológiánál az entitásokat menti le a rendszer egy az egyben adatbázisba, amely entitásoknak tipikusan szintén getter/setter metódusai vannak. Esetleg még számított mezők is beköszönnek.

Mindkét esetben az a szokás, hogy a modellbefolyásoló logikát külön Manager jellegű osztályokba tesszük, akik a tényleges igényeknek megfelelően építik (rombolják ) a modellt.

És végül a legfontosabb hozzáfűznivalóm az íráshoz: igen, hosszú távon megéri ezeket az elveket követve tervezni, kivéve, ha amiatt, mert nem készülünk el határidőre, rövid/közepes távon befejeződik a projekt. És ennek a kezelése bizony emberi kérdés. Emiatt zárszóként Jeff Atwoodot idézném:

The guys and gals who show up every day eager to hone their craft, who are passionate about building stuff that matters to them, and perhaps in some small way, to the rest of the world — those are the people and projects that will ultimately succeed.

PS.: Mostanában Aadaam is foglalkozik azzal, hogyan érdemes nagyobb rendszereket összerakni. Ráadásul azt mutatja meg, hogyan lehet PHP-ban nem gányolni. Szép teljesítmény az is.

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.

Most viszont az egész véget ért, ideje számot vetni, értékelni, ami elkészült, és a tanulságokat levonni.

Számomra ez nagy projekt volt: 4 hónap kódolás, 1 hónap dolgozatírás, és mellé még ez-az kapcsolódott (pl. prezentáció készítése). A méretre jellemző még, hogy 5000 sor Java kódot írtam (ez nagyobb, mint bármilyen projekt, aminek a fejlesztésébe belefolytam, és a többi projektet ráadásul nem is egyedül kódoltam), valamint 61 oldal dokumentációt (szintén rekorder méret), ráadásul angolul.

Sokféle új dolgot próbáltam ki menet közben (vagy használtam nagyobb méretben, mint korábban): Eclipse alapú fejlesztés, kényszerkielégítés (CSP/CLP) vagy éppen nagy dokumentumok szerkesztése LaTeXben. És persze Java rulez:D

Ami kicsit fájdalmasabb rész, az a tanulságok levonása: sajnos sikerült a szükségesnél kicsit nagyobbat markolni, aminek az lett a vége, hogy a befejezés kicsit rohanós lett. Ráadásul bejött a szokásos problémák egyike, mármint sikerült belefutni egyes implementációs/elvi szintű problémákba, amik megkerülésére vannak ötletek, de azért még időt igényel.

Ráadásul a negyedik-ötödik hónapra a kezdeti lelkesedés is elfogyott, így a morál csökkent. Valószínűleg könnyebb lenne fenntartani a lelkesedést, ha lenne még egy ekkora állat, aki hajlandó a projekttel foglalkozni – különösebb ellentételezés nélkül – azzal sajnos nem tudok szolgálni, munka viszont van bőven… Persze álmodozni lehet.

Ami még hasonlóan fontos kérdés, hogy hasznos volt-e a befektetett energia. Na, ez az, ami jó kérdés: rövid távon kifejezetten nehéz aprópénzre váltani, amit összeszedtem (pláne, hogy a cucc még nem is 100%-os), de hosszabb távon remélhetőleg hasznosabb lesz: felhasználható diplomamunkába, esetleg cikkekhez, doktoranduszi kutatási téma alapja lehet, stb.

De legalább az a veszély nem fenyeget, hogy a projekt hirtelen véget ér. A hiányokat lehet pótolni, illetve néhány újdonságot is lehet csinálni. De addig is irány a régi grind…

Ja, és megpróbálok majd gyakrabban írni az oldalra. Tudom, ilyet már mondtam, de próbálkozni lehet. Mások újévkor fogadnak meg mindig olyan dolgot, amit nem tartanak meg, én ezért nem ígérek semmit senkinek – elég lesz magammal elszámolnom.

Update: amit elfelejtettem, az az, hogy szeretnék köszönetet mondani mindenkinek, aki bármilyen aprósággal hozzájárult a munkához, gondolok itt azokra is, akik nem szerepelnek a dokumentáció köszönetnyilvánításában. Tényleg mindenkinek nagyon hálás vagyok.

Arról a gyakran előforduló modellről van szó, amikor sorok és oszlopok metszeteiben rácselemek csücsülnek, melyek automatikusan létrejönnek a nekik megfelelő sor-oszlop párra való hivatkozáskor, valamint automatikusan megszűnnek soruk vagy oszlopuk törlése esetén.
A megvalósítás kézenfekvőnek tűnik: a sorokban/oszlopokban egy map-ben tároljuk az oszlopokkal/sorokkal indexelve a rácselemeket.

Valahogy így:

Mi a gond ezzel?

• Ha törlünk egy oszlopot, az összes sor map-jében még ott marad a rá mutató referencia, mint kulcs. Ez memory leakhez vezet: a szemétgyűjtő nem tudja eltakarítani a “zombi” oszlopokat és a hozzájuk tartozó, ugyancsak zombi rácselemeket. Ez ráadásul az adatstruktúra perzisztálásánál is problémát jelent.
• Hogyan s mikor hozzuk létre a rácselemeket? Mindig, amikor létrehozunk egy oszlopot? Ezt jobban lehetne automatizálni, ráadásul ha nem minden rácspontba akarunk elemet tenni, fölöslegesen hozzuk létre ezeket.

Több megoldás is lehetséges, gondolhatnánk elsőre:

• Gondolkodhatnánk egy címkézett gráfban, és a beépített kollekciók helyett alkalmazhatnánk valamiféle gráfkezelő könyvtárat, pl. a JGraphT-t, mely gondoskodik csúcs törlésekor a hozzá tartozó élekről.
• Kibővíthetnénk a lista adatszerkezetet eseménykezelőkkel, melyek elem hozzáadásakor és törlésekor végrehajtanak egy megadott kódot.

Azonban a probléma megoldható a Java Collections Framework keretein belül, karöltve természetes kiegészítőjével, a Collections Generic API-val (a Commons Collections generikus változata). Nehogy már egy ilyen általános jelenséget ne tudjunk a megannyi hasznos absztrakciót tartalmazó Java nyelv elemeivel modellezni! A kulcsfogalom a gyenge referencia, mellyel befolyásolhatjuk a garbage collector működését, ezzel rábízva az elárvult elemek törlését.

Javában az alapértelmezett referencia erős (strong), de ezenkívül még létezik a gyenge (weak), lágy (soft) és fantom (phantom) referencia. A weak reference lényege, hogy amennyiben egy objektumra csak ilyenek mutatnak, a szemétgyűjtő teljes lelki nyugalommal eltakarítja. Nekünk pont ez a viselkedés jön kapóra: a map-ben gyenge referenciákat fogunk csak tárolni az oszlopokra/sorokra. (A másik két típus most nem érdekes számunkra, pedig azok is hasznosnak bizonyulhatnak más esetekben.)

A Collections API tartalmazza a WeakHashMap osztályt, mely a HashMap-hez hasonló, azonban kulcsai gyenge referenciák. A WeakHashMap ezeket átlátszóan kezeli, önmagától létrehozva és dereferálva nekünk őket. Így programunkban az automatikus törléshez csak két dolgot kell módosítanunk: HashMap helyett WeakHashMap-et használunk, és a kívánt pillanatban meghívjuk a garbage collectort.

A létrehozás pedig lusta map segítségével történik: a rácselemek példányosítása akkor és csak akkor történik, amikor először hivatkozunk az őket azonosító sor-oszlop párosra. Ehhez is kész eszközt kapunk a kezükbe a Collections Generic Libraryben: a LazyMap-et és az InstantiateFactory-t, melyek a Decorator és a Factory pattern alkalmazásával érik el céljukat.

Imhol a forráskód módosított része. Figyelemreméltó, hogy mennyi minden változott…

És egy kis tesztosztály, a kiértékelés a kedves olvasó feladata:

Hát ilyen power a Collections Framework, amint már Stampie is rámutatott, ami pedig esetleg hiányzik belőle, azt a Collections Generic pótolja. Mi a tanulság? Használjuk ki a nyelvi lehetőségeket, amelyek rendelkezésünkre állnak!