fixed typos after review

content/cs/admin-processes.md

@@ -9,6 +9,6 @@
 
 Jednorázové administrativní procesy by měly být spouštěny ve stejném prostředí jako běžné [dlouho běžící procesy](./processes) aplikace. Běží proti [vydání](./build-release-run) za použití stejného [kódu](./codebase) a [konfigurace ](./config) jako ostatní procesy daného vydání. Administrativní kód musí být dodáván spolu s aplikací, aby se zabránilo problémům se synchronizací.
 
-Stejné techniky [izolace závislostí](./dependencies) by měli být použity na všechny typy procesů. Například, pokud Ruby webový proces používá příkaz `bundle exec thin start`, tak databázová migrace by měla používat `bundle exec rake db:migrate`. Obdobně by pak měl program v Pythonu, využívající Virtualenv, používat přibalený `bin/python` pro spouštění jak Tornado webserveru, tak i pro spouštění `manage.py` administrativního procesu.
+Stejné techniky [izolace závislostí](./dependencies) by měly být použity na všechny typy procesů. Například, pokud Ruby webový proces používá příkaz `bundle exec thin start`, tak databázová migrace by měla používat `bundle exec rake db:migrate`. Obdobně by pak měl program v Pythonu, využívající Virtualenv, používat přibalený `bin/python` pro spouštění jak Tornado webserveru, tak i pro spouštění `manage.py` administrativního procesu.
 
-Twelve-factor metodika silně preferuje jazyky, které poskytují REPL shell v základu a umožňují tak snadno spouštět jednorázové skripty. V lokálním nasazení spouštějí vývojáři jednorázový administrativní proces příkazem přímo v shellu unvnitř repozitáže. V produkčním nasazení mohou vývojáři použít SSH nebo jiný způsob vzdáleného spouštění příkazů, který je v daném nasazení pro spouštění procesů k dispozici.
+Twelve-factor metodika silně preferuje jazyky, které poskytují REPL shell v základu a umožňují tak snadno spouštět jednorázové skripty. V lokálním nasazení spouštějí vývojáři jednorázový administrativní proces příkazem přímo v shellu uvnitř repozitáře. V produkčním nasazení mohou vývojáři použít SSH nebo jiný způsob vzdáleného spouštění příkazů, který je v daném nasazení pro spouštění procesů k dispozici.

content/cs/backing-services.md

@@ -3,7 +3,7 @@
 
 *Podpůrná* služba je jakákoliv služba, kterou aplikace konzumuje přes síť jako součást svého normálního běhu. Příklady zahrnují databáze (jako například [MySQL](https://dev.mysql.com/) nebo [CouchDB](https://couchdb.apache.org/)), messaging/queueing systémy (jako jsou [RabbitMQ](https://www.rabbitmq.com/) nebo [Beanstalkd](https://beanstalkd.github.io)), SMTP služby pro odchozí emaily (jako [Postfix](https://www.postfix.org/)) a cachovací systémy (jako je [Memcached](https://memcached.org/)).
 
-Podpůrné služby, jako například databáze, jsou obvykle spravovány stejnými systémovými inženýri jako samotné nasazení aplikace. K těmto lokálně spravovaným službám může aplikace navíc využívat služby provozované a spravované třetí stranou. To mohou být například SMTP služby (jako je [Postmark](https://postmarkapp.com/)), služby na sbírání metrik (jako [New Relic](https://newrelic.com/) nebo [Loggly](https://www.loggly.com/)), datová uložistě (jako [Amazon S3](https://aws.amazon.com/s3/)) a dokonce i služby přístupné přes API (jako jsou například [Twitter](https://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/) nebo [Last.fm](https://www.last.fm/api)).
+Podpůrné služby, jako například databáze, jsou obvykle spravovány stejnými systémovými inženýry jako samotné nasazení aplikace. K těmto lokálně spravovaným službám může aplikace navíc využívat služby provozované a spravované třetí stranou. To mohou být například SMTP služby (jako je [Postmark](https://postmarkapp.com/)), služby na sbírání metrik (jako [New Relic](https://newrelic.com/) nebo [Loggly](https://www.loggly.com/)), datová uložistě (jako [Amazon S3](https://aws.amazon.com/s3/)) a dokonce i služby přístupné přes API (jako jsou například [Twitter](https://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/) nebo [Last.fm](https://www.last.fm/api)).
 
 **Kód twelve-factor aplikace nedělá rozdíly mezi lokální službou a službou třetí strany.** Z pohledu aplikace jsou to připojené zdroje přístupné přes URL nebo jiné přístupové/přihlašovací údaje uložené v [konfiguraci](./config). Nasazení twelve-factor aplikace by mělo být schopné vyměnit lokální MySQL databázi za databázi spravovanou třetí stranou (jako je například [Amazon RDS](https://aws.amazon.com/rds/)) bez jakýchkoliv změn v aplikačním kódu. Obdobně může být lokální SMTP server nahrazen SMTP službou třetí strany (jako Postmark) bez změn v kódu. V obou případech se změní pouze přístupové a přihlašovací údaje v konfiguraci.
 

content/cs/build-release-run.md

@@ -15,5 +15,5 @@ Nástroje pro nasazení obvykle poskytují i správu vydání a zejména pak sch
 
 Každé vydaní by mělo mít vždy unikátní ID, jako je například časová značka ( `2011-04-06-20:32:17`) nebo inkrementální číslo (například `v100`). Vydání již nelze po vytvoření jakkoliv upravovat, libovolná změna musí vždy vytvořit nové vydání.
 
-Sestavení iniciují vývojáři aplikace, kdykoliv se nasazuje nový kód. Naopak ke spuštění v běhovém prostředí může dojít automaticky v případě restartu serveru nebo restartem havarovaného procesu pomocí správce procesů. Proto by měla mít fáze spuštění co nejméně pohyblivých částí, jelikož problémy bránící aplikaci v běhu mohou nastat uprostřed noci, kdy nejsou žádní vývořáji k dispozici. Fáze sestavení pak může být složitější, protože chyby jsou více na očích pro vývojáře kontrolující nasazení aplikace.
+Sestavení iniciují vývojáři aplikace, kdykoliv se nasazuje nový kód. Naopak ke spuštění v běhovém prostředí může dojít automaticky v případě restartu serveru nebo restartem havarovaného procesu pomocí správce procesů. Proto by měla mít fáze spuštění co nejméně pohyblivých částí, jelikož problémy bránící aplikaci v běhu mohou nastat uprostřed noci, kdy nejsou žádní vývojáři k dispozici. Fáze sestavení pak může být složitější, protože chyby jsou více na očích pro vývojáře kontrolující nasazení aplikace.
 

content/cs/codebase.md

@@ -9,7 +9,7 @@ Twelve-factor aplikace je vždy sledována ve verzovacím systému, jako je nap
 
 Vždy existuje korelace jedna-ku-jedné mezi zdrojovým kódem a aplikací: 
 
-* Pokud existuje více zdrojových kódů, nejedná se o aplikaci, ale o distribuovaný systém. Každá komponenta distibuovaného systému je dílčí aplikace, která může samostatně podléhat twelve-factor metodice.
+* Pokud existuje více zdrojových kódů, nejedná se o aplikaci, ale o distribuovaný systém. Každá komponenta distribuovaného systému je dílčí aplikace, která může samostatně podléhat twelve-factor metodice.
 * Více aplikací sdílejících stejný kód je porušení twelve-factor metodiky. Řešením je oddělení sdíleného kódu do knihovny, která se připojí pomocí [systému na správu závislostí](./dependencies).
 
 Každá aplikace má pouze jeden zdrojový kód, ale nasazení jedné aplikace bude vícero. *Nasazení* je běžící instance aplikace. Typicky je to produkční web a jeden nebo více testovacích webů. Každý vývojář má navíc lokální vývojovou kopii běžící aplikace, každou takovou kopii lze také považovat za nasazení.

content/cs/concurrency.md

@@ -9,6 +9,6 @@ Každý počítačový program se po spuštění prezentuje jako jeden nebo víc
 
 To nevylučuje, že si jednotlivé procesy nemohou spravovat interní multiplexování přes vlákna nebo pomocí async/event modelu, jako je tomu v [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](https://twistedmatrix.com/trac/) nebo [Node.js](https://nodejs.org/). Jednotlivé VM však mohou růst jen omezeně (vertikální škálování), aplikace tedy musí být schopná i běhu v několika procesech na více fyzických strojích.
 
-Proces model obvzlášť vyniká, když přijde čas na škálování. [Nesdílená a horizontálně dělitelná podstata procesů twelve-factor aplikace](./processes) znamená, že přidání větší souběžnosti je jednoduchá a spolehlivá operace. Sada typu procesů a množství procesů každého typu se nazývá *formace procesů*.
+Proces model obzvlášť vyniká, když přijde čas na škálování. [Nesdílená a horizontálně dělitelná podstata procesů twelve-factor aplikace](./processes) znamená, že přidání větší souběžnosti je jednoduchá a spolehlivá operace. Sada typu procesů a množství procesů každého typu se nazývá *formace procesů*.
 
 Procesy twelve-factor aplikace by [nikdy neměly démonizovat](https://dustin.github.com/2010/02/28/running-processes.html) nebo zapisovat PID soubory. Namísto toho by se měly spoléhat na správce procesů operačního systému (jako je například [systemd](https://www.freedesktop.org/wiki/Software/systemd/), správce distribuovaných procesů na cloudové platformě nebo nástroje typu [Foreman](https://blog.daviddollar.org/2011/05/06/introducing-foreman.html) během vývoje), který obstará [výstupní proudy](./logs), reakci na havarované procesy a obsluhu uživatelem vyvolaných restartů a zastavení.

content/cs/dependencies.md

@@ -7,6 +7,6 @@ Většina programovacých jazyků poskytuje balíčkovací systém pro distribuc
 
 Například [Bundler](https://bundler.io/) pro Ruby poskytuje `Gemfile` manifest formát pro deklaraci závislostí a `bundle exec` pro izolaci závislostí. Pro Python jsou to dva rozdílné nástroje, [Pip](https://www.pip-installer.org/en/latest/) je použit pro deklaraci závislostí a [Virtualenv](https://www.virtualenv.org/en/latest/) pro jejich izolaci. Dokonce i C má [Autoconf](https://www.gnu.org/s/autoconf/) pro deklaraci závislostí a statické linkování poskytuje izolaci závislostí. Nehledě na použitou sadu nástrojů, deklarace a izolace závislostí musí být vždy aplikovány společně, použití pouze jednoho nebo pouze druhého není dostatečné pro splnění podmínek twelve-factor metodiky.
 
-Jednou z výhod explicintní deklarace závislostí je to, že zjednodušuje počáteční rozběhnutí aplikace pro nové vývojáře. Nový vývojář si jen naklonuje repozitář aplikace do svého vývojového prostředí a jako prerekvizity mu postačí nainstalované běhové prostředí jazyka a příslušný správce závislostí. Vše potřebné pro rozběhnutí aplikace se zajistí deterministicky *build příkazem* . Například, build příkaz pro Ruby/Bundler je `bundle install`, pro Cloujure/[Leiningen](https://github.com/technomancy/leiningen#readme) je to `lein deps`.
+Jednou z výhod explicitní deklarace závislostí je to, že zjednodušuje počáteční rozběhnutí aplikace pro nové vývojáře. Nový vývojář si jen naklonuje repozitář aplikace do svého vývojového prostředí a jako prerekvizity mu postačí nainstalované běhové prostředí jazyka a příslušný správce závislostí. Vše potřebné pro rozběhnutí aplikace se zajistí deterministicky *build příkazem* . Například, build příkaz pro Ruby/Bundler je `bundle install`, pro Cloujure/[Leiningen](https://github.com/technomancy/leiningen#readme) je to `lein deps`.
 
 Twelve-factor aplikace se nespoléhají na implicitní existenci jakýchkoli systémových nástrojů. Příkladem může být spouštění ImageMagick nebo `curl` přes shell. I když tyto nástroje existují na mnoha a možná i většině aktuálně používaných systémů, neexistuje žadná záruka, že tyto nástroje budou existovat na systémech, kde aplikace poběží v budoucnu a nebo že budou na budoucích systémech dostupné v kompatibilní verzi. Pokud aplikace potřebuje spouštět nějaký nástroj přes shell, tak by měl být daný nástroj součástí aplikace.

content/cs/dev-prod-parity.md

@@ -27,7 +27,7 @@ Souhrn výše popsaného v tabulce:
  <td>Hodiny</td>
  </tr>
  <tr>
- <th>Autoři kódu vs ti kdo kód nasazují</th>
+ <th>Autoři kódu vs ti, kdo kód nasazují</th>
  <td>Rozdílní lidé</td>
  <td>Stejní lidé</td>
  </tr>
@@ -67,10 +67,10 @@ Souhrn výše popsaného v tabulce:
  </tr>
 </table>
 
-Vývojáři někdy rádi používají odlehčené varianty podpůrných služeb pro lokální vývoj, přesto že na produkci budou použity jejich plnohodnotné varianty. Například použití SQLite lokálně a PostgreSQL na produkci nebo lokální pamět použitá jako cache pro vývoj oproti Memcached v produkci.
+Vývojáři někdy rádi používají odlehčené varianty podpůrných služeb pro lokální vývoj, přestože na produkci budou použity jejich plnohodnotné varianty. Například použití SQLite lokálně a PostgreSQL na produkci nebo lokální pamět použitá jako cache pro vývoj oproti Memcached v produkci.
 
-**Twelve-factor vývojáři dokáží odolat nutkání používat rozdílné podpůrné služby ve vývojovém a produkčním prostředí**, i přesto že adaptéry teoreticky odstraňují jakékoliv rozdíly v podpůrných službách. Rozdíly mezi podpůrnými službami a drobné nekompatibility se vždy vynoří a způsobí, že kód který prošel testy ve vývojovém a testovacím prostředí pak nefunguje na produkci. Tento typ chyb způsobuje obtíže a odrazuje od průběžného nasazování. Náklady spojené s těmito obtížemi a následným útlumem v průběžném nasazování jsou velmi vysoké, zvažujeme-li je souhrně za celou dobu životnosti aplikace.
+**Twelve-factor vývojáři dokáží odolat nutkání používat rozdílné podpůrné služby ve vývojovém a produkčním prostředí** i přesto, že adaptéry teoreticky odstraňují jakékoliv rozdíly v podpůrných službách. Rozdíly mezi podpůrnými službami a drobné nekompatibility se vždy vynoří a způsobí, že kód který prošel testy ve vývojovém a testovacím prostředí pak nefunguje na produkci. Tento typ chyb způsobuje obtíže a odrazuje od průběžného nasazování. Náklady spojené s těmito obtížemi a následným útlumem v průběžném nasazování jsou velmi vysoké, zvažujeme-li je souhrně za celou dobu životnosti aplikace.
 
-Odlehčené varianty služeb jsou méně lákavé než bývaly dříve. Moderní podpůrné služby jako Memcached, PostgreSQL a RabbitMQ nejsou díky moderním balíčkovacím systémům jako [Homebrew](https://mxcl.github.com/homebrew/) a [apt-get](https://help.ubuntu.com/community/AptGet/Howto) složité na instalaci. Deklarativní nástroje pro provisioning, jako jsou například [Chef](https://www.opscode.com/chef/), či [Puppet](https://docs.puppetlabs.com/) v kombinaci s odlehčenými virtuálními prostředími typu [Docker](https://www.docker.com/) nebo [Vagrant](https://vagrantup.com/), umožňují vývojářům provozovat lokální vývojové prostředí, které velmi věrně odpovídá tomu produkčnímu. Cena za instalaci a provoz těchto systémů je poměrně nizká v porovnání s výhodami, které přináší podobnost vývoj/produkce a průběžné nasazování.
+Odlehčené varianty služeb jsou méně lákavé než bývaly dříve. Moderní podpůrné služby jako Memcached, PostgreSQL a RabbitMQ nejsou díky moderním balíčkovacím systémům jako [Homebrew](https://mxcl.github.com/homebrew/) a [apt-get](https://help.ubuntu.com/community/AptGet/Howto) složité na instalaci. Deklarativní nástroje pro provisioning, jako jsou například [Chef](https://www.opscode.com/chef/), či [Puppet](https://docs.puppetlabs.com/) v kombinaci s odlehčenými virtuálními prostředími typu [Docker](https://www.docker.com/) nebo [Vagrant](https://vagrantup.com/), umožňují vývojářům provozovat lokální vývojové prostředí, které velmi věrně odpovídá tomu produkčnímu. Cena za instalaci a provoz těchto systémů je poměrně nízká v porovnání s výhodami, které přináší podobnost vývoj/produkce a průběžné nasazování.
 
 Adaptéry pro různé podpůrné služby mají stále svůj význam, protože umožňují přechod na nové podpůrné služby poměrně bezbolestně. Všechna nasazení aplikace (vývojové, testovací a produkční) by však měla používat stejný typ a verzi každé podpůrné služby.

content/cs/disposability.md

@@ -8,8 +8,8 @@ Procesy by se měly snažit **minimalizovat čas spuštění**. Ideálně by pro
 
 Procesy **se korektně ukončí po přijetí signálu [SIGTERM](https://en.wikipedia.org/wiki/SIGTERM)** od správce procesů. Pro webový proces znamená korektní ukončení to, že přestane naslouchat na příslušném portu (tedy začne odmítat nové požadavky), aktuálně běžící požadavky zpracuje a pak se vypne. V tomto modelu předpokládáme, že HTTP požadavky jsou poměrně krátké (ne delší než pár sekund). V případě dlouho trvajícího spojení by se měl klient umět znovu sám připojit, dojde-li ke ztrátě spojení.
 
-Pro proces typu worker je korektní ukončení dosaženo vrácením aktuální úlohy zpět do pracovní fronty. Například v [RabbitMQ](https://www.rabbitmq.com/) může worker poslat [`NACK`](https://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack), u [Beanstalkd](https://beanstalkd.github.io) se úloha vrátí do fronty automaticky, pokud se worker odpojí. Systémy postavené na zamykání, jako například [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) musí uvolnit zámek pro záznam své úlohy. V tomto modelu předpokládáme, že všechny úlohy jsou [opakovatelné](https://en.wikipedia.org/wiki/Reentrant_%28subroutine%29), čehož se typicky dosáhne obalením výsledku do transakce anebo tím, že operaci učiníme [idempotetní](https://en.wikipedia.org/wiki/Idempotence).
+Pro proces typu worker je korektní ukončení dosaženo vrácením aktuální úlohy zpět do pracovní fronty. Například v [RabbitMQ](https://www.rabbitmq.com/) může worker poslat [`NACK`](https://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack), u [Beanstalkd](https://beanstalkd.github.io) se úloha vrátí do fronty automaticky, pokud se worker odpojí. Systémy postavené na zamykání, jako například [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) musí uvolnit zámek pro záznam své úlohy. V tomto modelu předpokládáme, že všechny úlohy jsou [opakovatelné](https://en.wikipedia.org/wiki/Reentrant_%28subroutine%29), čehož se typicky dosáhne obalením výsledku do transakce anebo tím, že operaci učiníme [idempotentní](https://en.wikipedia.org/wiki/Idempotence).
 
-Procesy by měli být dostatečné **robustní pro případ náhle smrti**, dojde-li například k selhání podkladového hardwaru. I když se to stává velmi zřídka narozdíl od koretního ukončení signálem `SIGTERM`, stále se to ale může stát. Doporučený postup je použít robustní systém, jako je Beanstalkd, který vrací úlohy zpět do fronty v případě odpojení klienta nebo vypršení časového limitu. V každém případě, twelve-factor aplikace je navržena tak, aby zvládna neočekávané a nekorektní ukončení. [Crash-only design](https://lwn.net/Articles/191059/) je tedy pro tento koncept [logickým východiskem](https://docs.couchdb.org/en/latest/intro/overview.html).
+Procesy by měly být dostatečně **robustní pro případ náhle smrti**, dojde-li například k selhání podkladového hardwaru. I když se to stává velmi zřídka narozdíl od koretního ukončení signálem `SIGTERM`, stále se to ale může stát. Doporučený postup je použít robustní systém, jako je Beanstalkd, který vrací úlohy zpět do fronty v případě odpojení klienta nebo vypršení časového limitu. V každém případě, twelve-factor aplikace je navržena tak, aby zvládna neočekávané a nekorektní ukončení. [Crash-only design](https://lwn.net/Articles/191059/) je tedy pro tento koncept [logickým východiskem](https://docs.couchdb.org/en/latest/intro/overview.html).