Webes projekt, webprogramozás

Amikor a cikkben dinamikus weboldalról beszélek, ez alatt olyan webszerveren futó programot értek, amelyik aktuális adatbázis tartalom és felhasználói munkamenet tulajdonságok alapján generálja a választ egy webes kérésre. Ha még nem tette volna, olvassa el a dinamikus weboldalakról szóló cikket. Hadd hivatkozzak egy másik cikkre is: olvassa el a webes projektek során felmerülő kérdésekről szóló cikket is, ugyanis itt most a programozási lépéssel kapcsolatos szempontokat boncoljuk részletesebben.

Egy dinamikus internetes oldal fejlesztése során az egyik kritikus pont az alkalmazás elkészítése, programozása. Ez a lépés a webprogramozók munkája, akik azok az IT szakemberek, akik valamilyen webes nyelvet és a webalkalmazások hatékonysági és biztonsági kérdéseiben otthonosan mozognak.

Ennek a munkának több megközelítése létezik. A programozók elkészíthetik a nulláról kezdve az alkalmazást, esetleg valamilyen webfejlesztési keretrendszer segítségével, vagy valamilyen más meglévő keretrendszert integrálhatnak, fejlesztik tovább az esetleg hiányzó funkciókat.

Az első eset sok veszélyt rejt magában, hiszen tulajdonképp abban az esetben is egy tartalomkezelő rendszer készül, aminek a fejlesztése elég komoly munka. Vagyis ez esetben vagy nagyon elhúzódik a fejlesztés, vagy pedig gyenge lesz a végeredmény, az elkészülő rendszer keveset fog tudni. Másrészt nagy az esélye, hogy a rendszer finomhangolására nem lesz idő és energia. Ha egy csapat egy weboldalhoz nulláról akar komplett tartalomkezelő rendszert írni, legalábbis kétséges a végeredmény.

Tartalomkezelő rendszerek

Véleményem szerint sokkal életképesebb koncepció, hogyha egy cég a fejlesztési munkát egy már kész tartalomkezelő rendszerre alapozza. Ebben az esetben a munka első lépése az alkalmazásba integrálni a szükséges  funkciókat, tartalomtípusokat. Ezek egy tartalomkezelő rendszer esetén adottak, így ez az egész fejlesztési munka 30%-át teszi ki, a maradék 70%-nyi erőfeszítés a testreszabásra, tesztelésre és  finomhangolásra fordítható. Márpedig mivel egy jó weboldal többnyire nem azonnal lesz alkalmas funkciója betöltésére és tulajdonosának stratégiai céljainak elérésére, hanem a mért eredmények (keresőből érkező találatok, konverziós ráta, oldalon eltöltött, idő, megnézett oldalak száma) alapján elvégzett optimalizálás után.

Egy jó tartalomkezelő rendszer tehát hatékony, biztonságos, sokféle tartalomtípust támogat, sok modulja van, amelyek építőkockákként funkcionálnak, könnyen használható adminisztrátori felülete van, amellyel az oldal tartalmát egyszerűen változtathatjuk. Nagyon fontos, hogy a működés eredményeit mérni lehessen, látogatók számát, honnan érkeznek, konverziós rátát valamint az optimalizálás bizonyos részeit (pl. keresőoptimalizálást) az adminisztrátori felületen el lehessen végezni.

Tartalomkezelő rendszerekből nagyon sokféle van. Ezeket többféleképp lehet csoportosítani: milyen nyelven készültek, milyen adatbázis-kezelő rendszert támogatnak és hogy milyen feltételek mellett használhatóak. Ez utóbbi szempont szerint vannak nyílt forrású, „szabad felhasználású” rendszerek, illetve kereskedelmi fejlesztések, amelyek nem érhetőek el mindenki számára.

Nyílt rendszerek és zárt rendszerek összehasonlítása

Egy webes fejlesztő cég egyik első és legfontosabb döntése, hogy fejlesztéseit valamilyen, már kész rendszerre alapozza, vagy saját tartalomkezelő rendszert fejleszt. Egy kész rendszer leggyakrabban valamilyen nyílt forráskódú, „szabadon felhasználható” fejlesztés. A nyílt forráskódú rendszereket általában egy közösség fejleszti, a forráskódot bárki letöltheti, átíratja és felhasználhatja. Népszerű nyílt tartalomkezelő rendszer a Drupal, Joomla, PHPNuke, e107.

A saját fejlesztésű tartalomkezelőt a cég programozó csapata készíti, tartja karban és nyújt technikai támogatást hozzá. A forráskódot védi, nem adja oda, ügyfelei a rendszert használatra kapják meg, de azt nem változtathatják meg.

Ár

A nyílt forrású, ingyenes tartalomkezelő rendszerek, nomen est omen, ingyen vannak. Ez azonban a projekt egészének az árát nem befolyásolja döntően, hiszen most csak a fejlesztésről beszélünk, és annak is a 70-80%-át az új funkciók programozása, az oldal tesztelése és finomhangolása teszi ki, ezeket mindenképp el kell végezni, akár nyílt, akár saját fejlesztésre alapul. Ráadásul egy egész projekt árában a fejlesztés csak az egyik lépés.

Még egy dolgot figyelembe kell venni, a nyílt forráskód és ingyenesség nem minden esetben jelenti azt, hogy üzleti célokra is felhasználható a rendszer: némely tartalomkezelő üzleti célú alkalmazásáért fizetni kell. Ezért, ha ilyen fejlesztést rendel meg, mindenképp tájékozódjon a licensz feltételekről.

Biztonság

Felemás a helyzet biztonsági szempontokból. A népszerű nyílt rendszereket sokan használják, ha hiba vagy biztonsági rés van bennük, akkor az gyorsan kiderül. Ilyenkor aki észrevette, jelenti a hibát a rendszer honlapjának fórumán és a következő verzióban kijavítják azt (jobb esetben). Emiatt a nyílt rendszerek legfrissebb publikált verziója általában elég biztonságos.

Csakhogy ha az oldal készítője nem frissíti erre az oldalt, akkor az adott verzió összes biztonsági rése kihasználható marad. Ilyenkor végtelenül egyszerű tönkretenni az oldalt, csak kell keresni egy bőbeszédűbb hibalistát, esetleg „feltörési útmutatót” (exploit) az adott verzióhoz. De ha még a legújabb verzió működteti is az oldalt még akkor is bárki letöltheti a forráskódot, márpedig annak ismerete egy feltörési kísérletben fél siker.

A saját fejlesztésű rendszerek előnye, hogy forráskódja nem forog közkézen és „feltörési kézikönyvek” (exploit) nem készülnek hozzájuk. A kisebb felhasználóbázis és emiatt vélhetően kevesebb tesztelés miatt viszont hibák és biztonsági rések egy része nem derül ki a programozók számra, így potenciálisan több ilyen található a rendszerben.

Ha egy zárt rendszert körültekintően írtak meg, figyelve az alapvető támadási módszerekre, szisztematikusan tesztelték, akkor elég kicsi az esély van arra, hogy az oldalt feltörik. Saját fejlesztéseknél ezért mindenképp tájékozódni kell arról, hogy a biztonsági kérdésekkel mennyire foglalkozott a fejlesztőcsapat a rendszer írása és tesztelése során.

Technikai támogatás

A nyílt rendszerekhez önmagukban nem jár technikai támogatás, azt annak a cégnek kell nyújtania, aki a projektet készíti. Ehhez nagyon komoly felkészültség kell, ugyanis mások által írt program megértése gyakran nem sokkal egyszerűbb, mint megírni elölről. Új funkciók integrálásához, hibák vagy biztonsági rések javításához azonban ez elengedhetetlenül szükséges.

Saját fejlesztésű kereskedelmi rendszereknél a technikai támogatás és a gyors hibajavítás magától értetődően a termék részét képezi, gyakran az nyílt forrású rendszereknek is létezik fizetős, kereskedelmi változata, amihez a kiegészítő szolgáltatás a technikai támogatás és a kiemelt sürgősségű hibajavítás.

Konklúzió

Mind a nyílt, mind a zárt fejlesztések mellett szólnak érvek. Mindig tájékozódjunk arról, hogy a cég milyen eszközre alapozva akarja elvégezni a munkát és mennyire ért ahhoz, ugyanis ez a záloga annak, hogy sikeres lesz-e a fejlesztési lépés.
Ha nincs egyenes válasz kérdéseinkre, gyanúsan olcsón dolgozik a cég és ráadásul húzódozik a változtatásoktól vagy új szolgáltatások integrációjától, akkor könnyen lehet, hogy egy ingyenes tartalomkezelőt alapváltozatát akarja eladni valós hozzáértés nélkül, figyelmen kívül hagyva az igényeket. Ilyenkor nem nagyon lesz lehetőségünk az „inkább úgy szeretném, hogy...” típusú kérdésekre, ezért érdemes inkább másik csapatot választani.