Recently a colleague of mine noticed this in the MDN description of WeakMap:
Because of references being weak, WeakMap keys are not enumerable (i.e. there is no method giving you a list of the keys). If they were, the list would depend on the state of garbage collection, introducing non-determinism. If you want to have a list of keys, you should use a Map.
My co-worker wondered what this meant exactly? Where does the non-determinism come from? Doesn’t the state of WeakMap still depend on garbage collection even if you can’t enumerate the keys?
OpenAPI is a specification that lets you write a document which describes a REST API. From this document, you can generate documentation, generate stubs to call into your API in a variety of languages, and automatically validate requests on the server, and much more. Swagger is a set of tools that work with OpenAPI. This will walk through setting up an OpenAPI document for a typical MongoDB/Express/Node.js app.
This is the first of a three part series.
If you’re using ES6 in node.js, there’s a lot of reasons to use the new “import” keyword to import modules:
import ld from 'lodash'; // Yay! const ld = require('lodash'); // Boo!
The old “require” way of doing things is known as “CommonJS”. The new “import” way of doing things is known as “ES6 Modules”. One of the things you’ve probably noticed, though, is you can use the “import * as” vs “import”, and sometimes it seems to makes a difference, and sometimes it doesn’t:
import ld from 'lodash'; import * as ld from 'lodash';
So, what’s the difference between these? Which one is “right”?
This is an updated version of this post. This is a quick and easy way to get Elasticsearch, Logstash, and Kibana up and running in Docker.
When an SSL connection fails in node.js, node.js usually gives you a helpful error message like “ECONNRESET” or “unable to verify the first certificate”. These errors don’t always tell you what is going wrong. Worse, if you go looking on stack overflow, you’ll usually get helpful advice like setting
rejectUnauthorized: falseor set the
NODE_TLS_REJECT_UNAUTHORIZEDenvironment variable to 0; these are terrible suggestions because the take away almost all of the security that you’re hoping to gain by using SSL in the first place.
Here is a list of interesting reasons why node.js fails to connect to an SSL server, and how to fix them. If you have any situations you’ve run into that are missing here, feel free to chime-in in the comments below.
subscribe via RSS