Oznámení slouží k okamžitému informování uživatele, např. na nový e-mail. Oznámení se zobrazují vždy na vrchu i v případě, že uživatel pracuje v desktopovém prostředí.

Obě funkce, živé dlaždice a oznámení, může uživatel vypnout.

Dlaždice

Dlaždice vám poskytuje dvě vrstvy, na které můžete vypisovat informace. Základní vrstva je určena pro komplexní informace a stará se o ni objekt TileUpdateManager. Druhá vrstva, která je řízena objektem BadgeUpdateManager, vám umožňuje do pravého dolního rohu vložit číslo od 1 do 99+ nebo jeden z jedenácti symbolů.

Barvu pozadí dlaždice a textu na dlaždici nastavujete v souboru package.appxmanifest.

Šablony dlaždic a oznámení

Rozvržení obsahu na dlaždici nebo oznámení je řízeno pomocí šablon. Šablony jsou popsány pomocí XML.

• Katalog šablon pro dlaždice.
• Katalog šablon pro oznámení.

Možnosti aktualizace dlaždic

Dlaždici může změnit běžící aplikace tak, že do fronty zařadí vzhledy dlaždic a je možné určit dobu platnosti a kdy se má dlaždice zobrazit (ScheduledTileNotification). Další možnost je vytvořit tzv. periodickou aktualizaci. Obsah dlaždice je generován na serveru a systémová služba TileUpdateManager si v pravidelném intervalu stahuje nový vzhled dlaždice. Na serveru se vlastně generuje xml soubor, který odpovídá vybrané šabloně. Poslední možností je využití Windows Notification Service.

TileUpdateManager

Princip je velmi jednoduchý. Stačí si vybrat šablonu, naplnit ji, vytvořit dlaždici a tu předat systémové službě. V následujícím příkladu si ukážeme využití periodických aktualizací:

var notifications = Windows.UI.Notifications; notifications.TileUpdateManager.createTileUpdaterForApplication().startPeriodicUpdate(
    new Windows.Foundation.Uri("http://stepanb.azurewebsites.net/GetTile.cshtml"),
    notifications.PeriodicUpdateRecurrence.halfHour);

BadgeUpdateManager

Podle toho, jestli chcete zobrazit číslo nebo znak, si musíte vybrat příslušnou šablonu, kterou pak naplníte.

Číslo:

var badgeXml = Notifications.BadgeUpdateManager.getTemplateContent(Notifications.BadgeTemplateType.badgeNumber);
var badgeAttributes = badgeXml.getElementsByTagName("badge");
badgeAttributes[0].setAttribute("value", "7"); 

Symbol:

var badgeXml = Notifications.BadgeUpdateManager.getTemplateContent(Notifications.BadgeTemplateType.badgeGlyph);
var badgeAttributes = badgeXml.getElementsByTagName("badge");
badgeAttributes[0].setAttribute("value", "newMessage");

Takto vytvořený Bage Tile přidáte na dlaždici:

var badgeNotification = new Notifications.BadgeNotification(badgeXml);
Notifications.BadgeUpdateManager.createBadgeUpdaterForApplication().update(badgeNotification);

Oznámení

Princip oznámení je velmi podobný jako u dlaždic. Výjimkou jsou periodické aktualizace, ty nelze použít pro oznámení. Oznámení musíte také povolit v package.appxmanifest.

var notifications = Windows.UI.Notifications;

var template = notifications.ToastTemplateType.toastImageAndText01;
var toastXml = notifications.ToastNotificationManager.getTemplateContent(template);

var toastTextElements = toastXml.getElementsByTagName("text");
toastTextElements[0].appendChild(toastXml.createTextNode("Hello World!"));

var toastImageElements = toastXml.getElementsByTagName("image");
toastImageElements[0].setAttribute("src", "ms-appx:///images/logo.png");
toastImageElements[0].setAttribute("alt", "red graphic");

var toast = new notifications.ToastNotification(toastXml);

var toastNotifier = notifications.ToastNotificationManager.createToastNotifier();
toastNotifier.show(toast);

 Přiložené zdrojové kódy ukázek

• Badge TileJavascript
• TemperatureLoggerClient
• ToastNotificationBasicJS

WebGL asi není třeba dlouze představovat – jde o JavaScriptové API pro akcelerované vykreslování grafiky do HTML canvasu; rozhraní je navrženo tak, aby bylo architektonicky identické s OpenGL ES 2.0. Pokud tedy máte s OpenGL nějakou zkušenost (já neměl žádnou), bude pro vás tento článek možná zbytečný a nezáživný.

Co vývojáře po prvních pár experimentech s WebGL nejvíce zaujme?

• Podpora prohlížečů je dobrá, ale může se lišit v závislosti na konkrétním hardwaru či operačním systému.
• WebGL je kromobyčejně ukecané, v porovnání s typickým JS API. To je daň za ohromnou flexibilitu a výkon.
• WebGL se mizerně ladí; zpravidla je lepší postupovat po malých krůčcích a dokázat případné problémy redukovat a izolovat.
• Na WebGL i OpenGL není skoro nic trojrozměrné; většinu 3D věcí si človek musí zařídit sám.

Během tohoto úvodního článku zkusíme vytvořit nejmenší funkční ukázku WebGL: nakreslíme jeden barevný bod. Něco takového je v tradičním 2D canvasu otázkou tří řádků kódu (viz článek Canvas – říkejme tomu plocha na kreslení); řešení ve WebGL je o poznání složitější a okouknout ho můžeme na této adrese: http://jsfiddle.net/ondras/qt7sk/.

Pojďme se nejprve podívat, co všechno WebGL potřebuje, aby mohlo něco vykreslit:

1. Souřadnice prvků, které chceme vykreslovat. Můžou být jedno- až čtyřrozměrné; v našem případě to bude jeden dvourozměrný bod.
2. Vertex shader; program, jehož úkolem je zejména přepočítat naše vlastní souřadice do tzv. clipspace, souřadného systému pro vykreslování v canvasu.
3. Fragment shader (někdy též méně korektně nazývaný pixel shader); program, jehož úkolem je spočítat barvu jednotlivých bodů všech vykreslovaných objektů.

Abychom mohli s WebGL cokoliv dělat, musíme nejprve z HTML canvasu získat kontext:

var gl = document.querySelector("canvas").getContext("experimental-webgl");

Všechna následná volání budou metody objektu gl. Název „experimental-webgl“ je dočasný (i když jej používají všechny současné prohlížeče) a bude v budoucnu nahrazen plnohodnotným „webgl“.

Shadery

Vertex i fragment shader jsou programy v jazyce, který byl velmi originálně nazván GLSL (GL Shading Language). Tyto programy jsou vykonávány přímo na GPU (přesněji: ovladač grafické karty je kompiluje do kódu, který je vykonáván na GPU), a proto jsou extra rychlé. Pro nás to bohužel znamená nutnost naučit se krom WebGL API ještě další jazyk, ale naštěstí to není nic složitého. Jeho syntaxe je podobná C a pro náš testovací program budou oba shadery triviální. Zdrojový kód shaderů se ve WebGL předává jako řetězec; můžeme ho proto uložit do JS stringu, do externího souboru (XHR) nebo do uzlu <script> ve stránce. Pro naše účely bude bohatě stačit předání v JS řetězci. Ve WebGL musíme shader nejprve vytvořit, pak mu předat zdrojový kód a pak ho zkompilovat. Jak bude vypadat ten náš?

attribute vec2 pos;

void main(void) {
    gl_Position = vec4(pos, 0.0, 1.0);
    gl_PointSize = 5.0;
}

Jeho vstupem je proměnná (dvourozměrné pole) pos; hlavním úkolem vertex shaderu je naplnit pro každý vstupní bod vestavěnou proměnnou gl_Position, která odpovídá výslednému umístění bodu. Zajímavé je, že gl_Position je čtyřrozměrné pole; proto k našemu dvourozměrnému doplníme nulu (na ose Z; tato hodnota nás vůbec nezajímá) a jedničku. Jednička na konci je důležitá: gl_Position je tzv. homogenní souřadnice, která u bodů v prostoru potřebuje poslední hodnotu právě jedna. (Proč? Více o tomto v některé z dalších kapitol, kde si povíme o tom, jak přesně probíhá výpočet pozice v canvasu.) Jako bonus ještě nastavíme vestavěnou hodnotu gl_PointSize, aby náš bod vypadal větší než jeden pixel.

A můžeme jít na další shader:

void main(void) {
    gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}

Fragment shader je ještě jednodušší: do vestavěné proměnné gl_FragColor akorát přiřadí červenou. Barvy se zapisují též jako čtyřrozměrné vektory; čtvrtá složka je průhlednost (1 = žádná průhlednost). Všechny složky jsou hodnoty mezi nulou a jedničkou.

Následně z obou shaderů vytvoříme tzv. OpenGL program a nastavíme jej jako aktivní. To proto, že v praxi budeme chtít mít k dispozici programů/shaderů celou řadu:

var program = gl.createProgram();
gl.attachShader(program, vertexShader);
gl.attachShader(program, fragmentShader);
gl.linkProgram(program);
gl.useProgram(program);

Dále si „sáhneme“ na vstupní hodnotu vertex shaderu (pos) a řekneme, že její hodnotu budeme definovat pomocí JS pole:

var posLoc = gl.getAttribLocation(program, "pos");
gl.enableVertexAttribArray(posLoc);

Většina příprav je za námi, jde se renderovat! Vlastně ne, ještě jsme nikam nezadali naši geometrii, respektive souřadnice našeho jediného bodu. Pro tento účel se musíme seznámit s buffery.

Buffery

Veškerá data, předávaná do GPU, jsou uložena v tzv. bufferech – kusech paměti, rychle přístupných z grafické karty. Práce s buffery může vypadat podivně, protože připomíná stavový automat: nejprve nastavíme buffer jako aktivní (bindBuffer) a tím říkáme, že všechny následné operace budou prováděny právě nad ním. Žádné předávání bufferů jako parametrů.

var posBuffer = gl.createBuffer();
gl.bindBuffer(gl.ARRAY_BUFFER, posBuffer);
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array([0.5, 0.5]), gl.STATIC_DRAW);

Konstantou gl.ARRAY_BUFFER specifikujeme, že chceme pracovat s obecným polem. Ještě je tu varianta gl.ELEMENT_ARRAY_BUFFER, o které si povíme někdy příště. Voláním bufferData nahrajeme zadané JS pole (musí to být typované pole, v našem případě Float32Array) do paměti grafické karty. Třetí parametr (gl.STATIC_DRAW) říká, jak máme v plánu tato data využívat a měnit: v našem případě říkáme, že je nechceme měnit vůbec.

gl.vertexAttribPointer(posLoc, 2, gl.FLOAT, false, 0, 0);

Tímto voláním provážeme právě aktivní buffer (ten, kde jsou souřadnice našeho bodu) s vstupem vertex shaderu. Dalšími parametry říkáme, že se z bufferu bude číst po dvou hodnotách, že to jsou destinná čísla, že je nechceme normalizovat, že nechceme žádné hodnoty přeskakovat a že budeme číst od začátku bufferu. Uff!

gl.clearColor(0.0, 0.0, 0.0, 1.0);
gl.clear(gl.COLOR_BUFFER_BIT);
gl.drawArrays(gl.POINTS, 0, 1);

Konečně jsme něco namalovali! Voláním clearColor nastavujeme barvu, kterou se má canvas vymazat (černou). Voláním clear plátno vymažeme a vposled dáme pokyn k vykreslení. Naši geometrii chceme vykreslovat jako prosté body (gl.POINTS), začneme na prvním a vykreslíme jeden. Vidíme červený čtvereček, hurá!

var gl = document.querySelector("canvas").getContext("experimental-webgl");

var vertexShader = gl.createShader(gl.VERTEX_SHADER);
gl.shaderSource(vertexShader, 'attribute vec2 pos; void main(void) { gl_Position = vec4(pos, 0.0, 1.0); gl_PointSize = 5.0;}');
gl.compileShader(vertexShader);

var fragmentShader = gl.createShader(gl.FRAGMENT_SHADER);
gl.shaderSource(fragmentShader, 'void main(void) {gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);}');
gl.compileShader(fragmentShader);

var program = gl.createProgram();
gl.attachShader(program, vertexShader);
gl.attachShader(program, fragmentShader);
gl.linkProgram(program);
gl.useProgram(program);

var posLoc = gl.getAttribLocation(program, "pos");
gl.enableVertexAttribArray(posLoc);

var posBuffer = gl.createBuffer();
gl.bindBuffer(gl.ARRAY_BUFFER, posBuffer);
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array([0.5, 0.5]), gl.STATIC_DRAW);
gl.vertexAttribPointer(posLoc, 2, gl.FLOAT, false, 0, 0);

gl.clearColor(0.0, 0.0, 0.0, 1.0);
gl.clear(gl.COLOR_BUFFER_BIT);
gl.drawArrays(gl.POINTS, 0, 1);

Domácí úkol

Na konec této kapitoly můžeme zvážit nějaká drobná vylepšení za domácí úkol:

• Změnit barvu bodu? Jasně, stačí upravit fragment shader.
• Změnit pozici bodu? Jasně, stačí upravit pole souřadic, předávané v metodě bufferData.
• Vykreslit více bodů? Jasně, přidat další souřadnice do pole bodů a zvýšit jejich počet v metodě drawArrays.
• Vykreslit body jako kolečka? Pokud se čtverečky nelíbí, bude to obtížnější. Takovou úpravu bychom provedli ve fragment shaderu (který je vykonáván pro každý vykreslovaný pixel). Přidali bychom test hodnoty gl_PointCoord, která nabývá hodnot mezi nulou a jedničkou a určuje vzdálenost od středu vykreslovaného vrcholu. Pokud by vzdálenost od středu byla vyšší než zadaný poloměr, bod bychom vykreslili jinou barvou (např. průhlednou).

Proč dávám přednost šablonám před DOM manipulací

Kdysi dávno jsem šablony také nepoužíval. Teď je používám skoro vždy. Proč?

Bezpečnost, XSS a vůbec

Známá věc, programátor zapomene někde escapovat string, a je problém. Se šablonovacím systémem na to myslet nemusím (tolik), viz také developers.google.com/closure/templates/docs/security.

Rychlost

innerHTML je stále nejrychlejší. V Google Closure se šablony kompilují do funkcí. Celá aplikace je tedy jeden JavaScript. Ten obsahuje kód, HTML v šablonách, texty. Třeba takový tapomat.cz, celá aplikace má jen pár desítek kb.

Události

Opravdu není nutné registrovat onclick na každý řádek tabulky. Máme event bubbling a event delegation. V Este vyrenderuji třeba seznam objednávek, a click (respektive tap event) dostane v listeneru přímo model konkrétní objednávky. Registrace bublajících událostí je velmi jednoduchá, viz demo. Díky bublání eventů můžeme obsah elementu přerenderovávat přes innerHTML kolikrát chceme, a není nutné eventy deregistrovat.

Lokalizace

V Google Closure Templates mám perfektní podporu lokalizace. Stačí si pamatovat vždy použít <msg> pro šablony a goog.getMsg pro kód, a lokalizace je hračka, i když se aplikaci rozhodnete lokalizovat poté, co je rok ve vývoji. Mimochodem, nepoužité překlady Closure Compiler při kompilaci odstraní, takže není třeba řešit bobtnání slovníků.

Pořádek

Každá šablona, respektive vykompilovaná funkce z ní, je umístěná ve svém namespace. Aplikace se skládá z features, a pomocí feature toggle a Closure Compileru můžu vykompilovat jen to, co je třeba. Příklad, mobilní verze nebude mít administraci. Jeden projekt, dva vykompilované soubory pro každé zařízení zvlášť. Veliký pokrok proti script tagům v HTML stránce!

Budoucnost a Angular

Angular se od všech ostatních MVC frameworků liší tím, že používá něco, co bude jednou součástí nativního api prohlížeče (takže to bude používat i Ondrej Žára ). Ano, šablonovací systém Angularu je něco jako polyfill pro github.com/toolkitchen/mdv. To je mimochodem důvod, proč Este nemá něco jako Angulaří šablony. Este má svoje vlastní postupy a časem bude zahrnovat i vlastní MDV polyfill.

MVC Frameworky

Framework není nic jiného, než předprogramovaná aplikace. Zajímavé je, že v Google Closure žádný jeden univerzální MVC framework není. Proč Closure nemá jeden MVC framework? Protože v Googlu má každý tým vlastní framework. Jeden pro mapy, další pro Google Docs, a tak dále. Většina JS programátorů ale nepíše mapy nebo Google Docs. Chtějí SPA (Single Page Applications). A tam narazí na mnoho již vyřešených problémů. Například routing. Ten mimochodem naprostá většina MVC frameworků řeší špatně, (krom Este MVC samozřejmě).

Onřej má tedy pravdu, že na specifické příklady se hodí framework vlastní. Ale na 80 % zbytku je dobré postavit se na záda někomu, kdo SPA MVC aplikaci už psal.

Existuje ještě třetí možnost. Pokud MVC framework není monolitický bastl, můžu si půjčit jen to, co potřebuji. Příklad. Este MVC používá este.Model, este.Collection, este.Router, este.este.storage.* a tak dále. Nicméně, ve vaší aplikaci můžete využít třeba jen este.Router a este.storage.Local.

Onřej Žára TODO MVC

TodoMVC Ondřeje Žáry je technologická hříčka. Tímto způsobem se píší příspěvky do soutěže js1k.com. Psát takto něco většího by byla katastrofa. Co když budeme chtít vyrenderovat todo v jiném pohledu? Budeme muset rozdělit soubor todo.js na model a jeho view. Co když budeme chtít zpracovávat více cest, napíšeme si vlastní router? A tak dále, ale já myslím, že Ondřej tohle ví, a zmiňuji to zde hlavně proto, aby někoho nenapadlo psát JS aplikaci podobným způsobem. Frameworky jsou dobrá věc. Neřešte, co už je vyřešené.

Este TODO MVC

TodoMVC demo napsané nad este.App. Možná vás zarazí velikost – 496 kb JavaScriptu! Ale to je v pořádku. V Closure můžeme psát velkoryse, není třeba se omezovat. Klidně můžeme použít takovouhle obří enumeraci, nebo implementaci localStorage pro IE 6 a 7. Nemyslete si ale, že jsem musel explicitně ten kód volat, přidávat script tag, nebo něco takového. Stačilo goog.require('este.storage.Local'); a můžu používat svou vlastní local storage. Closure a Este se postará o zbytek. Tento mód používáme při vývoji. Pro nasazení použijeme vykompilovanou verzi. Vykompilovaná Este TodoMVC app má 22 kb (po gzipu). Mimochodem, nemá smysl řešit velikost bez gzipu. Ten podporují všechny prohlížeče, a Closure Compiler navíc optimalizuje kód tak, aby se dobře kompresil. 22 kb se šablonama, logikou, podporou IE, MVC frameworkem, lokalizací plural rules a mnoho další. Pro srovnání, samotné jQuery má něco kolem 32 kb.

Závěr

Onřej Žára napsal pěkný článek, který snad pomůže vybrat si framework. Líbí se mi, jak šel do architektonických detailů. S jeho závěry však nesouhlasím. Zkusil jsem si oba způsoby vývoje, psát si všechno sám a reuse, a neměnil bych. V Google Closure Library je tak neskutečné množství perfentního otestovaného kódu, že by byla fakt veliká škoda jej nevyužít. Velikost a rychlost výsledné aplikace je díky Closure Compileru naprosto bezkonkurenční. Většina aplikací je menší než samotné jQuery.

Odpovědi na otázky z předchozího článku:

Rozumím tomu nástroji dobře? Dokážu v implementaci ospravedlnit existenci každé řádky svého kódu a vysvětlit, proč ho používám?

Ano, v Closure i Este mám všude podrobné testy a dema. Nevím o jiné knihovně tak dobře pokryté testy a zdokumentované.

Bude výslednému kódu rozumět i ten, kdo k němu přijde po mně? I za dva roky?

Jasně, Closure je v produkci už od roku 2007. Většina kódu se vůbec nemění, knihovna je stabilizovaná, breaking change jsem nezažil. Co se týká Este, snažím se psát hodně malých tříd, a minimalizovat breaking change. Změna signatury metody například, je navíc díky compileru bezpečná.

Volím framework proto, že je to nejlepší řešení mého problému? Nebo jen proto, že mi ho někdo doporučil a/nebo je zrovna in něco takového používat?

Volím Google Closure, a nad ním postavené Este, protože jsem napsal zilióny řádků v jQuery, Mootools, YUI, a dalších. Špatné cesty jsem si poctivě prošlapal.

Ospravedlní mi těch pár uspořených kilobajtů aplikačního kódu přítomnost frameworku, který leckdy sahá na několik set kilobajtů?

Je to naopak. :) S Closure jsou moje aplikace řádově menší než aplikace jiných frameworků. Zdrojáky jsou obrovské, ale výsledný kompilovaný script maličký.

Je pro mne práce s DOMem skutečně tolik obtížná a repetitivní, že kvůli ní musím klesnout k užití string-based šablon?

Ani ne, ale používám ji tam, kde to dává smysl. Třeba když přepínám pohledy, píšu komponentu (ale ta též může využívat šablony), a podobně. Když jde o HTML strukturu, šablony používám vždy. Je to velmi praktické a pohodlné.

Tento text odráží osobní názory a je pravděpodobné, že s ním nebudete souhlasit. Když ale dočtete až ke třetí kapitole, budete moci osobní názory objektivně konfrontovat přímo s konkrétní implementací.

1 Historický exkurz

MVC jako paradigma psaní webových aplikací existuje od nepaměti. Studentům každý rok do hlavy vtloukáme, že dokud bude výsledkem jejich práce spaghetti code, nelze mluvit o udržovatelnosti, čitelnosti a podobně.

Na MVC přitom nic objevného není – je to jen konkrétní aplikace SRP, SoC a podobně v prostředí interaktivního uživatelského rozhraní, syceného daty z nějakého (DB) úložiště. Právě proto se při tradičním psaní webů žádný MVC framework nepoužívá (a přesto to MVC je): prostě se výsledné HTML renderuje šablonou (view), data se papají z nějak abstrahované databáze (model) a zbytek – což může být párřádkový skript i všechoschopný moloch – se stará o logiku spolupráce těchto dvou (controller).

Veškeré serverové logice se samosebou občas říka framework (Nette, Zend, …); to je ale proto, že tím autor dává najevo, že jeho kód se umí postarat o všechny aspekty zpracovávání požadavků (jinak by to byl toolkit, knihovna, nebo něco obdobného). A zrovna náhodou při implementaci použil MVC, proč ne.

Během boomu JavaScriptových aplikací (čti: webových stránek, ve kterých logiku zpracovávání interakce a zobrazování dat realizuje klientský JavaScript) však kdosi přichází s myšlenkou, že “serverové MVC” by z jakéhosi důvodu mělo mít svůj klientský komplement – když to dobře fungovalo v místě A, jistě to bude skvěle fungovat i v místě B. (“Polsko jsme zabrali bez problémů. Co takhle to zkusit ještě s Ruskem?”)

Jaké argumenty v takových chvílích slýcháme?

1. “Vyrábět větší kusy HTML JavaScriptem je opruz. Proto potřebujeme JS šablony.”
2. “Můj web už obsahuje více než N řádků JS, z čehož je patrné, že se JavaScript stal hlavní komponentou stránky. Je na čase použít nějaký nástroj, který mi usnadní jeho psaní a zařídí, abych toho kódu nemusel psát tolik.”
3. “Programátoři na backendu používají MVC. Jaká ostuda, že já se svým JavaScriptem také nemám něco tak prďáckého!”

Za těchto okolností proto světlo světa spatřují JavaScriptové šablonovací systémy: klientské skripty, které na vstupu dostávají strukturovaná data a pseudo-HTML šablonu; provedou substituci a vrátí výsledný fragment HTML dokumentu. Nikdo pořádně neví, jak to dělat – kolik logiky v šablonách nabízet (mustache: logic-less templates), jestli duplikovat serverovou syntaxi (ejs, underscore), jak napasovat nutnost šablonovacích direktiv na fragmenty HTML (plates, PURE). Ve finále je rozhodně z čeho vybírat.

2 Šablony a jejich zásadní nedostatek

Použití šablonovacího systému na serverové straně bylo posledním krokem před dokončením zpracování požadavku: typický controller měl na svém posledním řádku něco jako template.render(data). Ve světě JavaScriptových šablon ale nekončíme vykreslením; jedná se o interaktivní aplikaci, a proto je nutné na vzniklou DOM strukturu ještě navěsit relevantní posluchače. Tím se dostáváme k zásadnímu problému všech šablonovacích systémů, jejichž výstupem je řetězec: není možné přímočaře pracovat s posluchači. Z výsledku je prve nutno postavit strom (innerHTML), ten procházet (querySelector) a přidávat události (addEventListener). A právě procházení je pracné a vyžaduje jasně a jednoznačně definované API mezi stránkou a JS (například pomocí atributů ID či class). Tato skutečnost je hlavním koncepčním nedostatkem samotných JavaScriptových šablon.

V tuto chvíli je možná na místě připomenout, že zmiňovaný neduh vůbec nepřipadá v úvahu při tradičním psaní JavaScriptu, známém též jako DOM manipulation. Uzly, které vyrobím pomocí createElement (nebo nějaké nadstavby), mám okamžitě k ruce a ve vhodnou chvíli na nich události pořeším.

A nyní přichází konfrontace s prvním argumentem, zmiňovaným v předchozí kapitole – totiž že DOM manipulation je opruz, je to pracné, je to zdlouhavé a ušetřený čas by se mohl věnovat něčemu užitečnějšímu. Jaké stanovisko k tomuto zaujmout?

Autor tohoto textu píše JavaScriptové aplikace zhruba osm let a zastává názor, že zmiňovaný argument je prázdná fráze. Proč?

1. Práce s DOMem může být pracná, ale k tomu slouží různá syntaktická zjednodušení, která abstrahují tyto úkony, nabízí zkrácený zápis a řeší kompatibilitu. Týká se to jak tvorby značek (create(“input”, {type:“button”, value:“A”, id:“b”, color:“red”})), tak konstrukce stromu (ul( li(), li( a() ), li()).
2. Vývojářův čas, strávený psaním DOM manipulation, je minimální v porovnání s ostatními aspekty JS aplikace: logikou zpracování událostí, komunikací s backendy, psaním chytrých algoritmů na zpracování dat. Správní vývojáři jsou líní a mohu potvrdit, že se při práci snažím maximum času přemýšlet (nad algoritmy, nad logikou toku programu, …) a jen čas od času něco málo skutečně napsat. Nikdy mi nepřišlo, že bych měl optimalizovat právě čas věnovaný tvorbě těch pár pitomých odstavců, divů a formulářových prvků.

Ve světle toho, jak málo mne DOM manipulation obtěžuje, nevidím mnoho přínosů pro JavaScriptové šablonovací systémy.

Občas se ještě objevuje myšlenka, že oddělené šablony pak mohou spravovat úplně jiní lidé a cenný čas JS programátora může být pálen psaním hardcore JS logiky. Ani náhodou, říkám: šablona je s přidruženým JavaScriptem symbioticky provázána a jakmile do ní začne sahat někdo cizí, dříve nebo později provede nekompatibilní změnu takovou, že si na takto “opravené” šabloně vyláme kód zuby. Nebo naopak, samosebou.

Pojďme se nyní podívat, jakým způsobem na zmiňovaný nedostatek klientského šablonování zareagovali chytří chlapci a děvčata na Internetu.

3 MVC framework

Vítejte ve světě JS MVC: nástrojů, které vzaly šablonování a doplnily do něj události. Jedná se o bleeding edge technologii; nové rostou jako houby po dešti a opět je z čeho vybírat. Bylo by nespravedlivé tyto frameworky označit jen za vylepšené šablony – zpravidla toho s sebou nesou ještě mnohem více, typicky podporu pro HTTP, práci s URL a data binding. Ve finále však ale všechny sdílí jeden základní společný rys: berou nějaký šablonovací systém a dovolují vzniklé HTML počůrat tak, aby se nad ním dalo komfortně (čti: semi-automaticky) pracovat s událostmi.

Pokud to doposud nebylo zcela patrné, tak je nejvyšší čas odhalit hlavní sdělení tohoto článku: Dle mého názoru jsou JS MVC frameworky nafouklá bublina, která vznikla opakovaným záplatováním jednoho konkrétního nádoru. Pojďme se podívat na mé argumenty:

1. Zmiňované počůrání HTML šablony je nekoncepční a vzniklo jako ctnost z nouze, způsobené nedostatkem JS šablonování. Více o tomto níže, u konkrétních ukázek.
2. MVC frameworky způsobují fragmentaci vývojářů. Nesdílí společná API ani vývojová paradigmata; každý je postavený dle nejlepšího vědomí a svědomí svého autora. Řadu let se JS komunita těší na konvergenci JS API v prohlížečích, aby se daly tradiční cross-browser problémy (addEventListener, querySelector, XHR, …) řešit bez zastřešujících můstků. A do této skvělé doby, kdy nekompatibilní prohlížeče skutečně mizí z trhu, najednou přichází desítky nových nástrojů se zcela odlišným zevnějškem. Hledáte JS vývojáře? Možná vám dříve stačilo, když měl skvělé povědomí o jazyce, znal prototypovou dědičnost, chápal uzávěry a event loop. Dnes už musí navíc hovořit tím dialektem JS, ve kterém je psaný firemní MVC framework – protože firemní MVC framework nectí operátor new ani klíčové slovo this; používá vlastní abstrakci, která sere na prototypy a věci, které jsou původnímu JavaScriptu blízké.

V rámci férovosti je nyní dobrá chvíle pozorovat některé populární JS MVC frameworky v jejich přirozeném prostředí. Ideální je pro to služba TodoMVC, která ukazuje implementaci triviální aplikace pomocí řady frameworků. Musíme ale opatrně – delší expozice vede k depresím z toho, v jakém marasmu se situace kolem frameworků nyní nachází.

3a Ember.js

Používá šablony Handlebars, což je syntaxe Mustache + další featury (explicitní IF a podobně). Ve vzorovém HTML jsou šablony vychytrale uloženy v uzlu <script>, což jednak není pravda (není to skript, ale hybrid HTML + custom markup), a za druhé to spolehlivě zmate většinu syntax highlighterů.

Události jsou provázány pomocí tagu či atributu action, kterému v šabloně upřesníme DOM událost a sdělíme název metody controlleru, která ji bude zpracovávat. Zatímco dříve bylo fujfujfuj napsat <label ondblclick=”editTodo()”>, nyní je hujhujhuj varianta <label {{action "editTodo" on="doubleClick"}}>.

V JavaScriptové části kódu je zcela zavrhnuto new a namísto toho věci vyrábíme různými variantami extend() a create(). Nomenklatura používá různé automagické konvence; můžeme si o nich přečíst v dokumentaci. Například controller TodosController, který je mj. zodpovědný za přidání nové položky, je sice definován s tímto jménem, ale jinak se jeho název už nikde dále v kódu nepoužívá (což neznamená, že ho můžeme pojmenovat jak chceme – aplikace očekává, že s ohledem na pojmenování okolních věcí bude něco s tímto názvem existovat. Data binding je realizován explicitním voláním set() na controlleru, který následně notifikuje posluchače o změně hodnoty.

Implementační zajímavost: v Ember.js mají funkce prototypovou metodu property, která jim definuje metadata (závislosti), na kterých volání této funkce závisí. Mimo jiné i kvůli tomu není možno používat tradiční prototypový přístup, kdy je jedna funkce sdílena spoustou různých objektů.

3b Backbone.js

Backbone nepoužívá žádné vestavěné šablonování, ale zhusta závisí na low-level knihovně Underscore. K provázání DOM událostí definuje vlastní syntaxi, podobnou CSS selektorům prefixovaným názvem události; zároveň s tím nabízí implementaci vzoru observer a tím pádem i užívání vlastních událostí.

To, čemu se jinde říká Controller, je v Backbone nazýváno View. Vlastní vyrábíme voláním create(), na prototypy můžeme zapomenout. Spolupráce s URL je zcela oddělená součást frameworku; jedná se o prosté mapování vzorů URL na vlastní funkce či události.

Zajímavost #1: ke zdrojovému kódu Backbone existuje anotace téměř ke každému řádku.

Zajímavost #2: Backbone jako jeden z mála nástrojů nenabízí vlastní abstrahovaný super; namísto toho zodpovědně vybízí k používání čistě JavaScriptového volání předka.

3c Angular.js

Tento super-heroic framework používá vlastní šablonovací jazyk, založený na speciálních HTML značkách a atributech (které z nějakého důvodu začínají na ng a připomínají tak, že až se do šablon někdo podívá za deset let, jistě mu budou připadat velmi New Generation). Výsledný mix HTML a NG je špatně čitelná směs. Vzpomínáte, jak se říkalo, že <form onsubmit=”...”> je fuj? Tak dnes frčí <form ng-submit=”...”>.

Hlavním tahounem Angularu je jeho obousměrný data-binding, totiž automatické reagování na změny v datech, se kterými se pracuje (ať už iniciované Angularem, nebo uživatelem). Realizace funguje na bázi opakovaného monitorování dat: funkcí $watch říkáme, která data chceme sledovat; (implicitním) voláním funkcí $apply a $digest dochází k ověření změny hodnot a automatickým aktualizacím. Více o těchto konceptech je k vidění v dokumentaci.

Implementační zajímavost #1: K detekci změn v datech dochází často (vlastně skoro pořád – po každém požadavku, po každé události); pro účely této detekce se musí data jednak porovnávat a druhak kopírovat (nutno si někde pamatovat minulý stav). To může mít samosbou dost neblahý vliv na výkon celé aplikace (mousemove? objemnější datové struktury?).

Implementační zajímavost #2: po změně ve watchovaných datech je volán relevantní posluchač (zpravidla ten, který má nová data vykreslit či jinak zpracovat). Jeho volání může ovšem způsobit změnu v datech někde jinde; proto je celý proces $digest potenciálně rekurzivní. Autoři tuto rekurzi omezili magickou konstantou 10, takže je nutné s daty dokonvergovat do stabilního stavu nejvýše na 10 iterací.

3d CanJS

Tento nástroj je postaven na spolupráci (a tedy i prerekvizitě) s jedním z low-level JS toolkitů: jQuery, Zepto, Dojo, YUI či Mootools. Nativně podporuje šablony EJS (syntaxe ve stylu ASP, v šabloně tedy vidíme např. <% todos.each(function( todo ) { %> či) a k dispozici je též plugin pro Mustache.

Posluchače událostí se definují vlastní CSS-like syntaxí (ať už pro DOM události či realizaci observeru). Pokud v šabloně použijeme výpis hodnoty, která je Observable (typicky .each nebo .attr), dojde v rámci šablony k navěšení posluchače na změnu tohoto Observable; při této se pak automaticky přerenderuje relevantní část šablony.

Dle dokumentace je doporučováno provazování HTML uzlů s datovými objekty – tato pochybná technika je k vidění v ukázkové aplikaci.

Zajímavost: autoři CanJS používají nezvykle obskurní techniku předávání undefined jako (nedefinovaného) parametru do všudepřítomné obalující anonymní funkce (viz první a poslední řádky zdrojových souborů).

3e KnockoutJS

Namísto tradičního šablonování si KnockoutJS počůrává části HTML atributem data-bind, ve kterém je možno specifikovat provázání obsahu prvku s daty i vyšší logiku (cykly, podmínky). Zápis

<a data-bind="css: { selected: showMode() == 'all' }" href="#/all">All</a>

tedy prvku přidá class=”selected”, pokud vykonání fragmentu JS vrátí pravdivou hodnotu. Implementace takového chování s sebou přirozeně nese takové radosti jako vnořené with a Function constructor (techniky, které patří k těm nejméně doporučovaným vůbec).

Automatická aktualizace HTML probíhá na základě vzoru Observer; voláním ko.observable() (implicitně při data-bind) vytvoříme hodnotu, která při své změně notifikuje posluchače. Sympatické je, že Model je zcela v režii uživatele a zpravidla to bývá tradiční JS konstrukční funkce. Jen ta data, která se následně propagují do HTML, jsou obalena jako ko.observable.

KnockoutJS nenabízí žádnou vestavěnou podporu pro práci s URL. Namísto Controller se v něm říká ViewModel, ale to je jen terminologický blázinec.

3z VanillaJS

Bylo by nezodpovědné jen hodnotit cizí práci a nepředvést nic vlastního. V rámci projektu TodoMVC existuje čistokrevná vanilla verze, ale není udržovaná a obyčejnému JavaScriptu dělá spíše medvědí službu. Naimplementoval jsem proto vlastní variantu ukázkové úlohy, na které je vidět, jakým způsobem k této problematice přistupujeme bez nutnosti nějakých MVC nástrojů.

Kód je rozdělen do dvou souborů – todo.js odpovídá jedné položce úkolovníku, udržuje její data i vizuální reprezentaci, zpracovává události. app.js zastřešuje celou aplikaci, aplikuje filtry, přistupuje k localStorage. Jak je vidno, hlavní manipulace s DOMem se odehrává ve funkci Todo.prototype._build – a není to nijak hrozné. Nabízejí se tato další rozšíření kódu:

1. Helper pro tvorbu DOM prvků (pomocí výčtu vlastností v objektu nebo CSS selektorem),
2. oddělení vizuální reprezentace do vlastního objektu (např. Todo.Visual), která by se starala výhradně o DOM a události; data by držel stávající objekt Todo.

4 Závěr

Zastánci MVC frameworků argumentují tím, že tyto nástroje dokážou zastřešit a provázat práci s individuálními komponentami a knihovnami aplikace. Dle mého názoru je tato výpomoc vágní, protože aplikační kód (controller) si člověk musí vždy vyrobit sám; to za něj žádný framework neudělá.

Naštěstí ale máme k dispozici návrhové vzory a hotová řešení pro všechny elementární úkony (práce s URL, RPC, Promise, DOM, Storage, Template, události, …) – proto mi přijde, že přidávání dalších úrovní indirekce/abstrakce má jen velmi malou přidanou hodnotu.

Až budete zvažovat použití nějakého JS MVC frameworku, zkuste si zodpovědět tyto otázky:

1. Rozumím tomu nástroji dobře? Dokážu v implementaci ospravedlnit existenci každé řádky svého kódu a vysvětlit, proč ho používám?
2. Bude výslednému kódu rozumět i ten, kdo k němu přijde po mně? I za dva roky?
3. Volím framework proto, že je to nejlepší řešení mého problému? Nebo jen proto, že mi ho někdo doporučil a/nebo je zrovna in něco takového používat?
4. Ospravedlní mi těch pár uspořených kilobajtů aplikačního kódu přítomnost frameworku, který leckdy sahá na několik set kilobajtů?
5. Je pro mne práce s DOMem skutečně tolik obtížná a repetitivní, že kvůli ní musím klesnout k užití string-based šablon?

Více jak dekádu je tu s námi nyní již velmi oblíbená metoda osobní produktivity Getting Things Done Davida Allena. Přes svou celosvětovou popularitu metody však má Západ stále nad námi náskok v jejím rozšíření mezi běžnými lidmi, který však postupně doháníme. GTD konference odehrávající se v pražských Dejvicích a jejích více než 200 účastníků tomu byla pěknou ukázkou.

Pořadatelská agentura IconMedia vsadila na kartu GTD, což se jí vyplatilo, a odvedla perfektní práci jak z pohledu programu, tak i organizace. Konferencí nás provázel zkušený moderátor Rostislav Kocman, který nejenže zajišťoval plynulé přechody mezi jednotlivými přednáškami, ale zároveň i zručně moderoval diskuze, kterými byla konference až nebývale prošpikována.

Pojďme se nyní blíže podívat na přednášky, které mě zaujaly, pokusím se doplnit i odkazy na užitečné zdroje.

Co je to GTD – představení metody (Petr Mára + Lukáš Gregor)

Potěšujícím faktem bylo, že většina publika již s GTD zkušenosti měla, nicméně našli se i tací, pro které to byla premiéra. Proto úvodní spíše diskuze Petra Máry a Lukáše Gregora na téma základů a přínosů GTD byla příjemným zahřívacím kolečkem.

Po úvodním představení pánů, jak se kdo ke GTD dostal, jaké s ním má zkušenosti a jak jej praktikuje, se již začaly řešit obecnější témata na úvod.

Především jsme se dozvěděli, jak vůbec s GTD začít. Pánové se shodli na tom, že začít s celým GTD ze dne na den je holý nesmysl. Metoda je natolik komplexní, že by zbytečně rychlý začátek člověka spíše odradil, proto je dobré začíná krůček po krůčku a postupně si tvořit důležité návyky a stavět z nich funkční systém.

Prvním asi nejdůležitějším návykem je zavedení inboxu. Tzn. místa, ať už fyzického nebo virtuálního, kam bude člověk průběžně dávat veškeré nápady, úkoly a povinnosti, které se ho týkají a potřebuje je řešit. Není problémem mít inboxů i vícero, což již velmi záleží na charakteru práce a života každého člověka. Já mám např. inboxy čtyři – inbox ve svému online Todoist úkolovníku, jednoduché poznámky v mobilu, když jsem mimo počítač, složku na papíry ve své pracovní tašce, pokud jsem mimo domov, a domácí pořadač na papírové a fyzické věci jako dopisy, účtenky apod.

Lukáš Gregor, jako správný Moravák, radil udělat si příjemnou neděli, otevřít si víno a na papír vysypat z hlavy veškeré úkoly, které se mě týkají a potřebuji se jim věnovat. Velmi užitečný je v tomto směru Implementation Guide od tvůrce GTD Davida Allena, podle něhož může člověk snadno krok po kroku začít s praktikováním GTD.

Zároveň jsme dostali i upozornění na problémy, které z využívání GTD vyplývají. Jednak se dle Rostislava Kocmana GTD nesmí stát fetišem, čili samotná administrativa GTD procesu nesmí překročit únosnou míru. GTD tu není proto, aby nás zaměstnávalo, ale aby nám v zaměstnání pomáhalo.

Dalším velmi častým problémem, se kterým se také potýkám, je lenivění krátkodobé paměti, jejíž nespolehlivost GTD proces řeší natolik dobře, že jí člověk potřebuje opravdu jen minimálně, což má za následek situace, kdy má člověk pocit, že by si měl raději napsat seznam, co si chce vzít z ledničky, aby na to, než tam dorazí, nezapomněl.

Zajímavým tématem byla i genderová otázka. Dle průzkumů jsou uživatelé GTD z 86 % muži a ze 14 % ženy, což si pánové vysvětlují tak, že muži si rádi hrají s procesy, nástroji a potřebují systém, zatímco ženy to dělají intuitivně.

Online a offline nástroje GTD (Josef Jasanský + Ondřej Nekola)

Podobným formátem diskuze se nesla i další přednáška věnující se nástrojům v GTD procesu.

Josef Jasanský, coby zástupce Apple světa, nedá dopustit na vlajkovou loď GTD v Apple prostředí, a tedy na nástroj OmniFocus, který je z důvodů své robustnosti vhodný spíše pro pokročilé uživatele GTD, kterým však nabízí velkou flexibilitu a možnost nastavit si GTD proces přesně na míru, což má za následek vysokou efektivitu práce.

Nižší penetraci GTD nástrojů ve Windows světě si Josef vysvětluje jako nižší ochotu Windows uživatelů platit za software a zároveň i existencí Outlooku, který lidé, hojně a v korporacích zpravidla z povinnosti, využívají. Pro Windows uživatele však je k dispozici velmi šikovný seriál o využití GTD pomocí Outlooku.

Uživatelům ne-Apple platforem Ondřej Nekola poradil využít projekt Alternative.to, pomocí něhož mohou snadno a rychle nalézt alternativu vybraného softwaru na jiné platformě. Ondřej zároveň i varoval před využitím Evernote pro potřeby GTD, nepřijde mu to dostatečně přirozené. Na druhou stranu nástroje jako Wunderlist, Things nebo již zmíněný OmniFocus by pánové doporučili.

Velkou otázkou ještě je, zda řešit GTD elektronicky nebo na papír. V tomto směru se pánové shodují, že jde o velmi individuální záležitost, každý člověk se musí rozhodnout, co mu více vyhovuje. Nicméně jako jednoduchou formulku, jak se rozhodnout, poradili pánové, že když člověku vyhovuje práce v Gmailu, organizování složek apod., pak je velká pravděpodobnost, že bude mít raději GTD elektronicky.

Panelová diskuze (Mára, Gregor, Jasanský, Nekola)

Závěr prvního bloku konference zakončila společná diskuze všech předešlých řečníků. Zajímavé závěry můžeme shrnout následovně.

Nemůžete-li se rozhodnout, který GTD nástroj vybrat, může vám pomoci srovnání více než 150 GTD nástrojů.

Cross-platformní řešení např. pro vlastníky Mac a zároveň Android zařízení mohou být nástroje Remember the Milk či Doit.im.

Petr Mára popisoval svou cestu k OmniFocusu. Nejprve ho zavrhl, po čase se k němu vrátil, ale zabralo mu dva intenzivní týdny ho pořádně pochopit a nastavit si ho dle svých potřeb, k čemuž mu výrazně pomohla knížka Creating Flow with OmniFocus.

Využití GTD v týmu je velký oříšek. Obecné principy jako dimenze pomáhají, ale konkrétnější věci jako např. kontexty jsou již problémem. Petr Mára má však velmi pozitivní zkušenost z firmy, kde GTD používali z přesvědčení, ne z donucení, všichni, cítil se tam prý jako v zenovém království. :)

Perspektivy a role v GTD (Jiří Knesl)

Po první přestávce si pro nás Jirka Knesl přichystal sice krátkou, ale za to pěkně zacílenou přednášku. Jirka mluvil o rolích, které zaujímáme (např. programátor, otec, potápeč apod.), resp. o rolích, které bychom zaujímat chtěli.

Nejsme schopni zvládat vše, a proto bychom měli dle Paretova pravidla 80/20, o kterém vyšla např. zajímavá knížka od Richarda Kocha, eliminovat své činnosti a zaměřovat se pouze na to, co dává přidanou hodnotu ve směru našich cílů, kýžených rolí.

Jirka radil si na papír sepsat veškeré své role, ve kterých aktuálně jsme a ve kterých bychom být chtěli, a ke každé si poznačit, jak moc se jí aktuálně věnujeme, resp. jak moc bychom se jí věnovat chtěli. Na základě toho pak snadno vidíme, kde máme problém, a tam kde je největší propast bychom měli věnovat většinu své energie. Tento postup můžeme v iteracích postupně aplikovat a dosahovat tak svých cílů. Výrazný postup se dle Jirky neděje na denní bázi, ale pouze v delších časových úsecích.

Život jako disciplína (Jaroslav Homolka + Petr Mára)

Kouč Jaroslav Homolka si ke své přednášce přizval na pomoc Petra Máru a společně odlehčenou formou v motivačním duchu diskutovali na téma disciplíny a sebeorganizace, což je podle Jaroslava klíčovou schopností úspěšných lidí.

Jaroslav z kraje pozvedl publiku náladu svým kvartetem lenocha, kterým by se člověk měl řídit, než se vůbec rozhodne, že bude nějakou činnost dělat:

1. Proč bych to měl dělat, má to vůbec smysl?
2. Když to má smysl, tak proč právě já?
3. Když už já, tak proč právě teď?
4. Proč právě takhle?

Společně s Petrem Jaroslav diskutoval různá témata, jejichž závěry je možné shrnout následovně:

• vybrat si pár věcí (3 – 5 rolí), těm se věnovat naplno a zbytek nechat plavat
• budovat efektivní síť vztahů, společně toho lidé dosáhnou mnohem více, být sám je velmi těžké
• lidé si často pletou management a leadership, nicméně většina lidí ještě stále potřebuje být řízena
• introverti by v sobě měli budovat extrovertní složku, a naopak
• velká rozhodnutí neuspěchat, ale dělat je s jasným záměrem
• držet směr a soustředit se na měřitelné výsledky jako zdroj poznání
• GTD je úžasný nástroj sebevzdělávání, dává neustálý feedback, co vedlo k cíli a co ne
• soustředit se na aktuální moment, popř. budoucnost, minulost již nezměníme
• vytrvat do vítězného konce, věci zpravidla nevyjdou hned, je potřeba je alespoň 3x zkusit

Work life balance (Pavel Trojánek + Ondřej Kubera)

Pavel Trojánek s Ondřejem Kuberou jsou zjevně zkušení v přípravě interaktivních workshopů, přednášku jsme totiž začali velmi netradičně – míčkovou válkou :)

Dostali jsme zpočátku tři otázky:

1. Trávím v práci více času, než bych chtěl?
2. Chtěl bych trávit více času se svými přáteli?
3. Mám dostatek času na své zájmy?

Kdo měl alespoň s jednou z otázek problém, měl hodit míček na Pavla. Zbytek lidí na Ondřeje. Ano, tušíte správně, zhruba 90 % zásahů schytal chudák Pavel :)

Výsledky evropského průzkumu na tyto dotazy vyšly následovně:

• 27 % lidí tráví moc času v práci
• 36 % lidí by chtělo trávit více času s přáteli
• 51 % lidí by chtělo více času na své zájmy
• méně než 10 % necítí žádný konflikt mezi prací a osobním životem

A jak z tohoto problému ven? Eliminace je samozřejmě třeba, ale i ta má své limity. Pánové proto přicházejí s konceptem integrace.

Stěžuje si váš přítel / vaše přítelkyně, že trávíte čas v posilovně místo s ní? Naučte jí chodit do posilovny s vámi a zabili jste dvě mouchy jednou ranou ;)

V podobném duchu jsme si prakticky vyzkoušeli zintegrovat více našich rolí dohromady, tak aby to dávalo smysl a lépe jsme tak využili svého času.

GTD v praxi vedení firem (Tomáš Baránek + Jan Straka)

Závěr konference se nesl opět v duchu diskuze, tentokrát na téma zkušeností se zaváděním principů GTD do fungování firmy. Diskutujícími byli Tomáš Baránek, majitel vydavatelství Jan Melvil Publishing, které mj. přeložilo původní knížku Davida Allena do české podoby Mít Vše Hotovo, čemuž se se věnuje i jejich stejnojmenný informační portál. Druhým diskutujícím byl Jan Straka, podnikatel v oblasti reklamní a grafické tvorby a tisku.

Jan zaváděl GTD ve dvou týmech. V jednom úspěšně, ve druhém však odešel s nepořízenou. Úspěch dle Jana závisel primárně na tom, že si do prvního týmu lidi vybral sám, vybíral si tedy lidi, kteří mu osobně sednou, jsou s ním na vlně a díky tomu neměl problém s komunikací a zaváděním principů GTD.

Na denní bázi používají Toodledo pro seznam projektů, kontextů a úkolů (co zaměstnanec, to kontext), Dropbox pro sdílení souborů a Evernote pro zbytek GTD. Zajímavostí je jejich sdílený seznam “waiting for”, který má praktický následek takový, že na něm nikdo nechce být, tudíž každý na tomto seznamu příslušnou práci co nejdříve udělá, aby na něj kolega nemusel dlouho čekat.

Tomášovi se zase osvědčilo zavedení GTD principů pomocí pozitivních a negativních příkladů. Když např. jeho kolegové, dle jeho slov “chaotici”, na vlastní oči viděli, jak rychle ve svých papírových složkách našel potřebné materiály, hned chtěli mít to samé. Na druhou stranu, když na obálku jedné z knih zapomněli přidat čárové kódy, které museli následně dolepovat ručně, všichni rádi uvítali zavedení šablon s checklisty.

Tomáš má také dobré zkušenosti s metodou Kaizen, Japonci navrženou po Druhé světové válce, která slouží pro zavádění velkých změn pomalou, postupnou cestou, cyklicky krůček po krůčku.

Oběma pánům se osvědčilo zavádět GTD ne procesně, ale přes firemní hodnoty. Zároveň si velmi chválí cestu jednoduchosti, čili ořezat GTD systém na úplné minimum, aby nebyl problém s odlišnou mentalitou lidí v týmu.

Shrnutí

První ročník GTD konference se rozhodně povedl a já už se těším na další :) Pro mě osobně bylo nejhodnotnější si uvědomit své role, zhodnotit, kde jsem teď a kde bych chtěl být, a zároveň si rozmyslet, jak jednotlivé role eliminovat, resp. integrovat, abych byl schopen ten hrozen svých činností lépe a více v pohodě zvládat.

Byli jste na GTD konferenci i vy? Jaký jste z ní měli dojem? Co se vám líbilo a co byste jak zlepšili?

Základní kontrakty jsou:

• Hledání
• Sdílení
• Nastavení

Vyhledávání

Pomocí tohoto kontraktu můžete hledání ve vaší aplikaci integrovat přímo do systémového hledání. Uživatel pak hledá informace z jednoho místa.

Nejdříve je potřeba integraci do systémového vyhledávání deklarovat v package.appxmanifest.

Pak je třeba zaregistrovat událost, kterou vyvolává systémové hledání. Těchto událostí je několik, podle toho, jaký komfort chcete uživateli nabídnout, např. našeptávání. Pokud chcete jen základní vyhledávání, stačí zaregistrovat událost onquerysubmitted.

Windows.ApplicationModel.Search.SearchPane.getForCurrentView().onquerysubmitted = function (eventObject) {
    txtSearch.innerText = eventObject.queryText;
};

Search contract sample obsahuje další příklady použití kontraktu hledání.

Sdílení

Pomocí kontraktu sdílení můžete předávat informace z jedné aplikace do druhé. Princip je velmi podobný schránce. Aplikace může být zdrojem sdílení. Zdroj sdílení naplní datový balíček, který je pak předán aplikaci, která se označuje jako cíl sdílení. Na následujícím snímku obrazovky je zdrojem sdílení aplikace Mapy a cílem sdílení je aplikace Pošta.

Typ sdílených dat

Sdílet můžete jakýkoliv typ dat. Pro některé typy, jako je např. text, URL, obrázek, jsou přímo připravené vlastnosti objektu DataRequest. Pokud potřebujete sdílet jiný typ dat, např. poštovní adresu, musíte tento typ dat nějak popsat. Můžete použít třeba MIME Type nebo obecně uznávané slovníky ze schema.org. Zdroj sdílení jen naplní datový balíček, ale cíl sdílení musí v package.appxmanifest deklarovat, jakým typům dat rozumí.

Zdroj sdílení

U zdroje sdílení stačí opět zaregistrovat příslušnou událost, v které pak naplníte datový balíček informacemi, které chcete sdílet.

Windows.ApplicationModel.DataTransfer.DataTransferManager.getForCurrentView().ondatarequested = function (eventObject) {
    var request = eventObject.request;

    request.data.properties.title = "MSDN Blog"; // musite nastavit!
    request.data.setText("MSDN Blog");
    request.data.setUri(new Windows.Foundation.Uri("http://blogs.msdn.com/b/vyvojari/"));
};

Cíl sdílení

Vytvořit cíl sdílení je již komplexnější úloha, pro kterou budete muset vytvořit i uživatelské rozhraní. Podívejte se na příklad Sharing content target app sample.

Nastavení

Nastavení je vlastně jediný kontrakt, který budete muset implementovat. Do nastavení musíte minimálně přidat typické „O aplikaci“, kde uživatel najde kontakt na technickou podporu a případně odkaz na dokument o ochraně osobních údajů, pokud ho aplikace vyžaduje.

Integrace do nastavení se opět děje pomocí události.

app.onsettings = function (e) {
    e.detail.applicationcommands = {    
        "about": {
            href: "/pages/about/about.html",
            title: "About"
        }
    }
    WinJS.UI.SettingsFlyout.populateSettings(e);
};

Tím jsme vytvořili položku s textem About v nastavení, která odkazuje na stránku /pages/about/about.html. Stránka about musí obsahovat element s id about, který je ovládací prvek WinJS.UI.SettingsFlyout.

<body>
    <div id="about" data-win-control="WinJS.UI.SettingsFlyout" data-win-options="{width: 'narrow'}">
        <div class="SettingsPane">
            <div class="win-label">
                <button onclick="WinJS.UI.SettingsFlyout.show()" class="win-backbutton">
                </button>
                <span class="SettingsTitle">About</span>
            </div>
            <article class="SettingsContent">
                <h2>Kontrakty</h2>
            </article>
        </div>
    </div>
</body>

POZOR! Výchozí barva textu je bílá na bílem pozadí. Je třeba změnit pozadí #about.

Zdrojové kódy z tohoto článku ke stažení.

Mobilní aplikace jsou pro vývojáře stále přitažlivější, především kvůli tomu, že i z domova může šikovný programátor vytvořit aplikace, které se dostanou k milionům uživatelů po celém světě.

Pokud chcete proniknout do hlubin vývoje aplikací a her pro Android, iOS, nebo Windows Phone, podívat se na odvrácenou stranu mobilních platforem, nebo zjistit jak na aplikacích vydělat opravdové peníze, navštivte mDevCamp 2013. Konferenci navazující na velmi úspěšný předchozí ročník s návštěvností přesahující 300 vývojářů ze všech koutů České Republiky i Slovenska.

Připraven je celodenní program rozdělený do tří sálů, který bude doslova nabitý zajímavými speakery a přednáškami. Těšit se můžete například na povídání o tom, jak se vyvíjí aplikace u slavných Madfinger Games, v podání Petra Benýška, David Vávra (Inmite) povypráví o vývoji pro Google Glass, Jan Ilavský a Vladimír Hrinčár (Hyperbolic Magnetism) představí blok o frameworcích pro vývoj mobilních her. Nahlédneme na pokročilá témata z vývoje pro iOS pohledem Roberta Vojty (Tapmates), nebo zkušenosti s monetizací nezávislých Android aplikací Tomáše Hubálka. Chybět nebude ale ani blok o přístupnosti mobilních aplikací napříč platformami, povídání Radka Pavlíčka, Daniela Kuneše (BIGLauncher) a dalších. A to ještě zdaleka není vše, několik dalších hvězdných speakerů bude na webu zveřejněno v průběhu nadcházejících týdnů.

Konference se odehraje v sobotu 25.5. v Praze, předprodej vstupenek bude zahájen už v průběhu tohoto týdne. Chcete-li být mezi prvními, kdo se o předprodeji dozví, registrujte se na webu mDevCamp.cz do newsletteru.

Pořadatelem konference je společnost Inmite, hlavními partnery konference mDevCamp 2013 jsou Google ČR a Nadace Vodafone Česká republika. Hlavními mediálními partnery jsou portály SvetAndroida.cz a Zdroják.cz.

Další odkazy:

• fotky z loňského ročníku: http://goo.gl/5vYUl
• web konference: http://mdevcamp.cz/
• web loňského ročníku: http://mdevcamp.cz/2012/
• přihlášení do newsletteru: http://goo.gl/sCCXe

Navigace

Stránka default.html slouží pro základní inicializaci aplikace a vlastně představuje aplikaci jako celek. Pomocí PageControlNavigater vkládáte do existující, hlavní stránky, stránky jiné.

<div id="contenthost" data-win-control="Application.PageControlNavigator" data-win-options="{home: '/pages/home/home.html'}"></div>

Jednotlivé stránky aplikace jsou pak definované v dalších html, css a js souborech:

Pokud se podíváte do js souborů jednotlivých stránek, tak tam najdete následující definici:

WinJS.UI.Pages.define("/pages/home/home.html", {
    …
}

Tím vytvoříte objekt stránky s pevně daným URI. Na takto vytvořenou stránku se pak odkazujete pomocí stále stejného URI.

about.addEventListener("click", function () {
    WinJS.Navigation.navigate("/pages/about/about.html");
});

Obrazovka je pak složena vlastně z několika stránek:

Pro návrat na předchozí stránku pak použijete:

btnBack.addEventListener("click", function () {
  if (WinJS.Navigation.canGoBack) {
    WinJS.Navigation.back();
  }
});

Jak vidíte, o veškerou navigaci ve vaší aplikaci se stará WinJS.Navigation. Tento princip výrazně zvyšuje výkon aplikace, protože není třeba vždy sestavovat komplet nový DOM a zpracovávat CSS a Javascript od nuly.

Pokud chcete použít element a ze specifikace HTML, tak je doporučeno na stránce vytvořit vlastní událost, která bude kliknutí na odkaz zpracovávat.

Událost:

linkClickEventHandler: function (eventInfo) {
    eventInfo.preventDefault();
    var link = eventInfo.target;
    WinJS.Navigation.navigate(link.href);
}

Registrace události (v události ready stránky):

WinJS.Utilities.query("a").listen("click", this.linkClickEventHandler, false);

 Tím zajistíte, že se bude stránka správně řadit do fronty pro navigaci.

Aplikační lišta pro navigaci

Aplikační lišta je náhrada za klasickou nabídku. Může být na obrazovce nahoře nebo dole.

Do aplikační lišty můžete umístit libovolné ovládací prvky. Aplikační lištu vložíme do stránky default.html bude tak vždy dostupná.

<div id="appbar" data-win-control="WinJS.UI.AppBar">
  <button data-win-control="WinJS.UI.AppBarCommand" data-win-options="{id:'cmd', label:'Command', icon:'placeholder'}" type="button"></button>
</div>

Přiřazení události pak uděláte v inicializaci stránky, tedy v události activated.

var appbar = document.getElementById("appbar").winControl;

var homeButton = appbar.getCommandById("homeButton");
homeButton.addEventListener("click", goToHomePage, false);

Zdrojové kódy z článku ke stažení.

GTD i u vás

Měl jsem to štěstí poznat pár firem, kde se používalo GTD ve větším a v týmech si lidi pomáhali. Někde jsem to GTD i sám zavedl. O tom ale dnes psát nechci.
Chci psát o tom, jak jim to pomohlo zredukovat byrokracii a zrychlilo komunikaci. Proč právě tady na Zdrojáku? Techniky samotné jsou sice platné i mimo IT, ale právě v IT firmách jsem byl ze své praxe svědkem toho všeho.

Hoď mi to do inboxu

Jedním z prvních kroků, které člověk dělá, když implementuje GTD, je uvědomění si svých inboxů. To máme: e-mail, informační systém, osobní e-mail, lístečky kolem monitoru, inbox v nástroji na sebeorganizaci, krátkodobá paměť (Slíbil jsi, že to uděláš! Ne neslíbil!), kolikrát i mobilní telefon.

Někdy umí člověk počet inboxů zredukovat (vždy se eliminuje paměť) na nezbytné minimum. V každém případě ale ví, jaké má inboxy. A tak když někomu řekne: „Hoď mi to do e-mailu/systému/na papír na stůl“, tak že na to nezapomene. Uvědomění všech inboxů je první krok, druhý je kontrola všech inboxů. Tedy člověk nekouká jen do e-mailu nebo IS, ale kontroluje všechny zdroje úkolů soustavně, a to je tím kouzlem, proč lidé v GTD vypadají, jako by nikdy nic nezapomněli.

Dej mi vědět, až to bude

No a když už nám tedy něco přistálo v inboxu, ještě není vůbec jasné, že jsme my ti praví, kdo mají danou událost udělat.

Máme 2 varianty:

1. úkol přistál na špatném stole, má ho řešit někdo jiný
2. úkol přistál u nás, my sice danou činnost nemáme dělat, ale záleží nám na výsledku

Pokud platí a), úkol předáme do inboxu někomu jinému. Dál se o věc nemusíme starat.

Pokud nás ale zajímá, jak dopadl výsledek, přidáme dotyčnému do inboxu zprávu, „až bude hotovo, dej mi vědět“ a přidáte si záležitost na seznám Čekám na. Pak máte jistotu, že se na věc nezapomene a že ji máte pod kontrolou.

Jednání, méně, lépe, efektivně

Když už musíte jednat, je dobré držet se několika pravidel.

• výsledkem jednání musí být, jaké jsou další kroky a kdo za ně zodpovídá, jinak se vaše jednání rozpliznou a nebudou mít ideální výsledek
• na jednání jde tak málo lidí, jak je to možné
• nejednat, pokud není o čem

Efektivně na e-mail

GTD minimalizuje počet inboxů. To znamená eliminovat filtry, které vám rozhazují e-maily do různých složek. Místo toho jeden inbox, který je pravidelně celý vyprázdněn a zpracován.

Návod, jak na e-mail:

• 1 inbox – čím méně e-mailů ke kontrole, tím lepší přehled na jeden pohled
• držte počet mailů ve schránce velmi nízký – průběžně objasňujte úlohy a rozhodujte se, jaké kroky podniknete
• nepracujte s e-mailem jako se seznamem úkolů – lidí, kteří používají e-mail jako seznam úkolů, je možná víc, než těch, kdo dělají GTD. Bohužel! E-mail neobsahuje žádnou evidenci toho, jaký chci výsledek, v jaké fázi úkol je a jestli jsem mezitím něco nezadal dalším lidem i jinými komunikačními kanály.

Víc informací

GTD je metoda, která se orientuje především na kroky spojené s řízením pracovního procesu. Cílem metody je vytvořit a udržovat spolehlivý a funkční přehled všech úkolů, které potřebujete udělat, a tyto úkoly přenést z paměti například na papír nebo do elektronické aplikace a mozek nadále používat jen ke kreativitě a dalšímu konstruktivnímu myšlení.
Chcete se o GTD dozvědět víc? Přijďte na GTD konferenci, kde budu přednášet o tom, jak probíhá plánování v GTD a jak se GTD staví k delším časovým horizontům. Konference probíhá v Praze 27.4., tedy už co nevidět. Zaregistrovat se můžete zde.

Ovládací prvky ze specifikace HTML5

Ovládací prvky ze specifikace HTML5 používáte naprosto identicky, jako u běžných webových aplikací. Jejich design je však přizpůsoben pro dotykové ovládání. Dalo by se říct, že výchozí styl ovládacího prvku je upraven tak, aby odpovídal požadavkům pro ovládání doteky. Pro toto chování nemusíte vůbec nic měnit ani nastavovat. K těmto ovládacím prvkům přistupujete stejně jako u běžné webové stránky.

Specifické ovládací prvky

Windows Runtime vám nabízí celou řadu ovládacích prvků, které usnadňují vývoj aplikace, ale nejsou součástí specifikace HTML5. Je to podobné, jako když pracuje např. s jQuery UI. Ovládací prvek je do stránky vložen pomocí Custom Data Attributes.

<div data-win-control="WinJS.UI.ToggleSwitch"
     data-win-options="{title: 'Wi-fi'}"
     id="myToggle">
</div>

Atribut data-win-control odkazuje na ovládací prvek ToogleSwitch, který je specifický pro Windows Store aplikace a nemá obdobu ve specifikaci HTML5. Tento ovládací prvek je ale ve finále samozřejmě vykreslen pomocí HTML5. Atributem data-win-options nastavujete vlastnosti ovládacího prvku.

Během inicializace aplikace je třeba všechny Custom Data Attributes zpracovat. O to se stará kód v události onactivated. Tento kód je součástí šablony.

args.setPromise(WinJS.UI.processAll());

Metoda processAll projde DOM a hledá elementy s atributem data-win-control, které zamění za příslušné prvky uživatelského rozhraní. ToogleSwitch je například reprezentován takto:

<div class="win-title" id="ms__id1" role="note">Wi-fi</div>
<div style="display: -ms-grid;">
  <div>On</div><div class="win-label">Off</div><input class="win-switch" role="checkbox" aria-checked="false" aria-disabled="false" aria-labelledby="ms__id1" type="range" max="1" step="1">
</div>

ListView

Představte si, že máte pole objektů, které jsou například vygenerovány z databáze nebo RSS Feed, a toto pole potřebujete zobrazit.

[{ title: "Banana Blast", text: "Low-fat frozen yogurt", picture: "/images/60Banana.png" },
 { title: "Lavish Lemon Ice", text: "Sorbet", picture: "/images/60Lemon.png" },
 { title: "Marvelous Mint", text: "Gelato", picture: "/images/60Mint.png" },
 { title: "Creamy Orange", text: "Sorbet", picture: "/images/60Orange.png" },
 { title: "Succulent Strawberry", text: "Sorbet", picture: "/images/60Strawberry.png" }]

Abyste nemuseli generovat DOM v nějakém cyklu, tak jak to bylo běžné v začátcích PHP, můžete použít ovládací prvek ListView.

<div id="smallListIconTextTemplate"data-win-control="WinJS.Binding.Template"style="display: none">
  <div class="smallListIconTextItem">
    <img src="#"class="smallListIconTextItem-Image"data-win-bind="src: picture"/>
    <div class="smallListIconTextItem-Detail">
      <h4 data-win-bind="innerText: title"></h4>
      <h6 data-win-bind="innerText: text"></h6>
    </div>
  </div>
</div>

<div id="listView"
     class="win-selectionstylefilled"
     data-win-control="WinJS.UI.ListView"
     data-win-options="{
       itemDataSource: myData.dataSource,
       itemTemplate: smallListIconTextTemplate,
       selectionMode: 'none',
       tapBehavior: 'none',
       swipeBehavior: 'none',
       layout: { type: WinJS.UI.GridLayout }
     }"
></div>

Princip je velmi jednoduchý. Pro každý prvek pole vytvoříte tzv. itemTemplate. Je to vlastně šablona, která se zkopíruje tolikrát, kolik je položek v poli a použije se pro vykreslení položek pole. Propojení šablony a objektu v poli se využívá datová vazba pomocí atributu data-win-bind. Datová vazba propojí vlastnost elementu s vlastností objektu. Detailní příklad najdete v příkladu HTML ListView essentials sample. Zdrojové kódy výše uvedeného příkladu najdete v příloze toho článku.

Process Lifetime Management – PLM

Windows Store aplikace jsou svým chováním podobné aplikacím na mobilních telefonech. Pokud není aplikace na popředí (Running), tak aplikace neběží (Suspended) a její vlákna na procesoru jsou zastavena, ale aplikace je stále zavedena v paměti. Mezi stavy Running a Suspended aplikace přechází vlastně okamžitě, stačí spustit její vlákna na procesoru. Aplikace je o přechodu mezi jednotlivými stavy obeznámena pomocí událostí.

Pokud začnou docházet systémové zdroje, tak je aplikace definitivně ukončena. Je odstraněna z paměti a jsou zrušena její vlákna na procesoru. Protože je již aplikace v režimu Suspended (neběží), tak se o přechodu do stavu Not running nedozví. O tom, že byla aplikace „násilně“ ukončena se dozví až při dalším startu. Tato informace je uchována ve vlastnosti args.detail.previousExecutionState.

Je na vás, na programátorech, abyste při události Suspending uložili rozdělanou práci uživatele a při dalším startu, pokud se aplikace dostala až do stavu Not running, jste uživatelovu rozdělanou práci obnovili.

app.onactivated = function (args) {
  if (args.detail.kind === activation.ActivationKind.launch) {
    if (args.detail.previousExecutionState !== activation.ApplicationExecutionState.terminated) {
      // TODO: This application has been newly launched. Initialize
      // your application here.
    } else {
      // TODO: This application has been reactivated from suspension.
      // Restore application state here.
    }
    args.setPromise(WinJS.UI.processAll());
  }
};

app.oncheckpoint = function (args) {
  // TODO: This application is about to be suspended. Save any state
  // that needs to persist across suspensions here. You might use the
  // WinJS.Application.sessionState object, which is automatically
  // saved and restored across suspension. If you need to complete an
  // asynchronous operation before your application is suspended, call
  // args.setPromise().
};

Může běžet aplikace na pozadí?

Ano i ne. Pokud potřebujete, aby vaše aplikace dělala nějakou činnost na pozadí, tak pro tuto činnost musíte najít vhodnou systémovou službu a té práci předat. Například, když víte, že budete stahovat velký objem dat, tak tuto práci nebude dělat vaše aplikace, ale předá ji systémové službě BackgroundTransfer.