deadlime

Talán nem túlzás azt állítani, hogy a Firebug a legjobb dolgok közé tartozik, ami manapság egy JavaScript fejlesztővel történhetnek. A több mint 10 millió letöltés, valamint a tény, hogy - bár maga is kiegészítő - kiegészítőket fejlesztenek hozzá elég bizonyítékul is szolgálhat ennek alátámasztására. Egy ilyen kiegészítőbe futottam bele még valamikor a múlt héten, ami a FirePHP nevet viseli (a nevével ellentétben bármely más szerver oldali nyelvvel használható, ami képes header-öket kiküldeni). Nincs is másra szükségünk csak egy Firefox-ra (ez remélhetőleg már mindenkinek van :)), egy Firebug-ra (ez is esélyes lehet, hogy akad a közelben) és a FirePHP-ra. Meg egy kis szerveroldali scriptre, ami szintén a FirePHP oldaláról tölthető le.

A kiterjesztés mögött rejlő ötlet rettentően egyszerű (és talán éppen ezért olyan fantasztikus): küldjünk ki pár speciális fejlécet valamiféle JSON tartalommal, amit kliens oldalon a kiegészítő feldolgoz és a Firebug segítségével szépen meg is jelenít. Ezek lehetnek több prioritásba sorolható egyszerű szöveges üzenetek (hasonlóak a Firebug beépített üzeneteihez), táblázatok, szépen formázott backtrace-ek vagy akár print_r()-hez hasonló információk változókról.

A szokásos "napi" php.net böngészgetésem során bukkantam rá a lentebb olvasható kódrészletre (bár nem egy bonyolult dolog, de mégsem jutott volna magamtól eszembe), amit szerintem kötelezővé kellene tenni minden egyes PHP alapú alkalmazás fejlesztési időszaka alatt. A kód nem csinál mást, mint hogy minden hibát kivétellé alakít át, így ha nincsenek elkapva, akkor egy egyszerű E_NOTICE-tól is lehal az oldal fatal error-ral, az error_reporting beállítástól függetlenül. :)

function error_handler($errno, $errstr, $errfile, $errline)
{
    throw new ErrorException(
        $errstr, 0, $errno,
        $errfile, $errline
    );
}
set_error_handler('error_handler');

Egyéni ízlés kérdése, de én még az alábbi kóddal kiegészíteném, hogy fatal error-ok helyett inkább valami olvasható dolgot kapjak:

function exception_handler($ex)
{
	print('<pre>'.$ex.'</pre>');
}
set_exception_handler('exception_handler');

És hogy miért is lenne hasznos? Elég sokan kikapcsolják az E_NOTICE-ok jelzését még fejlesztés alatt is, mondván hogy az nem számít. Pedig elég sok kisebb hibára (pl. változó név vagy tömb kulcs elgépelésekre) hívhatná fel a figyelmet, amik így csak a tesztelési időszakban derülnek ki (ha kiderülnek). Emellett biztonsági haszna is van, mint az a php.net-en is olvasható.

Mostanság parancssori scripteket írogatok Python-ban, ha éppen nincs jobb dolgom (ritka). Gondoltam hát, hogy ezzel kapcsolatos tapasztalataimat és a nyelvvel való ismerkedésemet megosztom egy - egyelőre még nem tudni hány részes - bejegyzéssorozatban. Az első rész témája az alkalmazásnak átadott paraméterek feldolgozása a getopt és az optparse modulok segítségével.

A programunk egy egyszerű "Hello World!" alkalmazás lesz parancssori stílusban. Két fajta bemenő paramétert fogad el. Az egyik a név, akinek köszönni fog, a másikra pedig megjeleníti a súgót, hogy hogyan is kell paraméterezni ezt a rettentő bonyolult programot.

Néha a lustaságomon felül kerekedik az a vágy, hogy új programozási nyelveket ismerjek meg. Ennek lett a legfrissebb áldozata a Python. Bár már volt vele dolgom régebben is, de körülbelül csak egy Fibonacci-számokat számoló rekurzív függvény megvalósításáig jutottam (az is nagy valószínűséggel valami példakód volt valamelyik segédletből).

Magáról a nyelvről azt lehet elmondani, hogy feltűnően szépnek mondható ahhoz képest, hogy a Pascal-stílusú nyelvek közé tartozik. És nem csak egyszerűen szép, hanem törekszik arra, hogy a benne írt kód is szép legyen (ahogy az a Python filozófiáinak listájában is szerepel: "Beautiful is better than ugly."). Persze ehhez az is kell, hogy ne csak Python nyelven, de Python stílusban is programozunk.
A kinézetet tekintve legszembetűnőbb különbség más nyelvekhez képest a kód kötelező indentálása. Nincsenek sorvégi pontok, pontosvesszők, if-eket és egyéb blokkszerkezeteket lezáró hullámos zárójelek vagy kulcsszavak. Minden az új sor karakterek és az indentálás alapján dől el. De mivel kódolás közben a nagy többség amúgy is szokott új sorokat és tabokat használni (és mivel a kötelező indentálás az esetek közel 100%-ában megegyezik azzal, amúgy is használnánk), ezért elég gyorsan hozzá lehet szokni ahhoz, hogy tulajdonképpen kevesebbet kell gépelni. Persze ez még kevés ahhoz, hogy használható is legyen valamire. Mivel napjaim nagy részét a webprogramozás teszi ki, ezért a szintaktikai ismerkedés után első dolgom az volt, hogy utánanézzek, mire is képes a kígyó a weben...

Segítsetek Vuknak Firefoxnak a kis rókának! :)

Avagy az oldal összerakásával terheljük inkább a látogató böngészőjét a szerver helyett.

Néha egész érdekes dolgokat lehet látni, ha az ember - szakmai ártalomból, vagy csak egyszerű kíváncsiságból - beleles egyes oldalak forrásába. Az ilyen oldalak közé tartozik a The World of Warcraft Armory is. Az első pillantásra elég bonyolultnak tűnő oldal mögött meglepően kicsi (5 soros) XML fájl van. Legalábbis látszólag. Természetesen az XSLT áll a dolog mögött, aminek a szerver oldali alkalmazásáról már réges-régen ejtettem pár szót. Nézzük akkor most meg, hogy kliens oldalon mit művelhetünk vele: