Merge pull request #178 from arialdomartini/typos

Typos in the Italian translation

content/it/admin-processes.md

@@ -1,14 +1,14 @@
 ## XII. Processi di Amministrazione
 ### Esegui i task di amministrazione come processi una tantum
 
-La "[process formation](./concurrency)" è l'array dei processi che vengono usati durante le normali operazioni dell'applicazione (ad esempio, la gestione delle richieste web). Non è tutto, però: ci sono dei task che lo sviluppatore può voler eseguire, una volta ogni tanto. Ad esempio:
+La "[process formation](./concurrency)" è l'array dei processi che vengono usati durante le normali operazioni dell'applicazione (per esempio, la gestione delle richieste web). Non è tutto, però: ci sono dei task che lo sviluppatore può voler eseguire, una volta ogni tanto. Per esempio:
 
 * Esecuzione delle migration del database (esempi: `manage.py migrate` in Django, `rake db:migrate` in Rails).
-* Esecuzione di una console (una [REPL](http:https://en.wikipedia.org/wiki/Read-eval-print_loop) shell) in modo tale da avviare del codice arbitrariamente o analizzare alcuni aspetti dell'applicazione specifici. Molti linguaggi prevedono una REPL, in genere avviando l'interprete senza opzioni ed argomenti aggiuntivi (esempi: `python` o `perl`) o in alcuni casi eseguibile con un comando separato (esempi: `irb` per Ruby, `rails console` per Rails).
+* Esecuzione di una console (una [REPL](http:https://en.wikipedia.org/wiki/Read-eval-print_loop) shell) in modo tale da avviare del codice arbitrariamente o analizzare alcuni aspetti dell'applicazione specifici. Molti linguaggi prevedono una REPL, in genere avviando l'interprete senza opzioni e argomenti aggiuntivi (esempi: `python` o `perl`) o in alcuni casi eseguibile con un comando separato (esempi: `irb` per Ruby, `rails console` per Rails).
 * Esecuzione one-time di alcuni script specifici (esempio: `php scripts/fix_bad_records.php`).
 
-Tali processi dovrebbero essere avviati in un ambiente identico a quello in cui [lavorano gli altri](./processes) nel contesto dell'applicazione. Dovrebbero essere eseguiti quindi su una specifica [release](./build-release-run), partendo dalla stessa [codebase](./codebase) ed impostazioni di [configurazione](./config). Il codice per l'amministrazione dovrebbe inoltre essere incluso nel codice dell'applicazione, in modo tale da evitare qualsiasi problema di sincronizzazione.
+Tali processi dovrebbero essere avviati in un ambiente identico a quello in cui [lavorano gli altri](./processes) nel contesto dell'applicazione. Dovrebbero essere eseguiti quindi su una specifica [release](./build-release-run), partendo dalla stessa [codebase](./codebase) e impostazioni di [configurazione](./config). Il codice per l'amministrazione dovrebbe inoltre essere incluso nel codice dell'applicazione, in modo tale da evitare qualsiasi problema di sincronizzazione.
 
-La stessa tecnica di [isolamento delle dipendenze](./dependencies) dovrebbe poter essere usata allo stesso modo su tutti i processi. Ad esempio, se il processo web di Ruby può usare il comando `bundle exec thin start`, una migration del database dovrebbe poter usare `bundle exec rake db:migrate` senza problemi. Allo stesso modo, un programma Python che usa Virtualenv dovrebbe usare il `bin/python` per eseguire sia i server Tornado che processi di amministrazione.
+La stessa tecnica di [isolamento delle dipendenze](./dependencies) dovrebbe poter essere usata allo stesso modo su tutti i processi. Per esempio, se il processo web di Ruby può usare il comando `bundle exec thin start`, una migration del database dovrebbe poter usare `bundle exec rake db:migrate` senza problemi. Allo stesso modo, un programma Python che usa Virtualenv dovrebbe usare il `bin/python` per eseguire sia i server Tornado che processi di amministrazione.
 
-La metodologia twelve-factor favorisce molto tutti quei linguaggi che offrono una shell REPL out of the box, rendendo quindi semplice l'esecuzione di script una tantum. In un deploy locale, gli sviluppatori possono invocare questi processi speciali tramite un semplice comando diretto. In un ambiente di produzione, invece, gli sviluppatori possono raggiungere lo stesso obiettivo tramite SSH o un qualsiasi altro sistema di esecuzione di comandi remoto.
+La metodologia twelve-factor favorisce molto tutti quei linguaggi che offrono una shell REPL out of the box, rendendo quindi semplice l'esecuzione di script una tantum. In un deployment locale, gli sviluppatori possono invocare questi processi speciali tramite un semplice comando diretto. In un ambiente di produzione, invece, gli sviluppatori possono raggiungere lo stesso obiettivo tramite SSH o un qualsiasi altro sistema di esecuzione di comandi remoto.

content/it/background.md

@@ -1,8 +1,8 @@
 Background
 ==========
 
-Chi ha scritto questo documento è stato coinvolto direttamente nella realizzazione e deploy di centinaia di applicazioni, ed indirettamente assistito allo sviluppo, operazioni e scaling di centinaia (o migliaia) di app tramite il proprio lavoro sulla piattaforma [Heroku](http:https://www.heroku.com/).
+Chi ha scritto questo documento è stato coinvolto direttamente nella realizzazione e nel deployment di centinaia di applicazioni, e ha indirettamente assistito allo sviluppo, le operazioni e lo scaling di centinaia (o migliaia) di app tramite il proprio lavoro sulla piattaforma [Heroku](http:https://www.heroku.com/).
 
 Questo documento riassume tutta quella che è stata la nostra esperienza, basata sull'osservazione di un grande numero di applicazioni SaaS. Si tratta di una "triangolazione" di pratiche di sviluppo ideali (con una particolare attenzione alla crescita organica dell'app nel tempo), la collaborazione dinamica nel corso del tempo tra gli sviluppatori sulla codebase e la necessità di evitare i costi di [software erosion](http:https://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/).
 
-La nostra motivazione è di far crescere la consapevolezza intorno ad alcuni problemi sistemici che abbiamo scoperto nello sviluppo di applicazioni moderne, cercando di fornire un vocabolario condiviso per la discussione di tali problemi. Oltre, ovviamente, ad offrire delle soluzioni concettuali a queste situazioni (senza però tralasciare il fattore tecnologia). Questo format si rifà ai libri di Martin Fowler *[Patterns of Enterprise Application Architecture](http:https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* e *[Refactoring](http:https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*.
+La nostra motivazione è di far crescere la consapevolezza intorno ad alcuni problemi sistemici che abbiamo scoperto nello sviluppo di applicazioni moderne, cercando di fornire un vocabolario condiviso per la discussione di tali problemi. Oltre, ovviamente, a offrire delle soluzioni concettuali a queste situazioni (senza però tralasciare il fattore tecnologia). Questo format si rifà ai libri di Martin Fowler *[Patterns of Enterprise Application Architecture](http:https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC)* e *[Refactoring](http:https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C)*.

content/it/backing-services.md

@@ -3,12 +3,12 @@
 
 Un "backing service" è un qualsiasi servizio che l'applicazione consuma attraverso la rete durante la sua esecuzione. Alcuni esempi includono i database (come [MySQL](http:https://dev.mysql.com/) o [CouchDB](http:https://couchdb.apache.org/)), servizi di messaging/code (come [RabbitMQ](http:https://www.rabbitmq.com/) oppure [Beanstalkd](http:https://kr.github.com/beanstalkd/)), servizi SMTP per la posta (come [Postfix](http:https://www.postfix.org/)) e sistemi di cache (come [Memcached](http:https://memcached.org/)).
 
-Un backing service (prendiamo ad esempio un database) è tradizionalmente gestito dallo stesso amministratore di sistema, al deploy dell'applicazione. In aggiunta a questi servizi gestiti in locale potrebbero esserne presenti altri, forniti da terze parti. Parliamo di servizi SMTP (come [Postmark](http:https://postmarkapp.com/)), servizi di raccolta metriche (come [New Relic](http:https://newrelic.com/) o [Loggly](http:https://www.loggly.com/)), servizi per asset (come [Amazon S3](http:https://aws.amazon.com/s3/)), ed anche servizi accessibili via API (come [Twitter](http:https://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), o [Last.fm](http:https://www.last.fm/api)).
+Un backing service (prendiamo ad esempio un database) è tradizionalmente gestito dallo stesso amministratore di sistema, al deployment dell'applicazione. In aggiunta a questi servizi gestiti in locale potrebbero esserne presenti altri, forniti da terze parti. Parliamo di servizi SMTP (come [Postmark](http:https://postmarkapp.com/)), servizi di raccolta metriche (come [New Relic](http:https://newrelic.com/) o [Loggly](http:https://www.loggly.com/)), servizi per asset (come [Amazon S3](http:https://aws.amazon.com/s3/)), e anche servizi accessibili via API (come [Twitter](http:https://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), o [Last.fm](http:https://www.last.fm/api)).
 
-**Il codice di un'app twelve-factor non fa distinzioni tra servizi in locale o third party**. Per l'applicazione, entrambi sono risorse connesse, accessibili via URL (o tramite un altro locator) e credenziali memorizzate nell'opportuno file di [configurazione](./config). Ad un qualsiasi [deploy](./codebase) di un'applicazione twelve-factor si deve poter permettere di passare velocemente da un database MySQL locale ad uno third party (come [Amazon RDS](http:https://aws.amazon.com/rds/)) senza alcuna modifica al codice. Allo stesso modo, un server SMTP locale dovrebbe poter essere cambiato con uno third party (come Postmark). In entrambi i casi, a cambiare dovrebbero essere **solo** i file di configurazione necessari.
+**Il codice di un'app twelve-factor non fa distinzioni tra servizi in locale o third party**. Per l'applicazione, entrambi sono risorse connesse, accessibili via URL (o tramite un altro locator) e credenziali memorizzate nell'opportuno file di [configurazione](./config). A un qualsiasi [deployment](./codebase) di un'applicazione twelve-factor si deve poter permettere di passare velocemente da un database MySQL locale a uno third party (come [Amazon RDS](http:https://aws.amazon.com/rds/)) senza alcuna modifica al codice. Allo stesso modo, un server SMTP locale dovrebbe poter essere cambiato con uno third party (come Postmark). In entrambi i casi, a cambiare dovrebbero essere **solo** i file di configurazione necessari.
 
-Ogni backing service è quindi definibile come una "risorsa connessa". Un Database MySQL è una risorsa. Due database MySQL (utilizzati per lo sharding a livello di applicazione) saranno visti come due distinte risorse. Un'app twelve-factor vede questi database come *risorse* anche per sottolineare la separazione dal deploy a cui fanno riferimento.
+Ogni backing service è quindi definibile come una "risorsa connessa". Un Database MySQL è una risorsa. Due database MySQL (utilizzati per lo sharding a livello di applicazione) saranno visti come due distinte risorse. Un'app twelve-factor vede questi database come *risorse* anche per sottolineare la separazione dal deployment a cui fanno riferimento.
 
-<img src="/images/attached-resources.png" class="full" alt="Un deploy di produzione collegato a quattro backing service." />
+<img src="/images/attached-resources.png" class="full" alt="Un deployment di produzione collegato a quattro backing service." />
 
-Le risorse possono essere collegate e scollegate da un deploy a piacimento. Ad esempio, supponiamo che il database dell'applicazione si comporti in modo anomalo per problemi hardware. L'amministratore potrebbe decidere di voler configurare un altro server di database ripreso da un recente backup. Il vecchio database verrebbe scollegato, quello nuovo connesso -- senza modifiche al codice.
+Le risorse possono essere collegate e scollegate da un deployment a piacimento. Per esempio, supponiamo che il database dell'applicazione si comporti in modo anomalo per problemi hardware. L'amministratore potrebbe decidere di voler configurare un altro server di database ripreso da un recente backup. Il vecchio database verrebbe scollegato, quello nuovo connesso -- senza modifiche al codice.

content/it/build-release-run.md

@@ -1,18 +1,18 @@
 ## V. Build, release, esecuzione
 ### Separare in modo netto lo stadio di build dall'esecuzione
 
-Una [codebase](./codebase) viene "trasformata" in deploy attraverso tre fasi:
+Una [codebase](./codebase) viene "trasformata" in deployment attraverso tre fasi:
 
-* la fase di *build*, che converte il codice del repo in una build "eseguibile". Usando una certa versione del codice, ad una specifica commit, nella fase di build vengono compilati i binari con gli asset appropriati includendo anche le eventuali dipendenze;
-* la fase di *release* prende la build prodotta nella fase precedente e la combina con l'attuale insieme di impostazioni di configurazione del deploy specifico. La *release* risultante contiene sia la build che le impostazioni;
+* la fase di *build*, che converte il codice del repo in una build "eseguibile". Usando una certa versione del codice, a una specifica commit, nella fase di build vengono compilati i binari con gli asset appropriati includendo anche le eventuali dipendenze;
+* la fase di *release* prende la build prodotta nella fase precedente e la combina con l'attuale insieme di impostazioni di configurazione del deployment specifico. La *release* risultante contiene sia la build che le impostazioni;
 * la fase di *esecuzione* (conosciuta anche come "runtime") vede l'applicazione in esecuzione nell'ambiente di destinazione, attraverso l'avvio di processi della release scelta;
 
 ![Il codice diventa build, che combinata con le impostazioni diventa release.](/images/release.png)
 
-**Un'app twelve-factor definisce una separazione netta tra build, release ed esecuzione.** Ad esempio, è impossibile effettuare dei cambiamenti del codice a runtime, dato che non c'è modo di propagare queste modifiche all'"indietro", verso la fase di build.
+**Un'app twelve-factor definisce una separazione netta tra build, release ed esecuzione.** Per esempio, è impossibile effettuare dei cambiamenti del codice a runtime, dato che non c'è modo di propagare queste modifiche all'"indietro", verso la fase di build.
 
-I tool di deploy offrono tipicamente dei tool di gestione delle release, in particolare alcuni dedicati ad un rollback verso una release precedente. Ad esempio, [Capistrano](https://github.com/capistrano/capistrano/wiki) memorizza le varie release in una sotto-directory chiamata `releases`, in cui la release attuale non è che un symlink verso la directory della release attuale. Il comando di rollback permette di tornare indietro ad una certa release velocemente.
+I tool di deployment offrono tipicamente dei tool di gestione delle release, in particolare alcuni dedicati a un rollback verso una release precedente. Per esempio, [Capistrano](https://github.com/capistrano/capistrano/wiki) memorizza le varie release in una sotto-directory chiamata `releases`, in cui la release attuale non è che un symlink verso la directory della release attuale. Il comando di rollback permette di tornare indietro a una certa release velocemente.
 
-Ogni release dovrebbe inoltre possedere un ID univoco di rilascio, come ad esempio un timestamp (es. `2011-04-06-20:32:17`) o un numero incrementale (es. `v100`). In un certo senso, la creazione di una release è una procedura "a senso unico" e una certa release non può essere modificata dopo la sua creazione. Qualsiasi cambiamento deve quindi prevedere una nuova release.
+Ogni release dovrebbe inoltre possedere un ID univoco di rilascio, come per esempio un timestamp (es. `2011-04-06-20:32:17`) o un numero incrementale (es. `v100`). In un certo senso, la creazione di una release è una procedura "a senso unico" e una certa release non può essere modificata dopo la sua creazione. Qualsiasi cambiamento deve quindi prevedere una nuova release.
 
-Una fase di build è sempre avviata da uno sviluppatore, non appena il codice viene modificato. Al contrario, l'esecuzione può essere anche gestita in modo automatico (si pensi al riavvio del server oppure ad un crash con successivo riavvio del processo). Ad ogni modo, una volta in esecuzione, la regola aurea è di evitare il più possibile (se non del tutto) modifiche che potrebbero rompere qualche equilibrio. Magari nel bel mezzo della notte, quando non c'è nessuno disponibile. La fase di build può essere sicuramente più "faticosa", comunque, visto che possono verificarsi degli errori da risolvere prima di proseguire.
+Una fase di build è sempre avviata da uno sviluppatore, non appena il codice viene modificato. Al contrario, l'esecuzione può essere anche gestita in modo automatico (si pensi al riavvio del server oppure a un crash con successivo riavvio del processo). A ogni modo, una volta in esecuzione, la regola aurea è di evitare il più possibile (se non del tutto) modifiche che potrebbero rompere qualche equilibrio. Magari nel bel mezzo della notte, quando non c'è nessuno disponibile. La fase di build può essere sicuramente più "faticosa", comunque, visto che possono verificarsi degli errori da risolvere prima di proseguire.

content/it/codebase.md

@@ -5,13 +5,13 @@ Un'app conforme alla metodologia twelve-factor è sempre sotto un sistema di con
 
 Una *codebase* è quindi un singolo repository (in un sistema centralizzato come Subversion), oppure un set di repo che condividono una root commit (in un sistema di controllo decentralizzato come Git).
 
-![Una codebase, N deploy](/images/codebase-deploys.png)
+![Una codebase, N deployment](/images/codebase-deploys.png)
 
-C'è sempre una relazione uno-ad-uno tra codebase ed applicazione:
+C'è sempre una relazione uno-ad-uno tra codebase e applicazione:
 
-* Se ci sono più codebase, non si parla più di applicazione ma di sistema distribuito. Ogni componente in un sistema distribuito è un'applicazione, ed ognuna di queste applicazioni può individualmente aderire alla metodologia twelve-factor.
+* Se ci sono più codebase, non si parla più di applicazione ma di sistema distribuito. Ogni componente in un sistema distribuito è un'applicazione, e ognuna di queste applicazioni può individualmente aderire alla metodologia twelve-factor.
 * Se più applicazioni condividono lo stesso codice si ha una violazione del twelve-factor. La soluzione è, ovviamente, quella di sistemare il codice in modo adeguato, in modo tale da essere incluso eventualmente dove necessario tramite un [dependency manager](./dependencies).
 
-Quindi: una sola codebase per applicazione, ma ci saranno comunque tanti deploy della stessa app. Per *deploy* si intende un'istanza dell'applicazione. Può essere il software in produzione, oppure una delle varie istanze in staging. Ancora, un deploy può essere la copia posseduta dal singolo sviluppatore nel suo ambiente locale.
+Quindi: una sola codebase per applicazione, ma ci saranno comunque tanti deployment della stessa app. Per *deploy* si intende un'istanza dell'applicazione. Può essere il software in produzione, oppure una delle varie istanze in staging. Ancora, un deploy può essere la copia posseduta dal singolo sviluppatore nel suo ambiente locale.
 
-La codebase rimane comunque sempre la stessa su tutti i deploy, anche se potrebbero essere attive diverse versioni nello stesso istante. Si pensi ad esempio ad uno sviluppatore che possiede dei commit in più che non ha ancora mandato in staging. Nonostante questo, comunque, rimane la condivisione della stessa codebase, nonostante la possibilità di avere più deploy della stessa app.
+La codebase rimane comunque sempre la stessa su tutti i deployment, anche se potrebbero essere attive diverse versioni nello stesso istante. Si pensi per esempio a uno sviluppatore che possiede dei commit in più che non ha ancora mandato in staging. Nonostante questo, comunque, rimane la condivisione della stessa codebase, nonostante la possibilità di avere più deploy della stessa app.