Example treatment for a custom round checkbox.
A Pen by Matt Smith on CodePen.
// JavaScript error reporting functions, including automatic window.onerror | |
// and unhandledrejection reporting. | |
// | |
// Based on: | |
// https://kevinlocke.name/bits/2019/07/30/more-robust-javascript-error-reporting/ | |
// | |
// API: | |
// reportError(message, error): | |
// Report an exception with optional message and exception value. | |
// reportRejection(message, cause): |
<template> | |
<!-- Drop box --> | |
<div class="dropzone" | |
@dragover.prevent | |
@dragleave="dragleave" | |
@dragenter="dragenter" | |
@drop="drop" | |
ref="dropzone" | |
> | |
<!-- Box Label --> |
var http = require('http'); | |
var url = require('url'); | |
var cheerio = require('cheerio'); | |
var result = []; | |
var myURL = url.parse(process.argv[2]); | |
var options = { | |
host: myURL.host, |
Example treatment for a custom round checkbox.
A Pen by Matt Smith on CodePen.
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log
in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
A little while ago I started using Typescript with the Angular 1.5 app I'm working on, to help ease the migration path to Angular 2. Here's how I did it. We'll go example by example through migrating real world code living in a large, mostly non-Typescript codebase.
Let's start with a few of the basic angular building blocks, then we'll go through some of the higher level patterns we derived.
#!/bin/bash | |
usage() { | |
echo "Usage $0 -c mongo_docker_container_name" | |
} | |
while [[ $# > 1 ]] | |
do | |
key="$1" |
As I've discovered, managing LXC containers is fairly straightforward, but when building out a system for provisioning out user maintained instances of NodeBB, it was imperative that unprivileged LXC containers were used, so that in the event of shell breakout from NodeBB followed by privilege escalation of the saas
user, the root
user in the LXC container would only be an unprivileged user on the host machine.
During the course of development, I ran into numerous blockers when it came to managing LXC containers in unexpected circumstances. Namely:
su
or executing lxc-*
commands as another user via sudo
lxc-*
commands via a program, application, or script. In my case, a Node.js application.angular.module('myApp.factories', []) | |
.factory('$fakeStorage', [ | |
function(){ | |
function FakeStorage() {}; | |
FakeStorage.prototype.setItem = function (key, value) { | |
this[key] = value; | |
}; | |
FakeStorage.prototype.getItem = function (key) { | |
return typeof this[key] == 'undefined' ? null : this[key]; | |
} |
When hosting our web applications, we often have one public IP
address (i.e., an IP address visible to the outside world)
using which we want to host multiple web apps. For example, one
may wants to host three different web apps respectively for
example1.com
, example2.com
, and example1.com/images
on
the same machine using a single IP address.
How can we do that? Well, the good news is Internet browsers