Skip to content

Instantly share code, notes, and snippets.

Avatar

Steve Coffman StevenACoffman

64 followers · 12 following
  • Khan Academy
  • Ann Arbor, MI
View GitHub Profile
@StevenACoffman
StevenACoffman / DACI.md
Last active Jul 11, 2022
DACI - Driver, Approver, Contributor, Informed
View DACI.md

Driver, Approver, Contributor, Informed (DACI)

Definition

The decision-making model we use, see below for acronym breakdown

The DACI acronym stands for the people who are involved in the decision-making process.

  • D = Driver. There is one driver and that person is responsible for getting stakeholders involved, gathering the input, and working with the Approver to ensure that the decision is made in the necessary timeframe. The driver need not be the person that leads the implementation of the decision.
  • A = Approver. The Approver is usually one person who is accountable for the results of the decision. The final decision is theirs alone. Less frequently, a decision will have more than one Approver, if it is affecting multiple areas of the organization and needs consensus among leads.
@StevenACoffman
StevenACoffman / gcs-signed-url-main.go
Created Jun 28, 2022 — forked from pdecat/gcs-signed-url-main.go
Creating a GCS Signed URL without a Service Account Key from a GCE instance or a GKE Pod using Workload Identity
View gcs-signed-url-main.go
package main
import (
"context"
"flag"
"log"
"net/url"
"time"
"cloud.google.com/go/compute/metadata"
@StevenACoffman
StevenACoffman / new-jersey-vs-mit.md
Last active May 1, 2022
Worse-Is-Better
View new-jersey-vs-mit.md

The New Jersey style (aka "Worse is Better") a model of software design and implementation which has the characteristics (in approximately descending order of importance):

  1. Simplicity: The design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.

  2. Correctness: The design should be correct in all observable aspects. It is slightly better to be simple than correct.

  3. Consistency: The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either complexity or inconsistency in the implementation.

  4. Completeness: The design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness

@StevenACoffman
StevenACoffman / index.html
Last active Apr 13, 2022 — forked from endrebak/chart.js
View index.html
<!DOCTYPE html>
<html lang="en">
<head>
<title>D3-Dag</title>
</head>
<body>
<div id="wrapper"></div>
<script src="https://unpkg.com/d3@6.7.0"></script>
<script src="https://unpkg.com/d3-dag@0.7.0"></script>
<script src="./zchart.js"></script>
@StevenACoffman
StevenACoffman / README.md
Created Apr 7, 2022 — forked from lawrencejones/README.md
Code examples to go with https://incident.io/blog/golang-errors
View README.md
@StevenACoffman
StevenACoffman / time-test.md
Created Mar 25, 2022
Time Tested techniques for testing time
View time-test.md

You can use an unexported package variable pointing to the time.Now function.

var (
    timeNow   = time.Now
    timeAfter = time.After
)

// ...

type Obj struct{}

@StevenACoffman
StevenACoffman / kubernetes-gitops-secrets.md
Last active Jan 31, 2022
Kubernetes GitOps Secrets
View kubernetes-gitops-secrets.md
@StevenACoffman
StevenACoffman / static.md
Last active Jan 21, 2022
Static binaries for various languages
View static.md
@StevenACoffman
StevenACoffman / go-mod-update.md
Last active Nov 14, 2021
go mod update
View go-mod-update.md

If you use cgo, then a lot of go module tools get really slow per golang/go#29427

For example, this is really slow:

go list -m -u all

Maybe Instead:

@StevenACoffman
StevenACoffman / pull-request-types.md
Created Oct 3, 2021
pull-requests-types.md
View pull-request-types.md

From The 7 Types of Pull Requests:

After reading Rouan Wilsenach’s article on Ship / Show / Ask, I realized that when creating a pull request, I’m thinking about:

  • How can I confidently get my code out of the door?
  • Will my changes pass the automated CI checks?
  • Will my changes pass a self-review? I.e. would I approve my own PR?
  • Will my colleagues be able to give me good feedback?

So this gives us 7 types of pull-request:

No Pull Request / Ship