Category: A mi gépünk

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.

HP ipaq rx3715 és Linux

Érdekes, és mint kiderült, kissé veszélyes játékba fogtam ma. Miután feladtam, hogy értelmesen összerakjam a M$ Windows Mobile 2003 SE rendszert, eldöntöttem, hogy lesz ami lesz, kipróbálom a linuxot rajta az [[http://www.handhelds.org/moin/moin.cgi/HpIpaqRx3715InstallFromUbuntu|itt]] található leírás alapján.

Érdekes, és mint kiderült, kissé veszélyes játékba fogtam ma. Miután feladtam, hogy értelmesen összerakjam a M$ Windows Mobile 2003 SE rendszert, eldöntöttem, hogy lesz ami lesz, kipróbálom a linuxot rajta az [[http://www.handhelds.org/moin/moin.cgi/HpIpaqRx3715InstallFromUbuntu|itt]] található leírás alapján.

Az első nehézség nem is ezzel volt kapcsolatos, életem legnagyobb bakiját sikerült elkövetnem, és csak a szerencsén múlott, hogy helyre tudtam hozni. A tanulság: mielött beletörölsz a particíós táblába, alaposan nézd meg, hogy melyik lemezzel teszed. Én nem tettem meg, és mivel az említett tutorial /dev/sda-ról beszél, vidáman beírtam a végzetes “sudo fdisk /dev/sda” sort, és gondolkodás nélkül irtam át a partíciós táblát. Mielött magamhoz tértem, a GRUB zavarbaejtő “Error 17” üzenetével találtam szembe magam. Szerencsére találtam a fiók alján egy linux lemezt, amivel helyrehoztam. Pánik vége. Rövid pihenő, egy erős tea, folytassuk.

A fenti égő de tanulságos baki után nem ütköztem komolyabb ellenállásba a telepítés során. Feszült koncentrációval és minden lépést alaposan átgondolva sikeresen particionáltam az SD kártyámat, és felmásoltam a szükséges fájlokat. Pár pillanat múlva a PDA képernyőjén biztató apróbetűs konzol jelent meg, és azon boot-szagú feliratok. Rövid várakozás után pedig a hőn áhított [[http://opie.handhelds.org|OPIE]] felülete fogadott. Bizakodással és az izgalomtól remegő kézzel ragadtam meg a stylus-t, és kezdtem meg bátortalan lépéseimet az ismeretlen rendszerben. Az első kellemetlenség, ami megzavarta az újdonság izgalmában úszó lelkemet, az a nyílvánvaló tény, hogy bizony a képernyő fekvő helyzetbe van fordítva. Hamar megtaláltam a menüben a “rotate screen” feliratú gombot, ami a kecsegtető hangvétel ellenére a várakozással tökéletesen ellentétes irányba, immár fejjel lefelé fordította a képernyőt. Ez legyen e legkisebb probléma, gondoltam, ha más működik. Azonban további csalódásoknak lettem kitéve. Csak hogy párat említsek a WLan egyáltalán nem működik, a Bluetooth hasonlóképp, és komoly nehézséget okoz a ciril betűs képernyőklaviatúra.

De persze sikereket is értem el, némi szenvedés árán sikerült hálózatba kötnöm a laptopommal usb-n keresztűl. Így sikerült pár srceenshotot töltenem le a kütyüről, amiket a beépített képlopóval csináltam (ügyes, és nagyon hasznos kis eszköz). Általánosságban az interfésszel jók a tapasztalataim, a naptár alkalmazás, jegyzetelés, és dokumentumok kezelése határozottan jobb, mint amivel eddig WM kapcsán összefutottam.

Végeredményben eredményes kisérletet zártam, bár a komoly hiányosságok miatt egyelőre nem jelent használható alternatívát. Íme pár screenshot a miheztartás végett:

Az első képernyő
Az OPIE rendszer kellemesen lágy vonalai fogadtak induláskor.

Konzol
Beépített konzol, és a top program mutatja a rendszer terhelését.

Benchmark
Még egy beépített eszköz: leméri a PDA egyes elemeinek a teljesítményét, ami összehasonlítható más kütyük méréseivel.

Ciril betűk
Zavarbaejtő, mi több, kellemetlen. Ciril betűk a klaviatúrán.

Utóirat: közben megtaláltam a megfelelő beállítást, így már egy sokkal kellemesebb angol billentyűzet fogad, sőt, magyar kiosztást is tartalmaz.

PHP debug Eclipse PDT-ben

Bevezetés

Gondolom, többekkel előfordult már, hogy volt egy olyan PHP-kódja, ami valami miatt nem az elvárható eredménnyel futott le. Ilyenkor nincs mit csinálni, lehet debuggolni. És ekkor szembesül az ember azzal, hogy az nem lesz olyan egyszerű…

A legegyszerűbb PHP-telepítésnél nincs debugger, azaz lépésenként nem lehet futtatni, töréspontokat elhelyezni, változók értékeit vizsgálni. Mármint automatikus módon. Amit lehet csinálni, az az, hogy megsaccolni, hol a hiba, és ezután a megfelelő helyeken a megfelelő változók értékeit kiíratni (akár echo, print_r vagy var_dump segítségével). Ha az adott helyen az elvárható érték adódik, akkor lehet továbblépni. A módszer működik, bár kissé favágás jellegű.

Persze nem én vagyok az első felhasználó, aki ezzel a problémával szembesül. A Zend cég kínál PHP IDE-t, a megfelelő áron. Itt csak az árral volt a probléma (a kalózkodással kíméljetek, valószínűleg én is szoftveres leszek, ezután illene, hogy én azért gondoskodjak a legális szoftverhasználatról a lehetőségeken belül).

Léteznek ingyenes megoldások is, de ezek többnyire a szolgáltatások terén hagynak kívánnivalót maguk után. De most végre sikerült találnom egy megoldást (több helyen kifejtve az interneten Setting up Eclipse PDT and XDebug Debugging PHP5 with Eclipse PDT under OSX: a piece of cake!), az Eclipse rendszer megfelelő beállítását.

Bevezetés

Gondolom, többekkel előfordult már, hogy volt egy olyan PHP-kódja, ami valami miatt nem az elvárható eredménnyel futott le. Ilyenkor nincs mit csinálni, lehet debuggolni. És ekkor szembesül az ember azzal, hogy az nem lesz olyan egyszerű…

A legegyszerűbb PHP-telepítésnél nincs debugger, azaz lépésenként nem lehet futtatni, töréspontokat elhelyezni, változók értékeit vizsgálni. Mármint automatikus módon. Amit lehet csinálni, az az, hogy megsaccolni, hol a hiba, és ezután a megfelelő helyeken a megfelelő változók értékeit kiíratni (akár echo, print_r vagy var_dump segítségével). Ha az adott helyen az elvárható érték adódik, akkor lehet továbblépni. A módszer működik, bár kissé favágás jellegű.

Persze nem én vagyok az első felhasználó, aki ezzel a problémával szembesül. A Zend cég kínál PHP IDE-t, a megfelelő áron. Itt csak az árral volt a probléma (a kalózkodással kíméljetek, valószínűleg én is szoftveres leszek, ezután illene, hogy én azért gondoskodjak a legális szoftverhasználatról a lehetőségeken belül).

Léteznek ingyenes megoldások is, de ezek többnyire a szolgáltatások terén hagynak kívánnivalót maguk után. De most végre sikerült találnom egy megoldást (több helyen kifejtve az interneten Setting up Eclipse PDT and XDebug Debugging PHP5 with Eclipse PDT under OSX: a piece of cake!), az Eclipse rendszer megfelelő beállítását.

Rövid összegzés

Azok kedvéért, akik vagy nagyon értenek hozzá, vagy csak bizonyos részek érdeklik őket, álljon itt egy rövid összefoglaló a lépésekről (a lépéseket természetesen nem feltétlen ebben a sorrendben kell végrehajtani, de érdemes pl. az Eclipse-et feltelepíteni, mielőtt össze akarod kapcsolni az XDebug-gal 🙂 ):

  • Alapvető PHP környezet beállítása
  • XDebug telepítése a PHP-hoz
  • Az Eclipse PDT projekt telepítése
  • Az Eclipse-hez XDebug plugin telepítése
  • Egyéb nyalánkságok

Feltételezések

Annak érdekében, hogy a cikk olvasható maradjon, és ne tegyen ki kisebb könyveket, bizonyos feltételezésekkel élek az olvasó ismereteire vonatkozóan:

Az alapvető PHP környezet telepítését nem részletezném. Ha gondot okoz, akkor nem javaslom a cikk további olvasását sem, ugyanis az Eclipse nem egy könnyen megtanulható, egyszerű eszköz, és a megfelelő beállítás szintén gondot okozhat. Esetleg ha feltétlen ragaszkodsz hozzá, léteznek olyan csomagok, amik egyben tartalmaznak Apache-ot, PHP-t és MySQL-t (pl. MAMP, WAMP, LAMP, stb.). A cikk további részében feltételezem továbbá, hogy a php.ini szerkesztése (megtalálása) nem okoz gondot.

Nincs módom/időm az összes elérhető rendszeren és verzióval tesztelni a környezetet, így csak korlátozott tapasztalatokat tudok megosztani. Az íráskor az Eclipse Core pluginek a jelenlegi legfrissebb, 3.3-as verzióval futnak, a PHP 5.2-es verziójú Apache (2.2.4) modulként futtatva. Az XDebug a 2-es verziónál tart (helyenként 0.2-esként hivatkoznak rá). A saját rendszerem Mac OSX 10.4 alapon fut, és erre a fent említett programok általam lettek lefordítva. A debugger ezen a rendszeren tökéletesen működött, gondot nem tapasztaltam.

PHP és XDebug

Az XDebug telepítése érdekesebb kérdés – szükség van egy lefordított modulra belőle – Windowsra és Linuxra van belőle a hivatalos XDebug oldalon, legalábbis bizonyos PHP verziókhoz, ha más platformon futtatod (mint én az OSX-szel), vagy nem megfelelő a PHP verzió, akkor lehet fordítani, vagy esetleg a Komodo IDE-jébe befordított változat is használható, amint az egyik OSX-es forrás is ajánlja. A fordítással kapcsolatban volt egy félmondatos megjegyzés, hogy azért nem azt követi, mert állítólag ahhoz a PHP-t (és azzal együtt az Apache-ot is) le kellene fordítania.

Erre én nagy bátran arra gondoltam, hogy mivel úgyis MacPorts-sal (korábban DarwinPorts) telepítettem fel a rendszert, és ezáltal lefordítottam, gondoltam, bátor leszek, és lefordítom inkább forrásból, minthogy egy harmadik gyártó programját kelljen használni, vagy hogy másik fizetős szoftvert telepítsek ezért a gépemre (pontosabban a demóját). Még egyszer: Linuxra és Windowsra van bináris változat is, azokat lehet használni, csak arra kell ügyelni, hogy a saját PHP verziónkhoz való változatot töltsük le.

Ha megvan a bináris változat, akkor jöhet a bűvészkedés a php.ini fájllal. A következő néhány sort kell beszúrni a fájlba: zend_extension=/xdebug/bináris/elérési/útja/xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000. Ha ez megvan, akkor újraindítandó a szerver (feltéve, hogy a php apache modulként van telepítve). Ezután a phpinfo lekérésével (akár parancssorból a php -i -vel, akár pedig a phpinfo(); parancs meghívásával egy scriptfájlban) az elején, amikor a Zend Engine verzióját kiírja, meg kell, hogy jelenjen az XDebug verziója is. Esetleg a php -m paranccsal a modulok listájában is meg lehet keresni az XDebug modult (mind a modulok, mind a Zend modulok között szerepelnie kell). Az említett módszerek közül bármelyikre elegendő megvizsgálni, nincs szükség az összes vizsgálat végrehajtására. Ha megvan, örülhetünk. Ha nem, akkor jöhet a vadászat, hogy mit rontottunk el. Ilyen esetekben némi segítséget jelenthet a hivatalos XDebug oldalon található dokumentáció.

A telepített XDebug megjelenik a phpinfo()-ban

Megjegyzés:Windows felhasználók esetén a lefordított bináris nem .so, hanem .dll kiterjesztéssel rendelkezik, és érdemes lehet a php bővítményei közé rakni (de természetesen ez nem kötelező); valamint a fájlnevet is megfelelően módosítani kell.

Abban az esetben, ha rossz XDebug binárist kaptunk, itt elképzelhető, hogy a PHP nem indul el – velem előfordult. A fordítás során ugyanis egy gusztustalan hibába futottam: sikerült 4.3-as PHP-hoz lefordítanom az XDebug-ot, és ez az 5.2-es PHP-val nem működik együtt, méghozzá olyan szinten, hogy a PHP el sem indult, hanem mindenféle különös hibaüzenetet dobált. Hogy ez hogyan jött elő? Az OSX 10.4 gyárilag tartalmaz egy 4.3-as PHP-t, amit elég nehézkes eltávolítani a rendszerből, ezért inkább MacPortsszal mellételepítettem az 5.2-es változatot. Ugyanakkor a fordításkor egyéb paraméterek megadása nélkül a 4.3-ast találta meg. Amikor a fordításkor megfelelő paraméterrel megadtam az 5.2-es PHP elérési útját, az így kapott binárissal rögtön elindult a PHP.

Eclipse

Mi is az az Eclipse? Egy teljesen nyílt IDE (gyengébbek kedvéért: integrált fejlesztői környezet). Nyílt azért is, mert teljesen nyílt forráskódú, és azért is, mert pluginalapú. Ez azt jelenti, hogy ha egy másik nyelvhez akarsz fejlesztői környezetet használni, azt ugyanúgy el lehet készíteni az Eclipse IDE felett, és ugyanazokat az elemeket képes is használni (például az Eclipse PDT-vel együtt feltelepülnek azok a pluginek is, amivel a Java fejlesztést lehet végezni). Mindezek felett az Eclipse Java nyelven íródott, ezért nagyszerűen egyforma (lassan) működik az összes nagyobb operációs rendszeren (persze a gépigénye megvan, rengeteg memóriát eszik például).

Netes bogarászás alapján az Eclipse PDT (Php Development Tool) plugincsomag kellően jó választásnak tűnik. Ha korábban nem volt telepített Eclipse és csomagkezelőből sem tölthető le akár mert az operációs rendszerhez nincs csomagkezelő (pl. Windows), akár mert az elérhető csomagkezelő nem tartalmazza (pl. OSX-en a MacPorts), akkor legegyszerűbb a
PDT Project oldaláról lehúzni. Egyébként a frissítések között is megadható az http://download.eclipse.org/tools/pdt/updates/ URL, és azon keresztül is telepíthető. Ez használható a Linuxon csomagkezelőből telepített Eclipse esetén is (a beépített frissítések egyébként a Help menü Software Updates pontja alatt érhető el – a lehető leglogikusabb hely a funkcióhoz :-p). Az Eclipse csomagkezelőjét használó funkciót nem teszteltem, de Balage tapasztalatai alapján a 3.2-es core modulokkal nem működik, 3.3-assal nem sikerült tesztelnie.

Léteznek egyéb PHP kiterjesztések is az Eclipse rendszerhez, de azok vagy abbamaradtak (pl. a PHPEclipse csomag utolsó kiadása 2005-ös), vagy még nem jutottak el egy bizonyos érettségi fokra. Természetesen a PDT Project sem jutott fejlődésének csúcspontjára, de előnye, hogy a PHP-t támogató Zend (is) mögötte áll, és arra készül, hogy az egész platformját átírja Eclipse alapra, miután a projekt megfelelő szintre eljutott.

Maga a telepítés teljesen magától értetődő, nem is fektetnék rá nagyobb hangsúlyt.

Eclipse és XDebug

Módosítás: 2007. szeptember 26-án.

Na, ez szép fázis. Az Eclipse PDT jelen helyzetben nem támogatja beépítve az XDebug-ot. Persze nincs semmi veszve, hisz az Eclipse pluginelhető rendszer, és a feladathoz létezik plugin. Ezt az Eclipse plugint kell még telepíteni az azEclipse Bugzilla-ról (a tervek szerint ez a funkció később bekerül az Eclipse PDT-be, de az még arrébb van). A megfelelő verzió választása itt is fontos lehet. Fontos: nem véletlenül nincs más helyen letölthető verzió. Szerencsére az Eclipse pluginek telepítése és eltávolítása egyaránt egyszerű művelet: bemásolás az Eclipse pluginkönyvtárába a pluginkönyvtár a telepített Eclipse struktúrában könnyen megtalálható, illetve eltávolítás ebből a könyvtárból. Természetesen eközben célszerű, ha maga az Eclipse nem fut, vagy ha mégis, akkor a változások érvényre juttatásához újra kell indítani. Természetesen ez a plugin nem érhető el egyelőre az Update Manageren keresztül.

Nekem ez a rész teljesen simán működött, a plugin létrehozta a szükséges új View-kat, beállítópanel(rész)eket. De mivel ez még nem hivatalos plugin, nem biztos, hogy mindenhol tökéletesen működni fog, óvatos kezelést igényel.

A 2007. szeptember 17-én megjelent Eclipse PDT már beépítve tartalmazza az XDebug-on keresztüli debuggoláshoz szükséges plugineket – és megváltoztatták a módot is, ahogy XDebug-os debug session-öket lehet létrehozni. Mostantól nem külön debugtípus az XDebug-on keresztüli, hanem a debug mód egyik paramétere a választott debugger.

Ha korábban az én írásom alapján állítottad össze a rendszert, és használtad a debuggert, és hagytad az Eclipse-nek, hogy frissítse magát, akkor azt vehetted észre, hogy mindenféle hibaüzenet nélkül megszűnik a debuggolás, a töréspontoknál nem áll meg futás közben, stb.

A probléma megoldására két megoldás van: az egyszerűbb az, hogy eltávolítod a meglevő Eclipse-et, és újratelepíted az új verziót (ezzel biztosan eltűnik minden hivatkozás az időközben elavulttá vált Bugzillán közölt pluginre), vagy ha nagyon profi vagy, akkor megpróbálhatod kézzel kihackelni a pluginek közül a kapcsolódó részeket.

Ha ezzel is megvagy, akkor már (elvileg) van egy teljesen működőképes PHP-debuggolásra alkalmas fejlesztői környezeted.

Amikor persze a Debug-ot meghívod, figyelni kell rá, hogy a felajánlott lehetőségek közül azokat válaszd, amiknek a nevében XDebug van – a másik másfajta debuggerhez való.

Egyéb nyalánkságok

Természetesen a lehetőségek itt még messze nem merültek ki. Például az Eclipse-et könnyű rávenni arra, hogy CVS vagy SVN verziókezelő rendszerrel szinkronizálja a projektet. A CVS támogatás a legtöbb Eclipse-verzióban benne van (konkrétabban én még nem láttam olyat, amiben ne lenne benne 🙂 ). Az SVN-hez legegyszerűbb a Subclipse plugin letöltése. Részletes telepítési útmutató a projekt oldalán található. A használata elsőre furcsa lehet (a Workspace view-ban a Project jobb gombos menüjében a Team menüben találhatóak az ehhez tartozó részek).

Hasznos lehet, ha a PHP projekt olyan mappába kerül, amit a webszerver is lát. Ez Eclipse alatt kis fejtörést igényel, ugyanis az Eclipse workspace alapon működik – viszont a workspace mappát nem (feltétlenül) érdemes a helyi gépen levő webszerver elérhetőségébe tenni. Én azt csináltam, hogy a workspace-t a saját mappámban hoztam létre, míg amikor ezen belül projekteket hoztam létre, azoknál gondoskodtam róla, hogy az Apache által kezelt mappába jöjjön létre a megfelelő mappa (ez az új projekt varázsló egyik pontjánál elérhető szolgáltatás, alapértelmezetten le van tiltva).

Az aktuális projekthez tartozó debug útvonalakat (pl. a felparaméterezett index-fájl, stb.) érdemes felvenni a rögzített debug módok listájára, sokkal gyorsabban felhasználható, különösen, ha hozzám hasonlóan olyan url-en keresztül érhető el a php-fájl, amit az Eclipse nem jól „tippel” meg.

Azok a bizonyos utolsó szavak

Balage volt olyan kedves, hogy a cikk egy félkész változatát tesztelte a Kubuntu Linux-án. A tapasztalata szerint a rendszer csomagkezelője által telepített 3.2-es Eclipse-core nem volt kompatibilis a linken elérhető Eclipse PDT-vel, az Eclipse honlapjáról letölthető változat meg nem igazán akart futni (pl. üres splash screen, csomagkezelője első nekifutásra kifagyott). Nem is sikerült megoldani így a gondot. Azoknak, akik hasonló cipőben járnak, tudom ajánlani az EasyEclipse PHP módját. Lényegesen egyszerűbben telepíthető, mint a teljes Eclipse csomag, benne van többek között a Subclipse plugin is, és nagyobb hangsúlyt fektetnek a kompatibilitásra, ugyanakkor ezért a rugalmasságban kell fizetni: nem biztos, hogy bármely Eclipse plugin gond nélkül együttműködik vele, illetve csak csomagként lehet frissíteni tudomásom szerint. Én ezt sem teszteltem, de Balage-nál megoldotta a gondokat.

És végül egy bizonyos „copyright” célú megjegyzés: az csak a véletlen műve, hogy nem olyan régen János egy hasonló témájú írást jelenített meg az oldalán: PHP fejlesztői környezet berendezése. Nem használtam fel semmit az írásából, nem a Zend debuggerét használtam fel. Erre két okom is volt: nem rajongok a csak egy dll/so formátumban terjesztett megoldásért teljesen nyílt rendszer összerakásakor (ugyan nem nézem meg a forrást, de csak megnyugtatóbb, ha én fordítom le… az meg már tényleg csak mellékes, hogy a Windows-nál is zártabb OSX felett építem fel ezt a rendszert… 🙂 ), valamint én ehhez találtam leírást. Az meg már csak hab a tortán, hogy ezzel elméletben remote debuggingra is lehetőség van, de ezt már végképp nem használom ki.

Sok sikert mindenkinek a rendszer használatához, ha van, aki megosztja a tapasztalatait, örömmel venném, ha kiegészíthetném vele ezt a leírást.

Programok összehangolása OSX alatt

Megvan már egy ideje, hogy Mac-et használok. A múltkor is, amikor ismét próbálkoztam a Windows-zal (lásd a cikket a Macre telepítéséről), már erőteljesen érzékelhető volt a különbség. Az, hogy a Mac működik, a Windows meg nem.

A helyzet még durvább, ha azt is figyelembe vesszük, hogy az Apple segített azoknak, akiknek egy egyszerű szolgáltatás hiányzik egy programból. Nekem például az iTunesszal volt egy-két problémám.

Több rendszer még több programját kipróbáltam korábban, és mivel az a szokásom, hogy szinte állandóan zenét hallgatok, szeretem időnként megnézni, hogy áll a zenelejátszás. Ugyanakkor az ellen sincs kifogásom, ha ehhez nem kell túl sokat kattintgatnom, stb.

Megvan már egy ideje, hogy Mac-et használok. A múltkor is, amikor ismét próbálkoztam a Windows-zal (lásd a cikket a Macre telepítéséről), már erőteljesen érzékelhető volt a különbség. Az, hogy a Mac működik, a Windows meg nem.

A helyzet még durvább, ha azt is figyelembe vesszük, hogy az Apple segített azoknak, akiknek egy egyszerű szolgáltatás hiányzik egy programból. Nekem például az iTunesszal volt egy-két problémám.

Több rendszer még több programját kipróbáltam korábban, és mivel az a szokásom, hogy szinte állandóan zenét hallgatok, szeretem időnként megnézni, hogy áll a zenelejátszás. Ugyanakkor az ellen sincs kifogásom, ha ehhez nem kell túl sokat kattintgatnom, stb.

Windows-on a Winampnál, Linuxon az Amaroknál elég volt a kis ikonjára ráhúzni az egeret, és rögtön kaptam egy feliratot arról, hogy mit játszik éppen, esetleg még arról is kaptam információt, hogy mennyi ideig játssza még az aktuális számot. Nem is beszélve arról, hogy mindkét program képes rá, hogy számváltáskor dobjon egy üzenetet, és ez rövid ideig jelenjen meg, majd automatikusan tűnjön el.

Na, az iTunes ezekre önmagában nem képes. Nincs egységes notification interfész az OSX-be integrálva, más kérdés, hogy helyette van a kvázi-szabványos, nyílt forrású notification-program, a Growl. Amennyire látom, egyre több OSX-es alkalmazásfejlesztő foglalkozik azzal, hogy Growl értesítéseket használjon, köztük kereskedelmi termékek is. Nem lepődnék meg, ha idővel az Apple saját szoftverei is elkezdenék használni.

De addig is, amíg ez nem következik be, a Growl fejlesztői elkészítettéka saját Growl-pluginjeiket a legtöbb alkalmazáshoz: az iChathez, az iTuneshoz és több máshoz is. Az iTunes-plugin pontosan arra képes, hogy üzenjen, ha új szám kezdődik.

Ezzel félig megvagyunk, a másik problémára csak trükkösebb megoldás képzelhető el. Ugyanis ezt még nem igazán csinálták meg korábban. De azért egy magamfajta kockafejnek ez azért nem jelentett igazi kihívást – pláne, hogy a megoldás nagyjából már megvolt a weben is. Sajnos egy jó ideje, hogy megtaláltam, akkor is nehezen, így nem tudom megmondani a forrását a megoldásnak, de ha megtalálom, utólag is be fogom illeszteni. Addig is névtelenül tisztelem meg azzal, hogy felhívom a közönség figyelmét, hogy a megoldás elve nem az enyém.

Tehát, a megoldás lényege az volt, hogy írni kell egy Applescript scriptet (szóismétlés ruley 🙂 ), ami értesíti a Growlt az aktuális szám adatairól, majd ehhez be kell állítani egy gyorsbillentyűt globális triggerként.

A globális trigger relatíve egyszerű eset volt nekem, aki már korábban úgyis használt Quicksilvert. A Quicksilver egy productivity app OSX-re (bár valahol olvastam, hogy már van Windows-os változata is), ami többek között alkalmazásgyorsindító (OSX-en szükség is van rá, ugyanis a Dock-on korlátozott számú ikon fér el, az Applications foldert megnyitni, és abban keresni körülményes, a Spotlight kereső pedig erre a célra lassú), és mellesleg egyéb lehetőségeket is kínál, például gyors levélírás a címjegyzék és a levezelőprogram felhasználásával vagy, amit most ki fogok használni, gyorsbillentyű hozzárendelése szinte bármihez (többek között Applescriptekhez is). A program egyébként tartalmaz iTunes modult is, amivel mellesleg az iTunes vezérlése is könnyedén megoldható.

Az Applescript pedig egy nagyon egyszerű, magas szintű nyelv, majdhogynem angol szöveget kell leírni csak ahhoz, hogy a kívánt funkcionalitást elérjem. Például az iTunes alkalmazás megcímzése a következőképpen történik: tell application "iTunes".

Ezután szerepelt mintakód is, de nekem nem tetszett az eredmény, ugyanis az eredeti Growl-pluginhez hasonló megjelenítést ért el, míg én Last.fm felhasználóként kicsit másfajtát vártam. Ezután kis testreszabás következett, meg persze Applescript dokumentáció böngészés (igen, ilyen is van és használható) után a következő végső kódot produkáltam (megosztom, mondván talán másnak is hasznos lesz.

tell application “System Events” to
if (application processes whose name is “iTunes”) is not {} then
log
tell application “iTunes”
if player state is playing then
set trk to current track
set trk_arts to the artist of trk
set trk_name to the name of trk
set trk_albm to the album of trk
set trk_dur to the time of trk
–Artwork
if (count of artwork of trk) ≥ 1 then
set trk_artwk to data of artwork 1 of trk
tell application “GrowlHelperApp”
set the allNotificationsList to ¬
{“Show Status”}
set the enabledNotificationsList to ¬
{“Show Status”}
(register as application ¬
“iTunesScript” all notifications allNotificationsList ¬
default notifications enabledNotificationsList ¬
) notify with name “Show Status” title trk_name description trk_arts & ”
” & trk_albm & ”
” & trk_dur application name “iTunesScript” pictImage trk_artwk
end tell
else
tell application “GrowlHelperApp”
set the allNotificationsList to ¬
{“Show Status”}
set the enabledNotificationsList to ¬
{“Show Status”}
register as application ¬
“iTunesScript” all notifications allNotificationsList ¬
default notifications enabledNotificationsList ¬
icon of application “iTunes”
notify with name “Show Status” title trk_name description trk_arts & ”
” & trk_albm & ”
” & trk_dur application name “iTunesScript”
end tell

end if
end if
end tell
end if
Az OSX rendszer egy nagy előnye, hogy viszonylag sokféle library-t kifejlesztett az Apple, ezek után a programozók elkezdhetnek a hozzáadott értékekkel foglalkozni, mint amilyen az alkalmazások közötti kommunikáció. Ez a rendszeren látszik. Természetesen az én megoldásom, mivel nem a háttérben, hanem a felhasználó segítségével történik, nem a legelegánsabb megoldás, de ez nem von le semmit az értékéből. A módszer használható, pár óra alatt össze lehetett hozni a dolgot minta alapján, és ha az embernek extra igényei vannak, elég részletes dokumentáció, és ügyes Applescript-készítő program áll a rendelkezésére.

Végeredmény: egy újabb jól használható pont azok számára, akik szeretik a végletekig testre szabni a rendszerüket, de nem kívánnak túl mélyen belefolyni a részletekbe, forrásba (tudom, Linux alatt is el lehet érni frontend megoldásokkal ugyanezt a hatást, mielőtt valaki kötözködne, de sokkal több munkát igényel). Nem véletlen használnak egyre többen OSX-et desktop operációs rendszernek.