Name | Image |
---|---|
aircall-available | ![]() |
aircall-connected | ![]() |
aircall-incoming |
# .bashrc QoL adds. | |
# Ultra lazy... | |
alias urc='source ~/.bashrc' | |
# Save history immediately | |
shopt -s histappend | |
#PROMPT_COMMAND="history -a;$PROMPT_COMMAND" | |
# https://askubuntu.com/questions/67283/is-it-possible-to-make-writing-to-bash-history-immediate | |
grep -q 'history -a' <<< $PROMPT_COMMAND || export PROMPT_COMMAND="history -a; $PROMPT_COMMAND" |
This GIST is here simply to demonstrate some workflows I've found helpful in guaranteeing a well-developed backlog for iteration teams. That said, workflows can be as simple or as complex as you need for your organization/project. At scale though, it's highly desirable to have a backlog as beautifully maintained as your products as their qualities are interdependent. And you'll see this point surface in retrospectives/feedback over time.
First off, DO NOT have workflows that looks like this:
#!/usr/bin/env python | |
# Copy into /usr/local/bin or as appropriate for your $PATH | |
import argparse | |
from pypdf import PdfReader | |
from pypdf.errors import PdfReadError | |
parser = argparse.ArgumentParser() | |
parser.add_argument("pdf", help="The PDF to extract attachments from.", type=str) |
Character Sets/Ranges [] : Match any characters within. Required expression.
Qualifiers {} : Quantity or range of an expression. IE: {3}, {2,200}
Groups () : Group expressions. Subgroups supported.
Non-Capturing Group (?:foo) : Does not "remember" matches. Lower overhead.
Kleen Star * : May occur 0 or more times.
APIGW is NOT the AWS service, but an industry standard technology for servicing resource access while providing facilities for oversight, governance, security, and operability considerations.
Some options:
- Apache APISIX
- Free, but you still pay for your own wrench time.
- Kong
- The GW is open source and free to use, but many features (such as OIDC) are paywalled.
🗒️ An excerpt from my good, ol' Jira Team Runbook.
Acceptance Criteria tactices are ever evolving, but this is a good skeleton to start from.
- User story
- Functional requirements
- Link to design docs / supporting resources
- Technical breakdown and analysis to identify infrastructure dependencies
#!/usr/bin/env bash | |
# ---------------------------------------------------------------------------------------------------------------------- | |
# | |
# make-ca-cert.sh | |
# | |
# SYNOPSIS | |
# Creates a CA if one doesn't already exist, and installs it (debian). | |
# Creats a server certificate (including wildcard SAN) signed by the CA. | |
# |
Project Management can be as simple or as complex as needed. If your project is you and a few highly-aligned folks in the same room then you might be able to make due with a whiteboard and some sticky-notes, but this doesn't scale. There's a lot of expertise involved in taking a project from sticky-notes to a scaled agile enterprise operating model, but the foundations of planning don't change. IE: If you want to dig for treasure, then you should plan to get a shovel to enable your success.
Before you jump into executing your vision, start by discovering a your minimum viable operating posture (see also the concept of minimum virtuous products), as this dictates a large portion of your overall organizational structure and talent strategy. Getting this wrong is similar to getting software architecture wrong -- it's all dysfunction and d