antdking

#!/usr/bin/env python
from contextlib import contextmanager
import inspect
from tempfile import NamedTemporaryFile
import typing as t
import typing_extensions as te

import os
import pystemd
import pystemd.run

antdking

#!/usr/bin/env bash

# gcloud doesn't provide a mechanism to configure Artifact Registry auth helpers out the box.
# ref: https://cloud.google.com/artifact-registry/docs/docker/authentication?hl=en-GB#gcloud-helper

registries="$(gcloud artifacts locations list --format json | jq -r '. | map("\(.name)-docker.pkg.dev") | join(",") | @sh')"

# don't quote 'registries', it's already escaped by jq
gcloud auth configure-docker $registries

antdking

Title

Guiding Principles

To let you be Production Ready from Day 0

Using the tool should enable tightly securing and monitoring your services, with no extra work necessary. Your scratch code is now near Production Ready*.

No Compromising Maintainability

Simple design, both for you and us.

antdking

#!/usr/bin/env bash

set -Eeuo pipefail

video_file="${1}"
palette_file="$(mktemp --suffix=.png)"
output_file="${video_file%.*}.gif"

function cleanup() {
  rm -f "${palette_file}"

antdking

import logging
import os
from collections import defaultdict
from typing import Dict


LOG = logging.getLogger(__name__)


class ParameterStoreEnvirontment:

antdking

root = true

[*]
charset = utf-8

end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

indent_style = space

antdking

version: "3.7"

services:
  app:
    build: .
    depends_on:
      - db
    x-tasks:
      test:
        depends_on: db launch

antdking

Python Types, why you should use stubs

TLDR;

Types are great, and so are stub files. However there's a major issue at the moment which means your implementation doesn't have to behave the same as what your stub file say. Don't use stub files yet.

The Background

antdking

a = ([]+![]) [+!![]]
c = ([]+ [][([]+![])[+[]] + ([]+![])[!![]+!![]] + ([]+![])[+!![]] + ([]+!![])[+[]]])[!![]+!![]+!![]] // []['flat'][3]
d = ([]+[][[]]) [!![]+!![]]
e = ([]+!![]) [!![]+!![]+!![]]
f = ([]+![]) [+[]]
i = ([]+[][[]]) [!![]+!![]+!![]+!![]+!![]]
l = ([]+![]) [!![]+!![]]
n = ([]+[][[]])[+!![]]  // undefined[1]
o = ([] + [][([]+![])[+[]] + ([]+![])[!![]+!![]] + ([]+![])[+!![]] + ([]+!![])[+[]]])[!![]+!![]+!![]+!![]+!![]+!![]] // function[6]
r = ([]+!![]) [+!![]]

antdking

At MadeTech, we need to deal with hundreds of projects, across lots of workspaces, and potentially across hundreds of clients' workspaces too.

To keep a standard approach, we should split dotfiles, or config files in general, into 3 categories:

• Project level, Source controlled
• Project level, user controlled
• Workspace level, user controlled

Project level, source controlled