Weblabor

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.

Az elmúlt pár napban felkapta a média a facebookos „vírusokat”. Nézzük meg, hogyan is működik ez. Egy pár soros, nagyon egyszerű példát szeretnék megmutatni, utána megosztom az aggályaimat.

A Sharp is beszállna a villanykönyv üzletbe, tervei pedig ambiciózusak: saját készüléke mellett új formátummal és önálló terjesztői platformmal rukkolna elő.

…avagy vannak egyenlők, és vannak egyenlőbbek.

Az ECMAScript 5 szabványt olvasgatva találtam rá, hogy a JavaScriptben két változó lehet:

1. különböző (a != b, ez a does-not-euals operator)
2. egyenlő (a == b, ez az equals operator)
3. szigorúan egyenlő (a === b, ez a strict equals operator)
4. nagyon szigorúan egyenlő (a ==== b, nincs ilyen operátor)