joepie91

Please don't include minified builds in your npm packages!

There's quite a few libraries on npm that not only include the regular build in their package, but also a minified build. While this may seem like a helpful addition to make the package more complete, it actually poses a real problem: it becomes very difficult to audit these libraries.

The problem

You've probably seen incidents like the event-stream incident, where a library was compromised in some way by an attacker. This sort of thing, also known as a "supply-chain attack", is starting to become more and more common - and it's something that developers need to protect themselves against.

One effective way to do so, is by auditing dependencies. Having at least a cursory look through every dependency in your dependency tree, to ensure that there's nothing sketchy in there. While it isn't going to be 100% perfect, it will detect most of these attacks - and no

joepie91

query = select("projects", anyOf([
	where(anyOf([{
		number_one: niceNumbers,
		number_two: niceNumbers
	}, {
		number_three: anyOf([ 42, column("number_one") ]),
		number_four: moreThan(1337)
	}]))
]));

joepie91

# parjs combinators

## Characters

digit			ASCII(?) digit in <base>
hex			ASCII(?) digit in base 16 (hex)
uniDecimal		unicode digit in base 10 (decimal)

letter			ASCII letter
uniLetter		unicode letter

joepie91

const immutableCollection = require("./");

let items = [{
	id: 1,
	color: "blue"
}, {
	id: 2,
	color: "red"
}, {
	id: 3,

joepie91

Loader utils
- parseString: Parse a given string as if it were a JSON-encoded string, mapping single-quote string boundaries to double-quote boundaries or just flat-out making up those boundaries, so that JSON.parse doesn't complain. If cannot be parsed as JSON, just return the string as-is. Seems to be used to decode escape codes in a variety of (non-JSON) strings.
- urlToRequest: "Converts some resource URL to a webpack module request."
- isUrlRequest: "Before call urlToRequest you need call isUrlRequest to ensure it is requestable url"

Docs here: https://www.npmjs.com/package/icss-utils

=====================

PostCSS

joepie91

"use strict";

const Promise = require("bluebird");
const AWS = require("aws-sdk");
AWS.config.update({ region: "eu-central-1" });

module.exports = function createRDSInstance(identifier) {
  let rds = new AWS.RDS();
  
  return Promise.try(() => {

joepie91

PO--CK  0x0033   51    0 0 1 1 0 0 1 1
-O--CK  0x0032   50    0 0 1 1 0 0 1 0
----CK  0x0030   48    0 0 1 1 0 0 0 0
POSR-K  0x002f   47    0 0 1 0 1 1 1 1
-OSR-K  0x002e   46    0 0 1 0 1 1 1 0
POS--K  0x0027   39    0 0 1 0 0 1 1 1
-O---K  0x0022   34    0 0 1 0 0 0 1 0
---R--  0x0008    8    0 0 0 0 1 0 0 0
                           K C R S O P
                           | | | | | |_ P prefailure warning

joepie91

Getting confused about the piles of development tools that people use for Javascript? Here's a quick index of what is used for what.

Keep in mind that you shouldn't add tools to your workflow for the sake of it. While you'll see many production systems using a wide range of tools, these tools are typically used because they solved a concrete problem for the developers working on it. You should not add tools to your project unless you have a concrete problem that they can solve; none of the tools here are required.

Start with nothing, and add tools as needed. This will keep you from getting lost in an incomprehensible pile of tooling.

Build/task runners

Typical examples: Gulp, Grunt

joepie91

You don't need a blockchain.

If you're reading this, you probably suggested to somebody that a particular technical problem could be solved with a blockchain.

Blockchains aren't a desirable thing; they're defined by having trustless consensus, which necessarily has to involve some form of costly signaling to work; that's what prevents attacks like sybil attacks.

In other words: blockchains must be expensive to operate, to work effectively. This makes it a last-resort solution, when you truly have no other options available for solving your problem; in almost every case you want a cheaper and less complex solution than a blockchain.

In particular, if your usecase is commercial, then you do not need or want trustless consensus. This especially includes usecases like supply chain tracking, ticketing, and so on. The whole *p

joepie91

// file: serial.js

const SerialPort = require('serialport')

module.exports = function() {
  const port = SerialPort('path/to/serial/port')
  const e = new events.EventEmitter()

  // listen for incoming serial data
  port.on('data', function (data) {