És mégis leng az inga…

A sok elborult, kocka téma után most egy kicsit könnyedebb vizekre eveznék. Ez nagyjából azt jelenti, hogy a következő írást úgy tervezem, hogy ne csak informatikusok számára legyen érthető (noha ők meglehetősen furcsa okokból nem hemzsegnek az oldal olvasói között).

Kicsit nehezen kezdek hozzá, ugyanis még könyvet nem ajánlottam ezeken a hasábokon – pedig olvastam párat, köztük olyat is, amit tényleg érdemesnek tartok arra, hogy többen olvassák. Ami mondjuk hasznos lenne, hiszen [intlink id=”635″ type=”post”]egyre kevesebbet olvasunk[/intlink].

Viszont a mostani könyvajánlatom nem fog ezen segíteni, ugyanis Umberto Eco Foucault-inga című műve kifejezetten ijesztő: csaknem 800 oldal, nem nagy betűkkel szedve, kemény táblával. De szemben a múltkor emlegetett Ügyféllel itt tartalom is van mellé: Eco professzor úr igen hosszadalmas kutatómunkáját (is) tartalmazza ez a könyv, benne a templomosokról, rózsakeresztesekről és hatalmas rejtett titkokról.

Ha van Terv, akkor minden mindennel összefügg. Ha van Terv, akkor nem kétséges, mi közük a templomos lovagoknak a hasszaszinokhoz, az alkimistáknak a párizsi metróhoz, a titokzatos Saint-Germain grófnak Shakespeare-hez, a rózsakereszteseknek Arsène Lupinhez, a druidáknak az Eiffel-toronyhoz, a Föld forgását bizonyító Foucault-féle ingának… Kihez-mihez is?

Ha van Terv, minden kiderül.

Mi is ez a Terv? Sokat nem mondanék róla, valamit a könyvnek is érdemes meghagyni, de röviden annyit tehetnék hozzá még, hogy negyvenkettő. Azaz a Terv mindent leír, ami a történelmünkben az elmúlt néhány száz évben történt. És a lehetőségekhez képest mégkonzisztens módon is.

Az értékelésem szükségképpen szubjektív, részrehajló vagyok. Én kedvelem a történelmi regényeket, szintúgy azokat a könyveket, amiben a természetfeletti erők is előkerülnek, de azért emberközpontúak maradnak. Ha ehhez még titkok is társulnak, és a főszereplőkkel még azonosulni is tudok, akkor borítékolható, hogy jól érzem magam olvasás közben.

  • Nem rossz – mondta Belbo. – Engem viszont ez a piramisokról szóló ötszáz oldal, ez nem hagy nyugodni.Tudták-e, hogy a Kheopsz-piramis pont a harmincadik szélességi fokon áll, és hogy az a szélességi kör szeli át a legtöbb szárazföldet? És hogy a Kheopsz-piramisnak ugyanazok  a geometriai arányai, mint az amazóniai Pedra Pintadának? És azt, hogy Egyiptomban két tollas kígyó is volt: az egyik Tutankamon trónján, a másik pedig a szakkarai piramison, és ez Quetzalcoatlra utal?
  • Quetzalcoatl a mexikói pantheon tagja. Mi köze neki Amazóniához? – kérdeztem.
  • Mit tudom én, valamit biztos kihagytam. […]

Érdemes lehet megfigyelni, hogy noha összeesküvéselméletekből van bőven a könyvben, a szerző megmarad a tudományos elfogadott módszerek mellett, azaz lehetőség szerint mindent támasszunk alá tényekkel, de legalábbis más művekkel. Jó ez?

Egy biztos: olyan mennyiségű forrásra hivatkozik menet közben, hogy a végén levő függelék kicsit kevés – csak kilenc oldal. Kevésszer fordult eddig elő, hogy egy könyv olvasása közben totál műveletlennek éreztem magam, de itt szinte folyamatosan ez az érzésem volt. Kevés olyan könyv van, ahol egyszerre kap szerepet a Rózsakeresztes kiáltvány, a Gergely-féle naptárreform, kombinatorika (némi programozással együtt) és a Föld forgását kísérleti úton kimutató Foucault-inga.

Szerencsére mindenhol elég pontosan megnevezi a forrásokat – még az elborult, “ördöngös” könyveket is. Így viszont eléri azt, amit nagyon sok könyvnek nem sikerül: hitelesség.

Mindezek mellett a könyv részletesen meg van tervezve: a fejezeteket tíz szakaszra osztotta, amelyeket a szefirák mentén oszt be. Azok kedvéért, akik nem tudnák, mik azok a szefirák (közétek tartoztam a könyv olvasása, illetve az értékelés írása előtt), a héber kabbalisztika tíz állomása a megvilágosodás felé. Emellett a fejezeteket rövid, kapcsolódó idézetek vezetik be.

Ugyanakkor fontosnak tartom megemlíteni, hogy a könyv nem kalandregény, semmilyen formában. Leginkább fejlődésregény: megmutatja, hogyan érti meg Doktor Casaubon a világ legfőbb titkait.

És itt jön az a pont, ahol találkozik a könyv a szakmai érdeklődésemmel is: megmutatja, hogyan lehet leírni a világot egy jól definiált rendszerben. Gondolom, informatikusok/szoftverfejlesztők ismerik ezt a feladatot – ezt rendszeresen kell csinálnunk. Jó tudatosítani az ilyesmit.

És mi különbözteti meg a regény összeesküvéselméleteit a tényleges igazságoktól? Ne akarjuk a hibákat is tökéletesen modellezni. Ha van két, az összes adatunkkal konzisztens hipotézisünk, válasszuk az egyszerűbbet. Meglepően sokszor használható.

Lassan lezárva gondolataimat azzal fejezném be ezt az írást, hogy mindenkinek sok szeretettel ajánlom Eco professzor úr könyvét elolvasásra, a könyv elejéről Raymond Smullyen mottóját idézve:

A babona bajt hoz.

Az idézetek az Európa Kiadó 1992-es magyar nyelvű kiadásából származnak.

Ganymede fejlesztés Java 6-tal OSX-en

Elég sok időt töltöttem már azzal, hogy Java 6 alapú fejlesztést lehessen végezni [intlink id=”570″ type=”post”]Eclipse-szel és OSX-szel[/intlink].

Az alapprobléma az volt, hogy egyszerre kellett 32 (az SWT Carbon API-ja kötelezően 32 bites) és 64 biten dolgozni (mert a Java 6 kötelezően 64 bites). Szerencsére ezt a fejlesztők is belátták, és elkészítették az SWT Cocoa portját (ami mellesleg nem lett rossz, de ez nem ennek az írásnak a témája).

Eredmény: némi varázslás után 3.5-ös Eclipse-szel lehetett Java6-ra fejleszteni (a varázslás nem ártott, de erről szintén nem most írok). De ez bizonyos esetekben nem elég. Például, ha az ember kénytelen 3.4-es Eclipse-szel is kompatibilis maradni, és ezt még ellenőrizni is szeretné.

Ez, és az apróbb problémák a 64 bites Java 6-tal győztek meg végül arról, hogy kb. egy hónappal a megjelenés után frissítsek Snow Leopardra. Elvégre abban van 32 bites Java 6 is, ezért elvileg mennie kellene a dolognak. Sőt, csak Java 6 van a rendszerben, szóval ez még jobb.

Na, Ganymede indul, szépen megy is. Összegyűjtöm a tesztelendő projekteket, és indítanám a runtime workbenchet, mire közli velem, hogy a Carbon SWT nem működik a 64 bites JVM-en. No comment.

A szokásos trükkjeimet ilyen esetekre végigpróbáltam, eredmény teljes kudarc, mígnem  az ESE konferenciáról beszámoló blogbejegyzés kommentjében Kevin Barnes leírja a megoldást: a VM-nek a -d32 paramétert átadva 32 bites JVM-et indít.

És ez tökéletesen működött. Szuper.

PS.: jellemző Eclipse probléma, hogy a megoldás triviális, csak megtalálni nehézkes. De legalább most már tudom, hogyan lehet 32 bitre force-olni a JVM-et.

Fejlesztés, metodikák, ortogonális kódok

D-nee tett fel hétvégén egy érdekes linket a deliciousre: Jeremy D. Miller írt egy egész részletes szösszenetet Orthogonal Code címmel, és egész jól összefoglal bizonyos programtervezési elveket.

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.

Számítógép használat másképpen

A héten bukkant fel a neten egy videó, R. Clayton Millertől 10/GUI címmel. Röviden bemutat egy koncepciót arról, hogyan lehetne használni a jövő számítógépeit.

Azok kedvéért, akik még nem látták, itt a videó:

Először is szeretném leszögezni, hogy a koncepció alapvetően tetszik. Konzisztens, motorikus reflexekre épít a felület használata (az gyorsan tanulható), az asztalra kirakott néhány widget koncepció az, ami nekem a KDE4-ben is nagyon tetszett, stb.

Az kérdéses, hogy a 2D helyett 1D ablakelhelyezés mennyire használható. Átlátni bizonyosan könnyebb, ugyanakkor kérdés, mit csinál akkor, ha egyszerre sok ablakot/alkalmazást szeretnék egyszerre használni. Megvan a kockázata, hogy arra nem annyira jól használható.

További lehetséges probléma, hogy mennyire lehet finom műveleteket végezni úgy, hogy a többi ujjunk bezavar(hat). Ez persze csak finomhangolása a rendszernek, mindez megtörténhet a mostani billentyűzet + egér/touchpad/trackpoint kombinációkkal, vagy a touchscreenekkel is.

Amit meg végképp nem látok, hogy a rendszer hogyan működne adatcentrikus alkalmazásokkal. Amikből van egy pár: különböző űrlapok kitöltése, megjelenítése, adattáblák áttekintése gyakori feladat a különböző enterprise alkalmazásokban. Persze, ezt is lehet jobban és rosszabbul csinálni, de ha egy rendszer használatához minden meglevő alkalmazást át kell írni, akkor sokáig élni fog a régi… Látjuk ezt IE6 kapcsán is, de ez most off volt. 😀

Mindenesetre ötletnek jó a folytatást tekintve – sőt, szerves folytatása az eddigi trendeknek. Kérdés, hogy mi lesz belőle, ha ténylegesen bekerül a mindennapokba.

Update: amit kihagytam az előző értékelésből.

A legtöbb interakciónál nem használjuk az ujjainkat külön-külön, hanem csak valami közös, motorikus reflex alakul ki. Persze, vannak esetek, amikor kivételek vannak, de ez ritkaság. Sokan nem tudnak 10 ujjal gépelni, kevesen zongorázak/hegedülnek/játszanak hangszeren, ami efféle problémákat vet fel.Megtanulható, de nem mindenki veszi rá a fáradtságot.

Persze az egy interakciós pont sávszélessége kérdéses, de ha jobban belegondolunk, amikor papírra írunk, akkor is egy pont az interakció, mégis egész gyorsan tudnak egyesek írni.

Kapcsolódó probléma, hogy mi történik, ha úgy próbálok többujjas gesztusokat végrehajtani, hogy az ujjaim különböző ablakok felett vannak?

És a legvégső problémám a rendszerrel: az emberek többsége nem képes egyszerre több mindent végezni – és itt a többujjas gesztusokat muszáj egyszerre csinálni. Nem biztos, hogy könnyű.

Most a frissítés hatására a kritikák abszolút túlsúlyba kerültek a pozitív tartalom mellett, ezért fontosnak tartom még egyszer megjegyezni, hogy szerintem érdekes koncepció, esetleg ki is próbálnám, ha lenne rá lehetőségem. De amire biztosan jó, az az, hogy végiggondoljuk, mire jó, és levonjuk a konzekvenciákat.

Eclipse Trivia: ListDialog

Némi bugfixing kapcsán eljutottam egy Eclipse plug-in belsejében a JFace ListDialog osztályhoz.

A dolog lényege, hogy egy definiált listát megjelenít, és lehetővé teszi a felhasználó számára az elemek kiválasztását egy dialógusban. Az ötlet jó, hiszen viszonylag gyakran szükséges feladat.

Ugyanakkor egy érdekes adalék a működéséhez: működik az a hasznos (és elvárt) funkció, hogy a lista elemei dupla kattintással történő kiválasztása működik. Feltéve, hogy a Mégsem gomb is engedélyezve van… 😀 No comment. (Ld. még Bug 292576).