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:
| package main | |
| import ( | |
| "bytes" | |
| "fmt" | |
| "text/template" | |
| ) | |
| func WithMap(format string, m map[string]string) (string, error) { | |
| tpl, err := template.New("format").Parse(format) |
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
| 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 { |
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
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 the recommended solution was to use tools.go file like this:
// +build tools
package tools
import (
So, are you building microservices? Take a look at a few of these symptoms, and decide for yourself:
We have a s3cr3t repository (ok, you can probably find it, but don't peek) that we will announce right before the contest start. It's some of the exercises that were literally and liberally stolen from literally and liberally stolen from the Exercism.io Go track.
Fork this repo, solve the exercises, and submit a pull request TO THAT REPO, NOT EXERCISM/GO for judging with the description containing your personal Tally (see rubric). No more commits after the time limit, but you can fuss with your Pull Request more after the time is up (like counting your score).
Please notify the judges in Slack the #go-contest channel which one, if any of your fully 100% passing solutions, should be considered for Special Awards: