diff --git a/.gitignore b/.gitignore
index 365e22148..8c9e75ddf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
.rvmrc
.bundle
.tool-versions
+.idea
diff --git a/content/uk/admin-processes.md b/content/uk/admin-processes.md
index 19b876297..cfb81a802 100644
--- a/content/uk/admin-processes.md
+++ b/content/uk/admin-processes.md
@@ -1,14 +1,28 @@
## XII. Задачі адміністрування
### Виконуйте задачі адміністрування/керування за допомогою разових процесів
-[Формація процесів](./concurrency) є певним набором процесів, які необхідні для виконання регулярних задач застосунку (наприклад, обробка веб-запитів). Разом з тим, розробникам часто необхідно виконувати разові адміністративні задачі для обслуговування застосунку, такі як:
+[Формація процесів](./concurrency) є певним набором процесів, які необхідні для виконання регулярних задач застосунку
+(наприклад, обробка веб-запитів). Разом з тим, розробникам часто необхідно виконувати разові адміністративні задачі
+для обслуговування застосунку, такі як:
* Запуск міграції бази даних (наприклад, `manage.py migrate` в Django, `rake db:migrate` в Rails).
-* Запуск консолі ([REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)) для виконання довільного коду або перевірки моделі застосунку на діючій базі даних. Більшість мов надають REPL шляхом запуску інтерпретатора без будь-яких аргументів (наприклад, `python` або `perl`) або в деяких випадках мають окрему команду (наприклад, `irb` для Ruby, `rails console` для Rails).
+* Запуск консолі ([REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)) для виконання довільного коду
+* або перевірки моделі застосунку на робочій базі даних. Більшість мов надають REPL шляхом запуску інтерпретатора без
+* будь-яких аргументів (наприклад, `python` або `perl`) або в деяких випадках мають окрему команду
+* (наприклад, `irb` для Ruby, `rails console` для Rails).
* Запуск разових скриптів, збережених в репозиторії застосунку (наприклад, `php scripts/fix_bad_records.php`).
-Разові процеси адміністрування слід запускати в такому ж середовищі, в якому запущені регулярні [тривалі процеси](./processes) застосунку. Вони запускаються на базі [релізу](./build-release-run), використовуючи ту ж [кодову базу](./codebase) і [конфігурацію](./config), як і будь-який інший процес на базі цього релізу. Для уникнення проблем з синхронізацією код адміністрування має поставлятися з кодом застосунку.
+Разові процеси адміністрування слід запускати в такому ж середовищі, в якому запущені регулярні
+[тривалі процеси](./processes) застосунку. Вони запускаються на базі [релізу](./build-release-run),
+використовуючи ту ж [кодову базу](./codebase) і [конфігурацію](./config), як і будь-який інший процес на базі цього релізу.
+Для уникнення проблем з синхронізацією код адміністрування має поставлятися з кодом застосунку.
-Для всіх типів процесів мають використовуватися однакові методи [ізоляції залежностей](./dependencies). Наприклад, якщо веб-процес Ruby використовує команду `bundle exec thin start`, то для міграції бази даних слід використовувати `bundle exec rake db:migrate`. Аналогічно, для програми на Python з Virtualenv слід використовувати `bin/python` як для запуску веб-сервера Tornado, так і для запуску будь-яких `manage.py` процесів адміністрування.
+Для всіх типів процесів мають використовуватися однакові методи [ізоляції залежностей](./dependencies).
+Наприклад, якщо вебпроцес Ruby використовує команду `bundle exec thin start`, то для міграції бази даних слід
+використовувати `bundle exec rake db:migrate`. Аналогічно, для програми на Python з Virtualenv слід використовувати
+`bin/python` як для запуску вебсервер Tornado, так і для запуску будь-яких `manage.py` процесів адміністрування.
-Методологія дванадцяти факторів надає перевагу мовам, які мають REPL "з коробки", і які дозволяють легко запускати разові скрипти. У локальному development середовищі розробник може запустити процес адміністрування за допомогою консольної команди всередині директорії застосунку. У production середовищі для запуску такого процесу розробники можуть використовувати ssh або інший механізм віддаленого виконання команд, що надається середовищем виконання.
\ No newline at end of file
+Методологія дванадцяти факторів надає перевагу мовам, які мають REPL "з коробки", і які дозволяють легко запускати
+разові скрипти. У локальному development середовищі розробник може запустити процес адміністрування за допомогою
+консольної команди всередині директорії застосунку. У production середовищі для запуску такого процесу розробники
+можуть використовувати ssh або інший механізм віддаленого виконання команд, що надається середовищем виконання.
\ No newline at end of file
diff --git a/content/uk/background.md b/content/uk/background.md
index fb1c16ccf..dc8ba1081 100644
--- a/content/uk/background.md
+++ b/content/uk/background.md
@@ -1,8 +1,17 @@
Передумови
==========
-Люди, що працювали над цим документом, брали безпосередню участь в розробці і розгортанні сотень застосунків, і мимоволі стали свідками розвитку, експлуатації та масштабування сотень тисяч застосунків під час нашої роботи над платформою [Heroku](http://www.heroku.com/).
+Люди, що працювали над цим документом, брали безпосередню участь в розробці й розгортанні сотень застосунків,
+і мимоволі стали свідками розвитку, експлуатації та масштабування сотень тисяч застосунків під час нашої роботи над
+платформою [Heroku](http://www.heroku.com/).
-В цьому документі узагальнюється весь наш досвід використання і спостереження за найрізноманітнішими SaaS-застосунками "в дикій природі". Документ об'єднує ідеальні практики розробки застосунків, особлива увага приділяється динаміці органічного росту застосунку з плином часу, взаємодії між розробниками, які працюють над кодом застосунку, та [уникненню витрат при ерозії програмного забезпечення](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/).
+В цьому документі узагальнюється весь наш досвід використання і спостереження за найрізноманітнішими SaaS-застосунками
+"в дикій природі". Документ об'єднує ідеальні практики розробки застосунків, особлива увага приділяється
+динаміці органічного росту застосунку з плином часу, взаємодії між розробниками, які працюють над кодом застосунку,
+та [уникненню витрат при ерозії програмного забезпечення](http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/).
-Наша мета полягає в тому, щоб підвищити обізнаність про деякі системні проблеми, які ми бачили в практиці розробки сучасних застосунків, а також в тому, щоб сформулювати спільні загальні поняття для обговорення цих проблем, і запропонувати набір загальних концептуальних рішень цих проблем з супутньою термінологією. Формат навіяний книгами Мартіна Фаулера (Martin Fowler) *[Patterns of Enterprise Application Architecture](https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* та *[Refactoring](https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*.
\ No newline at end of file
+Наша мета полягає в тому, щоб підвищити обізнаність про деякі системні проблеми, які ми бачили в практиці розробки
+сучасних застосунків, а також в тому, щоб сформулювати спільні загальні поняття для обговорення цих проблем,
+і запропонувати набір загальних концептуальних розв'язань цих проблем з супутньою термінологією.
+Формат навіяний книгами Мартіна Фаулера
+(Martin Fowler) *[Patterns of Enterprise Application Architecture](https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* та *[Refactoring](https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*.
\ No newline at end of file
diff --git a/content/uk/backing-services.md b/content/uk/backing-services.md
index ee2457558..e1723553e 100644
--- a/content/uk/backing-services.md
+++ b/content/uk/backing-services.md
@@ -1,14 +1,37 @@
## IV. Сторонні служби
### Вважайте сторонні служби (backing services) підключеними ресурсами
-*Стороння служба* — це будь-яка служба, яка доступна застосунку по мережі і необхідна для його нормальної роботи: бази даних (наприклад, [MySQL](http://dev.mysql.com/) або [CouchDB](http://couchdb.apache.org/)), системи черг повідомлень (наприклад, [RabbitMQ](http://www.rabbitmq.com/) або [Beanstalkd](https://beanstalkd.github.io)), служби SMTP для вихідної пошти (наприклад, [Postfix](http://www.postfix.org/)), системи кешування (наприклад, [Memcached](http://memcached.org/)) тощо.
+*Стороння служба* — це будь-яка служба, яка доступна застосунку мережею і необхідна для його нормальної роботи:
+бази даних (наприклад, [MySQL](http://dev.mysql.com/) або [CouchDB](http://couchdb.apache.org/)),
+системи черг повідомлень (наприклад, [RabbitMQ](http://www.rabbitmq.com/) або [Beanstalkd](https://beanstalkd.github.io)),
+служби SMTP для вихідної пошти (наприклад, [Postfix](http://www.postfix.org/)), системи кешування
+(наприклад, [Memcached](http://memcached.org/)) тощо.
-Допоміжні служби, такі як бази даних, традиційно управляються тими ж системними адміністраторами, які розгортають застосунок. Окрім локальних служб, застосунок може також використовувати служби, що надаються і керуються третіми сторонами: SMTP-сервіси (наприклад, [Postmark](http://postmarkapp.com/)), сервіси збору метрик (наприклад, [New Relic](http://newrelic.com/) або [Loggly](http://www.loggly.com/)), сховища бінарних даних (наприклад, [Amazon S3](http://aws.amazon.com/s3/)), а також різні сервіси, що надають доступ через API (наприклад, [Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), або [Last.fm](http://www.last.fm/api)).
+Допоміжні служби, такі як бази даних, традиційно управляються тими ж системними адміністраторами,
+які розгортають застосунок. Окрім локальних служб, застосунок може також використовувати служби,
+що надаються і керуються третіми сторонами: SMTP-сервіси (наприклад, [Postmark](http://postmarkapp.com/)),
+сервіси збору метрик (наприклад, [New Relic](http://newrelic.com/) або [Loggly](http://www.loggly.com/)),
+сховища бінарних даних (наприклад, [Amazon S3](http://aws.amazon.com/s3/)),
+а також різні сервіси, що надають доступ через API (наприклад, [Twitter](http://dev.twitter.com/),
+[Google Maps](https://developers.google.com/maps/), або [Last.fm](http://www.last.fm/api)).
-**Код застосунку дванадцяти факторів не бачить жодних відмінностей між локальними і сторонніми сервісами.** Для застосунку кожен з них є підключеним ресурсом, доступним за URL-адресою або іншими даними, що зберігаються в [конфігурації](./config). [Розгортання](./codebase) застосунку дванадцяти факторів повинно мати можливість, наприклад, замінити локальну базу даних MySQL на будь-яку керовану третьою стороною (наприклад, [Amazon RDS](http://aws.amazon.com/rds/)) без жодних змін в коді застосунку. Крім того, локальний сервер SMTP може бути замінений на сторонній SMTP-сервіс (наприклад, Postmark) без зміни коду. В обох випадках необхідно змінити лише налаштування відповідного ресурсу в конфігурації застосунку.
+**Код застосунку дванадцяти факторів не бачить жодних відмінностей між локальними й сторонніми сервісами.
+** Для застосунку кожен з них є підключеним ресурсом, доступним за URL-адресою або іншими даними,
+що зберігаються в [конфігурації](./config). [Розгортання](./codebase) застосунку дванадцяти факторів повинно мати можливість,
+наприклад, замінити локальну базу даних MySQL на будь-яку керовану третьою стороною
+(наприклад, [Amazon RDS](http://aws.amazon.com/rds/)) без жодних змін в коді застосунку. Крім того,
+локальний сервер SMTP може бути замінений на сторонній SMTP-сервіс (наприклад, Postmark) без зміни коду.
+В обох випадках необхідно змінити лише налаштування відповідного ресурсу в конфігурації застосунку.
-Кожна окрема стороння служба є *ресурсом*. Наприклад, база даних MySQL є ресурсом; дві бази даних MySQL (що використовуються для шардінгу на рівні застосунку) кваліфікуються як два різних ресурси. Застосунок дванадцяти факторів сприймає ці бази даних як *підключені ресурси*, що вказує на їхній слабкий зв'язок з розгортанням, в якому вони підключені.
+Кожна окрема стороння служба є *ресурсом*. Наприклад, база даних MySQL є ресурсом; дві бази даних MySQL
+(що використовуються для шардінгу на рівні застосунку) кваліфікуються як два різних ресурси. Застосунок дванадцяти
+факторів сприймає ці бази даних як *підключені ресурси*, що вказує на їхній слабкий зв'язок з розгортанням,
+в якому вони підключені.
-
+
-Ресурси за необхідності можуть бути підключені та відключені до розгортання застосунку. Наприклад, якщо база даних застосунку функціонує некорекно у зв'язку з апаратними проблемами, адміністратор може запустити новий сервер бази даних, відновленої з останньої резервної копії. Поточна база даних може бути відключена, а нова база даних підключена — все це без будь-яких змін коду.
+Ресурси за необхідності можуть бути підключені та відключені до розгортання застосунку.
+Наприклад, якщо база даних застосунку функціонує некоректно у зв'язку з апаратними проблемами,
+адміністратор може запустити новий сервер бази даних, відновленої з останньої резервної копії.
+Поточна база даних може бути відключена, а нова база даних підключена — все це без будь-яких змін коду.
diff --git a/content/uk/build-release-run.md b/content/uk/build-release-run.md
index eaaed6b44..1cb2a7928 100644
--- a/content/uk/build-release-run.md
+++ b/content/uk/build-release-run.md
@@ -3,16 +3,30 @@
[Кодова база](./codebase) перетворюється в розгортання (крім розгортання для розробки) у три етапи:
-* *Етап збірки* — це трансформація, яка перетворює код в репозиторії у пакунок, що може бути запущений, і який називається *збірка*. Використовуючи версію коду за вказаним у процесі розгортання коммітом, етап збірки завантажує [залежності](./dependencies) та компілює бінарні файли і ресурси (assets).
-* *Етап релізу* приймає збірку, отриману на етапі збірки, і об'єднує її з поточною [конфігурацією](./config) розгортання. Отриманий *реліз* містить збірку і конфігурацію і готовий до негайного запуску в середовищі виконання.
-* *Етап виконання* (також відомий як "runtime") запускає застосунок у середовищі виконання, увімкнувши деякий набір [процесів](./processes) застосунку з певного релізу.
+* *Етап збірки* — це трансформація, яка перетворює код в репозиторії у пакунок, що може бути запущений,
+і який називається *збірка*. Використовуючи версію коду за вказаним у процесі розгортання коммітом,
+етап збірки завантажує [залежності](./dependencies) та компілює бінарні файли й ресурси (assets).
+* *Етап релізу* приймає збірку, отриману на етапі збірки, і об'єднує її з поточною [конфігурацією](./config) розгортання.
+Отриманий *реліз* містить збірку і конфігурацію і готовий до негайного запуску в середовищі виконання.
+* *Етап виконання* (також відомий як "runtime") запускає застосунок у середовищі виконання,
+увімкнувши деякий набір [процесів](./processes) застосунку з певного релізу.
-**Застосунок дванадцяти факторів дотримується суворого відокремлення етапів збірки, релізу і виконання.** Наприклад, не можна вносити зміни в код під час етапу виконання, оскільки немає способу поширити ці зміни назад на етап збірки.
+**Застосунок дванадцяти факторів дотримується суворого відокремлення етапів збірки, релізу і виконання.** Наприклад,
+не можна вносити зміни в код під час етапу виконання, оскільки немає способу поширити ці зміни назад на етап збірки.
-Інструменти розгортання, як правило, надають засоби керування релізами, які дають можливість відкату до попередньої версії. Наприклад, інструмент розгортання [Capistrano](https://github.com/capistrano/capistrano/wiki) зберігає релізи в підкаталог з назвою `releases`, де поточний реліз є символічним посиланням на каталог поточного релізу. Команда Capistrano `rollback` дає можливість швидко виконати відкат до попередньої версії.
+Інструменти розгортання, як правило, надають засоби керування релізами, які дають можливість повернення до попередньої версії.
+Наприклад, інструмент розгортання [Capistrano](https://github.com/capistrano/capistrano/wiki) зберігає релізи
+в підкаталог з назвою `releases`, де поточний реліз є символічним посиланням на каталог поточного релізу.
+Команда Capistrano `rollback` дає можливість швидко виконати повернення до попередньої версії.
-Кожен реліз повинен завжди мати унікальний ідентифікатор, наприклад, мітку часу релізу (наприклад, `2011-04-06-20:32:17`) або номер, що зростає (наприклад, `v100`). Релізи можуть тільки додаватися, неможливо змінити реліз після його створення. Будь-які зміни мають створювати новий реліз.
+Кожен реліз повинен завжди мати унікальний ідентифікатор, наприклад, мітку часу релізу (наприклад, `2011-04-06-20:32:17`)
+або номер, що зростає (наприклад, `v100`). Релізи можуть тільки додаватися, неможливо змінити реліз після його створення.
+Будь-які зміни мають створювати новий реліз.
-Збірка ініцюється розробником застосунку щоразу при розгортанні нового коду. Запуск етапу виконання, навпаки, може відбуватися автоматично в таких випадках, як перезавантаження сервера або перезапуск процесу, шо впав, менеджером процесів. Таким чином, етап виконання має бути максимально технічно простим, бо проблеми, які заважають застосунку запуститися, можуть призвести до його зупинки посеред ночі, коли розробників немає на місці. Етап збірки може бути більш складним, бо можливі помилки завжди видимі розробнику, який запустив процес розгортання.
\ No newline at end of file
+Збірка ініціюється розробником застосунку щоразу при розгортанні нового коду. Запуск етапу виконання, навпаки,
+може відбуватися автоматично в таких випадках, як перезавантаження сервера або перезапуск процесу, що впав,
+менеджером процесів. Таким чином, етап виконання має бути максимально технічно простим, бо проблеми,
+які заважають застосунку запуститися, можуть призвести до його зупинки посеред ночі, коли розробників немає на місці.
+Етап збірки може бути більш складним, бо можливі помилки завжди видимі розробнику, який запустив процес розгортання.
\ No newline at end of file
diff --git a/content/uk/codebase.md b/content/uk/codebase.md
index 75e86bf68..391abedde 100644
--- a/content/uk/codebase.md
+++ b/content/uk/codebase.md
@@ -1,17 +1,30 @@
## I. Кодова база
-### Одна кодова база, що відслідковується в системі контролю версій та має багато розгортань
+### Одна кодова база, що відстежується в системі контролю версій та має багато розгортань
-Застосунок дванадцяти факторів завжди відслідковуються в системі контролю версій, такій як [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/) або [Subversion](http://subversion.apache.org/). Копія бази даних відстеження ревізій називається *репозиторій коду (code repository)*, що часто скорочується до *code repo* або просто *repo*.
+Застосунок дванадцяти факторів завжди відстежується в системі контролю версій,
+такій як [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/)
+або [Subversion](http://subversion.apache.org/). Копія бази даних відстеження ревізій називається
+*репозиторій коду (code repository)*, що часто скорочується до *code repo* або просто *repo*.
-*Кодова база* — це один репозиторій (в централізованих системах контролю версій, як Subversion), або декілька репозиторіїв, які мають спільний початковий комміт (в децентралізованих системах контролю версій, як Git).
+*Кодова база* — це один репозиторій (в централізованих системах контролю версій, як Subversion),
+або декілька репозиторіїв, які мають спільний початковий комміт (в децентралізованих системах контролю версій, як Git).
-
+
Завжди існує однозначна відповідність між кодовою базою і застосунком:
-* За наявності кількох баз коду, це не застосунок, це — розподілена система. Кожен компонент в розподіленій системі є застосунком, і кожен з них може окремо дотримуватися дванадцяти факторів.
-* Кілька різних застосунків, що спільно використовують загальну базу коду, є порушенням дванадцяти факторів. Рішенням в даній ситуації є виділення загального коду в бібліотеки, які можуть бути підключені через [менеджер залежностей](./dependencies).
+* За наявності кількох баз коду, це не застосунок, це — розподілена система. Кожен компонент в розподіленій системі
+* є застосунком, і кожен з них може окремо дотримуватися дванадцяти факторів.
+* Кілька різних застосунків, що спільно використовують загальну базу коду, є порушенням дванадцяти факторів.
+* Рішенням в даній ситуації є виділення загального коду в бібліотеки,
+які можуть бути підключені через [менеджера залежностей](./dependencies).
-Існує тільки одна кодова база для кожного застосунку, але може бути багато розгортань одного і того самого застосунку. *Розгортанням (deploy)* є запущений екземпляр застосунку. Це, як правило, production-сайт і один або більше staging-сайтів (проміжних розгортань). Крім того, розробник має копію застосунку, запущеного в його локальному середовищі розробки. Кожну з таких копій також можна кваліфікувати як розгортання (deploy).
+Існує тільки одна кодова база для кожного застосунку, але може бути багато розгортань одного і того самого застосунку.
+*Розгортанням (deploy)* є запущений екземпляр застосунку. Це, як правило, production-сайт і один або більше
+staging-сайтів (проміжних розгортань). Крім того, розробник має копію застосунку, запущеного в його локальному
+середовищі розробки. Кожну з таких копій також можна кваліфікувати як розгортання (deploy).
-Кодова база має бути єдина для всіх розгортань, хоча в кожному розгортанні можуть бути активні різні її версії. Наприклад, розробник може мати деякі зміни у коді, які ще не додані в staging-розгортання; staging-розгортання може мати деякі зміни, які ще не додані в production-розгортання. Але всі вони використовують одну і ту саму кодову базу, таким чином можна їх ідентифікувати як різні розгортання одного і того ж застосунку.
\ No newline at end of file
+Кодова база має бути єдина для всіх розгортань, хоча в кожному розгортанні можуть бути активні різні її версії.
+Наприклад, розробник може мати деякі зміни у коді, які ще не додані в staging-розгортання;
+staging-розгортання може мати деякі зміни, які ще не додані в production-розгортання. Але всі вони використовують
+одну і ту саму кодову базу, таким чином можна їх ідентифікувати як різні розгортання одного і того ж застосунку.
\ No newline at end of file
diff --git a/content/uk/concurrency.md b/content/uk/concurrency.md
index de609a2c8..0cff514ff 100644
--- a/content/uk/concurrency.md
+++ b/content/uk/concurrency.md
@@ -1,14 +1,36 @@
## VIII. Конкурентність
### Масштабуйте застосунок за допомогою процесів
-Будь-яка комп'ютерна програма після запуску представлена одним або декількома процесами. Веб-додатки мають різні форми виконання процесів. Наприклад, PHP-процеси виконуються як дочірні процеси Apache, які запускаються в разі потреби в залежності від навантаження. Java-процеси використовують протилежний підхід: JVM забезпечує один масивний мета-процес, який резервує велику кількість системних ресурсів (процесора і пам'яті) під час його запуску, і керує конкурентністю всередині себе за допомогою потоків виконання (threads). В обох випадках запущені процеси видимі для розробників застосунку мінімально.
+Будь-яка комп'ютерна програма після запуску представлена одним або декількома процесами.
+Вебдодатки мають різні форми виконання процесів. Наприклад, PHP-процеси виконуються як дочірні процеси Apache,
+які запускаються в разі потреби в залежності від навантаження. Java-процеси використовують протилежний підхід:
+JVM забезпечує один масивний метапроцес, який резервує велику кількість системних ресурсів (процесора і пам'яті)
+під час його запуску, і керує конкурентністю всередині себе за допомогою потоків виконання (threads).
+В обох випадках запущені процеси видимі для розробників застосунку мінімально.
-**В застосунку дванадцяти факторів, процеси є сутностями першого класу.** Процеси в застосунку дванадцяти факторів взяли сильні сторони від [моделі процесів UNIX для запуску сервісів](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Використовуючи цю модель, розробник може спроектувати свій застосунок таким чином, що для обробки різних робочих навантажень необхідно призначити кожному виду робіт свій *тип процесу*. Наприклад, HTTP-запити можуть бути оброблені за допомогою веб-процесу (web process), а тривалі фонові завдання оброблені робочим процесом (worker process).
+**В застосунку дванадцяти факторів, процеси є сутностями першого класу.
+** Процеси в застосунку дванадцяти факторів взяли сильні сторони від [моделі процесів UNIX для запуску сервісів](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/).
+Використовуючи цю модель, розробник може спроєктувати свій застосунок таким чином, що для обробки різних робочих
+навантажень необхідно призначити кожному виду робіт свій *тип процесу*. Наприклад, HTTP-запити можуть бути оброблені
+за допомогою вебпроцесу (web process), а тривалі фонові завдання оброблені робочим процесом (worker process).
-Це не виключає можливості використання індивідуального мультиплексування для окремих процесів через потоки виконання віртуальної машини або асинхронні/подієві моделі в таких інструментах, як [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/) або [Node.js](http://nodejs.org/). Але індивідуальна віртуальна машина може масшабуватися тільки обмежено (вертикальне масшабування), тому застосунок також повинен мати можливість бути запущеним як декілька процесів на декількох фізичних машинах.
+Це не виключає можливості використання індивідуального мультиплексування для окремих процесів через потоки виконання
+віртуальної машини або асинхронні/подієві моделі в таких інструментах,
+як [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/)
+або [Node.js](http://nodejs.org/). Але індивідуальна віртуальна машина може масштабуватися тільки обмежено
+(вертикальне масштабування), тому застосунок також повинен мати можливість бути запущеним як декілька процесів
+на декількох фізичних машинах.
-Модель, побудована на процесах, дійсно показує себе з найкращого боку, коли постає необхідність масштабування. [Відсутність розділених даних і горизонтальне розділення процесів застосунку дванадцяти факторів](./processes) означає, що додавання більшої конкурентності є простою і надійною операцією. Масив типів процесів і кількість процесів кожного типу називається *формацією процесів*.
+Модель, побудована на процесах, дійсно показує себе з найкращого боку, коли постає необхідність масштабування.
+[Відсутність розділених даних і горизонтальне розділення процесів застосунку дванадцяти факторів](./processes) означає,
+що додавання більшої конкурентності є простою і надійною операцією. Масив типів процесів і кількість процесів кожного
+типу називається *формацією процесів*.
-Процеси застосунку дванадцяти факторів [ніколи не мають демонізуватися](http://dustin.github.com/2010/02/28/running-processes.html) та записувати PID-файли. Замість цього вони мають покладатися на менеджер процесів операційної системи (наприклад, [systemd](https://www.freedesktop.org/wiki/Software/systemd/), розподілений менеджер процесів на хмарній платформі, або в процесі розробки на такий інструмент, як [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html)) для керування [потоком виведення](./logs), реагування на падіння процесів і обробку ініційованих користувачем перезавантаження чи завершення роботи.
+Процеси застосунку дванадцяти факторів [ніколи не мають демонізуватися](http://dustin.github.com/2010/02/28/running-processes.html)
+та записувати PID-файли. Замість цього вони мають покладатися на менеджера процесів операційної системи
+(наприклад, [systemd](https://www.freedesktop.org/wiki/Software/systemd/), розподілений менеджер процесів на хмарній
+платформі, або в процесі розробки на такий інструмент, як [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html))
+для керування [потоком виведення](./logs), реагування на падіння процесів і обробку ініційованих користувачем
+перезавантаження чи завершення роботи.
diff --git a/content/uk/config.md b/content/uk/config.md
index 8205ba784..ea753cec5 100644
--- a/content/uk/config.md
+++ b/content/uk/config.md
@@ -1,22 +1,45 @@
## III. Конфігурація
### Зберігайте конфігурацію в середовищі виконання
-*Конфігурація* застосунку — це все, що може змінюватися між [розгортаннями](./codebase) (staging-розгортання, production-розгортання, локальне середовище розробника тощо). Це включає:
+*Конфігурація* застосунку — це все, що може змінюватися між
+[розгортаннями](./codebase) (staging-розгортання, production-розгортання, локальне середовище розробника тощо).
+Це включає:
* Параметри підключення до бази даних, Memcached і інших [сторонніх сервісів](./backing-services);
* Реєстраційні дані для підключення до зовнішніх сервісів, таких як Amazon S3 або Twitter;
* Значення, що залежать від середовища розгортання, такі як канонічне ім'я хосту.
-Застосунки іноді зберігають конфігурації як константи в коді. Це є порушенням методології дванадцяти факторів, яка вимагає **обов'язкового відокремлення конфігурації від коду**. Конфігурації застосунку в розгортаннях суттєво відрізняються, код — однаковий.
-
-Лакмусовим папірцем того, чи правильно розділені конфігурація і код, є можливість в будь-який момент відкрити вихідний код застосунку у вільний доступ, при цьому не оприлюднюючи будь-яких приватних даних.
-
-Зверніть увагу, що визначення "конфігурації" **не включає** в себе внутрішні налаштування застосунку, такі як `сonfig/routes.rb` в Rails, або [як пов'язані основні модулі](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) в [Spring](http://spring.io/). Ці налаштування не змінюються між розгортаннями, і тому краще місце для них — саме в коді.
-
-Іншим підходом до конфігурації є використання конфігураційних файлів, що не зберігаються в систему контролю версій, таких як `сonfig/database.yml` в Rails. Це перевага у порівнянні з використанням констант в коді, але все ж таки має суттєві недоліки: є ймовірність помилково зберегти файл конфігурації в репозиторій; існує тенденція коли конфігураційні файли розкидані в різних місцях і в різних форматах, і стає важко передивлятися всі налаштування і керувати ними в одному місці. Крім того, формати цих файлів, як правило, специфічні для конкретної мови програмування чи фреймворку.
-
-**Застосунок дванадцати факторів зберігає конфігурацію в *змінних оточення*** (часто скорочується до *env vars* або *env*). Значення змінних оточення легко змінити між розгортаннями без зміни коду; на відміну від конфігураційних файлів, менш ймовірно випадково зберегти їх в репозиторій коду; і на відміну від конфігураційних файлів або інших механізмів конфігурації, таких як Java System Properties, вони є стандартом, незалежним від мови програмування чи фреймворку.
-
-Іншим аспектом керування конфігурацією є групування. Іноді застосунки об'єднують конфігурації в іменовані групи (які часто називаються "оточеннями"), які називаються в залежності від конкретного розгортання, наприклад, `development`, `test` і `production` оточення в Rails. Цей метод погано масштабується: чим більше створюється різних розгортань застосунку, тим більше необхідно нових імен оточень, наприклад, `staging` або `qa`. При подальшому рості проекту розробники можуть додавати свої власні спеціальні оточення, наприклад, `joes-staging`, що призводить до комбінаторного вибуху конфігурації, який робить керування розгортанням застосунку нестабільним.
-
-У застосунку дванадцяти факторів змінні оточення є незв'язаними між собою засобами керування. Кожна змінна повністю незалежна від інших. Вони ніколи не групуються разом в "оточення", керування ними здійснюється незалежно для кожного розгортання. Ця модель добре масштабується разом з появою більшої кількості розгортань застосунку протягом його експлуатації.
\ No newline at end of file
+Застосунки іноді зберігають конфігурації як константи в коді. Це є порушенням методології дванадцяти факторів,
+яка вимагає **обов'язкового відокремлення конфігурації від коду**. Конфігурації застосунку в розгортаннях суттєво
+відрізняються, код — однаковий.
+
+Лакмусовим папірцем того, чи правильно розділені конфігурація і код, є можливість в будь-який момент відкрити
+вихідний код застосунку у вільний доступ, при цьому не оприлюднюючи будь-яких приватних даних.
+
+Зверніть увагу, що визначення "конфігурації" **не містить** в собі внутрішні налаштування застосунку,
+такі як `сonfig/routes.rb` в Rails,
+або [як пов'язані основні модулі](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html)
+в [Spring](http://spring.io/). Ці налаштування не змінюються між розгортаннями, і тому краще місце для них — саме в коді.
+
+Іншим підходом до конфігурації є використання конфігураційних файлів, що не зберігаються в систему контролю версій,
+таких як `сonfig/database.yml` в Rails. Це перевага у порівнянні з використанням констант в коді, але все ж таки має
+суттєві недоліки: є ймовірність помилково зберегти файл конфігурації в репозиторій; існує тенденція коли конфігураційні
+файли розкидані в різних місцях і в різних форматах, і стає важко передивлятися всі налаштування і керувати ними в одному
+місці. Крім того, формати цих файлів, як правило, специфічні для конкретної мови програмування чи фреймворку.
+
+**Застосунок дванадцяти факторів зберігає конфігурацію в *змінних оточення*** (часто скорочується до *env vars* або *env*).
+Значення змінних оточення легко змінити між розгортаннями без зміни коду; на відміну від конфігураційних файлів,
+менш ймовірно випадково зберегти їх в репозиторій коду; і на відміну від конфігураційних файлів або інших механізмів
+конфігурації, таких як Java System Properties, вони є стандартом, незалежним від мови програмування чи фреймворку.
+
+Іншим аспектом керування конфігурацією є групування. Іноді застосунки об'єднують конфігурації в іменовані групи
+(які часто називаються "оточеннями"), які називаються в залежності від конкретного розгортання,
+наприклад, `development`, `test` і `production` оточення в Rails. Цей метод погано масштабується: чим більше створюється
+різних розгортань застосунку, тим більше необхідно нових імен оточень, наприклад, `staging` або `qa`.
+При подальшому рості проєкт розробники можуть додавати свої власні спеціальні оточення, наприклад, `joes-staging`,
+що призводить до комбінаторного вибуху конфігурації, який робить керування розгортанням застосунку нестабільним.
+
+У застосунку дванадцяти факторів змінні оточення є незв'язаними між собою засобами керування.
+Кожна змінна повністю незалежна від інших. Вони ніколи не групуються разом в "оточення", керування ними здійснюється
+незалежно для кожного розгортання. Ця модель добре масштабується разом з появою більшої кількості розгортань застосунку
+протягом його експлуатації.
\ No newline at end of file
diff --git a/content/uk/dependencies.md b/content/uk/dependencies.md
index 64dde9f30..c89ac0b6a 100644
--- a/content/uk/dependencies.md
+++ b/content/uk/dependencies.md
@@ -1,12 +1,34 @@
## II. Залежності
### Явно оголошуйте та ізолюйте залежності
-Більшість мов програмування мають системи пакунків для розповсюдження бібліотек, такі як [CPAN](http://www.cpan.org/) для Perl або [Rubygems](http://rubygems.org/) для Ruby. Бібліотеки, встановлені через систему пакунків, можуть бути доступними для всієї системи (так звані "site-packages") або встановлені в каталог застосунку (так звані "vendoring" або "bundling").
+Більшість мов програмування мають системи пакунків для розповсюдження бібліотек, такі як [CPAN](http://www.cpan.org/)
+для Perl або [Rubygems](http://rubygems.org/) для Ruby. Бібліотеки, встановлені через систему пакунків,
+можуть бути доступними для всієї системи (так звані "site-packages") або встановлені в каталог застосунку
+(так звані "vendoring" або "bundling").
-**Застосунок дванадцяти факторів ніколи не залежить від неявно існуючих, досупних всій системі пакунків.** Застосунок повно і точно вказує всі свої залежності за допомогою маніфесту *оголошення залежностей*. Крім того, він використовує інструмент *ізоляції залежністей* під час виконання, щоб гарантувати, що ніякі неявні залежності не "просочилися" з зовнішньої системи. Повна і явна специфікація залежностей використовується однаково як при розробці, так і в production.
+**Застосунок дванадцяти факторів ніколи не залежить від пакунків доступних всій системі котрі існують неявно.
+** Застосунок повно і точно вказує всі свої залежності за допомогою маніфесту *оголошення залежностей*.
+Крім того, він використовує інструмент *ізоляції залежностей* під час виконання, щоб гарантувати,
+що ніякі неявні залежності не "просочилися" з зовнішньої системи. Повна і явна специфікація залежностей використовується
+однаково як при розробці, так і в production.
-Наприклад, [Bundler](https://bundler.io/) в Ruby використовує `Gemfile` як формат маніфесту для оголошення залежностей і `bundle exec` для ізоляції залежностей. В Python є два окремі інструменти для цих задач - [Pip](http://www.pip-installer.org/en/latest/) використовується для оголошення і [Virtualenv](http://www.virtualenv.org/en/latest/) для ізоляції. Навіть C має [Autoconf](http://www.gnu.org/s/autoconf/) для оголошення залежностей, а статичне зв'язування може забезпечити ізоляцію залежностей. Який би не використовувався набір інструментів, оголошення і ізоляція залежностей завжди мають використовуватися разом — тільки одне або інше не є достатньою умовою для задоволення дванадцяти факторів.
+Наприклад, [Bundler](https://bundler.io/) в Ruby використовує `Gemfile` як формат маніфесту для оголошення
+залежностей і `bundle exec` для ізоляції залежностей. В Python є два окремі інструменти для цих задач
+- [Pip](http://www.pip-installer.org/en/latest/) використовується для оголошення
+- і [Virtualenv](http://www.virtualenv.org/en/latest/) для ізоляції.
+- Навіть C має [Autoconf](http://www.gnu.org/s/autoconf/) для оголошення залежностей, а статичне зв'язування може
+- забезпечити ізоляцію залежностей. Який би не використовувався набір інструментів, оголошення й ізоляція залежностей
+- завжди мають використовуватися разом — тільки одне або інше не є достатньою умовою для задоволення дванадцяти факторів.
-Однією з переваг явного оголошення залежностей є те, що це спрощує налаштування застосунку для нових розробників. Новий розробник може скопіювати кодову базу застосунку на свою машину, необхідними вимогами для якої є тільки наявність середовища виконання мови програмування та наявність менеджера залежностей. Все необхідне для запуску коду застосунку може бути налаштоване за допомогою визначеної *команди збірки*. Наприклад, команда збірки для Ruby/Bundler є `bundle install`, а для Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) це `lein deps`.
+Однією з переваг явного оголошення залежностей є те, що це спрощує налаштування застосунку для нових розробників.
+Новий розробник може скопіювати кодову базу застосунку на свою машину, необхідними вимогами для якої є тільки наявність
+середовища виконання мови програмування та наявність менеджера залежностей. Все необхідне для запуску коду застосунку
+може бути налаштоване за допомогою визначеної *команди збірки*. Наприклад, команда збірки для Ruby/Bundler
+є `bundle install`, а для Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) це `lein deps`.
-Застосунок дванадцяти факторів також ніколи не залежить від неявно існуючих будь-яких системних інструментів. Прикладом може бути запуск застосунком таких системних інструментів, як ImageMagick або `curl`. У той час, як ці інструменти можуть бути встановлені на багатьох або навіть більшості систем, немає жодної гарантії, що вони будуть встановлені на всіх системах, де застосунок може запускатися в майбутньому, або версія інструменту, встановлена в системі, буде сумісна з застосунком. Якщо застосунку потрібно запускати певні системні інструменти, то такі інструменти мають бути включені в сам застосунок.
\ No newline at end of file
+Застосунок дванадцяти факторів також ніколи не залежить від будь-яких системних інструментів котрі існують неявно.
+Прикладом може бути запуск застосунком таких системних інструментів, як ImageMagick або `curl`.
+У той час, як ці інструменти можуть бути встановлені на багатьох або навіть більшості систем, немає жодної гарантії,
+що вони будуть встановлені на всіх системах, де застосунок може запускатися в майбутньому, або версія інструменту,
+встановлена в системі, буде сумісна з застосунком. Якщо застосунку потрібно запускати певні системні інструменти,
+то такі інструменти мають бути включені в сам застосунок.
\ No newline at end of file
diff --git a/content/uk/dev-prod-parity.md b/content/uk/dev-prod-parity.md
index d31c57991..bb243c272 100644
--- a/content/uk/dev-prod-parity.md
+++ b/content/uk/dev-prod-parity.md
@@ -1,16 +1,21 @@
## X. Dev/prod паритет
### Прагніть максимальної ідентичності development, staging та production середовищ
-Історично склалося, що є суттєві відмінності між development середовищем (розробник вносить живі зміни в [локально розгорнутий](./codebase) застосунок) і production середовищем (до якого мають доступ кінцеві користувачі). Ці відмінності проявляються в трьох областях:
+Історично склалося, що є суттєві відмінності між development середовищем
+(розробник вносить живі зміни в [локально розгорнутий](./codebase) застосунок) і production середовищем
+(до якого мають доступ кінцеві користувачі). Ці відмінності проявляються в трьох областях:
* **Різниця в часі**: Розробник може працювати над кодом, який потрапить у production через дні, тижні або навіть місяці;
* **Різниця в персоналі**: Розробники пишуть код, Ops-інженери розгортають його;
-* **Різниця в інструментах**: Розробники можуть використовувати стек технологій такий, як Nginx, SQLite та OS X, в той час як на production використовується Apache, MySQL та Linux.
+* **Різниця в інструментах**: Розробники можуть використовувати стек технологій такий, як Nginx, SQLite та OS X,
+* в той час як на production використовується Apache, MySQL та Linux.
-**Застосунок дванадцяти факторів проектується для [безперервного розгортання](http://avc.com/2011/02/continuous-deployment/), завдяки мінімізації різниці між production і development середовищами.** Розглянемо три відмінності, описані вище:
+**Застосунок дванадцяти факторів проєктуватися для [безперервного розгортання](http://avc.com/2011/02/continuous-deployment/),
+завдяки мінімізації різниці між production і development середовищами.** Розглянемо три відмінності, описані вище:
* Зменшити різницю в часі: розробник може написати код і він буде розгорнутий через декілька годин або навіть хвилин;
-* Зменшити різницю в персоналі: розробники, які писали код, беруть активну участь в його розгортанні і спостерігають за його поведінкою на production;
+* Зменшити різницю в персоналі: розробники, які писали код, беруть активну участь в його розгортанні й спостерігають
+за його поведінкою на production;
* Зменшити різницю в інструментах: тримати development та production середовища максимально ідентичними.
Резюмуючи сказане вище в таблицю:
@@ -38,7 +43,9 @@
-[Сторонні служби](./backing-services), такі як бази даних, системи черг повідомлень або кеш, є однією з областей, де dev/prod паритет має важливе значення. Багато мов програмування мають бібліотеки, які спрощують доступ до сторонніх служб, в тому числі, *адаптери* для різних видів сервісів. Деякі приклади наведені в таблиці нижче.
+[Сторонні служби](./backing-services), такі як бази даних, системи черг повідомлень або кеш, є однією з областей,
+де dev/prod паритет має важливе значення. Багато мов програмування мають бібліотеки, які спрощують доступ до сторонніх
+служб, в тому числі *адаптери* для різних видів сервісів. Деякі приклади наведені в таблиці нижче.
-Іноді розробники бачать переваги у використанні "легких" сторонніх служб в їхньому локальному середовищі, в той час як більш серйозні і надійні сторонні служби будуть використовуватися у production. Наприклад, локально використовують SQLite, а на production PostgreSQL; або локально пам'ять процесу для кешування, а на production Memcached.
+Іноді розробники бачать переваги у використанні "легких" сторонніх служб в їхньому локальному середовищі,
+в той час, як більш серйозні й надійні сторонні служби будуть використовуватися у production.
+Наприклад, локально використовують SQLite, а на production PostgreSQL; або локально пам'ять процесу для кешування,
+а на production Memcached.
-**Розробник застосунку дванадцяти факторів уникає використання різних сторонніх служб в development і production середовищах**, навіть якщо адаптери теоретично абстраговані від будь-яких відмінностей у сторонніх службах. Відмінності між сторонніми службами означають, що може виникнути крихітна несумісність, в результаті чого код, який працював і пройшов тестування в development та staging середовищах, після розгортання не працює в production середовищі. Такий тип помилок створює перешкоди, які нівелюють переваги безперервного розгортання. Ціна цих перешкод і подальшого відновлення безперервного розгортання надзвичайно висока, якщо розглядати в сукупності за весь час експлуатації застосунку.
+**Розробник застосунку дванадцяти факторів уникає використання різних сторонніх служб в development і production
+середовищах**, навіть якщо адаптери теоретично абстраговані від будь-яких відмінностей у сторонніх службах.
+Відмінності між сторонніми службами означають, що може виникнути крихітна несумісність, в результаті чого код,
+який працював і пройшов тестування в development та staging середовищах, після розгортання не працює в production
+середовищі. Такий тип помилок створює перешкоди, які нівелюють переваги безперервного розгортання.
+Ціна цих перешкод і подальшого відновлення безперервного розгортання надзвичайно висока, якщо розглядати в сукупності
+за весь час експлуатації застосунку.
-Встановлення локально "легких" сторонніх сервісів вже не є таким привабливим, як було раніше. Сучасні надійні сторонні сервіси, такі як Memcached, PostgreSQL і RabbitMQ, досить легко встановити і запустити завдяки сучасним менеджерам пакунків, таким як [Homebrew](http://mxcl.github.com/homebrew/) і [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Крім того, декларативні інструменти підготовки середовища, такі як [Chef](http://www.opscode.com/chef/) і [Puppet](http://docs.puppetlabs.com/), у поєднанні з "легким" віртуальним середовищем, таким як [Vagrant](http://vagrantup.com/), дозволяють розробникам запускати локальні середовища, які наближені до production. Ціна встановлення і використання цих систем є низькою у порівнянні з користю dev/prod паритету і безперервного розгортання.
+Встановлення локально "легких" сторонніх сервісів вже не є таким привабливим, як було раніше.
+Сучасні надійні сторонні сервіси, такі як Memcached, PostgreSQL і RabbitMQ, досить легко встановити й запустити
+завдяки сучасним менеджерам пакунків, таким як [Homebrew](http://mxcl.github.com/homebrew/)
+і [apt-get](https://help.ubuntu.com/community/AptGet/Howto). Крім того, декларативні інструменти підготовки середовища,
+такі як [Chef](http://www.opscode.com/chef/) і [Puppet](http://docs.puppetlabs.com/), у поєднанні з "легким" віртуальним
+середовищем, таким як [Vagrant](http://vagrantup.com/), дозволяють розробникам запускати локальні середовища,
+які наближені до production. Ціна встановлення і використання цих систем є низькою у порівнянні з користю dev/prod паритету
+і безперервного розгортання.
-Адаптери для різних сторонніх сервісів все ж корисні, тому що вони роблять перенесення застосунку для використання з іншими сторонніми сервісами відносно безболісним. Але всі розгортання застосунку (development, staging та production середовища) мають використовувати один і той самий тип і версію кожного зі сторонніх сервісів.
\ No newline at end of file
+Адаптери для різних сторонніх сервісів все ж корисні, тому що вони роблять перенесення застосунку для використання
+з іншими сторонніми сервісами відносно безболісним. Але всі розгортання застосунку
+(development, staging та production середовища) мають використовувати один і той самий тип і версію кожного
+зі сторонніх сервісів.
\ No newline at end of file
diff --git a/content/uk/disposability.md b/content/uk/disposability.md
index 1aa86f6dd..18c66c4c5 100644
--- a/content/uk/disposability.md
+++ b/content/uk/disposability.md
@@ -1,12 +1,37 @@
-## IX. Утилізовуваність
+## IX. Одноразовість (Disposability)
### Підвищуйте надійність за допомогою швидкого запуску і коректного вимкнення
-**[Процеси](./processes) застосунку дванадцати факторів є *утилізовуваними*, тобто вони можуть бути запущені або зупинені в будь-який момент.** Це сприяє гнучкому масштабуванню, швидкому розгортанню [коду](./codebase) або змінам [конфігурації](./config) і надійності production-розгортання.
+**[Процеси](./processes) застосунку дванадцяти факторів є *одноразовими*, тобто вони можуть бути запущені
+або зупинені в будь-який момент.** Це сприяє гнучкому масштабуванню, швидкому розгортанню [коду](./codebase)
+або змінам [конфігурації](./config) й надійності production-розгортання.
-Слід намагатися **мінімізувати час запуску процесів**. В ідеалі час між моментом виконання команди запуску процесу і моментом, коли процес готовий приймати запити чи задачі, має тривати лише пару секунд. Короткий час запуску забезпечує більшу гнучкість для [релізу](./build-release-run) і масштабування. Крім того, це підвищує стійкість, оскільки менеджер процесів може легко переміщувати процеси на нові фізичні машини у разі необхідності.
+Слід намагатися **мінімізувати час запуску процесів**. В ідеалі час між моментом виконання команди запуску процесу
+і моментом, коли процес готовий приймати запити чи задачі, має тривати лише пару секунд. Короткий час запуску
+забезпечує більшу гнучкість для [релізу](./build-release-run) і масштабування. Крім того, це підвищує стійкість,
+оскільки менеджер процесів може легко переміщувати процеси на нові фізичні машини у разі необхідності.
-Процеси мають **коректно завершувати свою роботу, коли вони отримують [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)** сигнал від диспетчеру процесів. Для веб-процесу коректне завершення роботи досягається завдяки припиненню прослуховування порту, до якого він прив'язаний (що означає відмову від отримання будь-яких нових запитів), завершенню обробки будь-яких поточних запитів та зупинці самого процесу. В цій моделі передбачається, що HTTP-запити короткі (не більше ніж кілька секунд), а у разі довгих запитів (long polling) клієнт має намагатися відновити з'єднання у разі його втрати.
+Процеси мають **коректно завершувати свою роботу, коли вони отримують [SIGTERM](http://en.wikipedia.org/wiki/SIGTERM)**
+сигнал від диспетчера процесів. Для вебпроцесу коректне завершення роботи досягається завдяки припиненню прослуховування
+порту, до якого він прив'язаний (що означає відмову від отримання будь-яких нових запитів),
+завершенню обробки будь-яких поточних запитів та зупинці самого процесу. В цій моделі передбачається,
+що HTTP-запити короткі (не більше ніж кілька секунд), а у разі довгих запитів (long polling) клієнт має намагатися
+відновити з'єднання у разі його втрати.
-Для процесу, що виконує фонові задачі (worker), коректне завершення роботи досягається за рахунок повернення поточного завдання назад у чергу задач. Наприклад, в [RabbitMQ](http://www.rabbitmq.com/) робочий процес може надіслати команду [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); в [Beanstalkd](https://beanstalkd.github.io) завдання повертається в чергу автоматично щоразу, коли процес втрачає з'єднання. Системи, що використовують блокування, такі як [Delayed Job](https://github.com/collectiveidea/delayed_job#readme), мають бути повідомлені, щоб звільнити блокування задачі. В цій моделі передбачається, що всі задачі є [повторно вхідними](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29), що зазвичай досягається шляхом обертання результатів їхньої роботи в транзакції або шляхом використання [ідемпотентних](http://en.wikipedia.org/wiki/Idempotence) операцій.
+Для процесу, що виконує фонові задачі (worker), коректне завершення роботи досягається коштом повернення поточного
+завдання назад у чергу задач. Наприклад, в [RabbitMQ](http://www.rabbitmq.com/) робочий процес може надіслати
+команду [`NACK`](http://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack);
+в [Beanstalkd](https://beanstalkd.github.io) завдання повертається в чергу автоматично щоразу,
+коли процес втрачає з'єднання. Системи, що використовують блокування,
+такі як [Delayed Job](https://github.com/collectiveidea/delayed_job#readme), мають бути повідомлені,
+щоб звільнити блокування задачі. В цій моделі передбачається,
+що всі задачі є [повторно вхідними](http://en.wikipedia.org/wiki/Reentrant_%28subroutine%29),
+що зазвичай досягається шляхом обертання результатів їхньої роботи в транзакції або шляхом
+використання [ідемпотентних](http://en.wikipedia.org/wiki/Idempotence) операцій.
-Процеси також мають бути **стійкі до раптової зупинки** в разі відмови апаратних засобів, на яких вони запущені. Хоча це менш ймовірна подія, ніж коректне завершення роботи за допомогою сигналу `SIGTERM`, вона все ж таки може статися. Рекомендованим підходом є використання надійних черг завдань, таких як Beanstalkd, які повертають завдання в чергу задач, коли клієнти втрачають з'єднання або від'єднуються по тайм-ауту. У будь-якому випадку, застосунок дванадцяти факторів має проектуватися таким чином, щоб обробляти несподівані та некоректні вимкнення. Прикладом вдалої реалізації [архітектури "тільки аварійного вимкнення" (Crash-only design)](http://lwn.net/Articles/191059/) є [СouchDB](http://docs.couchdb.org/en/latest/intro/overview.html).
+Процеси також мають бути **стійкі до раптової зупинки** в разі відмови апаратних засобів, на яких вони запущені.
+Хоча це менш ймовірна подія, ніж коректне завершення роботи за допомогою сигналу `SIGTERM`, вона все ж таки може статися.
+Рекомендованим підходом є використання надійних черг завдань, таких як Beanstalkd, які повертають завдання в чергу задач,
+коли клієнти втрачають з'єднання або від'єднуються по тайм-ауту. У будь-якому випадку, застосунок дванадцяти факторів
+має проєктуватися таким чином, щоб обробляти несподівані та некоректні вимкнення.
+Прикладом вдалої реалізації [архітектури "тільки аварійного вимкнення" (Crash-only design)](http://lwn.net/Articles/191059/)
+є [CouchDB](http://docs.couchdb.org/en/latest/intro/overview.html).
diff --git a/content/uk/intro.md b/content/uk/intro.md
index 736e89c77..5259f7cfd 100644
--- a/content/uk/intro.md
+++ b/content/uk/intro.md
@@ -1,12 +1,17 @@
Вступ
=====
-У наш час програмне забезпечення зазвичай поставляється у вигляді сервісів, що називаються *веб-застосунки* (web-apps) або *software-as-a-service* (SaaS). Застосунок дванадцяти факторів — це методологія для створення SaaS-застосунків, які:
+У наш час програмне забезпечення зазвичай поставляється у вигляді сервісів, що називаються *веб-застосунки* (web-apps)
+або *software-as-a-service* (SaaS). Застосунок дванадцяти факторів — це методологія для створення SaaS-застосунків, які:
-* Використовують **декларативний** формат для автоматизації встановлення та налаштування, що зводить до мінімуму витрати часу і коштів для нових розробників, що приєднуються до проекту;
-* Мають **угоду** з операційною системою, пропонуючи **максимальну переносимість** між середовищами виконання;
-* Придатні для **розгортання** на сучасних **хмарних платформах**, що усуває необхідність у серверах та їх системному адмініструванні;
-* **Мінімізують різницю** між середовищем розробки і production середовищем, що дозволяє **безперервне розгортання** (continuous deployment) для забезпечення максимальної спритності розробки (agility);
-* Можуть **масштабуватися** без значних змін в інструментах, архітектурі і практиці розробки.
+* Використовують **декларативний** формат для автоматизації встановлення та налаштування, що зводить до мінімуму
+витрати часу і коштів для нових розробників, що приєднуються до проєкту;
+* Мають **угоду** з операційною системою, пропонуючи **максимальну портативність** між середовищами виконання;
+* Придатні для **розгортання** на сучасних **хмарних платформах**, що усуває необхідність у серверах
+їх системному адмініструванні;
+* **Мінімізують різницю** між середовищем розробки й production середовищем, що дозволяє **безперервне розгортання**
+(continuous deployment) для забезпечення максимальної спритності розробки (agility);
+* Можуть **масштабуватися** без значних змін в інструментах, архітектурі й практиці розробки.
-Методологію дванадцяти факторів можна використати для застосунків, що написані будь-якою мовою програмування та використовують будь-яку комбінацію із сторонніх служб (бази даних, черги, кеш-пам'ять тощо).
\ No newline at end of file
+Методологію дванадцяти факторів можна використати для застосунків, що написані будь-якою мовою програмування та
+використовують будь-яку комбінацію зі сторонніх служб (бази даних, черги, кеш-пам'ять тощо).
\ No newline at end of file
diff --git a/content/uk/logs.md b/content/uk/logs.md
index 324dc0b39..2ca82df84 100644
--- a/content/uk/logs.md
+++ b/content/uk/logs.md
@@ -1,16 +1,33 @@
## XI. Журналювання
### Сприймайте журналювання (logs) як потоки подій
-*Журналювання* забезпечує наочне уявлення про поведінку запущеного застосунку. Зазвичай у серверних середовищах журнали записуються у файл на диску ("logfile"), але це лише один з форматів виведення.
+*Журналювання* забезпечує наочне уявлення про поведінку запущеного застосунку. Зазвичай у серверних середовищах
+журнали записуються у файл на диску ("logfile"), але це лише один з форматів виведення.
-Журнал — це [потік](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) агрегованих, впорядкованих за часом подій, зібраних з потоків виведення всіх запущених процесів і сторонніх сервісів. Журнал в сирому вигляді, як правило, має текстовий формат з однією подією на кожен рядок (хоча трасування винятків можуть займати кілька рядків). Журнали не мають фіксованого початку і кінця, потік безперервний поки працює застосунок.
+Журнал — це [потік](https://adam.herokuapp.com/past/2011/4/1/logs_are_streams_not_files/) агрегованих,
+впорядкованих за часом подій, зібраних з потоків виведення всіх запущених процесів і сторонніх сервісів.
+Журнал в сирому вигляді, як правило, має текстовий формат з однією подією на кожен рядок (хоча трасування винятків
+можуть займати кілька рядків). Журнали не мають фіксованого початку і кінця, потік безперервний поки працює застосунок.
-**Застосунок дванадцяти факторів ніколи не займається маршрутизацію і зберіганням свого потоку виведення.** Застосунок не повинен записувати журнал у файл або керувати файлами журналів. Замість цього кожен запущений процес записує свій потік подій без буферизації в стандартне виведення `stdout`. В development середовищі розробник має можливість переглядати цей потік в терміналі, щоб спостерігати за поведінкою застосунку.
+**Застосунок дванадцяти факторів ніколи не займається маршрутизацію і зберіганням свого потоку виведення.
+** Застосунок не повинен записувати журнал у файл або керувати файлами журналів. Замість цього кожен запущений
+процес записує свій потік подій без буферизації в стандартне виведення `stdout`. В development середовищі розробник
+має можливість переглядати цей потік в терміналі, щоб спостерігати за поведінкою застосунку.
-В staging та production розгортаннях потік виведення кожного процесу перехоплюється середовищем виконання, збирається разом з усіма іншими потоками виведення застосунку і спрямовується до одного або кількох кінцевих пунктів призначення для перегляду і довгострокового архівування. Ці кінцеві пункти призначення не видимі для застосунку і не налаштовуються ним, вони керуються середовищем виконання. Для цього можуть бути використані маршрутизатори журналів з відкритим вихідним кодом (наприклад, [Logplex](https://github.com/heroku/logplex) та [Fluentd](https://github.com/fluent/fluentd)).
+В staging та production розгортаннях потік виведення кожного процесу перехоплюється середовищем виконання,
+збирається разом з усіма іншими потоками виведення застосунку і спрямовується до одного або кількох кінцевих
+пунктів призначення для перегляду і довгострокового архівування. Ці кінцеві пункти призначення не видимі
+для застосунку і не налаштовуються ним, вони керуються середовищем виконання. Для цього можуть бути використані
+маршрутизатори журналів з відкритим вихідним кодом (наприклад, [Logplex](https://github.com/heroku/logplex)
+та [Fluentd](https://github.com/fluent/fluentd)).
-Потік подій застосунку може бути направлений у файл або переглянутий у терміналі в режимі реального часу. Найважливішим є те, що потік може бути направлений у систему індексування і аналізу журналів, таку як [Splunk](http://www.splunk.com/), або систему зберігання даних загального призначення, таку як [Hadoop/Hive](http://hive.apache.org/). Ці системи мають широкі можливості і гнучкість для детального аналізу поведінки застосунку протягом тривалого часу, в тому числі:
+Потік подій застосунку може бути направлений у файл або переглянутий у терміналі в режимі реального часу.
+Найважливішим є те, що потік може бути направлений у систему індексування й аналізу журналів,
+таку як [Splunk](http://www.splunk.com/), або систему зберігання даних загального призначення,
+таку як [Hadoop/Hive](http://hive.apache.org/). Ці системи мають широкі можливості й гнучкість для детального
+аналізу поведінки застосунку протягом тривалого часу, в тому числі:
* Виявлення конкретних подій у минулому;
* Побудова графіків трендів (наприклад, кількість запитів за хвилину);
-* Активне оповіщення відповідно до визначених користувачем евристичних правил (наприклад, попередження, коли кількість помилок за хвилину перевищує певний поріг).
+* Активне оповіщення відповідно до визначених користувачем евристичних правил (наприклад, попередження,
+коли кількість помилок за хвилину перевищує певний поріг).
diff --git a/content/uk/port-binding.md b/content/uk/port-binding.md
index 99ae00cb7..e354dffb3 100644
--- a/content/uk/port-binding.md
+++ b/content/uk/port-binding.md
@@ -1,14 +1,29 @@
## VII. Прив'язка портів
### Експортуйте сервіси за допомогою прив'язки портів (port binding)
-Веб-застосунки іноді запускаються всередині контейнера веб-сервера. Наприклад, PHP-застосунок може бути запущений як модуль всередині [Apache HTTPD](http://httpd.apache.org/) або Java-застосунок може бути запущений всередині [Tomcat](http://tomcat.apache.org/).
+Веб-застосунки іноді запускаються всередині контейнера веб-сервера. Наприклад,
+PHP-застосунок може бути запущений як модуль всередині [Apache HTTPD](http://httpd.apache.org/)
+або Java-застосунок може бути запущений всередині [Tomcat](http://tomcat.apache.org/).
-**Застосунок дванадцяти факторів є повністю автономним** і в процесі виконання, щоб створити веб-сервіс, доступний через web, не покладається на ін'єкцію веб-сервера в середовище виконання. Веб-застосунок **експортує HTTP-сервіс шляхом прив'язки до порту** і прослуховує запити, що надходять на цей порт.
+**Застосунок дванадцяти факторів є повністю автономним** і в процесі виконання, щоб створити вебсервіс,
+доступний через web, не покладається на ін'єкцію вебсервер в середовище виконання. Вебзастосунок
+**експортує HTTP-сервіс шляхом прив'язки до порту** і прослуховує запити, що надходять на цей порт.
-У локальному development середовищі розробник відвідує URL-адресу вигляду `http://localhost:5000/` для доступу до сервісу, що експортується застосунком. При розгортанні рівень маршрутизації обробляє запити до загальнодоступного хосту і перенаправляє їх до порту, до якого прив'язано веб-процес.
+У локальному development середовищі розробник відвідує URL-адресу вигляду `http://localhost:5000/`
+для доступу до сервісу, що експортується застосунком. При розгортанні рівень маршрутизації обробляє запити до
+загальнодоступного хосту і перенаправляє їх до порту, до якого прив'язано вебпроцес.
-Як правило, це реалізується за допомогою [оголошення залежностей] (./dependencies) шляхом додавання бібліотеки веб-сервера до застосунку, наприклад, [Tornado](http://www.tornadoweb.org/) для Python, [Thin](http://code.macournoyer.com/thin/) для Ruby або [Jetty](http://www.eclipse.org/jetty/) для Java та інших мов на основі JVM. Це відбувається повністю в *просторі користувача*, тобто в коді застосунку. Прив'язка до порту для обробки запитів є "угодою" із середовищем виконання.
+Як правило, це реалізується за допомогою [оголошення залежностей] (./dependencies) шляхом додавання бібліотеки
+вебсервер до застосунку, наприклад, [Tornado](http://www.tornadoweb.org/)
+для Python, [Thin](http://code.macournoyer.com/thin/) для Ruby або [Jetty](http://www.eclipse.org/jetty/)
+для Java та інших мов на основі JVM. Це відбувається повністю в *просторі користувача*, тобто в коді застосунку.
+Прив'язка до порту для обробки запитів є "угодою" із середовищем виконання.
-HTTP — не єдиний сервіс, який може бути експортований шляхом прив'язки до порту. Майже будь-який вид серверного програмного забезпечення може бути запущений, прив'язаний до порту і може очікувати вхідні запити. Прикладами є [ejabberd](http://www.ejabberd.im/) (використовує [XMPP](http://xmpp.org/)) і [Redis](http://redis.io/) (використовує [протокол Redis](http://redis.io/topics/protocol)).
+HTTP — не єдиний сервіс, який може бути експортований шляхом прив'язки до порту. Майже будь-який вид серверного
+програмного забезпечення може бути запущений, прив'язаний до порту і може очікувати вхідні запити.
+Прикладами є [ejabberd](http://www.ejabberd.im/) (використовує [XMPP](http://xmpp.org/))
+і [Redis](http://redis.io/) (використовує [протокол Redis](http://redis.io/topics/protocol)).
-Також зверніть увагу, що підхід прив'язки до портів означає, що застосунок може виступати як [стороння служба](./backing-services) для іншого застосунку, надаючи свою URL-адресу як ресурс в [конфігурації](./config) застосунку-споживача.
\ No newline at end of file
+Також зверніть увагу, що підхід прив'язки до портів означає, що застосунок може виступати
+як [стороння служба](./backing-services) для іншого застосунку,
+надаючи свою URL-адресу як ресурс в [конфігурації](./config) застосунку-споживача.
\ No newline at end of file
diff --git a/content/uk/processes.md b/content/uk/processes.md
index be4a0b338..cc88fb924 100644
--- a/content/uk/processes.md
+++ b/content/uk/processes.md
@@ -1,14 +1,34 @@
## VI. Процеси
-### Запускайте застосунок як один або декілька процесів без збереження внутрішньго стану (stateless)
+### Запускайте застосунок як один або декілька процесів без збереження внутрішньо стану (stateless)
Застосунок запускається в середовищі виконання у вигляді одного або декількох *процесів*.
-У найпростішому випадку код є окремим скриптом, середовище виконання — ноутбук розробника зі встановленим середовищем виконання мови програмування, а процес запускається за допомогою командного рядка (наприклад, `python my_script.py`). В іншому випадку, це може бути production-розгортання складного застосунку, яке може використовувати багато [типів процесів, кожен з яких запущений у необхідній кількості екземплярів](./concurrency).
+У найпростішому випадку код є окремим скриптом, середовище виконання — ноутбук розробника зі встановленим
+середовищем виконання мови програмування, а процес запускається за допомогою командного рядка
+(наприклад, `python my_script.py`). В іншому випадку, це може бути production-розгортання складного застосунку,
+яке може використовувати багато [типів процесів, кожен з яких запущений у необхідній кількості екземплярів](./concurrency).
-**Процеси застосунку дванадцяти факторів не зберігають внутрішній стан (stateless) і [не розділяють ресурси](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Будь-які дані, що підлягають збереженню, мають зберігатися в [сторонній службі](./backing-services) зі збереженням внутрішнього стану (stateful) (як правило, в базі даних).
+**Процеси застосунку дванадцяти факторів не зберігають внутрішній стан (stateless)
+і [не розділяють ресурси](http://en.wikipedia.org/wiki/Shared_nothing_architecture).** Будь-які дані,
+що підлягають збереженню, мають зберігатися в [сторонній службі](./backing-services) зі збереженням внутрішнього стану
+(stateful) (як правило, в базі даних).
-Пам'ять та файлова система процесу можуть бути використані як короткостроковий кеш. Наприклад, завантаження, обробка і збереження великого файлу в базі даних. Застосунок дванадцяти факторів ніколи не припускає, що щось, закешоване в пам'яті або на диску, буде доступне при наступному запиті — за наявності багатьох запущених процесів різних типів є велика ймовірність, що наступний запит буде оброблений іншим процесом. Навіть при роботі тільки одного процесу перезапуск (викликаний розгортанням, змінами конфігурації або переміщенням процесу в інше фізичне місце розташування середовищем виконання), як правило, призведе до знищення всіх локальних (у пам'яті і файловій системі) станів.
+Пам'ять та файлова система процесу можуть бути використані як короткостроковий кеш. Наприклад, завантаження,
+обробка і збереження великого файлу в базі даних. Застосунок дванадцяти факторів ніколи не припускає, що щось,
+кешоване в пам'яті або на диску, буде доступне при наступному запиті — за наявності багатьох запущених процесів
+різних типів є велика ймовірність, що наступний запит буде оброблений іншим процесом.
+Навіть при роботі тільки одного процесу перезапуск (викликаний розгортанням, змінами конфігурації або переміщенням
+процесу в інше фізичне місце розташування середовищем виконання), як правило, призведе до знищення всіх
+локальних (у пам'яті й файловій системі) станів.
-Пакувальники ресурсів (наприклад, [Jammit](http://documentcloud.github.com/jammit/) або [django-compressor](http://django-compressor.readthedocs.org/)) використовують файлову систему як кеш для скомпільованих ресурсів. Застосунок дванадцяти факторів надає перевагу здійсненню такої компіляції під час [етапу збірки](./build-release-run), наприклад, як в [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html), а не під час виконання.
+Пакувальники ресурсів (наприклад, [Jammit](http://documentcloud.github.com/jammit/)
+або [django-compressor](http://django-compressor.readthedocs.org/)) використовують файлову систему як кеш для
+скомпільованих ресурсів. Застосунок дванадцяти факторів надає перевагу здійсненню такої компіляції під
+час [етапу збірки](./build-release-run), наприклад,
+як в [Rails asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html), а не під час виконання.
-Деякі веб-системи покладаються на ["липкі сесії"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence) — тобто кешують дані сесії користувача в пам'яті процесу застосунку і очікують, що наступні запити від того ж самого користувача будуть спрямовані до того ж самого процесу. Липкі сесії є порушенням дванадцяти факторів і їх ніколи не слід використовувати та покладатися на них. Дані сесії користувача є хорошим кандидатом для сховища даних, яке надає функцію обмеження терміну зберігання, наприклад, [Memcached](http://memcached.org/) або [Redis](http://redis.io/).
\ No newline at end of file
+Деякі вебсистеми покладаються на ["липкі сесії"](http://en.wikipedia.org/wiki/Load_balancing_%28computing%29#Persistence)
+— тобто кешують дані сесії користувача в пам'яті процесу застосунку й очікують, що наступні запити від того ж самого
+користувача будуть спрямовані до того ж самого процесу. Липкі сесії є порушенням дванадцяти факторів і їх ніколи не
+слід використовувати та покладатися на них. Дані сесії користувача є хорошим кандидатом для сховища даних, яке надає
+функцію обмеження терміну зберігання, наприклад, [Memcached](http://memcached.org/) або [Redis](http://redis.io/).
\ No newline at end of file
diff --git a/content/uk/toc.md b/content/uk/toc.md
index b9f5cb23e..3facde8d8 100644
--- a/content/uk/toc.md
+++ b/content/uk/toc.md
@@ -2,7 +2,7 @@
===================
## [I. Кодова база](./codebase)
-### Одна кодова база, що відслідковується в системі контролю версій та має багато розгортань
+### Одна кодова база, що відстежується в системі контролю версій та має багато розгортань
## [II. Залежності](./dependencies)
### Явно оголошуйте та ізолюйте залежності
@@ -17,7 +17,7 @@
### Суворо відокремлюйте етапи збірки та виконання
## [VI. Процеси](./processes)
-### Запускайте застосунок як один або декілька процесів без збереження внутрішньго стану (stateless)
+### Запускайте застосунок як один або декілька процесів без збереження внутрішнього стану (stateless)
## [VII. Прив'язка портів](./port-binding)
### Експортуйте сервіси за допомогою прив'язки портів (port binding)
@@ -25,7 +25,7 @@
## [VIII. Конкурентність](./concurrency)
### Масштабуйте застосунок за допомогою процесів
-## [IX. Утилізовуваність](./disposability)
+## [IX. Одноразовість](./disposability)
### Підвищуйте надійність за допомогою швидкого запуску і коректного вимкнення
## [X. Dev/prod паритет](./dev-prod-parity)