yaauie

#!/usr/bin/env bash -e
#
# Ensure Trailing Newline: ensures that the given plaintext file ends with a
# newline character, appending in-place only if it is missing.
#
# Portable on POSIX-based or POSIX-compatible systems, as it uses POSIX-standard
# invocations of `wc`, `tail`, and `echo`.
#
# Copyright 2018 Ry Biesemeyer
#

duhaime

import warnings
from skimage.measure import compare_ssim
from skimage.transform import resize
from scipy.stats import wasserstein_distance
from scipy.misc import imsave
from scipy.ndimage import imread
import numpy as np
import cv2

##

popravich

The standard names for indexes in PostgreSQL are:

{tablename}_{columnname(s)}_{suffix}

where the suffix is one of the following:

• pkey for a Primary Key constraint;
• key for a Unique constraint;
• excl for an Exclusion constraint;
• idx for any other kind of index;

jashkenas

Spurred by recent events (https://news.ycombinator.com/item?id=8244700), this is a quick set of jotted-down thoughts about the state of "Semantic" Versioning, and why we should be fighting the good fight against it.

For a long time in the history of software, version numbers indicated the relative progress and change in a given piece of software. A major release (1.x.x) was major, a minor release (x.1.x) was minor, and a patch release was just a small patch. You could evaluate a given piece of software by name + version, and get a feeling for how far away version 2.0.1 was from version 2.8.0.

But Semantic Versioning (henceforth, SemVer), as specified at http://semver.org/, changes this to prioritize a mechanistic understanding of a codebase over a human one. Any "breaking" change to the software must be accompanied with a new major version number. It's alright for robots, but bad for us.

SemVer tries to compress a huge amount of information — the nature of the change, the percentage of users that wil