Megint egy szakmai jellegu bejegyzes, mivel ilyen mar reg volt.

Egy ideje mar gondolkoztam a megfeleloen alkalmazott Listenerek elhelyezesen a kodban, ahelyett, hogy oda nem illo responsibility-t kezeljek a kodot teljesen elcsufito felteteles elagazasokkal. Ma reggel azonban a vonathoz setalva egy konkret pelda kapcsan egy – az eddiginel is otletesebb – megoldas jutott eszembe.

Eloszor, fejtsuk ki az alapproblemat. A MindGraph szandekaim szerint alkalmas lesz tobb, egyidejuleg megnyitott dokumentum kezelesere. Nyilvan lesz mindig egy aktiv, meg nehany masik a hatterben, amiket megfeleloen navigalva aktivva tudunk tenni, az aktualis aktivat passzivalva. Amikor “uresen” elinditjuk a MindGraph-et, letrehoz nekunk egy uj, ures dokumentumot. Mi tortenik azonban, ha ekkor betoltunk egy masik dokumentumot?

Szandekaim szerint ekkor az uj, ures dokumentum bezarodik, es a frissen betoltott dokumentum lesz az egyetlen megnyitott, aktiv darab. Ellenben, ha mar van egy megnyitott, nem ures dokumentumunk, es akkor toltunk be egy korabban lementettet, akkor nem akarjuk bezarni az elozot, csak passzivalni. Ergo, kepesnek kell lennunk arra, hogy megmondjuk, ez a dokumentum volt-e mar szerkesztve, vagy meg nem.

Az egyik lehetseges megoldas az, hogy fogjuk az aktualis aktiv dokumentumot, es megnezzuk, hogy van-e benne content. Ennek a megoldasnak tobb elonye is van, es siman lehet, hogy ezt valasztom, de azert kifejtem a masik megoldast is, ami eszembe jutott.

A programlogika, ami a scene-t modosithatja, be van csomagolva egy action osztalyba. Az osztalyoknak nyilvan egysegesitett interface-e van. A trukkos megoldas, amit kitalaltam, egy nagyon kulonleges wrapper osztaly.

A wrapper lenyege ugye az, hogy ugyanolyan interface-t biztosit, mint a becsomagolt osztaly, es annak is passzolja tovabb a fuggvenyhivasokat, csak ad hozza valami kis extra funkcionalitast. (van egy masikfele wrapper is, de en most erre gondolok)

Kitero: Ez kicsit olyan, mint egy peldanyra kihegyezett AOP, ahol a wrapperbe agyazott logika maga egy Aspect. De nyilvan az AOP ennel sokkal tobb, es nem veletlenul vannak teljes retegek kiemelve aspektusba.

Az en wrapper osztalyom egy dologban mas, mint a normalis: Az elso hivas utan “kicsomagolja” magat, azaz a logika vegrehajtasa utan kicsereli onmagat a becsomagolt osztalyra. Ezzel azt erjuk el, hogy a wrapperben hivott kod csak egyszer tud lefutni, es onnantol gyakorlatilag nem letezik a kodban, azaz nem is lassitja a futast.

Nyilvan kell egy kis trukkozes, hogy a sorrend megorzesevel ki tudjuk cserelni az akciot egy masikra, es nem is biztos, hogy szukseg van egy ennyire bonyolult kodra, hiszen ha egy sima feltetelvizsgalatot teszunk be helyette, a JIT alapu virtualis gep ugyis gondoskodni fog rola, hogy az elagazas megfelelo aga fusson, elhanyagolhato overhead-del. De azert erdemes elgondolkozni rajta, hogy milyen lehetosegek szuletnek egy ilyen megoldassal, hiszen az egesz programunk sokkal dinamikusabba valik. (hiszen nem csak onkicsomagolas lehet, hanem on-the-fly factory, meg onbecsomagolas, es hasonlok)

Ha lesz konkret kod ra, lehet, hogy bevagok par reszletet.

Az elmult esteken raszantam nemi idot, h reszelgessem meg a MindGraph-et. Ujfent megallapitottam, hogy a Visual Library egy csodalatos framework.. ha a gondolkozasod hasonlo, mint az alkotoke. Am amint valami usability jellegu valtozast akarsz csinalni – teszemazt atirni, hogy egy akcio ne duplakattintasra tortenjen, hanem mondjuk alt-shift-jobbgombra – kenytelen leszel fogni az o kodjukat, csinalni belole egy osztalyt, majd atirni benne, amit kell. Normalisan ezt oroklessel vagy dependency injectionnel, vagy konfiguracioval, vagy legalabb egy nyomorult factory osztallyal oldanad meg. Ehelyett kodot duplikalsz. Grrrr.

A jo hir viszont az, hogy a fenti problemak ellenere jol haladok, a felulet – par apro rondasagtol eltekintve – kb. azt tudja, amit a betahoz akarok, szoval ha a mentes-toltes megvan, akkor csinalok egy zart betat. Erdekel, hogy a felhasznalas logikaja es a felulet kepessegei mennyire lesznek erthetoek/elfogadhatoak masoknak.

Szoval aki betazni szeretne, irjon egy vonatkozo kommentet. Nem igerem, hogy mindenkinek lesz ra lehetosege – eloszor nem akarok 5-nel tobb embert igazabol – de a kesobbi teszteloi fazisokhoz is kellenek onkentesek.
Caveat: A kommentekhez olyan email cimet adjatok meg, amin el tudlak erni titeket..

Btw, most epp olyan tool-t keresek, amivel fel tudnek venni egy rovid kis bemutato videot. Nyilvan egy google keresessel lehet rengeteg ilyet talalni, de erdekelne, h van-e valakinek tapasztalata ilyen eszkozzel, illetve mit ajanlanatok.

A legutóbbi:

Az elmult napokban egy csomoszor dicsertem a MindGraph-et, meg irogattam rola itt a blogon, de azt meg nem magyaraztam el – ha jol emlexem – hogy mi is ez tulajdonkeppen.

Az alapotlet a Mind Mapping technika tovabbgondolasa. A Mind Mapping lenyege, hogy vizualizaljuk az otleteinket egy fastruktura szerint. Egy alapotletbol indulunk es szepen bontjuk lefele kisebb reszekre, leagazasokat huzva belole. Ket trivialis problema van ezzel a modszerrel:

• Az otletek mindig egy alapotletbol szarmaznak le, ezert annak meglehetosen altalanosnak kell lennie, ha mondjuk tobb, nem nagyon erosen kapcsolodo otletet szeretnenk kombinalni.
• Nem lehet kapcsolatot tobbszorozni az agak kozott, ezert ha egy dologra tobb helyen is hivatkozunk, duplikalnunk kell.

A mindgraph lenyege, hogy az egesz kapcsolatot graf alapokra helyezi, ezaltal egy demokratikus, tobbszorosen ide-oda kapcsolt otlethalmazt hozva letre.

A technikai reszletek utan nezzuk, hogy mire es hogyan tudjuk ezt hasznalni: Elsosorban a gondolataink gyors felvazolasa a cel. Lerakunk egy gondolatot, beleirjuk, hogy mi ez, majd hozzakotjuk a mar letezo gondolatokhoz, akar azt is specifikalva, hogy a kapcsolat micsoda. Ha mar rajzoltunk egy jo nagy terkepet, termeszetesen nem akarjuk azt sem elveszteni, szoval menthetunk es visszatolthetunk majd, illetve kepet is exportalhatunk. Ha egy otletet jobban ki akarunk fejteni, nehany verzio mulva arra is lesz lehetosegunk, hogy kifejto grafot rajzoljunk – ezt ugy kepzeljuk el, hogy rakattintunk egy dobozra, es felnyilik egy benne levo diagram.

Konkret alkalmazasok? Akarmi. En a programozassal kapcsolatos otleteimet szoktam ilyen modon lerajzolni, de siman el tudom kepzelni, hogy valaki csinal egy terkep alapu bevasarlolistat, es behuzogtja a kovetendo utat, vagy egy regeny cselekmenyet vazolja fel ilyen modon. A lenyeg ketretu: reszben az ihletett pillanat megragadasa, amikor elozonlenek bennunket a gondolatok, es hirtelen mindent le akarunk irni, masreszt az otletek/adatok es kapcsolataik vizualizalasa.

A design ennek megfeleloen nem a csicsara, hanem a nagyon egyszeru es gyors kezelhetosegre helyezi a hangsulyt. Emiatt helyenkent kenytelen vagyok elszakadni a gyakran optimalisnak tekintett windows-os kontrolloktol (a Mac-eseket meg nem is ismerem, szoval eselytelen, hogy kozel keruljek hozzajuk) es egyszerusiteni a dolgokat, peldaul a mar korabban emlitett torlesi problema: Az alap megoldas az lenne, hogy kijeloljuk es toroljuk, am a MindGraph-ben ez ugy fog tortenni, hogy fole visszuk az egeret (nem kattintunk) es megnyomjuk a torles gombot. Kesobb meg el fogok gondolkozni a csoportos kijeloles megvalositasan is, mert azert egy nagyobb szekciot egyessevel torolni keptelenseg.

Szoval ez a tool van most a satupadon. Ahogy reszelgetem, postolok majd meg kepeket.

Azért volt eredménye a ma esti programozásnak is.

Hover

Tegnap este elovettem kicsit a MindGraph-et, hogy reszelgessem. Az elozo verzio meg annyira buta volt, hogy torolni sem lehetett vele elemeket, ugyhogy ez volt a kovetkezo dolog, aminek nekilattam. Aranylag egyszeruen ment is a dolog, egy “aprosag” kivetelevel: A feltetelezesem, hogy a gombnyomasok (DEL) arra a widget-re mennek be, amin eppen az eger all, hibasnak bizonyult. Ez persze nagyjabol az egesz torlesi koncepciot felrugta, mivel most vagy lefejlesztek egy selection rendszert a torleshez, vagy maradok a lightweight rendszernel, es tenyleg azt torlom, ami az eger alatt van, de ez megzavarhatja a felhasznalokat. (noha hatekonysagat es leprogramozhatosagat tekintve siman veri a kijelolos megoldast).

A kovetkezo feladat meg nem tiszta, ketto kozul valaszthatok:

• Mentes/Betoltes rendszer: Erre egy eleg bonyolult rendszert tervezek, de egyelore vsz lefejlesztek egy egyszerut, aztan majd meghegesztem, amikor haladok a kesz verzio fele
• A kapcsolatok kirajzolasat ugy akarom megoldani, hogy ha a kapcsolatba kanyart akarunk rakni, akkor is ertelmesen kosse dobozokhoz a masik veget.

Az utobbi – bar csak szepseggel kapcsolatos dolognak tunik – valojaban eleg fontos, mert sokkal atlathatobba teszi az egeszet. Az elobbi fontossagat szerintem nem kell kifejtenem.

Amikor oda jutok, eldontom majd, hogy merre tovabb. A ma esti session utan rakok fel egy kepet is arrol, hogy hol jarok eppen – remelhetoleg lesz rajta valami latnivalo.

Eszembe jutott a minap egy jatekotlet, ami annyira megfogott, hogy nekialltam megtervezni a jatekot. Pontosabban, egy regebbi jatekotletem finomitasarol van szo. A jatek kifejezetten egyszeru, bonyolult grafikat, zenet nem igenyel, megis eleg szorakoztato. A Hiker cimet kapja, ha valaha elkeszul, es jo eselyt latok ra, hogy Android es/vagy Java ME lesz a platform.
A lenyeg azonban, amirol ez a post szol, nem a jatek. Amikor tervezni kezdtem, hamar belefutottam a szokasos issue-ba, miszerint rajzolni kene a terveket iras helyett. Es itt jott a kepbe a blogon mar korabban emlegetett, fel(ig se)kesz Mindgraph. Elovettem, elkezdtem felskiccelni, amit akartam, es egy perc alatt megallapitottam, hogy a Mindgraph egy nagyon jo tool, es mindenkeppen be kell fejeznem annak is a fejleszteset.
Szoval most eppen ketto darab futo petprojectem van nulla otthoni kodolas mellett. Hataridoket inkabb nem mondok.

Elgondolkoztam a minap azon, hogy hogyan kellene megoldani a “szovegdobozok automatikus elrendezese” funkciot. A feladat – mint azt mar rengeteg toolban lathattuk – nem trivialis. Reszben azert, mert mindenkinek masfele elrendezes a jo, reszben pedig azert, mert nehez szavakba onteni, hogy egy graf mitol “nez ki jol”.

Az elso megkozelitesem pusztan matematikai: megprobalom azokat a dobozokat kozepre hozni, amiknek sok kapcsolata van, es periferiara rakni azokat, amiknek keves. Mindezt azon feltetelezes alapjan, hogy sok kapcsolattal a fontos otletek rendelkeznek, es azokat megilleti a kozponti hely. A problema itt mindossze annyi, hogy a kesobbi boviteseknel siman van arra esely, hogy a fontos otletek tovabbi kapcsolatokat kapjanak, amihez viszont nem lesz eleg hely.

Elgondolkoztam azonban a jatekok AI-ahoz hasonlo, a felhasznalo viselkedeset figyelo es elemzo kodon is. Ez osszessegeben nyilvan hihetetlenul bonyolult, de aranylag konnyen ki lehet olyasmit deriteni, hogy az uj elemek letrahozasakor milyen tavol helyezi a felhasznalo az ujat a meglevoktol, valamint olyanokat is, hogy elre igazitva szereti a dolgokat, vagy csak ugy szethanyva, egymastol fuggetlenul. Egy erdekes gondolat ennek kapcsan, hogy ezt az extra infot le is kellene menteni a graf melle, amikor a felhasznalo menti azt, hiszen egyebkent ket szerkesztes kozott elveszne a history.. Ami viszont egybol elvezet a tobb felhasznalo altal mahinalt grafokhoz..

De eloszor is baby steps. Addig ugyse lesz szukseg erre a funkciora, amig nincs egy mukodo alkalmazas, mondjuk a v0.4.

Elgondolkoztam a minap, hogy hogyan nezzen ki a Mindgraph logikai modellje. Aztan arra a kovetkeztetesre jutottam, hogy gyakorlatilag nincs ra szukseg, ugyanis kizarolag duplikaciot tartalmaz. Minden adat es kapcsolat megtalalhato a vizualis modellben.

Szoval egyelore ugy tunik, meg annal is vekonyabb lesz az alkalmazas, mint vartam. Persze lehet, hogy idovel majd rajovok, hogy szuksegem van ra (a grafelemzes mar most is gyanusnak tunik) de addig nem foglalkozom vele, csak ugy epitem fel a strukturat, hogy konnyu legyen beleilleszteni, ha a jovoben megis szeretnem.

Legalabb egy orat szivtam egy nagyon trivialis hiba levadaszasaval, (rossz szovegdoboz meret az elso megjelenesnel) ami megint raebresztett arra, hogy tobbet kene foglalkoznom a refaktoralassal. Neha meg egy sort is erdemes kiemelni egy fuggvenybe, csak hogy annyi kod duplikacio se legyen.

A logikai ojjektumok megalkotasaval meg azota sem foglalkoztam, de most az kovetkezik. Modularis toltest-mentest akarok irni, hogy mindig legyen mentett file kompatibilitas, de ne legyen a mentesfile formatum valtozasaival gond. Ha kesz vannak a logikai modellek, akkor errefele megyek tovabb, es az a resz jo esellyel mar TDD-vel keszul majd. (Feluletet es beaneket TDD-zni lehetetlen/ertelmetlen)