paulirish

/* bling.js */
window.$ = document.querySelector.bind(document);
window.$$ = document.querySelectorAll.bind(document);
Node.prototype.on = window.on = function(name, fn) { this.addEventListener(name, fn); };
NodeList.prototype.__proto__ = Array.prototype;
NodeList.prototype.on = function(name, fn) { this.forEach((elem) => elem.on(name, fn)); };

nepsilon

Using auto backup with Vim

Not using versioning on your configuration files and editing them with Vim? Use Vim’s backup option to automatically keep a copy of past versions:

To put in your ~/.vimrc:

"Turn on backup option
set backup

deanhume

"use strict";

// Listen to fetch events
self.addEventListener('fetch', function(event) {

  // Check if the image is a jpeg
  if (/\.jpg$|.png$/.test(event.request.url)) {

  // Inspect the accept header for WebP support
  var supportsWebp = false;

nepsilon

How to test your web app for heavy traffic?

Load testing is a good way to understand your website or web app behaviour under high traffic. Here is how to use siege, a simple CLI tool.

Note: Use siege only on sites you own as its traffic could be interpreted as a DDOS attack.

Using 100 concurrent requests and up to 3 seconds between requests:

jay3sh

#!/bin/bash

#
# When you are working on your macbook sitting in cafe and you have to go pee, 
# you need some way to guard you machine. 
#
# Start this script, remove any earphones, and go do the job.
# The assumption is the thief will close the lid of the laptop before taking it away.
# This script detects the closing of the lid and plays some loud audio that will
# likely distract the thief and/or grab attention of nearby people, making the

joshdover

Idiomatic React Testing Patterns

Testing React components seems simple at first. Then you need to test something that isn't a pure interaction and things seem to break down. These 4 patterns should help you write readable, flexible tests for the type of component you are testing.

Setup

I recommend doing all setup in the most functional way possible. If you can avoid it, don't set variables in a beforeEach. This will help ensure tests are isolated and make things a bit easier to reason about. I use a pattern that gives great defaults for each test example but allows every example to override props when needed: