Yo
SlackExtract | |
.env | |
*.cache.json | |
*.json | |
.DS_Store | |
.cache/ | |
__pycache__/ |
package main | |
type TestingToken struct { | |
jwt string | |
} | |
func (t token) GetRequestMetadata(ctx context.Context, uri ...string) (map[string]string, error) { | |
return map[string]string{ | |
"authorization": "bearer " + t.token, | |
}, nil |
#book #read
by Patrick Lencioni
Lencioni reveals the five dysfunctions which go to the very heart of why teams even the best ones-often struggle. He outlines a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team.
- Lack of trust
I hereby claim:
- I am voidfiles on github.
- I am voidfiles (https://keybase.io/voidfiles) on keybase.
- I have a public key ASDv2Yh9I6PNOuiWnsIqrPstDmgmmvuuuK9dEfSMhVM7AAo
To claim this, I am signing this object:
This is an attempt to enumerate my values as a developer. In order to better evaluate future choices.
Face it, most things we try for the first time don't work quite right. That is the nature of trying new things. But, trying things is how we adapt. Given that the world is rapidly changing, the only way we can keep up is to try lots of new things, constantly. Therefore I highly value experimentation especially the kind that leads to failure as it is the best teacher.
Any choice I make needs to embrace experimentation. It should have a healthy budget for failure or missing the mark. It should learn from failure.
Ansible is configuration management tool and remote orchestration tool. It's kind of like Puppet, and Fabric had a baby. It can get boxes into a desired state like Puppet, but it can also run commands on a bunch of remote boxes like Fabric. It has a few difference from puppet. Namely that it pushes its configuration on demand to boxes instead of having a puppet dameon periodically check for changes and reset things. It also is configured entirely through yaml files that run tasks, instead of having a DSL for managing state.
Ansible is broken down into three major parts. Inventory, Playbooks, and Roles. I will cover these three briefly. Anyone looking for a more in-depth documentation on ansible should checkout the docs.
An inventory is a document that describes all of the hosts you want to manage, and how they are grouped. Take a look at our master inventory to get a sense of the structure.
{ | |
"version": "https://jsonfeed.org/version/1", | |
"title": {{ .Site.Title | jsonify }}, | |
"home_page_url": {{ .Permalink | jsonify }}, | |
{{ with .OutputFormats.Get "json" -}} | |
"feed_url": {{ .Permalink | jsonify }}, | |
{{- end }} | |
{{ if (.Site.Params.author) or (.Site.Params.author_url) -}} | |
"author": { | |
{{ if .Site.Params.author -}} |
#! /bin/bash -e | |
set -ex | |
if [[ -z "${BUILD_TAG}" ]]; then | |
echo "BUILD_TAG must be set before running this script"; | |
fi | |
export WORKSPACE=$(pwd) |
Let me know if this sounds, right.
I work at a company that has N services. Each service has it's own deployable artifact. Each artifact creation process is unique, but the pipeline, and deployment processes are similar. As we grow we are looking to create more services. I would like to manage this complexity in a couple of ways.
- We use Jenkins
- I'd like to use Jenkinsfile's to manage the jobs
- The artifact process should stay unique, some shared code loaded via fileLoader.fromGit
- I plan on using a shared deployment job configured via params
- I plan on using a shared pipeline job configured via params