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

Internet Explorer emulátor

2012. január 2. hétfő

Az egyik leghasznosabb internetes szolgáltatások egyike az IE NetRenderer nevű oldal, ahol egy adott weboldal címét beírva megkapjuk képként, hogy az adott oldal hogy néz ki az Internet Explorer böngésző különböző változatai alatt. Jelenleg a következő verziók vannak támogatva: Internet Explorer 9, 8, 7, 6 és 5.5.

A fentieken kívül pedig választhatunk még két olyan renderelési mód közül, ahol összevethetjük az IE7 és az IE6 közötti különbségeket is. Egyetlen hátránya annyi, hogy egy 1024×740 pixel méretű png fájlt kapunk vissza a renderelés után az általunk megadott oldalról, így az ennél bármelyik irányban nagyobb méretű tartalmakat nem láthatjuk egészben.

Ettől függetlenül webfejlesztéshez sokszor óriási segítséget nyújthat ez az ingyenes szolgáltatás.

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.

Hiba a tranzakció feldolgozása közben

2011. június 11. szombat

Az egyik legnagyobb hazai banknál van bankszámlám, melyhez biztosítanak webes elérhetőséget, így itthonról is tudom intézni a pénzügyi dolgokat, ha épp úgy alakul.

Most arról nem írok, hogy a belépést is mennyire körülményesen csinálták meg, meg hogy az egész rendszer mennyire nehézkesen és lomhán működik, inkább csak a képen szereplő hibaüzenetre szeretnék fókuszálni.

Első látásra semmi extra, látszólag a buta felhasználó hibája miatt jött elő a hibaüzenet, mert nem tudja, hogy egyszerre csak egy levelet lehet megteninteni és ebből adódóan egyet lehet megtekintésre bejelölni is. Azonban aki picit figyelmesebben jár-kel a világban és megnézi a képet (eseteg feljesztői szemmel nézi), észreveheti azt, hogy miért is írtam meg ezt a bejegyzést.

Nézzük az elejéről. Ezen a felületen jelölőnégyzetekkel (checkbox) lehet kijelölni a megtekintésre felsorolt leveleket. Ebből az ember feltételezné, hogy többet is ki lehet jelölni, hiszen a checkbox egyik nagyon hasznos tulajdonsága pontosan ez. Legalábbis amikor programozást tanultam, akkor azt tanították, hogy ez erre való, és én bizony az elmúlt 10+ évben így is használtam. Az esetek 99%-ban így is működik mindenhol.

Ha több lehetőség közül csak egyet lehet választani, akkor rádiógombot szokás használni (radio button), hiszen ott biztosítva van, hogy az egy csoporton belül található gombok közül mindig csak egy lehet bejelölve. (Az megint más kérdés, hogy egy fejlesztő néhény perces plusz munkával meg tudja oldani azt is, hogy vagy csak egy jelölőnégyzet vagy akár több rádiógombot is ki tudjon jelölni a felhasználó, de alapjában véve mindegyiket arra célszerű használni, amire tervezték.)

Tehát ezen a webes felületen még kellett legalább még egy elágazást rakni a kódba, ami megvizsgálja, hogy hány jelölőnégyzet van kijelölve és ha ez a szám egynél nagyobb, akkor meg kell jeleníteni az adott hibaüzenetet is. Plusz munka a fejlesztőnek (csak pár perc, de akkor is), a objektumokat nem kimondottan rendeltetésszerűen használjuk és bosszantó azoknak, aki erről az egyedi megoldásról megfelejtkeznek és egyszerre kettő (vagy a nagyon bátrak három, esetleg mégtöbb) jelölőnégyzetet is bejelölnek.

Most erről a nevetségesen apró dologról azért írtam bejegyzést, mert egyrészt fordított esetben tőlem, mint fejlesztőtől nem fogadnának el ilyesmit (sokkal egyszerűbb dolgokba is belekötöttek már) és jönnének a kérdések, hogy akkor ez most miért ilyen és miért nem olyan, stb. Másrészt pedig egy banknál, ahol néhány évente rendszeresen kicserélik a márványlapokat, mert annyi a pénz, hogy az ablakon folyik ki, ott ezzel egyáltalán nem foglalkoznak és simán megengedhetnek maguknak ennél sokkal nagyobb dolgokat is.

Apró figyelmesség a Twittertől

2011. április 27. szerda

Valamilyen okból kifolyólag a Twitternek nem sikerült kiküldenie részemre egy (vagy több) e-mailt és amikor legközelebb beléptem a webes felületre, ez az üzenet fogadott:

Alapjában véve semmi extra dolog nem történt, azonban mi, akik webes fejlesztésekkel foglalkoznak tudjuk, hogy az ilyen apró figyelmességek elkészítése mennyi plusz munkával jár egy oldal fejlesztésekor, hiszen rengeteg ilyen apróságra kell(ene) odafigyelni. Az eredményét pedig a felhasználóknak sokszor csak nagyon kis százaléka látja – mint például ezt is.

A legtöbben nem tudják, hogy egy weboldal elkészítésére fordított időből csak egy elég kis hányad az, amit a „látható” részekre fordítunk fejlesztés során (most itt tekintsünk el a CMS alapú, sablon segítségével készített egyszerűbb oldalaktól). A fejlesztésre fordított idő nagy része olyan dolgoknak az elkészítésére megy el, ami a működés során a háttérben zajlik szépen csendben, a felhasználók tudta nélkül (az adatbázis-műveletektől a beviteli mezőkbe beírt adatok ellenőrzéséig). A felhasználó pedig csak annyit lát az egészből, hogy „működik” az oldal.

Ez a fenti is egy ilyen apróság, én kb. az utolsó helyre tenném a tennivalók listájában a lepattanó vagy visszaérkező e-mailek figyelését (nem beszélve arról, hogy a megrendelők zöme meg sem fizetné ill. fizeti az ilyen fejlesztéseket). Jó dolog azt látni, hogy vannak, akik odafigyelnek ilyen dolgokra is.

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…)

Újraindult az Inertia!

2010. február 26. péntek

inertia 4

A mai napon, több éves szünet után újraindult az Inertia, az ország első olyan közössége, mely elsősorban webes szakembereknek szól. Az oldal a régi címen található, ugyanaz a design, ami évekkel ezelőtt volt, úgy hogy most ez eléggé meglepett, hirtelen nem is tudtam, hogy csak egy vicc, vagy tényleg komoly… :)

Miután meggyőződtem, hogy tényleg működik az oldal, az első dolgom a regisztráció volt és közben látom, hogy szállingóznak vissza a régi emberkék… Fura, de jó érzés újból, ennyi év szünet után ugyanazokat a neveket látni ugyanott.

Hiányzott, na… :)

“Modern böngészők modern alkalmazásokhoz”

2010. február 8. hétfő

A Google a vállalati blogjában bejelentette, hogy 2010. március 1. után nem támogatja tovább a régi böngészőket és arra bíztatja az embereket, hogy ha valaki régebbi verziójú böngészővel netezik, az váltson újabbra (Firefox 3.0, Internet Explorer 7.0, Safari 3.0  vagy Chrome 4.0, vagy ezeknél újabb böngészőket ajánlanak), ugyanis a Google-féle szolgáltatások között lesznek olyanok, amik nem fognak rendesen együttműködni a régebbi böngészőkkel.

Ezt a dolgot már nagyon rég meg kellett volna lépni, leginkább a 6-os verziószámú Internet Explorer leváltása miatt. Ugyanis még mindig sok felhasználó használja (pedig már amúgy is régóta elavultnak számít) az IE ezen változata.

(tovább…)