quad

I've been writing Rust full-time with a small team for over a year now. Throughout, I've lamented the lack of clear best practices around defining error types. One day, I'd love to write up my journey and enumerate the various strategies I've both seen and tried. Today is not that day.

Today, I want to reply to a blog post that almost perfectly summarised my current practice.

Go read it; I'll wait!

---

quad

cinch: supervisor trees for Rust

Constraints

1. Intra-task concurrent, because the child tasks can always opt-in to multi-task concurrency.

Problem Encountered

Matching -> impl Future with <F: Future>

Owning Future Lifetimes

quad

Don't use log levels, use structured logging

I read [an argument for only two log levels: INFO and ERROR][only-info-error]. I [responded][log-response] essentially saying:

1. I lightly agree that we could get away with two log levels.
2. I strongly disagree that we only need two ways to log.

Like the blog post's author, most of systems that I've worked on have had poor logging practices. But unlike the blog post's author, I strongly suspect that's because most logging APIs offer poor affordances.

quad

function sync() {
  const srcId = "you@example.com";
  const syncWindowInDays = 7;
  const syncStatuses = [
    CalendarApp.GuestStatus.MAYBE,
    CalendarApp.GuestStatus.OWNER,
    CalendarApp.GuestStatus.YES,
  ];
  
  const now = new Date();

quad

#!/bin/zsh

set -euo pipefail

start_sudo_session() {
	sudo --validate

	while :; do
		kill -0 $$ &>/dev/null
		sudo --non-interactive --validate

quad

from cryptography.hazmat.primitives.asymmetric.ec import ECDSA
from cryptography.hazmat.primitives.hashes import SHA256
from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat
from ykman.device import list_all_devices
from ykman.logging import init_logging
from yubikit.core import TRANSPORT
from yubikit.core.smartcard import SmartCardConnection
from yubikit.logging import LOG_LEVEL
from yubikit.management import CAPABILITY
from yubikit.openpgp import EcAttributes, KEY_REF, OID, OpenPgpSession

quad

What is this architecture called?

I rarely see the classical three-tier architecture in the wild; I frequently see a different architecture.

I don't know this architecture's name. Do you?

The Three-Tier Architecture

The "three-tier architecture" has been the reference pattern for Internet services:

quad

Interceptors Are Functions Too

I could not agree more with my colleague and friend Travis Johnson's opinion that "[INTERCEPTORS ARE SO COOL][iasc]!" In that post, he succinctly describes the [Interceptor pattern][pattern] as used adroitly by [OkHttp][okhttp]. But, as is often the case, I believe a complicated object-oriented pattern obscures the simple functional gem within it.

What is an Interceptor?

I'll quote liberally from [OkHttp's documentation on the topic][okhttp-interceptor]:

Interceptors are a powerful mechanism that can monitor, rewrite, and retry calls. […] >

quad

The Hybrid Service Architecture

I haven't found a description of the service architecture I frequently see; but, the Internet is lousy with descriptions of three tier and event driven architectures.

This write-up is for Future Me to point at when asked how to design a network service.

tl;dr

• A server cluster, scaled horizontally
• A queue cluster, scaled vertically or sharded

quad

#!/usr/bin/env ruby
#
# hey! a minimalist CRM for http://todotxt.com/
#
# hey tells you one thing you should do regularly, but haven't done lately.
#
#   $ todo.sh lf hey
#   1 @phone Mom (+1 234 567 8901) +family
#   2 @skype Dad +family
#   3 @email mentor