Magyar (In Hungarian) – Page 9

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

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.

Soha ne figyelmeztess, ha a visszavonás is elegendő!

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Tapasztaltad már azt a lehangoló érzést, ami akkor tölt el, amikor rájöttél – egy másodperccel később a kelleténél – hogy nem kellett volna OK-t válaszolnod a „Biztosan ki akar lépni?” kérdésre?

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

Igen? Nos, jó társaságban vagy – mindenkinek volt már hasonló tapasztalata, így nincs miért szégyenkezned. Nem a te hibád: a szoftvered hibája.

Soha ne figyelmeztess, ha a visszavonás is elegendő!
Miért? Mert a szoftvernek tudnia kellene, hogy szokásokat veszünk fel. Tudnia kellene, hogy azután, hogy számtalanszor válaszolunk OK-val a kérdésre, feltehetőleg akkor is az OK-t választjuk, ha nem arra gondoltunk. És azt is tudnia kellene, hogy nem lesz lehetőségünk gondolkodni, mielőtt véletlenül eldobjuk az egész munkánkat.

Miért kellene tudnia a szoftvernek ezeket a dolgokat? Mert a szoftvertervezőknek is tudniuk kellene, hogy szokásokat veszünk fel, akár akarjuk, akár nem.

A szokások felvétele tulajdonképpen egy jó dolog: segít megkímélni minket annak a gondjától, hogy gondolkodni kelljen, amikor az interfész bosszantó apróságaival találkozunk és csökkenti a valószínűségét, hogy a gondolatmenetünk eltérül. A „Biztosan ki akar lépni?” kérdésre a kezünkben van egy memorizált kattints-és-zárd-be folytonos folyamat. Ez jó, mert a legtöbb esetben nem akarunk gondolkodni a kérdésről – csak a jó dolgot csináljuk. Szerencsétlen módon, a szokásaink időnként félrevezetnek: nem lesz időnk rájönni a hibánkra, amíg meg nem csináltuk.

Így a tervezők számára egyenes út vezet az általános felhasználói felülettervezési elvhez: Ahhoz, hogy egy felhasználói felület emberi legyen, figyelembe kell vennie a szokások kialakulását.

Lehetséges megoldások

Mi lenne, ha a figyelmeztetést nehezebb lenne figyelmen kívül hagyni? Egy diszkrét figyelmeztetés felett könnyű átugrani, így vegyük elő a teljes eszköztárat: villogtatjuk a képernyőt és egy hangos, idegesítő zajt játszunk le annak érdekében, hogy biztosítsuk a felhasználói figyelmet. Próbálkozhatunk, ahogy tetszik, továbbra sem fog működni. Minél tolakodóbb a figyelmeztetés, annál gyorsabban meg akarunk szabadulni tőle (az OK-ra kattintva) és annál többször fogunk hibázni. A gond az, nem számít, mennyire tolja a képünk elé a figyelmeztetést a szmítógép, mi ugyanazt a hibát fogjuk elkövetni: akkor is az OK-ra kattintunk, ha nem azt akartuk. De ez még mindig nem a mi hibánk: addig, amíg szokások felvételével figyelmen kívül lehet hagyni a hibaüzenetet, felvesszük a szokásokat, azután pedig hibázni fogunk.

Mi lenne, ha a figyelmeztetést lehetetlen lenne figyelmen kívül hagyni? Ha a szokások okozzák a problémát, miért nem tervezzük úgy meg a felületet, hogy ne lehessen szokásokat felvenni? Így mindig rá leszünk kényszerítve, hogy gondolkodjunk a válaszadás előtt, és így mindig azt válaszoljuk, ami választ mi szeretnénk. Ez megoldja a problémát, nem?

Ez a fajta gondolkodás nem új: ez az írd-be-az-n-edik-szót-ebből-a-mondatból-a-folytatáshoz megközelítés. Például a Guild Wars játékban ahhoz, hogy egy karaktert töröljünk, először a „Törlés” gombra kell kattintani, majd a karakter nevét be kell írni megerősítésként. Sajnálatos módon ez nem mindig működik. Pontosabban:

Arra kényszerít minket, hogy koncentráljunk a szokatlan feladatra és nem arra, hogy tényleg el akarjuk-e dobni a munkánkat. Így a nem figyelmen kívül hagyható figyelmeztetés se sokkal jobb, mint a teljesen átlagos: mindkét esetben végeredményben elveszik a munkánk. Ez (a munka elvesztése) az elképzelhető legnagyobb bűn a szoftver világában.
Figyelemre méltóan idegesítő, és mert mindig szükséges a figyelem, szükségszerűen elterel minket a munkánkról (ami a második legnagyobb szoftver-bűn).
Mindig lassabb és több munkát igényel, mint egy egyszerű figyelmeztetés. Ezzel elköveti a harmadik legnagyobb bűnt – azzal, hogy több munkát igényel tőlünk, mint az szükséges.

A Guild Wars-os példánkban a második és harmadik pont nem túl lényeges, mert a karakterek törlése elég ritka esemény. De ha be kellene írni a dokumentum nevét, mielőtt mentés nélkül kiléphetnénk, nagyon megterhelőnek éreznénk.

Mit tanultunk? Azok a felületek, amik nem veszik figyelembe a megszokást, nagyon rosszak. A figyelmeztetés nagyobbá, hangosabbá és nem-figyelmen-kívül-hagyhatóvá tétele nem működik; akárhogy is nézzük, a figyelmeztetések egy nagy, sötét csapdát jelentenek az interfészben. Inkább szabaduljunk meg a figyelmeztetésektől.

A mentőöv: visszavonás

Ha csak simán eltávolítjuk a figyelmeztetéseket, nem mentjük meg a munkánkat a végzettől, de ha egy „visszavonási” lehetőséget beteszünk, akkor már igen. Hadd ismételjem meg: a figyelmeztetéses nyomorúságunkra a visszavonás a megoldás. Egy kellően robosztus visszavonással akár nemtörődöm módon is bezárhatjuk a munkánkat tudva, hogy mindig visszanyerhetjük. A visszavonással ezt a szörnyű „Hoppá!” érzést eltüntethetjük a munka visszaszerzésévelA „Hoppá!”-tényező egy Laura Creighton-nal folytatott megbeszélés alapján született meg..

Mivel szokásokat veszünk fel, soha nem fogjuk tudni garantálni, hogy nem lesz ilyen „Hoppá!” pillanatunk. Ezzel szemben a tervezőknek tudomásul kell venniük, hogy meg fog történni, és ennek megfelelően tervezni. Ahányszor csak megvan a lehetősége, hogy eldobjuk a munkánkat, a számítógépnek lehetővé kell tennie, hogy visszacsináljuk a dolgokat.

Ez elvezet minket az egyik legalapvetőbb és legfontosabb felülettervezési mantrához: Soha ne figyelmeztess, ha a visszavonás is elegendő!

A Google Mail egy jó példája ennek a mantrának. Ha törölsz egy e-mailt, azonnal ad lehetőséget arra, hogy visszavond ezt a lépést. Milyen felhasználóbarát! Ezzel ügyesen kikerüli a figyelmeztetések kérdését (csakúgy, mint a visszavonás láthatóságát). Ha hibázunk (ami elő fog fordulni), nem kerül túl sokba, mert egyszerűen visszavonhatjuk. A visszavonással kevesebbet aggódunk és több időt dolgozunk.

1. ábra: Még nincs túl késő. A Gmail lehetővé teszi, hogy visszavonjuk a törlést.

Természetesen ez csak egy rétege a visszavonhatóságnak – és Gmail ennél tovább megy. Ha törölsz egy levelet, az nem veszik el örökre… ott van a kukában, hogy visszaállíthasd, ha később úgy döntesz, mégsem akartad törölni.

Sajnos, ezt a leckét a Google Calendar még nem tanulta meg. És, ahogy megjósolható volt, töröltem már olyan eseményeket, amit nem akartam. Sokszor a rossz eseményt töröltem, ami különösen rossz, mert ekkor abban sem vagyok biztos, hogy mit töröltem. Visszavonás nélkül nincs is rá mód, hogy kitaláljam.

Google Calendar figyelmeztetőablaka: Biztos, hogy törölni akarod az
2. ábra: Légy óvatos! A Google Calendar nem engedi a téves törlések visszavonását.

Tulajdonképpen még Google Mail sem mindig használja ezt a módszert. Ha egy címkét törölsz, már jön is egy ilyen figyelmeztetés. Miért van az, hogy Google ilyen jól megcsinálja egy helyen, és alig néhány kattintással arrébb meg ilyen rosszul? Talán mert ez a figyelmeztetés alapú gondolkodás annyira beágyazódott, hogy hősies erőfeszítéseket igényel a meghaladása. Még olyan cégek is, amelyek egyébként a jó tervezés védőbástyái (ilyen a 37Signals), ezt nagyon rosszul csinálják.

Highrise figyelmeztetés: Biztos, hogy törölni akarod ezt a feladatot?
3. ábra: A Highrise, a 37Signals alkalmazása is figyelmeztet visszavonási lehetőség nélkül

Figyelmeztetések használata a visszavonás helyett a legkisebb ellenállás felé mozdulás útja a programozó szemszögéből, és nem igényel különösebben újító gondolkozást a tervező nézőpontjából. De ez nem mentség a számítógépeink számára, hogy nem emberi módon gondolkodnak.

Következtetés

A figyelmeztetések miatt elveszíthetjük a munkánkat, bizalmatlanok leszünk a számítógépekkel szemben és magunkat hibáztatjuk. Egy egyszerű, de bolondbiztos tervezési módszertan megoldja a problémát: „Soha ne figyelmeztess, ha a visszavonás is elegendő!” És ha a felhasználó törli a munkáját, mindig elegendő.

Ó, és a következő alkalommal, amikor azt látod, hogy figyelmeztetnek a visszavonás helyett, küldj az alkalmazás/weboldal tervezőjének egy kedves e-mailt, amiben javaslod, hogy inkább implementáljanak egy „visszavonás” funkciót. Küldj nekik egy linket erről a cikkről. Nézzük meg, meg tudjuk-e változtatni annak a módját, ahogy az emberek a webre terveznek – és ebben a folyamatban mindenki számítógépes életét egy kissé emberközelibbé és kevésbé frusztrálóvá tegyük. Kezdődjön a háború a figyelmeztetések ellen!

Illusztráció: Kevin Cornell

A szerzőről

Aza először 10 éves korában a SIGCHI helyi, san franciscoi székházában beszélt a felhasználói felületekről, és a rabjukká lett. 17 évesen nemzetközi megbeszéléseken és konzultációkon vett rész; 19 évesen egy fizikakönyv társszerzője lett, mert túl fiatal volt, hogy alkoholt vegyen; 21 évesen elkezdett inni, és társalapítója a Humanized-nek. Aza szeret játszani a kürtjén és a laborjában tenni-venni, ha az ideje engedi.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2007. július 13-a óta elérhető itt.

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.

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.

Suckerfish menük

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2003. november 7. óta elérhető itt.

A „DHTML” legördülő menük maguk után vonták az otromba, böngészőspecifikus hackelésekkel teletömött Javascript kódokat, amik az egyébként elegáns, szemantikus HTML kódot meglehetősen hozzáférhetetlenné A hozzáférhető/hozzáférhetetlen fogalmakon a webtervezői szókincsben megfelelő accessibility kifejezést értem. teszik. Ó, azok a pehelykönnyű, hozzáférhető, szabványos, böngészőfüggetlen módszerek! Tekintsd meg a Suckerfish Suckerfish: Brehm és Wikipedia alapján rövidszárnyú bojtorjánhal. Ez a hal a Gályatartóhal-félék családjába tartozik. Ezek a halak már az ókorban is ismertek voltak a Földközi-tenger vidékén, a halak különlegessége, hogy más halakhoz, esetenként hajókhoz kapcsolódtak, velük vitették magukat. Konkrétan a bojtorjánhalról Brehm ezt írja: „Elterjedésének határa valószínűen egybeesik a kardoshalakéval, mivel többedmagával ezekre tapadva viteti magát. (Brehm: Az állatok világa) menüket!

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk 2003. november 7. óta elérhető itt.

Először a HTML

Először is, válasszuk a legjobb módszert a menü leírásához — egy listát. Példánkban egy egyszerű HTML sorszámozás nélküli listát használunk.

<ul>
  <li>Sunfishes

    <ul>
      <li><a href="">Blackbanded sunfish</a></li>
      <li><a href="">Shadow bass</a></li>
      <li><a href="">Ozark bass</a></li>
      <li><a href="">White crappie</a></li>
    </ul>

  </li>

  <li>Grunts

    <ul>
      <li><a href="">Smallmouth grunt</a></li>
      <li><a href="">Burrito</a></li>
      <li><a href="">Pigfish</a></li>
    </ul>

  </li>

  <li>Remoras

    <ul>
      <li><a href="">Whalesucker</a></li>
      <li><a href="">Marlinsucker</a></li>
      <li><a href="">Ceylonese remora</a></li>
      <li><a href="">Spearfish remora</a></li>
      <li><a href="">Slender suckerfish</a></li>
    </ul>

  </li>
</ul>

Tényleg eléggé magától értetődő — tiszta és elegáns HTML, ami a hozzáférhetőséget biztosítja. De ezt most átalakítjuk egy dinamikus listává — a listaelemek első szintje egy vízszintes menüsávot fog alkotni, ebből fognak legördülni a második szintű listák.

Formázzuk meg!

Kezdésként minden listaelemet piszkáljunk meg egy kicsit — nevezetesen a margót és kitöltést nullára állítjuk, a listaelemek jelzését pedig kikapcsoljuk:

ul {
  padding: 0;
  margin: 0;
  list-style: none;
  }

A következő lépésben a lista első szintjét átalakítjuk egy vízszintes menüsávvá. Többféle technika van erre, amiket máshol részletesebben kifejtenek. Megjelölhetnénk az elemeket a display: inline; jellemzővel, de ebben a példában inkább balra lebegtetjük őket.

li {
  float: left;
  position: relative;
  width: 10em;
  }

Az elemek helye position: relative;-ra lett állítva, mivel a beágyazott listákat az első szinthez képest relatívan helyezzük majd el, a fix (!) szélességmegadás meg azért szükséges, hogy elérjünk bizonyos méreteket. A legördülő menü lassan összeáll.

Ezek után nézzük a lista második szintjét, ami a tényleges legördülő menü lesz:

li ul {
  display: none;
  position: absolute;
  top: 1em;
  left: 0;
  }

Ez a listák második szintjét abszolút módon helyezi el (kiemeli a HTML folyamból, és külön kezeli őket), és alapértelmezetten meg nem jelenítettekké állítja. Abban az esetben, ha a display: none; részt display: block;-ra cserélnénk, akkor látjuk szükségét a top és a left értékek beállításának az Internet Explorerben, mert ezek nélkül az IE a második szintű listákat az ősük jobb felső sarkába helyezi a bal alsó helyett. Sajnos ez az IE megoldás elkavarja a dolgokat az Opera-hoz hasonló böngészőkben, így ezekben a következő CSS kódra van szükség a top és left paraméterek beállításához:

li > ul {
  top: auto;
  left: auto;
  }

Angolul: And now, making the sucker work. Lefordíthatatlan szójáték, az angol suckerfish névvel játszik.

És most rakjuk hozzá az összekapcsolást! Ahhoz, hogy a második listaszintet megjelenítsük, amikor az első szinten a pontok „kiválasztódnak”, egyszerűen a következő kódot kell hozzáadni:

li:hover ul { display: block; }

Ami annyit jelent, hogy bármely elem, ami egy olyan pont alatti listában szerepel, amire az egérkurzor rámutat, megjelenítendő.

Végül, mert a listaelemek balra vannak lebegtetve, a tartalmat alattuk függetleníteni kell a lebegtetéstől a clear: left formázás kijelölésével.

Várjunk egy pillanatot!

”Ez a legördülő halandzsa nem működik!” – hallom az olvasók 102,6 százalékát (vagy a legfrissebb, éppen csökkenő hányadukat) kiabálni. Igen, mint kitalálható, az Internet Explorer felhasználóiról beszélek. Minél többet használod egyszerű szörfözőként, vagy webfejlesztőként a Mozillához hasonló böngészőket, annál feltűnőbb, hogy mennyire nevetséges az Internet Explorer, ha a webes szabványokról esik szó. A :hover pszeudoosztálynak elvben minden elemre működnie kellene, de az Internet Explorerben csak a linkekre működik. Pont. Mi a haszna a legördülő menünek, ha csak a böngészők -2,6 százalékán működik? Hogy őszinték legyünk, nem sok. Egy kicsit többet kell még varázsolnunk.

A mentőöv: DOM-szkriptelés

Ugyan megállapítottuk, hogy az IE ugyan nem támogatja a :hover pszeudo-osztályt, de a Document Object Model használatával egyszerűen kapcsolhatunk egéreseményeket (mouseover, mouseout) bármilyen elemhez. Ez jó hír számunkra, mert azt jelenti, hogy egy rövid JavaScript kódocskával hatékonyan orvosolhatjuk az IE :hover gondjait.

Mivel az IE vak, ahhoz, hogy azonosítsuk a :hover pszeudoosztály tulajdonságait, más módszert kell találni. A JavaScript segítségével manipulálhatuk a className tulajdonságát egy elemnek, így először egy kicsit a CSS-t kell megváltoztatnunk:

li:hover ul{ display: block; }

helyett a következő kód használható:

li:hover ul, li.over ul{ display: block; }

Ezután meghívhatjuk a :hover CSS szabályokat a kívánt elemre, ha hozzáadjuk az over osztályt a kívánt elemhez. Szükségünk lehet továbbá arra, hogy megmondjuk az IE-nek, hogy mely UL elemek szolgálnak az oldalon legördülő menüként. Ez egy id hozzáadásával tesszük meg a listánk gyökér ul elemére:

Ezáltal a

<ul>

kódból a következő lesz:

<ul id="nav">

Most, hogy tudjuk azonosítani a gyökér ul elemét a legördülő listánknak, kiemelhetjük ezt az elemet, és végigmehetünk az összes gyerekelemén, hozzáadva a mouseover és mouseout eseményeket az összes li elemhez a belsejében. Ezt így tehetjük meg:

startList = function() {
if (document.all&&document.getElementById) {
navRoot = document.getElementById("nav");
for (i=0; i<navRoot.childNodes.length; i++) {
node = navRoot.childNodes[i];
if (node.nodeName=="LI") {
node.onmouseover=function() {
this.className+=" over";
  }
  node.onmouseout=function() {
  this.className=this.className.replace(" over", "");
   }
   }
  }
 }
}
window.onload=startList;

A lap betöltésekor a startList függvény meghívódik. Ez meghatározza, hogy a böngésző IE 5 vagy újabb a document.all objektum és a document.getElementById függvény létezésének vizsgálatával. Ez egy picit nyers megoldás, de rövid és egyszerű, és mivel mi egy kompakt megoldást szeretnénk, ez is megteszi. Ezután végiglépked a listákon, engedélyezve a mouseover és a mouseout eseményeket, amik hozzáadják/eltávolítják a over osztályt a className tulajdonságához az elemnek.

Így már működik. Probléma esetén érdemes megnézni a megjegyzésekkel ellátott példa vázat működés közben.

Kopoltyúk, uszonyok, pikkelyek…

Eddig amit csináltunk, egy kicsit meztelennek tűnik. Ez a cikk csak az ötlet alapjait mutatja be, de CSS segítségével sokkal szebben meg lehet valósítani. Egy nyilvánvaló kiindulópont lehet háttérszín hozzárendelése a második listaszinthez.

Miután visszaállítottuk a top és left tulajdonságokat, ahogy korábban leírtuk, a legördölő menük a szép példában közvetlenül a feliratok alatt jelennek meg a legtöbb modern böngészőben, de sajnos nem mindben. A Safari 1.0-ban még mindig a képernyő bal felső sarkából gördülnek le.

További használhatósági és hozzáférhetőségi gondolatok

Ha az első listaszint elemeiből hivatkozásokat csinálunk, megengedjük a tabstop használatát azon olvasók számára, akik nem használnak mutatóeszközöket. Ha sikerül olyan oldalakra mutatnunk, amik magasabb szinten vannak, mint az almenü elemei, az még jobb eredményt ad.

A szerzőkről

Patrick Griffiths egy szabadúszó londoni webtervező, aki kedveli, tiszteli a soul-t, az evolúciót és a kedves weboldalát (megjegyzés: az eredeti pet kedvencet és háziállatot egyaránt jelent), a HTML Dog-ot. Időnként becézgeti a PTG-t a hangulatától függően.

Dan Webb egy webtervező és DJ-nek is tanul. A korábbi munkái között szerepel szabványkövető, hozzáférhető oldalak és webalkalmazások megvalósítása az Egyesült Királyság kormányzati hivatalainak és emberek táncra penderítése London homályos szórakozóhelyein.

Translated with the permission of A List Apart Magazine and the author[s]. (Az A List Apart oldal és a szerző engedélyével lefordítva.)

Az eredeti cikk elérhető itt.

Firefox – Take back the field

Az amerikai Oregon állambeli Amity környékén egy gabonaföldön különleges jel került elő. A jel nagyjából kör alakú, ~67 méter (220 láb) átmérőjű, ugyanakkor egy ismerős jelet formáz: a Mozilla Firefox böngésző logóját.

Firefox gabonakör A tettesek ugyanakkor nem az UFO-k voltak, hanem az Oregon Állami Egyetem (Oregon State University) Linux-felhasználók csoportja nevű szervezete (Linux Users Group), ami főleg hallgatókból áll.

További részletes leírás, képek a itt található.

Az alkotóknak ezúton is gratulálok, és remélve, még sokan átváltanak erre a nagyszerű böngészőre (vagy ha esetleg jobban tetszik valakinek, akkor Operára).