Kérem, nézze el nekem, hogy levelemmel személyes kapcsolataimat felhasználva zavarom önt. Előbbire mentségem, hogy kérdésem számomra rendkívül fontos, utóbbira pedig az, hogy már több éve, amióta először olvastam néhány gondolatát Magyarországról, majd a programozásról, él bennem a vágy, hogy megkeressem önt. Az írásaiban, interjúiban megfogalmazott világos meglátások ismeretlenül is bizalmat ébresztettek ön iránt - most pedig úgy érzem, már van mit mutatnom.
Bemutatkozás
37 éves programozó - programtervező vagyok, és lényegében amióta a pályán vagyok, egyetlen téma foglalkoztat: hosszú távú megoldások keresése a feladatok szegmentálásával, valóban újrahasználható komponensek létrehozása, plugin architektúrák kialakítása. Ezt a vezérfonalat követtem, amíg rajzolóprogramot fejlesztettem a Wissen Kft-nél, adatbányász modulokat a Cygronnál, majd közös ügyviteli alkalmazás keretet az Ulyssys Kft-nél több országos mezőgazdasági rendszerhez. Az úton számtalan akadályt volt szerencsém megtapasztalni: egyrészt technológiai korlátokat (nyelv, környezet, eszközkészlet-függés), másrészt azt, hogy az újrahasznosítás legalább annyira szervezés és előzetes, "irreálisan alapos" átgondolás, illetve utólagos védelem ("minek trükközni, amikor van bevált megoldás?") kérdése, mint a stabil fejlesztésé. Talán az Ulyssysnél végzett munkám az egyetlen, ahol valóban megtérült a befektetés, mert az "elég nagy" volt hozzá.
Ismereteimet és tapasztalataimat több mint tíz éve igyekszem egy álom-projektben megvalósítani, ez a dust: distributed unit system technology, egy általános alkalmazás keretrendszer. Ennek tervein és pilot implementációin dolgoztam a háttérben, majd jelenleg már "fél-hivatalosan" az iCode Kft-ben, és ennyi ideig tartott megtalálnom a hitem szerint helyes megközelítést. Ez a mai felfogás szerint teljesen irracionális feltevésekre alapul, elvi síkon arra, hogy az informatika alapvetően "mondvacsinált iparág", az üzleti és a technológiai "jó" fogalma igen ritkán fedi egymást, lévén egy program immateriális, legalapvetőbb tulajdonságai: a korlátlan másolhatóság, az elhasználódás hiánya és az objektív értékelhetőség révén akár végleges megoldást is jelenthet egy feladatra. Ez kereskedelmi szempontból csőd - mérnöki szemmel viszont a létező legnagyobb kihívás. Ennek elfogadása jelentett támpontot ahhoz, hogy a megoldás keresése során megkérdőjelezzek minden szokványos alapfogalmat, mint például az operációs rendszer, az objektum orientált programozási nyelv, sőt végül az objektum fogalma; vagy hogy a legnehezebb feladattá emeljem a triviális nyelvi alapelemeket: adatszerkezet leírás, értékadás, függvényhívás.
A dust alapelvei
A dust legfontosabb elve a "late binding", minden szempontból. Egy feladat megoldásához szükséges adatszerkezet, interfész és felhasznált külső szolgáltatáskészlet mindentől (operációs rendszer, nyelv, futtató környezet, tervezőeszközök ...) független - mégis az első lépésektől kezdve választanunk kell közülük már a komponensek leírásához (OO nyelv, esetleg UML eszköz kiválasztása). A dustban a típusok adat- és szolgáltatáskészletének leírását a programozástól független adathierarchia valósítja meg, amelynek csak szerkezete kötött, a tárolási módja szabad (saját formátum / XML / LDAP / ...). Ezt a hierarchiát egy futtató környezet tölti be, amely e leírás segítségével felelős minden adat perzisztens tárolásáért, kezeléséért. A környezet feladata az, hogy a szolgáltatásokat megvalósító kódrészeket akár legkésőbb, a hívás pillanatában betöltse, illetve számukra hozzáférést biztosítson az igényelt külső modulok adataihoz és szolgáltatásaihoz. Ilyen módon a lehető legkisebb "téglák" és kapcsolataik nyelvtől függetlenül teljes mértékben deklarálhatók az első kódsor leírása előtt; az elkészült komponensek azonnal újrahasználhatók, illetve lecserélhetők, hiszen valóban teljes "fekete dobozként" jelennek meg a többi komponens számára.
A dust szakít a hagyományos objektum fogalmával, helyette az entitás fogalmát használja, amely pontosan egy elsődleges, és nem kötött számú egyéb aspektust ("képesség, jelleg") összefogó absztrakt egység, aspektusai révén kereshető illetve ezek révén vesz részt a tevékenységekben. Ez sokkal rugalmasabban és közvetlenebb módon reprezentálja a "valóságot", például akár futás közben homogén módon bővíthető olyan aspektussal, amely a fejlesztés ideje alatt akár még nem is létezett; továbbá megoldást jelent a többszörös öröklés kapcsán felvetődő problémákra.
Ugyanilyen jelentős az objektumtól elszakított "kontextus" fogalma, amely így több szintű lehet (global, user, session, call). Bizonyos aspektusok ugyanis nem állandó, helyben deklarált kapcsolatban vannak egymással, hanem egy adott tevékenység "környezetében" elérhetők, program szempontjából azonos módon, de valójában a deklarációnak megfelelő szinten közösen megosztott, akár cserélhető aspektusokról van szó. Ilyen lehet: log, üzenetközvetítő komponens, aktuális nyelv és erőforráskészlet, GUI megjelenítő, ... Továbbá a kontextus (mint például egy felhasználó jogosultságai, belépési szintje vagy az aktuálisan használt kommunikációs csatorna) adott pillanatban pontosan ugyanúgy befolyásolhatja egyes adatok láthatóságát, funkciók végrehajthatóságát, mint az objektum öröklődése vagy elhelyezkedése egy Java package struktúrában.
Mindez természetesen futási overheadet jelent - hozzá kell tenni azonban, hogy például a Java futtatókörnyezet feladatai hasonlóak, ugyanakkor a dust runtime ennek töredéke, hiszen nem tartalmaz egy rendkívül komplex nyelvet, (inkább egy moduláris mikrokernelhez hasonlít); illetve önmaga is dust komponens, implementációja akár elemenként cserélhető, adott futtató környezethez optimalizálható. A fejlesztés jelenlegi nyelve Java a produktivitás miatt, a végső cél viszont a standard C implementáció és az ezáltal nyújtott maximális hordozhatóság (a C++ által adott többletet a dust helyettesíti).
A dust állapota
A fenti alapelvek néhány hónapja nyerték el jelenlegi, véglegesnek tekintett állapotukat, egyes koncepcionális alapelemek még formálódnak.
A jelenlegi Java implementáció tartalmazza az a fejlesztői-tervezői struktúrát, amelyben megoldott a unitok szeparációja, a jar-ok elkészítése, megvan a helye a C változat párhuzamos fejlesztésének. Elkészültek a runtime alapelemei: azonosítók kezelése, üzleti logika betöltés, adat és üzenettovábbítás, entitás keresés, az aspektus deklarációért felelős komponensek, adatexport első változata. Kitűzött következő mérföldkő: az adatobjektumok jelenleg kézzel létrehozott Java forrásának generálása a deklaráció alapján.
Hosszú távú célok
Meggyőződésem szerint civilizációnk jelenleg nem fenntartható pályán halad: a globális pénzügyi értékelő rendszer alaptörvényei ellentétesek a véges eltartóképességű ökológiai rendszerével, ebből következően rövid távon, éveken belül ki kell azt váltani egy olyan rendszerrel, amely közvetlen kapcsolatot teremt az erőforrások és a szükségletek között. Ezt az állítást a http://hajnalvilag.hu/books/hajnalvilag.pdf címen elérhető írásomban részletesen kifejtem. Kiemelkedően fontosnak tartom, hogy mire az általam elkerülhetetlennek tartott erőforrás és pénzügyi válságok jelentkeznek, legyen a birtokunkban olyan informatikai rendszer, amely lehetővé teszi közösségeink önszervezését (ennek a folyamatnak a leírása a Hajnalvilág 101. oldalától kezdődő Útiterv fejezet). A dust ennek eszköze, ezért például alapelvnek tekintem, hogy dust alapú rendszerben csak létező dolgok adatai tárolhatók, pénzügyi információk nem.
Rövid távú célok
A dust futtató rendszerének kialakítása után, még akár Java nyelven elkezdődhetne olyan projektek fejlesztése, amelyek a jelenlegi infrastruktúránk által mostohán kezelt szükségleteket elégíthetne ki, illetve amelyek alapvetően támaszkodnak a dust által lehetővé tett moduláris felépítésre. Például:
- helyi termelők országos rendszere, termékek, elérhetőségek, szállítás és raktározás szervezés;
- helyi közösségek önszerveződése: eszközök, képességek és feladatok megszervezése, végrehajtása, ezáltal szállítási és eszköz optimalizáció, hulladékcsökkentés;
- oktatás: tananyag, segédeszközök, önálló tanulás, felmérések, stb; e-papír+érintőképernyő/kamera által megvalósítható "virtuális iskolatáska" tervek és prototípus készítése; szótárprogram
- "energiatudatos ház" létrehozása (Home Automation és Smart Energy komponensekkel)
- "pilot-projektek" létező szolgáltatások kiváltására dust alapon; új technológiák integrálásával (pl. 3D interfészek, megosztott virtuális környezet)
Jelenlegi kérésem
Azért kerestem meg önt, mert hosszú keresgélés után most úgy érzem, helyes irányban haladok - ugyanakkor látnom kell, hogy ez a cél messze meghaladja lehetőségeimet és képességeimet. Nagy örömet jelentene számomra, ha a fentiek felkeltették volna érdeklődését, és lehetőséget kapnék egy viszonylag kötetlen személyes beszélgetésre, és így módom lenne az elképzeléseimet egy nagyobb tapasztalattal rendelkező és megbízható emberrel megosztani, megfelelő prioritásokat és rövid távú lépéssort kialakítani - vagy meghallgatni, miért nem látja kivitelezésre érdemesnek a koncepciót.
Bevallom, hosszabb távon kíváncsi lennék a véleményére a Hajnalvilágban leírtakkal kapcsolatban is... mind a dust alapvető céljai, mind pedig a felsorolt rövidtávú projekt-ötletek többsége alapvetően kötődik az ott leírt, a maitól teljesen idegen jövőképhez.
Együttműködés
Elsősorban természetesen "koldulok". Azért van lehetőségem ennyi energiát ölni egy szép elképzelésbe, mert jelenlegi munkahelyem, a barátom által vezetett iCode Kft alapvetően support tevékenységből tartja/tartotta fenn magát, ez a "kegyelmi idő" azonban a végéhez közelít. Ennek tudatában Gyuri új projekteket keresett, ezek egyike a HomeAutomation, Zigbee szabványon, Ember eszközökkel (egyébként kellemes programozni őket, és tréfás módon visszaköszönnek benne a dust alapkoncepciói...) - és mivel ez moduláris megközelítést igényel, a dust fejlesztést (amitől engem szinte lehetetlen elszakítani) a HomeAutomation projekthez kapcsolódó alapkutatásnak tekintettük. Erre azonban egy párfős cégnek nincs erőforrása, így nemsokára vagy átnyergelünk "pénzteremtő" fejlesztésekre, akár egy HA pilot kialakításával, akár más fejlesztői munkák elvállalásával - vagy találnom kell külső forrást a dust fejlesztésére.
Olyan megoldást keresek, ami nem jelenti az iCode "cserbenhagyását"; ráadásul számomra elfogadhatatlan megoldás "eladni" a dustot, amelyet csak úgy tudok elképzelni, mint a Hajnalvilág Alapítvány tulajdonát, és amely nem "termék": célja egy civilizációs probléma megoldásában való részvétel, nem pedig üzleti haszon. Ugyanakkor meg kell élnem valamiből, tehát lényegében azt kérdezem, milyen feltételekkel lenne hajlandó a közvetlen megtérülés reménye nélkül pénzt áldozni erre a célra...
Másodsorban szakértő konzultáció lehetőségét keresem. Az utóbbi időben sokat beszélgetek a tükörrel, de ez nem a leghatékonyabb módja a fejlesztésnek. Jól jönne egy megfelelően kritikus, de támogató és a fejlesztés céljával azonosulni képes segítő, aki valamennyi időt rá tudna szánni a dolog megértésére, feladattérkép és időtervek kialakítására, aki fel tudja fedezni a számomra nem látható szürke foltokat, látja mikor kell kizökkenteni egy beragadt folyamatot, illetve mikor lehet segítséget bevonni.
Amennyiben a dust tényleg képes "nagyra nőni", valós projektekben szerepelni, nyilván kevés egyetlen ember tudása és programozói kapacitása. Ma nyilván még nem lehet dust projektet indítani, mert a runtime kialakítása során azért még alakul, tisztul a belső interfész, hiányoznak az alapvető eszközök (deklaráció készítés leírása, esetleg szoftveres támogatása, forráskód generálás, core modulok). Ugyanakkor egy GUI unit deklaráció kialakítása már nem egyszemélyes feladat; annak átültetése valamilyen célplatformra szintén nem az; utána pedig jönnének a már "való világbeli" feladatok: emberek, földrajzi adatok, erőforrások, ... Sok programozói munka. Ennek egy része feltehetően "community" formájában is történhet, de annak szervezése - illetve "házon belüli", például egyetemi projektek további erőforrásokat igényelnek. Ebben, ha eljut ide a történet, szintén segítségre szorulok majd.
Remélem sikerült elfogadható tömörséggel és struktúrában összefoglalni a lényeget, köszönöm, hogy időt szakított elolvasására.
Üdvözlettel
Kedves Loránd
Ezt ismerősön keresztül próbáltam eljuttatni Bojár úrhoz, akivel kapcsolatban már évek óta azt képzeltem, hogy egyszer a segítségét fogom kérni. Választ nem kaptam.
