mitchellporter · August 10, 2016 15:33 · Jul 22, 2016 · Jun 26, 2016 · Jun 9, 2016 · Jun 6, 2016
diff --git a/getting-started.md b/getting-started.md
@@ -177,6 +177,10 @@ These are some resources on that:
 * [`node-gyp`, the build tool you will need for this purpose](https://github.com/nodejs/node-gyp)
 * [V8 API documentation for every supported Node.js version](http://v8dox.com/)
 
+## Writing Rust addons
+
+Neon is a new project that lets you write __memory-safe compiled extensions__ for Node.js, using Rust. It's still pretty new, but quite promising - an introduction can be found [here](http://calculist.org/blog/2015/12/23/neon-node-rust/).
+
 ## Odds and ends
 
 Some miscellaneous code snippets and examples, that I haven't written a section or article for yet.

diff --git a/getting-started.md b/getting-started.md
@@ -107,6 +107,7 @@ Note that this advice isn't necessarily complete. It answers some of the most co
 
 Also, keep in mind the golden rule of security: humans *suck* at repetition, regardless of their level of competence. __If a mistake *can* be made, then it *will* be made.__ Design your systems such that they are hard to use incorrectly.
 
+* __Sessions:__ Use something that implements session cookies. If you're using Express, [express-session](https://www.npmjs.com/package/express-session) will take care of this for you. Whatever you do, __don't use JWT for sessions__, even if many blog posts recommend it - it will cause security problems. [This article](http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/) goes into more detail.
 * __Password hashing:__ Use `scrypt`. [This wrapper module](https://www.npmjs.com/package/scrypt-for-humans) will make it easier to use.
 * __CSRF protection:__ You need this if you are building a website. Use [csurf](https://www.npmjs.com/package/csurf).
 * __XSS:__ Every good templater will escape output by default. __Only__ use templaters that do this (such as [Jade](http://jade-lang.com/) or [Nunjucks](https://mozilla.github.io/nunjucks/))! If you need to explicitly escape things, you should consider it insecure - it's too easy to forget to do this, and is practically guaranteed to result in vulnerabilities.

diff --git a/getting-started.md b/getting-started.md
@@ -64,6 +64,7 @@ To get started with Express, simply follow the below articles. Whatever you do,
 * [Installing Express](http://expressjs.com/en/starter/installing.html) (some of this was already covered in the NPM guide above)
 * [A Hello World example](http://expressjs.com/en/starter/hello-world.html)
 * [Routing](http://expressjs.com/en/guide/routing.html)
+* [Using template engines](http://expressjs.com/en/guide/using-template-engines.html)
 * [Writing Middleware](http://expressjs.com/en/guide/writing-middleware.html)
 * [Using Middleware](http://expressjs.com/en/guide/using-middleware.html)
 * [Static File Handling](http://expressjs.com/en/starter/static-files.html) (this is middleware, too!)

diff --git a/getting-started.md b/getting-started.md
@@ -156,6 +156,7 @@ Now let's say that you *are* having performance issues. Here are some articles a
 * [A tour of V8: object representation](http://jayconrod.com/posts/52/a-tour-of-v8-object-representation)
 * [Node.js in flames](http://techblog.netflix.com/2014/11/nodejs-in-flames.html)
 * [Realtime Node.js App: A Stress Testing Story (using Socket.IO)](https://bocoup.com/weblog/node-stress-test-analysis)
+* A bigger list of resources about V8 optimization and internals can be found [here](http://mrale.ph/v8/resources.html).
 
 These are some modules that you may find useful for profiling your application:
 

diff --git a/getting-started.md b/getting-started.md
@@ -25,10 +25,14 @@ Node.js is not a language. Rather, it's a "runtime" that lets you run Javascript
 * __If you are using Windows:__ You can download an installer from [the Node.js website](https://nodejs.org/en/). You should consider using a different operating system, though - Windows is generally rather poorly suited for software development outside of .NET. Things will be a lot easier if you use Linux or OS X.
 * __The package manager you'll use for Node.js, is called NPM.__ While it's very simple to use, it's not particularly well-documented. [This article](https://gist.github.com/joepie91/9b9dbd8c9ac3b55a65b2) will give you an introduction to it. Don't hesitate to add dependencies, even small ones! Node.js and NPM are specifically designed to make this possible without running into issues.
 * __The module system is very simple.__ [The Node.js documentation explains this further.](https://nodejs.org/api/modules.html)
-* __To be able to install "native addons" (compiled C++ modules), you need to take some additional steps.__ If you are on Linux or OS X, you likely already have everything you need - however, on Windows you'll have to install a few additional pieces of software. The instructions for all of these platforms can be found [here](https://github.com/nodejs/node-gyp#installation). __Do not skip this step.__ Installing pure-Javascript modules is not always a viable solution, especially where it concerns cryptography-related modules such as `scrypt` or `bcrypt`. If you're running into issues on Windows, try [these instructions](https://github.com/Microsoft/nodejs-guidelines/blob/master/windows-environment.md#compiling-native-addon-modules).
 * __MongoDB is commonly recommended and used with Node.js. It is, however, extremely poorly designed - and you shouldn't use it.__ [This article](http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/) goes into more detail about *why* you shouldn't use it. If you're not sure what to use, use [PostgreSQL](http://www.postgresql.org/).
 * The rest of the documentation for all the modules included with Node.js, can be found [here](https://nodejs.org/api/).
 
+## Setting up your environment
+
+* __To be able to install "native addons" (compiled C++ modules), you need to take some additional steps.__ If you are on Linux or OS X, you likely already have everything you need - however, on Windows you'll have to install a few additional pieces of software. The instructions for all of these platforms can be found [here](https://github.com/nodejs/node-gyp#installation). __Do not skip this step.__ Installing pure-Javascript modules is not always a viable solution, especially where it concerns cryptography-related modules such as `scrypt` or `bcrypt`.
+* __If you're running into issues on Windows,__ try [these instructions](https://github.com/Microsoft/nodejs-guidelines/blob/master/windows-environment.md#compiling-native-addon-modules) from Microsoft.
+
 ## Functional programming
 
 Javascript has part of its roots in functional programming languages, which means that you can use some of those concepts in your own projects. They can be greatly beneficial to the readability and maintainability of your code.

diff --git a/getting-started.md b/getting-started.md
@@ -14,7 +14,7 @@ These links will help you refresh your knowledge of JS, and make sure that you u
 * __Asynchronous execution in Javascript is normally implemented using CPS.__ This stands for "continuation-passing style", and [this](https://gist.github.com/joepie91/977c966cb0d6c15690b0) shows an example of how that works.
 * __However, in practice, you shouldn't use that, and you should use Promises instead.__ Whereas it is very easy to mess up CPS code, that is not an issue with Promises - error handling is much more reliable, for example. [This guide](https://gist.github.com/joepie91/791640557e3e5fd80861) should give you a decent introduction.
 * __A callback should be either consistently synchronous, or consistently asynchronous.__ You don't really have to worry about this when you're using Promises (as they ensure that this is consistent), but [this article](http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony) still has a good explanation of the reasons for this. A simpler example can be found [here](https://gist.github.com/joepie91/98576de0fab7badec167).
-* __Javascript does not have classes, and constructor functions are a bad idea.__ [This short article](https://hughfdjackson.com/javascript/prototypes%3A-the-short%28est-possible%29-story/) will help you understand the prototypical OOP model that Javascript uses. [This gist](https://gist.github.com/joepie91/22fb5cd443517566412b) shows a brief example of what the `this` variable refers to.
+* __Javascript does not have classes, and constructor functions are a bad idea.__ [This short article](https://hughfdjackson.com/javascript/prototypes%3A-the-short%28est-possible%29-story/) will help you understand the prototypical OOP model that Javascript uses. [This gist](https://gist.github.com/joepie91/22fb5cd443517566412b) shows a brief example of what the `this` variable refers to. Often you don't need inheritance at all - [this gist](https://gist.github.com/joepie91/657f2b4b054d90aa0c87) shows an example of creating an object in the simplest possible way.
 * __In Javascript, closures are everywhere, by default.__ [This gist](https://gist.github.com/joepie91/cb0e42c3562bc94e4491) shows an example.
 
 ## The Node.js platform

diff --git a/getting-started.md b/getting-started.md
@@ -106,6 +106,7 @@ Also, keep in mind the golden rule of security: humans *suck* at repetition, reg
 * __CSRF protection:__ You need this if you are building a website. Use [csurf](https://www.npmjs.com/package/csurf).
 * __XSS:__ Every good templater will escape output by default. __Only__ use templaters that do this (such as [Jade](http://jade-lang.com/) or [Nunjucks](https://mozilla.github.io/nunjucks/))! If you need to explicitly escape things, you should consider it insecure - it's too easy to forget to do this, and is practically guaranteed to result in vulnerabilities.
 * __SQL injection:__ Always use parameterized queries. When using MySQL, use the `node-mysql2` module instead of the `node-mysql` module - the latter doesn't use real parameterized queries. Ideally, use something like [Knex](http://knexjs.org/), which will also prevent many other issues, and make your queries much more readable and maintainable.
+* __Random numbers:__ Generating unpredictable random numbers is a lot harder than it seems. `Math.random()` will generate numbers that *seem* random, but are actually quite predictable by an attacker. If you need truly unpredictable random numbers, use something like [the `random-number-csprng` module](https://www.npmjs.com/package/random-number-csprng) instead. Don't try to implement it yourself.
 * __Cryptography:__ Follow the suggestions in [this gist](https://gist.github.com/tqbf/be58d2d39690c3b366ad). Whatever you do, __do not use the `crypto` module directly__, unless you really have no other choice. Never use pure-Javascript reimplementations - always use bindings to the original implementation, where possible (in the form of native addons).
 * __Vulnerability advisories:__ The Node Security Project keeps track of [known vulnerabilities](https://nodesecurity.io/advisories) in Node.js modules. Services like [VersionEye](https://www.versioneye.com/) will e-mail you, if your project uses a module that is found vulnerable.
 

diff --git a/getting-started.md b/getting-started.md
@@ -57,20 +57,20 @@ If this sounds complicated, don't worry - things almost always work "out of the
 
 To get started with Express, simply follow the below articles. Whatever you do, don't use the Express Generator - it generates confusing and bloated code. Just start from scratch and follow the guides!
 
-* [Installing Express](http://expressjs.com/starter/installing.html) (some of this was already covered in the NPM guide above)
-* [A Hello World example](http://expressjs.com/starter/hello-world.html)
-* [Routing](http://expressjs.com/guide/routing.html)
-* [Writing Middleware](http://expressjs.com/guide/writing-middleware.html)
-* [Using Middleware](http://expressjs.com/guide/using-middleware.html)
-* [Static File Handling](http://expressjs.com/starter/static-files.html) (this is middleware, too!)
-* [Error Handling](http://expressjs.com/guide/error-handling.html)
-* [Debugging](http://expressjs.com/guide/debugging.html)
+* [Installing Express](http://expressjs.com/en/starter/installing.html) (some of this was already covered in the NPM guide above)
+* [A Hello World example](http://expressjs.com/en/starter/hello-world.html)
+* [Routing](http://expressjs.com/en/guide/routing.html)
+* [Writing Middleware](http://expressjs.com/en/guide/writing-middleware.html)
+* [Using Middleware](http://expressjs.com/en/guide/using-middleware.html)
+* [Static File Handling](http://expressjs.com/en/starter/static-files.html) (this is middleware, too!)
+* [Error Handling](http://expressjs.com/en/guide/error-handling.html)
+* [Debugging](http://expressjs.com/en/guide/debugging.html)
 
 Some more odds and ends regarding about Express:
 
-* [Some FAQs](http://expressjs.com/starter/faq.html) (don't use MVC, however - [this is why](http://aredridel.dinhe.net/2015/01/30/why-mvc-does-not-fit-the-web/).)
-* [Express Behind Proxies](http://expressjs.com/guide/behind-proxies.html)
-* [The full Express API documentation](http://expressjs.com/4x/api.html)
+* [Some FAQs](http://expressjs.com/en/starter/faq.html) (don't use MVC, however - [this is why](http://aredridel.dinhe.net/2015/01/30/why-mvc-does-not-fit-the-web/).)
+* [Express Behind Proxies](http://expressjs.com/en/guide/behind-proxies.html)
+* [The full Express API documentation](http://expressjs.com/en/4x/api.html)
 
 Some examples:
 

diff --git a/getting-started.md b/getting-started.md
@@ -51,7 +51,7 @@ I'm still in the process of writing more about this, but so far, I've already wr
 
 ## Express
 
-If you want to build a website or web application, you'll probably find Express to be a good framework to start with. As a framework, it is *very* small. It only provides you with the basic necessities - everything else is a plugin.
+If you want to build a website or web application, you'll probably find [Express](http://expressjs.com/) to be a good framework to start with. As a framework, it is *very* small. It only provides you with the basic necessities - everything else is a plugin.
 
 If this sounds complicated, don't worry - things almost always work "out of the box". Simply follow the `README` for whichever "middleware" (Express plugin) you want to add.
 

diff --git a/getting-started.md b/getting-started.md
@@ -114,6 +114,7 @@ Also, keep in mind the golden rule of security: humans *suck* at repetition, reg
 
 This is an incomplete list, and I'll probably be adding stuff to it in the future.
 
+* __Determining the type of a value:__ [type-of-is](https://www.npmjs.com/package/type-of-is)
 * __Date/time handling:__ [Moment.js](http://momentjs.com/)
 * __Making HTTP requests:__ [bhttp](https://www.npmjs.com/package/bhttp)
 * __Clean debugging logs:__ [debug](https://www.npmjs.com/package/debug)

diff --git a/getting-started.md b/getting-started.md
@@ -130,6 +130,10 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 
 * __Your project is ready for release!__ But... you should still pick a license. [This article](http://cryto.net/~joepie91/blog/2013/03/21/licensing-for-beginners/) will give you a very basic introduction to copyright, and the different kind of (common) licenses you can use.
 
+## Scalability
+
+__Scalability is a result of your application architecture, not the technologies you pick.__ Be wary of anything that claims to be "scalable" - it's much more important to write loosely coupled code with small components, so that you can split out responsibilities across multiple processes and servers.
+
 ## Optimization
 
 The first rule of optimization is: __do not optimize.__

diff --git a/getting-started.md b/getting-started.md
@@ -25,7 +25,7 @@ Node.js is not a language. Rather, it's a "runtime" that lets you run Javascript
 * __If you are using Windows:__ You can download an installer from [the Node.js website](https://nodejs.org/en/). You should consider using a different operating system, though - Windows is generally rather poorly suited for software development outside of .NET. Things will be a lot easier if you use Linux or OS X.
 * __The package manager you'll use for Node.js, is called NPM.__ While it's very simple to use, it's not particularly well-documented. [This article](https://gist.github.com/joepie91/9b9dbd8c9ac3b55a65b2) will give you an introduction to it. Don't hesitate to add dependencies, even small ones! Node.js and NPM are specifically designed to make this possible without running into issues.
 * __The module system is very simple.__ [The Node.js documentation explains this further.](https://nodejs.org/api/modules.html)
-* __To be able to install "native addons" (compiled C++ modules), you need to take some additional steps.__ If you are on Linux or OS X, you likely already have everything you need - however, on Windows you'll have to install a few additional pieces of software. The instructions for all of these platforms can be found [here](https://github.com/nodejs/node-gyp#installation). __Do not skip this step.__ Installing pure-Javascript modules is not always a viable solution, especially where it concerns cryptography-related modules such as `scrypt` or `bcrypt`.
+* __To be able to install "native addons" (compiled C++ modules), you need to take some additional steps.__ If you are on Linux or OS X, you likely already have everything you need - however, on Windows you'll have to install a few additional pieces of software. The instructions for all of these platforms can be found [here](https://github.com/nodejs/node-gyp#installation). __Do not skip this step.__ Installing pure-Javascript modules is not always a viable solution, especially where it concerns cryptography-related modules such as `scrypt` or `bcrypt`. If you're running into issues on Windows, try [these instructions](https://github.com/Microsoft/nodejs-guidelines/blob/master/windows-environment.md#compiling-native-addon-modules).
 * __MongoDB is commonly recommended and used with Node.js. It is, however, extremely poorly designed - and you shouldn't use it.__ [This article](http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/) goes into more detail about *why* you shouldn't use it. If you're not sure what to use, use [PostgreSQL](http://www.postgresql.org/).
 * The rest of the documentation for all the modules included with Node.js, can be found [here](https://nodejs.org/api/).
 

diff --git a/getting-started.md b/getting-started.md
@@ -134,7 +134,7 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 
 The first rule of optimization is: __do not optimize.__
 
-The correct order of concerns is security first, then maintainability/readability, and *then* performance. Optimizing performance is something that you shouldn't care about, until you have *hard metrics* showing you that it is needed. If you can't show a performance problem in numbers, it doesn't exist.
+The correct order of concerns is security first, then maintainability/readability, and *then* performance. Optimizing performance is something that you shouldn't care about, until you have *hard metrics* showing you that it is needed. If you can't show a performance problem in numbers, it doesn't exist; while it is easy to optimize readable code, it's much harder to make optimized core more readable.
 
 There is one exception to this rule: *never* use any methods that end with `Sync` - these are blocking, synchronous methods, and will block your event loop (ie. your entire application) until they have completed. They may look convenient, but they are not worth the performance penalty.
 

diff --git a/getting-started.md b/getting-started.md
@@ -145,6 +145,7 @@ Now let's say that you *are* having performance issues. Here are some articles a
 * [Tuning Node.js](https://www.youtube.com/watch?v=FXyM1yrtloc)
 * [A tour of V8: object representation](http://jayconrod.com/posts/52/a-tour-of-v8-object-representation)
 * [Node.js in flames](http://techblog.netflix.com/2014/11/nodejs-in-flames.html)
+* [Realtime Node.js App: A Stress Testing Story (using Socket.IO)](https://bocoup.com/weblog/node-stress-test-analysis)
 
 These are some modules that you may find useful for profiling your application:
 

diff --git a/getting-started.md b/getting-started.md
@@ -100,7 +100,7 @@ Some common Express middleware that you might want to use:
 
 Note that this advice isn't necessarily complete. It answers some of the most common questions, but your project might have special requirements or caveats. When in doubt, you can always ask in the #Node.js channel!
 
-Also, keep in mind the golden rule of security: humans *suck* at repetition. __If a mistake *can* be made, then it *will* be made.__
+Also, keep in mind the golden rule of security: humans *suck* at repetition, regardless of their level of competence. __If a mistake *can* be made, then it *will* be made.__ Design your systems such that they are hard to use incorrectly.
 
 * __Password hashing:__ Use `scrypt`. [This wrapper module](https://www.npmjs.com/package/scrypt-for-humans) will make it easier to use.
 * __CSRF protection:__ You need this if you are building a website. Use [csurf](https://www.npmjs.com/package/csurf).

diff --git a/getting-started.md b/getting-started.md
@@ -100,6 +100,8 @@ Some common Express middleware that you might want to use:
 
 Note that this advice isn't necessarily complete. It answers some of the most common questions, but your project might have special requirements or caveats. When in doubt, you can always ask in the #Node.js channel!
 
+Also, keep in mind the golden rule of security: humans *suck* at repetition. __If a mistake *can* be made, then it *will* be made.__
+
 * __Password hashing:__ Use `scrypt`. [This wrapper module](https://www.npmjs.com/package/scrypt-for-humans) will make it easier to use.
 * __CSRF protection:__ You need this if you are building a website. Use [csurf](https://www.npmjs.com/package/csurf).
 * __XSS:__ Every good templater will escape output by default. __Only__ use templaters that do this (such as [Jade](http://jade-lang.com/) or [Nunjucks](https://mozilla.github.io/nunjucks/))! If you need to explicitly escape things, you should consider it insecure - it's too easy to forget to do this, and is practically guaranteed to result in vulnerabilities.

diff --git a/getting-started.md b/getting-started.md
@@ -118,6 +118,7 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 * __Cleaner stacktraces and errors:__ [pretty-error](https://www.npmjs.com/package/pretty-error)
 * __Markdown parsing:__ [marked](https://www.npmjs.com/package/marked)
 * __HTML parsing:__ [cheerio](https://www.npmjs.com/package/cheerio) (has a jQuery-like API)
+* __WebSockets:__ [ws](https://www.npmjs.com/package/ws)
 
 ## Deployment
 

diff --git a/getting-started.md b/getting-started.md
@@ -131,7 +131,7 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 
 The first rule of optimization is: __do not optimize.__
 
-The correct order of concerns is security first, then maintainability/readability, and *then* performance. Optimizing performance is something that you shouldn't care abou, until you have *hard metrics* showing you that it is needed. If you can't show a performance problem in numbers, it doesn't exist.
+The correct order of concerns is security first, then maintainability/readability, and *then* performance. Optimizing performance is something that you shouldn't care about, until you have *hard metrics* showing you that it is needed. If you can't show a performance problem in numbers, it doesn't exist.
 
 There is one exception to this rule: *never* use any methods that end with `Sync` - these are blocking, synchronous methods, and will block your event loop (ie. your entire application) until they have completed. They may look convenient, but they are not worth the performance penalty.
 

diff --git a/getting-started.md b/getting-started.md
@@ -127,17 +127,6 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 
 * __Your project is ready for release!__ But... you should still pick a license. [This article](http://cryto.net/~joepie91/blog/2013/03/21/licensing-for-beginners/) will give you a very basic introduction to copyright, and the different kind of (common) licenses you can use.
 
-## Writing C++ addons
-
-You'll usually want to avoid this - C++ is not a memory-safe language, so it's much safer to just write your code in Javascript. V8 is rather well-optimized, so in most cases, performance isn't a problem either. That said, sometimes - eg. when writing bindings to something else - you just *have* to write a native module.
-
-These are some resources on that:
-
-* [The addon documentation](https://nodejs.org/api/addons.html)
-* [`nan`, an abstraction layer for making your module work across Node.js versions](https://www.npmjs.com/package/nan) (you should absolutely use this)
-* [`node-gyp`, the build tool you will need for this purpose](https://github.com/nodejs/node-gyp)
-* [V8 API documentation for every supported Node.js version](http://v8dox.com/)
-
 ## Optimization
 
 The first rule of optimization is: __do not optimize.__
@@ -160,6 +149,17 @@ These are some modules that you may find useful for profiling your application:
 * __[heapdump](https://www.npmjs.com/package/heapdump):__ On-demand heap dumps, for later analysis. Usable from application code *in production*, so very useful for making a heap dump the moment your application goes over a certain heap size.
 * __[memwatch-next](https://www.npmjs.com/package/memwatch-next):__ Provides memory leak detection, and heap diffing.
 
+## Writing C++ addons
+
+You'll usually want to avoid this - C++ is not a memory-safe language, so it's much safer to just write your code in Javascript. V8 is rather well-optimized, so in most cases, performance isn't a problem either. That said, sometimes - eg. when writing bindings to something else - you just *have* to write a native module.
+
+These are some resources on that:
+
+* [The addon documentation](https://nodejs.org/api/addons.html)
+* [`nan`, an abstraction layer for making your module work across Node.js versions](https://www.npmjs.com/package/nan) (you should absolutely use this)
+* [`node-gyp`, the build tool you will need for this purpose](https://github.com/nodejs/node-gyp)
+* [V8 API documentation for every supported Node.js version](http://v8dox.com/)
+
 ## Odds and ends
 
 Some miscellaneous code snippets and examples, that I haven't written a section or article for yet.

diff --git a/getting-started.md b/getting-started.md
@@ -142,7 +142,7 @@ These are some resources on that:
 
 The first rule of optimization is: __do not optimize.__
 
-The correct order of concerns is `security > maintainability/readability > performance`. Optimizing performance is something that you shouldn't care about, until you have *hard metrics* showing you that it is a problem.
+The correct order of concerns is security first, then maintainability/readability, and *then* performance. Optimizing performance is something that you shouldn't care abou, until you have *hard metrics* showing you that it is needed. If you can't show a performance problem in numbers, it doesn't exist.
 
 There is one exception to this rule: *never* use any methods that end with `Sync` - these are blocking, synchronous methods, and will block your event loop (ie. your entire application) until they have completed. They may look convenient, but they are not worth the performance penalty.
 
@@ -158,6 +158,7 @@ These are some modules that you may find useful for profiling your application:
 
 * __[node-inspector](https://www.npmjs.com/package/node-inspector):__ Based on Chrome Developer Tools, this tool gives you many features, including CPU and heap profiling. Also useful for debugging in general.
 * __[heapdump](https://www.npmjs.com/package/heapdump):__ On-demand heap dumps, for later analysis. Usable from application code *in production*, so very useful for making a heap dump the moment your application goes over a certain heap size.
+* __[memwatch-next](https://www.npmjs.com/package/memwatch-next):__ Provides memory leak detection, and heap diffing.
 
 ## Odds and ends
 

diff --git a/getting-started.md b/getting-started.md
@@ -138,6 +138,27 @@ These are some resources on that:
 * [`node-gyp`, the build tool you will need for this purpose](https://github.com/nodejs/node-gyp)
 * [V8 API documentation for every supported Node.js version](http://v8dox.com/)
 
+## Optimization
+
+The first rule of optimization is: __do not optimize.__
+
+The correct order of concerns is `security > maintainability/readability > performance`. Optimizing performance is something that you shouldn't care about, until you have *hard metrics* showing you that it is a problem.
+
+There is one exception to this rule: *never* use any methods that end with `Sync` - these are blocking, synchronous methods, and will block your event loop (ie. your entire application) until they have completed. They may look convenient, but they are not worth the performance penalty.
+
+Now let's say that you *are* having performance issues. Here are some articles and videos to learn more about how optimization and profiling works in Node.js / V8 - they are going to be fairly in-depth, so you may want to hold off on reading these until you've gotten some practice with Node.js:
+
+* [Common causes of deoptimization](https://github.com/petkaantonov/bluebird/wiki/Optimization-killers)
+* [Monomorphism, and why it is important](http://mrale.ph/blog/2015/01/11/whats-up-with-monomorphism.html)
+* [Tuning Node.js](https://www.youtube.com/watch?v=FXyM1yrtloc)
+* [A tour of V8: object representation](http://jayconrod.com/posts/52/a-tour-of-v8-object-representation)
+* [Node.js in flames](http://techblog.netflix.com/2014/11/nodejs-in-flames.html)
+
+These are some modules that you may find useful for profiling your application:
+
+* __[node-inspector](https://www.npmjs.com/package/node-inspector):__ Based on Chrome Developer Tools, this tool gives you many features, including CPU and heap profiling. Also useful for debugging in general.
+* __[heapdump](https://www.npmjs.com/package/heapdump):__ On-demand heap dumps, for later analysis. Usable from application code *in production*, so very useful for making a heap dump the moment your application goes over a certain heap size.
+
 ## Odds and ends
 
 Some miscellaneous code snippets and examples, that I haven't written a section or article for yet.

diff --git a/getting-started.md b/getting-started.md
@@ -115,7 +115,7 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 * __Date/time handling:__ [Moment.js](http://momentjs.com/)
 * __Making HTTP requests:__ [bhttp](https://www.npmjs.com/package/bhttp)
 * __Clean debugging logs:__ [debug](https://www.npmjs.com/package/debug)
-* __Cleaner stacktraces and errors:__ [debug](https://www.npmjs.com/package/pretty-error)
+* __Cleaner stacktraces and errors:__ [pretty-error](https://www.npmjs.com/package/pretty-error)
 * __Markdown parsing:__ [marked](https://www.npmjs.com/package/marked)
 * __HTML parsing:__ [cheerio](https://www.npmjs.com/package/cheerio) (has a jQuery-like API)
 

diff --git a/getting-started.md b/getting-started.md
@@ -12,7 +12,7 @@ These links will help you refresh your knowledge of JS, and make sure that you u
 * __Javascript does automatic typecasting ("type conversion") in some cases.__ [This](https://gist.github.com/joepie91/5fd8c58345998d4dec5b) shows how various values cast to a boolean, and [this](https://gist.github.com/joepie91/b207efcfc6ace64f0f41) shows how `null` and `undefined` relate to each other.
 * __In Javascript, braces are optional for single-line statements - however, you should *always* use them.__ [This gist](https://gist.github.com/joepie91/203aaa8e36e1eb958fe7) demonstrates why.
 * __Asynchronous execution in Javascript is normally implemented using CPS.__ This stands for "continuation-passing style", and [this](https://gist.github.com/joepie91/977c966cb0d6c15690b0) shows an example of how that works.
-* __However, in practice, you shouldn't use that, and you should use Promises instead.__ Whereas it is very easy to mess up CPS code, that is an issue with Promises - error handling is much more reliable, for example. [This guide](https://gist.github.com/joepie91/791640557e3e5fd80861) should give you a decent introduction.
+* __However, in practice, you shouldn't use that, and you should use Promises instead.__ Whereas it is very easy to mess up CPS code, that is not an issue with Promises - error handling is much more reliable, for example. [This guide](https://gist.github.com/joepie91/791640557e3e5fd80861) should give you a decent introduction.
 * __A callback should be either consistently synchronous, or consistently asynchronous.__ You don't really have to worry about this when you're using Promises (as they ensure that this is consistent), but [this article](http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony) still has a good explanation of the reasons for this. A simpler example can be found [here](https://gist.github.com/joepie91/98576de0fab7badec167).
 * __Javascript does not have classes, and constructor functions are a bad idea.__ [This short article](https://hughfdjackson.com/javascript/prototypes%3A-the-short%28est-possible%29-story/) will help you understand the prototypical OOP model that Javascript uses. [This gist](https://gist.github.com/joepie91/22fb5cd443517566412b) shows a brief example of what the `this` variable refers to.
 * __In Javascript, closures are everywhere, by default.__ [This gist](https://gist.github.com/joepie91/cb0e42c3562bc94e4491) shows an example.

diff --git a/getting-started.md b/getting-started.md
@@ -55,7 +55,7 @@ If you want to build a website or web application, you'll probably find Express
 
 If this sounds complicated, don't worry - things almost always work "out of the box". Simply follow the `README` for whichever "middleware" (Express plugin) you want to add.
 
-To get started with Express, simply follow the below articles. Whatever you do, don't use the Express Generator - it generates confusing and bloated code. Just follow the guides!
+To get started with Express, simply follow the below articles. Whatever you do, don't use the Express Generator - it generates confusing and bloated code. Just start from scratch and follow the guides!
 
 * [Installing Express](http://expressjs.com/starter/installing.html) (some of this was already covered in the NPM guide above)
 * [A Hello World example](http://expressjs.com/starter/hello-world.html)

diff --git a/getting-started.md b/getting-started.md
@@ -43,6 +43,12 @@ To build "configurable" modules, you can use a pattern known as "parametric modu
 
 A commonly used pattern is the `EventEmitter` - this is exactly what it sounds like; an object that emits events. It's a very simple abstraction, but helps greatly in writing [loosely coupled](https://en.wikipedia.org/wiki/Loose_coupling) code. [This gist](https://gist.github.com/joepie91/82df4eff6956089e3fbf) illustrates the object, and the full documentation can be found [here](https://nodejs.org/api/events.html).
 
+## Code architecture
+
+The 'design' of your codebase matters a lot. Certain approaches for solving a problem work better than other approaches, and each approach has its own set of benefits and drawbacks. Picking the right approach is important - it will save you hours (or days!) of time down the line, when you are maintaining your code.
+
+I'm still in the process of writing more about this, but so far, I've already written an article that explains the difference between monolithic and modular code and why it matters. You can read it [here](https://gist.github.com/joepie91/7f03a733a3a72d2396d6).
+
 ## Express
 
 If you want to build a website or web application, you'll probably find Express to be a good framework to start with. As a framework, it is *very* small. It only provides you with the basic necessities - everything else is a plugin.

diff --git a/getting-started.md b/getting-started.md
@@ -111,6 +111,7 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 * __Clean debugging logs:__ [debug](https://www.npmjs.com/package/debug)
 * __Cleaner stacktraces and errors:__ [debug](https://www.npmjs.com/package/pretty-error)
 * __Markdown parsing:__ [marked](https://www.npmjs.com/package/marked)
+* __HTML parsing:__ [cheerio](https://www.npmjs.com/package/cheerio) (has a jQuery-like API)
 
 ## Deployment
 

diff --git a/getting-started.md b/getting-started.md
@@ -116,6 +116,10 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 
 * __Don't run Node.js as root, ever!__ If you want to expose your service at a privileged port (eg. port 80), and you probably do, then you can use [authbind](https://thomashunter.name/blog/using-authbind-with-node-js/) to accomplish that safely.
 
+## Distribution
+
+* __Your project is ready for release!__ But... you should still pick a license. [This article](http://cryto.net/~joepie91/blog/2013/03/21/licensing-for-beginners/) will give you a very basic introduction to copyright, and the different kind of (common) licenses you can use.
+
 ## Writing C++ addons
 
 You'll usually want to avoid this - C++ is not a memory-safe language, so it's much safer to just write your code in Javascript. V8 is rather well-optimized, so in most cases, performance isn't a problem either. That said, sometimes - eg. when writing bindings to something else - you just *have* to write a native module.

diff --git a/getting-started.md b/getting-started.md
@@ -112,6 +112,10 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 * __Cleaner stacktraces and errors:__ [debug](https://www.npmjs.com/package/pretty-error)
 * __Markdown parsing:__ [marked](https://www.npmjs.com/package/marked)
 
+## Deployment
+
+* __Don't run Node.js as root, ever!__ If you want to expose your service at a privileged port (eg. port 80), and you probably do, then you can use [authbind](https://thomashunter.name/blog/using-authbind-with-node-js/) to accomplish that safely.
+
 ## Writing C++ addons
 
 You'll usually want to avoid this - C++ is not a memory-safe language, so it's much safer to just write your code in Javascript. V8 is rather well-optimized, so in most cases, performance isn't a problem either. That said, sometimes - eg. when writing bindings to something else - you just *have* to write a native module.

diff --git a/getting-started.md b/getting-started.md
@@ -112,6 +112,17 @@ This is an incomplete list, and I'll probably be adding stuff to it in the futur
 * __Cleaner stacktraces and errors:__ [debug](https://www.npmjs.com/package/pretty-error)
 * __Markdown parsing:__ [marked](https://www.npmjs.com/package/marked)
 
+## Writing C++ addons
+
+You'll usually want to avoid this - C++ is not a memory-safe language, so it's much safer to just write your code in Javascript. V8 is rather well-optimized, so in most cases, performance isn't a problem either. That said, sometimes - eg. when writing bindings to something else - you just *have* to write a native module.
+
+These are some resources on that:
+
+* [The addon documentation](https://nodejs.org/api/addons.html)
+* [`nan`, an abstraction layer for making your module work across Node.js versions](https://www.npmjs.com/package/nan) (you should absolutely use this)
+* [`node-gyp`, the build tool you will need for this purpose](https://github.com/nodejs/node-gyp)
+* [V8 API documentation for every supported Node.js version](http://v8dox.com/)
+
 ## Odds and ends
 
 Some miscellaneous code snippets and examples, that I haven't written a section or article for yet.

diff --git a/getting-started.md b/getting-started.md
@@ -13,6 +13,7 @@ These links will help you refresh your knowledge of JS, and make sure that you u
 * __In Javascript, braces are optional for single-line statements - however, you should *always* use them.__ [This gist](https://gist.github.com/joepie91/203aaa8e36e1eb958fe7) demonstrates why.
 * __Asynchronous execution in Javascript is normally implemented using CPS.__ This stands for "continuation-passing style", and [this](https://gist.github.com/joepie91/977c966cb0d6c15690b0) shows an example of how that works.
 * __However, in practice, you shouldn't use that, and you should use Promises instead.__ Whereas it is very easy to mess up CPS code, that is an issue with Promises - error handling is much more reliable, for example. [This guide](https://gist.github.com/joepie91/791640557e3e5fd80861) should give you a decent introduction.
+* __A callback should be either consistently synchronous, or consistently asynchronous.__ You don't really have to worry about this when you're using Promises (as they ensure that this is consistent), but [this article](http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony) still has a good explanation of the reasons for this. A simpler example can be found [here](https://gist.github.com/joepie91/98576de0fab7badec167).
 * __Javascript does not have classes, and constructor functions are a bad idea.__ [This short article](https://hughfdjackson.com/javascript/prototypes%3A-the-short%28est-possible%29-story/) will help you understand the prototypical OOP model that Javascript uses. [This gist](https://gist.github.com/joepie91/22fb5cd443517566412b) shows a brief example of what the `this` variable refers to.
 * __In Javascript, closures are everywhere, by default.__ [This gist](https://gist.github.com/joepie91/cb0e42c3562bc94e4491) shows an example.