Weblabor

Az alábbiakban egy rugalmas, jól karbantartható, Python alapú fejlesztési környezet kialakítását mutatom be. Azt a környezetet tekintem rugalmasnak, amely nem köti meg a kezemet a fejlesztés során választott eszközöket illetően, alacsony jogosultsági szinttel is használható, a karbantarthatóságot pedig abban mérem, hogy milyen egyszerű módozatot nyújt környezetek létrehozására, testreszabására és törlésére. A bemutatott módszertant a mindennapi munkáim során alkalmazom.

Alkalmazásfejlesztés során felmerülhet az igény arra, hogy a késztermék több nyelven legyen képes megjelenni. Erre a problémára szeretnék most egy egyszerű megoldást bemutatni.

A HTML5 Boilerplate király. Gyakorlatilag egy HTML, CSS, JavaScript, .htaccess stb. „best practice” sabloncsomag, hogy weboldalak, webalkalmazások fejlesztésénél ne kelljen mindig a nulláról elindulnod. Persze az idő előrehaladtával előbb-utóbb minden fejlesztő elkészíti a saját pakkját. Ennek szellemében szerkesztette meg Paul Irish (Google Chrome, jQuery) és Divya Manian (Open Web Vigilante) a HTML5 Boilerplate-et, ami IE6-ig visszamenően keresztböngészős támogatást igér, HTML5-képes, optimális gyorstárazást biztosít, nyomtatásra felkészített stíluslapot tartalmaz, és így tovább. A gyűjtemény forráskódja public domain alatt elérhető.

A minap belefutottam a gyakorlatban egy érdekes problémába a PHP-ban írt háttérben futó folyamatai kapcsán. Ennek kapcsán úgy döntöttem, összeszedem azokat a baklövéseket, amiket egy fejlesztő elkövethet aszinkron folyamatok írásakor.

Komoly alkalmazások fejlesztése elképzelhetetlen sablonok használata nélkül. Számtalan megoldás létezik, az egyik legismertebb talán a Smarty. Én most egy sokkal egyszerűbb, PHP alapú megoldást szeretnék bemutatni, amivel könnyű elindulni a sablonok használatának rögös útján, és ha megismeri az ember, lehet, hogy nem is érzi szükségét a továbblépésnek.

A linuxos felhasználók, felhasználói táboruk összesítésben csekély volta miatt, eleddig mindig is mostohagyermekei voltak a webes látványtervezésnek. Ez a hozzáállás azonban egyre kevésbé kifizetődő.

Michael Tuck A Web Designer’s Guide to Linux Fonts című cikkében az indokokat és a fejlesztő rendelkezésére álló legelterjedtebb szabad betűtípusokat veszi górcső alá.

Időről időre fellángol a vita felhasználó, tesztelő, projektgazda és fejlesztő között egy-egy weboldal tartalmainak szerkesztésének módjáról.

Fejlesztőként szeretnénk, ha az oldal működne, jól működne. Szeretnénk, ha a felhasználó maximálisan meg lenne elégedve. A tartalom szerkesztése nem okozna problémát. Ugyanakkor nem szeretnénk, ha túl sok új dolgot kellene megtanulnia az oldala adminisztrálásához. Jön a kézenfekvő ötlet: építsünk be egy WYSIWYG szövegszerkesztőt az adminisztrációs felületbe.

És itt kezdődik a huzavona. Mi az, amit megengedhetünk a felhasználónak. Mik azok a dolgok, amiket biztonsági okokból tiltunk le? Mik azok a dolgok amiket azért, hogy egy „fejlett esztétikai érzékkel” rendelkező felhasználó „dühöngése” után se hulljon darabjaira az oldal, és még egységesen, a kialakított dizájnhoz illeszkedjenek az általa szerkesztett tartalmak.

Ahogy növekszik a webes alkalmazások komplexitása, úgy válik egyre égetőbb kérdéssé azok teljesítménye és ennek mérése.

var start = (new Date).getTime();

window.onload = function () {
	var end     = (new Date).getTime();
	var latency = end - start;
}

Ismerős a fenti kód? Ezzel több baj is van. Egyrészt maga a mérés befolyásolja az eredményeket: korábban kell betölteni a JavaScript interpretert, a kód feldolgozása késlelteti a többi erőforrás betöltését sít. Másrészt a JavaScript időbélyegek pontossága a böngészők között 7,5 ezredmásodperces eltérést mutat, ami, figyelembe véve az ezredmásodperc alatt végrehajtott műveleteket, akár 750%-os pontatlanságot is eredményezhet. Mindennek tetejébe pedig a fenti technika csak az oldal betöltésének kezdetétől számított időt jelzi, holott a felhasználó által érzékelt idő ennél a kiszolgáló és a hálózat késése miatt sokkal nagyobb.

A W3C új Web Timing ajánlástervezete erre keres megoldást egy szabványos analitikai felület definiálásával.

Ez az egész HTML5–JavaScript felhajtás a demóvilág hőskorát idézi. Láttad már a JS1k versenyt? Ha nem, itt az alkalom, hogy megnézd, mi fér bele 1024 byte JavaScriptbe.