My personal & professional linting setup. Run's Prettier as an ESLint rule via their ESLint plugin. Dynamic support for react or non-react applications depending on your project dependencies. Dynamic inclusion of Kent C Dodds' ESLint Jest config depending on your project dependencies.
Convenient opt-in configs for projects using Docker or Ethereum to avoid common false positives.
To understand more, see https://github.com/codfish/eslint-config-codfish.
To avoid having to manually setup everything and add all configuration/boilerplate code to your project, use cod-scripts instead. It was forked from kcd-scripts and ultimately inspired by react-scripts
.
# Original blog post: <https://mnx.io/blog/a-proper-server-naming-scheme/> | |
# Original word list: <http://web.archive.org/web/20091003023412/http://tothink.com/mnemonic/wordlist.txt> | |
# Sample usage: `curl <gist> | tail --lines +4 | shuf | head --lines 1` | |
acrobat | |
africa | |
alaska | |
albert | |
albino | |
album | |
alcohol |
#!/bin/sh | |
# PATH TO YOUR HOSTS FILE | |
ETC_HOSTS=/etc/hosts | |
# DEFAULT IP FOR HOSTNAME | |
IP="127.0.0.1" | |
# Hostname to add/remove. | |
HOSTNAME=$1 |
(Also see [remarkable][], the markdown parser created by the author of this cheatsheet)
IMPORTANT: Read this before implementing one of the configuration files below (for either Varnish 3.x or 4.x+).
USE: Replace the contents of the main Varnish configuration file located in /etc/varnish/default.vcl (root server access required - obviously) with the contents of the configuration you'll use (depending on your Varnish version) from the 2 examples provided below.
IMPORTANT: The following setup assumes a 180 sec (3 minute) cache time for cacheable content that does not have the correct cache-control HTTP headers. You can safely increase this to 300 sec (or more) for less busier sites or drop it to 60 sec or even 30 sec for high traffic sites. It obviously depends on your use case.
This gist assumes:
- you have a local git repo
- with an online remote repository (github / bitbucket etc)
- and a cloud server (Rackspace cloud / Amazon EC2 etc)
- your (PHP) scripts are served from /var/www/html/
- your webpages are executed by apache
- apache's home directory is /var/www/
FROM golang:1.13-alpine | |
# VARIANT can be either 'hugo' for the standard version or 'hugo_extended' for the extended version. | |
ARG VARIANT=hugo_extended | |
# VERSION can be either 'latest' or a specific version number | |
ARG VERSION=latest | |
RUN apk add --update --no-cache ca-certificates openssl git curl && \ | |
case ${VERSION} in \ | |
latest) \ |
In this gist I would like to describe an idea for GraphQL subscriptions. It was inspired by conversations about subscriptions in the GraphQL slack channel and different GH issues, like #89 and #411.
At the moment GraphQL allows 2 types of queries:
query
mutation
Reference implementation also adds the third type: subscription
. It does not have any semantics yet, so here I would like to propose one possible semantics interpretation and the reasoning behind it.
- GitHub LFS has a 2GB limit on file size. This never works with large projects like video productions.
- git-annex uses symlinks to manage annexed files. This doesn't work well on Windows.
So my conclusion at the moment is that Borg is the best backup software for mid/large-sized personal projects.