joepie91

In response to http://quirksmode.org/presentations/Spring2017/goingwrong_vanlanschot.pdf:

• "Native apps communicate directly with the OS. Web apps communicate with the browser, which communicates with the OS. Therefore web apps will always be a bit slower and coarser than native apps."
  • False -- there is nothing that requires this from a technical perspective. See eg. FirefoxOS and ChromeOS for an example of making the browser layer be the OS layer. Entirely implementation-dependent.
  • Misleading, too -- this can be said for literally every type of runtime, including commonly used ones like those for Python (which many of your desktop applications likely use!), Ruby, Go, the JVM, and so on. Browsers are not special in this regard.
• "It will have caught up with native in ... I don’t know, two years? But by that time native will also have progressed and we’ll still be behind."
  • False for pretty much the same reasons. Completely possible to achieve performance that is on-par with current-day deskt

nobitagamer

:: Setup default environment for developers
::  - Version: 1.2
:: How to use:
::  - Run from cmd: START http://boxstarter.org/package/nr/url?https://gist.githubusercontent.com/nobitagamer/a985aeee3409a1a846c7deab5e60d933/raw/
::  - From IE: http://boxstarter.org/package/nr/url?https://gist.githubusercontent.com/nobitagamer/a985aeee3409a1a846c7deab5e60d933/raw/

Set-ExplorerOptions -showHidenFilesFoldersDrivers -showProtectedOSFiles -showFileExtensions
Enable-RemoteDesktop

cinst WindowsInstaller31 -source webpi

joepie91

Your blockchain must have all of the following properties:

• It's a merkle tree, or a construct with equivalent properties.
• There is no single point of trust or authority; nodes are operated by different parties.
• Multiple 'forks' of the blockchain may exist - that is, nodes may disagree on what the full sequence of blocks looks like.
• In the case of such a fork, there must exist a deterministic consensus algorithm of some sort to decide what the "real" blockchain looks like (ie. which fork is "correct").
• The consensus algorithm must be executable with only the information contained in the blockchain (or its forks), and no external input (eg. no decisionmaking from a centralized 'trust node').

If your blockchain is missing any of the above properties, it is not a blockchain, it is just a ledger.

joepie91

While a lot of Node.js guides recommend using JWT as an alternative to session cookies (sometimes even mistakenly calling it "more secure than cookies"), this is a terrible idea. JWTs are absolutely not a secure way to deal with user authentication/sessions, and this article goes into more detail about that.

Secure user authentication requires the use of session cookies.

Cookies are small key/value pairs that are usually sent by a server, and stored on the client (often a browser). The client then sends this key/value pair back with every request, in a HTTP header. This way, unique clients can be identified between requests, and client-side settings can be stored and used by the server.

Session cookies are cookies containing a unique session ID that is generated by the server. This session ID is used by the server to identify the client whenever it makes a request, and to associate session data with that request.

*S

joepie91

Not all random values are created equal - for security-related code, you need a specific kind of random value.

A summary of this article, if you don't want to read the entire thing:

• Don't use Math.random(). There are extremely few cases where Math.random() is the right answer. Don't use it, unless you've read this entire article, and determined that it's necessary for your case.
• Don't use crypto.getRandomBytes directly. While it's a CSPRNG, it's easy to bias the result when 'transforming' it, such that the output becomes more predictable.
• If you want to generate random tokens or API keys: Use uuid, specifically the uuid.v4() method. Avoid node-uuid - it's not the same package, and doesn't produce reliably secure random values.
• If you want to generate random numbers in a range: Use random-number-csprng.

You should seriously consider reading the entire article, though - it's

joepie91

Terminology

• View: Also called a "template", a file that contains markup (like HTML) and optionally additional instructions on how to generate snippets of HTML, such as text interpolation, loops, conditionals, includes, and so on.
• View engine: Also called a "template library" or "templater", ie. a library that implements view functionality, and potentially also a custom language for specifying it (like Pug does).
• HTML templater: A template library that's designed specifically for generating HTML. It understands document structure and thus can provide useful advanced tools like mixins, as well as more secure output escaping (since it can determine the right escaping approach from the context in which a value is used), but it also means that the templater is not useful for anything other than HTML.
• String-based templater: A template library that implements templating logic, but that has no understanding of the content it is generating - it simply concatenates together strings, potenti

joepie91

If you're using Node.js, you might run into a warning like this:

DeprecationWarning: Using Buffer without `new` will soon stop working.

The reason for this warning is that the Buffer creation API was changed to require the use of new. However, contrary to what the warning says, you should not use new Buffer either, for security reasons. Any usage of it must be converted as soon as possible to Buffer.from, Buffer.alloc, or Buffer.allocUnsafe, depending on what it's being used for. Not changing it could mean a security vulnerability in your code.

Where is it coming from?

wojteklu

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

joepie91

By the way, I'm available for tutoring and code review :)

Table of contents

1. What Promises library should I use?
2. How do I create a Promise myself?
3. How do I use new Promise?
4. How do I resolve a Promise?
5. But what if I want to resolve a synchronous result or error?
6. [But what if it's at the start of a chain, and I'm not in a .then callback yet?](https://gist.github.com/joepie91/4c3a10629a4263a522e3bc4839a28c83#6-but

joepie91

Bluebird (http://bluebirdjs.com/docs/api/error-management-configuration.html#global-rejection-events)

• process.on//unhandledRejection: (Node.js) Potentially unhandled rejection.
• process.on//rejectionHandled: (Node.js) Cancel unhandled rejection, it was handled anyway.
• self.addEventListener//unhandledrejection: (WebWorkers) Potentially unhandled rejection.
• self.addEventListener//rejectionhandled: (WebWorkers) Cancel unhandled rejection, it was handled anyway.
• window.addEventListener//unhandledrejection: (Modern browsers, IE >= 9) Potentially unhandled rejection.
• window.addEventListener//rejectionhandled: (Modern browsers, IE >= 9) Cancel unhandled rejection, it was handled anyway.
• window.onunhandledrejection: (IE >= 6) Potentially unhandled rejection.
• window.onrejectionhandled: (IE >= 6) Cancel unhandled rejection, it was handled anyway.