| import util from 'util'; | |
| import crypto from 'crypto'; | |
| const HASH_ALGO = 'sha512'; | |
| // nist recommends 10000, 10x nist, approx 83ms on i7-8650U | |
| const HASH_ITERATIONS = 100000; | |
| const HASH_SALT_BYTES = 16; // Exceeds NIST Minimum 32/8 (4 bytes) | |
| const HASH_BYTES = 64; // Match Hash Algorithm lengh / bits (512 / 8); |
This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.
Agree? Disagree? Feel free to let me know at @JanStette.
Keep it simple, stupid. You ain't gonna need it.
| // <log errors to server> | |
| window.onerror = function (messageOrEvent, source, lineno, colno, error) { | |
| try { | |
| console.log({ | |
| //error message(string).Available as event (sic!) in HTML onerror = "" handler. | |
| messageOrEvent: messageOrEvent, | |
| //URL of the script where the error was raised(string) | |
| source: source, | |
| //Line number where error was raised(number) |
| //Contents from https://spring.io/understanding/CORS | |
| In the simplest scenario, cross-origin communications starts with a client making a GET, POST, or HEAD request against a resource on the server. | |
| In this scenario, the content type of a POST request is limited to application/x-www-form-urlencoded, multipart/form-data, or text/plain. The request includes an Origin header that indicates the origin of the client code. | |
| The server will consider the request's Origin and either allow or disallow the request. If the server allows the request, then it will respond with the requested resource and an Access-Control-Allow-Origin header in the response. This header will indicate to the client which client origins will be allowed to access the resource. Assuming that the Access-Control-Allow-Origin header matches the request's Origin, the browser will allow the request. | |
| On the other hand, if Access-Control-Allow-Origin is missing in the response or if it doesn't match the request's Origin, the browser will disallow th |
This is just another way to deal with errors following Go2 draft structure.
If I understood correctly handle is used as defer in many proposals, which, could be a drawback in case we want the function to fail as soon as error occurs.
So, a better scenario could be as follows:
handle function catches it and performs some operations before exiting the function (in the handle function one can decide to throw an error again if he/she needs to add additional info to the err)| /* | |
| Credit goes to Gokul Kathirvel who wrote the tutorial where this code comes from <3 | |
| https://dev.to/gokatz/automate-your-chrome-extension-deployment-in-minutes-48gb | |
| */ | |
| const zipFolder = require('zip-folder') | |
| const exec = require('child_process').exec | |
| const folder = 'dist' | |
| const zipName = 'extension.zip' |
"How do I get started with Node?" is a commonly heard question in #Node.js. This gist is an attempt to compile some of the answers to that question. It's a perpetual work-in-progress.
And if this list didn't quite answer your questions, I'm available for tutoring and code review! A donation is also welcome :)
Before you get started learning about JavaScript and Node.js, there's one very important article you need to read: Teach Yourself Programming in Ten Years.
Understand that it's going to take time to learn Node.js, just like it would take time to learn any other specialized topic - and that you're not going to learn effectively just by reading things, or following tutorials or courses. _Get out there and build things!
Note:
When this guide is more complete, the plan is to move it into Prepack documentation.
For now I put it out as a gist to gather initial feedback.
If you're building JavaScript apps, you might already be familiar with some tools that compile JavaScript code to equivalent JavaScript code:
