jferris

apiVersion: v1
kind: ConfigMap
metadata:
  name: example
  namespace: default
data:
  APPLICATION_HOST: example.com
  LANG: en_US.UTF-8
  PIDFILE: /tmp/server.pid
  PORT: "3000"

andersevenrud

True Color (24-bit) and italics with alacritty + tmux + vim (neovim)

This should make True Color (24-bit) and italics work in your tmux session and vim/neovim when using Alacritty (and should be compatible with any other terminal emulator, including Kitty).

Testing colors

Running this script should look the same in tmux as without.

curl -s https://gist.githubusercontent.com/lifepillar/09a44b8cf0f9397465614e622979107f/raw/24-bit-color.sh >24-bit-color.sh

ageis

security and hardening options for systemd service units

A common and reliable pattern in service unit files is thus:

NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
DevicePolicy=closed
ProtectSystem=strict

phansch

NOTE: This is outdated. Check the comments below for more up-to-date forks of this gist.

Improved YARD CHEATSHEET http://yardoc.org

forked from https://gist.github.com/chetan/1827484 which is from early 2012 and contains outdated information.

• Official Getting Started Guide
• Official Tags documentation
• Type naming examples

johnbintz

# be sure to comment out the require 'capistrano/deploy' line in your Capfile!

# config valid only for Capistrano 3.1
lock '3.2.1'

set :application, 'my-cool-application'

# the base docker repo reference
set :name, "johns-stuff/#{fetch(:application)}"

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.