DEV Community: Malcolm Low

Optimization Problems Explained: Traveling Salesman, Job Shop Scheduling, and the Knight's Tour

Malcolm Low — Thu, 10 Sep 2026 11:56:38 +0000

Originally published on malcolmlow.com.

The Knight’s Tour walkthrough on this blog treats the problem as a coding exercise: implement Warnsdorff’s heuristic, watch a knight visit every square exactly once, move on. But the Knight’s Tour belongs to a much larger family — combinatorial optimization problems, where the challenge isn’t computing an answer, it’s searching an astronomically large space of candidate answers for a good one. The Traveling Salesman Problem and Job Shop Scheduling are the two most-cited members of that family, and putting all three side by side makes clear why certain techniques keep reappearing across logistics, manufacturing, and chessboard puzzles alike.

1 · What Makes a Problem “Combinatorial”

A combinatorial optimization problem asks for the best arrangement, ordering, or assignment out of a finite but enormous set of possibilities. “Finite” is the misleading part — finite doesn’t mean small. The number of ways to order 20 cities is 20! (roughly 2.4 × 10¹⁸), and it only grows from there. Checking every possibility, brute force, is correct but useless: even a supercomputer evaluating a trillion arrangements per second would need decades for a 25-city tour.

This is the shared root of all three problems below. Each has a small, easily-stated rule for what counts as a valid solution, and a combinatorial explosion of candidates that satisfy the rule. The interesting work isn’t defining the problem — it’s finding a good answer without enumerating the haystack.

A useful vocabulary distinction: a problem is NP-complete if it’s among the hardest problems whose solutions can at least be verified quickly, and NP-hard if it’s at least as hard as those, whether or not verification is fast. TSP’s decision version (“is there a tour under length L?”) is NP-complete; its optimization version (“find the shortest tour”) is NP-hard. Job Shop Scheduling is NP-hard. The Knight’s Tour is a special case that, unusually, isn’t — more on that in Section 4.

2 · The Traveling Salesman Problem

Given a list of cities and the distances between each pair, find the shortest possible route that visits every city exactly once and returns to the start. First studied formally in the 1930s, TSP is the problem most people picture when they hear “NP-hard” — partly because it maps so cleanly onto real logistics: delivery routing, PCB drilling paths, DNA sequencing fragment assembly, even warehouse pick-path optimization all reduce to some variant of TSP.

The number of distinct tours for n cities is (n−1)!⁄2 — for just 15 cities, that’s over 43 billion routes. Exact solvers exist (branch-and-bound, cutting planes, integer linear programming) and can handle surprisingly large instances — the Concorde TSP solver has certified optimal tours for problems with tens of thousands of cities — but they can take unbounded time in the worst case. In practice, most applications use heuristics instead:

Heuristic	Idea	Typical gap from optimal
Nearest neighbor	Always jump to the closest unvisited city	~25%
2-opt local search	Repeatedly uncross pairs of edges that improve total length	~5%

For a full worked treatment of nearest neighbor, 2-opt, 3-opt and tabu search — including pseudocode, complexity, and how the four methods fit into a single practical pipeline — see Solving the Traveling Salesman Problem: Nearest Neighbor, 2-Opt, 3-Opt and Tabu Search.

Beyond hand-designed heuristics, a large body of research applies metaheuristics — genetic algorithms, ant colony optimization, bee colony optimization — to push closer to optimal on large instances. One example: Choong, Wong, Low & Chong, “A Bee Colony Optimization Algorithm with a Sequential-Pattern-Mining-based Pruning Strategy for the Traveling Salesman Problem,” International Journal of Bio-Inspired Computation, 15(4), 239–253 (2020), which uses sequential pattern mining to prune the search space a bee colony algorithm explores, improving both solution quality and runtime over earlier bee colony variants on standard TSP benchmarks. Section 7 below lists the full line of TSP research this paper builds on.

Most of the field trades a provable worst-case guarantee away for speed, accepting “probably close to optimal, verified empirically on benchmark instances” instead — which is exactly the trade-off metaheuristic approaches like the one above are built around.

3 · Job Shop Scheduling

A set of jobs, each made of an ordered sequence of operations, must run on a shared set of machines. Each machine can only process one operation at a time, and each job’s operations must run in their specified order. The goal is usually to minimize makespan — the total time until every job finishes. This is the workhorse problem behind semiconductor fab scheduling, shipyard and manufacturing floor planning, and container terminal crane assignment — anywhere shared, expensive resources have to be sequenced across competing demands.

Even the deceptively small “3 jobs × 3 machines” instance can take meaningful compute time to solve exactly, and general Job Shop Scheduling is NP-hard — confirmed by Garey, Johnson, and Sethi in 1976. The search space is every valid interleaving of operations across machines respecting precedence constraints, which grows combinatorially with both job count and machine count simultaneously, faster than TSP’s single-dimension city count.

Common approaches: dispatching rules (simple greedy priorities like “shortest processing time first” or “earliest due date first”), genetic algorithms (evolve a population of candidate schedules via mutation and crossover), simulated annealing (accept occasional worse moves to escape local optima), and constraint programming solvers for smaller, high-stakes instances where near-optimality genuinely matters. Neural network approaches are also an active research direction: Sim, Low, Chong & Shakeri, “Job Shop Scheduling Problem Neural Network Solver with Dispatching Rules,” IEEM 2020, 14–17 December 2020, Singapore, trains a neural network to select which dispatching rule to apply at each decision point, rather than committing to a single fixed rule for the whole schedule. Section 7 lists the earlier bee-colony-based JSSP work this line of research follows from.

Unlike TSP, there’s no single dominant heuristic with a well-known worst-case bound — the field leans heavily on metaheuristics, learned dispatching policies, and problem-specific rules tuned empirically to the shop floor in question.

4 · The Knight’s Tour — the Odd One Out

A knight on a chessboard must visit every square exactly once using only legal knight moves. As covered in the Codex CLI walkthrough, this is a special case of the Hamiltonian path problem: model each square as a graph node, connect two nodes if a knight can move between them in one hop, and a Knight’s Tour is exactly a Hamiltonian path through that graph.

Finding a Hamiltonian path in an arbitrary graph is NP-complete — it belongs in the same hardness class as TSP’s decision version. But the knight’s-move graph on a chessboard isn’t arbitrary; it has enough regular structure that a simple greedy rule, Warnsdorff’s rule (always move to the unvisited square with the fewest onward moves), finds a complete tour almost every time on boards 5×5 and larger, in linear time, with no backtracking needed in the overwhelming majority of cases.

The general Hamiltonian-circuit problem — not restricted to a knight’s-move graph — is itself a live research target for the same metaheuristic techniques used on TSP: Wong, Low & Chong, “Finding the Shortest Hamiltonian Circuit of Selected Places in Penang Using a Generic Bee Colony Optimization Framework,” BIC-TA 2011, 51–57 applies a bee colony framework to find the shortest Hamiltonian circuit connecting real-world locations — the same underlying graph-theory object the Knight’s Tour is a highly structured special case of.

Why this matters: the Knight’s Tour is a working example of a problem that sits inside an NP-complete family in general, yet becomes tractable once you exploit the specific structure of the instance. It’s a reminder that “NP-hard in general” doesn’t mean “hard for every input” — structured sub-cases can be much friendlier than the worst case the complexity class describes.

5 · What the Three Have in Common

Problem	Complexity	Dominant heuristic	Real-world domain
TSP	NP-hard	Nearest neighbor, 2-opt	Logistics, routing
Job Shop Scheduling	NP-hard	Dispatching rules, genetic algorithms	Manufacturing, semiconductor fabs
Knight’s Tour	Tractable special case of Hamiltonian path (NP-complete in general)	Warnsdorff’s rule	Puzzle design, graph theory pedagogy

The pattern across all three: a greedy, locally-informed rule — go to the nearest city, dispatch the shortest job first, move to the most-constrained square — gets surprisingly close to optimal, surprisingly fast, with no guarantee it always will. Exact methods (branch-and-bound, ILP, constraint solvers) remain necessary when the application genuinely needs a certified optimum or a worst-case bound, but for most production systems, a well-tuned greedy heuristic plus local-search refinement is the pragmatic default.

6 · When to Reach for Which Tool

Small instance, need the true optimum: exact solvers — branch-and-bound, integer linear programming, or off-the-shelf constraint solvers (OR-Tools, Gurobi, CPLEX).
Large instance, “good enough” is genuinely good enough: a simple greedy heuristic, ideally with a known worst-case bound if one exists for the problem.
Large instance, need better than greedy but exact is too slow: metaheuristics — simulated annealing, genetic algorithms, tabu search — layered on top of a greedy starting solution.
Your instance has exploitable structure (like the knight’s-move graph’s regularity): look for a problem-specific rule before reaching for general-purpose machinery. The cheapest algorithm is the one that exploits structure the general theory doesn’t assume.

7 · Related Publications from the Author

The full line of the author’s own published research on TSP and Job Shop Scheduling, drawn from the Publications page, spans nearly two decades of bee-colony and neural-network approaches to both problems:

Traveling Salesman Problem

Wong, L.P., Low, M.Y.H., Chong, C.S. (2008). “A Bee Colony Optimization Algorithm for Traveling Salesman Problem.” 2nd Asia Modelling Symposium (AMS 2008), 818–823, Kuala Lumpur, Malaysia.
Wong, L.P., Low, M.Y.H., Chong, C.S. (2008). “Bee Colony Optimization with Local Search for Traveling Salesman Problem.” 6th IEEE International Conference on Industrial Informatics (INDIN08), 1019–1025, Daejeon, Korea.
Wong, L.P., Low, M.Y.H., Chong, C.S. (2009). “A Bee Colony Optimization Algorithm with the Fragmentation State Transition Rule for Traveling Salesman Problem.” 4th Virtual International Conference on Intelligent Production Machines and Systems (IPROMS).
Wong, L.P., Low, M.Y.H., Chong, C.S. (2009). “An Efficient Bee Colony Optimization Algorithm for Traveling Salesman Problem using Frequency-based Pruning.” 7th IEEE International Conference on Industrial Informatics (INDIN09), 775–782, Cardiff, UK.
Wong, L.P., Low, M.Y.H., Chong, C.S. (2010). “Bee Colony Optimization with Local Search for Traveling Salesman Problem.” International Journal on Artificial Intelligence Tools, 19(3), 305–334.
Wong, L.P., Low, M.Y.H., Chong, C.S. (2011). “Finding the Shortest Hamiltonian Circuit of Selected Places in Penang Using a Generic Bee Colony Optimization Framework.” International Conference on Bio-Inspired Computing: Theories and Applications (BIC-TA 2011), 51–57, Penang, Malaysia.
Choong, S.S., Wong, L.P., Low, M.Y.H., Chong, C.S. (2020). “A Bee Colony Optimization Algorithm with a Sequential-Pattern-Mining-based Pruning Strategy for the Traveling Salesman Problem.” International Journal of Bio-Inspired Computation, 15(4), 239–253.

Job Shop Scheduling

Chong, C.S., Low, M.Y.H., Sivakumar, A.I., Gay, K.L. (2006). “A Bee Colony Optimization Algorithm to Job Shop Scheduling.” 2006 Winter Simulation Conference, 1954–1961, Monterey, CA.
Chong, C.S., Low, M.Y.H., Sivakumar, A.I., Gay, K.L. (2007). “Using a Bee Colony Algorithm for Neighbourhood Search in Job Shop Scheduling Problems.” 2007 European Conference on Modelling and Simulation, 459–465, Prague, Czech Republic.
Wong, L.P., Puan, C.Y., Low, M.Y.H., Chong, C.S. (2008). “Bee Colony Optimization Algorithm with Big Valley Landscape Exploitation for Job Shop Scheduling Problems.” 2008 Winter Simulation Conference, 2050–2058, Miami, FL.
Wong, L.P., Puan, C.Y., Low, M.Y.H., Chong, C.S., Wong, Y.W. (2010). “Bee Colony Optimisation Algorithm with Big Valley Landscape Exploitation for Job Shop Scheduling Problems.” International Journal of Bio-Inspired Computing, 2(2), 85–99.
Sim, M.H., Low, M.Y.H., Chong, C.S., Shakeri, M. (2020). “Job Shop Scheduling Problem Neural Network Solver with Dispatching Rules.” 2020 International Conference on Industrial Engineering and Engineering Management (IEEM2020), Singapore.
Yang, Z., Liu, F., Zhang, W., Lou, X., Low, M.Y.H., Gan, B.P. (2026). “LLM-Upgraded Graph Reinforcement Learning for Carbon-Aware Job Scheduling in Smart Manufacturing.” 41st ACM/SIGAPP Symposium On Applied Computing, 831–838, Thessaloniki, Greece.

Full author bibliography, including book chapters and the remaining 130+ conference and journal papers spanning simulation, crowd modeling, and manufacturing systems, is available on the Publications page.

None of these three problems has been “solved” in the sense of a fast, exact, general algorithm — and for TSP and Job Shop Scheduling, complexity theory says no such algorithm exists unless P = NP. What they share instead is a body of heuristics, decades deep, that trade a small, usually-acceptable gap from optimal for a massive reduction in compute time. The Knight’s Tour is the outlier that got lucky: enough structure in its specific graph that a two-line greedy rule does the job outright.

Combinatorial Optimization · 2026

✦ This article was assembled with the assistance of Claude by Anthropic ✦

How to Connect Codex to WordPress.com and Post from Termux on Android

Malcolm Low — Thu, 10 Sep 2026 11:49:38 +0000

Originally published on malcolmlow.com.

You can run Codex from an Android terminal and connect it to WordPress.com through the Model Context Protocol (MCP). This guide documents not only the successful setup, but also the connection failures encountered along the way: an incorrect endpoint that returned HTTP 404, an OAuth callback that depended on Termux remaining open, credentials that did not persist into a fresh process, and WordPress sites whose plans or connection states limited the available tools.

The example device is a Samsung Galaxy S26 Ultra, although the workflow applies to other Android phones capable of running a maintained Termux build. The important parts are the Codex CLI, the exact MCP endpoint, a working OAuth credential store, and a deliberate draft-first publishing workflow.

Using Claude instead? See Publishing to WordPress with Claude and the WordPress MCP Connector for the corresponding browser-based Claude workflow, WordPress HTML constraints, and reusable-skill approach.

1 · What You Need

An Android phone with Termux installed from a trusted source such as F-Droid or the official Termux GitHub releases.
Node.js, npm, and Git in Termux.
An OpenAI account and the Codex CLI.
A WordPress.com account with permission to edit the target site.
A WordPress.com site whose plan and MCP settings permit the content tools you need.

Avoid an obsolete Termux package from an unofficial source. MCP availability is also site-specific: one account can contain a usable paid WordPress.com site, a site requiring a plan upgrade, and disconnected Jetpack sites at the same time.

2 · Install Codex in Termux

Update Termux and install the prerequisites:

pkg update
pkg upgrade
pkg install nodejs git

node --version
npm --version

Install and verify Codex, then start it and complete the sign-in flow:

npm install -g @openai/codex
codex --version
codex

Android may open authorization in the default browser. Return to Termux when the browser step completes.

3 · Add the Exact WordPress.com MCP Endpoint

Enable the WordPress.com MCP tools for your account, granting only the capabilities you need. Then register the remote Streamable HTTP server in Termux:

codex mcp add wpcom-mcp --url https://public-api.wordpress.com/wpcom/v2/mcp/v1
codex mcp get wpcom-mcp
codex mcp list

The exact path matters. The working endpoint used in this session was:

https://public-api.wordpress.com/wpcom/v2/mcp/v1

The saved configuration should be enabled, use a Streamable HTTP transport, and contain the complete /wpcom/v2/mcp/v1 path. Codex stores MCP configuration in ~/.codex/config.toml by default.

🔐 Keep Termux running during OAuth, and never paste an access token into a prompt.

Start authentication with codex mcp login wpcom-mcp. The browser redirects to a temporary callback on 127.0.0.1, so the Codex process in Termux must remain alive to receive it.

After approval, start a fresh Codex session and verify the server again. Treat ~/.codex as private configuration and never commit it to a public repository.

4 · Problems Encountered and How to Debug Them

HTTP 404 during MCP initialization. The first failure looked like this:

MCP startup failed
unexpected server response: HTTP 404
when send initialize request

The configured URL was an incomplete WordPress.com API path, not an MCP endpoint:

https://public-api.wordpress.com/wpcom/

Inspect the registration with codex mcp get wpcom-mcp. If it is wrong, replace it cleanly and authenticate again:

codex mcp remove wpcom-mcp
codex mcp add wpcom-mcp --url https://public-api.wordpress.com/wpcom/v2/mcp/v1
codex mcp login wpcom-mcp

Browser approval succeeded, but the next session was unauthenticated. Symptoms included AuthRequired at startup, Auth: Unsupported in the MCP list, or a success message followed by failure in a fresh Codex process. That is a credential-persistence problem, not an endpoint problem.

Android Termux could not reliably store the OAuth token. In this session, the browser-based WordPress authorization completed successfully, but the Android Termux environment could not reliably save the OAuth token in a form that a later Codex process could retrieve. The clearest symptom was try_lock() not supported when Codex attempted to use its file-backed credential store. As a result, a fresh session could return AuthRequired even though the browser had just reported a successful login. This was a local credential-storage limitation, not a WordPress password problem and not an MCP endpoint problem.

Update Codex and retry because this behavior may improve in newer builds. If it remains, do not work around it by copying OAuth tokens into prompts, shell history, or ordinary files. Use a supported desktop Codex environment for the authenticated WordPress action while continuing to research and draft in Termux.

The server is configured but no tools appear. Start a fresh Codex process after configuration, run codex mcp list, and use /mcp inside the Codex terminal UI to inspect active servers. Run codex mcp --help when the installed CLI syntax is uncertain.

The account connects, but a particular site cannot be managed. Enumerate the sites first. In this session, the same account returned a usable WordPress.com site with partial MCP support, another site requiring a paid plan, and several disconnected Jetpack sites. Authentication alone does not guarantee that every site exposes tools.

5 · Ask Codex to Consult Official OpenAI Documentation

When CLI behavior may have changed, prompt Codex to consult the current official documentation instead of relying only on model memory. Name the source, the error, the evidence you want inspected, and the boundary that no configuration should be changed without approval.

The official references for this workflow are the Codex manual and its MCP configuration documentation.

Goal	Example Prompt
Verify setup	“Use current official OpenAI Codex documentation to verify how a Streamable HTTP MCP server and OAuth login should be configured. Cite the exact OpenAI pages you used. Then inspect my `wpcom-mcp` registration without changing it.”
Debug 404	“Debug this Codex MCP initialization error: HTTP 404. First inspect `codex mcp get wpcom-mcp`; compare the transport and URL with current official OpenAI MCP documentation and the service’s official endpoint. Explain the cause before making changes.”
Debug OAuth	“The browser says OAuth succeeded, but a fresh Codex session reports `AuthRequired`. Use official OpenAI Codex documentation, check `codex mcp list` and `/mcp`, distinguish server reachability from credential persistence, and do not ask me to paste a token.”
Collect evidence	“Diagnose this connection layer by layer: saved configuration, endpoint, transport, OAuth callback, stored credential, fresh-session discovery, WordPress site access, and tool permissions. Show the evidence for each conclusion.”

A useful troubleshooting prompt includes four things: the desired outcome, the observed error text, the authoritative sources to consult, and what Codex must not change without confirmation.

6 · Verify the Site Before Creating or Editing Content

Once the connector is working, ask Codex to list the accessible WordPress.com sites before writing anything:

Use the WordPress.com MCP tools to list the sites I can access.
Show each site ID, domain, connection status, and MCP availability.
Do not create or update content.

This session demonstrated why that step matters. The account had multiple sites, but only the intended Techucation site could perform the requested basic content operation. Use the numeric site ID or exact domain in later prompts, especially when similarly named or disconnected sites are present.

7 · Use a Draft-First Workflow

Tell Codex the target site and status explicitly:

Create a new post on malcolmlow.com as a draft.
Do not publish it.
Return the post ID, edit URL, and preview URL.

Before updating an existing draft, have Codex list recent drafts with their IDs and modification times. “The draft article” can be ambiguous when a site contains many drafts. In this session, the newest modified draft was identified as post 3955 before any write operation was attempted.

Publishing and editing are separate actions. A request to improve formatting should preserve status: draft. A request to publish should identify the site and post ID, and Codex should state that the change will make the article public before executing it.

8 · Security and Review Checklist

Install Termux and Codex only from trusted sources.
Never place WordPress passwords, OAuth tokens, or credential files in prompts.
Keep ~/.codex private.
Enable only the WordPress MCP tools you need.
Confirm the exact domain and post ID before a write.
Keep new and revised articles as drafts until reviewed.
Check headings, code blocks, links, categories, tags, featured image, alt text, and mobile layout.
Revoke WordPress.com access if the phone is lost or replaced.
Use Android screen locking and device encryption.

9 · Command Cheat Sheet

# Prepare Termux
pkg update
pkg upgrade
pkg install nodejs git

# Install Codex
npm install -g @openai/codex
codex --version

# Register WordPress.com MCP
codex mcp add wpcom-mcp --url https://public-api.wordpress.com/wpcom/v2/mcp/v1

# Authenticate and inspect
codex mcp login wpcom-mcp
codex mcp get wpcom-mcp
codex mcp list
codex mcp --help

# Start a fresh session
codex

# Inside the Codex TUI
/mcp

Once the connection works, keep the workflow conservative: let Codex research and draft first, create or update the WordPress draft second, review it in the editor, and publish only after the exact site and post have been confirmed.

AI Workflows · 2026

✦ This article was assembled with the assistance of OpenAI Codex and checked against current official Codex documentation ✦

Related AI workflow: This Codex–Termux publishing setup turns a mobile device into an agentic workflow environment. See what agentic workflow means and how AI enhances productivity.

WordPress Guides

Want a complete Codex project? Follow the hands-on Knight’s Tour project with Codex CLI, including scaffolding, tests and diff review.

Homebrew Cask Explained: Install macOS Apps from Terminal

Malcolm Low — Thu, 10 Sep 2026 11:49:35 +0000

Originally published on malcolmlow.com.

Homebrew Cask is a command-line extension of Homebrew, the macOS package manager, that installs, updates, and removes full graphical (GUI) applications, things like Chrome, Slack, or VS Code, using a single terminal command instead of downloading a disk image and dragging an icon into Applications.

Homebrew Cask quick answer: use brew install --cask app-name to install a macOS GUI application from Terminal.

brew search --cask chrome
brew install --cask google-chrome
brew upgrade --cask
brew uninstall --cask google-chrome

macOS users frequently face the challenge of efficiently managing application installations across multiple machines. The traditional approach involves manually downloading disk images, navigating installation wizards, and maintaining applications across systems. Homebrew Cask offers a command-line solution that significantly streamlines this process.

What Is Homebrew Cask?

Homebrew installs command-line tools and libraries, called formulae, while Homebrew Cask installs complete macOS applications with graphical interfaces. For example, brew install wget installs a terminal utility, whereas brew install --cask visual-studio-code installs the Visual Studio Code app in macOS. Cask functionality is built into modern Homebrew, so no separate tap or extension needs to be installed.

The conventional installation workflow requires multiple steps:

Locating the official download source
Downloading the disk image file
Opening and mounting the disk image
Transferring the application to the Applications folder
Ejecting the disk image
Managing the downloaded installer file
Repeating this process for each required application

Homebrew Cask reduces this to a single command:

brew install --cask google-chrome

The application is then installed automatically with no further user interaction required.

Key Advantages for Professional Workflows

1. Accelerated System Provisioning

Organizations and individual users can maintain installation scripts containing all required applications. A typical enterprise development environment setup might include:

brew install --cask visual-studio-code
brew install --cask docker
brew install --cask slack
brew install --cask zoom
brew install --cask rectangle
brew install --cask iterm2
brew install --cask spotify
brew install --cask vlc

This approach reduces new machine setup time from several hours to approximately 15-20 minutes, depending on network bandwidth and the number of applications being installed.

2. Simplified Update Management

Maintaining current software versions is essential for security compliance and feature availability. Run the following command to upgrade outdated Cask-managed applications:

brew upgrade --cask

This upgrades outdated managed casks. Casks marked version :latest or auto_updates true normally require the --greedy option:

brew upgrade --cask --greedy

3. Complete Application Removal

Plain brew uninstall --cask removes the managed application:

brew uninstall --cask docker

To also attempt removal of associated preferences and caches, use --zap:

brew uninstall --cask --zap docker

Use --zap carefully because it may remove files shared with other applications.

4. Automation and Standardization

Homebrew Cask’s command-line interface enables scripting and automation. Development teams can create standardized setup scripts ensuring consistent development environments. IT departments can implement automated workstation provisioning workflows. System configurations can be version-controlled in dotfiles repositories, enabling rapid deployment and rollback capabilities.

Recommended Applications by Category

The following applications represent commonly deployed tools across professional environments:

Development Tools

brew install --cask visual-studio-code
brew install --cask iterm2
brew install --cask docker
brew install --cask postman
brew install --cask dbeaver-community

Productivity Applications

brew install --cask rectangle        # Window management
brew install --cask alfred           # Enhanced search functionality
brew install --cask obsidian         # Knowledge management
brew install --cask notion           # Collaborative workspace

Communication Platforms

brew install --cask slack
brew install --cask zoom
brew install --cask discord

System Utilities

brew install --cask the-unarchiver
brew install --cask appcleaner
brew install --cask vlc

Implementation Guide

Organizations and users without an existing Homebrew installation can deploy it with a single command:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once Homebrew is installed, Cask functionality is built right in. Just start using brew install --cask commands.

Useful Commands to Know

# Search for an app
brew search --cask chrome

# Get information about an app
brew info --cask visual-studio-code

# List all installed cask apps
brew list --cask

# Update all apps
brew upgrade --cask

# Uninstall an app
brew uninstall --cask slack

How to Install Homebrew Casks in ~/Applications

By default, Homebrew Cask installs applications in /Applications. Use --appdir to target the per-user ~/Applications directory instead:

brew install --cask --appdir="$HOME/Applications" visual-studio-code

To use that location by default, set HOMEBREW_CASK_OPTS:

export HOMEBREW_CASK_OPTS="--appdir=${HOME}/Applications"

Add the export command to your shell profile to persist it across terminal sessions.

A Few Gotchas

Cask isn’t perfect. Here are some things to be aware of:

Not every app is available – Popular apps are well-covered, but niche or very new applications might not be in the repository yet
App Store apps aren’t included – Apps distributed exclusively through the Mac App Store can’t be installed via Cask
Some apps require manual steps – Occasionally, an app needs additional configuration or permissions that Cask can’t automate
Updates might lag slightly – Cask maintainers need to update formulas when new versions release, so there can be a brief delay

These are minor inconveniences compared to the time saved.

Frequently Asked Questions

What is a cask in Homebrew?

A “cask” is Homebrew’s term for a pre-packaged macOS GUI application, as opposed to a “formula,” which is Homebrew’s term for a command-line tool or library. When you run brew install --cask app-name, Homebrew downloads the official installer for that app and places it in Applications automatically, skipping the manual disk-image and drag-and-drop steps entirely.

What is the difference between Homebrew and Homebrew Cask?

Homebrew installs command-line tools and libraries (things like git or wget). Homebrew Cask is the same package manager extended to install full graphical applications (things like Chrome or Slack). Since 2018 they’ve shipped as a single unified brew command — you don’t need to install Cask separately, just add the --cask flag.

Is Homebrew Cask free?

Yes. Homebrew and Homebrew Cask are both free, open-source projects. There’s no cost to install or use them — you’re simply automating the download of each app’s own installer, which may itself be free or paid depending on the app.

How do I install an app with Homebrew Cask?

Run brew install --cask app-name in Terminal, replacing app-name with the app’s Cask identifier (for example, brew install --cask visual-studio-code). Use brew search --cask keyword first if you’re not sure of the exact name.

The Bottom Line

Homebrew Cask has fundamentally changed how I interact with my Mac. What started as a way to avoid repetitive downloads has become an essential part of my workflow. The ability to script, automate, and version-control my application setup means I’m never more than a few commands away from a productive environment.

If you spend any significant time on macOS, especially as a developer or power user, Homebrew Cask is worth learning. Your future self—the one setting up that next new machine—will thank you.

Try It Yourself

Pick three applications you use regularly and install them via Cask. I bet you’ll be hooked by the simplicity. Start with something like:

brew install --cask visual-studio-code
brew install --cask google-chrome  
brew install --cask rectangle

Welcome to a more efficient way of managing your Mac applications.

What’s your favorite Homebrew Cask application? Have you automated your Mac setup? Share your experiences in the comments below!

Try a Cask-managed Mac utility: Marta is a free dual-pane file manager for macOS, and it installs with brew install --cask marta.

Quantum Computing: A Complete Learning Path

Malcolm Low — Wed, 19 Aug 2026 16:05:49 +0000

QUANTUM SERIES 2026 — The complete learning path, from a single qubit to Grover's algorithm.

This is the index to the Techucation Quantum Series: a sequence of hands-on posts that build quantum computing from the ground up. Each one stands on its own, but together they form a single arc, from what a qubit actually is, through the rules that make quantum mechanics strange, to the algorithms that turn those rules into a real speedup. The order below is a learning path from first principles to algorithms, not the order the posts were written.

New to the topic? Read top to bottom. Already comfortable with qubits and gates? Skip ahead to the algorithms in Section 4.

0 · Foundational Pre-reading: The Math Behind the Phase

Euler's Formula: Why e^(iφ) Is Just Shorthand for a Circle
Optional warm-up before the qubit posts: the complex plane, i as a 90° rotation, and why the phase factor e^(iφ) traces a circle.

1 · Start Here: Qubits and Superposition

Quantum Computing From First Principles: Qubits, Hadamard Gates & Why H^2 = I
First principles: what a qubit is, how the Hadamard gate builds superposition, and why tensor products scale the state space.

2 · The Hadamard Toolkit

The Quantum Fourier Transform of a Single Qubit is the Hadamard Transform
The one-qubit QFT turns out to be exactly the Hadamard gate, a small result that anchors the bigger picture.

The Walsh-Hadamard Matrix: Backbone of Grover's Diffusion Operator
How the Hadamard sign table generalises to n qubits and powers Grover's diffusion step.

3 · The Rules of the Quantum World

Reversible Computation in Quantum Computing
Why every quantum gate must be reversible, and how ancilla bits turn irreversible logic into unitary logic.

The Cost of Garbage in Quantum Computing
Leftover junk qubits destroy interference; uncomputation cleans them up to protect the speedup.

The No-Cloning Theorem: Why You Cannot Copy a Qubit
A short proof that an unknown quantum state cannot be duplicated, and what that impossibility makes possible.

Quantum Teleportation, and Why It Is Not Cloning
Moving an unknown qubit from one place to another without ever copying it, using entanglement and two classical bits.

4 · Algorithms

Understanding Phase Kickback
The mechanism where the target qubit flips the control's phase, the trick underneath Deutsch's, Grover's, and Shor's.

Deutsch's Algorithm: The Four Cases
The four one-bit Boolean functions, the reversible oracle, and the single query that beats the classical two.

Deutsch Revisited: Quantum vs Classical in Qiskit
The same algorithm in running Qiskit code: two classical queries against one quantum query.

Grover's Algorithm: Inversion About the Mean
A full three-qubit walkthrough of the oracle and the amplitude amplification that surfaces the marked item.

5 · Entanglement and Bell's Inequality

The CHSH Game Simulator and Bell's Inequality
An interactive game where quantum entanglement beats the classical 75 percent ceiling and violates Bell's inequality.

Quantum Series 2026 · Built with Qiskit 1.x

Mac Mini M4 vs Mac Studio for Local LLMs: AI Benchmarks

Malcolm Low — Thu, 06 Aug 2026 02:48:52 +0000

Mac Mini M4 vs Mac Studio for Local LLMs

Which Mac is the better local-LLM workstation? The answer depends on model size, memory and whether sustained throughput matters more than price. My hands-on comparison covers the Mac Mini M4 and Mac Studio across 1B, 8B and 14B models.

Quick answer

The Mac Mini M4 is the value choice for smaller models and occasional experiments. Mac Studio pulls ahead for larger models, longer contexts and repeated generation, where its higher memory bandwidth and sustained cooling help.

What I measured

I compared generation speed, time to first token and prompt processing on representative 1B, 8B and 14B local models. Treat the results as workload-specific: quantisation, context length and backend settings can change the ranking.

Choosing between them

Choose the Mini when low cost, low power and a compact desk setup are priorities. Choose the Studio when local inference is a daily workload, larger models must stay in memory, or you need steadier performance over long sessions.

Read the full benchmark methodology and results on the canonical Mac Mini M4 vs Mac Studio article.

How to Connect Claude to the dev.to API and Build a Reusable Skill

Malcolm Low — Sun, 26 Jul 2026 08:49:17 +0000

MCP (Model Context Protocol) connectors extend Claude's reach into external services, but connector coverage is uneven across platforms. dev.to is one such gap: no MCP connector currently supports writing to it. This post documents the workaround — calling dev.to's REST API directly, converting that workflow into a reusable Claude skill, and the reasoning behind keeping the API key out of that skill entirely.

1. The Gap: No MCP Connector for dev.to Writes

Claude connects to external services through MCP (Model Context Protocol) connectors — Gmail, Google Drive, Shopify, and so on. A community-built dev-to-mcp server exists, but it only wraps dev.to's public API: get_articles, get_article, get_user, get_tags, get_comments, search_articles. Read-only, by design — the author explicitly left out the authenticated write endpoints to keep the initial release simple.

The existence of an MCP server for a service doesn't mean everything that service's API can do is exposed through it. That distinction matters when planning any AI-agent integration against a third-party platform.

2. The Workaround: dev.to's Real REST API

dev.to has had a full authenticated REST API for years — create, read, update, delete articles, plus follower and notification endpoints. It's a plain API, not an MCP tool, which means using it requires a general-purpose way to make HTTP calls: a sandboxed environment with network access and a shell. The complete reference — every endpoint, required headers, and response schema — is published at developers.forem.com/api/v1. This is the page an AI agent (or a person) should read directly before writing any integration code against it, rather than relying on prior training knowledge of the API shape.

The workflow reduces to three plain HTTP calls:

1. GET  /api/articles/:username/:slug   → find the numeric article ID
2. GET  /api/articles/:username/:slug   → pull body_markdown to edit locally
3. PUT  /api/articles/:id  (with api-key header)  → push the new title, tags, body

The raw markdown is fetched, edited with standard text-replacement, and pushed back with a signed request. The published URL and slug remain unchanged after a title edit, so existing links continue to resolve correctly.

3. Turning It Into a Reusable Skill

Claude supports "skills" — markdown files that document a workflow so it doesn't need to rediscover the same steps in a future session. The dev.to workflow above was written up as a SKILL.md covering the exact curl patterns, a link to the official API reference, the tag-format constraints (max four tags, alphanumeric only), and the note that a PUT only changes the fields explicitly sent.

That file sits alongside similar skills built for a Shopify cross-listing workflow and a WordPress publishing workflow — each one converting a one-off problem-solving session into something reusable, rather than re-explaining the same constraints each time.

🔐 The rule that mattered more than any of the code: the API key never went into the skill file.

Skill files persist. They are read back into context automatically in every future conversation, on any device, indefinitely. A live credential sitting in one is a standing liability — no expiry, no encryption, no audit trail, and no way to verify later who or what might have accessed it. The skill therefore documents where to obtain the key and includes a reminder to request it fresh each session, but the value itself is never written down. It is used for the curl calls in a single conversation, then discarded.

The key is generated at dev.to → Settings → Extensions, under the "DEV API Keys" section near the bottom of that page.

4. Applying This Pattern Elsewhere

This pattern is not dev.to-specific. It applies to any service where an MCP connector doesn't yet exist, or only covers part of the API:

Check whether the service has a plain REST API, even without an MCP wrapper — most established platforms do.
Have Claude write the skill file after the problem has been solved once, so it captures the real constraints (rate limits, required headers, field-naming quirks) rather than a guess.
Keep secrets out of anything durable. If a workflow needs a credential, the skill should describe how to obtain one and where to provide it — never store the value itself.
State the no-storage requirement explicitly when asking for a skill to be created, since the entire purpose of a skill is to outlive the conversation.

5. Example Prompts for Each Step

The steps above map directly onto plain-language requests. These are the actual prompts that drive each stage of the workflow:

Step	Example Prompt
Check what's possible	"Check your connectors and skills — can you update a post on dev.to?"
Set up (first time)	"Look up the API docs at developers.forem.com/api/v1, figure out how to update a dev.to article, then store what you learn into a skill — don't save the API key in it."
Connect (each session)	"Use the dev.to skill to update this post: [url]" — Claude should then ask for the API key and remind you it's generated at dev.to → Settings → Extensions.
Look up an article	"Look up this dev.to article and tell me its current title, tags, and ID: [url]"
Create a new post	"Publish a new dev.to post titled '[title]' with this content: [markdown], tagged [tag1, tag2, tag3]."
Update an existing post	"Update my dev.to post at [url] — change the title to '[new title]' and add the tag [tag]."
Sync with a source article	"This dev.to post is a cross-post of [source URL]. Update it to match the current version."

Each prompt is a plain description of the desired outcome, not a set of technical instructions — the skill file supplies the mechanics (endpoints, headers, field constraints) so the request itself can stay short.

Quantum Teleportation, and Why It Isn't Cloning

Malcolm Low — Wed, 24 Jun 2026 11:04:09 +0000

Part of the Techucation Quantum Series.

Teleportation is the most over-sold word in quantum computing. It conjures Star Trek transporters and faster-than-light messaging, and almost every popular account quietly implies you end up with a copy of the original. You do not. Quantum teleportation moves an unknown quantum state from one qubit to another while destroying the original, and that destruction is not an incidental detail. It is the mechanism that keeps the protocol on the right side of the no-cloning theorem.

A quick word on no-cloning

This whole protocol is haunted by the no-cloning theorem: there is no operation that copies an arbitrary unknown quantum state. I worked through the proof and its consequences in a recent post, The No-Cloning Theorem in Quantum Computing: Why You Can't Copy a Qubit, so I won't re-derive it here.

The single fact we need: you cannot deterministically duplicate an unknown qubit. The qualifiers matter, because teleportation lives in the gaps between them. The theorem forbids copying unknown states (a known state you can re-prepare at will), it forbids deterministic, perfect copies, and it is a statement about unitary operations — and measurement, which teleportation leans on at the decisive moment, is not unitary.

Why teleportation isn't cloning

The distinction in one sentence: cloning would leave |ψ⟩ in two places; teleportation leaves it in exactly one.

Partway through the protocol, Alice's message qubit is measured. Measurement collapses it into a classical basis state — a plain |0⟩ or |1⟩ carrying none of the original amplitudes. By the time Bob's qubit holds |ψ⟩, Alice's qubit demonstrably does not. The state was relocated, and the accounting is exact: one copy in, one copy out. No moment ever exists where two qubits both carry |ψ⟩, so there is nothing for the no-cloning theorem to object to.

This also kills the faster-than-light fantasy. The protocol forces Alice to send Bob two ordinary classical bits. Until they arrive, Bob's qubit is information-free — we will see that fall out of the algebra below.

The complete circuit

Read it left to right; the protocol splits into three stages. The message qubit q0 starts in the unknown state |ψ⟩, while q1 and q2 both start in |0⟩. In the diagram, * marks a control and (+) a CNOT target.

Stage 1 — Bell pair. Alice and Bob share an entangled pair: an H on q1 followed by a CNOT from q1 onto q2 prepares (|00⟩ + |11⟩)/√2 across the two halves.

Stage 2 — Alice measures. Alice folds her message into the pair (a CNOT from q0 onto q1, then an H on q0) and measures both of her qubits, collapsing them to two classical bits.

Stage 3 — Bob corrects. Depending on those two bits, Bob applies an X and/or a Z to q2 — the X controlled by Alice's q1 bit, the Z by her q0 bit — and q2 emerges as |ψ⟩.

The protocol in bra-ket and tensor form

Three qubits: q0 carries |ψ⟩ = α|0⟩ + β|1⟩, q1 is Alice's half of the Bell pair, and q2 is Bob's half. They pre-share |Φ+⟩ = (|00⟩ + |11⟩)/√2 on q1 q2.

Step 1 — the starting state. Tensor the message against the Bell pair:

|ψ⟩ = α|0⟩ + β|1⟩            (the unknown message on q0)

|ψ⟩ ⊗ |Φ+⟩ = (α|0⟩ + β|1⟩) ⊗ (|00⟩ + |11⟩)/√2
           = (1/√2) [ α|000⟩ + α|011⟩ + β|100⟩ + β|111⟩ ]

Step 2 — Alice's CNOT (control q0, target q1):

CNOT (control q0, target q1)  flips q1 wherever q0 = 1:

= (1/√2) [ α|000⟩ + α|011⟩ + β|110⟩ + β|101⟩ ]

Step 3 — Alice's Hadamard on q0. Substitute |0⟩ → (|0⟩+|1⟩)/√2 and |1⟩ → (|0⟩−|1⟩)/√2, then collect by the value of (q0 q1):

H on q0, then collect by the pair Alice will measure (q0 q1):

= (1/2) [ |00⟩ (α|0⟩ + β|1⟩)    ← case A
        + |01⟩ (α|1⟩ + β|0⟩)    ← case B
        + |10⟩ (α|0⟩ − β|1⟩)    ← case C
        + |11⟩ (α|1⟩ − β|0⟩) ]  ← case D

Each bracketed q2 state is the original |ψ⟩ acted on by a known Pauli. Alice measures, gets one of four outcomes (each with probability 1/4), sends the two bits to Bob, and Bob undoes the Pauli. The Case column ties each row back to the matching line in Step 3:

 Case | Alice measures (q0 q1) | Bob holds on q2 | Relation to |ψ⟩ | Bob applies 
------+------------------------+-----------------+-----------------+-------------
 A    | 00                     | α|0⟩ + β|1⟩     | I |ψ⟩           | nothing     
 B    | 01                     | α|1⟩ + β|0⟩     | X |ψ⟩           | X           
 C    | 10                     | α|0⟩ − β|1⟩     | Z |ψ⟩           | Z           
 D    | 11                     | α|1⟩ − β|0⟩     | ZX |ψ⟩          | X then Z

Bob applies Z^m0 X^m1 — an X if m1 = 1, then a Z if m0 = 1 — and every branch lands back on α|0⟩ + β|1⟩ = |ψ⟩.

Qiskit — classical feed-forward

This version measures mid-circuit and uses real classical conditioning via if_test. The verification trick: rather than read out Bob's state, apply the inverse of the preparation to q2. If teleportation worked, that must collapse q2 to |0⟩ on every shot.

import numpy as np
from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister, transpile
from qiskit.circuit.library import StatePreparation
from qiskit.quantum_info import random_statevector
from qiskit_aer import AerSimulator

# Unknown state to teleport (StatePreparation is unitary -> invertible)
psi  = random_statevector(2)
prep = StatePreparation(psi)

q   = QuantumRegister(3, "q")     # q0 message, q1 Alice, q2 Bob
mz  = ClassicalRegister(1, "mz")  # q0 result -> drives Z
mx  = ClassicalRegister(1, "mx")  # q1 result -> drives X
out = ClassicalRegister(1, "out") # verification bit
qc  = QuantumCircuit(q, mz, mx, out)

qc.append(prep, [0]); qc.barrier()        # 1. load |ψ⟩ onto q0
qc.h(1); qc.cx(1, 2); qc.barrier()        # 2. Bell pair on (q1,q2)
qc.cx(0, 1); qc.h(0)                      # 3. Alice's basis change
qc.measure(0, mz); qc.measure(1, mx); qc.barrier()

with qc.if_test((mx, 1)):                 # 4. Bob's corrections
    qc.x(2)
with qc.if_test((mz, 1)):
    qc.z(2)
qc.barrier()

qc.append(prep.inverse(), [2])            # 5. un-prepare on Bob: must read 0
qc.measure(2, out)

counts = AerSimulator().run(transpile(qc, AerSimulator()), shots=4000).result().get_counts()
clean  = all(k.split()[0] == "0" for k in counts)   # leftmost bit = out
print(counts); print("Teleportation verified:", clean)

The out bit comes back 0 on 100% of shots regardless of the random (mx, mz) branch — exactly the claim that Bob reconstructs |ψ⟩ in every case.

No faster-than-light, and the takeaway

Before Bob learns (m0, m1), his qubit is an equal mixture of the four branch states. Averaging the four projectors gives the Pauli twirl:

ρ_Bob = (1/4)( |ψ⟩⟨ψ| + X|ψ⟩⟨ψ|X
              + Z|ψ⟩⟨ψ|Z + XZ|ψ⟩⟨ψ|ZX )  =  I/2   for every |ψ⟩

for any |ψ⟩. Bob's local state is identical no matter what Alice sent, so no information has reached him yet. The classical bits are not a formality — they are the only thing that carries the state across, and they travel no faster than light.

Takeaway. No-cloning forbids duplicating an unknown qubit (proof here). Teleportation never attempts a copy: it entangles the message with a shared Bell pair, measures the original out of existence, and ships two classical bits naming which of four Pauli corrections rebuilds the state on the other end. Exactly one copy before, exactly one after. No-cloning is not a bug the protocol works around — it is the reason the protocol has to look the way it does.

Originally published at malcolmlow.com. Built with Qiskit. This article was written with the assistance of Claude by Anthropic.

Move Your WordPress.com Domain to Cloudflare and Halve the Renewal

Malcolm Low — Thu, 11 Jun 2026 04:33:59 +0000

This post was originally published on Techucation, my blog at malcolmlow.com. Cross-posted here for the dev.to community.

My WordPress.com domain renewal notice came in at £16/year, with auto-renew switched off and the expiry only a couple of days away. That is a fine price for convenience, but the same name sits on Cloudflare Registrar at wholesale cost with no markup. This post walks through the move end to end, including the one step that quietly breaks things if you rush it, and lays out the real cost difference.

The short version: you do not "renew at Cloudflare". You transfer the domain to Cloudflare, which extends the registration by a year in the process. The saving is real, but the order of operations matters.

1. The cost case

Cloudflare Registrar charges exactly what the registry charges them, with zero markup, and bundles WHOIS privacy for free. Retail registrars add a margin on top. For a .net the difference looks like this:

Item	WordPress.com	Cloudflare Registrar
.net renewal (1 yr)	£16 (approx US$20)	approx US$10.44 (at cost)
Markup	Retail margin	None (wholesale pass-through)
WHOIS privacy	Included	Included, free
Approx 5-year cost	approx US$100	approx US$52

Figures are indicative for mid-2026. Because Cloudflare is at cost, your renewal tracks the registry wholesale rate, so it moves up if the registry (Verisign for .net) raises prices. The trade-off: Cloudflare requires the domain to run on Cloudflare DNS.

2. The gotcha: transfer, not renew, and DNS moves first

Two things trip people up:

You cannot renew a domain at a registrar where it is not registered. To get Cloudflare pricing you transfer the domain in. A gTLD transfer (.com, .net, .org) automatically adds one year, so it replaces the renewal rather than stacking on top of it.

Cloudflare will not let you transfer the registration until the domain is already running on Cloudflare DNS. So the real sequence is DNS first, registrar second, with any redirect rebuilt in the middle so the site never goes dark.

Mind the expiry window. Do not start this within a few days of expiry and then walk away. A transfer left to auto-complete can take up to 5 days. If you are close to the date, expedite it (see step 6) rather than waiting out the clock.

3. Step by step

The full order of operations:

1  Unlock the domain at WordPress.com, get the EPP / auth code
2  Add the domain as a Free zone in Cloudflare
3  Stage the redirect in Cloudflare (before flipping nameservers)
4  Change nameservers at WordPress.com to Cloudflare's pair
5  Wait for the Cloudflare zone to go Active
6  Initiate the transfer in Cloudflare, paste the EPP code, pay
7  Approve / expedite the transfer on the WordPress.com side
8  Verify: registrar, new expiry, redirect, DNSSEC

Step 1. In WordPress.com under Upgrades > Domains, open the domain, turn off Transfer lock, then start the transfer-out flow far enough to reveal the EPP / auth code. Copy it. Do not let WordPress walk you all the way through its own wizard, you only want the code.

Step 2. In the Cloudflare dashboard, Add a domain, choose the Free plan. Cloudflare scans existing DNS and assigns you two nameservers like name.ns.cloudflare.com. Note them.

Step 3. If the domain is a redirect (common when it just points at another site of yours), rebuild that redirect in Cloudflare now while it sits idle. See section 4.

Step 4. Back at WordPress.com, switch the nameservers from WordPress to the two Cloudflare nameservers.

Step 5. Cloudflare flips the zone to Active once it sees the nameserver change, usually under an hour. The transfer option stays greyed out until then.

Step 6. Once Active, go to Domain Registration > Transfer Domains, select the domain, paste the EPP code, and pay the at-cost fee. This payment includes the added year.

Step 7. Watch for the confirmation from the losing registrar. WordPress.com surfaces a Transfer Management page with an Accept Transfer button. Clicking it skips the 5-day wait and completes the transfer in minutes.

Done: the registry should now show the registrar as Cloudflare, status Active, and the expiry rolled forward by a year.

4. The redirect-only trap

If your domain only exists to redirect to another site, the imported records (the host's A records and a couple of CNAMEs) become redundant once you build a Cloudflare Redirect Rule. Tempting to delete them all for a tidy zone. Here is the trap:

A Cloudflare Redirect Rule only fires on traffic that reaches Cloudflare's edge. Traffic only reaches the edge if the hostname resolves to a proxied record (orange cloud). Delete every record and the name resolves to nothing, so the redirect goes dark.

The fix is to keep one proxied placeholder for the rule to attach to:

Type	Name	Value	Proxy
A	@	192.0.2.1	Proxied
CNAME	www	@	Proxied (only if you want www)
TXT	@	"google-site-verification=..."	DNS only

192.0.2.1 is a reserved TEST-NET address that never routes anywhere, which is exactly what you want: the proxy intercepts the request before that IP is ever used. Then a single Redirect Rule (Rules > Redirect Rules) handles the rest:

Field	Setting
When (match)	hostname ends with example.net
Then (action)	301 to https://example.com + path
Preserve query string	On

Keep the TXT verification record as DNS only. It does not need to resolve to anything, it just needs to exist.

5. After the transfer

Three things to settle once the registrar shows Cloudflare:

Auto-renew. Optional, but turning it on (Domain Registration > your domain) means you never repeat the two-days-from-expiry scramble. If you leave it off, set yourself a reminder a few weeks before the date.

DNSSEC. Worth enabling for the added integrity protection. Because Cloudflare is now both your DNS and your registrar, the DS record is published to the registry automatically, so it activates without you touching the registrar by hand. Give it from a few minutes up to a couple of hours to show as signed at the registry.

Registrar lock. On by default at Cloudflare, so that one is already handled.

One caution with DNSSEC: once the DS record is published, do not move nameservers away from Cloudflare or disable DNSSEC out of order. Breaking the signature chain is the classic way to make a domain go dark, because validating resolvers will reject it. As long as DNS stays on Cloudflare, you are fine.

Net result

Same domain, half the renewal cost, a year added, and the registrar consolidated with your DNS. The only part that needs care is the DNS-first ordering and not over-deleting the redirect records. Everything else is a few clicks and a short wait.

Deutsch Algorithm Revisited: Quantum vs Classical Implementation in Qiskit

Malcolm Low — Sun, 07 Jun 2026 10:12:11 +0000

In the previous post on the Deutsch algorithm, we covered the theory. Here we implement both the classical and quantum approaches in Qiskit so the quantum advantage is visible in working code: the same problem solved with fewer oracle queries than any classical method can manage.

The Challenge

Given a black-box function f: {0,1} → {0,1}, determine whether it is:

Constant: f(0) = f(1) (always returns 0, or always returns 1)
Balanced: f(0) ≠ f(1) (returns 0 for one input, 1 for the other)

The whole question is how many times you must query the function:

Approach	Queries required
Classical	2
Quantum	1

Complete Qiskit Implementation

Oracle functions

First, build the oracle functions representing all possible single-bit Boolean functions:

from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister
from qiskit_aer import AerSimulator

def create_constant_oracle(constant_value):
    """Creates a constant oracle (returns 0 or 1 for all inputs)"""
    oracle = QuantumCircuit(2, name=f"Constant_{constant_value}")
    if constant_value == 1:
        oracle.x(1)  # Flip the output qubit
    return oracle

def create_balanced_oracle(balance_type):
    """Creates a balanced oracle"""
    oracle = QuantumCircuit(2, name=f"Balanced_{balance_type}")
    if balance_type == 'identity':
        # f(x) = x
        oracle.cx(0, 1)
    elif balance_type == 'negation':
        # f(x) = NOT x
        oracle.x(0)
        oracle.cx(0, 1)
        oracle.x(0)
    return oracle

Classical approach: two queries required

The classical algorithm must query the oracle twice, once for f(0) and once for f(1):

def classical_deutsch_query1(oracle):
    """First query: Evaluate f(0)"""
    qr = QuantumRegister(2, 'q')
    cr = ClassicalRegister(1, 'c')
    qc = QuantumCircuit(qr, cr)

    # Input: x = 0 (already initialized to |0>)
    qc.barrier()
    qc.compose(oracle, inplace=True)
    qc.barrier()
    qc.measure(1, 0)  # Measure output to get f(0)

    return qc

def classical_deutsch_query2(oracle):
    """Second query: Evaluate f(1)"""
    qr = QuantumRegister(2, 'q')
    cr = ClassicalRegister(1, 'c')
    qc = QuantumCircuit(qr, cr)

    qc.x(0)  # Input: x = 1
    qc.barrier()
    qc.compose(oracle, inplace=True)
    qc.barrier()
    qc.measure(1, 0)  # Measure output to get f(1)

    return qc

Quantum approach: one query suffices

The quantum Deutsch algorithm uses superposition and interference to answer with a single oracle query:

def deutsch_algorithm(oracle):
    """Implements the Deutsch algorithm - requires only ONE query"""
    qr = QuantumRegister(2, 'q')
    cr = ClassicalRegister(1, 'c')
    qc = QuantumCircuit(qr, cr)

    # Step 1: Initialize q[1] to |1>
    qc.x(1)
    qc.barrier()

    # Step 2: Apply Hadamard gates (create superposition)
    qc.h(0)
    qc.h(1)
    qc.barrier()

    # Step 3: Apply the oracle (SINGLE QUERY!)
    qc.compose(oracle, inplace=True)
    qc.barrier()

    # Step 4: Apply Hadamard to input qubit
    qc.h(0)
    qc.barrier()

    # Step 5: Measure
    qc.measure(0, 0)

    return qc

Running the comparison

Now test all four possible oracles with both approaches:

oracles = [
    ("Constant 0", create_constant_oracle(0)),
    ("Constant 1", create_constant_oracle(1)),
    ("Balanced (Identity)", create_balanced_oracle('identity')),
    ("Balanced (Negation)", create_balanced_oracle('negation'))
]

simulator = AerSimulator()

for name, oracle in oracles:
    # Classical: 2 queries
    qc1 = classical_deutsch_query1(oracle)
    result1 = simulator.run(qc1, shots=1).result()
    f_0 = int(list(result1.get_counts().keys())[0])

    qc2 = classical_deutsch_query2(oracle)
    result2 = simulator.run(qc2, shots=1).result()
    f_1 = int(list(result2.get_counts().keys())[0])

    classical_result = "CONSTANT" if f_0 == f_1 else "BALANCED"

    # Quantum: 1 query
    qc_quantum = deutsch_algorithm(oracle)
    result_quantum = simulator.run(qc_quantum, shots=1000).result()
    counts = result_quantum.get_counts()

    quantum_result = "CONSTANT" if '0' in counts else "BALANCED"

    print(f"{name}: Classical={classical_result}, Quantum={quantum_result}")

Circuit Diagrams

The full figures are rendered in the original post; the structure of each is:

Classical Query 1, f(0): q[0] stays in |0⟩, the oracle processes the input, and q[1] is measured to read f(0).
Classical Query 2, f(1): an X gate flips q[0] to |1⟩, the oracle processes it, and q[1] is measured to read f(1).
Quantum Deutsch (single query): initialise |01⟩, Hadamards on both wires create superposition, a single oracle query, a final Hadamard on q[0], then measure q[0].

The key structural difference: the classical circuits measure the output qubit q[1] to read function values, while the quantum circuit measures the input qubit q[0] after interference. That is what lets a single query reveal a global property of the function.

Sample Output

======================================================================
Testing: Constant 0 Oracle
======================================================================

[CLASSICAL APPROACH - Requires 2 queries]
  Query 1: f(0) = 0
  Query 2: f(1) = 0
  Result: Function is CONSTANT
  Total queries needed: 2

[QUANTUM APPROACH - Requires only 1 query]
  Measurement results: {'0': 1000}
  Result: Function is CONSTANT
  Total queries needed: 1

  Both methods agree: True

======================================================================
Testing: Balanced (Identity) Oracle
======================================================================

[CLASSICAL APPROACH - Requires 2 queries]
  Query 1: f(0) = 0
  Query 2: f(1) = 1
  Result: Function is BALANCED
  Total queries needed: 2

[QUANTUM APPROACH - Requires only 1 query]
  Measurement results: {'1': 1000}
  Result: Function is BALANCED
  Total queries needed: 1

  Both methods agree: True

Understanding the Quantum Advantage

Classical approach: evaluate f(0), evaluate f(1), compare the two results. Two queries required; you must check both inputs individually.

Quantum approach: query with a superposition of both inputs, use interference to extract the global property, then measure. One query required; it exploits quantum parallelism.

The quantum algorithm queries the oracle with a superposition of both inputs simultaneously (|0⟩ + |1⟩), then uses interference to extract a global property of the function without evaluating it on individual inputs. The single measurement directly tells you whether the function is constant or balanced.

Measurement Interpretation

Measurement	Function type	Explanation
\|0⟩	Constant	Constructive interference, f(0) ⊕ f(1) = 0
\|1⟩	Balanced	Destructive interference, f(0) ⊕ f(1) = 1

Running the Code

Install Qiskit and Aer:

pip install qiskit qiskit-aer

Then run the comparison script; it outputs the result for all four oracle types.

Conclusion

This implementation shows the Deutsch advantage concretely: a 2x reduction in oracle queries (from 2 to 1), the first algorithm to demonstrate quantum advantage over classical, and a foundational technique introducing superposition, interference, and phase kickback. The speedup is modest for this toy problem, but the same idea (query with superposition, extract a global property through interference) scales up to Deutsch-Jozsa, Simon's algorithm, and Shor's factoring.

Part of the Quantum Series 2026. Originally published on Techucation.

Deutsch's Algorithm in Quantum Computing: The 4 Cases

Malcolm Low — Sun, 07 Jun 2026 10:11:35 +0000

Deutsch's Algorithm determines whether a function f(x) is constant or balanced using only a single query. Before getting to the quantum circuit, it helps to see how the four possible single-bit functions are physically built.

The 4 Possible Functions

With one input bit, there are exactly four Boolean functions. Two are constant (the output ignores the input) and two are balanced (the output depends on the input). In each oracle the bottom input is set to 0 so the output wire carries exactly f(x).

#	Name	Function	Type
1	Constant Zero	f(x) = 0	Constant (identity, no gates)
2	Constant One	f(x) = 1	Constant (X on the output wire)
3	Balanced ID	f(x) = x	Balanced (CNOT)
4	Balanced NOT	f(x) = ¬x	Balanced (X, CNOT, X)

The General Oracle (U_f)

Every oracle is wrapped in the standard reversible form. It leaves the input register alone and XORs f(x) into the output register:

U_f |x⟩|y⟩  =  |x⟩ |y ⊕ f(x)⟩

The Complete Circuit

To detect the function type in one shot, initialise the bottom wire to |1⟩ and use Hadamard gates to build superposition on both wires before and after the oracle:

|0⟩ ──[H]──╤═════╤──[H]──[M]
           │ U_f │
|1⟩ ──[H]──╧═════╧───────────

The top wire is the control, the bottom wire is the target prepared in |−⟩. The oracle's (−1)^f(x) phase is kicked back onto the top wire, and the final Hadamard converts that phase difference into a measurable 0 or 1.

Mathematical Proof

1. Initialisation:   |ψ₀⟩ = |0⟩|1⟩

2. Superposition:    |ψ₁⟩ = |+⟩|−⟩ = ½(|0⟩ + |1⟩)(|0⟩ − |1⟩)

3. The kickback:     U_f |x⟩|−⟩ = (−1)^f(x) |x⟩|−⟩
                     the function output is pushed into the phase of the top qubit.

4. Global state:     |ψ₂⟩ = (1/√2) [ (−1)^f(0)|0⟩ + (−1)^f(1)|1⟩ ] ⊗ |−⟩

Final Measurement

After the last Hadamard on the top qubit, the relative phase between the two terms decides the outcome:

If f(0) = f(1) (constant) the top qubit collapses to ±|+⟩, so the final H gives measure 0.
If f(0) ≠ f(1) (balanced) it collapses to ±|−⟩, so the final H gives measure 1.

A single oracle query distinguishes constant from balanced, where any classical approach needs two. That one-query advantage is the seed of Deutsch-Jozsa, Simon's, and ultimately Shor's algorithm.

Part of the Quantum Series 2026. Originally published on Techucation, where the circuit diagrams are rendered in full.

Understanding Phase Kickback in Quantum Computing

Malcolm Low — Sun, 07 Jun 2026 10:08:40 +0000

In standard classical logic, a control bit dictates what happens to a target. In quantum mechanics the relationship is symmetric. When the target qubit is in an eigenstate of the gate operator, the eigenvalue phase is kicked back onto the control qubit, leaving the target unchanged while flipping the relative phase of the control. This post derives that result from first principles using the CNOT gate on |+⟩ ⊗ |−⟩.

1 · The CNOT Circuit and the Kickback Setup

The circuit places the control qubit in superposition |+⟩ and the target qubit in |−⟩. Since |−⟩ is an eigenstate of X with eigenvalue −1, the kickback occurs.

control:
|+⟩
|−⟩
target:
|−⟩
+
|−⟩

Key observation: The target qubit is unchanged after the CNOT. The control qubit flips from |+⟩ to |−⟩. The phase was kicked back to the control, not forward to the target.

2 · Full Derivation: |+⟩ ⊗ |−⟩ through CNOT

Step 1 — Define the initial state

|ψ₀⟩ = |+⟩ ⊗ |−⟩
= (1/√2)(|0⟩ + |1⟩) ⊗ (1/√2)(|0⟩ − |1⟩)

Step 2 — Expand the tensor product

|ψ₀⟩ = (1/2)[ |00⟩ − |01⟩ + |10⟩ − |11⟩ ]

Step 3 — Apply the CNOT gate

|ψ₁⟩ = (1/2)[ |00⟩ − |01⟩ + |11⟩ − |10⟩ ]

Step 4 — Factor and identify the result

|ψ₁⟩ = (1/2)[ |0⟩(|0⟩ − |1⟩) − |1⟩(|0⟩ − |1⟩) ]
= (1/√2)(|0⟩ − |1⟩) ⊗ (1/√2)(|0⟩ − |1⟩)
= |−⟩ ⊗ |−⟩

The target qubit is still |−⟩ — unchanged by the CNOT. The control qubit changed from |+⟩ to |−⟩. The −1 eigenvalue of the target has been kicked back as a relative phase onto the control.

3 · Why Phase Kickback Matters

The math shows that while we applied a gate to the target, the relative phase of the control qubit changed from positive to negative. This is a structural property of controlled unitaries acting on their eigenstates, and it appears at the core of every major quantum algorithm.

Algorithm	How phase kickback is used
Deutsch’s Algorithm	The oracle kicks a −1 phase onto the control qubit to encode whether f is constant or balanced, extractable with a single H gate measurement.
Grover’s Algorithm	The oracle flips the sign of the target state’s amplitude by kicking a −1 phase back to the control register, enabling amplitude amplification.
Shor’s Algorithm	Quantum Phase Estimation relies entirely on phase kickback to transfer eigenvalue information from the target register to the control register.

The general rule: for any unitary U with eigenstate |u⟩ (so U|u⟩ = eⁱᵖ|u⟩), a controlled-U gate with the control in superposition kicks the phase eⁱᵖ back to the control qubit. The target is unchanged.

Part of the Quantum Series 2026. Originally published on Techucation.

Quantum Computing From First Principles: Qubits, Hadamard Gates & Why H^2 = I

Malcolm Low — Sun, 07 Jun 2026 10:07:46 +0000

Part of the Quantum Computing: A Complete Learning Path series.

QUANTUM SERIES 2026 — Qubits, the Hadamard gate, superposition, tensor products, and quantum interference from first principles.

Classical computers store information in bits that are always exactly 0 or 1. Quantum computers exploit the principles of quantum mechanics to do something fundamentally different: they operate on qubits, which can exist in a superposition of both states simultaneously. The Hadamard gate is the simplest gate that creates this superposition, and understanding it from first principles is the entry point to every quantum algorithm that follows.

1 . The Qubit

A qubit is the fundamental unit of quantum information. Unlike a classical bit, a qubit can exist in a superposition of |0> and |1> simultaneously. We write its general state using Dirac (bra-ket) notation:

|ψ> = α|0> + β|1>

Here α and β are complex numbers called probability amplitudes. They must satisfy the normalisation condition:

|α|² + |β|² = 1

The two computational basis states are represented as column vectors:

|0> = [1, 0]ᵀ      |1> = [0, 1]ᵀ

When we measure the qubit in state |ψ> = α|0> + β|1>, we get |0> with probability |α|² and |1> with probability |β|². The act of measurement destroys the superposition and collapses the qubit to a definite classical state.

Key distinction: The superposition is not just ignorance about a hidden value. The qubit genuinely occupies both states until measured, and this physical reality is what quantum algorithms exploit.

2 . The Hadamard Gate

The Hadamard gate H is a 2x2 unitary matrix that maps each computational basis state to an equal superposition:

H = (1/√2) [ +1  +1 ]
           [ +1  -1 ]

Applying H to each basis state:

Input	H \|input>	Short name
\|0>	(1/√2)( \|0> + \|1> )	\|+>
\|1>	(1/√2)( \|0> - \|1> )	\|->

Both outputs have equal amplitudes of 1/√2, giving a 50% measurement probability for each outcome. The sign difference between |+> and |-> is what drives interference later.

Unitarity check: H^† H = I. Since H is real and symmetric, H^† = H, so H² = I. The Hadamard gate is its own inverse.

3 . H² = I: Quantum Interference

Applying H twice to |0> returns the qubit to |0>. The algebra shows exactly why the |1> amplitudes cancel through destructive interference:

H(H|0>)
  = H( (1/√2)(|0> + |1>) )
  = (1/√2)( H|0> + H|1> )
  = (1/√2)( (1/√2)(|0>+|1>) + (1/√2)(|0>-|1>) )
  = (1/2)( |0> + |1> + |0> - |1> )
  = (1/2)( 2|0> )
  = |0>  [correct]

The +|1> and -|1> terms cancel completely (destructive interference) while the |0> terms add (constructive interference). This is the fundamental mechanism behind quantum algorithms: arranging amplitudes so wrong answers cancel and the correct answer survives.

4 . Single-Qubit Circuit: H-H-Measure

A single qubit routed through two Hadamard gates and then measured always returns 0 with 100% probability:

q_0: --[H]--[H]--[M]--

Step	State	Notes
1. Initialise	\|ψ_0> = \|0>	Ground state
2. First H	\|ψ_1> = (1/√2)(\|0>+\|1>)	Superposition: 50/50
3. Second H	\|ψ_2> = \|0>	Interference collapses back
4. Measure	Result = 0	100% probability

This is a concrete demonstration that superposition is not just probabilistic noise. The deterministic outcome of 0 is only possible because the two Hadamard gates interact through interference, a purely quantum effect with no classical analogue.

5 . Tensor Products and Multi-Qubit States

Multi-qubit systems are described using the tensor product (x). For two qubits, the four computational basis states are:

Ket	Tensor form	Column vector
\|00>	\|0> x \|0>	[1, 0, 0, 0]ᵀ
\|01>	\|0> x \|1>	[0, 1, 0, 0]ᵀ
\|10>	\|1> x \|0>	[0, 0, 1, 0]ᵀ
\|11>	\|1> x \|1>	[0, 0, 0, 1]ᵀ

The tensor product of two vectors is computed by multiplying each element of the first vector by the entire second vector and stacking the results. For |0> x |1>:

|0> x |1> = [1,0]ᵀ x [0,1]ᵀ = [0, 1, 0, 0]ᵀ = |01>

Dimension growth: n qubits span a 2ⁿ-dimensional Hilbert space. A 3-qubit system already has 8 basis states; a 50-qubit system has 2⁵⁰ ~ 10^15, impossible to store classically.

6 . Two-Qubit Superposition: HxH on |00>

Applying independent Hadamard gates to both qubits starting from |00>:

q_0: --[H]--
q_1: --[H]--

(HxH)|00>
  = (H|0>) x (H|0>)
  = (1/√2)(|0>+|1>) x (1/√2)(|0>+|1>)
  = (1/2)( |00> + |01> + |10> + |11> )

All four two-qubit basis states appear with equal amplitude 1/2. Each has measurement probability (1/2)² = 25%. This is the two-qubit analogue of the uniform superposition that opens algorithms like Grover's.

7 . Interference in a Two-Qubit H-H Circuit

Applying HxH twice to |00> returns it to |00>:

Input to 2nd HxH	After (HxH)
\|00>	(1/2)( \|00> + \|01> + \|10> + \|11> )
\|01>	(1/2)( \|00> - \|01> + \|10> - \|11> )
\|10>	(1/2)( \|00> + \|01> - \|10> - \|11> )
\|11>	(1/2)( \|00> - \|01> - \|10> + \|11> )

Output state	Amplitude sum (x 1/4)	Result
\|00>	+1 +1 +1 +1	4/4 = 1, constructive
\|01>	+1 -1 +1 -1	0, destructive
\|10>	+1 +1 -1 -1	0, destructive
\|11>	+1 -1 -1 +1	0, destructive

Only |00> survives. This is the same interference structure that the Grover diffusion operator exploits at scale: constructive interference on the target state, destructive on all others.

8 . The HxH Matrix and Why It Matters

The combined HxH operator is a 4x4 Walsh-Hadamard matrix (scaled by 1/2), the two-qubit case of the popcount rule derived in the Walsh-Hadamard post:

HxH = (1/2) [ +1  +1  +1  +1 ]
            [ +1  -1  +1  -1 ]
            [ +1  +1  -1  -1 ]
            [ +1  -1  -1  +1 ]

Every quantum algorithm that achieves a speedup over classical computation does so through the same three-phase structure:

Phase	Operation	Purpose
1. Open	Hadamard on all qubits	Create uniform superposition over all 2ⁿ states
2. Operate	Oracle / phase manipulation	Mark or bias the amplitude of the target answer
3. Close	Hadamard again (+ measurement)	Interference concentrates probability on the answer

The bottom line: the qubit and the Hadamard gate are the entry point to everything. Grover's O(√N) search, Shor's O((log N)³) factoring, and every other quantum speedup ultimately trace back to this interference mechanism operating at scale.

Originally published on malcolmlow.com. Part of the Quantum Series 2026, built with Qiskit 1.x.