lynsei

Caching multi-stage builds in GitHub Actions

Caching Docker builds in GitHub Actions is an excellent article by @dtinth which analyses various strategies for speeding up builds in GitHub Actions. The upshot of the article is a fairly decisive conclusion that the best two ways to improve build times are:

1. Build images via a standard docker build command, while using GitHub Packages' Docker registry as a cache = Longer initial build but fastest re-build times.

2. Build your images via docker integrated BuildKit (DOCKER_BUILDKIT=1 docker build), while using a local registry and actions/cache to persist build caches = Fastest initial build but slightly longer re-build times.

The problem

lynsei

# import config.
# You can change the default config with `make cnf="config_special.env" build`
cnf ?= config.env
include $(cnf)
export $(shell sed 's/=.*//' $(cnf))

# import deploy config
# You can change the default deploy config with `make cnf="deploy_special.env" release`
dpl ?= deploy.env
include $(dpl)

lynsei

// Uses CommonJS, AMD or browser globals to create a jQuery plugin.

(function (factory) {
    if (typeof define === 'function' && define.amd) {
        // AMD. Register as an anonymous module.
        define(['jquery'], factory);
    } else if (typeof module === 'object' && module.exports) {
        // Node/CommonJS
        module.exports = function( root, jQuery ) {
            if ( jQuery === undefined ) {

lynsei

test

lynsei

syntax = "proto3";

// Package pb provides the protobuf definition of LLB: low-level builder instruction.
// LLB is DAG-structured; Op represents a vertex, and Definition represents a graph.
package pb;

import "github.com/gogo/protobuf/gogoproto/gogo.proto";

option (gogoproto.stable_marshaler_all) = true;

lynsei

Keybase proof

I hereby claim:

• I am lynsei on github.
• I am lynsei (https://keybase.io/lynsei) on keybase.
• I have a public key ASCfJHPBjB-l1vf6NSJFE1rhWWzYsVJg0VZWtWmFSqqZZQo

To claim this, I am signing this object:

lynsei

import type { NextRequest } from 'next/server'

export async function middleware(req: NextRequest) {
  // https://developer.mozilla.org/en-US/docs/Web/API/Crypto/subtle
  const plainText = 'Hello from the Edge!'
  const password = 'hunter2'
  const ptUtf8 = new TextEncoder().encode(plainText)
  const pwUtf8 = new TextEncoder().encode(password)
  const pwHash = await crypto.subtle.digest('SHA-256', pwUtf8)

lynsei

# Ḻʸⁿˢ
# serverless emulation tools for:
# /.data.cleansing <<< foolish input device permutations 
# /.pkg.singleton  <<< I used sift for roughly 10 years in high-traffic portal spaces
#
# .RIE
#    /.RIC
#    /.AWS.Serverless
#    /.Lambda
#    /+?.Twilio.Flex.Functions

lynsei

Sequelize: Step-By-Step

Sequelize is a powerful library in Javascript that makes it easy to manage a SQL database. Sequelize can layer over different protocols, but here we'll use PostgreSQL. At its core, Sequelize is an Object-Relational Mapper – meaning that it maps an object syntax onto our database schemas. Sequelize uses Node.JS and Javascript's object syntax to accomplish its mapping.

Under the hood, Sequelize used with PostgreSQL is several layers removed from our actual database:

1. First, we write our Sequelize, using Javascript objects to mimic the structure of our database tables.
2. Sequelize creates a SQL string and passes it to a lower-level library called pg (PostgreSQL).
3. pg connects to your PostgreSQL database and queries it or transforms its data.
4. pg passes the data back to Sequelize, which parses and returns that data as a Javascript object.

lynsei

/**
 * A variant of the JSON reader. Instead of reading arrays, where each record in the array field
 * has an 'id' property, it reads objects - aka associative arrays. The key of the entry will be the
 * array.
 * 
 * So where the JSON reader would like data like this:
 * [ { id: '1', property: 'foo' }, { id: '2', property: 'bar' } ]
 * 
 * the associative reader likes data like this:
 * { '1': { property: 'foo' }, '2': { property: 'bar' } }