Multi-Agent Capital System


# Building a Survival-First Multi-Agent Capital System

*How I designed a fleet of specialised AI agents governed by hard mathematical constraints — and why “don’t die” beats “grow fast” every time.*

-----

## The Problem With Most AI Agent Systems

Most multi-agent architectures are built around capability: what can each agent *do*? I built mine around a different question — what can each agent *spend*, and what happens if it’s wrong?

When you’re deploying autonomous agents against real capital, optimism is a bug. An agent that confidently recommends scaling spend based on five data points isn’t being helpful; it’s being dangerous. I needed a system where the architecture itself enforced epistemic humility, not just the prompts.

This is the story of how I built the MCP (Multi-Agent Capital Protocol) system — a fleet of seven specialised agents governed by a single inviolable principle: **survival dominates all upside considerations.**

-----

## The Architecture: A Fleet With a Constitution

The system is made up of seven agents, each with a tightly scoped role, a defined capital authority, and a set of hard prohibitions. No agent operates in isolation. Every allocation decision flows through a central governance layer before it touches real capital.

Here’s how the fleet breaks down:

### 🔭 Opportunity Discovery Agent

The ideation engine. It generates hypotheses and scans for opportunities — but critically, it has **zero capital authority**. Its only job is to produce falsifiable ideas with qualitative rationale and rough demand estimates. By capping its Information Quality Score (IQS) at 0.4, I’m formally acknowledging that raw hypotheses are low-confidence by definition. An agent that can’t spend money can’t cause financial harm by being over-optimistic.

### ✅ Validation Agent

Before a hypothesis becomes a commitment, it gets tested. The Validation Agent runs rapid falsification experiments with a hard ceiling of **£150 per test** and a maximum of three tests running in parallel. I require pass/fail metrics to be defined before a test begins — not after — and results must land within 72 hours. If more than half the tests fail, the budget is automatically halved. The IQS cap only lifts to 1.0 after real transactions are on the board.

### 🎯 Offer Engineering Agent

Once demand is validated, the Offer Engineering Agent translates signals into concrete offers: exact pricing, sales mechanism, and positioning. Crucially, it has **no capital authority at all** — it cannot run ads, cannot purchase tooling, and cannot assume conversion uplift without validation data backing it up. I designed it as a pure design function, nothing more.

### 📣 Distribution Growth Agent

Customer acquisition and channel execution. This agent can spend, but within tight guardrails I set deliberately: a maximum of 20% of remaining capital and a daily spend cap of £50. Every proposal must specify channel, volume, and CAC assumptions upfront. If cost-per-acquisition worsens across the majority of simulation runs, spend is automatically cut by 50%. I made speculative scaling an explicit prohibition — not a guideline, a prohibition.

### ⚙️ Automation Ops Agent

This agent removes human bottlenecks and reduces execution cost. Any automation it proposes must break even within 14 days, and its capital draw is capped at 10% of remaining funds. I set the IQS cap conservatively at 0.6 unless the automation is already directly linked to revenue — I’m not interested in building infrastructure for a future that hasn’t arrived yet.

### 🛡️ Risk Reality Check Agent

My favourite part of the system. This is an adversarial governance agent with veto power over any allocation exceeding 10% of capital. It can downgrade the IQS of any other agent, flag over-optimistic assumptions, and surface legal, financial, and execution risks. It cannot allocate capital itself — its power is purely preventative. I measure its success not by revenue generated, but by **capital-destructive decisions prevented**.

### 🧮 Controller Agent

The authoritative brain of the whole system. The Controller owns and mutates the global capital state, runs all Monte Carlo simulations, computes Kelly fractions, and enforces kill switches. It has the final say on every allocation — and I deliberately made that authority non-delegable. The system invalidates itself if the capital survival probability (`P_survive`) drops below 70%, or if the probability of total wipe-out (`P_wipe`) exceeds 10%.

-----

## The Design Principles That Shaped Everything

### 1. Separation of Ideation From Execution

The Opportunity Discovery Agent can dream freely precisely *because* it cannot spend. The Validation Agent can run experiments precisely *because* it cannot scale. Separating the permission to imagine from the permission to act creates a natural firewall against wishful thinking propagating into capital decisions.

### 2. IQS as a Formal Confidence Register

The Information Quality Score isn’t a vibe check — it’s a hard gate. Every agent has an IQS ceiling that reflects how much real-world evidence backs its claims. An agent working from hypotheses alone is capped at 0.4. One that has seen real transactions can reach 1.0. This means the system automatically demands more proof before granting more authority.

### 3. Survival as the North Star

The Controller’s governing invariant is stark: *survival dominates all upside considerations.* This isn’t pessimism — it’s the mathematically correct response to operating under genuine uncertainty. Kelly criterion theory tells us that overbetting destroys compounding returns even when the underlying edge is real. The MCP system encodes this at the architectural level.

### 4. Adversarial Governance by Design

The Risk Reality Check Agent exists to be the voice of doubt. In most organisations, the person who raises concerns is swimming against cultural current. Here, that voice has structural veto power. Building in adversarial governance means the system gets robustly stress-tested without relying on any individual’s courage to speak up.

### 5. Hard Constraints Beat Soft Guidelines

Every agent contract specifies not just what an agent *should* do, but what it *cannot* do. Prohibitions are explicit: no speculative scaling, no spend without validated demand, no grandfathered allocations, no delegation of final approval. Soft guidelines get eroded under pressure. Hard prohibitions don’t.

-----

## What We Learned

The most counterintuitive lesson from building this system is that **constraint is a feature, not a limitation.** Agents with tightly bounded authority are faster to reason about, safer to deploy, and easier to audit when something goes wrong. The system’s conservatism in early stages (low IQS caps, small spend limits, mandatory break-even windows) is precisely what creates the evidence base needed to act more boldly later.

We also learned that versioning agent contracts matters. Each contract carries an explicit changelog — even when the version increment has no semantic changes, the discipline of versioning creates accountability and makes it possible to trace exactly when the system’s behaviour changed and why.

The MCP system is not finished. It’s designed to be iterated on as the evidence base grows, IQS ratings update, and capital state changes. That’s the point: a governance architecture that evolves with its own track record, always anchored to the one constraint that can’t be negotiated away.

Don’t die first. Everything else is upside.

-----

*This post describes the v1.1 agent contract architecture. All capital authority figures and IQS thresholds reflect current system configuration.*

Building: Contrails & Cordite


# Building *[Contrails and Cordite](https://contrails-and-cordite.vercel.app/)*: A WW2 Aircraft Reference Site in Next.js

**A deep-dive into the design decisions, architecture, and image-handling challenges behind a passion project for warplane enthusiasts.**

---

### ## Where It Started

The brief was deceptively simple: build a comprehensive, image-forward reference site for WW2 aircraft enthusiasts using Next.js. No half-measures — every aircraft entry should feel like pulling a dossier out of an intelligence archive. Photographs front and centre, historical detail on every page, and a structure that lets visitors explore by aircraft or by theatre of war.

What followed was an education in the hidden complexity of building a visually rich site around a public image commons that was never designed to be depended upon.

---

### ## Information Architecture

I organised the site around two core content types that mirror how enthusiasts actually think about the subject:

****Aircraft**** — individual entries for twelve iconic types, spanning every major air force. The roster covers the Supermarine Spitfire, P-51 Mustang, Bf 109, Mitsubishi Zero, B-17 Flying Fortress, Avro Lancaster, Focke-Wulf Fw 190, Hawker Hurricane, Junkers Ju 87 Stuka, F4U Corsair, P-38 Lightning, and the Messerschmitt Me 262 — the world's first operational jet fighter.

****Theatres**** — five pages grouping aircraft and events by strategic context: Battle of Britain & the West, Eastern Front, Pacific, Mediterranean & North Africa, and Battle of the Atlantic. This axis of navigation exists because the performance envelope of an aircraft only makes sense when you understand the environment it was designed to fight in. A Spitfire and a Zero were contemporaries with broadly similar roles, but they were built for completely different wars.

The site also carries an About page and a hero-driven home screen that sets the atmospheric tone before visitors dive into the catalogue.

---

### ## Visual Design Principles

My overriding aesthetic goal was **dossier-meets-archive**. War photography from 1939–45 has an intrinsic visual authority — grain, contrast, the particular quality of light in a gun-camera frame — and the site's chrome had to earn the right to sit beside it rather than compete with it.

That translated into a handful of hard decisions:

- ****Photography at full bleed.**** No thumbnails relegated to a corner. Hero images fill the viewport; card images fill their containers. Text is layered over images using gradient overlays, not placed beside them.
- ****Dark, muted base palette.**** Near-black backgrounds (`ink-950`) prevent the interface from fighting the photographs for visual dominance. Gold-amber accent tones (`c8a44b`) nod to period military insignia and instrument-panel gauges.
- ****Monospaced type in supporting roles.**** Reference labels, classification stamps, and metadata are set in `Courier New` — a small detail that commits hard to the dossier metaphor without making body text unreadable.
- ****Restraint in motion.**** Hover states use `scale-105` on images — enough to signal interactivity, not enough to feel playful.

---

### ## The Image Problem

The biggest engineering challenge on this project had nothing to do with React or TypeScript. It was photographs.

Wikimedia Commons is the only freely-licensed archive with consistent coverage of WW2 aircraft photography. It has tens of thousands of images. It is also maintained by volunteers who rename, improve, and occasionally delete files without notice. The hash-based CDN URLs that Commons generates (`upload.wikimedia.org/wikipedia/commons/a/b3/...`) change every time a file is reuploaded. A URL that works today can silently 404 tomorrow.

The naive approach — hard-coding `<img src={commonsUrl} />` — produces broken-image icons the moment any URL rots. On a catalogue of twelve aircraft across five theatres, the probability of at least one URL breaking on any given day is uncomfortably high.

The solution I built has three interlocking tiers.

### Tier 1: The Proxy Route and URL Helper

Rather than sending the browser directly to `upload.wikimedia.org`, every image in the data layer is built using a `wm()` helper function that routes requests through a local Next.js API route (`/api/img`):

```ts
const wm = (file: string, width = 1200): string =>
  `/api/img?file=${encodeURIComponent(file)}&w=${width}`;
```

The API route fetches from Commons's stable `Special:FilePath` redirector — a URL that resolves to the current CDN hash for a given filename — on the server side, then streams the result back to the browser with aggressive cache headers (`max-age=86400, stale-while-revalidate=604800`). The browser never touches Wikimedia's CDN directly, which eliminates CORS friction and keeps image load times predictable.

Crucially, `Special:FilePath` URLs are stable for a given **filename**, even when the underlying CDN hash changes. This is a much stronger guarantee than hard-coding the hash URL directly.

### Tier 2: The Wikipedia REST API Fallback

If the Commons filename itself has changed — because a volunteer reuploaded a higher-resolution scan under a new name — the proxy returns a 404, and the browser fires the `onError` event on the image element. At this point, the `SafeImage` component makes a client-side call to the Wikipedia REST API:

```ts
const WIKI_API = 'https://en.wikipedia.org/api/rest_v1/page/summary/';

async function fetchWikiThumbnail(slug: string): Promise<string | null> {
  const res = await fetch(`${WIKI_API}${encodeURIComponent(slug)}`);
  const data = await res.json();
  return data?.originalimage?.source ?? data?.thumbnail?.source ?? null;
}
```

Each aircraft entry carries a `wikiSlug` field (e.g. `'Supermarine_Spitfire'`) that maps to its Wikipedia article, not its Commons filename — a distinction that matters because the two naming conventions often diverge. The REST API returns whatever image Wikipedia is currently using for that article's infobox, which is almost guaranteed to be a high-quality photograph of the correct subject.

### Tier 3: The Branded Placeholder

If both network tiers fail — the Commons proxy 404s **and** the Wikipedia API returns nothing — the `SafeImage` component falls back to a local SVG placeholder stored in `/public/placeholder.svg`. This is not a generic grey rectangle. It is a fully branded, inline SVG that looks like a period intelligence dossier — dark linen background, a geometric aircraft silhouette in the site's gold accent colour, and monospaced type reading **"Photograph unavailable / NO VISUAL RECORD ON FILE"**, with a red rubber-stamp **UNINDEXED** in the corner. It uses only web-safe fonts and zero external resources, so it loads in under a millisecond with complete certainty.

The result is a site where every image position is always occupied by something visually coherent, regardless of what the external archive does.

---

### ## The `SafeImage` Component

The component that orchestrates all three tiers is deliberately a plain `<img>` element wrapper rather than Next.js's built-in `<Image>`. This was a pragmatic choice: `next/image` intercepts `onError` in ways that make progressive fallback chains unreliable. Using a plain `<img>` keeps the error-handling logic fully in React's hands.

I track state across three stages and reset on `src` prop change via `useEffect`, which prevents a subtle bug where navigating from one aircraft detail page to another could leave the component stranded on a previous entry's fallback URL.

```tsx
// stage: 0 = primary src, 1 = wiki thumbnail, 2 = placeholder
const [currentSrc, setCurrentSrc] = useState<string>(src);
const [stage, setStage]           = useState<0 | 1 | 2>(0);
```

Above-the-fold hero images use `loading="eager"` to hit Largest Contentful Paint targets; card grids use `loading="lazy"` so the browser only fetches images as they scroll into view.

---

### ## Data Layer

Every aircraft and theatre entry is a TypeScript object that carries three image-related fields, enforced by type:

```ts
type Aircraft = {
  slug: string;
  name: string;
  image: string;       // proxied URL via wm() helper
  wikiSlug: string;    // Wikipedia article slug for REST API fallback
  imageCredit: string; // free-text credit line for figcaptions
  // ... historical fields
};
```

Separating `image` (the Commons filename, routed through the proxy) from `wikiSlug` (the Wikipedia article identifier) was a design decision that caused me some confusion early in the build — the two values often look similar but refer to different namespaces. Getting this distinction wrong produces fallback chains that skip straight to the placeholder when the primary URL fails, because the Wikipedia API lookup gets called with a Commons filename instead of an article slug.

---

### ## What I'd Do Differently

****Build the image infrastructure first.**** I added the proxy route and `SafeImage` component midway through the project, after discovering that naive image embedding produced a visually broken experience in testing. Starting with the resilient image system and working outward from there would have saved a couple of debugging sessions.

****Abstract the** `**wm()**` **helper earlier.**** I lost several hours to broken references after a routing refactor deleted the `/api/img` route. A centralised image utility with a clear API contract would have made those breakages obvious at compile time rather than runtime.

****Consider a build-time image validation step.**** A CI check that fetches each proxied URL and logs 404s would catch stale Commons filenames before they reach production — something I'd add if I were to revisit the project.

---

### ## The Result

**Contrails & Cordite** is the kind of site that's easy to underestimate from a technical description — "a Next.js catalogue with twelve entries and five category pages" doesn't sound ambitious. The ambition is in the details: in the image system that refuses to show a broken icon, in the placeholder that stays in character when the archive fails, in the design language that earns its place beside seventy-year-old photography.

The codebase is compact and the architecture is straightforward. What took time was getting the small things right — and the image-handling infrastructure, in particular, is a pattern I'd reach for again on any project that depends on community-maintained media archives.

---

**Built with Next.js, TypeScript, and Tailwind CSS. Images sourced from Wikimedia Commons under various public domain and free-use licences.**

Building: The Naval Archive


Building *[The Naval Archive](https://the-naval-archive.vercel.app/)*: Design Notes on a WW2 Warship Enthusiast Site

**April 2026 · Next.js, Tailwind CSS, Wikimedia Commons**

---

There's a particular atmosphere to naval history — salt-worn, severe, and grand. When I look at a photograph of HMS Hood steaming through the Firth of Forth in 1940, or read the signals log from the **Bismarck** chase, I feel the weight of iron and the ruthlessness of the sea. Building a website for WW2 warship enthusiasts posed the same challenge any period archivist faces: how do you honour that atmosphere without tipping into pastiche?

This is my build log for **The Naval Archive** — an eight-section Next.js site covering Top 10 ships by nation, world museums, dedicated profiles for HMS Hood, Rodney, and Belfast, the career of Admiral Cunningham, and a multi-theatre battle timeline. Here's how it came together.

---

### ## The Aesthetic Direction

My first decision was conceptual rather than technical: what **register** does a naval history site live in?

I looked at plenty of existing sites in this space. Most lean military-utilitarian — grey backgrounds, tabular layouts, the visual language of a database dump. Others go the opposite way, reaching for drama with widescreen stock footage and motion graphics that feel more like a streaming platform than an archive. Neither felt right to me.

The direction I committed to was ****editorial archive****: the sensibility of a serious illustrated reference — something like the Imperial War Museum's printed catalogues, or the dusty-but-authoritative volumes I'd find in a university naval library. In practice, that meant:

- ****Deep navy tones**** (`#0b1722`) as the dominant canvas, not black and not grey
- ****Parchment type**** (`#f2e9d5`) rather than pure white — softer on dark backgrounds
- ****Brass accents**** (`#b8933a`) for decorative elements, links, and highlights — the colour of a compass or a telescope barrel
- ****Rust**** (`#8b3a2a`) as the danger/alert accent, echoing oxide and blood
- A ****paper-grain texture**** layered over the whole page — a subtle SVG fractal noise overlay at 12% opacity in `mix-blend-mode: overlay`

The grain is a small touch but it does significant work. On a digital screen it suggests physical media without screaming "retro"; it gives the dark background a slight dimensionality, and it helps the archival photographs feel at home rather than floating in a void.

---

### ## Typography

I settled on three typefaces, each with a distinct job.

****Playfair Display**** carries all the display and heading work. It has the editorial authority of a broadsheet masthead, and its high-contrast strokes feel genuinely period-appropriate for a mid-20th-century archive. I set it at negative tracking (`-0.02em`) and a compressed line-height of `0.95` for the hero and section headings — tight enough to feel monumental without becoming unreadable.

****Lora**** handles body copy. It's a scholarly book serif with optical kerning that reads well at small sizes. The slightly warm letterforms complement Playfair without competing with it.

****Oswald**** plays the third role: stencil face. It appears in figure captions, stat ribbons, and navigational micro-labels — the visual equivalent of the stencilled markings on naval equipment. I set it in uppercase with generous letter-spacing, creating a typographic hierarchy that clearly signals "this is data or a label, not prose."

All three are loaded through `next/font` — no flash of unstyled text, zero layout shift.

---

### ## Structure and Navigation

I built the site across eight distinct sections using a flat Next.js App Router structure:

```
app/
  page.js              # home
  top-10/page.js       # 10 ships per nation, UK/USA/Japan/Germany
  museums/page.js      # 12 preserved vessels worldwide
  hms-hood/page.js     # ship profile
  hms-rodney/page.js   # ship profile
  hms-belfast/page.js  # ship profile
  cunningham/page.js   # career timeline
  timeline/page.js     # tabbed battle chronology
```

All editorial content — ship specs, museum descriptions, ranking data, battle events, and image URLs — lives in a single `lib/data.js` file. This was a deliberate choice on my part: it makes the site easy to edit without touching any component code, and keeps the page files clean, acting purely as presentational consumers of structured data.

I kept the navigation minimal: a horizontal bar with an anchor-chain logo mark, the site name in Playfair Display, and eight text links. On smaller screens it collapses gracefully — no hamburger menu tricks, just straightforward responsive stacking.

---

### ## Imagery: Wikimedia Commons and the Fallback Problem

Every photograph on the site loads from Wikimedia Commons — predominantly public-domain Royal Navy, U.S. Navy, and Imperial War Museum photographs. I whitelisted `upload.wikimedia.org` as a trusted image domain in `next.config.js`, and every `Figure` component links back to the source Commons page for attribution.

There was a problem I had to solve, though: Wikimedia Commons URLs occasionally go stale as files are renamed or reorganised, and `next/image` renders nothing at all on a broken URL — not even a visible error.

My solution was a `SafeImage` component wrapping `next/image` with an `onError` handler that swaps in a branded SVG placeholder. The placeholder renders a silhouette of a warship on the navy background with the brass-coloured site wordmark and the text **"Image unavailable"** — so a broken URL degrades gracefully to something that still looks intentional rather than leaving a blank void on the page.

Every ship card image — on the Top 10 rankings, the museum grid, the home section index — has a verified `1280px-` Wikimedia URL mapped in `lib/data.js`. Anyone who needs to update one can replace it with a fresh Commons URL in a single place.

---

### ## The Photography Treatment

One of the smaller but more satisfying decisions I made: applying a CSS filter to every historical photograph through the `Figure` component:

```css
**filter**: sepia(0.25) saturate(0.8) brightness(0.9);
```

It's subtle — not the full sepia treatment you'd apply to deliberately "age" a photograph, but enough to harmonise the varied source images into a cohesive visual language. A 1944 U.S. Navy official photograph and a 1990s museum shot of HMS Belfast tend to have quite different colour casts; this small filter brings them into the same family without destroying their documentary character.

---

### ## The Timeline Section

The most technically interesting page I built was the battle timeline — a tabbed chronology covering three theatres: the Battle of the Atlantic, the Battle of the Arctic, and the campaigns in the Pacific.

I managed the tab state client-side with a simple `useState` hook. Each theatre has an associated loss statistics strip — total ships lost, tonnage, lives — pulled from `lib/data.js` and displayed in the Oswald stencil face with brass rule separators. Below the stats, events render chronologically as a vertical timeline with alternating card positions: date and classification on one side, narrative and imagery on the other.

The human cost data was the most careful part to research and represent. Numbers like 3,500 merchant ships lost in the Atlantic and 36,000 merchant sailors killed deserve to be shown with weight, not buried in a table. I placed the stats strip above the narrative timeline as a permanent header for each theatre, so the reader is always aware of the scale as they scroll through individual events.

---

### ## Lessons

A few things I'd take away from this build for anyone tackling something similar:

****One content file is enough to start.**** Keeping all data in `lib/data.js` felt like a constraint early on but turned out to be a significant advantage during iteration. When image URLs needed correcting or ship data needed refining, I always knew exactly where to look.

****Dark-mode-first is its own design problem.**** Designing on a dark canvas meant rethinking contrast ratios, image presentation, and typography weight from scratch. My temptation was to over-brighten text and accents to compensate; the result looked like a gaming dashboard. Restraint and warm tones (`#f2e9d5` rather than `#ffffff`) turned out to be the answer.

****Texture does the work that illustration can't.**** The paper grain is two lines of CSS and an inline SVG. It contributes more to the archival atmosphere than anything more elaborate would have.

****Historical subject matter demands accuracy.**** Ship specifications, dates, and career timelines are the kind of thing that naval enthusiasts know cold. I source-checked every fact; a wrong displacement figure or a misattributed quote would undermine the authority the design works so hard to establish.

---

**The Naval Archive is a Next.js 14 site using the App Router, React 18, Tailwind CSS 3, and next/font. Images are served from Wikimedia Commons under various public-domain and open licences.**


Building: Iron and Steel


Building *[Iron & Steel](https://ww2-tanks.vercel.app/)*: A WW2 Armour Enthusiast's Website in Next.js

****April 2026 · Design & Development****

---

There's a particular kind of obsession that took hold of me when I started learning about World War 2 armoured warfare. One tank led to another. One battle to the next. Before long I was deep in comparative armour tables, debating whether the Tiger I's 88mm gun was worth its chronic mechanical unreliability, or tracing the T-34's evolutionary line from the BT-7 all the way through to Berlin. **Iron & Steel** started as an excuse to build something for that obsession — and became an exercise in thoughtful frontend engineering along the way.

---

### ## The Concept

My goal was a single, rich reference site covering the major armoured fighting vehicles of WW2 — tanks and tank destroyers — organised by nation, alongside a global museum directory and a historical timeline of key armoured engagements. Not a Wikipedia mirror, but a curated enthusiast's compendium: opinionated, visually distinctive, and fast.

I settled on the following content scope:

- ****60 tanks**** across six nations (Germany, USSR, USA, UK, Japan, Italy) — ten per country
- ****9 tank destroyer profiles**** with full technical specifications
- ****17 global museums**** with location details and Google Maps links
- ****8 timeline entries**** covering key moments in WW2 armoured warfare

---

### ## Design Direction: Military Industrial

My aesthetic brief was unambiguous: **military industrial**. That meant a tight, disciplined colour palette drawn from real-world military hardware — olive drab, khaki, weathered rust, and a deep gunmetal for backgrounds. No pastels. No gradients borrowed from SaaS dashboards. Every visual decision had to feel like it belonged on a field manual or a workshop schematic.

### Typography

Three typefaces do all the work:

- ****Black Han Sans**** — a heavy, condensed display face used for headings and the site name. It reads as monumental without being ornate, which suits the subject matter well.
- ****Barlow Condensed**** — a geometric sans used for UI elements, labels, and navigation. Clean and utilitarian.
- ****Share Tech Mono**** — a monospaced face reserved for specification data: armour thickness, top speed, weight. Monospace for numbers signals precision; it also carries an unmistakeable analogue-instrument quality.

The combination leans into function over decoration, which is exactly right for a site about machines designed to survive shell impacts.

### Motion

I kept animations purposeful and minimal — CSS keyframe scroll-reveal on section entries, subtle lift effects on card hover, and a slow pan on the hero image. Nothing that distracts from the content. If a user has `prefers-reduced-motion` set, the transitions collapse cleanly.

---

### ## Technical Stack

I built the project on ****Next.js 14**** with the App Router, written in TypeScript throughout. Styling is plain CSS with custom properties — no CSS framework, which keeps the build lean and forces every style decision to be intentional.

Data lives in static TypeScript files (`tanks.ts`, `destroyers.ts`, `museums.ts`). For a content set of this size that changes infrequently, a database would be over-engineering. Static data files are trivially auditable, easy to update, and compile-time type-checked.

---

### ## The Image Problem (and How I Solved It)

Sourcing over 70 photographs of WW2 vehicles and museums without licensing headaches meant leaning on ****Wikimedia Commons****, which hosts an enormous catalogue of public domain and Creative Commons military imagery. The challenge: Wikimedia URLs can change, articles get renamed, and some vehicles simply don't have a good Commons photograph.

My solution was a three-stage fallback component — `SafeImage` — that handles failure gracefully at every level:

****Tier 1 — Direct URL.**** Each data entry specifies a `Special:FilePath` URL pointing to a Commons image by filename. This is more stable than hotlinking a specific upload URL, because `Special:FilePath` always resolves to the current canonical file regardless of backend storage changes.

****Tier 2 — Wikipedia REST API.**** If the direct URL fails (network error, renamed file, 404), the component fires a request to the Wikipedia REST API using a `wikiSlug` — the article title for that vehicle or museum. The API returns the article's lead thumbnail, which is almost always a usable photograph.

****Tier 3 — Styled placeholder.**** If both image sources fail, the component renders a CSS-drawn metal-plate placeholder with the vehicle name. No broken image icons. No blank white rectangles. The placeholder is styled consistently with the rest of the UI.

This pattern eliminated all visible image failures in testing, and it degrades gracefully on slow connections — the placeholder appears instantly while image loads are in flight.

One subtlety worth noting: the component initialises its `failed` state to `!src` rather than `false`. This handles the edge case where a data entry has an empty string for its image URL — browsers don't fire `onError` for `src=""`, so without that initialisation the slot would silently render blank.

---

### ## Component Architecture

I composed the page from discrete, self-contained section components:

| Component | Notes |
|---|---|
| `Navbar` | Fixed, collapses to hamburger on mobile |
| `Hero` | Full-bleed image with aggregate stats overlay |
| `TanksByCountry` | Client component — tabbed interface, one tab per nation |
| `TankDestroyers` | Static grid of destroyer cards |
| `Museums` | Client component — filterable by world region |
| `Timeline` | Vertical timeline, CSS scroll-reveal |
| `Footer` | Navigation links and attribution |

I limited client components (`'use client'`) to sections that genuinely need interactivity — the country tabs and the museum region filter. Everything else renders on the server, keeping the JavaScript payload light.

---

### ## Museum Google Maps Integration

Every museum entry in my directory includes a direct Google Maps search link, constructed as:

```
https://www.google.com/maps/search/?api=1&query=Museum+Name+Location
```

This approach requires no API key and no Maps SDK. It opens a pre-populated search in the user's browser or Maps app, which is exactly the right behaviour for "I want to find this place."

---

### ## What I'd Do Differently

A few things I'd change with more time:

****MDX for vehicle write-ups.**** The longer descriptive text for each vehicle is currently a plain string in the data file. Moving it to MDX would allow richer formatting — pull quotes, inline images, footnotes — without giving up type safety.

****Incremental Static Regeneration for images.**** Rather than fetching Wikipedia thumbnails client-side on fallback, a better pattern would be a build-time script that resolves all images and writes a manifest, with ISR to keep it fresh. This would eliminate the client-side fetch entirely and remove the flash of placeholder-then-image on first load.

****Search.**** With 60+ vehicles, a keyboard-accessible search bar filtering across all sections would meaningfully improve navigation. The data is already structured for it — I just ran out of time.

---

### ## Closing Thoughts

**Iron & Steel** is the kind of project that justifies its own existence — a subject I find genuinely interesting, built with tools I wanted to work with, at a scope small enough to finish but large enough to be worth finishing. The image fallback system turned out to be the most interesting engineering problem in the whole build, which is often how these things go: the detail that seems like a footnote ends up teaching you something useful.

The project is available as a zipped Next.js starter for anyone who wants to run it locally or fork it as a template for a similar catalogue site.

---

**Built with Next.js 14 · TypeScript · Plain CSS · Wikimedia Commons**

Adding Latest posts…


Greetings!

In this post we will be building on the site created in the first two articles, and demonstrating the benefit of having re-usable components, to add your latest *Posts* to your home page.

## Steps 1 - Get the correct data

Open your *./pages/index.js* file and add the following to the end of the file.

```jsx
export async function getStaticProps() {
	// fetches all the post data from your published article folder
    const webpackContext = require.context('../posts', true, /\.\/.*\.md$/);
    // console.log('webpackContext', webpackContext.keys())

    // the list of file names contained inside the "posts" directory
    const keys = webpackContext.keys();

	// reverse the array of posts so the newest one is first
    const reverseKeys = keys.reverse();
    // console.log('keys', keys)

    const values = reverseKeys.map(webpackContext);
    // console.log('values', values)

    // getting the post data from the files contained in the "posts" folder
    const posts = reverseKeys.map((key, index) => {
        // dynamically creating the post slug from the file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');

        // console.log('slug', slug)
        // getting the .md file value associated with the current file name
        const value = values[index];
        // console.log('value', value)

        // parsing the YAML metadata and markdown body contained in the .md file
        const document = matter(value.default);
        // console.log('document', document.data)

        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
    // console.log('posts', posts);

	// cut the list of posts down to the first 4 in the array e.g. the latest 4 
    const topPosts = posts.slice(0, 4);
    // console.log('topPosts', topPosts)

	// export the data for the 4 latest posts
    return {
        props: {
            latestPosts: topPosts,
        },
    };
}
```

If you encounter issues I recommend using the console logs, already written in, to see where the issues are.

Assuming there are no errors you are now ready to move on to Step 2.

## Step 2 - Use the data

Now that you have the data for the posts, that you want displayed, it can be used to display on your home page.

There are only a few changes required to do this which are shown in the following code.

```jsx
import Head from 'next/head';
import Image from 'next/image';
import Layout from '../components/Layout';
import Introduction from '../components/Introduction';
import AnimatedSplash from '../components/AnimatedSplash';
// Change 1 - import the BlogList component, if not already done
import BlogList from '../components/BlogList';
import Contact from '../components/Contact';
import styles from '@/styles/Home.module.css';
// Change 2 - import grey-matter
import matter from 'gray-matter';

// Change 3 - change "props" to "latestPosts" to directly access the export data from Step 1
export default function Home({ latestPosts }) {
    return (
        <Layout>
            <Introduction />
            <AnimatedSplash />
			// Change 4 - add the BlogList component and pass in latestPosts
			// consider adding a heading before the component
            <BlogList allBlogs={latestPosts} />
            <Contact />
        </Layout>
    );
}
```

## Step 3 - View the data

Now that we have got the correct data, and passed it into the correct component, we are ready to see the result.

- Navigate to the *root* folder of your project
- Run `npm run dev`
- Now go to [http://localhost:3000](http://localhost:3000) in your browser

You should now see something like the following.

![Latest Posts!](https://res.cloudinary.com/xenos-design/image/upload/v1690470282/Post_Content/nextjs-md-latestPosts/latestPosts_kmlyxv.png)

And that’s it for now… you have now updated your blogging site, using Next’s and Markdown, and enhanced the experience of your readers. Hopefully, you found this article useful and will continue your journey.

Thanks for stopping by…

Filtering your Markdown posts


Welcome back!

Following on from my previous post [Create a NextJS blog using Markdown](https://www.stevengodson.com/blog/2023-06-15-nextjs-md-blog), I will now show you how to add Category filtering to your blog so that your ordinance can choose to see all posts of a particular type.

Before we begin you will need to have followed the installation steps in Part 1 of this series

## Key Files

The key files that we will be updating or creating are as follows.

**./components/BlogFiltersCategory.js** - this is the component that will render the interactive filter choices in the ./pages/blog/categories/index.js page.

**./components/BlogFiltersMain.js** - this is the component that will render the interactive filter choices in the ./pages/blog/index.js page.

The above two components are essentially the same apart from the href in the Link element, which points to different places.

**./components/BlogList.js** - this will need to be updated to show the categories against each posts card in the list.

**./pages/blog/categories/index.js** - this is the page that will filter your posts, based on the category selected, and render the list.

**./pages/blog/index.js** - this is the main blog page which will require minor updates to enable the filtering.

**./pages/blog/[slug].js** - this will need to be updated to show the categories against each post.

**./global.css** - This is where the styling for the dynamic components will be added.

The posts themselves will require an update to include the appropriate data into a unique entry against which the filtering can take place.

## Creating your filter
### Post Meta Data

The first thing that we will do is look at the metadata, which is at the front of each post, and amend it from this:

![Meta Data!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/001_gvyewg.png)

to this:

![Meta Data!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/002_bojc8s.png)

It is worth investing some time to consider what categories you want to use on your posts so that you have as complete a list as possible before we continue.

## Creating new files
Now we will create the new files needed to make this work.
### BlogFiltersMain.js

Create this file in the /.\/components/ folder and copy in the following code.

```jsx
import React from 'react';
import Link from 'next/link';
import Row from 'react-bootstrap/Row';
import Col from 'react-bootstrap/Col';

function BlogFilters() {
    const filters = ['Technology', 'Business', 'Freelancing', 'Personal'];

    return (
        <Row>
            {filters.map((filter, index) => (
                <Col md={6} lg={3} key={index}>
                    <Link href={`./blog/categories?category=${filter}`}>
                        <div className={`filterTag_${filter}`}>{filter}</div>
                    </Link>
                </Col>
            ))}
        </Row>
    );
}

export default BlogFilters;
```

Some key points to explain are:
* I have used /react-bootstrap/ for the row and column control
* There is an array of *strings* in this file, this needs to represent all of the categories that you want to actively use. This has been used in place of a table that would typically be used database or CMS-based blog. To avoid duplication you could store these values in a /.env/ file
* The /href/ in the /Link/ component points to one of the new files, that we will create later in this exercise, and passes in the filter name as a URL query so that it can be picked up from the context using getServerSideProps()
* The className content is also set dynamically with the styling controlled from the /global.css/ file

### BlogFiltersCategory.js

Create this file in the /.\/components/ folder, copy in all of the content from the /BlogFiltersMain.js/ files, and simply change the following.

```jsx
<Link href={`./blog/categories?category=${filter}`}>
	<div className={`filterTag_${filter}`}>{filter}</div>
</Link>
```

to

```jsx
<Link href={`./categories?category=${filter}`}>
	<div className={`filterTag_${filter}`}>{filter}</div>
</Link>
```


### Categories index.js

Now we will create the page where the filtered list will render.

Create the following folder /.\/pages/blog/categories\// and created an *index.js* file.

Now copy in the following code.

```jsx
import React from 'react';
import Link from 'next/link';
import matter from 'gray-matter';
import Layout from '../../../components/Layout';
import BlogList from '../../../components/BlogList';
import BlogFilters from '../../../components/BlogFiltersCategory';
import styles from '../../../styles/Blog.module.css';

function Categories({blogData}) {
    return (
        <Layout>
            <h1 className={styles.heading}>Tales from the deep...</h1>

            <hr />
            <h5 className={styles.heading}>Filter by Category or <Link href="../../blog">Back to Full List</Link></h5>
            <BlogFilters />
            <hr />

            <BlogList allBlogs={blogData} />
        </Layout>
    );
}

export default Categories;

export async function getServerSideProps(context) {

    const { req } = context;
    const passedURL = req.url;
    let filterName = passedURL.split('=');
    filterName = filterName[1];

    const webpackContext = require.context('../../../posts', true, /\.\/.*\.md$/);
    const keys = webpackContext.keys();
    const reverseKeys = keys.reverse();

    const values = reverseKeys.map(webpackContext);

    const posts = reverseKeys.map((key, index) => {
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');

        const value = values[index];
        const document = matter(value.default);

        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });

    const filteredPosts = (posts, filterName) => {
        const data = posts.filter((post) => post.frontmatter.category === filterName);
        return data;
    };

    let data = filteredPosts(posts, filterName);

    return {
        props: {
            blogData: data,
        },
    };
}
```

This file is very similar to the main *index.js* in the ./pages/blog/ folder. 

The key differences are:

* The use of *getServerSideProps* instead of *getStaticProps*. The reason for this is so that we can access the *context* API and pull the filter name that is passed from the filter components. This gets stripped from the request URL and passed into the *filteredPosts* function so the list of all posts can be filtered
* Use of the BlogFiltersCategory.js functionality. This ensures that a user clicking on categories after the initial filter will not be thrown back to the main blog page
* Reuse the BlogList component so there is a consistent look and feel to the site

### global.css

If you want to follow the same styling approach then copy the following into the *./styles/global.css* file.

```css
.tag_Technology,
.tag_Freelancing,
.tag_Personal,
.tag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
}
.tag_Freelancing {
    background-color: #00796b;
}
.tag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.tag_Business {
    background-color: darkblue;
}

.slugTag_Technology,
.slugTag_Freelancing,
.slugTag_Personal,
.slugTag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
    min-width: 250px;
    border-radius: 5px;
    margin-bottom: 2rem;
}
.slugTag_Freelancing {
    background-color: #00796b;
}
.slugTag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.slugTag_Business {
    background-color: darkblue;
}

.filterTag_Technology,
.filterTag_Freelancing,
.filterTag_Personal,
.filterTag_Business {
    text-align: center;
    background-color: var(--secondary-color);
    color: var(--primary-color);
    padding: 0.2rem 0;
    letter-spacing: 2px;
    font-size: 1.5rem;
    width: 100%;
    border-radius: 5px;
    margin-bottom: 1rem;
    cursor: pointer;
}
.filterTag_Freelancing {
    background-color: #00796b;
}
.filterTag_Personal {
    background-color: var(--primary-color);
    color: var(--secondary-color);
}
.filterTag_Business {
    background-color: darkblue;
}
```

If you are using another approach e.g. SASS, Bootstrap, or TailwindCSS then you can skip this section.

## Updating the existing document

Now that we have created the new pages and components we can move on to updating the existing pages and components to bring it all together.

### Blog index.js

Update the *./pages/blog/index.js* page to include the *BlogFilterMain.js* component as shown below.

![Blog Index!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/003_aonw61.png)

### BlogList.js

Now we update the BlogList component to render out the category name that has been added to a blog. I have done this as a conditional statement but, if you are sure it will always be added, you can add it without the conditional.

![Blog List!](https://res.cloudinary.com/xenos-design/image/upload/v1687248085/Post_Content/nextjs-md-filters/004_ua3j8o.png)

### Blog [slug].js

Finally, we will update the page, where all the content of an individual post is shown, to show the category name as well.

![Blog Slug!](https://res.cloudinary.com/xenos-design/image/upload/v1687195278/Post_Content/nextjs-md-filters/005_lww0os.png)

## Let's fire it up…
We are now ready to run the project and see our content. To do this you simply need to:

* navigate to the root folder in your terminal and run `npm run dev`
* open your browser navigate to *[http://localhost:3000/blog](http://localhost:3000/blog)*

The following should be visible on the screen.

![Working Blog!](https://res.cloudinary.com/xenos-design/image/upload/v1687248198/Post_Content/nextjs-md-filters/006_bagl8o.png)

And that’s it for now… you have now updated your blogging site, using Next’s and Markdown, and enhanced the experience of your readers. Hopefully, you found this article useful and will continue your journey.

In the next post of the series, we will be adding further functionality to your main *index.js* page by adding functionality for * latest posts*.

Thanks for stopping by…


Creating a NextJS blogging website using Markdown


Greetings!

In this article, the first in a series, I will take you through creating your own blogging website using the NextJS framework and Markdown files for the content.

A preview of the site can be seen at [https://nextjs-13-markdown-blog-website.vercel.app/](https://nextjs-13-markdown-blog-website.vercel.app/).

The advantage of this approach versus using a CMS backend e.g. Strapi, Ghost etc, is that you can build and deploy your site using Vercel without incurring any costs.

Being open there are limitations / compromises with this model, which I will talk about later on, but having built many CMS-based sites I like the simplicity of this approach.

## Now, let’s get started!

Firstly, you will need to clone the template repo that I have created for this article. This repo contains all you need to get started.

So create your project folder and navigate to it in a terminal. Then run the following.

```
git clone https://github.com/wookiehunter/nextjs-13-markdown-blog-website.git
```

Once the clone is complete, run the following to install the project's dependencies and start the project.

```
npm install && rpm run dev
```

Then, in your browser, navigate to [http://localhost:3000](http://localhost:3000) and you will be able to see the following front screen.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/001_kne8bm.png)

We are now ready to move on and look at the project folder and file structure.

## Project Structure

If you haven’t already, open the project using your chosen Code Editor / IDE. I use [Visual Studio Code](https://code.visualstudio.com/) for all Node.js/ReactJS projects.

### Folder Structure

The repo that I have provided comes with the following folder structure.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/002_ivlaou.png)

/*Components*/ - this is where the reusable React components will be kept.

/*MD\_Templates*/ - used to store any templates that you want to use to create your content.

/*node\_modules*/ - this doesn’t come with the repo as it is created when you run the `rpm install` command.

/*Pages*/ - this is the folder where you create the structure and pages for your NextJs project.

/*Posts*/ - this is where we will store the Markdown documents that will be used for your blog posts.

/*Public*/ - this is the folder where NextJs needs files that will be presented by your website kept, assuming you are not using separate storage or a CDN, such as images and Favicon files.

/*Styles*/ - CSS files are kept here. I have used CSS module files, but you can use any approach you are comfortable with e.g. Tailwind CSS, SASS, or Bootstrap.

/*Utils*/ - used to store utility functions used by your project. I have included one for Google Analytics as an example.

### Key Files

The key files that we will be focusing on are:

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/003_nxeabp.png)

/*Components/BlogList.js*/ - this is the component that will render your list of posts.

/*Pages/blog/\[slug\].js*/ - when you click o a post in your list, this is the page that will control how the post content is displayed.

/*Pages/blog/index.js*/ - this is the page that renders when you click on the Blog navigation link. You don’t need to use this if you want to show all of your posts on your home page pages/index.js

/*Posts/0001-my-first-post.md*/ - example of a post.

/*Next.config.js*/ - we need to add a specific config to this the project works correctly.

## How it works…

### Webpack Configuration

The following needs to be added to the next.config.js file. This allows Webpack to use [raw-loader](_https%3A//www.npmjs.com/package/raw-loader_) on .md files and create the arrays of Posts that you will showcase on your website.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/004_gdpwc7.png)

### Using Markdown to create content

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/005_aepw3c.png)

The above shows the format used in the example Markdown post. There are two key sections in the file.

The first section, shown below, is written in [YAML](https://yaml.org/) and can be thought of as metadata. This specific format is used by the [gray-matter](_https%3A//www.npmjs.com/package/gray-matter_) dependency package and allows us to use dot notation to access the values e.g. frontmatter.title etc.

```yaml
---
title: 'My first post..?'
author: 'Your Name'
date: '2021-06-01T12:00:00.000Z'
hero_image: /magic.png
intro: "I did a thing..."
keywords: ""
read: 3
---
```

/Note: when adding images, you can either point to content in the public folder of the project, as shown in the example, or use a URL to content in a CDN, Image site e.g. [Freepik](_https%3A//www.freepik.com_) or [Unsplash](_https%3A//www.unsplash.com_), or cloud-based storage./

The second section is the content of your post and can be written using Markdown syntax, see [https://www.markdownguide.org/basic-syntax/](https://www.markdownguide.org/basic-syntax/) for a basic guide.

Another key consideration is the naming convention that you use for your post .md files.

The repo that I have provided has the following code, in the /*posts/index.js*/ file, which reverses the array of keys that Webpack creates when it interrogates the /*posts*/ folder.

```jsx
export async function getStaticProps() {
    const webpackContext = require.context('../../posts', true, /\.\/.*\.md$/);
    // the list of file names contained
    // inside the "posts" directory
    const keys = webpackContext.keys();
    // this reverses the order of the posts to show the most recent first or alphabetically descending order
    const reverseKeys = keys.reverse();
    const values = reverseKeys.map(webpackContext);
    // getting the post data from the files contained
    // in the "posts" folder
    const posts = reverseKeys.map((key, index) => {
        // dynamically creating the post slug
        // from file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');
        // getting the .md file value associated
        // with the current file name
        const value = values[index];
        // parsing the YAML metadata and markdown body
        // contained in the .md file
        const document = matter(value.default);
        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
```

This is because I use a naming convention that allows for the newest posts to be shown at the top of the web page (the specific format I use is [yyyy-mm-dd-post-name.md](http://yyyy-mm-dd-post-name.md)). If you want to show your posts in alphabetical or some other order, you can amend the code easily.

Just replace the above with.

```jsx
export async function getStaticProps() {
    const webpackContext = require.context('../../posts', true, /\.\/.*\.md$/);
    // the list of file names contained
    // inside the "posts" directory
    const keys = webpackContext.keys();

    const values = keys.map(webpackContext);
    // getting the post data from the files contained
    // in the "posts" folder
    const posts = keys.map((key, index) => {
        // dynamically creating the post slug
        // from file name
        const slug = key
            .replace(/^.*[\\\/]/, '')
            .split('.')
            .slice(0, -1)
            .join('.');
        // getting the .md file value associated
        // with the current file name
        const value = values[index];
        // parsing the YAML metadata and markdown body
        // contained in the .md file
        const document = matter(value.default);
        return {
            frontmatter: document.data,
            markdownBody: document.content,
            slug,
        };
    });
```

At this point, it would be a good idea for you to create some test posts for yourself.

## Showing your content on your website

Now that we have content we can discuss how it is shown on the website.

There are three files that are key to creating, showing, and reading the posts in this project.

The first two are the blog/index.js file

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830044/Post_Content/nextjs-md-blog/006_wrlcdh.png)

And the components/BlogList.js file

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830043/Post_Content/nextjs-md-blog/007_ql0hpn.png)

The first uses Webpack to get the post data and passes it to the second so it can render on the screen.

/Note: you can easily move the code from the first file to your root index.js file if you don’t want a separate posts page./

The third and final file is /*pages/blog/\[slug\].js*/ which shows all of a post's content, at least that which you choose to show when a post is clicked on in the list.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/008_rep2aw.png)

As you can see this has both the frontmatter data and markdownBody content passed into it so that you have access to all of the content in your .md files.

I have used a combination of react-bootstrap and CSS to create a layout and style the content. As mentioned before you are free to use whatever styling approach works for you.

## Let's fire it up…

We are now ready to run the project and see our content. To do this you simply need to:

* navigate to the root folder in your terminal and run `npm run dev`
    
* open your browser and navigate to /[*localhost:3000*/](http://localhost:3000/)
    

The following should be visible on the screen.

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1686830042/Post_Content/nextjs-md-blog/009_kfxxuk.png)

Now click on the Blog link at the top and…

![NextJS Markdown Blog](https://res.cloudinary.com/xenos-design/image/upload/v1689967164/Post_Content/nextjs-md-blog/11_rv0td8.png)

Your posts are showing on your blog page and the content is accessible.

In Part 2 of this series we will be looking at the filters, discussing how these are used and how best to implement them.

5 things to consider for your business website


As a business owner in this modern world of ours, you want to be able to engage with as wide an audience as possible to maximise your potential revenue.

There are many ways in which you can achieve this but most, if not, in reality, all, rely on having an internet presence. So what should this presence be?

Social media is an obvious place to start. Huge audiences, ready-built platforms, global reach etc. However, whilst social media platforms are superb for marketing and customer/client engagement, they are enhancements rather than a replacement for a website/app.

The benefits of your business having a dedicated website are;

- bespoke styling and theme to match your businesses brand

- having the User Experience (UX) that you need to be driven through the User Interface (UI) that you want

- order lifecycle control from basket creation through to payment and order status management

- integration with your payment service

- you can share specialised content behind a secure login

So you have decided that your business deserves a website. What do you need to consider? the simple answer is \"Lots!\" but there are a number of key areas that will help get you started and ensure success. An overview of each of these areas and what they mean to you is summarised below.

## Where should I host my site?

This decision very much depends on a number of factors.

- how much control do you want to have over the look and feel of your website?

- do you want to build/maintain the website yourself or get a professional to do the work?

- how much traffic are you expecting?

- how frequently will your website structure or functionality, not content, be likely to change?

- what technologies do I want my website built with?

The specifics of which hosting provider you ultimately go with is a decision between you and, assuming you are not self-building, your web developer. The two high-level choices are;

### Hosted Service

This is where you use a service such as Wix.com, GoDaddy.com, WordPress.com et, there are many to choose from, and build your website using their templates, 'wizards' etc.

These are a, relatively, painless approach to building a website, especially for the non-technical, and you can be up and running in a fairly short period of time.

There is, however, a trade-off.

Using one of these services means you have less control over how and where your website/data is hosted, as well as having to live with the constraints that the service provider places upon you in terms of what can and cannot be achieved within their service.

This may be perfectly acceptable to you and your business, especially when starting out where you want something quick and easy, but be mindful of the future when your business is growing rapidly and you need to migrate to a more functionally rich solution.

### Self Hosted

The title of this option is somewhat misleading in that you do not have to build your own data centre, networks etc, rather that you take responsibility, albeit sub-contracted out to cloud providers and professionals, for where and how your website/app is hosted as well as the maintenance of the solution.

This opens up a cornucopia of possibilities and technology choices which, as a business owner, you may not want to spend time on. This is absolutely fine as you can leave a lot of these decisions to your trusted professionals who should be able to guide you down the right path depending on what business outcomes you want to achieve.

There is, of course, a trade-off. See what I did there...

By implementing your website/app in this way it is quite possible that it will be more expensive than using a Hosted Service.

However, the benefits from this approach, which in my experience outweigh the costs, are;

- flexibility

- scalability

- speed of change

- ability to try out new technologies

- ability to swap out providers to get better prices or enhanced services

## Domain name

So firstly \"What is a domain name?\"...

![Domains!](https://res.cloudinary.com/xenos-design/image/upload/v1650973009/Post_Content/web_domain_illustration_15756c7010.png 'Domains')

This is a key decision as the domain name you choose needs to be;

- **Memorable** - choose something that will stick in the memory

- **Meaningful** - relate to your business name or what your business does

- **Available** - you need to make sure that the domain name you want is available

It is also worth considering whether you want to register, although not necessarily use, multiple top-level domains, such as .com, .co.uk, .uk etc.

This is usually done to safeguard your business against competitors from trading under a similar web address and capitalising on your brand and hard work. These can be registered altogether, some Registrars provide bulk discounts, or later on as your business grows.

The one thing to be mindful of is that domain name registration is an ongoing cost, frequency-dependent on which Registrar you choose, and needs to be maintained otherwise you lose rights to the domain name(s) and your website will no longer be reachable.

## SEO / Analytics - putting you on the map, and keeping you there

Search Engine Optimisation (SEO) is all about getting to Page 1 on a Google search (other search engines are apparently available) and can be seen as a form of wizardry at times.

There are many articles that can be found online that go into this subject in much greater depth than I would want to in this article. Suffice to say that there are a few key considerations that you need to give consideration to when thinking about a website/app for your business.

- **Metadata** - this is the, mostly, unseen content in you site that search engines look for and index for users to search against. the main three are;

- **Title** - the text that appears in your browser tab

- **Description** - tells search engines what your site or page is for

- **Keywords** - the words that you specifically would like search engines to include your site in searches for

- **Sitemaps and Robots.txt** - these are files that need to be created and stored in the root directory of your website/app and are specifically there to help search engines by telling what content is important and what can be ignored

All this is great but unless you proactively monitor your performance and adjust accordingly your website is unlikely to rise to the heady heights of Page 1.

There are many, free and paid for, services and tools that will help you do this. My recommendation is that you start off with a free one, such as Google Analytics, and see how you get on before progressing to a paid tool.

If you are time-poor, understandable as you are building the next mega-corporation, then outsourcing this to a professional who will do the monitoring and maintenance for you is a great way to take the stress away.

## Images - stock vs owned

Depending on what your business does or is trying to market with a website then you will need to consider where your images come from and whether you want to pay a license fee or provide your own images, assuming you own the rights to use them and have these on the site.

I always look at it like this.

Am I showing a proprietary product or service that I want to have specific images of on my website?

If **YES**, then either hire a professional photographer to take the images you want (make sure the price includes you owning the right to own/use) or, if you are a budding photographer, take the images yourself and store them securely.

If **NO**, then using stock images, from services such as Getty or Unsplash, is a great way to go. Just make sure you read the licensing terms and understand whether you need to add a 'credit' against each image or somewhere on your website.

**Content / Copy**

Similar to images the written content on your website/app also needs to be considered and either outsourced to professionals or, if you have the experience necessary qualifications/experience/skills, do the job yourself.

Consideration should be given to bringing in professionals for the following areas;

- Legal and Commercial

- Sales and Marketing

- Technical Writing

- Content creation e.g. articles or blogs

## Summary

All of this can seem quite daunting, especially if you don't come from a technical background, so it is always worth speaking with a professional who can guide you through the process and help you make the right decisions for your business.


Securing your Media in WordPress


It may sound like a contradiction, but there are times when you upload content to your web fronted Content Management System but do not want it to be publicly visible.

Business use cases for this scenario include;

- legal services, where the content may be sensitive or covered by legislation such as GDPR
- creative or artistic content, where you have to show your work but do not want anyone to steal it
- members or subscribers only content, where you want to make the content visible to select or fee-paying subscribers

This article will address each of these scenarios and identify options for achieving the desired outcome. The choices I talk about are WordPress specific, but the context and principles are relevant to any technology.

## Legal Services

When your business provides legal services and your CRM uses WordPress, it is vital to keep the documents (images, PDFs) hidden from general view.

If you do not take specific action to secure your data, it will be indexed by search engines and can be accessed via the directory of your website e.g. _<a target=\"\_blank\" rel=\"\" href=\"http://www.example.com/wp-content/[$filename]\">www.example.com/wp-content/[$filename]</a>_.

This means you are unlikely to comply with local data protection regulations e.g. GDPR in the EU. Not to mention being open to litigation from clients who find their data is open to the world!

There are two specific actions you can take to negate these issues. Each has different layers of complexity depending on what needs to be delivered.

## Creative and Artistic Content

If your website is there to showcase your talent you do not want visitors to download it without permission.

Failure to protect your work can have the following consequences:

- Loss of revenue – if you sell your art through your website, and it is not under your control, you are potentially losing revenue.
- Intellectual property – your art is your intellectual property and should be protected against theft.

## Private or Paid for Content

If you produce content and want to monetise it or only make it available to who you want, you need to ensure that it is only accessible to those who should have access.

## So what can you do…?

Depending on your specific use case(s) three options available to you are:

_robots.txt file_

Adding a ‘robots.txt’ file to your website is a way of discouraging search engine crawlers (think leaf cutter ants, collecting info and returning with it to the hive) which URLs on your site they can access.

This is by no means foolproof and is not a guarantee of your content not appearing on search engine results.

**_Redirect_**

Adding redirect functionality to your website is a way of ensuring that direct access to your content, media files etc, is restricted to logged-in users.

In essence, it performs a check against content type and whether the browser trying to access it has an active session. If both conditions are not met, it redirects the browser to a specified URL (typically the home or login page).

This tends to be an “all or nothing” approach and does not differentiate between user roles. It also does not have any impact on search engine indexing.

**_Plugins_**

If you need a more robust solution, then there are plugins available for WordPress that will give you the following:

- Media file protection
- File type protection
- Role-based access to media files
- disable right-click functionality
- Prevent hot-linking to your content
- Enhanced redirects
- Block search engine indexing of media files
- Media file encryption
- Manual or automated creation of private links so you can share media files, with timed expiry capability
- Bulk protection functionality, if you have a lot of existing content you want to protect
- Integration with other plugins to provide enhanced capability

## Summary

Ensuring that your business is compliant with the relevant legislation and industry standards is critical to its continued success in building trust.


Efficiency through automation


In today's fast-paced world, businesses need to have a range of tools to ensure they are current with contacts from potential clients, partners or employees.

A key challenge is the greater the number of tools, the greater the complexity. So how should businesses address this challenge?

A great way to get around this is to integrate priority business systems. This ensures a clear flow of information and alerts to the appropriate communication channels.

I recently completed a project with a fantastic client, addressing this very issue.

Their starting position was quite typical. They had three web forms that sent data to a content management system. The client then took this data and copied it to a CRM. Not very efficient.

![Design 1!](https://res.cloudinary.com/xenos-design/image/upload/v1650975932/Post_Content/JR_1_a51220fe2c.png 'Layout')

Thankfully my client is dynamic and always looking to improve how they work.

This is the point where I got involved with the project. The brief? Integrate our web forms (NextJS/Formik) with our CRM (ClickUp) and messaging tool (Slack).

![Design 2!](https://res.cloudinary.com/xenos-design/image/upload/v1650975858/Post_Content/JR_2_636b77aa4a.png 'Layout')

Once I had reviewed the documentation and experimented with the integration options, the way forwards became clear.

The agreed solution was to integrate the web forms to ClickUp using its REST API to POST the data, as new tasks, to specific 'Lists'.

Then, using its native functionality, integrate ClickUp with Slack so that notifications would be generated, in the correct channels, when a new ClickUp task was created.

![Design 3!](https://res.cloudinary.com/xenos-design/image/upload/v1650975858/Post_Content/JR_3_8fc663b939.png 'Layout')

This took relatively minimal effort. The most time-consuming part was refactoring the functions in the web forms, to the structure for ClickUp and then testing the end to end data flow.

My client was thrilled by the improved workflow and how much time it saved them in manual effort.

Automation can improve customer engagement, improve employee efficiency and reduce operating costs. It doesn't have to be a large project or cost a fortune.

If you want to improve your business's efficiency, get in touch to discuss your requirements.


Using images on your website


It is absolutely true to say that using images on your website is a great way to make it more interesting, break up large sections of text and generally improve the user experience. In this post, I will share some of my experiences to hopefully make you better informed.

## **When should I use images?**

When considering whether an image should be used you should ask yourself the following design question.

_“Will it improve what is already there in some way…?”_

Some great reasons to say yes are:

- You are marketing a product, want to show it off and demonstrate how it works
- You are creating content and want to illustrate it with relevant imagery
- You want to include images that are relevant to your business or brand&nbsp;

If the answer is no, then look no further. However, if your answer is yes, then read on.

## **Where should I get my images from?**

This depends on your answer to the following question.

_“Am I showing a proprietary product or service that I want to have specific images of on my website?”_

If YES, then either hire a professional photographer to take the images you want (make sure the price includes you owning the right to own/use) or, if you are a budding photographer, take the images yourself and store them securely.

If NO, then using stock images is a great way to go. Just make sure you read the licensing terms and understand whether you need to add an ‘attribution’ against each image or somewhere on your website.

Most stock image websites will have ‘free’ content where only attribution is needed as well as ‘premium’ content that you have to pay for on either a subscription or per-image basis.

Examples of stock image sites are:

- [https://www.unsplash.com](https://www.unsplash.com)
- [https://www.istockphoto.com](https://www.istockphoto.com)
- [https://www.stock.adobe.com](https://www.stock.adobe.com)
- [https://www.freepik.com](https://www.freepik.com)
- [https://www.shutterstock.com](https://www.shutterstock.com)
- [https://www.pexels.com](https://www.pexels.com)
- [https://www.gettyimages.co.uk](https://www.gettyimages.co.uk)

## **What is image optimisation?**

Image optimisation is all about ensuring that you only use the largest image needed on your website. The size of an image impacts two things:  
Speed – how fast your website loads when a user has lower bandwidth for their internet connection, and  
Quality – generally the small the image size the worse the quality of the image that is seen.

_Example: a 300 x 300 pixel is unlikely to look great if stretched to 1200 x 1200._

One of the great things about using WordPress is that it will, when you upload an image to the media gallery, automatically create, assuming your image is large enough, a number of different versions of the image in different sizes.

So when you go select an image, to include on a page or in a post, it will present you with these options.

This is the point where you need to think about where you are placing the image and how big it is likely to be on a screen. If the image will be nested within text then there is little point in selecting a high-resolution version. The opposite is also true, if you want the image to be the width of a page you need to select a suitably large image resolution.

If the standard resolutions that WordPress provides, as standard, are not enough do not worry. Custom image sizes can be added with a little development.


Dynamic Metadata in NextJS


## Introduction

If you have ever wondered how you can introduce dynamic metadata into your projects using NextJS, then this article is exactly what you’ve been looking for!

I have recently built this into this very site, which is built using NextJS and Strapi CMS.

The same principle will work with any NextJS project that consumes data from a CMS.

## Getting Started

The first thing I did
approached trying to do this was to ensure that I had the correct setup in my Layout component.

This is the component that wraps all of the content within the pages of this site and uses the Head component of NextJS to allow for the passing of different values for the metadata e.g. title, description and keywords which are the main three used.

![Layout!](https://res.cloudinary.com/xenos-design/image/upload/v1650971173/Post_Content/nextjs_layout_9688014fb9.png 'Layout')

Although it is not essential, it is a good idea to add default props layout values for the metadata that you want to cover. This is shown at the bottom of the screen.

Following that, I updated the [slug] page, which is the page that displays an individual article when you click on the card, specifically where you can see that I find it in the title, description and keywords and pointed the value to 3 unique fields within the post content that is being extracted from the Strapi CMS.

![Layout!](https://res.cloudinary.com/xenos-design/image/upload/v1650971173/Post_Content/nextjs_slug_93d0e48f50.png 'stuff')

This allows me to pass in the values that I want, which are stored within each individual article record in the database.

By doing this you can create unique titles for each of your articles, which allows your audience to save them with meaningful titles without having to type something in.

You can also add in whatever page description and keywords they want, therefore making each individual article more usable to search engines.

Once this was done all I needed to was to create the three fields within the article record structure in Strapi CMS (metaTitle, metaDesc and metaKey). The name of the fields does not really matter, as long as it is meaningful to you and to whoever you may be getting to support implementation going forwards.

## Results

At this stage, you are in a position to test your code works as expected. I recommend using the Chrome dev tools. If you implement this correctly you should see the following:

![Results!](https://res.cloudinary.com/xenos-design/image/upload/v1650971173/Post_Content/nextjs_title_ed9402e5d0.png 'Results')

and

![Results!](https://res.cloudinary.com/xenos-design/image/upload/v1650971173/Post_Content/nextjs_meta_94e4f3704f.png 'Results')

as you will see each of my articles on this site have their own unique titles and metadata.

I hope you found this useful and gives you some inspiration to implement into your own projects. If you get stuck and need some advice for free contact me via email or Twitter.


Intro to Regex


So I thought it was about time I did some discovery and learned about the use of RegEx and what it can bring to a project.

To ensure that I got a structured introduction I undertook the course called **_REGULAR EXPRESSIONS FOR BEGINNERS – UNIVERSAL_** on Udemy by Edwin Diaz, which I thoroughly recommend as Edwin is great at boiling the essence of a topic down into something that is easily understood.

The following are the notes that I took while working through the course along with some worked-out examples, some of which were derived from the course and some of which I’ve implemented in other projects.

Hopefully, this will be of some use to you and give you a broad understanding of RegEx.

I recommend that you use an online tool for working through this as it will help bring it to life. Personally, I use https://RegEx101.com/ as it will work with a number of languages, has a dictionary of syntax and will actually explain to you what your expression is doing as you write it out.

## REGEX OPTIONS

In its most basic form RegEx will match against a specified set of characters within a target string:

Example:

_/car/g_ - will search for every instance of the string “car” within a target string of text.

_/car/gi_ - will do the same as the above but will be case insensitive.

_/car/gim_ - will do the same as above but will search across multiple lines of text.

_/car/s_ - will search within a single line using a full stop/period to identify the end of the line.

_/car/imgu_ - will be case insensitive, search across multiple lines, will search globally and look at Unicode characters.

It is important that you get the setting of these options correct in your expressions to ensure that you're matching against exactly what you want.

## META CHARACTERS

_/c.r/i_ - adding a full stop/period anywhere in your string is essentially adding a wildcard. This means that, under this example, the expression will match against anything that starts with the letter c and ends with the letter r. It will not care if there is a letter or a symbol in between them, so be careful if you specifically want to search for an actual full stop/period.

## ESCAPING

_/c\\.r/g_ - so if you want to search specifically for full stop/period, or if your search string includes something like a “/” because you are searching a URL for example, then you will need to escape that particular character. This is done by adding a “\\” in front of the character so as you will see an example the expression of only return matches to “c.r” some language engines will automatically escape characters so RTFD…

## MORE CHARACTERS

escaping can also be used to match against a whole host of different characters or actions within your RegEx expression for example _/C\\n\\t\\R/_ will specifically look for C, then a new line, then a tab and then an R.

But be mindful that the characters work in different ways depending on what language engine you are working with e.g. JavaScript or.net or PHP et cetera so refer to the documentation.

## RANGES

_[car]_ - treats this as a range of letters to search for and will return every instance of each individual letter.

_[a-z]_ - search for every alphabetical letter and return every match. This is case sensitive so example only search for lowercase letters whereas [A-Z] will only search for uppercase. They can both be combined in the same range. [0-9] will also do the same thing, but for the range of numbers zero and nine. The ranges do not have to start or finish as stated above just as easily be [b-f]&nbsp;for example.

_[abdq]werty_ - search for all of the letters within the range as well as anything that matches “werty”.

The range, start and endpoint can be anything you want it to be as long as it is separated by a [-] within square brackets.

## NEGATION

negation is when you tell the expression to exclude something and this is done using the ^ symbol (shift + 6 on Windows keyboard). An example of this would be _[^cat]_ which would tell your expression to ignore any of the letters within the range.

## SHORTHAND

so shorthand is, and don’t shout at me for this, a bit like a macro or short name function as you can type in \\ followed by a specific character or letter and it will produce the equivalent of typing out a longer expression range. I have added a couple of examples below but for full details refer to the documentation language engine;

_\\s_ - looks for any whitespace character.

_\\S_ - looks for any non-whitespace character.

_\\d_ - looks for any digit.

_\\D_ - looks for any non-digit.

_\\w_ - looks for any word character.

and the list goes on. What is good about this is that you combine them within ranges and negation to make your code shorter.

But be mindful as some of them produce slightly odd results such as _\\b_ which looks at the boundary of what it considers to be a word but will include digits e.g. it would match against all of Lettuce468.

These can also be used to create a pattern against which to match if you need to be very specific, for example;

_[\\w\\w\\w\\w\\w\\w@xenos\\-design\\.co\\.uk]_ would match against my email address, or any email address under the same domain where the word in front of the @ symbol is six characters long.

**REPETITION**

Quantifiers – these are meta characters when added tell you expression to select varying amounts of the character that proceeds it, for example;

_a?_ - will match zero or one of a, where a represents what you want to match against.

\*a\*\* - will look for from 0 to more of a. I have also seen as described as the Greedy quantify because it will match as many times as possible.

_a+_ - will look for one or more of a.

_a{x}_ - will look for the specified number of a where x equals a number.

_a{x,}_ - will look for xc or more of a where x is a number.

_a{x,y}_ - will look for the number of a’s between x and y.

_a\*?_ - This will match a from zero or more times, but as few times as possible. This is known as a lazy or reluctant quantifier.

These can be combined to create an expression that will search for a pattern, an example of this would be _\\d {5}-\\d {4}_ would match any set of values that look like this 12345-6789 an obvious use case for this could be if you’re searching for telephone numbers in a dataset where there is a specified format. The same could obviously be done for text strings as well or indeed combinations of both.

## GROUPING

must be done outside of the character/range set otherwise parentheses will just be escaped, however, characters set/range can be put inside grouping so _([0-9])_ will work but _[()]_ will not.

An example of how this would work is save(d)? which makes ‘d’ optional and therefore would match against both ‘save’ and ‘saved’.

## ALTERNATION

the use of the pipe symbol ‘|’ (shift + \\ on a windows keyboard) effectively works as an OR statement. However, some nuances of it are;

- whatever is written on the left takes precedence.
- global needs to be switched on for it to work.
- it can be used as many times as needed.

A more effective way to use this is to include grouping i.e. (Bat|Super)man will return against both ‘Superman’ and ‘Batman’.

Example to work in – _(\\w+|file\\d {3}\_export\\. file201_export._ remember that the right of the pipe sign takes precedence and will be classed as an eager function as is looking for all words so would return against an underscore but not a hyphen or a full stop.

Alternation can also be used in a nested group i.e. (soup (bowl|spoon)) will return against ‘soup bowl’ and ‘soup spoon’, be mindful of the spacing as this is quite key to a working.

## ANCHORS

_^s_ - will look for the first ‘s’ in a string e.g. it has to be at the beginning of the string.

_s$_ - as above but at the end of the string.

_^[a-z]_ - will look for any texturing that starts with a lowercase letter.

## WORD BOUNDARIES

_\\b_ - this will match up to the boundary of each word or word character.

_\\B_ -&nbsp;this will match twin non-word boundary, which is somewhat confusing, as it will not match on any string of less than three-word characters but on a string of more than three characters it will match as follows ‘test’ as it treats the beginning and the end characters as the boundaries themselves rather than the spaces around them as the boundary.

## BACK REFERENCES

is a way of referring to the string of text or digits within a grouping.

Typically most engines let you save up to 9 back-references, shown as follows day(light) \\1&nbsp;with the ‘\\1’ being the reference to the “variable”. This would only match if the texturing it is searching is written as follows&nbsp;daylight light.

## NON-CAPTURING GROUP

In this example we see yet another way a ‘?’ can be used to do something different within your expression.

(food) and (?:travel) and \\1 will match against “food and travel and food” because is repeating the first variable, whereas&nbsp;(?:food) and (travel) and \\2 will match against “food and travel and travel” because it is repeating the second variable which is travel.

Using the “?:” switches off that variable.

## POSITIVE AND NEGATIVE ASSERTIONS

_[A-Za-z]+(?=,)_ - this will search for any upper or lowercase letter that is followed by a comma.

_[A-Za-z]+(?!,)_ - this literally does the reverse (if != ,) e.g. does not equal comma and so will match every string of upper and lowercase letters that do not end with a comma.

## POSITIVE AND NEGATIVE LOOKAHEAD

_[A-Za-z]+(?&lt;=,)_ - very similar to the previous section except that by adding the “&lt;” you’re telling the expression to look at what comes before e.g. under this example it would look for every texturing that is preceded by a comma.

_[A-Za-z]+(?-_ - again, literally the reverse, where you are looking for everything that is not preceded by comma.

## MULTILANGUAGE SYMBOL SUPPORT

RegEx includes support for Unicode, so no matter what language you are searching against you will be able to use Unicode to create a match in your expression.

You can find the full Unicode listings at [https://home.unicode.org/](https://home.unicode.org/).

If it is to be included it in your ReEex expression as follows \\u2022 using the “\\” to escape the u so that it is turned into the Unicode character.

## EXAMPLES

Password Validation –&nbsp; the following is an example of an expression that could be used to validate against contents of the users chosen password to ensure that it matches against the policy in place on our project.

Expression: _/^(?=.*[A-Z])(?=.*[a-z])(?=.*\\d)(?=.*[!$£#])\\S{5,20}$/gm_

_(?=.\_[A-Z])\\_ – this validates against the password having at least one upper case character.

_(?=.\_[a-z])\\_ – this validates against the password having at least one lowercase character.

_(?=.\_\\d)\\_ – this validates against the password having at least one number.

_(?=.\_[!$£#])\\_ – this validates against password having at least one of the identified symbols within the square brackets.

_\\S{5,20}_ – this validates him the password being a minimum of 5 and a maximum of 20 characters.

Pretty URLs – the following example is something that I have deployed myself and is commonly seen on websites to make the URL in the browser more human readable. This example is specific to PHP running on an Apache server.

**_Step One_** - ensure your Apache server has the rewrite engine switched on.

**_Step Two_** - create a new file called .htaccess in your website’s root directory.

**_Step Three_** - opening with your code editor and add the following:

**_Step Four_** - RewriteEngine on, this switches the rewrite engine on

RewriteRule _^post/(\\d+)$ post.php?p_id=$1 [NC,L]_ -&nbsp;this tells the server to replace anything with a post.php?p_id=$1, where $1 equals the number identified in the group, and replaces it with post/post number e.g.&nbsp;domainname.com/posts/178, with the&nbsp;NC denoting that it is case insensitive and the&nbsp;L denoting but this is the last rule that should be processed.

## SUMMARY

Hopefully, this brief introduction to RegEx has sparked your interest to go and explore more for yourself and understand how this very powerful tool could be used in your projects.

I’ve enjoyed learning about something that seemed to be quite daunting before but now seems quite simple once you understand the syntax.

I have added some references below to language-specific documentation and a couple of tools that I found useful during this learning process.

## REFERENCES AND RESOURCES

[https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/)

[https://www.php.net](https://www.php.net)

[https://RegEx101.com/](https://RegEx101.com/)


Tech tales from the deep...