Merge pull request #159 from kamil89/patch-1

Fix typo in polish disposability translation

content/pl/disposability.md

@@ -7,7 +7,7 @@ Procesy powinny dążyć do **minimalizowania czasu swojego rozruchu**. W idealn
 
 Procesy **zamykają się gdy otrzymają sygnał [SIGTERM](http:https://en.wikipedia.org/wiki/SIGTERM)** od managera procesów. Dla procesów sieciowych poprawne zamknięcie polega na zakończeniu nasłuchiwania na porcie usługi (skutkiem czego jest odrzucanie nowych zapytań), zakończenie obecnych, a ostatecznie zaprzestaniu działania. Wynika z tego, że zapytania HTTP są krótkie (trwają nie więcej niż kilka sekund), lub w przypadku `long pollingu` i utraty połączenia klient powinien bezproblemowo spróbować połączyć się ponownie.
 
-Dla procesów roboczych poprawnym zamknięciem jest zwrot obecnie wykonywanego zadania do kolejki. Dla przykładu w [RabbitMQ](http:https://www.rabbitmq.com/) działający proces może wysłać wiadomość [`NACK`](http:https://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); w [Beanstalkd](http:https://kr.github.com/beanstalkd/), zadanie jest zwracane do kolejki automatycznie, gdy tylko proces się rozłączy. Systemy bazujące na blokadach zasobów jak [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) muszą upewnić się, że odblokowały zajmowany wcześniej zasób. W tym modelu ważne jest to, że wszystkie zadania są [wielobieżne](http:https://pl.wikipedia.org/wiki/Wielobieżność), co zazwyczaj jest osiągane przez zebranie wyników w transakcję lub uczynienie operacji [indepotentną](http:https://pl.wikipedia.org/wiki/Idempotentno%C5%9B%C4%87).
+Dla procesów roboczych poprawnym zamknięciem jest zwrot obecnie wykonywanego zadania do kolejki. Dla przykładu w [RabbitMQ](http:https://www.rabbitmq.com/) działający proces może wysłać wiadomość [`NACK`](http:https://www.rabbitmq.com/amqp-0-9-1-quickref.html#basic.nack); w [Beanstalkd](http:https://kr.github.com/beanstalkd/), zadanie jest zwracane do kolejki automatycznie, gdy tylko proces się rozłączy. Systemy bazujące na blokadach zasobów jak [Delayed Job](https://github.com/collectiveidea/delayed_job#readme) muszą upewnić się, że odblokowały zajmowany wcześniej zasób. W tym modelu ważne jest to, że wszystkie zadania są [wielobieżne](http:https://pl.wikipedia.org/wiki/Wielobieżność), co zazwyczaj jest osiągane przez zebranie wyników w transakcję lub uczynienie operacji [idempotentną](http:https://pl.wikipedia.org/wiki/Idempotentno%C5%9B%C4%87).
 
 Architektura aplikacji 12factor jest również zaprojektowana by działające procesy zostały poprawnie **zakończone w razie awarii** sprzętu. Podczas gdy taka sytuacja jest o wiele rzadsza niż otrzymanie sygnału `SIGTERM`, wciąż może mieć miejsce. Zalecanym podejściem w takich przypadkach jest stosowanie serwerowego systemu kolejkowania zadań, jak Beanstalkd, który zwróci zadanie do kolejki, gdy klient się rozłączy, bądź minie maksymalny czas obsługi pojedynczego zapytania. Architektura ["crash-only"](http:https://lwn.net/Articles/191059/) jest więc rozwinięciem takiego [konceptu](http:https://docs.couchdb.org/en/latest/intro/overview.html).