joepie91

Online things

• Package search (for stable channel)
  • An unofficial multi-channel package search (for all recent channels, including stable - currently not being updated)
• Options search (for stable channel)
• A list of channels, and when they were last updated
• A timeline of channel builds
• A source code search (that actually works!) of all NixOS repositories; Nix, nixpkgs, etc.

Development tooling

joepie91

options: let
    combinedOptions = options // {
        overlays = [
            (import ../nixpkgs-mozilla/rust-overlay.nix)
        ];
    };
in {
    master = (import (fetchTarball https://github.com/NixOS/nixpkgs/archive/master.tar.gz) combinedOptions);
    unstable = (import (fetchTarball https://github.com/NixOS/nixpkgs-channels/archive/nixos-unstable.tar.gz) combinedOptions);
    nixpkgs = (import <nixpkgs>) combinedOptions;

joepie91

const ChartjsNode = require('chartjs-node');
// 600x600 canvas size
var chartNode = new ChartjsNode(600, 600);
var randomnumber=Math.random();
var imagename = "testimage"+randomnumber+".png"
module.exports = imagename

// each api returns a Promise
chartNode.drawChart({
        type: 'bar',

joepie91

Lower precedence means a stronger binding; ie. this list is sorted from strongest to weakest binding, and in the case of equal precedence between two operators, the associativity decides the binding.

Prec	Abbreviation	Example	Assoc	Description
1	SELECT	e . attrpath [or def]	none	Select attribute denoted by the attribute path attrpath from set e. (An attribute path is a dot-separated list of attribute names.) If the attribute doesn’t exist, return default if provided, otherwise abort evaluation.
2	APP	e1 e2	left	Call function e1 with argument e2.
3	NEG	-e	none	Numeric negation.
4	HAS_ATTR	e ? attrpath	none	Test whether set e contains the attribute denoted by attrpath; return true or false.
5	CONCAT	e1 ++ e2	right	List concatenation.
6	MUL	e1 * e2	le

joepie91

A few notes on the "Gathering weak npm credentials" article

Yesterday, an article was released that describes how one person could obtain access to enough packages on npm to affect 52% of the package installations in the Node.js ecosystem. Unfortunately, this has brought about some comments from readers that completely miss the mark, and that draw away attention from the real issue behind all this.

To be very clear: This (security) issue was caused by 1) poor password management on the side of developers, 2) handing out unnecessary publish access to packages, and most of all 3) poor security on the side of the npm registry.

With that being said, let's address some of the common claims. This is going to be slightly ranty, because to be honest I'm rather disappointed that otherwise competent infosec people distract from the underlying causes like this. All that's going to do is prevent this from getting fixed in other l

joepie91

/// Handler for /travel/{url}
module.exports.travel = (event, context, callback) => {
  // Get the url from the resource path.
  // Get the html.
  // Turn it into a successful request.
  // Attach the Node.js callback onto the end.

  return Promise.try(() => {
    return getURLFromPath(event.path);
  }).then((url) => {

joepie91

'use strict';

const _ = require('lodash');

module.exports = (permissions, requiredPermissions) => {
  if (!_.isPlainObject(requiredPermissions)) {
    throw new TypeError('`requiredPermissions` is not an object');
  } else if (!_.isPlainObject(permissions)) {
    throw new TypeError('`permissions` is not an object');
  } else {

joepie91

Every once in a while, somebody comes into an IRC channel with a code question, and their code turns out to be a mess - very hard to understand, even harder to fix, and sometimes flat-out unfixable. This is usually followed by a recommendation towards the person asking the question, suggesting that they clean up the code first, and giving them concrete suggestions on how to do so.

Most of the time, this works fine - the asker cleans up the code and returns with a more readable version. Unfortunately, sometimes it does not.

The problem

Asking people on IRC a question means asking volunteers to give up their time and energy to solve your problem. This is fine, since that's what people are there to do in the first place - however, it means that you are expected to put in your part of the effort as well.

When you respond with something along the lines of:

joepie91

NOTE: This is simplified. However, it's a useful high-level model for determining what kind of database you need for your project.

Data models

• Documents: Single type of thing, no relations
• Relational: Multiple types of things, relations between different types of things
• Graph: Single or multiple types of things, relations between different things of the same type

Consistency models

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