kristianfreeman.com

Sleepy time tea

2024-10-11T19:04:41.744497+00:00

My current recipe for tea at nighttime. It tastes good, and knocks me out about 30-60min after I drink it.

Anecdotally, this has also seemed to increase my time in deep sleep via my WHOOP, but I haven't tracked it well enough to know for sure. The "you had extra deep sleep last night!" notification seems to be firing pretty regularly since I started making this recipe about a week and a half ago. Great!

Recipe

1 chamomile tea bag (link)
5g glycine (link)
3.5g magnesium glycinate (link)
A2 whole milk
Raw honey, to taste (link)

Update

This is working! My WHOOP score has definitely improved. Still the same recipe I wrote about in the original post.

The sleepy time tea is a winner

Tracked as “magnesium supplement” in WHOOP because they don’t allow arbitrary stat tracking

Recovery is up 5% and I’m hitting 100% sleep most nights (blank night from when I lost my charger for a day!)https://t.co/K5uXOWNA51 pic.twitter.com/04D7Hb2AIt
— Kristian Freeman (@kristianf_) October 11, 2024

Building your own radio network with Liquidsoap

2024-10-10T15:00:13.350584+00:00

With a ton of archived music and podcasts sitting on my NAS, I wanted to do something fun and run my own radio network - a collection of radio stations like "Business Podcasts", "Metal", and whatever else I might want to listen to. Then, I can tune into it at any point of time via my phone or on my Sonos speakers.

You can build this with Liquidsoap - described as "a powerful and flexible language for describing audio and video streams".¹

I've created an open-source repository kristianfreeman/radio that will help you do this.

First, you can set up a config.yaml:

stations:
  # Podcasts
  - name: comedy
    directories:
      - "/podcasts/comedy-podcast"
    shuffle: true
  - name: business
    directories:
      - "/podcasts/business-podcast"
      - "/podcasts/business-podcast2"
    shuffle: true
  - name: business_focus
    directories:
      - "/podcasts/business-podcast"
      - "/podcasts/business-podcast2"
    music_directories:
      - "/music/bgm"
    podcast_volume: 0.7
    music_volume: 0.3
    shuffle: true
  # Music
  - name: edm
    directories:
      - "/music/techno"
  - name: metal
    directories:
      - "/music/metal"

This example shows a few varieties of stations. You can name each station, and pass a directory of audio files to load. Liquidsoap will recursively search the directories and add the files inside to the station (and shuffle them, via the shuffle param).

My favorite is the hybrid music/podcast station. It basically muxes music and podcasts together on the fly - so you can build fun mixes. For instance, I have a bunch of chill vaporwave/focus music mixed with business podcasts.

With your config.yaml set up, you can run make to run the build script. It's a Python script that parses the config and outputs a .liq file for Liquidsoap. That file gets executed by Liquidsoap, and your radio stations will begin!

The Liquidsoap server runs a server called "Harbor" that outputs all the stations on a single URL structure:

localhost:8000/business
localhost:8000/comedy
localhost:8000/metal

With those URLs, you can plug them into VLC, iTunes, or add them on your Sonos app, and start streaming!

Liquidsoap is really funky. This post isn't a tutorial on it. I used ChatGPT to help me write the code.↩

My morning coffee

2024-10-09T15:00:23.180186+00:00

My morning coffee:

Freshly ground Medium roast Ruta Maya coffee¹ brewed with Aeropress²
1 scoop collagen peptides³
~5-10g creatine
~300-500mg pure L-theanine⁴ powder
1000 IU vitamin D3 + 200 micrograms vitamin K2⁵

This is a follow-up to my sleepy time tea recipe!

I emailed the address on the website to ask about testing, particularly around mycotoxins. The email bounced 💀↩
No special process here. There is a whole world of Aeropress brewing, but I just stick with the normal process as laid out in the instructions.↩
Before we were more conscious of ingredients, we had an Amazon subscription for some randomly sourced collagen. At some point, when we run out of our supply of collagen, I'll switch to a more legit/high-quality source.↩
This is new to my recipe, but the interactions between L-theanine and caffeine are well-defined: less jitters, pure caffeine buzz. It's great!↩
I have an Athletics Green-provided supply of this that came with my old AG1 supply. It's a droplet that is completely easy to over-dose - bad design. Another "I'll use it until I run out of it" thing.↩

Defer loading CSS files with one line of code

2024-10-08T21:16:19.798580+00:00

Here's how to defer CSS loading with one line of code, no extra dependencies needed:

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

We're setting the media property here to "print", meaning that it's only relevant when printing this page. But when onload fires, we change the media property to all - meaning it's relevant to the page again. The browser will then load the CSS. It's a tricky but effective way of deferring CSS until after page load.

Increasing Lighthouse score to 100 - how I did it on my blog

2024-10-08T21:14:50.571396+00:00

I know, I know - on a static site, a blog. It's not an incredibly demanding site, by any means. But the same strategy to improving perf applies on larger sites. Here's how I hit 100 on Performance stat for this site.

If you have direct control over the scripts and CSS you run on your site, you're in a good spot. It's pretty likely that Chrome's "Eliminate render-blocking resources" guide is going to be your best friend here.

On this blog, I had a few scripts and stylesheets running: particularly, littlefoot for footnotes, and instant.page to allow instant page loads. Adding async to these script tags and deferring the CSS load was the bulk of changes I needed to make directly on the site.

The print media trick for CSS works well here:

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

We're setting the media property here to "print", meaning that it's only relevant when printing this page. But when onload fires, we change the media property to all - meaning it's relevant to the page again. The browser will then load the CSS. It's a tricky but effective way of deferring CSS until after page load.

I also did some work on my Cloudflare config for this site to improve time to paint metrics. You can see in the below chart when I turned on caching at the Cloudflare level for my site:

I created a rule that is literally just "Cache Everything"¹, with a 60 second time-to-live setting. That means that my site is basically on a rolling sixty second cache, at the edge server level, not at the browser. bearblog doesn't seem to have any caching headers included, so instead of trying to lean on it for any sort of knowledge about when and why to cache, this implementation is simple. When a page is hit, it refreshes the cache, then serves out of it for a minute. After a minute, the cache is restarted. I have Cloudflare's "stale while revalidate" param set to true, so it serves stale content while it refreshes the cache.²

There's more work to do with SEO, but the site feels super fast. As more traffic comes here from my SEO experiments, it will be satisfying to know that the site is really fast, no matter where you're accessing it from.

Cloudflare, having a massive CDN after all, has a ton of docs around caching. Available here.↩
It's a blog! It's not a big deal to serve stale content. YMMV.↩

Understanding Astro's getStaticPaths function

2024-10-08T21:30:17.964882+00:00

getStaticPaths is the secret sauce for one of Astro's main tricks: generating static pages for dynamic routes.

Imagine we have a blog with three posts (slugs defined below):

hello-corgi
building-chatgpt-for-corgis
addressing-the-haters

Given an index page to list all of our blog posts (/blog), we have four routes in total.

In Astro, we would define two page files in src/pages to handle these:

src/pages/blog.astro - render the /blog page
src/pages/blog/[slug].astro - render a blog post, at /blog/:slug

By default, the blog post page is dynamic. If your Astro app gets a request to /blog/hello-corgi, it will look through the routes it knows about, and generate the blog post page.

That's great! File-based routing is incredibly easy to implement.

But what about if we want to know about those pages ahead of time? We already have src/content/blog/hello-corgi.md and so on - we know these routes will always exist. Couldn't we optimize by making those pages static?

This is where the getStaticPaths comes in handy. First, we'll indicate to Astro that we want this blog post page to be static, by setting the prerender attribute to true. Second, we'll get all of the blog posts, and export a list of static paths, based on the slug:

---
export const prerender = true
import { getCollection  } from "astro:content";

export async function getStaticPaths() {
  const blogEntries = await getCollection("blog");
  return blogEntries.map((entry) => ({
    params: { slug: entry.slug },
    props: { entry },
  }));
}

// Do other stuff to render the blog post
---

By implementing static paths, the Astro build engine can generate these pages ahead of time.

This gets even cooler when you introduce headless CMS tools like Sanity.io. You can have all of your blog posts live in a CMS, but when it comes time to build the site, you can make an API call at build time, grab X number of posts, and build X number of static pages.

Another place this can be helpful is with building sitemaps. When I first implemented a sitemap for Gangsheet, I noticed it had every page... but my blog posts. Because these were dynamically generated and rendered, they weren't able to be added onto the sitemap.¹ By adding getStaticPaths to my blog post page, and prerendering it, I was able to see it show up on the Gangsheet sitemap.

Most crawlers are pretty smart nowadays. If the blog post is linked somewhere on the site, the average Google/whatever search engine crawler can still render JS apps and grab the URLs as needed. But I'm old-school!↩

Releasing my bearblog Chrome extension

2024-10-08T16:30:13.729472+00:00

I wrote a quick Chrome extension¹ that makes it easier to navigate when working with bearblog.

Features:

Switcher for navigating between multiple bearblogs
Quick shortcuts for navigating to some of the most busy pages in the admin (Nav, Posts, Theme, etc.)
Auto-loading toolbar on your custom domain - think the WordPress navbar that shows up when you're authed on your WordPress site, and looking at the frontend

The dev toolbar that shows up on both bearblog.dev _and your custom domain._

The settings popup that you can use to set up your sites.

You can find the release here. Grab the ZIP and "Load unpacked" in your Chrome extension settings.

At least, it should have been quick. I tried to get it working on Safari, which was a terrible experience. The bulk of the code was quick to write.↩

How to add Cloudflare Turnstile to your Ruby on Rails application

2024-10-08T19:27:17.911646+00:00

tl;dr - the rails-cloudflare-turnstile gem¹ (GitHub link) is a great way to add Cloudflare Turnstile to your Rails app. Let's learn how to use it!

Setup

First, install the gem:

bundle add rails-cloudflare-turnstile

If you haven't enabled Turnstile yet in your Cloudflare account, follow the "Get Started" guide. You'll need a sitekey and secret key. Make sure to associate it with your domain too - for instance, kristianfreeman.com - in the Turnstile settings.

Add your sitekey and secret key to your Rails app - I like to use rails credentials:edit:

$ rails credentials:edit -e development
$ rails credentials:edit -e production

My credentials are structured like this:

cloudflare_turnstile:
  site_key: foo
  secret_key: bar

Create an initializer file, called config/initializers/turnstile.rb:

RailsCloudflareTurnstile.configure do |c|
  c.site_key = Rails.application.credentials.cloudflare_turnstile[:site_key]
  c.secret_key = Rails.application.credentials.cloudflare_turnstile[:secret_key]
  c.fail_open = false
end

Usage

First, we'll add the Turnstile JS script into an application layout file. If you are super performance-sensitive, you may want to do this specifically on the pages you're going to use Turnstile. Here, I'll just add it in app/views/layouts/application.html.erb:

<head>
  <%= cloudflare_turnstile_script_tag %>
</head>

In your forms, you can use the <%= cloudflare_turnstile %> partial to embed the Turnstile UI element right into your form. For instance, on a signup page:

<div>
  <%= cloudflare_turnstile %>
  <%= f.submit t("passwordless.sessions.new.submit"), class: "btn" %>
</div>

Importantly, you also need to validate on the server-side! Speaking as a CF employee who has talked to the Turnstile team, there is a lot of people implementing Turnstile... without the server-side validation.

Users are created in my app in UsersController#create. Let's validate the Turnstile data before calling that method:

class UsersController < ApplicationController
  before_action :validate_cloudflare_turnstile, only: [:create] if Rails.env.production?
  rescue_from RailsCloudflareTurnstile::Forbidden, with: :forbidden_turnstile

  def create
    # Implementation of creating users
  end

  private
  def forbidden_turnstile
    flash[:error] = "We had a problem creating your account."
    redirect_to root_path
  end

If the validation fails, the gem will throw an RailsCloudflareTurnstile::Forbidden exception. You need to rescue_from that exception in the controller, and do something with that failure. I prefer not to tell users - they're probably spammers - that their validation against Turnstile's rules fail.

Turnstile is great - really easy to configure, and literally saving me money by reducing the strain on my servers and ancillary analytics/marketing products, by reducing the number of junk users being added to my app. It only took ~15 minutes to get this implemented on one of my Rails apps, and I'm already seeing results.

Not my gem! But it's great - thanks to Instrumentl for building it.↩

The big bearblog syntax highlighting hack

2024-10-07T19:03:58.169750+00:00

While writing my post about Astro's content system, I realized that bearblog doesn't have syntax highlighting support for a lot of newer languages and frameworks.

For a few hours, I had actually added a notice:

An Astro code block (raw version, seen below) doesn't work as expected:

```astro
---
const { slug } = Astro.params
---
The current slug is {slug}

It renders, but it doesn't have any highlighting.

bearblog uses pygmentity, which is serviceable, but missing a lot of modern stuff.

I wanted to see if I could get custom syntax highlighting working on my site - by side-stepping pygmentify entirely and doing it by hand on the client-side.

And it worked! In fact, the above Markdown snippet is rendered with my custom solution. Let's look at how it works.

Shiki

Shiki is a modern syntax highlighting JS library that I first noticed in Astro's docs. It looks great. And it has theme support, meaning I can use my beloved Catppuccin Mocha without having to come up with a bunch of custom CSS selectors.

It has the ability to be used via CDN, too. Here's the example they give on the site:

<body>
  <div id="foo"></div>

  <script type="module">
    // be sure to specify the exact version
    import { codeToHtml } from 'https://esm.sh/shiki@1.0.0'
    // or
    // import { codeToHtml } from 'https://esm.run/shiki@1.0.0'

    const foo = document.getElementById('foo')
    foo.innerHTML = await codeToHtml('console.log("Hi, Shiki on CDN :)")', {
      lang: 'js',
      theme: 'rose-pine'
    })
  </script>
</body>

Basically, you can import it as an ESM, grab a given element, and replace the contents of it with transformed code passed through Shiki.

This gives us a great starting point. We need to grab any code in our blog post on page load, pass it through Shiki, and then replace the code with the new syntax highlighted version.

Implementation

Two problems quickly emerged as I tried to implement this:

The code blocks generated by bearblog have no language attached to them. If you specify a code block as "markdown", any indication that the code was Markdown is stripped away by the time the client loads the page.
The highlighted content doesn't "look" like the original code. A python snippet isn't Python anymore, it's HTML styled to look like Python.

That means we have to sidestep the entire code highlighting part of bearblog. Which is annoying, but certainly doable.

Instead, we can just provide a pre element inside of HTML, and give it a data attribute of language. pre elements retain the spacing of the text content inside, so it looks like code, and gets parsed by Shiki like it too!

Here's a very meta example of the first snippet in this post - how it actually appears in the raw post content. It's a pre with class shiki-highlight, and data-language set to Markdown:

<pre class="shiki-highlight" data-language="markdown">```astro
---
const { slug } = Astro.params
---
<p>The current slug is {slug}</p></pre>

Now, we¹ can write some custom JavaScript to find all instances of pre.shiki-highlight, and do the following:

Transform the content through Shiki, and put it in a new pre tag with all the right formatting.
Take the original content and wrap it with noscript - that way, if someone has JS disabled, they still see code.

The full snippet, including comments, is included below:

<script type="module">
import { codeToHtml } from 'https://esm.sh/shiki@1.0.0';

const codeBlocks = document.querySelectorAll("pre.shiki-highlight");

Array.from(codeBlocks).forEach(async el => {
  // Create a noscript element
  const noscript = document.createElement('noscript');
  
  // Clone the original div into the noscript element as a fallback
  const clone = el.cloneNode(true);
  noscript.appendChild(clone);
  
  // Insert noscript after the current element
  el.parentNode.insertBefore(noscript, el.nextSibling);
  
  // Generate rendered HTML (which might already include a <pre> from Shiki)
  const transformedHtml = await codeToHtml(el.innerText, {
    lang: el.dataset.language,
    theme: 'catppuccin-mocha',
  });
  
  // Parse the resulting HTML string into a DOM node (to get the inner <pre>)
  const tempContainer = document.createElement('div');
  tempContainer.innerHTML = transformedHtml;
  
  // Grab the <pre> from the generated HTML (Shiki returns <pre> with code already)
  const generatedPre = tempContainer.querySelector('pre');
  
  // Insert the new <pre> with its styles and classes after the noscript element
  if (generatedPre) {
      generatedPre.style["background-color"] = "var(--code-background-color)";
      el.parentNode.insertBefore(generatedPre, noscript.nextSibling);
  }
  
  // Hide the original pre
  el.style.display = 'none';
});
</script>

Issues

The main issue with this approach is that HTML still has to be escaped. .astro files are a combination of JavaScript and HTML. Any HTML inside of a pre tag gets evaluated as HTML, meaning it can quickly spiral out of control and try and render that HTML inside of your blog post! Uh-oh. Instead, we have to escape any HTML in the raw Markdown of our post before it even gets to Shiki on the client.

The second issue: this is a lot of work, and pretty brittle. 99% of the code samples on this site are pushed through Pygmentify with little issue, and the GPT-generated replacements I worked up for Pygmentify to render Catppuccin Mocha colors are good enough.

For newer file formats, this hack is a solution. But it would be better to have better support on bearblog's server for other highlighting solutions. I opened a feature suggestion to begin the convo about improving the syntax highlighting situation in bearblog. It would be even cooler if we could just get Shiki or another newer engine built into Bearblog, with the ability to switch to it with a single click.

I have noticed that Shiki has the ability to run inside of Cloudflare Workers, meaning that there could be a cool solution where the client doesn't even know or care about Shiki - the code to transform the HTML and syntax highlight it could happen on the edge, on the way to the reader. I don't see any particular advantage to implementing it there yet - but if we could turn off syntax highlighting and pass the raw Markdown block through the server to the client, this could be an interesting solution.

OK, it was me and ChatGPT 🤷↩

An introduction to Astro's content system

2024-10-08T19:27:07.050507+00:00

Astro is excellent for building blogs and documentation sites.

Over the weekend, I implemented Gangsheet.app’s blog using the built-in content collection system¹, and I was impressed at how easy it was. In this blog post, I’ll lay out how I implemented, with real code samples.

Astro’s Content Collection system

Astro has a built-in way to import .md, .mdx, .yaml, and .json files, and use them to generate pages for your site. These files are parsed and strictly typed using Zod.

I’m not tuned in to Astro’s development cycle, but I can speak as a developer who’s been in the static site/Jamstack space for a long time - Astro’s content layer is excellent. In a past life, I completely abused Gatsby’s content generation system to great effect. For instance, generating programatic SEO pages for a frontend development job board by generating massive amounts of combinatorial category pages².

With that history, I’m pretty well-versed in what the space looks like for using local and remote data to generate static-first sites. The example I lay out in this post - generating a blog - is very straightforward. The number of pages generated is N+1, where N is the number of blog posts (plus one index page). But some of the things that Astro does - no doubt due to better tooling, and experience seeing where some Jamstack sites have fallen short - have me very optimistic that this is a good platform to build on.

Define a content collection

For Gangsheet, I wanted a blog. The posts are authored in Markdown, stored in src/content/blog/*.md. These posts should be parsed, and then rendered at both /blog (the index of all posts), and /blog/:slug (the page for each individual post).

First, we’ll create the folder src/content/blog, and then fill in src/content/config.ts, which configures all content collections for our app:

import { defineCollection, reference, z } from 'astro:content';

const blogCollection = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    excerpt: z.string(),
    author: z.object({
      name: z.string(),
      x: z.string(),
    }),
    publishedAt: z.date(),
    related: z.array(reference('blog')),
  }),
});

export const collections = {
  'blog': blogCollection,
};

A blog post has:

A title
An excerpt
An author, with a name and 𝕏 @username
A publishedAt date
Related posts

A few interesting things to note here:

No slug! The slug is generated automatically for each post, based on the filename (e.g. src/content/blog/hello-world.mdx is, of course, /blog/hello-world).³
Related posts - woah! You can reference other types, or the same type. We’ll see how easy this is when authoring, in just a second.⁴

Add a blog post

We can generate a blog post by creating a new Markdown file in src/content/blog. I’ll create src/content/hello-world.md, below:

---
title: Hello world!
publishedAt: 2024-10-04
excerpt: My first blog post on my new Astro blog.
author: 
  name: Kristian Freeman
  x: kristianf_
related:
  - the-history-of-hello-world
---

Hello world! This is my new blog post.

Lots of interesting things to dig into here - luckily, it’s all pretty straightforward. title, publishedAt, and excerpt are simple string/date fields. author is an object (maybe a dictionary technically?) with nested fields.

related is a collection of other blog posts, based on the slug parameter (again, defined by the filename). We’ll look at how to access the related blog posts in the blog post page, later on.

Anything after the frontmatter is, of course, the content itself. Astro supports MDX, so you should be able to do fancy React component stuff here, too. I haven’t found a need for that yet, but if you want to see an example of how it works, check out Astro’s “Add reading time” recipe.

Implement page generation

Now, we have a content collection, living at src/content/blog - how do we use it?

First, let’s briefly review Astro’s “page” functionality:

Pages live inside src/pages
Pages use the .astro extension, which executes JavaScript and allows React or other front-end composition
They use file-based routing: src/pages

We’ll create two pages:

src/pages/blog.astro - the blog index.
src/pages/blog/[slug].astro - the template for each individual blog post.

Blog index

Defining the blog index page involves two steps - first, getting the collection using getCollection from the astro:content import. Then, we can render the blog posts using HTML:

---
import { getCollection } from "astro:content";

const posts = await getCollection("blog");
const sortedPosts = posts.sort(
  (a, b) => b.data.publishedAt.getTime() - a.data.publishedAt.getTime(),
);
---

<div>
  {sortedPosts.map((post) => (
    <div>
      <h2>
        <a href={`/blog/${post.slug}`}>
          {post.data.title}
        </a>
      </h2>
      <p>
        Published at {post.data.publishedAt}
      </p>
      <p>{post.data.excerpt}</p>
    </div>
  ))}
</div>

It won’t be indicated in the above code sample, but each post here is strongly typed. That means that post.slug and post.data, as well as everything inside data, have the benefit of TypeScript magic in your editor. If excerpt, for instance, was optional, we would be encouraged, via our editor and Astro’s build workflow, to handle the null case better.

Post page

---
import { getEntry, getEntries } from "astro:content";

const { slug } = Astro.params;
if (!slug) return Astro.redirect("/blog");

const post = await getEntry("blog", slug);
if (!post) return Astro.redirect("/blog");

const { Content, headings } = await post.render();
const relatedPosts = await getEntries(post.data.related);
---

<div>
  <article>
    <h1>{post.data.title}</h1>

    <div>
      <time datetime={post.data.publishedAt.toString()}></time>
    </div>

    <div>
      <p>{post.data.author.name}</p>
    </div>

    <div id="content"><Content /></div>
  </article>

  <section>
    <h2>Related Posts</h2>

    {relatedPosts.map((relatedPost) => (
      <div>
        <h3><a href={`/blog/${relatedPost.slug}`}>{relatedPost.data.title}</a></h3>
      </div>
    ))}
  </section>
</div>

First, we grab the slug param from Astro.params. Then we use it to grab the specific post for this page - getEntry(‘blog’, slug). post.render() pushes the Markdown through Astro’s MDX compiler, and returns a Content component that can be rendered on the page, as well as an array representing all the headers (h2, h3, etc.) for the content⁵.

The rendering is similar to what we did on the index page. post.data contains everything inside of the frontmatter for the post, so you can pull title, excerpt, author, etc. out and reference it wherever you need it in the HTML.

When we need to load related posts, we can call getEntries (note plural, not singular) to load all of the posts specified in post.data.related. We get an array back of related posts - still strictly parsed + typed; basically identical to the posts array we had on the index page. This is super powerful. I love this implementation!

Conclusion

I’m really happy I invested time in learning Astro’s content collection system. I haven’t yet had the chance to use Astro’s new system (in beta), but when Astro v5 is properly released, I’ll do a follow up blog post on what’s changed.

I wrote last week about investing in learning Astro. This continues to pay off. I’ve been able to build a lot of complex functionality in it, and most of the issues I’ve run into have been totally solvable - even the hard stuff, like auth, dynamic data loading, etc.

What I’m excited about most with the content collection system is that it feels like it lives inside of my app, which is quite complex, without resorting to hacks. It fits into the rest of the app in a way that makes sense. For instance, if I wanted to pin the most recent blog post as an “announcement” banner on my dashboard page - I wouldn’t have to make a crazy GraphQL query and combine dynamic and static pages in a way that feels bad. I can just call getCollection(“blog”) on any Astro page and render it out. No hacks needed!

I didn’t use Astro’s new v5 beta, which has apparently rewritten this system. I’m interested to see how it changed - maybe that will be a future post.↩
Given X number of location categories, Y number of framework/language categories, and Z number of “experience”/skill-level categories, generate X*Y*Z number of SEO-optimized pages, like “senior React.js jobs in the United States”. I was generating thousands of pages and running up against the container my site was building in - with Netlify at the time - running out of memory. Fun times!↩
You can also manually override the slug in the front-matter of the blog post.↩
As I’m writing this blog post, I’m realizing that author could be an awesome win here in terms of referencing. Instead of putting the author name/𝕏 username on every post, I could set up "src/content/authors/kristian.md" and just pass that reference in every blog post.↩
You can use this to generate a table of contents. See an example on a blog post from Gangsheet’s blog.↩