Skip to content

Commit

Permalink
Merge pull request #225 from filiphanes/slovak-locale
Browse files Browse the repository at this point in the history
Slovak locale
  • Loading branch information
raul committed Aug 22, 2019
2 parents ac77d25 + 79b1722 commit cdf4d61
Show file tree
Hide file tree
Showing 18 changed files with 335 additions and 1 deletion.
19 changes: 18 additions & 1 deletion Readme.md
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,24 @@ Daigle, Mark Imbriaco, Keith Rarick, Will Leinweber, Jesper Jørgensen, James
Ward, Adam Seligman, Phil Hagelberg, Jon Mountjoy, Matthew Turland, Daniel
Jomphe, Mattt Thompson, Anand Narasimhan, Lucas Fais, Pete Hodgson

Translations and edits by: [@sigerello](https://github.com/sigerello), [@mahnunchik](https://github.com/mahnunchik), [@francescomalatesta](https://github.com/francescomalatesta), [@astralhpi](https://github.com/astralhpi), [@liangshan](https://github.com/liangshan), [@orangain](https://github.com/orangain), [@Keirua](https://github.com/Keirua), Clément Camin, Bob Marteen, [@dmathieu](https://github.com/dmathieu), [@fernandes](https://github.com/fernandes), [@gwmoura](https://github.com/gwmoura), [@lfilho](https://github.com/lfilho), [@Arturszott](https://github.com/Arturszott), [@melikeyurtoglu](https://github.com/melikeyurtoglu) and [more](https://github.com/heroku/12factor/graphs/contributors).
Translations and edits by:
[@sigerello](https://github.com/sigerello),
[@mahnunchik](https://github.com/mahnunchik),
[@francescomalatesta](https://github.com/francescomalatesta),
[@astralhpi](https://github.com/astralhpi),
[@liangshan](https://github.com/liangshan),
[@orangain](https://github.com/orangain),
[@Keirua](https://github.com/Keirua),
Clément Camin,
Bob Marteen,
[@dmathieu](https://github.com/dmathieu),
[@fernandes](https://github.com/fernandes),
[@gwmoura](https://github.com/gwmoura),
[@lfilho](https://github.com/lfilho),
[@Arturszott](https://github.com/Arturszott),
[@melikeyurtoglu](https://github.com/melikeyurtoglu),
[@filiphanes](https://github.com/filiphanes)
and [more](https://github.com/heroku/12factor/graphs/contributors).

Released under the MIT License:
https://opensource.org/licenses/MIT
14 changes: 14 additions & 0 deletions content/sk/admin-processes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
## XII. Admin procesy
### Spúštanie administrátorských/správcovských úloh ako jednorazových procesov

[Process formation](./concurrency) je sada procesov, ktoré tvoria bežnú prevádzku aplikácie (napríklad odpovedanie na požiadavky). Na rozdiel od toho, vývojári často chcú spraviť jednorazové administratívne alebo údržbové úlohy, ako napríklad:

* Spustenie databázovej migrácie (e.g. `manage.py migrate` v Django, `rake db:migrate` v Rails).
* Spustenie konzoly (alebo tiež [REPL](http:https://en.wikipedia.org/wiki/Read-eval-print_loop) shell) aby mohli spúštať ľubovoľný kód alebo skúmať modely aplikácie voči živej databáze. Väčšina jazykov poskytuje REPL spustením interpretra bez argumentov (napr. `python` alebo `perl`) v niektorých prípadoch majú samostatný príkaz (napr. `irb` pre Ruby, `rails console` pre Rails).
* Spustenie jednorazových skriptov uložených v repozitári aplikácie (napr.. `php scripts/fix_bad_records.php`).

Jednorazové administračné procesy by sa mali spúštať v identickom prostredí ako bežné dlho [bežiace procesy](./processes) aplikácie. Bežia voči [releasu](./build-release-run), použitím rovnakého [kódu](./codebase) a [konfigurácie](./config) ako ostatné procesy bežiace v rámci releasu. Administračný kód sa musí dodať spolu s kódom aplikácie, aby sa zamedzilo synchronizačným problémom.

Rovnaká technika [izolácie závislostí](./dependencies) by sa mala použiť pre všetky typy procesov. Napríklad, ak Ruby webový proces používa príkaz `bundle exec thin start`, potom databázová migrácia by mala používať `bundle exec rake db:migrate`. A podobne Python program používajúci Virtualenv by mal používať `bin/python` rovnako na spúšťania Tornado webservera aj všetkých `manage.py` administračných procesov.

Dvanásť faktorová aplikácia silne preferuje jazyky, ktoré poskytujú REPL shell už v základe, a ktoré jednoducho umožňujú spúštanie jednorazových skriptov. Vývojári na lokálnom nasadení spúšťajú jednorazové administračné procesy priamym shell príkazom v priečinku aplikácie. V produkčnom nasadení môžu vývojári použiť ssh alebo iný spôsob vzdialeného spúšťania príkazov, ktorý poskytuje dané exekučné prostredie na spustenie takého procesu.
9 changes: 9 additions & 0 deletions content/sk/background.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
Background
==========

The contributors to this document have been directly involved in the development and deployment of hundreds of apps, and indirectly witnessed the development, operation, and scaling of hundreds of thousands of apps via our work on the <a href="http:https://www.heroku.com/" target="_blank">Heroku</a> platform.

This document synthesizes all of our experience and observations on a wide variety of software-as-a-service apps in the wild. It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app's codebase, and <a href="http:https://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/" target="_blank">avoiding the cost of software erosion</a>.

Our motivation is to raise awareness of some systemic problems we've seen in modern application development, to provide a shared vocabulary for discussing those problems, and to offer a set of broad conceptual solutions to those problems with accompanying terminology. The format is inspired by Martin Fowler's books *<a href="https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC" target="_blank">Patterns of Enterprise Application Architecture</a>* and *<a href="https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C" target="_blank">Refactoring</a>*.

14 changes: 14 additions & 0 deletions content/sk/backing-services.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
## IV. Podporné služby
### Spravovanie podporných služieb ako pripojených zdrojov

*Podporná služba* je akákoľvek služba, ktorú aplikácia konzumuje cez sieť ako súčasť je normálneho behu. Príklady zahŕňajú databázy (ako napr. [MySQL](http:https://dev.mysql.com/) alebo [CouchDB](http:https://couchdb.apache.org/)), messaging/queueing systémy (napr. [RabbitMQ](http:https://www.rabbitmq.com/) alebo [Beanstalkd](https://beanstalkd.github.io)), SMTP služby pre odchádzajúce emaily (napr. [Postfix](http:https://www.postfix.org/)), a cachovacie systémy (napr. [Memcached](http:https://memcached.org/)).

Podporné služby ako databázy sú tradične spravované tými istými systémovými administrátormi ako nasadenia aplikácie. Popri lokálne spravovaných službách, može mať aplikácia služby spravované tretími stranami. Príklady zahŕňajú SMTP služby (napr. [Postmark](http:https://postmarkapp.com/)), služby na zbieranie metrík (napr. [New Relic](http:https://newrelic.com/) alebo [Loggly](http:https://www.loggly.com/)), úložiskové služby (napr. [Amazon S3](http:https://aws.amazon.com/s3/)), alebo dokonca služby prístupné cez API (napr. [Twitter](http:https://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), alebo [Last.fm](http:https://www.last.fm/api)).

**Kód v dvanásť faktorovej aplikácii nerozlišuje medzi službou lokálnou a od tretej strany.** Pre aplikáciu sú obidve pripojené zdroje, prístupné cez URL alebo iné prístupové/prihlasovacie údaje uložené v [konfigurácii](./config). [Nasadenie](./codebase) dvanásť faktorovej aplikácie by malo byť schopné vymeniť lokálnu MySQL databázu s databázou spravovanou treťou stranou (napr. [Amazon RDS](http:https://aws.amazon.com/rds/)) bez akýchkoľvek zmien v kóde aplikácie. Podobne, lokálny SMTP server môže by vymenený SMTP službou od tretej strany (napr. Postmark) bez zmeny v kóde. V obidvoch prípado sa zmenia len prístupové a prihlasovacie údaje v konfigurácii.

Každá podporná služba je osobitným *zdrojom*. Napríklad, MySQL databáza je zdroj; dve MySQL databázy (používané na sharding na úrovni aplikácie) sú dva rôzne zdroje. Dvanásť faktorová aplikácie považuje tieto databázy ako *pripojené zdroje*, čo znamená ich voľné spojenie so súvisiacim nasadením.

<img src="/images/attached-resources.png" class="full" alt="Produkčné nasadenie pripojené ku štyrom podporným službám." />

Zdroje je možné pripájať a odpájať od nasedení podľa ľubovôle. Napríklad, ak je databáza z dôvodu hardvérových problémov nestabilná, správca aplikácie môže rozbehnúť nový databázový server zo zálohy. Aktuálna produkčná databáza môže byť odpojená a nový databáza pripojená -- všetko bez zmien v kóde.
19 changes: 19 additions & 0 deletions content/sk/build-release-run.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
## V. Build, release, run
### Jasne oddelené fázy build, release a run

[Kód](./codebase) sa transformuje do (nevývojárskeho) nasadenia troma krokmi:

* *Krok build* transformuje kód v repozitári na vykonateľný balík nazývaný *build*. Použitím verzie kódu v čase commitu špecifikovaného nasadzovacím procesom, krok build stiahne [závislosti](./dependencies) a skompiluje binárky a assets.
* *Krok release* zoberie build vytvorený predchádzajúcim krokom a skombinuje ho s aktuálnou [konfiguráciou](./config) pre dané nasadenie. Výsledok *release* obsahuje build a konfiguráciu pripravené na okamžité vykonanie v exekučnom prostredí.
* *Krok run* (alebo "runtime") spustí aplikáciu v exekučnom prostredí naštartovaním aplikačných [procesov](./processes) voči danému release.

![Kód sa stane buildom, ktorý sa skombinuje s konfiguráciou a vytvorí sa release.](/images/release.png)

**Dvanásť faktorová aplikácia striktne oddeľuje fázy build, release a run.** Napríklad: je nemožné spraviť zmeny v kóde počas jeho behu, keďže neexistuje spôsob, ako by sa tieto zmeny dostali späť do fázy build.

Nástroje na nasadzovanie zvyčajne ponúkajú spôsoby na správu release, hlavne teda možnosť vrátiť sa na predchádzajúci release. Napríklad [Capistrano](https://github.com/capistrano/capistrano/wiki) si ukladá release v podpriečinku s názvom `releases`, kde je aktuálny release symlink na priečinok s aktuálnym releasom. Tento príkaz `rollback` umožňuje jednoducho a rýchlo vrátiť sa na predchádzajúci release.

Každý release by mal vždy mať unikátne release ID, ako napríklad timestamp release (napríklad `2019-04-06-20:32:17`) alebo inkrementálne číslo (napr. `v100`). Releasy sú záznamy, ktoré iba pribúdajú a release sa nedá zmeniť potom jeho vytvorení. Každá zmenu musí vytvoriť nový release.

Buildy inicializujú developeri aplikácie kedykoľvek sa nasadzuje nový kód. Vykonávanie behu sa na rozdiel od buildov vykonáva automaticky v prípade reštartu servera, alebo pri reštarte padnutého procesu správcom procesov. Preto by fáza spustenia mala mať čo najmenej pohyblivých častí, keďže problémy, ktoré so spustením aplikácie môžu nastať v strede noci, keď developeri nie sú k dispozícii. Fáza build môže byť komplexnejšia, keďže chyby sú vždy viditeľné developerom, ktorí spustili nasadenie.

17 changes: 17 additions & 0 deletions content/sk/codebase.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
## I. Zdrojový kód
### Jeden zdrojový kód vo verzionovacom systéme, veľa nasadení

Dvanásť faktorová aplikácia je vždy uložená vo verzionovacom systéme ako napríklad [Git](http:https://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), alebo [Subversion](http:https://subversion.apache.org/). Kópia databázy verzionovacieho systému sa nazýva *repozitár kódu*, často skrátene *repozitár* alebo len *repo*.

*Zdrojový kód* je akýkoľvek repozitár (v centralizovanom verzionovacom systéme ako napr. Subversion), alebo akákoľvek skupina repozitárov, ktoré majú spoločný koreňový commit (v decentralizovanm verzionovacom systéme ako napr. Git).

![Jeden zdrojový kód má viacero nasadení](/images/codebase-deploys.png)

Vždy existuje korelácia jedna k jednej medzi zdrojovým kódom a aplikáciou:

* Ak je to viacero zdrojových kódov, nie je to aplikácia -- je to distribuovaný systém. Každý komponent v distribuovanom systéme je aplikácia, a každá môže osobitne spĺňať dvanásť faktorov.
* Viaceré aplikácie zdieľajúce jeden kód je porušenie dvanástich faktorov. Riešenie je oddelenie zdieľaného kódu do knižníc, ktoré sa pripoja pomocou [správy závislostí](./dependencies).

Každá aplikácia má len jeden zdrojový kód, ale nasadení jednej aplikácie bude viacero. *Nasadenie* je bežiaca inštancia aplikácie. Typicky je to produkčný web a jeden alebo viacero testovacích webov. Navyše, každý developer má kópiu bežiacej aplikácie vo svojom vlastnom vývojovom prostredí, z ktorých každé sa ráta ako nasadenie.

Zdrojový kód je rovnaký na všetkých nasadeniach, aj keď samozrejvie rôzne verzie môžu byť aktívne na rôznych nasadeniach. Napríklad, developer má niekoľko commitov, ktoré nie sú nasadené na testovacom prostredí a na testovacom prostredí sú commity, ktoré ešte nie sú na produkcii. Ale všetky zdieľajú jeden zdrojový kód a dá sa teda povedať, že sú rôznymi nasadeniami jednej aplikácie.
14 changes: 14 additions & 0 deletions content/sk/concurrency.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
## VIII. Concurrency
### Škálovanie pomocou modelu procesov

Každý počítačový program je po spustení reprezentovaný jedným alebo viac procesmi. Webové aplikácie sa objavujú v rôznych formách vykonávania procesov. Napríklad, PHP procesy bežia ako podprocesy Apachu, spustené na požiadanie podľa objemu požiadaviek. Java procesy prevzali opačný prístup, kde JVM poskytuje jeden masívny nadproces, ktorý si vyhradí veľké množstvo systémových prostriedkov (CPU a pamäte) pri spustení a súbežnosť spravuje interne cez vlákna. V obidvoch prípadoch sú bežiace procesy len minimálne viditeľné pre developera aplikácie.

![Škálovanie je vyjadrené bežiacimi procesmi, rôznorodosť funkcionality je vyjadrená typmi procesov.](/images/process-types.png)

**V dvanásť faktorovej aplikácii sú procesy prvotriednymi obyvateľmi.** Procesy v dvanásť faktorovej aplikácii preberajú správanie z [modelu unix procesov pre démony služieb](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Použitím tohoto modelu, developer môže navrhnúť svoju aplikáciu tak, aby rôznu prácu vykonávali rôzne *typy procesov*. Napríklad, HTTP požiadavky môže spravovať webový proces, a dlho bežiace úlohy na pozadí môže spravovať worker proces.

Toto nevylučuje, že si individuálne procesy nemôžu spravovať svoj interný multiplexing cez vlákna vnútri VM alebo interpretra, alebo async/event model v nástrojoch ako [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http:https://twistedmatrix.com/trac/), alebo [Node.js](http:https://nodejs.org/). Keďže individuálne VM môže rásť len obmedzene (vertikálne škálovanie), aplikáciu musí byť tiež schopná sa rozšíriť na viacero procesov bežiacich na viacerých fyzických strojoch.

Procesový model vyniká, keď príde čas rozširovania. [Nezdieľaná, horizontálne particionovateľná podstata procesov dvanásť faktorovej aplikácie](./processes) znamená, že pridanie väčšej súbežnosti je jednoduchá a spoľahlivá operácia. Súhrn typov procesov a počtu procesov každého typu sa nazýva *process formation*.

Procesty dvanásť faktorovej aplikácie [by sa nikdy nemali démonizovať](http:https://dustin.github.com/2010/02/28/running-processes.html) alebo zapisovať PID súbory. Namiesto toho by sa mali spoliehať na manažéra procesov operačného systému (ako napr. [systemd](https://www.freedesktop.org/wiki/Software/systemd/), distribuovaného manažéra procesov na cloudovej platforme, alebo nástroji ako [Foreman](http:https://blog.daviddollar.org/2011/05/06/introducing-foreman.html) počas vývoja) na spravovanie [výstupných streamov](./logs), reakcie na spadnuté procesy, a spravovanie userom iniciovaných reštartov a zastavení.
22 changes: 22 additions & 0 deletions content/sk/config.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
## III. Konfigurácia
### Konfigurácia uložená v prostredí

*Konfigurácia* aplikácie je všetko, čo sa líši medzi [nasadeniami](./codebase) (staging, produkcia, vývojárske prostredie, atď). To zahŕňa:

* Pripojenia k databázam, Memcached a iným [podporným službám](./backing-services)
* Prihlasovacie údaje k externým službám ako Amazon S3 alebo Twitter
* Špeciálne hodnotu Per-nasadenie values such ako napríklad kanonické názvy hostov.

Aplikácia si niekedy ukladá konštanty v kóde. Toto je porušenie dvanástich faktorov, ktoré vyžaduje **striktné oddelenie konfigurácie od kódu**. Konfigurácia sa medzi nasadeniami podstatne odlišuje, kód nie.

Litmusovým testom správneho oddelenia konfigurácie, je to či by mohla byť v ktoromkoľvek momente open-sourcovaná bez úniku prihlasovacích údajov.

Všimnite si, že definícia "konfigurácie" **nezahŕňa** internú konfiguráciu aplikácie, ako napríklad `config/routes.rb` v Rails, alebo [prepojenie modulov](http:https://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) v [Spring](http:https://spring.io/). Tento typ konfigurácie sa medzi nasadeniami nelíši, a preto je najlepšie ho nechať v kóde.

Ďalšou možnosťou, ako pristupovať ku konfiguráciám je mať konfiguračné súbory, ktoré nie sú uložené v revíznom systéme, ako napríklad `config/database.yml` v Rails. Je to obrovské zlepšenie oproti konštantám uloženým v repozitári, ale stále má slabosť: je veľmi jednoduché omylom tento súbor uložiť do repozitára; je tendencia mať konfiguračné súbory na rôznych miestach a v rôznych formátoch, a preto je ťažké ich spravovať z jedného miesta. Navyše, tieto formáty zvyknú byť špecifické pre jazyk alebo framework.

**Dvanásť faktorová aplikácia konfiguráciu ukladá v *premenných prostredia*** (často skrátané na *env vars* alebo *env*). Premenné prostredia sa dajú jednoducho meniť pri nasadeniach bez potreby zmeny v kóde; na rozdiel od konfiguračných súborov je minimálna šanca, že ich niekto omylom uloží do repozitára; a narozdiel od rôznych konfiguračných súborov, alebo iných konfiguračných mechanizmov ako napr. Java System Properties, premenné prostredia sú nezávislé na jazyku alebo OS.

Ďalším pohľadom na správu konfigurácie je zoskupovanie. Niekedy aplikácie zoskupia konfigurácie do pomenovaných skupín (často nazývaných called "prostredia") a sú pomenované podľa jednotlivých typov nasadení, ako napríklad `development`, `test`, a `production` prostredia v Rails. Tento spôsob je náročné škálovať čistým spôsobom: ako pribúdajú ďalšie typy nasadení, je potrebné vytvárať nové názvy prostredí, ako napríklad `staging` alebo `qa`. Ako projekt ďalej rastie, developeri môžu pridávať ďalšie vlastné špeciálne prostredia ako `joes-staging`, a výsledkom je kombinatorická explózia konfiguračných prostredí a tým sa stáva spravovanie nasadení veľmi citlivé.

V dvanásť faktorovej aplikácii sú premenné prostredia granulárne nastavenia, každé ortogonálne k inej premennej prostredia. Nikdy sa nezoskupujú spolu do pomenovaných "prostredí", ale namiesto toho sú nezávisle spravované pre každé nasadenie. Tento model sa plynule škáluje počas prirodzeného rastu aplikácie ako pribúdajú ďalšie typy nasadení.
Loading

0 comments on commit cdf4d61

Please sign in to comment.