Author: Zoltán Ujhelyi

Amikor nem játszunk roleplayt…

Csapat:

  • Timi, a párbajhős lovagina;
  • D-nee, a mindig éhes barbárral;
  • Eversong, Kyel-pap;
  • Overander, a lútmester harcos;
  • Stampie, a játék ellenére nem piromániás tűzvarázsló
  • és végül, de nem utolsósorban TeoZ, a “jóindulatú” KM-ünk.

KM (barbárnak): Tengsz-lengsz, keresel munkát… de ahhoz fürödni is kell…

JK (barbár – felszereléséről): Van egy orrbevaló…

Csapat:

  • Timi, a párbajhős lovagina;
  • D-nee, a mindig éhes barbárral;
  • Eversong, Kyel-pap;
  • Overander, a lútmester harcos;
  • Stampie, a játék ellenére nem piromániás tűzvarázsló
  • és végül, de nem utolsósorban TeoZ, a “jóindulatú” KM-ünk.

KM (barbárnak): Tengsz-lengsz, keresel munkát… de ahhoz fürödni is kell…

JK (barbár – felszereléséről): Van egy orrbevaló…

KM (barbárnak meséli NJK magyarázatát a feladatról): Nincs Lélektanod… De ha lenne, látnád, hogy már halál ideges, hogy ötször kell elmondania, kit engedj be…

JK1 (barbár): Én a természet gyermeke vagyok, tudom, mikor van eső.
JK2 (tűzvari): Van időjóslásod?
JK1: Van.
KM: Akkor ezért nem szoktál fürdeni.

KM: Egyes helyeken még láthatók a leégésnek (ed. a városrész éghetett le máskor) nyomai.
JK(tűzvari): Nem én voltam, nem kell rám nézni.

Kyel-pap barátja súlyos mérgezést kapott, pap a jellemek eltérése miatt nem tudja meggyógyítani.
Megjegyzés: Van rá hét perced, hogy megtérítsd, és utána még kettő, hogy meggyógyítsd.

KM: Egyértelműen egy találós vers és annak a megfejtése…

KM: Egyrészt törzsvendég, másrészt törzsíró…

JK (Kyel-pap, a haldoklónak): Amikor látom, hogy kevés idő van hátra, mondom neki, hogy nyugodjon meg, dőljön hátra…

JK (lovagina, leírja külsejét): Hosszú, barna hajú…
KM: … tarkopasz és fekete ruhában (a barbár parancsa, hogy a gyanús alakokat ne engedje be, kivéve a fekete ruhás tarkopasz embereket).

Lovag próbálja a barbárt Domvik hitére téríteni, ehhez megkínálja szerencsesütivel. Barbár az összeset elveszi és felfalja egy mozdulattal.
KM: Dobj érzékeléspróbált! (dob, megvan) Nem érted, mit keres a papír a sütiben.
JK1 (barbár): Miért zavarna, jóízűen megeszem.
JK2 (lovag): Te megetted Domvik tanításait?
JK3 (Kyel-pap): Még soha nem volt ilyen közel az agyához.
JK1: Igen, finom volt […] Ki az a Domvik? […] Mindig ilyen finom sütit süt Domvik?

Rajtaütés a fogadón, mágikus fényeket eloltják, tűzvarázsló tábortűz erősségű lánggömböt idéz a levegőbe, hogy ne legyen teljesen sötét.
JK (Kyel-pap): Látom, hogy valami nem stimmel, ezért megvárom, hátha valami lesz…

KM: A következőket látod, ahonnan ülsz…
JK (Kyel-pap): Már felálltam.

KM: Ez (ed. Hatalom szava varázslat) kicsit olyan, mint amikor a pap feje fölött ott a glória…
JK (tűzvarázsló): Ezt én tudnám most eljátszani (ed. a feje mögé idézte meg a lánggömböt).

KM (érzékeléspróbát dobat, megvan): Akkor hallottad, hogy egy csóka ott feláll… (messze)

KM: Ez kiderül, ha megfogod a nyílvesszőt. Megfogod a nyílvesszőt?

KM: Nem játszunk.
JK: No roleplaying, please.

JK1 (tűzvarázsló): Ez a lyuk (a falban nyitott a barbár egy lyukat).
JK2 (Bong, barbár): Bong-formájú.

JK: Mennyi az idő?
KM: Négy óra (délután). Lehet, hogy vacsorára végzünk is…
JK: A karakterekkel?

JK: Ahány ház, annyi család.

JK (tűzvari, sütit evett a játékos): Pillanat, csak tele volt a pofám.

KM dob, 1.
JK1: Egy.
JK2: Ez azt jelenti, hogy egy?
KM: Igen, ez azt jelenti, hogy egy.

JK1: Lehet, hogy ennek semmi köze sincs a fogadóban történtekhez…
JK2 (tűzvari): Lehet, hogy mi ássuk ki nekik a cseresznyét…
JK3 (éhes barbár felkapja a fejét): Cseresznyét?

KM: Bérletes ajtókeret…
JK: Please insert bérlet here…

JK (tűzvarzsló, manatöltődés miatt figyeli az időt): Tényleg, mennyi idő telt el azóta, hogy utoljára kérdeztem?

KM: Egy kör alakú terembe értek, négyszögletű padlóval.

KM: Kőszobor… Márványos a textúrája.

JK (barbár): Hülyén nézek rá (tűzvarázsló, miután lángot okádva elpusztított egy márványgólemet).
JK (tűzvari): Fel sem tűnik.

A karakterek találnak egy vörös, egy kék és egy zöld kristályt egy rejtvényben, a rejtvény megoldása után a harcos elteszi RGB-kristályok címszóval.
KM: Pofám leszakad, hogy ezt is belútolta.
JK: Majd villogtatod a barátaidnak… “Mi ez? Polárszűrő.”

A szerepjátékosok törvénykönyve, első passzus: Az egyszerű dolgokra figyelj, és próbáld meg kitalálni, mit akar a KM.

KM: Akkor ott tartottunk, hogy a plot kidobta a quest itemet.

A lovag a harc közepén a lehetőséget kihasználva hátbatámadta a másik lovagot.
JK (lovag): Elrontottan. Ki kellett volna hívnom párbajra.

KM: Itt tegyük ki a The End táblát. A vége Epic Fail volt.

Modulértékelés
JK (barbár): Tudtál motiválni, adtál patkányt (enni).

Eclipse és az OSX

Az elmúlt időszakban egy kicsit összejöttek a Java-fejlesztéssel kapcsolódó dolgaim. A keretrendszer, amibe éppen fejlesztek, nemrég esett át egy elég durva refactoringon (hogy Eclipse-projekt révén a csomagnevek megfeleljenek az Eclipse elnevezési konvencióinak), és akkor közben megtették még azt is, hogy a legfrissebb változat már csak 6-os Javaval fut.

Ezzel önmagában nem is lenne baj, hiszen ez egy research projekt, nem érdemes régi technológia felett fejleszteni. Szerencsére az Apple nemrég kiadta a Java környezetének hatos változatát (igen, az Apple, és igen, csak most), annak idején már telepítettem is, de valahogy használatba nem került még. Sebaj, az Eclipse futása közben is lehet Java-t váltani. Szal beteszem az új verziót a futtatási konfigurációba, és a puskaport szárazon tartva reménykedek.

Az elmúlt időszakban egy kicsit összejöttek a Java-fejlesztéssel kapcsolódó dolgaim. A keretrendszer, amibe éppen fejlesztek, nemrég esett át egy elég durva refactoringon (hogy Eclipse-projekt révén a csomagnevek megfeleljenek az Eclipse elnevezési konvencióinak), és akkor közben megtették még azt is, hogy a legfrissebb változat már csak 6-os Javaval fut.

Ezzel önmagában nem is lenne baj, hiszen ez egy research projekt, nem érdemes régi technológia felett fejleszteni. Szerencsére az Apple nemrég kiadta a Java környezetének hatos változatát (igen, az Apple, és igen, csak most), annak idején már telepítettem is, de valahogy használatba nem került még. Sebaj, az Eclipse futása közben is lehet Java-t váltani. Szal beteszem az új verziót a futtatási konfigurációba, és a puskaport szárazon tartva reménykedek.

Nincs szerencsém: brutális bundle not found kivételeket kaptam, és a hiányzó bundle-ök az eclipse alap moduljai voltak. Kicsit utánaolvasgatva a témákat kiderült, hogy az a gond, hogy az Apple Java 6 megoldása csak Intel-alapú gépen fut, és ott is csak 64 biten. Pontosabban nem is ez a probléma, hanem az, hogy az SWT a Carbon GUI könyvtárat használva jeleníti meg az Eclipse GUI-t. És az Apple döntésének megfelelően a Carbon nincs meg 64 biten, csak 32-n. Azaz ebből az irányból per pillanat nincs győzelem. Fényt mindössze annyi jelent az alagút végén, hogy az SWT-sek megkezdték a Cocoa portot, és az Adobe is biztosított erre a célra egy mérnököt (az Eclipse-technológiára alapozva fejlesztőkörnyezetet akarnak építeni az ismereteim szerint). A Cocoa-port jelenlegi állása szerint csak 32 bites APIt használ a rendszer, de remélhetőleg ez hamarosan változni fog. Talán a 3.5-re meglesz.

De addig is kellene egy megoldás, mert dolgoznom kéne. Egyik ötlet, ami segíthetne, az az Eclipse on Swing projekt lehetne. A céljuk az, hogy az SWT platformfüggő hívásait Swing-alapúra cseréli. Nagyon szép, csak sajnos még az SWT 3.2-es változatánál vannak lemaradva, ami nekem nem felel meg, ugyanis a keretrendszer legalább a 3.3-as Eclipse-et igényli, ugyancsak ez a helyzet a Subversive SVN pluginnel is. Azért kipróbáltam, nem indul be vele az Eclipse Ganymede…

Másik megoldás egy másik JVM lenne, ami nem igényli a 64 bitet. Van is egy ilyen, ami a találó Soylatte névre hallgat. Feltelepítem, beállítom Eclipse JVM-nek. De ekkor kiderül, hogy itt meg az a gond, hogy X11-et használna grafikus felületként, ahogyan meg nem lehet behívni az SWT számára a Carbont…

A helyzet siralmas… Háromféle, egymástól drasztikusan eltérő megoldást kipróbálva jutottam el oda, hogy per pillanat Eclipse pluginfejlesztést nem lehet OSX-en Java 6-on végezni. Siralmas, hogy ezért kénytelen vagyok egy virtuális gépen futó Windows-t használni. Majd figyelem a változásokat, és szükség szerint alátolok valamit a rendszernek. Addig is a remény hal meg utoljára – a sör meg először…

Európa-fogyatkozás

Elég hamar kicseréltem az Eclipse 3.3 Europa integrált fejlesztői környezetemet az új verzióra. Hamarabb, mint eredetileg terveztem. Ennek annyi volt az oka, hogy letöltöttem az M6-os release-üket kipróbálásra, és amikor meghalt a rendes fejlesztői környezetem (volt 900 MB telepítve, rendes kis pluginkönyvtár :p ), úgy döntöttem, megspórolom az egész újratöltését, és inkább berakom a Ganymede-be a cuccokat.

Nem mondom, akkor még korai volt egy kicsit (de csak egy kicsit), nem volt (sokkal) nagyobb szívás ott újra összerakni a munkakörnyezetet, mint az Europa-ban lett volna. Mostanra meg már, hogy van végleges 3.4-es változat, nem mennék vissza.

Elég hamar kicseréltem az Eclipse 3.3 Europa integrált fejlesztői környezetemet az új verzióra. Hamarabb, mint eredetileg terveztem. Ennek annyi volt az oka, hogy letöltöttem az M6-os release-üket kipróbálásra, és amikor meghalt a rendes fejlesztői környezetem (volt 900 MB telepítve, rendes kis pluginkönyvtár :p ), úgy döntöttem, megspórolom az egész újratöltését, és inkább berakom a Ganymede-be a cuccokat.

Nem mondom, akkor még korai volt egy kicsit (de csak egy kicsit), nem volt (sokkal) nagyobb szívás ott újra összerakni a munkakörnyezetet, mint az Europa-ban lett volna. Mostanra meg már, hogy van végleges 3.4-es változat, nem mennék vissza.

Ami a leghasznosabb újdonság számomra, az a megújult csomagkezelő. Egyrészt az az előnye, hogy nem kell előre eldönteni, hogy én most új csomagot akarok telepíteni, vagy a meglevő csomagokon akarok valamit módosítani (korábban idegesítő volt, amikor a rossz menüpontra kattintottam, és egy percig várhattam, amíg megnézte, hogy mit lehet csinálni), ugyanis két almenüpont helyett egy közös dialógusablakból lehet változtatni két fül között – ezek a fülek tartalmazzák a korábbi funkcionalitást. Legalábbis nagyrészt.

Ami úgy tűnik számomra, hogy hiányzik, az a korábbi változatban Select required nevű gomb a telepítendő csomagok választásánál. Lehet, hogy már nincs rá szükség, mert automatikusan bejelöli (nem vagyok benne egészen biztos, ezért ezt nem merem elítélni). Amiben biztosabb vagyok, az a csomagok eltávolítása. Ezt még egyáltalán nem sikerült az új verzióban véghezvinni.

Ami viszont roppant hasznos új funkcionalitás, az a dropin mappa koncepciója. Ez egy kijelölt mappa, amibe ha bedobunk letöltött csomagokat, akkor azokat a csomagkezelő látja, és a függőségeivel együtt telepíthetőek. Ez nagyon hasznos lehet akkor, ha valami olyan projektet akarunk telepíteni, ami valami miatt nem szerepel az Eclipse csomagkezelőben.

Egy másik apró változás, amivel találkoztam, az az Eclipse pluginek (illetve RAP programok) fejlesztésekor jött elő: bizonyos fájlokat megnyitva az Eclipse nem jön rá, hogy én egy megadott futtatási konfigurációval akarom futtatni egy automatikus futtatás parancs kiadásakor, hanem kézzel kell megjelölni. Az Europaban erre nem találtam alternatív megoldást, de a Ganymede sokkal kevésbé idegesítő. A problémát ugyen nem oldották meg, de legalább megkerülték: első futtatáskor lehet, hogy ki kell választanom a futtatási konfigurációt, de utána megjegyzi, és nyugodtan futtatja úgy is.

Az Eclipse 3.4 lesz Ubuntuhoz is – az Europa nem volt, mert valami ütközött az SWT-ben és az Ubuntuban, és ezt csak az új verzióra javították ki; ezért is van az, hogy még az LTS kiadásban is csak a két éves 3.2 (Callisto) került be. Nem tudom, hogy végül is kijavították-e, mert per pillanat nincs lehetőségem ezt ellenőrizni, de valamikor majd ezt is meg lehet tenni. Ez a probléma egyébként akkor merült fel, amikor Balage a leírásom alapján telepíteni próbálta az [[PHP debug Eclipse PDT-ben|Eclipse PDT-t debuggerrel]].

Apropó PHP debugger: a PDT projekt nincs szinkronizálva az Eclipse kiadásokkal, ebből még nincs hivatalosan kiadott verzió (sem pedig update site). De a dropin megoldás segítségével könnyen telepíthető a rendszerbe, és utána minden gond nélkül megy. A php debugger is szépen megy.

Viszont még egy negatívumról is írnék: az SWT widget-készlet még mindig Carbon-alapú OSX alatt, ami nem jó hír. Java 6-tal nem megy, mert az OSX-en kötelezően 64 bites, míg a Carbon 32. De szerencsére már elkezdődött a Cocoa-alapú változat fejlesztése, ha minden jól megy, a következő kiadásba már be is kerülhet. Ha ez tényleg így lesz, akkor lehet, hogy megint kiadás előtt fogok váltani. De ez majd kiderül. 🙂

Szóval egy hasznos új változatról van szó, nagyon forradalmi változás nincs benne, de megfelelő továbbfejlesztése a népszerű IDE-nek. Úgy gondolom, tele lehet még az előzőekhez hasonló apró változtatásokkal, de ezek felismeréséhez nem használtam eleget a korábbi változatokat, ezért nem kívánok most róla írni. Majd esetleg máskor. Mindenesetre bárki számára javaslom a verziófrissítést, ha nincs túlságosan előrehaladott állapotban egy projektjében, mert akkor kellemetlen lehet a váltás. De érdemesnek érdemes szerintem, nem sok helyen van inkompatibilitás a következő verziókkal. Az egyedüli gond az lehet, ha valami szükséges plugin nem érhető el az új változatban.

De ha valakinek nincs valami nagyon különleges igénye, akkor nyugodtan lehet frissíteni, szépen megy az új Ganymede is.

Felhasználói felületek és a programozás

Ennek az írásnak az ötlete már jó ideje motoszkál bennem. Mindig is érdekelt a programozás – magas szinten. Azaz érdekelt, hogyan lehet nagy rendszereket tervezni, érdekelt, hogy ezek a rendszerek hogyan használhatóak az egyszerű felhasználó szemében. Érdekelt, hogyan lehet megcsinálni, de valahogy sosem csináltam meg. Egyszer ki kéne próbálni, de erre a közeljövőben ismételten nem lesz időm.

Ez persze nem akadályozott meg abban, hogy utánaolvasgassak a témának. Illetve azon oldalak ajánlásait kövessem, akikre már amúgy is feliratkoztam. 🙂 Így találtam rá az Ars Technica cikksorozatára, ami a fejlesztési eszközöket, nyelveket, APIkat veszi górcső alá. Korábban már volt szerencsém az Ars Technicahoz, ők képesek voltak korábban például a Leopardot tizenegynéhány oldalban elemezni, elvárásokkal, hiányokkal és hasonló dolgokkal. Szerintem tanulságos volt, ezért érdemesnek láttam a cikksorozatba is belekóstolni.

Ennek az írásnak az ötlete már jó ideje motoszkál bennem. Mindig is érdekelt a programozás – magas szinten. Azaz érdekelt, hogyan lehet nagy rendszereket tervezni, érdekelt, hogy ezek a rendszerek hogyan használhatóak az egyszerű felhasználó szemében. Érdekelt, hogyan lehet megcsinálni, de valahogy sosem csináltam meg. Egyszer ki kéne próbálni, de erre a közeljövőben ismételten nem lesz időm.

Ez persze nem akadályozott meg abban, hogy utánaolvasgassak a témának. Illetve azon oldalak ajánlásait kövessem, akikre már amúgy is feliratkoztam. 🙂 Így találtam rá az Ars Technica cikksorozatára, ami a fejlesztési eszközöket, nyelveket, APIkat veszi górcső alá. Korábban már volt szerencsém az Ars Technicahoz, ők képesek voltak korábban például a Leopardot tizenegynéhány oldalban elemezni, elvárásokkal, hiányokkal és hasonló dolgokkal. Szerintem tanulságos volt, ezért érdemesnek láttam a cikksorozatba is belekóstolni.

Az írás alapvető példája, mint mondtam, az volt, hogy összevesse a lehetőségeket. Előrebocsátom, hogy az ő írásuk is (az enyém meg pláne) az Apple megoldását preferálja a Microsoftéval szemben, ezért aki ebből flamet csinálna, az inkább most hagyja abba. Annak semmi értelme sincs (mondom ezt én 🙂 ).

Na, ideje belevágni a témába. A vonatkozott cikksorozat engem leginkább egy vonatkozásban fogott meg: a második részben feszegette azt, hogy a Microsoft APIk mennyire nem kifinomultak – valószínűleg ez lehet az oka, hogy szerte a cégen belül is a “kerék újra feltalálása” a divat. Ezt talán a mellékelt kép is szemlélteti (a kép eredeti változata a http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.media/vista.png címen érhető el).

A Microsoft konzisztensnek nem nevezhető kínálata felhasználói felület témában

A helyzet rossz. Nagyon. A képen szereplő ablakok a Visual Studio 2005 kivételével az aktuálisan elérhető legfrissebb változatok. Érdemes megfigyelni, hogy vannak alkalmazások menüvel és menü nélkül (utóbbi esetben szalaggal vagy rejtett menüvel). További érdekesség, hogy az Office család szereplő tagjainál alapvető eltérések vannak szerkezetben (szalag nézet a Wordben, hagyományos nézet a Visioban, és az Outlook mindig is egyedi volt). Másik érdekesség az előre-hátra nyilak az Intézőben, az Internet Exporerben és a Windows Media Playerben. Pontosabban a mellette levő lefele nyíl, ami a listát jelenítené meg: minő véletlen, ebből is van háromféle változat.

Biztos, hogy van még különbség, de ezek felderítését az unatkozó olvasókra bízom. 🙂

Azzal semmi bajom sincs, hogy a Vistában a felület máshogy néz ki, mint korábban. Lehet vitatkozni rajta, hogy jobb lett vagy rosszabb, mint a korábbi, én nem teszem meg, mert csak képernyőképeken láttam a rendszert. De ez így katasztrófa. Az Ars Technica sorozatában még mondott egy érdekes példát: a Vista kezdeti változatában azért voltak gondok a hangkártyadriverekkel, mert a Microsoft a fejlesztés végső szakaszában módosította a hangrendszert. Az ok: leültek multimédiában érintett emberekkel, és azok jelezték, hogy a lejátszóprogramok feleslegesen terhelik a gépet, ha pollozzák a hangbuffer állapotát, jobb lenne, ha az értesítené őket, hogy fogyóban az adat. Felmerül a kérdés: ez miért nem került a cég multimédiás programjának, a Windows Media Player fejlesztésekor? Például mert nem használja a saját APIt?

Ezzel szemben OSX-en az Apple szinte minden programja (nem állítom, hogy minden, mert azért az sem lenne igaz) egy közös megjelenítési APIt használ, és ez az API elérhető a fejlesztők számára is. Ezen felül elérhető még [[http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/|Apple Human Interface Guidelines]] című dokumentum is, ami egyfajta szakácskönyvet ad a fejlesztők kezébe, hogy az Apple milyen elvek szerint építi fel a programjait (többé-kevésbé). Eredmény: ha jön egy programozó, aki OSXre szeretne szoftvert írni, megnézi ezt a dokumentációt, és ez alapján tervezi meg a felhasználói felületet, és a beépített APIt felhasználva valósítja meg. Következmény: a 3rd party programok is hasonlóak lesznek a beépítettekhez. Ez a Microsoftos káosznál elérhetetlen állapot…

Persze a dolog messze nem ilyen egyértelmű: a http://www.neopoleon.com/home/blogs/neo/archive/2008/03/17/29941.aspx oldalon például a szerző azt részletezi, hogy miért nem szereti az OSX APIjait. Ez érthető is. Ahogy az Ars Technicas cikk harmadik részében szerepel, az Apple által erőltetett Objective-C nyelv alapvetően különbözik a megszokott objektum-orientált nyelvektől, csak OSX-en lehet használni, az XCode nevű program semmi különöset nem nyújt egy Visual Studiohoz képest, sőt, az extrák tekintetében le is van maradva. Szintén ebben a cikkben szerepel, hogy OSX-en meg hiányolja a .NET bizonyos részeit vagy éppen az Office 2007-et. Más szóval a helyzet messze nem egyértelmű, érdemes a továbbiakban is figyelni a témát, milyen változások lesznek.

Frissítés: Az Ars Technica cikksorozatára való hivatkozásokat pótolom.

  • [[http://arstechnica.com/articles/culture/what-microsoft-could-learn-from-apple.ars|Áttekintés, történelem]]
  • [[http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.ars|A Microsoft megoldásainak összegzése]]
  • [[http://arstechnica.com/articles/culture/microsoft-learn-from-apple-III.ars|Az Apple APIk ismertetése]]

J2EE és JUnit – avagy a platformfüggő Java

Végre, beadtuk. Az UML tárgyból esedékes házi feladatot (lásd még [[J2EE – a nagy aknamező|a múltkori írást]]). Ez J2EE egyszerűen valami félelmetes. Ez a technológia szép. De tényleg…

Az implementáció után mindössze teszteseteket kellett írni az utolsó beadásra. Mindössze. Persze ez akkor sem olyan egyszerű, hiszen azt JUnitban kellett megírni, ami alapvetően maga szeretné futtatni a teszteket. Semmi gond, akkor átverjük, feltöltjük a JUnitot is a konténerbe, és ott majd látni fogja a keresett dolgokat.

Végre, beadtuk. Az UML tárgyból esedékes házi feladatot (lásd még [[J2EE – a nagy aknamező|a múltkori írást]]). Ez J2EE egyszerűen valami félelmetes. Ez a technológia szép. De tényleg…

Az implementáció után mindössze teszteseteket kellett írni az utolsó beadásra. Mindössze. Persze ez akkor sem olyan egyszerű, hiszen azt JUnitban kellett megírni, ami alapvetően maga szeretné futtatni a teszteket. Semmi gond, akkor átverjük, feltöltjük a JUnitot is a konténerbe, és ott majd látni fogja a keresett dolgokat.

Hehe, már megint optimista vagyok ezekkel a cuccokkal kapcsolatban. Ez, hogy feltöltsük a JUnitot, ez körülbelül két óra szívást jelentett a classpath, build path, referenced projects, requirements és hasonló témában projektek és pluginek viszonylatában. Ezek tulajdonképpen mind-mind egyfajta függőséget jelentenek a projektek és más projektek, esetleg libek vagy hasonlók között, de az a poén az egészben, hogy a szerepük között jelentős átfedések vannak. És ami igazán kellemetlen az az, hogy ha a helyes megoldás mellett egy nem szükséges helyen megadod a függőséget, akkor már nem jó. Lehet vele szépen játszadozni.

Jó, túl vagyunk az alapozáson, megvan a teszt keretrendszer, kezdünk teszteseteket írni. Egyszer csak egyik kolléga megkeres, hogy nagyon eszement hibaüzenetet ad egy importra: nem azt, hogy nem találja, hanem azt, hogy nem engedélyezett a használata. Remek, újabb szép körnek néz ki. Ezúttal sajnos nem tévedtem. Némi játszadozás után értettem meg, hogy tényleg látja, csak valami miatt nem akarja használni. Közben szétvertem a tesztkörnyezetet (utána újból órákba kerül, amíg mindenkinél összeáll, de erről később). Na, ekkor némi Google, meg váltogatás a különböző Eclipse környezeteim között (bizony, nekem több is van, be-be-be 🙂 ), és kiderül, hogy a probléma egészen csúnya: az Eclipse támogat egy package-korlátozást (access rule-nak hívja) a különböző pluginekre. Ok, ez önmagában nem csúnya, hisz így az Eclipse-plugin írója rákényszerítheti a felhasználó plugint, hogy az api-n keresztül érje el. De ami gáz, hogy ezt alkalmazta a beépített Java típuskönyvtárra.

Ok, módosítsuk a dolgot. Némi segítség után rájövök, hogy melyik jarban van a keresett osztály. Adjunk hozzá egy engedélyező bejegyzést a jarhoz tartozó access rule-ok közé. Újabb pofára esés, és kiderül, hogy nem írható. Remek. További leírásböngészés, és ekkor kiderül, hogy az ősét, ha tudom szerkeszteni, az is jó. Na, azt tudom, mert a globálisat engedi szerkeszteni, csak a system jarokét nem, meg a workspace-ben definiált pluginekét sem (azokat a plugin.xml szerkesztőjén lehet hakkolni). Remek, beírom az osztálynevet com.sun…. formában, örülnék, hogy megy, de nem megy. Ok, nézzünk mintát, igaza van, /-rel kell írni, és ha *-gal zárom, akkor egy package-re lebontva tudom szerepeltetni. Ok, egy részét átírom /-esre (nem kéne azért a teljes com. tartományt engedélyezni), majd csillaggal lezárom. Még mindig nem jó. Aztán kiderült. Ahhoz, hogy rekurzívan elinduljon lefelé a csomaghierarchiában, ahhoz nem árt **-gal lezárni… Na, ezután már megy.

Illetve csak az a hivatkozás. Csak a libekkel szórakozás miatt elment a futtatókörnyezet. Sebaj, rutinos róka vagyok már, nekilátok és összerakom a megfelelő fájlt (jó, most csaltam, összeklikkeltem a run dialogban). Végre megy nálam. Ekkor töltsük fel svn-re, hogy a többieknek is menjen.

Eltelik pár perc, és kiderült, hogy nem ment át. Mint utóbb kiderült, verzió- és oprendszerkülönbségek miatt. Az OSX->Windows irányban nem működik. És fordítva sem. Az lett a vége, hogy a Windows-osok megcsinálták a környezetet, majd feltöltötték svn-re, ezután én is megcsináltam az enyémet, de én nem töltöttem fel. Erre ezután minden commitnál vigyázni kellett remek. Még szerencse, hogy a Java platformfüggetlen.

De ez semmi ahhoz képest, ami ma hajnali 5 magasságában derült ki, 6 órával a beadás előtt (ameddig persze be is kellett érni az egyetemre). Megírtam már 40 tesztesetet – ez majdnem ezer sor kód, ezek segítségével több hibát is kijavítottam a tesztelt kódrészben. De tényleg. Futott minden. Amikor a kolléga közli velem, hogy a teszteseteim egy része meghal, és ez hazavágja az egész adatbázist. Nálam persze semmi ilyesmi. Némi kísérletezés után kiderül, a gond az, hogy a Windows nem eszi meg a megoldást. Pont. Akkor mutassuk be Macen. De Macen meg egyes Windowson megírt tesztesetek nem futnak. 😕

A hibát nem sikerült megoldani… Mindenesetre kezdem azt hinni, hogy olyan, hogy platformfüggetlen nem létezik. A Java legalábbis biztosan nem az. Például az AbevJava máshogy megy Windows-on, mint Linuxon vagy OSX-en. És ez a mostani hiba is megerősíti ezt az elképzelést. Azt, hogy mi lehet a hibás, csak tippelni tudom. Van egy elszúrt (értsd: feleslegesen túlbonyolított) entitáshalmazunk, van egy toplinkünk mysql adatbázishoz csatlakoztatva, van alatta oprendszer, OSGi konténer, stb. stb. stb. Erre már csak Murphyt idézném zárógondolatként:

  1. A bonyolult rendszerek hajlamosak a bonyolult meghibásodásokra.
  2. Ezzel szemben az egyszerű rendszerek is hajlamosak a bonyolult meghibásodásokra.