Weblabor

Mostanában egyre gyakrabban fordul elő, hogy kiszervezzük egy-egy oldal megjelenésének tervezését. Ilyen formában jónéhány emberrel kapcsolatba kerültünk. A tőlük kapott tervek – bizonyára tapasztalatlanságukból kifolyólag – csak egy dologban egyeztek: rengeteg nyitott kérdés hagytak, aminek a terv átadása után hosszas kommunikáció, és egy csomó „erre nem is gondoltam”, „nem is tudom”, „erre kérek még 2 napot” tartalmú levél lett az eredménye.

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.