Add spanish translation skeleton

sections/projectstructre/breakintcomponents.md

@@ -1,26 +1,32 @@
-# Structure your solution by components
+# Estructura tu solución en componentes Structure your solution by components
 
 <br/><br/>
 
+### Un párrafo explicativo
 
-### One Paragraph Explainer
-
-For medium sized apps and above, monoliths are really bad - a one big software with many dependencies is just hard to reason about and often lead to code spaghetti. Even those smart architects who are skilled to tame the beast and 'modularize' it - spend great mental effort on design and each change requires to carefully evaluate the impact on other dependant objects. The ultimate solution is to develop small software: divide the whole stack into self-contained components that don't share files with others, each constitute very few files (e.g. API, service, data access, test, etc) so that it's very easy to reason about it. Some may call this 'microservices' architecture - it's important to understand that microservices is not a spec which you must follow rather a set of principles. You may adopt many principles into a full-blown microservices architecture or adopt only few. Both are good as long as you keep the software complexity low. The very least you should do is create a basic borders between components, assign a folder in your project root for each business component and make it self contained - other components are allowed to consume its functionality only through its public interface or API. This is the foundation for keeping your components simple, avoid dependencies hell and pave the way to full-blown microservices in the future once your app grows.
+Para aplicaciones medianas y superiores, los monolitos son realmente malos: un software grande con muchas dependencias es simplemente difícil de entender y a menudo conduce a código espagueti. Incluso aquellos arquitectos inteligentes que están capacitados para domesticar a la bestia y "modularla": dedican un gran esfuerzo mental al diseño y cada cambio requiere evaluar cuidadosamente el impacto en otros objetos dependientes. La solución definitiva es desarrollar software pequeño: divide el stack completo en componentes independientes que no compartan archivos con otros, cada componente constituye muy pocos archivos (por ejemplo, API, servicio, acceso a datos, test, etc.) para que sea muy fácil entender. Algunos pueden llamar a esto 'arquitectura de microservicios': es importante entender que los microservicios no son una especificación que debas seguir sino un conjunto de principios. Puedes adoptar muchos principios en una arquitectura de microservicios en toda regla o adoptar solo unos pocos. Ambos son buenos siempre y cuando mantengas baja la complejidad del software. Lo mínimo que debes hacer es crear una frontera básica entre los componentes, asignar una carpeta en la raíz del proyecto para cada componente de negocio y hacerlo autónomo: otros componentes pueden consumir su funcionalidad solo a través de su interfaz pública o API. Esta es la base para mantener tus componentes simples, evitar las dependencias y allanar el camino a los microservicios en el futuro una vez que tu aplicación crezca
 
 <br/><br/>
 
 
-### Blog Quote: "Scaling requires scaling of the entire application"
- From the blog MartinFowler.com
+### Cita de Blog: "Scaling requires scaling of the entire application"
+ De el blog MartinFowler.com
 
- > Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.
+ > Las aplicaciones monolíticas pueden ser exitosas, pero cada vez más personas sienten frustraciones con ellas, especialmente a medida que se implementan más aplicaciones en la nube. Los ciclos de cambio están unidos: un cambio realizado en una pequeña parte de la aplicación requiere que se reconstruya y despliegue todo el monolito. Con el tiempo, a menudo es difícil mantener una buena estructura modular, lo que hace más difícil mantener los cambios que solo deberían afectar a un módulo dentro de ese módulo. El escalado requiere escalar toda la aplicación en lugar de partes de ella que requieren un mayor recurso.
 
  <br/><br/>
+
+ ### Cita del blog: "So what does the architecture of your application scream?"
+
+Del blog uncle-bob
+
+> ... si estuvieras mirando la arquitectura de una biblioteca, es probable que veas una gran entrada, un área para salida/entrada de empleados, áreas de lectura, salas de conferencias pequeñas y galería tras galería capaz de sostener estanterías para todos los libros en la biblioteca. Esa arquitectura gritaría: Biblioteca.
+Entonces, ¿qué grita la arquitectura de tu aplicación? Cuando observas la estructura de directorios de nivel superior y los archivos de origen en el paquete de nivel superior; ¿gritan: Sistema de Cuidado de la Salud, o Sistema de Contabilidad, o Sistema de Gestión de Inventario? ¿O gritan: Rails o Spring / Hibernate o ASP?
 
- ### Good: Structure your solution by self-contained components
+ ### Bien: Estructura tu solución en componentes autónomos
 ![alt text](https://github.com/i0natan/nodebestpractices/blob/master/assets/images/structurebycomponents.PNG "Structuring solution by components")
 
  <br/><br/> 
 
-### Bad: Group your files by technical role
+### Bad: Agrupa tus archivos por rol técnico
 ![alt text](https://github.com/i0natan/nodebestpractices/blob/master/assets/images/structurebyroles.PNG "Structuring solution by technical roles")

sections/projectstructre/configguide.md

@@ -1,17 +1,17 @@
-# Use environment aware, secure and hirearchical config
+# Usar una configuración segura, jerárquica y consciente del entorno
 
 <br/><br/>
 
 
-### One Paragraph Explainer
+### Un párrafo explicativo
 
-When dealing with configuration data, many things can just annoy and slow down: (1) setting all the keys using process environment variables becomes very tedious when in need to inject 100 keys (instead of just committing those in a config file), however when dealing with files only the devops admins can not alter the behaviour without changing the code. A reliable config solution must combine both configuration files + overrides from the process variables (b) when specifying all keys in a flat JSON, it become frustrating to find and modify entries when the list grows big. An hirearchical JSON files that is grouped into section can overcome this issue + few config libraries allows to store the configuration in multiple files and take care to union all in runtime. See example below (3) storing sensitive information like DB password is obviously not recommended but no quick and handy solution exists for this challenge. Some configuraiton library allows to encrypt files, others encrypt those entries during GIT commits or simple don't store real values for those entries and specify the actual value during deployment via environment variables. (4) some advanced config scenario demand to inject configuration value via command line (vargs) or sync configuration info via centralized cache like Redis so different servers won't hold different data. 
+Cuando se trata de datos de configuración, muchas cosas pueden molestar y ralentizar: (1) configurar todas las claves utilizando variables de entorno de proceso resulta muy tedioso cuando se necesitan inyectar 100 claves (en lugar de solo confirmarlas en un archivo de configuración), pero cuando tratas solo con archivos los administradores de devops no pueden alterar el comportamiento sin cambiar el código. Una solución de configuración confiable debe combinar los archivos de configuración y las sobre escrituras de las variables de proceso (b) al especificar todas las claves en un JSON plano, resulta frustrante encontrar y modificar entradas cuando la lista crece. Un archivo JSON jerárquico que está agrupado en una sección puede resolver este problema + pocas bibliotecas de configuración permiten almacenar la configuración en múltiples archivos y cuidar la unión en tiempo de ejecución. Ve el siguiente ejemplo (3) que almacena información confidencial como la contraseña de la base de datos, obviamente, no se recomienda, pero no existe una solución rápida y práctica para este desafío. Algunas bibliotecas de configuraciones permiten cifrar archivos, otras cifran esas entradas durante los commits de GIT o simplemente no almacenan valores reales para esas entradas y especifican el valor real durante la implementación a través de variables de entorno. (4) Algunos escenarios de configuración avanzada exigen inyectar el valor de configuración a través de la línea de comando (vargs) o sincronizar información de configuración a través de la caché centralizada como Redis para que los diferentes servidores no contengan datos diferentes.
 
-Some configuration libraries can provide most of these features for free, have a look at NPM libraries like [nconf](https://www.npmjs.com/package/nconf) and [config](https://www.npmjs.com/package/config) which tick many of these requirements.
+Algunas bibliotecas de configuración pueden proporcionar la mayoría de estas características de forma gratuita, echa un vistazo a las bibliotecas de NPM como [nconf](https://www.npmjs.com/package/nconf) y [config](https://www.npmjs.com/package/config) que validan muchos de estos requisitos.
 
 <br/><br/>
 
-### Code Example – hirearchical config helps to find entries and maintain huge config files
+### Ejemplo de código – la configuración jerárquica ayuda a encontrar entradas y mantener enormes archivos de configuración
 
 ```javascript
 {

sections/projectstructre/createlayers.md

@@ -1,11 +1,11 @@
-# Layer your app, keep Express within its boundaries
+# Aplica capas a tus componentes, mantén Express dentro de sus límites
 
 <br/><br/>
 
- ### Separate component code into layers: web, services and DAL
+ ### Separa el código del componente en capas: web, servicios y DAL (capa de acceso a datos)
 ![alt text](https://github.com/i0natan/nodebestpractices/blob/master/assets/images/structurebycomponents.PNG "Separate component code into layers")
 
  <br/><br/> 
 
-### 1 min explainer: The downside of mixing layers
+### 1 min explicativo: The downside of mixing layers
 ![alt text](https://github.com/i0natan/nodebestpractices/blob/master/assets/images/keepexpressinweb.gif "The downside of mixing layers")

sections/projectstructre/separateexpress.md

@@ -1,28 +1,24 @@
-# Separate Express 'app' and 'server'
+# Separar 'servidor' y 'aplicación' de express
 
 <br/><br/>
 
+### Un párrafo explicativo
 
-### One Paragraph Explainer
-
-The latest Express generator comes with a great practice that is worth to keep - the API declaration is separated from the network related configuration (port, protocol, etc). This allows testing the API in-process, without performing network calls, with all the benefits that it brings to the table: fast testing execution and getting coverage metrics of the code. It also allows deploying the same API under flexible and different network conditions. Bonus: better separation of concerns and cleaner code
+El último generador de Express viene con una gran práctica que vale la pena mantener: la declaración del API está separada de la configuración relacionada con la red (puerto, protocolo, etc.). Esto permite probar el API en proceso, sin realizar llamadas de red, con todos los beneficios que trae a la mesa: ejecución de prueba rápida y obtención de métricas de cobertura del código. También permite implementar la misma API bajo condiciones de red flexibles y diferentes. Bonificación: mejor separación de conceptos y código más limpio
 
 <br/><br/>
 
-### Code example: API declaration, should reside in app.js
-
+### Ejemplo de código: Declaración del API, debe residiir en app.js
 ```javascript
 var app = express();
 app.use(bodyParser.json());
 app.use("/api/events", events.API);
 app.use("/api/forms", forms);
 
 ```
-
 <br/><br/>
 
-### Code example: Server network declaration, should reside in /bin/www
-
+### Ejemplo de código: Declaración de red del servidor, debe residir en /bin/www
 ```javascript
 var app = require('../app');
 var http = require('http');
@@ -41,7 +37,5 @@ app.set('port', port);
 var server = http.createServer(app);
 
 ```
-
-
-### Example: test your API in-process using supertest (popular testing package)
+### Ejemplo: prueba tu API en proceso usando supertest (paquete de testing popular)
 ![alt text](https://github.com/i0natan/nodebestpractices/blob/master/assets/images/supertestinprocess.PNG "In process testing with Supertest")

sections/projectstructre/thincomponents.md

@@ -1,26 +1,32 @@
-# Structure your solution by components
+# Estructura tu solución en componentes Structure your solution by components
 
 <br/><br/>
 
+### Un párrafo explicativo
 
-### One Paragraph Explainer
-
-For medium sized apps and above, monoliths are really bad - a one big software with many dependencies is just hard to reason about and often lead to code spaghetti. Even those smart architects who are skilled to tame the beast and 'modulurize' it - spend great mental effort on design and each change requires to carefully evaluate the impact on other dependant objects. The ultimate solution is to develop small software: divide the whole stack into self-contained components that don't share files with others, each constitute very few files (e.g. API, service, data access, test, etc) so that it's very easy to reason about it. Some may call this 'microservices' architecture - it's important to understand that microservices is not a spec which you must follow rather a set of principles. You may adopt many principles into a full-blown microservices architecture or adopt only few. Both are good as long as you keep the software complexity low. The very least you should do is create a basic borders between components, assign a folder in your project root for each business component and make it self contained - other components are allowed to consumeits functionality only through its public interface or API. This is the foundation for keeping your components simple, avoid dependencies hell and pave the way to full-blown microservices in the future once your app grows
+Para aplicaciones medianas y superiores, los monolitos son realmente malos: un software grande con muchas dependencias es simplemente difícil de entender y a menudo conduce a código espagueti. Incluso aquellos arquitectos inteligentes que están capacitados para domesticar a la bestia y "modularla": dedican un gran esfuerzo mental al diseño y cada cambio requiere evaluar cuidadosamente el impacto en otros objetos dependientes. La solución definitiva es desarrollar software pequeño: divide el stack completo en componentes independientes que no compartan archivos con otros, cada componente constituye muy pocos archivos (por ejemplo, API, servicio, acceso a datos, test, etc.) para que sea muy fácil entender. Algunos pueden llamar a esto 'arquitectura de microservicios': es importante entender que los microservicios no son una especificación que debas seguir sino un conjunto de principios. Puedes adoptar muchos principios en una arquitectura de microservicios en toda regla o adoptar solo unos pocos. Ambos son buenos siempre y cuando mantengas baja la complejidad del software. Lo mínimo que debes hacer es crear una frontera básica entre los componentes, asignar una carpeta en la raíz del proyecto para cada componente de negocio y hacerlo autónomo: otros componentes pueden consumir su funcionalidad solo a través de su interfaz pública o API. Esta es la base para mantener tus componentes simples, evitar las dependencias y allanar el camino a los microservicios en el futuro una vez que tu aplicación crezca
 
 <br/><br/>
 
 
-### Blog Quote: "Scaling requires scaling of the entire application"
- From the blog MartinFowler.com
+### Cita de Blog: "Scaling requires scaling of the entire application"
+ De el blog MartinFowler.com
 
- > Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud . Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module. Scaling requires scaling of the entire application rather than parts of it that require greater resource.
+ > Las aplicaciones monolíticas pueden ser exitosas, pero cada vez más personas sienten frustraciones con ellas, especialmente a medida que se implementan más aplicaciones en la nube. Los ciclos de cambio están unidos: un cambio realizado en una pequeña parte de la aplicación requiere que se reconstruya y despliegue todo el monolito. Con el tiempo, a menudo es difícil mantener una buena estructura modular, lo que hace más difícil mantener los cambios que solo deberían afectar a un módulo dentro de ese módulo. El escalado requiere escalar toda la aplicación en lugar de partes de ella que requieren un mayor recurso.
 
  <br/><br/>
+
+ ### Cita del blog: "So what does the architecture of your application scream?"
+
+Del blog uncle-bob
+
+> ... si estuvieras mirando la arquitectura de una biblioteca, es probable que veas una gran entrada, un área para salida/entrada de empleados, áreas de lectura, salas de conferencias pequeñas y galería tras galería capaz de sostener estanterías para todos los libros en la biblioteca. Esa arquitectura gritaría: Biblioteca.
+Entonces, ¿qué grita la arquitectura de tu aplicación? Cuando observas la estructura de directorios de nivel superior y los archivos de origen en el paquete de nivel superior; ¿gritan: Sistema de Cuidado de la Salud, o Sistema de Contabilidad, o Sistema de Gestión de Inventario? ¿O gritan: Rails o Spring / Hibernate o ASP?
 
- ### Good: Structure your solution by self-contained components
+ ### Bien: Estructura tu solución en componentes autónomos
 ![alt text](https://github.com/i0natan/nodebestpractices/blob/master/assets/images/structurebycomponents.PNG "Structuring solution by components")
 
  <br/><br/> 
 
-### Bad: Group your files by technical role
+### Bad: Agrupa tus archivos por rol técnico
 ![alt text](https://github.com/i0natan/nodebestpractices/blob/master/assets/images/structurebyroles.PNG "Structuring solution by technical roles")