Alexander realAlexBarge

Octave CheatSheet

GNU Octave is a high-level interpreted language, primarily intended for numerical computations.
(via GNU Octave)

Hint: I also mad an octave docset for Dash: https://github.com/obstschale/octave-docset

Basics

API testing

Fuzz Testing For HTTP Endpoints

The artillery-plugin-fuzzer plugin makes it easy to run simple fuzz tests (also known as monkey tests) on HTTP endpoints.

Content / string testing

Big List of Naughty Strings

The Big List of Naughty Strings is an evolving list of strings which have a high probability of causing issues when used as user-input data. This is intended for use in helping both automated and manual QA testing.

☁️ How I got off the cloud and migrated everything from AWS to a VPS in Hetzner

This is an opinionated handbook on how I migrated all my Rails apps off the cloud and into VPS.

This is how I manage real production loads for my Rails apps. It assumes:

Rails 7+
Ruby 3+
PostgreSQL
Ubuntu Server 24.04
Capistrano, Puma, Nginx

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

	# Reserved Strings
	#
	# Strings which may be used elsewhere in code

	undefined
	null

	# Numeric Strings
	#
	# Strings which can be interpreted as numeric

	#!/bin/bash

	# This script takes a clean Ubuntu Server 24.04 LTS AMI and installs and configures
	# everything needed to deploy a Rails 7 app to it. The resulting state is a secure,
	# production-ready instance.

	set -euo pipefail

	# --- AESTHETICS ---

	#!/bin/bash

	# Production Docker Host Setup Script
	# This script sets up a secure, production-ready Docker host on Ubuntu Server 22.04 LTS
	# It includes security hardening, performance optimizations, and best practices
	# CAUTION: This script makes significant system changes. Use at your own risk.

	set -euo pipefail

	# --- AESTHETICS ---

	Understand the Task: Grasp the main objective, goals, requirements, constraints, and expected output.
	- Minimal Changes: If an existing prompt is provided, improve it only if it's simple. For complex prompts, enhance clarity and add missing elements without altering the original structure.
	- Reasoning Before Conclusions: Encourage reasoning steps before any conclusions are reached. ATTENTION! If the user provides examples where the reasoning happens afterward, REVERSE the order! NEVER START EXAMPLES WITH CONCLUSIONS!
	- Reasoning Order: Call out reasoning portions of the prompt and conclusion parts (specific fields by name). For each, determine the ORDER in which this is done, and whether it needs to be reversed.
	- Conclusion, classifications, or results should ALWAYS appear last.
	- Examples: Include high-quality examples if helpful, using placeholders [in brackets] for complex elements.
	- What kinds of examples may need to be included, how many, and whether they are complex enough to benefit from p

	You are an assistant that engages in extremely thorough, self-questioning reasoning. Your approach mirrors human stream-of-consciousness thinking, characterized by continuous exploration, self-doubt, and iterative analysis.

	## Core Principles

	1. EXPLORATION OVER CONCLUSION
	- Never rush to conclusions
	- Keep exploring until a solution emerges naturally from the evidence
	- If uncertain, continue reasoning indefinitely
	- Question every assumption and inference

	## Workflow Orchestration

	### 1. Plan Node Default
	- Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
	- If something goes sideways, STOP and re-plan immediately - don't keep pushing
	- Use plan mode for verification steps, not just building
	- Write detailed specs upfront to reduce ambiguity

	### 2. Subagent Strategy
	- Use subagents liberally to keep main context window clean