Monthly Archive for 2008. május.

Webadmin rövidhírek #3

Published on május 14, 2008 in webadmin. 2 Comments

Aktuális webadmin rövidhírek, szokás szerint megint főként MySQL témakörben, kiegészülve egyebekkel.

MySQL vs symlinkek

A MySQL MyISAM táblatípusának előnyei között emlegetném, hogy minden tábla külön fájlként szerepel, s minden adatbázis egy külön könyvtár a háttértáron történő reprezentációt illetően. Nem mindig jut az ember eszébe egy apró trükk, miszerint symlinkekkel “mozgathatóak” ezek a fájlok, így akár másik fizikai meghajtóra is át lehet helyezni azokat. Főként akkor jön jól a dolog, amikor éppen helyszűkébe kerül az ember.

SQL tuning

Az adatbázis optimalizáció témáról sohasem lehet eleget olvasni. Egy elég jó prezentációt rakott össze Jay Pipes (MySQL-es fazon) ebben a témában, mely nem csak MySQL-es szemszögből lehet érdekes.

MySQL Konferencia videók

Pár hete zajlott le a 2008-as MySQL konferencia, ennek videói lett elérhetőek – jópár érdekes téma volt, érdemes átnézni ezeket.

SimpleDB

Múltkor a CoachDB-ről írtam, most pedig egy SimleDB-s írást linkelek be, mely a hagyományos RDBMS – SimpleDB összehasonlítás témakört járja körül.

HScale – sharding MySQL Proxy alapokon

Magas rendelkezésreállás megoldások között az egyik menő téma a sharding, avagy nagy táblák bizonyos tulajdonságok mentén külön szerverekre történő széttördelése. Ezt a megoldást jellemzően alkalmazás szinten szokás megoldani, de van megoldás az adatbázisszerverek közelében is, a MySQL Proxy-t használó HScale kapcsán.

Dormando’s Proxy for MySQL

A fenti névvel illetett DPM nevű SQL proxy hasonlóan működik a MySQL Proxy kezdeményezéshez, ugyanúgy Lua-ban programozható, de lehet hozzá C modulokat is írni ha a sebesség fontos szempont (ezek a proxy-k szignifikánsan, több 10%-kal képesek az adatbázisszerver sebességet csökkenteni, valaki csinált egy mérést erről). Fontos szempont lehet még, hogy a MySQL körüli licenc kavarásoktól független, BSD licencelésű projektről van szó, szóval tutira szabad és ingyenes.

Friend Connect? – ezmiez?

Published on május 14, 2008 in webkettő. 4 Comments

Imádom, amikor a sajtó, a bloggerek, és még a konkurencia is egy az egyben megeszi a Google bejelentéseit, úgy, hogy nem is jelentettek be még semmi konkrétumot. A Friend Connect ennek a tipikus esete, aminek a teljes neve Google Friend Connect. A gyönyörű az egészben az, hogy a Google még csak nem is hazudik egy szóval sem, csak éppen nem hangsúlyoz ki pár dolgot, a világ másik fele pedig félinformációkra építve felfúj egy rózsaszín lufit, és boldogan körbeugrálja azt.

Me can make money without doing evil.

Friend Connect

A konkrét részletekről most sem lehet tudni igazán sokat, de ezúttal a demóból és az oldalból elég jól ki lehet bányászni, hogy mit takat a Google Friend Connect-je. Idézetek a Friend Connect oldaláról:

Google Friend Connect lets you grow traffic by easily adding social features to your website. With just a few snippets of code, you get more people engaging more deeply with your site.

Közösségi szolgáltatásokat adhatsz az oldaladhoz, de semmilyen információd nem lesz a látogatóidról, és a kapcsolataikról. Úgy fogsz felépíteni egy közösségi alkalmazást, hogy a felhasználók a te szolgáltatásodtól függetlenül, a Google-nél szocializálódnak, egy fal mögött.

Attract more visitors. Visitors bring along friends from social networks like Facebook, orkut, and others to interact on your site.

A látogatók a Facebook, Orkut és egyéb irányokból hozhatják a barátaikat. Miután a Google-nek hozzáférést adnak ezekhez a hálózataikhoz, az kiolvassa az információkat, avagy bemásol mindent a Google profilodba.

Enrich your site with social features. Choose engaging social features from a catalog of gadgets provided by Google and the OpenSocial developer community.

Mindez tehát a Google technológiájára, a Google Widgetekre és a Google OpenSocialra épül. A Google OpenSocial jelentése az információid a Google-hoz láncolása.

No programming whatsoever. Just copy and paste snippets of code into your site, and Google Friend Connect does the rest.

Nem kell programozni, csak kitenni egy iframe-et. A kitett iframe bár az oldaladról szól, a Google-nek épít fel egy közösségi háló adatbázist, vagyis azt, hogy te merre jártál, mely szolgáltatásokat használsz.

Mi a baj?

Nem az, hogy minden információ a Google-hoz kerül. Nem a technológia. Csak az, hogy ez azt jelenti – hacsak nem köp bele valaki a levesbe mihamarabb -, hogy az információt kiszipkázva a Google vezető alapszolgáltató lesz a közösségi hálózatok terén. Az egész ugyanis messze sem egy nyitott megoldás a nyílt olyan jelentésében, mely lehetővé tenné a Google bármely konkurenciájának hozzáférését a közösségi hálómhoz, csak és kizárólag a Google-nak lesz hozzáférése. Sőt, még csak annyira sem nyitott, hogy az akcióban részt vevő oldalaknak bármi közük is lenne ehhez a hálózathoz. Itt pedig az a gond, hogy ezek az oldalak nem fognak tudni valódi közösségi oldalként viselkedni, a felhasználók számára testreszabott oldalakat létrehozni.

Eddig is nehéz volt olyan embert találni, akinek ne lett volna Google azonosítója, ezután pedig a látogatóid simán regisztrálnak a Google-nál úgy, hogy még csak észre sem fogják venni ezt a tényt, mert azt hiszik, hogy nálad regisztráltak. Nálad meg nem fognak regisztrálni.

Ahogyan – bár egészen más lett kihangsúlyozva – az OpenSocial sem szól másról, mint a Google Widget platformjának reklámjáról és terjesztéséről, addig a Friend Connect sem szól másról, mint a Google Accounts reklámjáról és terjesztéséről, az egészet az OpenSocialra építve.

A baj az, hogy egyáltalán nem arról a gyönyörű nyitottságról van szó, amit az ember reflexből odaképzelne a dolgok mögé. És hogy ha minden így marad, a Google hátulról indulva lenyomja az összes közösségi háló szolgáltatást.

Nyitott, de…

A Friend Connect nyílt szabványokat fog használni az authentikációhoz, azaz OpenID azonosítóval be fogsz tudni lépni ezekre az oldalakra. Azok a felhasználók azonban, akiknek nincsen ilyen azonosítójuk, várhatóan egy Google azonosítót fognak kapni magától jövő természetességgel. Az OpenID azonosító, ami az authentikációhoz lesz használva, az nem azt jelenti, hogy az adatok (bármilyen információ, beállítás a felhasználói azonosítón/jelszón felül) is az OpenID szolgáltatónál landolnak, hanem egyenesen a Google-nál fognak.

A felépülő közösségi háló várhatóan nyitott lesz bármilyen Google által meghatározott szabványos közösségi háló importálására, de ezeket a hálókat egyelőre nincs olyan konkurencia, mely megpróbálná valóban nyílt módon összefogni, úgy, hogy valóban mozgathatóak legyenek az adataink, ellenben az összes potenciáli konkurencia szó nélkül implementálja az interfészeket, és beépül a Google hálózatába. Ezután viszont miért is kéne regisztrálnom ezekbe a konkurens oldalakba, ha elég a Google-hoz?

Nyitott, de közel sem eléggé, a nyitottság sajnos egy falon belüli nyitottságot takar.

Jó lesz, de…

Igen, irónia nélkül is ki lehet jelenteni, hogy jó dolgot talált ki a Google, és hogy nagyon kényelmes lehet csak egy közösségi hálóval élni, én is unom már az ismerősök jelölgetését. Az oldal tulajdonosok kapnak egy könnyű invitációs lehetőséget programozás nélkül, olyan szolgáltatásokat (chat, kedvencek jelölése), melyeket nekik nem kell egyáltalán leprogramozniuk.

Az oldalak létrehozhatnak olyan dobozokat, melyek a Google Widget technológiájára épülnek, és a saját szolgáltatásukat jobban tudják integrálni ezekbe a közösségükbe, és ezek a widgetek sok oldalon működhetnek majd.

Jó lesz tehát, de sokkal jobb lenne, ha szinkronizált közösségek épülnének fel, melyek kapcsolódnak egymással, de minden szolgáltató hozzáfér azokhoz az információkhoz, melyek rá tartoznak. Hiába veszek fel ugyanis kedvencnek a Google-nél egy receptet egy iframe-en belül widgetben, ha mint oldalgazda nem fogom tudni, hogy milyen recepteket szedett össze a felhasználó, és milyen továbbiakat ajánlhatok még neki.

Összefoglalás

A Google nyitottságot, látogatottságot, közösségi szolgáltatások könnyű beépíthetőségét ígéri programozás nélkül, de ez így ebben a formában sajnos nem tűnik igaznak, vagy legalábbis mellékhatások nélülinek. Még ha a fenti keretek között a lehető legnyíltabb is lesz a szolgáltatás, az oldalak részben hozzáférhetnek látogatóik közösségi hálós preferenciáihoz, információihoz, akkor is egy zárt Google platformot kezdünk el építeni, melyből győztes szolgáltatóként a Google fog kijönni. Modern, szuper és fantasztikus lesz, ugyanolyan mint amikor az IE6 kijött a Microsoft tolmácsolásában. Biztosan jó ez akkor is, még ha a Google barátságos, és az lesz a jövőben is? Nem kéne inkább valami valóban nyíltat, függetlent összehozni?

Lapozó HTML kódja

Published on május 9, 2008 in miner.hu és webfejlesztés. 5 Comments

A lapozás jellemző eleme a különböző webalkalmazásoknak, azonban így is túl sok rossz megoldást láttam már. A Woork bejegyzése (Perfect pagination style using CSS) ezt a kérdést járja körül. Én is.

Nem fogom az ott leírtakat elismételni, így mindenképpen ajánlom az ottani példák és megoldások elolvasását. Az általam preferált HTML kódot szeretném bemutatni, és leírni, hogy miért gondolom jó megoldásnak:

<ul class="pagination">
  <li class="previous off" rel="previous">« Previous</li>
  <li class="active">1</li>
  <li><a href="?page=2">2</a></li>
  <li><a href="?page=3">3</a></li>
  <li><a href="?page=4">4</a></li>
  <li><a href="?page=5">5</a></li>
  <li><a href="?page=6">6</a></li>
  <li><a href="?page=7">7</a></li>
  <li class="next" rel="next"><a href="?page=2">Next »</a></li>
</ul>

Egyrészt a lehetséges oldalak felsorolása listaszerű tartalom, másrészt a “hagyományos” megoldást, a táblázatot nem szeressük layoutra használni, harmadrészt span-okban ne is gondolkodjunk, mivel a felolvasó szoftverek állítólag nem igazán különítik el egymástól az így egymás után kerülő elemeket, megnehezítve a navigációt (igen, a Miner.hu lapozója több szempontból is rossz példa – az így maradt tipikus esete). Ráadásul egy ilyen lapozó CSS nélkül is átláthatóan, jól néz ki.

Aminek a megjelenítését meg kell oldanunk egy ilyen lapozónál, az az előző oldal, lehetséges oldalak és a következő oldal megjelenítése. Az éppen aktuális oldalt mindenképpen ki kell emelnünk, ízléstől függ, hogy azt is meghagyjuk-e linknek, vagy pedig nem. Akkor célszerű, ha több megjelenítése is lehet egy konkrét találati oldalnak, és mintegy “reset” funkciót lát el az aktuális oldalra kattintás. Ugyanígy az előző oldal az első oldalon ne legyen link, a következő oldal az utolsó oldalon ne legyen link, mert nem sok értelme van a dolognak. Itt is ízlés kérdése lehet, hogy ilyenkor megjelenítsük-e egyáltalán, vagy elhagyjuk, tán a “szűrkítve” meghagyás a jobb a konzisztens megjelenés szempontjából. A lapozott tartalomtól függően lehet “körbelapozást” csinálni, vagyis hogy az első oldalon az előző linkje az utolsó oldalra visz, ennek akkor van értelme, mikor várhatóan értelmes tartalmak találhatóak meg az utolsó oldalon is (azaz nem relevancia szerűen kapcsolódnak az oldalak, mindegyik ugyanolyan értelmes tartalmat kínál, vö.: cikkek lapozója vs. kereső lapozója).

A felsorolt oldalszámoknál is sokféle stratégiát lehet követni. Ha van, akkor mindig jelenítsük meg az előző és következő két-három oldalnak is a sorszámát (avagy ne 6 következő, 0 előző oldal látszódjon), az aktuális oldal legyen célszerűen középen. Ezeken kívül, szintén az adott tartalomtól függően megjeleníthetünk távolabbi oldalakat is. Ez akkor lehet jó, ha mondjuk dátum szerint listázunk elemeket, és úgy szeretne gyorsan eljutni valaki egy adott dátumtartományhoz, hogy nem tudja, melyik oldal fele lehet, és nagyokat ugrálva akar eljutni oda. Ha sokszor fordulhat elő, hogy egy adott konkrét oldalra szeretne ugrani valaki, akkor kitehetünk egy “ugrás egy adott oldalra” linket is, ahol JavaScriptből megkérdezzük az oldal sorszámát (vagy input mezőt jelenítünk meg erre a célra, vagy egy prompt() függvényt hívunk meg), majd az adott oldalra dobjuk látogatónkat. Hányszor írtad már át URL-ben az oldal sorszámát? Még mindig a gyors navigációhoz kapcsolódva, felmerülhet az első és az utolsó oldal kiemelése is – itt is az alkalmazás határozza meg, hogy van-e értelme ennek.

Kicsit a mikroformátumokról. Egyes böngésző kiterjesztések már támogatják a dolgot, és ki tudja, hogy a jövőben mi fogja támogatni, jelöljük meg hát mi is az előző és következő (akár az első és utolsó) odalakat mikroformátum módra, gépek számára érthetően. Ehhez rel=”previous” és rel=”next” részeket írjuk az előző és következő linkekhez (és a rel=”start” és rel=”end” részeket az első és utolsó oldalra mutatókhoz).

Végül nézzük az egyes elemekhez rendelt class-okat. Az előző és következő elemet jelöljük meg “previous” és “next” class-szal, így külön megjelenést tudunk adni nekik, akár kitolva balra és jobbra oldalra ezeket a linkeket, akár másmilyen formában. A sima oldal linkeket felesleges külön class-okkal jelölni. A nem aktív linkeket, elemeket hogy ha “off” class-szal jelöljük, akkor az “off” osztályhoz tudunk az inaktivitást jelző stílust rendelni (pl. szürke), egységesen, tehát nem kell külön definiálni a elemenként. Igen, egy HTML elemhez szóközzel elválasztva több osztályt is adhatunk, és ez teljesen szabványos, minden böngészőben működő megoldás!

Gondolkodjunk még el azon, hogy a tartalom után megjelenített lapozó nem jönne-e jól a tartalom előtt is, és ha igen, akkor ne felejtsük el oda is kirakni.

Azt hiszem nem hagytam ki semmit. Vagy mégis?

Google Reader szerű navigáció

Published on május 9, 2008 in webfejlesztés. 6 Comments

Emlékeim szerint a Google Reader-ben találkoztam vele először, aztán a Netvibes is átvette (egy ideig a feedolvasóban lehetett használni, most pedig a fülek közti mozgásra szolgál): a J és K billentyűk nyomkodásával történő navigációról van szó, mely segítségével előre-hátra lehet halani. A bejegyzés egy olyan JavaScript kódot mutat be, mely ezt a navigációt valósítja meg a Webakadémia címlapján az egyes bejegyzések közti ugrálás céljából.

Google Reader szerű navigáció weblapokon

Mindenekelőtt definiáljuk a feladatot. Az oldalra érkező felhasználónak tegyük lehetővé a bejegyzés címek közötti ugrálást. Ha a J billentyűt lenyomja az oldalon, akkor az éppen aktuálishoz (amin áll éppen) következő bejegyzés címéhez ugorjunk, ha a K billentyűt lenyomja az oldalon, akkor pedig az éppen aktuális előttire.

Válasszunk JavaScript keretrendszert a feladathoz. A Webakadémia sminkjét a K2 nevű sablon szolgáltatja, mely a jQuery-t használja a JavaScriptes effektek megvalósításához, így ez a választás adta magát. A jQuery egyébként is egy jó választás lehet (én folyamatosan ugrálok a Prototype, jQuery, mooTools és még ki tudja milyen keretrendszerek között), amire szükségünk lesz a kivitelezéshez, az pedig benne van, kivéve a scrollozást lehető tevő jQuery.ScrollTo kiegészítő, amit egy gyors mozdulattal gyorsan letöltöttem és behúztam az oldal fejlécéből.

Elsőként az aktuális scroll pozíció megállapítására lesz szükségünk, hogy aztán meghatározhassuk, hogy melyik bejegyzésen is áll éppen a böngészőnk. Ezt a jQuery(document).scrollTop() segítségével kérdezzük le:

var c = jQuery(document).scrollTop();

Ez pixelben fogja nekünk megadni az oldal tetejétől kapott távolságot. A változó neve “c”, mint “current” lett a hirtelen névválasztás égisze alatt. Következő kérdés, hogy melyik bejegyzésen állunk éppen, avagy hova kell scrolloznunk. Ehhez vesszük az összes bejegyzéscímet az oldalról:

var titles = jQuery('.post');

Majd addig pásztázzuk végig a bejegyzések pozícióját, míg egy olyan bejegyzéscímhez nem érünk, ami az éppen aktuális pozíció alatt kezdődik (nagyobb az offszetje).

var i = 0; while (i < titles.length && jQuery(titles[i]).offset().top - 32 <= c) { i++; }

A 32 pixelt a K2 téma sajátossága miatt vontam le, mely az oldal tetején mindig megjelenít egy ilyen magas csíkot az oldalak közötti ugráláshoz. A műveletek végén az “i” változó arra a címre mutat, mely lejjebb helyezkedik el az oldalon az aktuális oldal tetejéhez képest, avagy következő bejegyzésnek nevezhető.

Ennél a pontnál célszerű a billentyűlenyomások kezelését behozni a képbe. Mivel egy az aktuális oldalhoz képest globális billentyű kezelő függvényt szeretnénk megvalósítani, a billetnyűlenyomások elkapását a documentumunkhoz kell rendelni. Végeznünk kell azonban egy ellenőrzést, hogy hol történt az esemény, hiszen nem szeretnénk lekezelni az eseményt, ha a kurzor egy input mezőn textarea-n, stb. áll. Ezért megnézzük, hogy a HTML/BODY (böngészőfüggő) elemhez rendelhető-e az esemény:

jQuery(document).keypress(function(e){if(e.target.tagName=='HTML'||e.target.tagName=='BODY'){
  // ide jön az esemény lekezelése
}});

Meg kell még néznünk azt is, hogy J vagy K billentyűt nyomtunk-e le, ehhez a CTRL és ALT billentyűk állapotát is lekérdezzük (nem akarjuk lekezelni a CTRL-J, ALT-K, stb. kombinációkat:

if (!e.altKey && !e.ctrlKey && (e.which==106 || e.which==107)) {
}

Most kérdezhetjük le a fentebb már bemutatott kóddal az aktuális pozíciót, és számíthatjuk ki a következő bejegyzéscím sorszámát. Ha ezzel megvagyunk, a scrollozás előtt még korrigálni kell az “i” értékét ha a K betűt nyomtuk le, ekkor ugyanis nem a következő (most + 1), hanem az előző (most -1) elemre szeretnénk ugrani. Ha az “i”-ben a “most + 1″ szerepel, akkor kettőt levonva belőle ki is jön a kívánt érték:

if (e.which == 107) { i-=2; }

És a scrollozás (ha i-ben értelmes érték van):

if (i >= 0 && i < titles.length) {
  jQuery.scrollTo(jQuery(titles[i]).offset().top-32, 500, {easing:'swing'});
}

A teljes kód egyben:

jQuery(document).keypress(function(e){if(e.target.tagName=='HTML'||e.target.tagName=='BODY'){
  if (!e.altKey && !e.ctrlKey && (e.which==106 || e.which==107)) { // J and K
    var c = jQuery(document).scrollTop();
    var titles = jQuery('.post');
    var i = 0; while (i < titles.length && jQuery(titles[i]).offset().top - 32 <= c) { i++; }
    if (e.which == 107) { i-=2; }
    if (i >= 0 && i < titles.length) {
      jQuery.scrollTo(jQuery(titles[i]).offset().top-32, 500, {easing:'swing'});
    }
  }
}});

A bővíthetőség, átalakíthatóság száma közel végtelen, a kód pedig teljesen szabadon felhasználható.

Liligo.hu – a repülőjegy kereső

Published on május 6, 2008 in webfejlesztés és webkettő. 5 Comments

A Hírfigyelőhöz hasonlóan a most bemutatandó szolgáltatásnál is személyes érintettségem van, illetve ezen felül még egy dolog hasonló: ez a szolgáltatás is referenciaként szolgált a Netvibes-hoz történő jelentkezésemkor. A Liligo-ról van szó, mely egy francia cég repülőjegy kereső szolgáltatása, az apropó pedig az, hogy magyarul is elindult a szolgáltatás. A Hírfigyelős bejegyzésemhez képest technikai részleteket is megpróbálok leírni – igen sokat tanultam az oldal kliensoldali leprogramozásának kapcsán.

A hasonló szolgáltatásokhoz képest a Liligo két szempontból is többet nyújt, nem véletlenül szoktam ezt használni én is, amikor éppen repülőjegyet igyekszem vásárolni. Az egyik, hogy a potenciális ajánlatok begyűjtése on-the-fly, avagy a keresés időpontjában, a háttérben zajlik le, mintha valóban végignéznénk az összes ajánlatot. A másik lényegi különbség, hogy optimalizálva van fapados járatokra is, és ha éppen van úgy szolgáltatáspár, akkor képes két fapados szolgáltatótól a legjobb ajánlatot összeválogatni (odaút X szolgáltatóval, visszaút Y szolgáltatóval). Erre jellemzően sem a hazai utazási irodák nem képesek, sem pedig a külföldi hasonló szolgáltatások (melyek leginkább Amerikára vannak felkészülve, szemben a Liligo “mindent lefedő” európai kínálatával).

Az én feladatom anno a keresés frontendjének lekódolása volt, és bevallom nem ment könnyen, mint első komolyabb igazán JavaScript frontend projektem egyrészt több hónapig tartott, másrészt többször is leizzadtam vele. Két éve történt a dolog, anno blogbejegyzéseket is írtam okulásul a Weblabor hasábjain a kérdésről, kérdéskörről AJAX fejlesztés – tapasztalatok, AJAX fejlesztés – megjelenítés, AJAX fejlesztés-kommunikáció címmel. Ezeket a bejegyzéseket jó volt most is visszaolvasni – azóta is aktuálisak, és igazán új megoldások, technológiák sem jelentek meg azóta, melyek széleskörűen használhatóak lennének. Az utóbbi években persze részben már átírásra került a frontend kódja, és kisebb-nagyobb mértékben az oldal designja is változott, de az én fejlesztésemmel indult el az oldal francia változata, és állítólag még most is vannak olyan kódrészek, melyek a nevemhez köthetőek.

Ami érdekes megoldás a szerver oldalon, hogy a kereséskor lefutó robotok programozásához Java alapokon, Rhino motorral kis JavaScript programokat használ a szolgáltatás, nem véletlenül adott elő Xavier Casellato erről az idei Web Konferencián. Az oldal jellegéből adódóan a minél több párhuzamos kiszolgálás érdekében az alkalmazás egy nagy része a frontend kódba lett pakolva, így a szerver oldal feladata a JavaScript programkák futtatása, a kapott adatok nagyon minimális előfeldolgozása, majd pufferelése. A JavaScript kód ezt a puffert olvassa, dolgozza fel, és jeleníti meg folyamatosan. Úgy tudom, hogy ez a megoldás azóta sem változott, részemről egy elég ügyes, és költségkímélő megoldásnak tartom továbbra is.

A szolgáltatás magyar verziójáról tudni kell, hogy – első körben a hazai viszonyokhoz igazítva – kevesebb funkcióval indult el, így haladóbb felhasználóknak érdemesebb lehet az angol, francia vagy német (és más nyelvű) verziók használata, melyek már nem csak repülőjegyeket, hanem hoteleket is tudnak keresni (a francia verzió pedig még több dolgot). Szintén az idegen nyelvű változatok – egy igen érdekes – sajátossága egy a Netvibes-hoz hasonló felület, melyet az angol verzióban a jobb felső sarokban levő “Show My Liligo” linkkel lehet elérni. Gyakorlatilag felépítettek egy specializált Netvibes klónt, az utazások köré épülő widgetekkel, fülek létrehozásának lehetőségével, stb.

A Liligo csapatában többen is magyarok, így már csak ezért is érdekes a projekt számomra. Amiért folyamatosan “lobbizok”, az a szokásos hülyeségem: az API – az olyan konkurens nagyobb szolgáltatásoknak, mint például a Kelkoo és Expedia van már valamilyen API-ja régóta. Ezeket jó lenne ha külső fejlesztők is el tudnák érni, és érdekes szolgáltatásokat a Liligo köré kifejleszteni – ezzel talán még ismertebbé válna az oldal.

Miért WordPress?

Published on május 5, 2008 in webkettő. 40 Comments

A Nintendo Wii blogom kivételével az összes blogom alatt WordPress fut, és nem véletlenül. Ebben a bejegyzésben azt próbáltam meg összeszedni, hogy miért a WordPress motorját gondolom a legjobb blogplatformnak. Vannak egyéb platformokkal is tapasztalataim, de szívesen veszem ha más leírja hozzászólás formájában más motorok számára kínált előnyeit, hátrányait, vagy kitér olyan témákra is a WordPress-szel kapcsolatosan, melyeket itt most nem említek meg.

WordPress

Több lehetőséget is végigpróbáltam már, amit PHP+MySQL, avagy a legnépszerűbb/legolcsóbb hoszting kapcsán ki lehet próbálni, és végül a WordPress mellett tettem le a voksom blogok kiszolgálása kapcsán. Bár sohasem kerestem az okokat, a választás mögött nagyjából a jó alapok, és a jó pluginek állnak.

Az alapok

A Wordpress blogok kiszolgálására optimalizált CMS rendszer, ez eleve azt jelenti, hogy feltelepítés után az admin felület és az oldal megjelenítése a blogírás, olvasás igényeit kielégítő megjelenést ad. Ez nyilván egy előny, de ezzel együtt a WordPressben ez tényleg jól is sikerült. Nagyon régi admin felület emlékeim már nincsenek, arra még emlékszem, hogy mikor míg a WYSIWYG editorokat sohasem bírtam igazán, addig amikor megjelent a WordPressben ez a lehetőség, megemeltem a kalapom a megvalósítást illetően. Hasonló jellegű rendszerek esetében mindig is gond a WYSIWYG editor, hiszen a böngészők ezirányú beépített lehetősége sohasem túl barátságos, vannak kisebb-nagyobb hülyeségek. Ugyan nem néztem meg, hogy mit csináltak ezzel a fejlesztők, de egyszerű, jól használható eszközt tettek a kezem alá, és ez a lényeg. A gombsorok is a célszerű, értelmes funckiókat teszik elérhetővé, nincsenek betűkészlet, színek állítására szolgáló gombok, és egyéb hülyeségek, ami meg van, az jól működik. Maradva a WYSIWYG editornál, egy CMS rendszer fejlesztésekor örök probléma a képek (és egyéb fájlok) feltöltése, kezelése is, ez már a WordPress előző verziójánál is jól használható volt, a 2.5-ös verzió megoldása pedig egyszerűen és jól működik.

Az előző WordPress admin felület layoutot, designt illetően is úgy gondolom, hogy bőven jó példaként szolgált, a 2.5-ös verzió designja pedig úgy gondolom, hogy “díjnyertes alkotás”. A kezdeti lépéseket a két verzió közötti váltás során még idegenkedve figyeltem (”nagyon webkettes, de elég béna”), de mire eljutottak a fejlesztők a 2.5 kiadásáig, nagyon jól összepakolták a megjelenést. Nem hiába, több komoly UI designer is dolgozott rajta. Hogy konkrétumokat is említsek, az egyes akciók (mint új blogbejegyzés írása, régiek menedzselése/listája, a félbehagyott régiek) megfelelő kattintásszám után érhetőek el (új bejegyzés – 1 kattintás az admin felületről), a még nem moderált hozzászólások száma az admin felületen bárhonnan látható, a bejegyzés szerkesztő elrendezése a célnak tökéletesen megfelel (cím, bejegyzés tartalma, címkék/kategóriák egymás alatt, mentés és publikálás jobb oldalon). Az olyan “apróságok”, mint a az automatikus mentés, az átméretezhető bejegyzés szerkesztő doboz, a helyből elérhető médiatár vagy azonnali feltöltés “popup”-ban, az elrejthető nem használt mezők, a helyben létrehozható új kategória, a bejegyzés aktuális szavainak száma mind-mind a WordPress melletti elköteleződésem erősítik csak meg.

A WordPress 2.5 újdonsága az igazi Dashboard, ami egy helyre foglalja össze a fontosabb információkat – ez bár eddig is volt, de most lett igazán használható. Köszönhető ez egyrészt a kicsit módosított felépítésének, tartalmának, másrészt annak, hogy a pluginek is be tudnak ide dolgozni, ami még jobb áttekintést tesz lehetővé. A spam-ek kezelése szintén egy olyan dolog, melyet jól old meg alapból a WordPress: beállítható hogy minden hozzászólót egyszeri alkalommal engedélyezni kelljen – ezzel a spamek gyakorlatilag kiszűrésre kerülnek (már ami a megjelenésüket illeti). Jön viszont az adminisztráció, ami egy idő után (amikor a blog ismertté válik a spam robotok felé is) darabra eléggé megnövekszik a sok spam megjelenésével – de hála a JavaScriptes/AJAX-os megoldásoknak és az ügyes elrendezésű felületnek a WordPress-ben nagyon gyorsan végig lehet menni akár több száz spamen is (kb. 1 perc). A korona pedig az Akismet tud lenni, ami ezeket a spameket elég jó hatékonysággal kiszűri, ez egy olyan alapból telepítésre kerülő plugin, amely bár regisztrációt kíván a WordPress.com-on, de elég jó hatékonysággal működik. A hozzászólások jó kezelhetőségét az is segíti, hogy lehet róluk e-mail kérni (illetve alapból a szerző e-mail címére kimennek az e-mailek).

Biztos lenne még pár érv, amit össze tudnék szedni a WordPress mellett, de talán már ezekből is látszik, hogy még ha valakinek nem is jönnek be ezek a megoldások valamiért, azt nem lehet a blogmotorra mondani hogy csak hanyagul összedobálták volna. Más megoldások kapcsán ezen a szinten jellemzően két gond merül fel. Az egyik, hogy az admin menüszerkezete, layoutja nem blogolásra van optimalizálva, több felesleges menüponton is át kell küzdenem magam, ha valamit szeretnék csinálni, vagy csak kiváncsi vagyok rá, míg a másik, hogy jó kis munka, míg alapból kihozza ezeket a lehetőségeket az ember a rendszerből beállítások, pluginek feltelepítése után, és még akkor sem olyan érett a felület, mint a WordPress esetén.

Pluginek

Mindezeket a funkciókat pluginek segítségével turbózhatjuk fel igazán. Az Akismetről már esett szó, nekem még az alábbi bővítmények segítenek be (lustaságból nem linkelem be az oldalaikat, de könnyű megtalálni őket):

  • Fluency Admin – nagyon cool kinézetet varázsol az admin felületnek, fentebb dícsértem az alap admin kinézetet, no, ez még annál is pofásabb, és ha lehet a használhatóságon is lök egy kicsit még tovább (csak a modern böngészőkkel kompatibilis: Firefox, Safari, IE8).
  • Admin Drop Down Menu – a menüszerkezet második szintjét az első szintre kattintok, második szintre kattintok helyett legördülő menüssé varázsolja – mind az alap designnal, mind a Fluency felületével működik.
  • Subscribe to Comments – segítségével a hozzászólók az egy adott bejegyzéshez történő további hozzászólásokról e-mailben értesülhetnek. Alap plugin, kötelező feltenni.
  • Ozh’ Absolute Comments – a hozzászólások kezelése nagyon kényelmes lesz, egy hozzászólásra egyből tudok az admin felületen is válaszolni, nem kell a bejegyzés oldalára is elmenni. Jópár percet lehet vele spórolni.
  • Plugin Central – a 2.5-ös WordPress plugin kezelése sokat fejlődött, pl. admin felületről lehet frissíteni plugineket. Ez a bővítmény lehetővé teszi több plugin egyszerre történő frissítését, illetve új pluginek letöltési URL-jének megadásával azok admin felületről történő telepítését is.
  • Wassup – élőben láthatjuk, hogy kik látogatják éppen oldalunkat (IP cím, hosztnév, hivatkozó oldal, böngésző adatok, hozzászólás szerző infókkal, ismeretlen/belépett/korábban hozzászólt/robot kategóriákba sorolva a látogatókat), illetve visszamenőleges látogatási statisztikákat is képes megmutatni.
  • WordPress.com Stats – elég jó statisztikákat kínál a hivatkozókról, bejegyzéseink látogatottságáról, a keresőkifejezésekről melyekkel oldalunkra érkeztek a látogatók, az oldalunk linkjein történt “kimenő” kattintásokról és a bejövő linkekről. Bár nem egy Google Analytics, annál egy fokkal jobban kézreálló megoldást kínál. Ehhez is WordPress.com regisztráció,

Ezek mellett persze vannak még pluginjeim, de ezek azok, melyeket mindenkinek ajánlani tudok, és nagyon sokat segítettek a blog adminisztrálása, üzemeltetése, blogolás megértése kapcsán.

Egyebek

Az egyebek alá lehet besorolni a verzióváltáskor (nálam svn up pár naponta – az is megérne egy külön misét, hogy mennyire stabil az SVN-ben levő kód) lezajló automatikus adatbázis frissülést, a millió sablont (K2 a kedvenc, de tényleg nagyon sok ingyenesen használható van), a felhasználók optimális kezelhetőségét, az admin felületen szerkeszthető sablonokat és kiterjesztéseket, a widget támogatást.

Mindent összevetve a WordPress-t sok aprósága és a célra termettsége miatt favorizálom, de ahogy a bevezetőben is említettem, ha tud valaki jobbat, ne tartsa magában. :) Egy másik vetülete a kérdésnek: lehet, hogy adott esetben nem a WordPress a megoldás, mert olyanok a körülmények. Bár a WordPress pluginek segítségével elvihető általános CMS irányba is, lehet, hogy éppen nem a legjobb megoldás, mert elég, ha egy másik, vagy saját CMS-t használunk erre a célra. Ha egy oldalhoz akarunk blogot passzintani, és nem PHP+MySQL alapokon készült, akkor Ruby és Perl alapokon is vannak, alakulnak ki jól használható blog platformok, és lehet, hogy egy környezetet összerakni és üzemeltetni kényelmesebb, mint különbözőeket karban tartani. Végül ha blogszolgáltatást szeretnénk indítani, akkor sem biztos, hogy a WordPress mellett kell letennünk a voksunkat – bár hozzáteszem, “kész”, igazán jó megoldásról egyelőre nem tudok ebben az irányban (WordPress MU-val az a baj, hogy ha nagyon kicsi, vagy igazán nagy szolgáltatók vagyunk, akkor működik csak optimálisan).

Webadmin rövidhírek #2

Published on május 5, 2008 in webadmin. 1 Comment

Egyszer már írtam rövidhíreket webadminisztrátori (értsd weblapok hátteréül szolgáló szerverek rendszergazdáinak, adminjainak szóló) hírekről, ha minden jól megy, ebből folytatásos sztori lesz, főként MySQL témákban, de semmiképpen sem kizárólagosan. Következzenek hát rövidhíreink.

MySQL 6.0+ újdonságok

A MySQL 5.1 széria lassan, de biztosan éles környezetben is ajánlott verzióvá válik. Ha minden igaz, és a négynapos ünnep alatt nem változott a helyzet, most release candidate szerű állapotban leledzik, s egy olyan könnyelmű vélemény is elhangzott, hogy nincs benne hiba (ami persze nem igaz, de legalább jól hangzik). Ennek fényében ideje előretekinteni a következő MySQL verzióra, a 6.0-ra.

Ha valaki szeretné folyamatosan követni a MySQL 6.0 újdonságait, mindenképpen ajánlom figyelmébe az erről indult blogot, most pedig konkrétan a jövőt összefoglaló bejegyzést, The Roadmap címmel.

Legfőbb újdonságként a kisebb-nagyobb változások mellett kiemelném a Falcon adatbázismotort (igazi tranzakcióképes, modern motor) és az új backup mechanizmust, mely lehetővé teszi az adatbázis műveletek blokkolása nélküli backupolást (mindegyik adatbázismotorral). A MySQL 6.0 a tervek szerint az év vége fele várható.

MySQL optimalizálás

A MySQL a lekérdezéseket optimalizáló stratégiája – ahogy más adatbázisoké is – becslések alapján végzi a munkáját, választja ki a használt kulcsokat, stb. Ez a stratégia nem mindig jön azonban be, van amikor nem árt a rásegítés. Egy konkrét optimalizálással kapcsolatos példát olvashatunk az operációs rendszer cache és a lemezműveletek kapcsán a MySQL Performance Blogban.

Magas rendelkezésre állású MySQL

Több magas rendelkezésre állással kapcsolatos projektet gyűjtött össze a közösség pozitív tevékenységét bemutatandó a MySQLHA blog, melyek mind hoszting cégeknek, mind pedig a nagy rendelkezésre állásra törekvőknek érdekesek lehetnek.

Apache CouchDB

A CouchDB projekt, mely nemrégiben került be az Apache Software Foundation által gondozott projektek közé, egy olyan adatbázismotor, mely nem relációs adatbázisműveletek, hanem sokkal inkább dokumentum jellegű adattárolásra és lekérdezésekre szolgál. A projekt azért is érdekes, mert a Google és az Amazon is hasonló adatbázisokat kínálnak hoszting projektjeik keretében – a cél egy igazán jól skálázható, gyors adatelérést biztosító háttéradatbázis létrehozása. Az adatbázis sémáját (oszlopainak nevét, típusát) nem kell előre meghatározni, egy adatbázis elem (”sor”) szabadon tartalmazhat “oszlopokat”. Másik nézőpontból: egy adatbázis elem gyakorlatilag egy sztringekből, számokból, dátumokból, tömbökből, hashekből álló hashként (asszociatív tömbként) letárolt adathalmaz.

Az adatbázis REST kérésekkel írható, olvasható, az adatok JSON formátumban közlekednek. Mind emiatt, mind pedig a jó skálázhatóság miatt Web 2.0 barát megoldásnak nevezhető adatbázisról van szó, de ne számítsunk összetett, az SQL adatbázismotoroknál megszokott lekérdezhetőségre, amikor nem egy konkrét elemet kérdezünk le, akkor össz-vissz úgynevezett nézetekre támaszkodhatunk csak, melyek függvényszerűen leírt szűrőként működnek.