‘PHP’ címkével ellátott bejegyzések

Többdimenziós asszociatív tömb rendezése érték alapján PHP-ben

2012. november 6. kedd

Nem kell megijedni, a feladat megoldása sokkal egyszerűbb, mint ahogy a címből gondolnánk. Mivel több féle, bonyolultabbnál bonyolultabb megoldás is kering a neten, úgy gondoltam, hogy leírom azt, amelyiket a legegyszerűbbnek találtam erre a feladatra.

A probléma

Van egy többdimenziós asszociatív tömbünk és ezt szeretnénk a benne lévő értékek valamelyike alapján sorba rendezni. A tömbünk így néz ki:

array
(
  [0] => array
    (
      [gyarto] => Audi
      [evjarat] => 2001
      [km] => 189230
    )
  [1] => array
    (
      [gyarto] => Mercedes
      [evjarat] => 2004
      [km] => 176850
    )
  [2] => array
    (
      [gyarto] => BMW
      [evjarat] => 2003
      [km] => 246400
    )
)

A fenti tömb index szerinti sorbarendezésére van gyári PHP függvény, azonban ha mondjuk évjárat alapján szeretnénk megcsinálni a sorbarendezést, akkor arra valami más megoldást kell találnunk.

A megoldás

Létrehozunk egy saját kis függvényt – az alábbi példában a cmp() – majd annak segítségével rendezzük a tömbünk elemeit, valahogy így:

function cmp( $a, $b ) {
  return strcmp( $a["evjarat"], $b["evjarat"] );
}

usort( $tomb, “cmp” );

Ha pedig fordított sorrendet szeretnénk, akkor az itt leírt megoldás után egyszerűen csak használjuk az array_reverse() függvényt.

A fenti példa megtalálható a PHP dokumentációjában is.

Típuskonverzió PHP alatt

2012. július 10. kedd

Tegnap írtam Twitteren is, hogy az elmúlt 10 évben most volt szükségem másodszor típuskonverzióra a PHP használata során úgy, hogy napi szinten, aktívan írom a PHP kódokat.

Egyúttal elgondolkodtam azon, hogy tíz év alatt mennyi idő ment volna el azzal, hogy mindegyik elé odaírom, hogy mi micsoda (már ha a PHP megkövetelné a változók típusainak megadását is, minden deklaráció alkalmával). :)

Hibakeresés PHP-ben: hol a hiba?

2012. március 19. hétfő

Ezzel a bejegyzéssel csak azt szeretném megmutatni, hogy mennyire könnyen el lehet szúrni az időt egy látszólag végtelenül egyszerű problémával kódolás közben, növelve ezzel a fejlesztésre szánt időt. Szerencsére most az alábbi dologgal kevesebb, mint 2 percem ment el, de rossz esetben ugyanerre elmehet akár egy óra is.

Adott egy általam frissen írt PHP-s függvény, mely látszólag az adott sorokban teljesen hibátlan:

Mégis localhoston, az oldal frissítésekor a böngészőben azt látjuk, hogy valami nem stimmel a 225. sorban:

Parse error: syntax error, unexpected T_STRING, expecting ‘{‘ in [...]/index.php on line 225

A komlett függvényblokkot kiemelve, a php fájlt elmentve és a böngészőt frissítve probléma nélkül lefut a kód, tehát – amennyiben a szintaktika egyébként jónak tűnik – mostantól kezdve lehet gyanakodni arra, hogy belekerülhetett egy nem odavaló karakter a kódba még annak ellenére is, hogy minden egyes karakterét mi magunk írtuk és semmit sem illesztettünk be máshonnan. Ilyenkor célszerű a szerkesztőben azt a nézetet választani, ami mutatja a nem látható karaktereket is, majd ismét rénézni a problémás sor(ok)ra:

Megvan a hiba? :)

Ott rontottam el, hogy a nagy igyekezetben a space billentyűt úgy nyomtam le közvetlenül a kapcsos zárójel előtt a 225. sorban, hogy még nem vettem fel a másik ujjam az alt-ról, így sikerült ott egy alt-space kombinációt elhelyeznem, ami természetesen nem egyenértékű a space-szel.

Ilyen és ehhez hasonló dolgok történnek a fejlesztőkkel minden nap – és ha még csak ilyen, akkor annak csak örülni lehet, mert ez még a nagyon egyszerű problémák közé tartozik.

Tipp PHP-s hibakereséshez Mac és Linux alatt

2011. szeptember 1. csütörtök

Biztosan minden webfejlesztőnek megvan a maga kis megoldása – a fejlesztés mondhatni legutálatosabb részéhez – a hibakereséshez. Ennek ellenére biztosan lesznek azért olyan olvasói is ennek az írásnak, akiknek segíteni tudok az itt leírtakkal.

Ebben a bejegyzésben arról lesz szó, hogy hogyan tudjuk a különböző, PHP kódok futtatása alatt keletkező adatokat, információkat, üzeneteket a böngésző ablaka helyett egy egyszerű egy naplófájlba kiírni, valamint hogy hogyan tudjuk ezt a fájlt megtekinteni.

Lássunk is neki: nyissuk meg a parancssort és hozzuk létre egy naplófájlt erre a célra (természetesen az elérési út is és a fájlnév is lehet tetszőleges):

touch ~/Sites/webdev.log

Ezzel létrehoztuk a naplófájlunkat. Ezek után nincs más dolgunk, mint elindítani a /Applications/Utilities/Console.app nevű programot, majd azzal megnyitni a fent létrehozott fájlt. A Console.app folyamatosan mutatja (és frissíti) a fájl tartalmát, így azt valós időben láthatjuk.

Akik a Terminal használatához vannak inkább szokva, vagy akik valamilyen Linuxot használnak, a Console.app helyett használhatják a parancssort, ahova a következőket kell beírni:

tail -f ~/Sites/webdev.log

A fenti parancs gyakorlatilag ugyanazt csinálja, mint a Console.app, így pusztán megszokás kérdése, hogy ki melyiket használja. Én azért szeretem inkább a Terminalt használni, mert az egyrészt általában amúgy is nyitva van már, másrészt pedig kevesebb helyet foglal az asztalon, mint a Console.app.

Egy apró megjegyzés: Mac-en és Linux alatt általában az alábbi könyvtárban találhatjuk a logfájlokat: /var/log

PHP kód a naplófájlba íráshoz

PHP-s fejlesztéseknél használom ezt a megoldást, de természetesen nem csak és kizárólag PHP alatt használható. Minden esetre én most közzéteszem az általam írt és használt néhány soros PHP függvény egyszerűsített változatát, ami kiírja az imént létrehozott fájlba a tartalmat:

<?php
function trace( $msg ) {
  $logfile = ‘webdev.log’;
  $msg = date( ‘M d H:i:s’, mktime() ) . ‘ ‘ . $msg . “\n”;
  if ( is_writeable( $logfile ) ) {
  $fp = fopen( $logfile, ‘a+’ );
    if ( $fp ) {
      if ( fwrite( $fp, $msg ) === true ) {
        $content = fread( $fp, filesize( $logfile ) );
        fwrite( $fp, $content );
      }
      fclose( $fp );
    }
  }
}
?>

Nekem ez az egész csak annyiban különbözik a fent bemutatott változattól, hogy van benne még egy plusz feltétel az elején, így a beállításoknál tudom szabályozni, hogy lefusson-e a függvény, vagy sem.

A rend kedvéért azért még leírom a használatát az unalomig ismételt „Hello World!”-el, bár aki ezt a fenti néhány sorból nem érti, az valószínűleg nem is nagyon fog hibákat keresgélni…

trace( ‘Hello World!’ );

A végeredmény pedig valami hasonló lesz a parancssorban és a Console-ban:

Megéri az elején ezt a néhány percnyi időráfordítást, mert utána nagyon megkönnyíti a fejlesztés alatti hibák keresését és nem utolsó sorban sokkal elegánsabb megoldás az ilyen dolgok logfájlba való küldése, mint az, hogy a böngészőben a tartalom közé küldi ki a PHP a fejlesztéshez / debug-hoz szükséges – csak számunkra fontos – információkat.

A phpMyAdmin alapértelmezett betűméretének beállítása

2011. április 17. vasárnap

Apró, azonban annál bosszantóbb dolog, amikor a böngésző előzményeinek törlése után a phpMyAdmin ismét az alapértelmezett betűmérettel jeleníti meg a tartalmat. Ennek az oka az, hogy a phpMyAdmin nem felhasználónévhez kötve tárolja ezt a beállítást a kiszolgálón, hanem egy sütiben, a felhasználó gépén.

Szerencsére elég egyszerűen megváltoztathatjuk az alapértelmezett betűméretet – feltéve persze ha tudjuk, hogy hol tárolták el ezt az értéket a phpMyAdmin készítői. :)

Keressük meg a szerveren (vagy a saját gépünkön) a phpMyAdmin könytárát, majd ott lépjünk be a libraries alkönyvtárba. Ezután nyissuk meg a Config.class.php fájlt és keressük meg az alábbi szakaszt (nekem a 765. sor környékén található az alábbi rész):

} elseif (! $this->get(‘fontsize’)) {
  // 80% would correspond to the default browser font size
  // of 16, but use 82% to help read the monoface font
  $this->set(‘fontsize’, ’82%’);
}

Írjuk át a 82%-ot arra az értékre, ami nekünk a legjobban megfelel, majd mentsük el a változásokat. A következő belépésnél már az általunk megadott betűnagyság fogad minden felhasználót, akiknek nem tárolt el a gépén sütit a phpMyAdmin, vagy akiknek eddig is az alapértelmezett méret volt beállítva.

Természetesen a betűméret továbbra is megváltoztatható marad a phpMyAdmin felületén található legördülő listán, a fenti módosítások csak az alapértelmezett méretre fognak vonatkozni.

Hibajavítós hétfő

2010. március 1. hétfő

Az első számítógépes bug, 1947-ből

Az egyik legrosszabb munkának a PHP-s hibajavításokat tartom. Amikor tudjuk, hogy mi a hiba, de a kódot ezerszer átnézve sem találjuk meg, pedig ott van az orrunk előtt. Egy egyedi fejlesztés után a több száz vagy több ezer sornyi PHP kód között azért mindig akad néhány ilyen. Ezeket lehet ugye csökkenteni saját osztályok és függvények használatával, de azért néha mégiscsak becsúszik egy-egy bug.

Egy ennél sokkal rosszabb dolog pedig az, ha más munkájába kell beleturkálni (PHP/HTML), ráadásul úgy, hogy tele van hibával. Változónevek előtt nincs mindenhol ott a $ karakter, többféle és hibás karakterkódolás, többdimenziós tömbökben tárolt adatok, melyek külső fájlban vannak adatbázis helyett, stb. Szóval csupa jó dolog… :) Mindez persze egy “működő” oldalon. Jobban mondva mégsem működik rendesen, azért kell átnézni.

(tovább…)