-
Use Onion architecture
- Dependencies go inwards. That is, the Core domain doesn't know about outside layers
-
Use pipeline model to implement workflows/use-cases/stories
- Business logic makes decisions
- IO does storage with minimal logic
- Keep Business logic and IO separate
-
Keep IO at edges
** Find commmonly accessed tables and their use of indexes: | |
SELECT relname,seq_tup_read,idx_tup_fetch,cast(idx_tup_fetch AS numeric) / (idx_tup_fetch + seq_tup_read) AS idx_tup_pct FROM pg_stat_user_tables WHERE (idx_tup_fetch + seq_tup_read)>0 ORDER BY idx_tup_pct; | |
Returns output like: | |
relname | seq_tup_read | idx_tup_fetch | idx_tup_pct | |
----------------------+--------------+---------------+------------------------ | |
schema_migrations | 817 | 0 | 0.00000000000000000000 | |
user_device_photos | 349 | 0 | 0.00000000000000000000 |
# How to run | |
# In the folder with these files | |
# sudo python -m SimpleHTTPServer 80 | |
# | |
# Update the ip at the bottom of this file to the output of | |
# hostname -I | |
# This is your ip | |
# | |
# Start debian cd | |
# Press esc on menu |
#!/usr/bin/env bash | |
set -e | |
function usage() { | |
set -e | |
cat <<EOM | |
##### ecs-run ##### | |
Simple script for running tasks on Amazon Elastic Container Service | |
One of the following is required: | |
Required arguments: |
package main | |
import ( | |
"encoding/json" | |
"io/ioutil" | |
"log" | |
"net/http" | |
"os" | |
"bufio" |
This document is targeted at those who seek to build reproducible dev environment across machines, OS, and time.
It maybe easier for remote teams to work together and not spending hours each person setting up asdf/pyenv/rbenv
, LSP servers
, linters
, runtime/libs
. Nix is probably the closest thing to Docker in terms of development environment.
Flake is used here because it provides hermetic build, with absolutely no reliance on system environment (be it Arch/Catalina/Mojave). Also it freezes dependencies in flake.lock
so builds are reproducible.
This gist provides the setup to develop Java/Clojure/Python applications on Nix. But it can be easily adapted to ruby, nodejs, haskell.
#!/bin/bash | |
# video demo - https://www.youtube.com/watch?v=Y8TyE_DNds8 | |
mkdir ~/.tmp && cd $_ | |
# install aws-cli v2 | |
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && \ | |
unzip awscliv2.zip && \ | |
sudo ./aws/install |
#!/bin/bash | |
# video demo - https://www.youtube.com/watch?v=Y8TyE_DNds8 | |
mkdir ~/.tmp && cd $_ | |
# install aws-cli v2 | |
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && \ | |
unzip awscliv2.zip && \ | |
sudo ./aws/install |
Let us define an observable microservice as one that exposes its internal state through events, metrics, and trace data. Ideally we can aggregate this data in some sort of centralized observability system for alerting and diagnostics. In my opinion there are tools that work much better than others and I will use those in this example but the most important part is that you have a starting point and your services can be observed and alerted on somehow. If your company does not have the means to setup all of this infrastructure you should consider buying one of the many SaaS options out today.
Disclaimer: I am not a native .net or F# developer, I think at this point in my career I've logged 2 weeks on an F# dev team so the implementations given below may not be idiomatic, however, my experience comes from being apart of both Devops and microservices dev teams in other teams and organizations.
That being said; let's start building an "observable" micro
#!/bin/bash | |
bucket=$1 | |
set -e | |
echo "Removing all versions from $bucket" | |
versions=`aws s3api list-object-versions --bucket $bucket |jq '.Versions | .[] | select(.IsLatest | not)'` | |
markers=`aws s3api list-object-versions --bucket $bucket |jq '.DeleteMarkers'` |