Případ Kik a proč je dobře, že existuje možnost odstranit balíček z npm

Před pár dny proběhla událost, která si získala mimořádnou pozornost a pravděpodobně nikomu neušla. Odstranění jednoho balíčku z repozitáře npm způsobilo rozbití jiného balíčku, na kterém závisel Babel, velmi populární transpilátor pro převod kódu v ES6+ do ES5, a na krátkou dobu tím prakticky přestal fungovat repozitář npm. Tato událost přinesla několik zajímavých bodů, které stojí za zamyšlení.

Pokračovaní na novém blogu na Medium.

Async/await v JavaScriptu

S ES7 přichází do JavaScriptu klíčová slova await/async, která výrazně usnadní práci s asynchronním během skriptů. Zatím je jejich přidání ve 3. fázi schvalování (Candidate), díky Babelu je možné je používat (testovat) už dnes. 

Nejprve malé shrnutí, jak se asynchronní běh řešil dřív.

Řešení pomocí callbacků

V tomto článku budu pro ukázku používat funkci request(), která má simulovat vyslání HTTP požadavku a vrácení HTTP odpovědi, a doAllRequests(), která pomocí třech volání funkce request() zpracuje odpovědi ze tří webů. 

Ten vůbec nejstarší způsob bylo řešení pomocí callbacků. Asynchronní funkce přijala jako jeden z parametrů jinou funkci, kterou pak zavolala, jakmile dokončila zpracování.


const request = (url, cb) => {
  setTimeout(() => {
    cb(null, `Odpověď ze serveru ${url}.`)
  }, 1000)
}

const doAllRequests = () => {

  request('http://www.example.com', (err, body) => {
    // if (err) ...
    console.log(body)

    request('http://www.example2.com', (err, body2) => {
      // if (err) ...
      console.log(body2)

      request('http://www.example3.com', (err, body3) => {
        // if (err) ...
        console.log(body3)
      })
    })

  })
}

doAllRequests()

Problémů s callbacky bylo mnoho, především vznikal nepřehledný kód plný zanořených funkcí.

Řešení pomocí Promise

Později přišlo řešení pomocí třídy Promise, která se dostala i do ES6 a dnes ho už podporují jak Node.js, tak všechny hlavní prohlížeče.


const request = (url) => {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve(`Odpověď ze serveru ${url}.`)
    }, 1000)
  })
}

const doAllRequests = () => {
  request('http://www.example.com').then((body) => {
    console.log(body)
    return request('http://www.example2.com')

  }).then((body2) => {
    console.log(body2)
    return request('http://www.example3.com')

  }).then((body3) => {
    console.log(body3)

  }).catch((err) => {
    // zpracovani chyby
  })
}

doAllRequests()

Ani tohle řešení není moc ideální, funkce doAllRequests() je stále dost složitá a nepřehledná.

Řešení pomocí generátorů

Kromě Promise přináší ES6 i generátory, který lze použít také pro řízení asynchronního zpracování skriptu. Ideální je použití s knihovnou co.

Funkce request() bude stejná jako dříve, bude vracet Promise:


import co from 'co'

co(function* () {

  let body = yield request('http://www.example.com')
  let body2 = yield request('http://www.example2.com')
  let body3 = yield request('http://www.example3.com')

  console.log(body, body2, body3)
}).catch((err) => {
  // zpracovani chyby
})

Řešení pomocí async/await

S příchodem ES7 máme nové řešení pomocí klíčových slov async/await, což je vlastně jen obal nad generátory. Funkce request() bude opět vracet Promise, ale funkce doAllRequests() bude mnohem jednodušší:


const doAllRequests = async () => {
  try {

    let body = await request('http://www.example.com')
    let body2 = await request('http://www.example2.com')
    let body3 = await request('http://www.example3.com')

    console.log(body, body2, body3)

  } catch (err) {
    //zpracuj chybu...
  }
}

doAllRequests()

Zápis je nyní mnohem přehlednější a vše vypadá, jako kdyby byl kód synchronní. Je potřeba pouze označit funkci klíčovým slovem async a před funkci, která vrací Promise, dát klíčové slovo await. Chyby se zpracovávají pomocí try/catch, což je určitě příjemnější, než neustále testovat první parametr callbacku.

Konference Devel.cz 2015 a přednáška Webová API a Node.js

Včera (sobota 11.4.) se konala konference Devel.cz 2015. V dalším textu nejprve shrnu moje dojmy z celé akce, druhá část pak obsahuje podrobnější shrnutí mé přednášky o webových API a Node.js.

Konference Devel.cz

Celá akce byla, alespoň z mého pohledu, velmi vydařená. Za velké plus bych označil formát přednášek. Myslím, že právě 20 až 30 minut je pro podobný typ akcí nejlepší délka přednášek. Je to dost na to, aby přednášející mohl podrobněji popsat danou věc, ale zároveň to není tak moc, aby přicházel o pozornost. Letos bylo 7 přednášek 30 minut a 5 přednášek 20 minut. Pro příště bych se nebál udělat více, případně všechny, jen 20 minut, čímž by vznikl prostor ještě pro jeden samostatný blok přednášek. Delší přednášky bych nechal jen lidem jako Patrick Zandl, kteří dokážou během své půlhodinové přednášky ostatní po celých 45 minut výborně bavit. Vyhovuje mi taky formát hodina až hodina a půl přednášek + 20 minut pauzy.

Líbil se mi celkový mix přednášek, témata byla vybrána velmi dobře. Pro mě osobně byla nejlepší přednáška ta poslední od Ondry Žáry o WebGL, strhující tempo, vtipná a pro mě taky praktická a info z ní se mi bude hodit. Bavil jsem se výborně u již zmíněného Patricka Zandla a popisu strastí hardwarového startupu. Super byla také přednáška od Martina Michálka, poslední rok a půl se díky aktuálnímu projektu už věnuji jen serverové části vývoje a CSS trochu zanedbávám, takže se mi info o flexboxu libilo a hodilo. A ještě jedna přednáška, kterou zmíním, je ta o HSTS od Michala Špačka, opět je to něco, co s ohledem na to, že nyní hodně řešíme i bezpečnost naší aplikace, velmi hodí. Ostatní přednášky byly taky dobré, ale tyhle byly pro mě nejlepší.

Celkově se mi tedy konference líbila a čas na konferenci beru jako smysluplně využitý.

Úvodem k mé přednášce

Zvažoval jsem dvě možná témata na mojí přednášku.

První téma by se týkalo obecně návrhu API. Protože jsem měl možnost pracovat s množstvím API trochu detailněji, než je obvyklé, šlo by krásně popsat různé problémy, které mají známá API. Třeba popsat to, proč Shopify špatně implementuje OAuth2, proč se u většiny API nedá používat klasické stránkování jako na frontendu a musí se to u API řešit jinak, problémy kolem práce s oznamováním chyb, problémy s kešováním, s výkonem atd., velké téma by byly určitě i dokumentace. Bylo by toho hodně a bylo by to určitě zajímavé a řada věcí nikde popsaných není. Problém je v tom, že by tohle téma nebylo pro ostatní tak přínosné, protože málokdo z návštěvníků bude třeba v následujícím roce pro nějakou službu navrhovat a psát API, přednáška by tedy pro ostatní tak užitečná nebyla. Pokud by to byla konference typu Webexpo, tak bych zvolil tohle téma, protože se přednášky odehrávají v 6 různých místech a koho návrhy API nezajímají, ten by šel jinam, ale pro Devel.cz jsem chtěl, aby ty informace mohlo využít co nejvíce lidí.

Takže jsem vzal druhé téma, a to přímo poznatky z vývoje projektu Integromat.com. Ten vyvíjíme už rok a půl a teď probíhá testování, spustíme to nejpozději do konce prázdnin, ale nejspíš mnohem dříve (chcete-li, můžete nám na odkazované stránce nechat mail a až bude nějaká beta verze, tak vám napíšeme). Původně jsme chtěli projekt spustit těsně před konferencí v nějaké beta verzi, ale měli jsme informace o tom, že se v blízkosti konference bude pohybovat Michal Špaček a v takovém případě je dobré si rozmyslet, zda není lepší věnovat raději další dva měsíce testování zabezpečení, pro což jsme se také rozhodli.

Integromat je to integrační platforma, přes kterou si můžete propojit velké množství služeb. Takže můžete propojit třeba Instagram s Picasou a kdykoliv publikujete novou fotku na Instagramu, tak ji Integromat stáhne, něco s ní třeba udělá, zmenší ji, přidá k ní vodoznak nebo cokoliv chcete a pak ji pošle na Picasu. Podobné služby již existují, nicméně Integromat toho umí mnohem, mnohem více, především umí propojit neomezené množství služeb a vytvářet i mnohem složitější scénáře. Celý Integromat je napsán v Node.js v CoffeeScriptu.

Přednáška Webová API a Node.js

Pro obsah přednášky jsem vybral jednu chybu, kterou jsme udělali a která nás stála hodně času. A pak jedno dobré rozhodnutí, které nám naopak hodně času ušetřilo.

Oficiální npm balíčky služeb pro komunikaci s jejich API

Nejprve k té chybě. Ta spočívala v tom, že jsme využívali npm balíčky služeb pro komunikaci s jejich API. Řada služeb, např. Dropbox, Evernote, Google atd. vlastního Node.js klienta pro komunikaci s API. Kromě těch oficiálních existují ještě další balíčky třetích stran. V Node.js je k dispozici cca 140 tis. balíčků, tedy mnohem více, než má jakákoliv jiná platforma pro vývoj aplikací. Takže se může zdát jako docela dobrý nápad některý z těchto balíčků použít a neobjevovat znova kolo. Téměř pro každou službu nějaký npm balíček existuje, někdo už něco napsal a publikoval.

Takže takhle jsme postupovali i my. Když jsme chtěli doplnit do Integromatu třeba modul Dropbox, tak jsme zjistili, že Dropbox přímo nabízí jimi vyvíjeného Node.js klienta, takže jsme ho logicky použili. Nicméně Integromat se velmi dynamicky vyvíjí a neustále se měnilo jádro tím, jak se přidávala nová a nová napojení. No a zde se naráželo na problém. Ty věci, které jsme nově potřebovali, ten daný npm balíček nepodporoval a stálo hodně času to různě obcházet. Nakonec to vedlo k tomu, že jsme tyto balíčky služeb pro napojení na API z projektu odstranili a vše jsme si napsali sami.

První problém, na který jsme často naráželi, se týká obecně značné části npm balíčků, a jde o nerozšiřitelnost. Značná část vývojářů píše balíčky tak, že veškerý kód zaobalí do jedné obrovské funkce. To má velkou nevýhodu v tom, že do ní člověk nemůže nijak vstoupit. Když je potřeba upravit třeba jednu podmínku, tak to nijak nejde. Musí to vyřešit třeba tak, že si to forkne na Githubu a doplní si, co potřebuje, ale to není ideální.

Existují principy SOLID pro objektově orientovaný návrh a jedním z nich je i open/closed princip, který říká, že třídy, moduly, funkce atd. by měly být vždy otevřeny pro rozšíření a uzavřeny pro modifikace. A to platí i zde. Balíčky by měly být otevřeny pro individuální rozšíření. Jedna z věcí, která hodně přispívá k tomu, že je kód snadno rozšiřitelný, je psaní metod, které jsou hodně krátké, obvykle do 5 řádků.

První problém tedy je, že člověk nemůže snadno vstoupit do těchto oficiálních balíčků, když potřebuje něco změnit. Je to třeba taková drobnost jako HTTP kešování, což téměř každé API nějaké větší služby podporuje. Nicméně onen klient, npm balíček, třeba neumožní hlavičky zadat. A pro Integromat je to velký problém, protože tohle podporovat musí, jinak by ho to stálo mnoho zbytečného výkonu navíc. Jestli vám API jako odpověď vrátí HTTP kód 304, tedy beze změny, nebo zda musíte neustále zpracovávat několik MB soubor, je hodně znát.

Další problém je skrývání důležitých detailů. Když se třeba stane nějaká chyba, tak mnohdy ty balíčky nevrátí všechny důležité informace, např. vrácené hlavičky, stavový kód a třeba vrátí jen text chyby. To je opět problém, protože Integromat reaguje na různé chyby různě.

Takže když API vrátí stavový kód 401, tak to znamená, že Integromat již nemá přístup k danému účtu a automaticky kontaktuje uživatele a požádá ho, aby přístup obnovil. Když třeba dostane nějakou pětistovku, tak to obvykle znamená, že daný server je na chvíli odstaven a scénář se místo toho pustí za chvíli znova. Když dostane kód 429, tak to znamená příliš mnoho požadavků ze strany Integromatu a třeba Github vrácí sadu X-RateLimit hlaviček, které říkají, za jak dlouho se můžeme ptát znova. Při podobných implementacích potřebuje člověk znát úplně všechno, co server vrátí a tyto balíčky to často tak nedělají.

Další problém třeba neaktuálnost. Dané API se neustále vyvíjí a pořád se mění, avšak ten Node.js klient, npm balíček, zůstává stále stejný. Ukazoval jsem příklad s Evernotem.

Rozhodně tedy nedoporučuji tyhle klienty využívat a platí to pro všechny jazyky/platformy, nejen pro Node.js. Je mnohem snazší si to napsat sám. Dnes už všechna větší API jsou RESTová a používají JSON, takže se s tím pracuje velmi snadno.

Podobně pokud nějaké API přímo vytváříte, tak nedoporučuji k tomu programovat i vlastního klienta. Mnohem lepší je, pokud se zaměříte na samotnou dokumentaci a každý možný HTTP požadavek přesně popíšete. V tomhle jsou naprosto úžasné dokumentace od Apiary, kde je vždy jasně vidět, jak celá komunikace vypadá.

Integrační testování

Druhá část přednášky byla o integračním testování, které je minimálně stejně důležité, jako klasické unit testy, ale na konferencích to tak časté téma není.

Celé to funguje takto. Spustí se nějaká komunikace mezi Integromatem a nějakou službou, třeba Dropboxem, a všechny HTTP požadavky, odpovědi i výstupy se nahrávají a poté se uloží do testovacího souboru. Když se poté spustí test, tak se vytvoří falešná implementace Node.js http modulu a ten na příchozí požadavky bude reagovat předpřipravenými odpověďmi. Takže se nekomunikuje s ostrým Dropboxem, ale jen s jeho falešnou náhradou.

Teď podrobněji. Takhle vypadá vzorový příklad:

doRequest = (done) ->
  options =
    url: "https://api.dropbox.com/1/account/info"
    json: true

    request.get options, (err, response, body) ->
      ...
      done null,
        id: body.user.id

recorder.record()

doRequest (err, data) ->
  ...
  recorder.save "test1.json", data

V první části se definuje funkce doRequest(), která přijímá jeden parametr callback, který se zavolá po zpracování HTTP odpovědi z Dropboxu.

Na začátku funkce se specifikuje, jak má daný požadavek vypadat. Zadává se URL, pak že bude požadavek zpracován jako JSON. Následně se přes balíček request požadavek zašle a také zpracuje, přičemž z té odpovědi mě pouze zajímá ID uživatele, což je výstup z té funkce. Mohl bych chtít uchovat více informací, ale pro tento konkrétní příklad mě bude zajímat jen to ID.

V druhé části se spustí nahrávání požadavků. Od té chvíle se budou všechny HTTP požadavky nahrávat a ukládat do paměti. Následně se funkce doRequest() zavolá a její výstup se uloží společně s přesným zněním HTTP požadavku a odpovědi do souboru test1.json. Tímto způsobem se vygeneruje jeden test.

Tento příklad je velmi zjednodušený, u reálného požadavku by ještě bylo potřeba doplnit autorizační token uživatele, zpracovat případné chyby atd., ale pro ukázku to stačí takto.

Obsah onoho souboru pak vypadá takto:

{
    "request": {
        "method": "GET",
        "path": "/1/user/info",
        "host": "api.dropbox.com",
        "protocol": "https",
        "headers": {
            "accept": "application/json"
        }
    },
    "response": {
        "statusCode": 200,
        "headers": {
           ...
        },
        "body": "..."
    },
    "data": {
        "id": 123
    }
}

Je tady přesné znění toho, jak vypadal HTTP požadavek a odpověď. Jak vypadaly hlavičky, stavový kód, obsah a vše ostatní. A samozřejmě také výstup z funkce doRequest(), což je v kolekci data. To je jeden test.

Pak už zbývá jen test načíst a spustit:

tester.load "test1.json", doRequest

Mám tady nějaký tester, kterému předám název souboru s testem, a funkci, kterou chci testovat. Ten tester soubor načte a upraví reálný node.js modul HTTP, aby na požadavek s cestou account/info vrátil vždy tu vygenerovanou odpověď. Následně funkce doRequest() spustí a testuje, zda je její výstup stejný, jak výstup vygenerovaný v souboru. Když je požadavek nebo výstup jiný, tak test selže. Znamená to, že se něco změnilo, někde může být chyba.

Důležité je, že není potřeba jakkoliv funkci doRequest() pro test upravovat. Ona neví, že komunikuje s falešným modulem HTTP. Vše se chová jako reálná komunikace.

Takový způsob testování má nějaké výhody a nevýhody. Ty výhody vidím hlavně dvě. První je velká rychlost a snadnost, s jakou se nový test vytvoří. Což je hodně důležité, protože lidi obecně testy píšou neradi, takže když je zde nějaký rychlý způsob, jak testy vytvářet, tak je to velké plus.

A druhá velká výhoda je, že se testuje kompletně celá komunikace, to znamená vzájemná interakce více modulů a není potřeba kód pro test nijak upravovat. Je to dobrý doplněk k unit testům.

Naopak nevýhoda je v tom, že když se něco změní, posílají se nějaké další parametry, tak je potřeba test upravit, případně i přegenerovat. Nicméně tyhle testy používáme přibližně půl roku u napojení na úplně všechny služby a mnohokrát nám pomohly odhalit různé problémy, takže je doporučuji.

Pro tohle nahrávání požadavků a vytvoření falešné implementace http modulu se dá použít npm balíček nock.

Návrhy API

Na závěr jeden tip. Pokud vytváříte nové API, hlavně se neinspirujte u těch nejznámějších služeb. Když má někdo navrhnout nějaké API, a zažil jsem to několikrát, tak ho jako první napadne podívat se, jak to řeší třeba Facebook nebo Twitter a pak to zkopíruje. Tohle není úplně dobrý nápad. Problém je v tom, že tyhle API jsou už starší a musí udržovat zpětnou kompatibilitu a různé věci by dnes řešili třeba už jinak, ale změnit to jednoduše nemohou.

Pokud se chcete inspirovat, tak poměrně hezká API jsou nová API od Google, zejména Google Drive API. A věc, která se mi docela líbí je standard JSON API, kde je přesně řečeno, jak co má vypadat, jak se řeší odkazy, jak má vypadat filtrování dat, řazení, stránkování atd, takže pokud nevíte, jak něco udělat, podívejte se tam.

Předpovědi ekonomického a politického vývoje

Až příště uslyšíte nějakou ekonomickou nebo politickou předpověď, vzpomeňte si na tohle:

„Po dobu studie prováděl Philip Tetlock, profesor psychologie na Pensylvánské univerzitě, průběžné rozhovory s 284 lidmi, kteří si vydělávali tím, že zpracovávali komentáře nebo dávali rady ohledně politických či ekonomických trendů. Tito experti měli ohodnotit pravděpodobnost, že určitá událost v ne příliš vzdálené budoucnosti nastane, a to jednak v regionech světa, na kterou se daný odborník specializoval, a jednak v oblastech, ve kterých měl méně znalostí. Bude Gorbačov vytlačen ze své pozice v rámci státního převratu? Vstoupí USA do války v Perském zálivu? Která země se stane příštím novým velkým trhem? Celkem takto Tetlock shromáždil více než 80 tis. předpovědí. Také u expertů zjišťoval, jak ke svému závěru došli, jak reagovali, když se ukázalo, že předpověď byla mylná, jak hodnotili důkazy, které nepodporovaly jejich stanovisko. Respondenti měli hodnotit u každého případu pravděpodobnost tří alternativních výsledků: zachování statu quo, vývoj směrem k vyšší politické svobodě nebo ekonomickému růstu, anebo vývoj opačný (méně politické svobody, ekonomický pokles).

Výsledky byly zničující. Experti vykázali horší výkon, než kdyby jednoduše přidělili každému ze tří potenciálních výsledků stejnou pravděpodobnost. Jinými slovy lidé, kteří tráví svůj čas a živí se tím, že studují konkrétní problematiku, produkují slabší předpovědi než šimpanzi házející šipky, kteří distribuovali výsledky rovnoměrně mezi dané alternativy. Dokonce ani v regionech, které znali nejlépe, experti nedosáhli výrazně lepších výsledků než jiní, kteří se na tyto oblasti nespecializovali.

Ti, kteří toho věděli více, byli v předpovědích o něco lepší než ti, kteří toho věděli méně. Ale expertu s nejvíce znalostmi bývají často méně spolehliví. Je to proto, že člověk, který si osvojí více znalostí, si také vybuduje větší iluze o svých dovednostech a stává se nerealisticky sebevědomým. “

Philip E. Tetlock, Expert Political Judgment: How Good Is It? How Can We Know (Princton University Press, 2005).

Úryvek je z českého překladu knihy Thinking, Fast and Slow od laureáta Nobelovy ceny za ekonomii za rok 2002 Daniela Kahnemana.

 

Pozvánka na konferenci Devel.cz 2015

Poslední rok a půl jsem společně s kolegy Integrators trávil nad vývojem platformy, která umožňuje různě propojovat velké množství služeb. Díky tomu jsem mimo jiné dělal napojení na cca 60 webových API. Práce s API na podobném projektu je mnohem náročnější, než je obvyklé. Je potřeba velmi detailně řešit výkon, testování, ale i třeba transakčnost, mnoho různých limitů ze strany služeb, extrémní požadavky jsou kladené na bezpečnost.

Právě poznatky z tohoto projektu jsou pak námětem pro mojí přednášku na konferenci Devel.cz 2015. Cíl je vybrat cca 3 – 4 nejdůležitějších poučení z vývoje. Nápady, které se ukázaly být později velmi užitečnými. Ale také chyby, které mě pak stály hodně času při předělávání. Kritériem je maximální užitečnost. Žádné teoretické věci, ale přímo to, co se dá ihned využít. Dnes má téměř každá rozšířenější webový aplikace i svoje API a s propojováním služeb se nejspíš každý vývojář bude čím dál častěji setkávat, téma je tedy, myslím si, velmi aktuální.

Emoční inteligence a snižování váhy

Za poslední 3 měsíce jsem se zbavil 17 kg váhy. Na podzim jsem přišel o obezitu a po Novém roce i o nadváhu. Způsob, jakým jsem toho dosáhl, byl ten nejpřirozenější, nejklasičtější, nejlevnější a podle mě i nejzdravější. Nešlo o žádnou magii – žádné tablety, žádní poradci, žádné hladovky, ani žádná fitnesscentra. Stačilo jen lehce změnit stravu, rozdělit ji na více porcí, konzumovat ji během celého dne a každý den ujít pár kilometrů. To bohatě stačilo na to, abych každý týden přicházel o kilogram své hmotnosti.

Ne pro každého je však stejný úkol snadno řešitelný a řada lidí s tím má se snížením váhy velké problémy, mnohdy po celý život. Podle Organizace OSN pro výživu a zemědělství (FAO) má Česká republika nejvyšší procento obézních dospělých ze všech zemí na celém světě (1). Důsledky obezity jsou přitom velmi závažné, u lidí s obezitou je mimo jiné mnohem častější výskyt rakoviny (2), kterou v České republice onemocní každý 3. člověk a každý 4. na ni umírá (3).  Jak je možné, že vůbec něco jako epidemie obezity může existovat? Racionální úvaha přece říká, že rozhodnutí být obézní je po všech stránkách špatné.

Vím, že se do stavu obezity člověk může snadno dostat. Často jsem zažíval to, čemu se říká „stav flow“ (4), tedy plné soustředění, kdy člověk přestává vnímat okolí a čas. Ráno jsem se posadil k počítači s cílem něco rychle doprogrogramovat, a když jsem se končeně rozhodl, že je čas na snídani, zjistil jsem, že jsem u počítače strávil celý den a najednou byla tma a večer. Stav flow není typický jen pro programátory, u mě to však byl možná hlavní důvod, že jsem často měl jen jedno, dvě jídla denně, avšak vyšší kalorické hodnoty, než bylo nutné.

Příčiny toho, jak se člověk stane obézním, jsou různé. Zajímá mě však opačný proces, proč je takový problém váhu zase snížit. Podle studie VZP z roku 2011 (5) se 34% lidí obezitou snažilo zhubnout více než 5x, obezity se však trvale zbavit nedokázali. Ve svém okolí mám osoby, které se o trvalé zhubnutí neúspěšně pokoušely. Vždy to končilo na tom, že se daná osoba nedokázala k něčemu donutit  –  buď snížit kalorickou hodnotu denního přijmu stravy, nebo se pravidelně věnovat nějaké aktivitě.

Zaměřím se tedy pouze na jeden aspekt – na psychologickou stránku věci, která je z mého pohledu na celé věci nejdůležitější. Tedy co přesně člověk potřebuje k tomu, aby dokázal třeba hubnutí nebo cokoliv jiného dotáhnout úspěšně do konce.

Co je emoční inteligence

Pojem „emoční inteligence“ pochází z konce minulého století a za jeho rozšíření mezi veřejnost vděčíme především Danielu Golemanovi, psychologovi z Harvardu, díky jeho knize Emotional Intelligence: Why It Can Matter More Than IQ z roku 1995. Definice pojmu se velmi různí, česká Wikipedie popisuje emoční inteligenci jako schopnost zvládání svých emocí a umění vcítit se do emocí ostatních jedinců (6). Daniel Goleman pojem definuje v širším významu a vyjmenoval několik schopností, které emoční inteligenci tvoří: schopnost dokázat sám sebe motivovat a nevzdávat se tváří v tvář obtížím a frustraci, schopnost ovládat svoje pohnutky a odložit uspokojení na pozdější dobu, schopnost ovládnout svojí náladu a zabránit úzkosti a nervozitě, schopnost ovlivňovat kvalitu svého myšlení, schopnost vcítit se do situace druhého člověka a ani v těžkých chvílích neztrácet naději (7).

Goleman bývá za své pojetí definice emoční inteligence kritizován, a nejspíš i oprávněně (8), mně osobně se však jeho snaha upozornit na význam těchto konkrétních schopností zamlouvá. Právě některé ze zmíněných schopností přijdou na mysl člověku tehdy, chce-li vyčlenit typické vlastnosti osob, kterým nechybí schopnost donutit se k něčemu a dotahovat věci do úspěšného konce. Zejména půjde o schopnost odolat pokušení, schopnost víry v sám sebe (optimismus) a schopnost sám sebe motivovat.

Marsmallow experiment

Pravděpodobně nejznámější experiment ve zkoumání schopnosti odolat pokušení vedl Walter Mischel, jeden z nejcitovanějších psychologů 20. století. Experiment proběhl na Stanford University na (v průměru) čtyřletých dětech studentů nebo zaměstnanců této školy. Spočíval v tom, že pověřený asistent nabídl dítěti bonbon a dal mu na výběr: buď sní nabízený bonbon ihned, nebo vydrží přibližně 20 minut, dostane další bonbon a bude mít dva. Některé děti čekat nedokázaly a snědly bonbon ihned, jiné se vydržet alespoň snažily. Zakrývaly si oči, snažily se usnout, dělaly vše proto, aby bonbon nesnědly. Část dětí nakonec dokázala vydržet. (9)

Zajímavé bylo srovnání po několika letech, kdy mezi těmi, kteří před lety vydržet dokázali, a těmi, kteří nikoliv, byly velké rozdíly v mnoha oblastech. Schopnost odolat pokušení a odložit uskutečnění pohnutky byla u těch, kteří dokázali před lety vydržet, přítomná stále ve vyšší míře.

„Diagnostická hodnota toho, jak se děti k tomuto okamžiku pokušení postavily, se ukázala o dvanáct či čtrnáct let později, když tyto děti vyrostly v adolescenty. Emoční a sociální rozdíl mezi těmito dvěma skupinami dětí byl skutečně výrazný. Ti, kteří ve čtyřech letech pokušení odolali, byli nyní – jako adolescenti – daleko schopnější: byli asertivnější, pracovně výkonnější a lépe se dokázali vyrovnat s frustracemi, které život přináší. Byli méně náchylní k citovému zhroucení, k trémě či k regresivnímu chování ve stresu; pod nátlakem neztráceli hlavu a nepodléhali rozpakům. Zpravidla měli nejrůznější cíle a zájmy, na kterých pracovali. Byli vytrvalí, dokázali překonávat překážky, spoléhali sami na sebe; byli sebevědomí, důvěryhodní a iniciativní a pouštěli se do rozličných aktivit. A o více než desetiletí později byli stále schopni si ve svém úsilí dočasně odepřít uspokojení a odměnu.” (10)

Tato schopnost odložit uskutečnění pohnutky je podstatou veškerého našeho snažení, od dodržování diety až po získání doktorátu (10). Mimo jiné i z tohoto experimentu lze usuzovat, že je tato vlastnost buď vrozená, nebo získaná a rozvíjená především v průběhu prvních let života. Když jsem se na tuto vlastnost ptal svých přátel, které považuji za úspěšné, a u nichž je úspěch spojen se schopností odolávat pokušení, snad každý z nich mi potvrdil, že pokud byl před nimi nějaký obtížnější úkol, tak se dokázali k řešení donutit už v dětském věku. Emoční výchova a první roky života jsou pro rozvoj sociálních dovedností člověka naprosto nejzásadnější (11) a její absence se později zákonitě projeví.

Naděje a špatná známka

Charles R. Snyder byl psycholog z University of Kansas, který zkoumal rozdílný přístup k lidí k naději a motivaci. Vedl experiment, při kterém byla vysokoškolským studentům předložena hypotetická situace:

Předsevzali jste si dostat ze zkoušky dvojku. Avšak když vám vrátili váš test, dosáhli jste jen třicetiprocentní úspěšnosti, a dosáhli jste tedy čtyřku. Od chvíle, kdy jste se to dozvěděli, uplynul už týden. Co děláte?

Někteří studenti reagovali tím, že se začali připravovat pečlivěji. Přemýšleli o aktivitách, které povedou k tomu, že bude jejich výsledek lepší. Věřili, že mají výsledek testu ve svých rukou a pokud se na něj lépe připraví, tak budou mít i lepší známku. Jiní byli méně odhodlaní a méně věřili ve svůj úspěch. A někteří studenti, ti bez naděje, se vzdali ihned. Po prvním semestru se srovnaly výsledky SAT (testy blízce příbuzné IQ testům) při přijímacím řízení, známky na konci prvního ročníku a výsledky testovaných studentů a z nich vyplynulo, že tento test naděje předpověděl budoucí známky přesněji než výsledky SAT. (12)

Vidění příčin nezdaru ve vnějších okolnostech, které se dají změnit a které má člověk pod vlastní kontrolou, je velmi důležité a projeví se citelně i při takových úkolech, jako je třeba cílené snížení váhy. Část lidí totiž už na začátku nevěří, že dokáže svůj režim změnit a vytrvat u něj.

V tomto kontextu můžu zmínit jednu moji kamarádku. Považuji ji za velmi inteligentní, pořádá různé šachové či pokerové turnaje a myslím si, že logické problémy vyřeší mnohem lépe než většina ostatních. Její největší problém ale je značná nedůvěra v sebe sama. Během 4 let, které se známe, si podávala minimálně 4x přihlášku na různé vysoké školy, avšak ani jednou na přijímačky nedošla se zdůvodněním, že by vysokou školu stejně nebyla schopná vystudovat. Žádný psycholog ani terapeut ji nedokázal zbavit přesvědčení, že není dost chytrá, ačkoliv řada důkazů svědčí o opaku. Z jejího vyprávění vyplývá, že se k ni rodiče dětství nechovali správně a při různých příležitostech její sebevědomí spíše sráželi, až v ní dokázali vypěstovat pocit méněcennosti, který ji dovádí až k existenčním problémům.

Je zbytečné chtít po člověku s podobnými problémy, aby dokázal úspěšně realizovat nějaký postup, u kterého se víra v sebe sama předpokládá. Od začátku je to odsouzeno k neúspěchu. Různé úspěšné odborné programy pro zhubnutí proto zahrnují třeba kongnitivně-behaviorální terapii, která pomáhá podobné problémy odstranit.

Víra v sebe sama a také v to, že vše nakonec dobře dopadne, se však, myslím si, dá během života výrazně ovlivňovat. Za svůj dosavadní největší úspěch považuji přijímačky na gymnázium, jejichž součástí bylo i bodování školního průměru za posledních 5 let, který jsem měl však dost špatný a v době, kdy jsem si podíval na školu přihlášku, jsem věděl, že ztratím přibližně ⅓ všech bodů hned na začátku. Rok jsem se musel připravovat s tím, že musím udělat přijímačky ze všech nejlépe, neztratit žádné body, a navíc, že drtivá většina ostatních přijde o více více než třetinu bodů. Připravovat se s vědomím toho, že člověk nemá věci pod vlastní kontrolou a že nemusí stačit ani napsat test bez ztráty bodu, je mnohem obtížnější a vyžaduje i velkou víru v to, že věci prostě dopadnou dobře. Přijímačky jsem nakonec udělal nejlépe, když se připočítaly body za průměr, tak jsem propadl na poslední místo, ovšem v seznamu té čtvrtiny studentů, které na školu nakonec přijali.

Jsem si jistý, že podobné zážitky člověka ovlivní v tom, jak se rozhoduje později. Možná mě na první pohled bezvýznamné přijímačky na střední školu ovlivnily v tom, že jsem o pár let později dokončil bakalářské studium, dojel na kole k moři nebo bez větších problémů dodržel dietu.

Testy amerických plavců

Pro to, aby se člověk dokázal zbavit nadváhy, je též potřeba alespoň minimální míra motivace, respektive zvláštní schopnost sám sebe motivovat.

Zajímavý experiment schopnosti sebemotivace provedl Martin Seligman z Pennsylvánské univerzity, opět jeden z nejcitovanějších psychologů 20. století, na skupině amerických plavců před olympijskými hrami v roce 1988. V jeho pokusu rozhodčí oznámil plavcům horší časy, než kterých ve skutečnosti dosáhli. Poté měli druhý pokus. Zatímco ostatní členové amerického týmu měli při druhém pokusu horší výsledky, Matt Biondi, u něhož se na nadcházejících hrách očekávalo až 7 zlatých medailí, dokázal svůj už tak vynikající čas zlepšit, a to navzdory obvyklé zpětné vazbě neúspěchu, jenž oslabuje motivaci. Tato schopnost sebemotivace se pak projevila na hrách poté, co první dva závody prohrál a sportovní komentátoři se dohadovali, zda tyto porážky podlomí Biondiho úsilí v následujících závodech. Dokázal se však vzpamatovat a v následujících 5 závodech získal zlaté medaile. (13)

Existuje další studie, které dokazují, že schopnost sebemotivace a optimismus může být to, co odlišuje úspěšné od neúspěšných při stejné intelektuální úrovni obou skupin (14). Právě při hubnutí je sebemotivace důležitá. Na začátku může být impulzem cokoliv, jak pozitivní, tak negativní motivace (třeba strach), snižování váhy je však dlouhodobý proces obvykle na několik měsícům, během nichž člověk zažije různé situace, které mohou jeho snažení přerušit a vrátí ho zase zpět ke starým stravovacím návykům. Pokud si člověk naordinuje striktně zdravou stravu a začne ji dodržovat, téměř jistě přijdou situace, kdy režim nevydrží, což je normální a přirozené. Ale právě tehdy se projeví, zda se člověk dokáže znova namotivovat do stavu, v jakém celý proces začal.

Závěr

Pomalu se dostávám k tomu, proč jsem dokázal váhu cíleně snížit. Neměl jsem až tak silnou motivaci, jako mají mnohdy jiní, ale pokud je potřeba, dokážu si poručit. Měl jsem také víru v to, že daný postup je správný, že mám vše ve vlastních rukou, že mě okolí nedokáže negativně ovlivnit a že vše úspěšně brzy skončí. Svoji roli ale sehrála ještě jedna důležitá věc  – přeformulování problému tak, aby odpovídal mé povaze.

Že jsem se stal programátorem není náhoda. Název povolání je odvozen od slova program, což je konkrétní implementace nějakého algoritmu. Algoritmus je určitá posloupnost přesně daných kroků, má vždy jasný začátek a konec. U mých přátel, kteří se programováním živí, je snaha o algoritmizaci, matematizaci téměř všeho, od politické situace, až po řešení vztahů, patrná.

Podobným způsobem řeším i já většinu problémů, včetně snížení váhy. Hubnutí mělo jasně daný začátek a přesné datum konce. Každý víkend v celém období jsem měl přesně dáno, jaký má být úbytek váhy. Pokud byla váha vyšší, další týden jsem měl nižší kalorický příjem. Pokud byla váha nižší, mohl jsem si dopřávat více toho, co jsem jinak musel omezit.

Jestliže jsem však stejný postup zkoušel u ostatních, výsledky jako u mě stejné nebyly, protože postup nebyl přizpůsobem na míru tomu, kdo ho aplikoval. Pokud má člověk problémy se sebedonucením, je dobré používat různé plánovací aplikace, které ho v daný čas donutí přerušit práci a najíst se, čímž se vyhne situacím, kdy mu hlad nedovolí odolat pokušení sníst něco, co by jíst neměl. Mentální síla, která je nutná k překonání pokušení, bude pak potřeba v mnohem menší míře. Pokud má člověk problém s udržováním motivace, může být výhodné zapojit někoho dalšího ve svém okolí, kdo má stejný problém. Obě osoby se pak mohou motivovat navzájem a navzájem si pomoci. A konečně pokud má člověk problémy s vírou v sebe sama, často pomůže změna prostředí, práce, koníčků, v horších případech pomoc odborníka.

Poznámky a zdroje

Hlavním zdrojem informací byl český překlad kniha Daniela Golemana Emoční inteligence: Proč může být emnoční inteligence důležitější než IQ, Metafora, Praha, 2011, ISBN: 978-80-7359-334-6.

  1. Údaje jsou ze zprávy The State of Food and Agriculture z roku 2013 (http://www.fao.org/docrep/018/i3300e/i3300e.pdf).

  2. Vztah mezi obezitou a zvýšeným výskytem rakoviny je zmiňován všude, kde se hovoří o rizikách obezity, odkázat lze třeba na český STOB klub (http://www.stob.cz/cs/zdravotni-rizika-a-komplikace-obezity).

  3. Statistiky jsou převzaty ze stránek České onkologické společnosti České lékařské společnosti Jana Evangelisty Purkyně (http://www.linkos.cz/co-musite-vedet/ceska-republika-a-rakovina-v-cislech/).

  4. Stav „flow“ (proudění) popsal psycholog Mihaly Csikszentmihalyi jako zvláštní zónu, v nichž lidé dosahují vynikajících výkonů bez zvláštního úsilí. „Charakteristickým projevem tohoto stavu je spontánní pocit radosti nebo dokonce vytržení. V tomto stavu jsou lidé naprosto pohlceni tím, co dělají, a svojí činnosti věnují plnou, ničím nepřerušovanou pozornost. Pozornost je natolik soustředěná, že lidé si uvědomují pouze úzkou oblast vjemů spojenou s okamžitou činností a ztrácejí smysl pro čas a prostor.“ (Goleman, str 90).

  5. Údaje jsou z článku V České republice je 55 % lidí s nadváhou a obezitou, který shrnuje průzkum VZP (http://www.vzp.cz/klienti/aktuality/v-ceske-republice-je-55-lidi-s-nadvahou-a-obezitou).

  6. Pojem emoční inteligence uvedli poprvé v roce 1990 P. Salovey a J. D. Mayer. Lze ji chápat jako schopnost zvládání svých emocí a umění vcítit se do emocí ostatních jedinců. (http://cs.wikipedia.org/wiki/Emo%C4%8Dn%C3%AD_inteligence).

  7. Goleman, str 40.

  8. Odkaz na kritiku lze nalézt na anglické verzi hesla Emotional intelligence na Wikipedii (http://en.wikipedia.org/wiki/Emotional_intelligence#Criticisms_of_theoretical_foundation)

  9. Více informací o „bonbonovém testu“ lze najít třeba na anglické Wikipedii (http://en.wikipedia.org/wiki/Stanford_marshmallow_experiment). Experiment byl různě zpochybňován (ostatně jako asi jakýkoliv jiný významný experiment v oblasti psychologie). V roce 2014 Mischel vydal knihu The Marshmallow Test, kde podrobně celý experiment popsal a kde se tyto pochybnosti pokusil vyvrátit.

  10. Goleman, str 82.

  11. Celá Golemanova kniha se zabývá primárně emocemi a emoční výchovou a zdůrazňuje její vliv na psychiku člověka v dospělosti.

  12. Goleman, str 86. Výsledky byly poprvé zveřejněny ve studii The Will and the Ways: Development and Validation of Individual-Differences Measure of Hope (Vznik a průkaz individuálních rozdílů v měření schopnosti doufat), Journal of Personality and Social Psychology 60, 4, 1991, str 579.

  13. Goleman, str 87. Výsledky jsou ze studie Optimističtí plavci: Martin Seligman, Learned Optimism, New York, Knopf, 1991.

  14. Goleman, str. 88.

Na kole k moři

Jednoho dne mě napadlo, že bych mohl dojet na kole až k moři. Háček byl jen v tom, že jsem žádné kolo už 10 let neměl. A tak jsem si pár dní před odjezdem koupil první, na které jsem narazil, k tomu stan a celou kempingovou výbavu a s 25 kg nadváhy se vydal na cestu. Po 11 dnech jsem se dostal až do Itálie, do Trieste.

Celá story zde: http://www.ronnieweb.net/na-kole-k-mori/.

 

Node.js je nejrychleji rostoucí platformou pro vývoj aplikací + pozoruhodný vzestup Go

Na konci června se udála jedna zajímavá věc. Počet modulů v npm, balíčkovacím systému pro Node.js, byl 80970. Zajímavé je to především ve srovnání s ostatními jazyky/platformami, protože na začátku června Node.js překonal Ruby a právě na konci června i Javu, která doposud žebříčku vévodila.

Počet modulů v repozitáři, resp. jejich růst je velmi dobrá statistika, ze které lze vyčíst, jak je aktuálně který jazyk/platforma populární. V případě Node.js jde o fascinující počty, protože roste více než dvakrát rychleji než Java nebo PHP, přestože npm je tady teprve od roku 2011. Na tom je jasně vidět, že jednoznačně vítězí jednoduchost.

Já přešel na Node.js (+ CoffeeScript) před 2,5 roky v době, kdy těch modulů bylo cca 2 tis. a už tehdy jsem si byl jistý, že jednou bude Node.js nejpoužívanější, ale nemyslel jsem si, že toho dosáhne za tak krátkou dobu. Pro mě je právě na Node.js zcela zásadní ekosystém, protože teď neustále pracuji s různými API a vždy pro dané API najdu snadno modul, který už někdo přede mnou dělal, což mi ohromně šetří čas. I když třeba u Clojure může vypadat 9600 modulů jako velké množství, tak Node.js roste 20x rychleji, což se právě projeví ve chvíli, kdy potřebuji něco více specifického, protože v Node.js už to pravděpodobně bude k dispozici. To je myslím důvod, proč je Node.js tak populární a proč zase tolik nezáleží na tom, jak vypadá syntax jazyka.

Kromě toho je ještě velmi zajímavé, jak roste jazyk Go. Roste rychleji než Ruby a brzy dožene PHP a Javu. Go se mi velmi líbí a kdybych měl někam přejít, určitě by to bylo zde, tento rok bych mu určitě chtěl věnovat pár víkendů. Myslím si, že do budoucna bude Go a JavaScript/Node.js výborná kombinace a troufám si tvrdit, že do dvou let půjde o dvě nejpoužívanější platformy pro vývoj aplikací.

 

Představení nástroje Mockapito

Na mé přednášce na Webexpu jsem se zmínil o projektu Mockapito pro vývoj (nejen) single-page aplikací. V tomto článku ho blíže představím.

Frontend First!

Na blogu či v článcích na Zdrojáku jsem mnohokrát psal o způsobu, kterým vyvíjím aplikace a který je trochu odlišný v tom, že nejprve celá aplikace vzniká bez serverové části a tedy i bez databáze. Tento způsob vývoje jsem si pojmenoval jako Frontend First (FF) a v blízké budoucnosti plánuji web, který se tomuto způsobu vývoje bude blíže věnovat. Věřím, že dokonce roku se mi podaří web www.frontendfirst.com spustit. Kromě popisu samotné metody by to měl být třeba zdroj design patterns, které se speciálně k této metodě vážou. A plánuji i několik dalších souvisejících projektů, které ale představím až později.

Mockapito

Zatímco FF je popis filozofie vývoje, Mockapito je nástroj, který tento způsob umožní. Je psán v CoffeeScriptu, využívat bude Grunt, Yeoman a další užitečné projekty. Momentálně mám po všech projektech několik různých skriptů a grunt tasků, které teď přepíšu do jednoho nástroje Mockapito.

Mockapito je doplněk Apiary, všechny současné i budoucí výhody Apiary zůstávají. Apiary je výborný projekt, ve svém oboru jednička, nicméně je určen pro trochu jiné účely. Apiary má poměrně živý Github a některé jejich nástroje se mi velmi hodí i pro Mockapito.

Co by tedy měl Mockapito doplnit?

1. CLI pro vytváření pravidel v Apiary

Momentálně mi nevyhovuje způsob, jakým se v Apiary vytváří nová pravidla pro zdroje. Je to trochu komplikované. Mockapito umožné vytvářet nová pravidla přímo přes příkazový řádek.

Příklad:

mockapito resource langs

Jeden příkaz v souboru apiary.apib předgeneruje pravidla pro jeden zdroj langs. Vytvoří tedy pravidla pro výpis všech jazyků, pro detail jednoho jazyka, pro vytvoření, editaci a smazání.

mockapito resource users -prop id:n name:s surname:s birthday:d note:t -d "Detail uživatele s ID {id}"

Měl bych mít i možnost specifikovat, jak by měl daný objekt vypadat. Takže třeba výše uvedený příkaz vytvoří toto pravidlo:

Detail uživatele s ID {id}
GET /users/{id}
< 200
{
 "id": 1295806,
 "name": "Lorem",
 "surname": "Ipsum",
 "birthday": "2007-03-01",
 "note": "Lorem ipsum set dolorem lorem ipsum set dolorem"
}

 

Bude možné vytvářet vlastní typy (třeba mám typ email, který vygeneruje náhodný fake e-mail) nebo blíže je specifikovat pomocí parametrů (možnost říct, kolik jak dlouhý má být řetězec v note ap.).

Mockapito umožné také negenerovat všechna pravidla, ale třeba jen jednu URL:

mockapito resource POST /langs

Protože REST API má jasná pravidla, Mockapito pochopí, že výše uvedený příkaz je pro vytvoření nového zdroje a nastaví podle toho i třeba návratový HTTP kód. Stejně tak ví, že lichá úroveň vrací kolekci (/langs – seznam všech jazyků), sudá jeden konkrétní (/langs/{id} – detail jednoho jazyka).

Mockapito dokáže dobře odhadovat, jaká má být odpověď na daný požadavek na základě předchozích pravidel. To znamená, že pokud je třeba už určeno pravidlo pro výpis jednoho jazyka (/langs/{id}), když budu chtít vytvořit pravidlo pro výpis všech jazyků (/langs), Mockapito si zjistí z detailu, jaké vlastnosti jazyk má a podle toho vygeruje obsah odpovědi pro ostatní jazyky. Stačí tedy jen jednou specifikovat, jak má vypadat daný objekt.

Podobně dokáže Mockapito určit, kolik objektů třeba má být vráceno. Pokud chci zobrazit seznam všech jazyků, Mockapito umí vygenerovat jedním příkazem odpověď, ve které bude zadaný počet objektů.

Podobně Mockapito dokáže řešit úpravy či mazání. Řekněme, že máme v Apiary pro jednu sekci deset pravidel, používáme v objektech vlastnost „name“ a já bych ho chtěl vlastnost přejmenovat na „username“, tak je to opět jeden jednoduchý příkaz.

Jedna oblast je tedy velmi intuitivní program pro definici pravidel, jak má REST API vypadat. Konkrétní pravidla půjde samozřejmě libovolně upravit třeba přímo v souboru apiary.apib.

2. Sychronizace mezi Apiary a lokálním uložištěm

Snad se to podaří nějak vyřešit a Mockapito bude umět stáhnout aktuální verzi z Apiary, popř. novou verzi tam poslat.

3. Vlastní instance serveru pro komunikaci s projektem

Momentálně vše řeším tak, že pravidla z Apiary se překonvertují na .js a ten se nahrává do aplikace. V budoucnu bych spíše preferoval něco jako příkaz „mockapito server“, který dokáže spustit na jiném portu server, se kterým bude pak aplikace přímo komunikovat. Vyvíjená aplikace tedy nebude nijak upravována, pouze bude potřeba změnit URL, kam budou směřovat ajaxové požadavky, pokud poběží v testovacím režimu. Ideálně by to mělo být tak, že pokud budu chtit spustit aplikaci normálně, spustím ji třeba jako „grunt server“, pokud budu chtít ale využít Mockapito, spustím aplikaci jako „grunt server:mockapito“ a aplikace bude komunikovat s Mockapitem.

4. Možnost určité pravidlo na chvíli deaktivovat

Tohle mi teď chybí, mělo by být možné snadno nějaké pravidlo dočasně deaktivovat a místo toho požadavek směřovat přímo na ostrou verzi.

5. Podpora pro websockets, server-side events

K dispozici bude také webové rozhraní, přes které půjde nasimulovat příchozí zprávu zaslanou ze serveru do klienta. Příklad je třeba chat a příchozí nová zpráva ze serveru. Pravidla se budou definovat stejně jako v případe REST API, ale bude zde ještě webové rozhraní, přes které bude možné odpověď poslat do aplikace.

6. Podpora pro dynamické odpovědi

Někdy se hodí mít v odpovědi dynamická data, třeba aktuální datum. Nejspíš tam bude jednoduchý šablonovací systém a v body bude třeba možné zadat něco jako {{date.now()}}.

7. Lepší struktura pro velké projekty

V jednom souboru to není úplně ideální, pokud je těch pravidel hodně, špatně se soubor edituje.

Tohle jsou ty nejzákladnější body. V budoucnu uvažuji ještě o nějakých dalších věcech, ale ty jsou zatím ve fázi plánování.

Webexpo z pohledu přednášejícího

V následujících dnech se bude určitě objevovat řada článků s dojmy z Webexpa. V dalším textu nabídnu ten svůj, avšak z toho druhého pohledu, z pohledu přednášejícího.

Moje přednáška otevírala celý program v Development Hall. Trvala přibližně 50 minut + nějaký čas na Q & A. Příprava na ní mi zabrala hodně času, rozhodně více než 100 hodin. Vzhledem k tomu, že to byla pro mě první zkušenost s přednášením, chtěl jsem, aby byla co nejlepší, takže během posledních měsíců jsem přečetl mnoho knih a článků o tom, jak dělat co nejlepší prezentace.

Z pohledu speakera byla celá organizace Webexpa hodně profi. Četl jsem si předtím nějaké kritické články na organizaci, ale mám dojem, že se snad všechny problémy z dřívějších let podařilo odstranit. Nevím, nenapadá mě nic, co se by se dalo vytknout.

A teď k mé prezentaci.

Co bylo špatně

Moje prezentace nebyla dobrá. Bezprostředně po konci prezentace jsem z toho měl hodně špatný dojem a čekal jsem silně kritické reakce. Udělal jsem tři fatální chyby, které byly způsobeny hlavně chybějícími zkušenostmi. Dále je popíšu, pokud někdy budete ve stejné pozici jako já, snažte se je neopakovat.

1. Ujistěte se, že 100% víte, pro koho přednášíte

Původně jsem počítal s tím, že moje audience budou hlavně programátoři, kteří vytvářejí klasické server-side aplikace a kteří třeba už o SPA slyšeli a chtějí o tom vědět více. Vašek Stoupa mně kontaktoval s tím, že by bylo dobré představit širší veřejnosti to, co jsem popisoval v článku Moderní vývoj aplikací. Moje články na Zdroáku moc komentované nejsou a poměr mých přátel, kteří pracují třeba s AngularJS vs. píšou server-side aplikace třeba jen s jQuery je tak 1:10. Když se pak podívám i na to, kolik je třeba pracovních nabídek, ve kterých se AnguarJS zmiňuje, je to výrazně méně než třeba nabídky, ve kterých se zmiňuje Nette. To vše mě utvrdilo v názoru, že mnoho lidí u nás frameworky jako AngularJS nepoužívá a podle toho byla nastavena i úroveň přednášky převážně na intro do SPA.

Chyba. Než začala moje přednáška, mluvil jsem s cca 10 lidmi a u všech to bylo o článcích na Zdrojáku a čtené jsou. Když jsem se pak ptal publika, kdo používá jaký framework, zjistil jsem, že můj původní dojem byl velmi chybný, protože zhruba 2/3 návštěvníků už dříve používalo AngularJS a odhadem tak 90% SPA běžně už psalo. Takže pro většinu lidí to bylo moc basic a množství nových informací moc nebylo.

Poučení pro příště: zjistit si přesně, kdo na přednášku půjde a jaká je jeho úroveň znalostí. Šlo to třeba přes Twitter.

2. Chybějící live coding

Killer feature přesnášky měl být live coding. Máme neskutečně vymazelný celý devstack, vše velice dobře zautomatizované, a to jsem chtěl ukázat. Původní idea byla doprogramovat jednu funkci do Lingana + udělat user testing a pak ji změnit podle připomínek. Šlo o to ukázat, že tímhle zpsobem je možné velmi rychle udělat celý frontend a hned se lidí ptát a jejich připomínky zanášet. Je to rychlé jako prototypování, ale v tomhle případě je to reálná aplikace a nejen prototyp.

Po několika dnech úvahy jsem se ale rozhodl tuhle část vypustit. Bylo doporučeno použit notebooky, které jsou přímo na konferenci. Bylo možné použít vlastní, ale v minulých letech jsem viděl, že s tím mohou být obrovské problémy, řeší se nekompatibilita, pořád něco nefunguje atd. Zkoušel jsem použít c9.io, ale tam pořád taky něco nefungovalo a nakonec jsem se tedy rozhodl tuhle část vypustit. To byla ale chyba, tohle tam citelně chybělo a bez toho to bylo jen představení nástrojů, které používáme. Nakonec to stejně nahraju a přidám na Youtube jako doplněk k proběhlé přednášce.

Poučení pro příště: když něco chci a mám pocit, že to v přednášce být musí, tak to tam prostě být musí za každou cenu.

3. Neučte se přenášku zpaměti

Tady se projevila moje nezkušenost s přednášením naplno. Přednášku jsem měl totiž naučenou zpaměti, během 3 měsíců vzniklo 7 verzí, 3 prošly kompletní korekturou. Tohle bylo velmi špatné rozhodnutí, během přednášky jsem se občas ztrácel, kde jsem a spíše jsem přemýšlel o tom, jaká má být následující naučená věta a když byl nějaký krátký výpadek, úplně mě to vykolejilo a celá přednáška byla děsně rozkouskovaná. Když se pak člověk dostane do stresu, projeví se to hodně silně na angličtině, na řadu přijde nesmyslné zkracovní vět atd.

Poučení pro příště: dobře se připravit, ale nic se neučit zpaměti, možná s výjimkou úvodní minuty.

Co bylo dobře

Přesto všechno bylo pro mě přednášení na Webexpu jeden z nejlepších zážitků, který jsem kdy měl. Řadím ho do TOP 10. Pocit, kdy se dostanete na podium, zhasne se, svítí na vás jen reflektory a vy máte před sebou zaplněnou halu, je naprosto úžasný a těžko popsatelný. Být celá přednáška v češtině a neučená zpaměti, určitě bych si ji užil ještě mnohem více. V každém případě jsem přišel na to, že přednášení před ostatními mě bude do budoucna hodně bavit, ale chce to ještě nabrat hodně zkušeností z menších akcí.

Co se týče těch pozitivních částí přednášky, napadají mě dva body.

Ten první byla anketa, ta byla super a pro mě i trochu překvapení, jak obrovskou převahu AngularJS u nás má. To je super, protože jsem měl možnost hrát si se všemi ostaními populárními JS MVC frameworky a řekl bych, že AngularJS ostatní válcuje o dvě třídy. Takže pokud se u nás nejčastěji používá něco, o čem mám pocit, že je to nejlepší, co v daném oboru může být, tak z toho mám velkou radost.

Druhý pozitivní bod bylo myslím video Node.js song. Těch 30 vteřin mi hodně pomohlo, odpočinul jsem si. Ostatní video probudilo a po něm jsem zase získával plnou pozornost. Myslím, že tyhle prvky typu anketa nebo krátké video jsou hodně důležité proto, aby ta prezentace nebyla stereotypní, ale trochu více živá.

Kompletní text mé přednášky je k dispozici.