kjm0001

# add the contents of this file to ~/.inputrc

# this is where the magic happens
set editing-mode vi

# vi INSERT prompt
set vi-ins-mode-string "\1\e[30;44m\2 INS \1\e[0m\2 "

# vi NORMAL prompt
set vi-cmd-mode-string "\1\e[30;47m\2 NOR \1\e[0m\2 "

kjm0001

kubectl delete "$(kubectl api-resources --namespaced=true --verbs=delete -o name | tr "\n" "," | sed -e 's/,$//')" --all

kjm0001

#!/usr/bin/env bash
for user in $(aws iam list-users --output text | awk '{print $NF}'); do
    aws iam list-access-keys --user $user --output text
    test $? -gt 128 && exit
done

kjm0001

GitOps for Helm Users

Outline

1. Install Flux CLI and Kind
2. Make Personal Access Token for creating repositories
3. Export env vars locally
4. Create local demo cluster
5. Simple bootstrap
6. Clone the newly created git repo to your local workspace
7. Lets create a Helm release the most common way, using the Helm CLI

kjm0001

Git Flow (with rebasing)

See http://nvie.com/posts/a-successful-git-branching-model/

Features

kjm0001

"" Source your .vimrc
"source ~/.vimrc

"" -- Suggested options --
" Show a few lines of context around the cursor. Note that this makes the
" text scroll if you mouse-click near the start or end of the window.
set scrolloff=5

" Do incremental searching.
set incsearch

kjm0001

aws ssm get-parameters-by-path --path '/path/to/prams' --recursive \
  | jq .Parameters[].Name \
  | xargs -L1 -I'{}' aws ssm delete-parameter --name {}

kjm0001

#!/bin/sh

jq -c '.[]' params.json | while read i; do
    aws ssm put-parameter --cli-input-json $i
done

kjm0001

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

kjm0001

When many different people are working on a project simultaneously, pull requests can go stale quickly. A "stale" pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project. The most common reason why pull requests go stale is due to conflicts: if two pull requests both modify similar lines in the same file, and one pull request gets merged, the unmerged pull request will now have a conflict. Sometimes, a pull request can go stale without conflicts: perhaps changes in a different file in the codebase require corresponding changes in your pull request to conform to the new architecture, or perhaps the branch was created when someone had accidentally merged failing unit tests to the master branch. Regardless of the reason, if your pull request has gone stale, you will need to rebase your branch onto the latest version of the master branch before it can be merged.

What is a rebase?