MohammadMahdi Javid

Building AI agents for ERP and finance systems

2026-02-01T00:00:00+01:00

AI agents can take over real parts of an ERP workflow, like matching invoices or preparing journal entries. But a general-purpose agent with access to the whole ERP is not a financial control system.

ERP and accounting systems are full of rules: master data, posting rules, approval steps, fiscal periods, and records that have to stay auditable. An agent that can call any ERP endpoint and reason over unlimited transaction data will sooner or later produce an action that looks right and isn’t. The safer design gives the model small, bounded decisions and leaves validation, permissions, transaction integrity and every state change to deterministic services.

The core rule

Bound the agent, not the business process. Give each agent one narrow job, scoped data, typed tools and clear states, and put a deterministic validation layer in front of every ERP change.

From copilot to controlled workflow

The real difference isn’t a smarter or less smart model. It’s whether the model drives execution or the system does.

Model-driven

One generalist model
A large slice of the ERP in its context
Many overlapping tools
Writes straight into the ERP

Invalid accounts, wrong entities, duplicate postings, unapproved payments, a thin audit trail.

System-controlled

A router picks the workflow
A read-only agent retrieves and reconciles
A policy layer handles approvals
Deterministic checks: schema, permissions, accounting rules, balances, idempotency
One mutation service posts, then the result is verified and audited

What the architecture should optimize for

Minimal relevant context rather than maximal context.
Deterministic retrieval constraints before semantic retrieval.
Typed tool contracts rather than generic “update ERP” functions.
Server-side authorization rather than permissions encoded only in prompts.
Explicit validation before mutation rather than trusting model output.
Idempotent operations so retries do not create duplicate financial effects.
Observable execution so every material decision can be reconstructed later.

Context isolation: give the model exactly what the task requires

ERP data is highly contextual. The same vendor, account, tax treatment, or cost center can have different meanings across legal entities, fiscal periods, currencies, and business units.

Dumping a large portion of an ERP database into an agent context creates more than a token-management problem. It creates an authority problem because the model may see information that is irrelevant to the current transaction and still use it when forming a decision.

Common failure modes

Context distraction

Unrelated accounts, vendors, historical transactions, and policies compete for the model’s attention.

Context contamination

A malformed, stale, or attacker-controlled record becomes part of the reasoning context and influences later actions.

Cross-entity ambiguity

Records from different subsidiaries or accounting regimes appear together even though only one legal entity is relevant.

Historical-state confusion

A valid identifier from a previous fiscal period is mistaken for an identifier that is currently active.

Better pattern

Keep the system prompt focused on operational constraints. Put dynamic business data into structured retrieval results instead.

In the prompt

Task constraints
Allowed workflow
Tool boundaries
Output contract

In scoped runtime context

Entity, fiscal period, currency, cost centre
Transaction identifiers
The policy facts that apply

Engineering principle

A large context window does not compensate for poor context selection. Retrieve fewer facts with stronger provenance instead of supplying the model with an unrestricted ERP snapshot.

Scoped RAG: retrieval must preserve accounting boundaries

Retrieval for ERP agents should behave more like a database query than a generic knowledge search.

A semantic match such as “office equipment” is useful for finding descriptive text. It is not sufficient to determine which legal entity, account, tax code, or fiscal period should be used in a posting.

Agent query
Metadata filters
Exact + semantic search
Rerank
Small result set with provenance

Filters first: entity, fiscal period, currency, cost centre and access tier. Exact search for IDs and codes, semantic search for descriptions and policy text.

Retrieval rules for financial systems

Filter before retrieval

Apply authorization and business metadata constraints before semantic ranking. Retrieval should not first discover records and only later decide whether the agent was allowed to see them.

Combine exact and semantic search

Identifiers such as invoice numbers, purchase orders, tax identifiers, and account codes benefit from exact matching. Semantic retrieval is more useful for natural-language descriptions and policy text.

Return structured facts with provenance

A result should carry enough information for the application to identify where it came from.

{
  "document_id": "INV-2026-01842",
  "entity_code": "EU02",
  "fiscal_period": "2026-09",
  "vendor_id": "V-004281",
  "currency": "EUR",
  "source_system": "erp",
  "source_version": "current"
}

Keep retrieved content separate from instructions

Invoices, supplier notes, PDFs, email bodies, and OCR output are data. They are not trusted instructions to the agent.

Tool design: expose business capabilities, not your entire ERP API

An agent should not receive an unrestricted toolbox containing dozens of overlapping CRUD-style endpoints.

The important design question is not “How many APIs does the ERP have?” It is “Which operations does this agent actually need to complete this workflow?”

A narrow tool registry reduces ambiguity. More importantly, the backend must still enforce authorization and validation independently of the model.

Weak interface

{
  "name": "update_ledger",
  "description": "Updates financial records in the ERP",
  "parameters": {
    "account": "string",
    "amount": "number",
    "type": "string"
  }
}

The tool exposes an ambiguous mutation with almost no machine-checkable business semantics.

Stronger interface

{
  "name": "post_journal_entry",
  "description": "Creates a journal voucher from a validated transaction object.",
  "parameters": {
    "entity_code": {
      "type": "string"
    },
    "debit_account": {
      "type": "string"
    },
    "credit_account": {
      "type": "string"
    },
    "amount_minor": {
      "type": "integer",
      "minimum": 1
    },
    "currency": {
      "type": "string"
    },
    "idempotency_key": {
      "type": "string"
    },
    "source_document_id": {
      "type": "string"
    }
  },
  "required": [
    "entity_code",
    "debit_account",
    "credit_account",
    "amount_minor",
    "currency",
    "idempotency_key",
    "source_document_id"
  ]
}

The real control is not the JSON schema alone. The receiving service must verify every field against authoritative ERP state.

Tool-scoping rules

Give each specialized agent only the capabilities required for its workflow.
Prefer task-specific functions such as match_invoice, read_purchase_order, or create_journal_draft over generic mutation functions.
Make invalid states impossible to represent where practical.
Keep authorization checks on the server side.
Reject unknown, stale, or inactive identifiers before executing mutations.
Attach idempotency keys to operations that may be retried.
Return compact, structured results instead of raw HTTP responses or database dumps.

Important distinction

Tool restrictions are an AI control. They are not an authorization boundary.

The ERP service, gateway, or policy engine must remain the final authority.

The execution cycle: parse, retrieve, validate, act, verify

A dependable ERP agent should not jump directly from natural language to a financial mutation.

Parse
Retrieve
Validate
Authorize
Actuate
Verify

Any check fails: abort or escalate

1. Parse

Identify the immediate workflow objective.

For example:

identify the invoice
determine whether a purchase order exists
calculate the matching variance
prepare a posting candidate

Do not allow the model to invent missing accounting facts during parsing.

2. Retrieve

Fetch only the authoritative records required for the next decision.

Typical sources include:

vendor master
purchase order
goods receipt
invoice
payment status
accounting policy
account master

3. Validate

Check every value against authoritative state.

At minimum, validate:

entity and fiscal period
account status
currency
tax configuration
cost center
monetary precision
debit and credit totals
document status
approval state

4. Authorize

Determine whether the current actor and workflow are allowed to perform the requested operation.

Authorization should be evaluated outside the model.

[Agent Request]
      |
      v
[Policy Engine]
      |
      +--> Actor
      +--> Role
      +--> Entity
      +--> Operation
      +--> Amount
      +--> Approval state
      |
      v
[ALLOW / DENY / REQUIRE APPROVAL]

5. Actuate

Only a validated and authorized transaction should reach the ERP mutation service.

Prefer a structured transaction object:

{
  "entity_code": "EU02",
  "source_document_id": "INV-2026-01842",
  "debit_account": "610200",
  "credit_account": "200100",
  "amount_minor": 128450,
  "currency": "EUR",
  "idempotency_key": "INV-2026-01842:v1"
}

6. Verify

Do not assume that a successful HTTP response means the business operation succeeded.

Verify the resulting voucher, transaction ID, status, and relevant accounting totals.

If the ERP rejects the operation, return the structured error to the workflow controller and stop when the failure cannot be safely recovered.

Multi-agent specialization: separate reasoning from authority

Complex ERP workflows are usually easier to control when different responsibilities are separated.

[Inbound Invoice]
       |
       v
[Workflow Router]
  No mutation tools
       |
       +---------------------------+
       |                           |
       v                           v
[Matching Agent]             [Policy / Approval]
 Read-only                    Deterministic
       |
       v
[Validated Transaction Object]
       |
       v
[Posting Service]
 Deterministic mutation
       |
       v
[Voucher + Audit Event]

Responsibility boundaries

Router

Classifies the workflow and selects the appropriate execution path. It should not have write privileges.

Read-only retrieval or reconciliation agent

Compares invoices, purchase orders, receipts, and master data. Its outputs should be structured and independently verifiable.

Policy and approval layer

Applies thresholds, segregation-of-duties rules, approval requirements, and other deterministic controls.

Actuation service

Consumes a validated transaction object and performs the actual ERP mutation.

Keep handoffs small

Do not transfer complete conversational histories between agents.

Transfer only the state required for the next step.

{
  "workflow": "accounts_payable_match",
  "entity_code": "EU02",
  "invoice_id": "INV-2026-01842",
  "purchase_order_id": "PO-8492",
  "match_status": "matched",
  "variance_minor": 450,
  "currency": "EUR",
  "approval_required": false
}

This makes the workflow easier to test, replay, and audit.

Reliability controls that matter more than prompt wording

Prompt engineering is useful, but it should not carry the burden of financial correctness.

Idempotency

An agent may retry after a timeout or ambiguous tool response.

Without idempotency, the same invoice can be posted twice.

Request
  |
  v
[idempotency_key = invoice + workflow version]
  |
  +--> Seen before? ---- yes ---> Return existing result
  |
  no
  |
  v
Execute mutation
  |
  v
Persist result against key

Transaction boundaries

A multi-step workflow should not leave a partially applied financial change because the model failed halfway through.

Use explicit transaction boundaries in the ERP or service layer and design compensating actions where true atomicity is impossible.

Approval thresholds

Not every financial operation should be autonomous.

For example, an organization may require human approval based on:

monetary amount
vendor risk
unusual tax treatment
new bank details
cross-entity transfers
exceptional journal types

The thresholds must be configured by the organization rather than hard-coded into the model’s prompt.

Segregation of duties

The component that detects or proposes a transaction should not automatically receive unrestricted payment or approval authority.

Separate the steps:

Detect
Validate
Approve
Execute

instead of one agent that decides, approves and executes on its own.

Security and governance: treat external data as hostile input

Financial automation expands the attack surface because the model may process documents and messages originating outside the organization.

Supplier invoices, OCR output, emails, attachments, and retrieved text must be treated as untrusted data.

Required controls

Least privilege

Give service identities only the permissions required for the specific workflow.

Prompt-injection resistance

Do not allow instructions embedded in invoices, PDFs, or supplier notes to override system policy.

Server-side authorization

Never rely on the model to enforce access control.

Human approval

Require explicit approval where policy or risk thresholds demand it.

Immutable audit records

Capture the source document, relevant inputs, tool calls, policy decisions, resulting ERP transaction, and timestamps in a tamper-evident audit trail.

Sensitive-data minimization

Do not place payroll data, bank details, or unrelated customer information into model context merely because the agent technically can access it.

Auditability rule

The system should be able to answer three questions after every material action:

What did the agent see?

Why was the action allowed?

What exactly changed in the ERP?

Failure diagnosis: inspect the control boundary, not only the model

When an agent fails, the root cause is often not the language model itself.

Recursive tool loop

Symptom

The workflow repeatedly retries the same operation.

Typical cause

The service returns an error that is difficult to interpret or the controller has no explicit termination state.

Engineering response

Use bounded retries, structured error codes, and explicit terminal states.

Attempt 1
   |
   v
Structured error
   |
   v
Can retry safely?
   |
 +--+--+
 |     |
yes    no
 |     |
 v     v
Retry  Abort / Escalate

A retry limit should be derived from the operation and failure mode. A universal number such as “three attempts” is only a heuristic.

Parameter hallucination

Symptom

The model produces a plausible but nonexistent account, vendor, tax code, or transaction identifier.

Typical cause

The workflow allows free-form construction before authoritative lookup and validation.

Engineering response

Resolve identifiers against the ERP master data before mutation.

Free text
   |
   v
Candidate identifier
   |
   v
Authoritative lookup
   |
   +--> Not found ----> Stop
   |
   +--> Inactive -----> Stop
   |
   +--> Valid ---------> Continue

Context rot

Symptom

The agent loses the original business objective after many tool calls.

Typical cause

Large raw responses accumulate in the context.

Engineering response

Store state outside the conversation and pass forward only the fields required for the next step.

Step-by-step implementation plan

1. Define workflow boundaries

Choose one concrete ERP workflow.

Examples:

three-way invoice matching
vendor master validation
journal draft preparation
payment exception classification

Do not begin with “automate accounting” as a single agent scope.

2. Define authoritative systems

For every field the agent may use, document the authoritative source.

Field	Source of truth
Vendor ID	Vendor master
Account code	Chart of accounts
Tax code	Tax configuration
PO status	Purchasing system
Approval state	Workflow engine

3. Define the transaction contract

Create a versioned schema for the structured object that moves between reasoning components and deterministic services.

Treat this object as an API contract, not as free-form model output.

4. Build the read-only path first

Test retrieval, matching, validation, and explanations without allowing financial mutations.

Create synthetic edge cases for:

inactive vendors
closed fiscal periods
currency mismatches
duplicate invoices
missing purchase orders
tax mismatches
partial receipts
stale master data

5. Add policy enforcement

Introduce RBAC, approval rules, segregation of duties, and monetary thresholds outside the model.

6. Enable controlled mutation

Expose only the smallest deterministic mutation service required by the workflow.

Add:

idempotency
transaction handling
optimistic concurrency where appropriate
structured errors
audit events

7. Evaluate the complete system

Measure more than model accuracy.

Track:

retrieval precision
invalid identifier rate
unauthorized action rate
duplicate mutation rate
validation rejection rate
escalation rate
mean recovery time
audit completeness
end-to-end task success

Quick reference checklist

Architecture

Narrow workflow scope
Scoped retrieval with authorization metadata
Small, typed tool surface
Deterministic validation before mutation
Explicit state transitions

ERP correctness

Authoritative identifier lookup
Account and tax validation
Fiscal-period checks
Balance validation
Idempotent mutations
Transaction verification

Security

Server-side RBAC
Segregation of duties
Prompt-injection defenses
Sensitive-data minimization
Approval thresholds
Tamper-evident audit logs

Agent operations

Bounded retries
Structured error handling
Externalized workflow state
Compact agent handoffs
Full observability

The short version

The strongest pattern for AI in ERP automation isn’t a more autonomous generalist agent. It’s a controlled system: the model handles language and bounded reasoning, and deterministic services keep authority over business rules, permissions, transaction integrity and stored state. That split is what makes the workflow testable and auditable.

Who does what

The model proposes. The system validates. The ERP stays the source of truth.

Soldering 101

2024-06-06T00:00:00+02:00

Soldering is a small skill that opens up a lot: sensors, keyboards, robots, repairs and prototypes. This guide shows each step with a photo and covers the details that save beginners from burnt boards and joints that don’t hold.

If you remember one thing

Heat the metal parts first, then feed solder into the joint. Not onto the tip of the iron.

What a good joint looks like

Good: smooth and shiny, solder has flowed into the joint. Photo: Wikimedia Commons

Bad: dull and lumpy, sitting on top instead of flowing in. Photo: Wikimedia Commons

A good joint has three things:

The solder forms a small, shiny ramp between the pad and the wire or lead.
You can still see the shape of the lead under the solder. It isn’t buried in a blob.
Nothing moved while it cooled.

Set up safely

The bench

A steady surface, a clear bench, good light and tools within reach. Photo: Wikimedia Commons

Every time:

Work on a steady table, never on your lap.
Use bright light, and a magnifier if you have one.
Keep the iron in a proper stand, on a heat-resistant mat.
Keep paper towels, alcohol and plastic bags away from the iron.

Fumes

You might not smell much, but the flux in solder gives off fumes. Pull them away from your face, close to where you work.

A fume extractor behind the work pulls the smoke away from you. Photo: Wikimedia Commons

A small extractor or fan behind the joint is enough. Keep the airflow gentle: a strong draft cools the joint and blows small parts away.

Eyes, burns and hands

Wear safety glasses. Solder can spit, especially when you desolder.
The iron always goes back in the stand, never on the table.
Route the cable so you can’t catch it with your arm.
Have a heat-proof spot, like a ceramic tile, to drop hot parts on.
Wash your hands afterwards, especially with leaded solder.

Static (ESD)

Not every project needs it, but an anti-static strap is cheap and protects modern chips.

Clip the strap to a grounded point, like an ESD mat. Photo: Wikimedia Commons

The tools that matter

A few tools used well beat a big kit used at random. Photo: Wikimedia Commons

You need:

A temperature-controlled iron, or a good fixed-temperature one
A stand and a heat-resistant mat
Brass wool, or a damp sponge, to clean the tip
Electronics solder with a rosin (flux) core
Extra flux, as a pen or a small tub. It makes everything easier.
Helping hands or a PCB holder, so nothing moves while it cools
Flush cutters to trim leads
Isopropyl alcohol and a brush to clean up

Worth having: a magnifier, tweezers for small parts, desoldering wick or a pump for mistakes, and a heat gun for heat-shrink tubing.

Clean and tin the tip

Beginners skip this the most, and it matters the most. A dirty, oxidised tip passes heat badly, so you hold it on the pad longer, and that’s what damages boards.

A quick wipe removes the oxide. A clean tip heats faster. Photo: Wikimedia Commons

Wipe it quickly. If you use a sponge, it should be damp, not dripping.

Tinning: a thin coat of solder keeps the tip shiny. Photo: Wikimedia Commons

Repeat this rhythm all the time:

Heat the iron.
Clean the tip.
Melt a little solder on it, so it looks shiny.
Solder a joint.
Clean and re-tin every few joints, or whenever the tip looks dull.

Don’t keep the iron on the pad

If the solder takes more than a few seconds to melt, stop. Clean and tin the tip, add flux, and try again with better contact.

The basic motion

The iron heats the joint, solder goes into the joint, then everything holds still. Animation: Wikimedia Commons

Position: touch the iron to the pad and the lead at the same time.

Both metals heat together. Photo: Wikimedia Commons
Feed: touch the solder where the hot metals meet and let it flow. Don’t push.

The solder melts on the joint, not on the iron. Photo: Wikimedia Commons
Finish: take the solder away first, then the iron. Hold still while it cools.

Solder away, then iron away. Photo: Wikimedia Commons

A few details that help:

Use the flat face of the tip. More contact means faster heat.
If the solder won’t flow, add flux.
Don’t blow on the joint. Let it cool by itself.

Through-hole parts

Headers, resistors, LEDs: anything with legs that go through the board.

Heat pad and lead, feed solder, trim the lead. Photo: Wikimedia Commons

Push the part in fully, or to the height you want.
Bend the leads slightly so it doesn’t fall out.
Add flux if you have it.
Heat the pad and the lead together.
Feed solder into the joint.
Remove the solder, then the iron.
Trim the leads once it’s cool.

Watch the pad

If the pad starts to lift or the board around it changes colour, stop and let it cool. Holding the iron too long is the most common way to lift a pad.

Wires

With wires you want a joint that is mechanically strong as well as soldered.

Smooth flow is good. Bubbles and a rough surface usually mean too much heat or movement. Photo: Wikimedia Commons

Tin the wires first. Strip them, twist the strands, add flux, then heat the wire and feed solder until the strands look silver. No blobs. Two tinned wires join in a second.

Add strain relief. Solder isn’t glue. Put heat-shrink tubing over the joint, and tie the wire down so movement doesn’t pull on the joint.

Heat guns

A heat gun is great for heat-shrink tubing, but it doesn’t replace the iron on board joints.

What a heat gun is for: heat-shrink. Photo: Wikimedia Commons

Keep the nozzle moving.
Use the lowest heat that shrinks the tubing.
Don’t point it at the board for long. It can warp plastic, loosen connectors and damage parts.

For hot-air rework on electronics, use a hot-air rework station. Unlike a paint-stripping heat gun, it lets you set the temperature and airflow.

Check your work

Cold joints

A cold joint: dull, grainy, crusty. Photo: Wikimedia Commons

Fix: add flux, reheat until it flows, add a little fresh solder if needed, and let it cool without moving.

A healthy joint

Smooth, with clean edges and no spikes or balls. Photo: Wikimedia Commons

A 30-second check

Any bridges between pins, especially on chips and headers?
Any dull or grainy joints?
Any joints that look like a ball sitting on top?
Any pads that are discoloured or lifting?

Fixing mistakes

Boards get damaged during rework more than anywhere else. Keep heat contact short and use plenty of flux.

Add flux, add fresh solder if needed, remove it cleanly, solder again. Photo: Wikimedia Commons

Solder wick

Lay the braid on the solder, press the iron on top, lift both straight up. Photo: Wikimedia Commons

Put flux on the wick before you heat it. It soaks up solder much better.

Save the pad

Don’t keep heating the same pad. Heat, try, let it cool, try again.
If the solder won’t melt quickly: clean and tin the tip, add flux, or use a bigger tip.

A first look at SMD

You can learn surface-mount parts as a beginner. Start with larger sizes like 0805 before the tiny ones.

Tack one side, line it up, then solder the other side with flux. Photo: Wikimedia Commons

Finish cleanly

Inspect under bright light, magnified if you can.
Clean flux residue with isopropyl alcohol and a brush, and let the board dry before you power it.
Put the iron in its stand and unplug it.

A 30-minute practice plan

Motion: twist two scrap wires together and solder until you get three smooth joints in a row.
Through-hole: solder a header onto a spare board or perfboard. Aim for joints that all look the same.
Rework: make a bad joint on purpose, then fix it with flux and heat, and clean it up.

Cheat sheet

Before	During	After
Bright light, steady bench	Heat pad and lead together	Look for bridges and cold joints
Fumes pulled away	Feed solder into the joint	Clean off flux residue
Tip clean and tinned	Solder away, then iron	Iron in the stand, unplugged
	Hold still while it cools

Let’s listen to music together

2022-11-08T00:00:00+01:00

I’m a big fan of music, and I’m sure many of you are too. Here are a few of my favourites to start with.

Playlist on Spotify A few of my favourites Play here

Your turn

I’m not looking for anything in particular. If there’s a song you like and want to share, send it to me through any of the links on Follow Me. Suggestions are always welcome.

A SOCKS5 proxy over SSH to get around censorship

2022-10-02T00:00:00+02:00

This setup is for when your device can only reach the local network, a machine on that network can reach a filtered internet, and you have a server somewhere outside the filter. One SSH tunnel chains them together, and your device ends up with a normal SOCKS5 proxy.

Client phone or PC, intranet only

Middle filtered internet

Server open internet

What you need

Client: the device you want to browse from. It only reaches the intranet.
Middle: a Linux machine the client can reach, with internet access that is filtered.
Server: a machine outside the filter that you can SSH into from the middle machine. A small VPS is enough.
SSH on the middle machine and the server.
Dante on the server, only if you use option B.
Proxifier, or any app that can use a SOCKS5 proxy, on the client.

Tip

Anywhere below you can use a domain name instead of an IP address, and any free port instead of 1080.

Option A: SSH alone

SSH can act as a SOCKS5 proxy by itself. Run this on the middle machine:

ssh -C -N -D 0.0.0.0:1080 user@server.example.com

-D 0.0.0.0:1080 opens a SOCKS5 proxy on port 1080 of the middle machine, on all its network interfaces, so the client can reach it.
-C compresses the traffic, and -N means “no shell, just the tunnel”.
Add -v while you test, to see each connection as it opens.

Every connection the client makes through the proxy now leaves from the server, outside the filter.

Option B: Dante on the server

If you’d rather run a real SOCKS server on the outside machine, for example to share it between several tunnels, install Dante there and keep it on localhost, so only the tunnel can reach it:

sudo apt install dante-server

A minimal /etc/danted.conf:

logoutput: syslog
internal: 127.0.0.1 port = 1080
external: eth0
socksmethod: none
clientmethod: none
user.privileged: root
user.unprivileged: nobody

client pass { from: 127.0.0.0/8 to: 0.0.0.0/0 }
socks pass { from: 127.0.0.0/8 to: 0.0.0.0/0 }

Replace eth0 with the server’s network interface (ip a lists them), then sudo systemctl restart danted.

Now forward a port from the middle machine to Dante:

ssh -N -L 0.0.0.0:1080:127.0.0.1:1080 user@server.example.com

The pattern is -L [listen IP]:[listen port]:[destination IP]:[destination port]. Here the middle machine listens on port 1080 and sends everything to port 1080 on the server’s own localhost, where Dante is waiting.

Point the client at the proxy

On the client, add a proxy in Proxifier:

Profile → Proxy Servers → Add.
Address: the middle machine’s intranet IP. Port: 1080. Protocol: SOCKS Version 5.
Click Check to test it, then let Proxifier send all traffic through it.
Under Profile → Name Resolution, resolve hostnames through the proxy. Otherwise DNS lookups still go through the filtered network.

On a phone, use any app or browser setting that supports SOCKS5 with the same address and port. In Firefox it’s Settings → Network Settings → Manual proxy, with Proxy DNS when using SOCKS v5 ticked.

Keep it running

Log in with an SSH key instead of a password, so the tunnel can start without you typing anything.
Add -o ServerAliveInterval=30 -o ExitOnForwardFailure=yes so a dead connection is noticed quickly.
Wrap the command in autossh or a systemd service, so it comes back by itself after a drop.
Anyone who can reach the middle machine’s port 1080 can use your proxy. If the intranet isn’t yours, bind to one interface instead of 0.0.0.0, or block the port for everyone but your client with a firewall rule.

How to make your own website on GitHub Pages

2019-10-08T00:00:00+02:00

I wrote this guide in 2019 for a course where everyone had to put a personal website online. GitHub Pages hosts it for free, and you only need a browser, Git and a text editor. Every step has a screenshot, so you can check that your screen looks the same before you move on.

GitHub has changed since 2019

The screenshots are from 2019 and some buttons have moved. The Pages settings now live under Settings → Pages, new repositories use a branch called main instead of master, and the green Code button replaced “Clone or download”. The steps are otherwise the same.

1. Create a GitHub account

Go to github.com and click Sign up at the top right. Pick your username carefully: your site will live at yourusername.github.io.
Fill in the form.
Choose the Free plan.
The “customize” page is optional. You can skip it.
GitHub sends you an email. If it isn’t in your inbox, check spam.
Open it and click Verify email address.

2. Copy the website template

Open the personal website template.
Click Fork at the top right. This copies the template into your own account.
If you see a “Forking…” page, wait a few seconds or refresh. If you don’t see it, that’s fine too.
When it’s done you’re on your own copy, and the Fork button is greyed out.
Open your repositories: https://github.com/yourusername?tab=repositories (use your username).

You should see the template in the list.
Click personal_website_template, or go straight to https://github.com/yourusername/personal_website_template.
Click Settings.
Rename the repository to yourusername.github.io. If your username is ali, the name is ali.github.io.
Scroll down to GitHub Pages and set the source to the master branch (on today’s GitHub: Settings → Pages, branch main). If it’s already set, leave it.
Open yourusername.github.io in your browser. You should see the template site. It can take a minute or two the first time.

3. Install Git and download your site

Go to git-scm.com/downloads.
Click the button for your system. I used 64-bit Windows 10, so I clicked Windows.
The download should start on its own. If it doesn’t, go to git-scm.com/download/win

and pick the installer that matches your Windows (for most people, 64-bit Git for Windows Setup).
Run the downloaded .exe.
Click Next on every screen. The defaults are fine.

Show all eight installer screens
On the last screen click Install,

then Finish.
To check that it worked, type cmd in the Windows search box

and open Command Prompt.

Type git and press Enter. If you see a list of Git commands, Git is installed.
Back on GitHub, open your yourusername.github.io repository.
Click Clone or download (today: the green Code button) and copy the URL.
In Command Prompt, make a folder for your projects and clone the site into it:
```
cd /d C:\
md dev
cd dev
git clone https://github.com/yourusername/yourusername.github.io.git
```
Git prints a few lines while it downloads. When it stops, the site is on your computer.

4. Open the site in VS Code

Open Visual Studio Code, then File → Open Folder (Ctrl+K Ctrl+O).
Pick the C:\dev\yourusername.github.io folder and click Select Folder.
You should see the site’s files on the left.
Open _config.yml. Most of the site’s settings are in this one file.

5. Make it yours

Change the title, your name, the description and the colour skin.

Further down, fill in your bio, email and social links.
The pages themselves are Markdown files: cv.md, courses.md, blog.md and so on. Edit them like any text file.
To put your changes online, save, then commit and push from the same folder:
```
git add .
git commit -m "My first changes"
git push
```
GitHub rebuilds the site after every push. Refresh yourusername.github.io after a minute and you’ll see your changes.