MikoAndras.hu

Mikó András

Amit minden webfejlesztőnek tudnia kellene

Az első részben megismertük a böngészőtől kiinduló kérés első lépéseit. Mostanra tudjuk, hogy a webszerver a kért file-tól függően azonnal kiszolgálja a kérést, vagy előbb feldolgozást végez.

Amennyiben viszont a honlapunk programkódjának különböző tartalmakat kell kiszolgálnia, ehhez ezeket az információkat tárolni is tudni kell. Itt jönnek képbe a különböző típusú és előéletű adatbázisok.

Adatbázisok

Ha gyorsan szeretném összefoglalni, azt mondanám:
Adatok tárolására és célzott visszanyerésére alkalmas szoftveregyüttes.

Az első ilyen célra alkalmazott adatbázis a DNS-nél említett, neveket és azokhoz tartozó címeket tároló file volt.

A késóbbiek során egyre nagyobb és összetettebb adathalmazokat kellett tudni kezelni, ma már ott tartunk, hogy célzott – speciális területekre szakosodott – adatbázisok állnak rendelkezésünkre, hiszen más feltételeket támasztunk egy orvosi – főként molekulákkal dolgozó – illetve egy navigációs adatokat tartalmazó adatbázissal szemben.

Webes körökben mindenképen a relációs adatbázisok terjedtek el, egy-egy erősen specializált esetben van szükség ettől eltérő típus alkalmazására. Ennek ellenére szinte mindenki találkozott már vele – még ha nincs is teljesen tudatában -, hiszen a Google keresési algoritmusai mögött saját, célzott elképzelések alapján megírt adatbázis-motor rejtőzködik.

A korábban bevezetett szokás szerint itt is megemlítem az elterjedtebbeket. A bérelt tárhelyeken általában MySQL-lel találkozunk, ennek sokszor ellenpárja a PostgreSQL. Igazán nem mondanám vetélytársaknak vagy ellenfeleknek Őket, mivel mindegyiknek megvan a saját erőssége és gyengesége. Kicsit olyan lenne, mint zsiráfot hasonlítani hiénához: az egyik magas, a másik hangos.

Ezek mellett megjelenik kis számban az Oracle és az MSSQL is, ez utóbbi – érthető okok miatt – főleg ASP környezetben.

Nagyobb adathalmazzal dolgozó oldalak esetében az egyik optimalizálási célpont az adatbázis. Amennyiben sok lekérdezést kell a feldolgozás során kezelni, lekérdezésenként nyert századmásodpercek is hamar súlyos másodperceket jelenthetnek egy oldal megjelenítésében.

Ennek a folyamatnak az alapkövei a normálformák, amit minden relációs adatbázis esetében érdemes – és kell – követni, valamint a választott adatbáziskezelő sajátosságaihoz alakított ínyencségek.

Nyomkövetés

Nyomkövetés

Nyomkövetés

A dinamikus honlapok működéséhez – itt most első körben a webáruházakra gondolok – elengedhetetlen a felhasználó műveleteinek követése. Mivel a weben alkalmazott kommunikáció állapotmentes, ezért egyéb megoldásokhoz kell folyamodnunk, amennyiben szeretnénk megőrizni arra vonatkozó adatokat, hogy milyen termékeket rendelt meg egy felhasználó, vagy hogy milyen név/jelszó párossal jelentkezett be.

A mai napra ez már alapkövetelmény minden honlappal kapcsolatban, ami legalább egy felhasználói véleményezést engedélyező felülettel rendelkezik. Ennél azonban sokkal részletesebb, és több esetben sokkal messzebbre mutató nyomkövetést is ki lehet alakítani.

A Google Analytics és a hasonló statisztikai szoftverek már nem csak a felhasználó tudatos tevékenységeit rögzíti és értékeli ki – termékek kosárba helyezése, megrendelés, vélemény hozzáfűzése, feliratkozás hírlevélre -, hanem szinte minden tevékenységet, ami egy adott honlap oldalain történik – egy felhasználó melyik oldalakat nézte meg, azok mennyi ideig voltak megjelenítve, melyik oldalra érkezett, és melyikről távozott/hagyta abba a böngészést.

Ezek a nyomkövetési adatok szolgáltatják az alapját a “korábban megtekintett”, “leggyakrabban megtekintett”, “leglátogatottabb” ajánlatoknak.

A fenti példák mind arra vonatkoztak, hogy egy honlapon belül miként működik a nyomkövetés, de persze nem kell itt megállnunk, egyszerűen kiterjeszthető mindez több honlapon átívelő adatgyűjtő rendszerré. A részletes leírásban kivitelezési példákkal támasztom alá ezt az elméletet.

Kimenet

Ez az, ami miatt létrejött a DNS, ami miatt webszervert üzemeltetünk, és amit szeretnénk a felhasználók szokásainak kiismerésével minél hatékonyabban eljuttatni a célközönséghez.
A szerverből kijövő kimenet. A honlap mondanivalója. A tartalom.

Ezzel kapcsolatban két feladata van minden fejlesztőnek. Egyszerre kell a felhasználó és a technikai eszközök számára érthető tartalmat biztosítani. Az én elméletem szerint elsőként azt kell megtervezni, hogy mit és hogyan szeretnénk a felhasználó elé tárni, majd második körben kell mindezt a lehető legtömörebben, de egyben érthető módon a böngészőknek átadni.

Ide tartozik és csak a harmadik helyre kerülhet – bármennyire hangsúlyos is – a keresőkre való optimalizálás. Ezzel tudunk előkelőbb helyekre kerülni az eredménylistákban, ha valaki a honlapunkkal kapcsolatos fogalmakra keres, de ez nem mehet a tartalom rovására.

Mivel teljes könyvek jelennek meg a kimeneti kóddal, tartalommal és különböző optimalizálási megoldásokkal kapcsolatban, a részletekben a saját fejlesztéseim során gyűjtött tapasztalatokból fogok szemezgetni.

[LWX]AMP[P]? vs. kézi telepítés

A cím kicsit becsapós lehet, de aki találkozott már a Regexp (Szabályos kifejezés) felirási móddal, az hamar tudja értelmezni.

A LAMP, WAMP és XAMPP környezetek szinte teljesen megegyeznek. Az első betű arra utal, milyen környezetben futtatható – linux/windows/mindkettő -, ezen kívül mindegyik tartalmaz PHP értelmezőt, MySQL szervert és Apache webszervert.

A telepítésük viszonylag egyszerű, a sokak által kedvelt “tovább-tovább-befejez” módon történhet. Sok beállítást alapértelmezettnek tekintenek, még annyit sem kérdeznek, mint az összetevők külön-külön telepítői. A használatuk szintén nem bonyolult, gyorsan össze lehet állítani velük egy fejlesztőkörnyezetet.

Ami miatt én az egyedi telepítéseket jobban kedvelem az a szabadság, amivel a beállításokat kezelhetem, illetve egyben gyakorlom is mindazt a műveletsort, amire egy éles telepítésnél szükségem lehet.

Ezen felül sokkal jobb, ha az éles rendszerrel azonos – vagy komplikáltabb esetben közel azonos – környezetben történik a fejlesztés, mivel így könnyebb a hibákat reprodukálni, illetve kevesebb hiba indukálódik abból, hogy nem passzol egy verziószám, esetleg más a könyvtárelválasztó karakter (nem nevetni, találkoztam ilyennel is az idők során).

A részletek során kevésbé a telepítésre térek ki, inkább igyekszem olyan ajánlásokat összegyűjteni, amik nekem sokat segítenek egy hiba feltárásában, vagy jobb/gyorsabb rendszerek elkészítésében.

Tűzfal

Egy szerver nem csak egy ponton kommunikál a környezetével, hanem egyszerre akár több tucat ponton is. Nagyjából úgy lehetne elképzelni, mint egy háztömböt, amiben lakások vannak, lakásonként több ablakkal. Egy lakás megfelelhet egy szerveren futó szolgáltatásnak.

Amennyiben az összes lakás ablaka nyitva van, akkor elég könnyű bejutni, pláne akkor, ha valahol nincsenek is otthon.

Ha azonban szólunk a lakóknak, hogy kik a megbízható emberek, akiknek kinyithatják az ablakot, valamint befalazzuk azokat, ahova tudjuk, hogy nem fog senki beköltözni, akkor ezzel jelentősen megnehezíthetjük az illetéktelen behatolást.

De ez is csak egy első lépcső, sokkal több van a háttérben. Érdemes folyamatosan figyelni a ház körüli eseményeket, és kiértékelni, hátha egy induló betörést tudunk még káresemény előtt megakadályozni.

Ezzel a területtel én is többnyire “érdemes tudni” szinten foglalkozom, illetve tartok fenn egy szervert amin az ide vonatkozó beállításokat tesztelem, de semmi nincs mögötte, így ha mégis áldozattá válna, szinte azonnal újratelepíthetem.

Mindemellett összeírom mi az, amit képes egy tűzfal kivédeni, hogy láthatóvá tegyem, mi mindenre kell magát az alkalmazást felkészíteni.

Ugyanis a legjobb biztonsági berendezés is haszontalan, ha a tulajdonos beinvitálja a betörőt…

Összefoglalás

Az érintett anyagrészek elég terjedelmes ismeretanyagot fognak át, és sokszor láttam, hogy valaki “szakosodott” kliens oldali vagy szerver oldali programozásra, akár kizárólag adatbázisokra vagy bármely egyéb területre.

Ennek a lehetőségnek ellenére mindenkinek érdemes a fenti témakörök alapjaival tisztában lenni a sikeres együttműködés érdekében.

Pages: 1 2

,

Comments are currently closed.

4 thoughts on “Amit minden webfejlesztőnek tudnia kellene