The Modern Programmer

Google Cloud Tasks offer a good solution for controlling workflows in our backend infastructure, increasing load peaks resilency while keeping costs controlled. Such a powerful solution requires a careful configuration to properly work, specially when dealing with task retrying policy. This feature is basically controlled by a set of properties described in the Google Cloud documentation and quickly described here: minBackoff : Elapsed time in seconds, from the initial task execution, that defines the lower limit of the incremental retry time window. The first retry will occur minBackoff seconds after the initial task execution. maxBackoff : Elapsed time in seconds, from the initial task execution, that defines the higher limit of the incremental retry time window. After reaching maxBackoff the retry time will not increment, and retries will occur every maxBackoff seconds. maxDoublings : Number of times that minBackoff will be doubled (multiplied by two) in order to ...

Linting and formatting tools are common in the Javascript/Typescript (JS/TS) scene, and their benefits are out of discussion: linters allows applying a set of coding style rules, whereas formatters apply a set of not coding but format style rules. Used in a development team scenario, its usage allows unifying the codebase by applying a common set of coding and formatting rules, no matter who the coder was. However, if not properly configured, these tools can collide in their functions, being the most common case the linter formatting code, a task that might be performed by the formatter. This article exposes the way of proceeding in order to allow both tools living in armony. Install and configure a linter The most common linter in the JS/TS scene is ESLint since TSLint , in the moment of writing this article, has been deprecated in favour of the first one. To install ESLint run these commands: $ npm install eslint --save-dev $ npx eslint --init Once installed you c...

In Node, process.env property gives you access to the user environmental variables. Opposite to what you could think, these variables are always treated as strings , no matter the nature of your environment or the way you defined them. Misunderstanding of that said above can give you unpredictible behaviours, as that shown in the next code snippet regarding the usage of a presumably boolean env variable: process.env.FALSY = false; let evaluation = process.env.FALSY ? "This is imposible" : "This is the expected result"; // Since process.env.FALSY is returned as string, // and the bool value of a non empty string is true // it is evaluated not as falsy but as truthy The problem is not just related to boolean values, but also to numeric values, as shown the next code snippet: process.env.ONE = 1; let mustBeSix = process.env.ONE + 5; // Though you could expect mustBeSix being 6 // its result is the string concatenation // of '1' and '5' ie, ...