tym-xqo

#!/usr/local/bin/zsh

TOKEN=$(python3 -c "import secrets; print(secrets.token_hex(24)[:7])")
# echo $TOKEN
POD=$(kubectl get pods | grep tmp-$USER-dba | awk '{print $1}')
if [[ -z $POD ]]
then
    POD="tmp-$USER-dba-$TOKEN"
    kubectl run $POD \
    --image=registry.gitlab.com/tym27/jackknife:latest \

tym-xqo

author	title	revision	version	description
tym-xqo	BenchPrep SQL Style Guide	2021-12-12	1.1.1	A guide to writing clean, clear, and consistent SQL.

BenchPrep SQL Style Guide [WIP]

tym-xqo

Burning Glass query analysis

(TL;DR: see "Recommendations" at the end)

OK, so. There are a few things going on here. The example query as originally written:

explain analyze
select count(*)
  from "burning_glass_jobs"

tym-xqo

Nerium SaaS MVP ideas

• Nerium does not have a SQL query authoring interface, by design. "Write SQL in your favorite editor" is a feature, indeed one of the main selling points.
• So, a public offering needs a way to get SQL to it. I'm thinking of something that handled this through cloud storage: user writes and saves queries to a local directory; Nerium-SaaS offers a mechanism like Netlify, to ingest that and upload it to the cloud, using some naming scheme to ID the tenant and an "upload event" or release.
• also like Netlify, this could be handled via GitHub integration
• user also needs to be able to provide a database url to their data source. this will necessarily include a password, so it will have to be done securely somehow — I.e. ideally the Nerium instance we launch for them in k8s as access to it, but we as the service provider do not. At a minimum, if we can't get around having to share the share the secret, it's at least protected from other tenants and outsiders. In general, I imagine th

tym-xqo

How to run Postgres locally in Docker

• If you have a local Postgres service running on port 5432, stop it first
• Get Docker Desktop for Mac if you don't have it already
• Pull Postgres 10 image from Docker Hub: docker pull postgres:10
• Create a directory in a known location that will be mounted as a data volume where the container will store the database files: mkdir -p -m 0700 ${HOME}/Library/postgres-data
• Run the image (note that POSTGRES_PASSWORD is required in the container environment, and will be the password for the postgres user in the container Postgres instance):

   docker run -d \
     --name=dev-postgres \

tym-xqo

#!/bin/bash
set -e
env=${1-integration}
chart=${2-apps}
config=$(kubectl config get-contexts -o name | grep "$env")
for i in $config; do
    kubectl config use-context $i
    helm3 status $chart
done

tym-xqo

Ansible and you

Configuration management

Definition: the systems engineering practice of handling changes systematically so that a system maintains its integrity over time.

In software, this generally means ensuring the consistency of the environment in which our applications run:

• the operating system
• versions of interpreters, libraries, packages, and other services on which our stuff depends

tym-xqo

#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""Use SQLAlchemy engine to fetch a dataset from a query
"""
import os

from jinja2.sandbox import SandboxedEnvironment
from sqlalchemy import create_engine

tym-xqo

Podcast format proposal

• overall: as-it-happens discussion/conversation between ~tym and ~jmiller
• maybe invite other guests sometimes?
• broadly, subject matter of these conversations would focus on "what we think works in software projects" with the philosophy of "radical incrementalism" in the background — but not be limited to these
• let's record 6 1-hour sessions
  • it would be nice if we can get together in person for these somewhere, but we could always do over a call
• following something like St. John's College seminar practice, each session begins with an Opening Question, which we take turns asking
• once underway, we should let the conversation "follow the argument" — we don't need to stick to trying to answer the opening question directly; relevant tangents and even out-and-out digression is welcome and encouraged (although we should try to circle back and close open loops where we can). The Opening Question is a way to begin the discussion, not to limit its course
• after we have 6 hours

tym-xqo

Playbook/Checklist: adding disk space to boost01/mount

Failover to boost02

• (Maybe/Probably) Suspend boost reporting job
• ut site in maintenance mode(?)
• Manual run of boost etl job
• Switch Production k8s endpoints to boost02
  • external-reporting-compute-database
• external-reporting-database