Steve Coffman StevenACoffman

Rank by PageRank	Package/Repo Name	Rank in github repos	Github stars	Rank by stars
254	github.com/operator-framework/operator-sdk	137	2867	472
1839	github.com/kubernetes-sigs/kubebuilder	1591	2103	656

Star History

From this comment:

Many applications running for long periods of time eventually transition to broken states, and cannot recover except by being restarted. Kubernetes provides liveness probes to detect and remedy such situations.

apiVersion: batch/v1
kind: Job
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:

Unicode Character Look-Alikes

Original Letter	Look-Alike(s)
a	а ạ ą ä à á ą
c	с ƈ ċ
d	ԁ ɗ
e	е ẹ ė é è
g	ġ
h	һ

Repo Rinse

This will blow away anything that is not committed.

git reset --hard
git submodule foreach --recursive 'git reset HEAD . || :'
git submodule foreach --recursive 'git checkout -- . || :'
git submodule update --init --recursive
git clean -d -f -f -x
git submodule foreach --recursive git clean -d -f -f -x

Business wants to know:

How many features can you get done?
When will features be in production?

Story estimates provide unreliable answers to these questions. Further, the process of estimating stories can be harmful.

Even perfectly accurate estimates do not change the value of a story. Repeatedly deciding to defer very valuable but expensive stories in favor of cheap, nice-to-have stories will not instill a sense of trust in the customer. Knowing the costs of user stories distracts management from remaining focused on meeting the most important needs as quickly as possible. On top of that, estimates are always wrong. Sometimes wildly so. Why make bad decisions based on worse data?

It turns out that deliberately avoiding estimating helps teams focus on delivering the most valuable business needs, in a more efficient, incremental way. Progress transparency can be provided with story counts and cycle/lead times to show wait times in the queue/backlog without having to estimate anyth

Projects Using Mage:

Elastic Beats - Lightweight shippers for Elasticsearch & Logstash
Go Sparta - go microservices, powered by AWS Lambda
Gnormal 324
Hugo - Static Site Generator
Microsoft Cobalt - Infrastructure turn-key solution for app service workloads
MysteriumNetwork CI - CI tool for Decentralised VPN built on blockchain

Mage Tools - See magefile tags

If you've ever dealt with a team where different people had different versions of linters installed, you'll quickly realize that you should also lock your tools.

Before Go 1.13

Before Go 1.13 the recommended solution was to use tools.go file like this:

// +build tools

package tools

import (

From You're not actually building microservices

So, are you building microservices? Take a look at a few of these symptoms, and decide for yourself:

❌ A change to one microservice often requires changes to other microservices
✅ Deploying one microservice requires other microservices to be deployed at the same time
❓ Your microservices are overly chatty
❌ The same developers work across a large number of microservices
✅ Many of your microservices share a datastore
✅ Your microservices share a lot of the same code or models

	package main

	import (
	"bytes"
	"fmt"
	"text/template"
	)

	func WithMap(format string, m map[string]string) (string, error) {
	tpl, err := template.New("format").Parse(format)

	brew install caddy mkcert nss dnsmasq

	mkcert -install
	# test could be anything
	mkcert '.app.test' '.cdn.test'

	# rename the certs and move them under /usr/local/etc/caddy/certs

	cat <<EOF > /usr/local/etc/caddy/Caddyfile
	.app.test:443, .cdn.test:443 {