
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.


The Origin of Sayings


**Lasers**. Not the type that you saw in those classic James Bond movies, slowly advancing
to the hero's groin. These are known as *Q-switched lasers* and are the most common way to remove
tattoos. Before getting to the removal stage however, it is important to understand how tattoos
remain in the body.

Tattooing involves inserting ink into the dermal tissue layer of the skin (found under the epidermis – the
outermost layer of the skin). Once the ink has entered - normally using a tattoo needle - the pigment begins to
disperse itself through the epidermis and the upper dermis. Once it has entered these layers of the skin, the
body sends out some of its billions of personal protection operatives for foreign agents – Brex... no, *Phagocytes*.

The main function of *Phagocytes* within the human body is to protect from harmful particles, and are
essential for shielding the human body from infections and providing subsequent immunity. They are attracted to
foreign particles by chemical signals released by bacteria or other *Phagocytes*, and when eventually
coming into contact with their target, they bind, and then engulf them. Herein lies the problem; the ink
particles are too big to be ingested by the Phagocytes, so instead are held in stasis in the layers of skin by
its *collagen* network (the skins main structural protein).

So now you may be beginning to get an inkling as to how tattoos can be removed. The aforementioned
*Q-switched lasers* emit a centralised burst of light, targeting a specific spectrum of colour represented
in the tattoo. This means that for tattoos with differing colours, multiple lasers must be used (looking at you Ed Sheeran).
The laser is fired at these pigments, and as it hits, they are heated up by thousands of degrees, eventually
emitting the contained energy as a shockwave in a process known as *Photothermolysis*. The shockwave
ripples through the dermis of the skin, causing weaker structures to break apart – such as the ink particles -
while larger, stronger ones, merely vibrate. Once the tattoo pigment has been broken up into small enough fragments,
the Phagocytes can then fully engulf and dispose of them. The whole process can take 6-8 sessions of laser
removal for a normal-sized tattoo, and up to 10 sessions for larger tattoos.

So, given the fact that over 1 in 4 individuals are reported as regretting ever getting a tattoo, there’s hope
on the horizon for your mate Dave with his ‘*NO RAGRETS*’ motif across his chest can still have some optimism.

> 3235*BC*: The oldest discovery of tattooed human skin to date is found on the body of Ötzi the Iceman.


The Wonders of Tattoo Removal


## The Formation of Clouds

Ever wondered how these wondrous 500,000 tonne masses (~3,000 houses) form and travel across the skyline each day? How come they
don’t seem to shrink when it rains? Why do they appear angelically white? All great questions, so let’s break it
down.

Clouds primarily consist of water droplets and ice crystals, small and light enough to float in the air; but how
did the water vapour get up there in the first place?

When water particles are heated to a sufficient degree, they evaporate into a gas known as water vapour.
During this transformation, the water vapour is able to absorb heat particles from
their surrounding area, cooling the original source down in the process. However, there's an issue. Air can only hold a
specific amount of water vapour at any given time, dependent on its temperature and weight – known as
atmospheric pressure. However, once it reaches its maximum threshold – known as the dew point - if a drop in temperature
or atmospheric pressure occurs, the only option is for this water vapour to convert from gas to liquid, via the
process of condensation.

The newly condensed water particles can cling onto the billions of tiny particles that are travelling in the air
at any given time, usually a piece of pollen or dust, collecting at a central point known as the condensation
nuclei. These small masses have a radius between a few microns (thousandths of a millimetre) to a few tens of
microns. When billions of these particles collect together they form a cloud. As these particles are so
minuscule, they are lightweight enough to not have any appreciable fall velocity, meaning they remain floating
in the air.

### Fogging Up

This however, still doesn't explain how rain-showers occur. As the water droplets in a cloud collide whilst
moving in the air, they start to gain greater mass up to a tipping point where they are no longer able to freely
float in the air and gravity begins to take control. If these droplets are sufficiently large enough when
leaving the cloud (0.1 millimetres in diameter) they can survive the fall to earth without evaporating in the
process. Yet, this only results in what we recognise commonly as drizzle in Europe.

Surprisingly, temperatures at cloud level are usually below 0ºC, yet the water droplets can remain in liquid
form by a process known as super cooling. This is because water can exist as liquid if there are no nucleation
centres – points for it to condense at. However, small collisions or the presence of a suitable ice nuclei can
cause the water droplets to freeze solid. Water vapour can more easily condense onto these frozen particles,
allowing them to grow faster than their surrounding compatriots and in turn fall sooner. As they fall through
warmer layers of the air they begin to melt, and eventually reach the ground as heavy rain. Amazingly, if these
particles form in a sufficiently thick cloud they can reach the ground before melting, leading to what we refer
to as hail or sleet.

### Why are they whiter than white?

Now onto the final question, why do they appear white? The primary reason is that light transmitted from the sun
is white. To expand further, visible light travels as a wave (part of the electromagnetic spectrum); which when
spread out – such as a rainbow - allows us to perceive every viewable colour (disregarding black as that occurs
through the absence of colour). Each of these visible colours has a different wavelength (e.g. blue has the
shortest wavelength at around 400 nanometres, whilst red is the longest at 700 nanometres). Smaller particles
are able to scatter shorter wavelengths present in the atmosphere around 16 times more efficiently than longer
ones – making the sky appear blue, whilst larger particles such as water droplets scatter all wavelengths
relatively equally meaning no colour predominates, known as Mie Scattering. This means that to the
human eye, clouds appear white.

This may raise one final question. So why do some clouds (normally before it rains) appear grey? When light
initially hits the water droplets gathered in a cloud, the light particles reflect back towards the sun or
scatter to the sides of the cloud, making the base (the perceivable side from the ground) of the cloud appear
grey. This is accentuated in rain clouds, where the condensation nuclei are larger, meaning less light from the
sun reaches the bottom of a cloud. This explains why if you’ve been on a flight, as the plane reaches its
maximum altitude all the clouds below appear to be pearly white.

So next time you’re on the way to work on a rainy day, you can give the scientific explanation to your boss as
to why you’re soaked through.

#### Clouds in History

> Clouds began to appear on items produced during the Zhou dynasty, considered to be a symbol of good fortune in China.

> Greek philosopher Aristotle wrote Meteorologica, in which precipitation and the clouds from which precipitation fell
were called meteors, originating from the Greek word meteoros, meaning `high in the sky` and from this the modern term
meteorology, the study of clouds and weather.


A brief overview of the formation of clouds.

Every Cloud Has a Silver... what?


Git as a version control system has usage across the world, but many developers still limit themselves, staying
within mainstay commands. This article will investigate these litany of commands, and hopefully increase your
understanding and productivity.

### Merge

For example, take a common development team example. A team member has created a branch from **master**, and
added new functionality to print their name when the application runs. While the developer has been doing this,
the master branch has been advanced with 5 more features, leaving the new feature branch out-of-sync. A common
practice is to therefore run **git merge**, creating a new single commit in the feature branch, which
collects all the commits made since the feature branch was diverged from **master**.

This does have its pitfalls though. Given a large team where changes are consistently being pushed to the
**master** branch, the feature branch will have a high number of merge commits polluting its history. This
can be filtered away with an advanced **git log**, but without it, it may be confusing for other developers looking
at your code to quickly understand where changes were made.

![Git Merge Example](/articles/images/git-merge.svg)

### Rebase

Rebasing is the process of moving or combining a sequence of commits to a new base commit. Similar to merge,
**rebase** can be used to integrate changes from one branch, into another. However, unlike merge (which is a
non-destructive operation), rebase is used to move the entire **feature** branch, to the tip of the **master** branch,
incorporating all the previous commits from the **master** branch. This removes the need for unnecessary
commits from a merge, leaving a linear project history.

![Git Rebase Example](/articles/images/git-rebase.svg)

#### Pushing

However, any complex operations that squash commits, or reset/rebase your branch require a force push to the remote
branch.

Therefore, you can run:

```bash
git push --force origin my-feature-branch
```

However, when working on shared branches this can potentially overwrite changes made by other contributors.

A safer alternative that does not overwrite any work on the remote branch is:

```bash
git push --force-with-lease origin my-feature-branch
```

### Squashing Commits

There are times when you realise after you've committed a new feature, you still need to make some changes.
Commonly, a developer will make the change, and commit it to the branch, like so:

```bash
$ git log
commit d84b3e1f899d48c49e8f513302293ff36d1b0421 (HEAD -> master)
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:46:45 2020 +0000

    [master] | Removing unused line

commit 6a4e34b35dd3d5cd6e3fe34df9e04b3f80be0b85
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:46:06 2020 +0000

    [master] | Furthering altering Git instruction

commit bd0a16d1ffbaba26aa2a3e3715eba19503b4c190
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:45:46 2020 +0000

    [master] | Altering Git instruction

commit 0db3d898d87770b47a85c56c61a46bc46343e30a
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:38:59 2020 +0000

    [master] | Adding initial Git article
```

This has needlessly increased the size of the git history, with lots of commits adding nothing. In this case
it is preferable to combine commits `d84b3e`,`6a4e34b`, and `bd0a16d`. A commit
squash or fix can therefore be performed. This involves moving the commit/s into their parent node in the commit
tree. A **squash** will aggregate the commit messages of the combined commits, whilst a fix will
ignore them completely.

As a side-note, rebasing does not actually alter the already made commits (as this is not possible in **git**
through common commands), it creates new ones whilst removing any references to the old ones.

```bash
$ git rebase -i 0db3d898d87770b47a85c56c61a46bc46343e30a
pick bd0a16d [master] | Altering Git instruction
f 6a4e34b [master] | Furthering altering Git instruction
f d84b3e1 [master] | Removing unused line

$ git log
commit dc08bbe95d71a0079f080d326376e2029f11ce3f (HEAD -> master)
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:45:46 2020 +0000

    [master] | Altering Git instruction

commit 0db3d898d87770b47a85c56c61a46bc46343e30a
Author: Christopher Philp <email>
Date:   Wed Dec 16 14:38:59 2020 +0000

    [master] | Adding initial Git article
```

Here we can see from the **git log** that `d84b3e` and `6a4e34b` have been now moved inside `d84b3e`.


What a Git


## Optional Chaining

Optional chaining allows expressions to only run until the point one of the accessed fields is equal to `null{:js}` or `undefined{:js}`.
This is through the use of the `?.{:js}` operator - *optional property access* -
allowing anything expressed on the right of the question mark to continue executing, until `undefined{:js}` or `null{:js}` is encountered.

```js
let y = null;

// x === undefined
let x = y?.z.execute();

// Identical to the above
x = (y === null || y === undefined) ? undefined : y.z.execute();

y = {
  z: {
    execute: () => 5
  }
}
// x === 5
x = y?.z.execute();
```

The new operator is less verbose and more readable. Optional chaining can also be
used in two further areas – optional element access and optional calls.

### Optional Element Access

The optional chaining operator can be used when accessing to non-identifier properties. For instance if
accessing an index of an array.

```js
// New operator usage
return arr?.[0];
// Previous approach
return (arr === null || arr === undefined) ? undefined : arr[0];
```

### Optional Calls

These allow us to conditionally call expressions if they’re not returning `undefined{:js}` or `null{:js}`.

```js
let y = {
  z: {
    execute: undefined
  }
}

// x === undefined
let x = y.z?.execute?.();

y.z.execute = () => 5;

// x === 5
x = y.z?.execute?.();

y.z.execute = 5;

// This will still result in a type error
x = y.z?.execute?.();
```

## Nullish Coalescing

Nullish coalescing requires the use of the `??{:js}` operator and is used to fall back to a default value
when similarly dealing with `undefined{:js}` or `null{:js}`. The operator states that the value on the left of `??{:js}`
will be used if not equal to `undefined{:js}` or `null{:js}`, else use the expression to the right. See the example below:

```js
let y = null;
let z = 5;

// x === z === 5
let x = y ?? z;

y = 55;

// x === y === 55
x = y ?? z;
```

The `??{:js}` operator can replace uses of `||{:js}` when trying to use a default value, which gives better behaviour for falsy values.

```js
// ?? is better than using || as it avoids falsy behaviours
let x = 0;
let y = 0.5;

// total === y === 0.5 -> unlikely to be intended
let total = x || y;

// total === x === 0
total = x ?? y;
```

## Combining the two operators

Finally, the two operators can be combined to set a default value when `undefined{:js}` or `null{:js}` are encountered.

```js
let person = {
  name: 'Chris',
  details: undefined
};
let x = 5;

// personsAge === x === 5;
let personsAge = person.details?.age ?? x;
```

*Hopefully* you've learnt something new, or if not confirmed your understanding of operators that you use in
your daily development.


A quick look at some of the new features in TypeScript 3.7

TypeScript - Let's Learn


## Introduction

C and C++ unlike a lot of other languages provide the ability to directly interact with hardware memory -
normally described as a middle-level or systems language - through the use of
*pointers*. Every variable declared in any language has a memory location, and every memory location has an
address used to locate it. C++ gives you the power to directly modify this memory.

### Accessing Memory

In C++, the *memory address* (where a value lives) of a variable can be accessed through the
`&{:cpp}` operator - see the example below.

```cpp {1-3}
std::string food = "Pizza";
cout << food;  // outputs the value of food (Pizza)
cout << &food; // outputs the memory address of food (0x6dfed4)
```

### Pointers

A pointer on the other hand, is a variable that *stores the memory address of a variable as its value*, and
is created using the `*` operator. A pointer can exist for *any data type*, as it merely points to a memory address of the variable.

```cpp {1-9}
int x = 5;
int* y = &x;
// Equivalent to
int *y = &x;

cout << x; // outputs the value of x (5)
cout << y; // outputs the memory address of x (0x6dfed4)
cout << &y; // outputs the memory address of y (0x6ffd4)
cout << *y; // outputs the value of x (5)
```

### Arrow Operator

The arrow operator is a shorthand method for accessing the contents of a
`struct` or `class` *pointer* - normally the `.{:cpp}` operator would be used for non-pointer
access. The example below shows the equivalences.

```cpp {1-15}
class Rectangle {
  int width, height;
  public:
  void set_values (int,int);
  int area (void);
} rect;

Rectangle* p_rect = &rect; // creates a pointer to the rect declared above
p_rect->area;
// This is equivalent to
(*p_rect).area;
```

### References and Pointers

By default, arguments to a function in C++ are passed by value, and the changes made to any arguments inside the
function will not affect the original value, and instead are made to a copy. The 3 primary ways to pass arguments
are shown below.

#### Call by **value**

```cpp {1-7}
int square1(int n)
{
  cout << &n; // outputs the memory address of n (0x6dfed4)
  n *= n;
  // original n is unchanged - a copy of n has been created,
  // only the n inside the function is altered
  return n;
}
```

#### Call by *reference with a pointer argument*:

```cpp {1-12}
int x = 5;
int *p_x = &x;
square(p_x);

void square(int *n)
{
  cout << n; // outputs the memory address of n, which is the same as x (0x6dfed4)
  *n *= *n; // deferences to get the value at the memory address of p_x,

  // updating the value stored there
  cout << *n; // outputs the squared value of x (25)
  cout << x; // outputs the altered value of x (25)
}
```

#### Call by *reference with reference argument*:

```cpp {1-15}
int x = 5;
square(x);

void square(int &n)
{
  // inside the function, the reference is used to access the
  // actual argument used in the call
  cout << &n; // outputs the memory address of x (0x6dfed4)
  cout << n; // outputs the value of x (5)

  // Implicit de-referencing (without '*')
  n *= n;
  cout << n; // outputs the altered value of n, which is equal to x (25)
  cout << nx; // outputs the altered value of x (25)
}
```

### Benefits of Pointers

There are a number of benefits to using pointers:
- Values that are passed in to a function do not have to be copied, especially useful with large objects.
- They allow more than one value to be returned from a function.
- Memory access through pointers is stated to be more efficient than through an array.

```cpp {1-15}
int x = 5;
int y = 55;
int *p_x, *p_y = &x;
edit_two(*x, *y);

void edit_two(int *x, int *y)
{
  *x += 5;
  *y += 5;

  cout << *x; // edits the value at the memory address of x (10)
  cout << y*; // edits the value at the memory address of x (60)
}
```

Hopefully this has cleared up any confusion surrounding pointers, and you can begin to understand those
insufferable `nullptr` exceptions.


C++ - An Introduction to Pointers


We’ve all done it. After a late night of tossing and turning, you wake up blurry-eyed and aggravated.
There's only one thing that's going to get you through a 9A.M. stand-up; a steaming cup of tea or coffee to kick-start your day.

However, have you ever thought about the chemical reactions that mug is having on your body?

As you traverse through the average day your Central Nervous System (CNS) releases a neurotransmitter called *adenosine*,
which, as one of its many functions, regulates your sleep-wake cycle by slowing down nerve activity. With a sufficient
build-up of adenosine within the brain, it begins to signal a feeling of fatigue to the rest of the body.

### So how does caffeine alleviate this?

Consumed caffeine is absorbed by the body’s small intestine and passed into the bloodstream. Due to its structural makeup –
being both water and fat soluble – it is able to penetrate the blood-brain barrier.

Caffeine’s molecular structure closely resembles that of *adenosine*, enabling it to lock and block the brains adenosine receptors,
acting as a competitive inhibitor. This intensifies cellular activity within the body, simultaneously increasing the body’s heart and breathing rate.
Additionally, the activation of neural circuits within the brain causes natural stimulants such as adrenaline and dopamine to be released.

After a period of continuous coffee consumption however, the brain grows additional adenosine receptors to try and maintain equilibrium.
Understandably, more caffeine is required over time, to block a number of the newly grown receptors to produce a similar desired effect.
