.htaccess vs web.config

Struktura základního nette .htaccess je následující:

# disable directory listing
Options -Indexes

# mod_rewrite

RewriteEngine On
#RewriteBase /

# front controller
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule !\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$ index.php [L]

Abychom rozjeli routování a přepisování na naše velmi cool URLs musíme tento .htaccess soubor portovat na soubor web.config, který používá IIS. Výše zmíněný .htaccess převedený do web.config by měl vypadat následovně:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Nette App Rule">
<match url="^\.(pdf|js|ico|gif|jpg|png|css|rar|zip|tar\.gz)$" ignoreCase="false" negate="true" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" pattern="" ignoreCase="false" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" pattern="" ignoreCase="false" />
</conditions>
<action type="Rewrite" url="index.php/{R:1}"/>
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>

Tento soubor pak uložíme do stejného adresáře, kde se nachází .htaccess, často to bývá adresář document_root.

Trochu na vysvětlenou

Jak je jistě vidět, web.config je XML soubor definující všechno možné. Nastavení přepisovaných URL je v sekci <rewrite>. Tato sekce obsahuje sobor pravidel (<rules>), každé jako samostatný tag (<rule>) uvnitř kterého mohou být podmínky (<conditions>), jsou zde specifikovány URL adresy, které vyhovují danému pravidlu (<match>) a také jiné URL adresy, na které se mají vyhovující URL přepsat (<action>).

Samotná dokumentace pro strukturu souboru web.config nejspíš neexistuje, jelikož, jak praví můj kamarád – windowsový adminisrátor a znalec prostředí .NET – programátoři by vůbec neměli do web.config ručně zasahovat, takže Microsoft nepovažoval za nutné k tomuto souboru vytvářet dokumentaci. Pokud budete úspěšnější než já a podaří se vám něco o web.config vygooglit, nebojte se o své tipy podělit v komentáři.

V tomto článku si povíme kdy a jak správně uvolňovat objekty, které používáme, představíme si objective-c property a vysvětlíme si různé typy, kterými property pracují s pamětí. Na závěr si povíme něco o automatickém uvolňování paměti (nikoliv o garbage collectoru).

Retain Count – počítáme reference

Práce s pamětí v objective-c a Cocoa frameworku je založena na počítání referencí (odkazů) na objekty. To znamená, že pokud si vytvoříme nějaký objekt – jsme jeho vlastníkem – zvýší se jeho počet referencí (retain count nebo také reference count) o číslo 1. Pokud tento objekt již nechceme používat, naznačíme to tím, že jeho retain count opět snížíme. Jakmile počet referencí objektu dosáhne hodnoty 0, objekt bude automaticky odalokován. Ale pozor! Ne vždy jsme vlastníkem objektu, přestože ho používáme.

Vlastnictví objektů

• Vlastníkem objektu jsme tehdy, pokud ho sami vytvoříme. Objekty se vytváří pomocí metod začínajících na alloc, new nebo metod obsahujících slovo copy (např. alloc, newObject, mutableCopy)
• Vlastnictví objektu se dá získat také prostřednictvím metody retain, o které si povíme za chvíli
• Pokud jsme vlastníky objektu, jsme zodpovědní za jeho uvolnění (relinquishing ownership) – typicky pomocí metod release, či autorelease
• Naproti tomu, pokud objekt nevlastníme, nesmíme ho uvolňovat

Několik příkladů vytvoření objektů:

NSString *message = [[NSString alloc]
                      initWithString:@"Toto je muj retezec."];
NSString *copiedMessage = [message copy];
copiedMessage = @"Tento retezec je take muj!";
 
NSLog(message);
NSLog(copiedMessage);
 
[message release];
[copiedMessage release]

Doplňme tedy, že při vytvoření objektu se automaticky nastaví retain count na hodnotu 1. Metoda release nedělá nic jiného, než že tuto hodnotu opět sníží (vlastně dělá ještě něco jiného – vrací self, tzn. objekt, jehož reference count byl snížen).

Vypůjčené objekty

Ptáte se nyní, jakéže jsou ty objekty, které používáme ale nevlastníme je?
Jejich vytváření mají na starosti třídní metody (tzv. Convenience Methods). To jsou metody, které většinou na začátku svého jména specifikují datový typ, který vrací v návratové hodnotě. Tedy například u třídy NSString to může být stringWithString:, u třídy NSDate date u NSArray arrayWithObjects: a mnoho dalších. U těchto objektů nejsme vlastníky, třída je pro nás vytvoří a předá nám pouze referenci (odkaz na paměť), kde se tento objekt vyskytuje. Jelikož si ho třída vytvořila sama, tak se také sama postará o jeho správné uvolnění.

NSString *message = [NSString
                     stringWithString:@"Tento retezec nevlastnim ja."];
message = @"Ale ja chci svuj retezec...";
 
NSString *myOwnMessage = [message retain];
myOwnMessage = @"Jupi, ted mam svuj vlastni retezec";
message = @"A muzu si obsah sveho vlastniho retezce zmenit i v promenne message";
 
NSLog(message);
NSLog(myOwnMessage);
 
[myOwnMessage release];
// nikoliv [message release]

Pro úplnost se ještě podíváme na následující ukázku kódu :

NSString *myString = [[NSString alloc] initWithString: @"tohle je muj retezec"];
NSString *mySecongString = [[NSString
                             stringWithString:@"tenhle je taky muj"] retain];
 
//naproti tomu
NSString *aString = [NSString stringWithString:@"tenhle retezec ale neni muj"];
NSString *aSecondString = [[[NSString alloc]
                            initWithString: @"a tenhle rovnez neni muj"] autorelease];
 
[myString release];
[mySecondString release];

Z posledního ukázkového kódu by mělo být také zřejmé, jaký je význam použitých metod.

• Metoda retain zvyšuje čítač referencí u daného objektu (pro lepší použitelnost opět vrací self).
• Metoda autorelease dělá velmi podobnou věc, jako metoda release, akorát s tím rozdílem, že čítač referencí sníží až někdy později, automaticky.

Ddy se teda uvolní objekty, kterým jsme zaslali zprávu autorelease, to se dozvíme až, si budeme povídat o NSAutoreleasePool.

Objective-C 2.0 Property to vyřeší za nás

Možná znáte property z jiných programovacích jazyků, jako například z C#, či Javy. Možná netušíte, co to property jsou – jsou to prostě gettery a settery.

Nastavení property nikdy nebylo jednodušší

Objective-C 2.0 nám umožňuje definovat tyto metody, aniž bychom museli mít přímo jejich implementaci ve zdrojovém kódu. Můžeme si zvolit jakým způsobem tyto metody budou zacházet s pamětí privátních proměnných – jestli zvýší retain count nebo zkopírují celý objekt do nového, či jen přiřadí ukazatel na adresu. A jak na to?

Retain, copy, assign, nonatomic nebo readonly …?

Nejdůležitější nastavení je potřeba učinit při definici property v hlavičkovém souboru – klíčovým slovem @property. Syntaxe je následující:

@property [(attribute [, attribute2, ...])] type name;

Pak už jen stačí v souboru s implementací říct kompilátoru slovíčkem @synthesize, ať se o vše postará sám.

Právě význam volitelných atributů je potřeba si pořádně vysvětlit – určitě jste se už setkali s definicí jako @property (nonatomic, retain) ... ale je nutno zdůraznit že toto není zdaleka jediný a ne vždy ten nejlepší způsob, jak bychom mohli své property definovat.

Atributy a správa paměti

Z hlediska správy paměti máme celkem 3 možnosti, jak se můžou vygenerované settery chovat:

• assign
  obyčejné přiřazení – tímto atributem říkáme, že do privátní proměnné se má přiřadit adresa objektu, kterým nastavujeme hodnotu (parametr setteru), ale retain count není zvýšen. Toto je defaultní typ, který se použije, když nespecifikujeme žádný atribut, a většinou  je toto chování pro nás nežádoucí, ale například property dataSource a delegate pro UITableView právě tento přístup k paměti používají.
• retain
  říká, že setter přiřadí adresu objektu ke do privátní proměnné a zároveň zvýší její retain count pomocí metody retain. Díky tomu objekt může s proměnnou pracovat tak dlouho, dokud si ji sám neuvolní. Ale pozor, pracujeme pořád se stejnou adresou, takže pokud objekt, který jsme do proměnné přiřadili, někdy později změní svoji hodnotu, projeví se to i v instanční proměnné. Tento způsob používáme nejčastěji.
• copy
  pokud potřebujeme zajistit, aby hodnotu privátní proměnné nebylo možné měnit z vnějšku, specifikujeme právě tento atribut. Který namísto metody retain zavolá na proměnnou metodu copy, čímž zkopíruje obsah přiřazovaného objektu na jiné paměťové místo a tím tak zajistí nezávislost na původním objektu.

Vygenerované settery mohou vypadat zhruba následovně:

// @property NSString *string;
-(void)setString:(NSString *)newString {
    if (string != newString) {
        string = newString;
    }
} 
 
// @property (retain) NSString *string;
-(void)setString:(NSString *)newString {
    if (string != newString) {
        [string release];
        string = [newString retain];
    }
} 
 
// @property (copy) NSString *string;
-(void)setString:(NSString *)newString {
    if (string != newString) {
        [string release];
        string = [newString copy];
    }
}

Pokud od getterů, či setterů vyžadujeme, musíme si je už definovat sami.

Property umožňují definovat více atributů, než jen výše uvedené. Například nonatomic, či readonly. Ale jelikož tyto se přimo netýkají správy paměti, nebudu se o nich zde zmiňovat.

Automatické uvolnění paměti

Položili jste si někdy otázku jaký je rozdíl mezi release a autorelease? Cože tam má jedna metoda automatického a druhá ne? Odpovědí je NSAutoreleasePool.

Hromádka odložených objektů

Autorelease pool je vlastně jakýsi manažer paměti, který se stará právě o ty objekty, kterým zašleme autorelease namísto release. Všechny takovéto objeky se umístí do tohoto uložitě a fyzicky se uvolní až tehdy, když je uvolněn samotný objekt NSAutoreleasePoolu. Všimli jste si, že v aplikaci používate autorelease ale přitom jste nikde instanci třídy NSAutoreleasePool nevytvářeli? Tak se podívejte do souboru main.m kteréhokoliv XCode projektu iPhonové aplikace. Autorelease poolů se ale vytváří bez našeho vědomí více. Application Kit automaticky vytváří pooly při začátku cyklu událostí (event cycle, či event-loop). Zde se zachytávají například události generované při kliknutí na prvek GUI a ostatní vnitřní záležitosti dějící se v aplikaci. Na konci tohoto event-loopu je pool zase automaticky uvolněn.

Můžu si vytvořit své vlastní samouvolňovací jezírko?

Samozřejmě, že ano. A v některých situacích je to dokonce velmi vhodné, až nezbytné. Při vývoji iPhonových aplikací je to typicky, když:

1. používáme svá vlastní vlákna.
   Každé vlákno musí obsahovat autorelease pool. Nejčastěji si programátor vytvoří tento pool na začátku metody běžící ve vláknu a na konci metody pool zase uvolní. A pokud byste na to náhodou zapomněli nezoufejte, konzole vás na to upozorní hromadou krásných varování končících nějak podobně jako “object is just leaking”.
2. pokud v kódu máme cyklus vytvářející hodně pomocných objektů.
   Pokud máme cyklus a v každé iteraci potřebujeme vytvořit hodně pomocných objektů, může se hodit ušetřit paměť pomocí vytvoření autorelease poolu na začátku iterace cyklu a na konci iterace ho zase uvolnit. Docílíme tak uvolnění paměti hned jak ji skutečně nepotřebujeme, nikoliv akumulování a čekání až skončí event-loop případně jiný pool. Úplně ideální je uvolnit pool ne při každém průchodu, ale třeba jen v každé sté iteraci. To lze vyřešít jednoduchou if podmínkou.

Při vytváření vlastních poolů platí pravidlo, že pool se uvolňuje ve stejné oblasti viditelnosti (scope) jako byl vytvořen, tedy vytvoříme-li ho na začátku metody, na konci ho uvolňíme, vytvoříme-li ho uvnitř cyklu, před koncem cyklu uvolníme atp.

Doporučuji k přečtení

Ačkoliv tento článek je docela obsáhlý, poskytuje jen tu nejnutnější množinu potřebných znalostí. Pokud chcete umět opravdu dobře zacházet s pamětí v Cocoa objective-c, doporučuji prostudovat si následující zdroje.

• The Objective-C 2.0 Programming Language
• Memory Management Programming Guide for Cocoa

Co je to Bash?

Jsem uživatelem operačního systému Mac OS X a tudíž můžu s výhodou použít mocného nástroje zvaného Bash. K tomuto nástroji se dostaneme spuštěním aplikace Terminál. Vyskočí na vás sice jen černé nic neříkající okno, ale nenechte se odradit, v tuto chvíli se opravdu stáváte pánem (paní) svého počítače. Terminál totiž dokáže poslouchat příkazy, které mu zadáte, a podle nich udělat snad vše, na co si vzpomenete – a ještě mnohem víc. Stačí tedy jen vědět, co mu chcete přikázat.

Zálohování souborů pomocí terminálu

Jakožto bývalý uživatel Linuxu jsem stále ještě docela zběhlý v používání příkazové řádky (terminálu) a používám ji velmi rád. Je prostě rychlejší a mocnější.

Obvykle jsem zálohoval svá data vždy jednou za čas, když se mi prostě chtělo. Většinou jsem to dělal posloupností několika příkazů. Dejme tomu, že jsem si chtěl zálohovat složku se svými dokumenty do školy.

tar czf `date +"%Y-%d-%m"`.School.tar.gz School
mv [[datum]].School.tar.gz ~/Backup/

A poté jsem si chtěl zálohovat další složku, například veškerou svoji práci.

tar czf `date +"%Y-%d-%m"`.School.tar.gz School
mv [[datum]].School.tar.gz ~/Backup/

Jde to i jednodušeji – skriptováním

Skriptování zní jako něco velmi složitého, určeného pouze těm divným lidem, kteří rozumí jedničkám a nulám. Ale ve skutečnosti to vůbec složité není. Skript v Bashi je jen posloupnost příkazů – nemusíte je psát každý zvlášť, ale zapíšete si je všechny do jednoho souboru a ten si poté spustíte. Jak jednoduché…

Konečně řešení

Takže jsem nelenil, využil chvilky volnějšího času a pustil se do skriptování. Mým cílem bylo vytvořit skript, kterému pouze předám soubory, které chci zálohovat, a on se již o vše ostatní postará. Pojmenoval jsem si ho backup.sh.

#!/bin/bash
 
backupStorage=/Users/jirka/Backup/
 
# print usage info
usage() {
    echo -e "`basename $0` usage:"
    echo -e "`basename $0` backup_file [ backup_file, ... ]"
    echo -e "`basename $0` default backup storage is '$backupStorage'"
}
 
# do backup by creating tar.gz file and place it into desired folder
# arg1: path to file to backup
# arg2: path where to place backuped file
backup() {
    if [ $# -lt 2 ] && ([ ! -f $1 ] || [ ! -d $i ]) || [ ! -d $2 ]; then
        echo -e "$@"
        usage $@
        exit 4
    fi
    date=`date +"%Y-%m-%d"`
    fileName=`basename $1`.tar.gz
 
    echo $fileName
    tar czf /tmp/$fileName $1
 
    if [ ! -d $2$date ]; then
        mkdir $2$date
    fi
 
    mv /tmp/$fileName $2$date
}
 
# run the script
if [ ! -d $backupStorage ]; then
    echo -e "`basename $0`: backuping storage '$backupStorage' does not exist"
    exit 2
fi
 
if [ $# -lt 1 ]; then
    usage $@
    exit 2
fi
 
for i in $@; do
    if [ -f $i ] || [ -d $i ]; then
        backup $i $backupStorage
    else
        echo -e "`basename $0`: file '$i' does not exist"
    fi
done

Nyní si můžu jednoduše zálohovat své soubory jediným příkazem. Nesmím však zapomenout přidat soubor práva na spouštění.

chmod u+x backup.sh
./backup.sh School Work Photos Documents/ImportantFile.txt

Ve skriptu je pro uložení mých zálohovaných soborů nadefinována složka Backup v mém domovském adresáři. Po úspěšném ukončení skriptu se v ní vytvoří podsložka pojmenovaná podle aktuálního data a v ní všechny zálohované soubory zabalené do archivu tar.gz.

Zálohování skutečně automaticky

Ti bystřejší pochopili, že tohle stále ještě není automatické zálohovaní. Pořád tu musí být někdo, kdo celý skript spustí. Ale i tento problém se dá snadno vyřešit. Mac OS X nám totiž nabízí automatické spouštění skriptů a to v podstatě kdykoliv si usmyslíte – buďto jen určitý den v měsíci v určitou hodinu nebo třeba v pravidelných intervalech. Řekněme, že budeme chtít spouštět náš zálohovací skript každý týden. K tomuto účelu nám slouží složka /etc/periodic/weekly (v linuxu známá jako /etc/cron.weekly) Zde se umisťují skripty, které chceme, aby se automaticky spustily každý týden. Bohužel takovýto automatický skript neumí přijmout žádné parametry, takže je potřeba ještě malé úpravy – vytvoření dalšího skriptíku.

Chci si každý týden zálohovat své pracovní dokumenty, fotky a školu. Svůj skript jsem si umístil v domovském adresáři ve složce bin.

#!/bin/bash
/Users/jirka/bin/backup.sh /Users/jirka/School /Users/jirka/Work /Users/jirka/Photos
chown -R jirka:jirka /Users/jirka/Backup/`date +"%Y-%m-%d"`

Tento kód si uložíme do souboru a soubor umístíme do výše zmíněné složky (opět je nutné přidělit práva na spouštění pomocí příkazu chmod). Tohe už jsem ale netestoval, takže nemohu zaručit dokonalou funkčnost. Já si své zálohy budu spouštět kdy chci sám a hlavně si vyberu pokaždé různé soubory, které chci zálohovat.

Závěrem

Skript není dokonalý. Obsahuje pár nedostatků. Konkrétně, jméno zálohovaného souboru se zjišťuje podle posledního názvu v dané cestě k souboru. Například /Users/jirka/documents/soubor.txt bude zálohován jako soubor.txt.tar.gz. To tedy znamená, že pokud skriptu předáme dva různé soubory, které ale končí stejně, např. School/predmet1/prednaska.pdf a School/predmet2/prednaska.pdf, bude zálohován pouze jeden z nich – ten poslední.
Druhá nevýhoda je, že skript nefunguje správně pro soubory obsahující ve svém názvu mezery (na tohle už mé skriptovací schopnosti zřejmě nestačí).

Také je nutné upozornit, že zálohovaná data samozřejmě musí být jinde, než na počítači, který je zálohován. Takže na úplný závěr je potřeba si všechny soubory z zálohovacího uložiště skopírovat na flash disk, vypálit na CD, nebo jako backupStorage ve skriptu nadefinovat cestu k připojenému externímu disku. Externí disky na Mac OS X jsou vždy připojeny do složky /Volumes.

V tomto článku nastítím, jak probíhá instalace git serveru a vytváření vlastních repozitářů.

Instalace git serveru

Nejprve na linuxovém serveru nainstalujeme gitosis – software pro hostování git repozitářů. K tomu budeme potřebovat git a python, abychom mohli zdrojové kódy pomocí gitu stáhnout a pomocí pythonu je nainstalovat.

(Git nainstalujeme příkazem: sudo apt-get install git-core)

Stáhneme tedy nejnovější verzi gitosis

git clone git://eagain.net/gitosis.git

a nainstalujeme jej:

cd gitosis
sudo python setup.py install

Pokud při instalaci dostaneme chybu:

Traceback (most recent call last):
File "setup.py", line 2, in
from setuptools import setup, find_packages
ImportError: No module named setuptools

je třeba doinstalovat ještě python setuptools: sudo apt-get install python-setuptools

Vytvoření uživatele git

Nyní je potřeba vytvořit uživatele, který se o repozitáře bude starat. Přidáme tedy uživatele git, který bude mít domovský adresář ve /var/git.

sudo adduser \
    --system \
    --shell /bin/sh \
    --gecos 'git version control' \
    --group \
    --disabled-password \
--home /var/git \
git

Zinicializování uložiště pro repozitáře

Pro read-write přístup do repozitářů přes ssh potřebujeme ověření pomocí RSA klíče. Vytvoříme si tedy svůj klíč na domácím počítači a nahrajeme jej na server, kde běží gitosis. Pomocí tohoto klíče následně zinicializujeme základní uložiště pro naše budoucí repozitáře.

ssh-keygen -t rsa

Klíč se vytvoří v adresáři ~/.ssh/id_rsa.pub, zkopírujeme jej (ale musí zůstat i v .ssh/) například pomocí scp na git server a uložíme jako /tmp/id_rsa.pub

A zinicializujeme repozitáře:

sudo -H -u git gitosis-init

při úspěchu dostaneme výpis podobný následujícímu:

Initialized empty Git repository in /var/git/repositories/gitosis-admin.git/
Reinitialized existing Git repository in /var/git/repositories/gitosis-admin.git/

Nyní je vše připraveno a můžeme začít přidávat nové repozitáře a k nim jejich uživatele.

Ještě se ujistíme, že post-update hook má práva na spouštění, pokud ne, přidáme tyto práva příkazem:

sudo chmod a+x /var/git/repositories/gitosis-admin.git/hooks/post-update

Vytváření vlastních repozitářů

Nyní se můžeme odhlásit z SSH přistupu a náš repozitářový server ovládat vzdáleně. Jediné, co je potřeba, je stáhnout gitosis-admin repozitář, který se vytvořil při inicializaci. Předpokládejme, že náš server běží na IP adrese 192.168.0.100:

git clone git@192.168.0.100:gitosis-admin.git

V repozitáři je soubor gitosis.conf sloužící ke konfiguraci repozitářů, uživatelů a spousty dalšího. A složka keydir, kde jsou rsa klíče pro uživatele mající přístup k repozitářům. V současné době je zde jediný klíč a to ten, který jsme o pár řádků výše vygenerovali.

Pro přidání repozitáře si vytvoříme novou skupinu (foo), definujeme názvy repozitářů patřící do skupiny (položka writable) a uživatele, mající přístup ke všem repozitářům této skupiny (members).

[group foo]
writable = foorepo
members = ibru

Nyní je náš git server připraven pro repozitář s názvem foorepo. Vytvoříme tedy na našem lokálním počítači složku nebo můžeme přejít do složky s existujícími zdrojovými (nebo jakýmikoliv jinými) kódy. Nový repozitář vytvoříme sérií přikazů:

cd path/to/sources
git init
git remote add origin git@192.168.0.100:foorepo.git
# uděláme úpravy
git add .
git commit -a -m "inicializace repozitare"
git push origin master:refs/heads/master

Nyní je repozitář zcela hotov a můžeme k němu přistoupit pomocí

git clone git@192.168.0.100:foorepo.git

Přidávání uživatelů

Přidat nové uživatele je velmi jednoduché, stačí v konfiguračním souboru pro danou skupinu přidat jméno do řádku s “members = …” a do adresáře keydir přidat klíč vygenerovaný na počítači nového uživatele. Název souboru s klíčem je <jméno>.pub. Uživatel však svůj vygenerovaný klíč musí nechat i ve složce ~/.ssh/.

Můžeme tedy například přidat uživatele petr, který bude mít také právo přistupovat k repozitářům ve skupině foo:

[group foo]
writable = foorepo
members = ibru petr

a zkopírujeme klíč petr.pub do adresáře keydir

Nyní všechny změny commitneme na server:

git add keydir/petr.pub
git commit -a -m "pridani uzivatele petr do skupiny foo"
git push

Od této chvíle by užvatel petr měl být schopen ze svého počítače stáhnout repozitáře pomocí:

git clone git@192.168.0.100:foorepo.git

Další užitečná nastavení

V git serveru je možné nastavit ještě spoustu dalších možností. Jako například povolení read-only stáhnutí repozitářů i uživatelům, kteří nemají své rsa klíče na serveru. Případně webové rozhraní pro repozitáře. Toto nastavení už můj článek nezahrnuje, pro zájemce mohu dodporučit následující zdroje:

• gitosis readme – sekce git-daemon a gitweb
• Hosting Git repositories, The Easy (and Secure) Way – zde jsem čerpal já hlavní inspiraci pro tento článek