Merge pull request #17 from i0natan/master

merge master

README.md

@@ -17,6 +17,10 @@
  [![nodepractices](/assets/images/twitter-s.png)](https://twitter.com/nodepractices/) **Follow us on Twitter!** [**@nodepractices**](https://twitter.com/nodepractices/)
  <br/>
 
+ Read in different language: [![CN](/assets/flags/CN.png)**CN**](/README.chinese.md)     [(![ES](/assets/flags/ES.png)**ES**, ![FR](/assets/flags/FR.png)**FR**, ![HE](/assets/flags/HE.png)**HE**, ![KR](/assets/flags/KR.png)**KR**, ![RU](/assets/flags/RU.png)**RU** and ![TR](/assets/flags/TR.png)**TR** in progress!)](#translations)
+
+ <br/>
+
 # Welcome! 3 Things You Ought To Know First:
 **1. When you read here, you in fact read dozens of the best Node.js articles -** this is a summary and curation of the top-ranked content on Node.js best practices
 
@@ -36,6 +40,12 @@
 7. Performance Practices ([coming soon](https://github.com/i0natan/nodebestpractices/milestones?direction=asc&sort=due_date&state=open))
 
 
+* [Milestones](#milestones)
+* [Translations](#translations)
+* [Contributors](#contributors)
+* [Thank you notes](#thank-you-notes)
+* [Sources](#sources)
+
 <br/><br/><br/>
 # `1. Project Structure Practices`
 
@@ -667,6 +677,24 @@ To maintain this guide and keep it up to date, we are constantly updating and im
 
 <br/><br/>
 
+## Translations
+All translations are contributed by the community. We will be happy to get any help with either completed, ongoing or new translations!
+
+### Completed translations
+
+* ![CN](/assets/flags/CN.png) [Chinese](README.chinese.md) - Courtesy of [Matt Jin](https://github.com/mattjin)
+
+### Translations in progress
+
+* ![FR](/assets/flags/FR.png) [French](https://github.com/gaspaonrocks/nodebestpractices/blob/french-translation/README.french.md) ([Discussion]
+* ![HE](/assets/flags/HE.png) Hebrew ([Discussion](https://github.com/i0natan/nodebestpractices/issues/156))
+* ![KR](/assets/flags/KR.png) [Korean](https://github.com/i0natan/nodebestpractices/blob/korean-translation/README.md) ([Discussion](https://github.com/i0natan/nodebestpractices/issues/94))
+* ![RU](/assets/flags/RU.png) [Russian](https://github.com/i0natan/nodebestpractices/blob/russian-translation/README.russian.md) ([Discussion](https://github.com/i0natan/nodebestpractices/issues/105))
+* ![ES](/assets/flags/ES.png) [Spanish](https://github.com/i0natan/nodebestpractices/blob/spanish-translation/README.spanish.md) ([Discussion](https://github.com/i0natan/nodebestpractices/issues/95))
+* ![TR](/assets/flags/TR.png) Turkish ([Discussion](https://github.com/i0natan/nodebestpractices/issues/139))
+
+<br/><br/>
+
 # Contributors
 ## `Yoni Goldberg`
 Independent Node.js consultant who works with customers at USA, Europe and Israel on building large-scale scalable Node applications. Many of the best practices above were first published on his blog post at [http://www.goldbergyoni.com](http://www.goldbergyoni.com). Reach Yoni at @goldbergyoni or me@goldbergyoni.com
@@ -722,11 +750,11 @@ This repository is being kept up to date thanks to the help from the community.
 🌻 [Allen Fang](https://github.com/AllenFang),
 🌻 [Leonardo Villela](https://github.com/leonardovillela),
 🌻 [Michal Zalecki](https://github.com/MichalZalecki)
-🌻 [Chris Nicola](https://github.com/chrisnicola)
-
+🌻 [Chris Nicola](https://github.com/chrisnicola),
+🌻 [Alejandro Corredor](https://github.com/aecorredor)
 
+<br/>
 
+:star: **No Stars Yet, Waiting For The First To Suggest a New Bullet**
 
 <br/><br/>
-## :star: No Stars Yet, Waiting For The First To Suggest a New Bullet 
-

sections/errorhandling/shuttingtheprocess.md

@@ -19,15 +19,18 @@ process.on('uncaughtException', function(error) {
  
  
 // centralized error handler encapsulates error-handling related logic
-function errorHandler(){
+function errorHandler() {
   this.handleError = function (error) {
-  return logger.logError(err).then(sendMailToAdminIfCritical).then(saveInOpsQueueIfCritical).then(determineIfOperationalError);
-}
+    return logger.logError(err)
+      .then(sendMailToAdminIfCritical)
+      .then(saveInOpsQueueIfCritical)
+      .then(determineIfOperationalError);
+  }
 
-this.isTrustedError = function (error) {
-  return error.isOperational;
+  this.isTrustedError = function (error) {
+    return error.isOperational;
+  }
 }
-
 ```
 
 
@@ -49,4 +52,4 @@ From the blog: JS Recipes
 ### Blog Quote: "No safe way to leave without creating some undefined brittle state"
 From Node.js official documentation
  
-> …By the very nature of how throw works in JavaScript, there is almost never any way to safely “pick up where you left off”, without leaking references, or creating some other sort of undefined brittle state. The safest way to respond to a thrown error is to shut down the process. Of course, in a normal web server, you might have many connections open, and it is not reasonable to abruptly shut those down because an error was triggered by someone else. The better approach is to send an error response to the request that triggered the error, while letting the others finish in their normal time, and stop listening for new requests in that worker.
+> …By the very nature of how throw works in JavaScript, there is almost never any way to safely “pick up where you left off”, without leaking references, or creating some other sort of undefined brittle state. The safest way to respond to a thrown error is to shut down the process. Of course, in a normal web server, you might have many connections open, and it is not reasonable to abruptly shut those down because an error was triggered by someone else. The better approach is to send an error response to the request that triggered the error, while letting the others finish in their normal time, and stop listening for new requests in that worker.

sections/errorhandling/useonlythebuiltinerror.md

@@ -4,11 +4,6 @@
 ### One Paragraph Explainer
 
 The permissive nature of JS along with its variety code-flow options (e.g. EventEmitter, Callbacks, Promises, etc) pushes to great variance in how developers raise errors – some use strings, other define their own custom types. Using Node.js built-in Error object helps to keep uniformity within your code and with 3rd party libraries, it also preserves significant information like the StackTrace. When raising the exception, it’s usually a good practice to fill it with additional contextual properties like the error name and the associated HTTP error code. To achieve this uniformity and practices, consider extending the Error object with additional properties, see code example below
-Blog Quote: “I don’t see the value in having lots of different types”
-From the blog Ben Nadel, ranked 5 for the keywords “Node.js error object”
-…”Personally, I don’t see the value in having lots of different types of error objects – JavaScript, as a language, doesn’t seem to cater to Constructor-based error-catching. As such, differentiating on an object property seems far easier than differentiating on a Constructor type…
-
-
 
 ### Code Example – doing it right
 
@@ -59,6 +54,10 @@ if(user == null)
     throw new appError(commonErrors.resourceNotFound, commonHTTPErrors.notFound, "further explanation", true)
 ```
 
+### Blog Quote: "I don’t see the value in having lots of different types"
+From the blog Ben Nadel, ranked 5 for the keywords “Node.js error object”
+
+>…”Personally, I don’t see the value in having lots of different types of error objects – JavaScript, as a language, doesn’t seem to cater to Constructor-based error-catching. As such, differentiating on an object property seems far easier than differentiating on a Constructor type…
 
 ### Blog Quote: "A string is not an error"
 From the blog devthought.com, ranked 6 for the keywords “Node.js error object”

sections/projectstructre/configguide.md

@@ -5,7 +5,15 @@
 
 ### One Paragraph Explainer
 
-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 becomes frustrating to find and modify entries when the list grows bigger. A hierarchical JSON file that is grouped into sections can overcome this issue + few config libraries allow 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 configuration libraries allow to encrypt files, others encrypt those entries during GIT commits or simply don't store real values for those entries and specify the actual value during deployment via environment variables. (4) some advanced configuration scenarios demand to inject configuration values via command line (vargs) or sync configuration info via a centralized cache like Redis so multiple servers will use the same configuration data.
+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 
+
+(2) when specifying all keys in a flat JSON, it becomes frustrating to find and modify entries when the list grows bigger. A hierarchical JSON file that is grouped into sections can overcome this issue + few config libraries allow 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 configuration libraries allow to encrypt files, others encrypt those entries during GIT commits or simply don't store real values for those entries and specify the actual value during deployment via environment variables. 
+
+(4) some advanced configuration scenarios demand to inject configuration values via command line (vargs) or sync configuration info via a centralized cache like Redis so multiple servers will use the same configuration data.
 
 Some configuration libraries can provide most of these features for free, have a look at NPM libraries like [rc](https://www.npmjs.com/package/rc), [nconf](https://www.npmjs.com/package/nconf) and [config](https://www.npmjs.com/package/config) which tick many of these requirements.