Tutoriály vysvětlující, jak psát grafické aplikace v Javě, nám radí, abychom zabezpečili, aby se veškerý kód týkající se grafiky prováděl ve vláknu obsluhujícím frontu událostí. Výklad pak ilustrují na jednoduchých příkladech, které budou vždy fungovat. V tomto článečku bych se chtěl podrobněji podívat na jednu takovou nestandardnost.

Agentura Dobrý web realizovala rozsáhlý průzkum chování uživatelů českého internetu, jehož smyslem bylo zjistit jejich zvyklosti, preference a úroveň povědomí o základních prvcích na webové stránce. Z výsledků průzkumu pak vznikl následující seznam doporučení pro tvůrce webů.

Teoretických rad na téma „jak zrychlit server“ nalezneme všude dost. Horší to bývá s praktickými články, kde by lidé popisovali, co pro zrychlení udělali, proč a s jakým výsledkem. Jednu takovou „případovou zrychlovací studii“ známého českého serveru vám nabízíme.

Zdroják by měl přinášet nejen informace o nových technologiích a webových kouzlech. Rádi dáváme prostor i článkům, které se věnují metodice práce, „správným návykům“ při vývoji a podobně. Článek Reného Steina shrnuje takové zásadní věci, které by si měli pamatovat především vedoucí vývojových týmů…

Většina webdesignerů zná uživatelské protokoly – nebo minimálně jednoho jejich zástupce, protokol „mailto:“. Ten lze použít v odkazech, které po kliknutí otevřou mailový program. Ale co když tím mailovým programem má být webová aplikace? Lze to nějak zařídit? A lze zařídit i jiné protokoly?

Přihlášení uživatele k webové aplikaci je přece tak snadné: zadá jméno a heslo, odešle a – voila! – je přihlášen. Ale co je za tím? A co by za tím mělo být? Přinesou nové technologie nějaké změny v téhle oblasti? Oprášíme staré známé technologie, nebo vzniknou nové?

Před časem jsme v redakci diskutovali s kolegou o tom, co vlastně prozrazují „hlavičky“ v HTTP protokolu. Že v nich putují zajímavé informace o klientu, to je známo i mírně poučeným uživatelům, ale co prozrazují naopak o serveru? Udělali jsme si drobný průzkum velkých českých serverů a zde jsou výsledky.

V článku si představíme dva podobné nástroje, které vám mohou ušetřit čas při programování statickou kontrolou kódu v JavaScriptu. Zkontrolují, zda dodržujete jednotná pravidla zápisu kódu a upozorní vás na případné syntaktické chyby, překlepy, ale i na „zapomenuté“ příkazy, proměnné či nejasné konstrukce.

V ukázkách jednotlivých typů DI v minulém dílu seriálu byly objekty vždy sestavovány manuálně. Kód potřebný pro sestavování je ale obdobný pro všechny případy, a tak tuto práci můžeme u Dependency Injection přenechat tzv. kontejneru, kterému pouze poskytneme konfiguraci. Ukažme si, jak s ním pracovat.

Příběh OpenID zatím nekončí, přesto nabízí ponaučení i pro ostatní projekty. Obzvlášť pro projekty podobného ražení. Pokud vám připadá, že se OpenID nějak neujalo a hledáte příčinu v technických problémech, zbystřete – podle všeho se totiž opakuje historie o technicky zajímavém, ale zcela zbytečném řešení.