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

Felhasználók azonosítása fejlesztői oldalról nézve

2012. november 30. péntek

Gondoltam, hogy megosztok pár dolgot, ami a napokban eszembe jutott webes fejlesztések kapcsán. Ezek elsőre teljesen értelmetlennek tűnnek, azonban hosszú távon már egyáltalán nem azok, nagyban lehet velük növelni (vagy éppen csökkenteni) a felhasználói elégedettséget még akkor is, ha ezt elsőre nem is gondolnánk.

Felhasználók egyedi azonosítása: felhasználói névvel vagy email címmel?

Fejlesztőként már az első munkáim során el kellett gondolkodnom azon, hogy az éppen készülő rendszerbe milyen módon legyenek azonosítva a felhasználók. Az elején még volt egy időszak, amikor a felhasználói név volt az általam preferált egyedi azonosító (ettől persze az email cím sem egyezhetett meg két felhasználónál ugyanazon a rendszeren), de később a tapasztalatok alapján arra jutottam, hogy egyértelműen az email cím a legjobb egy-egy felhasználó azonosítására.

Méghozzá azért, mert:

  • ugyanarra a felhasználói névre több felhasználó is igényt tarthat (pl. keresztnév)
  • az email címek a felhasználói nevekkel szemben teljesen egyediek, így tökéletesen alkalmasak a felhasználók egyedi azonosítására
  • a felhasználói nevünk sokkal könnyebben elfelejthetjük, mint az email címünket (főleg akkor, ha nem választottunk magunknak valami nagyon egyedi nicknevet, amit senki más nem használ)
  • az email címünket könnyebben és gyorsabban megadjuk a regisztrációkor (egyrészt így is, úgy is meg kell adni, másrészt pedig nem kell sokat gondolkodni és próbálkozni a felhasználói nevünk megadásakor, ha az általunk előre elgondolt név már foglalt)

Ettől persze még nincs semmi baj a felhasználói névvel, de ha van egy avatar is mellette, akkor elég jól meg lehet különböztetni mondjuk két Csaba nevű felhasználót egy fórumban – gondoljunk itt a különböző oldalak alján mostanában elhelyezett Facebook kommentelési lehetőségre, ahol a legtöbben a saját, nevükkel szólnak hozzá a bejegyzésekhez.

A fentieket figyelembe véve nem is értem, hogy viszonylag nagyobb oldalakon miért erőltetik az egyedi felhasználói nevet annyira a mai napig…

Ill. a Facebook kapcsán még valami: a Facebook Connect is egy jó lehetőség az azonosításra de csak úgy, hogy ha bebiztosítjuk magunkat hosszú távra: ha esetleg törli magát a Facebookról a felhasználó, akkor még a mi rendszerünkbe az email címe segítségével be tudjon belépni (vagy kérni egy új jelszót).

Biztonsági kérdések

A másik, amit fejlesztőként és felhasználóként sem kívánok a hátam közepére sem, azok a különböző biztonsági kérdések, melyeket szintén a felhasználóra erőltetnek egyes oldalakon. Pl. az, hogy adjuk meg a nagyapánk foglalkozását, vagy a kedvenc írónk, költőnk, tanárunk és kutyánk nevét, rossz esetben pedig ezt az összeset együtt. Mert az embernek van, vagy volt több nagyapja is, lehet több kedvenc költője vagy írója, lehet több kedvenc tanára is és kutyából is lehet három. Vagy esetleg épp fordítva: nincs kedvence sem íróból, sem tanárból, de még csak kutyája sem volt soha és így tovább.

Sokkal célravezetőbb egy biztonságosabb jelszót kérni a felhasználótól, tehát ami legalább 8-10 karakter hosszú, amiben van kis- és nagybetű, szám, vagy esetleg valami írásjel, bár ez egyes esetekben és felhasználóknál problémákat jelenthet (pl. angol/magyar nyelvű billentyűzetkiosztásnál, kevesebb felhasználói ismerettel rendelkező felhasználóknál).

WordPress talapsztalatok

2012. november 21. szerda

Amikor eldöntöttem, hogy indítok egy blogot, akkor nagy dilemma volt, hogy mi hajtsa: saját blogmotor, vagy a WordPress? A Drupal, vagy esetleg valami más? Kezdetnek feltettem az itthoni gépre a WordPress mellé a Drupal akkori legfrissebb verzióját is, ill. megnéztem még néhány másik CMS-t a legegyszerűbbektől a legbonyolultabbakig. A végén mégis csak a WordPress-re esett a választásom a viszonylagos egyszerűsége, a sok plugin és az adminisztrációs felület felépítése miatt.

Nem szerettem volna egy egyszerű, sokak által használt sablonnál leragadni, mindenképpen valamilyen egyedi kinézetű blogot szerettem volna magamnak – mindezt úgy, hogy lehetőleg a legkevesebb időt kelljen eltölteni vele –ezért a WordPress-ben lévő alapértelmezett sablont írtam át a saját magam elképzelései alapján, ami kb. 2-3 délutánt vett igénybe úgy, hogy előtte a forráskódját szinte semennyire sem ismertem.

Ami tetszik

A WordPress-ben vannak dolgok, melyek nagyon tetszenek (de ez részben szubjektív), ezek a következők.

  • a telepítő egyszerűsége és a telepítés lépései, ahol tényleg csak a legminimálisabb dolgokat kell megadni (bár ha minden jól megy, akkor azt csak egyszer kell használni)
  • a Vezérlőpult (admin felület nyitó oldala) elrendezése és az, hogy a dobozokat tetszőleges helyre tudom tenni, tetszőleges tartalommal, ill. az oszlopok számát meg tudom adni
  • a bejegyzésszerkesztő a formázási lehetőségekkel, ill. az adtott bejegyzés időzített közzététele (bár ez utóbbival már rengetegszer meggyűlt a bajom, de ettől függetlenül egy nagyon jó dolog, hogy van ilyen lehetőség)
  • a rengeteg ingyenesen használható sablon és plugin
  • maga a közösség, ami köré épült az évek folyamán és az a lelkesedés, ahogy egyesek dolgoznak rajta

Ami nem tetszik

Mint minden ilyen tartalomkezelő rendszer, a WordPress is valamilyen szinten kompromisszumokra kényszeríti minket, ha nem akarunk napokat, vagy heteket eltölteni az átalakításával. Mivel hajlandó voltam kompromisszumokat kötni, ezért a CMS kiválasztása után viszonylag gyorsan el tudtam indítani a blogot. Itt most több mindent felsorolok, ami nem tetszik, de csak azért, hogy aki WordPress alapú blog indítására adja a fejét, az fel tudjon készülni az alábbiakra.

Szinte minden bejegyzésből több tucat vázlatot tárol a rendszer, aminek így utólag semmi értelme nincs, ez csak feleslegesen megtöbbszörözi az adatbázis méretét és nincs egy olyan automata funkció, mely egy bizonyos idő után (esetleg kézi beavatkozásra) törölné ezeket a közzététel után már soha többé nem használt vázlatokat. (Közben codee47 hozzászólt a bejegyzéshez, amiből megtudhatjuk, hogy a mentett/tárolt változatok számát a WP_POST_REVISIONS konstans segítségével lehet megadni, de akár ki is kapcsolhatjuk ezt a lehetőséget.)

A beágyazott YouTube videókat preview nézetben nem mutatja, csak ha élesítem az adott bejegyzést, ami engem nagyon zavar, mert szeretem a megírt postokat a végleges formájukban megnézni, mielőtt megnyomom a közzététel gombot és ebbe a videó előnézeti képe is beletartozik.

A HTML nézetben bevitt kódok egyes részleteit vizuális nézetbe visszakapcsolva elnyeli(!) és ha az adott bejegyzést éppen vizuális nézetben nyitom meg, akkor van, hogy írhatom újra az egészet, ami egy teljesen abszurd dolog egy ennyi éves és ennyi ember által használt CMS-nél. Bár elég valószínűnek tartom, hogy erről nem kimondottan a WordPress tehet, hanem a beépített szerkesztője, a TinyMCE.

Csak úgy nem szoktam képeket feltölteni a WordPress rendszerébe, előtte közvetlenül Photoshopból kerülnek a képek elmentésre, ami azt jelenti, hogy nincs szükségem arra, hogy a megfelelő minőséggel tömörített jpeg képet a WordPress tovább „optimalizálja” úgy, hogy közben a kép mérete (szélesség, magasság) egy pixelt sem változik, pedig a WordPress pont ezt teszi. Ezt a dolgot valószínűleg egy átlagos embert észre sem veszi, engem viszont annál inkább zavar.

Összességében egy jó választás volt

Nincs az a tartalomkezelő rendszer, amelynek ne lenne valamilyen gyengesége, csak ez különböző rendszerek alatt más és más. Így a fentiek ellenére közel három év blogolás után még mindig úgy gondolom, hogy a WordPress volt a legjobb választás a blogra és ha holnap egy újabb webnaplót indítanék, akkor ismét a WordPress-t választanám. (A Drupal is nagyon szimpatikus, de valahogy úgy érzem, hogy az nem kifejezetten egy blognak való CMS. Viszont egy összetettebb oldalt már nem indítanék el WordPress-ben, arra egészen biztosan a Drupalt használnám.)

Azoknak mindenképpen ajánlanám a WordPress-t, akik nincsenek otthon annyira a webes dolgokban (PHP, HTML, CSS). Kezdőknek tökéletes, ugyanakkor elég jól testre szabható és jó a támogatottsága, rengeteg ingyenes plugin és sablon található meg hozzá az interneten.

Gondolkodtam már azon, hogy előbb-utóbb neki kellene állni fejleszteni egy saját blogmotor a nulláról úgy, hogy ha elkészül, akkor az itteni bejegyzéseket egy az egyben át tudjam vinni oda, de valójában ennek nem sok értelme lenne, szinte végtelen mennyiségű idő menne el vele.

Frissítés: időközben készült ehhez a bejegyzéshez egy kiegészítés is, mely itt olvasható.

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). 🙂

Amikor nem látják…

2012. május 27. vasárnap

Ez a mai idézet (bár már volt korábban is):

A minőség azt jelenti, hogy akkor is jól csinálsz valamit, amikor nem látják.

— Henry Ford

Ez az idézet jutott ma eszembe akkor, amikor kb. 10 perccel tovább dolgoztam egy weboldalhoz tartozó faviconon, 3200%-os méretre nagyítva, pixeleket egyenként hozzáadva és azok átlátszóságát 5%-os eltérésekkel megadva azért, hogy 16×16 pixeles méretben is ugyanúgy nézzen ki, mint ahogy eredetiben. Az egy más kérdés, hogy ez a Photoshop feladata lenne az átméretezéskor, meg az is, hogy ezt hány látogató fogja majd észrevenni, vagy értékelni (egy sem).

Sajnos egy-egy megrendelői igény kielégítése egyre inkább azzal jár, hogy minél előbb, minél gyorsabban és minél olcsóbban készüljön el valami és az sem probléma, ha össze van csapva, csak az ár legyen minél alacsonyabb. Így elég ritkán van alkalmam arra, hogy valamire pont annyi időt fordítsak, amennyi szükséges lenne. Általában az elvárás az árajánlatig mindig a legprecízebb munka – leggyorsabb kivitelezés – legolcsóbb ár hármas, de amikor megtudják, hogy mennyivel többet kell fizetni ezek miatt az apróságok miatt, akkor már egyből háttérbe szorul a minőség kérdése. Mert bizony egy weboldalnál a több száz ilyen apróság, ami előjön, az akár a számlázáskor kétszeres, vagy még ennél is nagyobb szorzót eredményezhet.

Persze előre tudom, hogy a fenti ikonnál a megrendelő semmit sem fog belőle észrevenni és akkor sem zavarná a dolog, ha egy az egyben úgy menteném el a fájlt, ahogy a Photoshop átméretezte. Sőt, ha megtudnák, hogy ennyivel tovább tartott, akkor jönne az, hogy egyáltalán nem kellett volna vele foglalkozni és az, hogy az ég világon semmi értelme nincs, felesleges időpazarlás.

Ez a mostani viszont egy más jellegű munka (részben önkéntes és lehet, hogy írok később egyszer erről is), így szívesen eltöltök vele néhány extra órát úgy is, hogy előre tudom, hogy nem kapok érte semmit cserébe.

Twitter Fail Whale

2012. április 21. szombat

Szinte nincs olyan aktív Twitter-használó, aki ne ismerné a rendszer túlterheltségét jelző oldalt. Régebben sokkal többször lehetett látni, az utóbbi időben egyre kevesebbszer van ilyen és ha jól emlékszem, akkor volt egy olyan rövid időszak is, amikor nem ezzel jelezték (csak szöveg volt, kép nélkül) azt, ha a rendszer túlterhelés miatt nem tudja kiszolgálni az adott kérést.

Több hónapja láttam utoljára ezt a bálnát, tegnap viszont megint felbukkant és őszintén szólva nagyon megörültem neki, mert valahogy jópofának találom ezt az egészet (mármint nem a túlterhelést, hanem annak közlési módját). Aztán pár perc múlva átgondoltam, hogy mi is történt: kaptam egy hibaüzenetet, hogy bocs, túlterhelt a szerver, ezért most nem tudjuk kiszolgálni a kérést. Ennek a legtöbb felhasználó valószínűleg nem örülne, a Twitter azonban elérte azt – legalábbis nálam – hogy még egy ilyen hibaüzeneten is mosolyogjak és így már egyáltalán nem zavart a dolog.

Ez csak egy jelentéktelen dolognak tűnik, viszont mégis hozzájárul a felhasználói élményhez, nem is kis mértékben. Így kell ezt csinálni. 🙂

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 altspace 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.

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.