2012. november havi archívum

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

A legkedveltebb bejegyzések a blogon

2012. november 27. kedd

Lassan három éve lesz, hogy elkezdtem blogolni, azóta igyekszem havonta legalább 6-8 bejegyzést közzétenni. Most összeszedtem azokat a bejegyzéseket, melyek a kapott lájkok alapján a legnépszerűbbek. Volt köztük számomra pár meglepetés, de ezt majd a lista után részletezem.

#like #pi bejegyzés címe lájkok száma
1 1 Twitter magyarul 64
2 2 Twitter regisztráció 56
3 3 Facebook Timeline kikapcsolása 49
4 120 Ősz, 2011 19
5 57 Hungaroton Music Store 12
6 83 Egyetlen kép… 11

#like: rangsor a kapott lájkok alapján
#pi: rangsor az oldalmegtekintések alapján (page impressions) a blogbejegyzések kötött (a cím- és aloldalak, valamint a tag-eket kilistázó oldalak nélkül)

Azért írtam, hogy volt köztük meglepetés, mert vannak bejegyzések, melyeknek az elkészítési ideje egyáltalán nem áll arányban a kapott lájkok számával. Ilyen pl. az, amikor órákig tart elkészíteni egy bejegyzést (pl. Az Ubuntu 10.04 LTS telepítése, vagy az A MySQL és a Mac OS X) és szinte alig érkezik rá lájk (itt érdemes megjegyezni, hogy ettől függetlenül az oldalmegtekintések alapján a Az Ubuntu 10.04 LTS telepítése bejegyzés a rangsorban a negyedik).

Ugyanakkor vannak olyan is, amikor leírok pár mondatot, beszúrok egy képet, aminek az időigénye mondjuk 4-5 perc és szinte pillanatokon belül több, mint 10 embernek tetszik (ilyen pl. az Ősz, 2011 című bejegyzés, vagy az Egyetlen kép – ezeknél a bejegyzéseknél egyáltalán nem számítottam ennyi lájkra).

Persze azért nekem is vannak olyan bejegyzéseim, amiket valamilyen okból jobban kedvelek: ilyen pl. az általatok is kedvelt és fent említett Ősz, 2011, az Egyetlen kép, vagy az Afrika és Széchenyi Zsigmond, és az A Tenere fája című bejegyzések (ez utóbbi a legelső blogbejegyzésem a blogindító után).

A kapott kedvelések a ti véleményeteket tükrözik, de bármelyik bejegyzést is osztjátok meg, vagy lájkoljátok, én annak csak örülni tudok – és természetesen köszönöm ezúton is. :)

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

Indítsd újra az iPhone-odat

2012. november 13. kedd

Ma olvasom a beszeljukmac oldalán:

Ezentúl az Apple arra kéri a felhasználókat, ha bármilyen iPhone-nal kapcsolatos probléma miatt szeretnének időpontot kérni, előbb próbálják meg legalább egyszer ki- majd bekapcsolni a készüléket.

(Forrás: Időpont kell a Genius Bar-hoz? Először indítsd újra az iPhone-odat! – beszeljukmac.com)

Nem tudom, hogy mi folyik mostanában Cupertinóban, minden esetre régebben nem így mentek ott a dolgok. Ilyent már csak elvből sem írtak volna le korábban soha — de mondjuk szükség sem nagyon volt rá. Vicc ez az egész, na.

Minecraft szerver igényfelmérés

2012. november 9. péntek

Amióta megvettem a Minecraftet, azóta már többször megfordult a fejemben, hogy kellene indítani egy saját Minecraft szervert. Most úgy döntöttem, hogy tartok erről egy gyors igényfelmérést, ill. leírnám az ezzel kapcsolatos gondolataimat.

A szerverről komolyabb elképzeléseim lennének, tehát nem úgy tervezem, hogy elindítom, aztán majd ha nem tetszik, akkor két hét múlva le lesz állítva (mindezek ellenére – vagy éppen pont ezért – elképzelhetőnek tartok egy néhány hetes tesztidőszakot, de majd meglátjuk). Ebből kifolyólag ez elég sok szervezést, több ember összehangolt és folyamatos munkáját igényelné, így eszembe nem jutna, hogy egyedül álljak neki. Csak akkor szeretnék bajlódni egy ilyennel, ha megfelelő számú, komolyabb jelentkezőt találnék rá, akik az elképzeléseimet támogatják.

Annak ellenére, hogy mindenhol (így Magyarországon is) gomba módra szaporodnak a Minecraft szerverek, eddig egyik sem nyerte el teljes mértékben a tetszésem. Nem egy századik SMP vagy kreatív szervert szeretnék csinálni, hanem egy olyant, ahol megtalálhatóak az SMP játékmód mellett a kreatív módban készített, komolyabb építmények, szép környezetben. Eddig amikkel leginkább találkoztam: vagy nagyon komoly, előre megtervezett építmények, de kreatív módban, vagy pedig épített össze-vissza mindenki mindent, de SMP módban használták. Tehát én a fenti két dolog előnyös tulajdonságait szeretném valahogy egy szerver alá hozni. Annak ellenére, hogy nem nagyon találkoztam még hasonló magyar szerverrel (persze ez nem jelenti azt, hogy itthon nincs), úgy gondolom, hogy lenne rá igény. Külföldi szerverek között viszont már láttam ilyent.

A rendelkezésre álló szerver egy szervertermi VPS fix IP címmel, gigabites internet-kapcsolattal, 24/7-es rendelkezésre állással. A gép gyakorlatilag csak hajnalonként van használva kb. fél órát, átfutnak rajta a biztonsági mentéseim és a nap 95%-ában kihasználatlanul megy. Időnként tesztelem rajta a saját kódjaimat, de ez nem számottevő mértékű. Nem egy erőmű, de néhány játékossal már ki lett próbálva és úgy tűnik, hogy gond nélkül használható – és természetesen szükség esetén tetszőlegesen bővíthető. A legnagyobb probléma ezzel letudva… :)

Nagyjából összefoglalnám, hogy még mire gondoltam (ez csak egy irány az elképzeléseimről, tehát nincs kőbe vésve). Aki úgy gondolja, hogy szívesen részt venne benne, az jelezhetné felém a részvételi szándékát. Ha megvan a szükséges látszám és a részletek is tisztázottak, akkor bármikor indulhat a szerver, amire csak eredeti (megvásárolt) játékkal lehet csatlakozni.

Mivel még véletlenül sem egy nagyméretű, virtuális homokozót szeretnék építeni unatkozó tizenéveseknek, ezért egyelőre írnék egy korhatárt: húsz év felettieket várnék a szerverre, nekik már általában komolyabb elképzeléseik vannak, van igényük a minőségibb dolgok megépítésére és általában ki is tudják vitelezni azt.

Szeretném, ha a szerveren a hangsúly a valósághű kidolgozáson és a művészeti megvalósításon lenne. Hogy pontosan mire is gondolok: mindent lehet építeni, aminek van valóságalapja, viszont az unalomig ismételt piramisokat, a levegőben lógó, sok kocka átmérőjű lávagömböket, a pixelartokat, sárkányokat és a Nethert viszont szeretném elkerülni.

Addolást nem szeretnék, kivéve pl. a Netherben található itemeket (értelemszerűen, mivel az ki lenne kapcsolva), pénzrendszert viszont igen. A mobok spawnolása is engedélyezve lenne. Lehetőleg egy nagyobb térképet szeretnék, de fix mérettel (kezdésnek mondjuk egy 2×2 km-es területtel).

Ha esetleg érdekelne a dolog, akkor ne itt a hozzászólásoknál, hanem a csaba@dreambyte.hu e-mail címen jelezd, a Minecraft-ben használt felhasználói neveddel, életkoroddal, ill. annak a szervernek a nevével, ahol már építettél multiplayer módban valamit, vagy ahol időnként megtalálható vagy.

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.