Compare commits

..

1 Commits

@ -1,16 +1,13 @@
export TEXINPUTS=../tex//:
all: vlna prace.pdf sighup
all: prace.pdf sighup
# LaTeX je potreba spustit nekolikrat, aby spravne spocital odkazy
prace.pdf: prace.tex $(wildcard *.tex) literatura.bib prace.xmpdata
pdflatex $<
bibtex prace
pdflatex $<
pdflatex $<
vlna: $(wildcard *.tex)
-vlna -l $^
lualatex $<
biber prace
lualatex $<
lualatex $<
clean:
rm -f *.log *.dvi *.aux *.toc *.lof *.lot *.out *.bbl *.blg *.xmpi *.lol

@ -1,21 +1,21 @@
%% $Id$
%% File: `csplainnat.bst' for use with natbib package
%% This is a modification of `plainnat.bst' for Czech references style
%% (According to "CSN ISO 690: Bibliograficke citace. Obsah, forma a struktura").
%% Some modifications are commented, look for the keyword 'CHANGE'
%% For more detailed info use svn repository svn://kraken.pedf.cuni.cz/csplainnat/
%% File: `plainnat.bst'
%% A modification of `plain.bst' for use with natbib package
%%
%% Original plainnat.bst by Patrick W Daly
%% Modifications by David Mudr{\'{a}}k mudrd8mz@uxit.pedf.cuni.cz
%%
%% MAJOR MODIFICATIONS
%% * Added "@ONLINE" item type with added "cited" field.
%% Copyright 1993-2007 Patrick W Daly
%% Max-Planck-Institut f\"ur Sonnensystemforschung
%% Max-Planck-Str. 2
%% D-37191 Katlenburg-Lindau
%% Germany
%% E-mail: daly@mps.mpg.de
%%
%% This program can be redistributed and/or modified under the terms
%% of the LaTeX Project Public License Distributed from CTAN
%% archives in directory macros/latex/base/lppl.txt; either
%% version 1 of the License, or any later version.
%%
% Version and source file information:
% \ProvidesFile{natbst.mbs}[2007/11/26 1.93 (PWD)]
%
% BibTeX `plainnat' family
% version 0.99b for BibTeX versions 0.99a or later,
% for LaTeX versions 2.09 and 2e.
@ -72,7 +72,6 @@ ENTRY
url
volume
year
cited
}
{}
{ label extra.label sort.label short.list }
@ -86,7 +85,7 @@ FUNCTION {init.state.consts}
#3 'after.block :=
}
STRINGS { s t t1 t2 } % CHANGE mudrd8mz 2005-10-12 adding t1, t2
STRINGS { s t }
FUNCTION {output.nonnull}
{ 's :=
@ -212,37 +211,39 @@ FUNCTION {emphasize}
if$
}
FUNCTION {capitalize} % CHANGE mudrd8mz 2005-10-12 adding new function
{
duplicate$ empty$
FUNCTION {embolden} %% FUNCTION added by AK
{ duplicate$ empty$
{ pop$ "" }
{ "{\sc " swap$ * "}" * } %{ "u" change.case$ }
{ "{\bf " swap$ * "}" * }
if$
}
FUNCTION {scshape} %% FUNCTION added by AK
{ duplicate$ empty$
{ pop$ "" }
{ "{\sc " swap$ * "}" * }
if$
}
INTEGERS { nameptr namesleft numnames }
FUNCTION {format.names.full}
FUNCTION {format.names}
{ 's :=
#1 'nameptr :=
s num.names$ 'numnames :=
numnames 'namesleft :=
{ namesleft #0 > }
{ s nameptr "{ll}" format.name$ 't1 := % CHANGE mudrd8mz 2005-10-12
t1 capitalize 't1 := % CHANGE mudrd8mz 2005-10-12
s nameptr "{, f.}{~j.}" format.name$ 't2 := % CHANGE mudrd8mz 2005-10-12
t1 t2 * 't :=
{ s nameptr "{vv~}{ll}{, jj}{, f.}" format.name$ 't := %% {ff~}{vv~}{ll}{, jj} changed to {vv~}{ll}{, jj}{, f.} by AK
nameptr #1 >
{ namesleft #1 >
{ " -- " * t * } % CHANGE mudrd8mz 2005-10-13 : adding "--"
{ ", " * t * }
{ numnames #2 >
{ "" * } % CHANGE mudrd8mz 2005-10-12
{ "" * } %% { "," * } changed to { "" * } by AK (on suggestion by MK)
'skip$
if$
t "OTHERS" = % CHANGE mudrd8mz 2005-10-12 because of capitalize
{ " et~al." * }
{ " -- " * t * } % CHANGE mudrd8mz 2005-10-12 : between the last and the one before
t "others" =
{ " a~kol." * } %% et~al. changed to a~kol. by AK
{ " {\rm a} " * t * } %% and changed to {\rm a} by AK
if$
}
if$
@ -255,22 +256,6 @@ FUNCTION {format.names.full}
while$
}
FUNCTION {format.names.short} % CHANGE mudrd8mz 2005-10-14 adding more authors version
{ 's :=
s #1 "{ll}" format.name$ 't1 :=
t1 capitalize 't1 :=
s #1 "{, f.}{~j.}" format.name$ 't2 :=
t1 t2 * " et~al." *
}
FUNCTION {format.names}
{ duplicate$
num.names$ #3 >
{format.names.short} % pokud ma citace vice nez 3 autory, uvadi se pouze PRVNI et al.
{format.names.full} % pokud ma citace max 3 autory, uvadi se vsichni
if$
}
FUNCTION {format.key}
{ empty$
{ key field.or.null }
@ -281,17 +266,17 @@ FUNCTION {format.key}
FUNCTION {format.authors}
{ author empty$
{ "" }
{ author format.names }
{ author format.names scshape} %% scshape added by AK
if$
}
FUNCTION {format.editors}
{ editor empty$
{ "" }
{ editor format.names
{ editor format.names scshape %% scshape added by AK
editor num.names$ #1 >
{ " (Ed.)" * } % CHANGE mudrd8mz 2005-10-12
{ " (Ed.)" * }
{ ", editors" * }
{ ", editor" * }
if$
}
if$
@ -314,12 +299,10 @@ FUNCTION {format.issn}
FUNCTION {format.url}
{ url empty$
{ "" }
{ new.block "Dostupn{\'{e}}~z: \url{{" url * "}}" * }
{ new.block "URL \url{" url * "}" * }
if$
}
FUNCTION {format.doi}
{ doi empty$
{ "" }
@ -330,11 +313,10 @@ FUNCTION {format.doi}
FUNCTION {format.title}
{ title empty$
{ "" }
{ title }
{ title "t" change.case$ }
if$
}
FUNCTION {format.full.names}
{'s :=
#1 'nameptr :=
@ -349,12 +331,12 @@ FUNCTION {format.full.names}
{ ", " * t * }
{
numnames #2 >
{ "," * }
{ "" * } %% { "," * } changed to { "" * } by AK (on suggestion by MK)
'skip$
if$
t "others" =
{ " et~al." * }
{ ", " * t * } % CHANGE mudrd8mz 2005-10-12
{ " a~kol." * } %% et~al. changed to a~kol. by AK
{ " a " * t * } %% and changed to a by AK
if$
}
if$
@ -449,7 +431,7 @@ FUNCTION {n.dashify}
FUNCTION {format.date}
{ year duplicate$ empty$
{ "empty year in " cite$ * warning$
pop$ "" }
pop$ " " }
'skip$
if$
month empty$
@ -461,6 +443,34 @@ FUNCTION {format.date}
extra.label *
}
%%% Non-successful atempt to change the function format.date to produce year in brackets
%FUNCTION {format.date}
%{ year duplicate$ empty$
% { "empty year in " cite$ * warning$
% pop$ " " }
% {
% " (" * year * %% 'skip$ replaced by { "(" * year * } by AK
% }
% if$
% month empty$
% 'skip$
% { month
% " " * swap$ *
% }
% if$
% extra.label * ")" * %% extra.label * changed to extra.label * ")" * by AK
%}
FUNCTION {output.year.check} %% function added by AK
{ year empty$ %% It replaces original format.date on most places below
{ "empty year in " cite$ * warning$ }
{ write$
" (" year * extra.label * ")" *
mid.sentence 'output.state :=
}
if$
}
FUNCTION {format.btitle}
{ title emphasize
}
@ -483,10 +493,10 @@ FUNCTION {either.or.check}
FUNCTION {format.bvolume}
{ volume empty$
{ "" }
{ "" volume tie.or.space.connect % CHANGE mudrd8mz 2005-10-12 removing "volume"
{ "volume" volume tie.or.space.connect
series empty$
'skip$
{ " / " * series emphasize * } % CHANGE mudrd8mz 2005-10-12 "of" --> "/"
{ " of " * series emphasize * }
if$
"volume and number" number either.or.check
}
@ -498,13 +508,13 @@ FUNCTION {format.number.series}
{ number empty$
{ series field.or.null }
{ output.state mid.sentence =
{ "{\v{c}}." } % CHANGE mudrd8mz 2005-10-12 "{\v{c}}" instead of "number"
{ "{\v{C}}." }
{ "number" }
{ "Number" }
if$
number tie.or.space.connect
series empty$
{ "there's a number but no series in " cite$ * warning$ }
{ " v " * series * } % CHANGE mudrd8mz 2005-10-12 "in" --> "v"
{ " in " * series * }
if$
}
if$
@ -550,8 +560,8 @@ FUNCTION {format.pages}
{ pages empty$
{ "" }
{ pages multi.page.check
{ "s." pages n.dashify tie.or.space.connect } % CHANGE mudrd8mz 2007-03-15: 'pages' -> 's.'
{ "s." pages tie.or.space.connect } % CHANGE mudrd8mz 2007-03-15: 'pages' -> 's.'
{ "pages" pages n.dashify tie.or.space.connect }
{ "page" pages tie.or.space.connect }
if$
}
if$
@ -565,10 +575,10 @@ FUNCTION {format.eid}
}
FUNCTION {format.vol.num.pages}
{ volume field.or.null
{ volume field.or.null embolden %% embolden added by AK
number empty$
'skip$
{ ", " number * *
{ "\penalty0 (" number * ")" * *
volume empty$
{ "there's a number but no volume in " cite$ * warning$ }
'skip$
@ -579,7 +589,7 @@ FUNCTION {format.vol.num.pages}
'skip$
{ duplicate$ empty$
{ pop$ format.pages }
{ ", s.~" * pages n.dashify * }
{ ", \penalty0 " * pages n.dashify * } %% { ":\penalty0 " * pages n.dashify * } changed to { ", \penalty0 " * pages n.dashify * } by AK
if$
}
if$
@ -589,7 +599,7 @@ FUNCTION {format.vol.num.eid}
{ volume field.or.null
number empty$
'skip$
{ "\penalty0, " number * *
{ "\penalty0 (" number * ")" * *
volume empty$
{ "there's a number but no volume in " cite$ * warning$ }
'skip$
@ -610,7 +620,7 @@ FUNCTION {format.chapter.pages}
{ chapter empty$
'format.pages
{ type empty$
{ "" } % CHANGE mudrd8mz 2008-04-08 removing the word "chapter"
{ "chapter" }
{ type "l" change.case$ }
if$
chapter tie.or.space.connect
@ -627,7 +637,7 @@ FUNCTION {format.in.ed.booktitle}
{ "" }
{ editor empty$
{ "In " booktitle emphasize * }
{ "In " format.editors * " " * booktitle emphasize * } % CHANGE mudrd8mz 2005-10-12
{ "In " format.editors * ", " * booktitle emphasize * }
if$
}
if$
@ -646,7 +656,9 @@ FUNCTION {empty.misc.check}
FUNCTION {format.thesis.type}
{ type empty$
'skip$
{ pop$ type } % CHANGE mudrd8mz 2007-03-15: Do not lowercase the thesis type
{ pop$
type "t" change.case$
}
if$
}
@ -671,9 +683,9 @@ FUNCTION {format.article.crossref}
{ "In \emph{" journal * "}" * }
if$
}
{ "In " key * }
{ "In " }
if$
" \citep{" * crossref * "}" *
" \citet{" * crossref * "}" *
}
FUNCTION {format.book.crossref}
@ -697,12 +709,12 @@ FUNCTION {format.book.crossref}
{ "\emph{" * series * "}" * }
if$
}
{ key * }
'skip$
if$
}
'skip$
if$
", \citet{" * crossref * "}" *
" \citet{" * crossref * "}" *
}
FUNCTION {format.incoll.inproc.crossref}
@ -718,7 +730,7 @@ FUNCTION {format.incoll.inproc.crossref}
{ "In \emph{" booktitle * "}" * }
if$
}
{ "In " key * }
{ "In " }
if$
}
{ "In " }
@ -730,17 +742,19 @@ FUNCTION {article}
{ output.bibitem
format.authors "author" output.check
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.title "title" output.check
new.block
crossref missing$
{ journal emphasize "journal" output.check
new.sentence
format.date "year" output.check
eid empty$
{ format.vol.num.pages output }
{ format.vol.num.eid output }
if$
%% format.date "year" output.check %% commented by AK
}
{ format.article.crossref output.nonnull
eid empty$
@ -757,33 +771,6 @@ FUNCTION {article}
fin.entry
}
FUNCTION {online} % CHANGE mudrd8mz 2005-10-12 addign new item type
{ output.bibitem
format.authors output
new.block
format.btitle " [online]" * output
new.sentence
publisher missing$
'skip$
{ publisher output }
if$
year missing$
'skip$
{ format.date "year" output.check }
if$
new.sentence
cited missing$
'skip$
{ "[cit.~" cited * "]" * output }
if$
new.sentence
note output
new.sentence
format.url output
fin.entry
}
FUNCTION {book}
{ output.bibitem
author empty$
@ -797,28 +784,30 @@ FUNCTION {book}
if$
}
if$
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.btitle "title" output.check
crossref missing$
{ new.block
format.bvolume output
{ format.bvolume output
new.block
format.number.series output
new.sentence
publisher
% address "~: " * publisher * % CHANGE mudrd8mz 2005-10-12
"publisher" output.check
publisher "publisher" output.check
address output
}
{ new.block
format.book.crossref output.nonnull
}
if$
format.edition output
format.date "year" output.check
%% format.date "year" output.check %% commented by AK
format.isbn output
format.doi output
format.url output
new.block
note output
format.isbn output
fin.entry
}
@ -826,17 +815,20 @@ FUNCTION {booklet}
{ output.bibitem
format.authors output
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.title "title" output.check
howpublished address new.block.checkb
howpublished output
address output
format.date output
%format.date output %% commented by AK
format.isbn output
format.doi output
format.url output
new.block
note output
format.isbn output
fin.entry
}
@ -853,6 +845,9 @@ FUNCTION {inbook}
if$
}
if$
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.btitle "title" output.check
crossref missing$
@ -870,12 +865,12 @@ FUNCTION {inbook}
}
if$
format.edition output
format.date "year" output.check
%format.date "year" output.check %% commented by AK
format.isbn output
format.doi output
format.url output
new.block
note output
format.isbn output
fin.entry
}
@ -883,6 +878,9 @@ FUNCTION {incollection}
{ output.bibitem
format.authors "author" output.check
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.title "title" output.check
new.block
@ -890,24 +888,21 @@ FUNCTION {incollection}
{ format.in.ed.booktitle "booktitle" output.check
format.bvolume output
format.number.series output
format.chapter.pages output
new.sentence
address ": " * publisher * % CHANGE mudrd8mz 2005-10-12
"publisher" output.check
%publisher "publisher" output.check
%address output
publisher "publisher" output.check
address output
format.edition output
format.date "year" output.check
new.sentence
format.chapter.pages output
%format.date "year" output.check %% commented by AK
}
{ format.incoll.inproc.crossref output.nonnull
format.chapter.pages output
}
if$
format.isbn output
format.doi output
format.url output
new.block
format.isbn output
note output
fin.entry
}
@ -916,6 +911,9 @@ FUNCTION {inproceedings}
{ output.bibitem
format.authors "author" output.check
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.title "title" output.check
new.block
@ -928,7 +926,7 @@ FUNCTION {inproceedings}
{ organization publisher new.sentence.checkb
organization output
publisher output
format.date "year" output.check
%format.date "year" output.check %% commented by AK
}
{ address output.nonnull
format.date "year" output.check
@ -942,10 +940,10 @@ FUNCTION {inproceedings}
format.pages output
}
if$
format.isbn output
format.doi output
format.url output
new.block
format.isbn output
note output
fin.entry
}
@ -956,13 +954,16 @@ FUNCTION {manual}
{ output.bibitem
format.authors output
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.btitle "title" output.check
organization address new.block.checkb
organization output
address output
format.edition output
format.date output
%format.date output %% added by AK
format.url output
new.block
note output
@ -973,13 +974,16 @@ FUNCTION {mastersthesis}
{ output.bibitem
format.authors "author" output.check
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.title "title" output.check
new.block
"Master's thesis" format.thesis.type output.nonnull
school "school" output.check
address output
format.date "year" output.check
%format.date "year" output.check %% added by AK
format.url output
new.block
note output
@ -990,11 +994,15 @@ FUNCTION {misc}
{ output.bibitem
format.authors output
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block %% added by AK
title howpublished new.block.checkb
format.title output
howpublished new.block.checka
howpublished output
format.date output
%format.date output %% commented by AK
format.issn output
format.url output
new.block
@ -1007,13 +1015,16 @@ FUNCTION {phdthesis}
{ output.bibitem
format.authors "author" output.check
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.btitle "title" output.check
new.block
"PhD thesis" format.thesis.type output.nonnull
school "school" output.check
address output
format.date "year" output.check
%format.date "year" output.check %% commented by AK
format.url output
new.block
note output
@ -1024,19 +1035,22 @@ FUNCTION {proceedings}
{ output.bibitem
format.editors output
editor format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.btitle "title" output.check
format.bvolume output
format.number.series output
address output
format.date "year" output.check
%format.date "year" output.check %% commented by AK
new.sentence
organization output
publisher output
format.isbn output
format.doi output
format.url output
new.block
format.isbn output
note output
fin.entry
}
@ -1045,13 +1059,16 @@ FUNCTION {techreport}
{ output.bibitem
format.authors "author" output.check
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.title "title" output.check
new.block
format.tr.number output.nonnull
institution "institution" output.check
address output
format.date "year" output.check
%format.date "year" output.check %% commented by AK
format.url output
new.block
note output
@ -1062,12 +1079,15 @@ FUNCTION {unpublished}
{ output.bibitem
format.authors "author" output.check
author format.key output
new.block %% added by AK
%format.date "year" output.check %% added by AK, commented later on
output.year.check %% added by AK as replacement of format.date
new.block
format.title "title" output.check
format.url output
new.block
note "note" output.check
format.date output
%format.date output %% commented by AK
format.url output
fin.entry
}
@ -1165,12 +1185,12 @@ FUNCTION {format.lab.names}
s #1 "{vv~}{ll}" format.name$
s num.names$ duplicate$
#2 >
{ pop$ " et~al." * }
{ pop$ " a~kol." * } %% originally et~al.
{ #2 <
'skip$
{ s #2 "{ff }{vv }{ll}{ jj}" format.name$ "others" =
{ " et~al." * }
{ " -- " * s #2 "{vv~}{ll}" format.name$ * } % CHANGE mudrd8mz 2005-10-12: changed "and"
{ " a~kol." * } %% AK change
{ " a " * s #2 "{vv~}{ll}" format.name$ * } %% AK change
if$
}
if$
@ -1393,6 +1413,10 @@ FUNCTION {presort}
if$
" "
*
year field.or.null sortify
*
" "
*
cite$
*
#1 entry.max$ substring$

@ -1 +0,0 @@
<mxfile host="app.diagrams.net" modified="2020-04-26T15:32:20.875Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36" etag="XFr7jOKMDi_xrn2ql5_A" version="13.0.1" type="device"><diagram id="C5RBs43oDa-KdzZeNtuy" name="Page-1">7VxLd5s4FP41LJuDJIRh6Thpp49JM02mma7mECPbxIA8GCd2f/1IvJGwsbGBNHU2QVfSRVx99yklChp56w+BtZj9SW3iKlC11wq6UiAEKjLYL07ZxBTT0GPCNHDsZFBOuHN+knRmQl05NlmWBoaUuqGzKBPH1PfJOCzRrCCgL+VhE+qW37qwpkQi3I0tV6Y+OHY4i6kGHOT0P4gznaVvBroZ93hWOjj5kuXMsulLgYSuFTQKKA3jJ289Ii4XXiqXh4+bB/fLXP/w6a/lf9bfl5/vb76/i5m9P2RK9gkB8cPGrI13TwBZk4+6NoSrqeOpD8tFMkV9ttxVIq+7++G3++SDw00qRcaKbRhrXL7MnJDcLawx73lhmGG0Wei5rAXYY8KPBCFZCxtQs3qQiZRhkVCPhMGGzUu5mIMLHHNKgKgna3/Jd9VMSLPChmoJzUpwNM1Y57JiD4m4DhAdkETnsGb0pLKOkS8JkQFowR9nZG1Nqc+ktSCBw1ZDgpx6m5JgvbCXsbapFwC2KnpVED3QZNkDFcvCR20JH0rClyHr20NuP1hr7FrLpTMuC4+snfCfSHo4af0o9Fzxj1fTxiZt+GzxhUm8+aPYl0+LWum8eHHElkzVPhvDvoqugjGpV+PQCqYkrMOsvNGFbcQVKpTSAuJaofNc/oaqrU3ecEsd9nUZjgaiBgNRN+PvTKYVTZnACUCRlSlwiiUhcYqwln14c/gNJPg9ZbqvvjHdL8k5c4a9ab5x1vwKL1Sr+YM+NR9iKKo+bKj6Faxwt7pvngFYYQrrXU/PCDRLoEFGU/xpqGwQO/Y8QA4752/T9Wi64HpSN9Ob6wFy1Pl9s3CUEVaGgH8wDak3txSou2wpl48Be5rypyXn7NtkTTz2xPfrJ/9NfSaycMU7t24aE6LlusSl08DyhK0r9d3mHbX7FwZ0nmXDnBLQFVuenZiMLNHljTH1uPmKOxhLx5/e00WZwFowb30hE74Tek75lmyOXgYPhgNT19i+GkDHGLeJpZRPiiW9AksGkrHUXvaIzm6kyq7V+xHYpx/BqGyU9IZuBBtlPqBjL6L1jb4S9nIo9oU+uC/6es2gT4U+ybXuCT+GB2tTGLbgA5Y71gvKwRLS1N3rUtWjxqfZaa4t8YpPqztY0p3PX2+uR7IC9V0zFY1MJq7eSqZy3aQcQAXPhEdH5XjpSQ6ozuHThWpC3QR6dESDDN1otfiOjbKeGTKQwKBTJMlloE9kF4JUGUTWnJliXxkhZXiVT2XrUX3ySDmFA9M04xEe/3V55eV0Ys8j7kU+Mxpzmq8U9F5CZTCj3uNqWQ+xfQElIXHiuO6IujSIXogm0Q+jM4jbDoNA2udTn0iQAxWYK9IuacgSHEZsM1QHSCv7ACxjDabbX8QaaC/vO5d8Ks14fbRk9Bktnazmg1SBkYi0lqN1KNd8GuMPFNCXY/HXitb3ht9vjb5Dg3WEyu9hlnf3uoTx6VHR1kM77cjxuLSedoL7VLP6U7VXZur3VbVedU0zBBVperCMRR3Ys7p/bGLcDbb1E4Yxb8CNpEHk6z47/eWwDUD5PRrY7UfE8YLfaUkX5ErEzbWsDQx7X6xH4paVwHKdqc81hOEwKhjwLMgZW+4w6fAc2+Y8LgPC8nXrMeLHIZ3IjjHHlwq+2pVGJfchk8lKdvGiCP8dar41v3rHFG+Ay0foqco0hWo6hE4mS9JOCCzn+7dxFu7YhKf3YTFXt1dZFl5zFvck7fm5ctTA2m5FGxKCOK3q5mCnlSMoJ/PDm6+HO8KGAVuT4PDVOEK4JZ/PTYsG0+vh3XhHZAr4anqvqCvvqAnlLcE7lr1dlxY2zSq7LnK1De5tmP3FojcpqhKB3hI+sVqTpQvrEsa3E72hwy5PJMVu21rOIlcLqo7fGiKwL2AB4egzc6IHA6uO0anSAuE9GO4GFtaOG49qyktIP248qFmPJNcuzqa1U1SK31Jks3f9CvepzEg4qIdNlVkTLojAlryEDnHle9oFN/ztrf7JgFLL6FSHCsJ70GC31dTxceOBUWPFxXt3RhfAlcOVD8QnAX2OyhUgu4Mg1iryiwbRFRn5QoFcUChWG5JKhree8j/tvZi49GU8s4LwwvJ9GjIcUv/fYj3LjeoHcZGKBNfPJK5VHVCnaHb9QNlWxUjEdvqqhBCVV11nAbISt1aT0A67jllj2ZrW26NWoZp1Cg9d63hj3ejNnsLqIO1wx6t143ilBXeRbmnyjcc97Vf0BxFn23VK24XNcoIOQIXx6rKgqh12rPimjFevWQPeEvu82qxBWjA6ynixZv7PN+Lh+b8wQdf/Aw==</diagram></mxfile>

@ -1,50 +1,46 @@
\chapter{Staticky generované webové stránky}
\chapter{Staticky generovaný web}
Princip statické webové stránky sahá ke vzniku WWW, kdy existovaly pouze stránky statické, tedy stránky nevytvářené dynamicky na základě různých proměnných a na uživatelském vstupu. U~statických webových stránek dochází k~vytvoření HTML kódu ve chvíli, kdy je změněn zdrojový obsah nebo kdy autor ručně spustí generátor. \citep{pcmag_static}
Princip statické webové stránky sahá ke vzniku WWW, kdy existovaly pouze stránky statické, tedy stejné pro každého uživatele. Jejich obsah může být průběžně aktualizován, ovšem negenerují se zvlášť pro každého uživatele na základě různých proměnných. U statických webů tedy dochází k vytvoření čístého HTML ve chvíli, kdy je změněn zdrojový obsah, nebo kdy autor ručně spustí generátor. \citep{pcmag_static}
Dynamické stránky jsou generovány speciálně pro každého uživatele na základě jeho nastavení, různých vstupů, proměnných a dalších vlastností ovlivňujících výslednou podobu či obsah stránky. Ke generování dochází ve chvíli, kdy si uživatel stránku vyžádá, nikoliv předem, jako je tomu u~staticky generovaných stránek. \citep{pcmag_dynamic}
Dynamické stránky jsou generovány speciálně pro každého uživatele na základě jeho nastavení, různých vstpů, proměnných a dalších vlastností. Ke generování dochází ve chvíli, kdy si uživatel stránku vyžádá, nikoliv předem, jako je tomu u staticky generovaných stránek. \citep{pcmag_dynamic}
\section{Výhody statických webových stránek}\label{kap:vyhody-statickych-webovych-stranek}
Pro sdílení statického obsahu mezi různé uživatele stačí velmi jednoduchý HTTP\footnote{Hypertext Transfer Protocol -- Internetový protokol sloužící ke komunikaci s~WWW servery.} server bez jakýchkoliv dalších modulů typu \textit{PHP}, \textit{Python} a dalších systémů\footnote{Jedná se o~programovací jazyky nejčasteji používané ke tvorbě dynamických webových aplikací.}, které by obsah dynamicky generovaly například z~dat přečtených z~databáze nebo z~uživatelského vstupu. Na straně serveru tedy nedochází ke zpracování obsahu těsně před jeho odesláním uživateli, čímž se v~komunikaci mezi klientem a serverem výrazně snižuje \uv{Time To First Byte\footnote{Time To First Byte -- Čas mezi odesláním požadavku a přijmutím prvního bajtu dat.}}, a tím dochází ke snížení celkové latence. \citep{mozttfb}
Pro sdílení statického obsahu mezi různé uživatele stačí velmi jednoduchý HTTP server bez jakýchkoliv dalších modulů typu \textit{PHP}, \textit{Pythnon} a dalších systémů, které by obsah dynamicky generovaly například z dat vytažených z databáze, nebo z uživatelského vstupu. Na straně serveru tedy nedochází ke zpracování obsahu těsně před jeho odesláním uživateli, čímž se v komunikaci mezi klientem a serverem se drasticky snižuje \uv{Time To Firt Byte}\footnote{Time To First Byte --- čas mezi odesláním požadavku a přijmutím prvního bajtu dat.} a tím dochází ke snížení celkové latence. \citep{mozttfb}
Snížení latence může pozitivně přispět ke spokojenosti uživatelů, což dokazuje nespočet výzkumů na toto téma, například analýza z~webového portálu Financial Times, kde se uvádí, že rychlost webové stránky negativně ovlivňuje hloubku jejího užívání, ať už je odezva sebemenší. Jak je zde rovněž uvedeno, data ukazují, že z~pohledu uživatelské spokojenosti a finančního dopadu existují jasné a důležité výhody při zrychlení webové stránky. Z~tohoto výzkumu se autoři rozhodli v~měsících po vydání analýzy investovat více času do úprav všech aspektů svých nových webových stránek s~cílem jejich zrychlení. \citep{financialtimes}
Snížení samotné latence může pozitivně přispět ke spokojenosti uživatelů, což dokazuje nespočet výzkumů na toto téma, například analýza z webového portálu Financial Times, kde se uvádí, že rychlost webové stránky negativně ovlivňuje hloubku jejího užívání, ať už je odezva sebemenší. Jak je zde rovněž uvedeno, data ukazují, že pohledu uživatelské spokojenosti a finančního dopadu existují jasné a důležité výhody při zrychlení webové stránky. Z tohoto výzkumu se autoři rozhodli v následujících měsících od vydání analýzy zainvestovat více času do úprav všech aspektů jejich nové stránky FT.com s cílem jejího zrychlení.\todo{Nechat opravit překlad}
Eliminováním dynamického obsahu se také předchází nevyžádaným vstupům od uživatele, jež mohou být i cílené na prolomení bezpečnostních nedostatků webové aplikace a v~některých případech mohou vést k~úniku citlivých dat, převzetí kontroly útočníka nad webovou aplikací nebo celým serverem, podstrčení falešných dat uživateli a mnoha dalším běžným útokům. Statický web eliminuje tento problém, jelikož nemá žádný uživatelský vstup.
Eliminováním dynamického obsahu se také předchází nevyžádaným vstupům od uživatele, které mohou být i cílené na prolomení bezpečnostních nedostatků webové aplikace a v některých případech mohou vést k úniku citlivých dat, převzetí kontroly útočníka nad webovou aplikací nebo celým serverem, podstrčení falešných dat uživateli a mnoho dalším běžně se stávajícím útokům. Statický web eliminuje tento problém, jelikož nemá žádný uživatelský vstup.
Sledování a analýze nejčastějších chyb webových aplikací a serverů se věnuje organizace OWASP\footnote{The Open Web Application Security Project (\url{https://owasp.org/}).}, která vydává aktualizované seznamy a statistiky. Podle \cite{owasp2017} se v~roce 2017 objevovaly nejčastěji tyto chyby a bezpečnostní nedostatky:
Sledování a analýze nejčastějších chyb webových aplikací a serverů se věnuje organizace OWASP\footnote{The Open Web Application Security Project --- \url{https://owasp.org/}.}, která vydává aktualizované seznamy a statistiky. Podle OWASP byly v roce 2017 nejčastější tyto chyby a bezpečnostní nedostatky:
\begin{enumerate}
\item injekce,
\item rozbitá autentizace,
\item odhalení citlivých dat,
\item XML External Entities (XXE),
\item nefunkční řízení přístupu,
\item špatná konfigurace zabezpečení,
\item Cross-Site Scripting (XSS),
\item nezabezpečená deserializace,
\item užívání komponent se známými zranitelnostmi,
\item nedostatečné logování a monitorování.
\item{Injekce}
\item{Rozbitá autentizace}
\item{Odhalení citlivých dat}
\item{XML External Entities (XXE)}
\item{Nefunkční řízení přístupu}
\item{Špatná konfigurace zabezpečení}
\item{Cross-Site Scripting (XSS)}
\item{Nezabezpečná deserializace}
\item{Uživání komponent se známými zranitelnostmi}
\item{Nedostatečné logování a monitorování}
\end{enumerate}
Většina těchto chyb se vztahuje právě k~dynamickým webovým aplikacím. Bezpečnost tedy závisí nejen na programátorovi, jenž aplikaci vytváří, ale také na tom, že programovací jazyk je bezpečně implementován. To nelze tvrdit o~nejpoužívanějším jazyce PHP, který obsahuje mnoho chyb, viz statistika nalezených bezpečnostních děr na serveru \cite{cve_php}, který se tímto tématem zabývá. Jazyk zároveň nevede programátora k~psaní bezpečného kódu, což má za následek nebezpečené aplikace, pokud si autor nedá pozor na správné ošetření vstupů a dalších bezpečnostních aspektů programu.
\citep{owasp2017}
Podstatným příkladem chybovosti dynamických webů je systém Wordpress, v~němž jsou podle serveru \cite{cve_wordpress} každý rok nalezeny desítky bezpečnostních chyb, přičemž mnoho dalších přibývá s~instalací nezabezpečených rozšíření. Napří\-klad na začátku roku 2020 byla nalezena bezpečnostní chyba v~rozšíření využívaném na více než dvě stě tisících webových stránkách, která útočníkům umožňovala smazat obsah databáze \citep{thehackernews_wordpress_1}. Na konci roku 2019 umožnila chyba ve dvou neza\-bezpečených rozšířeních neautorizované přihlášení k~účtu administrátora bez použití hesla \citep{thehackernews_wordpress_2}.
Většina těchto chyb se vztahuje právě k dynamickým webovým aplikacím. Bezpečnost tedy závisí nejen na programátorovi který aplikaci vytváří, ale také na tom, že programovací jazyk je bezpečně implementován. To nelze tvrdit o nejpoužívanějším jazyce PHP, který nejen že obsahuje spousty chyb, viz. seznam nalezených bezpečnostních děr \citep{cve_php}, ale zároveň nevede programátora ke psaní bezpečného kódu a ve výsledku vzniká nebezpečná aplikace, pokud si autor nedá pozor na správné ošetření vstupů a další bezpečnostní aspekty programu.
Údržba velkých webových aplikací je často problematická. Kód je nutné udržovat v~návaznosti na aktualizace daného jazyka, databázového systému a dalších aspektů. Těmto aktualizacím se z~bezpečnostních důvodů nelze vyhýbat. Statický web nemusí udržovat funkční propojení s~databázemi a dalšími částmi systému, a je tedy mnohem méně náročný na dlouhodobou údržbu. Při zvolení správného generátoru není nutná ani údržba šablon a celý systém při zachování stejného prostředí nepřestane fungovat. Protože statický generátor nepracuje s~uživatelským vstupem, vyhýbá se bezpečnostním chybám a tím i nutným aktualizacím.
Skvělým příkladem chybovosti dynamických webů je systém Wordpress, ve kterém jsou každý rok nalezeny desítky bezpečnostních chyb \citep{cve_wordpress}, přičemž mnoho dalších přibývá s instalací špatně napsanách rozšíření. Například na začátku roku 2020 byla nalezena bezpečnostní chyba v rozšíření, které bylo využíváno na více než dvě stě tisících webových stránkách a potencionálním útočníkům umožnila smazat obsah databáze \citep{thehackernews_wordpress_1}. Na konci roku 2019 umožnila chyba ve dvou nezabezpečených rozšířeních neautorizované přihlášní k účtu administrátora bez použití hesla \citep{thehackernews_wordpress_2}.
Jako každý jiný systém, i statické generátory mají své nevýhody. Hlavním z~problémů je, že tvorba a správa obsahu může být pro běžného uživatele náročnější než skrze klasické webové rozhraní s~administračním panelem a jednoduchou správou celého obsahu. Pro přidání nebo úpravu obsahu je nutné pracovat s~lokálními soubory ve stromové struktuře a při generování je často potřebný zásah do shellu\footnote{Program pro interpretování příkazů v~prostředí příkazové řádky.}. Tvorba systému pro automatizované generování je také náročnější než instalace některého z~běžných CMS\footnote{Systém pro správu a obsahu (Wordpress, Joomla, Drupal a podobně).}. \citep{softpedia_generators}
Údržba velkých webových aplikací je také často problematická. Kód je nutné udržovat v návaznosti na aktualizace daného jazyka, databázového systému a dalších věcí. Těmto aktualizacím se z bezpečnostních důvodů nelze vyhýbat. Statický web nemusí udržovat funkční propojení s databázemi a různými frameworky\todo{Lepši slovo?} a je tedy mnohem méně náročný na dlouhodobou údržbu. Při zvolení správného generátoru není nutná ani údržba šablon a celý systém při zachování stejného prostředí nepřestane fungovat. Protože statický generátor nepracuje s uživatelským vstupem, vyhýbá se bezpečnostním chybám a tím i nutným aktualizacím.\todo{Zdroj?}
\section{Princip generátorů}\label{kap:princip-generatoru}
Jako každý jiný systém, i statické generátory mají své nevýhody. Hlavním z problémů je to, že správa statického generátoru a tvorba obsahu je náročnější, než klasické webové rozhraní s administračním panelem, různými uživateli a jednoduchou správou pro běžné technicky nenadané uživatele. Pro přidání nebo úpravu obsahu je nutné pracovat s lokálními soubory ve stromové struktuře a při generování je často potřebný zásah do shellu\footnote{Program pro interpretování příkazů v prostředí příkazové řádky.}. Tvorba systému pro automatizované generování je také náročnější než instalace některého z běžných CMS\footnote{Content Management System}. \citep{softpedia_generators}
Ekosystém generátoru statického obsahu je tvořen ze tří hlavních složek.
\section{Princip generátorů}
První částí jsou soubory šablon, jež popisují rozložení stránky, vizuální vlastnosti, typografii, ale také vstupní a výstupní kódování a formáty. V~podstatě definují, jak a kam se bude obsah vkládat.
Generátor statického obsahu je tvořen ze tří hlavních částí. První částí jsou soubory šablon, které popisují rozložení stránky, vizuální vlastnosti, typografii, ale také vstupní a výstupní kódování a formáty. V podstatě definují jak a kam se bude obsah vkládat. Druhou částí je obsah obecně psaný v některém ze značkovacích jazyků, nejčastěji v jazyce Markdown. Obsah je strukturován do vlastních sekcí a souborů, aby bylo snadné rozlišit, do které části výsledné stránky patří. Třetí a poslední částí je samotné jádro generátoru, které zpracovává obsah, vkládá ho do šablon a renderuje statickou webovou stránku.
Druhou částí je obsah samotný, napsaný v~některém ze značkovacích jazyků, jež jsou dále popsány v~kapitole \ref{kap:znackovaci-jazyky}. Obsah bývá strukturován do sekcí a souborů, aby bylo snadné rozlišit, do které části výsledné stránky patří.
Třetí a poslední složkou je samotné jádro generátoru, jež zpracovává obsah, vkládá ho do šablon a generuje statickou webovou stránku.
Většina generátorů zároveň umí pracovat s~konfiguračními soubory, pomocí nichž lze nastavit globální chování generátoru. Část z~nich také integruje jednoduchý webserver, který umožňuje autorovi náhled výstupních stránek, zatím co tvoří obsah.
Většina generátorů zároveň umí pracovat s konfiguračními soubory, kterými jde nastavit chování generátoru na jednom centralizovaném místě. Část z nich má také integrovaný jednoduchý web server, který umožňuje autorovi náhled výstupních stránek během tvorby obsahu.
\citep{softpedia_generators}

@ -1,72 +1,56 @@
\chapter{Značkovací jazyky}\label{kap:znackovaci-jazyky}
Tato kapitola se zabývá analýzou nejběžnějších jazyků pro popis obsahu používaných ve statických generátorech z~předchozí kapitoly, dalším důležitým jazykům ze světa sázení a jejich pricipům.
\chapter{Značkovací jazyky pro popis obsahu}
\section{Principy značkovacích jazyků}
Definici konceptu značkovacích jazyků nebo-li \uv{markup jazyků}, můžeme najít napří\-klad v~RFC 7764\footnote{Jako \textit{RFC} se označují standardy vydané organizací IETF (Internet Engineering Task Force).}, tedy, že v~počítačových systémech jsou kontextuální data ukládána a zpracována několika technikami. Informaci lze kódovat jako čistý text bez speciálních formátovacích znaků. Tento přístup je jednoduchý pro implementaci i použití, ovšem neumožňuje složitější formátování textu.
Vysvětlení principu značkovacích jazyků, nebo také takzvaně \uv{makrup jazyků}, můžeme najít například v RFC 7764\footnote{Jako \textit{RFC} se označují standardy vydané organizací IETF (Internet Engineering Task Force).}, tedy že v počítačových systémech jsou kontextuální data ukládána a zpracována několika technikami. Informaci lze kódovat jako čistý text bez speciálních formátovacích znaků. Tento přístup je jednoduchý pro implementaci i použití, ovšem neumožňuje složitější formátování textu.
Kódovat můžeme i do binárních formátů určených ke zpracování a interpretaci specia\-lizovanými programy, jimiž mohou být například LibreOffice Writer, či proprietární software\footnote{Software nerespektující základní svobody uživatele, které jsou popsány na adrese \url{https://www.gnu.org/philosophy/free-sw.html}} Microsoft Word. Zřejmou nevýhodou je to, že zdroj není čitelný bez programu určeného pro jeho interpretaci.
Kódovat lze můžeme i do binárních dat určených ke zpracování a interpretaci specializovaným programem. Zřejmou nevýhodou je to, že zdroj není čitelný bez programu určeného pro jeho interpretaci.
Markup jazyky se snaží o~spojení nejlepšího z~obou světů, tedy o~obsah s~možností formátování, který je jednoduše čitelný jak pro člověka, tak pro stroj. Toho je dosaženo tím, že v~je v~běžných textových souborech přiřazen vybraným znakům speciální význam. Uživatel je schopen tyto znaky psát bez potřeby speciálních nástrojů, a tím jednoduše tento speciální význam vyjádřit. Například v~rámci jazyka Markdown, jenž je popsán v~následujích sekcích, se význam znaku \texttt{\#} na začátku řádku mění z~běžného křížku na definování nadpisu první úrovně. \citep{rfc7764}
Markup jazyky se snaží o spojení toho nejlepšího z obou světů, tedy o obsah čitelný v čistém textu s možností formátování. To je dosaženo tím, že běžným znakům jsou přiděleny speciální významy nedefinované původní znakovou sadou. Uživatel je schopen tyto znaky psát jako čistý text a vyjádřit tím speciální význam. Například v rámci jazyka Markdown se znak \texttt{\#} změní z běžného křížku na definování nadpisu první úrovně, nebo také kombinace znaků \texttt{<p>} značí začátek odstavce v HTML. \citep{rfc7764}
\section{Nejběžnější jazyky}
V~současnosti existuje nespočet značkovacích jazyků, z~nichž nejčastěji používaným je nepochybně HTML, ovšem tato práce se věnuje těm nejpoužívanějším jazykům, jež mají uživateli usnadnit psaní a sázení obsahu. Uživatel se tedy nemusí při jeho tvorbě nutně zabývat typografií a formátováním obsahu, což jsou aspekty, o~které se později stará generátor pomocí šablon. U~HTML je tomu naopak, uživatel řeší samotný obsah i formátování v~jednu chvíli skrze různé druhy formátovacích tagů. O~vyplňování obsahu do HTML se v~případě staticky generovaných webových stránek stará právě samotný generátor.
Vybrané jazyky jsou zároveň cílené na čitelnost samotného zdrojového obsahu v~čistém textu bez nutnosti jeho interpretace speciálním prostředím či zpracováním do jiných formátů, jimiž mohou být PDF, DjVu, PostScript apod. Například podtržení textu je v~nějakém pseudo-jazyce reprezentováno opravdovým podtržením pomocí rovnítek, viz příklad \ref{lst:pseudo-jazyk}, nikoliv obalením nadpisu ve speciální deklaraci, jako je tomu právě u~jazyka HTML. Podtržení je poté pro čtenáře mnohem jasnější, jelikož nemusí přemýšlet, co v~kontextu HTML daný tag znamená, kdežto podtržení z~kontextu souboru vyplývá.
\begin{lstlisting}[label=lst:pseudo-jazyk,caption=Příklad podtržení nadpisu ve značkovacím pseudo-jazyce]
Nadpis
======
\end{lstlisting}
Následující jazyky byly vybrány základě jejich výskytu u~generátorů vybraných v~předchozí kapitole a také podle aktuálních statistik ze serveru \cite{slant}, který se věnuje obecnému určení oblíbenosti na základě hodnocení ze strany uživatelů.
Ke dnešnímu dni vnikl nespočet značkovacích jazyků. Nejpoužívanějším z nich jednoznačně HTML, ovšem tato práce se věnuje těm nejpoužívanějším jazykům, které mají uživateli usnadnit psaní a sázení obsahu. Uživatel tedy nemusí nutně řešit typografii a formátování obsahu při jeho psaní, tedy o věci, o které se později stará generátor pomocí šablon. U HTML je tomu naopak, kdy uživatel řeší samotný obsah i formátování v jednu chvíli skrze různé druhy formátovacích tagů. O vyplňování obsahu do HTML se v případě staticky generovaných webů stará právě samotný generátor.
\subsection{\TeX}\label{kap:tex}
Vybrané jazyky jsou zároveň cílené na čitelnost samotného zdrojového obsahu v čistém textu bez nutnosti jeho interpretace speciálním prostředím či zpracováním do jiného formátu, například do PDF, DjVu, PostScript apod. Například podtržení textu je v nějakém pseudo-jazyce reprezentováno opravdovým podtržením pomocí spojovníků, nikoliv obalením nadpisu ve speciální deklaraci, jako je tomu například u HTML. Podtržení je poté pro čtenáře mnohem jasnější, jelikož nemusí přemýšlet, co v případě HTML daný tag vůbec způsobuje, ale podtržený vyplývá z kontextu.
Tento jazyk se vzdaluje od původního konceptu čitelnosti zdroje, ovšem ve statických generátorech ho lze stále efektivně využít. Je jedním z~nejrozšířenějších sázecích jazyků se spoustou možností a funkcionalit, z~nichž velmi zajímavým rozšířením je prostředí pro psaní matematických formulí, díky němuž se jazyk stal velmi populárním v~oblasti technických publikací. Tyto funkcionality se často objevují i v~jiných jazycích a jsou efektivně využívány pro jejich rozšíření.
Většina uživatelů se setkala spíše s~jazykem \LaTeX, tedy s~nadstavbou původního \TeX{}u, která má uživateli zjednodušit práci svými makry a rozšířeními. Realita je ovšem taková, že \LaTeX{} dělá celou práci složitější, jak popisuje RNDr. Olšák:
\begin{quote}
Představte si, že si nějaký uživatel přečte \LaTeX{}ovou příručku a nabude doj\-mu, že mu bude stačit rozumět problematice sazby na úrovni této příručky. Pak se jednou překlepne třeba při sestavování tabulky a na terminálu na něj \TeX{} křičí: {\tt Extra alignment tab has been changed to "\verb|\cr|".} Uživatel začne znovu listovat ve své příručce a zjistí, že tam o~žádném "\verb|\cr|"{} není jediná zmínka. Má pak tři možnosti: (1)~Zmáčkne Enter a podobně se zachová i u~dalších chyb. Pomyslí si, že ten \LaTeX{} je něco tajemného a mys\-tického. (2)~Propadne zoufalství a jde od toho. Dojde k~závěru, ľe je lepší zůstat u~Wordu. Vždyť stačí vzít tabulku v~Excelu a jednoduše ji přemístit do Wordu a jaképak smolení se s~nějakým podezřelým "\verb|\cr|". (3)~Pořídí si \TeX{}book a po intenzivním studiu nakonec řekne: \uv{aha}. V~tuto chvíli ale už nepotřebuje, aby mu \LaTeX{} zakrýval složitost \TeX{}u. \citep{nolatex}
\end{quote}
Seznam nejoblíbenějších jazyků je sestaven podle aktuálních statistik ze serveru Slant, který se věnuje obecnému určení oblíbenosti na základě hodnocení ze strany uživatelů. \citep{slant}
Ve výsledku je tedy lepší, z~různých důvodů popsaných RNDr. Olšákem v~jeho publikaci, použít samotný plain \TeX{} na úkor vyšší vstupní úrovně pro používání jazyka.
\subsection{Markdown}
\subsection{Troff}
Vznik jazyka Markdown byl 14. prosince roku 2014, když John Gruber vydal jeho první popis syntaxe a referenční implementaci.
Troff je jedním z~nejstarších jazyků a předchůdcem jazyka \TeX. Autorem původní verze je Joe Ossanna, po jehož smrti převzal vývoj Brian Kernighan. Samotný Troff je reimplementací a rozšířením původního programu RUNOFF z~operačního systému CTSS. Vznikl za účelem sazby dokumentů na novém operačním systému Unix. \citep{ossanna1977troff}
Hlavním z cílů syntaxe jazyka je vytvářet co možná nejčitelnější obsah v syrové podobě. Dokument psaný v Markdownu by měl být publikovatelný sám o sobě jako čistý text bez dalších úprav a zpracování. Jazyk byl ovlivněn několika již existujícími specifikacemi jiných jazyků, ovšem největším zdrojem inspirace pro jeho vznik jsou čisté emailové korespondence. \citep{daringfireball}
Dnes existuje celá řada různých implementací a modernizovaných rozšíření, například Groff\footnote{\url{https://www.gnu.org/software/groff/}}, Heirloom troff\footnote{\url{http://heirloom.sourceforge.net/doctools.html}}, nebo moderní Neatroff\footnote{\url{https://repo.or.cz/neatroff.git/}}, který se snaží o~spojení toho nejlepšího ze všech předchozích implementací. Sám Brian Kernighan v~soukromé emailové konverzaci doporučuje použití některé alternativní implementace, jež jsou podle Keringhana lepší ve všech směrech.
První specifikaci Gruber vydal společně s referenční implementací v jazyce Perl, která slouží pro konverzi Markdownu do HTML. Program také nese stejný název \uv{Markdown}, ovšem mluvíme-li o \uv{Markdownu}, máme nejčastěji na mysli samotnou syntaxi. Ta je dnes již implementována v mnoha různých jazycích a programech. Gruberova specifikace ovšem není formální standard, kvůli čemuž vznikl veliký počet alternativních a více čí méně pozměněných implementací, které nemusí být navzájem kompatibilní. Nejčastějšími z nich jsou například Github Markdown, CommonMark, R Markdown a mnoho dalších. \citep{commonmark}
I~přes vznik mnoha alternativních jazyků, například dříve zmíněného \TeX{}u a \LaTeX{}u, je Troff (Groff) stále hojně využíván v~praxi, zejména u~softwarové dokumentace v~Unixových operačních systémech.
Nevyužívanější formální specifikací je právě CommonMark, který slouží jako pevný základ většiny rozšíření. \citep{github_formal_markdown_spec}.
\subsection{Markdown}\label{kap:markdown}
Podobně jako je tomu u specifikací, existuje velké množství programů, které tyto různé specifikace překládají. Švýcarským nožem mezi nimi je program Pandoc \footnote{\url{https://pandoc.org/}}, který umí překládat Markdown do enormního výběru jiných formátů, nebo z jiných formátů zpět. Tato funkcionalita se nezvtahuje pouze na jazyk Markdown, ovšem Pandoc dokáže operovat mezi všemy podporovanými formáty, například dokáže konvertovat obsah z HTML do \TeX{}u. Na druhou stranu existují i velmi jednoduché překladače, například program smu\footnote{\url{https://github.com/Gottox/smu}}, který umí překládat Markdown do HTML nebo čistého textu a neobsahuje více než 600 SLOC\footnote{Source lines of code}, tedy řádků kódu hlavního programu.
Jazyk Markdown vznikl 19. března roku 2004, když John Gruber vydal první popis syntaxe a referenční implementaci.
\subsection{Org-mode}
Hlavním z~cílů syntaxe jazyka je vytvářet co možná nejčitelnější obsah podobě čistého textu. Dokument psaný v~Markdownu by měl být publikovatelný jako textový soubor bez dalších úprav a zpracování. Jazyk byl ovlivněn několika již existujícími specifikacemi jiných jazyků, ovšem největším zdrojem inspirace pro jeho vznik jsou čisté e-mailové korespondence\footnote{E-mail, který není formátován pomocí HTML.}. \citep{daringfireball}
... \citep{environment_for_literate_programming} \citep{orgmanual}
První specifikaci Gruber vydal společně s~referenční implementací v~jazyce Perl, která prováděla konverzi zdrojového souboru popsaného v~jazyce Markdown do HTML. Tento program je také pojmenován \textit{Markdown}, ovšem mluvíme-li o~\textit{Markdownu}, máme nej\-častěji na mysli samotnou syntaxi. Ta má dnes mnoho implementací v~různých programovacích jazycích. Gruberova specifikace ovšem není formálním standardem, kvůli čemuž vznikl veliký počet alternativních a více či méně pozměněných implementací, jež nemusí být navzájem kompatibilní. Nejčastějšími z~nich jsou například Github Markdown, CommonMark, RMarkdown a mnoho dalších. \citep{commonmark}
\subsection{AsciiDoc}
Nevyužívanější formální specifikací je právě CommonMark\footnote{\url{https://commonmark.org/}}, jenž slouží jako pevný základ většiny rozšíření. \citep{github_formal_markdown_spec}
...
Podobně, jako je tomu u~specifikací, existuje velké množství programů, které tyto různé specifikace překládají. Švýcarským nožem mezi nimi je program Pandoc\footnote{\url{https://pandoc.org/}}, jenž umí překládat Markdown do enormního výběru jiných formátů, nebo z~jiných formátů zpět. Tato funkcionalita se nevztahuje pouze na jazyk Markdown, Pandoc dokáže operovat mezi všemi podporovanými formáty, například dokáže konvertovat obsah z~HTML do \TeX{}u. Na druhou stranu existují i velmi jednoduché překladače, například program smu\footnote{\url{https://github.com/Gottox/smu/}}, který umí překládat Markdown do HTML nebo čistého textu a neobsahuje více než šest set řádků kódu hlavního programu.
\subsection{reStructuredText}
Užitečným rozšířením je, mimo jiné, také integrace matematického prostředí z~jazyka \TeX, viz sekce \ref{kap:tex}.
...
\subsection{Org-mode}
\subsection{\TeX}
Org-mode vznikl jako jeden z~módů pro editor Emacs\footnote{\url{https://www.gnu.org/software/emacs/}}. Funguje podobně jako ostatní markup jazyky, tedy jako jeden centrální systém pro správu obsahu, ze kterého lze vytvářet jiné formáty, například HTML, \LaTeX, Open Document, Markdown, PDF a podobně s~možností přidání libovolného nového backendu. Cílem Org-mode je možnost ho používat i s~minimální úrovní jeho znalosti, ovšem jeho funkcionalita je vždy přístupná. Vše je realizováno pouze na čistých textových souborech, nejlépe přenositelným typem souboru. Editor Emacs je zároveň velmi často portován na různé druhy systémů, a je tedy možné ho využívat v~podstatě kdekoliv. \citep{orgmanual}
Tento jazyk se již vzdaluje od původního konceptu čitelnosti zdroje, ovšem ve statických generátorech ho lze stále efektivně využít a jeho části se velmi často objevují jako rozšíření dříve zmíněných jazyků. Jedním z hlavních rozšíření jsou zápisy matematických rovnic, které z \TeX{}u vychází.\todo{Rozšířit o popis TeXu a matiky.}
Podporuje také \textit{literate programming} a \textit{reproducible research}, tedy, že Org soubory mohou obsahovat plně funkční bloky s~kódem, které lze hodnotit v~rámci systému, a výstup bloků lze automaticky vkládat přímo do dokumentu. \citep{environment_for_literate_programming}
Většina uživatelů se setkala spíše s jazykem \LaTeX, tedy s nadstavbou původního \TeX{}u, která má uživateli zjednodušit práci svými makry a rozšířeními. Realita je ovšem taková, že \LaTeX{} dělá celou práci složitější, jak popisuje doktor Olšák:
Jak popisuje \cite{carsten_dominik} ve svém krátkém technickém popisu, Org-mode umí navrhování, psaní poznámek, hypertextové odkazy, tabulky, seznamy, plánování projektů, GTD, HTML a \LaTeX{}, a to všechno v~čistých textových souborech v~editoru Emacs.
\begin{quote}
Představte si, že si nějaký uživatel přečte \LaTeX{}ovou příručku a nabyde dojmu, že mu bude stačit rozumět problematice sazby na úrovni této příručky. Pak se jednou překlepne třeba při sestavování tabulky a na terminálu na něj \TeX{} křičí: {\tt Extra alignment tab has been changed to "\verb|\cr|".} Uživatel začne znovu listovat ve své příručce a zjistí, že tam o~žádném "\verb|\cr|" není jediná zmínka. Má pak tři možnosti: (1)~Zmáčkne Enter a podobně se zachová i u~dalších chyb. Pomyslí si, že ten \LaTeX{} je něco tajemného a mystického. (2)~Propadne zoufalství a jde od toho. Dojde k~závěru, ľe je lepší zůstat u~Wordu. Vždyť stačí vzít tabulku v~Excelu a jednoduše ji přemístit do Wordu a jaképak smolení se s~nějakým podezřelým "\verb|\cr|". (3)~Pořídí si \TeX{}book a po intenzivním studiu nakonec řekne: \uv{aha}. V~tuto chvíli ale už nepotřebuje, aby mu \LaTeX{} zakrýval složitost \TeX{}u.
\end{quote} \citep{nolatex}
\subsection{reStructuredText}
Je tedy lepší použít samotný \TeX.
Tento jazyk, známý také jako ReST, je, stejně jako Markdown, zároveň syntaxí i parsovacím systémem syntaxe pro tvorbu dokumentů a webových stránek. Svou oblibu získal hlavně v~komunitě jazyka Python. Ve své dokumentaci\footnote{\url{https://docutils.sourceforge.io/rst.html}} je popisován jako syntax pro využití ke psaní \textit{Python docstrings} a dalších druhů dokumentace, která je spolehlivá a jednoduchá. ReST vznikl v~návaznosti na jazyk StructuredText, jenž trpěl mnoha nedostatky. Cílem jazyka reStructuredText je tyto nedostatky opravit a doplnit. \citep{problems_with_structuredtext}
\subsection{Troff}
S~jazykem se lze setkat u~značné části existujících generátorů statických webových stránek, z~nichž některé jsou zmíněny v~kapitole \ref{kap:paradigmata}.

@ -1,202 +1,81 @@
\chapter{Modelová implementace}\label{kap:modelova-implementace}
\chapter{Modelová implementace}
Tato část práce se věnuje tvorbě modelové implementace systému pro generování sta\-tických webových stránek dle definovaných požadavků v~kapitole \ref{kap:taxonomie-pozadavku}. Jsou zde vybrány vhodné součásti, ze kterých je modelová implementace složena.
Tato část práce se věnuje tvorbě modelové implementace systému pro generování statického webu dle definovaných požadavků. Systém je vytvářen na základě poznatků z předchozích částí práce.
\section{Výběr vhodného systému}\label{kap:vyber-vhodneho-systemu}
\section{Požadavky na modelový web}
Modelový systém se skládá ze dvou částí, a to z~verzovacího systému pro správu obsahu a generátoru statického HTML. Obě tyto součásti jsou vybírány na základě poznatků z~předchozích částí práce.
Jako modelovoá implementace byl zvolen web pro distribuci výukových materiálů. Webové stránky byly objednány Ústavem výzkumu a rozvoje vzdělávání Pedagogické fakulty Univerzity Karlovy za účelem usnadnění práce již aktivních učitelů a jsou tedy plně využívány v praxi mnoha pedagogy z celé republiky. Materiály jsou určeny pro podporu výuky během vyhlášeného stavu nouze v době šíření viru COVID-19 a mají učitelům pomoci s přípravou distanční výuky a úkolů v době vyhlášení celostátní karantény. Tuto implementaci lze ovšem použít na distribuci jakýchkoliv jiných výukových materiálů, či ke psaní dokumentace.
\subsection{Verzovací systém pro správu obsahu}\label{kap:vyber-vhodneho-systemu-verzovani}
Hlavním požadavkem je možnost dělit obsah na sekce dle druhu školy (základní škola, střední škola, vysoká škola atd.) a dále pak na subsekce podle předmětů a oborů. Do samotného obsahu musí být možné vkládat přílohy ke stažení v různých formátech, obrázky a videa s možností jejich ocitování. Všechny přiložené soubory musí být distribuovatelné přímo z webových stránek, nikoliv s externích zdrojů. Všechna videa je nutné vložit do stránky a musí je být možné přehrát v nativním přehrávači prohlížeče bez nutnosti otevírání externích webových stránek či programů.
Pro správu obsahu i šablon a statických souborů byl zvolen distribuovaný verzovací systém Git, jenž má v~porovnání s~jinými verzovacími systémy, zejména centralizovanými, spousty výhod. Jeho hlavní výhodou je rozšířené využití v~praxi a snadné používání. Díky svým decentralizovaným vlastnostem ho lze využívat v~mnoha odlišných pracovních postupech. S~naklonovaným repozitářem lze pracovat i bez připojení k~síti, což lze považovat i za druh zálohy. Git také umožňuje slučování různých změn od mnoha uživatelů a dovoluje jednoduše řešit potenciální konflikty. \citep{why_is_git_better_than_x}
Stránky musí být staticky generované a není tedy žádoucí v rámci webu řešit uživatelské účty, přihlašování apod. Zároveň je důležité, aby byl obsah zobrazitelný na každém druhu zařízení, tedy jak na monitorech s nadstandardní velikostí, tak na mobilních zařízeních. Z důvodu potencionálního vytížení sítě je nutné, aby byl celý obsah optimalizován za účelem předejití vysoké latence, a to z důvodů probíraných v předchozí části práce, tedy v sekci \ref{kap:vyhody-statickych-webovych-stranek}.
Skvěle využitelnou funkcí pro modelovou implementaci je také to, že po provedení změn v~repozitáři lze pomocí Gitu spouštět skripty, které mohou provádět automatické gene\-rování obsahu a další užitečné operace. Tato funkcionalita je implementována v~rámci modelové implementace v~sekci \ref{kap:automaticke-generovani-obsahu}.
Obsah stránek musí být verzován, decentralizován a spravován předem pověřenými uživateli. Generování statického webu na základě změn obsahu je nutné řešit automatizovaně.
\subsection{Generátor statického webu}
\section{Výběr vhodného systému}
Protože forma modelového webu odpovídá paradigmatu webové prezentace ze sekce \ref{kap:paradigmata-webova-prezentace}, byl pro jeho generování použit program Zola\footnote{\url{https://www.getzola.org/}}.
Modelový web se skládá ze dvou sytstémů, a to ze systému pro správu obsahu a systému pro jeho generování do HTML.
Vybraný generátor splňuje všechny požadavky z~kapitoly \ref{kap:taxonomie-pozadavku} a oproti jiným systémům je výhodný tím, že je napsaný v~jazyce Rust. Je tedy mnohem rychlejší a bezpečnější než většina jeho alternativ \citep{benchmarks_game}. Tato výhoda v~rychlosti se znatelně projevuje při zpracování obsáhlých webových stránek či mnoha obrázků.
Pro správu obsahu i šablon a statických souborů byl zvolen systém Git. Hlavní výhodou tohoto verzovacího systému je jeho rozšířené využití v praxi a dokáže s ním tedy pracovat spousta uživatelů. Zároveň má v porovnání s jinými verzovacími systémy spousty výhod.\todo{Příklady + citace}
V~rámci generátoru je využíván značkovací jazyk Markdown, který je snadný a velmi rozšířený. Kromě těchto výhod si zachovává většinu funkcí a rysů, jež lze najít v~ostatních složitých systémech. Zároveň je možné generátor zkompilovat\footnote{Spustitelné programy musí být převedeny do strojového kódu procesem zvaným \textit{kompilace}.} do jednoho staticky linkovaného\footnote{Spustitelný soubor má všechny potřebné knihovny integrované v~sobě.} binárního souboru, s~nímž se pracuje mnohem lépe než se složitým frameworkem.
Protože forma modelového webu odpovídá paradigmatu webové prezentace ze sekce \ref{kap:paradigmata-webova-prezentace}, byl pro jeho generování použit program Zola\footnote{\url{https://www.getzola.org/}}, jehož výhody jsou v sekci \ref{kap:paradigmata-webova-prezentace} popsány.
\section{Tvorba šablony}
Jak se uvádí v~dokumentaci\footnote{\url{https://www.getzola.org/documentation/content/overview/}}, Zola pracuje s~několika druhy stránek, primárně s~tak\-zvanou \textit{sekcí} a \textit{stránkou}.
Jak se uvádí v dokumentaci\footnote{\url{https://www.getzola.org/documentation/content/overview/}}, Zola pracuje s několika druhy stránek, primárně s takzvanou \uv{sekcí} a \uv{stránkou}. Každá sekce může mít vlastní obsah, ovšem může obsahovat i další subsekce, díky čemuž lze dělit obsah do stromové struktury. Stránka slouží pouze k předání obsahu a nikoliv k dalšímu větvení struktury. Dá se tedy říci, že stránka značí konec dané větve. Kořenem celého stromu je speciální sekce s názvem \uv{index}. Každá tato část standardně využívá vlastní HTML šablonu, ovšem nejde o pravidlo a každá část větve může využívat jinou šablonu. To je užitečné například u stránek s různým druhem obsahu. V rámci modelového webu zůstává druh obsahu stejný a není tedy třeba odchylovat se od standardní struktury.
\textit{Stránka} slouží pouze k~předání obsahu a nikoliv k~dalšímu větvení struktury. Dá se tedy říci, že stránka v~rámci stromové struktury reprezentuje konec větve.
Soubory se šablonami se nachází ve složce \texttt{templates/}, ve které generátor vždy očekává šablonu \texttt{index.html}. Ta se využívá jak k vykreslení úvodní kořenové stránky, tak ji mohou ostatní šablony rozšiřovat. Tato kořenová šablona tedy obsahuje základní strukturu celé stránky, přičemž navazující šablony jen mění určité části obsahu a nedefinují celou strukturu znovu.
Každá \textit{sekce} může mít vlastní obsah, ovšem může obsahovat i další subsekce, pomocí nichž lze obsah ve stromové struktuře větvit. Kořenem celého stromu je speciální sekce s~názvem \textit{index}.
Pro každou část se obvykle používá vlastní HTML šablona, ovšem není to pravidlem a každá část větve může využívat šablonu jinou. To je užitečné například u~stránek s~různými druhy obsahu. V~rámci modelového webu zůstává druh obsahu stejný a není tedy třeba se odchylovat od standardní struktury.
Soubory se šablonami se nachází ve složce \texttt{templates/}, ve které generátor vždy očekává šablonu \texttt{index.html}. Ta se využívá jak k~vykreslení úvodní kořenové stránky, tak jako základ, jež mohou ostatní šablony rozšiřovat. Tato kořenová šablona tedy obsahuje základní strukturu celé stránky, přičemž navazující šablony jen mění určité její části a nedefinují celou strukturu znovu.
Generátor Zola v~šablonách hledá vlastní řídící sekvence, jež se popisují kombinací složených závorek a dalších znaků. Existují tři druhy kombinací, které lze použít:
Generátor v šablonách hledá vlastní řídící sekvence, které se popisují závorkami. Existují tři druhy kombinací, které lze použít:
\begin{itemize}
\item \texttt{\{\% \%\}} -- Metoda, funkce, cykly, podmínky, práce s~proměnnou atd.
\item \texttt{\{\% \%\}} -- Metoda, funkce, cykly, podmínky, práce s proměnnou atd.
\item \texttt{\{\{ \}\}} -- Výpis do HTML
\item \texttt{\{\# \#\}} -- Komentář
\end{itemize}
Generátor také vyžaduje konfigurační soubor \texttt{config.toml} v~kořenové složce projektu, jenž obsahuje různá nastavení stránky, globální proměnné a chování generátoru.
Generátor také vyždaduje konfigurační soubor \texttt{config.toml} v kořenové složce projektu, který obsahuje různé nastavení stránky, globální proměnné a chování generátoru.
\begin{lstlisting}[label=lst:jednoducha-konfigurace,caption=Příklad jednoduché konfigurace v~souboru \texttt{config.toml}]
# Adresa pro kterou se generují odkazy
\begin{lstlisting}[label=lst:jednoducha-konfigurace,caption=Příklad jednoduché konfigurace v souboru \texttt{config.toml}]
# Adresa ze které se generují odkazy
base_url = "https://ucitelonline.pedf.cuni.cz"
# Název stránky
title = "Učitel online"
title = "%(*Učitel online*)"
# Popis stránky
description = "Web pro ditstribuci užitečných materiálů"
description = "%(*Web pro distribuci užitečných materiálů*)"
# Zda se bude zpracovávat CSS systémem Sass
compile_sass = true
\end{lstlisting}
Systém vždy zpracuje úvodní šablonu \texttt{index.html}, ze které pak lze odvíjet ostatní šablony. Tato hlavní šablona obsahuje strukturu celé webové stránky a nesmí v~ní chybět validní HTML struktura, tedy hlavička, tělo, metadata, kódování a podobně. Do struktury lze vkládat libovolné řídící sekvence generátoru, které ovlivňují výsledný výstup.
\begin{lstlisting}[label=lst:zakladni-sablona,caption=Základní šablona \texttt{index.html}]
<!DOCTYPE html>
<html lang="cs">
<head>
<meta charset="UTF-8">
<title>{{ config.title }}</title>
</head>
<body>
</body>
</html>
\end{lstlisting}
V~příkladu \ref{lst:zakladni-sablona} je název stránky mezi tagy \texttt{<title></title>} vyplněn generátorem. Ten do šablony vloží hodnotu konstanty \texttt{config.title}, která je nastavena v~konfiguračním souboru \texttt{config.toml} z~příkladu \ref{lst:jednoducha-konfigurace}. Názvem stránky bude tedy řetězec \uv{Učitel online}. Generátor dokáže převzít kteroukoliv konstantu z~kontextu konfiguračního souboru.
Všechny tyto řídící sekvence, nebo také \textit{direktivy}, lze v~rámci generátoru navazovat na sebe, podobně jako je tomu v~unixových systémech. Spojování funkcí a filtrů se provádí znakem \texttt{|}, stejně jako v~POSIX\footnote{Portable Operating System Interface -- Rodina standardů unixových systémů} shellu, kde se výstup jednoho příkazu stane vstupem příkazu navazujícího. Například je možné název stránky vypsat ve velkých písmenech i přesto, že v~konfiguračním souboru je řetězec s~názvem formátován pouze s~velkým písmenem na začátku. K~převedení na velká písmena slouží filtr \texttt{upper}. Názvem stránky bude po zpracování programem \ref{lst:filtr-upper} řetězec \uv{UČITEL ONLINE}.
\begin{lstlisting}[label=lst:filtr-upper,caption=Základní šablona s~filtrem pro přepsání názvu na velká písmena]
<!DOCTYPE html>
<html lang="cs">
<head>
<meta charset="UTF-8">
<title>{{ config.title | upper }}</title>
</head>
<body>
</body>
</html>
\end{lstlisting}
Generátor umožnuje v~šabloně vytvářet speciální bloky, jejichž obsah lze v~navazujících šablonách měnit. Je tedy možné měnit části struktury šablony. K~vysvětlení principu fungování bloků je název stránky v~příkladu \ref{lst:bloky} obalen blokem \texttt{title} a do těla vložen blok \texttt{content}.
\begin{lstlisting}[label=lst:bloky,caption=Využití bloků v~šabloně z~příkladu \ref{lst:filtr-upper}]
<!DOCTYPE html>
<html lang="cs">
<head>
<meta charset="UTF-8">
<title>{% block title %}{{ config.title | upper }}{% endblock %}</title>
</head>
<body>
{% block content %}
Ahoj, světe!
{% endblock %}
</body>
</html>
\end{lstlisting}
Název stránky zůstane stejný a v~jejím těle přibude text \uv{Ahoj, světe!}. Vytvoříme-li novou šablonu s~názvem \texttt{section.html}, generátor nám umožní rozšířit ji o~původní šablonu \texttt{index.html} a měnit pouze definované bloky. Není tedy nutné znovu definovat celou strukturu stránky. Pro importování nebo-li rozšíření šablony slouží direktiva \texttt{extends}.
\begin{lstlisting}[label=lst:sablona-section,caption=Definice nové šablony \texttt{section.html} rozšiřující šablonu z~příkladu \ref{lst:bloky}]
{% extends "index.html" %}
{% block title %}{{ config.title | upper }} &ndash; {{ section.title }}{% endblock %}
{% block content %}
Toto je obsah kategorie.
{% endblock %}
\end{lstlisting}
Šablona \texttt{section.html} se v~rámci generátoru Zola implicitně využívá pro všechny existující sekce\footnote{\url{https://www.getzola.org/documentation/content/section/}}. Názvem stránky v~této šabloně bude, podobně jako u~hlavní šablony, název stránky z~konstanty \texttt{config.title} definované v~konfiguračním souboru, ale také spojovník a název dané sekce. Za modelový výstup lze považovat například \uv{UČITEL ONLINE -- základní a střední škola}, bude-li se uživatel nacházet v~sekci pro základní a střední školy.
V~bloku s~obsahem bude původní obsah \uv{Ahoj, světe!} nahrazen za řetězec \uv{Toto je obsah kategorie}. Ten ovšem nechceme definovat přímo v~šabloně, nýbrž cílem generátoru je vyplňovat obsah ze zdrojových souborů v~sázecím jazyce, viz sekce \ref{kap:princip-generatoru}. Zola pro vkládání obsahu využívá stejný princip jako v~ostatních případech, tedy vypsání obsahu proměnné, v~tomto případě proměnné \texttt{section.content}, která obsahuje zkompilované HTML z~daného Markdown souboru. Zároveň je dobrou praktikou provést vyčištění vstupu filtrem \texttt{safe}\footnote{\url{https://tera.netlify.com/docs/\#safe}}.
\begin{lstlisting}[label=lst:sablona-section-vlozeni-obsahu,caption=Vkládání obsahu ze zdrojového Markdown souboru]
{% extends "index.html" %}
{% block title %}{{ config.title | upper }} &ndash; {{ section.title }}{% endblock %}
{% block content %}
{{ section.content | safe }}
{% endblock %}
\end{lstlisting}
Z~důvodu přenositelnosti systému a principu staticky generovaných stránek by žádný obsah neměl být definován přímo v~šabloně, nýbrž by měl být do stránky vkládán generátorem z~proměnných nebo ze sázeného obsahu. V~rámci modelové implementace je toto nepsané pravidlo dodržováno.
\section{Automatické generování vícevrstvé navigace}
Obsah modelové implementace je dělen do stromové datové struktury o~potenciálně nekonečné hloubce, kdy každá část větve je v~rámci generátoru vlastní kategorií, nikoliv stránkou. Pro modelovou implementaci bylo zvoleno, aby se navigace generovala v~návaznosti na aktivní cestu ve stromě. Ve stránce jsou dvě různé navigace: hlavní, která je vždy viditelná a obsahuje rozdělení obsahu dle škol, a vedlejší, jež zobrazuje aktivní větev stromu.
\begin{figure}[h]\centering
\includegraphics{img/generovani-vicevrstve-navigace}
\caption{Diagram průběhu generování vícevrstvé navigace}
\end{figure}
První vrstvou struktury jsou hlavní sekce, v~rámci implementace pojmenované jako $L_1$, které jsou vždy vypsány ve vlastní navigaci. Pod touto navigací je zobrazen seznam všech kategorií, které vybraná položka v~$L_1$ obsahuje. Pokud uživatel zvolí kteroukoliv položku v~$L_2$, v~navigaci se objeví další sloupec, který obsahuje všechny podkategorie vybrané položky, tedy všechny podkategorie ve vrstvě $L_3$. Takto lze stromem procházet potenciálně donekonečna. Styly modelové šablony ovšem počítají s~maxi\-mální hloubkou čtyř subkategorií.
Tato funkcionalita je implementována pomocí tří cyklů, z~nichž jeden je vložený. První cyklus (příklad \ref{lst:obsah-cyklus1}) se provádí pro všechny rodiče aktivní kategorie vrstev $L_2,L_3,\dotsc,L_n$, kde $n$ je aktuální vrstva. V~každé iteraci se mění kontext, ve kterém generátor pracuje. Z~daného kontextu generátor vypisuje pomocí vnořeného cyklu všechny subkategorie. Ve druhém cyklu (příklad \ref{lst:obsah-cyklus2}) se vypisují všichni potomci dané stránky, tedy potomci ve vrstvě $L_{n+1}$.
\begin{lstlisting}[label=lst:obsah-cyklus1,caption=Cyklus pro vypisování všech rodičů v~dané větvi navigace]
{% if section.ancestors %}
{% for s in section.ancestors %}
{% if loop.index < 2 %}{% continue %}{% endif %}
<ul>
{% set s = get_section(path=s) %}
{% for s in s.subsections %}
{% set s = get_section(path=s) %}
<li><a href="{{ s.permalink }}"
{% if current_path == s.path %}
class="active"
{% elif current_path is containing(s.path) %}
class="ancestor"
{% endif %}
>{{ s.title }}</a></li>
{% endfor %}
</ul>
{% endfor %}
{% endif %}
\end{lstlisting}
\begin{lstlisting}[label=lst:obsah-cyklus2,caption=Cyklus pro vypisování všech potomků dané stránky do navigace]
{% if section.subsections %}
<ul>
{% for s in section.subsections %}
{% set s = get_section(path=s) %}
<li><a href="{{ s.permalink }}">{{ s.title }}</a></li>
{% endfor %}
</ul>
{% endif %}
\end{lstlisting}
\todo[inline]{Tohle je pěkná ukázka, vyberte klidně ještě jednu dvě, které jsou něčím zajímavé, typické, nebo naopak výjimečné pro ilustraci toho, co chcete o daném, systému sdělit.}
\section{Rozšíření šablony}\label{kap:rozsireni-sablony}
\section{Rozšíření šablony}
Ve výchozím stavu neumí generátor zpracovávat nic jiného, než co je uvedeno ve specifikaci CommonMark, viz sekce \ref{kap:markdown}. Dle požadavků modelového webu je nutné, aby generátor uměl vkládat videa přímo do stránky. Taková funkcionalita není součástí specifikace CommonMark, a je tedy potřeba rozšířit generátor. Nejvhodnějším způsobem přidání vlastních funkcionalit je využití filtrů, jež se v~rámci generátoru nazývají \textit{shortcode}.
Ve výchozím stavu generátor neumí vkládat nic jiného, než je uvedeno ve specifikaci CommonMark\footnote{\url{https://commonmark.org/}}. Dle požadavků modelového webu je nutné, aby generátor uměl vkládat videa přímo do stránky. Taková funkce není soušástí specifikace CommonMark a je tedy potřeba rozšířit funkcionalitu generátoru. Nejvhodnějším způsobem přidání vlastní funkce je využití vlastních filtrů, které se v rámci generátoru nazývají \uv{shortcode}.
Principem vlastních filtrů je to, že si uživatel vytvoří vlastní šablonu, kterou lze vyvolat pomocí speciální řídící sekvence přímo z~obsahu. Každý tento shortcode může pracovat s~libovolným množstvím proměnných a po zpracování vloží do místa vyvolání zkompilovaný HTML kód. Dá se tedy říci, že shortcode je ve své podstatě funkce, jež umí pracovat s~parametry.
Principem vlastních filtrů je to, že uživatel si vytvoří vlastní šablonu, kterou lze vyvolat speciální řídící sekvencí přímo z obsahu. Každý tento shortcode může pracovat s libovolným množstvím proměnných a po zpracování vloží do místa vyvolání zkompilovaný HTML kód. Lze tedy tvrdit, že shortcode je v své podstatě imperativní funkce, která umí pracovat s parametry.
Pro tvorbu těchto filtrů je v~generátoru Zola určena složka \texttt{templates/shortcodes} obsahující jejich HTML šablony a kód pro zpracování generátorem. Název HTML souboru definuje název vlastního filtru. Vytvoříme-li uvnitř této složky soubor nazvaný \texttt{video.html}, budeme v~obsahu schopni využívat vlastní filtr s~názvem \texttt{video}.
Pro tvorbu těchto filtrů je v generátoru Zola určena složka \texttt{templates/shortcodes}, která obsahuje jejich HTML šablony a kód pro zpracování generátorem. Název HTML souboru definuje název vlastního filtru. Vytvoříme-li uvitř této složky soubor nazvaný \texttt{video.html}, budeme schopni využívat vlastní filtr s názvem \texttt{video}.
\begin{lstlisting}[label=lst:jednoduchy-filtr,caption=Příklad jednoduchého filtru s~jedním atributem]
\begin{lstlisting}[label=lst:jednoduchy-filtr,caption=Příklad jednoduchého filtru s jedním atributem]
<video controls><source src="{{ src }}"></video>
\end{lstlisting}
V~příkladu \ref{lst:jednoduchy-filtr} bude filtr očekávat atribut \texttt{src} a bude vracet jednoduchý HTML kód pro vložení videa do stránky. Tento filtr lze vyvolat kdekoliv v~obsahu, tedy v~kterémkoliv souboru s~koncovkou \texttt{.md}, v~nichž je uložen obsah. Za názvem filtru se do závorky uvádí parametry. Pro lepší přehlednost lze parametry oddělovat čárkou, což ovšem není pro správné zpracování generátorem nutné.
V příkladu \ref{lst:jednoduchy-filtr} bude filtr očekávat atribut \texttt{src} a bude vracet jednoduchý HTML kód pro vložení videa do stránky. Tento filtr lze vyvolat kdekoliv v obsahu, tedy v kterémkoliv souboru s koncovkou \texttt{.md}. Za názvem filtru se do závorky uvádí parametry oddělené čárkou. U posledního parametru se čárky nevuvádí, což platí i v případě, kdy se uvádí pouze jeden parametr, jako je tomu v příkladu \ref{lst:vyvolani-filtru}.
\begin{lstlisting}[label=lst:vyvolani-filtru,caption=Vyvolání vlastního filtru s~jedním parametrem]
\begin{lstlisting}[label=lst:vyvolani-filtru,caption=Vyvolání vlastního filtru s jedním parametrem]
{{ video(src="video.webm") }}
\end{lstlisting}
V~rámci vybraného generátoru není nutné specifikovat atributy na jeden řádek a lze je pro další zpřehlednění vypisovat na více řádků, stejně jako v~příkladu \ref{lst:formatovani-atributu}. Výstupem této direktivy bude následující HTML kód.
V rámci vybraného generátoru není nutné specifikovat atributy na jeden řádek a lze je pro přehlednost vypisovat na více řádků, jako tomu je například u programu \ref{lst:formatovani-atributu}, zůstane-li dodržena koncepce oddělení atributů čárkou, tedy že poslední atribut vždy zůstane bez čárky. Výstupem této direktivy bude následující HTML kód.
\begin{lstlisting}[caption=Výstup direktivy z~příkladu \ref{lst:jednoduchy-filtr}]
\begin{lstlisting}[caption=Výstup direktivy z příkladu \ref{lst:jednoduchy-filtr}]
<video controls><source src="video.webm"></video>
\end{lstlisting}
Součástí požadavků pro modelový web jsou i citace přiložených souborů a videí. Existující filtr je tedy třeba rozšířit o~možnost přiložení různých metadat. Tato metadata ovšem nejsou pro vložení videa povinná. Ve specifikaci vlastních filtrů lze využívat všechny operátory, jež generátor nabízí. Nejlepším přístupem k~tomuto problému je tedy využití jednoduchých podmínek, které kontrolují, zda je každá z~hodnot zadána jako parametr, a v~případě že ano, vepíše se do obsahu. Atributy ošetřené podmínkami tedy nejsou povinné, zatímco nevyplněný atribut \texttt{src} by při generování vyvolal chybu. V~následujícím příkladu jsou přidány podmínky pro kontrolu a případné vložení, jimiž jsou název videa (\texttt{title}), jméno autora (\texttt{author}) a rok vytvoření (\texttt{year}).
Součástí požadavků pro modelový web jsou i citace přiložených souborů a videí. Existující filtr je tedy třeba rozšířit o možnost přiložení různých metadat. Tato metadata ovšem nejsou pro vložení videa povinná. Ve specifikaci vlastních filtrů lze využívat všechny operátory, které generátor nabízí. Nejlepším přístupem k tomuto problému je tedy využití jednoduchých podmínek, které kontrolují, zda je každá z hodnot zadána jako parametr a v případě že ano, vepíše se do obsahu. Atributy ošetřené podmínkami tedy nejsou povinné, zatímco nevyplněný atribut \texttt{src} by při generování vyvolal chybu. V následujícím příkladu jsou přidány podmínky pro kontrolu a případné vložení, jimiž jsou název videa (\texttt{title}), jméno autora (\texttt{author}) a rok vytvoření (\texttt{year}).
\begin{lstlisting}[label=lst:filtr-s-podminkami,caption=Filtr pro vkládání videa s~využitím podmínek]
\begin{lstlisting}[label=lst:filtr-s-podminkami,caption=Filtr pro vkládání videa s využitím podmínek]
<video controls><source src="{{ src }}"></video>
{% if title or year and author %}
<div class="metadata">
@ -208,29 +87,29 @@ Součástí požadavků pro modelový web jsou i citace přiložených souborů
{% endif %}
\end{lstlisting}
Filtr je opět možné vyvolat pomocí stejné direktivy kdekoliv v~obsahu, ovšem nyní lze libovolně přidávat parametry pro metadata.
Filtr je možné opět vyvolat pomocí stejné direktivy kdekoliv v obsahu, ovšem nyní lze libovolně přidat parametry pro metadata.
\begin{lstlisting}[label=lst:formatovani-atributu,caption=Vyvolání filtru \ref{lst:filtr-s-podminkami} s~formátováním na řádky]
\begin{lstlisting}[label=lst:formatovani-atributu,caption=Vyvolání filtru \ref{lst:filtr-s-podminkami} s formátováním na řádky]
{{ video(
src="video.webm"
title="Název videa"
author="Jméno autora"
src="video.webm",
title="Název videa",
author="Jméno autora",
year="2020"
) }}
\end{lstlisting}
Protože byly zadány všechny povinné i nepovinné atributy, výstupem toho filtru budou i části kódu s~metadaty.
Protože byly zadány všechny povinné i nepovinné atributy, výtupem toho filtru budou i části kódu s metadaty.
\begin{lstlisting}[caption=Výstup direktivy z~příkladu \ref{lst:formatovani-atributu}]
<video controls><source src="video.webm"></video>
\begin{lstlisting}[caption=Výstup direktivy z příkladu \ref{lst:formatovani-atributu}]
<video controls><source src="video.webm"></video>
<div class="metadata">
Název videa (2020, Jméno autora)
</div>
\end{lstlisting}
Pro modelový web byla zvážena možnost vypisování obsahu automaticky, tedy že program projde složku s~obsahem a pokud narazí na soubor se specifikovanou koncovkou, vypíše jej do obsahu podle daných pravidel. Generátor Zola umožňuje prohledávání složek a práci se soubory, pro které se v~rámci Zoly používá termín \uv{asset}. Tuto funkcionalitu lze tedy implementovat jednoduchým cyklem a filtrem, které zpracují všechny případné soubory ve složce dané stránky. Soubory lze filtrovat mnoha způsoby, z~nichž je nejuniverzálnější funkce \texttt{matching()}, která dovoluje filtrovat vstup regulárními výrazy dle jejich implementace v~jazyce Rust\footnote{\url{https://docs.rs/regex/1.3.6/regex/}}. V~následujícím příkladu je pro ilustraci této funkcionality implementován program vypisující obrázky s~předem definovanými koncovkami.
Pro modelový web byla zvážena možnost vypisování obsahu automaticky, tedy že program zkontroluje složku s obsahem a pokud narazí na soubor se specifikovanou koncovkou, vypíše jej do obsahu podle daných pravidel. Generátor Zola umožňuje prohledávání složek a práci se soubory, v rámci Zoly takzvanými \uv{assety}. Tuto funkcionalitu lze tedy implementovat jednoduchým cyklem a filtem, které zpracují všechny případné soubory ve složce dané stránky. Zoubory lze filtrovat mnoha způsoby, z nichž je nejuniverzálnější funkce \texttt{matching()}, která dovoluje filtrovat vstup regulárními výrazy dle implementace regex v jazyce Rust\footnote{\url{https://docs.rs/regex/1.3.6/regex/}}. V následujícím příkladu je pro ilustraci této funkcionality implementován program vypisující obrázky s předem definovanými koncovkami.
\begin{lstlisting}[caption=Automatický výpis obrázků s~pevně definovanými koncovkami]
\begin{lstlisting}[caption=Automatický výpis obrázků s pevně definovanými koncovkami]
{% if section.assets %}
{% for asset in section.assets %}
{% if asset is matching("\.(?i:jpg|gif|png)$") %}
@ -240,9 +119,9 @@ Pro modelový web byla zvážena možnost vypisování obsahu automaticky, tedy
{% endif %}
\end{lstlisting}
Toto řešení ovšem není ve výsledném modelu implementováno, protože jedním z~požadavků je možnost vkládání souborů na libovolné místo v~obsahu. Na stejném principu je vytvořen filtr pro vkládání souborů, který tento požadavek splňuje. Výhodou filtru je, že ho lze vyvolat kdekoliv v~obsahu a není vázán na pevně dané místo v~šabloně. Filtr očekává alespoň jeden parametr uvádějící název souboru bez koncovky, podle něhož pak vyhledá všechny různé formáty s~tímto názvem, a ty vloží do stránky. Druhým libovolným parametrem je název souboru, který se do stránky vloží místo názvu souboru. To umožňuje uživateli volně pracovat s~názvy souborů v~souborové struktuře bez ovlivnění obsahu stránky.
Toto řešení ovšem není ve výsledném modelu implemntováno, protože jedním z požadavků je možnost vkládání souborů na libovolné místo v obsahu. Na stejném principu je ovšem vytvořen filtr pro vládání souborů, který tento požadavek splňuje. Výhodou filtru je, že ho lze vyvolat kdekoliv v obsahu a není vázán na pevně dané místo v šabloně. Ten očekává alespoň jeden parametr uvádějící název souboru bez koncovky, pro dle kterého pak filtr vyhledá všechny různé formáty s tímto názvem a ty vloží do stránky. Druhým libovolným parametrem je název souboru, který se do stránky vloží místo názvu souboru. to umožňuje uivateli volně pracovat s názvy souborů v souborvé struktuře bez ovlivnění obsahu stránky.
\begin{lstlisting}[label=lst:filtr-souboru,caption=Filtr pro výpis souborů s~automatickým hledáním]
\begin{lstlisting}[label=lst:filtr-souboru,caption=Filtr pro výpis souborů s automatickým hledáním]
{% if section.assets and filename %}
<div class="file">
<div class="title">
@ -261,24 +140,22 @@ Toto řešení ovšem není ve výsledném modelu implementováno, protože jedn
{% endif %}
\end{lstlisting}
V~první části filtr zkontroluje, zda byl vyplněn parametr \texttt{title}: pokud ano, nastaví ho jako název souboru v~obsahu, v~opačném případě využije název souboru samotného.
Ve druhém kroku nastává kontrola, jestli se ve složce nacházejí soubory (mimo hlavní soubor \texttt{\_index.md}) --- když ano, tak se iterativně zkontrolují všechny soubory, zda splňují podmínku názvu. Kontrola této podmínky je tvořena kombinací proměnných generátoru a regulárního výrazu. Každý soubor, který splňuje podmínku, je poté vypsán do obsahu jako přímý odkaz k~jeho stažení.
V první části filtr zkontroluje, zda byl vyplněn parametr \texttt{title} a v přípdě že ano, nastaví ho jako název souoru v obsahu. V opačném případě využije název souboru samotného. Ve druhém kroku nastává kontrola, zda se ve složce nacházejí soubory (mimo hlavní soubor \texttt{\_index.md}) a pokud ano, přes všechny soubory se iteruje kontrola, zda soubor splňuje podmínku názvu. Kontrola této podmínky je tvořena kombinací proměnných generátoru a regulárního výrazu. Každý soubor který splňuje podmínku je poté vypsán do obahu jako přímý odkaz k jeho stažení.
Jako text v~odkazu se použije koncovka souboru, která se získává spojením několika filtrů, tedy filtru \texttt{split(pat=".")}, který rozdělí řetězec podle znaku tečka do pole, a navazujícího filtru \texttt{last}, jenž vrátí poslední položku v~poli. Tím filtr získá samotnou koncovku souboru.
Jako text v odkazu se použije koncovka souboru, která se záskává spojením několika filtrů, tedy filtru \texttt{split(pat=".")}, který rozdělí řetězec podle znaku tečka do pole a navazující filtr \texttt{last} vrátí poslední položku v poli. Tím filtr získá samotnou koncovku souboru.
Filtr lze vyvolat stejně, jako je tomu u~filtru pro vkládání videa. Název filtru je opět definován názvem souboru \texttt{templates/shortcodes/document.html} a bude jím tedy název \texttt{document()}.
Filtr lze vyvolat stejně, jako je tomu u filtru pro vkládání videa. Název filtru je opět definován názvem souboru \texttt{tmeplates/shortcodes/document.html} a bude jím tedy název \texttt{document()}.
\begin{lstlisting}[label=lst:vyvolani-filtru-souboru,caption=Vyvolání filtru \ref{lst:filtr-souboru}]
{{ document(
filename="pracovni-list"
filename="pracovni-list",
title="Pracovní list"
) }}
\end{lstlisting}
V~příkladu \ref{lst:vyvolani-filtru-souboru} je definován i nepovinný atribut \texttt{title}, který pro přehlednost umožňuje nastavit název. Atribut \texttt{filename} definuje název souboru ve složce bez koncovky. Všechny soubory, jež chce uživatel vypsat, musí tedy mít stejný název a musí se lišit pouze koncovkou. Jsou-li ve složce soubory s~názvem \texttt{pracovni-list} a koncovkami \texttt{pdf}, \texttt{odt}, \texttt{djvu} a \texttt{ps}, bude výstupem filtru následující HTML.
V příkladu \ref{lst:vyvolani-filtru-souboru} je definován i nepovinný atribut \texttt{title}, který kvůli přehlednosti umožňuje nastavit název. Atribut \texttt{filename} definuje název souboru ve složce bez koncovky. Všechny soubory, které chce uživatel vypsat, musí tedy mít stejný název a musí se lišit pouze koncovkou. Jsou li ve složce soubory s názvem \texttt{pracovni-list} a koncovkami \texttt{pdf}, \texttt{odt}, \texttt{djvu} a \texttt{ps}, bute výstupem filtru následující HTML.
\begin{lstlisting}[caption=Výstup direktivy z~příkladu \ref{lst:vyvolani-filtru-souboru}]
\begin{lstlisting}[caption=Výstup direktivy z příkladu \ref{lst:vyvolani-filtru-souboru}]
<div class="file">
<div class="title">Pracovní list</div>
<a href="pracovni-list.pdf">pdf</a>
@ -288,102 +165,14 @@ V~příkladu \ref{lst:vyvolani-filtru-souboru} je definován i nepovinný atribu
</div>
\end{lstlisting}
\section{Optimalizace}\label{kap:optimalizace}
Optimalizace je provedena na základě článku ze serveru \cite{calomel_optimization}, který se věnuje sestavením užitečných rad pro optimalizaci webových stránek na serverech s~omezeným připojením do sítě a zvýšení spokojenosti uživatelů z~užívání optimalizovaného webu, jak je rozebráno v~sekci \ref{kap:vyhody-statickych-webovych-stranek}.
Jak se na webu Calomel píše, provozování webserveru může být hodnotnou zkušeností, ale zároveň může být i zkouškou trpělivosti. Chcete svým uživatelům předávat všechny vaše stránky a obrázky, ovšem máte jen omezenou šířku pásma, pomocí které můžete data přenášet. Pokud přetížíte své připojení, klienti navštěvující váš web server si budou myslet, že je pomalý a neresponzivní. Je tedy třeba webový server nastavit tím nejlepším možným způsobem s~cílem získat co nejvíce návštěv a zlepšit zážitek vašim návštěvníkům. Následující rady slouží ke snížení zátěže serveru, ke zrychlení odesílání stránek a k~zastavení nechtěného a škodlivého provozu.
Práce se věnuje pouze technickým optimalizacím spojeným s~tvorbou samotné webové stránky, nikoliv však optimalizacím sítě, web serveru a vizuálního návrhu. Nenačítá-li se stránka během několika vteřin, většina uživatelů jednoduše odejde. Cílem této sekce je provést optimalizace, které urychlí načítání modelové implementace.
\subsection{Typy a kvalita obrázků}
\section{Optimalizace}
Fotografie a grafika využívají mnohem více dat pro přenos než běžný HTML text a je tedy nutné provést optimalizaci (kompresi) obrázků na co nejmenší možnou velikost souborů. Obrázky není třeba renderovat na více než 72 dpi a pro každý druh grafiky je třeba zvolit vhodný formát, tj. formát JPEG pro fotografie a formáty PNG či SVG pro jednoduchou grafiku. Rastrové obrázky by neměly přesáhnout maximální rozlišení zobrazované na stránce. Klíčové je také nevyužívat obrázky v~případě, kdy je lze nahradit čistým HTML a CSS.
Optimalizace modelové implementace je provedena na základě článku ze serveru Calomel, který se věnuje sestavením užitečných rad pro optimalizaci webových stránek na serverech s omezeným připojením do sítě a pro zlepšení uživatelského pocitu z jejich užívání.
Obrázky ve formátu JPEG mají velice efektivní ztrátovou kompresi, pomocí které lze zredukovat velikost obrázku o~značnou část. Autor článku tvrdí, že většinu obrázků lze komprimovat až o~50\% bez viditelné ztráty na kvalitě. Své obrázky dokonce zkomprimoval ze 27 kilobajtů na pouhých 8 kilobajtů s~JPEG kompresí 60\%.
\begin{quote}\todo{Přeložit}
Running a webserver can be a rewarding experience and also a trial in patience. You want to serve out all your pages and pictures, but you only have a finite amount of bandwidth to do so. if you overload your connection client visiting your server will think it is slow and unresponsive. You need to setup your server in the most efficient way possible to get the most visits you can and give your visitors a positive experience. The following are tips on reducing the load on your webserver, speeding up the serving pages and stopping unwanted and abusive traffic.
\end{quote} \citep{calomel_optimization}
\subsection{Ikona \textit{favicon.ico}}
Původně je \textit{favicon.ico} výtvorem firmy Microsoft, kdy Internet Explorer automaticky odesílal požadavek na pevnou URL \texttt{/favicon.ico} od kořene webového serveru. Jde o~malou ikonku, jež se dnes zobrazuje u~každé záložky s~webovou stránkou. Problémem je, že se požadavkům na~ní nelze vyhnout a vždy se počítá s~tím, že ikona webu existuje. Odesílá se vždy s~každou stránkou a některé prohlížeče se po ní dotazují z~neznámých důvodu dvakrát. Autor článku uvádí, že u~některých serverů bylo až 30\% přenesených dat využito jen na odesílání ikony.
Principem optimalizace je udržet ikonu co nejmenší, v~nejlepším případě tak malou, aby se vešla do jednoho TCP paketu, tedy do velikosti 1460 bajtů na většině systémů. Toho lze docílit tím, že ikona nebude větší než 16x16 pixelů s~nízkou barevnou hloubkou, nejlépe pouze se~čtyřmi barvami. Také je možné poslat jen 1x1 pixelů veliký prázdný obrázek nebo vracet stavový kód 204\footnote{204 No Content -- Server úspěšně zpracoval požadavek, ale nevrací žádný obsah.} a neodesílat ikonu žádnou.
\subsection{Obecné HTML optimalizace}
Redukcí nepotřebných znaků v~HTML lze také ušetřit značnou část přenesených dat. Nejvhodnější je:
\begin{itemize}
\item nepoužívání HTML komentářů,
\item využití CSS pro formátování stránek,
\item využití oddělovače nebo elementu \texttt{span} namísto tabulek,
\item odstranění přebytečných tagů a prázdných mezer a řádků,
\item vytvoření obrázkových náhledů namísto odesílání obrázků v~plném rozlišení,
\item recyklování již použitých obrázků a tlačítek.
\end{itemize}
K~odstranění přebytečných mezer, zalomení řádků, HTML komentářů a prázdných řádků lze použít automatický filtr pro kompresi výstupu. Toto by se nabízelo jako jedna z~dalších možností pro implementaci rozšíření. Generátor Zola provádí kompresi CSS, ovšem nemá zabudovanou funkcionalitu pro minifikaci výsledného HTML, která je v~době psaní této práce vyvíjena\footnote{\url{https://github.com/getzola/zola/issues/542/}}.
Touto redukcí lze ušetřit 2\% přenosu dat oproti ručně psanému neoptimalizovanému kódu. Je-li průměrná velikost stránky sto kilobajtů, lze touto optimalizací ušetřit dva kilobajty při každém odeslání stránky. Při odeslání sta tisíce stránek za měsíc je ve výsledku ušetřeno dvě stě megabajtů dat, které jsou jinak zbytečně odesílány uživatelům, kteří je stejně nezobrazí.
Další obecné rady pro optimalizaci HTML jsou uvedeny na serveru \cite{yahoo_optimization}, kde se uvádí spousta dalších způsobů ke zrychlení načítání stránky a k~nižšímu vytížení sítě.
Připojením externích CSS a JavaScript souborů je umožněno jejich ukládání do paměti cache, což snižuje HTTP požadavky vůči serveru. Je-li obsah těchto souborů přímo ve stránce, je odesílán pokaždé s~novou stránkou, a to vede ke zbytečnému vytěžování sítě. S~tím souvisí i velikost stránek, kdy se soubory s~větší než danou maximální velikostí do mezipaměti neukládají, a je proto dobré tuto velikost nepřekračovat.
Připojením externího CSS přímo do hlavičky je umožněno progresivní vykreslování webové stránky, které urychluje \uv{Time To First Byte}, viz sekce \ref{kap:vyhody-statickych-webovych-stranek}. Naopak umístěním případných JavaScript souborů až na konec celé stránky se prioritizuje načítání viditelného obsahu před méně důležitými skripty.
\subsection{Optimalizace videa}
Protože v~modelové implementaci jsou do stránky vkládána i videa, je nutné provádět jejich optimalizaci podobně, jako je tomu u~obrázků. Důležité je používat kvalitní kompresi, pouze nutné rozlišení a renderovat videa ve správném poměru stran a bez zbytečných černých okrajů. Při zpracování videa je dobré neprovádět jeho transkódování do jiného formátu z~původního, ovšem zároveň je třeba dbát na kompatibilitu s~prohlížeči, které různé formáty a kontejnery neumí vždy nativně přehrát.
\section{Správa obsahu a verzování}
Statické stránky neumožňují správu uživatelů v~rámci webové aplikace, tedy to, že se případný editor nebo administrátor přihlásí a upravuje obsah klikáním či psaním v~edi\-toru, který během psaní formátuje text tak, jak bude ve výsledku vypadat. Správu uživatelů lze jednoduše řešit omezením přístupu na web server, kde mohou do obsahu zasahovat jen oprávnění uživatelé. To je však velmi těžkopádné řešení, protože neumožňuje práci více uživatelů najednou a neudržuje předešlé verze obsahu a historii úprav. Lepší alternativou je využití některého verzovacího systému. Pro účely modelové implementace byl vybrán distribuovaný verzovací systém Git, jak je vysvětleno v~sekci \ref{kap:vyber-vhodneho-systemu-verzovani}.
V~tomto systému jsou soubory uloženy v~repozitářích, kde každý projekt je vlastní repozitář. V~rámci jednotlivých repozitářů se ukládají všechny změny obsahu prostřednictvím takzvaných \textit{commitů} --- záznamů o~provedených změnách včetně jejich krátkého popisu a autora. Tyto revize lze provádět v~různých větvích repozitáře a větve je možné mezi sebou spojovat a kombinovat. Rovněž je možné se vracet do kteréhokoliv bodu v~historii v~rámci každé větvě.
Nastane-li konflikt při nahrávání změn, umožňuje Git jejich snadné vyřešení. Konflikt je stav, kdy například dva různí uživatelé provedli úpravy na stejném místě stejného souboru a snaží se je nahrát do repozitáře. Git v~tuto chvíli druhého uživatele upozorní, že původní soubor byl změněn a je třeba tento konflikt vyřešit. Zamezuje se tak přepsání změn prvního uživatele.
K~systému Git existují různé služby, jež tento systém rozšiřují o~webové grafické rozhraní s~množstvím dalších rozšíření. Nejčastěji používanými službami jsou GitHub\footnote{\url{https://github.com/}}, GitLab\footnote{\url{https://gitlab.com/}}, nebo Bitbucket\footnote{\url{https://bitbucket.org/}}, z~nichž některé lze provozovat na vlastním serveru. Snadným systémem pro vlastní provozování je také program Gitea\footnote{\url{https://gitea.com/}}, jenž je oproti předem zmíněným systémům zcela svobodným softwarem\footnote{Respektuje základní svobody uživatele (\url{https://www.gnu.org/philosophy/free-sw.html})} a je velmi jednoduchý na instalaci a správu. Tyto systémy mají navíc integrovaný jednoduchý editor pro úpravu souborů přímo z~webového rozhraní a také umí zobrazovat náhled souborů s~obsahem napsaným v~jazyce Markdown, jenž je popsán v~sekci \ref{kap:markdown}.
\subsection{Automatizace generování obsahu}\label{kap:automaticke-generovani-obsahu}
Tato část práce se věnuje samotné implementaci automatického generování obsahu na základě změn v~repozitáři.
Jak bylo zmíněno v~sekci \ref{kap:vyber-vhodneho-systemu-verzovani}, git umožňuje nastavení takzvaných \textit{Git hooks}, jež se v~určité chvíli spustí. Jak uvádí dokumentace\footnote{\url{https://git-scm.com/docs/githooks/}}, existuje spousta druhů hooků, které jsou vyvolány v~různé části zpracování požadavku. V~případě této implementace je nejvhodnější hook \textit{post-receive}, jenž je spouštěn až po nahrání a zpracování všech změn v~repozitáři.
Skript \ref{lst:git-hook-skript} po vyvolání Gitem provede veškeré potřebné operace ke zpracování nového obsahu na web serveru Je složen z~několika částí.
Jako první probíhá na řádcích 1--3 nastavení proměnných, ve kterých se ukládá odkaz na vzdálený Git repozitář, název složky, do níž se obsah má klonovat, a název složky, do které se má kopírovat výstup čili vygenerované HTML. Dále se skript na řádku 5 přepíná do složky, v~níž se sám nachází --- aby skript fungoval vždy, ať je spuštěný ze kteréhokoliv místa v~souborovém systému.
V~další části skriptu probíhá na řádku 7 kontrola, zda již existuje složka s~naklonovaným Git repozitářem. Pokud složka neexistuje, provede se naklonování vzdáleného repozitáře a tím i vytvoření složky.
Třetí část provádí generování statického obsahu. Nejprve se skript přepne do repozitáře, v~němž provede příkaz \texttt{git pull}, který do složky stáhne poslední změny ze vzdáleného repozitáře: synchronizuje obsah na poslední verzi. Po synchronizaci repozitáře proběhne samotné spuštění generátoru, jenž z~obsahu vygeneruje statické HTML, které vloží do složky \texttt{./public}. Poté na řádcích 12--14 probíhá kopírování nově vygenerovaného obsahu do složky \texttt{/srv/www/ucitelonline} včetně nastavení unixových práv souborů na bezpečné hodnoty, které se liší pro složky a pro soubory.
\begin{lstlisting}[
label=lst:git-hook-skript,
caption=Skript pro automatizované generování obsahu,
language=sh,
numbers=left,
stepnumber=1,
firstnumber=0
]
#!/bin/sh -e
GREPO="https://git.microlab.space/pedf/ucitelonline"
GDIR="ucitelonline"
WEBROOT="/srv/www/ucitelonline"
cd $(dirname $0)
[ ! -d "$GDIR" ] && git clone --recursive "$GREPO" "$GDIR"
cd "$GDIR"
git pull
zola build
rsync --recursive --delete --checksum \
--group --groupmap=*:www-data --chmod=D750,F640 \
public/ "$WEBROOT"
\end{lstlisting}
Skript spoléhá na to, že systém má již předem správně nakonfigurované uživatele, uživatelské skupiny a web server, a že jsou nainstalované potřebné programy Git, Rsync a generátor Zola. Systémový uživatel, pod kterým je vyvolán Git hook, musí být ve skupině \textit{www-data}, nebo v~jiné skupině společně s~uživatelem, pod nímž je spuštěn web server. Zároveň musí mít uživatel práva pro zápis do cílové složky, tedy kořenové složky web serveru: \texttt{/srv/www/ucitelonline}.
Ve většině případů by bylo vhodné klonovat a generovat obsah v~dočasné složce, napří\-klad v~\texttt{/tmp}, a po zkopírování souborů do složky web serveru opět zdrojové soubory smazat. To se ovšem v~této implementaci nehodí, protože repozitář se zdrojovými soubory může být velký a jeho klonování může potenciálně zabrat zbytečné množství času, na rozdíl od~příkazu \texttt{git pull}, který pouze stáhne změny. Generátor zároveň při generování zpracuje pouze nutné změny, zatímco po čistém naklonování musí zpracovat celý obsah znovu, což může také trvat dlouho, obzvlášť při zpracování mnoha obrázků. V~této implementaci se tedy zachováním naklonovaného repozitáře výrazně zkracuje čas celého skriptu.

@ -1,87 +1,27 @@
\chapter{Webová paradigmata}\label{kap:paradigmata}
\chapter{Webová paradigmata}
Ve světě webových stránek se setkáváme se spoustou forem a paradigmat, jež se hodí pro zpracování různých druhů informací. Neexistuje žádné formální zařazení druhů webových stránek do skupin, ovšem některé webové portály se pokouší určit základní druhy webových stránek, které se na Internetu objevují. Na základě těchto portálů a jejich rozřazení do skupin\footnote{\url{http://www.xislegraphix.com/website-types.html}}\footnote{\url{https://www.hostgator.com/blog/popular-types-websites-create/}}, jež jsou často mířené na specifický obsah, lze vytvořit t základních paradigmat. Jsou jimi:
Ve světě webových stránek se setkáváme se spoustou forem a paradigmat, která se hodí pro obsažení různých druhů informací. Neexistují žádné formální zařazení druhů webových stránek do skupin, ovšem některé webové portály se pokouší určit základní druhy webů, které se na Internetu objevují. Na základě těchto portálů a jejich rozřazení do skupin\footnote{\url{http://www.xislegraphix.com/website-types.html}}\footnote{\url{https://www.hostgator.com/blog/popular-types-websites-create}}\footnote{\url{https://www.quora.com/What-are-the-different-types-of-websites}}\todo{Přesunout odkazy pod jednu položku.}, které jsou často mířené na specifický obsah, lze vytvořit tři základní paradigmata, do kterých lze tyto weby zařadit. Jsou jimi:
\begin{itemize}
\item webová prezentace,
\item index všeobecných informací,
\item technická dokumentace,
\item galerie,
\item sociální sítě a fóra.
\item{Webová prezentace}
\item{Index všeobecných informací}
\item{Technická dokumentace}
\item{Sociální sítě a fóra}
\end{itemize}
V~této práci bylo ke každému z~paradigmat vybráno několik existujících generátorů, které jsou vhodné pro generování a správu daného druhu obsahu. Výjimkou je skupina sociálních sítí a fór, kde staticky generovaný obsah není z~důvodu často se měnícího obsahu vhodným řešením.
V této práci byl ke každému z paradigmat vybrán systém vhodný pro generování a správu daného druhu obsahu. Výjimkou je skupina sociálních sítí a fór, kde staticky generovaný obsah není z důvodu často se měnícího obsahu vhodným řešením.
\section{Webová prezentace}\label{kap:paradigmata-webova-prezentace}
Nejbližší původním webovým stránkám z~dob vzniku WWW jsou webové prezentace, tedy stránky s~jednoduchým obsahem sloužící k~předání informací čtenáři, například formou článků. Do této skupiny lze zařadit portfolia, blog, online noviny a časopisy, firemní stránky a podobně, jež se skvěle hodí ke statickému generování obsahu.
Nejbližší původním webům z dob vzniku WWW jsou webové prezentace, tedy stránky s jednoduchým obsahem, které slouží k předání informací čtenáři například formou článků. Do této skupiny lze zařadit portfolia, blog, online noviny a časopisy, firemní stránky, foto alba a podobně. Tento druh stránek se skvěle hodí ke statickému generování obsahu, který se odesílá všem uživatelům stejný a nemění se často.
Generátory pro tento typ webové stránky jsou často univerzální a je možné aplikovat většinu těchto generátorů i na ostatní formy stránek. Většina existujících generátorů je zaměřena právě na toto paradigma, a lze z~čeho vybírat. Každým dnem vznikají nové implementace a svět staticky generovaných stránek se rapidně mění.
\begin{longtable}[c]{|l|l|l|}
\caption{Vybrané generátory pro webové prezentace}
\label{tab:generatory-prezentace}\\
\hline
\multicolumn{1}{|c|}{\textbf{Program}} & \multicolumn{1}{c|}{\textbf{Jazyk}} & \multicolumn{1}{c|}{\textbf{Podporované jazyky obsahu}} \\ \hline
\endfirsthead
%
\endhead
%
blogc\footnote{\url{https://blogc.rgm.io/}} & C & Vlastní jazyk blogc-source\footnote{\url{https://blogc.rgm.io/man/blogc-source.7.html}} založený na Markdownu \\ \hline
Hugo\footnote{\url{https://gohugo.io/}} & Go & Markdown, HTML, AsciiDoc, Pandoc Markdown, reST \\ \hline
Luapress\footnote{\url{https://luapress.org/}} & Lua & Markdown \\ \hline
Nift\footnote{\url{https://www.staticgen.com/nift/}} & C++ & Agnostický, tj. Markdown, \LaTeX, HTML, JS, SQL, ... \\ \hline
Pelican\footnote{\url{https://blog.getpelican.com/}} & Python & Markdown, reST \\ \hline
ssg\footnote{\url{https://www.romanzolotarev.com/ssg.html}} & shell & Markdown (lowdown, Markdown.pl) \\ \hline
Zola\footnote{\url{https://www.getzola.org/}} & Rust & Markdown (CommonMark) \\ \hline
\end{longtable}
Jako nejvhodnější systém pro generování webových prezentací byl vybrán software Zola. Ten je oproti jiným systémům výhodný tím, že je napsaný v jazyce Rust a je tedy snadno rozšiřitelný a mnohem rychlejší, než jeho alternativy.\todo{Citovat benchmark}. I stěmitop výhodami si zachovává spousty funkcí a ryců, které lze na jít v ostatních složitých systémech. Také je možné generátor zkompilovat do jednoho staticky linkovaného binárního souboru, se kterým se pracuje mnohem lépe, než se složitým frameworkem.
\section{Index všeobecných informací}
Za obecného zástupce tohoto druhu stránek lze považovat Wikipedii, která podnítila vznik spousty jiných takzvaných \textit{Wiki systémů} a stránek. Jde o~formu stránky, jež obsahuje velké množství informací s~různou provázaností. Nejde o~lineární dokumentaci projektu, nýbrž o~encyklopedii obecných informací.
Jak již bylo řečeno, tuto formu stránek lze implementovat jakýmkoliv generátorem. Existují ale generátory vytvořené přímo pro účel tohoto paradigmatu. Takových gene\-rátorů je ovšem málo, jelikož jedním ze základních znaků wiki je to, že její obsah tvoří komunita uživatelů, což nemusí být vždy vhodné pro systém statického generování obsahu. Jedním takovým programem je ikiwiki\footnote{\url{https://ikiwiki.info/}}, který funguje stejně jako ostatní sta\-tické generátory. Další programy, například MDwiki\footnote{\url{https://dynalon.github.io/mdwiki/}}, zpracovávají Markdown přímo v~prohlížeči a HTML obsah tedy není předgenerován na serveru.
Program MDwiki je prezentován jako generátor vytvořený na míru pro wiki stránky, ovšem jeho výstup je velice podobný generátorům z~tabulky \ref{tab:generatory-technicka-dokumentace}.
Za obecného zástupce tohoto druhu stránek lze považovat Wikipiedii, která podnítila vznik spousty jiných takzvaných \uv{Wiki systémů} a stránek.
\section{Technická dokumentace}
Od Wiki stránek se technická dokumentace liší organizováním svého obsahu, který je cílený na přesný popis systému či objektu. Obsah je strukturován jako manuál, nebo-li kniha, kde se obsah každé části věnuje danému tématu a různý obsah je strukturován do vlastních knih.
\begin{longtable}[c]{|l|l|l|}
\caption{Vybrané generátory pro technickou dokumentaci}
\label{tab:generatory-technicka-dokumentace}\\
\hline
\multicolumn{1}{|c|}{\textbf{Program}} &
\multicolumn{1}{c|}{\textbf{Jazyk}} &
\multicolumn{1}{c|}{\textbf{Podporované jazyky obsahu}} \\ \hline
\endfirsthead
%
\endhead
%
mdBook\footnote{\url{https://github.com/rust-lang/mdBook/}} & Rust & Markdown \\ \hline
MkDocs\footnote{\url{https://www.mkdocs.org/}} & Python & Markdown \\ \hline
Sphinx\footnote{\url{https://www.sphinx-doc.org/}} & Python & reStructuredText \\ \hline
\end{longtable}
\section{Galerie}
V~případě galerií se jedná o~obsah složený primárně z~obrázků nebo videí uspořádaných ve struktuře pro jejich snadnou prezentaci. Mohou sloužit jako foto alba, časové příběhové osy, nebo jako portfolio produktů či fotografií.
Generátory galerií umožňují jednoduše řadit obrázky do skupin a vytvářet k~nim popisky. Markup jazyky zde nehrají tak velkou roli jako u~ostatních druhů paradigmat, jelikož hlavním obsahem není text, nýbrž samotné obrázky a videa.
Na rozdíl od Wiki stránek se technická dokumentace liší organizováním svého obsahu, který je cílený na přesný popis systému či objektu.
\begin{longtable}[c]{|l|l|l|}
\caption{Vybrané generátory pro galerie}
\label{tab:generatory-galerie}\\
\hline
\multicolumn{1}{|c|}{\textbf{Program}} &
\multicolumn{1}{c|}{\textbf{Jazyk}} \\ \hline
\endfirsthead
%
\endhead
%
Exposé\footnote{\url{https://github.com/Jack000/Expose/}} & shell \\ \hline
fgallery\footnote{\url{https://gitlab.com/wavexx/fgallery/}} & Perl \\ \hline
Prosopopee\footnote{\url{https://github.com/Psycojoker/prosopopee/}} & Python \\ \hline
Sigal\footnote{\url{http://sigal.saimon.org/}} & Python \\ \hline
\end{longtable}

@ -1,27 +1,8 @@
\chapter{Taxonomie požadavků pro modelový web}\label{kap:taxonomie-pozadavku}
Tato kapitola se věnuje určení základních požadavků pro modelovou implementaci. Jsou zde shrnuta obecná kritéria, která platí pro většinu webových prezentací, a také kritéria specifická pro modelovou implementaci v~rámci této práce. Dle těchto kritérií je poté v~následující kapitole vytvořena samotná implementace.
Jako modelová implementace byl zvolen web pro distribuci výukových materiálů a odkazů užitečných pro výuku. Tvorba těchto webových stránek je zadána Ústavem výzkumu a rozvoje vzdělávání Pedagogické fakulty Univerzity Karlovy za účelem usnadnění práce již aktivních učitelů v~době šíření viru COVID-19. Tyto webové stránky mají učitelům pomoci s~přípravou distanční výuky a úkolů v~době vyhlášení stavu nouze a celostátní karantény. Modelová implementace je tedy plně využívána v~praxi mnoha pedagogy z~celé republiky. Tuto implementaci lze ovšem použít pro distribuci jakýchkoliv jiných výukových materiálů či ke psaní a správě dokumentace.
\chapter{Taxonomie požadavků}
\section{Obecná kritéria}
Jako zdroj obecných kriterií je použit článek ze serveru \cite{calomel_optimization}, který se mimo jiné věnuje i optimalizacím, jež jsou dále popsány v~sekci \ref{kap:optimalizace}.
Z~důvodu potenciálního vytížení sítě je nutné, aby byl celý obsah optimalizován za účelem předejití vysoké latence, a to z~důvodů probíraných v~předchozí části práce, tedy v~sekci \ref{kap:vyhody-statickych-webovych-stranek}.
Stránky by měly být udržovatelné i po předání jinému správci, a celý systém by tedy měl být dostatečně zdokumentován. Také je důležité, aby byla zajištěna kompatibilita s~nejběžněji používanými prohlížeči.
\section{Kritéria specifická pro modelový web}
Specifická kritéria jsou vytvořena na základě požadavků autorů obsahu, tedy učitelů, z~nichž má každý své specifické požadavky na funkce a vlastnosti, které musí obsah splňovat. Následující kritéria jsou souhrnem a kompromisem mezi všemi požadavky.
Stránky musí být staticky generované a není tedy žádoucí v~rámci webu řešit uživatelské účty, přihlašování apod. Hlavním požadavkem pro strukturu stránky je možnost dělit obsah na sekce dle druhu školy (základní škola, střední škola, vysoká škola atd.) a dále pak na subsekce podle předmětů a oborů.
Do samotného obsahu musí být možné vkládat přílohy ke stažení v~různých formátech, obrázky a videa s~možností jejich ocitování, tedy uvedení autora, názvu díla apod. Všechny přiložené soubory musí být distribuovatelné přímo z~webových stránek, nikoliv z~externích zdrojů. Všechna videa je nutné vložit do stránky a musí je být možné přehrát v~nativním přehrávači prohlížeče bez nutnosti otevírání externích webových stránek či programů. V~hlavičce každé stránky musí být možné specifikovat následující informace: autora či seznam autorů obsahu, skupinu, pro kterou je obsah určen a časovou dotaci.
Obsah stránek musí být možné spravovat předem pověřenými uživateli a jeho změny musí být zaznamenávány v~decentralizovaném verzovacím systému. Generování static\-kého webu na základě změn obsahu je nutné řešit automatizovaně --- bez dalších zásahů správce či manuálního nahrání nového obsahu na webserver.
\section{Kritéria pro šablony a design}
Obsah musí být zobrazitelný na každém druhu zařízení, tedy jak na monitorech s~nadstandardní velikostí, tak na mobilních zařízeních. Zároveň musí být snadno čitelný, v~nejlepším případě vysoce kontrastní černý text na bílém pozadí s~dostatečnou velikostí. Navigace v~obsahu musí být jednoduchá a intuitivní a vzhled celé stránky konzistentní. Na stránce nesmí přesahovat objem vizuálních elementů nad obsahem. Relevantní obsah by měl být na jednom místě, nikoliv rozdělený na několik různých stránek, mezi kterými musí uživatel přecházet.

@ -1,16 +1,6 @@
\chapter{Vyhodnocení modelové implementace}
V~této části práce je shrnuta a zhodnocena modelová implementace z~kapitoly \ref{kap:modelova-implementace}, a to jak implementace a využití samotného systému, tak jeho rozšíření implementovaných v~sekci \ref{kap:automaticke-generovani-obsahu}. Součástí této kapitoly jsou také návrhy pro další rozšíření systému.
\section{Návrhy pro rozříšení systému}
Webové stránky vytvořené v~rámci této práce jsou k~dispozici na adrese \url{https://ucitelonline.pedf.cuni.cz/} a jejich zdrojový kód je umístěn v~Git repozitáři na adrese \url{https://git.microlab.space/pedf/ucitelonline/}.
\section{Návrhy pro rozšíření systému}
V~praxi bylo zjištěno, že uživatelé, kteří neznají verzovací systém Git, mají problémy se jej naučit, obzvlášť v~prostředí, které vyžaduje rychlé zpracování změn. Systém by bylo dobré rozšířit o~jednoduchou webovou administraci, jež umožňuje nezkušeným uživatelům jednoduchou práci s~obsahem bez nutnosti hledání souborů ve stromové struktuře a znalosti jazyka Markdown. Částečně je tato funkcionalita poskytována systémem Gitea, jenž umožňuje jednodušší úpravy provádět přímo v~prohlížeči, ovšem uživatel musí stále znát a pracovat s~unikátnostmi jazyka Markdown a generátoru Zola.
Skript \ref{lst:git-hook-skript} pro automatické generování obsahu ze sekce \ref{kap:automaticke-generovani-obsahu} je možné rozšířit tak, aby byl schopen pracovat se vstupem z~Git hooku či se standardním vstupem \textit{stdin}, který by umožňoval využití skriptu univerzálně pro různé webové stránky, nikoliv jen specificky pro tuto implementaci. Skript by také bylo možné rozšířit o~jednoduché příkazy \texttt{echo}, které by oznamovaly stav, v~němž se skript nachází. Standardní výstup skriptu vyvolaný přes Git hook je přesměrován uživateli, jenž spustil příkaz \texttt{git push} a tím i samotný hook. Skript by poté informoval uživatele o~tom, zda právě stahuje změny na server, generuje statický obsah, či kopíruje soubory do kořenové složky web serveru. Z~důvodu zachování jednoduchosti skriptu nebyly tyto funkcionality implementovány.
\section{Vyhodnocení implementace vlastních rozšíření}
Do systému v~modelové implementaci byla přidána vlastní rozšíření, tedy filtry pro vkládání souborů a videí do obsahu stránky, viz \ref{kap:rozsireni-sablony}. Tyto filtry splňují původní požadavky, avšak jejich použití v~obsahu se vymyká původnímu principu jazyka Markdown: že obsah je čitelný i v~čistém textu. Pro vyvolání filtrů je třeba vyplňovat jejich různé atributy, což se může zdát nepřehledné někomu, kdo si fungování filtrů neprostudoval. Zároveň je pak obsah nepřenositelný do jiných systémů, které neumí tyto filtry zpracovat a v~nichž by se kód pro vyvolání filtrů v~takovém případě mohl interpretovat jako čistý text.
\section{Implementace rozšíření}

@ -8,241 +8,186 @@
% ===========================================================================
@techreport{rfc7764,
author = "Leonard, Sean",
howpublished = "Internet Requests for Comments",
institution = "Internet Engineering Task Force",
issn = "2070-1721",
journal = "IETF Documents",
month = "Mar",
author = {Leonard, Sean},
url = {Internet Requests for Comments},
institution = {Internet Engineering Task Force},
issn = {2070-1721},
journal = {IETF Documents},
month = {Mar},
number = 7764,
organization = "Internet Engineering Task Force",
publisher = "Internet Engineering Task Force",
title = "Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations",
type = "RFC",
url = "https://tools.ietf.org/html/rfc7764",
year = "2016"
organization = {Internet Engineering Task Force},
publisher = {Internet Engineering Task Force},
title = {Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations},
type = {RFC},
url = {https://tools.ietf.org/html/rfc7764},
year = {2016}
}
@online{slant,
author = "Slant",
cited = "2020-02-10",
title = "What are the best markup languages?",
url = "https://web.archive.org/web/20200210061112/https://www.slant.co/topics/589/~best-markup-languages",
year = "2020"
author = {Slant},
url = {https://web.archive.org/web/20200210061112/https://www.slant.co/topics/589/~best-markup-languages},
urldate = {2020-02-10},
title = {What are the best markup languages?},
year = {2020}
}
@manual{orgmanual,
author = "{The Org Mode Developers}",
publisher = "Network Theory Ltd.",
title = "The Org Manual",
year = "2020"
author = {{The Org Mode Developers}},
publisher = {Network Theory Ltd.},
title = {The Org Manual},
year = {2020}
}
@article{environment_for_literate_programming,
accepted = "2011-10-03",
acknowledgement = "",
author = "Schulte, Eric and Davison, Dan and Dye, Thomas and Dominik, Carsten",
bibdate = "2011-10-03",
coden = "JSSOBK",
day = "25",
issn = "1548-7660",
journal = "Journal of Statistical Software",
keywords = "",
month = "1",
number = "3",
pages = "1--24",
submitted = "2010-12-22",
title = "A Multi-Language Computing Environment for Literate Programming and Reproducible Research",
url = "http://www.jstatsoft.org/v46/i03",
volume = "46",
year = "2012"
accepted = {2011-10-03},
acknowledgement = {},
author = {Schulte, Eric and Davison, Dan and Dye, Thomas and Dominik, Carsten},
bibdate = {2011-10-03},
coden = {JSSOBK},
day = {25},
issn = {1548-7660},
journal = {Journal of Statistical Software},
keywords = {},
month = {1},
number = {3},
pages = {1--24},
submitted = {2010-12-22},
title = {A Multi-Language Computing Environment for Literate Programming and Reproducible Research},
url = {http://www.jstatsoft.org/v46/i03},
volume = {46},
year = {2012}
}
@online{pcmag_dynamic,
author = "{PC{ }Magazine}",
url = "https://web.archive.org/web/20170117040526/https://www.pcmag.com/encyclopedia/term/42199/dynamic-web-page",
cited = "2020-02-12",
title = "Definition of: dynamic Web page",
year = "2017"
author = {{PC{ }Magazine}},
url = {https://web.archive.org/web/20170117040526/https://www.pcmag.com/encyclopedia/term/42199/dynamic-web-page},
urldate = {2020-02-12},
title = {Definition of: dynamic Web page},
year = {2017}
}
@online{pcmag_static,
author = "{PC{ }Magazine}",
url = "https://web.archive.org/web/20200223095514/https://www.pcmag.com/encyclopedia/term/static-web-page",
cited = "2020-02-12",
title = "Definition of: static Web page",
year = "2020"
@misc{pcmag_static,
author = {{PC{ }Magazine}},
url = {https://web.archive.org/web/20200223095514/https://www.pcmag.com/encyclopedia/term/static-web-page},
urldate = {2020-02-12},
title = {Definition of: static Web page},
year = {2020}
}
@online{mozttfb,
author = "Hoffman, Billy",
date = "2013-09-26",
url = "https://moz.com/blog/improving-search-rank-by-optimizing-your-time-to-first-byte",
cited = "2020-02-12",
title = "Improving Search Rank by Optimizing Your Time to First Byte",
year = "2013"
@misc{mozttfb,
author = {Hoffman, Billy},
date = {2013-09-26},
url = {https://web.archive.org/web/20190416124447/https://moz.com/blog/improving-search-rank-by-optimizing-your-time-to-first-byte},
urldate = {2020-02-12},
title = {Improving Search Rank by Optimizing Your Time to First Byte},
year = {2013}
}
@online{financialtimes,
author = "Chadburn, Matt and Lahav, Gadi",
date = "2016-04-04",
url = "https://web.archive.org/web/20180929125709/http://engineroom.ft.com/2016/04/04/a-faster-ft-com/",
journal = "Financial Times",
cited = "2020-02-15",
title = "How slow websites damage publishers revenue",
year = "2016"
@misc{financialtimes,
author = {Chadburn, Matt and Lahav, Gadi},
date = {2016-04-04},
url = {https://web.archive.org/web/20180929125709/http://engineroom.ft.com/2016/04/04/a-faster-ft-com/},
journal = {Financial Times},
urldate = {2020-02-15},
title = {How slow websites damage publishers revenue},
year = {2016}
}
@online{nolatex,
author = "Ol{\v s}{\'a}k, Petr",
date = "1997-08-14",
url = "http://petr.olsak.net/ftp/olsak/bulletin/nolatex.pdf",
cited = "2020-03-10",
title = "Pro{\v c} nerad pou{\v z}{\'\i}v{\'a}m LaTeX",
year = "1997"
@misc{nolatex,
author = {Ol{\v s}{\'a}k, Petr},
date = {1997-08-14},
url = {http://petr.olsak.net/ftp/olsak/bulletin/nolatex.pdf},
title = {Pro{\v c} nerad pou{\v z}{\'\i}v{\'a}m LaTeX},
year = {1997}
}
@online{daringfireball,
author = "Gruber, John",
date = "2004-12-14",
url = "https://daringfireball.net/projects/markdown/",
cited = "2020-02-27",
title = "Markdown",
year = "2004"
author = {Gruber, John},
date = {2004-12-14},
url = {https://web.archive.org/web/20200227143926/https://daringfireball.net/projects/markdown/},
urldate = {2020-02-27},
title = {Markdown},
year = {2004}
}
@online{softpedia_generators,
author = "Cimpanu, Catalin",
date = "2015-05-22",
url = "https://news.softpedia.com/news/How-Static-Site-Generators-Work-482007.shtml",
journal = "Softpedia",
cited = "2020-03-16",
title = "How Static Site Generators Work",
year = "2015"
@article{softpedia_generators,
author = {Cimpanu, Catalin},
date = {2015-05-22},
url = {https://web.archive.org/web/20200316165614/https://news.softpedia.com/news/How-Static-Site-Generators-Work-482007.shtml},
journal = {Softpedia},
urldate = {2020-03-16},
title = {How Static Site Generators Work},
year = {2015}
}
@online{commonmark,
author = "MacFarlane, John",
url = "https://spec.commonmark.org/",
cited = "2020-03-22",
title = "CommonMark Spec",
year = "2019"
@misc{commonmark,
author = {MacFarlane, John},
url = {https://spec.commonmark.org/},
urldate = {2020-03-22},
title = {CommonMark Spec},
year = {2019}
}
@online{calomel_optimization,
author = "Calomel",
date = "2017-01-01",
url = "https://calomel.org/save_web_bandwidth.html",
cited = "2020-03-23",
title = "Webserver Optimization and Bandwidth Saving Tips",
year = "2017"
@misc{calomel_optimization,
author = {Calomel},
date = {2017-01-01},
url = {https://calomel.org/save_web_bandwidth.html},
urldate = {2020-03-23},
title = {Webserver Optimization and Bandwidth Saving Tips},
year = {2017}
}
@online{github_formal_markdown_spec,
author = "Mart{\'\i}, Vicent",
url = "https://github.blog/2017-03-14-a-formal-spec-for-github-markdown/",
cited = "2020-03-23",
title = "A formal spec for GitHub Flavored Markdown",
year = "2017"
@misc{github_formal_markdown_spec,
author = {Mart{\'\i}, Vicent},
url = {https://github.blog/2017-03-14-a-formal-spec-for-github-markdown/},
urldate = {2020-03-23},
title = {A formal spec for GitHub Flavored Markdown},
year = {2017}
}
@techreport{owasp2017,
author = "OWASP",
url = "https://owasp.org/www-pdf-archive/OWASP_Top_10-2017_(en).pdf.pdf",
institution = "OWASP",
journal = "OWASP Top Ten",
organization = "OWASP",
publisher = "OWASP",
series = "OWASP Top Ten",
title = "OWASP Top Ten 2017",
year = "2017"
}
@online{cve_wordpress,
author = "{CVE{ }Details}",
url = "https://www.cvedetails.com/product/4096/Wordpress-Wordpress.html",
cited = "2020-03-29",
organization = "CVE{ }Details",
title = "Wordpress : Vulnerability Statistics",
year = "2020"
}
@online{thehackernews_wordpress_1,
author = "Khandelwal, Swati",
date = "2020-02-17",
url = "https://thehackernews.com/2020/02/themegrill-wordpress-plugin.html",
cited = "2020-03-29",
journal = "The Hacker News",
title = "Critical Bug in WordPress Theme Plugin Opens 200,000 Sites to Hackers",
year = "2020"
}
@online{thehackernews_wordpress_2,
author = "Khandelwal, Swati",
date = "2019-12-13",
url = "https://thehackernews.com/2019/12/wordpress-elementor-beaver.html",
cited = "2020-03-29",
journal = "The Hacker News",
title = "Flaw in Elementor and Beaver Addons Let Anyone Hack WordPress Sites",
year = "2019"
}
@online{cve_php,
author = "{CVE{ }Details}",
url = "https://www.cvedetails.com/product/128/PHP-PHP.html",
cited = "2020-03-31",
organization = "CVE{ }Details",
title = "PHP : Vulnerability Statistics",
year = "2020"
}
@online{carsten_dominik,
author = "Dominik, Carsten",
date = "2008-11-06",
url = "https://orgmode.org/worg/org-quotes.html",
cited = "2020-04-15",
title = "Technical description in 24 words",
year = "2008"
}
@online{benchmarks_game,
author = "Gouy, Isaac",
url = "https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html",
cited = "2020-03-18",
title = "The Computer Language Benchmarks Game",
year = "2020"
}
@online{yahoo_optimization,
author = "Yahoo!",
url = "https://developer.yahoo.com/performance/rules.html",
cited = "2020-04-21",
title = "Best Practices for Speeding Up Your Web Site",
year = "2020"
}
@online{why_is_git_better_than_x,
author = "Chacon, Scott",
url = "http://z.github.io/whygitisbetter/",
cited = "2020-03-26",
title = "Why Git is Better than X",
year = "2009"
}
@online{problems_with_structuredtext,
author = "Goodger, David",
date = "2012-01-03",
url = "https://docutils.sourceforge.io/docs/dev/rst/problems.html",
cited = "2020-05-01",
title = "Problems With StructuredText",
year = "2012"
}
@article{ossanna1977troff,
author = "Ossanna, Joseph F and Kernighan, Brian W",
journal = "Bell Laboratories Computing Science Technical Report",
title = "Troff user{\rq}s manual",
volume = "54",
year = "1977"
author = {OWASP},
url = {https://owasp.org/www-pdf-archive/OWASP_Top_10-2017_\%28en\%29.pdf.pdf},
institution = {OWASP},
journal = {OWASP Top Ten},
organization = {OWASP},
publisher = {OWASP},
series = {OWASP Top Ten},
title = {OWASP Top Ten 2017},
year = {2017}
}
@misc{cve_wordpress,
author = {{CVE{ }Details}},
url = {https://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337},
organization = {CVE{ }Details},
title = {Wordpress : Vulnerability Statistics},
year = {2020}
}
@article{thehackernews_wordpress_1,
author = {Khandelwal, Swati},
date = {2020-02-17},
url = {https://thehackernews.com/2020/02/themegrill-wordpress-plugin.html},
journal = {The Hacker News},
title = {Critical Bug in WordPress Theme Plugin Opens 200,000 Sites to Hackers},
year = {2020}
}
@article{thehackernews_wordpress_2,
author = {Khandelwal, Swati},
date = {2019-12-13},
url = {https://thehackernews.com/2019/12/wordpress-elementor-beaver.html},
journal = {The Hacker News},
title = {Flaw in Elementor and Beaver Addons Let Anyone Hack WordPress Sites},
year = {2019}
}
@misc{cve_php,
author = {{CVE{ }Details}},
url = {https://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337},
organization = {CVE{ }Details},
title = {PHP : Vulnerability Statistics},
year = {2020}
}

@ -9,7 +9,7 @@
%%% a unsrt jsou standardní součástí latexových distribucí. Styl czplainnat
%%% je dodáván s touto šablonou a bibTeX ho hledá v aktuálním adresáři.
\bibliographystyle{csplainnat} %% Autor (rok) s českými spojkami
%\bibliographystyle{czplainnat} %% Autor (rok) s českými spojkami
% \bibliographystyle{plainnat} %% Autor (rok) s anglickými spojkami
% \bibliographystyle{unsrt} %% [číslo]
@ -18,7 +18,8 @@
%%% Vytvoření seznamu literatury. Pozor, pokud jste necitovali ani jednu
%%% položku, seznam se automaticky vynechá.
\bibliography{literatura}
%\bibliography{literatura}
\printbibliography
%%% Kdybyste chtěli bibliografii vytvářet ručně (bez bibTeXu), lze to udělat
%%% následovně. V takovém případě se řiďte normou ISO 690 a zvyklostmi v oboru.

Binary file not shown.

@ -28,13 +28,38 @@
%% kódování
\usepackage{textcomp} % speciální symboly pro kódování T1
\usepackage[utf8]{inputenc} % vstupní kódování v UTF-8
\usepackage[T1]{fontenc} % výstupní kódování v T1 (české znaky)
% toto není v LuaLaTeXu potřeba
% \usepackage[utf8]{inputenc} % vstupní kódování v UTF-8
% \usepackage[T1]{fontenc} % výstupní kódování v T1 (české znaky)
\usepackage[czech]{babel} % České řetězce a dělení slov
%% bibliografie
\usepackage[czech]{babel} % Česká bibliografie
\usepackage[authoryear,colon,sort,round]{natbib}
% \usepackage[authoryear,colon,sort,round]{natbib}
% BibLaTeX je udržovaný balíček
% kvůli chybě v Babelu je ale třeba toto:
% zdroj: https://tex.stackexchange.com/a/529993/2891
\usepackage{etoolbox}
\makeatletter
\newcommand\my@hyphen{-}
\patchcmd\select@language{-}{\my@hyphen }{}{\fail}
\makeatother
\usepackage[style=iso-authoryear]{biblatex} % literatura ve stylu IS0 690
\let\citep\parencite % kompatibilita s natbibovými makry
\addbibresource{literatura.bib} % musíme nahrát literaturu
\ifdefined\directlua
\usepackage{luavlna}% zamezit jednoznakovým předložkám na koncích řádků
\fi
% použít dagger jako symbol pro poznámky pod čarou
% https://tex.stackexchange.com/a/829/2891
\usepackage[symbol,perpage]{footmisc}
\renewcommand{\thefootnote}{\fnsymbol{footnote}}
\DefineFNsymbols*{myfootnote}{\dagger\ddagger*\S\P\|% pořadí symbolů pro poznámky
{**}{\dagger\dagger}{\ddagger\ddagger}}
\setfnsymbol{myfootnote}
%% Formátování podle předpisů PedF
% velikosti fontů jsou v základím nastavení správně
\usepackage[top=30mm, bottom=25mm, left=35mm, right=20mm]{geometry} % odsazení od okrajů
@ -62,8 +87,6 @@
\usepackage{paralist} % lepší enumerate a itemize
\usepackage{xcolor} % barevná sazba
\usepackage{xargs} % vlastni prikazy
\usepackage{longtable} % tabulky lze zalomit na více stránek a
% podpora poznámek pod čarou v tabulce
%%% Zdrojový kód
\usepackage{listings}
@ -74,41 +97,42 @@
showstringspaces=false,
tabsize=4,
breaklines=true,
escapeinside={\%(*}{*)},
extendedchars=true,
literate=
{á}{{\'a}}1
{č}{{\v{c}}}1
{ď}{{\v{d}}}1
{é}{{\'e}}1
{ě}{{\v{e}}}1
{í}{{\'i}}1
{ň}{{\v{n}}}1
{ó}{{\'o}}1
{ř}{{\v{r}}}1
{š}{{\v{s}}}1
{ť}{{\v{t}}}1
{ú}{{\'u}}1
{ů}{{\r{u}}}1
{ý}{{\'y}}1
{ž}{{\v{z}}}1
{Á}{{\'A}}1
{Č}{{\v{C}}}1
{Ď}{{\v{D}}}1
{É}{{\'E}}1
{Ě}{{\v{E}}}1
{Í}{{\'I}}1
{Ň}{{\v{N}}}1
{Ó}{{\'O}}1
{Ř}{{\v{R}}}1
{Š}{{\v{S}}}1
{Ť}{{\v{T}}}1
{Ú}{{\'U}}1
{Ů}{{\r{U}}}1
{Ý}{{\'Y}}1
{Ž}{{\v{Z}}}1
% literate=
% {á}{{\'a}}1
% {č}{{\v{c}}}1
% {ď}{{\v{d}}}1
% {é}{{\'e}}1
% {ě}{{\v{e}}}1
% {í}{{\'i}}1
% {ň}{{\v{n}}}1
% {ó}{{\'o}}1
% {ř}{{\v{r}}}1
% {š}{{\v{s}}}1
% {ť}{{\v{t}}}1
% {ú}{{\'u}}1
% {ů}{{\r{u}}}1
% {ý}{{\'y}}1
% {ž}{{\v{z}}}1
% {Á}{{\'A}}1
% {Č}{{\v{C}}}1
% {Ď}{{\v{D}}}1
% {É}{{\'E}}1
% {Ě}{{\v{E}}}1
% {Í}{{\'I}}1
% {Ň}{{\v{N}}}1
% {Ó}{{\'O}}1
% {Ř}{{\v{R}}}1
% {Š}{{\v{S}}}1
% {Ť}{{\v{T}}}1
% {Ú}{{\'U}}1
% {Ů}{{\r{U}}}1
% {Ý}{{\'Y}}1
% {Ž}{{\v{Z}}}1
}
\renewcommand{\lstlistingname}{Fig.} % Přejmenování popisků
\renewcommand{\lstlistlistingname}{Seznam ukázek zdrojového kódu} % Přejmenování názvu seznamu
\renewcommand{\lstlistingname}{Program} % Přejmenování popisků
\renewcommand{\lstlistlistingname}{Seznam programů} % Přejmenování názvu seznamu programů
%%% vlastní poznámky
@ -134,46 +158,47 @@
% Rok odevzdání
\def\RokOdevzdani{2020}
\def\DatumOdevzdani{4. května}
% Název katedry nebo ústavu, kde byla práce oficiálně zadána
% (dle Organizační struktury MFF UK, případně plný název pracoviště mimo MFF)
\def\Katedra{Katedra informačních technologií a technické výchovy}
\def\KatedraEN{Name of the department}
% Jedná se o katedru (department) nebo o ústav (institute)?
\def\TypPracoviste{Katedra}
\def\TypPracovisteEN{Department}
% Vedoucí práce: Jméno a příjmení s~tituly
\def\Vedouci{PhDr. Josef Procházka, Ph.D.}
% Pracoviště vedoucího (opět dle Organizační struktury MFF)
\def\KatedraVedouciho{Katedra informačních technologií a technické výchovy}
\def\KatedraVedoucihoEN{}
% Studijní program a obor
\def\StudijniProgram{Specializace v~pedagogice}
\def\StudijniProgram{Specializace v pedagogice}
\def\StudijniObor{Informační technologie se zaměřením na vzdělávání}
% Nepovinné poděkování (vedoucímu práce, konzultantovi, tomu, kdo
% zapůjčil software, literaturu apod.)
\def\Podekovani{%
Děkuji především svému vedoucímu PhDr. Josefu Procházkovi, Ph.D. za všestrannou podporu během všech fází zpracování této práce, především pak za jeho vstřícnost, trpělivost a pochopení.
Mou povinností je také poděkovat Lukáši Hozdovi za jeho technickou a odbornou asistenci se statickými generátory a se sázením samotné práce, a dále také Bc. Janu Vaisovi za jeho cenné rady k~sázení a k~obecnému psaní závěrečnách prací.
Dále musím poděkovat Vítu Matějíčkovi, Albertu Pospíšilovi a Dawidu Kubiśovi za pomoc s~překlady, korekturou a za obecné rady k~obsahu. Také děkuji Ing. Emilu K. Mironovovi, Ph.D. za pomoc s~formální úpravou.
Na závěr děkuji partnerce a rodině za podporu během psaní této práce.
Děkuji hlavně svému vedoucímu, doktoru Procházkovi, který mě vždy nasměroval správnou cestou a měl se mnou trpělivost. Velmi děkuji Lukáši Hozdovi za jeho technickou a odbornou asistenci se statickými generátory a se sázením samotné práce, a dále také Honzovi Vaisovi za jeho cenné rady k sázení a k obecnému psaní závěrečnách prací. Také děkuji Albertu Pospíšilovi za jeho pomoc s překlady a korekturou. Dále pak děkuji partnerce, členům spolku \textit{microlab} a ostatním za podporu a pomoc při tvorbě práce.
}
% Abstrakt (doporučený rozsah cca 80-200 slov; nejedná se o zadání práce)
\def\Abstrakt{%
Bakalářská práce pojednává o~problematice statických webových stránek a jejich gene\-rátorů. Popisuje nejčastěji používaná webová paradigmata, generátory a značkovací jazyky, které se ke psaní obsahu těchto stránek používají. Součástí práce je i taxonomie požadavků a jejich modelová implementace ve formě celého systému pro generování statických webových stránek, včetně optimalizace a implementace vlastních rozšíření a verzovacího systému pro správu obsahu. V~závěrečné části je modelová implementace vyhodnocena na základě dříve zmíněných požadavků a poznatků z~předchozí části práce.
Abstrakt.
}
\def\AbstraktEN{%
This bachelor's thesis deals with static websites and static web generators. It describes the most used website paradigms, static web generators and typesetting languages, which are used as source files for the content of the website. A~part of the thesis is dedicated to the taxonomy of requirements for a specific website and its actual implementation with optimizations, implementations of custom extensions and a Content Management System. The last part of the thesis evaluates the created implementation according to the given requirements and findings from the first part.
Abstract.
}
% 3 až 5 klíčových slov (doporučeno), každé uzavřeno ve složených závorkách
\def\KlicovaSlova{%
{www}, {web}, {statický}, {generátor}
{www} {web} {generátor}
}
\def\KlicovaSlovaEN{%
{www}, {web}, {static}, {generator}
{www} {web} {generator}
}
%% Balíček hyperref, kterým jdou vyrábět klikací odkazy v PDF,
@ -194,7 +219,6 @@ This bachelor's thesis deals with static websites and static web generators. It
\tableofcontents
%%% Jednotlivé kapitoly práce jsou pro přehlednost uloženy v samostatných souborech
\include{uvod}
\include{kap-generatory}

@ -1,8 +1,7 @@
%%% Titulní strana práce a další povinné informační strany
%%% Titulní strana práce
\addtocontents{toc}{\protect\thispagestyle{empty}}
\pagenumbering{arabic}
\pagestyle{empty}
\hypersetup{pageanchor=false}
@ -61,14 +60,24 @@ Praha \RokOdevzdani
\openright
\hypersetup{pageanchor=true}
\pagestyle{plain}
\pagenumbering{roman}
\vglue 0pt plus 1fill
\noindent
Odevzdáním této bakalářské práce na téma \NazevPrace{} potvrzuji, že jsem ji vypracoval pod vedením vedoucího práce samostatně za použití v~práci uvedených pramenů a literatury. Dále potvrzuji, že tato práce nebyla využita k~získání jiného nebo stejného titulu.
Prohlašuji, že jsem tuto bakalářskou práci vypracoval(a) samostatně a výhradně
s~použitím citovaných pramenů, literatury a dalších odborných zdrojů.
\medskip\noindent
Beru na~vědomí, že se na moji práci vztahují práva a povinnosti vyplývající
ze zákona č. 121/2000 Sb., autorského zákona v~platném znění, zejména skutečnost,
že Univerzita Karlova má právo na~uzavření licenční smlouvy o~užití této
práce jako školního díla podle §60 odst. 1 autorského zákona.
\vspace{10mm}
\hbox{\hbox to 0.5\hsize{%
Praha, \DatumOdevzdani{} \RokOdevzdani
V ............ dne ............
\hss}\hbox to 0.5\hsize{%
Podpis autora
\hss}}
@ -79,12 +88,10 @@ Podpis autora
%%% Poděkování
\openright
\vglue 0pt plus 1fill
\noindent
\Podekovani
\vspace{20mm}
\newpage
%%% Povinná informační strana bakalářské práce
@ -95,28 +102,44 @@ Podpis autora
\setlength\parindent{0mm}
\setlength\parskip{5mm}
{\Large\bfseries Abstrakt}
Název práce:
\NazevPrace
\Abstrakt
Autor:
\AutorPrace
\vspace{4mm}
\TypPracoviste:
\Katedra
Vedoucí bakalářské práce:
\Vedouci, \KatedraVedouciho
{\Large\bfseries Klíčová slova}
Abstrakt:
\Abstrakt
Klíčová slova:
\KlicovaSlova
\vss}\nobreak\vbox to 0.49\vsize{
\setlength\parindent{0mm}
\setlength\parskip{5mm}
{\Large\bfseries Abstract}
Title:
\NazevPraceEN
\AbstraktEN
Author:
\AutorPrace
\vspace{4mm}
\TypPracovisteEN:
\KatedraEN
Supervisor:
\Vedouci, \KatedraVedoucihoEN
{\Large\bfseries Keywords}
Abstract:
\AbstraktEN
Keywords:
\KlicovaSlovaEN
\vss}
@ -124,3 +147,6 @@ Podpis autora
\newpage
\openright
\pagestyle{plain}
\pagenumbering{arabic}
\setcounter{page}{1}

@ -1,25 +1,3 @@
\chapter{Úvod}
\pagestyle{plain}
\chapter*{Úvod}
\addcontentsline{toc}{chapter}{Úvod}
Od statických stránek, které se používaly při vzniku WWW\footnote{World Wide Web -- Celosvětová síť pro prohlížení, ukládání a sdílení dokumentů}, se trend posunul ke složitým webovým aplikacím a frameworkům, jako jsou například Wordpress, Joomla, nebo Drupal. Dnes se opět trend obrací směrem ke tvorbě statických webových stránek, které jsou mnohem lepší z~hlediska rychlosti a bezpečnosti.
Práce se zabývá problematikou generátorů statických webových stránek. Za statické webové stránky se považují stránky, jejichž obsah je předem vygenerován do HTML\footnote{Hypertext Markup Language -- Sázecí jazyk používaný k~popisu obsahu a struktury webové stránky} pomocí daného generátoru, tedy programu, který z~obsahu napsaného v~libovolném značkovacím jazyce vygeneruje validní webovou stránku.
\section{Cíle práce}
Hlavním cílem práce je vysvětlit čtenáři fungování a sestavení automatizovaného systému pro generování statických webových stránek. Čtenář porozumí problematice sta\-tických webových stránek, jejich generátorů, značkovacích jazyků a implementaci těchto konceptů prakticky v~modelové implementaci. Tento hlavní cíl je dále rozpracován cíli dílčími:
\begin{itemize}
\item seznámit čtenáře se systémy pro generování statických webů,
\item analyzovat základní funkce mapovaných systémů,
\item sestavit taxonomii požadavků na systém pro generování statického webu,
\item navrhnout modelovou implementaci s~užitím vybraného systému,
\item vyhodnotit funkce daného systému a navrhnout jeho rozšíření.
\end{itemize}
\section{Struktura práce}
Struktura práce je koncipována do čtyř základních částí; v~první části je pojednáváno o~konceptu statických webových stránek, jejich výhodách a o~roli statických generátorů. Další část navazuje analýzou nejčastějších webových paradigmat, která se ve světe WWW objevují, a jsou v~ní vybrány nejvhodnější systémy pro generování jejich static\-kého obsahu. Dále následuje kapitola pojednávající o~nejběžnějších značkovacích jazycích, kterými je popisován obsah pro vybrané generátory.
V~další, praktické části jsou definována kritéria požadavků pro modelovou implementaci, která je poté realizována včetně ukázek kódu a popisu celého principu fungování systému. V~závěrečné kapitole je modelová implementace vyhodnocena a jsou zde určeny návrhy na její další rozšíření.

@ -1,14 +1,2 @@
\chapter*{Závěr}
\addcontentsline{toc}{chapter}{Závěr}
Cílem práce bylo analyzovat a zhodnotit generátory statických webových stránek a jimi využívaných značkovacích jazyků. Součástí bylo také vytvoření modelové implementace, její rozšíření, optimalizace a celkové zhodnocení.
Z~práce plyne, že statické webové stránky jsou bezpečnější a rychlejší než dynamické webové aplikace. Nehodí se ovšem pro některá specifická paradigmata. Zároveň je práce s~nimi bez pomocných nástrojů složitější hlavně pro uživatele, kteří chtějí do obsahu přispívat a kteří zároveň neumí pracovat s~verzovacími systémy. Na druhou stranu je jejich údržba méně složitá v~roli serverového administrátora.
K~určení nejběžnějších webových paradigmat bylo přistoupeno analýzou nejběžněji se vyskytujících typů webových stránek. Pro každé paradigma byly vybrány statické gene\-rátory, které jsou ke generování daného typu stránek nejvhodnější, nebo bylo určeno, že dané paradigma není pro statické generátory vhodné.
Na základě obecných a specificky zadaných požadavků byla sestavena taxonomie požadavků pro modelový web, podle kterého byl modelový systém úspěšně vytvořen. Do systému byla dle požadavků implementována i vlastní rozšíření s~cílem nahradit chybějící funkcionalitu vybraného generátoru. Systém se podařilo ze značné části optimalizovat, přičemž byly vytvořeny návrhy na další možnou optimalizaci.
Vyhodnocení modelové implementace popisuje možná vylepšení systému a jeho nedostatky, z~nichž nejzásadnější je složitý systém úprav obsahu a nutná znalost značkovacího jazyka Markdown, specifických rozšíření a verzovacího systému Git.
Práce dokazuje, že při vhodné kombinaci značkovacího jazyka, generátoru, verzovacího systému, skriptů pro automatizaci a pomocných nástrojů je možné vytvořit bezpečný a rychlý systém pro generování statických webových stránek. S~rapidním vývojem softwaru v~této oblasti může být situace v~budoucnu velmi odlišná.