
Karlova Univerzita nedávno zveřejnila náhled nového uživatelského rozhraní svého Studentského informačního systému (SIS). Systém byl vyvinut koncem 90. let či krátce po roce 2000 a lze tedy očekávat, že po určité době aplikace potřebuje nějakým způsobem obnovit. Nově vydaný náhled tak představuje uživatelské rozhraní SIS4, které by mělo do aplikaci vnést moderní design. Nicméně, již krátce po prozkoumání designu je člověk nemile překvapen. Prozatím pominu fakt, že celé rozhraní vypadá jako blog a ne jako vyspělý informační systém, ve kterém by se studenti měli přihlašovat na předměty, kontrolovat zkoušeky a vyučující by měli spravovat své předměty. Rád bych také podotknul, že než jsem se rozhodl napsat tento kritický článek, navrhoval jsem několik změn v uživatelském rozhraní, které jsem odeslal jako součást feedbacku, ale povětšinou byly zamítnuty s odůvodněním, že by to zpomalilo vývoj a přechod na nový systém. Měl bych zde také poznamenat, že některé problémy, které popisuji v tomto článku, jsem zjistil až dodatečně.

## Někdo zapomněl, že ne všichni lidé používají myš
Prvním zásadním problémem, kterého jsem si všiml, je absence podpory navigace jen s pomocí klávesnice. V tomto ohledu pochopím, že méně zkušený vývojář tento druh ovládání opomene a mohu si sypat popel na hlavu také já sám, neboť při psaní tohoto článku jsem si všiml několika nedostatků i na svém webu. Nicméně, v případě systému, jako je SIS Univerzity Karlovy, který je používán více než desítky tisíc studentů s různými potřebami, je toto opomenutí poměrně zásádním problémem. Ne každý uživatel má totiž možnost používat myš, někteří uživatelé naopak preferují klávesnici, protože zrychluje navigaci na webu. Jak zásadní je problém v SIS? Téměř každému tlačítku chybí stylizovaný stav :focus, co je ovšem horší, výchozí stav :focus je obvykle odstraněn, takže chybí jakákoliv vizuální signalizace, kde se uživatel právě nachází, pokud stiskne klávesu tab. Mnoho vlastních prvků, jako jsou například zaškrtávací políčka, je z ovládání pomocí klávesnice zcela vyjmuto.

<br />

![Ústřižek stránky zobrazující nabídku, název "Obecné možnosti společné pro různé studie" a aktivní a neaktivní zaškrtávací políčka](/img/blog--SIS4-checkboxes.png)_Tato políčka nelze zaškrtnout/odškrtnout pomocí klávesnice._

<br />

## Není určen pro osoby se zrakovým postižením.
Druhým závažným problémem je skutečnost, že webové stránky nebyly navrženy s ohledem na zrakově postižené uživatele. Když například zapnu simulaci nejčastějších zrakových vad, nejsem schopen poznat, zda je následující přepínací tlačítko ve stavu _zapnuto_ nebo _vypnuto_. Příliš nepomáhá ani název sloupce v záhlaví tabulky, kde jsou popsané stavy obrácené. Naštěstí není mnoho míst, kde se web spoléhá na barvy při popisu stavu nebo předávání informace. Ale téměř ve všech místech, kde tomu tak je, je to provedeno špatně. Nejde jen o barvy, ale také o velikost písma, která se výrazně liší a v některých případech je text tak malý, že i já mám problém ho přečíst.

<br />

![Ústřižek stránky zobrazující pět možností se zelenými přepínači v zapnutém stavu](/img/blog--SIS4-toggles-standard.png)_Myslím, že je jasné, že tyto přepínače jsou zapnuté._

<br />

![Ústřižek stránky zobrazující pět možností se zelenými přepínači v zapnutém stavu s aplikovaným filterm zrakového postižení](/img/blog--SIS4-toggles-colour-blind.png)_Ovšem zde je na místě otázka, zdali je stav přepínače stále jasný? Snímek obrazovky byl pořízen se zapnutým filtrem Deuteranopia_

<br />


## Proč tak prázdné a ohraničené?
Design je prostorný, ale chaotický. Pokud sledujete alespoň jednoho designéra na jakékoliv sociální síti, určitě najdete alespoň dva příspěvky, které říkají, že negativní prostor je superdůležitý, a já nemohu než souhlasit. Musí být ale jasné, které části obsahu spolu souvisejí a které ne. V případě uživatelského rozhraní SIS negativní prostor narušuje pocit konzistence a vnáší zmatek. Na některých stránkách, jako je níže uvedený Studijní plán, je nadpis příliš vzdálen od obsahu, a negativní prostor tak naopak podporuje pocit, že tam něco chybí. V tabulkách je použito moc malé písmo s příliš velkým _paddingem_, takže to opět působí tak nějak rozbitě, a to nemluvím o názvu tabulky, který je opět příliš daleko.

<br />

![Úryvek stránky s názvem 'Studijní plán: Všimli jste si toho uříznutého okraje?](/img/blog--SIS4-studijni-plan.png)_Všimli jste si toho modrého odříznutého okraje?_

<br />

Další věc, která se mi nelíbí, jsou rámečky, okraje a sekce, při otevření některých stránek se střídají šedé a bílé části bez jakéhokoli vizuálního důvodu. Extrémním příkladem je stránka na screenshotu, kde jsou dvě šedé části rozdělené prázdnou bílou sekcí. Bílá sekce tak opět navozuje pocit, že je na stránce něco rozbité. Tento pocit ještě zesílí, když otevřete položku v tabulce a všimneme si velkého šedého okraje, který ani není kolem bílé tabulky rovnoměrně rozložen.

<br />

![Snímek obrazovky stránky zobrazující záhlaví, červené menu a tabulky s informacemi týkajícími se studia](/img/blog--SIS4-studies.png)_Takto vypadá celá stránka_

<br />

## Závěrem
Toto rozhodně nebyly všechny problémy, které vidím v redesignu uživatelského rozhraní SIS Univerzity Karlovy. Nemám však důvod se v nich hlouběji vrtat, protože prozatím by výše zmíněné problémy učinily jakýkoli design nepoužitelným. Možná však napíši další článek zaměřený na některé principy designu, které by prakticky poukázaly na některé problémy, kterými trpí i redesign SIS. Každopádně, v případě, že by si tento článek přečetl někdo z vývojářů, kteří tento design vytvořili, rád se zapojím a pomohu s návrhy, jak tyto problémy vyřešit.

Nezanedbávejte přístupnost svých webových stránek 🙂 Není to zas taková dřina a usnadníte řadě lidí prohlížení vašeho webu. V případě, že nevíte, kde začít, podívejte se na tyto zdroje: [access guide Instagram](https://www.instagram.com/access_guide_/) nebo [accessibility tricks and resources for designers](https://www.getstark.co/library/collections/accessibility-tips,-tricks,-and-resources-for-designers/) na [ webu Stark rozšíření](https://www.getstark.co/).


Co všechno se nepovedlo se SIS4


Možná jste si již všimli, že některé články byly přeloženy pomocí DeepL translátoru. Je to protože nemám příliš času na to, abych pravidelně publikoval nový obsah, natož potom překládal již napsané příspěvky. Když jsem tedy přeložil titulní stránku svého webu do angličtiny, rozhodl jsem se použít k překladu blogu překladač DeepL, což mi umožňuje web udržovat dvojjazyčný a zároveň se soustředit na nový obsah.

Jsem si ale zároveň vědom toho, že kvalita překladů DeepL je velmi rozdílná, a proto nevylučuji, že až budu mít více času, tak se pustím u každého článku do řádného překládání. Zároveň s překladem webu jsem se také rozhodl, že nové příspěvky budou psány převážně anglicky, protože bych se rád zdokonalil v psaní v angličtině. Je pro mne také mnohem snazší opravit zprzněný překlad do češtiny než do angličtiny. :)

Pokud neznáte překladač DeepL: jedná se o aplikaci využívající umělou inteligenci a strojové učení za účelem poskytnout co nejvhodnější překlady. Na základě srovnání, které mají na svém webu, je nejméně čtyřikrát lepší než překladač Google, nemluvě o službách Bing a Amazon. [Určitě tedy stojí za vyzkoušení](deepl), jsem si jistý, že budete překvapeni, jak povedené překlady produkuje!

Proč používám DeepL k překladu některých článků


Chtěli byste zkusit moderní JavaScriptový framework jako Angular, React nebo Vue, ale máte k dispozici jen PHP hosting? Jednou z možností je poohlédnout se po službách jako [Netlify](netlify) nebo [Vercel](vercel), obě poskytují tzv. JAM stack hosting zdarma. Pokud se ovšem nechcete vzdát svého PHP hostingu, chcete zkusit JavaScriptovým framework a zároveň myslíte na SEO, je tu ještě další možnost. Není ovšem rozhodně určená pro velké projekty nebo weby, které stojí na co nejlepší SEO optimalizaci, byť ta je v tomto případě menší problém.

Řekněme, že máme hotový front-end, zbuildění jako SPA _(single page application)_ a nahraný na testovacím FTP. Dál vytvoříme soubor `ssr-index.php`. Do něj následně vložíme veškeré funkce pro zobrazení dat z API robotům a crawlerům. Ne, nemusíte se bát, nebudete muset kopírovat všechen HTML kód z vašeho front-endu.

## PHP server side rendering
PHP nabízí funkci `file_get_contents`, tu můžeme snadno využít ke komunikaci s naší API. Získanou odpověď pak převést do PHP objektu či pole a s daty dále pracovat. Předpokladem úspěchu je také fakt, že v rámci URL se nachází alespoň jeden identifikátor příspěvku či stránky, jejichž data chceme načíst. V mém příkladě to bude _slug_. První část souboru `ssr-index.php` tedy bude vypadat následovně:

```php
<?php

$SITE_ROOT = "http://example.com";

if ($_GET['slug']) {
    $response = file_get_contents($SITE_ROOT.'?slug='.$_GET['slug']);
    $jsonData = json_decode($response);

    if ($jsonData) {
        renderPage($jsonData, $_GET['slug']);
    }
} else {
    $jsonData = json_decode('{
        "title": "Název stránky",
        "content": "Obsah stránky"
    }');
    renderPage($jsonData, '');
}

```

Pro lepší přehlednost si na začátku souboru nadefinujeme tzv. root URL. Následně, pokud se v rámci adresy nachází GET hodnota _slug_ zavoláme skrze `file_get_contents` API a odpověď převedeme pomocí `json_decode` do PHP objektu. Odpověď z naší API je JSON, pokud pracujete s jinými daty, bude potřeba jiná transformační funkce. Pokud se transformace do PHP objektu zdařila a proměnná nese nějakou hodnotu, vykreslíme HTML stránku. V případě, že GET parametr nebyl přítomen v rámci URL adresy, můžeme vykreslit prázdnou tzv. _fallback_ stránku, neboť se robot nachází pravděpodobně na úvodní stránce. Příkladu chybí situace, kdy API vrátí odpověď s chybovým kódem, to by chtělo také ošetřit.

V obou případech funkce `renderPage` zajistí vykreslení základní HTML stránky. V našem příkladu si vystačím jen s obyčejným HTML a několika meta tagy, nicméně meze se nekladou a můžete si pohrát i s podobou této stránky. Nicméně je vcelku zbytečné ji jakkoliv designovat. Zaměřil bych se tedy spíše na sémantiku.

```php
function renderPage($data, $slug) {
    ?>
    <!DOCTYPE html>
    <html lang="cs">
        <head>
				    <meta charset="UTF-8" />
            <title>Název stránky</title>
            <meta property="og:title" content="<?php echo $data->title; ?>" />
            <meta property="og:description" content="<?php echo preg_replace('/<\/?[^>]+(>|$)/m', '',$data->excerpt); ?>" />
            <meta property="og:site_name" content="Název stránky" />
            <meta property="og:image" content="<?php echo $data->image; ?>" />
            <meta property="og:type" content="article" />
            <meta property="og:url" content="https://example.com/<?php echo $slug; ?>" />
            <meta name="twitter:card" content="summary_large_image" />
        </head>
        <body>
	        <main>
		        <h1><?php echo $data->title; ?></h1>
            <?php echo $data->content; ?>
	        </main>
        </body>
        <script type="application/ld+json">
            {
                "@context":"http://schema.org",
                "@type":"Article",
                "name": "<?php echo $data->title; ?>",
                "headline": "<?php echo $data->title; ?>",
                "datePublished": "<?php echo $data->date; ?>",
                "articleBody": "<?php echo preg_replace('/<\/?[^>]+(>|$)/m', '',$data->content); ?>",
                "abstract": "<?php echo preg_replace('/<\/?[^>]+(>|$)/m', '',$data->excerpt); ?>",
                "url": "https://example.com/<?php echo $slug; ?>",
                "publisher": {
                "@type": "Organization",
                "name": "Název stránky"
                }
        </script>
    </html>
    <?php
}
```

Jak je z ústřižku patrné, vykreslená stránka bude obsahovat základní meta tady, dále také OpenGraph hlavičky pro zobrazení na sociálních sítích a JSON+LD schéma pro _rich results_. V samotném těle jsem si vystačil pouze s pro nadpis H1 a HTML obsahem příspěvku. Zde je ovšem prostor přidat tagů a informací více.

## Jak o tom říct robotům?

Zbývá tedy přesměrovat roboty na `ssr-index.php`. Za tímto účelem je potřeba upravit soubor `.htaccess`. Předpokládejme, že máte standardní hosting s `RewriteEngine On` v opačném případě je nutné jej zapnout.

```bash
 <IfModule mod_rewrite.c>
  RewriteEngine On

	# allow social media crawlers to work by redirecting them to a server-rendered static version on the page
  RewriteCond %{HTTP_USER_AGENT} (facebookexternalhit/[0-9]|Twitterbot|Pinterest|Facebot|Google|Ads|SeznamBot|Bing|Telegram|Discord|Whatsapp|FreshBot)
  RewriteRule ^(.*)$ ssr-index.php?slug=$1 [QSA,L]

  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_URI} !api
  RewriteRule ^(.*)$ index.html [QSA,L]
</IfModule>
```

Jak je možno vidět z ústřižku, pokud _USER-AGENT_ návštěvníka odpovídá některému z definovaných v seznamu, dojde k přesměrování na soubor `ssr-index.php`, v opačném případě pokračuje návštěvník na soubor `index.html`, tedy klasický web.

## Závěrem
Jak si lze všimnout z ústřižků, celé řešení má řadu úskalí, počínaje nutností definovat seznam robotů a konče tvorbou speciální stránky, určené pro komunikaci s API. Nejedná se proto o řešení, které bych doporučoval na velké weby či weby jimž záleží na 100% spolehlivosti v SEO. Je to spíše řešení pro menší weby, které si nezakládají na 100% SEO. Je to řešení, které ovšem může poskytnout dobrý odrazový můstek pro přechod z tradičního hostingu k novým službám.

[netlify]: https://www.netlify.com
[vercel]: https://vercel.com

Moderní JS frameworky a tradiční PHP hosting?

Napadla vás někdy nějaká funkce, která by se hodila jako rozšíření do vašeho prohlížeče, ale nevěděli jste kde začít? Přesně pro vás je tento návod. Ukážeme si jak vytvořit rozšíření, které uživateli umožní generovat libovolně velké obrázky z externí API. V závěru článku potom naleznete několik užitečných zdrojů, kam se vydat, pokud byste se chtěli věnovat tvorbě rozšíření více.

## Základem je manifest
Nejdůležitějším souborem rozšíření je `manifest.json` jedná se o vstupní bod, z kterého prohlížeč pozná jméno rozšíření, verzi a také jaké soubory načíst a jaké funkce či práva rozšíření využívá. Úplně základní `manifest.json` by měl vypadat zhruba následovně:

```json
{
  "name": "Generátor obrázků",
  "version": "1.0.0",
  "manifest_version": 2,
  "description": "Vygeneruj libovolně velký obrázek.",

  "icons": {
    "16": "icons/icon-16.png",
    "32": "icons/icon-32.png",
    "48": "icons/icon-48.png",
    "128": "icons/icon-128.png"
  }
} 
```

Zastavím se pouze u dvou vlastností, a to `manifest_version`. Tato hodnota určuje nejen verzi, ale také dostupné funkce a očekávané vlastnosti souboru. V tuto chvíli je vhodné používat spíše verzi 2, přestože Google již oficiálně podporuje také verzi 3. Jednak obvykle při řešení složitějších problémů narazíte na řešení pro manifest verze 2 a jednak některé databáze rozšíření verzi 3 ještě stále nepodporují - například Microsoft.

Druhou hodnotou je pole `icons`, základní sada velikostí by měla být 16, 32, 48 a 128 pixelů. Nicméně, `chrome.browserAction` využívá i 24px. Lze se také setkat s hodnotami 19 a 38, ty by měly být v tuto chvíli již neaktuální a nepoužívají se viz [Stack Overflow](icons).

## Zobrazení okna rozšíření
Tímto bychom měli sice nadefinované rozšíření, ale pokud bychom jej načetli do prohlížeče, nic by se nestalo. Za tímto účelem je potřeba přidat ještě další hodnotu do souboru `manifest.json`:

```json
...
  "browser_action": {
    "default_popup": "popup.html" .
  }
...
```

Hodnota `browser_action` definuje akce, které mají být dostupné v hlavním menu prohlížeče, tedy skrze ikonku rozšíření. Lze zde nadefinovat hodnoty pro ikonu, nápovědu, badge a popup. V tomto návodu si vystačíme pouze s popupem. Pokud by vás však zajímaly další možnosti, podívejte se například na web [Chrome Developers](browserAction).

Soubor `popup.html` by se měl nacházet ve stejné složce jako `manifest.json`, pro zjednodušení nebudu nijak strukturovat adresáře, nicméně je dobrým zvykem rozdělit jednotlivé části rozšíření do vlastních složek.

Obsah souboru `popup.html` je standardní HTML stránka, která může obsahovat odkaz na CSS styly nebo vlastní skripty.

```html
<!DOCTYPE html>
<html lang="cs">
  <head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My first extension</title>
    <link rel="stylesheet" href="style.css">
  </head>
  <body>
    <h1>Generátor obrázků</h1>
    <p>Generuj libovolně velký obrázek</p>
    <input type="text" id="imageSize" placeholder="Rozměry, např. 360x200">
    <img id="imagePreview" src="http://img.silencesys.com/360x200?text=360x200&color=4ddd9a&text-color=145b3a" alt="360x200">
    <input id="imageLink" type="text">
  </body>
  <script src="popup.js"></script>
</html>
```

V tomto případě tedy načítáme dva další externí soubory - `style.css` a `popup.js`. První by měl obsahovat design našeho rozšíření a v tomto návodu jej nebudu již dále zmiňovat. Druhý soubor potom obsahuje všechny důležité funkce. Krom souborů zobrazíme v našem rozšíření také nadpis, tedy název, text, dva inputy a obrázek.

## Načtení rozšíření v prohlížeči
Než se pustíme do přidávání funkcí našemu rozšíření, vyzkoušíme jestli se načte v prohlížeči. Uvádím postupy pro dva nejčastější prohlížeče, nicméně pokud používat prohlížeč s chromiovým jádrem, postup bude stejný. 

### Google Chrome
1. Do adresy prohlížeče zadáme `chrome://extensions/` tímto se otevře nastavení rozšíření
2. V pravém horním rohu nejprve přepneme do vývojářského módu (_Developer mode_)
3. Zobrazí se panel s několika možnostmi: Načíst rozbalené (_Load unpacked_), Zabalit rozšíření (_Pack extension_) a Aktualizovat (_Update_). Zvolíme možnost Načíst rozbalené (_Load unpacked_).
4. V otevřeném okně najdeme složku s rozšířením, kde se nachází soubor `manifest.json` a klikneme na otevřít.
5. Rozšíření by se mělo zobrazit v seznamu rozšíření.

### Microsoft Edge
1. Do adresy prohlížeče zadáme `edge://extensions/` tímto se otevře nastavení rozšíření
2. V levém panelu, úplně dole, se nachází přepínání vývojářského módu (_Developer mode_), zapneme jej
3. V pravém panelu s rozšířeními se vpravo zobrazí několik možností  Načíst rozbalené (_Load unpacked_), Zabalit rozšíření (_Pack extension_) a Aktualizovat (_Update_). Zvolíme možnost Načíst rozbalené (_Load unpacked_).
4. V otevřeném okně najdeme složku s rozšířením, kde se nachází soubor `manifest.json` a klikneme na otevřít
5. Rozšíření by se mělo zobrazit v seznamu rozšíření.

Pokud se rozšíření zobrazilo v seznamu rozšíření, mělo by se také zobrazit v hlavním panelu prohlížeče. Kliknutím na ikonku rozšíření, by se měl zobrazit popup, který jsme nadefinovali v předchozím kroku. Tím by bylo rozšíření úspěšně načteno v prohlížeči.

## Interakce
Pokud se vše povedlo, přišel čas rozšíření trochu oživit. Otevřeme tedy soubor `popup.js` a přidáme do něj několik funkcí.

### Vlastní rozměry obrázku
První input v zobrazení by měl sloužit pro zadávání rozměrů obrázku, náhled by se měl potom ideálně aktualizovat po stisknutí klávesy enter. Způsobů, jak toho docílit, je spousta, já v tomto návodu zvolil event `onkeypress`. Nicméně, rozšíření neumožňují přidávat funkce k eventům v HTML stránce, a tak atribut `onkeypress` použít nemůžeme. Namísto toho je potřeba event zaregistrovat v JavaScript souboru, a to následujícím způsobem:

```js
const imageSizeInput = document.getElementById('imageSize')
imageSizeInput.addEventListener('keypress', updateImageSize)
```

Pomocí `getElementById` získáme DOM element z HTML stránky a následně skrze funkci `addEventListener` přidáme eventu `keypress` funkci, jež má být volána vždy po stisknutí nějaké klávesy. Abychom předešli tomu, že se bude náhled aktualizovat s každým stisknutím klávesy, můžeme použít například následující podmínku `if (event.key === 'Enter')` tím zajistíme, že se funkce spustí jen pokud uživatel stiskne klávesu enter.

```js
function updateImageSize (event) {
  if (event.key === 'Enter') {
    resizeImage(event.target.value)
  }
}
```

Předtím než se pustíme do definování funkce `resizeImage` je ještě potřeba najít v dokumentu dva další elementy, a to obrázek a input, který bude obsahovat odkaz na obrázek. Na začátek souboru tedy přidáme následující dva řádky:

```js
const imagePreview = document.getElementById('imagePreview')
const imageLinkInput = document.getElementById('imageLink')
```

Teď už nám nic nebrání v nadefinování funkce `resizeImage`, která upraví zdroj obrázku a nahradí hodnotu inputu s odkazem na obrázek.

```js
function resizeImage (size) {
  imagePreview.src = `http://img.silencesys.com/${size}?text=${size}&color=4ddd9a&text-color=145b3a`
  imagePreview.alt = size
  imageLinkInput.value = imagePreview.src
}
```

Interakce by tedy byla hotova, aby se ovšem změny projevily i v rozšíření v prohlížeči, je potřeba rozšíření aktualizovat. Za tímto účelem otevřeme stránku s rozšířeními - `chrome://extensions/` resp. `edge://extensions/` a u našeho rozšíření klikneme na tlačítko Načíst znovu (_Reload_). Rozšíření by tak mělo načíst změny a po kliknutí na ikonku v panelu prohlížeče, úpravě velikosti v prvním inputu a stisknutím klávesy enter by mělo dojít k aktualizaci obrázku za nový.

## Vzhled rozšíření
Jak jsem psal na začátku, cílem tohoto návodu není design rozšíření, ale spíše ilustrace základního procesu a navedení, jak začít. Z toho důvodu nebudu popisovat, jak by mohlo rozšíření vypadat, ale naopak upozorním na pár věcí. Popup okno rozšíření by nemělo být menší než 25x25 a větší než 800x600 pixelů. Obecně lze použít jakákoliv CSS, která jsou prohlížeči podporována. 

## Další zdroje
Gratuluji k úspěšnému vytvoření vašeho rozšíření pro Google Chrome a Microsoft Edge. Pokud vás celý proces zaujal a chtěli byste se dozvědět více, doporučuji navštívit následující stránky  [Chrome Developer](chromeDeveloper) a [Microsoft Edge documentation](edgeDeveloper).


[icons]: https://stackoverflow.com/a/60184542/7564018
[browserAction]: https://developer.chrome.com/docs/extensions/reference/browserAction/#parts-of-the-ui
[chromeDeveloper]: https://developer.chrome.com/docs/extensions/mv3/
[edgeDeveloper]: https://docs.microsoft.com/en-us/microsoft-edge/extensions-chromium/

Vlastní rozšíření pro Google Chrome

Pokud jste se rozhodli vytvořit nejen obyčejnou webovou aplikaci, ale chcete
zároveň zajistit, aby byl obsah vašich stránek stravitelný pro vyhledávací roboty.
Strukturovaným JSON+LD datům se nevyhnete. Pro zajištění snadné indexace a zobrazení
_ústřižků_ z vaší stránky v rámci vyhledávání doporučuji použít Google [JSON+LD](google-json).

Většina webových stránek používá [schema.org](schema), nicméně pro Google Search je lepší
spoléhat se na dokumentaci od Google než na Schema.org.

Webové stránky ve Wordpressu většinou obsahují nějaké základní SEO optimalizace,
proto o nich většina blogerů ani neví a přesto jsou v rámci vyhledávání hodnoceni
dobře. Proto je také důležité, abychom do vlastních webů tyto prvky také zahrnuly a
roboti vyhledávacích serverů se na naše weby nedíval skrz prsty.

## Server-side strukturovaná data v Nuxt.js

Nuxt.js je framework, jež umožňuje tvorbu webů ve Vue.js s již předpřipraveným
renderováním webu na serveru, rozdělování kódu a generováním statických stránek.
Zároveň obsahuje celou řadu užitečných knihoven či umožňuje jejich následné
nainstalování. Jedním z takových rozšíření je [vue-meta](vue-meta), které umožňuje
editaci hlavičky stránky přímo z komponent a právě toho využijeme pro přidání
strukturovaných dat do hlavičky stránky.

```js
export default {
  data () {
    return {
      structuredData: {
        "@context": "http://schema.org",
        "@type": "Article",
        // Zbytek strukturovaných dat, pro možnosti se podívejte na odkaz výše
        // nebo Google Docs...
      }
    }
  },
  head () {
    return {
      script: [{ innerHTML: JSON.stringify(this.structuredData), type: 'application/ld+json' }]
    }
  },
  async asyncData (context) {
    // Načtení dat a vrácení článku na serveru.
  }
}
```

## Vysvětlení ukázky kódu
Uvnitř funkce `data()` si předformátujeme hodnoty, které mají být následně zobrazeny
ve strukturovaném data bloku. Pokud potřebujete data načítat data dynamicky, měl by
být blok se strukturovanými daty obsažen již ve funkci `asyncData()`.  Jak jsem již
zmiňoval Nuxt.js umožňuje ve funkci `head()` upravit podobu hlavičky stránky a právě
sem vložíme skritp se strukturovanými daty. Nuxt následně vygeneruje `<script>` tag,
který bude obsahovat strukturovaná data a typ _application/ld+json_, nezapomeňte proto
vždy nastavit i vlastnost `type`.

## Závěr
Díky tomuto drobnému ústřižku kódu zajístíte, že vaše Nuxt.js aplikace bude pro
Google Search stravitelná a Google bude schopný zobrazit krom klasického vyhledávání
také speciální ústřižky.



[google-json]: https://developers.google.com/search/docs/guides/intro-structured-data?utm_source=devtools
[schema]: https://schema.org/
[vue-meta]: https://vue-meta.nuxtjs.org/

Jak přidat asynchronní JSON+LD strukturovaná data do NUXT.js web app

XSLT nabízí celou řadu nativních funkcí jako například `not()`, `sum()` a řada dalších. XSLT 2.0 také přineslo podporu pro definování vlastních funkcí v XSLT šabloně, a právě na ni bych se chtěl podívat v tomto článku. 

Vlastní XSLT funkci lze definovat pomocí elementu `xsl:function`, který má tři atributy. Prvním je jméno funkce, `name`, které musí obsahovat také *namespace* prefix. Ten je důležitý zejména proto, aby nedošlo ke kolizi s již existujícími XSLT funkcemi. Prefix také nesmí obsahovat žádný z rezervovaných prefixů viz [W3 dokumentace](https://www.w3.org/TR/xslt20/#dt-reserved-namespace). Druhým atributem je `as`, který definuje datový typ, jež funkce vrací. Nejčastější datové typy lze nalézt například na webu [IBM](https://www.ibm.com/developerworks/library/x-schemaawarexslt/index.html#table1), nezapomeňme ovšem, že v případě základních typů je nutné užít prefix `xs:`. Posledním atributem je `override`, který určuje, co se má stát, pokud již v šabloně existuje stejná funkce se stejným počtem parametrů, *aritou*. Poslední dva atributy není nutné specifikovat.

```xml
<xsl:function name="rocek:getElementId" as="attribute()" override="yes">

</xsl:function>
```

Funkce může přijímat také parametry, k tomuto účelu slouží element `xsl:param`. Stejně jako v případě funkce je nutné specifikovat atribut `name`, tentokrát ovšem není nutné uvádět *namespace* prefix. Atribut `as` opět určuje datový typ.

```xml
<xsl:function name="rocek:getElementId" as="attribute()" override="yes">
  <xsl:param name="element" as="element()" />
</xsl:function>
```

Nakonec by měla funkce obsahovat nějaké tělo. V našem případě vrátíme ID elementu, a to buď z atributu `xml:id` nebo `ana`. Podle toho, zdali je ID přítomné. Nejsem si jistý, že by kdy bylo takovou funkci potřeba vytvářet, nicméně pro ilustrační účely takto jednoduchá funkce postačuje.

```xml
<xsl:function name="rocek:getElementId" as="attribute()" override="yes">
  <xsl:param name="element" as="element()" />
  <xsl:choose>
    <xsl:when test="$element/@xml:id">
      <xsl:sequence select="$element/@xml:id"/>
    </xsl:when>
    <xsl:otherwise>
      <xsl:sequence select="$element/@ana"/>
    </xsl:otherwise>
  </xsl:choose>
</xsl:function>
```

Krom nadefinování funkce je nutné také registrovat vlastní *namespace*. Toho lze docílit pomocí úpravy XSL stylesheet hlavičky následujícím způsobem. Adresa za rovnítkem může být libovolná.

```xml
<xsl:stylesheet
  xmlns="http://www.tei-c.org/ns/1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:rocek="http://libovolna.adresa"
  version="3.0"
  exclude-result-prefixes="tei lindat"
>
  
</xsl:stylesheet>
```

Po této úpravě je funkce úspěšně nadefinovaná a připravená na použití v našich transformacích. Třeba tímto způsobem:

```xml
<xsl:template match="div">
  <div id="section-{rocek:getElementId(current())}">
    <xsl:apply-templates/>
  </div>
</xsl:template>
```

Vlastní funkce v XSL

V nedávné době jsem začal dělat na relativně jednoduché aplikaci v [Electronu](https://www.electronjs.org). Jelikož jsem zvyklý pracovat s JavaScriptovými frameworky [Vue.js](https://vuejs.org) a [React.js](https://reactjs.org), přemýšlel jsem, zdali bych je mohl využít i pro tuto aplikaci - samozřejmě, že mohl. Rozhodl jsem se tedy pro Vue.js. Chvíli jsem Googlil, jaké způsoby propjení se nejčastěji používají. Většinou jsem skončil u nějakého již hotového CLI. Rozhodl jsem se tedy, že zkusím [Vue CLI plugin Electron Builder](https://nklayman.github.io/vue-cli-plugin-electron-builder/). Jak název napovídá jedná se o rozšíření pro Vue CLI a implementuje krom Electronu také [Electron Builder](https://www.electron.build), což je balíček, který následně zásadním způsobem zjednoduše vytvoření buildu s hotovou aplikací.

Začal jsem tedy vyvíjet aplikaci, zkusil jsem i několik první buildů. Z počátku se jevilo vše bez problémů, ty přibývali až s tím, jak se rozšiřoval kód aplikace. Tedy snad krom toho, že ani první build na macOS mi nefungoval, ukázalo se ovšem, že se jedná o problém Archiver aplikace, která po rozbalení zipu neobnoví symliky, lze to tedy obejít jiným softwarem pro práci s archivy. Mimo to Apple o chybě ví již od macOS Catalina. U macOS ještě zůstanu, zkoušel jsem také build pro nové MacBooky s procesory Apple Silicon, nejprve se zdálo, že Electron Builder tyto procesory nerozeznává, nicméně po kontrole v Activity Monitoru jsem zjistil, že některé buildy jsou označené jako _Apple_ a jiné _Intel_. Došlo mi, že buildy se tedy vytváří podle správné architektury, ale záleží, který se vytvoří první - jestli ARM nebo Intel, protože ten druhý ho přepíše. Takových hloupých drobností se vynořila ještě řada, mimo to třeba nešlo vytvořit .dmg ani .pkg. Kamarád mi tedy doporučuje `electron-packager`. Jenže nahradit builder v téhle CLI utilitě není otázka jednoho npm *(Node Package Manager)* příkazu. Všechny problémy jsem nakonec vyřešil a buildy mi fungují tak, jak potřebuji, nicméně vedlo mne to k otázce, co kdybych si to řešil celé sám?

Právě tomu bych se chtěl věnovat v tomto článku. Narozdíl od Vue.js jsem se ale rozhodl pro React.js. Rozhodl jsem se také tradiční Webpack nahradit Vite a zkusit, jestli tyhle nástroje půjde kombinovat. Ponechme stranou, že zatímco u Electron bundleru získám uričtou svobodu nad konfigurací, tak s Vite ji zase část obětuji. Nicméně, kombinace těhle nástroju je nakonec jednodušší, než bych čekal. Samozřejmě má svá uskalí a rozhodně není tak pohodlná jak hotové CLI nástroje, tedy pokud se nerozhodnete napsat něco podobného sami. To ovšem součástí tohoto článku nebude.

## Vite a React.js

Začneme instalací Vite, jak už jsem říkal jedná se o svým způsobem obdobu Webpacku. Stejně jako Webpack nabízí dev server i nástroj pro _zbuildění_ kódu aplikace. Nicméně, na rozdíl od Webpacku pracuje rovnou s ES _(ECMAScript)_ moduly a nekompiluje je do CommonJS, dále také Express.js web server nahradil minimalistický Koa server. _Hot module reloading_ je také mnohonásobně rychlejší, de facto instantní, na druhou stranu umožňuje použití pouze ES modulů a nikoliv CommonJS nebo AMD. Build kódu provádí v  předkonfigurovaném [Rollupu](https://rollupjs.org/guide/en/), kdežto Webpack tohle řeší sám. Jakousi pomyslnou výhodou je také nutnost minimální konfigurace celého projektu, tedy pokud se rozhodnete použít některý z předdefinovaných presetů, například React nebo Vue.

```bash
npm init @vitejs/app my-react-app
```

Během tvorby projektu se Vite zeptá na volbu šablony, zvolíme tedy `react`. Následně se zobrazí výzva s několika příkazy, které bychom měli spustit, aby se vše nainstalovalo, tedy:

```bash
cd my-react-app
npm install
npm run dev
```

Pokud jsme spustili minimálně ty první dva, Vite rozhraní a React.js applikace jsou připravné. Zbývá tedy finální příkaz, a to spustit dev server, abychom ověřili, že vše funguje. V příkazovém řádku by se nám měla zobrazit informace, že aplikace běží na `http://localhost:3000` případně nějakém jiném portu, pokud je 3000 již zabraný. Můžeme se tedy pustit do instalace Electronu,

## Electron

Je framework pro tvorbu _cross-platform_ desktopových aplikací s pomocí JavaScriptu, CSS a HTML. Díky Electronu tak lze vytvořit nativní aplikace a ty nejtěžší věci jako updatování, nativní menu a notifikace nebo crash reporting za nás řeší právě Electron. Instalace je velice jednoduchá, stačí spustit následující příkaz:

```bash
npm install --save-dev electron
```

Teď už jen zbývá upravit soubor `package.json` a přidat tzv. _entry point_ pro Electron aplikaci, nejčastěji zvaný `main.js`. Nicméně v tuto chvíli přichází na řadu první háček, Electron podporuje pouze CommonJS, zatímco Vite jen ES. Jednou možností je smířit se s tím, že části pro Electron budou v CommonJS a části pro Vite/React v ES, to ale trochu znesnadní možnost sdílení kódu. Jelikož Vite preferuje ES je jednodušší kód pro Electron kompilovat z ES do CommonJS. Náš _entry point_ bude tedy vypadat následovně:

**main.js**
```js
import { app, BrowserWindow } from 'electron'
import path from 'path'

const IS_DEV = process.env.IS_IN_DEVELOPMENT || false

function createWindow () {
  // Vytvoříme hlavní okno Electronu
  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: true,
      enableRemoteModule: true
    }
  })

  if (IS_DEV) {
    // Pokud jsme ve vývojovém režimu načteme obsah z localhost serveru - vite
    // a otevřeme vývojářské nástroje
    win.loadURL('http://localhost:3000')
    win.webContents.openDevTools()
  } else {
    // Ve všech ostatních případech načteme soubor index.html ze složky dist
    win.loadURL(`file://${path.join(__dirname, '..' ,'dist', 'index.html')}`)
  }
}

app.whenReady().then(createWindow)

app.on('window-all-closed', () => {
  // Na macOS je běžné, že aplikace a její menu bar zůstanou
  // aktivní dokud uživatel aplikaci nevypne skrze zkratku Cmd + Q
  if (process.platform !== 'darwin') {
    app.quit()
  }
})

app.on('activate', () => {
  // Pokud je na macOS aplikace v docku, je běžné, že se okno vytvoří po
  // kliknutí na ikonu v docku, pokud nejsou žádná okna aktivní
  if (BrowserWindow.getAllWindows().length === 0) {
    createWindow()
  }
})
```

Snad jedím rozdílem proti tomu, který najdeme na webu Electronu je použití ES a deklarace globální proměnné `IS_DEV`, kterou
rozlišíme zdali má Electron instance načíst web z Vite serveru nebo vygenerovanou HTML stránku ve složce `./dist`. Následně je potřeba
upravit `package.json` tak aby hodnota `"main"` odkazovala na náš soubor, tedy ne tak úplně:

**package.json**

```json
{
  "main": "./dist/main.js",
}
```

Možná vás překvapí, že odkazuji do složky `dist`, kdežto náš soubor není v žádné složce. Hned vysvěltím.

## ESBuild

Jak už jsem psal, Electron podporuje pouze CommonJS, zatímco Vite a tím pádem i React pracuje pouze ES. Co s tím?
Nejjednodušším řešením je použít nějaký bundler, v tomto případě esbuild, neboť jej používá i Vite. Zkoušel jsem také Babel, nicméně
je v konfilktu s Vite a aplikaci se pak nepodaří _zbuildit_. Nainstalujeme tedy esbuild:

```bash
npm install --save-dev esbuild
```

Do části `"scripts"` přidáme následující řádky:

```json
{
  "scripts": {
    "esbuild-cjs": "esbuild main.js --format=cjs --outfile=./dist/main.js",
    "electron:dev": "npm run esbuild-cjs && IS_IN_DEVELOPMENT=true electron ."
  }
}
```

První skript, tedy `esbuild-cjs` transformuje ES kód do CommonJS a tím pádem jej učiní stravitelným pro Electron. Když
si jej pořádně přečteme, tak také zjistíme, že výstupní soubor se ukládá do složky `./dist/main.js`, tedy tam, kam jsme odkázali
v hodnotě `"main"` v `package.json` souboru. Druhý skript potom slouží ke spuštění vývojové instance Electronu. Pokud jsme tedy vše udělali správně, spuštěním příkazu `npm run electron:dev` se nejprve transformuje soubor `main.js` do CommonJS a až následně se spustí Electron. Pokud nám zároveň běží Vite server, zobrazí se uvodní stránka React aplikace - shodná s tou, kterou jsme viděli v prohlížeči po navštívení stránky `http://localhost:3000`. Teď už zbývá jen zvolit si ten správný builder a můžeme vyvíjet aplikace s Vite, Reactem a Electronem.

## Electron Packager

Po úvodním fiasku s Electron Builderem jsem se rozhodl, že pro tento článek zkusím alternativu, tedy [Electron Packager](https://github.com/electron/electron-packager). Musím uznat, že dokumentace se nedá srovnávat, Builder ji má mnohem lepší, ale zkusit se má všechno. Nainstalujeme tedy Electron Packager:

```bash
npm install --save-dev electron-packager
```

Po instalaci stačí přidat do `package.json` do hodnoty `"scripts"` další skript, a to:

```json
{
  "scripts": {
    "electron:build": "npm run esbuild-cjs && electron-packager --out=release ."
  }
}
```

Skript opět nejprve využije již existujícího esbuild skritpu k tomu, aby soubor `main.js` převedl do CommonJS a následně zavolá
Electron Builder, který v tomto případě vytvoří package aplikace pro naši aktivní paltformu. V případe Windows pro Windows, macOS pro macOS a Linuxu pro Linux. Tím máme hotovo a nezbývá než si pohrát se samotnou aplikací a konfigurací všech součástí.

Electron a Vite.js s React.js


Pokud chceme na svém webu nebo nějakém jiném zobrazovat příspěvky ze sociálních sítí,
či pracovat s nějakou API, je často dobré mít vlastní server, který výsledky z původní API nacachuje.
To platí zejména ve chvíli, kdy jsou dotazy na API limitované a hrozilo by reálné riziko, že se jednoho
dne server dané služby zapře a už nic nepošle.

V tomto článku bych se chtěl věnovat tomu, jak si takovou jednoduchou API cache vytvořit s pomocí
_Express.js_ aplikace. Předpokládám tedy alespoň základní znalost _JavaScriptu_, práce s _NPM (Node Package Manager)_ a příkazovou řádkou.

## Začínáme

Nejjednodušším způsobem, jak začít s _Express.js_ aplikací je využít tzv. _Express application generator_. To je
jednoduchý nástroj, který přípraví základní strukturu projektu a do souboru `package.json` přidá informaci o
knihovnách, které budeme pro naši aplikaci potřebovat. Začněme tedy vytvořením složky s naší aplikací:

```bash
mkdir API-Cache && cd API-Cache
```

Následně ve složce vytvoříme novou _Express.js_ aplikaci a doinstalujeme několik knihoven. Doporučuji se také podívat
na případné možnosti konfigurace v [dokumentaci](https://expressjs.com/en/starter/generator.html).

```bash
npx express-generator && npm install
```

V naší složce by se tak měla vytvořit základní struktura projektu včetně složky `node_modules` obsahující všechny knihovny
specifikované v souboru `package.json`. Pro náš projekt budeme ovšem potřebovat ještě několik dalších knihoven, které
_generátor_ neobsahuje, a to _dotenv_, _cors_ a _got_, případně také _nodemon_ pro automatické restartování serveru při změně v kódu.

```bash
npm install --save dotenv cors got
# jelikož v produkci nodemon nepotřebujeme, nainstalujeme jej pouze jako dev dependency
npm install --save-dev nodemon
```

Nakonec vytvoříme prázdný `.env` soubor, který bude obsahovat citlivá data naší aplikace, například autentizační tokeny.

```bash
touch .env
```

Tímto bychom měli mít připraveno vše potřebné pro vývoj aplikace.

## Zdroj informací

Pro naši příkladovou aplikaci použijeme jako zdroj informací volně přístupnout API _Quotes on Desing_, která
obsahuje řadu citátů významných osobností. Informace k API jsou naleznutelné [zde](https://quotesondesign.com/api/) pro naše účely si zkopírujte
tento odkaz:

```
https://quotesondesign.com/wp-json/wp/v2/posts/?orderby=rand&per_page=1
```

Výsledky jsou řazené náhodně, navíc díky parametru `per_page=1` se nám zobrazí vždy pouze jeden citát.

## Cache

Dále potřebujeme vyřešit _cache_ providera, v tomto článku budu pracovat s _cache_ v paměti serveru. Nejedná se
o zcela ideální řešení, zejména pokud je potřeba uchovat větší množství dat nebo by měla data v cache zůstat i
po restartu serveru. V takovém případě by bylo lepší zvolit _cache_, která se ukládá na disk. Nicméně v tomto případě předpokládám,
že data zůstanou v _cache_ jen maximálně několik desítek minut.

Vytvoříme si tedy jednoduchou _constructor function/class_, která bude držet naše data. Vytvoříme si tedy složku `mkdir utils`, ve které budeme
mít uloženou naši _constructor function/class_ - `DataCache.js`.

**DataCache.js**
```js
function DataCache (fetchFunction, minutesToLive = 10) {
  this.fetchFunction = fetchFunction;
  this.millisecondsToLive = minutesToLive * 60 * 1000;
  this.fetchDate = new Date(0);
  this.cache = null;

  //...

}

module.exports = DataCache;
```

Základní podoba naší _constructor function/class_ _DataCache_ je tedy následující, přijímá dva parametry.
První `fetchFunction` je metoda, která má načíst data z našeho zdroje, pokud je potřeba aktualizovat _cache_.
Druhý parametr je doba životnosti dat v _cache_ než přestanou být validní. Pro lepší přehlednost je budeme zadávat v minutách
a přepočteme je až následně do miliseknud. Dále si připravíme proměnnou `this.cache`, jež by měla obsahovat data a `this.fetchDate`,
která bude nést datum posledního načtení dat do _cache_.

Do naší třídy si také přidáme funkci `isCacheExpired()` abychom zjistili, zdali už _cache_ expirovala, či nikoliv.

```js
  this.isCacheExpired = () => {
    return (this.fetchDate.getTime() + this.millisecondsToLive) < new Date().getTime();
  }
```
Metoda porovnává momentální čas se součtem času uloženém v proměnné
`fetchDate` a životností cache. Pokud je tento čas menší než je momentální čas, _cache_ expirovala.
Nejdůležitější funkcí je ovšem `getData()`, neboť zajišťuje jednak načtení dat ze zdroje a jednak jejich vrácení z cache, a to
v závislosti na tom, zdali jsou v cache uložené a je stále validní.

```js
  this.getData = () => {
    if (!this.cache || this.isCacheExpired()) {
      console.log('expirováno - načítám nová data');
      return this.fetchFunction()
        .then((data) => {
        this.cache = data;
        this.fetchDate = new Date();
        return data;
      });
    } else {
      console.log('data jsou v cache');
      return Promise.resolve(this.cache);
    }
  }
```

Metoda vždy vrací _Promise_ s daty. Pro lepší přehlednost jsem také v kódu nechal logy, jež nám v příkazovém řádku
ukáží, jestli server načítal data nově nebo z _cache_. Tímto máme hotovou naši _DataCache_ třídu a můžeme ji vyzkoušet
v praxi.

## Načítání dat na serveru

Vytvoříme si tedy v rootu projektu složku s controllery `mkdir controllers && cd controllers` a v ní controller `touch QuoteController.js`. _QuoteController_ bude obsahovat pouze jednu metodu, a to `getQuote`, která se dotáže _Quote on Design_ serveru na aktuální citát.

**QuoteController.js**

```js
const got = require('got');
const DataCache = require('../utils/DataCache');

function getQuote () {
  return got(`https://quotesondesign.com/wp-json/wp/v2/posts/?orderby=rand&per_page=1`)
    .then((response) => {
      return JSON.parse(response.body);
    })
    .catch((error) => {
      return error;
    });
}

const quote = new DataCache(getQuote, 1);

module.exports = quote;
```

Nejprve načteme potřebné knihovny, což je _got_, který budeme potřebovat pro
dotaz do API a naše třída _DataCache_. Následně
deklarujeme funkci `getQuote()` která se skládá pouze z dotazu do API. Pro dotaz
použijeme knihovnu [_got_](https://github.com/sindresorhus/got), byť by šlo
využít i standardního _HTTP_ modulu, nicméně _got_ nám podstatně
ušetří práci. V `then` bloku převedeme ještě tělo odpovědi do formátu _JSON_,
neboť _got_ sám o sobě s odpovědí nijak nepracuje a vrací pouze textový řetězec.
Nakonec vytvoříme proměnnou, v níž inicializujeme naši _DataCache_ třídu a vyexportujeme ji.

Do souboru `./routes/index.js` přidáme následující řádky. _Require_ na náš controller přidáme pod ostatní
_require_ řádky. Registraci naší cesty potom kamkoliv pod původní kód, avšak před `module.exports`.

```js
// .. původní require statements
const quoteController = require('../controllers/quoteController');

// ... původní kód
router.get('/quote', async (req, res, next) => {
  quoteController.getData().then((data) => {
    res.json(data);
  });
});
```

V registraci _route_ pouze zavoláme _controller_ a v něm metodu z naší třídy, jež pro nás zprostředkovává
data buďto z _cache_ nebo z dotazu do API. Vrácená data potom odešleme ve formátu json. To je vše! Teď už
jen stačí spustit příkaz `npm run start` a navštívit v prohlížeči stránku `http://localhost:3000/quote`, kde by
se měl zobrazit náhodný citát! V konzoli serveru by mělo být vidět následující:

```
[nodemon] starting `node ./bin/www`
expirováno - načítám nová data
GET /quote 200 164.028 ms - 5056
data jsou v cache
GET /quote 200 1.710 ms - 5056
data jsou v cache
GET /quote 200 0.969 ms - 5056
```

## Závěrem
Gratuluji k úspěšnému vytvoření velice jednoduché a základní API cache! Pokud jste se rozhodli, že vám
takováto jednoduchá cache stačí. Doporučuji podívat se na celý kód znovu a rozšířit, případně upravit zachytávání chyb, stejně tak
je asi vhodné odstranit z kódu `console.log()` části. `DataCache` třídu lze také velmi snadno rozšířit modulem `fs`
o možnost ukládání cache na disk, byť ani to nemusí být v některých případech ideální.


Jak vytvořit vlastní cache server pro různá API?


Pokud cheme pracovat v PHP s Oracle databází, je nutné si nejprve zkompilovat a
nainstalovat OCI8 rozšíření.

## Instalace Oracle Instant Clienta a SDK

Nejprve si z ([webu Oracle][wOracle]) stáhneme _Instant Clienta_ a _SDK_ k čemuž
je zároveň potřeba se zaregistrovat na webu Oracle. Hledáme soubory
`instantclient-basic-linux.x64-[verze].zip` a `instantclient-sdk-linux.x64-[verze].zip`.
Jakmile soubory stáhneme, vytvoříme složku v `/opt`, například `mkdir /opt/oracle`. Soubory
do složky následně přesuneme.

```bash
mv instantclient-basic-linux.x64-[verze].zip /opt/oracle/instantclient-basic-linux.x64-[verze].zip
mv instantclient-sdk-linux.x64-[verze].zip /opt/oracle/instantclient-sdk-linux.x64-[verze].zip
```

Přesunuté soubory je potřeba rozbalit.

```bash
cd /opt/oracle
unzip instantclient-basic-linux.x64-[verze].zip
unzip instantclient-sdk-linux.x64-[verze].zip
```

Následně vytvoříme symbolické odkazy na `.so` soubory. **Vaše verze Instant Clienta a SDK
se může lišit, proto překontrolujte název složky i název .so souborů.**

```bash
ln -s /opt/oracle/instantclient_19_5/libclntsh.so.19.5 /opt/oracle/instantclient_19_5/libclntsh.so
ln -s /opt/oracle/instantclient_19_5/libocci.so.19.5 /opt/oracle/instantclient_19_5/libocci.so
```

Nakonec je ještě nutné přidat složku do konfigurace ldconfigu. **Opět se bude lišit název složky**

```bash
echo /opt/oracle/instantclient_19_5 > /etc/ld.so.conf.d/oracle-instantclient.conf
```

A aktualizovat ldconfig, pomocí příkazu `ldconfig`.

## Instalace rozšíření do PHP

Abychom mohli oci8 rozšíření zkompilovat, je obvykle nutné nainstalovat ještě několik
dalších knihoven. Zpravidla se jedná o tyto:

```bash
apt install php-dev php-pear build-essential libaio1
```

Po úspěšné instalaci se můžeme konečně pustit do kompilace OCI8 rozšíření. V příkaze
`echo` uvedeme cestu ke složce s instalací _instant clienta_, neboť pokud bychom ji
neuvedli, zeptala by se nás na to instalace stejně.

```bash
echo "instantclient,/opt/oracle/instantclient_12_2" | pecl install oci8
```

Po kompilaci a instalaci je ještě potřeba upravit konfiguraci PHP tak, aby rozšíření
OCI8 načítalo. Proto odešleme následující sadu příkazů:

```bash
echo "extension=oci8.so" >> /etc/php/7.3/mods-available/oci8.ini
ln -s /etc/php/7.3/mods-available/oci8.ini /etc/php/7.3/cli/conf.d/20-oci8.ini
ln -s /etc/php/7.3/mods-available/oci8.ini /etc/php/7.3/fpm/conf.d/20-oci8.ini
ln -s /etc/php/7.3/mods-available/oci8.ini /etc/php/7.3/apache2/conf.d/20-oci8.ini
```

První řádek vytvoří `.ini` soubor v modech PHP 7.3. Pokud máte jinou verzi PHP, nebo si
nejste jistí, zkontrolujte si ji nejprve příkazem `php --version`. Zbývající tři řádky vytvoří
symbolický link do CLI, FPM a Apache2, aby bylo rozšíření načteno ve všech prostředích. Pokud ovšem
nepoužíváte FPM nebo Apache2, můžete jeden z těchto řádků s klidným svědomím vypustit.
Nakonec zkontrolujeme, zdali je rozšíření skutečně zapnuto

```bash
php -m | grep oci8
php-fpm7.3 -m | grep oci8
```

Pokud uvidíte oci8, jsme téměř u konce. Ještě je totiž potřeba restartovat FPM klienta, případně Apache2.

```bash
service php7.3-fpm restart
## nebo
service apache2 restart
```



[wOracle]: https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html

Martin Roček