
When deploying this blog I wanted a quick way to monitor that specific versions of the blog had rolled to the public.
The eventual solution is outlined below.

### Versioning package.json

Using the [pre-commit](https://www.npmjs.com/package/pre-commit) package a hook can be setup that runs prior to any commit.
This looks like:

```json
"scripts": {
  "patch": "npm version --no-commit-hooks --no-git-tag-version patch && git add package*.json",
},
```

- `commit-hooks`: Disable any default node hooks which could interfere
- `git-tag-version`: Creates a version commit and tag - I wanted the version change to be part of the existing commit
- `git add package*.json`: Add the updated versioning files to the commit

### Going Meta

To then display this version as part of the `<meta>` required some small tweaks.

```js title="next.config.js"
const { version } = require('./package.json');

module.exports = {
  ...mdx,
  publicRuntimeConfig: {
    version,
  }
}
```

```tsx title="Layout.tsx"
import Head from 'next/head';
import getConfig from 'next/config'; 

const { publicRuntimeConfig } = getConfig();

const Layout = ({ children }) => {
  return (
    <Head>
      <meta name='version' content={publicRuntimeConfig?.version} />
    </Head>
  );
};
```

And voilà - the version now appears in the header:

```html
<head>
  <meta name="version" content="0.1.65">
</head>
```


The Best Version


Coming from Java the concept of ownership was alien - so to solidify this knowledge I'm going to attempt a brief summary 
in ~5 minutes.

### Ownership

Each variable in Rust has an owner. Once ownership is declared, there is exactly one binding to any given resource[*](#reference-counting).

Once ownership is moved, the previous owner no longer has access.

```rust
let x = vec![1];
let y = x;

println!("{}", x[0])

//: # (error[E0382]: borrow of moved value: `x`)
```

### Copies

Ownership rules do not apply to **primitive** types, or anything that implements the `Copy{:rust}` trait (which gives
a type **copy semantics** instead of **move semantics**).

```rust
let a = 5 as i32;
let _y = a as i64;

println!("{}", a);

//: Finished [] target(s) in 0.65s
```

### Functions

A function can also take ownership of a variable via its parameters.

```rust
fn new_owner(_x: Vec<i32>) {
  // my_vec is now owned by the new_owner function
}

let my_vec: Vec<i32> = vec![1]; // vector containing a single element, 1
new_owner(my_vec);

print!("{}", my_vec[0]);
// error[E0382]: borrow of moved value: `my_vec`
```

Whenever you see `f(value){:rust}` you can know that **f** has received ownership of **value**.

### Borrowing

Instead of taking ownership, a resource can be **borrowed**. Rather than passing by value, we can pass by reference.
The reference borrows ownership of the variable, until the period where it is released again, at
which point the prior owner can manipulate the data.

```rust
fn new_owner(_x: &Vec<i32>) {
  // my_vec is now borrowed by the new_owner function
  print!("{}", _x[0]);
}

let my_vec: Vec<i32> = vec![1]; // vector containing a single element, 1
new_owner(&my_vec);

print!("{}", my_vec[0]);
// Compiles and prints: 11
```

The references are immutable, so changes to internal state are forbidden.

You can take a reference (pointer) to an item, but you have to give it back. In particular, you have to give it back 
before the lifetime of the underlying item expires, as tracked by the compiler.

```rust
fn new_owner(_x: &Vec<i32>) {
  _x.insert(0, 1);
}
// error[E0596]: cannot borrow `*_x` as mutable, as it is behind a `&` reference
```

### Mutable References

A mutable reference allows the mutation of borrowed resources.

```rust /mut/
fn new_owner(_x: &mut Vec<i32>) {
  _x.insert(0, 5);
  print("{}", _x[0]);
}
 
let mut my_vec: Vec<i32> = vec![1]; // vector containing a single element, 1
new_owner(&mut my_vec);
// Compiles and prints: 5
```

#### Key Points

- If you have a mutable reference to a value, you can have no other references to that value.


```rust /mut/1-3
let mut s = String::from("Test");

let r1 = &mut s;
let r2 = &mut s;

println!("{}, {}", r1, r2);
error[E0499]: cannot borrow `s` as mutable more than once at a time
```

- At any given time, you can have either one mutable reference **or** any number of immutable references.

```rust /mut/5-6
let mut s = String::from("Test");

let r1 = &s;
let r2 = &mut s;

println!("{}, {}, and {}", r1, r2);
error[E0502]: cannot borrow `s` as mutable because it is also borrowed as immutable
```

### Lifetimes

Borrowing references to objects and then passing them around can be dangerous. If a resource that has been borrowed
is deallocated by its owner we must ensure that other users can no longer access the value. In Rust this is done using 
lifetimes, which describe the scope of how long a particular reference is valid for.

Lifetimes are defined using the `'a` syntax, which means '*the lifetime a*'. 

```rust
fn hello_world<'a>(x: &'a i32) { ... }
```

The functions seen before have implicit lifetimes provided through a process known as *lifetime elision*.

```rust
fn print(s: &str); // elided (implicit)

fn print<'a>(s: &'a str); // expanded (explicit)
```

#### Structs

`struct{:rust}`s must define explicit lifetimes when containing a reference. This ensures that any reference to internal 
reference data within an object does not live longer than the owner.

```rust
struct Point {
  x: &'a i32,
  y: &'b i32,
}

fn main() {
  let tmp; 

  {
    let x: &i32 = &1;
    let y: &i32 = &2;
    let p1 = Point { x, y }; 
    tmp = &p1.x;
  } // p1 has exited its scope here
  
  println!("{}", tmp); // `p1.x` does not live long enough
}
```

### Smart Pointers

Smart pointer types act similarly to standard pointers, but allow further fine-grained control over behaviour.
When a developer uses memory that contains dynamically allocated data with smart pointers, they are automatically 
de-allocated.

#### Reference Cell

A reference cell is a smart pointer type that executes the borrowing rules at runtime rather than at compile time. 

`RefCell<T>{:rust}` has the following rules:
- If there is no reference to `T{:rust}`, you may get either a mutable or immutable reference.
- If there is already a mutable reference to `T{:rust}`, you must wait until this reference is dropped.
- If there are one or more immutable references to `T{:rust}`, you may get an immutable reference.

```rust
use std::cell::RefCell;
let container = RefCell::new(11);

{
    let _c = container.borrow();
    // You may borrow immutably multiple times
    assert!(container.try_borrow().is_ok());
    // Cannot borrow as mutable because it is already borrowed as immutable.
    assert!(container.try_borrow_mut().is_err());
}
```

#### Reference Counting

Reference counts (`Rc<T>{:rust}`) sum up the number of references made to an object, and where no references exist, the data can be
de-allocated. A reference-counted pointer to an item allows shared ownership of the data, breaking one of the initial rules outlined
earlier, and allowing data leakage within Rust, so must be used with care. 

Graph data structures use `Rc<T>{:rust}`, as multiple edges might point to the same node, and that node is conceptually 
owned by all the edges that point to it.
a
```rust
use std::rc::Rc;
use std::cell::RefCell;

struct Node {
    next: RefCell<Option<Rc<Node>>>,
    val: i32
}

fn main() {
    let foo1 = Rc::new(Node { next: RefCell::new(None), val: 5 });
    let foo2 = Rc::new(Node { next: RefCell::new(Some(foo1.clone())), val: 10 });
    *foo1.next.borrow_mut() = Some(foo2.clone());
    // Node with value 10 <-> Node with value 5
}
```



Rust Borrow Checker in Five


After recently working on some k8's deployments we came across this obscure error when attempting to delete
multiple unneeded `Secret`s generated by `Helm`.

```yaml
Error: trouble configuring builtin PatchTransformer with config: `
path: my_patch.yaml
target:
  kind: ServiceAccount
...
`: unable to parse SM or JSON patch from [my_patch.yaml]
```

Doing some investigation it was discovered that the pretty innocuous patch in question:

```yaml
- patch: |
    \$patch: delete
    kind: ServiceAccount
    metadata:
      namespace: my-namespace
  target:
    kind: Secret
```

was missing a **mandatory** `name{:yaml}` field. I mean, why would you need a `name{:yaml}`? It's just a patch, right? 
Well, apparently not. And turns out the value can be anything you want, so long as it's there...

```yaml
- patch: |
    \$patch: delete
    kind: ServiceAccount
    metadata:
      name: this-can-be-anything
      namespace: my-namespace
  target:
    kind: Secret
```


The Joys of Kustomize Patches


## Starting Point

Don't laugh, the blog started out pretty rough.

![Picture of the Original Blog](/articles/images/original-blog.png)

Moving in to 2023 I felt that I'd reached my mid-blog-life crisis and a refresh was required.

### Migrating to NextJS

NextJS provides a number of advantages over vanilla React:
- Static site generation
- MDX support
- File based routing
- Image optimisation

### Converting to MDX

I've been using MDX for a couple of separate sites I've been building, - and it's made writing
technical prose a breeze. Previewing blog content within the IDE, with images, prior to switching to the browser
reduces time-to-production massively as well.

I decided to combine this with [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote) enabling static processing of
MDX, with numerous plugins applied at compile time (discussed later). The docs themselves do declare:

> if you are trying to build a blog for personal or small business use, consider just using normal html and css.
> You definitely do not need to be using a heavy full-stack javascript framework to make a simple blog.

but where's the fun in being a conformist...


Also, the [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview/) scores speak for themselves, especially
for First Meaningful Paint times.

![Blog Lighthouse Score](/articles/images/blog-lighthouse-score.png)

#### Article Metadata

Another benefit to `nest-mdx-remote` is the metadata being accessible from the markdown file itself, reducing the need
for manual intervention at compile times for display generation, and easy inclusion of article metadata in the HTML headers for SEO purposes.

Mine takes the format below:

```mdxjs {1-6}
---
title: Improving the Blog
description: It wasn't even public
date: '2023-03-03'
category: Technology
---
```

Thanks to `mdx`, alongside these changes I added some flavour for the article summary cards including the [reading time](https://www.npmjs.com/package/reading-time)
for each article (estimates based on markdown text-length), simple date sorting for recent article highlights utilising [DayJS](https://day.js.org/) from the date
metadata, and categories which will be used in future tag filtering.

### Tailwind

`styled-components` is a great library, but with some recent projects I've found it's a bit slower to prototype features,
with each element templated outside the primary render.

```tsx
// styled-component
const Button = styled.button`
    margin: 1rem;
    padding: 1rem;
    @media (min-width: 768px) {
        padding: 2rem;
    }
    border-radius: 0.25rem;
    border: 2px solid blue;
    background-color: blue;
    color: white;
`;

const TestComponent = () => <Button>Hello world!</Button>;
```

Tailwind allows you to quickly prototype inline styling and easily group styling across multiple components.
It's also pretty intuitive, so guessing commands becomes second nature (also has mature IDE auto-completion support).

```tsx
// tailwind
const TestComponent = () => (
    <div className="text-base mg-1 p-1 md:p-2 rounded border-solid border-2
                    border-light-blue-500 bg-blue-500 text-white-500">
        Hello World!
    </div>
);
```

As you can imagine this becomes unreadable when you start to get multiple elements in the tree.

### Plug-wins

I'm implementing both `rehype` and `remark` plugins as part of the site generation:

- `remark-gfm`: Support for advanced Markdown features such as tables and footnotes
- `rehype-slug`: Appends `id` attributes to each heading element
- `rehype-autolink-headings`: Utilises the `id` attribute above, generating direct page section links.
- `rehype-pretty-code`: Code highlighting using the `shiki` library. Not just syntax highlights but line numbers,
grouped highlights, css themes, and markdown metadata.
- `rehype-img-size`: Discussed [below](#image-lazy-loading).

This is all implemented with a config variable:
```tsx
const mdxSource = await serialize(content, {
    ...,
    mdxOptions: {
      format: 'mdx',
      remarkPlugins: [
        remarkGfm,
      ],
      rehypePlugins: [
        rehypeSlug,
        [rehypeAutolinkHeadings, { behavior: 'wrap', properties: { className: ['anchor'] } }],
        [rehypePrettyCode, {
          theme: {
            dark: 'monokai',
            light: 'one-dark-pro',
          },
          keepBackground: true,
          onVisitHighlightedLine(node) {
            // Each line node by default has `class="line"`.
            node.properties.className?.push('highlighted');
          },
        }],
        [rehypeImgSize, { dir: 'public' }],
      ],
    },
  });
```

### Image Lazy Loading

As the website is statically generated, default lazy-loading for `next/image` elements is unsupported.

I've used the `next-image-export-optimizer` package to generate the images at build time, alongside the `rehype-img-size`
plugin. The plugin ensures that the image size can be extracted from the embedded markdown images, whilst the export provides images
in a number of sizes in the *WebP* format. This allows the image to be lazy-loaded by the browser, which can then be replaced
by the high-quality image for the correct page size once fully rendered.

```tsx
const mdxConfig = {
  ...,
  transpilePackages: ['react-icons', "next-image-export-optimizer"],
  images: {
    loader: "custom",
    imageSizes: [16, 64, 128, 256, 384],
    deviceSizes: [320, 640, 1080, 1920, 2048],
  },
  env: {
    nextImageExportOptimizer_imageFolderPath: "public",
    nextImageExportOptimizer_exportFolderPath: "out",
    nextImageExportOptimizer_quality: 75,
    nextImageExportOptimizer_storePicturesInWEBP: true,
    nextImageExportOptimizer_exportFolderName: "nextImageExportOptimizer",
    nextImageExportOptimizer_generateAndUseBlurImages: true,
  },
}
```

```tsx
const components = {
  img: (props) => <ExportedImage {...props} priority={true} placeholder='blur' loading='eager' role='img' />,
};

...
<MDXRemote {...source} components={components} />
```

### Dark Mode

I thought this would be a relatively simple task, but it turned out to be more complicated than I'd anticipated.

The `next-themes` package provides a simple way to switch between light and dark mode, using the `prefers-color-scheme` media query,
and integrates nicely with `tailwind`.

```tsx {1-10}
import { useTheme } from 'next-themes';
import { useEffect,useState } from 'react';
import { RiMoonClearLine, RiSunLine } from 'react-icons/ri';

const ThemeToggle = () => {
  const [mounted, setMounted] = useState(false);
  const { theme, setTheme } = useTheme();

  // Show only when mounted on client, alleviating hydration issues
  useEffect(() => setMounted(true), []);

  if (!mounted) return <></>;

  return (
    <HeaderIcon onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
      {theme === 'light' ? <RiMoonClearLine size={25} /> : <RiSunLine size={25} />}
    </HeaderIcon>
  );
};
```

However, due to the fact that each page is generated from `mdx`, switching the styling is slightly more complicated.

To get around this I added `scss` ensuring that when the `data-theme` is switched, the correct code blocks are
displayed.

```scss {1-12}
html.dark {
  pre[data-theme="light"],
  code[data-theme="light"] {
    display: none;
  }
}

html.light {
  pre[data-theme="dark"],
  code[data-theme="dark"] {
    display: none;
  }
}
```

### Animation

To enter my final form:

![Even Further Beyond](/articles/images/dbz-goku.gif)

I decided to add some eye-candy with [framer](https://www.framer.com/motion/introduction/).

Using the component below I'm able to introduce all 5 readers (generous) of the blog to the near imperceptible movement of a hand.

```tsx
const HandWave = () => (
  <motion.div
    className='inline-block pl-1'
    animate={{ rotate: 20 }}
    transition={{
      from: 0,
      duration: 0.75,
      repeat: Infinity,
      repeatType: 'reverse',
      ease: 'easeInOut',
      type: 'tween',
    }}>
    👋
  </motion.div>
);
```

N.B. to get a slightly more noticeable effect it's also been added to the theme switcher:

```tsx
<motion.div whileTap={{ rotate: 360 }}>
  <HeaderIcon onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>
    {theme === 'light' ? <RiMoonClearLine size={25} /> : <RiSunLine size={25} />}
  </HeaderIcon>
</motion.div>
```

Give it a spin. Pardon the pun.

### Fin

This can all be viewed [on my repository](https://github.com/chrismphilp/philp.io) if you're interested.


Improving the Blog


![Victorian Art Museum](/articles/images/origin-of-sayings.jpg)

The English language is full of nuanced sayings that are used almost imperceptibly every day and a lot of these
have some bizarre beginnings.

### Baker’s Dozen

A baker’s dozen is commonly understood to mean 13. Go back to Medieval England, and we get a some clarity regarding its origins.
Common law dictated that the price of bread was related to the cost of the wheat used in its production.
Any baker found to be selling overpriced buns (having a loaf) was subject to punishment, including large fines and flogging.
Thus, to account for anomalies in the baking process, bakers would bake an extra bap to ensure they were free from prosecution.

### Shambles

A shambles nowadays may be your common reply to the state of the country, but its origins are pretty
grimy. Butchers in the 17th century would display and sell their goods on a table or stall in the street, which was
known as a *shamble*. This led to the collective noun representing the street where butchers operated being known as
the *shambles* (the name survives in many roads to this day). However, as butchers would throw offal (don't ask) into the streets,
the meaning began to be associated with being a place of *untidiness or disorganisation*.

### Humble Pie

In the 14th century the *numbles* was the name given to the less appetizing parts of an animal.
The *numbles* were commonly used as a primary ingredient in pies given their relatively
low cost at the time, sowere often eaten by the lower classes, whilst the upper classes would take the more valued cuts. The adjective
*humble* was derived separately, meaning of lower class. The similarity in the two words likely led to its current
idiomatic meaning – *make a humble apology and accept humiliation*.

![Humble Pie](/articles/images/humble-pie.gif)

### Goodbye

This is relatively simple one, but interesting nonetheless. In the 15th century a common farewell was
‘*God be with thee*’. Over 300 years this eventually got compounded; ‘*God be with yee*’ in the 16th
century; ‘*God b'wee*’ in the 17th; and eventually ‘*Goodbye*’ by the 18th century.

### Beyond the Pale

What we know today as pale (light in colour) is far different from its now obsolete early English meaning – a
stake or pointed piece of wood, also known as a fencepost. In turn the *Pale* began to be associated with
the area enclosed by these pale posts, such as a settlement. Therefore, anyone wanting to go outside of these
safe areas were said to be going ‘*beyond the Pale*’ – to go outside agreed standard of decency.

### Nail Your Colours to the Mast

During nautical battles, the flag of a ship were struck (lowered) to surrender to the enemy – and was customary
for the enemy to direct the cannon towards the ships mast during a battle to disable it. If all the masts
were hit, the captain usually had little choice but to surrender. If however the captain decided to
fight on, the crew were ordered to hoist the colours on remnants of the ships rigging, said to be
‘*nailing the colours to the mast*’.

The first usage is linked to the *Venerable*, the flagship of British Admiral Adam Duncan, at the *Battle of Camperdown* in 1797.
The mainmast of the ship was struck by the Dutch enemy bringing down the ships flag, which could be interpreted by
the rest of the fleet as surrender. Jack Crawford, a sea-hand upon the ship, climbed the remains of the
splintered mast and nailed the standard back in place. With the standard intact, the fleet fought on and the
British were eventually victorious, with the battle penned as the ending of the Dutch dominance at sea and
the beginning of Britannia ruling the wave.

![Jack Sparrow](/articles/images/jack-sparrow.gif)

### Steal Someone's Thunder

Surprisingly, this idiom comes from a real event in the early 18th century. The petulant playwright
John Dennis devised a thunder machine that could be used during one of his plays - consisting of a sheet of tin
being rattled backstage (the joys of pre-television). Unfortunately, the play was a disaster and flopped (who'd have guessed),
yet a few days later he heard his machine in action during a rival performance of Macbeth. Upon the
discovery he shouted

> that is my thunder by God; the villains will play my thunder, but not my plays

### Hair of the Dog

Anyone who’s woken up not knowing where they are has probably heard this one. But its original etymology
can be traced back as far as 2500BC in Northern Syria, from a book in which the God Ilu becomes hungover after a
drinking binge, and the recipe in which he is prescribed consists of ‘*hairs of a dog*’ and an unknown
plant mixed with olive oil (sounds incredible). The belief seems to stem from the idea that being bitten by a rabid dog could be
cured by ingesting a potion containing some of the dog’s fur.

![Dog with Incredible Perm](/articles/images/dog-hair.gif)

### Once in a Blue Moon

It is generally known to mean something highly irregular – originating from a clerical pamphlet
printed in 1528, where one of the characters converses to another

> if they say the mone is blewe, we must believe that it is true

It is likely in reference to the fact that priests at the time expected any statement
they made to their parish to be believed, no matter how farcical (no comment).

However, a blue moon is in fact possible. This occurred most notably after the eruption of Krakatoa in 1883,
when the moon had a blue tinge for almost two years. Large ash particles in the atmosphere
that were released after the eruption, diffracted red light making the moon appear blue or slightly green.
Still, pretty rare.


Welcome to the blog
👋

Recent Articles 📚

Including version metadata in NextJS

Lending you a hand

Sense makes much

It wasn't even public

Bite the bullet and learn something new