Úgy néz ki, egyelőre Balage Debug Visualisation projektje még fut egy darabig, nem ért véget azzal, hogy megkapta rá a jegyét. Nemrég volt egy újabb release, most pedig én egy régi ígéretemnek tettem eleget, és készítettem hozzá egy bemutató videót.
A videó nagyon egyszerű: megmutatom, hogy egy komplex debug eljárás esetén (hiszen egy másik Eclipse példányban futtatott plugin projektet tesztelek vele) hogyan használható ez a plugin.
Mindenesetre jöjjön a lényeg:
Megfelelő igény esetén esetleg arról is fogok beszélni, hogy hogyan készült a videó – most csak annyit mondanék róla, hogy teljesen nyílt szoftverek felhasználásával készült – eltekintve a youtube felületén hozzáadott annotációktól.
Ami viszont vicces volt, hogy feltölteni macerás: a fájl lassan töltődik fel, és időnként megszakadt közben a net – ebben az esetben pedig az AJAX-os feltöltő script végtelen ciklusba került, és nem töltött fel semmit, de nem is vette észre, hogy vége a dalnak. Talán majd egyszer ezt is javítják (vagy nekem javul meg a netem ).
Aki figyelemmel kisérte a nem rég [[Debug vizualizáció Eclipse-hez|bejelentett]] projektet, az már tudhat róla, hogy pár hónapja működik egy eclipse update site a honlapon. Az említett projekt [[http://code.google.com/p/debugvisualisation/|honlapján]] egy ideje már bejelentettük a létezését, de az itteni kihirdetés idő és kedv hiányában késett egy kicsit.
Tehát a lényeg: az eclipse menüben Help/Software Updates../Available Software/Add Site..: http://eclipse.cubussapiens.hu
Jelenleg egyetlen feature található rajta, de ahogy az időnk engedi, ez a kör bővülhet. Addig is használjátok egészséggel ezt az egyet, és nyugodtan küldjetek hibajelzést/kivánságot a projekt oldalára.
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:
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.
A héten tartja/tartotta az Apple a WWDC07-et, az Apple fejlesztői konferenciát. Maguk a konferencia rendezvényei zártak, de Steve Jobs nyitóelőadása elérhető interneten keresztül sugározva (természetesen Quicktime rendszeren, illetve várhatóan később az iTunes-on keresztül is, de ez valamilyen szinten érthető is…).
A mostani nyitóelőadás java részét az tette ki, hogy megmutassák, milyen (rohadt jó) intuitív megoldások várhatóak az őszre halasztott OSX 10.5-re. Hát a Vista innovatív ötletei mellett tényleg történik is itt valami… Picit többet csináltak a fejlesztők, mint összelopkodtak egy csomó jó ötletet…
Jó, tény, hogy a Spaces néven beharangozott megatuti megoldásuk a KDE-ben már valamilyen formában régóta megtalálható, de igenis ügyes dolgokat is kitaláltak. Például kifejezetten tetszetősek az iChat új videokonferenciás szolgáltatásai. Tény, parasztvakítás… Nem véletlenül népszerű az OSX az otthoni felhasználók körében (persze azok között akik ismerik és meg tudják fizetni): azokat a dolgokat próbálják meg megvalósítani, amire az otthoni felhasználóknak szüksége van, azaz: böngészés, levelezés, multimédia. Ezekre a feladatokra mind-mind beépített programokkal rendelkeznek, megfelelő tudású, sablonokkal ellátott videovágó, DVD-készítő vagy hangvágó programok. A Windows-os Movie Makerrel hagyjatok békén…
Noha nekem nem ez volt a célom, amikor Mac-et vettem, de azért jó tudni, hogy ilyeneket is tud. Mellesleg, amikor UNIX-alapúvá tették a rendszert (miután nem tudom, melyik BSD-változatot használták fel, ezért nem mondok több konkrétumot), a Mac-et csábító platformmá tették az Open Source fejlesztők számára. Most már az ismertebb nyílt forrású termékeknek gőzerővel készülnek a portjai OSX-re, ha még nincsenek is készen (és itt porton nem az éppen futtatható változatot értem, hanem egy a rendszerbe szervesen illeszkedő változatot. Az előbbiekből nagyobb a már kész cuccok aránya…)
Másik érdekesség, ami elhangzott, hogy a játékfejlesztők is elkezdtek célplatformként gondolni a Macre. Az id Software régi motoros a UNIX-alapú rendszerekre való fejlesztésben, hiszen OpenGL alapú motorokat használnak, és termékeiket más platformokra is eladják, érdekes módon pont az idei WWDC-re időzítették az új motoruk első bemutatóját. Szintén az előadáson az EA egyik vezetője is bejelentette, hogy az EA is úgy gondolja, hogy a játékaikat Macre is ki fogják adni. Ha a nagy cégek komolyan elindulnak ebbe az irányba, az jó, ugyanis akkor lassan meg fog szűnni az a probléma, hogy a Macen nem lehet játszani.
Ami probléma persze ebben a formában marhaság… Minden operációs rendszerre vannak elérhető játékok, a Linuxra írt játékok nagy részének van Mac-es portja is, ezen felül főleg a shareware játékok piacán sokan elsődlegesen OSX-re fejlesztenek. Tudom, sokan ezeket nem tekintik játékoknak, csak a 3D-ben pompázó hiperrealisztikus engine-ek által hajtott programokat, de nem értek velük egyet. Ezek a kis játékok gyakran sokkal tovább lekötik a fantáziát, mint a csillogó-villogó csodák, mert az embertől több kreativitást kívánnak (természetesen vannak kivételek, de általában ez jellemző).
A harmadik nagyobb bejelentés még érdekesebb volt. Steve Jobs bejelentette, hogy böngészőjüket, az eddig csak Apple platformon elérhető Safarit kiadják Windows-ra is, sőt a bétaváltozat már el is érhető. A célokról megoszlanak a vélemények, de hivatalosan az a magyarázat, hogy az iPhone-ba integrálták a teljes Safari-motort, és a Windows-os fejlesztőknek is megkönnyítik a dolgát, ha iPhone-ra akarnak szoftvert írni.
A reklámszöveg, amivel a Safari 3-at népszerűsítették, az volt, hogy a Safari jelenleg a leggyorsabb elérhető böngésző (az IE7-tel kár összevetni, de a Firefoxnál is gyorsabban jeleníti meg az oldalakat). Ezt akár el is hiszem nekik. A terjesztést az iTunes-on keresztül tervezik, ami jó indulási lehetőséget jelenthet nekik, hiszen elég sok Windowsfelhasználónak van feltelepítve a program.
Természetesen a dolog messze nem megy ilyen könnyedén. Pár hónapja nagy visszhangot váltott ki a hír, hogy egy nappal a biztonsági frissítés kiadása után a Safarin keresztül feltörtek egy OSX-et futtató gépet, és a jelek szerint a Safari továbbra sem a legbiztonságosabb böngésző. Ugyanis egy nappal a kiadása után nagyon súlyos biztonsági réseket találtak a programban. További problémák az új motorral, hogy a frissített WebKit eszközökkel nem kompatibilis minden jelenlegi OSX widget.
Ezek a problémák mellett én mindenesetre jónak tartom, hogy a Safari megjelenik Windows-ra is. Egyfelől a biztonsági kockázatok kezelése segít(het) az eddig bombabiztosnak tartott OSX védettségének növelésében, amire szükség is lesz, mert az OSX is olyan irányt vesz, hogy az egyszerű emberek is használhassák, és ha a számuk elér egy kritikus tömeget, akkor már ezt a platformot is támadni fogják. És az OSX messze nem olyan biztonságos operációs rendszer, mint amilyennek hirdetik. Egyszerűen a kevesebb támadásból kevesebb nagyobb eset adódik.
Ami viszont komolyan segíthet, az az, hogy a rendszer lehetővé teszi, hogy még több ember váltson át Safarira – remélhetőleg IE-ről, hiszen annál nagyságrendekkel jobb, felhasználói élményben és szabványkövetésben egyaránt. Én személy szerint hiányolom a Safariból a Firefoxban megszokott rugalmasságot, de ez sok felhasználónak nem jelent problémát. Ez lehetővé teheti, hogy az IE részesedése tovább csökkenjen.
Ugyanakkor nem állítom, hogy az IE bukásra van ítélve. Ha a Microsoft időben elkezdi a fejlesztéseket, akkor akár visszaveheti a ………….-tól (ízlés szerinti IE-től különböző böngészővel kitölthető) a legjobb böngésző, a legszabványkövetőbb böngésző, stb. címeket, és ezáltal eredményesen is együtt lehetne működni a dolgokkal. Ehhez mondjuk valószínűleg az kell, hogy az IE részesedése 50% körülire, esetleg valamivel az alá csökkenjen, ugyanis ekkor már eredményesen szembe lehet menni a Microsoft saját érdekeivel. Ez jelenleg még nem megy…
).
