diff --git a/.eleventy.js b/.eleventy.js
index 1c8c7775bc..b913246ac9 100644
--- a/.eleventy.js
+++ b/.eleventy.js
@@ -44,6 +44,7 @@ module.exports = function (eleventyConfig) {
   eleventyConfig.addCollection("elixirPosts", require("./collections/elixirPosts"));
   eleventyConfig.addCollection("rustPosts", require("./collections/rustPosts"));
   eleventyConfig.addCollection("sveltePosts", require("./collections/sveltePosts"));
+  eleventyConfig.addCollection("travelPosts", require("./collections/travelPosts"));
   eleventyConfig.addCollection("authors", require("./collections/authors"));
   eleventyConfig.addCollection("authorsPostsPaged", require("./collections/authorsPostsPaged"));
   eleventyConfig.addCollection("tags", require("./collections/tags"));
@@ -224,6 +225,11 @@ module.exports = function (eleventyConfig) {
     return response.data.replace("<svg", `<svg focusable="false" role="presentation"`);
   });
 
+  eleventyConfig.addShortcode("mastodonHandleUrl", handle => {
+    const [user, server] = handle.split("@").filter(Boolean);
+    return `https://${server}/@${user}`;
+  });
+
   eleventyConfig.setServerOptions({
     watch: ["./dist/assets/css/*.css", "./dist/assets/js/*.js"],
   });
diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index eb188ce202..79734e4d96 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -12,9 +12,10 @@ jobs:
   lint:
     name: Linting
     runs-on: ubuntu-latest
+    if: ${{ github.event_name != 'schedule' }}
 
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - uses: actions/setup-node@v4
         with:
           registry-url: "https://registry.npmjs.org"
@@ -34,9 +35,10 @@ jobs:
   visual-regressions:
     name: 'Visual Regressions'
     runs-on: ubuntu-latest
+    if: ${{ github.event_name != 'schedule' }}
 
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
       - uses: actions/setup-node@v4
         with:
           registry-url: "https://registry.npmjs.org"
@@ -62,9 +64,10 @@ jobs:
   performance:
     name: 'Performance'
     runs-on: ubuntu-latest
+    if: ${{ github.event_name != 'schedule' }}
 
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
         with:
           ref: ${{ github.event.pull_request.head.sha }}
       - uses: actions/setup-node@v4
@@ -91,9 +94,10 @@ jobs:
   crawl:
     name: 'Crawl Links'
     runs-on: ubuntu-latest
+    if: ${{ github.event_name != 'schedule' }}
 
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
         with:
           ref: ${{ github.event.pull_request.head.sha }}
       - uses: actions/setup-node@v4
@@ -118,9 +122,10 @@ jobs:
   gravity:
     name: 'Gravity'
     runs-on: ubuntu-latest
+    if: ${{ github.event_name != 'schedule' }}
 
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4
         with:
           ref: ${{ github.event.pull_request.head.sha }}
       - uses: actions/setup-node@v4
diff --git a/.prettierrc.js b/.prettierrc.js
index e77dc422b5..86ae1ecc4d 100644
--- a/.prettierrc.js
+++ b/.prettierrc.js
@@ -10,8 +10,8 @@ module.exports = {
     {
       files: "*.md",
       options: {
+        proseWrap: "never",
         printWidth: 80,
-        proseWrap: "always",
       },
     },
     {
diff --git a/README.md b/README.md
index 33cf0a5821..2a9492ef39 100644
--- a/README.md
+++ b/README.md
@@ -4,6 +4,4 @@ The source code for [https://mainmatter.com](https://mainmatter.com).
 
 ## Copyright
 
-Copyright &copy; 2019-2022 Mainmatter GmbH (https://mainmatter.com), released
-under the
-[Creative Commons Attribution-NonCommercial 4.0 International license](https://creativecommons.org/licenses/by-nc/4.0/).
+Copyright &copy; 2019-2022 Mainmatter GmbH (https://mainmatter.com), released under the [Creative Commons Attribution-NonCommercial 4.0 International license](https://creativecommons.org/licenses/by-nc/4.0/).
diff --git a/collections/travelPosts.js b/collections/travelPosts.js
new file mode 100644
index 0000000000..36c8b07a90
--- /dev/null
+++ b/collections/travelPosts.js
@@ -0,0 +1,10 @@
+const livePosts = require("./posts");
+
+module.exports = collection => {
+  const allPosts = livePosts(collection);
+  return allPosts.filter(
+    post =>
+      Array.isArray(post.data.tags) &&
+      post.data.tags.some(t => t.match(/^process/) || t.match(/^culture/) || t.match(/^consulting/))
+  );
+};
diff --git a/config/this-week-in-open-source.config.json b/config/this-week-in-open-source.config.json
index ddbbe82f1d..b44f6e738a 100644
--- a/config/this-week-in-open-source.config.json
+++ b/config/this-week-in-open-source.config.json
@@ -22,7 +22,9 @@
         "rust-lang/www.rust-lang.org",
         "dimforge/rapier.rs",
         "marcoow/pacesetter",
-        "mainmatter/cargo-autoinherit"
+        "mainmatter/cargo-autoinherit",
+        "mainmatter/100-exercises-to-learn-rust",
+        "mainmatter/gerust"
       ]
     },
     {
@@ -88,7 +90,8 @@
         "sveltejs/language-tools",
         "svecosystem/runed",
         "mainmatter/sheepdog",
-        "paoloricciuti/optimistikit"
+        "paoloricciuti/optimistikit",
+        "animotionjs/animotion"
       ]
     },
     {
@@ -205,7 +208,9 @@
         "adopted-ember-addons/ember-drag-drop",
         "tleunen/babel-plugin-module-resolver",
         "snewcomer/intersection-observer-admin",
-        "mansona/auto-reveal-theme-mainmatter"
+        "mansona/auto-reveal-theme-mainmatter",
+        "formatjs/formatjs",
+        "vitejs/vite"
       ]
     },
     {
@@ -464,7 +469,9 @@
         "ember-cli/ember-cli-deprecation-workflow",
         "ember-cli/babel-plugin-debug-macros",
         "adopted-ember-addons/ember-sortable",
-        "elwayman02/ember-resize-modifier"
+        "elwayman02/ember-resize-modifier",
+        "ember-codemods/tagless-ember-components-codemod",
+        "adopted-ember-addons/ember-paper"
       ]
     },
     {
@@ -563,7 +570,8 @@
     "oscard0m/example-probot-vercel-ts",
     "paoloricciuti/darkmodething",
     "mansona/testing-release-plan",
-    "BlueCutOfficial/site-cv"
+    "BlueCutOfficial/site-cv",
+    "mainmatter/gravity_dummy"
   ],
   "exclude_closed_not_merged": true,
   "output_path": "src/twios/",
diff --git a/netlify.toml b/netlify.toml
index e40c6d0ce3..c38a3b715d 100644
--- a/netlify.toml
+++ b/netlify.toml
@@ -199,7 +199,7 @@
 # redirect old "Web-based Services in Rust" landing page to regular workshop
 [[redirects]]
   from = "https://rust-web-services-workshop.mainmatter.com/*"
-  to = "https://mainmatter.com/services/workshops/web-based-services-in-rust/"
+  to = "https://mainmatter.com/services/workshops/build-production-ready-apis-in-rust/"
   force = true
 
 # redirect old "Web-based Servides in Rust" workshop to new one
diff --git a/package.json b/package.json
index af203c98a9..a8dc5a5afa 100644
--- a/package.json
+++ b/package.json
@@ -34,15 +34,15 @@
   },
   "devDependencies": {
     "@11ty/eleventy": "^2.0.1",
-    "@11ty/eleventy-img": "^4.0.0",
+    "@11ty/eleventy-img": "^6.0.0",
     "@11ty/eleventy-navigation": "^0.3.2",
     "@11ty/eleventy-plugin-rss": "1.2.0",
     "@11ty/eleventy-plugin-syntaxhighlight": "5.0.0",
-    "@lhci/cli": "^0.13.0",
+    "@lhci/cli": "^0.14.0",
     "@percy/cli": "^1.28.7",
     "@quasibit/eleventy-plugin-sitemap": "^2.1.5",
-    "@rollup/plugin-commonjs": "^26.0.1",
-    "@rollup/plugin-node-resolve": "^15.2.3",
+    "@rollup/plugin-commonjs": "^28.0.0",
+    "@rollup/plugin-node-resolve": "^16.0.0",
     "@rollup/plugin-terser": "^0.4.4",
     "@tbranyen/jsdom": "13.0.0",
     "broken-link-checker": "^0.7.8",
@@ -50,7 +50,7 @@
     "cross-env": "7.0.3",
     "dayjs": "^1.10.4",
     "eslint": "^9.0.0",
-    "eslint-config-prettier": "^9.1.0",
+    "eslint-config-prettier": "^10.0.0",
     "eslint-plugin-n": "^17.0.0",
     "eslint-plugin-prettier": "^5.1.3",
     "express": "^4.18.1",
@@ -58,9 +58,9 @@
     "markdown-it": "14.1.0",
     "markdown-it-footnote": "^4.0.0",
     "netlify-plugin-11ty": "^1.1.0",
-    "npm-run-all2": "^6.0.0",
-    "prettier": "3.2.5",
-    "prettier-plugin-jinja-template": "^1.3.3",
+    "npm-run-all2": "^7.0.0",
+    "prettier": "3.4.2",
+    "prettier-plugin-jinja-template": "^2.0.0",
     "replace-in-file": "^7.0.0",
     "rollup": "^4.18.0",
     "sass": "^1.32.8",
@@ -83,7 +83,7 @@
     "node": ">=20"
   },
   "volta": {
-    "node": "20.15.1",
-    "pnpm": "9.7.0"
+    "node": "22.13.0",
+    "pnpm": "9.15.4"
   }
 }
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index dfd24c5413..6816642f13 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -10,7 +10,7 @@ importers:
     dependencies:
       '@sentry/browser':
         specifier: ^8.0.0
-        version: 8.15.0
+        version: 8.48.0
       gsap:
         specifier: ^3.12.3
         version: 3.12.5
@@ -22,8 +22,8 @@ importers:
         specifier: ^2.0.1
         version: 2.0.1
       '@11ty/eleventy-img':
-        specifier: ^4.0.0
-        version: 4.0.2
+        specifier: ^6.0.0
+        version: 6.0.0
       '@11ty/eleventy-navigation':
         specifier: ^0.3.2
         version: 0.3.5
@@ -34,23 +34,23 @@ importers:
         specifier: 5.0.0
         version: 5.0.0
       '@lhci/cli':
-        specifier: ^0.13.0
-        version: 0.13.0
+        specifier: ^0.14.0
+        version: 0.14.0
       '@percy/cli':
         specifier: ^1.28.7
-        version: 1.28.8
+        version: 1.30.6
       '@quasibit/eleventy-plugin-sitemap':
         specifier: ^2.1.5
         version: 2.2.0
       '@rollup/plugin-commonjs':
-        specifier: ^26.0.1
-        version: 26.0.1(rollup@4.18.0)
+        specifier: ^28.0.0
+        version: 28.0.2(rollup@4.30.1)
       '@rollup/plugin-node-resolve':
-        specifier: ^15.2.3
-        version: 15.2.3(rollup@4.18.0)
+        specifier: ^16.0.0
+        version: 16.0.0(rollup@4.30.1)
       '@rollup/plugin-terser':
         specifier: ^0.4.4
-        version: 0.4.4(rollup@4.18.0)
+        version: 0.4.4(rollup@4.30.1)
       '@tbranyen/jsdom':
         specifier: 13.0.0
         version: 13.0.0
@@ -65,22 +65,22 @@ importers:
         version: 7.0.3
       dayjs:
         specifier: ^1.10.4
-        version: 1.11.11
+        version: 1.11.13
       eslint:
         specifier: ^9.0.0
-        version: 9.6.0
+        version: 9.18.0
       eslint-config-prettier:
-        specifier: ^9.1.0
-        version: 9.1.0(eslint@9.6.0)
+        specifier: ^10.0.0
+        version: 10.0.1(eslint@9.18.0)
       eslint-plugin-n:
         specifier: ^17.0.0
-        version: 17.9.0(eslint@9.6.0)
+        version: 17.15.1(eslint@9.18.0)
       eslint-plugin-prettier:
         specifier: ^5.1.3
-        version: 5.1.3(eslint-config-prettier@9.1.0(eslint@9.6.0))(eslint@9.6.0)(prettier@3.2.5)
+        version: 5.2.1(eslint-config-prettier@10.0.1(eslint@9.18.0))(eslint@9.18.0)(prettier@3.4.2)
       express:
         specifier: ^4.18.1
-        version: 4.19.2
+        version: 4.21.2
       html-minifier:
         specifier: 4.0.0
         version: 4.0.0
@@ -94,23 +94,23 @@ importers:
         specifier: ^1.1.0
         version: 1.4.0
       npm-run-all2:
-        specifier: ^6.0.0
-        version: 6.2.2
+        specifier: ^7.0.0
+        version: 7.0.2
       prettier:
-        specifier: 3.2.5
-        version: 3.2.5
+        specifier: 3.4.2
+        version: 3.4.2
       prettier-plugin-jinja-template:
-        specifier: ^1.3.3
-        version: 1.4.1(prettier@3.2.5)
+        specifier: ^2.0.0
+        version: 2.0.0(prettier@3.4.2)
       replace-in-file:
         specifier: ^7.0.0
         version: 7.2.0
       rollup:
         specifier: ^4.18.0
-        version: 4.18.0
+        version: 4.30.1
       sass:
         specifier: ^1.32.8
-        version: 1.77.6
+        version: 1.83.1
       slugify:
         specifier: 1.6.6
         version: 1.6.6
@@ -119,7 +119,7 @@ importers:
         version: 3.3.2
       wicg-inert:
         specifier: ^3.1.1
-        version: 3.1.2
+        version: 3.1.3
 
 packages:
 
@@ -131,12 +131,12 @@ packages:
     engines: {node: '>=14'}
     hasBin: true
 
-  '@11ty/eleventy-fetch@4.0.1':
-    resolution: {integrity: sha512-yIiLM5ziBmg86i4TlXpBdcIygJHvh/GgPJyAiFOckO9H4y9cQDM8eIcJCUQ4Mum0NEVui/OjhEut2R08xw0vlQ==}
-    engines: {node: '>=14'}
+  '@11ty/eleventy-fetch@5.0.2':
+    resolution: {integrity: sha512-yu7oZ5iv7zvFDawSYcN19cz7ddJB7OXPGZ47z/MzYmLa2LkpJm0KnZW2xGwpKvVrXd+tyb96ts6AqlkJT/ibwQ==}
+    engines: {node: '>=18'}
 
-  '@11ty/eleventy-img@4.0.2':
-    resolution: {integrity: sha512-MSCkZRJk9rWa7nojx9HBMZJePOrm+V3XNpT091qguj61SG5UsgXbxAkoeejO3npmKIQJTyVIV/rrA6d7xZYOvw==}
+  '@11ty/eleventy-img@6.0.0':
+    resolution: {integrity: sha512-5vQj6NMxaRwI/rkRkrDajUvNy4p4xJz2DJrlgk0JpvYegkC8OxAoLE+sXqd5Ij5IgqfoPHiepf/3FbTHAnYXzg==}
     engines: {node: '>=18'}
 
   '@11ty/eleventy-navigation@0.3.5':
@@ -152,6 +152,10 @@ packages:
     resolution: {integrity: sha512-nULO91om7vQw4Y/UBjM8i7nJ1xl+/nyK4rImZ41lFxiY2d+XUz7ChAj1CDYFjrLZeu0utAYJTZ45LlcHTkUG4g==}
     engines: {node: '>=12'}
 
+  '@11ty/eleventy-utils@2.0.0':
+    resolution: {integrity: sha512-rKny6X7+ARuke0TaA6FwNv2PWJCNSdPQqbqDgaZgi+bPXwnPRTEi3CWzvr6vVgh/1XpO1G4FhRPreLhtcwHUyg==}
+    engines: {node: '>=18'}
+
   '@11ty/eleventy@2.0.1':
     resolution: {integrity: sha512-t8XVUbCJByhVEa1RzO0zS2QzbL3wPY8ot1yUw9noqiSHxJWUwv6jiwm1/MZDPTYtkZH2ZHvdQIRQ5/SjG9XmLw==}
     engines: {node: '>=14'}
@@ -161,205 +165,209 @@ packages:
     resolution: {integrity: sha512-Mqt6im1xpb1Ykn3nbcCovWXK3ggywRJa+IXIdoz4wIIK+cvozADH63lexcuPpGS/gJ6/m2JxyyXDyupkMr5DHw==}
     engines: {node: '>=14'}
 
-  '@babel/code-frame@7.24.7':
-    resolution: {integrity: sha512-BcYH1CVJBO9tvyIZ2jVeXgSIMvGZ2FDRvDdOIVQyuklNKSsx+eppDEBq/g47Ayw+RqNFE+URvOShmf+f/qwAlA==}
-    engines: {node: '>=6.9.0'}
-
-  '@babel/helper-string-parser@7.24.7':
-    resolution: {integrity: sha512-7MbVt6xrwFQbunH2DNQsAP5sTGxfqQtErvBIvIMi6EQnbgUOuVYanvREcmFrOPhoXBrTtjhhP+lW+o5UfK+tDg==}
+  '@babel/code-frame@7.26.2':
+    resolution: {integrity: sha512-RJlIHRueQgwWitWgF8OdFYGZX328Ax5BCemNGlqHfplnRT9ESi8JkFlvaVYbS+UubVY6dpv87Fs2u5M29iNFVQ==}
     engines: {node: '>=6.9.0'}
 
-  '@babel/helper-validator-identifier@7.24.7':
-    resolution: {integrity: sha512-rR+PBcQ1SMQDDyF6X0wxtG8QyLCgUB0eRAGguqRLfkCA87l7yAP7ehq8SNj96OOGTO8OBV70KhuFYcIkHXOg0w==}
+  '@babel/helper-string-parser@7.25.9':
+    resolution: {integrity: sha512-4A/SCr/2KLd5jrtOMFzaKjVtAei3+2r/NChoBNoZ3EyP/+GlhoaEGoWOZUmFmoITP7zOJyHIMm+DYRd8o3PvHA==}
     engines: {node: '>=6.9.0'}
 
-  '@babel/highlight@7.24.7':
-    resolution: {integrity: sha512-EStJpq4OuY8xYfhGVXngigBJRWxftKX9ksiGDnmlY3o7B/V7KIAc9X4oiK87uPJSc/vs5L869bem5fhZa8caZw==}
+  '@babel/helper-validator-identifier@7.25.9':
+    resolution: {integrity: sha512-Ed61U6XJc3CVRfkERJWDz4dJwKe7iLmmJsbOGu9wSloNSFttHV0I8g6UAgb7qnK5ly5bGLPd4oXZlxCdANBOWQ==}
     engines: {node: '>=6.9.0'}
 
-  '@babel/parser@7.24.7':
-    resolution: {integrity: sha512-9uUYRm6OqQrCqQdG1iCBwBPZgN8ciDBro2nIOFaiRz1/BCxaI7CNvQbDHvsArAC7Tw9Hda/B3U+6ui9u4HWXPw==}
+  '@babel/parser@7.26.5':
+    resolution: {integrity: sha512-SRJ4jYmXRqV1/Xc+TIVG84WjHBXKlxO9sHQnA2Pf12QQEAp1LOh6kDzNHXcUnbH1QI0FDoPPVOt+vyUDucxpaw==}
     engines: {node: '>=6.0.0'}
     hasBin: true
 
-  '@babel/types@7.24.7':
-    resolution: {integrity: sha512-XEFXSlxiG5td2EJRe8vOmRbaXVgfcBlszKujvVmWIK/UpywWljQCfzAv3RQCGujWQ1RD4YYWEAqDXfuJiy8f5Q==}
+  '@babel/types@7.26.5':
+    resolution: {integrity: sha512-L6mZmwFDK6Cjh1nRCLXpa6no13ZIioJDz7mdkzHv399pThrTa/k0nUlNaenOeh2kWu/iaOQYElEpKPUswUa9Vg==}
     engines: {node: '>=6.9.0'}
 
-  '@emnapi/runtime@1.2.0':
-    resolution: {integrity: sha512-bV21/9LQmcQeCPEg3BDFtvwL6cwiTMksYNWQQ4KOxCZikEGalWtenoZ0wCiukJINlGCIi2KXx01g4FoH/LxpzQ==}
+  '@emnapi/runtime@1.3.1':
+    resolution: {integrity: sha512-kEBmG8KyqtxJZv+ygbEim+KCGtIq1fC22Ms3S4ziXmYKm8uyoLX0MHONVKwp+9opg390VaKRNt4a7A9NwmpNhw==}
 
-  '@eslint-community/eslint-utils@4.4.0':
-    resolution: {integrity: sha512-1/sA4dwrzBAyeUoQ6oxahHKmrZvsnLCg4RfxW3ZFGGmQkSNQPFNLV9CUEFQP1x9EYXHTo5p6xdhZM1Ne9p/AfA==}
+  '@eslint-community/eslint-utils@4.4.1':
+    resolution: {integrity: sha512-s3O3waFUrMV8P/XaF/+ZTp1X9XBZW1a4B97ZnjQF2KYWaFD2A8KyFBsrsfSjEmjn3RGWAIuvlneuZm3CUK3jbA==}
     engines: {node: ^12.22.0 || ^14.17.0 || >=16.0.0}
     peerDependencies:
       eslint: ^6.0.0 || ^7.0.0 || >=8.0.0
 
-  '@eslint-community/regexpp@4.11.0':
-    resolution: {integrity: sha512-G/M/tIiMrTAxEWRfLfQJMmGNX28IxBg4PBz8XqQhqUHLFI6TL2htpIB1iQCj144V5ee/JaKyT9/WZ0MGZWfA7A==}
+  '@eslint-community/regexpp@4.12.1':
+    resolution: {integrity: sha512-CCZCDJuduB9OUkFkY2IgppNZMi2lBQgD2qzwXkEia16cge2pijY/aXi96CJMquDMn3nJdlPV1A5KrJEXwfLNzQ==}
     engines: {node: ^12.0.0 || ^14.0.0 || >=16.0.0}
 
-  '@eslint/config-array@0.17.0':
-    resolution: {integrity: sha512-A68TBu6/1mHHuc5YJL0U0VVeGNiklLAL6rRmhTCP2B5XjWLMnrX+HkO+IAXyHvks5cyyY1jjK5ITPQ1HGS2EVA==}
+  '@eslint/config-array@0.19.1':
+    resolution: {integrity: sha512-fo6Mtm5mWyKjA/Chy1BYTdn5mGJoDNjC7C64ug20ADsRDGrA85bN3uK3MaKbeRkRuuIEAR5N33Jr1pbm411/PA==}
+    engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
+
+  '@eslint/core@0.10.0':
+    resolution: {integrity: sha512-gFHJ+xBOo4G3WRlR1e/3G8A6/KZAH6zcE/hkLRCZTi/B9avAG365QhFA8uOGzTMqgTghpn7/fSnscW++dpMSAw==}
+    engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
+
+  '@eslint/eslintrc@3.2.0':
+    resolution: {integrity: sha512-grOjVNN8P3hjJn/eIETF1wwd12DdnwFDoyceUJLYYdkpbwq3nLi+4fqrTAONx7XDALqlL220wC/RHSC/QTI/0w==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
-  '@eslint/eslintrc@3.1.0':
-    resolution: {integrity: sha512-4Bfj15dVJdoy3RfZmmo86RK1Fwzn6SstsvK9JS+BaVKqC6QQQQyXekNaC+g+LKNgkQ+2VhGAzm6hO40AhMR3zQ==}
+  '@eslint/js@9.18.0':
+    resolution: {integrity: sha512-fK6L7rxcq6/z+AaQMtiFTkvbHkBLNlwyRxHpKawP0x3u9+NC6MQTnFW+AdpwC6gfHTW0051cokQgtTN2FqlxQA==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
-  '@eslint/js@9.6.0':
-    resolution: {integrity: sha512-D9B0/3vNg44ZeWbYMpBoXqNP4j6eQD5vNwIlGAuFRRzK/WtT/jvDQW3Bi9kkf3PMDMlM7Yi+73VLUsn5bJcl8A==}
+  '@eslint/object-schema@2.1.5':
+    resolution: {integrity: sha512-o0bhxnL89h5Bae5T318nFoFzGy+YE5i/gGkoPAgkmTVdRKTiv3p8JHevPiPaMwoloKfEiiaHlawCqaZMqRm+XQ==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
-  '@eslint/object-schema@2.1.4':
-    resolution: {integrity: sha512-BsWiH1yFGjXXS2yvrf5LyuoSIIbPrGUWob917o+BTKuZ7qJdxX8aJLRxs1fS9n6r7vESrq1OUqb68dANcFXuQQ==}
+  '@eslint/plugin-kit@0.2.5':
+    resolution: {integrity: sha512-lB05FkqEdUg2AA0xEbUz0SnkXT1LcCTa438W4IWTUh4hdOnVbQyOJ81OrDXsJk/LSiJHubgGEFoR5EHq1NsH1A==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
-  '@formatjs/ecma402-abstract@2.0.0':
-    resolution: {integrity: sha512-rRqXOqdFmk7RYvj4khklyqzcfQl9vEL/usogncBHRZfZBDOwMGuSRNFl02fu5KGHXdbinju+YXyuR+Nk8xlr/g==}
+  '@formatjs/ecma402-abstract@2.3.2':
+    resolution: {integrity: sha512-6sE5nyvDloULiyOMbOTJEEgWL32w+VHkZQs8S02Lnn8Y/O5aQhjOEXwWzvR7SsBE/exxlSpY2EsWZgqHbtLatg==}
 
-  '@formatjs/fast-memoize@2.2.0':
-    resolution: {integrity: sha512-hnk/nY8FyrL5YxwP9e4r9dqeM6cAbo8PeU9UjyXojZMNvVad2Z06FAVHyR3Ecw6fza+0GH7vdJgiKIVXTMbSBA==}
+  '@formatjs/fast-memoize@2.2.6':
+    resolution: {integrity: sha512-luIXeE2LJbQnnzotY1f2U2m7xuQNj2DA8Vq4ce1BY9ebRZaoPB1+8eZ6nXpLzsxuW5spQxr7LdCg+CApZwkqkw==}
 
-  '@formatjs/icu-messageformat-parser@2.7.8':
-    resolution: {integrity: sha512-nBZJYmhpcSX0WeJ5SDYUkZ42AgR3xiyhNCsQweFx3cz/ULJjym8bHAzWKvG5e2+1XO98dBYC0fWeeAECAVSwLA==}
+  '@formatjs/icu-messageformat-parser@2.9.8':
+    resolution: {integrity: sha512-hZlLNI3+Lev8IAXuwehLoN7QTKqbx3XXwFW1jh0AdIA9XJdzn9Uzr+2LLBspPm/PX0+NLIfykj/8IKxQqHUcUQ==}
 
-  '@formatjs/icu-skeleton-parser@1.8.2':
-    resolution: {integrity: sha512-k4ERKgw7aKGWJZgTarIcNEmvyTVD9FYh0mTrrBMHZ1b8hUu6iOJ4SzsZlo3UNAvHYa+PnvntIwRPt1/vy4nA9Q==}
+  '@formatjs/icu-skeleton-parser@1.8.12':
+    resolution: {integrity: sha512-QRAY2jC1BomFQHYDMcZtClqHR55EEnB96V7Xbk/UiBodsuFc5kujybzt87+qj1KqmJozFhk6n4KiT1HKwAkcfg==}
 
-  '@formatjs/intl-localematcher@0.5.4':
-    resolution: {integrity: sha512-zTwEpWOzZ2CiKcB93BLngUX59hQkuZjT2+SAQEscSm52peDW/getsawMcWF1rGRpMCX6D7nSJA3CzJ8gn13N/g==}
+  '@formatjs/intl-localematcher@0.5.10':
+    resolution: {integrity: sha512-af3qATX+m4Rnd9+wHcjJ4w2ijq+rAVP3CCinJQvFv1kgSu1W6jypUmvleJxcewdxmutM8dmIRZFxO/IQBZmP2Q==}
+
+  '@humanfs/core@0.19.1':
+    resolution: {integrity: sha512-5DyQ4+1JEUzejeK1JGICcideyfUbGixgS9jNgex5nqkW+cY7WZhxBigmieN5Qnw9ZosSNVC9KQKyb+GUaGyKUA==}
+    engines: {node: '>=18.18.0'}
+
+  '@humanfs/node@0.16.6':
+    resolution: {integrity: sha512-YuI2ZHQL78Q5HbhDiBA1X4LmYdXCKCMQIfw0pw7piHJwyREFebJUvrQN4cMssyES6x+vfUbx1CIpaQUKYdQZOw==}
+    engines: {node: '>=18.18.0'}
 
   '@humanwhocodes/module-importer@1.0.1':
     resolution: {integrity: sha512-bxveV4V8v5Yb4ncFTT3rPSgZBOpCkjfK0y4oVVVJwIuDVBRMDXrPyXRL988i5ap9m9bnyEEjWfm5WkBmtffLfA==}
     engines: {node: '>=12.22'}
 
-  '@humanwhocodes/retry@0.3.0':
-    resolution: {integrity: sha512-d2CGZR2o7fS6sWB7DG/3a95bGKQyHMACZ5aW8qGkkqQpUoZV6C0X7Pc7l4ZNMZkfNBf4VWNe9E1jRsf0G146Ew==}
+  '@humanwhocodes/retry@0.3.1':
+    resolution: {integrity: sha512-JBxkERygn7Bv/GbN5Rv8Ul6LVknS+5Bp6RgDC/O8gEBU/yeH5Ui5C/OlWrTb6qct7LjjfT6Re2NxB0ln0yYybA==}
+    engines: {node: '>=18.18'}
+
+  '@humanwhocodes/retry@0.4.1':
+    resolution: {integrity: sha512-c7hNEllBlenFTHBky65mhq8WD2kbN9Q6gk0bTk8lSBvc554jpXSkST1iePudpt7+A/AQvuHs9EMqjHDXMY1lrA==}
     engines: {node: '>=18.18'}
 
   '@iarna/toml@2.2.5':
     resolution: {integrity: sha512-trnsAYxU3xnS1gPHPyU961coFyLkh4gAD/0zQ5mymY4yOZ+CYvsPqUbOFSw0aDM4y0tV7tiFxL/1XfXPNC6IPg==}
 
-  '@img/sharp-darwin-arm64@0.33.4':
-    resolution: {integrity: sha512-p0suNqXufJs9t3RqLBO6vvrgr5OhgbWp76s5gTRvdmxmuv9E1rcaqGUsl3l4mKVmXPkTkTErXediAui4x+8PSA==}
-    engines: {glibc: '>=2.26', node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-darwin-arm64@0.33.5':
+    resolution: {integrity: sha512-UT4p+iz/2H4twwAoLCqfA9UH5pI6DggwKEGuaPy7nCVQ8ZsiY5PIcrRvD1DzuY3qYL07NtIQcWnBSY/heikIFQ==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [arm64]
     os: [darwin]
 
-  '@img/sharp-darwin-x64@0.33.4':
-    resolution: {integrity: sha512-0l7yRObwtTi82Z6ebVI2PnHT8EB2NxBgpK2MiKJZJ7cz32R4lxd001ecMhzzsZig3Yv9oclvqqdV93jo9hy+Dw==}
-    engines: {glibc: '>=2.26', node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-darwin-x64@0.33.5':
+    resolution: {integrity: sha512-fyHac4jIc1ANYGRDxtiqelIbdWkIuQaI84Mv45KvGRRxSAa7o7d1ZKAOBaYbnepLC1WqxfpimdeWfvqqSGwR2Q==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [x64]
     os: [darwin]
 
-  '@img/sharp-libvips-darwin-arm64@1.0.2':
-    resolution: {integrity: sha512-tcK/41Rq8IKlSaKRCCAuuY3lDJjQnYIW1UXU1kxcEKrfL8WR7N6+rzNoOxoQRJWTAECuKwgAHnPvqXGN8XfkHA==}
-    engines: {macos: '>=11', npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-libvips-darwin-arm64@1.0.4':
+    resolution: {integrity: sha512-XblONe153h0O2zuFfTAbQYAX2JhYmDHeWikp1LM9Hul9gVPjFY427k6dFEcOL72O01QxQsWi761svJ/ev9xEDg==}
     cpu: [arm64]
     os: [darwin]
 
-  '@img/sharp-libvips-darwin-x64@1.0.2':
-    resolution: {integrity: sha512-Ofw+7oaWa0HiiMiKWqqaZbaYV3/UGL2wAPeLuJTx+9cXpCRdvQhCLG0IH8YGwM0yGWGLpsF4Su9vM1o6aer+Fw==}
-    engines: {macos: '>=10.13', npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-libvips-darwin-x64@1.0.4':
+    resolution: {integrity: sha512-xnGR8YuZYfJGmWPvmlunFaWJsb9T/AO2ykoP3Fz/0X5XV2aoYBPkX6xqCQvUTKKiLddarLaxpzNe+b1hjeWHAQ==}
     cpu: [x64]
     os: [darwin]
 
-  '@img/sharp-libvips-linux-arm64@1.0.2':
-    resolution: {integrity: sha512-x7kCt3N00ofFmmkkdshwj3vGPCnmiDh7Gwnd4nUwZln2YjqPxV1NlTyZOvoDWdKQVDL911487HOueBvrpflagw==}
-    engines: {glibc: '>=2.26', npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-libvips-linux-arm64@1.0.4':
+    resolution: {integrity: sha512-9B+taZ8DlyyqzZQnoeIvDVR/2F4EbMepXMc/NdVbkzsJbzkUjhXv/70GQJ7tdLA4YJgNP25zukcxpX2/SueNrA==}
     cpu: [arm64]
     os: [linux]
 
-  '@img/sharp-libvips-linux-arm@1.0.2':
-    resolution: {integrity: sha512-iLWCvrKgeFoglQxdEwzu1eQV04o8YeYGFXtfWU26Zr2wWT3q3MTzC+QTCO3ZQfWd3doKHT4Pm2kRmLbupT+sZw==}
-    engines: {glibc: '>=2.28', npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-libvips-linux-arm@1.0.5':
+    resolution: {integrity: sha512-gvcC4ACAOPRNATg/ov8/MnbxFDJqf/pDePbBnuBDcjsI8PssmjoKMAz4LtLaVi+OnSb5FK/yIOamqDwGmXW32g==}
     cpu: [arm]
     os: [linux]
 
-  '@img/sharp-libvips-linux-s390x@1.0.2':
-    resolution: {integrity: sha512-cmhQ1J4qVhfmS6szYW7RT+gLJq9dH2i4maq+qyXayUSn9/3iY2ZeWpbAgSpSVbV2E1JUL2Gg7pwnYQ1h8rQIog==}
-    engines: {glibc: '>=2.28', npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-libvips-linux-s390x@1.0.4':
+    resolution: {integrity: sha512-u7Wz6ntiSSgGSGcjZ55im6uvTrOxSIS8/dgoVMoiGE9I6JAfU50yH5BoDlYA1tcuGS7g/QNtetJnxA6QEsCVTA==}
     cpu: [s390x]
     os: [linux]
 
-  '@img/sharp-libvips-linux-x64@1.0.2':
-    resolution: {integrity: sha512-E441q4Qdb+7yuyiADVi5J+44x8ctlrqn8XgkDTwr4qPJzWkaHwD489iZ4nGDgcuya4iMN3ULV6NwbhRZJ9Z7SQ==}
-    engines: {glibc: '>=2.26', npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-libvips-linux-x64@1.0.4':
+    resolution: {integrity: sha512-MmWmQ3iPFZr0Iev+BAgVMb3ZyC4KeFc3jFxnNbEPas60e1cIfevbtuyf9nDGIzOaW9PdnDciJm+wFFaTlj5xYw==}
     cpu: [x64]
     os: [linux]
 
-  '@img/sharp-libvips-linuxmusl-arm64@1.0.2':
-    resolution: {integrity: sha512-3CAkndNpYUrlDqkCM5qhksfE+qSIREVpyoeHIU6jd48SJZViAmznoQQLAv4hVXF7xyUB9zf+G++e2v1ABjCbEQ==}
-    engines: {musl: '>=1.2.2', npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-libvips-linuxmusl-arm64@1.0.4':
+    resolution: {integrity: sha512-9Ti+BbTYDcsbp4wfYib8Ctm1ilkugkA/uscUn6UXK1ldpC1JjiXbLfFZtRlBhjPZ5o1NCLiDbg8fhUPKStHoTA==}
     cpu: [arm64]
     os: [linux]
 
-  '@img/sharp-libvips-linuxmusl-x64@1.0.2':
-    resolution: {integrity: sha512-VI94Q6khIHqHWNOh6LLdm9s2Ry4zdjWJwH56WoiJU7NTeDwyApdZZ8c+SADC8OH98KWNQXnE01UdJ9CSfZvwZw==}
-    engines: {musl: '>=1.2.2', npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-libvips-linuxmusl-x64@1.0.4':
+    resolution: {integrity: sha512-viYN1KX9m+/hGkJtvYYp+CCLgnJXwiQB39damAO7WMdKWlIhmYTfHjwSbQeUK/20vY154mwezd9HflVFM1wVSw==}
     cpu: [x64]
     os: [linux]
 
-  '@img/sharp-linux-arm64@0.33.4':
-    resolution: {integrity: sha512-2800clwVg1ZQtxwSoTlHvtm9ObgAax7V6MTAB/hDT945Tfyy3hVkmiHpeLPCKYqYR1Gcmv1uDZ3a4OFwkdBL7Q==}
-    engines: {glibc: '>=2.26', node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-linux-arm64@0.33.5':
+    resolution: {integrity: sha512-JMVv+AMRyGOHtO1RFBiJy/MBsgz0x4AWrT6QoEVVTyh1E39TrCUpTRI7mx9VksGX4awWASxqCYLCV4wBZHAYxA==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [arm64]
     os: [linux]
 
-  '@img/sharp-linux-arm@0.33.4':
-    resolution: {integrity: sha512-RUgBD1c0+gCYZGCCe6mMdTiOFS0Zc/XrN0fYd6hISIKcDUbAW5NtSQW9g/powkrXYm6Vzwd6y+fqmExDuCdHNQ==}
-    engines: {glibc: '>=2.28', node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-linux-arm@0.33.5':
+    resolution: {integrity: sha512-JTS1eldqZbJxjvKaAkxhZmBqPRGmxgu+qFKSInv8moZ2AmT5Yib3EQ1c6gp493HvrvV8QgdOXdyaIBrhvFhBMQ==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [arm]
     os: [linux]
 
-  '@img/sharp-linux-s390x@0.33.4':
-    resolution: {integrity: sha512-h3RAL3siQoyzSoH36tUeS0PDmb5wINKGYzcLB5C6DIiAn2F3udeFAum+gj8IbA/82+8RGCTn7XW8WTFnqag4tQ==}
-    engines: {glibc: '>=2.31', node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-linux-s390x@0.33.5':
+    resolution: {integrity: sha512-y/5PCd+mP4CA/sPDKl2961b+C9d+vPAveS33s6Z3zfASk2j5upL6fXVPZi7ztePZ5CuH+1kW8JtvxgbuXHRa4Q==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [s390x]
     os: [linux]
 
-  '@img/sharp-linux-x64@0.33.4':
-    resolution: {integrity: sha512-GoR++s0XW9DGVi8SUGQ/U4AeIzLdNjHka6jidVwapQ/JebGVQIpi52OdyxCNVRE++n1FCLzjDovJNozif7w/Aw==}
-    engines: {glibc: '>=2.26', node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-linux-x64@0.33.5':
+    resolution: {integrity: sha512-opC+Ok5pRNAzuvq1AG0ar+1owsu842/Ab+4qvU879ippJBHvyY5n2mxF1izXqkPYlGuP/M556uh53jRLJmzTWA==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [x64]
     os: [linux]
 
-  '@img/sharp-linuxmusl-arm64@0.33.4':
-    resolution: {integrity: sha512-nhr1yC3BlVrKDTl6cO12gTpXMl4ITBUZieehFvMntlCXFzH2bvKG76tBL2Y/OqhupZt81pR7R+Q5YhJxW0rGgQ==}
-    engines: {musl: '>=1.2.2', node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-linuxmusl-arm64@0.33.5':
+    resolution: {integrity: sha512-XrHMZwGQGvJg2V/oRSUfSAfjfPxO+4DkiRh6p2AFjLQztWUuY/o8Mq0eMQVIY7HJ1CDQUJlxGGZRw1a5bqmd1g==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [arm64]
     os: [linux]
 
-  '@img/sharp-linuxmusl-x64@0.33.4':
-    resolution: {integrity: sha512-uCPTku0zwqDmZEOi4ILyGdmW76tH7dm8kKlOIV1XC5cLyJ71ENAAqarOHQh0RLfpIpbV5KOpXzdU6XkJtS0daw==}
-    engines: {musl: '>=1.2.2', node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-linuxmusl-x64@0.33.5':
+    resolution: {integrity: sha512-WT+d/cgqKkkKySYmqoZ8y3pxx7lx9vVejxW/W4DOFMYVSkErR+w7mf2u8m/y4+xHe7yY9DAXQMWQhpnMuFfScw==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [x64]
     os: [linux]
 
-  '@img/sharp-wasm32@0.33.4':
-    resolution: {integrity: sha512-Bmmauh4sXUsUqkleQahpdNXKvo+wa1V9KhT2pDA4VJGKwnKMJXiSTGphn0gnJrlooda0QxCtXc6RX1XAU6hMnQ==}
-    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-wasm32@0.33.5':
+    resolution: {integrity: sha512-ykUW4LVGaMcU9lu9thv85CbRMAwfeadCJHRsg2GmeRa/cJxsVY9Rbd57JcMxBkKHag5U/x7TSBpScF4U8ElVzg==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [wasm32]
 
-  '@img/sharp-win32-ia32@0.33.4':
-    resolution: {integrity: sha512-99SJ91XzUhYHbx7uhK3+9Lf7+LjwMGQZMDlO/E/YVJ7Nc3lyDFZPGhjwiYdctoH2BOzW9+TnfqcaMKt0jHLdqw==}
-    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-win32-ia32@0.33.5':
+    resolution: {integrity: sha512-T36PblLaTwuVJ/zw/LaH0PdZkRz5rd3SmMHX8GSmR7vtNSP5Z6bQkExdSK7xGWyxLw4sUknBuugTelgw2faBbQ==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [ia32]
     os: [win32]
 
-  '@img/sharp-win32-x64@0.33.4':
-    resolution: {integrity: sha512-3QLocdTRVIrFNye5YocZl+KKpYKP+fksi1QhmOArgx7GyhIbQp/WrJRu176jm8IxromS7RIkzMiMINVdBtC8Aw==}
-    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0, npm: '>=9.6.5', pnpm: '>=7.1.0', yarn: '>=3.2.0'}
+  '@img/sharp-win32-x64@0.33.5':
+    resolution: {integrity: sha512-MpY/o8/8kj+EcnxwvrP4aTJSWw/aZ7JIGR4aBeZkZw5B7/Jn+tY9/VNwtcoGmdT7GfggGIU4kygOMSbYnOrAbg==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
     cpu: [x64]
     os: [win32]
 
-  '@isaacs/cliui@8.0.2':
-    resolution: {integrity: sha512-O8jcjabXaleOG9DQ0+ARXWZBTfnP4WNAqzuiJK7ll44AmxGKv/J2M4TPjxjY3znBCfvBXFzucm1twdyFybFqEA==}
-    engines: {node: '>=12'}
-
-  '@jridgewell/gen-mapping@0.3.5':
-    resolution: {integrity: sha512-IzL8ZoEDIBRWEzlCcRhOaCupYyN5gdIK+Q6fbFdPDg6HqX6jpkItn7DFIpW9LQzXG6Df9sA7+OKnq0qlz/GaQg==}
+  '@jridgewell/gen-mapping@0.3.8':
+    resolution: {integrity: sha512-imAbBGkb+ebQyxKgzv5Hu2nmROxoDOXHh80evxdoXNOrvAnVx7zimzc1Oo5h9RlfV4vPXaE2iM5pOFbvOCClWA==}
     engines: {node: '>=6.0.0'}
 
   '@jridgewell/resolve-uri@3.1.2':
@@ -373,18 +381,21 @@ packages:
   '@jridgewell/source-map@0.3.6':
     resolution: {integrity: sha512-1ZJTZebgqllO79ue2bm3rIGud/bOe0pP5BjSRCRxxYkEZS8STV7zN84UBbiYu7jy+eCKSnVIUgoWWE/tt+shMQ==}
 
-  '@jridgewell/sourcemap-codec@1.4.15':
-    resolution: {integrity: sha512-eF2rxCRulEKXHTRiDrDy6erMYWqNw4LPdQ8UQA4huuxaQsVeRPFl2oM8oDGxMFhJUWZf9McpLtJasDDZb/Bpeg==}
+  '@jridgewell/sourcemap-codec@1.5.0':
+    resolution: {integrity: sha512-gv3ZRaISU3fjPAgNsriBRqGWQL6quFx04YMPW/zD8XMLsU32mhCCbfbO6KZFLjvYpCZ8zyDEgqsgf+PwPaM7GQ==}
 
   '@jridgewell/trace-mapping@0.3.25':
     resolution: {integrity: sha512-vNk6aEwybGtawWmy/PzwnGDOjCkLWSD2wqvjGGAgOAwCGWySYXfYoxt00IJkTF+8Lb57DwOb3Aa0o9CApepiYQ==}
 
-  '@lhci/cli@0.13.0':
-    resolution: {integrity: sha512-Y/ulyvT3h2j1jeFEoNC9RM5zOTW9s48Np3yC/kpKP6++to4ulMu4mKrmFit5zFHKuH7pC1+bkcYwM1/ul78FfQ==}
+  '@keyv/serialize@1.0.2':
+    resolution: {integrity: sha512-+E/LyaAeuABniD/RvUezWVXKpeuvwLEA9//nE9952zBaOdBd2mQ3pPoM8cUe2X6IcMByfuSLzmYqnYshG60+HQ==}
+
+  '@lhci/cli@0.14.0':
+    resolution: {integrity: sha512-TxOH9pFBnmmN7Jmo2Aimxx5UhE8veqXpHfFJDMWsCVxkwh7mGxcAWchGl84mK139SZbbRmerqZ72c+h2nG9/QQ==}
     hasBin: true
 
-  '@lhci/utils@0.13.0':
-    resolution: {integrity: sha512-QkICuVx9rwP8cw0KIV7nEqMldKCddGwYVHal3NnvXl1dGkGJn+0kHZeN8RYZ6aBbLnjTqTCnK0KNAiVxIpD4cw==}
+  '@lhci/utils@0.14.0':
+    resolution: {integrity: sha512-LyP1RbvYQ9xNl7uLnl5AO8fDRata9MG/KYfVFKFkYenlsVS6QJsNjLzWNEoMIaE4jOPdQQlSp4tO7dtnyDxzbQ==}
 
   '@nodelib/fs.scandir@2.1.5':
     resolution: {integrity: sha512-vq24Bq3ym5HEQm2NKCr3yXDwjc7vTsEThRDnkp2DK9p1uqLR+DHurm/NOTo0KG7HYHU7eppKZj3MyqYuMBf62g==}
@@ -398,90 +409,175 @@ packages:
     resolution: {integrity: sha512-oGB+UxlgWcgQkgwo8GcEGwemoTFt3FIO9ababBmaGwXIoBKZ+GTy0pP185beGg7Llih/NSHSV2XAs1lnznocSg==}
     engines: {node: '>= 8'}
 
-  '@percy/cli-app@1.28.8':
-    resolution: {integrity: sha512-UQzO/I2WKhhh18M5zKzOdqSOGLzViIKDX/77r+pEvz3DC/wlEB4bVTrEKFVvLdj1F4WGLfYCpGh2yIf/+OoDEg==}
+  '@parcel/watcher-android-arm64@2.5.0':
+    resolution: {integrity: sha512-qlX4eS28bUcQCdribHkg/herLe+0A9RyYC+mm2PXpncit8z5b3nSqGVzMNR3CmtAOgRutiZ02eIJJgP/b1iEFQ==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [arm64]
+    os: [android]
+
+  '@parcel/watcher-darwin-arm64@2.5.0':
+    resolution: {integrity: sha512-hyZ3TANnzGfLpRA2s/4U1kbw2ZI4qGxaRJbBH2DCSREFfubMswheh8TeiC1sGZ3z2jUf3s37P0BBlrD3sjVTUw==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [arm64]
+    os: [darwin]
+
+  '@parcel/watcher-darwin-x64@2.5.0':
+    resolution: {integrity: sha512-9rhlwd78saKf18fT869/poydQK8YqlU26TMiNg7AIu7eBp9adqbJZqmdFOsbZ5cnLp5XvRo9wcFmNHgHdWaGYA==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [x64]
+    os: [darwin]
+
+  '@parcel/watcher-freebsd-x64@2.5.0':
+    resolution: {integrity: sha512-syvfhZzyM8kErg3VF0xpV8dixJ+RzbUaaGaeb7uDuz0D3FK97/mZ5AJQ3XNnDsXX7KkFNtyQyFrXZzQIcN49Tw==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [x64]
+    os: [freebsd]
+
+  '@parcel/watcher-linux-arm-glibc@2.5.0':
+    resolution: {integrity: sha512-0VQY1K35DQET3dVYWpOaPFecqOT9dbuCfzjxoQyif1Wc574t3kOSkKevULddcR9znz1TcklCE7Ht6NIxjvTqLA==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [arm]
+    os: [linux]
+
+  '@parcel/watcher-linux-arm-musl@2.5.0':
+    resolution: {integrity: sha512-6uHywSIzz8+vi2lAzFeltnYbdHsDm3iIB57d4g5oaB9vKwjb6N6dRIgZMujw4nm5r6v9/BQH0noq6DzHrqr2pA==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [arm]
+    os: [linux]
+
+  '@parcel/watcher-linux-arm64-glibc@2.5.0':
+    resolution: {integrity: sha512-BfNjXwZKxBy4WibDb/LDCriWSKLz+jJRL3cM/DllnHH5QUyoiUNEp3GmL80ZqxeumoADfCCP19+qiYiC8gUBjA==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [arm64]
+    os: [linux]
+
+  '@parcel/watcher-linux-arm64-musl@2.5.0':
+    resolution: {integrity: sha512-S1qARKOphxfiBEkwLUbHjCY9BWPdWnW9j7f7Hb2jPplu8UZ3nes7zpPOW9bkLbHRvWM0WDTsjdOTUgW0xLBN1Q==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [arm64]
+    os: [linux]
+
+  '@parcel/watcher-linux-x64-glibc@2.5.0':
+    resolution: {integrity: sha512-d9AOkusyXARkFD66S6zlGXyzx5RvY+chTP9Jp0ypSTC9d4lzyRs9ovGf/80VCxjKddcUvnsGwCHWuF2EoPgWjw==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [x64]
+    os: [linux]
+
+  '@parcel/watcher-linux-x64-musl@2.5.0':
+    resolution: {integrity: sha512-iqOC+GoTDoFyk/VYSFHwjHhYrk8bljW6zOhPuhi5t9ulqiYq1togGJB5e3PwYVFFfeVgc6pbz3JdQyDoBszVaA==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [x64]
+    os: [linux]
+
+  '@parcel/watcher-win32-arm64@2.5.0':
+    resolution: {integrity: sha512-twtft1d+JRNkM5YbmexfcH/N4znDtjgysFaV9zvZmmJezQsKpkfLYJ+JFV3uygugK6AtIM2oADPkB2AdhBrNig==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [arm64]
+    os: [win32]
+
+  '@parcel/watcher-win32-ia32@2.5.0':
+    resolution: {integrity: sha512-+rgpsNRKwo8A53elqbbHXdOMtY/tAtTzManTWShB5Kk54N8Q9mzNWV7tV+IbGueCbcj826MfWGU3mprWtuf1TA==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [ia32]
+    os: [win32]
+
+  '@parcel/watcher-win32-x64@2.5.0':
+    resolution: {integrity: sha512-lPrxve92zEHdgeff3aiu4gDOIt4u7sJYha6wbdEZDCDUhtjTsOMiaJzG5lMY4GkWH8p0fMmO2Ppq5G5XXG+DQw==}
+    engines: {node: '>= 10.0.0'}
+    cpu: [x64]
+    os: [win32]
+
+  '@parcel/watcher@2.5.0':
+    resolution: {integrity: sha512-i0GV1yJnm2n3Yq1qw6QrUrd/LI9bE8WEBOTtOkpCXHHdyN3TAGgqAK/DAT05z4fq2x04cARXt2pDmjWjL92iTQ==}
+    engines: {node: '>= 10.0.0'}
+
+  '@paulirish/trace_engine@0.0.23':
+    resolution: {integrity: sha512-2ym/q7HhC5K+akXkNV6Gip3oaHpbI6TsGjmcAsl7bcJ528MVbacPQeoauLFEeLXH4ulJvsxQwNDIg/kAEhFZxw==}
+
+  '@percy/cli-app@1.30.6':
+    resolution: {integrity: sha512-IjsWqXcjjXBPErU87Zrvui2k8nogz6trXVUpiGVkPGlFXeGjQXzB95wUECRDqvDTRRrisW1p/XVJi62dUAOX2A==}
     engines: {node: '>=14'}
 
-  '@percy/cli-build@1.28.8':
-    resolution: {integrity: sha512-4PiMffATEsr3CKaHUU9dXPKUu5gWfpVnp2YLawsSjxZj4XsOPqkWC8MsBv7CFVpNBbfjYufSzMe9YLHVcPS14A==}
+  '@percy/cli-build@1.30.6':
+    resolution: {integrity: sha512-8MxuqrjIn2pxuGOVm2V1XkVNrC88a2Xog6qC9omqf69LQfFB5hR1+s40M/MC/9oM8MJFRsNJJ5PUDRHOwgM02Q==}
     engines: {node: '>=14'}
 
-  '@percy/cli-command@1.28.8':
-    resolution: {integrity: sha512-pXV0RqFQYK8bcYvMmf04Bp0HFprq+gqF0B8MrevhqA2YJldISln6TrOEpymQI89Sfj261xdOe6tl0WMIbawAiw==}
+  '@percy/cli-command@1.30.6':
+    resolution: {integrity: sha512-k+/5GTXcbPfgKV6N7yqqt2E3OwQYJl/+fXQZSy7LAfNMR9X0w26ah2ErznyaCsLTPeDyurAJ7SPIOXHsq28uRA==}
     engines: {node: '>=14'}
     hasBin: true
 
-  '@percy/cli-config@1.28.8':
-    resolution: {integrity: sha512-uD13cLYZAhCFdh2zBCCk73LqG/Dx4MUBybs4lLMlAwQZsWRnn4X//99dgVyzOUDzLS8oRWzouFx7Z/5SOcMPvA==}
+  '@percy/cli-config@1.30.6':
+    resolution: {integrity: sha512-hKsadKRizSxe+SuuDItDZV0qd32FNpfUYHhpA1gxkAhAtgZy4d1bINmKgrB6I55cSD1yYZgRGXI1e2+NI5q5ig==}
     engines: {node: '>=14'}
 
-  '@percy/cli-exec@1.28.8':
-    resolution: {integrity: sha512-a2EhPuuykz9WTIdEEdf9zmqGOu1MATz+Ss4rzIIpXlto5k40K42hn/lzRRIQzGNok6ADXJ0vZ0lLgoBX+SMEPw==}
+  '@percy/cli-exec@1.30.6':
+    resolution: {integrity: sha512-N/vdTi5NJWT7AqQt8XgheGgB+vByZtX/WkpG5/a0WsJltOIYJKM0ZZIaUxZsUtXwgustdrEFchlAin/87aasvg==}
     engines: {node: '>=14'}
 
-  '@percy/cli-snapshot@1.28.8':
-    resolution: {integrity: sha512-mIOI9uD0GiOqo4jhaJPRShrgy8isAir3ID9vMQ96B+g2ziUhRWceNdFr+N/OwHFRJ8wyUmJnji2Fr0bNagOWGA==}
+  '@percy/cli-snapshot@1.30.6':
+    resolution: {integrity: sha512-D5qYBLVXBmIYloVfCGfIwYBg3vUXWaTA0dne0aEvIVWBN7QRKncFTHeehGe4CXal9tceFbJyx7yJCu3XXP10hg==}
     engines: {node: '>=14'}
 
-  '@percy/cli-upload@1.28.8':
-    resolution: {integrity: sha512-qgj610GPo3a5cbRXoP6LPfqp9+Qrgo8Sg7aYswomrt6j7zdoV1RAf419eNfP4pYtLoMji4EIGcSMQ91tWv2DoA==}
+  '@percy/cli-upload@1.30.6':
+    resolution: {integrity: sha512-5buyO7tljBOeCKARLegoxT8NvtiZs/kIXt63d7BRVTfJKa7rn/2Xw0Y/DVseGixHFryZ6C//osvE50nHifcKYw==}
     engines: {node: '>=14'}
 
-  '@percy/cli@1.28.8':
-    resolution: {integrity: sha512-sbbiC7Kfs1i+4AsLpHgEx3f6rntXiRShuQa3aNuAQMugXuKgZrr2kI6wzygfO352mYeplblyZNxC0zhXPxtyFA==}
+  '@percy/cli@1.30.6':
+    resolution: {integrity: sha512-bR6niEywRPMXe3Koadk9ryQtCYP62LOTVQddi8I6STlOy8iEUsD2GMa8Sw4oU9hvD250Im0zpe5jP08BwrSfnw==}
     engines: {node: '>=14'}
     hasBin: true
 
-  '@percy/client@1.28.8':
-    resolution: {integrity: sha512-icBiRmLwODrnbxSDmhhN1KLz6W4xE+0bM8rEF/qcUC8SRKecBrz0RA60kyg/jn3H01iv0TOe4NXEMHHk+f7s7w==}
+  '@percy/client@1.30.6':
+    resolution: {integrity: sha512-iHcYK4djy/WA3ZqIVcgOmuOtDeMiGDmJZ0DlDG38HMmAPgXHSThNXNz9bnXb2OSJFxXVRdlAE8DoqFK5FnwNsg==}
     engines: {node: '>=14'}
 
-  '@percy/config@1.28.8':
-    resolution: {integrity: sha512-jsH1CdJQDHfnqRNiR+apugxz3HuMq129LH2+qrf1Ow3nFLRbYfeGD25xiCGMaeDfYCHkY26oSo6409/asBdvpA==}
+  '@percy/config@1.30.6':
+    resolution: {integrity: sha512-qYUu4TVLJgtG/RIwa/AM+d3f1xH4D3uSvCoWUhX4y5rK5QDZ0UqWEvDOD6CJDn8i1xXi4ZY/JB7HKYKUTHeppQ==}
     engines: {node: '>=14'}
 
-  '@percy/core@1.28.8':
-    resolution: {integrity: sha512-6YfhDoTqUhn3Zs8L9xLNHyGVcRzTjCdi51gwZtf9by/+pDCe8eaqpd5QrkoLocdEcV7Oi+FJcoZxE4OZlQNlyQ==}
+  '@percy/core@1.30.6':
+    resolution: {integrity: sha512-G0ULd3pHz8s4RajxUGTWGx8Ngl+jhOjIPNxOBtKh0ywgAnbvUWNWLKYvs9QinZcoPGfWgwc5+1btbeJxTAVGQg==}
     engines: {node: '>=14'}
 
-  '@percy/dom@1.28.8':
-    resolution: {integrity: sha512-0e/357X13C5lt/49ZiB7WHcYDgRs9nEz0hPFA7qnBa+Q0N5pemZCgUZzY1ltge2v9XYT0IAwYgO7P0V0xObRVQ==}
-
-  '@percy/env@1.28.8':
-    resolution: {integrity: sha512-ZuyOPaaQxpCIVs1lgFeb2DRFAfhbAX7LaK8RAKtcAzoKW86YUosL/OWUtmmzQUvnGMWZb611WLIcV48lspkrQQ==}
-    engines: {node: '>=14'}
+  '@percy/dom@1.30.6':
+    resolution: {integrity: sha512-pMlzYYJfgVdNYbw1iJIQZxXzszL3EmIrbGvvpkred3RciJ4T3/pFlqiLiPS7TTUovMFFgRjTR1gLOH1eeWyM5A==}
 
-  '@percy/logger@1.28.8':
-    resolution: {integrity: sha512-yw5O8ZJjA9wNaHv/AgzvPDxDEWpHVFBmF6BDKZ+bT2xErgJt8UFgm0+Zv7pRbqXdoEAEHQbBeaYMrI7QkFaebg==}
+  '@percy/env@1.30.6':
+    resolution: {integrity: sha512-GU3ZcyiCUM3KiRmcpa5fpOIkuHBUonvBhNeg1jErZFEZFQDNm238SFnKQFEJIYCX96W5Q9qqXMwjApj7qBpiWg==}
     engines: {node: '>=14'}
 
-  '@percy/sdk-utils@1.28.8':
-    resolution: {integrity: sha512-eqeIloD3OvHtPVUn08jDKt8m46oakKliEWDGliPdeWTtrfnoTJZtk8yNKe7jn8N3gzNYgU8iytwWFQV00zHBjQ==}
+  '@percy/logger@1.30.6':
+    resolution: {integrity: sha512-HDhAIjjqOlpAIqClu+fvuWSA2cvxh3aMHtKN3gRdRMppHCvyyfmVbKd1PoLPV7Z0SQzZkyaBMAjiRXWMPksLig==}
     engines: {node: '>=14'}
 
-  '@percy/webdriver-utils@1.28.8':
-    resolution: {integrity: sha512-xrL3zBw+coeBs1nrKxHo6Fa3xqLjVACnR9KYc+GR/KrltK3TZF4gmGOHUtFHq7Y+OK9iKFyWqpl0RRwq0Ne2eg==}
+  '@percy/sdk-utils@1.30.6':
+    resolution: {integrity: sha512-LSayDfxAaXJaSv5SIDKMf7EjDl+k4kufYO88YQwc9+9Yr58qqrPFon11x0PvJdA2IDGBo1G6QbvpLUO0Vem2FQ==}
     engines: {node: '>=14'}
 
-  '@pkgjs/parseargs@0.11.0':
-    resolution: {integrity: sha512-+1VkjdD0QBLPodGrJUeqarH8VAIvQODIbwh9XpP5Syisf7YoQgsJKPNFoqqLQlu+VQ/tVSshMR6loPMn8U+dPg==}
+  '@percy/webdriver-utils@1.30.6':
+    resolution: {integrity: sha512-B1M9HWP3ZEM5CuDSMUx+68mrrKm9/JjJ0KO/OLztRh+v7TOsgOWpHMHalurwEIfoNf/olduQ4/Vv9TPrTSj72Q==}
     engines: {node: '>=14'}
 
   '@pkgr/core@0.1.1':
     resolution: {integrity: sha512-cq8o4cWH0ibXh9VGi5P20Tu9XF/0fFXl9EUinr9QfTM7a7p0oTA4iJRCQWppXR1Pg8dSM0UCItCkPwsk9qWWYA==}
     engines: {node: ^12.20.0 || ^14.18.0 || >=16.0.0}
 
-  '@puppeteer/browsers@1.9.1':
-    resolution: {integrity: sha512-PuvK6xZzGhKPvlx3fpfdM2kYY3P/hB1URtK8wA7XUJ6prn6pp22zvJHu48th0SGcHL9SutbPHrFuQgfXTFobWA==}
-    engines: {node: '>=16.3.0'}
+  '@puppeteer/browsers@2.3.0':
+    resolution: {integrity: sha512-ioXoq9gPxkss4MYhD+SFaU9p1IHFUX0ILAWFPyjGaBdjLsYAlZw6j1iLA0N/m12uVHLFDfSYNF7EQccjinIMDA==}
+    engines: {node: '>=18'}
     hasBin: true
 
   '@quasibit/eleventy-plugin-sitemap@2.2.0':
     resolution: {integrity: sha512-7YoU4jjipLjifBhZwttLWbAAkImmBfeMQ0+1ST6mJO45z2mFLHZcgnfHwGF2joNk74wiYNsNOB1ennouzQFZIQ==}
     engines: {node: '>=10.0.0'}
 
-  '@rollup/plugin-commonjs@26.0.1':
-    resolution: {integrity: sha512-UnsKoZK6/aGIH6AdkptXhNvhaqftcjq3zZdT+LY5Ftms6JR06nADcDsYp5hTU9E2lbJUEOhdlY5J4DNTneM+jQ==}
+  '@rgrove/parse-xml@4.2.0':
+    resolution: {integrity: sha512-UuBOt7BOsKVOkFXRe4Ypd/lADuNIfqJXv8GvHqtXaTYXPPKkj2nS2zPllVsrtRjcomDhIJVBnZwfmlI222WH8g==}
+    engines: {node: '>=14.0.0'}
+
+  '@rollup/plugin-commonjs@28.0.2':
+    resolution: {integrity: sha512-BEFI2EDqzl+vA1rl97IDRZ61AIwGH093d9nz8+dThxJNH8oSoB7MjWvPCX3dkaK1/RCJ/1v/R1XB15FuSs0fQw==}
     engines: {node: '>=16.0.0 || 14 >= 14.17'}
     peerDependencies:
       rollup: ^2.68.0||^3.0.0||^4.0.0
@@ -489,8 +585,8 @@ packages:
       rollup:
         optional: true
 
-  '@rollup/plugin-node-resolve@15.2.3':
-    resolution: {integrity: sha512-j/lym8nf5E21LwBT4Df1VD6hRO2L2iwUeUmP7litikRsVp1H6NWx20NEp0Y7su+7XGc476GnXXc4kFeZNGmaSQ==}
+  '@rollup/plugin-node-resolve@16.0.0':
+    resolution: {integrity: sha512-0FPvAeVUT/zdWoO0jnb/V5BlBsUSNfkIOtFHzMO4H9MOklrmQFY6FduVHKucNb/aTFxvnGhj4MNj/T1oNdDfNg==}
     engines: {node: '>=14.0.0'}
     peerDependencies:
       rollup: ^2.78.0||^3.0.0||^4.0.0
@@ -507,8 +603,8 @@ packages:
       rollup:
         optional: true
 
-  '@rollup/pluginutils@5.1.0':
-    resolution: {integrity: sha512-XTIWOPPcpvyKI6L1NHo0lFlCyznUEyPmPY1mc3KpPVDYulHSTvyeLNVW00QTLIAFNhR3kYnJTQHeGqU4M3n09g==}
+  '@rollup/pluginutils@5.1.4':
+    resolution: {integrity: sha512-USm05zrsFxYLPdWWq+K3STlWiT/3ELn3RcV5hJMghpeAIhxfsUIg6mt12CBJBInWMV4VneoV7SfGv8xIwo2qNQ==}
     engines: {node: '>=14.0.0'}
     peerDependencies:
       rollup: ^1.20.0||^2.0.0||^3.0.0||^4.0.0
@@ -516,112 +612,127 @@ packages:
       rollup:
         optional: true
 
-  '@rollup/rollup-android-arm-eabi@4.18.0':
-    resolution: {integrity: sha512-Tya6xypR10giZV1XzxmH5wr25VcZSncG0pZIjfePT0OVBvqNEurzValetGNarVrGiq66EBVAFn15iYX4w6FKgQ==}
+  '@rollup/rollup-android-arm-eabi@4.30.1':
+    resolution: {integrity: sha512-pSWY+EVt3rJ9fQ3IqlrEUtXh3cGqGtPDH1FQlNZehO2yYxCHEX1SPsz1M//NXwYfbTlcKr9WObLnJX9FsS9K1Q==}
     cpu: [arm]
     os: [android]
 
-  '@rollup/rollup-android-arm64@4.18.0':
-    resolution: {integrity: sha512-avCea0RAP03lTsDhEyfy+hpfr85KfyTctMADqHVhLAF3MlIkq83CP8UfAHUssgXTYd+6er6PaAhx/QGv4L1EiA==}
+  '@rollup/rollup-android-arm64@4.30.1':
+    resolution: {integrity: sha512-/NA2qXxE3D/BRjOJM8wQblmArQq1YoBVJjrjoTSBS09jgUisq7bqxNHJ8kjCHeV21W/9WDGwJEWSN0KQ2mtD/w==}
     cpu: [arm64]
     os: [android]
 
-  '@rollup/rollup-darwin-arm64@4.18.0':
-    resolution: {integrity: sha512-IWfdwU7KDSm07Ty0PuA/W2JYoZ4iTj3TUQjkVsO/6U+4I1jN5lcR71ZEvRh52sDOERdnNhhHU57UITXz5jC1/w==}
+  '@rollup/rollup-darwin-arm64@4.30.1':
+    resolution: {integrity: sha512-r7FQIXD7gB0WJ5mokTUgUWPl0eYIH0wnxqeSAhuIwvnnpjdVB8cRRClyKLQr7lgzjctkbp5KmswWszlwYln03Q==}
     cpu: [arm64]
     os: [darwin]
 
-  '@rollup/rollup-darwin-x64@4.18.0':
-    resolution: {integrity: sha512-n2LMsUz7Ynu7DoQrSQkBf8iNrjOGyPLrdSg802vk6XT3FtsgX6JbE8IHRvposskFm9SNxzkLYGSq9QdpLYpRNA==}
+  '@rollup/rollup-darwin-x64@4.30.1':
+    resolution: {integrity: sha512-x78BavIwSH6sqfP2xeI1hd1GpHL8J4W2BXcVM/5KYKoAD3nNsfitQhvWSw+TFtQTLZ9OmlF+FEInEHyubut2OA==}
     cpu: [x64]
     os: [darwin]
 
-  '@rollup/rollup-linux-arm-gnueabihf@4.18.0':
-    resolution: {integrity: sha512-C/zbRYRXFjWvz9Z4haRxcTdnkPt1BtCkz+7RtBSuNmKzMzp3ZxdM28Mpccn6pt28/UWUCTXa+b0Mx1k3g6NOMA==}
+  '@rollup/rollup-freebsd-arm64@4.30.1':
+    resolution: {integrity: sha512-HYTlUAjbO1z8ywxsDFWADfTRfTIIy/oUlfIDmlHYmjUP2QRDTzBuWXc9O4CXM+bo9qfiCclmHk1x4ogBjOUpUQ==}
+    cpu: [arm64]
+    os: [freebsd]
+
+  '@rollup/rollup-freebsd-x64@4.30.1':
+    resolution: {integrity: sha512-1MEdGqogQLccphhX5myCJqeGNYTNcmTyaic9S7CG3JhwuIByJ7J05vGbZxsizQthP1xpVx7kd3o31eOogfEirw==}
+    cpu: [x64]
+    os: [freebsd]
+
+  '@rollup/rollup-linux-arm-gnueabihf@4.30.1':
+    resolution: {integrity: sha512-PaMRNBSqCx7K3Wc9QZkFx5+CX27WFpAMxJNiYGAXfmMIKC7jstlr32UhTgK6T07OtqR+wYlWm9IxzennjnvdJg==}
     cpu: [arm]
     os: [linux]
 
-  '@rollup/rollup-linux-arm-musleabihf@4.18.0':
-    resolution: {integrity: sha512-l3m9ewPgjQSXrUMHg93vt0hYCGnrMOcUpTz6FLtbwljo2HluS4zTXFy2571YQbisTnfTKPZ01u/ukJdQTLGh9A==}
+  '@rollup/rollup-linux-arm-musleabihf@4.30.1':
+    resolution: {integrity: sha512-B8Rcyj9AV7ZlEFqvB5BubG5iO6ANDsRKlhIxySXcF1axXYUyqwBok+XZPgIYGBgs7LDXfWfifxhw0Ik57T0Yug==}
     cpu: [arm]
     os: [linux]
 
-  '@rollup/rollup-linux-arm64-gnu@4.18.0':
-    resolution: {integrity: sha512-rJ5D47d8WD7J+7STKdCUAgmQk49xuFrRi9pZkWoRD1UeSMakbcepWXPF8ycChBoAqs1pb2wzvbY6Q33WmN2ftw==}
+  '@rollup/rollup-linux-arm64-gnu@4.30.1':
+    resolution: {integrity: sha512-hqVyueGxAj3cBKrAI4aFHLV+h0Lv5VgWZs9CUGqr1z0fZtlADVV1YPOij6AhcK5An33EXaxnDLmJdQikcn5NEw==}
     cpu: [arm64]
     os: [linux]
 
-  '@rollup/rollup-linux-arm64-musl@4.18.0':
-    resolution: {integrity: sha512-be6Yx37b24ZwxQ+wOQXXLZqpq4jTckJhtGlWGZs68TgdKXJgw54lUUoFYrg6Zs/kjzAQwEwYbp8JxZVzZLRepQ==}
+  '@rollup/rollup-linux-arm64-musl@4.30.1':
+    resolution: {integrity: sha512-i4Ab2vnvS1AE1PyOIGp2kXni69gU2DAUVt6FSXeIqUCPIR3ZlheMW3oP2JkukDfu3PsexYRbOiJrY+yVNSk9oA==}
     cpu: [arm64]
     os: [linux]
 
-  '@rollup/rollup-linux-powerpc64le-gnu@4.18.0':
-    resolution: {integrity: sha512-hNVMQK+qrA9Todu9+wqrXOHxFiD5YmdEi3paj6vP02Kx1hjd2LLYR2eaN7DsEshg09+9uzWi2W18MJDlG0cxJA==}
+  '@rollup/rollup-linux-loongarch64-gnu@4.30.1':
+    resolution: {integrity: sha512-fARcF5g296snX0oLGkVxPmysetwUk2zmHcca+e9ObOovBR++9ZPOhqFUM61UUZ2EYpXVPN1redgqVoBB34nTpQ==}
+    cpu: [loong64]
+    os: [linux]
+
+  '@rollup/rollup-linux-powerpc64le-gnu@4.30.1':
+    resolution: {integrity: sha512-GLrZraoO3wVT4uFXh67ElpwQY0DIygxdv0BNW9Hkm3X34wu+BkqrDrkcsIapAY+N2ATEbvak0XQ9gxZtCIA5Rw==}
     cpu: [ppc64]
     os: [linux]
 
-  '@rollup/rollup-linux-riscv64-gnu@4.18.0':
-    resolution: {integrity: sha512-ROCM7i+m1NfdrsmvwSzoxp9HFtmKGHEqu5NNDiZWQtXLA8S5HBCkVvKAxJ8U+CVctHwV2Gb5VUaK7UAkzhDjlg==}
+  '@rollup/rollup-linux-riscv64-gnu@4.30.1':
+    resolution: {integrity: sha512-0WKLaAUUHKBtll0wvOmh6yh3S0wSU9+yas923JIChfxOaaBarmb/lBKPF0w/+jTVozFnOXJeRGZ8NvOxvk/jcw==}
     cpu: [riscv64]
     os: [linux]
 
-  '@rollup/rollup-linux-s390x-gnu@4.18.0':
-    resolution: {integrity: sha512-0UyyRHyDN42QL+NbqevXIIUnKA47A+45WyasO+y2bGJ1mhQrfrtXUpTxCOrfxCR4esV3/RLYyucGVPiUsO8xjg==}
+  '@rollup/rollup-linux-s390x-gnu@4.30.1':
+    resolution: {integrity: sha512-GWFs97Ruxo5Bt+cvVTQkOJ6TIx0xJDD/bMAOXWJg8TCSTEK8RnFeOeiFTxKniTc4vMIaWvCplMAFBt9miGxgkA==}
     cpu: [s390x]
     os: [linux]
 
-  '@rollup/rollup-linux-x64-gnu@4.18.0':
-    resolution: {integrity: sha512-xuglR2rBVHA5UsI8h8UbX4VJ470PtGCf5Vpswh7p2ukaqBGFTnsfzxUBetoWBWymHMxbIG0Cmx7Y9qDZzr648w==}
+  '@rollup/rollup-linux-x64-gnu@4.30.1':
+    resolution: {integrity: sha512-UtgGb7QGgXDIO+tqqJ5oZRGHsDLO8SlpE4MhqpY9Llpzi5rJMvrK6ZGhsRCST2abZdBqIBeXW6WPD5fGK5SDwg==}
     cpu: [x64]
     os: [linux]
 
-  '@rollup/rollup-linux-x64-musl@4.18.0':
-    resolution: {integrity: sha512-LKaqQL9osY/ir2geuLVvRRs+utWUNilzdE90TpyoX0eNqPzWjRm14oMEE+YLve4k/NAqCdPkGYDaDF5Sw+xBfg==}
+  '@rollup/rollup-linux-x64-musl@4.30.1':
+    resolution: {integrity: sha512-V9U8Ey2UqmQsBT+xTOeMzPzwDzyXmnAoO4edZhL7INkwQcaW1Ckv3WJX3qrrp/VHaDkEWIBWhRwP47r8cdrOow==}
     cpu: [x64]
     os: [linux]
 
-  '@rollup/rollup-win32-arm64-msvc@4.18.0':
-    resolution: {integrity: sha512-7J6TkZQFGo9qBKH0pk2cEVSRhJbL6MtfWxth7Y5YmZs57Pi+4x6c2dStAUvaQkHQLnEQv1jzBUW43GvZW8OFqA==}
+  '@rollup/rollup-win32-arm64-msvc@4.30.1':
+    resolution: {integrity: sha512-WabtHWiPaFF47W3PkHnjbmWawnX/aE57K47ZDT1BXTS5GgrBUEpvOzq0FI0V/UYzQJgdb8XlhVNH8/fwV8xDjw==}
     cpu: [arm64]
     os: [win32]
 
-  '@rollup/rollup-win32-ia32-msvc@4.18.0':
-    resolution: {integrity: sha512-Txjh+IxBPbkUB9+SXZMpv+b/vnTEtFyfWZgJ6iyCmt2tdx0OF5WhFowLmnh8ENGNpfUlUZkdI//4IEmhwPieNg==}
+  '@rollup/rollup-win32-ia32-msvc@4.30.1':
+    resolution: {integrity: sha512-pxHAU+Zv39hLUTdQQHUVHf4P+0C47y/ZloorHpzs2SXMRqeAWmGghzAhfOlzFHHwjvgokdFAhC4V+6kC1lRRfw==}
     cpu: [ia32]
     os: [win32]
 
-  '@rollup/rollup-win32-x64-msvc@4.18.0':
-    resolution: {integrity: sha512-UOo5FdvOL0+eIVTgS4tIdbW+TtnBLWg1YBCcU2KWM7nuNwRz9bksDX1bekJJCpu25N1DVWaCwnT39dVQxzqS8g==}
+  '@rollup/rollup-win32-x64-msvc@4.30.1':
+    resolution: {integrity: sha512-D6qjsXGcvhTjv0kI4fU8tUuBDF/Ueee4SVX79VfNDXZa64TfCW1Slkb6Z7O1p7vflqZjcmOVdZlqf8gvJxc6og==}
     cpu: [x64]
     os: [win32]
 
-  '@sentry-internal/browser-utils@8.15.0':
-    resolution: {integrity: sha512-DquySUQRnmMyRbfHH9t/JDwPMsVaCOCzV/6XmMb7s4FDYTWSCSpumJEYfiyJCuI9NeebPHZWF7LZCHH4glSAJQ==}
+  '@sentry-internal/browser-utils@8.48.0':
+    resolution: {integrity: sha512-pLtu0Fa1Ou0v3M1OEO1MB1EONJVmXEGtoTwFRCO1RPQI2ulmkG6BikINClFG5IBpoYKZ33WkEXuM6U5xh+pdZg==}
     engines: {node: '>=14.18'}
 
-  '@sentry-internal/feedback@8.15.0':
-    resolution: {integrity: sha512-W6XiLpw7fL1A0KaHxIH45nbC2M8uagrMoBnMZ1NcqE4AoSe7VtoDqPsLvQ7MgMXwsBYiPu2AItRnKoGFS/dUBA==}
+  '@sentry-internal/feedback@8.48.0':
+    resolution: {integrity: sha512-6PwcJNHVPg0EfZxmN+XxVOClfQpv7MBAweV8t9i5l7VFr8sM/7wPNSeU/cG7iK19Ug9ZEkBpzMOe3G4GXJ5bpw==}
     engines: {node: '>=14.18'}
 
-  '@sentry-internal/replay-canvas@8.15.0':
-    resolution: {integrity: sha512-gfezIuvf94wY748l5wSy4pRm+45GjiBm0Q/KLnXROLZKmbI7MTJrdQXA2Oxut848iISTQo4/LimecFnBDiaGtw==}
+  '@sentry-internal/replay-canvas@8.48.0':
+    resolution: {integrity: sha512-LdivLfBXXB9us1aAc6XaL7/L2Ob4vi3C/fEOXElehg3qHjX6q6pewiv5wBvVXGX1NfZTRvu+X11k6TZoxKsezw==}
     engines: {node: '>=14.18'}
 
-  '@sentry-internal/replay@8.15.0':
-    resolution: {integrity: sha512-d4cA8pjr0CGHkTe8ulqMROYCX3bMHBAi/7DJBr11i4MdNCUl+/pndA9C5TiFv0sFzk/hDZQZS3J+MfGp56ZQHw==}
+  '@sentry-internal/replay@8.48.0':
+    resolution: {integrity: sha512-csILVupc5RkrsTrncuUTGmlB56FQSFjXPYWG8I8yBTGlXEJ+o8oTuF6+55R4vbw3EIzBveXWi4kEBbnQlXW/eg==}
     engines: {node: '>=14.18'}
 
-  '@sentry/browser@8.15.0':
-    resolution: {integrity: sha512-Tx4eFgAqa8tedg30+Cgr7qFocWHise8p3jb/RSNs+TCEBXLVtQidHHVZMO71FWUAC86D7woo5hMKTt+UmB8pgg==}
+  '@sentry/browser@8.48.0':
+    resolution: {integrity: sha512-fuuVULB5/1vI8NoIwXwR3xwhJJqk+y4RdSdajExGF7nnUDBpwUJyXsmYJnOkBO+oLeEs58xaCpotCKiPUNnE3g==}
     engines: {node: '>=14.18'}
 
   '@sentry/core@6.19.7':
     resolution: {integrity: sha512-tOfZ/umqB2AcHPGbIrsFLcvApdTm9ggpi/kQZFkej7kMphjT+SGBiQfYtjyg9jcRW+ilAR4JXC9BGKsdEQ+8Vw==}
     engines: {node: '>=6'}
 
-  '@sentry/core@8.15.0':
-    resolution: {integrity: sha512-RjuEq/34VjNmxlfzq+485jG63/Vst90svQapLwVgBZWgM8jxrLyCRXHU0wfBc7/1IhV/T9GYAplrJQAkG4J9Ow==}
+  '@sentry/core@8.48.0':
+    resolution: {integrity: sha512-VGwYgTfLpvJ5LRO5A+qWo1gpo6SfqaGXL9TOzVgBucAdpzbrYHpZ87sEarDVq/4275uk1b0S293/mfsskFczyw==}
     engines: {node: '>=14.18'}
 
   '@sentry/hub@6.19.7':
@@ -640,18 +751,10 @@ packages:
     resolution: {integrity: sha512-jH84pDYE+hHIbVnab3Hr+ZXr1v8QABfhx39KknxqKWr2l0oEItzepV0URvbEhB446lk/S/59230dlUUIBGsXbg==}
     engines: {node: '>=6'}
 
-  '@sentry/types@8.15.0':
-    resolution: {integrity: sha512-AZc9nSHKuNH8P/7ihmq5fbZBiQ7Gr35kJq9Tad9eVuOgL8D+2b6Vqu/61ljVVlMFI0tBGFsSkWJ/00PfBcVKWg==}
-    engines: {node: '>=14.18'}
-
   '@sentry/utils@6.19.7':
     resolution: {integrity: sha512-z95ECmE3i9pbWoXQrD/7PgkBAzJYR+iXtPuTkpBjDKs86O3mT+PXOT3BAn79w2wkn7/i3vOGD2xVr1uiMl26dA==}
     engines: {node: '>=6'}
 
-  '@sentry/utils@8.15.0':
-    resolution: {integrity: sha512-1ISmyYFuRHJbGun0gUYscyz1aP6RfILUldNAUwQwF0Ycu8YOi4n8uwJRN0aov6cCi41tnZWOMBagSeLxbJiJgQ==}
-    engines: {node: '>=14.18'}
-
   '@sindresorhus/slugify@1.1.2':
     resolution: {integrity: sha512-V9nR/W0Xd9TSGXpZ4iFUcFGhuOJtZX82Fzxj1YISlbSgKvIiNa7eLEZrT0vAraPOt++KHauIVNYgGRgjc13dXA==}
     engines: {node: '>=10'}
@@ -671,8 +774,11 @@ packages:
     resolution: {integrity: sha512-L7z9BgrNEcYyUYtF+HaEfiS5ebkh9jXqbszz7pC0hRBPaatV0XjSD3+eHrpqFemQfgwiFF0QPIarnIihIDn7OA==}
     engines: {node: '>=10.13.0'}
 
-  '@types/estree@1.0.5':
-    resolution: {integrity: sha512-/kYRxGDLWzHOB7q+wtSUQlFrtcdUccpfy+X+9iMBpHK8QLLhx2wIPYuS5DYtR9Wa/YlZAbIovy7qVdB1Aq6Lyw==}
+  '@types/estree@1.0.6':
+    resolution: {integrity: sha512-AYnb1nQyY49te+VRAVgmzfcgjYS91mY5P0TKUDCLEM+gNnA+3T6rWITXRLYCpahpqSQbN5cE+gHpnPyXjHWxcw==}
+
+  '@types/json-schema@7.0.15':
+    resolution: {integrity: sha512-5+fP8P8MFNC+AyZCDxrB2pkZFPGzqQWUzpSeuuVLvm8VMcorNYavBqoFcxK8bQz4Qsbn4oUEEem4wDLfcysGHA==}
 
   '@types/minimatch@3.0.5':
     resolution: {integrity: sha512-Klz949h02Gz2uZCMGwDUSDS1YBlTdDDgbWHi+81l29tQALUtvz4rAYi5uoVhE5Lagoq6DeqAUlbrHvW/mXDgdQ==}
@@ -680,8 +786,8 @@ packages:
   '@types/node@14.18.63':
     resolution: {integrity: sha512-fAtCfv4jJg+ExtXhvCkCqUKZ+4ok/JQk01qDKhL5BDDoS3AxKXhV5/MAVUZyQnSEd2GT92fkgZl0pz0Q0AzcIQ==}
 
-  '@types/node@20.14.10':
-    resolution: {integrity: sha512-MdiXf+nDuMvY0gJKxyfZ7/6UFsETO7mGKF54MVD/ekJS6HdFtpZFBgrh6Pseu64XTb2MLyFPlbW6hj8HYRQNOQ==}
+  '@types/node@22.10.5':
+    resolution: {integrity: sha512-F8Q+SeGimwOo86fiovQh8qiXfFEh2/ocYv7tU5pJ3EXMSSxk1Joj5wefpFK2fHTf/N6HKGSxIDBT9f3gCxXPkQ==}
 
   '@types/resolve@1.20.2':
     resolution: {integrity: sha512-60BCwRFOZCQhDncwQdxxeOEEkbc5dIMccYLwbxsS4TUNeVECQ/pBJ0j09mrHOl/JJvpRPGwO9SvE4nR2Nb/a4Q==}
@@ -728,8 +834,8 @@ packages:
     engines: {node: '>=0.4.0'}
     hasBin: true
 
-  acorn@8.12.1:
-    resolution: {integrity: sha512-tcpGyI9zbizT9JbV6oYE477V6mTlXvvi0T0G3SNIYE2apm/G5huBa1+K89VGeovbg+jycCrfhl3ADxErOuO6Jg==}
+  acorn@8.14.0:
+    resolution: {integrity: sha512-cl669nCJTZBsL97OF4kUQm5g5hC2uihk0NxY3WENAC0TYdILVkAyHymAntgxGkl7K+t0cXIrH5siy5S4XkFycA==}
     engines: {node: '>=0.4.0'}
     hasBin: true
 
@@ -737,15 +843,15 @@ packages:
     resolution: {integrity: sha512-RZNwNclF7+MS/8bDg70amg32dyeZGZxiDuQmZxKLAlQjr3jGyLx+4Kkk58UO7D2QdgFIQCovuSuZESne6RG6XQ==}
     engines: {node: '>= 6.0.0'}
 
-  agent-base@7.1.1:
-    resolution: {integrity: sha512-H0TSyFNDMomMNJQBn8wFV5YC/2eJ+VXECwOadZJT554xP6cODZHPX3H9QMQECxvrgiSOP1pHjy1sMWQVYJOUOA==}
+  agent-base@7.1.3:
+    resolution: {integrity: sha512-jRR5wdylq8CkOe6hei19GGZnxM6rBGwFl3Bg0YItGDimvjGtAvdZk4Pu6Cl4u4Igsws4a1fd1Vq3ezrhn4KmFw==}
     engines: {node: '>= 14'}
 
   ajv@6.12.6:
     resolution: {integrity: sha512-j3fVLgvTo527anyYyJOGTYJbG+vnnQYvE0m5mmkc1TK+nxAppkCLMIL0aZ4dblVCNoGShhm+kzE4ZUykBoMg4g==}
 
-  ajv@8.16.0:
-    resolution: {integrity: sha512-F0twR8U1ZU67JIEtekUcLkXkoO5mMMmgGD8sK/xUFzJ805jxHQl92hImFAqqXMyMYjSPOyUPAwHYhB72g5sTXw==}
+  ajv@8.17.1:
+    resolution: {integrity: sha512-B/gBuNg5SiMTrPkC+A2+cW0RszwxYmn6VYxB/inlBStS5nx6xHIt/ehKRhIMhqusl7a8LjQoZnjCs5vhwxOQ1g==}
 
   ansi-colors@4.1.3:
     resolution: {integrity: sha512-/6w/C21Pm1A7aZitlI5Ni/2J6FFQN8i1Cvz3kHABAAbw93v/NlvKdVOqz7CCWz/3iv/JplRSEEZ83XION15ovw==}
@@ -775,10 +881,6 @@ packages:
     resolution: {integrity: sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==}
     engines: {node: '>=8'}
 
-  ansi-regex@6.0.1:
-    resolution: {integrity: sha512-n5M855fKb2SsfMIiFFoVrABHJC8QtHwVx+mHWP3QcEqBHYienj5dHSgjbxtC0WEZXYt4wcD6zrQElDPhFuZgfA==}
-    engines: {node: '>=12'}
-
   ansi-styles@1.1.0:
     resolution: {integrity: sha512-f2PKUkN5QngiSemowa6Mrk9MPCdtFiOSmibjZ+j1qhLGHHYsqZwmBMRF3IRMVXo8sybDqx2fJl2d/8OphBoWkA==}
     engines: {node: '>=0.10.0'}
@@ -859,8 +961,8 @@ packages:
   asn1@0.2.6:
     resolution: {integrity: sha512-ix/FxPn0MDjeyJ7i/yoHGFt/EX6LyNbxSEhPPXODPL+KB0VPk86UYfL0lMdy+KCnv+fmvIzySwaK5COwqVbWTQ==}
 
-  assert-never@1.3.0:
-    resolution: {integrity: sha512-9Z3vxQ+berkL/JJo0dK+EY3Lp0s3NtSnP3VCLsh5HDcZPrh0M+KQRK5sWhUeyPPH+/RCxZqOxLMR+YC6vlviEQ==}
+  assert-never@1.4.0:
+    resolution: {integrity: sha512-5oJg84os6NMQNl27T9LnZkvvqzvAnHu03ShCnoj6bsJwS7L8AO4lf+C/XjK/nvzEqQB744moC6V128RucQd1jA==}
 
   assert-plus@1.0.0:
     resolution: {integrity: sha512-NfJ4UzBCcQGLDlQq7nHxH+tv3kyZ0hHQqF5BO6J7tNJeP5do1llPr8dZ8zHonfhAu0PHAdMkSo+8o0wxg9lZWw==}
@@ -873,8 +975,8 @@ packages:
   async-limiter@1.0.1:
     resolution: {integrity: sha512-csOlWGAcRFJaI6m+F2WKdnMKr4HhdhFVBk0H/QbJFMCr+uO2kwohwXQPxw/9OCxp05r5ghVBFSyioixx3gfkNQ==}
 
-  async@3.2.5:
-    resolution: {integrity: sha512-baNZyqaaLhyLVKm/DlvdW051MSgO6b8eVfIezl9E5PqWxFgzLm/wQntEW4zOytVburDEr0JlALEpdOFwvErLsg==}
+  async@3.2.6:
+    resolution: {integrity: sha512-htCUDlxyyCLMgaM3xXg0C0LW2xqfuQ6p05pCEIsXuyQ+a1koYKTuBMzRNwmybfLgvJDMd0r1LTn4+E0Ti6C2AA==}
 
   asynckit@0.4.0:
     resolution: {integrity: sha512-Oei9OH4tRh0YqU3GxhX79dM/mwVgvbZJaSNaRk+bshkj0S5cfHcgYakreBjrHwatXKbz+IoIdYLxrKim2MjW0Q==}
@@ -882,15 +984,15 @@ packages:
   aws-sign2@0.7.0:
     resolution: {integrity: sha512-08kcGqnYf/YmjoRhfxyu+CLxBjUtHLXLXX/vUfx9l2LYzG3c1m61nrpyFUZI6zeS+Li/wWMMidD9KgrqtGq3mA==}
 
-  aws4@1.13.0:
-    resolution: {integrity: sha512-3AungXC4I8kKsS9PuS4JH2nc+0bVY/mjgrephHTIi8fpEeGsTHBUJeosp0Wc1myYMElmD0B3Oc4XL/HVJ4PV2g==}
+  aws4@1.13.2:
+    resolution: {integrity: sha512-lHe62zvbTB5eEABUVi/AwVh0ZKY9rMMDhmm+eeyuuUQbQ3+J+fONVQOZyj+DdrvD4BY33uYniyRJ4UJIaSKAfw==}
 
-  axe-core@4.9.1:
-    resolution: {integrity: sha512-QbUdXJVTpvUTHU7871ppZkdOLBeGUKBQWHkHrvN2V9IQWGMt61zf3B45BtzjxEJzYuj0JBjBZP/hmYS/R9pmAw==}
+  axe-core@4.10.2:
+    resolution: {integrity: sha512-RE3mdQ7P3FRSe7eqCWoeQ/Z9QXrtniSjp1wUjt5nRC3WIpz5rSCve6o3fsZ2aCpJtrZjSZgjwXAoTO5k4tEI0w==}
     engines: {node: '>=4'}
 
-  b4a@1.6.6:
-    resolution: {integrity: sha512-5Tk1HLk6b6ctmjIkAcU/Ujv/1WqiDl0F0JdRCR80VsOcUlHcu7pWeWRlOqQLHfDEsVx9YH/aif5AG4ehoCtTmg==}
+  b4a@1.6.7:
+    resolution: {integrity: sha512-OnAYlL5b7LEkALw87fUVafQw5rVR9RjwGd4KUwNQ6DrrNmaVaUCgLipfVlzrPQ4tWOR9P0IXGNOx50jYCCdSJg==}
 
   babel-walk@3.0.0-canary-5:
     resolution: {integrity: sha512-GAwkz0AihzY5bkwIY5QDR+LvsRQgB/B+1foMPvi0FZPMl5fjD7ICiznUiBdLYMH1QYe6vqu4gWYytZOccLouFw==}
@@ -899,8 +1001,20 @@ packages:
   balanced-match@1.0.2:
     resolution: {integrity: sha512-3oSeUO0TMV67hN1AmbXsK4yaqU7tjiHlbxRDZOpH0KW9+CeX4bRAaX0Anxt0tx2MrpRpWwQaPwIlISEJhYU5Pw==}
 
-  bare-events@2.4.2:
-    resolution: {integrity: sha512-qMKFd2qG/36aA4GwvKq8MxnPgCQAmBWmSyLWsJcbn8v03wvIPQ/hG1Ms8bPzndZxMDoHpxez5VOS+gC9Yi24/Q==}
+  bare-events@2.5.4:
+    resolution: {integrity: sha512-+gFfDkR8pj4/TrWCGUGWmJIkBwuxPS5F+a5yWjOHQt2hHvNZd5YLzadjmDUtFmMM4y429bnKLa8bYBMHcYdnQA==}
+
+  bare-fs@2.3.5:
+    resolution: {integrity: sha512-SlE9eTxifPDJrT6YgemQ1WGFleevzwY+XAP1Xqgl56HtcrisC2CHCZ2tq6dBpcH2TnNxwUEUGhweo+lrQtYuiw==}
+
+  bare-os@2.4.4:
+    resolution: {integrity: sha512-z3UiI2yi1mK0sXeRdc4O1Kk8aOa/e+FNWZcTiPB/dfTWyLypuE99LibgRaQki914Jq//yAWylcAt+mknKdixRQ==}
+
+  bare-path@2.1.3:
+    resolution: {integrity: sha512-lh/eITfU8hrj9Ru5quUp0Io1kJWIk1bTjzo7JH1P5dWmQ2EL4hFUlfI8FonAhSlgIfhn63p84CDY/x+PisgcXA==}
+
+  bare-stream@2.6.1:
+    resolution: {integrity: sha512-eVZbtKM+4uehzrsj49KtCy3Pbg7kO1pJ3SKZ1SFrIH/0pnj9scuGGgUlNDf/7qS8WKtGdiJY5Kyhs/ivYPTB/g==}
 
   base64-js@1.5.1:
     resolution: {integrity: sha512-AKpaYlHn8t4SVbOHCy+b5+KKgvR4vrsD8vbvrbiQJps7fKDTkjkDry6ji0rUJjC0kzbNePLwzxq8iypo41qeWA==}
@@ -931,8 +1045,8 @@ packages:
   bluebird@2.11.0:
     resolution: {integrity: sha512-UfFSr22dmHPQqPP9XWHRhq+gWnHCYguQGkXQlbyPtW5qTnhFWA8/iXg765tH0cAjy7l/zPJ1aBTO0g5XgA7kvQ==}
 
-  body-parser@1.20.2:
-    resolution: {integrity: sha512-ml9pReCu3M61kGlqoTm2umSXTlRTuGTx0bfYj+uIUKKYycG5NtSbeetV3faSU6R7ajOPw0g/J1PvK4qNy7s5bA==}
+  body-parser@1.20.3:
+    resolution: {integrity: sha512-7rAxByjUMqQ3/bHJy7D6OGXvx/MMc4IqBn/X0fcM1QUcAItpZrBEYhWGem+tzXH90c+G01ypMcYJBO9Y30203g==}
     engines: {node: '>= 0.8', npm: 1.2.8000 || >= 1.4.16}
 
   boolbase@1.0.0:
@@ -969,20 +1083,22 @@ packages:
   buffer@5.7.1:
     resolution: {integrity: sha512-EHcyIPBQ4BSGlvjB16k5KgAJ27CIsHY/2JBmCRReo48y9rQ3MaUzWX3KVlBa4U7MyX02HdVj0K7C3WaB3ju7FQ==}
 
-  builtin-modules@3.3.0:
-    resolution: {integrity: sha512-zhaCDicdLuWN5UbN5IMnFqNMhNfo919sH85y2/ea+5Yg9TsTkeZxpL+JLbp6cgYFS4sRLp3YV4S6yDuqVWHYOw==}
-    engines: {node: '>=6'}
-
-  bytes@3.0.0:
-    resolution: {integrity: sha512-pMhOfFDPiv9t5jjIXkHosWmkSyQbvsgEVNkz0ERHbuLh2T/7j4Mqqpz523Fe8MVY89KC6Sh/QfS2sM+SjgFDcw==}
-    engines: {node: '>= 0.8'}
+  buffer@6.0.3:
+    resolution: {integrity: sha512-FTiCpNxtwiZZHEZbcbTIcZjERVICn9yq/pDFkTl95/AxzD1naBctN7YO68riM/gLSDY7sdrMby8hofADYuuqOA==}
 
   bytes@3.1.2:
     resolution: {integrity: sha512-/Nf7TyzTx6S3yRJObOAV7956r8cr2+Oj8AC5dt8wSP3BQAoeX58NoHyCU8P8zGkNXStjTSi6fzO6F0pBdcYbEg==}
     engines: {node: '>= 0.8'}
 
-  call-bind@1.0.7:
-    resolution: {integrity: sha512-GHTSNSYICQ7scH7sZ+M2rFopRoLh8t2bLSW6BbgrtLsahOIB5iyAVJf9GjWK3cYTDaMj4XdBpM1cA6pIS0Kv2w==}
+  cacheable@1.8.7:
+    resolution: {integrity: sha512-AbfG7dAuYNjYxFUtL1lAqmlWdxczCJ47w7cFjhGcnGnUdwSo6VgmSojfoW3tUI12HUkgTJ5kqj78yyq6TsFtlg==}
+
+  call-bind-apply-helpers@1.0.1:
+    resolution: {integrity: sha512-BhYE+WDaywFg2TBWYNXAE+8B1ATnThNBqXHP5nQu0jWJdVvY2hvkpyB3qOmtmDePiS5/BDQ8wASEWGMWRG148g==}
+    engines: {node: '>= 0.4'}
+
+  call-bound@1.0.3:
+    resolution: {integrity: sha512-YTd+6wGlNlPxSuri7Y6X8tY2dmm12UMH66RpKMhiX6rsk5wXXnYgbUcOt8kiS31/AjfoTOvCsE+w8nZQLQnzHA==}
     engines: {node: '>= 0.4'}
 
   caller-path@0.1.0:
@@ -1044,6 +1160,10 @@ packages:
     resolution: {integrity: sha512-7VT13fmjotKpGipCW9JEQAusEPE+Ei8nl6/g4FBAmIm0GOOLMua9NDDo/DWp0ZAxCr3cPq5ZpBqmPAQgDda2Pw==}
     engines: {node: '>= 8.10.0'}
 
+  chokidar@4.0.3:
+    resolution: {integrity: sha512-Qgzu8kfBvo+cA4962jnP1KkS6Dop5NS6g7R5LFYJr4b8Ub94PPQXUksCw9PvXoeXPRRddRNC5C1JQUR2SMGtnA==}
+    engines: {node: '>= 14.16.0'}
+
   chrome-launcher@0.13.4:
     resolution: {integrity: sha512-nnzXiDbGKjDSK6t2I+35OAPBy5Pw/39bgkb/ZAFwMhwJbdYBp6aH+vW28ZgtjdU890Q7D+3wN/tB8N66q5Gi2A==}
 
@@ -1052,8 +1172,8 @@ packages:
     engines: {node: '>=12.13.0'}
     hasBin: true
 
-  chromium-bidi@0.5.8:
-    resolution: {integrity: sha512-blqh+1cEQbHBKmok3rVJkBlBxt9beKBgOsxbFgs7UJcoVbbeZ+K7+6liAsjgpc8l1Xd55cQUy14fXZdGSb4zIw==}
+  chromium-bidi@0.6.3:
+    resolution: {integrity: sha512-qXlsCmpCZJAnoTYI83Iu6EdYQpMYdVkCfq08KDh2pmlVqK5t5IA9mGs4/LwCwp4fqisSOMXZxP3HIh8w8aRn0A==}
     peerDependencies:
       devtools-protocol: '*'
 
@@ -1136,8 +1256,8 @@ packages:
     resolution: {integrity: sha512-AF3r7P5dWxL8MxyITRMlORQNaOA2IkAFaTr4k7BUumjPtRpGDTZpl0Pb1XCO6JeDCBdp126Cgs9sMxqSjgYyRg==}
     engines: {node: '>= 0.6'}
 
-  compression@1.7.4:
-    resolution: {integrity: sha512-jaSIDzP9pZVS4ZfQ+TzvtiWhdpFhE2RDHz8QJkpX9SIpLq88VueF5jJw6t+6CUQcAoA6t+x89MLrWAqpfDE8iQ==}
+  compression@1.7.5:
+    resolution: {integrity: sha512-bQJ0YRck5ak3LgtnpKkiabX5pNF7tMUh1BSy2ZBOTh0Dim0BUu6aPPwByIns6/A5Prh8PufSPerMDUklpzes2Q==}
     engines: {node: '>= 0.8.0'}
 
   concat-map@0.0.1:
@@ -1173,8 +1293,8 @@ packages:
     resolution: {integrity: sha512-aSWTXFzaKWkvHO1Ny/s+ePFpvKsPnjc551iI41v3ny/ow6tBG5Vd+FuqGNhh1LxOmVzOlGUriIlOaokOvhaStA==}
     engines: {node: '>= 0.6'}
 
-  cookie@0.6.0:
-    resolution: {integrity: sha512-U71cyTamuh1CRNCfpGY6to28lxvNwPG4Guz/EVjgf3Jmzv0vlDp1atT9eS5dDjMYHucpHbWns6Lwf3BKz6svdw==}
+  cookie@0.7.1:
+    resolution: {integrity: sha512-6DnInpx7SJ2AK3+CTUE/ZM0vWTUboZCegxhC2xiIydHR9jNuTAASBrfEpHhiGOZw/nX51bHt6YQl8jsGo4y/0w==}
     engines: {node: '>= 0.6'}
 
   core-util-is@1.0.2:
@@ -1197,11 +1317,8 @@ packages:
     engines: {node: '>=10.14', npm: '>=6', yarn: '>=1'}
     hasBin: true
 
-  cross-fetch@4.0.0:
-    resolution: {integrity: sha512-e4a5N8lVvuLgAWgnCrLr2PP0YyDOTHa9H/Rj54dirp61qXnNq46m82bRhNqIA5VccJtWBvPTFRV3TtvHUKPB1g==}
-
-  cross-spawn@7.0.3:
-    resolution: {integrity: sha512-iRDPJKUPVEND7dHPO8rkbOnPpyDygcDFtWjpeWNCgy8WP2rXcxXL8TskReQl6OrB2G7+UJrags1q15Fudc7G6w==}
+  cross-spawn@7.0.6:
+    resolution: {integrity: sha512-uV2QOWP2nWzsy2aMp8aRibhi9dlzF5Hgh5SHaB9OiTGEyDTiJJyx0uy51QXdyWbtAHNua4XJzUKca3OzKUd3vA==}
     engines: {node: '>= 8'}
 
   crypto-random-string@2.0.0:
@@ -1247,8 +1364,8 @@ packages:
   data-urls@1.1.0:
     resolution: {integrity: sha512-YTWYI9se1P55u58gL5GkQHW4P6VJBJ5iBT+B5a7i2Tjadhv52paJG0qHX4A0OR6/t52odI64KP2YvFpkDOi3eQ==}
 
-  dayjs@1.11.11:
-    resolution: {integrity: sha512-okzr3f11N6WuqYtZSvm+F776mB41wRZMhKP+hc34YdW+KmtYYK9iqvHSwo2k9FEH3fhGXvOPV6yz2IcSrfRUDg==}
+  dayjs@1.11.13:
+    resolution: {integrity: sha512-oaMBel6gjolK862uaPQOVTA7q3TZhuSvuMQAAglQDOWYO9A91IrAOUJEyKVlqJlHE0vq5p5UXxzdPfMH/x6xNg==}
 
   debug@2.6.9:
     resolution: {integrity: sha512-bC7ElrdJaJnPbAP+1EotYvqZsb3ecl5wi6Bfi6BJTUcNowp6cvspg0jXznRTKDjm/E7AdgFBVeAPVMNcKGsHMA==}
@@ -1258,17 +1375,8 @@ packages:
       supports-color:
         optional: true
 
-  debug@4.3.4:
-    resolution: {integrity: sha512-PRWFHuSU3eDtQJPvnNY7Jcket1j0t5OuOsFzPPzsekD52Zl8qUfFIPEiswXqIvHWGVHOgX+7G/vCNNhehwxfkQ==}
-    engines: {node: '>=6.0'}
-    peerDependencies:
-      supports-color: '*'
-    peerDependenciesMeta:
-      supports-color:
-        optional: true
-
-  debug@4.3.5:
-    resolution: {integrity: sha512-pt0bNEmneDIvdL1Xsd9oDQ/wrQRkXDT4AUWlNZNPKvW5x/jyO9VFXkJUP07vQ2upmw5PlaITaPKc31jK13V+jg==}
+  debug@4.4.0:
+    resolution: {integrity: sha512-6WTZ/IxCY/T6BALoZHaE4ctp9xm+Z5kY/pzYaCHRFeyVhojxlrm+46y68HA6hr0TcwEssoxNiDEUJQjfPZ/RYA==}
     engines: {node: '>=6.0'}
     peerDependencies:
       supports-color: '*'
@@ -1280,6 +1388,9 @@ packages:
     resolution: {integrity: sha512-z2S+W9X73hAUUki+N+9Za2lBlun89zigOyGrsax+KUQ6wKW4ZoWpEYBkGhQjwAjjDCkWxhY0VKEhk8wzY7F5cA==}
     engines: {node: '>=0.10.0'}
 
+  decimal.js@10.4.3:
+    resolution: {integrity: sha512-VBBaLc1MgL5XpzgIP7ny5Z6Nx3UrRkIViUkPUdtl9aya5amy3De1gsUUSB1g3+3sExYNjCAsAznmukyxCb1GRA==}
+
   deep-is@0.1.4:
     resolution: {integrity: sha512-oIPzksmTg4/MriiaYGO+okXDT7ztn/w3Eptv/+gSIdMdKsJo0u4CfYNFJPy+4SKMuCqGw2wxnA+URMg3t8a/bQ==}
 
@@ -1291,10 +1402,6 @@ packages:
     resolution: {integrity: sha512-bDF7bg6OSNcSwFWPu4zYKpVkJZQYVrAANMYB8bc9Szem1D0yKdm4sa/rOCs2aC9+2GMqQ7KnwtZRvDhmLF0dXw==}
     engines: {node: '>= 0.10.0'}
 
-  define-data-property@1.1.4:
-    resolution: {integrity: sha512-rBMvIzlpA8v6E+SJZoo++HAYqsLrkg7MSfIinMPFhmkorw7X+dOXVJQs+QT69zGkzMyfDnIMN2Wid1+NbL3T+A==}
-    engines: {node: '>= 0.4'}
-
   define-lazy-prop@2.0.0:
     resolution: {integrity: sha512-Ds09qNh8yw3khSjiJjiUInaGX9xlqZDY7JVryGxdxV7NPeuqQfplOpQ66yJFZut3jLa5zOwkXw1g9EI2uKh4Og==}
     engines: {node: '>=8'}
@@ -1319,6 +1426,11 @@ packages:
     resolution: {integrity: sha512-2sJGJTaXIIaR1w4iJSNoN0hnMY7Gpc/n8D4qSCJw8QqFWXf7cuAgnEHxBpweaVcPevC2l3KpjYCx3NypQQgaJg==}
     engines: {node: '>= 0.8', npm: 1.2.8000 || >= 1.4.16}
 
+  detect-libc@1.0.3:
+    resolution: {integrity: sha512-pGjwhsmsp4kL2RTz08wcOlGN83otlqHeD/Z5T8GXZB+/YcpQ/dgo+lbU8ZsGxV0HIvqqxo9l7mqYwyYMD9bKDg==}
+    engines: {node: '>=0.10'}
+    hasBin: true
+
   detect-libc@2.0.3:
     resolution: {integrity: sha512-bwy0MGW55bG41VqxxypOsdSdGqLwXPI/focwgTYCFMbdUiBAxLg9CFzG08sz2aqzknwiX7Hkl0bQENjg8iLByw==}
     engines: {node: '>=8'}
@@ -1331,11 +1443,8 @@ packages:
   dev-null@0.1.1:
     resolution: {integrity: sha512-nMNZG0zfMgmdv8S5O0TM5cpwNbGKRGPCxVsr0SmA3NZZy9CYBbuNLL0PD3Acx9e5LIUgwONXtM9kM6RlawPxEQ==}
 
-  devtools-protocol@0.0.1211954:
-    resolution: {integrity: sha512-f6BRhngr9wpHN8omZOoSaEJFscTL+tjNhmeBqHHC3CZ3K2N75sDeKXZeTkAEkTCcrusDatfwjRRBh0uz4ov/sA==}
-
-  devtools-protocol@0.0.1232444:
-    resolution: {integrity: sha512-pM27vqEfxSxRkTMnF+XCmxSEb6duO5R+t8A9DEEJgy4Wz2RVanje2mmj99B6A3zv2r/qGfYlOvYznUhuokizmg==}
+  devtools-protocol@0.0.1312386:
+    resolution: {integrity: sha512-DPnhUXvmvKT2dFA/j7B+riVLUt9Q6RKJlcppojL5CoRywJJKLDYnRlw0gTFKfgDPHP5E04UoB71SxoJlVZy8FA==}
 
   doctypes@1.1.0:
     resolution: {integrity: sha512-LLBi6pEqS6Do3EKQ3J0NqHWV5hhb78Pi8vvESYwyOy2c31ZEZVdtitdzsQsKb7878PEERhzUk0ftqGhG6Mz+pQ==}
@@ -1364,22 +1473,23 @@ packages:
   domutils@2.8.0:
     resolution: {integrity: sha512-w96Cjofp72M5IIhpjgobBimYEfoPjx1Vx0BSX9P30WBdZW2WIKU0T1Bd0kz2eNZ9ikjKgHbEyKx8BB6H1L3h3A==}
 
-  domutils@3.1.0:
-    resolution: {integrity: sha512-H78uMmQtI2AhgDJjWeQmHwJJ2bLPD3GMmO7Zja/ZZh84wkm+4ut+IUnUdRa8uCGX88DiVx1j6FRe1XfxEgjEZA==}
+  domutils@3.2.2:
+    resolution: {integrity: sha512-6kZKyUajlDuqlHKVX1w7gyslj9MPIXzIFiz/rGu35uC1wMi+kMhQwGhl4lt9unC9Vb9INnY9Z3/ZA3+FhASLaw==}
 
   dot-prop@5.3.0:
     resolution: {integrity: sha512-QM8q3zDe58hqUqjraQOmzZ1LIH9SWQJTlEKCH4kJ2oQvLZk7RbQXvtDM2XEq3fwkV9CCvvH4LA0AV+ogFsBM2Q==}
     engines: {node: '>=8'}
 
+  dunder-proto@1.0.1:
+    resolution: {integrity: sha512-KIN/nDJBQRcXw0MLVhZE9iQHmG68qAVIBg9CqmUYjmQIhgij9U5MFvrqkUL5FbtyyzZuOeOt0zdeRe4UY7ct+A==}
+    engines: {node: '>= 0.4'}
+
   duplexer@0.1.1:
     resolution: {integrity: sha512-sxNZ+ljy+RA1maXoUReeqBBpBC6RLKmg5ewzV+x+mSETmWNoKdZN6vcQjpFROemza23hGFskJtFNoUWUaQ+R4Q==}
 
   duplexer@0.1.2:
     resolution: {integrity: sha512-jtD6YG370ZCIi/9GTaJKQxWTZD045+4R4hTk/x1UyoqadyJ9x9CgSi1RlVDQF8U2sxLLSnFkCaMihqljHIWgMg==}
 
-  eastasianwidth@0.2.0:
-    resolution: {integrity: sha512-I88TYZWc9XiYHRQ4/3c5rjjfgkjhLyW2luGIheGERbNQ6OY7yTybanSpDXZa8y7VUP9YmDcYa+eyq4ca7iLqWA==}
-
   ecc-jsbn@0.1.2:
     resolution: {integrity: sha512-eh9O+hwRHNbG4BLTjEl3nw044CkGm5X6LoaCf7LPp7UU8Qrt47JYNi6nPX8xjW97TKGKm1ouctg0QSpZe9qrnw==}
 
@@ -1394,18 +1504,19 @@ packages:
   emoji-regex@8.0.0:
     resolution: {integrity: sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==}
 
-  emoji-regex@9.2.2:
-    resolution: {integrity: sha512-L18DaJsXSUk2+42pv8mLs5jJT2hqFkFE4j21wOmgbUqsZ2hL72NsUU785g9RXgo3s0ZNgVl42TiHp3ZtOv/Vyg==}
-
   encodeurl@1.0.2:
     resolution: {integrity: sha512-TPJXq8JqFaVYm2CWmPvnP2Iyo4ZSM7/QKcSmuMLDObfpH5fi7RUGmd/rTDf+rut/saiDiQEeVTNgAmJEdAOx0w==}
     engines: {node: '>= 0.8'}
 
+  encodeurl@2.0.0:
+    resolution: {integrity: sha512-Q0n9HRi4m6JuGIV1eFlmvJB7ZEVxu93IrMyiMsGC0lrMJMWzRgx6WGquyfQgZVb31vhGgXnfmPNNXmxnOkRBrg==}
+    engines: {node: '>= 0.8'}
+
   end-of-stream@1.4.4:
     resolution: {integrity: sha512-+uw1inIHVPQoaVuHzRyXd21icM+cnt4CzD5rW+NC1wjOUSTOs+Te7FOv7AhN7vS9x/oIyhLP5PR1H+phQAHu5Q==}
 
-  enhanced-resolve@5.17.0:
-    resolution: {integrity: sha512-dwDPwZL0dmye8Txp2gzFmA6sxALaSvdRDjPH0viLcKrtlOL3tw62nWWweVD1SdILDTJrbrL6tdWVN58Wo6U3eA==}
+  enhanced-resolve@5.18.0:
+    resolution: {integrity: sha512-0/r0MySGYG8YqlayBZ6MuCfECmHFdJ5qyPh8s8wa5Hnm6SaFLSK1VYCbj+NKp090Nm1caZhD+QTnmxO7esYGyQ==}
     engines: {node: '>=10.13.0'}
 
   enquirer@2.4.1:
@@ -1423,6 +1534,10 @@ packages:
     resolution: {integrity: sha512-V0hjH4dGPh9Ao5p0MoRY6BVqtwCjhz6vI5LT8AJ55H+4g9/4vbHx1I54fS0XuclLhDHArPQCiMjDxjaL8fPxhw==}
     engines: {node: '>=0.12'}
 
+  entities@6.0.0:
+    resolution: {integrity: sha512-aKstq2TDOndCn4diEyp9Uq/Flu2i1GlLkc6XIDQSDMuaFE3OPW5OphLCyQ5SpSJZTb4reN+kTcYru5yIfXoRPw==}
+    engines: {node: '>=0.12'}
+
   eol@0.2.0:
     resolution: {integrity: sha512-LCBxmDyUDh5pAXALohe9NCwyedyECwpFrcebZyW/XNTzn4WZFY3cX9MdkrJQu71ojEoHqcsciqFG7d3WQA+1Ew==}
 
@@ -1436,16 +1551,20 @@ packages:
   errors@0.2.0:
     resolution: {integrity: sha512-W0w4yTo+twP/wGTF25kBGAXroAHzvxZvEDHJsCixlWS8lf8li0aZDhT+hz0mHQwsSW5esD5jyTQkaqA0ZHF83A==}
 
-  es-define-property@1.0.0:
-    resolution: {integrity: sha512-jxayLKShrEqqzJ0eumQbVhTYQM27CfT1T35+gCgDFoL82JLsXqTJ76zv6A0YLOgEnLUMvLzsDsGIrl8NFpT2gQ==}
+  es-define-property@1.0.1:
+    resolution: {integrity: sha512-e3nRfgfUZ4rNGL232gUgX06QNyyez04KdjFrF+LTRoOXmrOgFKDg4BCdsjW8EnT69eqdYGmRpJwiPVYNrCaW3g==}
     engines: {node: '>= 0.4'}
 
   es-errors@1.3.0:
     resolution: {integrity: sha512-Zf5H2Kxt2xjTvbJvP2ZWLEICxA6j+hAmMzIlypy4xcBg1vKVnx89Wy0GbS+kf5cwCVFFzdCFh2XSCFNULS6csw==}
     engines: {node: '>= 0.4'}
 
-  escalade@3.1.2:
-    resolution: {integrity: sha512-ErCHMCae19vR8vQGe50xIsVomy19rg6gFu3+r3jkEO46suLMWBksvVyoGgQV+jOfl84ZSOSlmv6Gxa89PmTGmA==}
+  es-object-atoms@1.0.0:
+    resolution: {integrity: sha512-MZ4iQ6JwHOBQjahnjwaC1ZtIBH+2ohjamzAO3oaHcXYup7qxjF2fixyH+Q71voWHeOkI2q/TnJao/KfXYIZWbw==}
+    engines: {node: '>= 0.4'}
+
+  escalade@3.2.0:
+    resolution: {integrity: sha512-WUj2qlxaQtO4g6Pq5c29GTcWGDyd8itL8zTlipgECz3JesAiiOKotd8JU6otB3PACgG6xkJUyVhboMS+bje/jA==}
     engines: {node: '>=6'}
 
   escape-html@1.0.3:
@@ -1479,8 +1598,8 @@ packages:
     peerDependencies:
       eslint: '>=6.0.0'
 
-  eslint-config-prettier@9.1.0:
-    resolution: {integrity: sha512-NSWl5BFQWEPi1j4TjVNItzYV7dZXZ+wP6I6ZhrBGpChQhZRUaElihE9uRRkcbRnNb76UMKDF3r+WTmNcGPKsqw==}
+  eslint-config-prettier@10.0.1:
+    resolution: {integrity: sha512-lZBts941cyJyeaooiKxAtzoPHTN+GbQTJFAIdQbRhA4/8whaAraEh47Whw/ZFfrjNSnlAxqfm9i0XVAEkULjCw==}
     hasBin: true
     peerDependencies:
       eslint: '>=7.0.0'
@@ -1491,14 +1610,14 @@ packages:
     peerDependencies:
       eslint: '>=8'
 
-  eslint-plugin-n@17.9.0:
-    resolution: {integrity: sha512-CPSaXDXdrT4nsrOrO4mT4VB6FMUkoySRkHWuuJJHVqsIEjIeZgMY1H7AzSwPbDScikBmLN82KeM1u7ixV7PzGg==}
+  eslint-plugin-n@17.15.1:
+    resolution: {integrity: sha512-KFw7x02hZZkBdbZEFQduRGH4VkIH4MW97ClsbAM4Y4E6KguBJWGfWG1P4HEIpZk2bkoWf0bojpnjNAhYQP8beA==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
     peerDependencies:
       eslint: '>=8.23.0'
 
-  eslint-plugin-prettier@5.1.3:
-    resolution: {integrity: sha512-C9GCVAs4Eq7ZC/XFQHITLiHJxQngdtraXaM+LoUFoFp/lHNl2Zn8f3WQbe9HvTBBQ9YnKFB0/2Ajdqwo5D1EAw==}
+  eslint-plugin-prettier@5.2.1:
+    resolution: {integrity: sha512-gH3iR3g4JfF+yYPaJYkN7jEl9QbweL/YfkoRlNnuIEHEz1vHVlCmWOS+eGGiRuzHQXdJFCOTxRgvju9b8VUmrw==}
     engines: {node: ^14.18.0 || >=16.0.0}
     peerDependencies:
       '@types/eslint': '>=8.0.0'
@@ -1511,25 +1630,30 @@ packages:
       eslint-config-prettier:
         optional: true
 
-  eslint-scope@8.0.1:
-    resolution: {integrity: sha512-pL8XjgP4ZOmmwfFE8mEhSxA7ZY4C+LWyqjQ3o4yWkkmD0qcMT9kkW3zWHOczhWcjTSgqycYAgwSlXvZltv65og==}
+  eslint-scope@8.2.0:
+    resolution: {integrity: sha512-PHlWUfG6lvPc3yvP5A4PNyBL1W8fkDUccmI21JUu/+GKZBoH/W5u6usENXUrWFRsyoW5ACUjFGgAFQp5gUlb/A==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
   eslint-visitor-keys@3.4.3:
     resolution: {integrity: sha512-wpc+LXeiyiisxPlEkUzU6svyS1frIO3Mgxj1fdy7Pm8Ygzguax2N3Fa/D/ag1WqbOprdI+uY6wMUl8/a2G+iag==}
     engines: {node: ^12.22.0 || ^14.17.0 || >=16.0.0}
 
-  eslint-visitor-keys@4.0.0:
-    resolution: {integrity: sha512-OtIRv/2GyiF6o/d8K7MYKKbXrOUBIK6SfkIRM4Z0dY3w+LiQ0vy3F57m0Z71bjbyeiWFiHJ8brqnmE6H6/jEuw==}
+  eslint-visitor-keys@4.2.0:
+    resolution: {integrity: sha512-UyLnSehNt62FFhSwjZlHmeokpRK59rcz29j+F1/aDgbkbRTk7wIc9XzdoasMUbRNKDM0qQt/+BJ4BrpFeABemw==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
-  eslint@9.6.0:
-    resolution: {integrity: sha512-ElQkdLMEEqQNM9Njff+2Y4q2afHk7JpkPvrd7Xh7xefwgQynqPxwf55J7di9+MEibWUGdNjFF9ITG9Pck5M84w==}
+  eslint@9.18.0:
+    resolution: {integrity: sha512-+waTfRWQlSbpt3KWE+CjrPPYnbq9kfZIYUqapc0uBXyjTp8aYXZDsUH16m39Ryq3NjAVP4tjuF7KaukeqoCoaA==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
     hasBin: true
+    peerDependencies:
+      jiti: '*'
+    peerDependenciesMeta:
+      jiti:
+        optional: true
 
-  espree@10.1.0:
-    resolution: {integrity: sha512-M1M6CpiE6ffoigIOWYO9UDP8TMUw9kqb21tf+08IgDYjCsOvCuDt4jQcZmoYxx+w7zlKw9/N0KXfto+I8/FrXA==}
+  espree@10.3.0:
+    resolution: {integrity: sha512-0QYC8b24HWY8zjRnDTL6RiHfDbAWn63qb4LMj1Z4b076A4une81+z03Kg7l7mn/48PUTqoLptSXez8oknU8Clg==}
     engines: {node: ^18.18.0 || ^20.9.0 || >=21.1.0}
 
   esprima@4.0.1:
@@ -1537,8 +1661,8 @@ packages:
     engines: {node: '>=4'}
     hasBin: true
 
-  esquery@1.5.0:
-    resolution: {integrity: sha512-YQLXUplAwJgCydQ78IMJywZCceoqk1oH01OERdSAJc/7U2AylwjhSCLDEtqwg811idIS/9fIU5GjG73IgjKMVg==}
+  esquery@1.6.0:
+    resolution: {integrity: sha512-ca9pw9fomFcKPvFLXhBKUK90ZvGibiGOvRJNbjljY7s7uq/5YO4BOzcYtJqExdx99rF6aAcnRxHmcUHcz6sQsg==}
     engines: {node: '>=0.10'}
 
   esrecurse@4.3.0:
@@ -1567,8 +1691,8 @@ packages:
   eventemitter3@4.0.7:
     resolution: {integrity: sha512-8guHBZCwKnFhYdHr2ysuRWErTwhoN2X8XELRlrRwpmfeY2jjuUN4taQMsULKUVo1K4DvZl+0pgfyoysHxvmvEw==}
 
-  express@4.19.2:
-    resolution: {integrity: sha512-5T6nhjsT+EOMzuck8JjBHARTHfMht0POzlA60WV2pMD3gyXw2LZnZ+ueGdNxG+0calOJcWKbpFcuzLZ91YWq9Q==}
+  express@4.21.2:
+    resolution: {integrity: sha512-28HqgMZAmih1Czt9ny7qr6ek2qddF4FclbMzwhCREB6OFfH+rXAnuNCwo1/wFvrtbgsQDb4kSbX9de9lFbrXnA==}
     engines: {node: '>= 0.10.0'}
 
   extend-shallow@2.0.1:
@@ -1603,8 +1727,8 @@ packages:
   fast-fifo@1.3.2:
     resolution: {integrity: sha512-/d9sfos4yxzpwkDkuN7k2SqFKtYNmCTzgfEpz82x34IM9/zc8KGxQoXg1liNC/izpRM/MBdt44Nmx41ZWqk+FQ==}
 
-  fast-glob@3.3.2:
-    resolution: {integrity: sha512-oX2ruAFQwf/Orj8m737Y5adxDQO0LAB7/S5MnxCdTNDd4p6BsyIVsv9JQsATbTSq8KHRpLwIHbVlUNatxd+1Ow==}
+  fast-glob@3.3.3:
+    resolution: {integrity: sha512-7MptL8U0cqcFdzIzwOTHoilX9x5BrNqye7Z/LuC7kCMRio1EMSyqRK3BEAUD7sXRq4iT4AzTVuZdhgQ2TCvYLg==}
     engines: {node: '>=8.6.0'}
 
   fast-json-stable-stringify@2.1.0:
@@ -1613,12 +1737,23 @@ packages:
   fast-levenshtein@2.0.6:
     resolution: {integrity: sha512-DCXu6Ifhqcks7TZKY3Hxp3y6qphY5SJZmrWMDrKcERSOXWQdMhU9Ig/PYrzyw/ul9jOIyh0N4M0tbC5hodg8dw==}
 
-  fastq@1.17.1:
-    resolution: {integrity: sha512-sRVD3lWVIXWg6By68ZN7vho9a1pQcN/WBFaAAsDDFzlJjvoGx0P8z7V1t72grFJfJhu3YPZBuu25f7Kaw2jN1w==}
+  fast-uri@3.0.5:
+    resolution: {integrity: sha512-5JnBCWpFlMo0a3ciDy/JckMzzv1U9coZrIhedq+HXxxUfDTAiS0LA8OKVao4G9BxmCVck/jtA5r3KAtRWEyD8Q==}
+
+  fastq@1.18.0:
+    resolution: {integrity: sha512-QKHXPW0hD8g4UET03SdOdunzSouc9N4AuHdsX8XNcTsuz+yYFILVNIX4l9yHABMhiEI9Db0JTTIpu0wB+Y1QQw==}
 
   fd-slicer@1.1.0:
     resolution: {integrity: sha512-cE1qsB/VwyQozZ+q1dGxR8LBYNZeofhEdUNGSMbQD3Gw2lAzX9Zb3uIU6Ebc/Fmyjo9AWWfnn0AUCHqtevs/8g==}
 
+  fdir@6.4.2:
+    resolution: {integrity: sha512-KnhMXsKSPZlAhp7+IjUkRZKPb4fUyccpDrdFXbi4QL1qkmFh9kVY09Yox+n4MaOb3lHZ1Tv829C3oaaXoMYPDQ==}
+    peerDependencies:
+      picomatch: ^3 || ^4
+    peerDependenciesMeta:
+      picomatch:
+        optional: true
+
   figures@2.0.0:
     resolution: {integrity: sha512-Oa2M9atig69ZkfwiApY8F2Yy+tzMbazyvqv21R0NsSC8floSOC09BbT1ITWAdoMGQvJ/aZnR1KMwdx9tvHnTNA==}
     engines: {node: '>=4'}
@@ -1634,8 +1769,8 @@ packages:
     resolution: {integrity: sha512-YsGpe3WHLK8ZYi4tWDg2Jy3ebRz2rXowDxnld4bkQB00cc/1Zw9AWnC0i9ztDJitivtQvaI9KaLyKrc+hBW0yg==}
     engines: {node: '>=8'}
 
-  finalhandler@1.2.0:
-    resolution: {integrity: sha512-5uXcUVftlQMFnWC9qu/svkWv3GTd2PfUhK/3PLkYNAe7FbqJMt3515HaxE6eRL74GdsriiwujiawdaB1BpEISg==}
+  finalhandler@1.3.1:
+    resolution: {integrity: sha512-6BN9trH7bp3qvnrRyzsBz+g3lZxTNZTbVO2EV1CS0WIcDbawYVdYvGflME/9QP0h0pYlCDBCTjYa9nZzMDpyxQ==}
     engines: {node: '>= 0.8'}
 
   find-up@4.1.0:
@@ -1646,20 +1781,15 @@ packages:
     resolution: {integrity: sha512-78/PXT1wlLLDgTzDs7sjq9hzz0vXD+zn+7wypEe4fXQxCmdmqfGsEPQxmiCSQI3ajFV91bVSsvNtrJRiW6nGng==}
     engines: {node: '>=10'}
 
-  flat-cache@3.2.0:
-    resolution: {integrity: sha512-CYcENa+FtcUKLmhhqyctpclsq7QF38pKjZHsGNiSQF5r4FtoKDWabFDl3hzaEQMvT1LHEysw5twgLvpYYb4vbw==}
-    engines: {node: ^10.12.0 || >=12.0.0}
-
   flat-cache@4.0.1:
     resolution: {integrity: sha512-f7ccFPK3SXFHpx15UIGyRJ/FJQctuKZ0zVuN3frBo4HnK3cay9VEW0R6yPYFHC0AgqhukPzKjq22t5DmAyqGyw==}
     engines: {node: '>=16'}
 
-  flatted@3.3.1:
-    resolution: {integrity: sha512-X8cqMLLie7KsNUDSdzeN8FYK9rEt4Dt67OsG/DNGnYTSDBG4uFAJFBnUeiV+zCVAvwFy56IjM9sH51jVaEhNxw==}
+  flat-cache@6.1.5:
+    resolution: {integrity: sha512-QR+2kN38f8nMfiIQ1LHYjuDEmZNZVjxuxY+HufbS3BW0EX01Q5OnH7iduOYRutmgiXb797HAKcXUeXrvRjjgSQ==}
 
-  foreground-child@3.2.1:
-    resolution: {integrity: sha512-PXUUyLqrR2XCWICfv6ukppP96sdFwWbNEnfEMt7jNsISjMsvaLNinAHNDYyvkyU+SZG2BTSbT5NjG+vZslfGTA==}
-    engines: {node: '>=14'}
+  flatted@3.3.2:
+    resolution: {integrity: sha512-AiwGJM8YcNOaobumgtng+6NHuOqC3A7MixFeDafM3X9cIUM+xUXoS5Vfgf+OihAYe20fxqNM9yPBXJzRtZ/4eA==}
 
   forever-agent@0.6.1:
     resolution: {integrity: sha512-j0KLYPhm6zeac4lz3oJ3o65qvgQCcPubiyotZrXqEaG4hNagNYO8qdlUrX5vwqv9ohqeT/Z3j6+yW067yWWdUw==}
@@ -1682,10 +1812,6 @@ packages:
     resolution: {integrity: sha512-zJ2mQYM18rEFOudeV4GShTGIQ7RbzA7ozbU9I/XBpm7kqgMywgmylMwXHxZJmkVoYkna9d2pVXVXPdYTP9ej8Q==}
     engines: {node: '>= 0.6'}
 
-  fs-extra@11.2.0:
-    resolution: {integrity: sha512-PmDi3uwK5nFuXh7XDTlVnS17xJS7vW36is2+w3xcv8SVxiB4NyATf4ctkVY5bkSjX0Y4nbvZCq1/EjtEyr9ktw==}
-    engines: {node: '>=14.14'}
-
   fs.realpath@1.0.0:
     resolution: {integrity: sha512-OO0pH2lK6a0hZnAdau5ItzHPI6pUlvI7jMVnxUQRtw4owF2wk8lOSabtGDCTP4Ggrg2MbGnWO9X8K1t4+fGMDw==}
 
@@ -1701,19 +1827,23 @@ packages:
     resolution: {integrity: sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==}
     engines: {node: 6.* || 8.* || >= 10.*}
 
-  get-intrinsic@1.2.4:
-    resolution: {integrity: sha512-5uYhsJH8VJBTv7oslg4BznJYhDoRI6waYCxMmCdnTrcCrHA/fCFKoTFz2JKKE0HdDFUF7/oQuhzumXJK7paBRQ==}
+  get-intrinsic@1.2.7:
+    resolution: {integrity: sha512-VW6Pxhsrk0KAOqs3WEd0klDiF/+V7gQOpAvY1jVU/LHmaD/kQO4523aiJuikX/QAKYiW6x8Jh+RJej1almdtCA==}
+    engines: {node: '>= 0.4'}
+
+  get-proto@1.0.1:
+    resolution: {integrity: sha512-sTSfBjoXBp89JvIKIefqw7U2CCebsc74kiY6awiGogKtoSGbgjYE/G/+l9sF3MWFPNc9IcoOC4ODfKHfxFmp0g==}
     engines: {node: '>= 0.4'}
 
   get-stream@5.2.0:
     resolution: {integrity: sha512-nBF+F1rAZVCu/p7rjzgA+Yb4lfYXrpl7a6VmJrU8wF9I1CKvP/QwPNZHnOlwbTkY6dvtFIzFMSyQXbLoTQPRpA==}
     engines: {node: '>=8'}
 
-  get-tsconfig@4.7.5:
-    resolution: {integrity: sha512-ZCuZCnlqNzjb4QprAzXKdpp/gh6KTxSJuw3IBsPnV/7fV4NxC9ckB+vPTt8w7fJA0TaSD7c55BR47JD6MEDyDw==}
+  get-tsconfig@4.8.1:
+    resolution: {integrity: sha512-k9PN+cFBmaLWtVz29SkUoqU5O0slLuHJXt/2P+tMVFT+phsSGXGkp9t3rQIqdz0e+06EHNGs3oM6ZX1s2zHxRg==}
 
-  get-uri@6.0.3:
-    resolution: {integrity: sha512-BzUrJBS9EcUb4cFol8r4W3v1cPsSyajLSthNkz5BxbpDcHN5tIrM10E2eNvfnvBn3DaT3DUgx0OpsBKkaOpanw==}
+  get-uri@6.0.4:
+    resolution: {integrity: sha512-E1b1lFFLvLgak2whF2xDBcOy6NLVGZBqqjJjsIhvopKfWWEi64pLVTWWehV8KlLerZkfNTA95sTe2OdJKm1OzQ==}
     engines: {node: '>= 14'}
 
   getpass@0.1.7:
@@ -1727,11 +1857,6 @@ packages:
     resolution: {integrity: sha512-XxwI8EOhVQgWp6iDL+3b0r86f4d6AX6zSU55HfB4ydCEuXLXc5FcYeOu+nnGftS4TEju/11rt4KJPTMgbfmv4A==}
     engines: {node: '>=10.13.0'}
 
-  glob@10.4.3:
-    resolution: {integrity: sha512-Q38SGlYRpVtDBPSWEylRyctn7uDeTp4NQERTLiCT1FqA9JXPYWqAVmQU6qh4r/zMM5ehxTcbaO8EjhWnvEhmyg==}
-    engines: {node: '>=18'}
-    hasBin: true
-
   glob@7.2.3:
     resolution: {integrity: sha512-nFR0zLpU2YCaRxwoCJvL6UvCH2JFyFVIvwTLsIf21AuHlMskA1hhTdk+LlYJtOlYt9v6dvszD2BGRqBL+iQK9Q==}
     deprecated: Glob versions prior to v9 are no longer supported
@@ -1745,12 +1870,13 @@ packages:
     resolution: {integrity: sha512-oahGvuMGQlPw/ivIYBjVSrWAfWLBeku5tpPE2fOPLi+WHffIWbuh2tCjhyQhTBPMf5E9jDEH4FOmTYgYwbKwtQ==}
     engines: {node: '>=18'}
 
-  globals@15.8.0:
-    resolution: {integrity: sha512-VZAJ4cewHTExBWDHR6yptdIBlx9YSSZuwojj9Nt5mBRXQzrKakDsVKQ1J63sklLvzAJm0X5+RpO4i3Y2hcOnFw==}
+  globals@15.14.0:
+    resolution: {integrity: sha512-OkToC372DtlQeje9/zHIo5CT8lRP/FUgEOKBEhU4e0abL7J7CD24fD9ohiLN5hagG/kWCYj4K5oaxxtj2Z0Dig==}
     engines: {node: '>=18'}
 
-  gopd@1.0.1:
-    resolution: {integrity: sha512-d65bNlIadxvpb/A2abVdlqKqV563juRnZ1Wtk6s1sIR8uNsXR70xqIzVqxVf1eTqDunwT2MkczEeaezCKTZhwA==}
+  gopd@1.2.0:
+    resolution: {integrity: sha512-ZUKRh6/kUFoAiTAtTYPZJ3hw9wNxx+BIBOijnlG9PnrJsCcSjs1wyyD6vJpaYtgnzDrKYRSqf3OO6Rfa93xsRg==}
+    engines: {node: '>= 0.4'}
 
   graceful-fs@4.2.11:
     resolution: {integrity: sha512-RbJ5/jmFcNNCcDV5o9eTnBLJ/HszWV0P73bc+Ff4nS/rJj+YaS6IGyiOL0VoBYX+l1Wrl3k63h/KrH+nhJ0XvQ==}
@@ -1796,15 +1922,8 @@ packages:
     resolution: {integrity: sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==}
     engines: {node: '>=8'}
 
-  has-property-descriptors@1.0.2:
-    resolution: {integrity: sha512-55JNKuIW+vq4Ke1BjOTjM2YctQIvCT7GFzHwmfZPGo5wnrgkid0YQtnAleFSqumZm4az3n2BS+erby5ipJdgrg==}
-
-  has-proto@1.0.3:
-    resolution: {integrity: sha512-SJ1amZAJUiZS+PhsVLf5tGydlaVB8EdFpaSO4gmiUKUOxk8qzn5AIy4ZeJUmh22znIdk/uMAUT2pl3FxzVUH+Q==}
-    engines: {node: '>= 0.4'}
-
-  has-symbols@1.0.3:
-    resolution: {integrity: sha512-l3LCuF6MgDNwTDKkdYGEihYjt5pRPbEg46rtlmnSPlUbgmB8LOIrKJbYYFBSbnPaJexMKtiPO8hmeRjRz2Td+A==}
+  has-symbols@1.1.0:
+    resolution: {integrity: sha512-1cDNdwJ2Jaohmb3sg4OmKaMBwuC48sYni5HUw2DvsC8LjGTLK9h+eb1X6RyuOHe4hT0ULCW68iomhjUoKUqlPQ==}
     engines: {node: '>= 0.4'}
 
   has-tostringtag@1.0.2:
@@ -1819,6 +1938,9 @@ packages:
     resolution: {integrity: sha512-F/1DnUGPopORZi0ni+CvrCgHQ5FyEAHRLSApuYWMmrbSwoN2Mn/7k+Gl38gJnR7yyDZk6WLXwiGod1JOWNDKGw==}
     hasBin: true
 
+  hookified@1.6.0:
+    resolution: {integrity: sha512-se7cpwTA+iA/eY548Bu03JJqBiEZAqU2jnyKdj5B5qurtBg64CZGHTgqCv4Yh7NWu6FGI09W61MCq+NoPj9GXA==}
+
   html-encoding-sniffer@1.0.2:
     resolution: {integrity: sha512-71lZziiDnsuabfdYiUeWdCVyKuqwWi23L8YeIgV9jSSZHCtb6wB1BKWooH7L3tn4/FuZJMVWyNaIDr4RGmaSYw==}
 
@@ -1854,8 +1976,8 @@ packages:
     resolution: {integrity: sha512-dFcAjpTQFgoLMzC2VwU+C/CbS7uRL0lWmxDITmqm7C+7F0Odmj6s9l6alZc6AELXhrnggM2CeWSXHGOdX2YtwA==}
     engines: {node: '>= 6'}
 
-  https-proxy-agent@7.0.5:
-    resolution: {integrity: sha512-1e4Wqeblerz+tMKPIq2EMGiiWW1dIjZOksyHWSUm1rmuvw/how9hBHZ38lAGj5ID4Ik6EdkOw7NmWPy6LAwalw==}
+  https-proxy-agent@7.0.6:
+    resolution: {integrity: sha512-vK9P5/iUfdl95AI+JVyUuIcVtd4ofvtrOr3HNtM2yxC9bnMbEdp3x01OhQNnjb8IJYi38VlTE3mBXwcfvywuSw==}
     engines: {node: '>= 14'}
 
   humanize-duration@3.32.1:
@@ -1868,20 +1990,20 @@ packages:
   ieee754@1.2.1:
     resolution: {integrity: sha512-dcyqhDvX1C46lXZcVqCpK+FtMRQVdIMN6/Df5js2zouUsqG7I6sFxitIC+7KYK29KdXOLHdu9zL4sFnoVQnqaA==}
 
-  ignore@5.3.1:
-    resolution: {integrity: sha512-5Fytz/IraMjqpwfd34ke28PTVMjZjJG2MPn5t7OE4eUCUNf8BAa7b5WUS9/Qvr6mwOQS7Mk6vdsMno5he+T8Xw==}
+  ignore@5.3.2:
+    resolution: {integrity: sha512-hsBTNUqQTDwkWtcdYI2i06Y/nUBEsNEDJKjWdigLvegy8kDuJAS8uRlpkkcQpyEXL0Z/pjDy5HBmMjRCJ2gq+g==}
     engines: {node: '>= 4'}
 
-  image-size@1.1.1:
-    resolution: {integrity: sha512-541xKlUw6jr/6gGuk92F+mYM5zaFAc5ahphvkqvNe2bQ6gVBkd6bfrmVJ2t4KDAfikAYZyIqTnktX3i6/aQDrQ==}
+  image-size@1.2.0:
+    resolution: {integrity: sha512-4S8fwbO6w3GeCVN6OPtA9I5IGKkcDMPcKndtUlpJuCwu7JLjtj7JZpwqLuyY2nrmQT3AWsCJLSKPsc2mPBSl3w==}
     engines: {node: '>=16.x'}
     hasBin: true
 
   image-ssim@0.2.0:
     resolution: {integrity: sha512-W7+sO6/yhxy83L0G7xR8YAc5Z5QFtYEXXRV6EaE8tuYBZJnA3gVgp3q7X7muhLZVodeb9UfvjSbwt9VJwjIYAg==}
 
-  immutable@4.3.6:
-    resolution: {integrity: sha512-Ju0+lEMyzMVZarkTn/gqRpdqd5dOPaz1mCZ0SH3JV6iFw81PldE/PEB1hWVEA288HPt4WXW8O7AWxB10M+03QQ==}
+  immutable@5.0.3:
+    resolution: {integrity: sha512-P8IdPQHq3lA1xVeBRi5VPqUm5HDgKnx0Ru51wZz5mjxHr5n3RWhjIpOFU7ybkUxfB+5IToy+OLaHYDBIWsv+uw==}
 
   import-fresh@3.3.0:
     resolution: {integrity: sha512-veYYhQa+D1QBKznvhUHxb8faxlrwUnxseDAbAp457E0wLNio2bOSKnjYDhMj+YiAq61xrMGhQk9iXVk5FzgQMw==}
@@ -1902,8 +2024,8 @@ packages:
     resolution: {integrity: sha512-cntlB5ghuB0iuO65Ovoi8ogLHiWGs/5yNrtUcKjFhSSiVeAIVpD7koaSU9RM8mpXw5YDi9RdYXGQMaOURB7ycQ==}
     engines: {node: '>=6.0.0'}
 
-  intl-messageformat@10.5.14:
-    resolution: {integrity: sha512-IjC6sI0X7YRjjyVH9aUgdftcmZK7WXdHeil4KwbjDnRWjnVitKpAx3rr6t6di1joFp5188VqKcobOPA6mCLG/w==}
+  intl-messageformat@10.7.11:
+    resolution: {integrity: sha512-IB2N1tmI24k2EFH3PWjU7ivJsnWyLwOWOva0jnXFa29WzB6fb0JZ5EMQGu+XN5lDtjHYFo0/UooP67zBwUg7rQ==}
 
   ip-address@9.0.5:
     resolution: {integrity: sha512-zHtQzGojZXTwZTHQqra+ETKd4Sn3vgi7uBmlPoXVWZqYvuKmtI0l/VZTjqGmJY9x88GGOaZ9+G9ES8hC4T4X8g==}
@@ -1932,12 +2054,8 @@ packages:
   is-browser@2.1.0:
     resolution: {integrity: sha512-F5rTJxDQ2sW81fcfOR1GnCXT6sVJC104fCyfj+mjpwNEwaPYSn5fte5jiHmBg3DHsIoL/l8Kvw5VN5SsTRcRFQ==}
 
-  is-builtin-module@3.2.1:
-    resolution: {integrity: sha512-BSLE3HnV2syZ0FK0iMA/yUGplUeMmNz4AW5fnTunbCIqZi4vG3WjJT9FHMy5D69xmAYBHXQhJdALdpwVxV501A==}
-    engines: {node: '>=6'}
-
-  is-core-module@2.14.0:
-    resolution: {integrity: sha512-a5dFJih5ZLYlRtDc0dZWP7RiKr6xIKzmn/oAYCDvdLThadVgyJwlaoQPmRtMSpz+rk0OGAgIu+TcM9HUF0fk1A==}
+  is-core-module@2.16.1:
+    resolution: {integrity: sha512-UfoeMA6fIJ8wTYFEUjelnaGI67v6+N7qXJEvQuIGa99l4xsCruSYOVSQ0uPANn4dAzm8lkYPaKLrrijLq7x23w==}
     engines: {node: '>= 0.4'}
 
   is-decimal@1.0.4:
@@ -1988,10 +2106,6 @@ packages:
   is-object@1.0.2:
     resolution: {integrity: sha512-2rRIahhZr2UWb45fIOuvZGpFtz0TyOZLf32KxBbSoUCeZR495zCKlWUKKUByk3geS2eAs7ZAABt0Y/Rx0GiQGA==}
 
-  is-path-inside@3.0.3:
-    resolution: {integrity: sha512-Fd4gABb+ycGAmKou8eMftCupSir5lRxqf4aD/vd0cD2qc4HL07OjCeuHMr8Ro4CoMaeCKDB0/ECBOVWjTwUvPQ==}
-    engines: {node: '>=8'}
-
   is-potential-custom-element-name@1.0.1:
     resolution: {integrity: sha512-bCYeRA2rVibKZd+s2625gGnGF/t7DSqDs4dP7CrLA1m7jKWz6pps0LpYLJN8Q64HtmPKJ1hrN3nzPNKFEKOUiQ==}
 
@@ -2001,16 +2115,16 @@ packages:
   is-reference@1.2.1:
     resolution: {integrity: sha512-U82MsXXiFIrjCK4otLT+o2NA2Cd2g5MLoOVXUZjIOhLurrRxpEXzI8O0KZHr3IjLvlAH1kTPYSuqer5T9ZVBKQ==}
 
-  is-regex@1.1.4:
-    resolution: {integrity: sha512-kvRdxDsxZjhzUX07ZnLydzS1TU/TJlTUHHY4YLL87e37oUA49DfkLqgy+VjFocowy29cKvcSiu+kIv728jTTVg==}
+  is-regex@1.2.1:
+    resolution: {integrity: sha512-MjYsKHO5O7mCsmRGxWcLWheFqN9DJ/2TmngvjKXihe6efViPqc274+Fx/4fYj/r03+ESvBdTXK0V6tA3rgez1g==}
     engines: {node: '>= 0.4'}
 
   is-stream@1.1.0:
     resolution: {integrity: sha512-uQPm8kcs47jx38atAcWTVxyltQYoPT68y9aWYdV6yWXSyW8mzSat0TL6CiWdZeCdF3KrAvpVtnHbTv4RN+rqdQ==}
     engines: {node: '>=0.10.0'}
 
-  is-string@1.0.7:
-    resolution: {integrity: sha512-tE2UXzivje6ofPW7l23cjDOMa09gb7xlAqG6jG5ej6uPV32TlWP3NKPigtaGeHNu9fohccRYvIiZMfOOnOYUtg==}
+  is-string@1.1.1:
+    resolution: {integrity: sha512-BtEeSsoaQjlSPBemMQIrY1MY0uM6vnS1g5fmufYOtnxLGUZM2178PKbhsk7Ffv58IX+ZtcvoGwccYsh0PglkAA==}
     engines: {node: '>= 0.4'}
 
   is-typedarray@1.0.0:
@@ -2033,6 +2147,10 @@ packages:
   isexe@2.0.0:
     resolution: {integrity: sha512-RHxMLp9lnKHGHRng9QFhRCMbYAcVpn69smSGcq3f36xjgVVWThj4qqLbTLlq7Ssj8B+fIQ1EuCEGI2lKsyQeIw==}
 
+  isexe@3.1.1:
+    resolution: {integrity: sha512-LpB/54B+/2J5hqQ7imZHfdU31OlgQqx7ZicVlkm9kzg9/w8GKLEcFfJl/t7DCEDueOyBAD6zCCwTO6Fzs0NoEQ==}
+    engines: {node: '>=16'}
+
   iso-639-1@2.1.15:
     resolution: {integrity: sha512-7c7mBznZu2ktfvyT582E2msM+Udc1EjOyhVRE/0ZsjD9LBtWSm23h3PtiRh2a35XoUsTQQjJXaJzuLjXsOdFDg==}
     engines: {node: '>=6.0'}
@@ -2043,12 +2161,8 @@ packages:
   isstream@0.1.2:
     resolution: {integrity: sha512-Yljz7ffyPbrLpLngrMtZ7NduUgVvi6wG9RJ9IUcyCd59YQ911PBJphODUcbOVbqYfxe1wuYf/LJ8PauMRwsM/g==}
 
-  jackspeak@3.4.1:
-    resolution: {integrity: sha512-U23pQPDnmYybVkYjObcuYMk43VRlMLLqLI+RdZy8s8WV8WsxO9SnqSroKaluuvcNOdCAlauKszDwd+umbot5Mg==}
-    engines: {node: '>=18'}
-
-  jake@10.9.1:
-    resolution: {integrity: sha512-61btcOHNnLnsOdtLgA5efqQWjnSi/vow5HbI7HMdKKWqvrKR1bLK3BPlJn9gcSaP2ewuamUSMB5XEy76KUIS2w==}
+  jake@10.9.2:
+    resolution: {integrity: sha512-2P4SQ0HrLQ+fw6llpLnOaGAvN2Zu6778SJMrCUwns4fOoG9ayrTiZk3VV8sCPkVZF8ab0zksVpS8FDY5pRCNBA==}
     engines: {node: '>=10'}
     hasBin: true
 
@@ -2085,9 +2199,9 @@ packages:
   json-parse-even-better-errors@2.3.1:
     resolution: {integrity: sha512-xyFwyhro/JEof6Ghe2iz2NcXoj2sloNsWr/XsERDK/oiPCfaNhl5ONfp+jQdAZRQQ0IJWNzH9zIZF7li91kh2w==}
 
-  json-parse-even-better-errors@3.0.2:
-    resolution: {integrity: sha512-fi0NG4bPjCHunUJffmLd0gxssIgkNmArMvis4iNah6Owg1MCJjWhEcDLmsK6iGkJq3tHwbDkTlce70/tmXN4cQ==}
-    engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
+  json-parse-even-better-errors@4.0.0:
+    resolution: {integrity: sha512-lR4MXjGNgkJc7tkQ97kb2nuEMnNCyU//XYVH0MKTGcXEiSudQ5MKGKen3C5QubYy0vmq+JGitUg92uuywGEwIA==}
+    engines: {node: ^18.17.0 || >=20.5.0}
 
   json-schema-traverse@0.4.1:
     resolution: {integrity: sha512-xbbCH5dCYU5T8LcEhhuh7HJ88HXuW3qsI3Y0zOZFKfZEHcpWiHU/Jxzk629Brsab/mMiHQti9wMP+845RPe3Vg==}
@@ -2104,9 +2218,6 @@ packages:
   json-stringify-safe@5.0.1:
     resolution: {integrity: sha512-ZClg6AaYvamvYEE82d3Iyd3vSSIjQ+odgjaTzRuO3s7toCdFKczob2i0zCh7JE8kWn17yvAWhUVxvqGwUalsRA==}
 
-  jsonfile@6.1.0:
-    resolution: {integrity: sha512-5dgndWOriYSm5cnYaJNhalLNDKOqFwyDB/rr1E9ZsGciGvKPs8R2xYGCacuf3z6K1YKDz182fd+fY3cn3pMqXQ==}
-
   jsprim@1.4.2:
     resolution: {integrity: sha512-P2bSOMAc/ciLz6DzgjVlGJP9+BrJWu5UDGK70C2iweC5QBIeFf0ZXRvGjEj2uYgrY2MkAAhsSWHDWlFtEroZWw==}
     engines: {node: '>=0.6.0'}
@@ -2121,6 +2232,9 @@ packages:
   keyv@4.5.4:
     resolution: {integrity: sha512-oxVHkHR/EJf2CNXnWxRLW6mg7JyCCUcG0DtEGmL2ctUo1PNTin1PUil+r/+4r5MpVgC/fn1kjsx7mjSujKqIpw==}
 
+  keyv@5.2.3:
+    resolution: {integrity: sha512-AGKecUfzrowabUv0bH1RIR5Vf7w+l4S3xtQAypKaUpTdIR1EbrAcTxHCrpo9Q+IWeUlFE2palRtgIQcgm+PQJw==}
+
   kind-of@6.0.3:
     resolution: {integrity: sha512-dcS1ul+9tmeD95T+x28/ehLgd9mENa3LsvDTtzm3vyBEO7RPptvAD+t44WVXaUjTBRcrpFeFlC8WCruUR456hw==}
     engines: {node: '>=0.10.0'}
@@ -2149,8 +2263,8 @@ packages:
   lighthouse-stack-packs@1.12.1:
     resolution: {integrity: sha512-i4jTmg7tvZQFwNFiwB+nCK6a7ICR68Xcwo+VIVd6Spi71vBNFUlds5HiDrSbClZdkQDON2Bhqv+KKJIo5zkPeA==}
 
-  lighthouse@11.4.0:
-    resolution: {integrity: sha512-NmGBIdLznIBTfla566gpNPdbascVA0uWFG2LyuRQPeMT06ai3QxzDqSpaR5dToDuEQIPkyU0qqxwHj8kst8x+g==}
+  lighthouse@12.1.0:
+    resolution: {integrity: sha512-PQLaNcv3tQcybnYux6T8uoS6+RNrNYvVJBbGo0kkbD4XTjesGslOXWeMkUQDK7c28nLfVZi7gYWDUsicTLglKQ==}
     engines: {node: '>=18.16'}
     hasBin: true
 
@@ -2171,8 +2285,8 @@ packages:
   linkify-it@5.0.0:
     resolution: {integrity: sha512-5aHCbzQRADcdP+ATqnDuhhJ/MRIqDkZX5pyjFHRRysS8vZ5AbqGEoFIb6pYHPZ+L/OC2Lc+xT8uHVVR5CAK/wQ==}
 
-  liquidjs@10.14.0:
-    resolution: {integrity: sha512-Zjg35Yo3L/2aNy7QkICha/ulbXRtZS7oRenWyDDfw+J34Xy3fOKWWHxASC9r0gbxN661nrwmG/kOIKHfYcVk4Q==}
+  liquidjs@10.20.1:
+    resolution: {integrity: sha512-eZ33jfxjj0It8tkY+I4gbKWfXvMmOvQvvraxVFSLcTjZWCjdWMLBnevk48qw9AQIwIHFp58vZc59vH9Qwdq7mw==}
     engines: {node: '>=14'}
     hasBin: true
 
@@ -2208,10 +2322,6 @@ packages:
   lower-case@1.1.4:
     resolution: {integrity: sha512-2Fgx1Ycm599x+WGpIYwJOvsjmXFzTSc34IwDWALRA/8AopUKAVPwfJ+h5+f85BCp0PWmmJcWzEpxOpoXycMpdA==}
 
-  lru-cache@10.4.0:
-    resolution: {integrity: sha512-bfJaPTuEiTYBu+ulDaeQ0F+uLmlfFkMgXj4cbwfuMSjgObGMzb55FMMbDvbRU0fAHZ4sLGkz2mKwcMg8Dvm8Ww==}
-    engines: {node: '>=18'}
-
   lru-cache@4.1.5:
     resolution: {integrity: sha512-sWZlbEP2OsHNkXrMl5GYk/jKk70MBng6UU4YI/qGDYbgf6YbP4EvmqISbXCoJiRKs+1bSpFHVgQxvJ17F2li5g==}
 
@@ -2222,12 +2332,12 @@ packages:
   lru_map@0.3.3:
     resolution: {integrity: sha512-Pn9cox5CsMYngeDbmChANltQl+5pi6XmTrraMSzhPmMBbmgcxmqWry0U3PGapCU1yB4/LqCcom7qhHZiF/jGfQ==}
 
-  luxon@3.4.4:
-    resolution: {integrity: sha512-zobTr7akeGHnv7eBOXcRgMeCP6+uyYsczwmeRCauvpvaAltgNyTbLH/+VaEAPUeWBT+1GuNmz4wC/6jtQzbbVA==}
+  luxon@3.5.0:
+    resolution: {integrity: sha512-rh+Zjr6DNfUYR3bPwJEnuwDdqMbxZW7LOQfUN4B54+Cl+0o5zaU9RJ6bcidfDtC1cWCZXQ+nvX8bf6bAji37QQ==}
     engines: {node: '>=12'}
 
-  magic-string@0.30.10:
-    resolution: {integrity: sha512-iIRwTIf0QKV3UAnYK4PU8uiEc4SRh5jX0mwpIwETPpHdhVM4f53RSwS/vXvN1JhGX+Cs7B8qIq3d6AH49O5fAQ==}
+  magic-string@0.30.17:
+    resolution: {integrity: sha512-sNPKHvyjVf7gyjwS4xGTaW/mCnF8wnjtifKBEhxfZ7E/S8tQ0rssrwGNn6q8JH/ohItJfSQp9mBtQYuTlH5QnA==}
 
   make-dir@3.1.0:
     resolution: {integrity: sha512-g3FeP20LNwhALb/6Cz6Dd4F2ngze0jz7tbzrD2wAV+o9FeNHe4rL+yK2md0J/fiSf1sa1ADhXqi5+oVwOM/eGw==}
@@ -2247,6 +2357,10 @@ packages:
   marky@1.2.5:
     resolution: {integrity: sha512-q9JtQJKjpsVxCRVgQ+WapguSbKC3SQ5HEzFGPAJMStgh3QjCawp00UKv3MTTAArTmGmmPUvllHZoNbZ3gs0I+Q==}
 
+  math-intrinsics@1.1.0:
+    resolution: {integrity: sha512-/IXtbwEk5HTPyEwyKX6hGkYXxM9nbj64B+ilVJnC/R6B0pH5G4V3b0pVbL7DBj4tkhBAppbQUlf6F6Xl9LHu1g==}
+    engines: {node: '>= 0.4'}
+
   maximatch@0.1.0:
     resolution: {integrity: sha512-9ORVtDUFk4u/NFfo0vG/ND/z7UQCVZBL539YW0+U1I7H1BkZwizcPx5foFv7LCPcBnm2U6RjFnQOsIvN4/Vm2A==}
     engines: {node: '>=0.10.0'}
@@ -2274,8 +2388,8 @@ packages:
     resolution: {integrity: sha512-S3UwM3yj5mtUSEfP41UZmt/0SCoVYUcU1rkXv+BQ5Ig8ndL4sPoJNBUJERafdPb5jjHJGuMgytgKvKIf58XNBw==}
     engines: {node: '>= 0.10.0'}
 
-  merge-descriptors@1.0.1:
-    resolution: {integrity: sha512-cCi6g3/Zr1iqQi6ySbseM1Xvooa98N0w31jzUYrXPX2xqObmFGHJ0tQ5u74H3mVh7wLouTseZyYIq39g8cNp1w==}
+  merge-descriptors@1.0.3:
+    resolution: {integrity: sha512-gaNvAS7TZ897/rVaZ0nMtAyxNyi/pdbjbAwUpFQpN70GqnVfOiXpeUUMKRBmzXaSQ8DdTX4/0ms62r2K+hE6mQ==}
 
   merge2@1.4.1:
     resolution: {integrity: sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==}
@@ -2288,14 +2402,18 @@ packages:
     resolution: {integrity: sha512-iclAHeNqNm68zFtnZ0e+1L2yUIdvzNoauKU4WBA3VvH/vPFieF7qfRlwUZU+DA9P9bPXIS90ulxoUoCH23sV2w==}
     engines: {node: '>= 0.6'}
 
-  micromatch@4.0.7:
-    resolution: {integrity: sha512-LPP/3KorzCwBxfeUuZmaR6bG2kdeHSbe0P2tY3FLRU4vYrjYz5hI4QZwV0njUx3jeuKe67YukQ1LSPZBKDqO/Q==}
+  micromatch@4.0.8:
+    resolution: {integrity: sha512-PXwfBhYu0hBCPw8Dn0E+WDYb7af3dSLVWKi3HGv84IdF4TyFoC0ysxFd0Goxw7nSv4T/PzEJQxsYsEiFCKo2BA==}
     engines: {node: '>=8.6'}
 
   mime-db@1.52.0:
     resolution: {integrity: sha512-sPU4uV7dYlvtWJxwwxHD0PuihVNiE7TyAbQ5SWxDCB9mUYvOgroQOwYQQOKPJ8CIbE+1ETVlOoK1UC2nU3gYvg==}
     engines: {node: '>= 0.6'}
 
+  mime-db@1.53.0:
+    resolution: {integrity: sha512-oHlN/w+3MQ3rba9rqFr6V/ypF10LSkdwUysQL7GkXoTgIWeV+tcXGA852TBxH+gsh8UWoyhR1hKcoMJTuWflpg==}
+    engines: {node: '>= 0.6'}
+
   mime-types@2.1.35:
     resolution: {integrity: sha512-ZDY+bPm5zTTF+YpCrAU9nK0UgICYPT0QtT1NZWFv4s++TNkcgVaT0g6+4R2uI4MjQjzysHB1zxuWL50hzaeXiw==}
     engines: {node: '>= 0.6'}
@@ -2332,16 +2450,9 @@ packages:
     resolution: {integrity: sha512-DxiNidxSEK+tHG6zOIklvNOwm3hvCrbUrdtzY74U6HKTJxvIDfOUL5W5P2Ghd3DTkhhKPYGqeNUIh5qcM4YBfw==}
     engines: {node: '>=8'}
 
-  minipass@7.1.2:
-    resolution: {integrity: sha512-qOOzS1cBTWYF4BH8fVePDBOO9iptMnGUEZwNc/cMWnTV2nVLZ7VoNWEPHkYczZA0pdoA7dl6e7FL659nX9S2aw==}
-    engines: {node: '>=16 || 14 >=14.17'}
-
   mitt@3.0.1:
     resolution: {integrity: sha512-vKivATfr97l2/QBCYAkXYDbrIWPM2IIKEl7YPhjCvKlG3kE2gm+uBo6nEXK3M5/Ffh/FLpKExzOQ3JJoJGFKBw==}
 
-  mkdirp-classic@0.5.3:
-    resolution: {integrity: sha512-gKLcREMhtuZRwRAfqP3RFW+TK4JqApVBtOIftVgjuABpAtpxhPGaDcfvbhNvD0B8iD1oUr/txX35NjcaY6Ns/A==}
-
   mkdirp@0.5.6:
     resolution: {integrity: sha512-FP+p8RB8OWpF3YZBCrP5gtADmtXApB5AMLn+vdyA+PyxCjrCs00mjyUozssO33cwDeT3wNGdLxJ5M//YqtHAJw==}
     hasBin: true
@@ -2349,15 +2460,12 @@ packages:
   moo@0.5.2:
     resolution: {integrity: sha512-iSAJLHYKnX41mKcJKjqvnAN9sf0LMDTXDEvFv+ffuRR9a1MIuXLjMNL6EsnDHSkKLTWNqQQ5uo61P4EbU4NU+Q==}
 
-  morphdom@2.7.3:
-    resolution: {integrity: sha512-rvGK92GxSuPEZLY8D/JH07cG3BxyA+/F0Bxg32OoGAEFFhGWA3OqVpqPZlOgZTCR52clXrmz+z2pYSJ6gOig1w==}
+  morphdom@2.7.4:
+    resolution: {integrity: sha512-ATTbWMgGa+FaMU3FhnFYB6WgulCqwf6opOll4CBzmVDTLvPMmUPrEv8CudmLPK0MESa64+6B89fWOxP3+YIlxQ==}
 
   ms@2.0.0:
     resolution: {integrity: sha512-Tpp60P6IUJDTuOq/5Z8cdskzJujfwqfOTkrwIwj7IRISpnkJnT6SyJ4PCPnGMoFjC9ddhal5KVIYtAt97ix05A==}
 
-  ms@2.1.2:
-    resolution: {integrity: sha512-sGkPx+VjMtmA6MX27oA4FBFELFCZZ4S4XqeGOXCv68tT+jb3vk/RyaKWP0PTKyWtmLSM0b+adUTEvbs1PEaH2w==}
-
   ms@2.1.3:
     resolution: {integrity: sha512-6FlzubTLZG3J2a/NVCAleEhjzq5oxgHyaCU9yYXvcLsvoVaHJq/s5xXI6/XXP6tz7R9xAOtHnSO/tXtF3WRTlA==}
 
@@ -2379,6 +2487,10 @@ packages:
     resolution: {integrity: sha512-+EUsqGPLsM+j/zdChZjsnX51g4XrHFOIXwfnCVPGlQk/k5giakcKsuxCObBRu6DSm9opw/O6slWbJdghQM4bBg==}
     engines: {node: '>= 0.6'}
 
+  negotiator@0.6.4:
+    resolution: {integrity: sha512-myRT3DiWPHqho5PrJaIRyaMv2kgYf0mUVgBNOYMuCH5Ki1yEiQaf/ZJuQ62nvpc44wL5WDbTX7yGJi1Neevw8w==}
+    engines: {node: '>= 0.6'}
+
   neo-async@2.6.2:
     resolution: {integrity: sha512-Yd3UES5mWCSqR+qNT93S3UoYUkqAZ9lLg8a7g9rimsWmYGK8cVToA4/sF3RrshdyV3sAGMXVUmpMYOw+dLpOuw==}
 
@@ -2393,6 +2505,9 @@ packages:
   no-case@2.3.2:
     resolution: {integrity: sha512-rmTZ9kz+f3rCvK2TD1Ue/oZlns7OGoIWP4fc3llxxRXlOkHKoWPPWJOfFYpITabSow43QJbRIoHQXtt10VldyQ==}
 
+  node-addon-api@7.1.1:
+    resolution: {integrity: sha512-5m3bsyrjFWE1xf7nz7YXdN4udnVtXK6/Yfgn5qnahL6bCkf2yKt4k3nuTKAtT4r3IG8JNR2ncsIMdZuAzJjHQQ==}
+
   node-fetch@2.7.0:
     resolution: {integrity: sha512-c4FRfUm/dbcWZ7U+1Wq0AwCyFL+3nt2bEw05wfxSz+DWpWsitgmSgYmy2dQdWyKC1694ELPqMs/YzUSNozLt8A==}
     engines: {node: 4.x || >=6.0.0}
@@ -2415,13 +2530,13 @@ packages:
     resolution: {integrity: sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==}
     engines: {node: '>=0.10.0'}
 
-  npm-normalize-package-bin@3.0.1:
-    resolution: {integrity: sha512-dMxCf+zZ+3zeQZXKxmyuCKlIDPGuv8EF940xbkC4kQVDTtqoh6rJFO+JTKSA6/Rwi0getWmtuy4Itup0AMcaDQ==}
-    engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
+  npm-normalize-package-bin@4.0.0:
+    resolution: {integrity: sha512-TZKxPvItzai9kN9H/TkmCtx/ZN/hvr3vUycjlfmH0ootY9yFBzNOpiXAdIn1Iteqsvk4lQn6B5PTrt+n6h8k/w==}
+    engines: {node: ^18.17.0 || >=20.5.0}
 
-  npm-run-all2@6.2.2:
-    resolution: {integrity: sha512-Q+alQAGIW7ZhKcxLt8GcSi3h3ryheD6xnmXahkMRVM5LYmajcUrSITm8h+OPC9RYWMV2GR0Q1ntTUCfxaNoOJw==}
-    engines: {node: ^14.18.0 || ^16.13.0 || >=18.0.0, npm: '>= 8'}
+  npm-run-all2@7.0.2:
+    resolution: {integrity: sha512-7tXR+r9hzRNOPNTvXegM+QzCuMjzUIIq66VDunL6j60O4RrExx32XUhlrS7UK4VcdGw5/Wxzb3kfNcFix9JKDA==}
+    engines: {node: ^18.17.0 || >=20.5.0, npm: '>= 9'}
     hasBin: true
 
   nth-check@2.1.1:
@@ -2437,8 +2552,8 @@ packages:
       chokidar:
         optional: true
 
-  nwsapi@2.2.10:
-    resolution: {integrity: sha512-QK0sRs7MKv0tKe1+5uZIQk/C8XGza4DAnztJG8iD+TpJIORARrCxczA738awHrZoHeTjSSoHqao2teO0dC/gFQ==}
+  nwsapi@2.2.16:
+    resolution: {integrity: sha512-F1I/bimDpj3ncaNDhfyMWuFqmQDBwDB0Fogc2qpL3BWvkQteFD/8BzWuIRl83rq0DXfm8SGt/HFhLXZyljTXcQ==}
 
   oauth-sign@0.9.0:
     resolution: {integrity: sha512-fexhUFFPTGV8ybAtSIGbV6gOkSv8UtRbDBnAyLQw4QPKkgNlsH2ByPGtMUqdWkos6YCRmAqViwgZrJc/mRDzZQ==}
@@ -2451,8 +2566,8 @@ packages:
     resolution: {integrity: sha512-rJgTQnkUnH1sFw8yT6VSU3zD3sWmu6sZhIseY8VX+GRu3P6F7Fu+JNDoXfklElbLJSnc3FUQHVe4cU5hj+BcUg==}
     engines: {node: '>=0.10.0'}
 
-  object-inspect@1.13.2:
-    resolution: {integrity: sha512-IRZSRuzJiynemAXPYtPe5BoI/RESNYR7TYm50MC5Mqbd3Jmw5y790sErYw3V6SryFJD64b74qQQs9wn5Bg/k3g==}
+  object-inspect@1.13.3:
+    resolution: {integrity: sha512-kDCGIbxkDSXE3euJZZXzc6to7fCrKHNI/hSRQnRuQ+BWjFNzZwiFF8fj/6o2t2G9/jTj8PSIYTfCLelLZEeRpA==}
     engines: {node: '>= 0.4'}
 
   on-finished@2.4.1:
@@ -2532,17 +2647,14 @@ packages:
     resolution: {integrity: sha512-R4nPAVTAU0B9D35/Gk3uJf/7XYbQcyohSKdvAxIRSNghFl4e71hVoGnBNQz9cWaXxO2I10KTC+3jMdvvoKw6dQ==}
     engines: {node: '>=6'}
 
-  pac-proxy-agent@7.0.2:
-    resolution: {integrity: sha512-BFi3vZnO9X5Qt6NRz7ZOaPja3ic0PhlsmCRYLOpN11+mWBCR6XJDqW5RF3j8jm4WGGQZtBA+bTfxYzeKW73eHg==}
+  pac-proxy-agent@7.1.0:
+    resolution: {integrity: sha512-Z5FnLVVZSnX7WjBg0mhDtydeRZ1xMcATZThjySQUHqr+0ksP8kqaw23fNKkaaN/Z8gwLUs/W7xdl0I75eP2Xyw==}
     engines: {node: '>= 14'}
 
   pac-resolver@7.0.1:
     resolution: {integrity: sha512-5NPgf87AT2STgwa2ntRMr45jTKrYBGkVU36yT0ig/n/GMAa3oPqhZfIQ2kMEimReg0+t9kZViDVZ83qfVUlckg==}
     engines: {node: '>= 14'}
 
-  package-json-from-dist@1.0.0:
-    resolution: {integrity: sha512-dATvCeZN/8wQsGywez1mzHtTlP22H8OEfPrVMLNr4/eGa+ijtLn/6M5f0dY8UKNrC2O9UCU6SSoG3qRKnt7STw==}
-
   pako@2.1.0:
     resolution: {integrity: sha512-w+eufiZ1WuJYgPXbV/PO3NCMEc3xqylkKHzp8bxp1uW4qaSNQUkwmLLEc3kKsfz8lpV1F8Ht3U1Cm+9Srog2ug==}
 
@@ -2591,15 +2703,11 @@ packages:
   path-parse@1.0.7:
     resolution: {integrity: sha512-LDJzPVEEEPR+y48z93A0Ed0yXb8pAByGWo/k5YYdYgpY2/2EsOsksJrq7lOHxryrVOn1ejG6oAp8ahvOIQD8sw==}
 
-  path-scurry@1.11.1:
-    resolution: {integrity: sha512-Xa4Nw17FS9ApQFJ9umLiJS4orGjm7ZzwUrwamcGQuHSzDyth9boKDaycYdDcZDuqYATXw4HFXgaqWTctW/v1HA==}
-    engines: {node: '>=16 || 14 >=14.18'}
+  path-to-regexp@0.1.12:
+    resolution: {integrity: sha512-RA1GjUVMnvYFxuqovrEqZoxxW5NUZqbwKtYz/Tt7nXerk0LbLblQmrsgdeOxV5SFHf0UDggjS/bSeOZwt1pmEQ==}
 
-  path-to-regexp@0.1.7:
-    resolution: {integrity: sha512-5DFkuoqlv1uYQKxy8omFBeJPQcdoE07Kv2sferDCrAq1ohOU+MSDswDIbnx3YAM60qIOnYa53wBhXW0EbMonrQ==}
-
-  path-to-regexp@6.2.2:
-    resolution: {integrity: sha512-GQX3SSMokngb36+whdpRXE+3f9V8UzyAorlYvOGx87ufGHehNTn5lCxrKtLyZ4Yl/wEKnNnr98ZzOwwDZV5ogw==}
+  path-to-regexp@6.3.0:
+    resolution: {integrity: sha512-Yhpw4T9C6hPpgPeA28us07OJeqZ5EzQTkbfwuhsUg0c237RomFoETJgmp2sa3F/41gfLE6G5cqcYwznmeEeOlQ==}
 
   path-type@4.0.0:
     resolution: {integrity: sha512-gDKb8aZMDeD/tZWs9P6+q0J9Mwkdl6xMV8TjnGP3qJVJ06bdMgkbBlLU8IdfOsIsFz2BW1rNVT3XuNEl8zPAvw==}
@@ -2611,13 +2719,17 @@ packages:
   performance-now@2.1.0:
     resolution: {integrity: sha512-7EAHlyLHI56VEIdK57uwHdHKIaAGbnXPiw0yWbarQZOKaKpvUIgW0jWRVLiatnM+XXlSwsanIBH/hzGMJulMow==}
 
-  picocolors@1.0.1:
-    resolution: {integrity: sha512-anP1Z8qwhkbmu7MFP5iTt+wQKXgwzf7zTyGlcdzabySa9vd0Xt392U0rVmz9poOaBj0uHJKyyo9/upk0HrEQew==}
+  picocolors@1.1.1:
+    resolution: {integrity: sha512-xceH2snhtb5M9liqDsmEw56le376mTZkEX/jEb/RxNFyegNul7eNslCXP9FDj/Lcu0X8KEyMceP2ntpaHrDEVA==}
 
   picomatch@2.3.1:
     resolution: {integrity: sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA==}
     engines: {node: '>=8.6'}
 
+  picomatch@4.0.2:
+    resolution: {integrity: sha512-M7BAV6Rlcy5u+m6oPhAPFgJTzAioX/6B0DxyvDlo9l8+T3nLKbrczg2WLUyzd45L8RqfUMyGPzekbMvX2Ldkwg==}
+    engines: {node: '>=12'}
+
   pidtree@0.6.0:
     resolution: {integrity: sha512-eG2dWTVw5bzqGRztnHExczNxt5VGsE6OwTeCG3fdUf9KBsZzO3R5OIIIzWR+iZA0NtZ+RDVdaoE2dK1cn6jH4g==}
     engines: {node: '>=0.10'}
@@ -2661,13 +2773,13 @@ packages:
     resolution: {integrity: sha512-GbK2cP9nraSSUF9N2XwUwqfzlAFlMNYYl+ShE/V+H8a9uNl/oUqB1w2EL54Jh0OlyRSd8RfWYJ3coVS4TROP2w==}
     engines: {node: '>=6.0.0'}
 
-  prettier-plugin-jinja-template@1.4.1:
-    resolution: {integrity: sha512-YHDa/f9BpEDIYIPKsnmoKQudWszXBPaVifjR7X+W2n/uAzWLXV/j9FEvua3np7gkzSEOFyapJQrCS4YhhbhbdA==}
+  prettier-plugin-jinja-template@2.0.0:
+    resolution: {integrity: sha512-REZDAcZuOUvMDaPS47/GNRLKvbxh9DO9euXhWA7gJGqTLGzHPK2Z841F8I4bxsR7e2lqnHezkQ8GcWaKekKBVQ==}
     peerDependencies:
       prettier: ^3.0.0
 
-  prettier@3.2.5:
-    resolution: {integrity: sha512-3/GWa9aOC0YeD7LUfvOG2NiDyhOWRvt1k+rcKhOuYnMY24iiCphgneUfJDyFXd6rZCAnuLBv6UeAULtrhT/F4A==}
+  prettier@3.4.2:
+    resolution: {integrity: sha512-e9MewbtFo+Fevyuxn/4rrcDAaq0IYxPGLvObpQjiZBMAzB9IGmzlnG9RZy3FFas+eBMu2vA0CszMeduow5dIuQ==}
     engines: {node: '>=14'}
     hasBin: true
 
@@ -2692,8 +2804,8 @@ packages:
     resolution: {integrity: sha512-llQsMLSUDUPT44jdrU/O37qlnifitDP+ZwrmmZcoSKyLKvtZxpyV0n2/bD/N4tBAAZ/gJEdZU7KMraoK1+XYAg==}
     engines: {node: '>= 0.10'}
 
-  proxy-agent@6.3.1:
-    resolution: {integrity: sha512-Rb5RVBy1iyqOtNl15Cw/llpeLH8bsb37gM1FUfKQ+Wck6xHlbAhWGUFiTRHtkjqGTA5pSHz6+0hrPW/oECihPQ==}
+  proxy-agent@6.5.0:
+    resolution: {integrity: sha512-TmatMXdr2KlRiA2CyDu8GqR8EjahTG3aY3nXjdzFyoZbmB8hrBsTyMezhULIXKnC0jpfjlmiZ3+EaCzoInSu/A==}
     engines: {node: '>= 14'}
 
   proxy-from-env@1.1.0:
@@ -2702,15 +2814,11 @@ packages:
   prr@1.0.1:
     resolution: {integrity: sha512-yPw4Sng1gWghHQWj0B3ZggWUm4qVbPwPFcRG8KyxiU7J2OHFSoEHKS+EZ3fv5l1t9CyCiop6l/ZYeWbrgoQejw==}
 
-  ps-list@8.1.1:
-    resolution: {integrity: sha512-OPS9kEJYVmiO48u/B9qneqhkMvgCxT+Tm28VCEJpheTpl8cJ0ffZRRNgS5mrQRTrX5yRTpaJ+hRDeefXYmmorQ==}
-    engines: {node: ^12.20.0 || ^14.13.1 || >=16.0.0}
-
   pseudomap@1.0.2:
     resolution: {integrity: sha512-b/YwNhb8lk1Zz2+bXXpS/LK9OisiZZ1SNsSLxN1x2OXVEhW2Ckr/7mWE5vrC1ZTiJlD9g19jWszTmJsB+oEpFQ==}
 
-  psl@1.9.0:
-    resolution: {integrity: sha512-E/ZsdU4HLs/68gYzgGTkMicWTLPdAftJLfJFlLUAAKZGkStNU72sZjT66SnMDVOfOWY/YAoiD7Jxa9iHvngcag==}
+  psl@1.15.0:
+    resolution: {integrity: sha512-JZd3gMVBAVQkSs6HdNZo9Sdo0LNcQeMNP3CozBJb3JYC/QUYZTnKxP+f8oWRX4rHP5EurWxqAHTSwUCjlNKa1w==}
 
   pug-attrs@3.0.0:
     resolution: {integrity: sha512-azINV9dUtzPMFQktvTXciNAfAuVh/L/JCl0vtPCwvOA21uZrC08K/UnmrL+SXGEVc1FwzjW62+xw5S/uaLj6cA==}
@@ -2748,8 +2856,8 @@ packages:
   pug@3.0.3:
     resolution: {integrity: sha512-uBi6kmc9f3SZ3PXxqcHiUZLmIXgfgWooKWXcwSGwQd2Zi5Rb0bT14+8CJjJgI8AB+nndLaNgHGrcc6bPIB665g==}
 
-  pump@3.0.0:
-    resolution: {integrity: sha512-LwZy+p3SFs1Pytd/jYct4wpv49HiYCqd9Rlc5ZVdk0V+8Yzv6jR5Blk3TRmPL1ft69TxP0IMZGJ+WPFU2BFhww==}
+  pump@3.0.2:
+    resolution: {integrity: sha512-tUPXtzlGM8FE3P0ZL6DVs/3P58k9nk8/jZeQCurTJylQA8qFYzHFfhBJkuqyE0FifOsQ0uKWekiZ5g8wtr28cw==}
 
   punycode.js@2.3.1:
     resolution: {integrity: sha512-uxFIHU0YlHYhDQtV4R9J6a52SLx28BCjT+4ieh7IGbgwVJWO+km431c4yRlREUAsAmt/uMjQUyQHNEPf0M39CA==}
@@ -2759,12 +2867,12 @@ packages:
     resolution: {integrity: sha512-vYt7UD1U9Wg6138shLtLOvdAu+8DsC/ilFtEVHcH+wydcSpNE20AfSOduf6MkRFahL5FY7X1oU7nKVZFtfq8Fg==}
     engines: {node: '>=6'}
 
-  puppeteer-core@21.11.0:
-    resolution: {integrity: sha512-ArbnyA3U5SGHokEvkfWjW+O8hOxV1RSJxOgriX/3A4xZRqixt9ZFHD0yPgZQF05Qj0oAqi8H/7stDorjoHY90Q==}
-    engines: {node: '>=16.13.2'}
+  puppeteer-core@22.15.0:
+    resolution: {integrity: sha512-cHArnywCiAAVXa3t4GGL2vttNxh7GqXtIYGym99egkNJ3oG//wL9LkvO4WE8W1TJe95t1F1ocu9X4xWaGsOKOA==}
+    engines: {node: '>=18'}
 
-  qs@6.11.0:
-    resolution: {integrity: sha512-MvjoMCJwEarSbUYk5O+nmoSzSutSsTwF85zcHPQ9OrlFoZOYIjaqBAJIqIXjptyD5vThxGq52Xu/MaJzRkIk4Q==}
+  qs@6.13.0:
+    resolution: {integrity: sha512-+38qI9SOr8tfZ4QmJNplMUxqjbe7LKvvZgWdExBOmd+egZTtjLB67Gu0HRX3u/XOq7UU2Nx6nsjvS16Z9uwfpg==}
     engines: {node: '>=0.6'}
 
   qs@6.5.3:
@@ -2791,9 +2899,9 @@ packages:
     resolution: {integrity: sha512-8zGqypfENjCIqGhgXToC8aB2r7YrBX+AQAfIPs/Mlk+BtPTztOvTS01NRW/3Eh60J+a48lt8qsCzirQ6loCVfA==}
     engines: {node: '>= 0.8'}
 
-  read-package-json-fast@3.0.2:
-    resolution: {integrity: sha512-0J+Msgym3vrLOUB3hzQCuZHII0xkNGCtz/HJH9xZshwv9DbDwkw1KaE3gx/e2J5rpEY5rtOy6cyhKOPrkP7FZw==}
-    engines: {node: ^14.17.0 || ^16.13.0 || >=18.0.0}
+  read-package-json-fast@4.0.0:
+    resolution: {integrity: sha512-qpt8EwugBWDw2cgE2W+/3oxC+KTez2uSVR8JU9Q36TXPAGCaozfQUs59v4j4GFpWTaw0i6hAZSvOmu1J0uOEUg==}
+    engines: {node: ^18.17.0 || >=20.5.0}
 
   readable-stream@1.0.34:
     resolution: {integrity: sha512-ok1qVCJuRkNmvebYikljxJA/UEsKwLl2nI1OmaqAu4/UE+h0wKCHok4XkL/gvi39OacXvw59RJUOFUkDib2rHg==}
@@ -2805,6 +2913,10 @@ packages:
     resolution: {integrity: sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA==}
     engines: {node: '>=8.10.0'}
 
+  readdirp@4.1.1:
+    resolution: {integrity: sha512-h80JrZu/MHUZCyHu5ciuoI0+WxsCxzxJTILn6Fs8rxSnFPh+UVHYfeIxK1nVGugMqkfC4vJcBOYbkfkwYK0+gw==}
+    engines: {node: '>= 14.18.0'}
+
   recursive-copy@2.0.14:
     resolution: {integrity: sha512-K8WNY8f8naTpfbA+RaXmkaQuD1IeW9EgNEfyGxSqqTQukpVtoOKros9jUqbpEsSw59YOmpd8nCBgtqJZy5nvog==}
 
@@ -2853,8 +2965,9 @@ packages:
   resolve-pkg-maps@1.0.0:
     resolution: {integrity: sha512-seS2Tj26TBVOC2NIc2rOe2y2ZO7efxITtLZcGSOnHHNOQ7CkiUBfw0Iw2ck6xkIhPwLhKNLS8BO+hEpngQlqzw==}
 
-  resolve@1.22.8:
-    resolution: {integrity: sha512-oKWePCxqpd6FlLvGV1VU0x7bkPmmCNolxzjMf4NczoDnQcIWrAF+cPtZn5i6n+RfD2d9i0tzpKnG6Yk168yIyw==}
+  resolve@1.22.10:
+    resolution: {integrity: sha512-NPRy+/ncIMeDlTAsuqwKIiferiawhefFJtkNSW0qZJEqMEb+qBt/77B/jGeeek+F0uOeN05CDa6HXbbIgtVX4w==}
+    engines: {node: '>= 0.4'}
     hasBin: true
 
   restore-cursor@2.0.0:
@@ -2889,8 +3002,8 @@ packages:
   robots-txt-parse@0.0.4:
     resolution: {integrity: sha512-B2VQEC5oe9MD/77oILGi98NNAqtY1BlqgrwlYjq/RR5sDfZqpkFj1sG5pCieiSApoTxatJgGW+yWCh0zFfOGMQ==}
 
-  rollup@4.18.0:
-    resolution: {integrity: sha512-QmJz14PX3rzbJCN1SG4Xe/bAAX2a6NpCP8ab2vfu2GiUr8AQcr2nCV/oEO3yneFarB67zk8ShlIyWb2LGTb3Sg==}
+  rollup@4.30.1:
+    resolution: {integrity: sha512-mlJ4glW020fPuLi7DkM/lN97mYEZGWeqBnrljzN0gs7GLctqX3lNWxKQ7Gl712UAX+6fog/L3jh4gb7R6aVi3w==}
     engines: {node: '>=18.0.0', npm: '>=8.0.0'}
     hasBin: true
 
@@ -2914,8 +3027,8 @@ packages:
   safer-buffer@2.1.2:
     resolution: {integrity: sha512-YZo3K82SD7Riyi0E1EQPojLz7kpepnSQI9IyPbHHg1XXXevb5dJI7tpyN2ADxGcQbHG7vcyRHk0cbwqcQriUtg==}
 
-  sass@1.77.6:
-    resolution: {integrity: sha512-ByXE1oLD79GVq9Ht1PeHWCPMPB8XHpBuz1r85oByKHjZY6qV6rWnQovQzXJXuQ/XyE1Oj3iPk3lo28uzaRA2/Q==}
+  sass@1.83.1:
+    resolution: {integrity: sha512-EVJbDaEs4Rr3F0glJzFSOvtg2/oy2V/YrGFPqPY24UqcLDWcI9ZY5sN+qyO3c/QCZwzgfirvhXvINiJCE/OLcA==}
     engines: {node: '>=14.0.0'}
     hasBin: true
 
@@ -2945,35 +3058,31 @@ packages:
     resolution: {integrity: sha512-BR7VvDCVHO+q2xBEWskxS6DJE1qRnb7DxzUrogb71CWoSficBxYsiAGd+Kl0mmq/MprG9yArRkyrQxTO6XjMzA==}
     hasBin: true
 
-  semver@7.6.2:
-    resolution: {integrity: sha512-FNAIBWCx9qcRhoHcgcJ0gvU7SN1lYU2ZXuSfl04bSC5OpvDHFyJCjdNHomPXxjQlCBU67YW64PzY7/VIEH7F2w==}
+  semver@7.6.3:
+    resolution: {integrity: sha512-oVekP1cKtI+CTDvHWYFUcMtsK/00wmAEfyqKfNdARm8u1wNVhSgaX7A8d4UuIlUI5e84iEwOhs7ZPYRmzU9U6A==}
     engines: {node: '>=10'}
     hasBin: true
 
-  send@0.18.0:
-    resolution: {integrity: sha512-qqWzuOjSFOuqPjFe4NOsMLafToQQwBSOEpS+FwEt3A2V3vKubTquT3vmLTQpFgMXp8AlFWFuP1qKaJZOtPpVXg==}
+  send@0.19.0:
+    resolution: {integrity: sha512-dW41u5VfLXu8SJh5bwRmyYUbAoSB3c9uQh6L8h/KtsFREPWpbX1lrljJo186Jc4nmci/sGUZ9a0a0J2zgfq2hw==}
     engines: {node: '>= 0.8.0'}
 
   serialize-javascript@6.0.2:
     resolution: {integrity: sha512-Saa1xPByTTq2gdeFZYLLo+RFE35NHZkAbqZeWNd3BpzppeVisAqpDjcp8dyf6uIvEqJRd46jemmyA4iFIeVk8g==}
 
-  serve-static@1.15.0:
-    resolution: {integrity: sha512-XGuRDNjXUijsUL0vl6nSD7cwURuzEgglbOaFuZM9g3kwDXOWVTck0jLzjPzGD+TazWbboZYu52/9/XPdUgne9g==}
+  serve-static@1.16.2:
+    resolution: {integrity: sha512-VqpjJZKadQB/PEbEwvFdO43Ax5dFBZ2UECszz8bQ7pi7wt//PWe1P6MN7eCnjsatYtBT6EuiClbjSWP2WrIoTw==}
     engines: {node: '>= 0.8.0'}
 
   set-blocking@2.0.0:
     resolution: {integrity: sha512-KiKBS8AnWGEyLzofFfmvKwpdPzqiy16LvQfK3yv/fVH7Bj13/wl3JSR1J+rfgRE9q7xUJK4qvgS8raSOeLUehw==}
 
-  set-function-length@1.2.2:
-    resolution: {integrity: sha512-pgRc4hJ4/sNjWCSS9AmnS40x3bNMDTknHgL5UaMBTMyJnU90EgWh1Rz+MC9eFu4BuN/UwZjKQuY/1v3rM7HMfg==}
-    engines: {node: '>= 0.4'}
-
   setprototypeof@1.2.0:
     resolution: {integrity: sha512-E5LDX7Wrp85Kil5bhZv46j8jOeboKq5JMmYM3gVGdGH8xFpPWXUMsNrlODCrkoxMEeNi/XZIwuRvY4XNwYMJpw==}
 
-  sharp@0.33.4:
-    resolution: {integrity: sha512-7i/dt5kGl7qR4gwPRD2biwD2/SvBn3O04J77XKFgL2OnZtQw+AG9wnuS/csmu80nPRHLYE9E41fyEiG8nhH6/Q==}
-    engines: {libvips: '>=8.15.2', node: ^18.17.0 || ^20.3.0 || >=21.0.0}
+  sharp@0.33.5:
+    resolution: {integrity: sha512-haPVm1EkS9pgvHrQ/F3Xy+hgcuMV0Wm9vfIBSiwZ05k+xgb0PkBQpGsAA/oWdDobNaZTH5ppvHtzCFbnSEwHVw==}
+    engines: {node: ^18.17.0 || ^20.3.0 || >=21.0.0}
 
   shebang-command@2.0.0:
     resolution: {integrity: sha512-kHxr2zZpYtdmrN1qDjrrX/Z1rR1kG8Dx+gkpK1G4eXmvXswmcE1hTWBWYUzlraYw1/yZp6YuDY77YtvbN0dmDA==}
@@ -2983,20 +3092,29 @@ packages:
     resolution: {integrity: sha512-7++dFhtcx3353uBaq8DDR4NuxBetBzC7ZQOhmTQInHEd6bSrXdiEyzCvG07Z44UYdLShWUyXt5M/yhz8ekcb1A==}
     engines: {node: '>=8'}
 
-  shell-quote@1.8.1:
-    resolution: {integrity: sha512-6j1W9l1iAs/4xYBI1SYOVZyFcCis9b4KCLQ8fgAGG07QvzaRLVVRQvAy85yNmmZSjYjg4MWh4gNvlPujU/5LpA==}
+  shell-quote@1.8.2:
+    resolution: {integrity: sha512-AzqKpGKjrj7EM6rKVQEPpB288oCfnrEIuyoT9cyF4nmGa7V8Zk6f7RRqYisX8X9m+Q7bd632aZW4ky7EhbQztA==}
+    engines: {node: '>= 0.4'}
+
+  side-channel-list@1.0.0:
+    resolution: {integrity: sha512-FCLHtRD/gnpCiCHEiJLOwdmFP+wzCmDEkc9y7NsYxeF4u7Btsn1ZuwgwJGxImImHicJArLP4R0yX4c2KCrMrTA==}
+    engines: {node: '>= 0.4'}
 
-  side-channel@1.0.6:
-    resolution: {integrity: sha512-fDW/EZ6Q9RiO8eFG8Hj+7u/oW+XrPTIChwCOM2+th2A6OblDtYYIpve9m+KvI9Z4C9qSEXlaGR6bTEYHReuglA==}
+  side-channel-map@1.0.1:
+    resolution: {integrity: sha512-VCjCNfgMsby3tTdo02nbjtM/ewra6jPHmpThenkTYh8pG9ucZ/1P8So4u4FGBek/BjpOVsDCMoLA/iuBKIFXRA==}
+    engines: {node: '>= 0.4'}
+
+  side-channel-weakmap@1.0.2:
+    resolution: {integrity: sha512-WPS/HvHQTYnHisLo9McqBHOJk2FkHO/tlpvldyrnem4aeQp4hai3gythswg6p01oSoTl58rcpiFAjF2br2Ak2A==}
+    engines: {node: '>= 0.4'}
+
+  side-channel@1.1.0:
+    resolution: {integrity: sha512-ZX99e6tRweoUXqR+VBrslhda51Nh5MTQwou5tnUDgbtyM0dBgmhEDtWGP/xbKn6hqfPRHujUNwz5fy/wbbhnpw==}
     engines: {node: '>= 0.4'}
 
   signal-exit@3.0.7:
     resolution: {integrity: sha512-wnD2ZE+l+SPC/uoS0vXeE9L1+0wuaMqKlfz9AMUo38JsyLSBWSFcHR1Rri62LZc12vLr1gb3jl7iwQhgwpAbGQ==}
 
-  signal-exit@4.1.0:
-    resolution: {integrity: sha512-bzyZ1e88w9O1iNJbKnOlvYTrWPDl46O1bG0D3XInv+9tkPrxrN8jUUTiFlDkkmKWgn1M6CfIA13SuGqOa9Korw==}
-    engines: {node: '>=14'}
-
   simple-swizzle@0.2.2:
     resolution: {integrity: sha512-JA//kQgZtbuY83m+xT+tXJkmJncGMTFT+C+g2h2R9uxkYIrE2yy9sgmcLhCnw57/WSD+Eh3J97FPEDFnbXnDUg==}
 
@@ -3020,16 +3138,16 @@ packages:
   smob@1.5.0:
     resolution: {integrity: sha512-g6T+p7QO8npa+/hNx9ohv1E5pVCmWrVCUzUXJyLdMmftX6ER0oiWY/w9knEonLpnOp6b6FenKnMfR8gqwWdwig==}
 
-  socks-proxy-agent@8.0.4:
-    resolution: {integrity: sha512-GNAq/eg8Udq2x0eNiFkr9gRg5bA7PXEWagQdeRX4cPSG+X/8V38v637gim9bjFptMk1QWsCTr0ttrJEiXbNnRw==}
+  socks-proxy-agent@8.0.5:
+    resolution: {integrity: sha512-HehCEsotFqbPW9sJ8WVYB6UbmIMv7kUUORIF2Nncq4VQvBfNBLibW9YZR5dlYCSUhwcD628pRllm7n+E+YTzJw==}
     engines: {node: '>= 14'}
 
   socks@2.8.3:
     resolution: {integrity: sha512-l5x7VUUWbjVFbafGLxPWkYsHIhEvmF85tbIeFZWc8ZPtoMyybuEhL7Jye/ooC4/d48FgOjSJXgsF/AJPYCW8Zw==}
     engines: {node: '>= 10.0.0', npm: '>= 3.0.0'}
 
-  source-map-js@1.2.0:
-    resolution: {integrity: sha512-itJW8lvSA0TXEphiRoawsCksnlf8SyvmFzIhltqAHluXd88pkCd+cXJVHTDwdCr0IzwptSm035IHQktUu1QUMg==}
+  source-map-js@1.2.1:
+    resolution: {integrity: sha512-UXWMKhLOwVKb728IUtQPXxfYU+usdybtUrK/8uGE8CQMvrhOpwvzDBwj0QhSL7MQc7vIsISBG8VQ8+IDQxpfQA==}
     engines: {node: '>=0.10.0'}
 
   source-map-support@0.5.21:
@@ -3078,8 +3196,8 @@ packages:
   stream-length@1.0.2:
     resolution: {integrity: sha512-aI+qKFiwoDV4rsXiS7WRoCt+v2RX1nUj17+KJC5r2gfh5xoSJIfP6Y3Do/HtvesFcTSWthIuJ3l1cvKQY/+nZg==}
 
-  streamx@2.18.0:
-    resolution: {integrity: sha512-LLUC1TWdjVdn1weXGcSxyTR3T4+acB6tVGXT95y0nGbca4t4o/ng1wKAGTljm9VicuCVLvRlqFYXYy5GwgM7sQ==}
+  streamx@2.21.1:
+    resolution: {integrity: sha512-PhP9wUnFLa+91CPy3N6tiQsK+gnYyUNuk15S3YG/zjYE7RuPeCjJngqnzpC31ow0lzBHQ+QGO4cNJnd0djYUsw==}
 
   string-width@2.1.1:
     resolution: {integrity: sha512-nOqH59deCq9SRHlxq1Aw85Jnt4w6KvLKqWVik6oA9ZklXLNIOlqg4F2yrT1MVaTjAqvVwdfeZ7w7aCvJD7ugkw==}
@@ -3089,10 +3207,6 @@ packages:
     resolution: {integrity: sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==}
     engines: {node: '>=8'}
 
-  string-width@5.1.2:
-    resolution: {integrity: sha512-HnLOCR3vjcY8beoNLtcjZ5/nxn2afmME6lhrDrebokqMap+XbeW8n9TXpPDOqdGK5qcI3oT0GKTW6wC7EMiVqA==}
-    engines: {node: '>=12'}
-
   string_decoder@0.10.31:
     resolution: {integrity: sha512-ev2QzSzWPYmy9GuqfIVildA4OdcGLeFZQrq5ys6RtiuF+RQQiZWr8TZNyAcuVXyQRYfEO+MsoB/1BuQVhOJuoQ==}
 
@@ -3120,10 +3234,6 @@ packages:
     resolution: {integrity: sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==}
     engines: {node: '>=8'}
 
-  strip-ansi@7.1.0:
-    resolution: {integrity: sha512-iq6eVVI64nQQTRYq2KtEg2d2uU7LElhTJwsH4YzIHZshxlgZms/wIc4VoDQTlG/IvVIrBKG06CrZnp0qv7hkcQ==}
-    engines: {node: '>=12'}
-
   strip-bom-string@1.0.0:
     resolution: {integrity: sha512-uCC2VHvQRYu+lMh4My/sFNmF2klFymLX1wHJeXnbEJERpV/ZsVuonzerjfrGpIGF7LBVa1O7i9kjiWvJiFck8g==}
     engines: {node: '>=0.10.0'}
@@ -3161,33 +3271,30 @@ packages:
   symbol-tree@3.2.4:
     resolution: {integrity: sha512-9QNk5KwDF+Bvz+PyObkmSYjI5ksVUYtjW7AU22r2NKcfLJcXp96hkDWU3+XndOsUb+AQ9QhfzfCT2O+CNWT5Tw==}
 
-  synckit@0.8.8:
-    resolution: {integrity: sha512-HwOKAP7Wc5aRGYdKH+dw0PRRpbO841v2DENBtjnR5HFWoiNByAl7vrx3p0G/rCyYXQsrxqtX48TImFtPcIHSpQ==}
+  synckit@0.9.2:
+    resolution: {integrity: sha512-vrozgXDQwYO72vHjUb/HnFbQx1exDjoKzqx23aXEg2a9VIg2TSFZ8FmeZpTjUCFMYw7mpX4BE2SFu8wI7asYsw==}
     engines: {node: ^14.18.0 || >=16.0.0}
 
   tapable@2.2.1:
     resolution: {integrity: sha512-GNzQvQTOIP6RyTfE2Qxb8ZVlNmw0n88vp1szwWRimP02mnTsx3Wtn5qRdqY9w2XduFNUgvOwhNnQsjwCp+kqaQ==}
     engines: {node: '>=6'}
 
-  tar-fs@3.0.4:
-    resolution: {integrity: sha512-5AFQU8b9qLfZCX9zp2duONhPmZv0hGYiBPJsyUdqMjzq/mqVpy/rEUSeHk1+YitmxugaptgBh5oDGU3VsAJq4w==}
+  tar-fs@3.0.7:
+    resolution: {integrity: sha512-2sAfoF/zw/2n8goUGnGRZTWTD4INtnScPZvyYBI6BDlJ3wNR5o1dw03EfBvuhG6GBLvC4J+C7j7W+64aZ0ogQA==}
 
   tar-stream@3.1.7:
     resolution: {integrity: sha512-qJj60CXt7IU1Ffyc3NJMjh6EkuCFej46zUqJ4J7pqYlThyd9bO0XBTmcOIhSzZJVWfsLks0+nle/j538YAW9RQ==}
 
-  terser@5.31.1:
-    resolution: {integrity: sha512-37upzU1+viGvuFtBo9NPufCb9dwM0+l9hMxYyWfBA+fbwrPqNJAhbZ6W47bBFnZHKHTUBnMvi87434qq+qnxOg==}
+  terser@5.37.0:
+    resolution: {integrity: sha512-B8wRRkmre4ERucLM/uXx4MOV5cbnOlVAqUst+1+iLKPI0dOgFO28f84ptoQt9HEI537PMzfYa/d+GEPKTRXmYA==}
     engines: {node: '>=10'}
     hasBin: true
 
-  text-decoder@1.1.0:
-    resolution: {integrity: sha512-TmLJNj6UgX8xcUZo4UDStGQtDiTzF7BzWlzn9g7UWrjkpHr5uJTK1ld16wZ3LXb2vb6jH8qU89dW5whuMdXYdw==}
+  text-decoder@1.2.3:
+    resolution: {integrity: sha512-3/o9z3X0X0fTupwsYvR03pJ/DjWuqqrfwBgTQzdWDiQSm9KitAyz/9WqsT2JQW7KV2m+bC2ol/zqpW37NHxLaA==}
 
-  text-table@0.2.0:
-    resolution: {integrity: sha512-N+8UisAXDGk8PFXP4HAzVR9nbfmVJ3zYLAWiTIoqC5v5isinhr+r5uaO8+7r3BMfuNIufIsA7RdpVgacC2cSpw==}
-
-  third-party-web@0.24.3:
-    resolution: {integrity: sha512-imE6hXZyaCeGinGFCvpWsv0oelsEaufSG39qYBQhp3urGq4OLOtsuEddf3XgKxmAAczBD/I1Tnp8L3gJ3ksTuQ==}
+  third-party-web@0.24.5:
+    resolution: {integrity: sha512-1rUOdMYpNTRajgk1F7CmHD26oA6rTKekBjHay854J6OkPXeNyPcR54rhWDaamlWyi9t2wAVPQESdedBhucmOLA==}
 
   through2-sink@1.0.0:
     resolution: {integrity: sha512-9HvIHIEXZ5YgstQx3vsu4U/QQ/n7X5RHlXf8MsfSEnEzeUFbX9BHBWmlwdQ1b6CzDlUEDwjFnkSIxpJZ6qP+0Q==}
@@ -3201,11 +3308,11 @@ packages:
   through@2.3.8:
     resolution: {integrity: sha512-w89qg7PI8wAdvX60bMDP+bFoD5Dvhm9oLheFp5O4a2QF0cSBGsBX4qZmadPMvVqlLJBBci+WqGGOAPvcDeNSVg==}
 
-  tldts-core@6.1.31:
-    resolution: {integrity: sha512-IdTd0OpW2qgG1mbFxoXp14ohLNO6KP+H3htsNb3pk2FF8m21vvIaDlTWmKBR+UnZmXkSFOfZYYeswPAjSoHs+g==}
+  tldts-core@6.1.71:
+    resolution: {integrity: sha512-LRbChn2YRpic1KxY+ldL1pGXN/oVvKfCVufwfVzEQdFYNo39uF7AJa/WXdo+gYO7PTvdfkCPCed6Hkvz/kR7jg==}
 
-  tldts-icann@6.1.31:
-    resolution: {integrity: sha512-C4skEg7UQ039td+I2vkNIPqv9h7T4EOocOAaco1Y5elNSJQhdcHlGm9QhqYVtFmPRN5apUrpu3lc2QiAtVV66A==}
+  tldts-icann@6.1.71:
+    resolution: {integrity: sha512-hEbB+VrNQM3Nhs+2FFWrCNbYGhFJb9MzfzEjK4qrZUBC2y2v0V99sJofJE99SfI0jac4ZdPBtdU82ges+EQGIw==}
 
   tmp@0.0.33:
     resolution: {integrity: sha512-jRCJlojKnZ3addtTOjdIqoRuPEKBvNXcGYqzO6zWZX8KfKEpnGY5jfggJQ3EjKuu8D4bJRr0y+cYJFmYbImXGw==}
@@ -3215,10 +3322,6 @@ packages:
     resolution: {integrity: sha512-J7Z2K08jbGcdA1kkQpJSqLF6T0tdQqpR2pnSUXsIchbPdTI9v3e85cLW0d6WDhwuAleOV71j2xWs8qMPfK7nKw==}
     engines: {node: '>=6'}
 
-  to-fast-properties@2.0.0:
-    resolution: {integrity: sha512-/OaKK0xYrs3DmxRYqL/yDc+FxFUVYhDlXMhRmv3z915w2HF1tnN1omB354j8VUGO/hbRzyD6Y3sA7v7GS/ceog==}
-    engines: {node: '>=4'}
-
   to-regex-range@5.0.1:
     resolution: {integrity: sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==}
     engines: {node: '>=8.0'}
@@ -3247,8 +3350,8 @@ packages:
   tslib@1.14.1:
     resolution: {integrity: sha512-Xni35NKzjgMrwevysHTCArtLDpPvye8zV/0E4EyYn43P7/7qvQwPh9BGkHewbMulVntbigmcT7rdX3BNo9wRJg==}
 
-  tslib@2.6.3:
-    resolution: {integrity: sha512-xNvxJEOUiWPGhUuUdQgAJPKOOJfGnIyKySOc09XkKsgdUV/3E2zvwZYdejjmRgPCgcym1juLH3226yA7sEFJKQ==}
+  tslib@2.8.1:
+    resolution: {integrity: sha512-oJFu94HQb+KVduSUQL7wnpmqnfmLsOA/nAh6b6EH0wCEoK0/mPeXU6c3wKDV83MkOuHPRHtSXKKU99IBazS/2w==}
 
   tunnel-agent@0.6.0:
     resolution: {integrity: sha512-McnNiV1l8RYeY8tBgEpuodCC1mLUdbSN+CYBL7kJsJNInOP8UjDDEwdk6Mw60vdLLrr5NHKZhMAOSrR2NZuQ+w==}
@@ -3280,25 +3383,21 @@ packages:
   uc.micro@2.1.0:
     resolution: {integrity: sha512-ARDJmphmdvUk6Glw7y9DQ2bFkKBHwQHLi2lsaH6PPmz/Ka9sFOBsBluozhDltWmnv9u/cF6Rt87znRTPV+yp/A==}
 
-  uglify-js@3.18.0:
-    resolution: {integrity: sha512-SyVVbcNBCk0dzr9XL/R/ySrmYf0s372K6/hFklzgcp2lBFyXtw4I7BOdDjlLhE1aVqaI/SHWXWmYdlZxuyF38A==}
+  uglify-js@3.19.3:
+    resolution: {integrity: sha512-v3Xu+yuwBXisp6QYTcH4UbH+xYJXqnq2m/LtQVWKWzYc1iehYnLixoQDN9FH6/j9/oybfd6W9Ghwkl8+UMKTKQ==}
     engines: {node: '>=0.8.0'}
     hasBin: true
 
   unbzip2-stream@1.4.3:
     resolution: {integrity: sha512-mlExGW4w71ebDJviH16lQLtZS32VKqsSfk80GCfUlwT/4/hNRFsoscrF/c++9xinkMzECL1uL9DDwXqFWkruPg==}
 
-  undici-types@5.26.5:
-    resolution: {integrity: sha512-JlCMO+ehdEIKqlFxk6IfVoAUVmgz7cU7zD/h9XZ0qzeosSHmUJVOzSQvvYSYWXkFXC+IfLKSIffhv0sVZup6pA==}
+  undici-types@6.20.0:
+    resolution: {integrity: sha512-Ny6QZ2Nju20vw1SRHe3d9jVu6gJ+4e3+MMpqu7pqE5HT6WsTSlce++GQmK5UXS8mzV8DSYHrQH+Xrf2jVcuKNg==}
 
   unique-string@2.0.0:
     resolution: {integrity: sha512-uNaeirEPvpZWSgzwsPGtU2zVSTrn/8L5q/IexZmH0eH6SA73CmAA5U4GwORTxQAZs95TAXLNqeLoPPNO5gZfWg==}
     engines: {node: '>=8'}
 
-  universalify@2.0.1:
-    resolution: {integrity: sha512-gptHNQghINnc/vTGIk0SOFGFNXw7JVrlRUtConJRlvaw6DuX0wO5Jeko9sWrMBhh+PsYAZ7oXAiOnf/UKogyiw==}
-    engines: {node: '>= 10.0.0'}
-
   unpipe@1.0.0:
     resolution: {integrity: sha512-pjy2bYhSsufwWlKwPc+l3cN7+wuJlK6uz0YdJEOlQDbl6jo/YlPi4mb8agUkVC8BF7V8NuzeyPNqRksA3hztKQ==}
     engines: {node: '>= 0.8'}
@@ -3392,8 +3491,13 @@ packages:
     engines: {node: '>= 8'}
     hasBin: true
 
-  wicg-inert@3.1.2:
-    resolution: {integrity: sha512-Ba9tGNYxXwaqKEi9sJJvPMKuo063umUPsHN0JJsjrs2j8KDSzkWLMZGZ+MH1Jf1Fq4OWZ5HsESJID6nRza2ang==}
+  which@5.0.0:
+    resolution: {integrity: sha512-JEdGzHwwkrbWoGOlIHqQ5gtprKGOenpDHpxE9zVR1bWbOtYRyPPHMe9FaP6x61CmNaTThSkb0DAJte5jD+DmzQ==}
+    engines: {node: ^18.17.0 || >=20.5.0}
+    hasBin: true
+
+  wicg-inert@3.1.3:
+    resolution: {integrity: sha512-5L0PKK7iP+0Q/jv2ccgmkz/pfXbumZtlEyWS/xnX+L+Og3f7WjL4+iEs18k4IuldOX3PgGpza3qGndL9xUBjCQ==}
 
   win-release@1.1.1:
     resolution: {integrity: sha512-iCRnKVvGxOQdsKhcQId2PXV1vV3J/sDPXKA4Oe9+Eti2nb2ESEsYHRYls/UjoUW3bIc5ZDO8dTH50A/5iVN+bw==}
@@ -3418,10 +3522,6 @@ packages:
     resolution: {integrity: sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==}
     engines: {node: '>=10'}
 
-  wrap-ansi@8.1.0:
-    resolution: {integrity: sha512-si7QWI6zUMq56bESFvagtmzMdGOtoxfR+Sez11Mobfc7tm+VkUckk9bW2UeffTGVUbOksxmSw0AA2gs8g71NCQ==}
-    engines: {node: '>=12'}
-
   wrappy@1.0.2:
     resolution: {integrity: sha512-l4Sp/DRseor9wL6EvV2+TuQn63dMkPjZ/sp9XkghTEbV9KlPS1xUsZ3u7/IQO4wxtcFB4bgpQPRcR3QCvezPcQ==}
 
@@ -3451,18 +3551,6 @@ packages:
       utf-8-validate:
         optional: true
 
-  ws@8.16.0:
-    resolution: {integrity: sha512-HS0c//TP7Ina87TfiPUz1rQzMhHrl/SG2guqRcTOIUYD2q8uhUdNHZYJUaQ8aTGPzCh+c6oawMKW35nFl1dxyQ==}
-    engines: {node: '>=10.0.0'}
-    peerDependencies:
-      bufferutil: ^4.0.1
-      utf-8-validate: '>=5.0.2'
-    peerDependenciesMeta:
-      bufferutil:
-        optional: true
-      utf-8-validate:
-        optional: true
-
   ws@8.18.0:
     resolution: {integrity: sha512-8VbfWfHLbbwu3+N6OKsOMpBdT4kXPDDB9cJk2bJ6mh9ucxdlnNvH1e+roYkKmN9Nxw2yjz7VzeO9oOz2zJ04Pw==}
     engines: {node: '>=10.0.0'}
@@ -3502,8 +3590,8 @@ packages:
   yallist@4.0.0:
     resolution: {integrity: sha512-3wdGidZyq5PB084XLES5TpOSRA3wjXAlIWMhum2kRcv/41Sn2emQ0dycQW4uZXLejwKvg6EsvbdlVL+FYEct7A==}
 
-  yaml@2.4.5:
-    resolution: {integrity: sha512-aBx2bnqDzVOyNKfsysjA2ms5ZlnjSAW2eG3/L5G/CSujfjLJTJsEw1bGw8kCf04KodQWk1pxlGnZ56CRxiawmg==}
+  yaml@2.7.0:
+    resolution: {integrity: sha512-+hSoy/QHluxmC9kCIJyL/uyFmLmc+e5CFR5Wa+bpIhIj85LVb9ZH2nVnqrHoSvKogwODv0ClqZkmiSSaIH5LTA==}
     engines: {node: '>= 14'}
     hasBin: true
 
@@ -3536,6 +3624,9 @@ packages:
     resolution: {integrity: sha512-rVksvsnNCdJ/ohGc6xgPwyN8eheCxsiLM8mxuE/t/mOVqJewPuO1miLpTHQiRgTKCLexL4MeAFVagts7HmNZ2Q==}
     engines: {node: '>=10'}
 
+  zod@3.23.8:
+    resolution: {integrity: sha512-XBx9AXhXktjUqnepgTiE5flcKIYWi/rme0Eaj+5Y0lftuGBq+jyRu/md4WnuxqgP1ubdpNCsYEYPxrzVHD8d6g==}
+
 snapshots:
 
   '@11ty/dependency-tree@2.0.1': {}
@@ -3544,12 +3635,12 @@ snapshots:
     dependencies:
       '@11ty/eleventy-utils': 1.0.3
       chokidar: 3.6.0
-      debug: 4.3.5
+      debug: 4.4.0
       dev-ip: 1.0.1
-      finalhandler: 1.2.0
+      finalhandler: 1.3.1
       mime: 3.0.0
       minimist: 1.2.8
-      morphdom: 2.7.3
+      morphdom: 2.7.4
       please-upgrade-node: 3.2.0
       ssri: 8.0.1
       ws: 8.18.0
@@ -3558,27 +3649,27 @@ snapshots:
       - supports-color
       - utf-8-validate
 
-  '@11ty/eleventy-fetch@4.0.1':
+  '@11ty/eleventy-fetch@5.0.2':
     dependencies:
-      debug: 4.3.5
-      flat-cache: 3.2.0
-      node-fetch: 2.7.0
+      '@rgrove/parse-xml': 4.2.0
+      debug: 4.4.0
+      flat-cache: 6.1.5
+      graceful-fs: 4.2.11
       p-queue: 6.6.2
     transitivePeerDependencies:
-      - encoding
       - supports-color
 
-  '@11ty/eleventy-img@4.0.2':
+  '@11ty/eleventy-img@6.0.0':
     dependencies:
-      '@11ty/eleventy-fetch': 4.0.1
+      '@11ty/eleventy-fetch': 5.0.2
+      '@11ty/eleventy-utils': 2.0.0
       brotli-size: 4.0.0
-      debug: 4.3.5
-      entities: 4.5.0
-      image-size: 1.1.1
+      debug: 4.4.0
+      entities: 6.0.0
+      image-size: 1.2.0
       p-queue: 6.6.2
-      sharp: 0.33.4
+      sharp: 0.33.5
     transitivePeerDependencies:
-      - encoding
       - supports-color
 
   '@11ty/eleventy-navigation@0.3.5':
@@ -3587,7 +3678,7 @@ snapshots:
 
   '@11ty/eleventy-plugin-rss@1.2.0':
     dependencies:
-      debug: 4.3.5
+      debug: 4.4.0
       posthtml: 0.16.6
       posthtml-urls: 1.0.0
     transitivePeerDependencies:
@@ -3601,6 +3692,8 @@ snapshots:
     dependencies:
       normalize-path: 3.0.0
 
+  '@11ty/eleventy-utils@2.0.0': {}
+
   '@11ty/eleventy@2.0.1':
     dependencies:
       '@11ty/dependency-tree': 2.0.1
@@ -3611,11 +3704,11 @@ snapshots:
       '@sindresorhus/slugify': 1.1.2
       bcp-47-normalize: 1.1.1
       chokidar: 3.6.0
-      cross-spawn: 7.0.3
-      debug: 4.3.5
+      cross-spawn: 7.0.6
+      debug: 4.4.0
       dependency-graph: 0.11.0
       ejs: 3.1.10
-      fast-glob: 3.3.2
+      fast-glob: 3.3.3
       graceful-fs: 4.2.11
       gray-matter: 4.0.3
       hamljs: 0.6.2
@@ -3623,23 +3716,23 @@ snapshots:
       is-glob: 4.0.3
       iso-639-1: 2.1.15
       kleur: 4.1.5
-      liquidjs: 10.14.0
-      luxon: 3.4.4
+      liquidjs: 10.20.1
+      luxon: 3.5.0
       markdown-it: 13.0.2
-      micromatch: 4.0.7
+      micromatch: 4.0.8
       minimist: 1.2.8
       moo: 0.5.2
       multimatch: 5.0.0
       mustache: 4.2.0
       normalize-path: 3.0.0
       nunjucks: 3.2.4(chokidar@3.6.0)
-      path-to-regexp: 6.2.2
+      path-to-regexp: 6.3.0
       please-upgrade-node: 3.2.0
       posthtml: 0.16.6
       posthtml-urls: 1.0.0
       pug: 3.0.3
       recursive-copy: 2.0.14
-      semver: 7.6.2
+      semver: 7.6.3
       slugify: 1.6.6
     transitivePeerDependencies:
       - bufferutil
@@ -3648,59 +3741,56 @@ snapshots:
 
   '@11ty/lodash-custom@4.17.21': {}
 
-  '@babel/code-frame@7.24.7':
+  '@babel/code-frame@7.26.2':
     dependencies:
-      '@babel/highlight': 7.24.7
-      picocolors: 1.0.1
-
-  '@babel/helper-string-parser@7.24.7': {}
+      '@babel/helper-validator-identifier': 7.25.9
+      js-tokens: 4.0.0
+      picocolors: 1.1.1
 
-  '@babel/helper-validator-identifier@7.24.7': {}
+  '@babel/helper-string-parser@7.25.9': {}
 
-  '@babel/highlight@7.24.7':
-    dependencies:
-      '@babel/helper-validator-identifier': 7.24.7
-      chalk: 2.4.2
-      js-tokens: 4.0.0
-      picocolors: 1.0.1
+  '@babel/helper-validator-identifier@7.25.9': {}
 
-  '@babel/parser@7.24.7':
+  '@babel/parser@7.26.5':
     dependencies:
-      '@babel/types': 7.24.7
+      '@babel/types': 7.26.5
 
-  '@babel/types@7.24.7':
+  '@babel/types@7.26.5':
     dependencies:
-      '@babel/helper-string-parser': 7.24.7
-      '@babel/helper-validator-identifier': 7.24.7
-      to-fast-properties: 2.0.0
+      '@babel/helper-string-parser': 7.25.9
+      '@babel/helper-validator-identifier': 7.25.9
 
-  '@emnapi/runtime@1.2.0':
+  '@emnapi/runtime@1.3.1':
     dependencies:
-      tslib: 2.6.3
+      tslib: 2.8.1
     optional: true
 
-  '@eslint-community/eslint-utils@4.4.0(eslint@9.6.0)':
+  '@eslint-community/eslint-utils@4.4.1(eslint@9.18.0)':
     dependencies:
-      eslint: 9.6.0
+      eslint: 9.18.0
       eslint-visitor-keys: 3.4.3
 
-  '@eslint-community/regexpp@4.11.0': {}
+  '@eslint-community/regexpp@4.12.1': {}
 
-  '@eslint/config-array@0.17.0':
+  '@eslint/config-array@0.19.1':
     dependencies:
-      '@eslint/object-schema': 2.1.4
-      debug: 4.3.5
+      '@eslint/object-schema': 2.1.5
+      debug: 4.4.0
       minimatch: 3.1.2
     transitivePeerDependencies:
       - supports-color
 
-  '@eslint/eslintrc@3.1.0':
+  '@eslint/core@0.10.0':
+    dependencies:
+      '@types/json-schema': 7.0.15
+
+  '@eslint/eslintrc@3.2.0':
     dependencies:
       ajv: 6.12.6
-      debug: 4.3.5
-      espree: 10.1.0
+      debug: 4.4.0
+      espree: 10.3.0
       globals: 14.0.0
-      ignore: 5.3.1
+      ignore: 5.3.2
       import-fresh: 3.3.0
       js-yaml: 4.1.0
       minimatch: 3.1.2
@@ -3708,128 +3798,135 @@ snapshots:
     transitivePeerDependencies:
       - supports-color
 
-  '@eslint/js@9.6.0': {}
+  '@eslint/js@9.18.0': {}
+
+  '@eslint/object-schema@2.1.5': {}
+
+  '@eslint/plugin-kit@0.2.5':
+    dependencies:
+      '@eslint/core': 0.10.0
+      levn: 0.4.1
 
-  '@eslint/object-schema@2.1.4': {}
+  '@formatjs/ecma402-abstract@2.3.2':
+    dependencies:
+      '@formatjs/fast-memoize': 2.2.6
+      '@formatjs/intl-localematcher': 0.5.10
+      decimal.js: 10.4.3
+      tslib: 2.8.1
 
-  '@formatjs/ecma402-abstract@2.0.0':
+  '@formatjs/fast-memoize@2.2.6':
     dependencies:
-      '@formatjs/intl-localematcher': 0.5.4
-      tslib: 2.6.3
+      tslib: 2.8.1
 
-  '@formatjs/fast-memoize@2.2.0':
+  '@formatjs/icu-messageformat-parser@2.9.8':
     dependencies:
-      tslib: 2.6.3
+      '@formatjs/ecma402-abstract': 2.3.2
+      '@formatjs/icu-skeleton-parser': 1.8.12
+      tslib: 2.8.1
 
-  '@formatjs/icu-messageformat-parser@2.7.8':
+  '@formatjs/icu-skeleton-parser@1.8.12':
     dependencies:
-      '@formatjs/ecma402-abstract': 2.0.0
-      '@formatjs/icu-skeleton-parser': 1.8.2
-      tslib: 2.6.3
+      '@formatjs/ecma402-abstract': 2.3.2
+      tslib: 2.8.1
 
-  '@formatjs/icu-skeleton-parser@1.8.2':
+  '@formatjs/intl-localematcher@0.5.10':
     dependencies:
-      '@formatjs/ecma402-abstract': 2.0.0
-      tslib: 2.6.3
+      tslib: 2.8.1
+
+  '@humanfs/core@0.19.1': {}
 
-  '@formatjs/intl-localematcher@0.5.4':
+  '@humanfs/node@0.16.6':
     dependencies:
-      tslib: 2.6.3
+      '@humanfs/core': 0.19.1
+      '@humanwhocodes/retry': 0.3.1
 
   '@humanwhocodes/module-importer@1.0.1': {}
 
-  '@humanwhocodes/retry@0.3.0': {}
+  '@humanwhocodes/retry@0.3.1': {}
+
+  '@humanwhocodes/retry@0.4.1': {}
 
   '@iarna/toml@2.2.5': {}
 
-  '@img/sharp-darwin-arm64@0.33.4':
+  '@img/sharp-darwin-arm64@0.33.5':
     optionalDependencies:
-      '@img/sharp-libvips-darwin-arm64': 1.0.2
+      '@img/sharp-libvips-darwin-arm64': 1.0.4
     optional: true
 
-  '@img/sharp-darwin-x64@0.33.4':
+  '@img/sharp-darwin-x64@0.33.5':
     optionalDependencies:
-      '@img/sharp-libvips-darwin-x64': 1.0.2
+      '@img/sharp-libvips-darwin-x64': 1.0.4
     optional: true
 
-  '@img/sharp-libvips-darwin-arm64@1.0.2':
+  '@img/sharp-libvips-darwin-arm64@1.0.4':
     optional: true
 
-  '@img/sharp-libvips-darwin-x64@1.0.2':
+  '@img/sharp-libvips-darwin-x64@1.0.4':
     optional: true
 
-  '@img/sharp-libvips-linux-arm64@1.0.2':
+  '@img/sharp-libvips-linux-arm64@1.0.4':
     optional: true
 
-  '@img/sharp-libvips-linux-arm@1.0.2':
+  '@img/sharp-libvips-linux-arm@1.0.5':
     optional: true
 
-  '@img/sharp-libvips-linux-s390x@1.0.2':
+  '@img/sharp-libvips-linux-s390x@1.0.4':
     optional: true
 
-  '@img/sharp-libvips-linux-x64@1.0.2':
+  '@img/sharp-libvips-linux-x64@1.0.4':
     optional: true
 
-  '@img/sharp-libvips-linuxmusl-arm64@1.0.2':
+  '@img/sharp-libvips-linuxmusl-arm64@1.0.4':
     optional: true
 
-  '@img/sharp-libvips-linuxmusl-x64@1.0.2':
+  '@img/sharp-libvips-linuxmusl-x64@1.0.4':
     optional: true
 
-  '@img/sharp-linux-arm64@0.33.4':
+  '@img/sharp-linux-arm64@0.33.5':
     optionalDependencies:
-      '@img/sharp-libvips-linux-arm64': 1.0.2
+      '@img/sharp-libvips-linux-arm64': 1.0.4
     optional: true
 
-  '@img/sharp-linux-arm@0.33.4':
+  '@img/sharp-linux-arm@0.33.5':
     optionalDependencies:
-      '@img/sharp-libvips-linux-arm': 1.0.2
+      '@img/sharp-libvips-linux-arm': 1.0.5
     optional: true
 
-  '@img/sharp-linux-s390x@0.33.4':
+  '@img/sharp-linux-s390x@0.33.5':
     optionalDependencies:
-      '@img/sharp-libvips-linux-s390x': 1.0.2
+      '@img/sharp-libvips-linux-s390x': 1.0.4
     optional: true
 
-  '@img/sharp-linux-x64@0.33.4':
+  '@img/sharp-linux-x64@0.33.5':
     optionalDependencies:
-      '@img/sharp-libvips-linux-x64': 1.0.2
+      '@img/sharp-libvips-linux-x64': 1.0.4
     optional: true
 
-  '@img/sharp-linuxmusl-arm64@0.33.4':
+  '@img/sharp-linuxmusl-arm64@0.33.5':
     optionalDependencies:
-      '@img/sharp-libvips-linuxmusl-arm64': 1.0.2
+      '@img/sharp-libvips-linuxmusl-arm64': 1.0.4
     optional: true
 
-  '@img/sharp-linuxmusl-x64@0.33.4':
+  '@img/sharp-linuxmusl-x64@0.33.5':
     optionalDependencies:
-      '@img/sharp-libvips-linuxmusl-x64': 1.0.2
+      '@img/sharp-libvips-linuxmusl-x64': 1.0.4
     optional: true
 
-  '@img/sharp-wasm32@0.33.4':
+  '@img/sharp-wasm32@0.33.5':
     dependencies:
-      '@emnapi/runtime': 1.2.0
+      '@emnapi/runtime': 1.3.1
     optional: true
 
-  '@img/sharp-win32-ia32@0.33.4':
+  '@img/sharp-win32-ia32@0.33.5':
     optional: true
 
-  '@img/sharp-win32-x64@0.33.4':
+  '@img/sharp-win32-x64@0.33.5':
     optional: true
 
-  '@isaacs/cliui@8.0.2':
-    dependencies:
-      string-width: 5.1.2
-      string-width-cjs: string-width@4.2.3
-      strip-ansi: 7.1.0
-      strip-ansi-cjs: strip-ansi@6.0.1
-      wrap-ansi: 8.1.0
-      wrap-ansi-cjs: wrap-ansi@7.0.0
-
-  '@jridgewell/gen-mapping@0.3.5':
+  '@jridgewell/gen-mapping@0.3.8':
     dependencies:
       '@jridgewell/set-array': 1.2.1
-      '@jridgewell/sourcemap-codec': 1.4.15
+      '@jridgewell/sourcemap-codec': 1.5.0
       '@jridgewell/trace-mapping': 0.3.25
 
   '@jridgewell/resolve-uri@3.1.2': {}
@@ -3838,29 +3935,33 @@ snapshots:
 
   '@jridgewell/source-map@0.3.6':
     dependencies:
-      '@jridgewell/gen-mapping': 0.3.5
+      '@jridgewell/gen-mapping': 0.3.8
       '@jridgewell/trace-mapping': 0.3.25
 
-  '@jridgewell/sourcemap-codec@1.4.15': {}
+  '@jridgewell/sourcemap-codec@1.5.0': {}
 
   '@jridgewell/trace-mapping@0.3.25':
     dependencies:
       '@jridgewell/resolve-uri': 3.1.2
-      '@jridgewell/sourcemap-codec': 1.4.15
+      '@jridgewell/sourcemap-codec': 1.5.0
+
+  '@keyv/serialize@1.0.2':
+    dependencies:
+      buffer: 6.0.3
 
-  '@lhci/cli@0.13.0':
+  '@lhci/cli@0.14.0':
     dependencies:
-      '@lhci/utils': 0.13.0
+      '@lhci/utils': 0.14.0
       chrome-launcher: 0.13.4
-      compression: 1.7.4
-      debug: 4.3.5
-      express: 4.19.2
-      https-proxy-agent: 5.0.1
+      compression: 1.7.5
+      debug: 4.4.0
+      express: 4.21.2
       inquirer: 6.5.2
       isomorphic-fetch: 3.0.0
-      lighthouse: 11.4.0
+      lighthouse: 12.1.0
       lighthouse-logger: 1.2.0
       open: 7.4.2
+      proxy-agent: 6.5.0
       tmp: 0.1.0
       uuid: 8.3.2
       yargs: 15.4.1
@@ -3871,12 +3972,12 @@ snapshots:
       - supports-color
       - utf-8-validate
 
-  '@lhci/utils@0.13.0':
+  '@lhci/utils@0.14.0':
     dependencies:
-      debug: 4.3.5
+      debug: 4.4.0
       isomorphic-fetch: 3.0.0
       js-yaml: 3.14.1
-      lighthouse: 11.4.0
+      lighthouse: 12.1.0
       tree-kill: 1.2.2
     transitivePeerDependencies:
       - bufferutil
@@ -3894,52 +3995,115 @@ snapshots:
   '@nodelib/fs.walk@1.2.8':
     dependencies:
       '@nodelib/fs.scandir': 2.1.5
-      fastq: 1.17.1
+      fastq: 1.18.0
+
+  '@parcel/watcher-android-arm64@2.5.0':
+    optional: true
+
+  '@parcel/watcher-darwin-arm64@2.5.0':
+    optional: true
+
+  '@parcel/watcher-darwin-x64@2.5.0':
+    optional: true
 
-  '@percy/cli-app@1.28.8':
+  '@parcel/watcher-freebsd-x64@2.5.0':
+    optional: true
+
+  '@parcel/watcher-linux-arm-glibc@2.5.0':
+    optional: true
+
+  '@parcel/watcher-linux-arm-musl@2.5.0':
+    optional: true
+
+  '@parcel/watcher-linux-arm64-glibc@2.5.0':
+    optional: true
+
+  '@parcel/watcher-linux-arm64-musl@2.5.0':
+    optional: true
+
+  '@parcel/watcher-linux-x64-glibc@2.5.0':
+    optional: true
+
+  '@parcel/watcher-linux-x64-musl@2.5.0':
+    optional: true
+
+  '@parcel/watcher-win32-arm64@2.5.0':
+    optional: true
+
+  '@parcel/watcher-win32-ia32@2.5.0':
+    optional: true
+
+  '@parcel/watcher-win32-x64@2.5.0':
+    optional: true
+
+  '@parcel/watcher@2.5.0':
     dependencies:
-      '@percy/cli-command': 1.28.8
-      '@percy/cli-exec': 1.28.8
+      detect-libc: 1.0.3
+      is-glob: 4.0.3
+      micromatch: 4.0.8
+      node-addon-api: 7.1.1
+    optionalDependencies:
+      '@parcel/watcher-android-arm64': 2.5.0
+      '@parcel/watcher-darwin-arm64': 2.5.0
+      '@parcel/watcher-darwin-x64': 2.5.0
+      '@parcel/watcher-freebsd-x64': 2.5.0
+      '@parcel/watcher-linux-arm-glibc': 2.5.0
+      '@parcel/watcher-linux-arm-musl': 2.5.0
+      '@parcel/watcher-linux-arm64-glibc': 2.5.0
+      '@parcel/watcher-linux-arm64-musl': 2.5.0
+      '@parcel/watcher-linux-x64-glibc': 2.5.0
+      '@parcel/watcher-linux-x64-musl': 2.5.0
+      '@parcel/watcher-win32-arm64': 2.5.0
+      '@parcel/watcher-win32-ia32': 2.5.0
+      '@parcel/watcher-win32-x64': 2.5.0
+    optional: true
+
+  '@paulirish/trace_engine@0.0.23': {}
+
+  '@percy/cli-app@1.30.6':
+    dependencies:
+      '@percy/cli-command': 1.30.6
+      '@percy/cli-exec': 1.30.6
     transitivePeerDependencies:
       - bufferutil
       - supports-color
       - typescript
       - utf-8-validate
 
-  '@percy/cli-build@1.28.8':
+  '@percy/cli-build@1.30.6':
     dependencies:
-      '@percy/cli-command': 1.28.8
+      '@percy/cli-command': 1.30.6
     transitivePeerDependencies:
       - bufferutil
       - supports-color
       - typescript
       - utf-8-validate
 
-  '@percy/cli-command@1.28.8':
+  '@percy/cli-command@1.30.6':
     dependencies:
-      '@percy/config': 1.28.8
-      '@percy/core': 1.28.8
-      '@percy/logger': 1.28.8
+      '@percy/config': 1.30.6
+      '@percy/core': 1.30.6
+      '@percy/logger': 1.30.6
     transitivePeerDependencies:
       - bufferutil
       - supports-color
       - typescript
       - utf-8-validate
 
-  '@percy/cli-config@1.28.8':
+  '@percy/cli-config@1.30.6':
     dependencies:
-      '@percy/cli-command': 1.28.8
+      '@percy/cli-command': 1.30.6
     transitivePeerDependencies:
       - bufferutil
       - supports-color
       - typescript
       - utf-8-validate
 
-  '@percy/cli-exec@1.28.8':
+  '@percy/cli-exec@1.30.6':
     dependencies:
-      '@percy/cli-command': 1.28.8
-      '@percy/logger': 1.28.8
-      cross-spawn: 7.0.3
+      '@percy/cli-command': 1.30.6
+      '@percy/logger': 1.30.6
+      cross-spawn: 7.0.6
       which: 2.0.2
     transitivePeerDependencies:
       - bufferutil
@@ -3947,112 +4111,110 @@ snapshots:
       - typescript
       - utf-8-validate
 
-  '@percy/cli-snapshot@1.28.8':
+  '@percy/cli-snapshot@1.30.6':
     dependencies:
-      '@percy/cli-command': 1.28.8
-      yaml: 2.4.5
+      '@percy/cli-command': 1.30.6
+      yaml: 2.7.0
     transitivePeerDependencies:
       - bufferutil
       - supports-color
       - typescript
       - utf-8-validate
 
-  '@percy/cli-upload@1.28.8':
+  '@percy/cli-upload@1.30.6':
     dependencies:
-      '@percy/cli-command': 1.28.8
-      fast-glob: 3.3.2
-      image-size: 1.1.1
+      '@percy/cli-command': 1.30.6
+      fast-glob: 3.3.3
+      image-size: 1.2.0
     transitivePeerDependencies:
       - bufferutil
       - supports-color
       - typescript
       - utf-8-validate
 
-  '@percy/cli@1.28.8':
-    dependencies:
-      '@percy/cli-app': 1.28.8
-      '@percy/cli-build': 1.28.8
-      '@percy/cli-command': 1.28.8
-      '@percy/cli-config': 1.28.8
-      '@percy/cli-exec': 1.28.8
-      '@percy/cli-snapshot': 1.28.8
-      '@percy/cli-upload': 1.28.8
-      '@percy/client': 1.28.8
-      '@percy/logger': 1.28.8
+  '@percy/cli@1.30.6':
+    dependencies:
+      '@percy/cli-app': 1.30.6
+      '@percy/cli-build': 1.30.6
+      '@percy/cli-command': 1.30.6
+      '@percy/cli-config': 1.30.6
+      '@percy/cli-exec': 1.30.6
+      '@percy/cli-snapshot': 1.30.6
+      '@percy/cli-upload': 1.30.6
+      '@percy/client': 1.30.6
+      '@percy/logger': 1.30.6
     transitivePeerDependencies:
       - bufferutil
       - supports-color
       - typescript
       - utf-8-validate
 
-  '@percy/client@1.28.8':
+  '@percy/client@1.30.6':
     dependencies:
-      '@percy/env': 1.28.8
-      '@percy/logger': 1.28.8
+      '@percy/env': 1.30.6
+      '@percy/logger': 1.30.6
       pako: 2.1.0
 
-  '@percy/config@1.28.8':
+  '@percy/config@1.30.6':
     dependencies:
-      '@percy/logger': 1.28.8
-      ajv: 8.16.0
+      '@percy/logger': 1.30.6
+      ajv: 8.17.1
       cosmiconfig: 8.3.6
-      yaml: 2.4.5
+      yaml: 2.7.0
     transitivePeerDependencies:
       - typescript
 
-  '@percy/core@1.28.8':
+  '@percy/core@1.30.6':
     dependencies:
-      '@percy/client': 1.28.8
-      '@percy/config': 1.28.8
-      '@percy/dom': 1.28.8
-      '@percy/logger': 1.28.8
-      '@percy/webdriver-utils': 1.28.8
+      '@percy/client': 1.30.6
+      '@percy/config': 1.30.6
+      '@percy/dom': 1.30.6
+      '@percy/logger': 1.30.6
+      '@percy/webdriver-utils': 1.30.6
       content-disposition: 0.5.4
-      cross-spawn: 7.0.3
+      cross-spawn: 7.0.6
       extract-zip: 2.0.1
-      fast-glob: 3.3.2
-      micromatch: 4.0.7
+      fast-glob: 3.3.3
+      micromatch: 4.0.8
       mime-types: 2.1.35
       pako: 2.1.0
-      path-to-regexp: 6.2.2
+      path-to-regexp: 6.3.0
       rimraf: 3.0.2
       ws: 8.18.0
-      yaml: 2.4.5
+      yaml: 2.7.0
     transitivePeerDependencies:
       - bufferutil
       - supports-color
       - typescript
       - utf-8-validate
 
-  '@percy/dom@1.28.8': {}
+  '@percy/dom@1.30.6': {}
 
-  '@percy/env@1.28.8':
+  '@percy/env@1.30.6':
     dependencies:
-      '@percy/logger': 1.28.8
+      '@percy/logger': 1.30.6
 
-  '@percy/logger@1.28.8': {}
+  '@percy/logger@1.30.6': {}
 
-  '@percy/sdk-utils@1.28.8': {}
+  '@percy/sdk-utils@1.30.6': {}
 
-  '@percy/webdriver-utils@1.28.8':
+  '@percy/webdriver-utils@1.30.6':
     dependencies:
-      '@percy/config': 1.28.8
-      '@percy/sdk-utils': 1.28.8
+      '@percy/config': 1.30.6
+      '@percy/sdk-utils': 1.30.6
     transitivePeerDependencies:
       - typescript
 
-  '@pkgjs/parseargs@0.11.0':
-    optional: true
-
   '@pkgr/core@0.1.1': {}
 
-  '@puppeteer/browsers@1.9.1':
+  '@puppeteer/browsers@2.3.0':
     dependencies:
-      debug: 4.3.4
+      debug: 4.4.0
       extract-zip: 2.0.1
       progress: 2.0.3
-      proxy-agent: 6.3.1
-      tar-fs: 3.0.4
+      proxy-agent: 6.5.0
+      semver: 7.6.3
+      tar-fs: 3.0.7
       unbzip2-stream: 1.4.3
       yargs: 17.7.2
     transitivePeerDependencies:
@@ -4063,127 +4225,128 @@ snapshots:
       array-flat-polyfill: 1.0.1
       sitemap: 6.4.0
 
-  '@rollup/plugin-commonjs@26.0.1(rollup@4.18.0)':
+  '@rgrove/parse-xml@4.2.0': {}
+
+  '@rollup/plugin-commonjs@28.0.2(rollup@4.30.1)':
     dependencies:
-      '@rollup/pluginutils': 5.1.0(rollup@4.18.0)
+      '@rollup/pluginutils': 5.1.4(rollup@4.30.1)
       commondir: 1.0.1
       estree-walker: 2.0.2
-      glob: 10.4.3
+      fdir: 6.4.2(picomatch@4.0.2)
       is-reference: 1.2.1
-      magic-string: 0.30.10
+      magic-string: 0.30.17
+      picomatch: 4.0.2
     optionalDependencies:
-      rollup: 4.18.0
+      rollup: 4.30.1
 
-  '@rollup/plugin-node-resolve@15.2.3(rollup@4.18.0)':
+  '@rollup/plugin-node-resolve@16.0.0(rollup@4.30.1)':
     dependencies:
-      '@rollup/pluginutils': 5.1.0(rollup@4.18.0)
+      '@rollup/pluginutils': 5.1.4(rollup@4.30.1)
       '@types/resolve': 1.20.2
       deepmerge: 4.3.1
-      is-builtin-module: 3.2.1
       is-module: 1.0.0
-      resolve: 1.22.8
+      resolve: 1.22.10
     optionalDependencies:
-      rollup: 4.18.0
+      rollup: 4.30.1
 
-  '@rollup/plugin-terser@0.4.4(rollup@4.18.0)':
+  '@rollup/plugin-terser@0.4.4(rollup@4.30.1)':
     dependencies:
       serialize-javascript: 6.0.2
       smob: 1.5.0
-      terser: 5.31.1
+      terser: 5.37.0
     optionalDependencies:
-      rollup: 4.18.0
+      rollup: 4.30.1
 
-  '@rollup/pluginutils@5.1.0(rollup@4.18.0)':
+  '@rollup/pluginutils@5.1.4(rollup@4.30.1)':
     dependencies:
-      '@types/estree': 1.0.5
+      '@types/estree': 1.0.6
       estree-walker: 2.0.2
-      picomatch: 2.3.1
+      picomatch: 4.0.2
     optionalDependencies:
-      rollup: 4.18.0
+      rollup: 4.30.1
+
+  '@rollup/rollup-android-arm-eabi@4.30.1':
+    optional: true
+
+  '@rollup/rollup-android-arm64@4.30.1':
+    optional: true
 
-  '@rollup/rollup-android-arm-eabi@4.18.0':
+  '@rollup/rollup-darwin-arm64@4.30.1':
     optional: true
 
-  '@rollup/rollup-android-arm64@4.18.0':
+  '@rollup/rollup-darwin-x64@4.30.1':
     optional: true
 
-  '@rollup/rollup-darwin-arm64@4.18.0':
+  '@rollup/rollup-freebsd-arm64@4.30.1':
     optional: true
 
-  '@rollup/rollup-darwin-x64@4.18.0':
+  '@rollup/rollup-freebsd-x64@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-arm-gnueabihf@4.18.0':
+  '@rollup/rollup-linux-arm-gnueabihf@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-arm-musleabihf@4.18.0':
+  '@rollup/rollup-linux-arm-musleabihf@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-arm64-gnu@4.18.0':
+  '@rollup/rollup-linux-arm64-gnu@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-arm64-musl@4.18.0':
+  '@rollup/rollup-linux-arm64-musl@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-powerpc64le-gnu@4.18.0':
+  '@rollup/rollup-linux-loongarch64-gnu@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-riscv64-gnu@4.18.0':
+  '@rollup/rollup-linux-powerpc64le-gnu@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-s390x-gnu@4.18.0':
+  '@rollup/rollup-linux-riscv64-gnu@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-x64-gnu@4.18.0':
+  '@rollup/rollup-linux-s390x-gnu@4.30.1':
     optional: true
 
-  '@rollup/rollup-linux-x64-musl@4.18.0':
+  '@rollup/rollup-linux-x64-gnu@4.30.1':
     optional: true
 
-  '@rollup/rollup-win32-arm64-msvc@4.18.0':
+  '@rollup/rollup-linux-x64-musl@4.30.1':
     optional: true
 
-  '@rollup/rollup-win32-ia32-msvc@4.18.0':
+  '@rollup/rollup-win32-arm64-msvc@4.30.1':
     optional: true
 
-  '@rollup/rollup-win32-x64-msvc@4.18.0':
+  '@rollup/rollup-win32-ia32-msvc@4.30.1':
     optional: true
 
-  '@sentry-internal/browser-utils@8.15.0':
+  '@rollup/rollup-win32-x64-msvc@4.30.1':
+    optional: true
+
+  '@sentry-internal/browser-utils@8.48.0':
     dependencies:
-      '@sentry/core': 8.15.0
-      '@sentry/types': 8.15.0
-      '@sentry/utils': 8.15.0
+      '@sentry/core': 8.48.0
 
-  '@sentry-internal/feedback@8.15.0':
+  '@sentry-internal/feedback@8.48.0':
     dependencies:
-      '@sentry/core': 8.15.0
-      '@sentry/types': 8.15.0
-      '@sentry/utils': 8.15.0
+      '@sentry/core': 8.48.0
 
-  '@sentry-internal/replay-canvas@8.15.0':
+  '@sentry-internal/replay-canvas@8.48.0':
     dependencies:
-      '@sentry-internal/replay': 8.15.0
-      '@sentry/core': 8.15.0
-      '@sentry/types': 8.15.0
-      '@sentry/utils': 8.15.0
+      '@sentry-internal/replay': 8.48.0
+      '@sentry/core': 8.48.0
 
-  '@sentry-internal/replay@8.15.0':
+  '@sentry-internal/replay@8.48.0':
     dependencies:
-      '@sentry-internal/browser-utils': 8.15.0
-      '@sentry/core': 8.15.0
-      '@sentry/types': 8.15.0
-      '@sentry/utils': 8.15.0
+      '@sentry-internal/browser-utils': 8.48.0
+      '@sentry/core': 8.48.0
 
-  '@sentry/browser@8.15.0':
+  '@sentry/browser@8.48.0':
     dependencies:
-      '@sentry-internal/browser-utils': 8.15.0
-      '@sentry-internal/feedback': 8.15.0
-      '@sentry-internal/replay': 8.15.0
-      '@sentry-internal/replay-canvas': 8.15.0
-      '@sentry/core': 8.15.0
-      '@sentry/types': 8.15.0
-      '@sentry/utils': 8.15.0
+      '@sentry-internal/browser-utils': 8.48.0
+      '@sentry-internal/feedback': 8.48.0
+      '@sentry-internal/replay': 8.48.0
+      '@sentry-internal/replay-canvas': 8.48.0
+      '@sentry/core': 8.48.0
 
   '@sentry/core@6.19.7':
     dependencies:
@@ -4193,10 +4356,7 @@ snapshots:
       '@sentry/utils': 6.19.7
       tslib: 1.14.1
 
-  '@sentry/core@8.15.0':
-    dependencies:
-      '@sentry/types': 8.15.0
-      '@sentry/utils': 8.15.0
+  '@sentry/core@8.48.0': {}
 
   '@sentry/hub@6.19.7':
     dependencies:
@@ -4225,17 +4385,11 @@ snapshots:
 
   '@sentry/types@6.19.7': {}
 
-  '@sentry/types@8.15.0': {}
-
   '@sentry/utils@6.19.7':
     dependencies:
       '@sentry/types': 6.19.7
       tslib: 1.14.1
 
-  '@sentry/utils@8.15.0':
-    dependencies:
-      '@sentry/types': 8.15.0
-
   '@sindresorhus/slugify@1.1.2':
     dependencies:
       '@sindresorhus/transliterate': 0.1.2
@@ -4259,7 +4413,7 @@ snapshots:
       escodegen: 1.14.3
       html-encoding-sniffer: 1.0.2
       is-potential-custom-element-name: 1.0.1
-      nwsapi: 2.2.10
+      nwsapi: 2.2.16
       parse5: 5.1.0
       pn: 1.1.0
       request: 2.88.2
@@ -4283,15 +4437,17 @@ snapshots:
 
   '@trysound/sax@0.2.0': {}
 
-  '@types/estree@1.0.5': {}
+  '@types/estree@1.0.6': {}
+
+  '@types/json-schema@7.0.15': {}
 
   '@types/minimatch@3.0.5': {}
 
   '@types/node@14.18.63': {}
 
-  '@types/node@20.14.10':
+  '@types/node@22.10.5':
     dependencies:
-      undici-types: 5.26.5
+      undici-types: 6.20.0
 
   '@types/resolve@1.20.2': {}
 
@@ -4301,7 +4457,7 @@ snapshots:
 
   '@types/yauzl@2.10.3':
     dependencies:
-      '@types/node': 20.14.10
+      '@types/node': 22.10.5
     optional: true
 
   a-sync-waterfall@1.0.1: {}
@@ -4320,9 +4476,9 @@ snapshots:
       acorn: 6.4.2
       acorn-walk: 6.2.0
 
-  acorn-jsx@5.3.2(acorn@8.12.1):
+  acorn-jsx@5.3.2(acorn@8.14.0):
     dependencies:
-      acorn: 8.12.1
+      acorn: 8.14.0
 
   acorn-walk@6.2.0: {}
 
@@ -4330,19 +4486,15 @@ snapshots:
 
   acorn@7.4.1: {}
 
-  acorn@8.12.1: {}
+  acorn@8.14.0: {}
 
   agent-base@6.0.2:
     dependencies:
-      debug: 4.3.5
+      debug: 4.4.0
     transitivePeerDependencies:
       - supports-color
 
-  agent-base@7.1.1:
-    dependencies:
-      debug: 4.3.5
-    transitivePeerDependencies:
-      - supports-color
+  agent-base@7.1.3: {}
 
   ajv@6.12.6:
     dependencies:
@@ -4351,12 +4503,12 @@ snapshots:
       json-schema-traverse: 0.4.1
       uri-js: 4.4.1
 
-  ajv@8.16.0:
+  ajv@8.17.1:
     dependencies:
       fast-deep-equal: 3.1.3
+      fast-uri: 3.0.5
       json-schema-traverse: 1.0.0
       require-from-string: 2.0.2
-      uri-js: 4.4.1
 
   ansi-colors@4.1.3: {}
 
@@ -4372,8 +4524,6 @@ snapshots:
 
   ansi-regex@5.0.1: {}
 
-  ansi-regex@6.0.1: {}
-
   ansi-styles@1.1.0: {}
 
   ansi-styles@2.2.1: {}
@@ -4431,35 +4581,55 @@ snapshots:
     dependencies:
       safer-buffer: 2.1.2
 
-  assert-never@1.3.0: {}
+  assert-never@1.4.0: {}
 
   assert-plus@1.0.0: {}
 
   ast-types@0.13.4:
     dependencies:
-      tslib: 2.6.3
+      tslib: 2.8.1
 
   async-limiter@1.0.1: {}
 
-  async@3.2.5: {}
+  async@3.2.6: {}
 
   asynckit@0.4.0: {}
 
   aws-sign2@0.7.0: {}
 
-  aws4@1.13.0: {}
+  aws4@1.13.2: {}
 
-  axe-core@4.9.1: {}
+  axe-core@4.10.2: {}
 
-  b4a@1.6.6: {}
+  b4a@1.6.7: {}
 
   babel-walk@3.0.0-canary-5:
     dependencies:
-      '@babel/types': 7.24.7
+      '@babel/types': 7.26.5
 
   balanced-match@1.0.2: {}
 
-  bare-events@2.4.2:
+  bare-events@2.5.4:
+    optional: true
+
+  bare-fs@2.3.5:
+    dependencies:
+      bare-events: 2.5.4
+      bare-path: 2.1.3
+      bare-stream: 2.6.1
+    optional: true
+
+  bare-os@2.4.4:
+    optional: true
+
+  bare-path@2.1.3:
+    dependencies:
+      bare-os: 2.4.4
+    optional: true
+
+  bare-stream@2.6.1:
+    dependencies:
+      streamx: 2.21.1
     optional: true
 
   base64-js@1.5.1: {}
@@ -4506,7 +4676,7 @@ snapshots:
 
   bluebird@2.11.0: {}
 
-  body-parser@1.20.2:
+  body-parser@1.20.3:
     dependencies:
       bytes: 3.1.2
       content-type: 1.0.5
@@ -4516,7 +4686,7 @@ snapshots:
       http-errors: 2.0.0
       iconv-lite: 0.4.24
       on-finished: 2.4.1
-      qs: 6.11.0
+      qs: 6.13.0
       raw-body: 2.5.2
       type-is: 1.6.18
       unpipe: 1.0.0
@@ -4551,7 +4721,7 @@ snapshots:
       http-equiv-refresh: 1.0.0
       humanize-duration: 3.32.1
       is-stream: 1.1.0
-      is-string: 1.0.7
+      is-string: 1.1.1
       limited-request-queue: 2.0.0
       link-types: 1.1.0
       maybe-callback: 2.1.0
@@ -4580,19 +4750,27 @@ snapshots:
       base64-js: 1.5.1
       ieee754: 1.2.1
 
-  builtin-modules@3.3.0: {}
-
-  bytes@3.0.0: {}
+  buffer@6.0.3:
+    dependencies:
+      base64-js: 1.5.1
+      ieee754: 1.2.1
 
   bytes@3.1.2: {}
 
-  call-bind@1.0.7:
+  cacheable@1.8.7:
+    dependencies:
+      hookified: 1.6.0
+      keyv: 5.2.3
+
+  call-bind-apply-helpers@1.0.1:
     dependencies:
-      es-define-property: 1.0.0
       es-errors: 1.3.0
       function-bind: 1.1.2
-      get-intrinsic: 1.2.4
-      set-function-length: 1.2.2
+
+  call-bound@1.0.3:
+    dependencies:
+      call-bind-apply-helpers: 1.0.1
+      get-intrinsic: 1.2.7
 
   caller-path@0.1.0:
     dependencies:
@@ -4646,7 +4824,7 @@ snapshots:
 
   character-parser@2.2.0:
     dependencies:
-      is-regex: 1.1.4
+      is-regex: 1.2.1
 
   chardet@0.7.0: {}
 
@@ -4662,9 +4840,13 @@ snapshots:
     optionalDependencies:
       fsevents: 2.3.3
 
+  chokidar@4.0.3:
+    dependencies:
+      readdirp: 4.1.1
+
   chrome-launcher@0.13.4:
     dependencies:
-      '@types/node': 20.14.10
+      '@types/node': 22.10.5
       escape-string-regexp: 1.0.5
       is-wsl: 2.2.0
       lighthouse-logger: 1.2.0
@@ -4675,18 +4857,19 @@ snapshots:
 
   chrome-launcher@1.1.2:
     dependencies:
-      '@types/node': 20.14.10
+      '@types/node': 22.10.5
       escape-string-regexp: 4.0.0
       is-wsl: 2.2.0
       lighthouse-logger: 2.0.1
     transitivePeerDependencies:
       - supports-color
 
-  chromium-bidi@0.5.8(devtools-protocol@0.0.1232444):
+  chromium-bidi@0.6.3(devtools-protocol@0.0.1312386):
     dependencies:
-      devtools-protocol: 0.0.1232444
+      devtools-protocol: 0.0.1312386
       mitt: 3.0.1
       urlpattern-polyfill: 10.0.0
+      zod: 3.23.8
 
   clean-css@4.2.4:
     dependencies:
@@ -4764,16 +4947,16 @@ snapshots:
 
   compressible@2.0.18:
     dependencies:
-      mime-db: 1.52.0
+      mime-db: 1.53.0
 
-  compression@1.7.4:
+  compression@1.7.5:
     dependencies:
-      accepts: 1.3.8
-      bytes: 3.0.0
+      bytes: 3.1.2
       compressible: 2.0.18
       debug: 2.6.9
+      negotiator: 0.6.4
       on-headers: 1.0.2
-      safe-buffer: 5.1.2
+      safe-buffer: 5.2.1
       vary: 1.1.2
     transitivePeerDependencies:
       - supports-color
@@ -4800,8 +4983,8 @@ snapshots:
 
   constantinople@4.0.1:
     dependencies:
-      '@babel/parser': 7.24.7
-      '@babel/types': 7.24.7
+      '@babel/parser': 7.26.5
+      '@babel/types': 7.26.5
 
   content-disposition@0.5.4:
     dependencies:
@@ -4813,7 +4996,7 @@ snapshots:
 
   cookie@0.4.2: {}
 
-  cookie@0.6.0: {}
+  cookie@0.7.1: {}
 
   core-util-is@1.0.2: {}
 
@@ -4828,15 +5011,9 @@ snapshots:
 
   cross-env@7.0.3:
     dependencies:
-      cross-spawn: 7.0.3
+      cross-spawn: 7.0.6
 
-  cross-fetch@4.0.0:
-    dependencies:
-      node-fetch: 2.7.0
-    transitivePeerDependencies:
-      - encoding
-
-  cross-spawn@7.0.3:
+  cross-spawn@7.0.6:
     dependencies:
       path-key: 3.1.1
       shebang-command: 2.0.0
@@ -4851,18 +5028,18 @@ snapshots:
       boolbase: 1.0.0
       css-what: 6.1.0
       domhandler: 5.0.3
-      domutils: 3.1.0
+      domutils: 3.2.2
       nth-check: 2.1.1
 
   css-tree@2.2.1:
     dependencies:
       mdn-data: 2.0.28
-      source-map-js: 1.2.0
+      source-map-js: 1.2.1
 
   css-tree@2.3.1:
     dependencies:
       mdn-data: 2.0.30
-      source-map-js: 1.2.0
+      source-map-js: 1.2.1
 
   css-what@6.1.0: {}
 
@@ -4888,22 +5065,20 @@ snapshots:
       whatwg-mimetype: 2.3.0
       whatwg-url: 7.1.0
 
-  dayjs@1.11.11: {}
+  dayjs@1.11.13: {}
 
   debug@2.6.9:
     dependencies:
       ms: 2.0.0
 
-  debug@4.3.4:
-    dependencies:
-      ms: 2.1.2
-
-  debug@4.3.5:
+  debug@4.4.0:
     dependencies:
-      ms: 2.1.2
+      ms: 2.1.3
 
   decamelize@1.2.0: {}
 
+  decimal.js@10.4.3: {}
+
   deep-is@0.1.4: {}
 
   deepmerge@4.3.1: {}
@@ -4912,12 +5087,6 @@ snapshots:
     dependencies:
       os-name: 1.0.3
 
-  define-data-property@1.1.4:
-    dependencies:
-      es-define-property: 1.0.0
-      es-errors: 1.3.0
-      gopd: 1.0.1
-
   define-lazy-prop@2.0.0: {}
 
   degenerator@5.0.1:
@@ -4934,15 +5103,16 @@ snapshots:
 
   destroy@1.2.0: {}
 
+  detect-libc@1.0.3:
+    optional: true
+
   detect-libc@2.0.3: {}
 
   dev-ip@1.0.1: {}
 
   dev-null@0.1.1: {}
 
-  devtools-protocol@0.0.1211954: {}
-
-  devtools-protocol@0.0.1232444: {}
+  devtools-protocol@0.0.1312386: {}
 
   doctypes@1.1.0: {}
 
@@ -4978,7 +5148,7 @@ snapshots:
       domelementtype: 2.3.0
       domhandler: 4.3.1
 
-  domutils@3.1.0:
+  domutils@3.2.2:
     dependencies:
       dom-serializer: 2.0.0
       domelementtype: 2.3.0
@@ -4988,12 +5158,16 @@ snapshots:
     dependencies:
       is-obj: 2.0.0
 
+  dunder-proto@1.0.1:
+    dependencies:
+      call-bind-apply-helpers: 1.0.1
+      es-errors: 1.3.0
+      gopd: 1.2.0
+
   duplexer@0.1.1: {}
 
   duplexer@0.1.2: {}
 
-  eastasianwidth@0.2.0: {}
-
   ecc-jsbn@0.1.2:
     dependencies:
       jsbn: 0.1.1
@@ -5003,19 +5177,19 @@ snapshots:
 
   ejs@3.1.10:
     dependencies:
-      jake: 10.9.1
+      jake: 10.9.2
 
   emoji-regex@8.0.0: {}
 
-  emoji-regex@9.2.2: {}
-
   encodeurl@1.0.2: {}
 
+  encodeurl@2.0.0: {}
+
   end-of-stream@1.4.4:
     dependencies:
       once: 1.4.0
 
-  enhanced-resolve@5.17.0:
+  enhanced-resolve@5.18.0:
     dependencies:
       graceful-fs: 4.2.11
       tapable: 2.2.1
@@ -5031,6 +5205,8 @@ snapshots:
 
   entities@4.5.0: {}
 
+  entities@6.0.0: {}
+
   eol@0.2.0: {}
 
   errno@0.1.8:
@@ -5043,13 +5219,15 @@ snapshots:
 
   errors@0.2.0: {}
 
-  es-define-property@1.0.0:
-    dependencies:
-      get-intrinsic: 1.2.4
+  es-define-property@1.0.1: {}
 
   es-errors@1.3.0: {}
 
-  escalade@3.1.2: {}
+  es-object-atoms@1.0.0:
+    dependencies:
+      es-errors: 1.3.0
+
+  escalade@3.2.0: {}
 
   escape-html@1.0.3: {}
 
@@ -5076,100 +5254,100 @@ snapshots:
     optionalDependencies:
       source-map: 0.6.1
 
-  eslint-compat-utils@0.5.1(eslint@9.6.0):
+  eslint-compat-utils@0.5.1(eslint@9.18.0):
     dependencies:
-      eslint: 9.6.0
-      semver: 7.6.2
+      eslint: 9.18.0
+      semver: 7.6.3
 
-  eslint-config-prettier@9.1.0(eslint@9.6.0):
+  eslint-config-prettier@10.0.1(eslint@9.18.0):
     dependencies:
-      eslint: 9.6.0
+      eslint: 9.18.0
 
-  eslint-plugin-es-x@7.8.0(eslint@9.6.0):
+  eslint-plugin-es-x@7.8.0(eslint@9.18.0):
     dependencies:
-      '@eslint-community/eslint-utils': 4.4.0(eslint@9.6.0)
-      '@eslint-community/regexpp': 4.11.0
-      eslint: 9.6.0
-      eslint-compat-utils: 0.5.1(eslint@9.6.0)
+      '@eslint-community/eslint-utils': 4.4.1(eslint@9.18.0)
+      '@eslint-community/regexpp': 4.12.1
+      eslint: 9.18.0
+      eslint-compat-utils: 0.5.1(eslint@9.18.0)
 
-  eslint-plugin-n@17.9.0(eslint@9.6.0):
+  eslint-plugin-n@17.15.1(eslint@9.18.0):
     dependencies:
-      '@eslint-community/eslint-utils': 4.4.0(eslint@9.6.0)
-      enhanced-resolve: 5.17.0
-      eslint: 9.6.0
-      eslint-plugin-es-x: 7.8.0(eslint@9.6.0)
-      get-tsconfig: 4.7.5
-      globals: 15.8.0
-      ignore: 5.3.1
+      '@eslint-community/eslint-utils': 4.4.1(eslint@9.18.0)
+      enhanced-resolve: 5.18.0
+      eslint: 9.18.0
+      eslint-plugin-es-x: 7.8.0(eslint@9.18.0)
+      get-tsconfig: 4.8.1
+      globals: 15.14.0
+      ignore: 5.3.2
       minimatch: 9.0.5
-      semver: 7.6.2
+      semver: 7.6.3
 
-  eslint-plugin-prettier@5.1.3(eslint-config-prettier@9.1.0(eslint@9.6.0))(eslint@9.6.0)(prettier@3.2.5):
+  eslint-plugin-prettier@5.2.1(eslint-config-prettier@10.0.1(eslint@9.18.0))(eslint@9.18.0)(prettier@3.4.2):
     dependencies:
-      eslint: 9.6.0
-      prettier: 3.2.5
+      eslint: 9.18.0
+      prettier: 3.4.2
       prettier-linter-helpers: 1.0.0
-      synckit: 0.8.8
+      synckit: 0.9.2
     optionalDependencies:
-      eslint-config-prettier: 9.1.0(eslint@9.6.0)
+      eslint-config-prettier: 10.0.1(eslint@9.18.0)
 
-  eslint-scope@8.0.1:
+  eslint-scope@8.2.0:
     dependencies:
       esrecurse: 4.3.0
       estraverse: 5.3.0
 
   eslint-visitor-keys@3.4.3: {}
 
-  eslint-visitor-keys@4.0.0: {}
+  eslint-visitor-keys@4.2.0: {}
 
-  eslint@9.6.0:
+  eslint@9.18.0:
     dependencies:
-      '@eslint-community/eslint-utils': 4.4.0(eslint@9.6.0)
-      '@eslint-community/regexpp': 4.11.0
-      '@eslint/config-array': 0.17.0
-      '@eslint/eslintrc': 3.1.0
-      '@eslint/js': 9.6.0
+      '@eslint-community/eslint-utils': 4.4.1(eslint@9.18.0)
+      '@eslint-community/regexpp': 4.12.1
+      '@eslint/config-array': 0.19.1
+      '@eslint/core': 0.10.0
+      '@eslint/eslintrc': 3.2.0
+      '@eslint/js': 9.18.0
+      '@eslint/plugin-kit': 0.2.5
+      '@humanfs/node': 0.16.6
       '@humanwhocodes/module-importer': 1.0.1
-      '@humanwhocodes/retry': 0.3.0
-      '@nodelib/fs.walk': 1.2.8
+      '@humanwhocodes/retry': 0.4.1
+      '@types/estree': 1.0.6
+      '@types/json-schema': 7.0.15
       ajv: 6.12.6
       chalk: 4.1.2
-      cross-spawn: 7.0.3
-      debug: 4.3.5
+      cross-spawn: 7.0.6
+      debug: 4.4.0
       escape-string-regexp: 4.0.0
-      eslint-scope: 8.0.1
-      eslint-visitor-keys: 4.0.0
-      espree: 10.1.0
-      esquery: 1.5.0
+      eslint-scope: 8.2.0
+      eslint-visitor-keys: 4.2.0
+      espree: 10.3.0
+      esquery: 1.6.0
       esutils: 2.0.3
       fast-deep-equal: 3.1.3
       file-entry-cache: 8.0.0
       find-up: 5.0.0
       glob-parent: 6.0.2
-      ignore: 5.3.1
+      ignore: 5.3.2
       imurmurhash: 0.1.4
       is-glob: 4.0.3
-      is-path-inside: 3.0.3
       json-stable-stringify-without-jsonify: 1.0.1
-      levn: 0.4.1
       lodash.merge: 4.6.2
       minimatch: 3.1.2
       natural-compare: 1.4.0
       optionator: 0.9.4
-      strip-ansi: 6.0.1
-      text-table: 0.2.0
     transitivePeerDependencies:
       - supports-color
 
-  espree@10.1.0:
+  espree@10.3.0:
     dependencies:
-      acorn: 8.12.1
-      acorn-jsx: 5.3.2(acorn@8.12.1)
-      eslint-visitor-keys: 4.0.0
+      acorn: 8.14.0
+      acorn-jsx: 5.3.2(acorn@8.14.0)
+      eslint-visitor-keys: 4.2.0
 
   esprima@4.0.1: {}
 
-  esquery@1.5.0:
+  esquery@1.6.0:
     dependencies:
       estraverse: 5.3.0
 
@@ -5189,34 +5367,34 @@ snapshots:
 
   eventemitter3@4.0.7: {}
 
-  express@4.19.2:
+  express@4.21.2:
     dependencies:
       accepts: 1.3.8
       array-flatten: 1.1.1
-      body-parser: 1.20.2
+      body-parser: 1.20.3
       content-disposition: 0.5.4
       content-type: 1.0.5
-      cookie: 0.6.0
+      cookie: 0.7.1
       cookie-signature: 1.0.6
       debug: 2.6.9
       depd: 2.0.0
-      encodeurl: 1.0.2
+      encodeurl: 2.0.0
       escape-html: 1.0.3
       etag: 1.8.1
-      finalhandler: 1.2.0
+      finalhandler: 1.3.1
       fresh: 0.5.2
       http-errors: 2.0.0
-      merge-descriptors: 1.0.1
+      merge-descriptors: 1.0.3
       methods: 1.1.2
       on-finished: 2.4.1
       parseurl: 1.3.3
-      path-to-regexp: 0.1.7
+      path-to-regexp: 0.1.12
       proxy-addr: 2.0.7
-      qs: 6.11.0
+      qs: 6.13.0
       range-parser: 1.2.1
       safe-buffer: 5.2.1
-      send: 0.18.0
-      serve-static: 1.15.0
+      send: 0.19.0
+      serve-static: 1.16.2
       setprototypeof: 1.2.0
       statuses: 2.0.1
       type-is: 1.6.18
@@ -5241,7 +5419,7 @@ snapshots:
 
   extract-zip@2.0.1:
     dependencies:
-      debug: 4.3.5
+      debug: 4.4.0
       get-stream: 5.2.0
       yauzl: 2.10.0
     optionalDependencies:
@@ -5257,19 +5435,21 @@ snapshots:
 
   fast-fifo@1.3.2: {}
 
-  fast-glob@3.3.2:
+  fast-glob@3.3.3:
     dependencies:
       '@nodelib/fs.stat': 2.0.5
       '@nodelib/fs.walk': 1.2.8
       glob-parent: 5.1.2
       merge2: 1.4.1
-      micromatch: 4.0.7
+      micromatch: 4.0.8
 
   fast-json-stable-stringify@2.1.0: {}
 
   fast-levenshtein@2.0.6: {}
 
-  fastq@1.17.1:
+  fast-uri@3.0.5: {}
+
+  fastq@1.18.0:
     dependencies:
       reusify: 1.0.4
 
@@ -5277,6 +5457,10 @@ snapshots:
     dependencies:
       pend: 1.2.0
 
+  fdir@6.4.2(picomatch@4.0.2):
+    optionalDependencies:
+      picomatch: 4.0.2
+
   figures@2.0.0:
     dependencies:
       escape-string-regexp: 1.0.5
@@ -5293,10 +5477,10 @@ snapshots:
     dependencies:
       to-regex-range: 5.0.1
 
-  finalhandler@1.2.0:
+  finalhandler@1.3.1:
     dependencies:
       debug: 2.6.9
-      encodeurl: 1.0.2
+      encodeurl: 2.0.0
       escape-html: 1.0.3
       on-finished: 2.4.1
       parseurl: 1.3.3
@@ -5315,23 +5499,18 @@ snapshots:
       locate-path: 6.0.0
       path-exists: 4.0.0
 
-  flat-cache@3.2.0:
-    dependencies:
-      flatted: 3.3.1
-      keyv: 4.5.4
-      rimraf: 3.0.2
-
   flat-cache@4.0.1:
     dependencies:
-      flatted: 3.3.1
+      flatted: 3.3.2
       keyv: 4.5.4
 
-  flatted@3.3.1: {}
-
-  foreground-child@3.2.1:
+  flat-cache@6.1.5:
     dependencies:
-      cross-spawn: 7.0.3
-      signal-exit: 4.1.0
+      cacheable: 1.8.7
+      flatted: 3.3.2
+      hookified: 1.6.0
+
+  flatted@3.3.2: {}
 
   forever-agent@0.6.1: {}
 
@@ -5357,12 +5536,6 @@ snapshots:
 
   fresh@0.5.2: {}
 
-  fs-extra@11.2.0:
-    dependencies:
-      graceful-fs: 4.2.11
-      jsonfile: 6.1.0
-      universalify: 2.0.1
-
   fs.realpath@1.0.0: {}
 
   fsevents@2.3.3:
@@ -5372,28 +5545,37 @@ snapshots:
 
   get-caller-file@2.0.5: {}
 
-  get-intrinsic@1.2.4:
+  get-intrinsic@1.2.7:
     dependencies:
+      call-bind-apply-helpers: 1.0.1
+      es-define-property: 1.0.1
       es-errors: 1.3.0
+      es-object-atoms: 1.0.0
       function-bind: 1.1.2
-      has-proto: 1.0.3
-      has-symbols: 1.0.3
+      get-proto: 1.0.1
+      gopd: 1.2.0
+      has-symbols: 1.1.0
       hasown: 2.0.2
+      math-intrinsics: 1.1.0
+
+  get-proto@1.0.1:
+    dependencies:
+      dunder-proto: 1.0.1
+      es-object-atoms: 1.0.0
 
   get-stream@5.2.0:
     dependencies:
-      pump: 3.0.0
+      pump: 3.0.2
 
-  get-tsconfig@4.7.5:
+  get-tsconfig@4.8.1:
     dependencies:
       resolve-pkg-maps: 1.0.0
 
-  get-uri@6.0.3:
+  get-uri@6.0.4:
     dependencies:
       basic-ftp: 5.0.5
       data-uri-to-buffer: 6.0.2
-      debug: 4.3.5
-      fs-extra: 11.2.0
+      debug: 4.4.0
     transitivePeerDependencies:
       - supports-color
 
@@ -5409,15 +5591,6 @@ snapshots:
     dependencies:
       is-glob: 4.0.3
 
-  glob@10.4.3:
-    dependencies:
-      foreground-child: 3.2.1
-      jackspeak: 3.4.1
-      minimatch: 9.0.5
-      minipass: 7.1.2
-      package-json-from-dist: 1.0.0
-      path-scurry: 1.11.1
-
   glob@7.2.3:
     dependencies:
       fs.realpath: 1.0.0
@@ -5437,11 +5610,9 @@ snapshots:
 
   globals@14.0.0: {}
 
-  globals@15.8.0: {}
+  globals@15.14.0: {}
 
-  gopd@1.0.1:
-    dependencies:
-      get-intrinsic: 1.2.4
+  gopd@1.2.0: {}
 
   graceful-fs@4.2.11: {}
 
@@ -5463,7 +5634,7 @@ snapshots:
       source-map: 0.6.1
       wordwrap: 1.0.0
     optionalDependencies:
-      uglify-js: 3.18.0
+      uglify-js: 3.19.3
 
   har-schema@2.0.0: {}
 
@@ -5484,17 +5655,11 @@ snapshots:
 
   has-flag@4.0.0: {}
 
-  has-property-descriptors@1.0.2:
-    dependencies:
-      es-define-property: 1.0.0
-
-  has-proto@1.0.3: {}
-
-  has-symbols@1.0.3: {}
+  has-symbols@1.1.0: {}
 
   has-tostringtag@1.0.2:
     dependencies:
-      has-symbols: 1.0.3
+      has-symbols: 1.1.0
 
   hasown@2.0.2:
     dependencies:
@@ -5502,6 +5667,8 @@ snapshots:
 
   he@1.2.0: {}
 
+  hookified@1.6.0: {}
+
   html-encoding-sniffer@1.0.2:
     dependencies:
       whatwg-encoding: 1.0.5
@@ -5514,7 +5681,7 @@ snapshots:
       he: 1.2.0
       param-case: 2.1.1
       relateurl: 0.2.7
-      uglify-js: 3.18.0
+      uglify-js: 3.19.3
 
   htmlparser2@7.2.0:
     dependencies:
@@ -5537,8 +5704,8 @@ snapshots:
 
   http-proxy-agent@7.0.2:
     dependencies:
-      agent-base: 7.1.1
-      debug: 4.3.5
+      agent-base: 7.1.3
+      debug: 4.4.0
     transitivePeerDependencies:
       - supports-color
 
@@ -5551,14 +5718,14 @@ snapshots:
   https-proxy-agent@5.0.1:
     dependencies:
       agent-base: 6.0.2
-      debug: 4.3.5
+      debug: 4.4.0
     transitivePeerDependencies:
       - supports-color
 
-  https-proxy-agent@7.0.5:
+  https-proxy-agent@7.0.6:
     dependencies:
-      agent-base: 7.1.1
-      debug: 4.3.5
+      agent-base: 7.1.3
+      debug: 4.4.0
     transitivePeerDependencies:
       - supports-color
 
@@ -5570,15 +5737,15 @@ snapshots:
 
   ieee754@1.2.1: {}
 
-  ignore@5.3.1: {}
+  ignore@5.3.2: {}
 
-  image-size@1.1.1:
+  image-size@1.2.0:
     dependencies:
       queue: 6.0.2
 
   image-ssim@0.2.0: {}
 
-  immutable@4.3.6: {}
+  immutable@5.0.3: {}
 
   import-fresh@3.3.0:
     dependencies:
@@ -5610,12 +5777,12 @@ snapshots:
       strip-ansi: 5.2.0
       through: 2.3.8
 
-  intl-messageformat@10.5.14:
+  intl-messageformat@10.7.11:
     dependencies:
-      '@formatjs/ecma402-abstract': 2.0.0
-      '@formatjs/fast-memoize': 2.2.0
-      '@formatjs/icu-messageformat-parser': 2.7.8
-      tslib: 2.6.3
+      '@formatjs/ecma402-abstract': 2.3.2
+      '@formatjs/fast-memoize': 2.2.6
+      '@formatjs/icu-messageformat-parser': 2.9.8
+      tslib: 2.8.1
 
   ip-address@9.0.5:
     dependencies:
@@ -5641,11 +5808,7 @@ snapshots:
 
   is-browser@2.1.0: {}
 
-  is-builtin-module@3.2.1:
-    dependencies:
-      builtin-modules: 3.3.0
-
-  is-core-module@2.14.0:
+  is-core-module@2.16.1:
     dependencies:
       hasown: 2.0.2
 
@@ -5680,25 +5843,26 @@ snapshots:
 
   is-object@1.0.2: {}
 
-  is-path-inside@3.0.3: {}
-
   is-potential-custom-element-name@1.0.1: {}
 
   is-promise@2.2.2: {}
 
   is-reference@1.2.1:
     dependencies:
-      '@types/estree': 1.0.5
+      '@types/estree': 1.0.6
 
-  is-regex@1.1.4:
+  is-regex@1.2.1:
     dependencies:
-      call-bind: 1.0.7
+      call-bound: 1.0.3
+      gopd: 1.2.0
       has-tostringtag: 1.0.2
+      hasown: 2.0.2
 
   is-stream@1.1.0: {}
 
-  is-string@1.0.7:
+  is-string@1.1.1:
     dependencies:
+      call-bound: 1.0.3
       has-tostringtag: 1.0.2
 
   is-typedarray@1.0.0: {}
@@ -5715,6 +5879,8 @@ snapshots:
 
   isexe@2.0.0: {}
 
+  isexe@3.1.1: {}
+
   iso-639-1@2.1.15: {}
 
   isomorphic-fetch@3.0.0:
@@ -5726,15 +5892,9 @@ snapshots:
 
   isstream@0.1.2: {}
 
-  jackspeak@3.4.1:
+  jake@10.9.2:
     dependencies:
-      '@isaacs/cliui': 8.0.2
-    optionalDependencies:
-      '@pkgjs/parseargs': 0.11.0
-
-  jake@10.9.1:
-    dependencies:
-      async: 3.2.5
+      async: 3.2.6
       chalk: 4.1.2
       filelist: 1.0.4
       minimatch: 3.1.2
@@ -5764,7 +5924,7 @@ snapshots:
 
   json-parse-even-better-errors@2.3.1: {}
 
-  json-parse-even-better-errors@3.0.2: {}
+  json-parse-even-better-errors@4.0.0: {}
 
   json-schema-traverse@0.4.1: {}
 
@@ -5776,12 +5936,6 @@ snapshots:
 
   json-stringify-safe@5.0.1: {}
 
-  jsonfile@6.1.0:
-    dependencies:
-      universalify: 2.0.1
-    optionalDependencies:
-      graceful-fs: 4.2.11
-
   jsprim@1.4.2:
     dependencies:
       assert-plus: 1.0.0
@@ -5800,6 +5954,10 @@ snapshots:
     dependencies:
       json-buffer: 3.0.1
 
+  keyv@5.2.3:
+    dependencies:
+      '@keyv/serialize': 1.0.2
+
   kind-of@6.0.3: {}
 
   kleur@4.1.5: {}
@@ -5832,17 +5990,18 @@ snapshots:
 
   lighthouse-stack-packs@1.12.1: {}
 
-  lighthouse@11.4.0:
+  lighthouse@12.1.0:
     dependencies:
+      '@paulirish/trace_engine': 0.0.23
       '@sentry/node': 6.19.7
-      axe-core: 4.9.1
+      axe-core: 4.10.2
       chrome-launcher: 1.1.2
       configstore: 5.0.1
       csp_evaluator: 1.1.1
-      devtools-protocol: 0.0.1211954
+      devtools-protocol: 0.0.1312386
       enquirer: 2.4.1
       http-link-header: 1.1.3
-      intl-messageformat: 10.5.14
+      intl-messageformat: 10.7.11
       jpeg-js: 0.4.4
       js-library-detector: 6.7.0
       lighthouse-logger: 2.0.1
@@ -5852,19 +6011,17 @@ snapshots:
       metaviewport-parser: 0.3.0
       open: 8.4.2
       parse-cache-control: 1.0.1
-      ps-list: 8.1.1
-      puppeteer-core: 21.11.0
+      puppeteer-core: 22.15.0
       robots-parser: 3.0.1
       semver: 5.7.2
       speedline-core: 1.4.3
-      third-party-web: 0.24.3
-      tldts-icann: 6.1.31
+      third-party-web: 0.24.5
+      tldts-icann: 6.1.71
       ws: 7.5.10
       yargs: 17.7.2
       yargs-parser: 21.1.1
     transitivePeerDependencies:
       - bufferutil
-      - encoding
       - supports-color
       - utf-8-validate
 
@@ -5885,7 +6042,7 @@ snapshots:
     dependencies:
       uc.micro: 2.1.0
 
-  liquidjs@10.14.0:
+  liquidjs@10.20.1:
     dependencies:
       commander: 10.0.1
 
@@ -5913,8 +6070,6 @@ snapshots:
 
   lower-case@1.1.4: {}
 
-  lru-cache@10.4.0: {}
-
   lru-cache@4.1.5:
     dependencies:
       pseudomap: 1.0.2
@@ -5924,11 +6079,11 @@ snapshots:
 
   lru_map@0.3.3: {}
 
-  luxon@3.4.4: {}
+  luxon@3.5.0: {}
 
-  magic-string@0.30.10:
+  magic-string@0.30.17:
     dependencies:
-      '@jridgewell/sourcemap-codec': 1.4.15
+      '@jridgewell/sourcemap-codec': 1.5.0
 
   make-dir@3.1.0:
     dependencies:
@@ -5955,6 +6110,8 @@ snapshots:
 
   marky@1.2.5: {}
 
+  math-intrinsics@1.1.0: {}
+
   maximatch@0.1.0:
     dependencies:
       array-differ: 1.0.0
@@ -5976,7 +6133,7 @@ snapshots:
 
   memorystream@0.3.1: {}
 
-  merge-descriptors@1.0.1: {}
+  merge-descriptors@1.0.3: {}
 
   merge2@1.4.1: {}
 
@@ -5984,13 +6141,15 @@ snapshots:
 
   methods@1.1.2: {}
 
-  micromatch@4.0.7:
+  micromatch@4.0.8:
     dependencies:
       braces: 3.0.3
       picomatch: 2.3.1
 
   mime-db@1.52.0: {}
 
+  mime-db@1.53.0: {}
+
   mime-types@2.1.35:
     dependencies:
       mime-db: 1.52.0
@@ -6019,24 +6178,18 @@ snapshots:
     dependencies:
       yallist: 4.0.0
 
-  minipass@7.1.2: {}
-
   mitt@3.0.1: {}
 
-  mkdirp-classic@0.5.3: {}
-
   mkdirp@0.5.6:
     dependencies:
       minimist: 1.2.8
 
   moo@0.5.2: {}
 
-  morphdom@2.7.3: {}
+  morphdom@2.7.4: {}
 
   ms@2.0.0: {}
 
-  ms@2.1.2: {}
-
   ms@2.1.3: {}
 
   multimatch@5.0.0:
@@ -6055,6 +6208,8 @@ snapshots:
 
   negotiator@0.6.3: {}
 
+  negotiator@0.6.4: {}
+
   neo-async@2.6.2: {}
 
   netlify-plugin-11ty@1.4.0: {}
@@ -6065,6 +6220,9 @@ snapshots:
     dependencies:
       lower-case: 1.1.4
 
+  node-addon-api@7.1.1:
+    optional: true
+
   node-fetch@2.7.0:
     dependencies:
       whatwg-url: 5.0.0
@@ -6086,17 +6244,18 @@ snapshots:
 
   normalize-path@3.0.0: {}
 
-  npm-normalize-package-bin@3.0.1: {}
+  npm-normalize-package-bin@4.0.0: {}
 
-  npm-run-all2@6.2.2:
+  npm-run-all2@7.0.2:
     dependencies:
       ansi-styles: 6.2.1
-      cross-spawn: 7.0.3
+      cross-spawn: 7.0.6
       memorystream: 0.3.1
       minimatch: 9.0.5
       pidtree: 0.6.0
-      read-package-json-fast: 3.0.2
-      shell-quote: 1.8.1
+      read-package-json-fast: 4.0.0
+      shell-quote: 1.8.2
+      which: 5.0.0
 
   nth-check@2.1.1:
     dependencies:
@@ -6110,7 +6269,7 @@ snapshots:
     optionalDependencies:
       chokidar: 3.6.0
 
-  nwsapi@2.2.10: {}
+  nwsapi@2.2.16: {}
 
   oauth-sign@0.9.0: {}
 
@@ -6118,7 +6277,7 @@ snapshots:
 
   object-assign@4.1.1: {}
 
-  object-inspect@1.13.2: {}
+  object-inspect@1.13.3: {}
 
   on-finished@2.4.1:
     dependencies:
@@ -6203,16 +6362,16 @@ snapshots:
 
   p-try@2.2.0: {}
 
-  pac-proxy-agent@7.0.2:
+  pac-proxy-agent@7.1.0:
     dependencies:
       '@tootallnate/quickjs-emscripten': 0.23.0
-      agent-base: 7.1.1
-      debug: 4.3.5
-      get-uri: 6.0.3
+      agent-base: 7.1.3
+      debug: 4.4.0
+      get-uri: 6.0.4
       http-proxy-agent: 7.0.2
-      https-proxy-agent: 7.0.5
+      https-proxy-agent: 7.0.6
       pac-resolver: 7.0.1
-      socks-proxy-agent: 8.0.4
+      socks-proxy-agent: 8.0.5
     transitivePeerDependencies:
       - supports-color
 
@@ -6221,8 +6380,6 @@ snapshots:
       degenerator: 5.0.1
       netmask: 2.0.2
 
-  package-json-from-dist@1.0.0: {}
-
   pako@2.1.0: {}
 
   param-case@2.1.1:
@@ -6239,7 +6396,7 @@ snapshots:
 
   parse-json@5.2.0:
     dependencies:
-      '@babel/code-frame': 7.24.7
+      '@babel/code-frame': 7.26.2
       error-ex: 1.3.2
       json-parse-even-better-errors: 2.3.1
       lines-and-columns: 1.2.4
@@ -6248,7 +6405,7 @@ snapshots:
 
   parse5@3.0.3:
     dependencies:
-      '@types/node': 20.14.10
+      '@types/node': 22.10.5
 
   parse5@5.1.0: {}
 
@@ -6262,14 +6419,9 @@ snapshots:
 
   path-parse@1.0.7: {}
 
-  path-scurry@1.11.1:
-    dependencies:
-      lru-cache: 10.4.0
-      minipass: 7.1.2
+  path-to-regexp@0.1.12: {}
 
-  path-to-regexp@0.1.7: {}
-
-  path-to-regexp@6.2.2: {}
+  path-to-regexp@6.3.0: {}
 
   path-type@4.0.0: {}
 
@@ -6277,10 +6429,12 @@ snapshots:
 
   performance-now@2.1.0: {}
 
-  picocolors@1.0.1: {}
+  picocolors@1.1.1: {}
 
   picomatch@2.3.1: {}
 
+  picomatch@4.0.2: {}
+
   pidtree@0.6.0: {}
 
   pify@2.3.0: {}
@@ -6319,11 +6473,11 @@ snapshots:
     dependencies:
       fast-diff: 1.3.0
 
-  prettier-plugin-jinja-template@1.4.1(prettier@3.2.5):
+  prettier-plugin-jinja-template@2.0.0(prettier@3.4.2):
     dependencies:
-      prettier: 3.2.5
+      prettier: 3.4.2
 
-  prettier@3.2.5: {}
+  prettier@3.4.2: {}
 
   prismjs@1.29.0: {}
 
@@ -6344,16 +6498,16 @@ snapshots:
       forwarded: 0.2.0
       ipaddr.js: 1.9.1
 
-  proxy-agent@6.3.1:
+  proxy-agent@6.5.0:
     dependencies:
-      agent-base: 7.1.1
-      debug: 4.3.5
+      agent-base: 7.1.3
+      debug: 4.4.0
       http-proxy-agent: 7.0.2
-      https-proxy-agent: 7.0.5
+      https-proxy-agent: 7.0.6
       lru-cache: 7.18.3
-      pac-proxy-agent: 7.0.2
+      pac-proxy-agent: 7.1.0
       proxy-from-env: 1.1.0
-      socks-proxy-agent: 8.0.4
+      socks-proxy-agent: 8.0.5
     transitivePeerDependencies:
       - supports-color
 
@@ -6361,11 +6515,11 @@ snapshots:
 
   prr@1.0.1: {}
 
-  ps-list@8.1.1: {}
-
   pseudomap@1.0.2: {}
 
-  psl@1.9.0: {}
+  psl@1.15.0:
+    dependencies:
+      punycode: 2.3.1
 
   pug-attrs@3.0.0:
     dependencies:
@@ -6392,7 +6546,7 @@ snapshots:
       jstransformer: 1.0.0
       pug-error: 2.1.0
       pug-walk: 2.0.0
-      resolve: 1.22.8
+      resolve: 1.22.10
 
   pug-lexer@5.0.1:
     dependencies:
@@ -6434,7 +6588,7 @@ snapshots:
       pug-runtime: 3.0.1
       pug-strip-comments: 2.0.0
 
-  pump@3.0.0:
+  pump@3.0.2:
     dependencies:
       end-of-stream: 1.4.4
       once: 1.4.0
@@ -6443,23 +6597,21 @@ snapshots:
 
   punycode@2.3.1: {}
 
-  puppeteer-core@21.11.0:
+  puppeteer-core@22.15.0:
     dependencies:
-      '@puppeteer/browsers': 1.9.1
-      chromium-bidi: 0.5.8(devtools-protocol@0.0.1232444)
-      cross-fetch: 4.0.0
-      debug: 4.3.4
-      devtools-protocol: 0.0.1232444
-      ws: 8.16.0
+      '@puppeteer/browsers': 2.3.0
+      chromium-bidi: 0.6.3(devtools-protocol@0.0.1312386)
+      debug: 4.4.0
+      devtools-protocol: 0.0.1312386
+      ws: 8.18.0
     transitivePeerDependencies:
       - bufferutil
-      - encoding
       - supports-color
       - utf-8-validate
 
-  qs@6.11.0:
+  qs@6.13.0:
     dependencies:
-      side-channel: 1.0.6
+      side-channel: 1.1.0
 
   qs@6.5.3: {}
 
@@ -6484,10 +6636,10 @@ snapshots:
       iconv-lite: 0.4.24
       unpipe: 1.0.0
 
-  read-package-json-fast@3.0.2:
+  read-package-json-fast@4.0.0:
     dependencies:
-      json-parse-even-better-errors: 3.0.2
-      npm-normalize-package-bin: 3.0.1
+      json-parse-even-better-errors: 4.0.0
+      npm-normalize-package-bin: 4.0.0
 
   readable-stream@1.0.34:
     dependencies:
@@ -6510,6 +6662,8 @@ snapshots:
     dependencies:
       picomatch: 2.3.1
 
+  readdirp@4.1.1: {}
+
   recursive-copy@2.0.14:
     dependencies:
       errno: 0.1.8
@@ -6545,7 +6699,7 @@ snapshots:
   request@2.88.2:
     dependencies:
       aws-sign2: 0.7.0
-      aws4: 1.13.0
+      aws4: 1.13.2
       caseless: 0.12.0
       combined-stream: 1.0.8
       extend: 3.0.2
@@ -6575,9 +6729,9 @@ snapshots:
 
   resolve-pkg-maps@1.0.0: {}
 
-  resolve@1.22.8:
+  resolve@1.22.10:
     dependencies:
-      is-core-module: 2.14.0
+      is-core-module: 2.16.1
       path-parse: 1.0.7
       supports-preserve-symlinks-flag: 1.0.0
 
@@ -6612,26 +6766,29 @@ snapshots:
       stream-combiner: 0.2.2
       through: 2.3.8
 
-  rollup@4.18.0:
+  rollup@4.30.1:
     dependencies:
-      '@types/estree': 1.0.5
+      '@types/estree': 1.0.6
     optionalDependencies:
-      '@rollup/rollup-android-arm-eabi': 4.18.0
-      '@rollup/rollup-android-arm64': 4.18.0
-      '@rollup/rollup-darwin-arm64': 4.18.0
-      '@rollup/rollup-darwin-x64': 4.18.0
-      '@rollup/rollup-linux-arm-gnueabihf': 4.18.0
-      '@rollup/rollup-linux-arm-musleabihf': 4.18.0
-      '@rollup/rollup-linux-arm64-gnu': 4.18.0
-      '@rollup/rollup-linux-arm64-musl': 4.18.0
-      '@rollup/rollup-linux-powerpc64le-gnu': 4.18.0
-      '@rollup/rollup-linux-riscv64-gnu': 4.18.0
-      '@rollup/rollup-linux-s390x-gnu': 4.18.0
-      '@rollup/rollup-linux-x64-gnu': 4.18.0
-      '@rollup/rollup-linux-x64-musl': 4.18.0
-      '@rollup/rollup-win32-arm64-msvc': 4.18.0
-      '@rollup/rollup-win32-ia32-msvc': 4.18.0
-      '@rollup/rollup-win32-x64-msvc': 4.18.0
+      '@rollup/rollup-android-arm-eabi': 4.30.1
+      '@rollup/rollup-android-arm64': 4.30.1
+      '@rollup/rollup-darwin-arm64': 4.30.1
+      '@rollup/rollup-darwin-x64': 4.30.1
+      '@rollup/rollup-freebsd-arm64': 4.30.1
+      '@rollup/rollup-freebsd-x64': 4.30.1
+      '@rollup/rollup-linux-arm-gnueabihf': 4.30.1
+      '@rollup/rollup-linux-arm-musleabihf': 4.30.1
+      '@rollup/rollup-linux-arm64-gnu': 4.30.1
+      '@rollup/rollup-linux-arm64-musl': 4.30.1
+      '@rollup/rollup-linux-loongarch64-gnu': 4.30.1
+      '@rollup/rollup-linux-powerpc64le-gnu': 4.30.1
+      '@rollup/rollup-linux-riscv64-gnu': 4.30.1
+      '@rollup/rollup-linux-s390x-gnu': 4.30.1
+      '@rollup/rollup-linux-x64-gnu': 4.30.1
+      '@rollup/rollup-linux-x64-musl': 4.30.1
+      '@rollup/rollup-win32-arm64-msvc': 4.30.1
+      '@rollup/rollup-win32-ia32-msvc': 4.30.1
+      '@rollup/rollup-win32-x64-msvc': 4.30.1
       fsevents: 2.3.3
 
   run-async@2.4.1: {}
@@ -6650,11 +6807,13 @@ snapshots:
 
   safer-buffer@2.1.2: {}
 
-  sass@1.77.6:
+  sass@1.83.1:
     dependencies:
-      chokidar: 3.6.0
-      immutable: 4.3.6
-      source-map-js: 1.2.0
+      chokidar: 4.0.3
+      immutable: 5.0.3
+      source-map-js: 1.2.1
+    optionalDependencies:
+      '@parcel/watcher': 2.5.0
 
   sax@1.4.1: {}
 
@@ -6675,9 +6834,9 @@ snapshots:
 
   semver@6.3.1: {}
 
-  semver@7.6.2: {}
+  semver@7.6.3: {}
 
-  send@0.18.0:
+  send@0.19.0:
     dependencies:
       debug: 2.6.9
       depd: 2.0.0
@@ -6699,53 +6858,44 @@ snapshots:
     dependencies:
       randombytes: 2.1.0
 
-  serve-static@1.15.0:
+  serve-static@1.16.2:
     dependencies:
-      encodeurl: 1.0.2
+      encodeurl: 2.0.0
       escape-html: 1.0.3
       parseurl: 1.3.3
-      send: 0.18.0
+      send: 0.19.0
     transitivePeerDependencies:
       - supports-color
 
   set-blocking@2.0.0: {}
 
-  set-function-length@1.2.2:
-    dependencies:
-      define-data-property: 1.1.4
-      es-errors: 1.3.0
-      function-bind: 1.1.2
-      get-intrinsic: 1.2.4
-      gopd: 1.0.1
-      has-property-descriptors: 1.0.2
-
   setprototypeof@1.2.0: {}
 
-  sharp@0.33.4:
+  sharp@0.33.5:
     dependencies:
       color: 4.2.3
       detect-libc: 2.0.3
-      semver: 7.6.2
+      semver: 7.6.3
     optionalDependencies:
-      '@img/sharp-darwin-arm64': 0.33.4
-      '@img/sharp-darwin-x64': 0.33.4
-      '@img/sharp-libvips-darwin-arm64': 1.0.2
-      '@img/sharp-libvips-darwin-x64': 1.0.2
-      '@img/sharp-libvips-linux-arm': 1.0.2
-      '@img/sharp-libvips-linux-arm64': 1.0.2
-      '@img/sharp-libvips-linux-s390x': 1.0.2
-      '@img/sharp-libvips-linux-x64': 1.0.2
-      '@img/sharp-libvips-linuxmusl-arm64': 1.0.2
-      '@img/sharp-libvips-linuxmusl-x64': 1.0.2
-      '@img/sharp-linux-arm': 0.33.4
-      '@img/sharp-linux-arm64': 0.33.4
-      '@img/sharp-linux-s390x': 0.33.4
-      '@img/sharp-linux-x64': 0.33.4
-      '@img/sharp-linuxmusl-arm64': 0.33.4
-      '@img/sharp-linuxmusl-x64': 0.33.4
-      '@img/sharp-wasm32': 0.33.4
-      '@img/sharp-win32-ia32': 0.33.4
-      '@img/sharp-win32-x64': 0.33.4
+      '@img/sharp-darwin-arm64': 0.33.5
+      '@img/sharp-darwin-x64': 0.33.5
+      '@img/sharp-libvips-darwin-arm64': 1.0.4
+      '@img/sharp-libvips-darwin-x64': 1.0.4
+      '@img/sharp-libvips-linux-arm': 1.0.5
+      '@img/sharp-libvips-linux-arm64': 1.0.4
+      '@img/sharp-libvips-linux-s390x': 1.0.4
+      '@img/sharp-libvips-linux-x64': 1.0.4
+      '@img/sharp-libvips-linuxmusl-arm64': 1.0.4
+      '@img/sharp-libvips-linuxmusl-x64': 1.0.4
+      '@img/sharp-linux-arm': 0.33.5
+      '@img/sharp-linux-arm64': 0.33.5
+      '@img/sharp-linux-s390x': 0.33.5
+      '@img/sharp-linux-x64': 0.33.5
+      '@img/sharp-linuxmusl-arm64': 0.33.5
+      '@img/sharp-linuxmusl-x64': 0.33.5
+      '@img/sharp-wasm32': 0.33.5
+      '@img/sharp-win32-ia32': 0.33.5
+      '@img/sharp-win32-x64': 0.33.5
 
   shebang-command@2.0.0:
     dependencies:
@@ -6753,18 +6903,37 @@ snapshots:
 
   shebang-regex@3.0.0: {}
 
-  shell-quote@1.8.1: {}
+  shell-quote@1.8.2: {}
 
-  side-channel@1.0.6:
+  side-channel-list@1.0.0:
     dependencies:
-      call-bind: 1.0.7
       es-errors: 1.3.0
-      get-intrinsic: 1.2.4
-      object-inspect: 1.13.2
+      object-inspect: 1.13.3
 
-  signal-exit@3.0.7: {}
+  side-channel-map@1.0.1:
+    dependencies:
+      call-bound: 1.0.3
+      es-errors: 1.3.0
+      get-intrinsic: 1.2.7
+      object-inspect: 1.13.3
+
+  side-channel-weakmap@1.0.2:
+    dependencies:
+      call-bound: 1.0.3
+      es-errors: 1.3.0
+      get-intrinsic: 1.2.7
+      object-inspect: 1.13.3
+      side-channel-map: 1.0.1
 
-  signal-exit@4.1.0: {}
+  side-channel@1.1.0:
+    dependencies:
+      es-errors: 1.3.0
+      object-inspect: 1.13.3
+      side-channel-list: 1.0.0
+      side-channel-map: 1.0.1
+      side-channel-weakmap: 1.0.2
+
+  signal-exit@3.0.7: {}
 
   simple-swizzle@0.2.2:
     dependencies:
@@ -6785,10 +6954,10 @@ snapshots:
 
   smob@1.5.0: {}
 
-  socks-proxy-agent@8.0.4:
+  socks-proxy-agent@8.0.5:
     dependencies:
-      agent-base: 7.1.1
-      debug: 4.3.5
+      agent-base: 7.1.3
+      debug: 4.4.0
       socks: 2.8.3
     transitivePeerDependencies:
       - supports-color
@@ -6798,7 +6967,7 @@ snapshots:
       ip-address: 9.0.5
       smart-buffer: 4.2.0
 
-  source-map-js@1.2.0: {}
+  source-map-js@1.2.1: {}
 
   source-map-support@0.5.21:
     dependencies:
@@ -6809,7 +6978,7 @@ snapshots:
 
   speedline-core@1.4.3:
     dependencies:
-      '@types/node': 20.14.10
+      '@types/node': 22.10.5
       image-ssim: 0.2.0
       jpeg-js: 0.4.4
 
@@ -6852,13 +7021,13 @@ snapshots:
     dependencies:
       bluebird: 2.11.0
 
-  streamx@2.18.0:
+  streamx@2.21.1:
     dependencies:
       fast-fifo: 1.3.2
       queue-tick: 1.0.1
-      text-decoder: 1.1.0
+      text-decoder: 1.2.3
     optionalDependencies:
-      bare-events: 2.4.2
+      bare-events: 2.5.4
 
   string-width@2.1.1:
     dependencies:
@@ -6871,12 +7040,6 @@ snapshots:
       is-fullwidth-code-point: 3.0.0
       strip-ansi: 6.0.1
 
-  string-width@5.1.2:
-    dependencies:
-      eastasianwidth: 0.2.0
-      emoji-regex: 9.2.2
-      strip-ansi: 7.1.0
-
   string_decoder@0.10.31: {}
 
   string_decoder@1.1.1:
@@ -6903,10 +7066,6 @@ snapshots:
     dependencies:
       ansi-regex: 5.0.1
 
-  strip-ansi@7.1.0:
-    dependencies:
-      ansi-regex: 6.0.1
-
   strip-bom-string@1.0.0: {}
 
   strip-json-comments@3.1.1: {}
@@ -6933,43 +7092,43 @@ snapshots:
       css-tree: 2.3.1
       css-what: 6.1.0
       csso: 5.0.5
-      picocolors: 1.0.1
+      picocolors: 1.1.1
 
   symbol-tree@3.2.4: {}
 
-  synckit@0.8.8:
+  synckit@0.9.2:
     dependencies:
       '@pkgr/core': 0.1.1
-      tslib: 2.6.3
+      tslib: 2.8.1
 
   tapable@2.2.1: {}
 
-  tar-fs@3.0.4:
+  tar-fs@3.0.7:
     dependencies:
-      mkdirp-classic: 0.5.3
-      pump: 3.0.0
+      pump: 3.0.2
       tar-stream: 3.1.7
+    optionalDependencies:
+      bare-fs: 2.3.5
+      bare-path: 2.1.3
 
   tar-stream@3.1.7:
     dependencies:
-      b4a: 1.6.6
+      b4a: 1.6.7
       fast-fifo: 1.3.2
-      streamx: 2.18.0
+      streamx: 2.21.1
 
-  terser@5.31.1:
+  terser@5.37.0:
     dependencies:
       '@jridgewell/source-map': 0.3.6
-      acorn: 8.12.1
+      acorn: 8.14.0
       commander: 2.20.3
       source-map-support: 0.5.21
 
-  text-decoder@1.1.0:
+  text-decoder@1.2.3:
     dependencies:
-      b4a: 1.6.6
-
-  text-table@0.2.0: {}
+      b4a: 1.6.7
 
-  third-party-web@0.24.3: {}
+  third-party-web@0.24.5: {}
 
   through2-sink@1.0.0:
     dependencies:
@@ -6988,11 +7147,11 @@ snapshots:
 
   through@2.3.8: {}
 
-  tldts-core@6.1.31: {}
+  tldts-core@6.1.71: {}
 
-  tldts-icann@6.1.31:
+  tldts-icann@6.1.71:
     dependencies:
-      tldts-core: 6.1.31
+      tldts-core: 6.1.71
 
   tmp@0.0.33:
     dependencies:
@@ -7002,8 +7161,6 @@ snapshots:
     dependencies:
       rimraf: 2.7.1
 
-  to-fast-properties@2.0.0: {}
-
   to-regex-range@5.0.1:
     dependencies:
       is-number: 7.0.0
@@ -7014,7 +7171,7 @@ snapshots:
 
   tough-cookie@2.5.0:
     dependencies:
-      psl: 1.9.0
+      psl: 1.15.0
       punycode: 2.3.1
 
   tr46@0.0.3: {}
@@ -7027,7 +7184,7 @@ snapshots:
 
   tslib@1.14.1: {}
 
-  tslib@2.6.3: {}
+  tslib@2.8.1: {}
 
   tunnel-agent@0.6.0:
     dependencies:
@@ -7058,21 +7215,19 @@ snapshots:
 
   uc.micro@2.1.0: {}
 
-  uglify-js@3.18.0: {}
+  uglify-js@3.19.3: {}
 
   unbzip2-stream@1.4.3:
     dependencies:
       buffer: 5.7.1
       through: 2.3.8
 
-  undici-types@5.26.5: {}
+  undici-types@6.20.0: {}
 
   unique-string@2.0.0:
     dependencies:
       crypto-random-string: 2.0.0
 
-  universalify@2.0.1: {}
-
   unpipe@1.0.0: {}
 
   upper-case@1.1.3: {}
@@ -7088,7 +7243,7 @@ snapshots:
   urlobj@0.0.11:
     dependencies:
       is-object: 1.0.2
-      is-string: 1.0.7
+      is-string: 1.1.1
       object-assign: 4.1.1
 
   urlpattern-polyfill@10.0.0: {}
@@ -7160,7 +7315,11 @@ snapshots:
     dependencies:
       isexe: 2.0.0
 
-  wicg-inert@3.1.2: {}
+  which@5.0.0:
+    dependencies:
+      isexe: 3.1.1
+
+  wicg-inert@3.1.3: {}
 
   win-release@1.1.1:
     dependencies:
@@ -7168,9 +7327,9 @@ snapshots:
 
   with@7.0.2:
     dependencies:
-      '@babel/parser': 7.24.7
-      '@babel/types': 7.24.7
-      assert-never: 1.3.0
+      '@babel/parser': 7.26.5
+      '@babel/types': 7.26.5
+      assert-never: 1.4.0
       babel-walk: 3.0.0-canary-5
 
   word-wrap@1.2.5: {}
@@ -7189,12 +7348,6 @@ snapshots:
       string-width: 4.2.3
       strip-ansi: 6.0.1
 
-  wrap-ansi@8.1.0:
-    dependencies:
-      ansi-styles: 6.2.1
-      string-width: 5.1.2
-      strip-ansi: 7.1.0
-
   wrappy@1.0.2: {}
 
   write-file-atomic@3.0.3:
@@ -7210,8 +7363,6 @@ snapshots:
 
   ws@7.5.10: {}
 
-  ws@8.16.0: {}
-
   ws@8.18.0: {}
 
   xdg-basedir@4.0.0: {}
@@ -7230,7 +7381,7 @@ snapshots:
 
   yallist@4.0.0: {}
 
-  yaml@2.4.5: {}
+  yaml@2.7.0: {}
 
   yamlparser@0.0.2: {}
 
@@ -7263,7 +7414,7 @@ snapshots:
   yargs@17.7.2:
     dependencies:
       cliui: 8.0.1
-      escalade: 3.1.2
+      escalade: 3.2.0
       get-caller-file: 2.0.5
       require-directory: 2.1.1
       string-width: 4.2.3
@@ -7276,3 +7427,5 @@ snapshots:
       fd-slicer: 1.1.0
 
   yocto-queue@0.1.0: {}
+
+  zod@3.23.8: {}
diff --git a/src/_data/config.js b/src/_data/config.js
index aafca79f2d..7a53618e9c 100644
--- a/src/_data/config.js
+++ b/src/_data/config.js
@@ -9,6 +9,6 @@ module.exports = {
   authorHandle: "",
   authorName: "",
   description:
-    "We are Europe’s leading mobile and web design & development consultancy. Our clients value code quality, dependability and honesty. We are trusted by Generali, Qonto, Trainline, and CLARK.",
+    "We know the code, tools, and practices that go into successful development. We partner with our clients to solve their toughest tech challenges by sharing our skills and expertise as teammates.",
   maxPostsPerPage: 6,
 };
diff --git a/src/_data/publicRustWorkshops.json b/src/_data/publicRustWorkshops.json
index 681415c421..6b8e1c2c53 100644
--- a/src/_data/publicRustWorkshops.json
+++ b/src/_data/publicRustWorkshops.json
@@ -1,10 +1,22 @@
 {
   "workshops": [
     {
-      "endDate": "2024-05-29T18:00+02:00",
-      "date": "May 28th + 29th, 2024, 14:00-18:00 CEST",
-      "text": "Remote Workshop: Telemetry for Rust APIs – you can't fix what you can't see",
-      "link": "https://ti.to/mainmatter/rust-telemetry-may-2024"
+      "endDate": "2025-01-24T18:00+01:00",
+      "date": "Jan 23rd + 24th, 2025, 14:00-18:00 CET",
+      "text": "Remote Workshop: Testing for Rust projects – going beyond the basics",
+      "link": "https://ti.to/mainmatter/rust-testing-jan-2025"
+    },
+    {
+      "endDate": "2025-02-28T18:00+01:00",
+      "date": "Feb 27th + 28th, 2025, 14:00-18:00 CET",
+      "text": "Remote Workshop: Rust-Python Interoperability",
+      "link": "https://ti.to/mainmatter/rust-python-feb-2025"
+    },
+    {
+      "endDate": "2025-02-21T18:00+01:00",
+      "date": "Jan 30th – Feb 21st, 2025, 14:00-18:00 CET",
+      "text": "Remote Workshop: Learn Rust, starting from scratch",
+      "link": "https://ti.to/mainmatter/rust-from-scratch-jan-2025"
     }
   ]
 }
diff --git a/src/_data/publicSvelteWorkshops.json b/src/_data/publicSvelteWorkshops.json
new file mode 100644
index 0000000000..de65474db5
--- /dev/null
+++ b/src/_data/publicSvelteWorkshops.json
@@ -0,0 +1,10 @@
+{
+  "workshops": [
+    {
+      "endDate": "2025-02-07T18:00+01:00",
+      "date": "Feb 6th – 7th, 2025, 14:00-18:00 CET",
+      "text": "Remote Workshop: Svelte 5 & Runes",
+      "link": "https://ti.to/mainmatter/svelte-5-runes-feb-2025"
+    }
+  ]
+}
diff --git a/src/_data/services.json b/src/_data/services.json
index 6da137f66c..317b059a5c 100644
--- a/src/_data/services.json
+++ b/src/_data/services.json
@@ -21,6 +21,23 @@
       "linkUrl": "/services/strategic-advice"
     }
   ],
+  "services-list-clutch": [
+    {
+      "heading": "Launch your idea",
+      "text": "From Concept to MVP",
+      "linkUrl": "/services/launch-your-idea/"
+    },
+    {
+      "heading": "Modernize your tech stack",
+      "text": "Upgrades instead of rewrites",
+      "linkUrl": "/services/tech-modernization/"
+    },
+    {
+      "heading": "Get strategic advice",
+      "text": "Assessments, transformation and scaling",
+      "linkUrl": "/services/strategic-advice"
+    }
+  ],
   "team-reinforcement": [
     {
       "heading": "Launch your idea",
diff --git a/src/_data/socials.json b/src/_data/socials.json
index 2b7a11258c..e8ac48f306 100644
--- a/src/_data/socials.json
+++ b/src/_data/socials.json
@@ -8,6 +8,10 @@
       "text": "LinkedIn",
       "link": "https://www.linkedin.com/company/mainmatter/"
     },
+    {
+      "text": "Bluesky",
+      "link": "https://bsky.app/profile/mainmatter.com"
+    },
     {
       "text": "Twitter",
       "link": "https://twitter.com/mainmatter/"
diff --git a/src/_data/team.json b/src/_data/team.json
index fa58c26679..16a5f7f500 100644
--- a/src/_data/team.json
+++ b/src/_data/team.json
@@ -56,14 +56,14 @@
       "name": "Majd Bayassi",
       "imgPath": "/assets/images/team/majd.jpg"
     },
-    {
-      "name": "Emma Sofia Dell'Acqua",
-      "imgPath": "/assets/images/team/emma.jpg"
-    },
     {
       "name": "Marco Otte-Witte",
       "imgPath": "/assets/images/team/marco.jpg"
     },
+    {
+      "name": "Celli",
+      "imgPath": "/assets/images/team/celli.jpg"
+    },
     {
       "name": "Chris Manson",
       "imgPath": "/assets/images/team/chris.jpg"
diff --git a/src/appearances/2016-07-12-authentication-and-session-management-in-fastboot.md b/src/appearances/2016-07-12-authentication-and-session-management-in-fastboot.md
index 5fd1047ffc..6ba5d76ddd 100644
--- a/src/appearances/2016-07-12-authentication-and-session-management-in-fastboot.md
+++ b/src/appearances/2016-07-12-authentication-and-session-management-in-fastboot.md
@@ -6,5 +6,4 @@ media: video
 channel: embercamp-2016
 ---
 
-Marco Otte-Witte shows how authentication ans session management works in
-FastBoot with cookies.
+Marco Otte-Witte shows how authentication ans session management works in FastBoot with cookies.
diff --git a/src/appearances/2017-03-28-animate-the-web-with-ember.md b/src/appearances/2017-03-28-animate-the-web-with-ember.md
index 0b1c8f8f0c..f457f3fa9f 100644
--- a/src/appearances/2017-03-28-animate-the-web-with-ember.md
+++ b/src/appearances/2017-03-28-animate-the-web-with-ember.md
@@ -6,5 +6,4 @@ media: video
 channel: emberconf-2017
 ---
 
-Jessica Jordan shows how to do animations on the web leveraging HTML5 canvas and
-the Web Animation API.
+Jessica Jordan shows how to do animations on the web leveraging HTML5 canvas and the Web Animation API.
diff --git a/src/appearances/2017-05-24-feel-the-glimmer.md b/src/appearances/2017-05-24-feel-the-glimmer.md
index 10d5a19799..cc54f6821a 100644
--- a/src/appearances/2017-05-24-feel-the-glimmer.md
+++ b/src/appearances/2017-05-24-feel-the-glimmer.md
@@ -6,5 +6,4 @@ media: video
 channel: ember-munich
 ---
 
-Marco Otte-Witte introduces Glimmer.js and the Glimmer VM and explains how they
-work.
+Marco Otte-Witte introduces Glimmer.js and the Glimmer VM and explains how they work.
diff --git a/src/appearances/2017-07-11-the-modern-state-of-web-components.md b/src/appearances/2017-07-11-the-modern-state-of-web-components.md
index 0b2cdb7c37..713a48976b 100644
--- a/src/appearances/2017-07-11-the-modern-state-of-web-components.md
+++ b/src/appearances/2017-07-11-the-modern-state-of-web-components.md
@@ -6,5 +6,4 @@ media: video
 channel: embercamp-2017
 ---
 
-Jessica Jordan gives an update on the status of native web components and shows
-how they can be used via Glimmer.js today.
+Jessica Jordan gives an update on the status of native web components and shows how they can be used via Glimmer.js today.
diff --git a/src/appearances/2017-10-23-a-glimmer-of-hope-creating-modern-web-components-with-glimmer.md b/src/appearances/2017-10-23-a-glimmer-of-hope-creating-modern-web-components-with-glimmer.md
index 1539cc4631..7825f45878 100644
--- a/src/appearances/2017-10-23-a-glimmer-of-hope-creating-modern-web-components-with-glimmer.md
+++ b/src/appearances/2017-10-23-a-glimmer-of-hope-creating-modern-web-components-with-glimmer.md
@@ -6,5 +6,4 @@ media: video
 channel: international-javascript-conference-2017
 ---
 
-Jessica Jordan elaborates on how web components can be built today leveraging
-Glimmer.js.
+Jessica Jordan elaborates on how web components can be built today leveraging Glimmer.js.
diff --git a/src/appearances/2018-02-22-testing-against-time-in-javascript-applications.md b/src/appearances/2018-02-22-testing-against-time-in-javascript-applications.md
index b1785abcd7..ca54e56269 100644
--- a/src/appearances/2018-02-22-testing-against-time-in-javascript-applications.md
+++ b/src/appearances/2018-02-22-testing-against-time-in-javascript-applications.md
@@ -6,5 +6,4 @@ media: video
 channel: assertjs-2018
 ---
 
-Jessica Jordan introduces patterns and best practices around testing
-asynchronous and time-dependent behaviors.
+Jessica Jordan introduces patterns and best practices around testing asynchronous and time-dependent behaviors.
diff --git a/src/appearances/2018-03-13-everything-they-didnt-tell-you-about-the-ember-community.md b/src/appearances/2018-03-13-everything-they-didnt-tell-you-about-the-ember-community.md
index 6ebb7109fa..48b876ec2d 100644
--- a/src/appearances/2018-03-13-everything-they-didnt-tell-you-about-the-ember-community.md
+++ b/src/appearances/2018-03-13-everything-they-didnt-tell-you-about-the-ember-community.md
@@ -6,5 +6,4 @@ media: video
 channel: emberconf-2018
 ---
 
-Jessica Jordan shares some insights to what defines the Ember Community and what
-drives it forward.
+Jessica Jordan shares some insights to what defines the Ember Community and what drives it forward.
diff --git a/src/appearances/2018-03-13-the-next-generation-of-testing.md b/src/appearances/2018-03-13-the-next-generation-of-testing.md
index 3678954021..078b6f0d0e 100644
--- a/src/appearances/2018-03-13-the-next-generation-of-testing.md
+++ b/src/appearances/2018-03-13-the-next-generation-of-testing.md
@@ -6,5 +6,4 @@ media: video
 channel: emberconf-2018
 ---
 
-Tobias Bieniek elaborates on what modern testing of Ember.js applications looks
-like.
+Tobias Bieniek elaborates on what modern testing of Ember.js applications looks like.
diff --git a/src/appearances/2018-09-21-internationalization-its-easy-in-ember.md b/src/appearances/2018-09-21-internationalization-its-easy-in-ember.md
index 6dc6955049..584d2c6566 100644
--- a/src/appearances/2018-09-21-internationalization-its-easy-in-ember.md
+++ b/src/appearances/2018-09-21-internationalization-its-easy-in-ember.md
@@ -6,5 +6,4 @@ media: video
 channel: embercamp-2018
 ---
 
-Tobias Bieniek shares just how easy internationalization of Ember apps can be
-when done right.
+Tobias Bieniek shares just how easy internationalization of Ember apps can be when done right.
diff --git a/src/appearances/2018-10-11-deliver-fast-apps-even-faster.md b/src/appearances/2018-10-11-deliver-fast-apps-even-faster.md
index 8d6f826c95..afd8c21f3d 100644
--- a/src/appearances/2018-10-11-deliver-fast-apps-even-faster.md
+++ b/src/appearances/2018-10-11-deliver-fast-apps-even-faster.md
@@ -6,5 +6,4 @@ media: video
 channel: emberfest-2018
 ---
 
-Marco Otte-Witte talks about optimizing JavaScript bundles and loading behaviour
-of Ember.js apps.
+Marco Otte-Witte talks about optimizing JavaScript bundles and loading behaviour of Ember.js apps.
diff --git a/src/appearances/2018-10-11-els-the-ember-language-server.md b/src/appearances/2018-10-11-els-the-ember-language-server.md
index e56b42bb63..1697b1c276 100644
--- a/src/appearances/2018-10-11-els-the-ember-language-server.md
+++ b/src/appearances/2018-10-11-els-the-ember-language-server.md
@@ -6,5 +6,4 @@ media: video
 channel: emberfest-2018
 ---
 
-Tobias Bieniek gives an update on the status of the Ember Language Server and
-goals for the future.
+Tobias Bieniek gives an update on the status of the Ember Language Server and goals for the future.
diff --git a/src/appearances/2018-10-29-crafting-web-comics-with-ember.md b/src/appearances/2018-10-29-crafting-web-comics-with-ember.md
index 7943e691f4..91fa1f2efc 100644
--- a/src/appearances/2018-10-29-crafting-web-comics-with-ember.md
+++ b/src/appearances/2018-10-29-crafting-web-comics-with-ember.md
@@ -6,5 +6,4 @@ media: video
 channel: reactiveconf-2018
 ---
 
-Jessica Jordan shares how to build comics for the web using Ember.js and the Web
-Animation API.
+Jessica Jordan shares how to build comics for the web using Ember.js and the Web Animation API.
diff --git a/src/appearances/2019-06-01-crafting-comics-for-literally-everyone.md b/src/appearances/2019-06-01-crafting-comics-for-literally-everyone.md
index d617e4f9e0..e12f9fad70 100644
--- a/src/appearances/2019-06-01-crafting-comics-for-literally-everyone.md
+++ b/src/appearances/2019-06-01-crafting-comics-for-literally-everyone.md
@@ -6,5 +6,4 @@ media: video
 channel: jsconf-eu-2019
 ---
 
-Jessica Jordan demonstrates how to create an immersive web comic experience that
-is not only engaging for sighted users but accessible for everyone.
+Jessica Jordan demonstrates how to create an immersive web comic experience that is not only engaging for sighted users but accessible for everyone.
diff --git a/src/appearances/2019-06-22-thriving-through-the-hype-cycle.md b/src/appearances/2019-06-22-thriving-through-the-hype-cycle.md
index 787a62c143..7321e60d23 100644
--- a/src/appearances/2019-06-22-thriving-through-the-hype-cycle.md
+++ b/src/appearances/2019-06-22-thriving-through-the-hype-cycle.md
@@ -6,5 +6,4 @@ media: video
 channel: commit-porto-2019
 ---
 
-Ricardo Mendes goes through the history of Ember.js as a project and how it
-braves the fads of front-end development.
+Ricardo Mendes goes through the history of Ember.js as a project and how it braves the fads of front-end development.
diff --git a/src/appearances/2019-10-17-console-group-and-qunit.md b/src/appearances/2019-10-17-console-group-and-qunit.md
index 688465d3c7..f3c990c46b 100644
--- a/src/appearances/2019-10-17-console-group-and-qunit.md
+++ b/src/appearances/2019-10-17-console-group-and-qunit.md
@@ -6,5 +6,4 @@ media: video
 channel: emberfest-2019
 ---
 
-Tobias Bieniek shows how grouping console statements makes for a better QUnit
-experience.
+Tobias Bieniek shows how grouping console statements makes for a better QUnit experience.
diff --git a/src/appearances/2019-10-17-jam-stack-for-human-beings.md b/src/appearances/2019-10-17-jam-stack-for-human-beings.md
index 0ff02b4db7..57542bc5ef 100644
--- a/src/appearances/2019-10-17-jam-stack-for-human-beings.md
+++ b/src/appearances/2019-10-17-jam-stack-for-human-beings.md
@@ -6,5 +6,4 @@ media: video
 channel: emberfest-2019
 ---
 
-Chris Manson shares what the JAM stack even is and how Ember developers can
-leverage its concepts.
+Chris Manson shares what the JAM stack even is and how Ember developers can leverage its concepts.
diff --git a/src/appearances/2019-10-17-steady-state-with-ember-octane.md b/src/appearances/2019-10-17-steady-state-with-ember-octane.md
index 692587dbac..23e9bd1ddb 100644
--- a/src/appearances/2019-10-17-steady-state-with-ember-octane.md
+++ b/src/appearances/2019-10-17-steady-state-with-ember-octane.md
@@ -6,5 +6,4 @@ media: video
 channel: emberfest-2019
 ---
 
-Jessica Jordan explains how state management works with decorators and tracked
-properties in Ember Octane apps.
+Jessica Jordan explains how state management works with decorators and tracked properties in Ember Octane apps.
diff --git a/src/appearances/2020-03-16-decorators-in-depth.md b/src/appearances/2020-03-16-decorators-in-depth.md
index 126da8e6ae..19284b562b 100644
--- a/src/appearances/2020-03-16-decorators-in-depth.md
+++ b/src/appearances/2020-03-16-decorators-in-depth.md
@@ -6,5 +6,4 @@ media: video
 channel: emberconf-2020
 ---
 
-Marco Otte-Witte explains how decorators that are the foundation for Ember's
-@tracked and @actions work under the hood.
+Marco Otte-Witte explains how decorators that are the foundation for Ember's @tracked and @actions work under the hood.
diff --git a/src/appearances/2020-03-16-the-power-of-debugging.md b/src/appearances/2020-03-16-the-power-of-debugging.md
index 5f702cd3df..8843356708 100644
--- a/src/appearances/2020-03-16-the-power-of-debugging.md
+++ b/src/appearances/2020-03-16-the-power-of-debugging.md
@@ -6,5 +6,4 @@ media: video
 channel: emberconf-2020
 ---
 
-Samanta de Barros explains how to leverage tools to debug and better understand
-the structure of Ember apps.
+Samanta de Barros explains how to leverage tools to debug and better understand the structure of Ember apps.
diff --git a/src/appearances/2020-12-10-the-three-pillars-of-successful-digital-product-development.md b/src/appearances/2020-12-10-the-three-pillars-of-successful-digital-product-development.md
index 0f21f81fa1..20a87c43a7 100644
--- a/src/appearances/2020-12-10-the-three-pillars-of-successful-digital-product-development.md
+++ b/src/appearances/2020-12-10-the-three-pillars-of-successful-digital-product-development.md
@@ -6,6 +6,4 @@ media: video
 channel: product-circle
 ---
 
-Marco Otte-Witte shares best practices for digital product development in the
-areas of planning and preparation, process and collaboration, as well as
-infrastructure and practices.
+Marco Otte-Witte shares best practices for digital product development in the areas of planning and preparation, process and collaboration, as well as infrastructure and practices.
diff --git a/src/appearances/2020-12-10-version-control-in-design.md b/src/appearances/2020-12-10-version-control-in-design.md
index d8f1ae1a73..fc7a41a954 100644
--- a/src/appearances/2020-12-10-version-control-in-design.md
+++ b/src/appearances/2020-12-10-version-control-in-design.md
@@ -6,5 +6,4 @@ media: video
 channel: on-product
 ---
 
-Mar High explains how design teams can benefit from version control and explores
-best practices for collaboration.
+Mar High explains how design teams can benefit from version control and explores best practices for collaboration.
diff --git a/src/appearances/2021-03-29-handling-images-on-the-web.md b/src/appearances/2021-03-29-handling-images-on-the-web.md
index daabdc0f47..b4c2c3c309 100644
--- a/src/appearances/2021-03-29-handling-images-on-the-web.md
+++ b/src/appearances/2021-03-29-handling-images-on-the-web.md
@@ -6,6 +6,4 @@ media: video
 channel: emberconf-2021
 ---
 
-Handling images on the web has evolved from a simple task to a complex topic.
-Marco Otte-Witte presents options for different scenarios along with challenges
-and advantages as well as disadvantages of different approaches.
+Handling images on the web has evolved from a simple task to a complex topic. Marco Otte-Witte presents options for different scenarios along with challenges and advantages as well as disadvantages of different approaches.
diff --git a/src/appearances/2021-03-29-please-wait-oh-it-didnt-work.md b/src/appearances/2021-03-29-please-wait-oh-it-didnt-work.md
index 161288d1b2..d9c23be21a 100644
--- a/src/appearances/2021-03-29-please-wait-oh-it-didnt-work.md
+++ b/src/appearances/2021-03-29-please-wait-oh-it-didnt-work.md
@@ -6,6 +6,4 @@ media: video
 channel: emberconf-2021
 ---
 
-Tobias Bieniek explains how to implement and test loading states, how to deal
-with network errors and how to prevent Sentry from filling up with uncaught
-promise errors.
+Tobias Bieniek explains how to implement and test loading states, how to deal with network errors and how to prevent Sentry from filling up with uncaught promise errors.
diff --git a/src/appearances/2021-09-30-data-validation-in-ember-apps.md b/src/appearances/2021-09-30-data-validation-in-ember-apps.md
index cf663b5f2f..10d328bdc0 100644
--- a/src/appearances/2021-09-30-data-validation-in-ember-apps.md
+++ b/src/appearances/2021-09-30-data-validation-in-ember-apps.md
@@ -6,7 +6,4 @@ media: video
 channel: emberfest-2021
 ---
 
-Ember Octane’s tracking system makes it easier to integrate libraries from the
-wider JavaScript ecosystem in Ember apps. Bartłomiej Dudzik explained how to
-leverage other packages for validating data than ember-cp-validations or
-ember-changeset.
+Ember Octane’s tracking system makes it easier to integrate libraries from the wider JavaScript ecosystem in Ember apps. Bartłomiej Dudzik explained how to leverage other packages for validating data than ember-cp-validations or ember-changeset.
diff --git a/src/appearances/2021-09-30-making-mira.md b/src/appearances/2021-09-30-making-mira.md
index ec5bbc2f48..5851a4242c 100644
--- a/src/appearances/2021-09-30-making-mira.md
+++ b/src/appearances/2021-09-30-making-mira.md
@@ -6,6 +6,4 @@ media: video
 channel: emberfest-2021
 ---
 
-Mira is a robot created by Pixar artist Alonso Martinez, capable of recreating a
-great number of emotions and interactions. In his talk, Nick Schot brings Mira
-to the web while explaining different animation techniques.
+Mira is a robot created by Pixar artist Alonso Martinez, capable of recreating a great number of emotions and interactions. In his talk, Nick Schot brings Mira to the web while explaining different animation techniques.
diff --git a/src/appearances/2021-09-30-universal-design-systems-the-ember-way.md b/src/appearances/2021-09-30-universal-design-systems-the-ember-way.md
index 4f34e1ed27..999207e9cb 100644
--- a/src/appearances/2021-09-30-universal-design-systems-the-ember-way.md
+++ b/src/appearances/2021-09-30-universal-design-systems-the-ember-way.md
@@ -6,6 +6,4 @@ media: video
 channel: emberfest-2021
 ---
 
-With Ember being HTML-First, doors open to new possibilities. Chris Manson
-explores the opportunity of building a design system with Ember that can also be
-consumed by apps that are not using JavaScript in his talk.
+With Ember being HTML-First, doors open to new possibilities. Chris Manson explores the opportunity of building a design system with Ember that can also be consumed by apps that are not using JavaScript in his talk.
diff --git a/src/appearances/2022-04-19-lint-your-code-into-the-future.md b/src/appearances/2022-04-19-lint-your-code-into-the-future.md
index f7c120227f..d216428761 100644
--- a/src/appearances/2022-04-19-lint-your-code-into-the-future.md
+++ b/src/appearances/2022-04-19-lint-your-code-into-the-future.md
@@ -6,9 +6,6 @@ media: video
 channel: emberconf-2022
 ---
 
-Adopting new linting rules in modestly sized apps can often leave you with
-several linting errors across hundreds of files.
+Adopting new linting rules in modestly sized apps can often leave you with several linting errors across hundreds of files.
 
-Chris Manson explains how you can reduce the struggle and happily lint large
-apps all the way to modern Ember at your own pace in his talk from
-EmberConf 2022.
+Chris Manson explains how you can reduce the struggle and happily lint large apps all the way to modern Ember at your own pace in his talk from EmberConf 2022.
diff --git a/src/appearances/2022-09-22-bottled-ember.md b/src/appearances/2022-09-22-bottled-ember.md
index 20631123e9..930d4ec25c 100644
--- a/src/appearances/2022-09-22-bottled-ember.md
+++ b/src/appearances/2022-09-22-bottled-ember.md
@@ -1,15 +1,9 @@
 ---
-title:
-  "Bottled Ember - Batteries Included Web Framework, tiny tiny living space"
+title: "Bottled Ember - Batteries Included Web Framework, tiny tiny living space"
 image: "/assets/images/talks/2022-09-22-emberfest-2022/bottled-ember.jpg"
 url: https://www.youtube.com/watch?v=On7gcZsuQ7g
 media: video
 channel: emberfest-2022
 ---
 
-All Ember addons come with the concept of a “dummy app”. This has been super
-useful to test our addons and has even been part of the reason why we have been
-able to support so many different versions of Ember from a single addon using
-ember-try scenarios. This talk by Chris from EmberFest 2022, gives a bit of
-detail on how “classic” addons work and proposes an alternative to replacing the
-idea of the addon's dummy app with a monorepo in V2 addons.
+All Ember addons come with the concept of a “dummy app”. This has been super useful to test our addons and has even been part of the reason why we have been able to support so many different versions of Ember from a single addon using ember-try scenarios. This talk by Chris from EmberFest 2022, gives a bit of detail on how “classic” addons work and proposes an alternative to replacing the idea of the addon's dummy app with a monorepo in V2 addons.
diff --git a/src/appearances/2022-09-22-certificates-for-ember-serve.md b/src/appearances/2022-09-22-certificates-for-ember-serve.md
index f10a2b3c82..f3f6a19caf 100644
--- a/src/appearances/2022-09-22-certificates-for-ember-serve.md
+++ b/src/appearances/2022-09-22-certificates-for-ember-serve.md
@@ -6,7 +6,6 @@ media: video
 channel: emberfest-2022
 ---
 
-From enabling secure cookies to working with crypto, there are many reasons why
-you might want to serve your Ember application over HTTPS locally.
+From enabling secure cookies to working with crypto, there are many reasons why you might want to serve your Ember application over HTTPS locally.
 
 Learn how in this talk by Florian from EmberFest 2022.
diff --git a/src/appearances/2022-09-22-the-future-of-ember.md b/src/appearances/2022-09-22-the-future-of-ember.md
index 7d5fb4b50a..3c3640933f 100644
--- a/src/appearances/2022-09-22-the-future-of-ember.md
+++ b/src/appearances/2022-09-22-the-future-of-ember.md
@@ -6,7 +6,4 @@ media: video
 channel: emberfest-2022
 ---
 
-EmberFest 2022 closed with a panel about the future of Ember, moderated by Marco
-Otte-Witte with panelists Melanie Sumner, Chris Manson, Ed Faulkner, and Chris
-Krycho. The panel discussed challenges and opportunities, how we market Ember
-and where it fits in in the wider ecosystem of frontend frameworks.
+EmberFest 2022 closed with a panel about the future of Ember, moderated by Marco Otte-Witte with panelists Melanie Sumner, Chris Manson, Ed Faulkner, and Chris Krycho. The panel discussed challenges and opportunities, how we market Ember and where it fits in in the wider ecosystem of frontend frameworks.
diff --git a/src/appearances/2022-12-09-misusing-cucumber.md b/src/appearances/2022-12-09-misusing-cucumber.md
index 3077afc78a..9c1dc50d18 100644
--- a/src/appearances/2022-12-09-misusing-cucumber.md
+++ b/src/appearances/2022-12-09-misusing-cucumber.md
@@ -6,5 +6,4 @@ media: video
 channel: embereurope-q4-2022
 ---
 
-Andrey Mikhaylov explained how to test Ember apps with Cucumber at the Ember
-Europe Q4 2002 Meetup.
+Andrey Mikhaylov explained how to test Ember apps with Cucumber at the Ember Europe Q4 2002 Meetup.
diff --git a/src/appearances/2022-12-09-properly-flaky-modifiers.md b/src/appearances/2022-12-09-properly-flaky-modifiers.md
index 81fe3285da..7a53b37d2c 100644
--- a/src/appearances/2022-12-09-properly-flaky-modifiers.md
+++ b/src/appearances/2022-12-09-properly-flaky-modifiers.md
@@ -6,5 +6,4 @@ media: video
 channel: embereurope-q4-2022
 ---
 
-Florian Pichler showed how to build a snowflake effect with modifiers and Ember
-components at the last Ember Europe Q4 2022 Meetup.
+Florian Pichler showed how to build a snowflake effect with modifiers and Ember components at the last Ember Europe Q4 2022 Meetup.
diff --git a/src/appearances/2023-03-23-animations-in-ember-update.md b/src/appearances/2023-03-23-animations-in-ember-update.md
index 1f8382f62c..4c7ac34ef1 100644
--- a/src/appearances/2023-03-23-animations-in-ember-update.md
+++ b/src/appearances/2023-03-23-animations-in-ember-update.md
@@ -6,7 +6,4 @@ media: video
 channel: embereurope-q1-2023
 ---
 
-Animations in Ember are evolving! Nick Schot presented upcoming changes,
-covering different animation techniques with demos. He also shared the progress
-on a new framework he’s been working on that will make animations in Ember even
-better.
+Animations in Ember are evolving! Nick Schot presented upcoming changes, covering different animation techniques with demos. He also shared the progress on a new framework he’s been working on that will make animations in Ember even better.
diff --git a/src/appearances/2023-04-20-sending-emails-from-the-edge.md b/src/appearances/2023-04-20-sending-emails-from-the-edge.md
index 0f9599fd15..67f80728a9 100644
--- a/src/appearances/2023-04-20-sending-emails-from-the-edge.md
+++ b/src/appearances/2023-04-20-sending-emails-from-the-edge.md
@@ -6,6 +6,4 @@ media: video
 channel: rustmunich-2-2023
 ---
 
-Marco Otte-Witte explained how to run Rust code on edge functions in his talk at
-the Rust Munich Meetup. He showed how Rust, compiled to WASM, running on
-Cloudflare Workers handles submissions of [Mainmatter's contact form](/contact).
+Marco Otte-Witte explained how to run Rust code on edge functions in his talk at the Rust Munich Meetup. He showed how Rust, compiled to WASM, running on Cloudflare Workers handles submissions of [Mainmatter's contact form](/contact).
diff --git a/src/appearances/2023-09-13-continuous-deployment-workflows.md b/src/appearances/2023-09-13-continuous-deployment-workflows.md
index 6907811dfd..2623ccf241 100644
--- a/src/appearances/2023-09-13-continuous-deployment-workflows.md
+++ b/src/appearances/2023-09-13-continuous-deployment-workflows.md
@@ -6,7 +6,4 @@ media: video
 channel: stackconf-2023
 ---
 
-Marco Otte-Witte presented the main advantages of continuous deployment over
-traditional release processes, explained the essential components of a
-continuous deployment infrastructure, and discussed typical challenges as well
-as strategies to overcome them.
+Marco Otte-Witte presented the main advantages of continuous deployment over traditional release processes, explained the essential components of a continuous deployment infrastructure, and discussed typical challenges as well as strategies to overcome them.
diff --git a/src/appearances/2023-09-21-securing-the-investment.md b/src/appearances/2023-09-21-securing-the-investment.md
index d25561bfa7..fe5343b06b 100644
--- a/src/appearances/2023-09-21-securing-the-investment.md
+++ b/src/appearances/2023-09-21-securing-the-investment.md
@@ -6,7 +6,4 @@ media: video
 channel: emberfest-2023
 ---
 
-Marco Otte-Witte talked about investing into open source projects that companies
-depend on, the risks of failing to invest, and the Embroider initiative that
-Mainmatter is running with a group of sponsors to ship Embroider, Ember's new
-build system, at EmberFest 2023 in Madrid.
+Marco Otte-Witte talked about investing into open source projects that companies depend on, the risks of failing to invest, and the Embroider initiative that Mainmatter is running with a group of sponsors to ship Embroider, Ember's new build system, at EmberFest 2023 in Madrid.
diff --git a/src/appearances/2023-09-22-the-emberguides-in-french.md b/src/appearances/2023-09-22-the-emberguides-in-french.md
index 013fb7df1a..510c668aa2 100644
--- a/src/appearances/2023-09-22-the-emberguides-in-french.md
+++ b/src/appearances/2023-09-22-the-emberguides-in-french.md
@@ -6,6 +6,4 @@ media: video
 channel: emberfest-2023
 ---
 
-Marine Dunstetter walked us through the process of translating the Ember Guides
-to French and highlighted the importance of translation in making documentation
-more accessible at EmberFest 2023 in Madrid.
+Marine Dunstetter walked us through the process of translating the Ember Guides to French and highlighted the importance of translation in making documentation more accessible at EmberFest 2023 in Madrid.
diff --git a/src/appearances/2023-10-12-reasoning-about-rust.md b/src/appearances/2023-10-12-reasoning-about-rust.md
index e205ea7c6e..e0bb9ddb85 100644
--- a/src/appearances/2023-10-12-reasoning-about-rust.md
+++ b/src/appearances/2023-10-12-reasoning-about-rust.md
@@ -6,6 +6,4 @@ media: video
 channel: eurorust23
 ---
 
-Our Principal Engineering Consultant, Luca Palmieri, introduced us to Rustdoc’s
-JSON format and the possibilities that come with this new #rustlang feature in
-his talk at EuroRust 2023.
+Our Principal Engineering Consultant, Luca Palmieri, introduced us to Rustdoc’s JSON format and the possibilities that come with this new #rustlang feature in his talk at EuroRust 2023.
diff --git a/src/appearances/2023-10-25-rust-in-production-panel.md b/src/appearances/2023-10-25-rust-in-production-panel.md
index e05094c9ed..ff5365d53f 100644
--- a/src/appearances/2023-10-25-rust-in-production-panel.md
+++ b/src/appearances/2023-10-25-rust-in-production-panel.md
@@ -6,7 +6,4 @@ media: video
 channel: rustweb
 ---
 
-Our Principal Engineering Consultant, Luca Palmieri, moderated a panel on real
-world use cases and experiences with Rust in production, with panelists Jeremy
-Lempereur (Rust engineer at Apollo GraphQL), and Bastien Dolla (co-founder at
-Rayon).
+Our Principal Engineering Consultant, Luca Palmieri, moderated a panel on real world use cases and experiences with Rust in production, with panelists Jeremy Lempereur (Rust engineer at Apollo GraphQL), and Bastien Dolla (co-founder at Rayon).
diff --git a/src/appearances/2023-10-27-get-ready-to-rustle.md b/src/appearances/2023-10-27-get-ready-to-rustle.md
index 251ee4c2fa..a02b01cefb 100644
--- a/src/appearances/2023-10-27-get-ready-to-rustle.md
+++ b/src/appearances/2023-10-27-get-ready-to-rustle.md
@@ -6,5 +6,4 @@ media: video
 channel: portotechhub-2023
 ---
 
-Marco Otte-Witte talked about how Rust is the next step for backend web
-development at Porto Tech Hub 2023.
+Marco Otte-Witte talked about how Rust is the next step for backend web development at Porto Tech Hub 2023.
diff --git a/src/appearances/2023-11-11-enhance.md b/src/appearances/2023-11-11-enhance.md
index b31da49570..df2b6add9a 100644
--- a/src/appearances/2023-11-11-enhance.md
+++ b/src/appearances/2023-11-11-enhance.md
@@ -6,5 +6,4 @@ media: video
 channel: sveltesummit
 ---
 
-Paolo Ricciuti introduced us to progressive enhancement in SvelteKit at Svelte
-Summit Fall 2023.
+Paolo Ricciuti introduced us to progressive enhancement in SvelteKit at Svelte Summit Fall 2023.
diff --git a/src/appearances/2023-12-07-embroider-ama.md b/src/appearances/2023-12-07-embroider-ama.md
index a1d761e5fb..99d209ba1d 100644
--- a/src/appearances/2023-12-07-embroider-ama.md
+++ b/src/appearances/2023-12-07-embroider-ama.md
@@ -6,6 +6,4 @@ media: video
 channel: embereurope-q4-2023
 ---
 
-Chris Manson and Ed Faulkner answered questions about Embroider and previewed
-the upcoming release as well as Vite support, at the Q4 2023 Ember Europe
-meetup.
+Chris Manson and Ed Faulkner answered questions about Embroider and previewed the upcoming release as well as Vite support, at the Q4 2023 Ember Europe meetup.
diff --git a/src/appearances/2023-12-07-embroider-update.md b/src/appearances/2023-12-07-embroider-update.md
index 9a649d2ca1..3370d90e6b 100644
--- a/src/appearances/2023-12-07-embroider-update.md
+++ b/src/appearances/2023-12-07-embroider-update.md
@@ -6,6 +6,4 @@ media: video
 channel: embereurope-q4-2023
 ---
 
-Chris Manson gave an update on the Embroider Initiative's progress so far. He
-discussed Vite support, challenges the team is facing and what's coming in the
-future.
+Chris Manson gave an update on the Embroider Initiative's progress so far. He discussed Vite support, challenges the team is facing and what's coming in the future.
diff --git a/src/appearances/2024-02-07-rust-in-production-why-how.md b/src/appearances/2024-02-07-rust-in-production-why-how.md
index d28da96277..e66c34f027 100644
--- a/src/appearances/2024-02-07-rust-in-production-why-how.md
+++ b/src/appearances/2024-02-07-rust-in-production-why-how.md
@@ -1,13 +1,9 @@
 ---
 title: "Panel - Rust in Production: Why? How?"
-image: "/assets/images/talks/2024-02-07-rustweb-london/thumbnail-panel.jpg"
+image: "/assets/images/talks/2024-02-07-rustweb-london/new-thumbnail.png"
 url: https://youtu.be/ZRBayed8cLw
 media: video
 channel: rustweb-london
 ---
 
-Moderator Luca Palmieri (Principal Engineering Consultant at Mainmatter) and
-panelists ​Edward Wright (Lead GIS Engineer at Vortexa), ​Nodar Daneliya
-(Founder and CEO of Shuttle), and ​James Cole (Arwen.ai), discussed the reasons
-for choosing Rust and how they use it in production at our Rust for the Web
-meetup in London.
+Moderator Luca Palmieri (Principal Engineering Consultant at Mainmatter) and panelists ​Edward Wright (Lead GIS Engineer at Vortexa), ​Nodar Daneliya (Founder and CEO of Shuttle), and ​James Cole (Arwen.ai), discussed the reasons for choosing Rust and how they use it in production at our Rust for the Web meetup in London.
diff --git a/src/appearances/2024-02-07-rust-playbook.md b/src/appearances/2024-02-07-rust-playbook.md
index 6ef35ff4e0..23de44c83d 100644
--- a/src/appearances/2024-02-07-rust-playbook.md
+++ b/src/appearances/2024-02-07-rust-playbook.md
@@ -1,11 +1,9 @@
 ---
 title: "Adopting Rust: the missing playbook for managers and CTOs"
-image: "/assets/images/talks/2024-02-07-rustweb-london/thumbnail-luca.jpg"
+image: "/assets/images/talks/2024-02-07-rustweb-london/new-thumbnail-luca.png"
 url: https://youtu.be/Y5NIgRTTS-A
 media: video
 channel: rustweb-london
 ---
 
-Our Principal Engineering Consultant, Luca Palmieri, presented the missing
-playbook for Rust adoption for managers and CTOs at our Rust for the Web meetup
-in London.
+Our Principal Engineering Consultant, Luca Palmieri, presented the missing playbook for Rust adoption for managers and CTOs at our Rust for the Web meetup in London.
diff --git a/src/appearances/2024-03-21-embroider-update-vite.md b/src/appearances/2024-03-21-embroider-update-vite.md
index 38e2aaf024..6ed8fb8ace 100644
--- a/src/appearances/2024-03-21-embroider-update-vite.md
+++ b/src/appearances/2024-03-21-embroider-update-vite.md
@@ -1,10 +1,9 @@
 ---
 title: "Update on the Embroider Initiative (Vite 🤫)"
-image: "/assets/images/talks/2024-03-21-embereurope-2024-q1/embroider-update-talk.jpg"
+image: "/assets/images/talks/2024-03-21-embereurope-2024-q1/new-thumbnails.png"
 url: https://youtu.be/SCWpDNE0IaA
 media: video
 channel: embereurope-q1-2024
 ---
 
-Chris Manson gave an update on the Embroider Initiative's progress so far and
-showed off a real world Vite build.
+Chris Manson gave an update on the Embroider Initiative's progress so far and showed off a real world Vite build.
diff --git a/src/appearances/2024-03-26-pavex-api-development-in-rust.md b/src/appearances/2024-03-26-pavex-api-development-in-rust.md
index 1e58227cab..bdcd7b3c13 100644
--- a/src/appearances/2024-03-26-pavex-api-development-in-rust.md
+++ b/src/appearances/2024-03-26-pavex-api-development-in-rust.md
@@ -1,10 +1,9 @@
 ---
 title: "Pavex: re-imaging API development in Rust"
-image: "/assets/images/talks/2024-03-26-rustnationuk-2024/talk-thumbnail.jpg"
+image: "/assets/images/talks/2024-03-26-rustnationuk-2024/new-thumbnails.png"
 url: https://youtu.be/cMea6IMRk2s
 media: video
 channel: rustnationuk
 ---
 
-Our Principal Engineering Consultant, Luca Palmieri, talked about the state of
-Rust’s web ecosystem and his Pavex project in his talk at Rust Nation UK 2024.
+Our Principal Engineering Consultant, Luca Palmieri, talked about the state of Rust’s web ecosystem and his Pavex project in his talk at Rust Nation UK 2024.
diff --git a/src/appearances/2024-04-23-rust-panel.md b/src/appearances/2024-04-23-rust-panel.md
index 2409348bf4..1be94bb906 100644
--- a/src/appearances/2024-04-23-rust-panel.md
+++ b/src/appearances/2024-04-23-rust-panel.md
@@ -1,11 +1,9 @@
 ---
 title: "Panel discussion at Rust'n'Tell Berlin"
-image: "/assets/images/talks/2024-04-23-rust-web-berlin/thumbnail-panel.jpg"
+image: "/assets/images/talks/2024-04-23-rust-web-berlin/new-thumbnails.png"
 url: https://youtu.be/_D0IS1ftlPc
 media: video
 channel: rustweb-berlin
 ---
 
-Mainmatter's Principal Engineering Consultant Luca Palmieri, SAP's Jonas Dohse,
-and Fermyon's Ryan Levick discussed aspects of using Rust in production and
-answered questions from the audience at our Rust for the Web event in Berlin.
+Mainmatter's Principal Engineering Consultant Luca Palmieri, SAP's Jonas Dohse, and Fermyon's Ryan Levick discussed aspects of using Rust in production and answered questions from the audience at our Rust for the Web event in Berlin.
diff --git a/src/appearances/2024-04-27-fullstack-testing.md b/src/appearances/2024-04-27-fullstack-testing.md
index ec49fc6404..e8b4ea6a6b 100644
--- a/src/appearances/2024-04-27-fullstack-testing.md
+++ b/src/appearances/2024-04-27-fullstack-testing.md
@@ -1,10 +1,9 @@
 ---
 title: "Fullstack Testing SvelteKit apps"
-image: "/assets/images/talks/2024-04-27-fullstack-testing/thumbnail.jpg"
+image: "/assets/images/talks/2024-04-27-fullstack-testing/new-thumbnails.png"
 url: https://www.youtube.com/watch?v=gkJ09joGBZ4&t=6752s
 media: video
 channel: sveltesummit
 ---
 
-Paolo Ricciuti shared how to full-stack-test SvelteKit applications at Svelte
-Summit Spring 2024.
+Paolo Ricciuti shared how to full-stack-test SvelteKit applications at Svelte Summit Spring 2024.
diff --git a/src/appearances/2024-09-13-emberconf-2024.md b/src/appearances/2024-09-13-emberconf-2024.md
new file mode 100644
index 0000000000..d657997e3a
--- /dev/null
+++ b/src/appearances/2024-09-13-emberconf-2024.md
@@ -0,0 +1,9 @@
+---
+title: "Launching Ember into the Future"
+image: "/assets/images/talks/2024-09-13-emberconf-2024/new-thumbnail.png"
+url: https://www.youtube.com/watch?v=qlLWRCEDvPI
+media: video
+channel: emberconf-2024
+---
+
+Chris Manson explained how Embroider translates old "Emberisms" into modern JavaScript to use with Vite, and shared an update on the Embroider initiative in his talk at EmberConf.
diff --git a/src/appearances/2024-09-13-rust-opensource-more.md b/src/appearances/2024-09-13-rust-opensource-more.md
new file mode 100644
index 0000000000..cccbb0fbfb
--- /dev/null
+++ b/src/appearances/2024-09-13-rust-opensource-more.md
@@ -0,0 +1,9 @@
+---
+title: "Rust, Open Source, and more @ Linux Inlaws"
+image: "/assets/images/talks/2024-09-13-rust-linux-inlaws/new-thumbnail.png"
+url: https://ia802203.us.archive.org/25/items/LI_S02E14_Rustacean_Station__54D6/LI_S02E14_Rustacean_Station_.mp3
+media: video
+channel: rust-linux-inlaws
+---
+
+Mainmatter’s Founder Marco Otte-Witte was on the Linux Inlaws podcast to discuss Rust, open source, foundations, EuroRust and more.
diff --git a/src/appearances/2024-09-13-rust-panel.md b/src/appearances/2024-09-13-rust-panel.md
new file mode 100644
index 0000000000..b6c9d1cddd
--- /dev/null
+++ b/src/appearances/2024-09-13-rust-panel.md
@@ -0,0 +1,9 @@
+---
+title: "Panel discussion at Rust for the Web x BCN Rust"
+image: "/assets/images/talks/2024-09-13-rustweb-barcelona/new-thumbnail.png"
+url: https://youtu.be/3G4DPk5y6iM
+media: video
+channel: rustweb-barcelona
+---
+
+Mainmatter's Principal Engineering Consultant Luca Palmieri, Software Engineer at Matchday, Matilda Smeds, and Engineering Director at Workato, Gleb Pomykalov had a panel discussion about Rust and answered questions from the audience at our Rust for the Web event in Barcelona.
diff --git a/src/appearances/2024-10-03-viteconf.md b/src/appearances/2024-10-03-viteconf.md
new file mode 100644
index 0000000000..bc7d96e70e
--- /dev/null
+++ b/src/appearances/2024-10-03-viteconf.md
@@ -0,0 +1,9 @@
+---
+title: "Ember's Journey to Build with Vite"
+image: "/assets/images/talks/2024-10-03-viteconf/thumbnail.png"
+url: https://www.youtube.com/watch?v=Nh6S4cfehs0
+media: video
+channel: viteconf-2024
+---
+
+At ViteConf, our Ember expert Chris Manson, member of the Ember.js Core Learning and Tooling Teams, presented Ember's move to Vite for its new Embroider build system that sets the foundation for Ember's future.
diff --git a/src/assets/css/app.scss b/src/assets/css/app.scss
index 28518fb669..e6b1c38a0e 100644
--- a/src/assets/css/app.scss
+++ b/src/assets/css/app.scss
@@ -67,6 +67,7 @@
 @import "components/embroider-sponsors";
 @import "components/images-side-by-side-grid";
 @import "components/grid-event-card";
+@import "components/form-with-image";
 
 @import "animations/text-animation";
 
diff --git a/src/assets/css/base/_prism-theme.scss b/src/assets/css/base/_prism-theme.scss
index 82f58887c0..5ff6c5216f 100644
--- a/src/assets/css/base/_prism-theme.scss
+++ b/src/assets/css/base/_prism-theme.scss
@@ -98,14 +98,14 @@ pre > code {
 .token.char,
 .token.builtin,
 .token.inserted {
-  color: #03DAC5;
+  color: #a5d6ff;
 }
 .token.operator,
 .token.entity,
 .token.url,
 .language-css .token.string,
 .style .token.string {
-  color: #03DAC5;
+  color: #a5d6ff;
   background: #161b22;
 }
 .token.atrule,
diff --git a/src/assets/css/components/_contact-form.scss b/src/assets/css/components/_contact-form.scss
index 57906b3eb2..b456c65cb8 100644
--- a/src/assets/css/components/_contact-form.scss
+++ b/src/assets/css/components/_contact-form.scss
@@ -81,6 +81,23 @@ $states: "loading", "success", "error";
   transition:
     opacity 0.3s ease,
     transform 0.3s ease;
+
+  &.contact-form__label-checkbox {
+    color: var(--color-white);
+    font-weight: 700;
+    display: inline-block;
+    padding: 1rem 0;
+    font-family: inherit;
+    font-size: 100%;
+    line-height: 1.15;
+    margin: 0;
+    position: relative;
+    opacity: 1;
+    display: flex;
+    flex-direction: row;
+    align-items: baseline;
+    justify-content: flex-start;
+  }
 }
 
 .contact-form__label-required {
@@ -117,6 +134,35 @@ $states: "loading", "success", "error";
       opacity: 0;
     }
   }
+
+  &.contact-form__input-checkbox {
+    display: grid;
+    place-content: center;
+    padding: 0;
+    margin-right: 1rem;
+    -webkit-appearance: none;
+    appearance: none;
+    background-color: transparent;
+    font: inherit;
+    color: currentColor;
+    width: 1em;
+    height: 100%;
+    border: 0.15em solid currentColor;
+    border-radius: 0.15em;
+    transform: translateY(-0.075em);
+    transition: 0.3s background-color ease;
+
+    &::before {
+      content: "";
+      width: 0.5em;
+      height: 0.5em;
+      opacity: 0;
+    }
+
+    &:checked {
+      background-color: currentcolor;
+    }
+  }
 }
 
 .contact-form__select {
@@ -168,7 +214,7 @@ $states: "loading", "success", "error";
   opacity: 0;
   background-color: rgba(0, 0, 0, 0);
   text-align: center;
-  z-index: 1;
+  z-index: 2;
   pointer-events: none;
   transition:
     background-color 0.3s ease,
diff --git a/src/assets/css/components/_cta-banner.scss b/src/assets/css/components/_cta-banner.scss
index f80d467c18..7c20dadc70 100644
--- a/src/assets/css/components/_cta-banner.scss
+++ b/src/assets/css/components/_cta-banner.scss
@@ -1,5 +1,4 @@
 .cta-banner {
-  position: relative;
   z-index: 50;
 
   &--purple {
diff --git a/src/assets/css/components/_featured-case-studies.scss b/src/assets/css/components/_featured-case-studies.scss
index fdf96f40b8..d05ae004cc 100644
--- a/src/assets/css/components/_featured-case-studies.scss
+++ b/src/assets/css/components/_featured-case-studies.scss
@@ -1,5 +1,6 @@
 .featured-case-studies {
-  padding: 3rem 0 5rem;
+  margin-block-start: 3rem;
+  margin-block-end: 5rem;
 }
 
 .featured-case-studies__heading {
@@ -18,7 +19,8 @@
 
 @media (min-width: $breakpoint-m) {
   .featured-case-studies {
-    padding: 5rem 0 11rem;
+    margin-block-start: 5rem;
+    margin-block-end: 11rem;
   }
 
   .featured-case-studies__list {
diff --git a/src/assets/css/components/_form-with-image.scss b/src/assets/css/components/_form-with-image.scss
new file mode 100644
index 0000000000..553294d3a0
--- /dev/null
+++ b/src/assets/css/components/_form-with-image.scss
@@ -0,0 +1,29 @@
+.form-with-image {
+  display: flex;
+  flex-direction:column-reverse;
+}
+
+.form-with-image__form {
+  margin-top:0;
+}
+
+.form-with-image__image {
+  margin: 3rem 0 0 0;
+}
+
+.form-with-image__image img {
+  width: 100%;
+}
+
+@media (min-width: $breakpoint-m) {
+  .form-with-image {
+    display: flex;
+    flex-direction: row;
+    justify-content: space-between;
+    gap: 2.5rem;
+  }
+
+  .form-with-image__image {
+    margin: 0;
+  }
+}
diff --git a/src/assets/js/app.js b/src/assets/js/app.js
index d032502682..746e13ed08 100644
--- a/src/assets/js/app.js
+++ b/src/assets/js/app.js
@@ -14,8 +14,9 @@ if (window.location.host === "mainmatter.com") {
 const navElement = document.getElementById("nav");
 new Nav(navElement);
 
-const contactForm = document.getElementById("contact-form");
-if (contactForm) new ContactForm(contactForm);
+for (const form of document.querySelectorAll("[data-contact-form]")) {
+  new ContactForm(form);
+}
 
 const logoList = document.getElementById("logo-list");
 if (logoList) new LogoList(logoList);
diff --git a/src/assets/js/contact-form.js b/src/assets/js/contact-form.js
index df251b3513..fd66b26305 100644
--- a/src/assets/js/contact-form.js
+++ b/src/assets/js/contact-form.js
@@ -30,7 +30,7 @@ export class ContactForm {
   }
 
   sendMessage(formData) {
-    const handleError = () => {
+    const handleError = e => {
       this.updateFormState("error", "An error occurred.");
       if (window.location.host === "mainmatter.com") {
         Sentry.addBreadcrumb({
@@ -39,34 +39,45 @@ export class ContactForm {
           level: "info",
           data: formData,
         });
-        Sentry.captureException(new Error("Failed to deliver message via contact form!"));
+        Sentry.captureException(e);
       }
     };
 
     const { plausible } = window;
+    const { goal } = this.form.dataset;
     if (plausible) {
-      plausible("Contact");
+      plausible(goal);
     }
 
-    return fetch("https://contact.mainmatter.dev/send", {
-      body: JSON.stringify(formData),
+    let { action, method } = this.form.dataset;
+
+    let params = {
       cache: "no-cache",
-      headers: {
-        "Content-Type": "application/json; charset=UTF-8'",
-      },
-      method: "POST",
+      method,
       mode: "cors",
-    })
+    };
+    if (method.toLowerCase() === "get") {
+      const queryString = new URLSearchParams(formData).toString();
+      action = `${action}?${queryString}`;
+    } else {
+      params = {
+        ...params,
+        body: JSON.stringify(formData),
+        headers: {
+          "Content-Type": "application/json; charset=UTF-8'",
+        },
+      };
+    }
+
+    return fetch(action, params)
       .then(response => {
         if (response.ok) {
           this.updateFormState("success", "Message sent successfully.");
         } else {
-          handleError();
+          handleError(new Error("Failed to deliver message via contact form!"));
         }
       })
-      .catch(() => {
-        handleError();
-      });
+      .catch(handleError);
   }
 
   updateFormState(state, screenreaderAnnouncement) {
diff --git a/src/atom.njk b/src/atom.njk
index 95558e4a7c..4887ea74d5 100644
--- a/src/atom.njk
+++ b/src/atom.njk
@@ -4,7 +4,7 @@ eleventyExcludeFromCollections: true
 layout: ""
 metadata:
   title: "Mainmatter"
-  subtitle: "We are Europe’s leading mobile and web design & development consultancy. Our clients value code quality, dependability and honesty. We are trusted by Generali, Qonto, Trainline, and CLARK."
+  subtitle: "We know the code, tools, and practices that go into successful development. We partner with our clients to solve their toughest tech challenges by sharing our skills and expertise as teammates."
   language: "en"
   url: "https://mainmatter.com/"
   author:
diff --git a/src/author.njk b/src/author.njk
index f60e2a1435..311bf73c82 100644
--- a/src/author.njk
+++ b/src/author.njk
@@ -65,7 +65,7 @@ permalink: "/blog/author/{{ paged.author.fileSlug }}/{% if paged.number > 1 %}/p
 
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/authors/algo_luca.md b/src/authors/algo_luca.md
index 70c3da5e0e..9de4dfb958 100644
--- a/src/authors/algo_luca.md
+++ b/src/authors/algo_luca.md
@@ -2,5 +2,6 @@
 name: "Luca Palmieri"
 github: LukeMathWalker
 twitter: algo_luca
+mastodon: "@algo_luca@hachyderm.io"
 bio: "Principal Engineering Consultant"
 ---
diff --git a/src/authors/hdoordt.md b/src/authors/hdoordt.md
new file mode 100644
index 0000000000..8f44abb377
--- /dev/null
+++ b/src/authors/hdoordt.md
@@ -0,0 +1,6 @@
+---
+name: "Henk Oordt"
+github: hdoordt
+linkedin: hdoordt
+bio: "Senior Software Engineering Consultant"
+---
diff --git a/src/authors/marcoow.md b/src/authors/marcoow.md
index b5263b9420..001e4e48e2 100644
--- a/src/authors/marcoow.md
+++ b/src/authors/marcoow.md
@@ -3,5 +3,7 @@ name: "Marco Otte-Witte"
 github: marcoow
 twitter: marcoow
 linkedin: marco-otte-witte
+mastodon: "@marcoow@mastodon.social"
+bluesky: marcoow.bsky.social
 bio: "Founder and Managing Director of Mainmatter"
 ---
diff --git a/src/authors/nickschot.md b/src/authors/nickschot.md
index 82643d0dfc..430ee89cad 100644
--- a/src/authors/nickschot.md
+++ b/src/authors/nickschot.md
@@ -2,5 +2,7 @@
 name: "Nick Schot"
 github: nickschot
 twitter: nickschot
+bluesky: nickschot.bsky.social
+mastodon: "@nickschot@toot.community"
 bio: "Senior Software Engineer"
 ---
diff --git a/src/authors/oscard0m_.md b/src/authors/oscard0m_.md
index e70df80a5a..13831a1250 100644
--- a/src/authors/oscard0m_.md
+++ b/src/authors/oscard0m_.md
@@ -2,5 +2,6 @@
 name: "Oscar Dominguez"
 github: oscard0m
 twitter: oscard0m_
+mastodon: "@OscarDOM@mastodon.social"
 bio: "Software Engineer"
 ---
diff --git a/src/authors/paoloricciuti.md b/src/authors/paoloricciuti.md
index c695045804..3bda2795d9 100644
--- a/src/authors/paoloricciuti.md
+++ b/src/authors/paoloricciuti.md
@@ -3,7 +3,7 @@ name: "Paolo Ricciuti"
 github: paoloricciuti
 twitter: paoloricciuti
 linkedin: paolo-ricciuti-571a91187
-bio:
-  'Senior Software Engineer at Mainmatter, Co-creator of <a
-  href="https://sveltelab.dev">sveltelab.dev</a>'
+bluesky: paolo.ricciuti.me
+mastodon: "@paoloricciuti@front-end.social"
+bio: 'Senior Software Engineer at Mainmatter, Co-creator of <a href="https://sveltelab.dev">sveltelab.dev</a>'
 ---
diff --git a/src/authors/pichfl.md b/src/authors/pichfl.md
index bf309cfa95..b8f2905997 100644
--- a/src/authors/pichfl.md
+++ b/src/authors/pichfl.md
@@ -1,7 +1,8 @@
 ---
 name: "Florian Pichler"
 github: pichfl
-twitter: pichfl
 linkedin: pichfl
+mastodon: "@fp@social.lol"
+bluesky: pichfl.bsky.social
 bio: "Consultant for Technology and Design at Mainmatter"
 ---
diff --git a/src/authors/real_ate.md b/src/authors/real_ate.md
index f9346e3ea2..e2c8001af9 100644
--- a/src/authors/real_ate.md
+++ b/src/authors/real_ate.md
@@ -1,7 +1,7 @@
 ---
 name: "Chris Manson"
 github: mansona
-twitter: real_ate
 linkedin: realate
+mastodon: "@real_ate@mastodon.social"
 bio: "Senior Software Engineer, Ember Learning Core Team member"
 ---
diff --git a/src/authors/zeppelin.md b/src/authors/zeppelin.md
index a13f42c344..74ca7469d3 100644
--- a/src/authors/zeppelin.md
+++ b/src/authors/zeppelin.md
@@ -1,7 +1,7 @@
 ---
 name: "Gabor Babicz"
 github: zeppelin
-twitter: xeppelin
+mastodon: "@gabor@babicz.social"
 linkedin: xeppelin
 bio: "Senior Software Engineer"
 ---
diff --git a/src/blog.njk b/src/blog.njk
index 5d429b810c..1399c8e1d4 100644
--- a/src/blog.njk
+++ b/src/blog.njk
@@ -3,7 +3,7 @@ eleventyComputed:
   title: "Engineering, Design & Product Blog {% if pagination.pageNumber > 0 %}
     - Page {{ pagination.pageNumber + 1 }}
   {% endif %}"
-description: "Frontend and JavaScript, Svelte and Ember, Rust and WASM, Elixir and Phoenix, Product and Design: Stay on top of what's happening."
+description: "Frontend and JavaScript, Svelte and Ember, Rust and WASM, Elixir and Phoenix, Product and Design, Process and Tools: Stay on top of what's happening."
 permalink: "/blog/{% if pagination.pageNumber > 0 %}/page/{{ pagination.pageNumber + 1 }}/{% endif %}"
 layout: base
 pagination:
@@ -51,7 +51,7 @@ eleventyNavigation:
 </div>
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/calendar/2019-05-25-emberginners.md b/src/calendar/2019-05-25-emberginners.md
index abb4b6e92a..e2f1caec2a 100644
--- a/src/calendar/2019-05-25-emberginners.md
+++ b/src/calendar/2019-05-25-emberginners.md
@@ -6,6 +6,4 @@ url: https://www.meetup.com/Ember-js-Berlin/events/260668987/
 kind: meetup
 ---
 
-Mainmatter holds a JavaScript beginner workshop for women and non-binary people
-that will guide attendees through building their first web application using
-EmberJS.
+Mainmatter holds a JavaScript beginner workshop for women and non-binary people that will guide attendees through building their first web application using EmberJS.
diff --git a/src/calendar/2019-06-01-jsconfeu.md b/src/calendar/2019-06-01-jsconfeu.md
index 92046abdd4..1063b83c0f 100644
--- a/src/calendar/2019-06-01-jsconfeu.md
+++ b/src/calendar/2019-06-01-jsconfeu.md
@@ -6,5 +6,4 @@ url: https://2019.jsconf.eu
 kind: conference
 ---
 
-Our own [@jjordan_dev](https://twitter.com/jjordan_dev) will speak about
-crafting accessible web comics for everyone.
+Our own [@jjordan_dev](https://twitter.com/jjordan_dev) will speak about crafting accessible web comics for everyone.
diff --git a/src/calendar/2019-06-22-commitporto.md b/src/calendar/2019-06-22-commitporto.md
index 982cb96b5c..25b69a05d3 100644
--- a/src/calendar/2019-06-22-commitporto.md
+++ b/src/calendar/2019-06-22-commitporto.md
@@ -6,5 +6,4 @@ url: https://commitporto.com
 kind: conference
 ---
 
-Ricardo Mendes will tell a story about the JavaScript hype cycles and how
-Ember.js has managed to keep up with them.
+Ricardo Mendes will tell a story about the JavaScript hype cycles and how Ember.js has managed to keep up with them.
diff --git a/src/calendar/2019-07-10-fullstacklondon.md b/src/calendar/2019-07-10-fullstacklondon.md
index 555212d5ac..8a26e83df9 100644
--- a/src/calendar/2019-07-10-fullstacklondon.md
+++ b/src/calendar/2019-07-10-fullstacklondon.md
@@ -6,5 +6,4 @@ url: https://skillsmatter.com/conferences/11213-fullstack-london-2019-the-confer
 kind: conference
 ---
 
-Jessica Jordan will give a talk about crafting web comics for literally
-everyone.
+Jessica Jordan will give a talk about crafting web comics for literally everyone.
diff --git a/src/calendar/2019-09-19-hiveconf.md b/src/calendar/2019-09-19-hiveconf.md
index f17d22317c..07b40be6e9 100644
--- a/src/calendar/2019-09-19-hiveconf.md
+++ b/src/calendar/2019-09-19-hiveconf.md
@@ -6,5 +6,4 @@ url: http://hiveconf19.eventbrite.com
 kind: conference
 ---
 
-Jessica Jordan will be joining the panel to talk about topics around Tech and
-HR.
+Jessica Jordan will be joining the panel to talk about topics around Tech and HR.
diff --git a/src/calendar/2019-09-30-emberfest.md b/src/calendar/2019-09-30-emberfest.md
index 34fe0dcfbd..96aeab5f3e 100644
--- a/src/calendar/2019-09-30-emberfest.md
+++ b/src/calendar/2019-09-30-emberfest.md
@@ -6,6 +6,4 @@ url: https://emberfest.eu
 kind: conference
 ---
 
-EmberFest is back with a hybrid on-site/virtual event in September. We are
-co-organizing the event and our team is looking forward to meeting up with the
-Ember.js community in Rome.
+EmberFest is back with a hybrid on-site/virtual event in September. We are co-organizing the event and our team is looking forward to meeting up with the Ember.js community in Rome.
diff --git a/src/calendar/2019-10-17-emberfest.md b/src/calendar/2019-10-17-emberfest.md
index 4ddb9345b9..ad69a1e89f 100644
--- a/src/calendar/2019-10-17-emberfest.md
+++ b/src/calendar/2019-10-17-emberfest.md
@@ -6,5 +6,4 @@ url: https://emberfest.eu
 kind: conference
 ---
 
-We are co-organizing EmberFest and the team is looking forward to meeting up
-with the Ember.js community in Copenhagen.
+We are co-organizing EmberFest and the team is looking forward to meeting up with the Ember.js community in Copenhagen.
diff --git a/src/calendar/2020-03-16-emberconf.md b/src/calendar/2020-03-16-emberconf.md
index 5b0aec1e4c..c13ce9e446 100644
--- a/src/calendar/2020-03-16-emberconf.md
+++ b/src/calendar/2020-03-16-emberconf.md
@@ -6,5 +6,4 @@ url: https://emberconf.com/
 kind: conference
 ---
 
-EmberConf is the main yearly conference around all things Ember.js and the
-Mainmatter team will be present in full force, delivering workshops and talks.
+EmberConf is the main yearly conference around all things Ember.js and the Mainmatter team will be present in full force, delivering workshops and talks.
diff --git a/src/calendar/2020-06-18-banking-innovation-forum.md b/src/calendar/2020-06-18-banking-innovation-forum.md
index 46ed52a7ee..720d79db32 100644
--- a/src/calendar/2020-06-18-banking-innovation-forum.md
+++ b/src/calendar/2020-06-18-banking-innovation-forum.md
@@ -6,7 +6,4 @@ url: https://ict-solutions-events.com/2nd-annual-international-banking-innovatio
 kind: conference
 ---
 
-The Banking Innovation Forum covers the latest trends, developments and
-disrupting technology that will affect The Banking Industry. Marco Otte-Witte
-will deliver a talk about how banks and FinTechs can leverage technology to
-build better products.
+The Banking Innovation Forum covers the latest trends, developments and disrupting technology that will affect The Banking Industry. Marco Otte-Witte will deliver a talk about how banks and FinTechs can leverage technology to build better products.
diff --git a/src/calendar/2020-10-06-modern-re.md b/src/calendar/2020-10-06-modern-re.md
index be6dc52a17..8a582c645a 100644
--- a/src/calendar/2020-10-06-modern-re.md
+++ b/src/calendar/2020-10-06-modern-re.md
@@ -6,7 +6,4 @@ url: https://www.modern-re.de
 kind: conference
 ---
 
-Modern RE focusses on topics around requirements engineering and agile project
-management. Marco Otte-Witte will deliver a talk about how bad patterns in
-planning, management and project setup lead to dissatisfying results and how
-teams can avoid them.
+Modern RE focusses on topics around requirements engineering and agile project management. Marco Otte-Witte will deliver a talk about how bad patterns in planning, management and project setup lead to dissatisfying results and how teams can avoid them.
diff --git a/src/calendar/2020-10-16-emberfest.md b/src/calendar/2020-10-16-emberfest.md
index 324d891ee6..f15e3e93d1 100644
--- a/src/calendar/2020-10-16-emberfest.md
+++ b/src/calendar/2020-10-16-emberfest.md
@@ -6,6 +6,4 @@ url: https://emberfest.eu
 kind: conference
 ---
 
-EmberFest is the European Community Ember Conference. While there will be no
-actual conference in 2020, Chris Manson and Ricardo Mendes will lead a remote
-Ember.js contributor workshop.
+EmberFest is the European Community Ember Conference. While there will be no actual conference in 2020, Chris Manson and Ricardo Mendes will lead a remote Ember.js contributor workshop.
diff --git a/src/calendar/2020-11-26-womentechmakers.md b/src/calendar/2020-11-26-womentechmakers.md
index 0cb2683236..ac095c7b80 100644
--- a/src/calendar/2020-11-26-womentechmakers.md
+++ b/src/calendar/2020-11-26-womentechmakers.md
@@ -1,22 +1,11 @@
 ---
-title:
-  "[Women Techmakers Berlin] Version control in design: best practices for
-  collaboration"
+title: "[Women Techmakers Berlin] Version control in design: best practices for collaboration"
 image: "/assets/images/calendar/2020-11-26-womentechmakers/logo.svg"
 location: Remote
 url: https://www.meetup.com/Women-Techmakers-Berlin/events/274409725/
 kind: meetup
 ---
 
-Women Techmakers Berlin has been encouraging diversity in tech in Berlin
-since 2015. They strive for visibility, networking and resources to make the
-tech community of Berlin inclusive. They are one of the most active chapters of
-the global Women Techmakers program run by Google.
+Women Techmakers Berlin has been encouraging diversity in tech in Berlin since 2015. They strive for visibility, networking and resources to make the tech community of Berlin inclusive. They are one of the most active chapters of the global Women Techmakers program run by Google.
 
-On November 26th, Mar High will be giving a talk about version control in
-design. Version control systems (VCS) have long been used by software engineers
-to manage their codebases and collaborate effectively. In this talk, Mar will
-explore best practices of VCS as they apply to user interface design, go over a
-brief history, and analyze strengths and limitations of the most popular UI
-design programs (Sketch & Adobe XD with Abstract, and Figma with Version
-History).
+On November 26th, Mar High will be giving a talk about version control in design. Version control systems (VCS) have long been used by software engineers to manage their codebases and collaborate effectively. In this talk, Mar will explore best practices of VCS as they apply to user interface design, go over a brief history, and analyze strengths and limitations of the most popular UI design programs (Sketch & Adobe XD with Abstract, and Figma with Version History).
diff --git a/src/calendar/2020-12-10-onproduct.md b/src/calendar/2020-12-10-onproduct.md
index 0dbefebbbd..f6c7346250 100644
--- a/src/calendar/2020-12-10-onproduct.md
+++ b/src/calendar/2020-12-10-onproduct.md
@@ -1,20 +1,11 @@
 ---
-title:
-  "[OnProduct #26] Version control in design: best practices for collaboration"
+title: "[OnProduct #26] Version control in design: best practices for collaboration"
 image: "/assets/images/calendar/2020-12-10-onproduct/logo.svg"
 location: Remote
 url: https://www.meetup.com/OnProduct/events/274647325
 kind: meetup
 ---
 
-OnProduct is a meetup for product people in Berlin. Their goal is to create a
-living community of designers, product managers, developers, QA engineers that
-exchange ideas, best practices and know how.
+OnProduct is a meetup for product people in Berlin. Their goal is to create a living community of designers, product managers, developers, QA engineers that exchange ideas, best practices and know how.
 
-In case you miss the previous presentation, Mar High will share once again give
-a talk about version control in design on December 10th. Version control systems
-(VCS) have long been used by software engineers to manage their codebases and
-collaborate effectively. In this talk, Mar will explore best practices of VCS as
-they apply to user interface design, go over a brief history, and analyze
-strengths and limitations of the most popular UI design programs (Sketch & Adobe
-XD with Abstract, and Figma with Version History).
+In case you miss the previous presentation, Mar High will share once again give a talk about version control in design on December 10th. Version control systems (VCS) have long been used by software engineers to manage their codebases and collaborate effectively. In this talk, Mar will explore best practices of VCS as they apply to user interface design, go over a brief history, and analyze strengths and limitations of the most popular UI design programs (Sketch & Adobe XD with Abstract, and Figma with Version History).
diff --git a/src/calendar/2020-12-10-product-circle-london.md b/src/calendar/2020-12-10-product-circle-london.md
index 4aa64d2296..0ad6f9587f 100644
--- a/src/calendar/2020-12-10-product-circle-london.md
+++ b/src/calendar/2020-12-10-product-circle-london.md
@@ -1,21 +1,11 @@
 ---
-title:
-  "[Product Circle London] The three pillars of effective digital product
-  development"
+title: "[Product Circle London] The three pillars of effective digital product development"
 image: "/assets/images/calendar/2020-12-10-product-circle-london/logo.png"
 location: Remote
 url: https://www.meetup.com/Product-Circle/events/274691004/
 kind: meetup
 ---
 
-Product Circle is an opportunity for all PMO's, Product Owners, Project
-Managers, Delivery Leads, and anyone involved in a Digital Product / Project
-team to come and network as well as to discuss trends and topics.
+Product Circle is an opportunity for all PMO's, Product Owners, Project Managers, Delivery Leads, and anyone involved in a Digital Product / Project team to come and network as well as to discuss trends and topics.
 
-Mainmatter's founder and CEO Marco Otte-Witte will present at Product Circle's
-Christmas Special and deliver a talk about the three pillars of effective
-digital product development. In the talk, Marco will explain how successful
-projects are scoped, planned and executed as well as what techniques and
-strategies to avoid. He will also dive deep into how successful product teams
-are structured and what is needed to establish an efficient infrastructure that
-will support ambitious projects sustainably.
+Mainmatter's founder and CEO Marco Otte-Witte will present at Product Circle's Christmas Special and deliver a talk about the three pillars of effective digital product development. In the talk, Marco will explain how successful projects are scoped, planned and executed as well as what techniques and strategies to avoid. He will also dive deep into how successful product teams are structured and what is needed to establish an efficient infrastructure that will support ambitious projects sustainably.
diff --git a/src/calendar/2021-03-29-emberconf.md b/src/calendar/2021-03-29-emberconf.md
index 0738ab88c6..f6a899c4f7 100644
--- a/src/calendar/2021-03-29-emberconf.md
+++ b/src/calendar/2021-03-29-emberconf.md
@@ -6,5 +6,4 @@ url: https://emberconf.com/
 kind: conference
 ---
 
-EmberConf 2021 is going virtual again and will be live-streamed everywhere. The
-Mainmatter team will be around like every year, delivering workshops and talks.
+EmberConf 2021 is going virtual again and will be live-streamed everywhere. The Mainmatter team will be around like every year, delivering workshops and talks.
diff --git a/src/calendar/2022-09-22-emberfest.md b/src/calendar/2022-09-22-emberfest.md
index 070d02037d..e3a4c48621 100644
--- a/src/calendar/2022-09-22-emberfest.md
+++ b/src/calendar/2022-09-22-emberfest.md
@@ -7,9 +7,4 @@ kind: conference
 color: purple
 ---
 
-EmberFest is the European Community Ember Conference happening in Paris, from
-the 22nd to the 23rd of September. If you’re looking for updates on the latest
-and greatest in Ember and Glimmer this is the place to be. EmberFest is also a
-great opportunity to get in touch with the European Ember Community (and friends
-from abroad) and hiring Ember talent. Like every year, we’re happy to be
-co-organizing the event!
+EmberFest is the European Community Ember Conference happening in Paris, from the 22nd to the 23rd of September. If you’re looking for updates on the latest and greatest in Ember and Glimmer this is the place to be. EmberFest is also a great opportunity to get in touch with the European Ember Community (and friends from abroad) and hiring Ember talent. Like every year, we’re happy to be co-organizing the event!
diff --git a/src/calendar/2022-10-13-eurorust.md b/src/calendar/2022-10-13-eurorust.md
index 0c275a3ccc..69a1af3be8 100644
--- a/src/calendar/2022-10-13-eurorust.md
+++ b/src/calendar/2022-10-13-eurorust.md
@@ -7,6 +7,4 @@ kind: conference
 color: aqua
 ---
 
-EuroRust is a 2 day conference for the European Rust community, organized by
-Mainmatter. We cover all things Rust: from Rust patterns and idioms to systems
-programming and CLI tooling, servers WASM, and embedded systems.
+EuroRust is a 2 day conference for the European Rust community, organized by Mainmatter. We cover all things Rust: from Rust patterns and idioms to systems programming and CLI tooling, servers WASM, and embedded systems.
diff --git a/src/calendar/2022-12-08-embereurope-london.md b/src/calendar/2022-12-08-embereurope-london.md
index 1333e914c3..00d05092a9 100644
--- a/src/calendar/2022-12-08-embereurope-london.md
+++ b/src/calendar/2022-12-08-embereurope-london.md
@@ -7,8 +7,4 @@ kind: meetup
 color: aqua
 ---
 
-Ember Europe is back in Q4 with the last event for the year, this time hosted by
-CrowdStrike in London. The Ember Europe meetup series brings together the Ember
-community from all of Europe once a quarter. The meetup is organized by
-Mainmatter and Intercom as a hybrid event, hosted from a different city each
-time with the option for people to join remotely as well.
+Ember Europe is back in Q4 with the last event for the year, this time hosted by CrowdStrike in London. The Ember Europe meetup series brings together the Ember community from all of Europe once a quarter. The meetup is organized by Mainmatter and Intercom as a hybrid event, hosted from a different city each time with the option for people to join remotely as well.
diff --git a/src/calendar/2023-03-23-embereurope-ghent.md b/src/calendar/2023-03-23-embereurope-ghent.md
index 8d02c96b33..be5b2edc8b 100644
--- a/src/calendar/2023-03-23-embereurope-ghent.md
+++ b/src/calendar/2023-03-23-embereurope-ghent.md
@@ -7,7 +7,4 @@ kind: meetup
 color: purple
 ---
 
-Ember Europe is back in 2023 with the first meetup of the year, hosted by OTA
-Insight in Ghent, Belgium. The Ember Europe meetup series brings together the
-Ember community from all of Europe once a quarter. The meetup is organized by
-Mainmatter and Intercom.
+Ember Europe is back in 2023 with the first meetup of the year, hosted by OTA Insight in Ghent, Belgium. The Ember Europe meetup series brings together the Ember community from all of Europe once a quarter. The meetup is organized by Mainmatter and Intercom.
diff --git a/src/calendar/2023-04-20-elixirconf-eu.md b/src/calendar/2023-04-20-elixirconf-eu.md
index 7bed1450c4..9bd948d933 100644
--- a/src/calendar/2023-04-20-elixirconf-eu.md
+++ b/src/calendar/2023-04-20-elixirconf-eu.md
@@ -7,7 +7,4 @@ kind: conference
 color: aqua
 ---
 
-ElixirConf is a 2-day hybrid conference, gathering hundreds of developers with a
-passion for Elixir to learn about, share and inspire the progression of the
-Elixir ecosystem. Mainmatter will be supporting the conference as a silver
-sponsor!
+ElixirConf is a 2-day hybrid conference, gathering hundreds of developers with a passion for Elixir to learn about, share and inspire the progression of the Elixir ecosystem. Mainmatter will be supporting the conference as a silver sponsor!
diff --git a/src/calendar/2023-04-20-rust-munich.md b/src/calendar/2023-04-20-rust-munich.md
index a36f539240..acea33a335 100644
--- a/src/calendar/2023-04-20-rust-munich.md
+++ b/src/calendar/2023-04-20-rust-munich.md
@@ -7,5 +7,4 @@ kind: meetup
 color: purple
 ---
 
-The next Rust meetup for Rust fans in and around Munich is happening on the 20th
-of April. The meetup is hosted by Mainmatter at our office.
+The next Rust meetup for Rust fans in and around Munich is happening on the 20th of April. The meetup is hosted by Mainmatter at our office.
diff --git a/src/calendar/2023-05-08-magdeburger-developer-days.md b/src/calendar/2023-05-08-magdeburger-developer-days.md
index 5cc57ccbda..47c8dd73b6 100644
--- a/src/calendar/2023-05-08-magdeburger-developer-days.md
+++ b/src/calendar/2023-05-08-magdeburger-developer-days.md
@@ -7,9 +7,4 @@ kind: conference
 color: aqua
 ---
 
-Magdeburger Developer Days is a 3-day software engineering conference in
-Magdeburg. Mainmatter Founder Marco Otte-Witte will talk about Continuous
-Deployment Workflows. He will present main advantages compared to classical
-processes, explain the essential components of such a process (especially with
-regard to testing and automation), and discuss typical challenges and strategies
-to overcome them.
+Magdeburger Developer Days is a 3-day software engineering conference in Magdeburg. Mainmatter Founder Marco Otte-Witte will talk about Continuous Deployment Workflows. He will present main advantages compared to classical processes, explain the essential components of such a process (especially with regard to testing and automation), and discuss typical challenges and strategies to overcome them.
diff --git a/src/calendar/2023-05-25-devdays-europe.md b/src/calendar/2023-05-25-devdays-europe.md
index d2c6027266..2b22e86ea4 100644
--- a/src/calendar/2023-05-25-devdays-europe.md
+++ b/src/calendar/2023-05-25-devdays-europe.md
@@ -7,9 +7,4 @@ kind: conference
 color: purple
 ---
 
-DevDays Europe is a 2-day software development conference covering the emerging
-technologies and best practices in the software development industry –
-regardless of technological platform or language. Mainmatter Founder Marco
-Otte-Witte will discuss the state of the web development ecosystem for Rust, the
-challenges that come with adopting it, and share some real-world examples to
-show what’s possible in his talk "Get Ready to Rustle".
+DevDays Europe is a 2-day software development conference covering the emerging technologies and best practices in the software development industry – regardless of technological platform or language. Mainmatter Founder Marco Otte-Witte will discuss the state of the web development ecosystem for Rust, the challenges that come with adopting it, and share some real-world examples to show what’s possible in his talk "Get Ready to Rustle".
diff --git a/src/calendar/2023-06-15-embereurope-dublin.md b/src/calendar/2023-06-15-embereurope-dublin.md
index 33dd3d5350..b687e9ebe3 100644
--- a/src/calendar/2023-06-15-embereurope-dublin.md
+++ b/src/calendar/2023-06-15-embereurope-dublin.md
@@ -7,7 +7,4 @@ kind: meetup
 color: purple
 ---
 
-The second Ember Europe meetup of 2023 is happening on June 15th and is hosted
-by Intercom at their Dublin office. The Ember Europe meetup series brings
-together the Ember community from all of Europe once a quarter. The meetup is
-organized by Mainmatter and Intercom.
+The second Ember Europe meetup of 2023 is happening on June 15th and is hosted by Intercom at their Dublin office. The Ember Europe meetup series brings together the Ember community from all of Europe once a quarter. The meetup is organized by Mainmatter and Intercom.
diff --git a/src/calendar/2023-07-20-emberconf.md b/src/calendar/2023-07-20-emberconf.md
index 55118f5b42..bb14ebb2f2 100644
--- a/src/calendar/2023-07-20-emberconf.md
+++ b/src/calendar/2023-07-20-emberconf.md
@@ -7,6 +7,4 @@ kind: conference
 color: aqua
 ---
 
-EmberConf is a 2-day Ember.js conference, taking place in Portland and online on
-July 20th-21st. Nick Schot will be giving a workshop on animating Ember apps,
-and Chris Manson will show how to build a modern Ember Addon.
+EmberConf is a 2-day Ember.js conference, taking place in Portland and online on July 20th-21st. Nick Schot will be giving a workshop on animating Ember apps, and Chris Manson will show how to build a modern Ember Addon.
diff --git a/src/calendar/2023-07-27-wearedevelopers.md b/src/calendar/2023-07-27-wearedevelopers.md
index 2036b4ac23..4061f5ab47 100644
--- a/src/calendar/2023-07-27-wearedevelopers.md
+++ b/src/calendar/2023-07-27-wearedevelopers.md
@@ -7,9 +7,4 @@ kind: conference
 color: purple
 ---
 
-WeAreDevelopers World Congress is a 2-day conference and the best place to get a
-complete overview of recent insights and future trends in modern software
-development. Mainmatter Founder Marco Otte-Witte will discuss the state of the
-web development ecosystem for Rust, the challenges that come with adopting it,
-and share some real-world examples to show what’s possible in his talk "Get
-Ready to Rustle".
+WeAreDevelopers World Congress is a 2-day conference and the best place to get a complete overview of recent insights and future trends in modern software development. Mainmatter Founder Marco Otte-Witte will discuss the state of the web development ecosystem for Rust, the challenges that come with adopting it, and share some real-world examples to show what’s possible in his talk "Get Ready to Rustle".
diff --git a/src/calendar/2023-07-29-coscup.md b/src/calendar/2023-07-29-coscup.md
index 73656b116d..a62622c027 100644
--- a/src/calendar/2023-07-29-coscup.md
+++ b/src/calendar/2023-07-29-coscup.md
@@ -7,7 +7,4 @@ kind: conference
 color: aqua
 ---
 
-COSCUP is a 2-day conference for Open Source coders, users, and promoters taking
-place in Taipei on July 29-30. Luca Palmieri will share his experience writing
-“Zero to Production in Rust” covering all aspects from topic definition to
-marketing and distribution of a technical book.
+COSCUP is a 2-day conference for Open Source coders, users, and promoters taking place in Taipei on July 29-30. Luca Palmieri will share his experience writing “Zero to Production in Rust” covering all aspects from topic definition to marketing and distribution of a technical book.
diff --git a/src/calendar/2023-09-13-stackconf.md b/src/calendar/2023-09-13-stackconf.md
index 184148fa87..8b4960b14a 100644
--- a/src/calendar/2023-09-13-stackconf.md
+++ b/src/calendar/2023-09-13-stackconf.md
@@ -7,9 +7,4 @@ kind: conference
 color: purple
 ---
 
-stackconf is a 2-day Open Source Infrastructure conference, covering solutions
-in the spectrum of continuous integration, container, hybrid and cloud
-technologies. Mainmatter's Founder Marco Otte-Witte will discuss the main
-advantages of continuous deployment over traditional release processes, explain
-the essential components of a continuous deployment infrastructure, and discuss
-typical challenges and strategies to overcome them in his talk.
+stackconf is a 2-day Open Source Infrastructure conference, covering solutions in the spectrum of continuous integration, container, hybrid and cloud technologies. Mainmatter's Founder Marco Otte-Witte will discuss the main advantages of continuous deployment over traditional release processes, explain the essential components of a continuous deployment infrastructure, and discuss typical challenges and strategies to overcome them in his talk.
diff --git a/src/calendar/2023-09-21-emberfest.md b/src/calendar/2023-09-21-emberfest.md
index 88e846eb08..55e89557e7 100644
--- a/src/calendar/2023-09-21-emberfest.md
+++ b/src/calendar/2023-09-21-emberfest.md
@@ -7,9 +7,4 @@ kind: conference
 color: aqua
 ---
 
-EmberFest is the European Community Ember Conference, this year happening in
-Madrid, from September 22nd to 23rd. If you’re looking for updates on the latest
-and greatest in Ember and Glimmer this is the place to be. EmberFest is also a
-great opportunity to get in touch with the European Ember Community (and friends
-from abroad) and hiring Ember talent. Mainmatter is co-organizing the event and
-our team will be in Madrid in full force!
+EmberFest is the European Community Ember Conference, this year happening in Madrid, from September 22nd to 23rd. If you’re looking for updates on the latest and greatest in Ember and Glimmer this is the place to be. EmberFest is also a great opportunity to get in touch with the European Ember Community (and friends from abroad) and hiring Ember talent. Mainmatter is co-organizing the event and our team will be in Madrid in full force!
diff --git a/src/calendar/2023-10-12-eurorust.md b/src/calendar/2023-10-12-eurorust.md
index 29afb4c19f..bacdd4ab24 100644
--- a/src/calendar/2023-10-12-eurorust.md
+++ b/src/calendar/2023-10-12-eurorust.md
@@ -7,6 +7,4 @@ kind: conference
 color: aqua
 ---
 
-EuroRust is a 2 day conference for the European Rust community, organized by
-Mainmatter. We cover all things Rust: from Rust patterns and idioms to systems
-programming and CLI tooling, servers WASM, and embedded systems.
+EuroRust is a 2 day conference for the European Rust community, organized by Mainmatter. We cover all things Rust: from Rust patterns and idioms to systems programming and CLI tooling, servers WASM, and embedded systems.
diff --git a/src/calendar/2023-10-25-rust-on-the-web.md b/src/calendar/2023-10-25-rust-on-the-web.md
index 6208caab81..d9bdf64f4e 100644
--- a/src/calendar/2023-10-25-rust-on-the-web.md
+++ b/src/calendar/2023-10-25-rust-on-the-web.md
@@ -7,8 +7,4 @@ kind: meetup
 color: purple
 ---
 
-We are running a meetup together with the Rust Paris meetup group to talk about
-Rust for web and cloud applications. The event will be hosted by our friends at
-Qonto in their office in Paris. Our Principal Engineering Consultant, Luca
-Palmieri, will be moderating a panel on real world use cases and experiences
-with Rust in production.
+We are running a meetup together with the Rust Paris meetup group to talk about Rust for web and cloud applications. The event will be hosted by our friends at Qonto in their office in Paris. Our Principal Engineering Consultant, Luca Palmieri, will be moderating a panel on real world use cases and experiences with Rust in production.
diff --git a/src/calendar/2023-10-27-portotechhub.md b/src/calendar/2023-10-27-portotechhub.md
index d1075ddbaf..2ae7e806ef 100644
--- a/src/calendar/2023-10-27-portotechhub.md
+++ b/src/calendar/2023-10-27-portotechhub.md
@@ -7,8 +7,4 @@ kind: conference
 color: purple
 ---
 
-Porto Tech Hub is the biggest tech conference in Porto, taking place on October
-27th in Alfândega do Porto. Mainmatter Founder Marco Otte-Witte will discuss the
-state of the web development ecosystem for Rust, the challenges that come with
-adopting it, and share some real-world examples to show what’s possible in his
-talk "Get Ready to Rustle".
+Porto Tech Hub is the biggest tech conference in Porto, taking place on October 27th in Alfândega do Porto. Mainmatter Founder Marco Otte-Witte will discuss the state of the web development ecosystem for Rust, the challenges that come with adopting it, and share some real-world examples to show what’s possible in his talk "Get Ready to Rustle".
diff --git a/src/calendar/2023-11-11-svelte-summit.md b/src/calendar/2023-11-11-svelte-summit.md
index 87c29768fd..5aea45e56f 100644
--- a/src/calendar/2023-11-11-svelte-summit.md
+++ b/src/calendar/2023-11-11-svelte-summit.md
@@ -7,7 +7,4 @@ kind: summit
 color: aqua
 ---
 
-Svelte Summit is an online conference dedicated to Svelte and everything that is
-happening in the community. Mainmatter's Svelte expert Paolo Ricciuti will talk
-about progressive enhancements in SvelteKit in his talk "Enhance!!!" and we are
-supporting the event as a Gold Sponsor as well.
+Svelte Summit is an online conference dedicated to Svelte and everything that is happening in the community. Mainmatter's Svelte expert Paolo Ricciuti will talk about progressive enhancements in SvelteKit in his talk "Enhance!!!" and we are supporting the event as a Gold Sponsor as well.
diff --git a/src/calendar/2023-11-19-rustlabit.md b/src/calendar/2023-11-19-rustlabit.md
index 0b74489fd0..75e77b69e3 100644
--- a/src/calendar/2023-11-19-rustlabit.md
+++ b/src/calendar/2023-11-19-rustlabit.md
@@ -7,7 +7,4 @@ kind: conference
 color: purple
 ---
 
-RustLab is an international Rust conference taking place annually over the
-course of two days: this year's event is hosted in Florence. Mainmatter's
-Principal Engineering Consultant Luca Palmieri will discuss the current state
-and shortcomings of pavex, a new Rust framework for building APIs, in his talk.
+RustLab is an international Rust conference taking place annually over the course of two days: this year's event is hosted in Florence. Mainmatter's Principal Engineering Consultant Luca Palmieri will discuss the current state and shortcomings of pavex, a new Rust framework for building APIs, in his talk.
diff --git a/src/calendar/2023-11-22-shsession.md b/src/calendar/2023-11-22-shsession.md
index 3c6c654e29..7a4852bb5b 100644
--- a/src/calendar/2023-11-22-shsession.md
+++ b/src/calendar/2023-11-22-shsession.md
@@ -7,7 +7,4 @@ kind: meetup
 color: aqua
 ---
 
-Schrodinger Session is a meetup series fully accessible and free for everyone,
-organized by Schrödinger Hat. Mainmatter's Principal Engineering Consultant Luca
-Palmieri will host the workshop "Learning Rust, one exercise at a time!",
-covering all core concepts of the Rust programming language.
+Schrodinger Session is a meetup series fully accessible and free for everyone, organized by Schrödinger Hat. Mainmatter's Principal Engineering Consultant Luca Palmieri will host the workshop "Learning Rust, one exercise at a time!", covering all core concepts of the Rust programming language.
diff --git a/src/calendar/2023-12-07-embereurope-remote.md b/src/calendar/2023-12-07-embereurope-remote.md
index 426b54a2c7..38e39afc83 100644
--- a/src/calendar/2023-12-07-embereurope-remote.md
+++ b/src/calendar/2023-12-07-embereurope-remote.md
@@ -7,9 +7,4 @@ kind: meetup
 color: purple
 ---
 
-The final Ember Europe meetup of 2023 is happening on December 7th and will be
-fully remote. Our Chris Manson will give an update on the progress made with the
-Embroider initiative and answer questions in an Embroider AMA session together
-with Ed Faulkner. The Ember Europe meetup series brings together the Ember
-community from all of Europe once a quarter. The meetup is organized by
-Mainmatter and Intercom.
+The final Ember Europe meetup of 2023 is happening on December 7th and will be fully remote. Our Chris Manson will give an update on the progress made with the Embroider initiative and answer questions in an Embroider AMA session together with Ed Faulkner. The Ember Europe meetup series brings together the Ember community from all of Europe once a quarter. The meetup is organized by Mainmatter and Intercom.
diff --git a/src/calendar/2023-12-11-ittage.md b/src/calendar/2023-12-11-ittage.md
index bfe4bf6325..4e20ed900c 100644
--- a/src/calendar/2023-12-11-ittage.md
+++ b/src/calendar/2023-12-11-ittage.md
@@ -7,7 +7,4 @@ kind: conference
 color: aqua
 ---
 
-Learn about the essential components of Continuous Deployment Workflows, their
-main advantages, and typical challenges along with the strategies to overcome
-them in Marco Otte-Witte's talk at IT-Tage. IT-Tage is a 4-day IT conference
-happening in Frankfurt.
+Learn about the essential components of Continuous Deployment Workflows, their main advantages, and typical challenges along with the strategies to overcome them in Marco Otte-Witte's talk at IT-Tage. IT-Tage is a 4-day IT conference happening in Frankfurt.
diff --git a/src/calendar/2023-12-12-telemetry-rust-workshop.md b/src/calendar/2023-12-12-telemetry-rust-workshop.md
index 88e3b04fe0..7523d77317 100644
--- a/src/calendar/2023-12-12-telemetry-rust-workshop.md
+++ b/src/calendar/2023-12-12-telemetry-rust-workshop.md
@@ -7,6 +7,4 @@ kind: workshop
 color: aqua
 ---
 
-We are running a remote Rust Telemetry workshop over two afternoons in December.
-Host Luca Palmieri will introduce you to a comprehensive toolkit to detect,
-troubleshoot and resolve issues in your Rust applications.
+We are running a remote Rust Telemetry workshop over two afternoons in December. Host Luca Palmieri will introduce you to a comprehensive toolkit to detect, troubleshoot and resolve issues in your Rust applications.
diff --git a/src/calendar/2024-01-24-rust-day.md b/src/calendar/2024-01-24-rust-day.md
index a6aeb646b9..9399640c77 100644
--- a/src/calendar/2024-01-24-rust-day.md
+++ b/src/calendar/2024-01-24-rust-day.md
@@ -7,7 +7,4 @@ kind: conference
 color: purple
 ---
 
-Rust Day is an online event organized by WeAreDevelopers and fully dedicated to
-Rust. Mainmatter's Principal Engineering Consultant Luca Palmieri will give an
-introduction to Rustdoc's JSON format and discuss some of its possible usecases
-in his talk.
+Rust Day is an online event organized by WeAreDevelopers and fully dedicated to Rust. Mainmatter's Principal Engineering Consultant Luca Palmieri will give an introduction to Rustdoc's JSON format and discuss some of its possible usecases in his talk.
diff --git a/src/calendar/2024-01-30-svelte-workshop.md b/src/calendar/2024-01-30-svelte-workshop.md
index ff35676088..64c4c17505 100644
--- a/src/calendar/2024-01-30-svelte-workshop.md
+++ b/src/calendar/2024-01-30-svelte-workshop.md
@@ -7,7 +7,4 @@ kind: workshop
 color: purple
 ---
 
-We are running a remote hands-on Svelte and SvelteKit workshop over three
-afternoons from January 30th to February 1st. Hosts Florian Pichler and Paolo
-Ricciuti take participants through the entire process of building a real-world,
-progressively enhanced SvelteKit application.
+We are running a remote hands-on Svelte and SvelteKit workshop over three afternoons from January 30th to February 1st. Hosts Florian Pichler and Paolo Ricciuti take participants through the entire process of building a real-world, progressively enhanced SvelteKit application.
diff --git a/src/calendar/2024-02-07-rust-for-the-web.md b/src/calendar/2024-02-07-rust-for-the-web.md
index 5521ad3a20..dbbab4126f 100644
--- a/src/calendar/2024-02-07-rust-for-the-web.md
+++ b/src/calendar/2024-02-07-rust-for-the-web.md
@@ -7,9 +7,4 @@ kind: meetup
 color: purple
 ---
 
-We are running an event together with Shuttle, Vortexa, and the Rust London
-meetup group focused on using Rust for web development. The event will be hosted
-by TrueLayer in London on Feb. 7th, 2024. Our Principal Engineering Consultant,
-Luca Palmieri, will present the playbook for successful Rust adoption as well as
-moderate a panel talking about success stories and challenges with David Cole
-from Arwen.ai and Nodar Daneliya from Shuttle.
+We are running an event together with Shuttle, Vortexa, and the Rust London meetup group focused on using Rust for web development. The event will be hosted by TrueLayer in London on Feb. 7th, 2024. Our Principal Engineering Consultant, Luca Palmieri, will present the playbook for successful Rust adoption as well as moderate a panel talking about success stories and challenges with David Cole from Arwen.ai and Nodar Daneliya from Shuttle.
diff --git a/src/calendar/2024-02-23-svelte-workshop.md b/src/calendar/2024-02-23-svelte-workshop.md
index b63fae4e4c..0c440d930d 100644
--- a/src/calendar/2024-02-23-svelte-workshop.md
+++ b/src/calendar/2024-02-23-svelte-workshop.md
@@ -7,6 +7,4 @@ kind: workshop
 color: purple
 ---
 
-We are running a free, one-day, Svelte and SvelteKit introductory workshop in
-Munich, hosted by our friends at Experteer in their office. The workshop is held
-by Svelte Ambassador Paolo Ricciuti and Mainmatter's Founder Marco Otte-Witte.
+We are running a free, one-day, Svelte and SvelteKit introductory workshop in Munich, hosted by our friends at Experteer in their office. The workshop is held by Svelte Ambassador Paolo Ricciuti and Mainmatter's Founder Marco Otte-Witte.
diff --git a/src/calendar/2024-02-29-devworld.md b/src/calendar/2024-02-29-devworld.md
index 66b679c47b..c893d6aa5b 100644
--- a/src/calendar/2024-02-29-devworld.md
+++ b/src/calendar/2024-02-29-devworld.md
@@ -7,6 +7,4 @@ kind: conference
 color: aqua
 ---
 
-DevWorld is a 2-Day Festival of Tech with Developers from around the Planet,
-taking place in Amsterdam on February 29th to March 1st. Mainmatter's Principal
-Engineering Consultant Luca Palmieri will give a talk on Rust for Backend.
+DevWorld is a 2-Day Festival of Tech with Developers from around the Planet, taking place in Amsterdam on February 29th to March 1st. Mainmatter's Principal Engineering Consultant Luca Palmieri will give a talk on Rust for Backend.
diff --git a/src/calendar/2024-03-21-embereurope-remote.md b/src/calendar/2024-03-21-embereurope-remote.md
index fde526ec83..763bd92eae 100644
--- a/src/calendar/2024-03-21-embereurope-remote.md
+++ b/src/calendar/2024-03-21-embereurope-remote.md
@@ -7,8 +7,4 @@ kind: meetup
 color: purple
 ---
 
-The first Ember Europe meetup of 2024 is taking place remotely on March 21st.
-Our Chris Manson will give an update on the progress made with the Embroider
-initiative and show the current state of Vite support with Embroider. The Ember
-Europe meetup series brings together the Ember community from all of Europe once
-a quarter. The meetup is organized by Mainmatter.
+The first Ember Europe meetup of 2024 is taking place remotely on March 21st. Our Chris Manson will give an update on the progress made with the Embroider initiative and show the current state of Vite support with Embroider. The Ember Europe meetup series brings together the Ember community from all of Europe once a quarter. The meetup is organized by Mainmatter.
diff --git a/src/calendar/2024-03-26-rust-nation.md b/src/calendar/2024-03-26-rust-nation.md
index c86e0f4b4a..4e4c3c0ef4 100644
--- a/src/calendar/2024-03-26-rust-nation.md
+++ b/src/calendar/2024-03-26-rust-nation.md
@@ -7,9 +7,4 @@ kind: conference
 color: aqua
 ---
 
-Rust Nation is the first UK conference dedicated to the Rust language. It will
-be held in London on March 26th to 28th. Mainmatter's Principal Engineering
-Consultant Luca Palmieri will discuss the current state of Rust's web ecosystem
-and the reasons for starting pavex, a new Rust framework for building APIs, in
-his talk. Luca will also host the expert workshop "Testing for Rust projects:
-going beyond the basics".
+Rust Nation is the first UK conference dedicated to the Rust language. It will be held in London on March 26th to 28th. Mainmatter's Principal Engineering Consultant Luca Palmieri will discuss the current state of Rust's web ecosystem and the reasons for starting pavex, a new Rust framework for building APIs, in his talk. Luca will also host the expert workshop "Testing for Rust projects: going beyond the basics".
diff --git a/src/calendar/2024-04-15-testing-for-rust-projects.md b/src/calendar/2024-04-15-testing-for-rust-projects.md
index 3bfb23768a..3696e349ee 100644
--- a/src/calendar/2024-04-15-testing-for-rust-projects.md
+++ b/src/calendar/2024-04-15-testing-for-rust-projects.md
@@ -7,6 +7,4 @@ kind: workshop
 color: aqua
 ---
 
-We are running a remote Rust workshop over two afternoons on April 15th & 16th,
-hosted by Luca Palmieri. Luca will present advanced testing patterns for Rust
-projects.
+We are running a remote Rust workshop over two afternoons on April 15th & 16th, hosted by Luca Palmieri. Luca will present advanced testing patterns for Rust projects.
diff --git a/src/calendar/2024-04-18-elixirconf-eu.md b/src/calendar/2024-04-18-elixirconf-eu.md
index eefdd56384..76f88580c2 100644
--- a/src/calendar/2024-04-18-elixirconf-eu.md
+++ b/src/calendar/2024-04-18-elixirconf-eu.md
@@ -7,6 +7,4 @@ kind: conference
 color: purple
 ---
 
-ElixirConf is a 2-day hybrid conference, gathering hundreds of developers with a
-passion for Elixir to learn about, share and inspire the progression of the
-Elixir ecosystem. We are supporting the conference as a silver sponsor!
+ElixirConf is a 2-day hybrid conference, gathering hundreds of developers with a passion for Elixir to learn about, share and inspire the progression of the Elixir ecosystem. We are supporting the conference as a silver sponsor!
diff --git a/src/calendar/2024-04-23-rust-for-the-web.md b/src/calendar/2024-04-23-rust-for-the-web.md
index 97c5bc832f..8a416ffd18 100644
--- a/src/calendar/2024-04-23-rust-for-the-web.md
+++ b/src/calendar/2024-04-23-rust-for-the-web.md
@@ -7,7 +7,4 @@ kind: meetup
 color: aqua
 ---
 
-We are running an event together with the Rust Berlin meetup group focused on
-using Rust for web development. The event is happening at Bauhaus, in Berlin, on
-April 23rd. Our Principal Engineering Consultant, Luca Palmieri, will moderate a
-panel featuring Ryan Levick and Jonas Dohse.
+We are running an event together with the Rust Berlin meetup group focused on using Rust for web development. The event is happening at Bauhaus, in Berlin, on April 23rd. Our Principal Engineering Consultant, Luca Palmieri, will moderate a panel featuring Ryan Levick and Jonas Dohse.
diff --git a/src/calendar/2024-04-27-svelte-summit-spring.md b/src/calendar/2024-04-27-svelte-summit-spring.md
index 1f75fb30cf..837d1e5010 100644
--- a/src/calendar/2024-04-27-svelte-summit-spring.md
+++ b/src/calendar/2024-04-27-svelte-summit-spring.md
@@ -7,6 +7,4 @@ kind: summit
 color: aqua
 ---
 
-Svelte Summit is an online conference dedicated to Svelte and everything that is
-happening in the community. Mainmatter's Svelte expert Paolo Ricciuti will talk
-about full-stack testing for SvelteKit applications.
+Svelte Summit is an online conference dedicated to Svelte and everything that is happening in the community. Mainmatter's Svelte expert Paolo Ricciuti will talk about full-stack testing for SvelteKit applications.
diff --git a/src/calendar/2024-05-07-advanced-developers-conference.md b/src/calendar/2024-05-07-advanced-developers-conference.md
index d5064938fe..52e6db1422 100644
--- a/src/calendar/2024-05-07-advanced-developers-conference.md
+++ b/src/calendar/2024-05-07-advanced-developers-conference.md
@@ -7,8 +7,4 @@ kind: conference
 color: purple
 ---
 
-ADC 24 is taking place in Regensburg's Jahnstadion on May 6th to 8th. Mainmatter
-Founder Marco Otte-Witte will present the state of the web development ecosystem
-for Rust, reasons for adopting Rust for web developments, challenges that come
-with that, and share some real-world examples to show what’s possible in his
-talk "Get Ready to Rustle".
+ADC 24 is taking place in Regensburg's Jahnstadion on May 6th to 8th. Mainmatter Founder Marco Otte-Witte will present the state of the web development ecosystem for Rust, reasons for adopting Rust for web developments, challenges that come with that, and share some real-world examples to show what’s possible in his talk "Get Ready to Rustle".
diff --git a/src/calendar/2024-05-28-telemetry-rust-workshop.md b/src/calendar/2024-05-28-telemetry-rust-workshop.md
index 2bb8773d16..6b746b449d 100644
--- a/src/calendar/2024-05-28-telemetry-rust-workshop.md
+++ b/src/calendar/2024-05-28-telemetry-rust-workshop.md
@@ -1,6 +1,5 @@
 ---
-title:
-  "Remote Workshop: Telemetry for Rust APIs – you can't fix what you can't see"
+title: "Remote Workshop: Telemetry for Rust APIs – you can't fix what you can't see"
 image: "/assets/images/calendar/2024-05-28-telemetry-rust-workshop/rust.png"
 location: "Online"
 url: https://ti.to/mainmatter/rust-telemetry-may-2024
@@ -8,6 +7,4 @@ kind: workshop
 color: aqua
 ---
 
-We are running a remote Rust Telemetry workshop over two afternoons on May 28th
-& 29th. Host Luca Palmieri will introduce a comprehensive toolkit to detect,
-troubleshoot and resolve issues in your Rust applications.
+We are running a remote Rust Telemetry workshop over two afternoons on May 28th & 29th. Host Luca Palmieri will introduce a comprehensive toolkit to detect, troubleshoot and resolve issues in your Rust applications.
diff --git a/src/calendar/2024-05-30-rust-for-the-web.md b/src/calendar/2024-05-30-rust-for-the-web.md
index a2b8a190d3..570b304fc9 100644
--- a/src/calendar/2024-05-30-rust-for-the-web.md
+++ b/src/calendar/2024-05-30-rust-for-the-web.md
@@ -7,7 +7,4 @@ kind: meetup
 color: aqua
 ---
 
-We are running an event together with the Barcelona Rust meetup group focused on
-using Rust for web development. The event is happening at AdevintaSpain, in
-Barcelona, on May 30th. Our Principal Engineering Consultant, Luca Palmieri,
-will moderate a panel featuring Matilda Smeds and Gleb Pomykalov.
+We are running an event together with the Barcelona Rust meetup group focused on using Rust for web development. The event is happening at AdevintaSpain, in Barcelona, on May 30th. Our Principal Engineering Consultant, Luca Palmieri, will moderate a panel featuring Matilda Smeds and Gleb Pomykalov.
diff --git a/src/calendar/2024-05-31-emberconf.md b/src/calendar/2024-05-31-emberconf.md
index a610909cbf..cb9228ac4e 100644
--- a/src/calendar/2024-05-31-emberconf.md
+++ b/src/calendar/2024-05-31-emberconf.md
@@ -7,7 +7,4 @@ kind: conference
 color: purple
 ---
 
-EmberConf is taking place in New York and online on May 31st. Chris Manson will
-discuss how ember-cli’s old Emberisms were translated to modern JavaScript
-tooling like ViteJs and more updates on Embroider and the
-[Embroider initiative](/ember-initiative/).
+EmberConf is taking place in New York and online on May 31st. Chris Manson will discuss how ember-cli’s old Emberisms were translated to modern JavaScript tooling like ViteJs and more updates on Embroider and the [Embroider initiative](/ember-initiative/).
diff --git a/src/calendar/2024-07-18-embereurope-remote.md b/src/calendar/2024-07-18-embereurope-remote.md
index 0aa03c9c4f..d3f9d4d9f3 100644
--- a/src/calendar/2024-07-18-embereurope-remote.md
+++ b/src/calendar/2024-07-18-embereurope-remote.md
@@ -10,7 +10,4 @@ hero:
   imageAlt: "A tiled background of European flags"
 ---
 
-We are back with our Q2 2024 event in July (yes, we're doing a Q2 event in Q3).
-Join remotely on July 18th starting from 19:00 CEST. The Ember Europe meetup
-series brings together the Ember community from all of Europe once a quarter.
-The meetup is organized by Mainmatter and Intercom.
+We are back with our Q2 2024 event in July (yes, we're doing a Q2 event in Q3). Join remotely on July 18th starting from 19:00 CEST. The Ember Europe meetup series brings together the Ember community from all of Europe once a quarter. The meetup is organized by Mainmatter and Intercom.
diff --git a/src/calendar/2024-09-12-emberfest.md b/src/calendar/2024-09-12-emberfest.md
index 2eb5dc38e9..6714ab846f 100644
--- a/src/calendar/2024-09-12-emberfest.md
+++ b/src/calendar/2024-09-12-emberfest.md
@@ -10,9 +10,4 @@ hero:
   imageAlt: "EmberFest Venue, Williams & Woods"
 ---
 
-EmberFest is the European Community Ember Conference, this year happening in
-Dublin, on September 12th & 13th. If you’re looking for updates on the latest
-and greatest in Ember and Glimmer this is the place to be. EmberFest is also a
-great opportunity to get in touch with the European Ember Community (and friends
-from abroad) and hiring Ember talent. Mainmatter is co-organizing the event and
-our team will be in Dublin in full force!
+EmberFest is the European Community Ember Conference, this year happening in Dublin, on September 12th & 13th. If you’re looking for updates on the latest and greatest in Ember and Glimmer this is the place to be. EmberFest is also a great opportunity to get in touch with the European Ember Community (and friends from abroad) and hiring Ember talent. Mainmatter is co-organizing the event and our team will be in Dublin in full force!
diff --git a/src/calendar/2024-10-03-vite-conf.md b/src/calendar/2024-10-03-vite-conf.md
new file mode 100644
index 0000000000..5a55b715e7
--- /dev/null
+++ b/src/calendar/2024-10-03-vite-conf.md
@@ -0,0 +1,13 @@
+---
+title: "ViteConf"
+image: "/assets/images/calendar/2024-10-03-viteconf-24/viteconf-logo.png"
+location: Online
+url: https://viteconf.org/
+kind: conference
+color: purple
+hero:
+  image: "/assets/images/hero/viteconf-24.png"
+  imageAlt: "ViteConf pyramid."
+---
+
+ViteConf 2024 will be held online on October 3rd and 4th. Mainmatter’s Chris Manson, will present “Ember’s Journey to Build with Vite”. His talk will cover how Ember.js developers can now, after the successful Embroider initiative, use Vite to build their applications, offering a new approach for Ember development.
diff --git a/src/calendar/2024-10-10-eurorust.md b/src/calendar/2024-10-10-eurorust.md
index 9ddb7910e1..27f91748e6 100644
--- a/src/calendar/2024-10-10-eurorust.md
+++ b/src/calendar/2024-10-10-eurorust.md
@@ -10,6 +10,4 @@ hero:
   imageAlt: "A conference room of attendees."
 ---
 
-EuroRust is a 2 day conference for the European Rust community, organized by
-Mainmatter. We cover all things Rust: from Rust patterns and idioms to systems
-programming and CLI tooling, servers WASM, and embedded systems.
+EuroRust is a 2 day conference for the European Rust community, organized by Mainmatter. We cover all things Rust: from Rust patterns and idioms to systems programming and CLI tooling, servers WASM, and embedded systems.
diff --git a/src/calendar/2024-11-19-embereuropeq4-remote.md b/src/calendar/2024-11-19-embereuropeq4-remote.md
new file mode 100644
index 0000000000..50105530c7
--- /dev/null
+++ b/src/calendar/2024-11-19-embereuropeq4-remote.md
@@ -0,0 +1,13 @@
+---
+title: "Ember Europe Q4 Meetup"
+image: "/assets/images/calendar/2024-11-19-embereuropeq4-remote/logo.png"
+location: Remote
+url: https://www.meetup.com/ember-europe/events/304061078/
+kind: meetup
+color: purple
+hero:
+  image: "/assets/images/calendar/2024-11-19-embereuropeq4-remote/embereurope.png"
+  imageAlt: "A tiled background of European flags"
+---
+
+We’re back with our Q4 2024 event! Join us remotely on November 19th, starting at 19:00 CET. The Ember Europe meetup series connects the Ember community from across Europe every quarter.
diff --git a/src/calendar/2024-11-27-wey-wey-web.md b/src/calendar/2024-11-27-wey-wey-web.md
new file mode 100644
index 0000000000..73ec70dc3b
--- /dev/null
+++ b/src/calendar/2024-11-27-wey-wey-web.md
@@ -0,0 +1,13 @@
+---
+title: "Wey Wey Web"
+image: "/assets/images/calendar/2024-11-27-weyweyweb/weyweyweb-logo.png"
+location: ESAD, Malaga, Spain
+url: https://www.weyweyweb.com/
+kind: conference
+color: purple
+hero:
+  image: "/assets/images/hero/weyweyweb-malaga-spain.jpg"
+  imageAlt: "The view of Málaga, Spain."
+---
+
+Wey Wey Web is an annual conference for UI enthusiasts, taking place in Málaga, Spain, this year. Mainmatter’s full-stack web developer, Paolo Ricciuti, will lead a workshop titled “Svelte and SvelteKit - From 0 to Fullstack,” where attendees will learn Svelte from the basics, progressing from a syntax showcase to building a fully scalable, full-stack, progressively enhanced application.
diff --git a/src/calendar/2024-11-28-rust-hack-and-learn-with-mainmatter-and-otto.md b/src/calendar/2024-11-28-rust-hack-and-learn-with-mainmatter-and-otto.md
new file mode 100644
index 0000000000..d3f37dbf2f
--- /dev/null
+++ b/src/calendar/2024-11-28-rust-hack-and-learn-with-mainmatter-and-otto.md
@@ -0,0 +1,13 @@
+---
+title: "Rust Hack & Learn with Mainmatter & Otto"
+image: "/assets/images/calendar/2024-11-28-rust-hack-and-learn-with-mainmatter-and-otto/rust.png"
+location: "Hamburg"
+url: https://www.meetup.com/rust-meetup-hamburg/events/303898286/
+kind: meetup
+color: aqua
+hero:
+  image: "/assets/images/hero/hamburg.png"
+  imageAlt: "The view of Hamburg"
+---
+
+We're hosting an event in collaboration with the Rust Hamburg meetup group and Otto in November. The event will take place at Otto's Collabor8 space in Hamburg, on November 28th. Mainmatter's Founder, Marco Otte-Witte, will introduce [gerust](https://github.com/mainmatter/gerust), a project generator and manager for Rust backend projects.
diff --git a/src/calendar/2025-05-05-rust-workshop-adc.md b/src/calendar/2025-05-05-rust-workshop-adc.md
new file mode 100644
index 0000000000..3216b27aee
--- /dev/null
+++ b/src/calendar/2025-05-05-rust-workshop-adc.md
@@ -0,0 +1,13 @@
+---
+title: "100 Exercises to Learn Rust at ADC"
+image: "/assets/images/calendar/2025-05-05-rust-workshop-adc/rust.png"
+location: "Regensburg & Online"
+url: https://adc.ms/25/Workshops
+kind: workshop
+color: purple
+hero:
+  image: "/assets/images/hero/Regensburg.png"
+  imageAlt: "The view of Regensburg"
+---
+
+Join our 100 Exercises to Learn Rust workshop at ADC 2024 in Regensburg! This hands-on session, led by Marco Otte-Witte, introduces Rust fundamentals – from syntax to the Rust ecosystem – through 100 practical exercises you can complete at your own pace. Designed for developers with experience in any programming language, with materials in English and questions welcome in German or English.
diff --git a/src/calendar/2025-05-08-svelte-summit.md b/src/calendar/2025-05-08-svelte-summit.md
new file mode 100644
index 0000000000..8f7c5dcbf7
--- /dev/null
+++ b/src/calendar/2025-05-08-svelte-summit.md
@@ -0,0 +1,13 @@
+---
+title: "Svelte Summit Spring 2025"
+image: "/assets/images/calendar/2025-05-08-svelte-summit/svelte.png"
+location: "Barcelona & Online"
+url: https://www.sveltesummit.com
+kind: conference
+color: aqua
+hero:
+  image: "/assets/images/calendar/2025-05-08-svelte-summit/venue.jpg"
+  imageAlt: "View of the Svelte Summit venue in Barcelona: a courtyard with concrete floor, tablees with chairs and light garlands."
+---
+
+We're co-organizing Svelte Summit Spring 2025 in Barcelona together with our friends from Svelte Society. Rich Harris, the creator of Svelte, will join us for a talk on-site in Barcelona. Mainmatter will run a workshops on the day before the main conference.
diff --git a/src/calendar/2025-10-09-eurorust.md b/src/calendar/2025-10-09-eurorust.md
new file mode 100644
index 0000000000..3209417659
--- /dev/null
+++ b/src/calendar/2025-10-09-eurorust.md
@@ -0,0 +1,13 @@
+---
+title: "EuroRust 2025"
+image: "/assets/images/calendar/2025-10-09-eurorust/rust.png"
+location: "Paris & Online"
+url: https://eurorust.eu
+kind: conference
+color: purple
+hero:
+  image: "/assets/images/calendar/2025-10-09-eurorust/paris.jpg"
+  imageAlt: "View of a Parisian street with the Eiffel tower in the background"
+---
+
+EuroRust is a 2 day conference for the European Rust community. It covers all things Rust: from Rust patterns and idioms to system programming and CLI tooling, servers WASM and embedded systems. Mainmatter will host EuroRust 2025 in Paris and online.
diff --git a/src/cases/ais.md b/src/cases/ais.md
index 3bde889cfa..f8eec907bd 100644
--- a/src/cases/ais.md
+++ b/src/cases/ais.md
@@ -3,17 +3,10 @@ layout: case-study
 company: AIS
 title: An MVP for an IT security dashboard | Work
 problem: AIS wanted to be able to supervise their metrics with a dashboard.
-solution:
-  We helped defining and shaping the goal as well as designed and implemented a
-  finished MVP.
+solution: We helped defining and shaping the goal as well as designed and implemented a finished MVP.
 tags: Launch your idea
 displayTitle: "An MVP for an IT <em>infrastructure</em> security dashboard"
-description:
-  <p>AIS provides continuous monitoring of companies' external assets, allowing
-  to proactively secure their attack surfaces.</p><p>Having built the core of
-  their product in-house, they approached Mainmatter for support with building a
-  web frontend for it. We conceptualized, designed and developed the application
-  in 6 weeks, guiding AIS\' team along the way.</p>
+description: <p>AIS provides continuous monitoring of companies' external assets, allowing to proactively secure their attack surfaces.</p><p>Having built the core of their product in-house, they approached Mainmatter for support with building a web frontend for it. We conceptualized, designed and developed the application in 6 weeks, guiding AIS\' team along the way.</p>
 hero:
   color: purple
   image: "/assets/images/work/ais.jpg"
diff --git a/src/cases/aleph-alpha.md b/src/cases/aleph-alpha.md
index 67a9966556..63afe9d35f 100644
--- a/src/cases/aleph-alpha.md
+++ b/src/cases/aleph-alpha.md
@@ -1,20 +1,12 @@
 ---
 layout: case-study
 company: Aleph Alpha
-problem:
-  Aleph Alpha wanted to take advantage of Rust’s built-in efficiency for their
-  latest learning model.
+problem: Aleph Alpha wanted to take advantage of Rust’s built-in efficiency for their latest learning model.
 solution: We provided the know-how to build the infrastructure.
 tags: Team reinforcement
 title: Preprocessing trillions of tokens with Rust | Work
 displayTitle: "Preprocessing trillions of tokens with Rust"
-description:
-  <p>Aleph Alpha empowers businesses and governments with the most advanced
-  generative AI technology, to gain a decisive edge in the thriving AI
-  economy.</p><p>Training AI models requires preprocessing large amounts of
-  data. When Aleph Alpha set out to leverage Rust to prepare the training
-  dataset for their new model, they reached out to Mainmatter for support in
-  architecting and implementing a scalable and efficient data pipeline.</p>
+description: <p>Aleph Alpha empowers businesses and governments with the most advanced generative AI technology, to gain a decisive edge in the thriving AI economy.</p><p>Training AI models requires preprocessing large amounts of data. When Aleph Alpha set out to leverage Rust to prepare the training dataset for their new model, they reached out to Mainmatter for support in architecting and implementing a scalable and efficient data pipeline.</p>
 hero:
   color: purple
   image: "/assets/images/work/aleph-alpha-background-2.jpg"
@@ -24,8 +16,7 @@ og:
   image: /assets/images/cases/cs-aleph-alpha-og-image.jpg
 ---
 
-{% from "image-aspect-ratio.njk" import imageAspectRatio %}
-{% from "quote.njk" import quote %}
+{% from "image-aspect-ratio.njk" import imageAspectRatio %} {% from "quote.njk" import quote %}
 
 <div class="case-study__section">
   <h3 class="case-study__heading">About Aleph Alpha</h3>
diff --git a/src/cases/asilimia.md b/src/cases/asilimia.md
index 36b3774796..cb5f6a1791 100644
--- a/src/cases/asilimia.md
+++ b/src/cases/asilimia.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: Asilimia
 tags: Team reinforcement
-description:
-  <p>Asilimia is a Kenyan digital payment application tailored for micro and
-  small businesses in Sub-Saharan Africa.</p><p>Mainmatter facilitated two
-  remote product design sprints to ideate, prototype, validate and test
-  product-market fit of its new bookkeeping features.</p>
+description: <p>Asilimia is a Kenyan digital payment application tailored for micro and small businesses in Sub-Saharan Africa.</p><p>Mainmatter facilitated two remote product design sprints to ideate, prototype, validate and test product-market fit of its new bookkeeping features.</p>
 hero:
   tags: "design sprint"
 permalink: false
diff --git a/src/cases/auditboard.md b/src/cases/auditboard.md
index d9ac44bae5..f588d9e77b 100644
--- a/src/cases/auditboard.md
+++ b/src/cases/auditboard.md
@@ -1,17 +1,10 @@
 ---
 layout: case-study
 company: Auditboard
-problem:
-  AuditBoard needed senior developers to translate their entire application.
-solution:
-  We took it on so they didn’t have to disrupt their roadmap to get it done.
+problem: AuditBoard needed senior developers to translate their entire application.
+solution: We took it on so they didn’t have to disrupt their roadmap to get it done.
 tags: Team reinforcement
-description:
-  <p>Auditboard enables companies to elevate their audit, risk, and compliance
-  teams with their online risk management platform.</p><p>Their application was
-  only available in english when they approached us for support with
-  localization. We set up an architecture and migrated their code automatically,
-  saving their team months of effort.</p>
+description: <p>Auditboard enables companies to elevate their audit, risk, and compliance teams with their online risk management platform.</p><p>Their application was only available in english when they approached us for support with localization. We set up an architecture and migrated their code automatically, saving their team months of effort.</p>
 hero:
   tags: "development / Ember.js / Format.js"
 permalink: false
diff --git a/src/cases/bmw-car-it.md b/src/cases/bmw-car-it.md
index 004a5f2e8f..08c291bdfb 100644
--- a/src/cases/bmw-car-it.md
+++ b/src/cases/bmw-car-it.md
@@ -1,17 +1,10 @@
 ---
 layout: case-study
 company: BMW Car IT
-problem:
-  BMW Car IT was looking to get a group of developers up to speed with Rust.
-solution:
-  We ran a 4-day mixed on-site and remote workshop for them, covering all the
-  topics they needed to know.
+problem: BMW Car IT was looking to get a group of developers up to speed with Rust.
+solution: We ran a 4-day mixed on-site and remote workshop for them, covering all the topics they needed to know.
 tags: Workshops
-description:
-  <p>BMW Car IT develops software for infotainment and autonomous
-  driving.</p><p>When they wanted to get a team of developers up to speed with
-  Rust, they reached out to Mainmatter. We ran a workshop for them, giving them
-  a smooth entry to Rust.</p>
+description: <p>BMW Car IT develops software for infotainment and autonomous driving.</p><p>When they wanted to get a team of developers up to speed with Rust, they reached out to Mainmatter. We ran a workshop for them, giving them a smooth entry to Rust.</p>
 hero:
   tags: "Rust / training"
 permalink: false
diff --git a/src/cases/camilyo.md b/src/cases/camilyo.md
index d58c3f465d..3900c1417a 100644
--- a/src/cases/camilyo.md
+++ b/src/cases/camilyo.md
@@ -2,16 +2,9 @@
 layout: case-study
 company: Camilyo
 problem: Camilyo's codebase lacked tests which slowed down velocity.
-solution:
-  We introduced solid testing practices and based on those, modernized the
-  codebase.
+solution: We introduced solid testing practices and based on those, modernized the codebase.
 tags: Tech Modernization
-description:
-  <p>Camilyo is an integrated marketing platform for online service
-  providers.</p><p>Mainmatter supported their team with identifying and fixing
-  issues in their Ember.js applications, improving their testing practices,
-  adopting modern Ember.js patterns and leveling up their team along the
-  way.</p>
+description: <p>Camilyo is an integrated marketing platform for online service providers.</p><p>Mainmatter supported their team with identifying and fixing issues in their Ember.js applications, improving their testing practices, adopting modern Ember.js patterns and leveling up their team along the way.</p>
 hero:
   tags: "development / mentoring / Ember.js"
 permalink: false
diff --git a/src/cases/cardstack.md b/src/cases/cardstack.md
index 83e707bd48..3ca892cd98 100644
--- a/src/cases/cardstack.md
+++ b/src/cases/cardstack.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: Cardstack
 tags: Team reinforcement
-description:
-  <p>Cardstack builds the experience layer for a decentralized
-  internet.</p><p>Mainmatter helped them complete their Card UI system and
-  validate its abilities in various prototype projects, identifying and fixing
-  some issues in their core framework along the way.</p>
+description: <p>Cardstack builds the experience layer for a decentralized internet.</p><p>Mainmatter helped them complete their Card UI system and validate its abilities in various prototype projects, identifying and fixing some issues in their core framework along the way.</p>
 hero:
   tags: "development / Ember.js"
 permalink: false
diff --git a/src/cases/clark.md b/src/cases/clark.md
index 842b69216d..c6a5765c61 100644
--- a/src/cases/clark.md
+++ b/src/cases/clark.md
@@ -2,12 +2,7 @@
 layout: case-study
 company: CLARK
 tags: Team reinforcement
-description:
-  <p>CLARK is a leading insurance broker app in the DACH region.</p><p>They
-  approached Mainmatter when they were looking for guidance on how to solidify
-  the codebase of their insurance management app. We conducted a thorough
-  review, presented the report to the team and layed out a plan for addressing
-  the identified issues.</p>
+description: <p>CLARK is a leading insurance broker app in the DACH region.</p><p>They approached Mainmatter when they were looking for guidance on how to solidify the codebase of their insurance management app. We conducted a thorough review, presented the report to the team and layed out a plan for addressing the identified issues.</p>
 hero:
   tags: "assessment / architecture / Ember.js"
 permalink: false
diff --git a/src/cases/ddwrt.md b/src/cases/ddwrt.md
index b676616b96..90cdfd3610 100644
--- a/src/cases/ddwrt.md
+++ b/src/cases/ddwrt.md
@@ -3,10 +3,7 @@ layout: case-study
 company: DDWRT
 title: A modern UI for DD-WRT NXT based on Ember.js | Work
 displayTitle: "A modern user interface for perennial router firmware"
-description:
-  "DD-WRT is a firmware for wireless routers running on millions of devices
-  worldwide. Mainmatter developed an Ember.js based foundation for a new
-  configuration UI."
+description: "DD-WRT is a firmware for wireless routers running on millions of devices worldwide. Mainmatter developed an Ember.js based foundation for a new configuration UI."
 problem: DD-WRT wanted a new user experience for their Linux-based firmware.
 solution: We built a new user interface using Ember.js as a strong foundation.
 tags: Team reinforcement
@@ -19,9 +16,7 @@ og:
   image: /assets/images/cases/cs-dd-wrt-og-image.jpg
 ---
 
-{% from "secondary-feature.njk" import secondaryFeature %}
-{% from "quote.njk" import quote %}
-{% from "btn-secondary.njk" import btnSecondary %}
+{% from "secondary-feature.njk" import secondaryFeature %} {% from "quote.njk" import quote %} {% from "btn-secondary.njk" import btnSecondary %}
 
 <div class="case-study__section">
   <h3 class="case-study__heading">About DD-WRT</h3>
diff --git a/src/cases/dim3.md b/src/cases/dim3.md
index 830cab8c4a..725748c4aa 100644
--- a/src/cases/dim3.md
+++ b/src/cases/dim3.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: Dim3
 tags: Team reinforcement
-description:
-  <p>Dim3 delivers software allowing hospitals to manage and optimize their
-  patients’ nutrition plans.</p><p>They approached Mainmatter when they faced
-  severe performance problem in their app. We identified and fixed these issues
-  and also found and solved some potential future problems along the way.</p>
+description: <p>Dim3 delivers software allowing hospitals to manage and optimize their patients’ nutrition plans.</p><p>They approached Mainmatter when they faced severe performance problem in their app. We identified and fixed these issues and also found and solved some potential future problems along the way.</p>
 hero:
   tags: "assessment / Ember.js"
 permalink: false
diff --git a/src/cases/embedd.md b/src/cases/embedd.md
index d3e0febb33..7054b75b89 100644
--- a/src/cases/embedd.md
+++ b/src/cases/embedd.md
@@ -2,10 +2,7 @@
 layout: case-study
 company: embeDD
 tags: Team reinforcement
-description:
-  <p>embeDD is the company behind the popular router firmware DD-WRT.</p><p>We
-  guided embeDD in laying the foundation for the next version of the firmware's
-  UI component so they could rely on it for years to come.</p>
+description: <p>embeDD is the company behind the popular router firmware DD-WRT.</p><p>We guided embeDD in laying the foundation for the next version of the firmware's UI component so they could rely on it for years to come.</p>
 hero:
   tags: "architecture / development / Ember.js"
 permalink: false
diff --git a/src/cases/erdil.md b/src/cases/erdil.md
index 59573f650d..a303e6db19 100644
--- a/src/cases/erdil.md
+++ b/src/cases/erdil.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: ERDiL
 tags: Team reinforcement
-description:
-  <p>ERDiL builds natural language processing software that helps companies
-  analyze messages from their customers.</p><p>They reached out to Mainmatter
-  for guidance on writing tests for their dashboard app based on Ember.js and
-  Ruby on Rails as well as establishing a sustainable testing culture.</p>
+description: <p>ERDiL builds natural language processing software that helps companies analyze messages from their customers.</p><p>They reached out to Mainmatter for guidance on writing tests for their dashboard app based on Ember.js and Ruby on Rails as well as establishing a sustainable testing culture.</p>
 hero:
   tags: "architecture / Ember.js / Ruby on Rails"
 permalink: false
diff --git a/src/cases/expedition.md b/src/cases/expedition.md
index 02e29db318..a01d0d5d34 100644
--- a/src/cases/expedition.md
+++ b/src/cases/expedition.md
@@ -3,16 +3,9 @@ layout: case-study
 company: Expedition
 title: An architecture based on Elixir and Ember.js for Expedition | Work
 displayTitle: "A sturdy foundation for advanced system architecture"
-description:
-  <p>Expedition is an online travel magazine for global citizens.</p><p>They
-  turned to Mainmatter when they were looking for guidance to get the most out
-  of their technology stack based on Elixir, Phoenix and Ember.js.</p>
-problem:
-  Expedition needed help sharpening up their Ember.js client and their Elixir &
-  Phoenix API.
-solution:
-  We reviewed their codebase and identified a priority list for the existing
-  issues.
+description: <p>Expedition is an online travel magazine for global citizens.</p><p>They turned to Mainmatter when they were looking for guidance to get the most out of their technology stack based on Elixir, Phoenix and Ember.js.</p>
+problem: Expedition needed help sharpening up their Ember.js client and their Elixir & Phoenix API.
+solution: We reviewed their codebase and identified a priority list for the existing issues.
 tags: Strategic Advice
 hero:
   color: purple
diff --git a/src/cases/experteer.md b/src/cases/experteer.md
index 922fffdbd0..f8d513041c 100644
--- a/src/cases/experteer.md
+++ b/src/cases/experteer.md
@@ -2,18 +2,11 @@
 layout: case-study
 company: Experteer
 title: A mobile onboarding experience | Work
-problem:
-  Experteer was lacking the internal UI/UX capacity they needed to build
-  user-focused solutions.
+problem: Experteer was lacking the internal UI/UX capacity they needed to build user-focused solutions.
 solution: Our experts mentored their team through designing a solution.
 tags: Launch your idea
-displayTitle:
-  "A <em>smooth</em> mobile onboarding experience – design to release"
-description:
-  <p>Experteer is Europe’s leading executive career service.</p><p>Mainmatter
-  has supported them in various ways over the years, building custom web apps,
-  reviewing their code as well as providing architecture and process
-  consulting.</p>
+displayTitle: "A <em>smooth</em> mobile onboarding experience – design to release"
+description: <p>Experteer is Europe’s leading executive career service.</p><p>Mainmatter has supported them in various ways over the years, building custom web apps, reviewing their code as well as providing architecture and process consulting.</p>
 hero:
   color: purple
   image: "/assets/images/work/experteer.jpg"
diff --git a/src/cases/generali.md b/src/cases/generali.md
index bacff7af65..42fd9b8e7b 100644
--- a/src/cases/generali.md
+++ b/src/cases/generali.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: Generali
 tags: Team reinforcement
-description:
-  <p>Generali approached Mainmatter when they were looking for support with an
-  internal Ember.js project.</p><p>We guided their team during the course of the
-  project by teaching and establishing best practices until the project’s
-  successful completion.</p>
+description: <p>Generali approached Mainmatter when they were looking for support with an internal Ember.js project.</p><p>We guided their team during the course of the project by teaching and establishing best practices until the project’s successful completion.</p>
 hero:
   tags: "architecture / mentoring / Ember.js"
 permalink: false
diff --git a/src/cases/hop-skip-drive.md b/src/cases/hop-skip-drive.md
index f3e416f3a1..6170ea763e 100644
--- a/src/cases/hop-skip-drive.md
+++ b/src/cases/hop-skip-drive.md
@@ -2,16 +2,9 @@
 layout: case-study
 company: HopSkipDrive
 tags: Team reinforcement
-problem:
-  HopSkipDrive wanted to track rides in real time and react to exceptions
-  immediately.
-solution:
-  Mainmatter built their internal dashboard on Ruby on Rails and Ember.js.
-description:
-  <p>HopSkipDrive builds a safe and dependable transportation solution for
-  schools and families.</p><p>Mainmatter built their internal dashboard on Ruby
-  on Rails and Ember.js, allowing them to track rides in real time and react to
-  exceptions immediately.</p>
+problem: HopSkipDrive wanted to track rides in real time and react to exceptions immediately.
+solution: Mainmatter built their internal dashboard on Ruby on Rails and Ember.js.
+description: <p>HopSkipDrive builds a safe and dependable transportation solution for schools and families.</p><p>Mainmatter built their internal dashboard on Ruby on Rails and Ember.js, allowing them to track rides in real time and react to exceptions immediately.</p>
 hero:
   tags: "architecture / Ember.js / Ruby on Rails"
 permalink: false
diff --git a/src/cases/kisters.md b/src/cases/kisters.md
index f27c1ae2a4..9b0fd4cf4f 100644
--- a/src/cases/kisters.md
+++ b/src/cases/kisters.md
@@ -1,18 +1,10 @@
 ---
 layout: case-study
 company: POELLATH
-problem:
-  KISTERS was looking for a way to move load transparently between their
-  servers, edge functions, and users' browsers.
-solution:
-  We developed a prototype tool for them that runs the same Rust code on the
-  server, edge function, and browsers via WebAssembly.
+problem: KISTERS was looking for a way to move load transparently between their servers, edge functions, and users' browsers.
+solution: We developed a prototype tool for them that runs the same Rust code on the server, edge function, and browsers via WebAssembly.
 tags: Launch your idea
-description:
-  <p>KISTERS are experts in environmental monitoring, IT and data
-  management</p><p>We developed a prototype tool for them that runs the same
-  Rust code on the server as well as on an edge function and in the browser via
-  WebAssembly.</p>
+description: <p>KISTERS are experts in environmental monitoring, IT and data management</p><p>We developed a prototype tool for them that runs the same Rust code on the server as well as on an edge function and in the browser via WebAssembly.</p>
 hero:
   tags: "architecture / Rust / WASM"
 permalink: false
diff --git a/src/cases/loconet.md b/src/cases/loconet.md
index 938d489e95..56b009efc5 100644
--- a/src/cases/loconet.md
+++ b/src/cases/loconet.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: LoCoNET
 tags: Team reinforcement
-description:
-  <p>LoCoNET builds online games for the web. They reached out to Mainmatter to
-  improve their team’s productivity.</p><p>We identified and fixed some blocking
-  issues, laid the architectural foundation for some advanced features and
-  conducted workshops to level up their team’s expertise.</p>
+description: <p>LoCoNET builds online games for the web. They reached out to Mainmatter to improve their team’s productivity.</p><p>We identified and fixed some blocking issues, laid the architectural foundation for some advanced features and conducted workshops to level up their team’s expertise.</p>
 hero:
   tags: "architecture / mentoring / Ember.js"
 permalink: false
diff --git a/src/cases/medify.md b/src/cases/medify.md
index a57598ce50..455b0392f7 100644
--- a/src/cases/medify.md
+++ b/src/cases/medify.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: Medify
 tags: Team reinforcement
-description:
-  <p>Medify offers high-quality medical admissions help and was used by 2 in 3
-  of 2020's UCAT applicants in the UK.</p><p>Mainmatter supported their team
-  with identifying issues in their Ember.js apps, architectural advice as well
-  as releasing a business-critical project on schedule.</p>
+description: <p>Medify offers high-quality medical admissions help and was used by 2 in 3 of 2020's UCAT applicants in the UK.</p><p>Mainmatter supported their team with identifying issues in their Ember.js apps, architectural advice as well as releasing a business-critical project on schedule.</p>
 hero:
   tags: "development / Ember.js / Ruby on Rails"
 permalink: false
diff --git a/src/cases/mobimed.md b/src/cases/mobimed.md
index ba8cb2505f..9c8c4da25f 100644
--- a/src/cases/mobimed.md
+++ b/src/cases/mobimed.md
@@ -4,21 +4,13 @@ company: Mobi.MED
 title: Modernizing Code and Design for a Healthcare Software Supplier
 displayTitle: "Modernizing Healthcare Software"
 problem: mobi.MED needed to refresh their codebase and UI.
-solution:
-  Our team developed a design system, implemented it in the application, and
-  modernized the codebase along the way.
+solution: Our team developed a design system, implemented it in the application, and modernized the codebase along the way.
 tags: Tech modernization
-description:
-  <p>mobi.MED offers an all-in-one software solution for doctors' practices in
-  Austria and Germany</p><p>Mainmatter modernized the codebase of their
-  frontend, established a design system and refreshed the UI and UX of the
-  application.</p>
+description: <p>mobi.MED offers an all-in-one software solution for doctors' practices in Austria and Germany</p><p>Mainmatter modernized the codebase of their frontend, established a design system and refreshed the UI and UX of the application.</p>
 hero:
   color: purple
   image: "/assets/images/work/mobimed.jpg"
-  imageAlt:
-    "Woman in green protective clothes sitting in front of 3 computer screens
-    holding a computer mouse"
+  imageAlt: "Woman in green protective clothes sitting in front of 3 computer screens holding a computer mouse"
   tags: "design / development / mentoring"
 og:
   image: /assets/images/cases/cs-mobimed-og-image.jpg
diff --git a/src/cases/mvb.md b/src/cases/mvb.md
index 8555fe7aa8..ebff3b3739 100644
--- a/src/cases/mvb.md
+++ b/src/cases/mvb.md
@@ -1,18 +1,12 @@
 ---
 layout: case-study
 company: MVB
-problem:
-  MVB lacked the experience to feel confident that they were delivering on
-  quality under time pressure.
+problem: MVB lacked the experience to feel confident that they were delivering on quality under time pressure.
 solution: Our experts mentored the team to achieve both requirements.
 tags: Team reinforcement
 title: A platform for the german book industry | Work
 displayTitle: "A platform for the <em>german</em> book industry"
-description:
-  <p>MVB provides marketing solutions for the German book industry.</p><p>They
-  approached Mainmatter when they were looking for external expertise. We
-  performed a workshop, leveling up the team’s expertise and guided the project
-  until its successful completion.</p>
+description: <p>MVB provides marketing solutions for the German book industry.</p><p>They approached Mainmatter when they were looking for external expertise. We performed a workshop, leveling up the team’s expertise and guided the project until its successful completion.</p>
 hero:
   color: purple
   image: "/assets/images/work/mvb-background.jpg"
diff --git a/src/cases/neighbourhoodie.md b/src/cases/neighbourhoodie.md
index e59a289fde..ac324c83a2 100644
--- a/src/cases/neighbourhoodie.md
+++ b/src/cases/neighbourhoodie.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: Neighbourhoodie
 tags: Team reinforcement
-description:
-  Mainmatter helped Neighbourhoodie successfully complete their first Ember.js
-  project. We conducted an on-site workshop for their team, teaching Ember.js’
-  fundamental concepts as well as advanced patterns, enabling their team to
-  complete their project successfully.
+description: Mainmatter helped Neighbourhoodie successfully complete their first Ember.js project. We conducted an on-site workshop for their team, teaching Ember.js’ fundamental concepts as well as advanced patterns, enabling their team to complete their project successfully.
 hero:
   tags: "mentoring / Ember.js"
 permalink: false
diff --git a/src/cases/phorest.md b/src/cases/phorest.md
index 77076b49ff..9975449890 100644
--- a/src/cases/phorest.md
+++ b/src/cases/phorest.md
@@ -2,11 +2,7 @@
 layout: case-study
 company: Phorest
 tags: Team reinforcement
-description:
-  <p>Phorest provides software that enables 150.000+ salon and spa professionals
-  worldwide to manage and market their businesses.</p><p>When they aimed to
-  migrate their existing Java based product to the web, they reached out to
-  Mainmatter for support with architecting and accelerating that transition.</p>
+description: <p>Phorest provides software that enables 150.000+ salon and spa professionals worldwide to manage and market their businesses.</p><p>When they aimed to migrate their existing Java based product to the web, they reached out to Mainmatter for support with architecting and accelerating that transition.</p>
 hero:
   tags: "architecture / development / Ember.js"
 permalink: false
diff --git a/src/cases/poellath.md b/src/cases/poellath.md
index 67ff90bbc3..ec788cf0bd 100644
--- a/src/cases/poellath.md
+++ b/src/cases/poellath.md
@@ -1,17 +1,10 @@
 ---
 layout: case-study
 company: POELLATH
-problem:
-  POELLATH wanted to offer their investors a digital onboarding experience.
-solution:
-  Our team walked them through the process and developed a concept they could
-  build off of.
+problem: POELLATH wanted to offer their investors a digital onboarding experience.
+solution: Our team walked them through the process and developed a concept they could build off of.
 tags: Launch your idea
-description:
-  <p>POELLATH is a German law firm specializing in advice on transactions and
-  asset management.</p><p>When they were looking to build custom software tools
-  to improve workflows, we conducted a product strategy workshop with them to
-  develop a clear understanding of these tools and enable the next steps.</p>
+description: <p>POELLATH is a German law firm specializing in advice on transactions and asset management.</p><p>When they were looking to build custom software tools to improve workflows, we conducted a product strategy workshop with them to develop a clear understanding of these tools and enable the next steps.</p>
 hero:
   tags: "product strategy / architecture"
 permalink: false
diff --git a/src/cases/qonto.md b/src/cases/qonto.md
index 35dc4556d4..279b8f3d57 100644
--- a/src/cases/qonto.md
+++ b/src/cases/qonto.md
@@ -3,18 +3,10 @@ layout: case-study
 company: Qonto
 title: Co-Engineering the Future of Banking for SMEs with Qonto | Work
 displayTitle: "A helping hand for a visionary fintech startup"
-problem:
-  Qonto was facing a number of impediments that were slowing down their
-  workflow.
-solution:
-  We helped them release new features quickly while laying the foundations for
-  sustainable growth at an accelerated pace.
+problem: Qonto was facing a number of impediments that were slowing down their workflow.
+solution: We helped them release new features quickly while laying the foundations for sustainable growth at an accelerated pace.
 tags: Team reinforcement
-description:
-  <p>Qonto is the leading neobank for SMEs and freelancers in
-  Europe.</p><p>Mainmatter worked with their web frontend team to boost their
-  productivity, establish Ember.js best practices, and ensure long-term
-  success.</p>
+description: <p>Qonto is the leading neobank for SMEs and freelancers in Europe.</p><p>Mainmatter worked with their web frontend team to boost their productivity, establish Ember.js best practices, and ensure long-term success.</p>
 hero:
   color: purple
   image: "/assets/images/work/qonto.jpg"
diff --git a/src/cases/rail-europe.md b/src/cases/rail-europe.md
index 0506ba7a44..033af27b44 100644
--- a/src/cases/rail-europe.md
+++ b/src/cases/rail-europe.md
@@ -1,21 +1,12 @@
 ---
 layout: case-study
 company: Rail Europe
-problem:
-  Rail Europe needed to establish the best way forward after an acquisition.
-solution:
-  We provided an assessment and a roadmap – then supported the implementation.
+problem: Rail Europe needed to establish the best way forward after an acquisition.
+solution: We provided an assessment and a roadmap – then supported the implementation.
 tags: Strategic advice
 title: Transformation for Growth | Work
 displayTitle: Transformation for Growth
-description:
-  <p>Rail Europe is the reference brand for European train booking, providing
-  technology service solutions to +15,000 travel professionals in 70
-  countries.</p><p>When setting off on their growth initiative, Rail Europe
-  reached out to Mainmatter to perform an audit of their existing tech platform.
-  We identified impediments and since support their team to address those which
-  includes fixing performance bottlenecks and rebuilding the B2C offering in
-  Svelte.</p>
+description: <p>Rail Europe is the reference brand for European train booking, providing technology service solutions to +15,000 travel professionals in 70 countries.</p><p>When setting off on their growth initiative, Rail Europe reached out to Mainmatter to perform an audit of their existing tech platform. We identified impediments and since support their team to address those which includes fixing performance bottlenecks and rebuilding the B2C offering in Svelte.</p>
 hero:
   color: purple
   image: "/assets/images/work/rail-europe.jpg"
@@ -25,8 +16,7 @@ og:
   image: /assets/images/cases/cs-rail-europe-og-image.jpeg
 ---
 
-{% from "quote.njk" import quote %}
-{% from "image-aspect-ratio.njk" import imageAspectRatio %}
+{% from "quote.njk" import quote %} {% from "image-aspect-ratio.njk" import imageAspectRatio %}
 
 <div class="case-study__section">
   <h3 class="case-study__heading">About Rail Europe</h3>
diff --git a/src/cases/ringler.md b/src/cases/ringler.md
index a2a6487da0..170e00a04e 100644
--- a/src/cases/ringler.md
+++ b/src/cases/ringler.md
@@ -2,10 +2,7 @@
 layout: case-study
 company: Ringler
 tags: Team reinforcement
-description:
-  We helped Ringler meet the deadline for one their projects without sacrificing
-  on quality. Our technology experts joined Ringler’s internal team, increasing
-  the available workforce and sharing their expertise.
+description: We helped Ringler meet the deadline for one their projects without sacrificing on quality. Our technology experts joined Ringler’s internal team, increasing the available workforce and sharing their expertise.
 hero:
   tags: "development / mentoring / Ember.js"
 permalink: false
diff --git a/src/cases/robin-hood.md b/src/cases/robin-hood.md
index 80e79ed628..c361876b24 100644
--- a/src/cases/robin-hood.md
+++ b/src/cases/robin-hood.md
@@ -3,14 +3,8 @@ layout: case-study
 company: Robin Hood
 tags: Team reinforcement
 problem: Robin Hood wanted a tool for managing Civic User Testing Groups.
-solution:
-  Mainmatter helped them improve their engineering process and built a web based
-  tool with Ruby on Rails.
-description:
-  <p>Robin Hood is a charitable foundation fighting poverty in New York
-  City.</p><p>Mainmatter helped them establish an effective engineering process
-  as well as build and release a web based tool with Ruby on Rails for managing
-  Civic User Testing Groups.</p>
+solution: Mainmatter helped them improve their engineering process and built a web based tool with Ruby on Rails.
+description: <p>Robin Hood is a charitable foundation fighting poverty in New York City.</p><p>Mainmatter helped them establish an effective engineering process as well as build and release a web based tool with Ruby on Rails for managing Civic User Testing Groups.</p>
 hero:
   tags: "process / development / Ruby on Rails"
 permalink: false
diff --git a/src/cases/sage.md b/src/cases/sage.md
index f06b57cb07..a93c0ff7f1 100644
--- a/src/cases/sage.md
+++ b/src/cases/sage.md
@@ -2,16 +2,9 @@
 layout: case-study
 company: Sage Intacct
 problem: Sage Software was being slowed down by its legacy code.
-solution:
-  We worked with them to update and streamline their codebase so they could move
-  forward.
+solution: We worked with them to update and streamline their codebase so they could move forward.
 tags: Tech modernization
-description:
-  <p>Sage Intacct is the leading provider of online Accounting and Finance
-  Management software.</p><p>Mainmatter helped their engineering team to
-  identify and overcome issues that had a negative impact on their velocity as
-  well as migrate the codebase to more modern patterns and a more sustainable
-  architecture.</p>
+description: <p>Sage Intacct is the leading provider of online Accounting and Finance Management software.</p><p>Mainmatter helped their engineering team to identify and overcome issues that had a negative impact on their velocity as well as migrate the codebase to more modern patterns and a more sustainable architecture.</p>
 hero:
   tags: "development / architecture / mentoring"
 permalink: false
diff --git a/src/cases/sutori.md b/src/cases/sutori.md
index 777c730539..65f32a7fe7 100644
--- a/src/cases/sutori.md
+++ b/src/cases/sutori.md
@@ -2,12 +2,7 @@
 layout: case-study
 company: Sutori
 tags: Team reinforcement
-description:
-  <p>Sutori is an online, collaborative learning platform that helps teachers
-  present information in the remote classroom.</p><p>When they wanted to
-  internationalize their service, Mainmatter set up the architecture in their
-  application as well as the infrastructure that supports their development
-  team.</p>
+description: <p>Sutori is an online, collaborative learning platform that helps teachers present information in the remote classroom.</p><p>When they wanted to internationalize their service, Mainmatter set up the architecture in their application as well as the infrastructure that supports their development team.</p>
 hero:
   tags: "architecture / development"
 permalink: false
diff --git a/src/cases/terminal49.md b/src/cases/terminal49.md
index 2aed4e32a0..5e542590f1 100644
--- a/src/cases/terminal49.md
+++ b/src/cases/terminal49.md
@@ -2,12 +2,9 @@
 layout: case-study
 company: Terminal49
 tags: Team reinforcement
-description:
-  <p>Terminal49 is the all-in-one shipment and container tracking
-  platform.</p><p>When their team was facing challenges and delivery bottlenecks
-  with their frontend application, they reached out to Mainmatter for support.
-  We performed an assessment of their codebase, prepared a roadmap and supported
-  their team to follow that.</p>
+problem: Terminal49 was facing challenges and delivery bottlenecks with their frontend application.
+solution: Mainmatter performed an assessment of their codebase to create a product roadmap.
+description: <p>Terminal49 is the all-in-one shipment and container tracking platform.</p><p>When their team was facing challenges and delivery bottlenecks with their frontend application, they reached out to Mainmatter for support. We performed an assessment of their codebase, prepared a roadmap and supported their team to follow that.</p>
 hero:
   tags: "architecture / development / Ember.js"
 permalink: false
diff --git a/src/cases/timify.md b/src/cases/timify.md
index 4f8309229c..e147775bff 100644
--- a/src/cases/timify.md
+++ b/src/cases/timify.md
@@ -4,14 +4,9 @@ company: Timify
 title: Laying a solid frontend foundation for an ambitious startup | Work
 displayTitle: "An engineering overhaul for a <em>validated</em> booking system"
 problem: Timify's entire system needed to be re-engineered from the ground up.
-solution:
-  We completed the first release version of the new application and got them up
-  to speed on best practices and patterns for Ember.js
+solution: We completed the first release version of the new application and got them up to speed on best practices and patterns for Ember.js
 tags: Team reinforcement
-description:
-  <p>Timify is an online appointment scheduling service that connects service
-  providers with clients.</p><p>When they decided it was time to re-engineer
-  their existing product, they trusted us to set them up for future success.</p>
+description: <p>Timify is an online appointment scheduling service that connects service providers with clients.</p><p>When they decided it was time to re-engineer their existing product, they trusted us to set them up for future success.</p>
 hero:
   color: purple
   image: "/assets/images/work/timify.jpg"
diff --git a/src/cases/trainline.md b/src/cases/trainline.md
index 5cdc4018bf..413cf1ca53 100644
--- a/src/cases/trainline.md
+++ b/src/cases/trainline.md
@@ -3,17 +3,10 @@ layout: case-study
 company: Trainline
 title: Mobile train tickets with Ember.js for Trainline | Work
 displayTitle: "The full market potential for a <em>leading</em> travel platform"
-problem:
-  Trainline was in need of a mobile web app to complement their desktop
-  apllication.
-solution:
-  We helped deliver the web app and developed the team’s expertise through
-  pair-programming sessions and code reviews.
+problem: Trainline was in need of a mobile web app to complement their desktop apllication.
+solution: We helped deliver the web app and developed the team’s expertise through pair-programming sessions and code reviews.
 tags: Team reinforcement
-description:
-  <p>Trainline is Europe’s leading rail and coach platform.</p><p>We helped them
-  deliver a high-performance mobile web app, along with an improved engineering
-  process.</p>
+description: <p>Trainline is Europe’s leading rail and coach platform.</p><p>We helped them deliver a high-performance mobile web app, along with an improved engineering process.</p>
 hero:
   color: purple
   image: "/assets/images/work/trainline.jpg"
diff --git a/src/cases/weplan.md b/src/cases/weplan.md
index 08054a6b8f..b3b2ffe27f 100644
--- a/src/cases/weplan.md
+++ b/src/cases/weplan.md
@@ -2,10 +2,7 @@
 layout: case-study
 company: WePlan
 tags: Team reinforcement
-description:
-  <p>WePlan is a software company offering smart workforce planning
-  solutions.</p><p>We worked with them to modernize their Ember.js codebase,
-  refactor old patterns and accelerate their team's value delivery.</p>
+description: <p>WePlan is a software company offering smart workforce planning solutions.</p><p>We worked with them to modernize their Ember.js codebase, refactor old patterns and accelerate their team's value delivery.</p>
 hero:
   tags: "architecture / development / mentoring"
 permalink: false
diff --git a/src/cases/xbav.md b/src/cases/xbav.md
index 65539fdc66..1b94b13867 100644
--- a/src/cases/xbav.md
+++ b/src/cases/xbav.md
@@ -2,18 +2,9 @@
 layout: case-study
 company: xbAV
 tags: Team reinforcement
-problem:
-  xbAV were looking for support releasing a number of critical features built
-  with Ruby on Rails.
-solution:
-  Our experts joined xbAV’s team, increasing the available workforce while
-  boosting their expertise.
-description:
-  <p>xbAV makes pensions accessible for employees, employers and
-  agents.</p><p>They approached Mainmatter when they were looking for support
-  releasing a number of critical features built with Ruby on Rails. Our
-  technology experts joined xbAV’s internal team, increasing the available
-  workforce while boosting their expertise.</p>
+problem: xbAV were looking for support releasing a number of critical features built with Ruby on Rails.
+solution: Our experts joined xbAV’s team, increasing the available workforce while boosting their expertise.
+description: <p>xbAV makes pensions accessible for employees, employers and agents.</p><p>They approached Mainmatter when they were looking for support releasing a number of critical features built with Ruby on Rails. Our technology experts joined xbAV’s internal team, increasing the available workforce while boosting their expertise.</p>
 hero:
   tags: "architecture / development / Ruby on Rails"
 permalink: false
diff --git a/src/channels/assertjs-2018.md b/src/channels/assertjs-2018.md
index 0575c1f8b4..6c177724c0 100644
--- a/src/channels/assertjs-2018.md
+++ b/src/channels/assertjs-2018.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2018-02-22-assertjs-2018/logo.png"
 url: https://2018.assertjs.com
 ---
 
-Assert(js) Testing Conference is a one-day, single-track conference with a laser
-focus on testing for JavaScript developers.
+Assert(js) Testing Conference is a one-day, single-track conference with a laser focus on testing for JavaScript developers.
diff --git a/src/channels/bangbangconwest-2019.md b/src/channels/bangbangconwest-2019.md
index f69f0403d6..763caa6d01 100644
--- a/src/channels/bangbangconwest-2019.md
+++ b/src/channels/bangbangconwest-2019.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2019-02-23-bangbangconwest-2019/logo.png"
 url: http://bangbangcon.com/west/
 ---
 
-!!Con West was a two-day conference of ten-minute talks about the joy,
-excitement, and surprise of computing.
+!!Con West was a two-day conference of ten-minute talks about the joy, excitement, and surprise of computing.
diff --git a/src/channels/commit-porto-2019.md b/src/channels/commit-porto-2019.md
index 6190232c3f..6d5681912f 100644
--- a/src/channels/commit-porto-2019.md
+++ b/src/channels/commit-porto-2019.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2019-06-22-commit-porto-2019/logo.png"
 url: https://commitporto.com/
 ---
 
-Commit Porto is a tech conference organized by AlumniEI-FEUP, annually taking
-place in Porto, Portugal.
+Commit Porto is a tech conference organized by AlumniEI-FEUP, annually taking place in Porto, Portugal.
diff --git a/src/channels/devfest-nantes-2018.md b/src/channels/devfest-nantes-2018.md
index a931413639..360af40e69 100644
--- a/src/channels/devfest-nantes-2018.md
+++ b/src/channels/devfest-nantes-2018.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2018-10-18-devfest-nantes-2018/logo.png"
 url: https://devfest2018.gdgnantes.com
 ---
 
-DevFest Nantes is a technical conference for developers, aimed at students,
-professionals or simply curious techies.
+DevFest Nantes is a technical conference for developers, aimed at students, professionals or simply curious techies.
diff --git a/src/channels/ember-munich.md b/src/channels/ember-munich.md
index 98ce852c1f..df5d90c2f7 100644
--- a/src/channels/ember-munich.md
+++ b/src/channels/ember-munich.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2017-05-24-ember-munich/logo.png"
 url: https://www.meetup.com/Ember-js-Munich/
 ---
 
-Ember.js Munich is the local Ember.js meetup in Munich, held around 4 times per
-year.
+Ember.js Munich is the local Ember.js meetup in Munich, held around 4 times per year.
diff --git a/src/channels/emberconf-2017.md b/src/channels/emberconf-2017.md
index 7c5b4c2ebf..d733af5eda 100644
--- a/src/channels/emberconf-2017.md
+++ b/src/channels/emberconf-2017.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2017-03-28-emberconf-2017/logo.png"
 url: https://2017.emberconf.com
 ---
 
-EmberConf is the main yearly conference around all things Ember in Portland, OR,
-USA.
+EmberConf is the main yearly conference around all things Ember in Portland, OR, USA.
diff --git a/src/channels/emberconf-2018.md b/src/channels/emberconf-2018.md
index 2b333e1828..13af3a63b2 100644
--- a/src/channels/emberconf-2018.md
+++ b/src/channels/emberconf-2018.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2018-03-13-emberconf-2018/logo.svg"
 url: https://2018.emberconf.com
 ---
 
-EmberConf is the main yearly conference around all things Ember in Portland, OR,
-USA.
+EmberConf is the main yearly conference around all things Ember in Portland, OR, USA.
diff --git a/src/channels/emberconf-2019.md b/src/channels/emberconf-2019.md
index 20d317d8df..8b967ac7a5 100644
--- a/src/channels/emberconf-2019.md
+++ b/src/channels/emberconf-2019.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2019-03-16-emberconf-2019/logo.png"
 url: https://emberconf.com
 ---
 
-EmberConf is the main yearly conference around all things Ember in Portland, OR,
-USA.
+EmberConf is the main yearly conference around all things Ember in Portland, OR, USA.
diff --git a/src/channels/emberconf-2020.md b/src/channels/emberconf-2020.md
index 7e4effd7a6..ae7df66f93 100644
--- a/src/channels/emberconf-2020.md
+++ b/src/channels/emberconf-2020.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2020-03-16-emberconf-2020/logo.svg"
 url: https://2020.emberconf.com
 ---
 
-EmberConf is the main yearly conference around all things Ember – virtual and
-streamed in 2020.
+EmberConf is the main yearly conference around all things Ember – virtual and streamed in 2020.
diff --git a/src/channels/emberconf-2021.md b/src/channels/emberconf-2021.md
index cf1045839f..4684988bb4 100644
--- a/src/channels/emberconf-2021.md
+++ b/src/channels/emberconf-2021.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2021-03-29-emberconf-2021/logo.svg"
 url: https://emberconf.com
 ---
 
-EmberConf is 2 days of Ember talks, sessions and fun – streaming live virtually
-everywhere.
+EmberConf is 2 days of Ember talks, sessions and fun – streaming live virtually everywhere.
diff --git a/src/channels/emberconf-2022.md b/src/channels/emberconf-2022.md
index b92c3c9ae6..dcf9583d37 100644
--- a/src/channels/emberconf-2022.md
+++ b/src/channels/emberconf-2022.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2022-04-19-emberconf-2022/logo.svg"
 url: https://emberconf.com
 ---
 
-EmberConf is 4 days of Ember talks, sessions and fun – streaming live virtually
-everywhere.
+EmberConf is 4 days of Ember talks, sessions and fun – streaming live virtually everywhere.
diff --git a/src/channels/emberconf-2024.md b/src/channels/emberconf-2024.md
new file mode 100644
index 0000000000..1362839e40
--- /dev/null
+++ b/src/channels/emberconf-2024.md
@@ -0,0 +1,7 @@
+---
+title: "EmberConf 2024"
+image: "/assets/images/talks/2024-09-13-emberconf-2024/new-logo.png"
+url: https://emberconf.com
+---
+
+EmberConf is a one-day conference for the Ember.js community. This year's event happened in New York and online on May 31st.
diff --git a/src/channels/embereurope-q1-2023.md b/src/channels/embereurope-q1-2023.md
index 59c3fdbd14..d2df006eeb 100644
--- a/src/channels/embereurope-q1-2023.md
+++ b/src/channels/embereurope-q1-2023.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2023-03-23-embereurope-2023-q1/logo.svg"
 url: https://www.meetup.com/ember-europe/events/291659853/
 ---
 
-The Ember.js Europe meetup brings together the Ember community from all of
-Europe once a quarter.
+The Ember.js Europe meetup brings together the Ember community from all of Europe once a quarter.
diff --git a/src/channels/embereurope-q1-2024.md b/src/channels/embereurope-q1-2024.md
index e73533d1f3..81dd80640f 100644
--- a/src/channels/embereurope-q1-2024.md
+++ b/src/channels/embereurope-q1-2024.md
@@ -1,8 +1,7 @@
 ---
 title: "Ember Europe Q4 Meetup 2023"
-image: "/assets/images/talks/2024-03-21-embereurope-2024-q1/logo.svg"
+image: "/assets/images/talks/2024-03-21-embereurope-2024-q1/ember-logo.png"
 url: https://www.meetup.com/de-DE/ember-europe/
 ---
 
-The Ember.js Europe meetup brings together the Ember community from all of
-Europe once a quarter.
+The Ember.js Europe meetup brings together the Ember community from all of Europe once a quarter.
diff --git a/src/channels/embereurope-q4-2022.md b/src/channels/embereurope-q4-2022.md
index cc697472d2..bf3fd92171 100644
--- a/src/channels/embereurope-q4-2022.md
+++ b/src/channels/embereurope-q4-2022.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2022-12-09-embereurope-2022/logo.svg"
 url: https://www.meetup.com/de-DE/ember-europe/
 ---
 
-The Ember.js Europe meetup brings together the Ember community from all of
-Europe once a quarter.
+The Ember.js Europe meetup brings together the Ember community from all of Europe once a quarter.
diff --git a/src/channels/embereurope-q4-2023.md b/src/channels/embereurope-q4-2023.md
index e699099305..a21f6afce0 100644
--- a/src/channels/embereurope-q4-2023.md
+++ b/src/channels/embereurope-q4-2023.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2023-12-07-embereurope-2023-q4/logo.svg"
 url: https://www.meetup.com/de-DE/ember-europe/
 ---
 
-The Ember.js Europe meetup brings together the Ember community from all of
-Europe once a quarter. Ember Europe is run by Mainmatter and Intercom.
+The Ember.js Europe meetup brings together the Ember community from all of Europe once a quarter. Ember Europe is run by Mainmatter and Intercom.
diff --git a/src/channels/emberfest-2019.md b/src/channels/emberfest-2019.md
index 8e4107ffd4..8139b8406f 100644
--- a/src/channels/emberfest-2019.md
+++ b/src/channels/emberfest-2019.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2019-10-17-emberfest-2019/logo.png"
 url: https://emberfest.eu
 ---
 
-EmberFest is the European Community Ember Conference and took place in
-Copenhagen, Denmark in 2019.
+EmberFest is the European Community Ember Conference and took place in Copenhagen, Denmark in 2019.
diff --git a/src/channels/eurorust23.md b/src/channels/eurorust23.md
index cadb70cee6..7d516a53df 100644
--- a/src/channels/eurorust23.md
+++ b/src/channels/eurorust23.md
@@ -4,6 +4,4 @@ image: "/assets/images/talks/2023-10-12-eurorust-2023/logo.png"
 url: https://eurorust.eu/
 ---
 
-EuroRust is a 2 day conference for the European Rust community, organized by
-Mainmatter. We cover all things Rust: from Rust patterns and idioms to systems
-programming and CLI tooling, servers WASM, and embedded systems.
+EuroRust is a 2 day conference for the European Rust community, organized by Mainmatter. We cover all things Rust: from Rust patterns and idioms to systems programming and CLI tooling, servers WASM, and embedded systems.
diff --git a/src/channels/international-javascript-conference-2017.md b/src/channels/international-javascript-conference-2017.md
index 9ee1388d22..6a1b3b8dd4 100644
--- a/src/channels/international-javascript-conference-2017.md
+++ b/src/channels/international-javascript-conference-2017.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2017-10-23-international-javascript-conference-2017
 url: https://javascript-conference.com/archiv/archiv-ijs-2017/
 ---
 
-International JavaScript Conference is a 3 day conference around everything
-JavaScript.
+International JavaScript Conference is a 3 day conference around everything JavaScript.
diff --git a/src/channels/jsconf-eu-2019.md b/src/channels/jsconf-eu-2019.md
index db36006a3e..0a4b98024b 100644
--- a/src/channels/jsconf-eu-2019.md
+++ b/src/channels/jsconf-eu-2019.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2019-06-01-jsconf-eu-2019/logo.png"
 url: https://2019.jsconf.eu
 ---
 
-JSConf EU is a major conference for the JavaScript community in Europe, annually
-taking place in Berlin, Germany.
+JSConf EU is a major conference for the JavaScript community in Europe, annually taking place in Berlin, Germany.
diff --git a/src/channels/product-circle.md b/src/channels/product-circle.md
index 94236409df..f7f3a15ce8 100644
--- a/src/channels/product-circle.md
+++ b/src/channels/product-circle.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2020-12-10-product-circle/logo.jpg"
 url: https://www.meetup.com/Product-Circle/
 ---
 
-Product Circle is a meetup for all PMO's, Product Owners, Project Managers,
-Delivery Leads, and anyone involved in a Digital Product/Project team.
+Product Circle is a meetup for all PMO's, Product Owners, Project Managers, Delivery Leads, and anyone involved in a Digital Product/Project team.
diff --git a/src/channels/rust-linux-inlaws.md b/src/channels/rust-linux-inlaws.md
new file mode 100644
index 0000000000..ca3fda812b
--- /dev/null
+++ b/src/channels/rust-linux-inlaws.md
@@ -0,0 +1,7 @@
+---
+title: "Linux Inlaws Podcast"
+image: "/assets/images/talks/2024-09-13-rust-linux-inlaws/logo.png"
+url: https://linuxinlaws.eu/#episodes
+---
+
+Linux Inlaws is a podcast dedicated to open-source software and technology, offering humorous insights and discussions. It has been running since January 2020.
diff --git a/src/channels/rustnationuk.md b/src/channels/rustnationuk.md
index 310af84d7a..5a392247c4 100644
--- a/src/channels/rustnationuk.md
+++ b/src/channels/rustnationuk.md
@@ -1,8 +1,7 @@
 ---
 title: "Rust Nation UK 2024"
-image: "/assets/images/talks/2024-03-26-rustnationuk-2024/logo.svg"
+image: "/assets/images/talks/2024-03-26-rustnationuk-2024/new-logo.png"
 url: https://www.rustnationuk.com/
 ---
 
-Rust Nation is the first UK conference dedicated to the Rust language. It was
-held in London on March 26th to 28th.
+Rust Nation is the first UK conference dedicated to the Rust language. It was held in London on March 26th to 28th.
diff --git a/src/channels/rustweb-barcelona.md b/src/channels/rustweb-barcelona.md
new file mode 100644
index 0000000000..ca2e4cbefd
--- /dev/null
+++ b/src/channels/rustweb-barcelona.md
@@ -0,0 +1,7 @@
+---
+title: "Rust for the web"
+image: "/assets/images/talks/2024-09-13-rustweb-barcelona/logo.png"
+url: https://www.meetup.com/es-ES/bcnrust/events/300765894/
+---
+
+“Rust for the web” Barcelona was an event organized by the Mainmatter team in collaboration with BCN Rust, and hosted by Adevinta Spain.
diff --git a/src/channels/rustweb-berlin.md b/src/channels/rustweb-berlin.md
index e13eb53cd3..efd3a78ced 100644
--- a/src/channels/rustweb-berlin.md
+++ b/src/channels/rustweb-berlin.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2024-04-23-rust-web-berlin/logo.png"
 url: https://www.meetup.com/rust-berlin/events/300047151/
 ---
 
-“Rust'n'tell - Rust for the Web” in Berlin in April 2024 was an event organized
-by Mainmatter in collaboration with the Rust Berlin meetup group.
+“Rust'n'tell - Rust for the Web” in Berlin in April 2024 was an event organized by Mainmatter in collaboration with the Rust Berlin meetup group.
diff --git a/src/channels/rustweb-london.md b/src/channels/rustweb-london.md
index 8eee3591af..906e373d69 100644
--- a/src/channels/rustweb-london.md
+++ b/src/channels/rustweb-london.md
@@ -4,6 +4,4 @@ image: "/assets/images/talks/2024-02-07-rustweb-london/logo.png"
 url: https://www.meetup.com/rust-london-user-group/events/298413388/
 ---
 
-“Rust for the Web” in London in February 2024 was an event organized by
-Mainmatter in collaboration with Vortexa, Shuttle, and the Rust London meetup,
-hosted by TrueLayer.
+“Rust for the Web” in London in February 2024 was an event organized by Mainmatter in collaboration with Vortexa, Shuttle, and the Rust London meetup, hosted by TrueLayer.
diff --git a/src/channels/rustweb.md b/src/channels/rustweb.md
index 3d9aabc7a8..fb5b8c7948 100644
--- a/src/channels/rustweb.md
+++ b/src/channels/rustweb.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2023-11-25-rust-web/logo.png"
 url: https://mobilizon.fr/events/149c0367-66cb-42c6-aa0c-8495bf6d2a52
 ---
 
-“Rust for the web” is an event organized by the Mainmatter team in collaboration
-with the Rust Paris meetup, and hosted by Qonto.
+“Rust for the web” is an event organized by the Mainmatter team in collaboration with the Rust Paris meetup, and hosted by Qonto.
diff --git a/src/channels/stackconf-2023.md b/src/channels/stackconf-2023.md
index 0ddbcc056a..ccca566c35 100644
--- a/src/channels/stackconf-2023.md
+++ b/src/channels/stackconf-2023.md
@@ -4,6 +4,4 @@ image: "/assets/images/talks/2023-09-13-stackconf-2023/logo.png"
 url: https://stackconf.eu/
 ---
 
-stackconf is a 2-day conference about open source infrastructure solutions in
-the spectrum of continuous integration, container, hybrid and cloud
-technologies.
+stackconf is a 2-day conference about open source infrastructure solutions in the spectrum of continuous integration, container, hybrid and cloud technologies.
diff --git a/src/channels/sveltesummit.md b/src/channels/sveltesummit.md
index c7ffbe9f98..f8f358cc9d 100644
--- a/src/channels/sveltesummit.md
+++ b/src/channels/sveltesummit.md
@@ -4,5 +4,4 @@ image: "/assets/images/talks/2023-11-11-enhance/logo.png"
 url: https://www.sveltesummit.com/
 ---
 
-Svelte Summit is a virtual event dedicated to Svelte and everything that is
-happening in the community.
+Svelte Summit is a virtual event dedicated to Svelte and everything that is happening in the community.
diff --git a/src/channels/viteconf-2024.md b/src/channels/viteconf-2024.md
new file mode 100644
index 0000000000..259019c139
--- /dev/null
+++ b/src/channels/viteconf-2024.md
@@ -0,0 +1,7 @@
+---
+title: "ViteConf"
+image: "/assets/images/talks/2024-10-03-viteconf/logo.png"
+url: https://viteconf.org/
+---
+
+ViteConf is a conference focused on Vite, the modern build tool and development server that enhances the front-end development experience with fast performance and a streamlined workflow.
diff --git a/src/clutch.njk b/src/clutch.njk
new file mode 100644
index 0000000000..16829bc8ab
--- /dev/null
+++ b/src/clutch.njk
@@ -0,0 +1,223 @@
+---
+layout: "base"
+title: "Team Up With Us for Better Tech!"
+description: "We transform bold ideas into shipped products, sharing our skills and expertise with our clients as teammates."
+og:
+  image: "/assets/images/clutch/og-image.jpg"
+---
+
+{% from "color-hero.njk" import colorHero %}
+{% from "featured-services.njk" import featuredServices %}
+{% from "logo-list.njk" import logoList %}
+{% from "featured-case-studies.njk" import featuredCaseStudies %}
+{% from "image-banner-with-text.njk" import imageBannerWithText %}
+{% from "cta-banner.njk" import ctaBanner %}
+{% from "image-aspect-ratio.njk" import imageAspectRatio %}
+{% from "quote.njk" import quote %}
+{% from "tech-cards.njk" import techCards %}
+{% from "btn-secondary.njk" import btnSecondary %}
+{%
+  set 'content' = {
+  "title": "Team Up With Us for Better Tech!",
+  "text": "We know the skills, practices and code that goes into winning product development. Our team of experts is ready to roll up their sleeves to help you tackle your toughest tech challenges so you can focus on your main matter.",
+  "image": "/assets/images/hero/home.jpg",
+  "alt": "Balloons flying over the sky",
+  "loading": "eager"
+  }
+%}
+{{ colorHero('purple', content) }}
+{%
+  set 'content' = {
+  "title": "Discover our services",
+  "subtitle": "Transform bold ideas into shipped products"
+  }
+%}
+{{ featuredServices(services['services-list-clutch'], content) }}
+{%
+  set awards = [
+  'ember',
+  'node',
+  'rust',
+  'financial',
+  'logistics',
+  'arts-entertainment',
+  'staff-aug'
+  ]
+%}
+{%- macro awardItem(award) -%}
+  {% set imagePath %}/assets/images/clutch/awards/{{ award }}.png{% endset %}
+  <li class="logo-list__item">
+    <div class="logo-list__image clutch-award__image">
+      {% image imagePath, "Clutch award icon", "5rem", "eager" %}
+    </div>
+  </li>
+{%- endmacro -%}
+<style>
+  .clutch-award__image img {
+    height: 12rem;
+    max-height: unset;
+    width: auto;
+  }
+</style>
+<section class="logo-list" id="logo-list">
+  <div class="logo-list__wrapper">
+    <div class="logo-list__inner" data-marquee style="--marquee-logo-count: {{ awards | length }};">
+      <ul class="logo-list__list">
+        {% for award in awards %}
+          {{ awardItem(award) }}
+        {% endfor %}
+      </ul>
+      <ul class="logo-list__list logo-list__list--duplicate" aria-hidden="true">
+        {% for award in awards %}
+          {{ awardItem(award) }}
+        {% endfor %}
+      </ul>
+    </div>
+  </div>
+  <button class="logo-list__button" data-marquee-controls>Pause animation</button>
+</section>
+
+<section class="mb-10">
+  {%
+    set imageData = {
+    "imgPath": "/assets/images/photos/balloons-top.jpeg",
+    "alt": "Server room",
+    "sizes": "100vw",
+    "loading": "lazy",
+    "sizesArray": [760, 1440, 1920]
+    }
+  %}
+  {{ imageAspectRatio(imageData, "32/13", "35/19") }}
+</section>
+
+{% set clients = ['experteer', 'mvb', 'trainline', 'ais'] %}
+{{ featuredCaseStudies(clients, 'Browse our work') }}
+
+<div class="container container--lg quote-section">
+  {%
+    set content = {
+    "text": "As we did not have any design or frontend expertise in-house, we could not professionally build the user interface of our platform and bring the product to the market. We were looking for support and chose to work with Mainmatter, which turned out to be a great partner for us. The experienced team of Mainmatter helped us release an MVP and set the foundation for developing the application in the future.",
+    "source": "Milivoj Simeonovski, Chief Product Officer (Founding)",
+    "image": "/assets/images/photos/milivoj-simeonovski.png",
+    "alt": "Milivoj Simeonovski smiling at the camera wearing a red sweater",
+    "loading": "lazy"
+    }
+  %}
+  {{ quote(content) }}
+</div>
+
+{%
+  set 'tech_1' = {
+  "title": "Rust is a competitive advantage",
+  "logo": "rust",
+  "link": "rust-consulting"
+  }
+%}
+{%
+  set 'tech_2' = {
+  "title": "Svelte is the future of frontend development",
+  "logo": "svelte",
+  "link": "svelte-consulting"
+  }
+%}
+{%
+  set 'tech_3' = {
+  "title": "Elixir and Phoenix: The best of all worlds",
+  "logo": "elixir",
+  "link": "expertise/elixir-phoenix"
+  }
+%}
+{%
+  set 'tech_4' = {
+  "title": "We're veteran Ruby and Ruby on Rails experts",
+  "logo": "ruby",
+  "link": "ruby-rails-consulting"
+  }
+%}
+{%
+  set 'tech_5' = {
+  "title": "Ember is our expertise",
+  "logo": "ember",
+  "link": "ember-consulting"
+  }
+%}
+{% set technologies = [tech_1, tech_2, tech_3, tech_4, tech_5] %}
+{{ techCards('team-reinforcement_technologies', 'Technologies', 'Our skillset is based on a core set of technologies that cover architecture, backend and frontend development with: ', technologies) }}
+
+<section class="my-10 container container--lg">
+  <div class="split-content">
+    <a href="https://clutch.co/profile/mainmatter" class="split-content__link"></a>
+    <div class="split-content__wrapper">
+      <div class="split-content__content">
+        <h4>
+          We are trusted by innovative companies with high ambitions – check out what they have to
+          say about us!
+        </h4>
+        {%
+          set link = {
+          "label": 'Read reviews',
+          "url": 'https://clutch.co/profile/mainmatter#reviews'
+          }
+        %}
+        {{ btnSecondary( link, 'mt-2' ) }}
+      </div>
+      <div class="split-content__feature">
+        <div class="secondary-feature">
+          <div class="secondary-feature__image-wrapper">
+            <script
+              type="text/javascript"
+              src="https://widget.clutch.co/static/js/widget.js"
+            ></script>
+            <div
+              class="clutch-widget"
+              data-url="https://widget.clutch.co"
+              data-widget-type="1"
+              data-height="80"
+              data-nofollow="true"
+              data-expandifr="true"
+              data-scale="100"
+              data-clutchcompany-id="850814"
+            ></div>
+          </div>
+        </div>
+      </div>
+    </div>
+  </div>
+</section>
+
+{%
+  set logoCompanies = [
+  'Qonto',
+  'Trainline',
+  'Aleph Alpha',
+  'Timify',
+  'Experteer',
+  'Robin Hood',
+  'Rail Europe'
+  ]
+%}
+{{ logoList(logoCompanies) }}
+
+<section class="mt-15 mb-0">
+  {%
+    set imageData = {
+    "imgPath": "/assets/images/photos/balloons-line.jpeg",
+    "alt": "Server room",
+    "sizes": "100vw",
+    "loading": "lazy",
+    "sizesArray": [760, 1440, 1920]
+    }
+  %}
+  {{ imageAspectRatio(imageData, "32/13", "35/19") }}
+</section>
+
+{% include "global/default-newsletter-cta.njk" %}
+{%
+  set 'content' = {
+  "title": "Team up with us for better tech!",
+  "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
+  "linkUrl": "/contact",
+  "linkText": "Get in touch"
+  }
+%}
+{{ ctaBanner('purple', 'full', content) }}
diff --git a/src/components/author-socials.njk b/src/components/author-socials.njk
index b05538ec3f..2d78ab14f6 100644
--- a/src/components/author-socials.njk
+++ b/src/components/author-socials.njk
@@ -21,6 +21,22 @@
           </a>
         </li>
       {% endif %}
+      {% if author.data.mastodon %}
+        <li>
+          <a class="author-socials__icon" href="{% mastodonHandleUrl author.data.mastodon %}">
+            {% include 'svg/social-mastodon.njk' %}
+            <span class="screenreader">{{ author.data.mastodon }} on Mastodon</span>
+          </a>
+        </li>
+      {% endif %}
+      {% if author.data.bluesky %}
+        <li>
+          <a class="author-socials__icon" href="https://bsky.app/profile/{{ author.data.bluesky }}">
+            {% include 'svg/social-bluesky.njk' %}
+            <span class="screenreader">{{ author.data.bluesky }} on Bluesky</span>
+          </a>
+        </li>
+      {% endif %}
     </ul>
   {% endif %}
 {%- endmacro -%}
diff --git a/src/components/contact-form.njk b/src/components/contact-form.njk
index dab44876f6..96b92332d9 100644
--- a/src/components/contact-form.njk
+++ b/src/components/contact-form.njk
@@ -9,7 +9,15 @@
         your next big move.
       </p>
       <h4 class="mt-10">Send us a message</h4>
-      <form class="contact-form__form" id="contact-form" data-status="initial">
+      <form
+        class="contact-form__form"
+        id="contact-form"
+        data-contact-form
+        data-status="initial"
+        data-action="https://contact.mainmatter.dev/send"
+        data-method="post"
+        data-goal="Contact"
+      >
         <div data-form-content tabindex="-1">
           <div class="contact-form__field">
             <input
@@ -62,7 +70,7 @@
               <option value="Strategic advice">Strategic advice</option>
               <option value="Workshops">Workshops</option>
               <option value="Ember Initiative">Ember Initiative</option>
-              <option value="Getting an Ember app on Vite">Getting an Ember app on Vite</option>
+              <option value="Travel Company Transformation">Travel Company Transformation</option>
               <option value="Other">Other</option>
             </select>
             <label class="contact-form__label h4" for="service"> How can we help you? </label>
@@ -95,7 +103,7 @@
         <div class="contact-form__status">
           <button class="contact-form__close" data-reset-form>
             {% include 'svg/close.njk' %}
-            <span class="screenreader">Close Menu</span>
+            <span class="screenreader">Close</span>
           </button>
           <div class="contact-form__loading h4" data-form-loading>
             Your message is being sent…
diff --git a/src/components/featured-case-studies.njk b/src/components/featured-case-studies.njk
index 0a7e4f5da3..275d0098f6 100644
--- a/src/components/featured-case-studies.njk
+++ b/src/components/featured-case-studies.njk
@@ -9,7 +9,9 @@ list: An array where each item is the slug for the case study.
 {%- macro featuredCaseStudies(caseStudies, heading) -%}
   <section class="featured-case-studies">
     <div class="container container--xl">
-      <h2 class="featured-case-studies__heading h5">{{ heading }}</h2>
+      {%- if heading -%}
+        <h2 class="featured-case-studies__heading h5">{{ heading }}</h2>
+      {%- endif -%}
       <ul class="featured-case-studies__list">
         {%- for caseStudyHandle in caseStudies -%}
           {% if loop.index === 1 %}
diff --git a/src/components/global/meta.njk b/src/components/global/meta.njk
index 03378a1f93..f284c23651 100644
--- a/src/components/global/meta.njk
+++ b/src/components/global/meta.njk
@@ -30,11 +30,13 @@
 {%- endif -%}
 
 {%- if pageDesc -%}
-  <meta name="description" content="{{ pageDesc }}" />
-  <meta name="twitter:description" content="{{ pageDesc }}" />
-  <meta property="og:description" content="{{ pageDesc }}" />
+  <meta name="description" content="{{ pageDesc | striptags(true) | escape | nl2br }}" />
+  <meta name="twitter:description" content="{{ pageDesc | striptags(true) | escape | nl2br }}" />
+  <meta property="og:description" content="{{ pageDesc | striptags(true) | escape | nl2br }}" />
 {%- endif -%}
 
+<meta name="fediverse:creator" content="@mainmatter@fosstodon.org" />
+
 {%- if og.image -%}
   <meta name="twitter:card" content="summary_large_image" />
   <meta name="twitter:title" content="{{ pageTitle }}" />
diff --git a/src/components/layouts/case-study.njk b/src/components/layouts/case-study.njk
index f1c33029e8..61bcd094a2 100644
--- a/src/components/layouts/case-study.njk
+++ b/src/components/layouts/case-study.njk
@@ -26,7 +26,7 @@ layout: base
   {% endif %}
   {%
     set 'content' = {
-    "title": "Grow your business with us",
+    "title": "Team up with us to go further!",
     "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
     "linkUrl": "/contact",
     "linkText": "Get in touch"
diff --git a/src/components/layouts/post.njk b/src/components/layouts/post.njk
index 917319e60f..381d556e78 100644
--- a/src/components/layouts/post.njk
+++ b/src/components/layouts/post.njk
@@ -103,7 +103,7 @@ layout: base
 {{ newsletterCta(tags) }}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/components/layouts/workshop.njk b/src/components/layouts/workshop.njk
index 82e81b74f7..f335668cdd 100644
--- a/src/components/layouts/workshop.njk
+++ b/src/components/layouts/workshop.njk
@@ -27,8 +27,10 @@ layout: "base"
       <div class="post__tagline">
         {% if tagline %}
           {{ tagline | safe }}
+          {% elseif introduction %}
+          {{ introduction | safe }}
         {% else %}
-          <p>{{ description | safe }}</p>
+          {{ description | safe }}
         {% endif %}
       </div>
     </div>
@@ -38,7 +40,7 @@ layout: "base"
     set 'content' = {
     "title": "Book this workshop",
     "text": "Our mentors look forward to working with your team and unlocking new capabilities.",
-    "linkUrl": "/contact",
+    "linkUrl": "#book-workshop",
     "linkText": "Get in touch"
     }
   %}
@@ -76,6 +78,113 @@ layout: "base"
     </div>
   </section>
 
+  <section
+    class="cta-banner cta-banner--purple container container--xl my-10"
+    data-background-color="purple"
+  >
+    <a id="book-workshop"></a>
+    <div class="cta-banner__wrapper">
+      <div class="cta-banner__main">
+        <h2 class="cta-banner__title">Book this workshop</h2>
+        <div class="cta-banner__text">
+          Our mentors look forward to working with your team and unlocking new capabilities.
+        </div>
+        <form
+          data-contact-form
+          class="contact-form__form"
+          data-status="initial"
+          data-action="https://hooks.zapier.com/hooks/catch/4837956/29yixsv/"
+          data-method="get"
+          data-goal="Workshop+Contact"
+        >
+          <input type="hidden" name="workshop" value="{{ title }}" />
+          <div data-form-content class="contact-form__field cta__input mb-2 mt-2">
+            <input
+              class="contact-form__input"
+              id="name"
+              type="text"
+              name="name"
+              placeholder="Your name"
+              required
+            />
+            <label class="contact-form__label h4" for="name">
+              Your name
+              <span class="screenreader">(Required)</span>
+            </label>
+            <span class="contact-form__label-required" aria-hidden="true">Required</span>
+          </div>
+          <div class="contact-form__field cta__input mb-2 mt-2">
+            <input
+              class="contact-form__input"
+              id="company"
+              type="text"
+              name="company"
+              placeholder="Your company's name"
+            />
+            <label class="contact-form__label h4" for="name"> Your company's name </label>
+          </div>
+          <div class="contact-form__field cta__input mb-2 mt-2">
+            <input
+              class="contact-form__input"
+              id="email"
+              type="email"
+              name="email"
+              placeholder="Your e-mail"
+              required
+            />
+            <label class="contact-form__label h4" for="email">
+              Your e-mail
+              <span class="screenreader">(Required)</span>
+            </label>
+            <span class="contact-form__label-required" aria-hidden="true">Required</span>
+          </div>
+          <div class="contact-form__field">
+            <textarea
+              class="contact-form__input"
+              id="contact-message"
+              name="message"
+              type="text"
+              placeholder="Tell us about your training needs"
+              rows="8"
+            ></textarea>
+            <label class="contact-form__label h4" for="contact-message">
+              Tell us about your training needs
+            </label>
+          </div>
+          <button class="btn-primary btn-primary--white" type="submit">
+            <span>Get in touch</span>
+            {% include 'svg/arrow.njk' %}
+          </button>
+          <div class="contact-form__status">
+            <button class="contact-form__close" data-reset-form>
+              {% include 'svg/close.njk' %}
+              <span class="screenreader">Close</span>
+            </button>
+            <div class="contact-form__loading h4" data-form-loading>
+              Your message is being sent…
+              <div class="loader" aria-hidden="true"></div>
+            </div>
+            <div class="contact-form__error" tabindex="-1" data-form-error>
+              <div class="contact-form__status-wrapper">
+                <h2 class="contact-form__success-subheading h3">Unable to send message.</h2>
+                <p>
+                  Please try again later or contact us at
+                  <a href="mailto:info@mainmatter.com">info@mainmatter.com</a>
+                </p>
+              </div>
+            </div>
+            <div class="contact-form__success" tabindex="-1" data-form-success>
+              <div class="contact-form__status-wrapper">
+                <h2 class="contact-form__success-heading h3">Thank you!</h2>
+                <p class="contact-form__success-subheading h3">We will be in touch soon.</p>
+              </div>
+            </div>
+          </div>
+        </form>
+      </div>
+    </div>
+  </section>
+
   {%
     set 'content' = {
     "title": "Not the right workshop for you?",
@@ -86,13 +195,4 @@ layout: "base"
   %}
   {{ ctaBanner('aqua', 'default', content) }}
   {{ newsletterCta(tags) }}
-  {%
-    set 'content' = {
-    "title": "Book this workshop",
-    "text": "Our mentors look forward to working with your team and unlocking new capabilities.",
-    "linkUrl": "/contact",
-    "linkText": "Get in touch"
-    }
-  %}
-  {{ ctaBanner('purple', 'full', content) }}
 {%- endblock -%}
diff --git a/src/components/strategy-list.njk b/src/components/strategy-list.njk
index 21b994cb90..a417376bf7 100644
--- a/src/components/strategy-list.njk
+++ b/src/components/strategy-list.njk
@@ -17,7 +17,7 @@
                 <span class="strategy-list__eyebrow mb-015 h5">{{ el.eyebrow }}</span>
               {% endif %}
               {% if el.title %}
-                <p class="strategy-list__title h4">{{ el.title }}</p>
+                <p class="strategy-list__title h4">{{ el.title | safe }}</p>
               {% endif %}
               {% if el.text %}
                 <p class="mt-2">{{ el.text | safe }}</p>
diff --git a/src/components/svg/social-bluesky.njk b/src/components/svg/social-bluesky.njk
new file mode 100644
index 0000000000..1c70d3c053
--- /dev/null
+++ b/src/components/svg/social-bluesky.njk
@@ -0,0 +1,16 @@
+<svg
+  focusable="false"
+  aria-hidden="false"
+  width="40"
+  height="40"
+  viewBox="0 0 40 40"
+  fill="none"
+  xmlns="http://www.w3.org/2000/svg"
+>
+  <path
+    fill-rule="evenodd"
+    clip-rule="evenodd"
+    d="M20.4166 40.4166C31.4623 40.4166 40.4166 31.4623 40.4166 20.4166C40.4166 9.37093 31.4623 0.416626 20.4166 0.416626C9.37093 0.416626 0.416626 9.37093 0.416626 20.4166C0.416626 31.4623 9.37093 40.4166 20.4166 40.4166ZM20.5768 20.3378C19.4467 18.0002 16.3687 13.6443 13.5071 11.496C11.4424 9.94582 8.09665 8.74641 8.09665 12.563C8.09665 13.3251 8.53365 18.966 8.78997 19.8819C9.68079 23.0657 12.9274 23.8778 15.8153 23.3863C10.7673 24.2452 9.48321 27.0912 12.2565 29.937C17.5237 35.3417 19.8269 28.5812 20.4171 26.8486L20.4171 26.8486C20.5253 26.531 20.5759 26.3824 20.5767 26.5087C20.5774 26.3824 20.628 26.531 20.7362 26.8486L20.7365 26.8493C21.3273 28.5829 23.6306 35.3408 28.8968 29.937C31.6701 27.0912 30.386 24.2454 25.338 23.3863C28.2259 23.8778 31.4724 23.0657 32.3634 19.8819C32.6197 18.9661 33.0567 13.3252 33.0567 12.563C33.0567 8.74641 29.7112 9.94582 27.6464 11.496C24.7847 13.6442 21.7069 18.0003 20.5768 20.3378Z"
+    fill="currentColor"
+  />
+</svg>
diff --git a/src/elixir-phoenix.njk b/src/elixir-phoenix.njk
index 04c5e8c3c2..f38a95bcf9 100644
--- a/src/elixir-phoenix.njk
+++ b/src/elixir-phoenix.njk
@@ -1,10 +1,10 @@
 ---
 layout: base
-title: Level-up your team with Elixir &amp; Phoenix experts
+title: "Team Up With Us for Elixir & Phoenix! | Elixir consulting"
 description: Augment your in-house team with Elixir & Phoenix technology experts. Speed up projects and remove long-standing issues – from refactoring to shipping new features.
 permalink: /expertise/elixir-phoenix/
 og:
-  image: /assets/images/elixir/lp-elixir-phoenix-consulting-og-image.jpg
+  image: /assets/images/elixir/og-image.png
 ---
 
 {% from "color-hero.njk" import colorHero %}
@@ -19,7 +19,7 @@ og:
 {% from "quote.njk" import quote %}
 {%
   set 'content' = {
-  "title": "Elixir & Phoenix",
+  "title": "Team Up With Us for Elixir & Phoenix!",
   "text": "Elixir and Phoenix form a modern and capable stack for building ambitious digital products of the future, based on an established foundation that has proven itself for decades.",
   "image": "/assets/images/hero/phoenix.jpg",
   "alt": "Feathers of a bird, maybe a phoenix",
@@ -112,8 +112,8 @@ og:
 {{ recentPosts("Latest from our blog on the topic", collections.elixirPosts) }}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
-  "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
+  "title": "Team up with us for Elixir and Phoenix!",
+  "text": "Our Elixir and Phoenix experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
   }
diff --git a/src/ember-consulting.njk b/src/ember-consulting.njk
index 0e2bbaed4d..98d05ab61f 100644
--- a/src/ember-consulting.njk
+++ b/src/ember-consulting.njk
@@ -1,10 +1,10 @@
 ---
 layout: base
-title: Europe's leading Ember experts | Ember consulting
+title: "Team Up With Us for Ember! | Ember consulting"
 description: Temporarily extend your team with Europe's leading Ember experts. Speed up projects and remove long-standing issues – from refactoring to shipping new features.
 permalink: /ember-consulting/
 og:
-  image: /assets/images/ember/lp-ember-consulting-og-image.jpg
+  image: /assets/images/ember/og-image.png
 ---
 
 {% from "text-with-list.njk" import textWithList %}
@@ -19,7 +19,7 @@ og:
 {%
   set 'content' = {
   "eyebrow": "Our Expertise: Ember",
-  "title": "Ember is our expertise",
+  "title": "Team Up With Us for Ember!",
   "text": "We are long-time Ember experts and active contributors to the ecosystem. Our team of community leaders makes Mainmatter the foremost Ember consultancy.",
   "image": "/assets/images/hero/ember.jpg",
   "alt": "A hamster sitting in the straw",
@@ -428,8 +428,8 @@ og:
 {% include "global/ember-newsletter-cta.njk" %}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
-  "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
+  "title": "Team up with us for Ember!",
+  "text": "Our Ember experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
   }
diff --git a/src/events.njk b/src/events.njk
index 1ea71b2e25..9e7ece8c87 100644
--- a/src/events.njk
+++ b/src/events.njk
@@ -80,7 +80,7 @@ eleventyImport:
 {% include "global/default-newsletter-cta.njk" %}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/feed.njk b/src/feed.njk
index 2bf22a8c4c..65068b3051 100644
--- a/src/feed.njk
+++ b/src/feed.njk
@@ -4,7 +4,7 @@ eleventyExcludeFromCollections: true
 layout: ""
 metadata:
   title: "Mainmatter"
-  subtitle: "We are Europe’s leading mobile and web design & development consultancy. Our clients value code quality, dependability and honesty. We are trusted by Generali, Qonto, Trainline, and CLARK."
+  subtitle: "We know the code, tools, and practices that go into successful development. We partner with our clients to solve their toughest tech challenges by sharing our skills and expertise as teammates."
   language: "en"
   url: "https://mainmatter.com/"
   author:
diff --git a/src/index.njk b/src/index.njk
index 2777d9dd9c..9e48b6c6ae 100644
--- a/src/index.njk
+++ b/src/index.njk
@@ -15,8 +15,8 @@ eleventyImport:
 {% from "image-aspect-ratio.njk" import imageAspectRatio %}
 {%
   set 'content' = {
-  "title": "Your expert guides for the journey ahead",
-  "text": "It takes brains to develop a no-brainer. At Mainmatter we teach, cross-pollinate and collaborate with our clients to develop digital products and practices they can build on.",
+  "title": "Team Up With Us To Go Further!",
+  "text": "We know the code, tools, and practices that go into successful development. We partner with our clients to solve their toughest tech challenges by sharing our skills and expertise as teammates.",
   "image": "/assets/images/hero/home.jpg",
   "alt": "Balloons flying over the sky",
   "loading": "eager"
@@ -177,7 +177,7 @@ eleventyImport:
 {% include "global/default-newsletter-cta.njk" %}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/playbook.njk b/src/playbook.njk
index ac07607a5e..badbf8f5ab 100644
--- a/src/playbook.njk
+++ b/src/playbook.njk
@@ -53,7 +53,7 @@ permalink: /playbook/
 {{ strategyList('playbook', list=elements) }}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/posts/2013-06-15-authentication-in-emberjs.md b/src/posts/2013-06-15-authentication-in-emberjs.md
index a35cee42f7..c5063c5ddb 100644
--- a/src/posts/2013-06-15-authentication-in-emberjs.md
+++ b/src/posts/2013-06-15-authentication-in-emberjs.md
@@ -3,33 +3,18 @@ title: "Authentication in ember.js"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
 tags: ember
-description:
-  "Marco Otte-Witte describes an approach for implementing a session mechanism,
-  authentication and authorization in Ember.js applications."
+description: "Marco Otte-Witte describes an approach for implementing a session mechanism, authentication and authorization in Ember.js applications."
 tagline: |
   <p><strong>Update:</strong><em>I released an Ember.js plugin that makes it very easy to implement an authentication system as described in this post: <a href="/blog/2013/10/09/embersimpleauth">Ember.SimpleAuth</a>.</em></p> <p><strong>Update:</strong> <em>After I wrote this I found out that it’s actually not the best approach to implement authentication in Ember.js… There are some things missing and some other things can be done in a much simpler way. <a href="/blog/2013/08/08/better-authentication-in-emberjs" title="(better) authnetication with ember.js">I wrote a summary of the (better) authentication mechanism we moved to.</a></em></p> <p><em>I’m using the latest (as of mid June 2013) <a href="https://github.com/emberjs/ember.js">ember</a>/<a href="https://github.com/emberjs/data">ember-data</a>/<a href="https://github.com/wycats/handlebars.js">handlebars</a> code directly from the respective github repositories in this example.</em></p>
 ---
 
-When we started our first project with [ember.js](http://emberjs.com), **the
-first thing we came across was how to implement authentication**. While all of
-us had implemented authentication in "normal" [Rails](http://rubyonrails.org)
-apps several times we initially weren’t sure how to do it in ember.js. Also
-information on the internet was scarce and hard to find.
+When we started our first project with [ember.js](http://emberjs.com), **the first thing we came across was how to implement authentication**. While all of us had implemented authentication in "normal" [Rails](http://rubyonrails.org) apps several times we initially weren’t sure how to do it in ember.js. Also information on the internet was scarce and hard to find.
 
-The only more elaborate sample project I found was the
-[ember-auth](https://github.com/heartsentwined/ember-auth) plugin. While that
-seemed to be very complete and high quality it is also very heavy weight and I
-didn’t want to add such a big thing to our codebase only to implement simple
-authentication into our app. So I rolled my own implementation.
+The only more elaborate sample project I found was the [ember-auth](https://github.com/heartsentwined/ember-auth) plugin. While that seemed to be very complete and high quality it is also very heavy weight and I didn’t want to add such a big thing to our codebase only to implement simple authentication into our app. So I rolled my own implementation.
 
 ## The basics
 
-The general route to go with authentication in ember.js is to use **token based
-authentication** where the client submits the regular username/password
-credentials to the server once and if those are valid receives an authentication
-token in response. That token is then sent along with every request the client
-makes to the server. Having understood this the first thing to do is to
-implement a regular login form with username and password fields:
+The general route to go with authentication in ember.js is to use **token based authentication** where the client submits the regular username/password credentials to the server once and if those are valid receives an authentication token in response. That token is then sent along with every request the client makes to the server. Having understood this the first thing to do is to implement a regular login form with username and password fields:
 
 ```hbs
 {% raw %}
@@ -47,10 +32,7 @@ implement a regular login form with username and password fields:
 {% endraw %}
 ```
 
-That template is backed by a route that handles the submission event and posts
-the data to the /session route on the server - which then responds with either
-status 401 or 200 and a JSON containing the authentication token and the id of
-the authenticated user:
+That template is backed by a route that handles the submission event and posts the data to the /session route on the server - which then responds with either status 401 or 200 and a JSON containing the authentication token and the id of the authenticated user:
 
 <!-- prettier-ignore -->
 ```js
@@ -81,13 +63,9 @@ App.SessionsNewRoute = Ember.Route.extend({
 {% endraw %}
 ```
 
-I’m using a route instead of a controller here as redirecting should only be
-done from routes and not controllers. See e.g.
-[this SO post](http://stackoverflow.com/questions/11552417/emberjs-how-to-transition-to-a-router-from-a-controllers-action/11555014#11555014)
-for more info.
+I’m using a route instead of a controller here as redirecting should only be done from routes and not controllers. See e.g. [this SO post](http://stackoverflow.com/questions/11552417/emberjs-how-to-transition-to-a-router-from-a-controllers-action/11555014#11555014) for more info.
 
-The response JSON from the server would look somehow like this in the successful
-login case:
+The response JSON from the server would look somehow like this in the successful login case:
 
 ```js
 {% raw %}on
@@ -100,11 +78,7 @@ login case:
 {% endraw %}
 ```
 
-At this point the client has the authentication data necessary to authenticate
-itself against the server. As tat authentication data would be lost every time
-the application on the client reloads and we don’t want to force a new login
-every time the user reloads the page we can simply **store that data in a cookie
-(of course you could use local storage etc.)**:
+At this point the client has the authentication data necessary to authenticate itself against the server. As tat authentication data would be lost every time the application on the client reloads and we don’t want to force a new login every time the user reloads the page we can simply **store that data in a cookie (of course you could use local storage etc.)**:
 
 ```js
 {% raw %}
@@ -115,13 +89,7 @@ $.cookie('auth_account', App.Auth.get('accountId'));
 
 ## Making authenticated requests
 
-The next step is to actually send the authentication token to the server. As the
-only point point of interaction between client and server in an ember.js app is
-**when the store adapter reads or writes data, the token has to be integrated in
-that adapter somehow**. As there’s not (yet) any out-off-the-box support for
-authentication in the
-[DS.RESTAdapter](https://github.com/emberjs/data/blob/v3.9.0/addon/adapters/rest.js),
-I simply added it myself:
+The next step is to actually send the authentication token to the server. As the only point point of interaction between client and server in an ember.js app is **when the store adapter reads or writes data, the token has to be integrated in that adapter somehow**. As there’s not (yet) any out-off-the-box support for authentication in the [DS.RESTAdapter](https://github.com/emberjs/data/blob/v3.9.0/addon/adapters/rest.js), I simply added it myself:
 
 ```js
 {% raw %}
@@ -136,12 +104,7 @@ App.AuthenticatedRESTAdapter = DS.RESTAdapter.extend({
 {% endraw %}
 ```
 
-Now the adapter will pass along the authentication token with every request to
-the server. One thing that should be made sure though is that whenever the
-adapter sees **a
-[401](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#401) response
-which would mean that for some reason the authentication token became invalid,
-the session data on the client is deleted** and we require a fresh login:
+Now the adapter will pass along the authentication token with every request to the server. One thing that should be made sure though is that whenever the adapter sees **a [401](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#401) response which would mean that for some reason the authentication token became invalid, the session data on the client is deleted** and we require a fresh login:
 
 ```js
 {% raw %}
@@ -156,13 +119,7 @@ DS.rejectionHandler = function (reason) {
 
 ## Enforcing authentication on the client
 
-Now that the general authentication mechanism is in place it would be cool to
-have a way of enforcing authentication on the client for specific routes so the
-user never gets to see any pages that they aren’t allowed to. This can be done
-by simply **introducing a custom route class that will check for the presence of
-a session and if none is present redirects to the login screen**. Any other
-routes that require authentication can then inherit from that one instead if the
-regular [`Ember.Route`](http://emberjs.com/api/classes/Ember.Route.html)
+Now that the general authentication mechanism is in place it would be cool to have a way of enforcing authentication on the client for specific routes so the user never gets to see any pages that they aren’t allowed to. This can be done by simply **introducing a custom route class that will check for the presence of a session and if none is present redirects to the login screen**. Any other routes that require authentication can then inherit from that one instead if the regular [`Ember.Route`](http://emberjs.com/api/classes/Ember.Route.html)
 
 ```js
 {% raw %}
@@ -179,10 +136,7 @@ App.AuthenticatedRoute = Ember.Route.extend({
 {% endraw %}
 ```
 
-This is actually very similar to the concept of an `AuthController` in Rails
-with a
-[`before_filter`](http://api.rubyonrails.org/classes/AbstractController/Callbacks/ClassMethods.html#method-i-before_filter)
-that enforces authentication:
+This is actually very similar to the concept of an `AuthController` in Rails with a [`before_filter`](http://api.rubyonrails.org/classes/AbstractController/Callbacks/ClassMethods.html#method-i-before_filter) that enforces authentication:
 
 ```rb
 class AuthenticatedController < ApplicationController
@@ -194,8 +148,7 @@ end
 
 ## Cleanup
 
-As the code is now spread up into a number of files and classes, I added a
-`Session` model:
+As the code is now spread up into a number of files and classes, I added a `Session` model:
 
 ```js
 {% raw %}
@@ -206,8 +159,7 @@ App.Session = DS.Model.extend({
 {% endraw %}
 ```
 
-alongside an `App.AuthManager` accompanied by a custom initializer to clean it
-up:
+alongside an `App.AuthManager` accompanied by a custom initializer to clean it up:
 
 <!-- prettier-ignore -->
 ```js
diff --git a/src/posts/2013-06-27-excellent-172.md b/src/posts/2013-06-27-excellent-172.md
index cc691869d7..8722ff1957 100644
--- a/src/posts/2013-06-27-excellent-172.md
+++ b/src/posts/2013-06-27-excellent-172.md
@@ -2,17 +2,13 @@
 title: "excellent 1.7.2"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces excellent 1.7.2 with 3 new checks and a more
-  forgiving and stable parser mechanism."
+description: "Marco Otte-Witte announces excellent 1.7.2 with 3 new checks and a more forgiving and stable parser mechanism."
 tags: ruby
 tagline: |
   <p>We just released excellent 1.7.2 which includes the following fixes:</p>
 ---
 
 - fixed `Simplabs::Excellent::Checks::Rails::CustomInitializeMethodCheck`
-- fixed `Simplabs::Excellent::Checks::MethodNameCheck` so it allows method names
-  that exist in Ruby itself
-- fixed `Simplabs::Excellent::Checks::GlobalVariableCheck` so it doesn't report
-  false positives for rescue bodies
+- fixed `Simplabs::Excellent::Checks::MethodNameCheck` so it allows method names that exist in Ruby itself
+- fixed `Simplabs::Excellent::Checks::GlobalVariableCheck` so it doesn't report false positives for rescue bodies
 - made the parser more forgiving/stable in some situations
diff --git a/src/posts/2013-06-28-excellent-200.md b/src/posts/2013-06-28-excellent-200.md
index 7cdfbc78fb..0db64b2205 100644
--- a/src/posts/2013-06-28-excellent-200.md
+++ b/src/posts/2013-06-28-excellent-200.md
@@ -2,21 +2,14 @@
 title: "excellent 2.0.0"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces excellent 2.0.0 with support for a configuration
-  file, a whitelist of allowed global variables and re-enabled standard checks."
+description: "Marco Otte-Witte announces excellent 2.0.0 with support for a configuration file, a whitelist of allowed global variables and re-enabled standard checks."
 tags: ruby
 tagline: |
   <p>We just released excellent 2.0.0 which has some big improvements:</p>
 ---
 
-- now supporting config file `.excellent.yml` in current working directory to
-  configure which specs to run/ not to run with thresholds, patterns etc.
-- predefined globals will not be reported anymore (`$!`, `$@`, `$&`,
-  `$```,`\$’`,`\$+`,`\$1`,`\$2..`,`\$~`,`\$=`,`\$/`,`\$\`,`\$,`,`\$;`,`\$.`,`\$`,`\$\_`,`\$0`,`\$\*`,`\$\$`,`\$?`,`\$:`,`\$"`,`\$DEBUG`,`\$FILENAME`,`\$LOAD_PATH`,`\$stdin`,`\$stdout`,`\$stderr`,`\$VERBOSE`,`\$-0`,`\$-a`,`\$-d`,`\$-F`,`\$-i`,`\$-I`,`\$-l`,`\$-p`,`\$-v`)
-- enabled previously disable checks again: `AbcMetricMethodCheck`,
-  `ControlCouplingCheck`, `CyclomaticComplexityBlockCheck`,
-  `CyclomaticComplexityMethodCheck`, `ForLoopCheck`, `FlogBlockCheck`,
-  `FlogClassCheck`, `FlogMethodCheck`
+- now supporting config file `.excellent.yml` in current working directory to configure which specs to run/ not to run with thresholds, patterns etc.
+- predefined globals will not be reported anymore (`$!`, `$@`, `$&`, `$```,`\$’`,`\$+`,`\$1`,`\$2..`,`\$~`,`\$=`,`\$/`,`\$\`,`\$,`,`\$;`,`\$.`,`\$`,`\$\_`,`\$0`,`\$\*`,`\$\$`,`\$?`,`\$:`,`\$"`,`\$DEBUG`,`\$FILENAME`,`\$LOAD_PATH`,`\$stdin`,`\$stdout`,`\$stderr`,`\$VERBOSE`,`\$-0`,`\$-a`,`\$-d`,`\$-F`,`\$-i`,`\$-I`,`\$-l`,`\$-p`,`\$-v`)
+- enabled previously disable checks again: `AbcMetricMethodCheck`, `ControlCouplingCheck`, `CyclomaticComplexityBlockCheck`, `CyclomaticComplexityMethodCheck`, `ForLoopCheck`, `FlogBlockCheck`, `FlogClassCheck`, `FlogMethodCheck`
 - testing now uses Rspec 2
 - internal cleanups/simplifications
diff --git a/src/posts/2013-08-08-better-authentication-in-emberjs.md b/src/posts/2013-08-08-better-authentication-in-emberjs.md
index 893fbff625..a811c162ba 100644
--- a/src/posts/2013-08-08-better-authentication-in-emberjs.md
+++ b/src/posts/2013-08-08-better-authentication-in-emberjs.md
@@ -2,46 +2,25 @@
 title: "(better) Authentication in ember.js"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte introduces an update to the mechanism for implementing a
-  session, authentication and authorization in Ember.js applications."
+description: "Marco Otte-Witte introduces an update to the mechanism for implementing a session, authentication and authorization in Ember.js applications."
 tags: ember
 tagline: |
   <p><strong>Update:</strong><em>I released an Ember.js plugin that makes it very easy to implement an authentication system as described in this post: <a href="/blog/2013/06/15/authentication-in-emberjs">Ember.SimpleAuth</a>.</em></p> <p>When we started our first <a href="http://emberjs.com">ember.js</a> project in June 2013, one of the first things we implemented was authentication. Now, almost 2 months later, <strong>it has become clear that our initial approach was not really the best and had some shortcomings. So I implemented a better authentication</strong> (mostly based on the embercasts on authentication).</p>
 ---
 
-_I’m using the latest (as of early August 2013) [ember.js](http://emberjs.com)
-and [handlebars](http://handlebarsjs.com) releases in this example._
+_I’m using the latest (as of early August 2013) [ember.js](http://emberjs.com) and [handlebars](http://handlebarsjs.com) releases in this example._
 
-_**Update:**I changed the section on actually using the token to use
-[\$.ajaxPrefilter](http://api.jquery.com/jQuery.ajaxPrefilter/) instead of a
-custom ember-data adapter_
+_**Update:**I changed the section on actually using the token to use [\$.ajaxPrefilter](http://api.jquery.com/jQuery.ajaxPrefilter/) instead of a custom ember-data adapter_
 
 ## The basics
 
-The basic approach is still the same as in our initial implementation - we have
-a **`/session` route in our Rails app that the client `POST`s its credentials to
-and if those are valid gets back an authentication token** together with an id
-that identifies the user’s account on the server side.
+The basic approach is still the same as in our initial implementation - we have a **`/session` route in our Rails app that the client `POST`s its credentials to and if those are valid gets back an authentication token** together with an id that identifies the user’s account on the server side.
 
-This data is stored in a _"session"_ object on the client side (while
-technically there is no session in this stateless authentication mechanism, I
-still call it session in absence of an idea for a better name). The
-**authentication token is then sent in a header** with every request the client
-makes.
+This data is stored in a _"session"_ object on the client side (while technically there is no session in this stateless authentication mechanism, I still call it session in absence of an idea for a better name). The **authentication token is then sent in a header** with every request the client makes.
 
 ## The client _"session"_
 
-The _"session"_ object on the client side is a **plain `Ember.Object` that
-simply keeps the data that is received from the server** on session creation. It
-also stores the authentication token and the user’s account ID in cookies so the
-user doesn’t have to login again after a page reload (As Ed points out in a
-comment on the old post it’s a security issue to store the authentication token
-in a cookie without the user’s permission - I think using a session cookie like
-I do should be ok as it’s deleted when the browser window is closed. Of course
-you could also use sth. like localStorage like Marc points out. I’m creating
-this object in an initializer so I can be sure it exists (of course it might be
-empty) when the application starts.
+The _"session"_ object on the client side is a **plain `Ember.Object` that simply keeps the data that is received from the server** on session creation. It also stores the authentication token and the user’s account ID in cookies so the user doesn’t have to login again after a page reload (As Ed points out in a comment on the old post it’s a security issue to store the authentication token in a cookie without the user’s permission - I think using a session cookie like I do should be ok as it’s deleted when the browser window is closed. Of course you could also use sth. like localStorage like Marc points out. I’m creating this object in an initializer so I can be sure it exists (of course it might be empty) when the application starts.
 
 <!-- prettier-ignore -->
 ```js
@@ -74,22 +53,11 @@ Ember.Application.initializer({
 {% endraw %}
 ```
 
-When this has run I can always access the current _"session"_ information as
-`App.Session`. Notice the `.create()` at the end of the initializer that creates
-an instance of the `Ember.Object` right away. When we need to **check whether a
-user is authenticated we can simply check for presence of the `authToken`
-property**. Of course we could add a `isAuthenticated()` method that could
-perform additional checks but we didn’t have the need for that yet.
+When this has run I can always access the current _"session"_ information as `App.Session`. Notice the `.create()` at the end of the initializer that creates an instance of the `Ember.Object` right away. When we need to **check whether a user is authenticated we can simply check for presence of the `authToken` property**. Of course we could add a `isAuthenticated()` method that could perform additional checks but we didn’t have the need for that yet.
 
-This _"session"_ object will also load the actual account record from the server
-if the `authAccountId` is set
-(`this.set('authAccount', App.Account.find(authAccountId));`. This allows us to
-e.g. use `App.Session.authAccount.fullName` in our templates to display the
-user’s name or similar data.)
+This _"session"_ object will also load the actual account record from the server if the `authAccountId` is set (`this.set('authAccount', App.Account.find(authAccountId));`. This allows us to e.g. use `App.Session.authAccount.fullName` in our templates to display the user’s name or similar data.)
 
-To actually use the `authToken` when making server requests, **we register an
-[AJAX prefilter](http://api.jquery.com/jQuery.ajaxPrefilter/) that adds the
-authentication token in a header as long as the request is sent to our domain**:
+To actually use the `authToken` when making server requests, **we register an [AJAX prefilter](http://api.jquery.com/jQuery.ajaxPrefilter/) that adds the authentication token in a header as long as the request is sent to our domain**:
 
 ```js
 {% raw %}
@@ -104,8 +72,7 @@ Ember.$.ajaxPrefilter(function (options, originalOptions, jqXHR) {
 {% endraw %}
 ```
 
-The Rails server can then find the authenticated user by the token in the
-header:
+The Rails server can then find the authenticated user by the token in the header:
 
 ```rb
 class ApplicationController < ActionController::Base
@@ -122,11 +89,7 @@ end
 
 ## Logging in
 
-As described above, the login API is a simple `/session` route on the server
-side that accepts the user’s login and password and **responds with either HTTP
-status 401 when the credentials are invalid or a session JSON when the
-authentication was successful**. On the client side we have routes for creating
-and destroying the session:
+As described above, the login API is a simple `/session` route on the server side that accepts the user’s login and password and **responds with either HTTP status 401 when the credentials are invalid or a session JSON when the authentication was successful**. On the client side we have routes for creating and destroying the session:
 
 <!-- prettier-ignore -->
 ```js
@@ -140,14 +103,7 @@ App.Router.map(function() {
 {% endraw %}
 ```
 
-The `SessionNewController` only needs one action `login` that sends the entered
-credentials and acts according to the server’s response - if the server responds
-successfully **it reads the session data from the response and updates the
-`App.Session` object accordingly**. It also checks whether there is an attempted
-transition that was intercepted due to missing authentication and retries that
-if it exists (This is the case where the user tries to access a certain page
-without having authenticated, is redirected to the login form, logs in and is
-redirected again to the initially requested page).
+The `SessionNewController` only needs one action `login` that sends the entered credentials and acts according to the server’s response - if the server responds successfully **it reads the session data from the response and updates the `App.Session` object accordingly**. It also checks whether there is an attempted transition that was intercepted due to missing authentication and retries that if it exists (This is the case where the user tries to access a certain page without having authenticated, is redirected to the login form, logs in and is redirected again to the initially requested page).
 
 <!-- prettier-ignore -->
 ```js
@@ -178,12 +134,9 @@ App.SessionNewController = Ember.Controller.extend({
 {% endraw %}
 ```
 
-Notice that we do not handle the error case here. To have a better user
-experience you would probably want to define a `.fail` handler as well that
-display an error message.
+Notice that we do not handle the error case here. To have a better user experience you would probably want to define a `.fail` handler as well that display an error message.
 
-The template is just a simple form (actual elements, classes etc. of course
-depend on your specific application):
+The template is just a simple form (actual elements, classes etc. of course depend on your specific application):
 
 ```hbs
 {% raw %}
@@ -206,11 +159,7 @@ depend on your specific application):
 
 ## Logging out
 
-Logging out is actually pretty simple as well. The **client just sends a
-`DELETE` to the same `/session` route** that makes the server reset the
-authentication token in the database so that the token on the client side is
-invalidated. The client also deletes the saved session information in
-`App.Session` so there’s no stale data.
+Logging out is actually pretty simple as well. The **client just sends a `DELETE` to the same `/session` route** that makes the server reset the authentication token in the database so that the token on the client side is invalidated. The client also deletes the saved session information in `App.Session` so there’s no stale data.
 
 <!-- prettier-ignore -->
 ```js
@@ -233,9 +182,7 @@ App.SessionDestroyController = Ember.Controller.extend({
 {% endraw %}
 ```
 
-As this action should be triggered as soon as the user enters the
-`/#/session/destroy` route, we have a simple route implementation that
-**triggers the action upon route activation**:
+As this action should be triggered as soon as the user enters the `/#/session/destroy` route, we have a simple route implementation that **triggers the action upon route activation**:
 
 <!-- prettier-ignore -->
 ```js
@@ -250,9 +197,7 @@ App.SessionDestroyRoute = Ember.Route.extend({
 
 ## Authenticated routes
 
-To easily enable authentication for any route in the application, I created an
-**`App.AuthenticatedRoute` that extends `Ember.Route`** and that all routes that
-need to enforce user authentication can extend again:
+To easily enable authentication for any route in the application, I created an **`App.AuthenticatedRoute` that extends `Ember.Route`** and that all routes that need to enforce user authentication can extend again:
 
 <!-- prettier-ignore -->
 ```js
@@ -272,8 +217,6 @@ App.AuthenticatedRoute = Ember.Route.extend({
 {% endraw %}
 ```
 
-Notice that `redirectToLogin` sets the `attemptedTransition` of `App.Session` so
-that the user will be redirected to the initially requested page after
-successfulyl logging in.
+Notice that `redirectToLogin` sets the `attemptedTransition` of `App.Session` so that the user will be redirected to the initially requested page after successfulyl logging in.
 
 This is better authentication with ember.js - enjoy!
diff --git a/src/posts/2013-10-09-embersimpleauth.md b/src/posts/2013-10-09-embersimpleauth.md
index 3ab0b42c8b..dca27776fa 100644
--- a/src/posts/2013-10-09-embersimpleauth.md
+++ b/src/posts/2013-10-09-embersimpleauth.md
@@ -2,26 +2,17 @@
 title: "Ember.SimpleAuth"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces Ember.SimpleAuth, an addon for implementing a
-  session mechanism, authentication and authorization for Ember.js applications."
+description: "Marco Otte-Witte announces Ember.SimpleAuth, an addon for implementing a session mechanism, authentication and authorization for Ember.js applications."
 tags: ember
 tagline: |
   <p><strong>Update: <a href="/blog/2014/01/20/embersimpleauth-010">Ember.SimpleAuth 0.1.0 has been released!</a></strong> The information in this is (partially) outdated.</p> <p>After I wrote 2 <a href="/blog/2013/06/15/authentication-in-emberjs" title="the initial post">blog</a> <a href="/blog/2013/08/08/better-authentication-in-emberjs" title="the second post with a refined implementation">posts</a> on implementing token based authentication in <a href="http://emberjs.com">Ember.js</a> applications and got quite some feedback, good suggestions etc., I thought it <strong>would be nice to pack all these ideas in an Ember.js plugin</strong> so everybody could easily integrate that into their applications. Now <strong>I finally managed to release version 0.0.1 of that plugin</strong>: <a href="https://github.com/mainmatter/ember-simple-auth">Ember.SimpleAuth</a>.</p>
 ---
 
-Instead of providing a heavyweight out-of-the-box solution with predefined
-routes, controllers etc., Ember.SimpleAuth defines lightweight mixins that the
-application code implements. It also **does not dictate anything with respect to
-application structure, routing etc**. However, setting up Ember.SimpleAuth is
-**very straight forward** and it can be **completely customized**. The
-requirements on the server interface are minimal
-([see the README for more information on the server side](https://github.com/mainmatter/ember-simple-auth#the-server-side)).
+Instead of providing a heavyweight out-of-the-box solution with predefined routes, controllers etc., Ember.SimpleAuth defines lightweight mixins that the application code implements. It also **does not dictate anything with respect to application structure, routing etc**. However, setting up Ember.SimpleAuth is **very straight forward** and it can be **completely customized**. The requirements on the server interface are minimal ([see the README for more information on the server side](https://github.com/mainmatter/ember-simple-auth#the-server-side)).
 
 ## Using Ember.SimpleAuth
 
-Using Ember.SimpleAuth in an application only requires a few simple steps.
-First, it must be enabled which is best done in a custom initializer:
+Using Ember.SimpleAuth in an application only requires a few simple steps. First, it must be enabled which is best done in a custom initializer:
 
 ```js
 {% raw %}
@@ -45,8 +36,7 @@ App.Router.map(function () {
 {% endraw %}
 ```
 
-Then, the generated **controller and route must implement the mixins provided by
-Ember.SimpleAuth**:
+Then, the generated **controller and route must implement the mixins provided by Ember.SimpleAuth**:
 
 ```js
 {% raw %}
@@ -82,12 +72,7 @@ Of course the application also needs a template that renders the login form:
 {% endraw %}
 ```
 
-At this point, everything that’s necessary for users to log in and out is set
-up. Also, every AJAX request (unless it’s a cross domain request) that the
-application makes will send the authentication token that is obtained when the
-user logs in. **To actually protect routes so that they are only accessible for
-authenticated users, simply implement the respective Ember.SimpleAuth mixin** in
-the route classes:
+At this point, everything that’s necessary for users to log in and out is set up. Also, every AJAX request (unless it’s a cross domain request) that the application makes will send the authentication token that is obtained when the user logs in. **To actually protect routes so that they are only accessible for authenticated users, simply implement the respective Ember.SimpleAuth mixin** in the route classes:
 
 ```js
 {% raw %}
@@ -99,10 +84,6 @@ App.ProtectedRoute = Ember.Route.extend(
 
 ## More
 
-There is more documentation as well as examples in the
-[repository on github](https://github.com/mainmatter/ember-simple-auth). Also
-the **code base is quite small so I suggest to read through it** to better
-understand what’s going on internally.
+There is more documentation as well as examples in the [repository on github](https://github.com/mainmatter/ember-simple-auth). Also the **code base is quite small so I suggest to read through it** to better understand what’s going on internally.
 
-Patches, bug reports etc. are highly appreciated of course -
-[get started by forking the project on github](https://github.com/mainmatter/ember-simple-auth)!
+Patches, bug reports etc. are highly appreciated of course - [get started by forking the project on github](https://github.com/mainmatter/ember-simple-auth)!
diff --git a/src/posts/2013-10-28-embersimpleauth-implements-rfc-6749-oauth-20.md b/src/posts/2013-10-28-embersimpleauth-implements-rfc-6749-oauth-20.md
index ad4aa7f870..96a2957a74 100644
--- a/src/posts/2013-10-28-embersimpleauth-implements-rfc-6749-oauth-20.md
+++ b/src/posts/2013-10-28-embersimpleauth-implements-rfc-6749-oauth-20.md
@@ -2,31 +2,17 @@
 title: "Ember.SimpleAuth implements RFC 6749 (OAuth 2.0)"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces support for OAuth 2.0 in Ember.SimpleAuth, the
-  addon for implementing a session and authentication/authorization for
-  Ember.js."
+description: "Marco Otte-Witte announces support for OAuth 2.0 in Ember.SimpleAuth, the addon for implementing a session and authentication/authorization for Ember.js."
 tags: ember
 tagline: |
   <p><strong>Update: <a href="/blog/2014/01/20/embersimpleauth-010">Ember.SimpleAuth 0.1.0 has been released!</a></strong> The information in this is (partially) outdated.</p> <p>With the <a href="https://github.com/mainmatter/ember-simple-auth/releases/tag/0.0.4">release of Ember.SimpleAuth 0.0.4</a> <strong>the library is compliant with OAuth 2.0</strong> - specifically it implements the <em>&quot;Resource Owner Password Credentials Grant Type&quot;</em> as defined in <a href="http://tools.ietf.org/html/rfc6749">RFC 6749</a> (thanks <a href="https://github.com/adamlc">adamlc</a> for the suggestion). While this is only a minor change in terms of functionality and data flow, used headers etc. it makes everyone’s life a lot easier as instead of implementing your own server endpoints you can now utilize <a href="https://github.com/search?q=oauth%20middleware">one of several OAuth 2.0 middlewares that already implement the spec</a>.</p>
 ---
 
-With the OAuth 2.0 support also comes **support for access token expiration and
-[refresh tokens](http://tools.ietf.org/html/rfc6749#section-6)**. Using expiring
-access tokens improves overall security as replay attacks are less likely while
-with refresh tokens **Ember.SimpleAuth can automatically obtain new access
-tokens** before they expire so that the user doesn’t recognize the token
-actually changes.
+With the OAuth 2.0 support also comes **support for access token expiration and [refresh tokens](http://tools.ietf.org/html/rfc6749#section-6)**. Using expiring access tokens improves overall security as replay attacks are less likely while with refresh tokens **Ember.SimpleAuth can automatically obtain new access tokens** before they expire so that the user doesn’t recognize the token actually changes.
 
 ## Other changes
 
-Other smaller additions include **support for
-[external OAuth/OpenID providers](https://github.com/mainmatter/ember-simple-auth#external-oauthopenid-providers)**
-and
-[manipulation of the request used to obtain the access token](https://github.com/mainmatter/ember-simple-auth#custom-server-protocols).
-Also the API was simplified and the `login` and `logout` actions were moved to
-the `ApplicationControllerMixin` and the `/logout` route has been removed. The
-new API now looks like this:
+Other smaller additions include **support for [external OAuth/OpenID providers](https://github.com/mainmatter/ember-simple-auth#external-oauthopenid-providers)** and [manipulation of the request used to obtain the access token](https://github.com/mainmatter/ember-simple-auth#custom-server-protocols). Also the API was simplified and the `login` and `logout` actions were moved to the `ApplicationControllerMixin` and the `/logout` route has been removed. The new API now looks like this:
 
 ```js
 {% raw %}
@@ -53,10 +39,4 @@ App.LoginController = Ember.Controller.extend(
 
 ## Future plans
 
-Currently I’m working on adding API documentation within the source together
-with a means of generating some nice HTML out of that. I don’t currently see
-that there is much else missing in the library so **I’d like to release a 1.0.0
-version soon**. Of course I’d like to make sure that Ember.SimpleAuth is
-actually being used and working so
-[please submit bug reports, patches etc.](https://github.com/mainmatter/ember-simple-auth)
-or **provide general feedback/ideas!**
+Currently I’m working on adding API documentation within the source together with a means of generating some nice HTML out of that. I don’t currently see that there is much else missing in the library so **I’d like to release a 1.0.0 version soon**. Of course I’d like to make sure that Ember.SimpleAuth is actually being used and working so [please submit bug reports, patches etc.](https://github.com/mainmatter/ember-simple-auth) or **provide general feedback/ideas!**
diff --git a/src/posts/2014-01-20-embersimpleauth-010.md b/src/posts/2014-01-20-embersimpleauth-010.md
index dda3c17cea..76b5480eb2 100644
--- a/src/posts/2014-01-20-embersimpleauth-010.md
+++ b/src/posts/2014-01-20-embersimpleauth-010.md
@@ -2,10 +2,7 @@
 title: "Ember.SimpleAuth 0.1.0"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces Ember.SimpleAuth 0.1.0 with an improved
-  architecture that allows for arbitrary authentication and authorization
-  strategies."
+description: "Marco Otte-Witte announces Ember.SimpleAuth 0.1.0 with an improved architecture that allows for arbitrary authentication and authorization strategies."
 tags: ember
 tagline: |
   <p>Since <a href="https://github.com/mainmatter/ember-simple-auth">Ember.SimpleAuth</a> was released in October 2013, there were lots of issues reported, pull requests submitted and merged etc. <strong>Now all this feedback together with some fundamental design improvements results in the <a href="https://github.com/mainmatter/ember-simple-auth/releases/tag/0.1.0">release of the 0.1.0 version of Ember.SimpleAuth</a>.</strong> This is hopefully paving the way for a soon-to-be-released version 1.0.</p>
@@ -13,12 +10,7 @@ tagline: |
 
 ## What changed?
 
-The most significant change is the **extraction of everything specific to
-specific authentication/authorization mechanisms (e.g. the default OAuth 2.0
-implementation) into strategy classes** which significantly improves
-customizability and extensibility. Instead of having to override parts of the
-library, using e.g. a custom authentication method is now as simple as
-specifying the class in the respective controller:
+The most significant change is the **extraction of everything specific to specific authentication/authorization mechanisms (e.g. the default OAuth 2.0 implementation) into strategy classes** which significantly improves customizability and extensibility. Instead of having to override parts of the library, using e.g. a custom authentication method is now as simple as specifying the class in the respective controller:
 
 ```js
 {% raw %}
@@ -31,25 +23,13 @@ App.LoginController = Ember.Controller.extend(
 {% endraw %}
 ```
 
-This **makes implementations cleaner and also helps defining the public API that
-Ember.SimpleAuth** will settle on in the long term.
+This **makes implementations cleaner and also helps defining the public API that Ember.SimpleAuth** will settle on in the long term.
 
-Other changes include the introduction of store strategies (Ember.SimpleAuth
-comes with a cookie store that is equivalent to the old store, a store that uses
-the browser’s localStorage API and which is the new default as well as an
-in-memory store which is mainly useful for testing) as well as error
-handling/token invalidation, added callback actions like
-`sessionInvalidationSucceeded` etc. See the
-[README](https://github.com/mainmatter/ember-simple-auth#readme) and the
-[API docs](http://ember-simple-auth.com/api/) for complete documentation.
+Other changes include the introduction of store strategies (Ember.SimpleAuth comes with a cookie store that is equivalent to the old store, a store that uses the browser’s localStorage API and which is the new default as well as an in-memory store which is mainly useful for testing) as well as error handling/token invalidation, added callback actions like `sessionInvalidationSucceeded` etc. See the [README](https://github.com/mainmatter/ember-simple-auth#readme) and the [API docs](http://ember-simple-auth.com/api/) for complete documentation.
 
 ## Upgrading
 
-Upgrading will be pretty straight forward in most cases. The main change that
-could bite you is probably the change in `Ember.SimpleAuth.setup`’s signature.
-While it used to expect the `container` as well as the application instance,
-**the `container` argument was dropped** as it wasn’t actually needed. So in the
-initializer, change this:
+Upgrading will be pretty straight forward in most cases. The main change that could bite you is probably the change in `Ember.SimpleAuth.setup`’s signature. While it used to expect the `container` as well as the application instance, **the `container` argument was dropped** as it wasn’t actually needed. So in the initializer, change this:
 
 ```js
 {% raw %}
@@ -75,9 +55,7 @@ Ember.Application.initializer({
 {% endraw %}
 ```
 
-Also, as the **`login` and `logout` actions in `ApplicationRouteMixin` were
-renamed to `authenticateSession` and `invalidateSession`**, in your templates
-change this:
+Also, as the **`login` and `logout` actions in `ApplicationRouteMixin` were renamed to `authenticateSession` and `invalidateSession`**, in your templates change this:
 
 ```hbs
 {% raw %}
@@ -101,8 +79,7 @@ to this:
 {% endraw %}
 ```
 
-Also the **`LoginControllerMixin`’s `login` action was renamed to
-`authenticate`** so in your login template change this:
+Also the **`LoginControllerMixin`’s `login` action was renamed to `authenticate`** so in your login template change this:
 
 ```hbs
 {% raw %}
@@ -118,17 +95,8 @@ to this:
 {% endraw %}
 ```
 
-These are really the only changes needed if your application is using
-Ember.SimpleAuth’s default settings, the default OAuth 2.0 mechanism etc. For
-other scenarios, see the
-[README](https://github.com/mainmatter/ember-simple-auth#readme),
-[API docs](http://ember-simple-auth.com/api/) and also the examples provided in
-the repository.
+These are really the only changes needed if your application is using Ember.SimpleAuth’s default settings, the default OAuth 2.0 mechanism etc. For other scenarios, see the [README](https://github.com/mainmatter/ember-simple-auth#readme), [API docs](http://ember-simple-auth.com/api/) and also the examples provided in the repository.
 
 ## Outlook
 
-**I hope that this release can pave the way towards a stable API for
-Ember.SimpleAuth.** It would also be great of course if many people came up with
-authenticator and authorizer implementations for all kinds of backends to prove
-the design of Ember.SimpleAuth’s strategy approach as well as to build a library
-of ready-to-use strategies for the most common setups.
+**I hope that this release can pave the way towards a stable API for Ember.SimpleAuth.** It would also be great of course if many people came up with authenticator and authorizer implementations for all kinds of backends to prove the design of Ember.SimpleAuth’s strategy approach as well as to build a library of ready-to-use strategies for the most common setups.
diff --git a/src/posts/2014-03-11-embersimpleauth-020.md b/src/posts/2014-03-11-embersimpleauth-020.md
index ed77b7e015..25e7ba126e 100644
--- a/src/posts/2014-03-11-embersimpleauth-020.md
+++ b/src/posts/2014-03-11-embersimpleauth-020.md
@@ -2,14 +2,10 @@
 title: "Ember.SimpleAuth 0.2.0"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces Ember.SimpleAuth 0.2.0 with a completely rebuilt
-  build and testing infrastructure as well as important bug fixes."
+description: "Marco Otte-Witte announces Ember.SimpleAuth 0.2.0 with a completely rebuilt build and testing infrastructure as well as important bug fixes."
 tags: ember
 tagline: |
   <p>We released Ember.SimpleAuth 0.2.0.</p>
 ---
 
-Ember.SimpleAuth was released with a **completely rebuilt build and testing
-infrastructure as well as some important bug fixes. Find the
-[complete release notes on github](https://github.com/mainmatter/ember-simple-auth/releases/tag/0.2.0).**
+Ember.SimpleAuth was released with a **completely rebuilt build and testing infrastructure as well as some important bug fixes. Find the [complete release notes on github](https://github.com/mainmatter/ember-simple-auth/releases/tag/0.2.0).**
diff --git a/src/posts/2014-04-06-embersimpleauth-021.md b/src/posts/2014-04-06-embersimpleauth-021.md
index 724fa0d3ab..6df2f8580e 100644
--- a/src/posts/2014-04-06-embersimpleauth-021.md
+++ b/src/posts/2014-04-06-embersimpleauth-021.md
@@ -2,13 +2,10 @@
 title: "Ember.SimpleAuth 0.2.1"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces Ember.SimpleAuth 0.2.1 with some minor
-  improvements."
+description: "Marco Otte-Witte announces Ember.SimpleAuth 0.2.1 with some minor improvements."
 tags: ember
 tagline: |
   <p>We released Ember.SimpleAuth 0.2.1.</p>
 ---
 
-Ember.SimpleAuth 0.2.1 was released with some minor improvements:
-[https://github.com/mainmatter/ember-simple-auth/releases/tag/0.2.1](https://github.com/mainmatter/ember-simple-auth/releases/tag/0.2.1)
+Ember.SimpleAuth 0.2.1 was released with some minor improvements: [https://github.com/mainmatter/ember-simple-auth/releases/tag/0.2.1](https://github.com/mainmatter/ember-simple-auth/releases/tag/0.2.1)
diff --git a/src/posts/2014-04-10-embersimpleauth-030.md b/src/posts/2014-04-10-embersimpleauth-030.md
index f08edb0da8..e5eb1c884f 100644
--- a/src/posts/2014-04-10-embersimpleauth-030.md
+++ b/src/posts/2014-04-10-embersimpleauth-030.md
@@ -2,9 +2,7 @@
 title: "Ember.SimpleAuth 0.3.0"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces Ember.SimpleAuth 0.3.0, splitting the addon into a
-  core and extensions for specific authentication/authorization mechanisms."
+description: "Marco Otte-Witte announces Ember.SimpleAuth 0.3.0, splitting the addon into a core and extensions for specific authentication/authorization mechanisms."
 tags: ember
 tagline: |
   <p>Ember.SimpleAuth 0.3.0 was just released. The <strong>main change in this release is the split of Ember.SimpleAuth into one core library and a set of extension libraries</strong>. These extension libraries include everything that’s not mandatorily required for Ember.SimpleAuth like authenticators, stores etc. so that every application would only have to load whatever it needs.</p>
@@ -12,26 +10,13 @@ tagline: |
 
 These extension libraries are:
 
-- **ember-simple-auth-oauth2**: includes the OAuth 2.0 authenticator and
-  authorizer which are just one option out of many and probably not needed in
-  many projects (e.g. when using a custom authenticator)
-- **ember-simple-auth-devise**: new authenticator/authorizer package that is
-  compatible with the Ruby gem
-  [devise](https://github.com/plataformatec/devise).
-- **ember-simple-auth-cookie-store**: The cookie store which is probably only
-  used in few projects.
+- **ember-simple-auth-oauth2**: includes the OAuth 2.0 authenticator and authorizer which are just one option out of many and probably not needed in many projects (e.g. when using a custom authenticator)
+- **ember-simple-auth-devise**: new authenticator/authorizer package that is compatible with the Ruby gem [devise](https://github.com/plataformatec/devise).
+- **ember-simple-auth-cookie-store**: The cookie store which is probably only used in few projects.
 
-There are hopefully more extension libraries to come as people start to provide
-more authenticators, authorizers and other components and now there’s a (more or
-less, pre 1.0) stable API for these libraries as well as a set of tasks to build
-and test them
+There are hopefully more extension libraries to come as people start to provide more authenticators, authorizers and other components and now there’s a (more or less, pre 1.0) stable API for these libraries as well as a set of tasks to build and test them
 
-Another bigger change in this release is that **having an authorizer is now
-optional**. As there are applications that are purely client side and don’t use
-a server backend expecting every application to use an authorizer was probably
-not so great in the first place. However, applications that do use an authorizer
-can simply configure one in Ember.SimpleAuth’s setup method and everything will
-behave as before:
+Another bigger change in this release is that **having an authorizer is now optional**. As there are applications that are purely client side and don’t use a server backend expecting every application to use an authorizer was probably not so great in the first place. However, applications that do use an authorizer can simply configure one in Ember.SimpleAuth’s setup method and everything will behave as before:
 
 ```js
 {% raw %}
@@ -46,5 +31,4 @@ Ember.Application.initializer({
 {% endraw %}
 ```
 
-For more information about this release see the release notes at:
-[https://github.com/mainmatter/ember-simple-auth/releases/tag/0.3.0](https://github.com/mainmatter/ember-simple-auth/releases/tag/0.3.0)
+For more information about this release see the release notes at: [https://github.com/mainmatter/ember-simple-auth/releases/tag/0.3.0](https://github.com/mainmatter/ember-simple-auth/releases/tag/0.3.0)
diff --git a/src/posts/2014-04-24-embersimpleauth-needs-a-logo.md b/src/posts/2014-04-24-embersimpleauth-needs-a-logo.md
index 36f8d9a35f..be3d22c073 100644
--- a/src/posts/2014-04-24-embersimpleauth-needs-a-logo.md
+++ b/src/posts/2014-04-24-embersimpleauth-needs-a-logo.md
@@ -2,16 +2,10 @@
 title: "Ember.SimpleAuth needs a logo!"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte posts a request for the community to contribute a logo to
-  Ember.SimpleAuth."
+description: "Marco Otte-Witte posts a request for the community to contribute a logo to Ember.SimpleAuth."
 tags: ember
 tagline: |
   <p>The project needs a logo.</p>
 ---
 
-Every good open source project needs a nice and shiny logo these days. It would
-be great if Ember.SimpleAuth had one as well. As I’m not really an expert in
-these things it would be great if some of the more artistic advanced
-contributors/followers could
-[contribute something](https://github.com/mainmatter/ember-simple-auth/issues/152)!
+Every good open source project needs a nice and shiny logo these days. It would be great if Ember.SimpleAuth had one as well. As I’m not really an expert in these things it would be great if some of the more artistic advanced contributors/followers could [contribute something](https://github.com/mainmatter/ember-simple-auth/issues/152)!
diff --git a/src/posts/2014-06-30-using-ember-simple-auth-with-ember-cli.md b/src/posts/2014-06-30-using-ember-simple-auth-with-ember-cli.md
index da4cce3d3f..4a5671a501 100644
--- a/src/posts/2014-06-30-using-ember-simple-auth-with-ember-cli.md
+++ b/src/posts/2014-06-30-using-ember-simple-auth-with-ember-cli.md
@@ -2,9 +2,7 @@
 title: "Using Ember Simple Auth with ember-cli"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces the release of ember-cli-simple-auth as an Ember
-  CLI addon."
+description: "Marco Otte-Witte announces the release of ember-cli-simple-auth as an Ember CLI addon."
 tags: ember
 tagline: |
   <p>With the latest release of <a href="https://github.com/mainmatter/ember-simple-auth">Ember Simple Auth</a>, using the library with <a href="https://github.com/ember-cli/ember-cli">ember-cli</a> has become much simpler. As ember-cli in general is still pretty new to many people though, <strong>this post describes how to setup a project using Ember Simple Auth with ember-cli</strong>.</p>
@@ -12,9 +10,7 @@ tagline: |
 
 ## Setting up the basic project
 
-First of all you need to install [PhantomJS](http://phantomjs.org),
-[bower](http://bower.io) and of course ember-cli (Ember Simple Auth requires
-**at least Ember CLI 0.0.44**):
+First of all you need to install [PhantomJS](http://phantomjs.org), [bower](http://bower.io) and of course ember-cli (Ember Simple Auth requires **at least Ember CLI 0.0.44**):
 
 ```bash
 npm install -g phantomjs
@@ -37,22 +33,16 @@ ember server
 
 ## Installing Ember Simple Auth
 
-Installing Ember Simple Auth in an ember-cli project is really easy now. All you
-have to do is install
-[the ember-cli addon from npm](https://www.npmjs.com/package/ember-cli-simple-auth):
+Installing Ember Simple Auth in an ember-cli project is really easy now. All you have to do is install [the ember-cli addon from npm](https://www.npmjs.com/package/ember-cli-simple-auth):
 
 ```bash
 npm install --save-dev ember-cli-simple-auth
 ember generate ember-cli-simple-auth
 ```
 
-This will install Ember Simple Auth’s
-[AMD](http://requirejs.org/docs/whyamd.html) distribution into the project,
-register the initializer so Ember Simple Auth automatically sets itself up and
-add itself as a dependency to the project’s `package.json`.
+This will install Ember Simple Auth’s [AMD](http://requirejs.org/docs/whyamd.html) distribution into the project, register the initializer so Ember Simple Auth automatically sets itself up and add itself as a dependency to the project’s `package.json`.
 
-You can add a login route and login/logout links to verify it all actually
-works:
+You can add a login route and login/logout links to verify it all actually works:
 
 ```js
 {% raw %}
@@ -89,20 +79,14 @@ export default Ember.Route.extend(ApplicationRouteMixin);
 
 ## Setting up authentication
 
-To actually give the user the option to login, we need to add an authentication
-package for Ember Simple Auth. Let’s assume you have an OAuth 2.0 compatible
-server running at `http://localhost:3000`. To use that, install the
-[OAuth 2.0 extension library](https://github.com/mainmatter/ember-simple-auth/blob/master/addon/authenticators/oauth2-password-grant.js)
-which again is as easy as installing the
-[package from npm](https://www.npmjs.com/package/ember-cli-simple-auth-oauth2):
+To actually give the user the option to login, we need to add an authentication package for Ember Simple Auth. Let’s assume you have an OAuth 2.0 compatible server running at `http://localhost:3000`. To use that, install the [OAuth 2.0 extension library](https://github.com/mainmatter/ember-simple-auth/blob/master/addon/authenticators/oauth2-password-grant.js) which again is as easy as installing the [package from npm](https://www.npmjs.com/package/ember-cli-simple-auth-oauth2):
 
 ```bash
 npm install --save-dev ember-cli-simple-auth-oauth2
 ember generate ember-cli-simple-auth-oauth2
 ```
 
-Like the ember-cli-simple-auth package this will setup itself so that nothing
-else has to be done in order to use the OAuth 2.0 functionality.
+Like the ember-cli-simple-auth package this will setup itself so that nothing else has to be done in order to use the OAuth 2.0 functionality.
 
 The OAuth 2.0 authentication mechanism needs a login form, so let’s create that:
 
@@ -123,8 +107,7 @@ The OAuth 2.0 authentication mechanism needs a login form, so let’s create tha
 {% endraw %}
 ```
 
-Then implement the `LoginControllerMixin` in the login controller and make that
-use the OAuth 2.0 authenticator to perform the actual authentication:
+Then implement the `LoginControllerMixin` in the login controller and make that use the OAuth 2.0 authenticator to perform the actual authentication:
 
 ```js
 {% raw %}
@@ -138,9 +121,7 @@ export default Ember.Controller.extend(LoginControllerMixin, {
 {% endraw %}
 ```
 
-As the OAuth 2.0 authenticator would by default use the same domain and port to
-send the authentication requests to that the Ember.js is loaded from you need to
-configure it to use `http://localhost:3000` instead:
+As the OAuth 2.0 authenticator would by default use the same domain and port to send the authentication requests to that the Ember.js is loaded from you need to configure it to use `http://localhost:3000` instead:
 
 ```js
 {% raw %}
@@ -154,15 +135,8 @@ if (environment === 'development') {
 {% endraw %}
 ```
 
-You also need to make sure that your server allows cross origin requests by
-[enabling CORS](http://enable-cors.org) (e.g. with
-[rack-cors](https://github.com/cyu/rack-cors) if you’re using a rack based
-server).
+You also need to make sure that your server allows cross origin requests by [enabling CORS](http://enable-cors.org) (e.g. with [rack-cors](https://github.com/cyu/rack-cors) if you’re using a rack based server).
 
 ## Conclusion
 
-This is how you set up an ember-cli project with Ember Simple Auth. For further
-documentation and examples see the
-[github repository](https://github.com/mainmatter/ember-simple-auth) and the
-[API docs for Ember Simple Auth](http://ember-simple-auth.com/api/) and the
-[OAuth 2.0 extension library](http://ember-simple-auth.com/api/).
+This is how you set up an ember-cli project with Ember Simple Auth. For further documentation and examples see the [github repository](https://github.com/mainmatter/ember-simple-auth) and the [API docs for Ember Simple Auth](http://ember-simple-auth.com/api/) and the [OAuth 2.0 extension library](http://ember-simple-auth.com/api/).
diff --git a/src/posts/2014-07-25-testing-with-ember-simple-auth-and-ember-cli.md b/src/posts/2014-07-25-testing-with-ember-simple-auth-and-ember-cli.md
index 09b8be1e7f..2be2c54ae9 100644
--- a/src/posts/2014-07-25-testing-with-ember-simple-auth-and-ember-cli.md
+++ b/src/posts/2014-07-25-testing-with-ember-simple-auth-and-ember-cli.md
@@ -2,9 +2,7 @@
 title: "Testing with Ember Simple Auth and Ember CLI"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte explains how to test Ember CLI applications using
-  ember-cli-simple-auth with the testing package ember-cli-simple-auth-testing."
+description: "Marco Otte-Witte explains how to test Ember CLI applications using ember-cli-simple-auth with the testing package ember-cli-simple-auth-testing."
 tags: ember
 tagline: |
   <p><a href="/blog/2014/06/30/using-ember-simple-auth-with-ember-cli" title="Using Ember Simple Auth with ember-cli">The last blog post</a> showed how to use <a href="https://github.com/mainmatter/ember-simple-auth">Ember Simple Auth</a> with <a href="https://github.com/ember-cli/ember-cli">Ember CLI</a> to implement session handling and authentication. <strong>This post shows how to test that code</strong>.</p>
@@ -12,18 +10,14 @@ tagline: |
 
 ## The testing package
 
-First of all **install the new
-[ember-cli-simple-auth-testing package](https://www.npmjs.com/package/ember-cli-simple-auth-testing)**:
+First of all **install the new [ember-cli-simple-auth-testing package](https://www.npmjs.com/package/ember-cli-simple-auth-testing)**:
 
 ```bash
 npm install --save-dev ember-cli-simple-auth-testing
 ember generate ember-cli-simple-auth-testing
 ```
 
-**This package adds test helpers to the application** (unless it’s running with
-the `production` environment) that make it easy to authenticate and invalidate
-the session in tests without having to stub server responses etc. To make these
-helpers available to all tests, import them in `tests/helpers/start-app.js`:
+**This package adds test helpers to the application** (unless it’s running with the `production` environment) that make it easy to authenticate and invalidate the session in tests without having to stub server responses etc. To make these helpers available to all tests, import them in `tests/helpers/start-app.js`:
 
 ```js
 {% raw %}
@@ -38,13 +32,7 @@ export default function startApp(attrs) {
 
 ## Configuring the `test` environment
 
-The next step is to configure the `test` environment. As the tests should be
-isolated and leave no traces of any kind so that subsequent tests don’t have
-implicit dependencies on the ones that have run earlier, Ember Simple Auth’s
-default `localStorage` store cannot be used as that would leave data in the
-`localStorage`. **Instead configure the
-[ephemeral store](http://ember-simple-auth.com/api/classes/EphemeralStore.html)
-to be used in the `test` environment**:
+The next step is to configure the `test` environment. As the tests should be isolated and leave no traces of any kind so that subsequent tests don’t have implicit dependencies on the ones that have run earlier, Ember Simple Auth’s default `localStorage` store cannot be used as that would leave data in the `localStorage`. **Instead configure the [ephemeral store](http://ember-simple-auth.com/api/classes/EphemeralStore.html) to be used in the `test` environment**:
 
 ```js
 {% raw %}
@@ -57,15 +45,11 @@ if (environment === 'test') {
 {% endraw %}
 ```
 
-The ephemeral store stores data in memory and thus will be completely fresh for
-every test so that tests cannot influence each other.
+The ephemeral store stores data in memory and thus will be completely fresh for every test so that tests cannot influence each other.
 
 ## Adding the Tests
 
-Now everything is set up and a test can be added. To e.g. test that a certain
-route can only be accessed when the session is authenticated, add tests like
-these (notice the use of the test helpers `authenticateSession` and
-`invalidateSession`):
+Now everything is set up and a test can be added. To e.g. test that a certain route can only be accessed when the session is authenticated, add tests like these (notice the use of the test helpers `authenticateSession` and `invalidateSession`):
 
 ```js
 {% raw %}
@@ -91,6 +75,4 @@ test('a protected route is not accessible when the session is not authenticated'
 {% endraw %}
 ```
 
-This is how easy it is to test session handling and authentication with Ember
-Simple Auth and Ember CLI. The full example project can be
-[found on github](https://github.com/mainmatter/ember-simple-auth-example)
+This is how easy it is to test session handling and authentication with Ember Simple Auth and Ember CLI. The full example project can be [found on github](https://github.com/mainmatter/ember-simple-auth-example)
diff --git a/src/posts/2014-10-15-the-most-important-command-when-working-with-xcode-6.md b/src/posts/2014-10-15-the-most-important-command-when-working-with-xcode-6.md
index f61dc2976d..008d0685ff 100644
--- a/src/posts/2014-10-15-the-most-important-command-when-working-with-xcode-6.md
+++ b/src/posts/2014-10-15-the-most-important-command-when-working-with-xcode-6.md
@@ -2,9 +2,7 @@
 title: "The most important command when working with XCode 6"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte shows how to disable XCode 6's crash reporter dialog for a
-  less annoying development experience."
+description: "Marco Otte-Witte shows how to disable XCode 6's crash reporter dialog for a less annoying development experience."
 tags: misc
 tagline: |
   <p>Switching off XCode's Crash Reporter saved my day.</p>
@@ -14,6 +12,4 @@ tagline: |
 defaults write com.apple.CrashReporter DialogType none
 ```
 
-This disables the Crash Reporter window that shows when SourceKitService crashes
-(which is all the time). So while it doesn’t prevent SourceKitService from
-crashing at least you don’t have to click that window away anymore.
+This disables the Crash Reporter window that shows when SourceKitService crashes (which is all the time). So while it doesn’t prevent SourceKitService from crashing at least you don’t have to click that window away anymore.
diff --git a/src/posts/2015-07-29-ember-simple-auth-10-a-first-look.md b/src/posts/2015-07-29-ember-simple-auth-10-a-first-look.md
index d454c26ed0..0a4f64f43b 100644
--- a/src/posts/2015-07-29-ember-simple-auth-10-a-first-look.md
+++ b/src/posts/2015-07-29-ember-simple-auth-10-a-first-look.md
@@ -2,10 +2,7 @@
 title: "Ember Simple Auth 1.0 - a first look"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte gives an outlook on Ember Simple Auth 1.0 with Ember.js 2.0
-  support, a session service and discontinued support for non-Ember CLI
-  projects."
+description: "Marco Otte-Witte gives an outlook on Ember Simple Auth 1.0 with Ember.js 2.0 support, a session service and discontinued support for non-Ember CLI projects."
 tags: ember
 tagline: |
   <p>The <strong>first beta of Ember Simple Auth 1.0 will be released soon</strong> and this post provides a first look at the changes that come with it.</p>
@@ -13,18 +10,11 @@ tagline: |
 
 ## Ember 2.0 Compatibility
 
-The biggest improvement of course is that the **library will be compatible with
-Ember 2.0** (which is mainly due to the fact that it now uses instance
-initializers for a majority of its setup work). Also when using Ember 1.13 you
-shouldn’t be seeing any deprecations triggered by Ember Simple Auth anymore so
-that the upgrade path to 2.0 is clean.
+The biggest improvement of course is that the **library will be compatible with Ember 2.0** (which is mainly due to the fact that it now uses instance initializers for a majority of its setup work). Also when using Ember 1.13 you shouldn’t be seeing any deprecations triggered by Ember Simple Auth anymore so that the upgrade path to 2.0 is clean.
 
 ## Session as a Service
 
-While previous versions of Ember Simple Auth injected the session into routes,
-controllers and components, **Ember Simple Auth 1.0 drops that and instead
-provides a new `Session` service** that encapsulates all access to the actual
-session and can simply be injected wherever necessary, e.g.:
+While previous versions of Ember Simple Auth injected the session into routes, controllers and components, **Ember Simple Auth 1.0 drops that and instead provides a new `Session` service** that encapsulates all access to the actual session and can simply be injected wherever necessary, e.g.:
 
 <!-- prettier-ignore -->
 ```js
@@ -48,17 +38,9 @@ export default Ember.Component.extend({
 {% endraw %}
 ```
 
-It provides a similar UI as the old session object, including `authenticate` and
-`invalidate` methods. Instead of reading the session content directly from the
-session as was the case in old versions of the library, the session provides a
-`content` property that can be used to read and write date from and to the
-session.
+It provides a similar UI as the old session object, including `authenticate` and `invalidate` methods. Instead of reading the session content directly from the session as was the case in old versions of the library, the session provides a `content` property that can be used to read and write date from and to the session.
 
-Also support for defining a custom session class has been dropped in favor of
-defining a service that uses the session service to provide functionality based
-on that. E.g. the typical use case of providing access to the authenticated
-account can now easily be implemented with a `SessionAccount` service that in
-turn uses the `Session` service:
+Also support for defining a custom session class has been dropped in favor of defining a service that uses the session service to provide functionality based on that. E.g. the typical use case of providing access to the authenticated account can now easily be implemented with a `SessionAccount` service that in turn uses the `Session` service:
 
 <!-- prettier-ignore -->
 ```js
@@ -84,45 +66,19 @@ export default Ember.Service.extend({
 
 ## Ember CLI only
 
-While previous versions of Ember Simple Auth provided 3 different versions (AMD,
-globals and the Ember CLI addons) where the Ember CLI addon was also split up
-into several sub addons, **1.0 will come as one single Ember CLI addon**. This
-offers 3 main advantages:
-
-- The project structure is the standard Ember CLI addon structure and no longer
-  a custom set of grunt tasks etc. This not only makes the development and
-  release process much simpler but also promotes contributions from others.
-- It is now much simpler to install Ember CLI as it’s now only
-  `ember install ember-simple-auth` command instead of install at least 2
-  packages or potentially more.
-- Since all the source is now transpiled with Babel as part of the Ember CLI
-  build process, all the source code has been updated to use thinks like
-  template strings, function literals, deconstruction etc., making the code far
-  more concise and readable.
+While previous versions of Ember Simple Auth provided 3 different versions (AMD, globals and the Ember CLI addons) where the Ember CLI addon was also split up into several sub addons, **1.0 will come as one single Ember CLI addon**. This offers 3 main advantages:
+
+- The project structure is the standard Ember CLI addon structure and no longer a custom set of grunt tasks etc. This not only makes the development and release process much simpler but also promotes contributions from others.
+- It is now much simpler to install Ember CLI as it’s now only `ember install ember-simple-auth` command instead of install at least 2 packages or potentially more.
+- Since all the source is now transpiled with Babel as part of the Ember CLI build process, all the source code has been updated to use thinks like template strings, function literals, deconstruction etc., making the code far more concise and readable.
 
 ## Getting to 1.0
 
-1.0 is still not fully finished and ready for release. While I plan to release a
-first beta until next week latest, getting to the final release still requires
-some work:
-
-- The docs need to be updated to fit the new API and modules. Existing
-  documentation is still based on classes and namespaces and we need to find a
-  way to convert that so we document modules instead.
-- The docs are also not complete for new features like the **Session** service
-  and existing documentation needs to be reviewed for whether it’s actually
-  still correct.
-- The code should be reviewed and cleaned up before the final 1.0 release - much
-  of it is still what I wrote almost 2 years ago when I was still relatively new
-  to Ember and could probably be greatly improved.
-- The setup of the AJAX prefilter should be decoupled from the library so that
-  it’s opt-in and could be replaced with a different approach (e.g. sth. that
-  sets a property on the application’s Ember Data adapter instead) - see
-  [#522](https://github.com/mainmatter/ember-simple-auth/pull/522) and
-  [#270](https://github.com/mainmatter/ember-simple-auth/issues/270). A
-  compatibility Addon should be extracted that implements the current behavior
-  of setting up the prefilter automatically.
-
-You can track the progress in the `jj-abrams` branch and if you want to submit a
-PR for any of the above mentioned tasks that would be greatly appreciated of
-course!
+1.0 is still not fully finished and ready for release. While I plan to release a first beta until next week latest, getting to the final release still requires some work:
+
+- The docs need to be updated to fit the new API and modules. Existing documentation is still based on classes and namespaces and we need to find a way to convert that so we document modules instead.
+- The docs are also not complete for new features like the **Session** service and existing documentation needs to be reviewed for whether it’s actually still correct.
+- The code should be reviewed and cleaned up before the final 1.0 release - much of it is still what I wrote almost 2 years ago when I was still relatively new to Ember and could probably be greatly improved.
+- The setup of the AJAX prefilter should be decoupled from the library so that it’s opt-in and could be replaced with a different approach (e.g. sth. that sets a property on the application’s Ember Data adapter instead) - see [#522](https://github.com/mainmatter/ember-simple-auth/pull/522) and [#270](https://github.com/mainmatter/ember-simple-auth/issues/270). A compatibility Addon should be extracted that implements the current behavior of setting up the prefilter automatically.
+
+You can track the progress in the `jj-abrams` branch and if you want to submit a PR for any of the above mentioned tasks that would be greatly appreciated of course!
diff --git a/src/posts/2015-08-07-rails-api-auth.md b/src/posts/2015-08-07-rails-api-auth.md
index 2e77d7488c..4820d8578f 100644
--- a/src/posts/2015-08-07-rails-api-auth.md
+++ b/src/posts/2015-08-07-rails-api-auth.md
@@ -2,9 +2,7 @@
 title: "Rails API Auth"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  'Marco Otte-Witte announces rails_api_auth, a Rails engine that implements the
-  "Resource Owner Password Credentials Grant" OAuth 2.0 flow.'
+description: 'Marco Otte-Witte announces rails_api_auth, a Rails engine that implements the "Resource Owner Password Credentials Grant" OAuth 2.0 flow.'
 tags: ruby
 tagline: |
   <p>We are happy to announce the first public release of the <a href="https://github.com/mainmatter/rails_api_auth"><code>rails_api_auth</code> gem</a>. <code>rails_api_auth</code> is a <strong>lightweight Rails Engine that implements the <em>&quot;Resource Owner Password Credentials Grant&quot;</em> OAuth 2.0 flow</strong> as well as Facebook authentication and is <strong>built for usage in API projects</strong>. If you’re building a client side application with e.g. a browser MVC like <a href="http://emberjs.com">Ember.js</a> (where you might be using <a href="https://github.com/mainmatter/ember-simple-auth">Ember Simple Auth</a> which works great with rails_api_auth of course), a mobile app or anything else that’s backed by a Rails-based API, rails_api_auth is for you.</p>
@@ -12,49 +10,20 @@ tagline: |
 
 ## Why another Authentication Engine?
 
-Of course there are lots of authentication libraries for Rails already. While
-all of them are great and work well especially with traditional server rendered
-applications none of them are really lightweight and simple. In fact they are
-all pretty massive - all of them provide a lot more functionality than
-rails_api_auth does of course though. However, when you’re building an API and
-all you want is to provide a mechanism for users to exchange their login
-credentials for a token and then validate that incoming requests include a valid
-token in the `Authorization` header, you just don’t need most of that
-functionality and could use sth. much smaller, easier to understand and debug.
-In fact, rails_api_auth is basically just the controller and model plus a few
-helper methods that we use in most of our Rails-based API projects. When we
-realized we were reimplementing those in most projects we decided to extract
-them into an engine so they could be easily reused and also shared with others.
+Of course there are lots of authentication libraries for Rails already. While all of them are great and work well especially with traditional server rendered applications none of them are really lightweight and simple. In fact they are all pretty massive - all of them provide a lot more functionality than rails_api_auth does of course though. However, when you’re building an API and all you want is to provide a mechanism for users to exchange their login credentials for a token and then validate that incoming requests include a valid token in the `Authorization` header, you just don’t need most of that functionality and could use sth. much smaller, easier to understand and debug. In fact, rails_api_auth is basically just the controller and model plus a few helper methods that we use in most of our Rails-based API projects. When we realized we were reimplementing those in most projects we decided to extract them into an engine so they could be easily reused and also shared with others.
 
 ## The _"Resource Owner Password Credentials Grant"_
 
-The _"Resource Owner Password Credentials Grant"_ flow is really **just a
-formalization of the process where the users send their login credentials to the
-server and in return receive a token** (we’re using random Bearer tokens for now
-but will also support JSON Web Tokens (JWTs) soon). That **token will then be
-sent in the `Authorization` header** in subsequent requests so that the server
-can validate the user’s identity. The engine stores these credentials and tokens
-in `Login` models. Storing that data in a separate model instead of the
-application’s `User` model keeps the authentication code clearly separated from
-user profile data etc. and makes the engine easier to integrate. The `Login`
-model can be associated to the application’s `User` model by setting the
-`user_model_relation` configuration value
-([see the README for more info on configuring the engine).](https://github.com/mainmatter/rails_api_auth#configuration)
-
-The _"Resource Owner Password Credentials Grant"_ flow defines 2 endpoints - one
-for obtaining a token and one for revoking it (the 2nd one is actually optional
-as users can be logged without any server interaction by simply deleting the
-token on the client):
+The _"Resource Owner Password Credentials Grant"_ flow is really **just a formalization of the process where the users send their login credentials to the server and in return receive a token** (we’re using random Bearer tokens for now but will also support JSON Web Tokens (JWTs) soon). That **token will then be sent in the `Authorization` header** in subsequent requests so that the server can validate the user’s identity. The engine stores these credentials and tokens in `Login` models. Storing that data in a separate model instead of the application’s `User` model keeps the authentication code clearly separated from user profile data etc. and makes the engine easier to integrate. The `Login` model can be associated to the application’s `User` model by setting the `user_model_relation` configuration value ([see the README for more info on configuring the engine).](https://github.com/mainmatter/rails_api_auth#configuration)
+
+The _"Resource Owner Password Credentials Grant"_ flow defines 2 endpoints - one for obtaining a token and one for revoking it (the 2nd one is actually optional as users can be logged without any server interaction by simply deleting the token on the client):
 
 ```
 token  POST /token  oauth2#create
 revoke POST /revoke oauth2#destroy
 ```
 
-Both of these endpoints are already implemented in the engine. To validate that
-incoming requests include a valid Bearer token, the library defines the
-`authenticate!` method that is easily added as a `before_action` in
-authenticated-only controllers:
+Both of these endpoints are already implemented in the engine. To validate that incoming requests include a valid Bearer token, the library defines the `authenticate!` method that is easily added as a `before_action` in authenticated-only controllers:
 
 ```ruby
 class SecretThingsController < ApplicationController
@@ -66,30 +35,14 @@ class SecretThingsController < ApplicationController
 end
 ```
 
-When a valid token is present and a `Login` with that token exists, the method
-will save that in the `current_login` attribute so that it can be used in the
-controller. If no token is present or no `Login` exists for the token, it will
-respond with 401 and prevent the actual controller action from being executed.
-The `authenticate!` method can also be called with a block to add custom checks
-for the user’s authentication state.
+When a valid token is present and a `Login` with that token exists, the method will save that in the `current_login` attribute so that it can be used in the controller. If no token is present or no `Login` exists for the token, it will respond with 401 and prevent the actual controller action from being executed. The `authenticate!` method can also be called with a block to add custom checks for the user’s authentication state.
 
 ## Facebook Authentication
 
-Another common way of authenticating users that we’re using in many projects is
-Facebook authentication. The typical flow for this authentication type in web
-applications is opening a popup that displays Facebook’s login page and - after
-that - a page where the users grants your application access to their profile
-data. Once the user did that, Facebook will redirect to the web app and include
-an `auth_code` in the response that the web app then takes and sends to its API
-to validate it and exchange it for a Bearer token.
+Another common way of authenticating users that we’re using in many projects is Facebook authentication. The typical flow for this authentication type in web applications is opening a popup that displays Facebook’s login page and - after that - a page where the users grants your application access to their profile data. Once the user did that, Facebook will redirect to the web app and include an `auth_code` in the response that the web app then takes and sends to its API to validate it and exchange it for a Bearer token.
 
-rails_api_auth implements the API part of that in the `POST /token` route as
-well -
-[see the demo project for an example of how to use it](https://github.com/mainmatter/rails_api_auth-demo#facebook-authentication).
+rails_api_auth implements the API part of that in the `POST /token` route as well - [see the demo project for an example of how to use it](https://github.com/mainmatter/rails_api_auth-demo#facebook-authentication).
 
 ## Feedback and contributions welcome!
 
-As rails_api_auth is quite new and not yet widely used we’re happy to get
-feedback and suggestions for things we have missed. Also please **try the gem
-and report bugs** as you encounter them. **Contributions and pull requests are
-also appreciated** of course!
+As rails_api_auth is quite new and not yet widely used we’re happy to get feedback and suggestions for things we have missed. Also please **try the gem and report bugs** as you encounter them. **Contributions and pull requests are also appreciated** of course!
diff --git a/src/posts/2015-11-27-updating-to-ember-simple-auth-1.0.md b/src/posts/2015-11-27-updating-to-ember-simple-auth-1.0.md
index 44a6121806..94e68a6a9b 100644
--- a/src/posts/2015-11-27-updating-to-ember-simple-auth-1.0.md
+++ b/src/posts/2015-11-27-updating-to-ember-simple-auth-1.0.md
@@ -2,29 +2,17 @@
 title: "Updating to Ember Simple Auth 1.0"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte gives an update on the upcoming Ember Simple Auth 1.0
-  release and shows how to use it in Ember CLI applications."
+description: "Marco Otte-Witte gives an update on the upcoming Ember Simple Auth 1.0 release and shows how to use it in Ember CLI applications."
 tags: ember
 tagline: |
   <p>With Ember Simple Auth 1.0.0 having been <a href="https://github.com/mainmatter/ember-simple-auth/releases/tag/1.0.0">released a few days ago</a>, a lot of people will want to upgrade their applications to it so they can finally make the switch to Ember.js 2.0. While quite a big part of the <a href="http://ember-simple-auth.com/api/">public API</a> has been changed in 1.0.0, <strong>updating an application from Ember Simple Auth 0.8.0 or earlier versions is actually not as hard as it might appear</strong> at first glance. This post explains the steps that are necessary to bring an application to 1.0.0.</p>
 ---
 
-As 1.0.0 marks the first stable release of Ember Simple Auth, upcoming versions
-will adhere to the [Semantic Versioning](http://semver.org) rule of not
-including breaking changes in patch level or minor releases. In fact, **Ember
-Simple Auth will follow Ember’s example and only make additive, backwards
-compatible changes in all 1.x releases** and only remove deprecated parts of the
-library in the next major release.
+As 1.0.0 marks the first stable release of Ember Simple Auth, upcoming versions will adhere to the [Semantic Versioning](http://semver.org) rule of not including breaking changes in patch level or minor releases. In fact, **Ember Simple Auth will follow Ember’s example and only make additive, backwards compatible changes in all 1.x releases** and only remove deprecated parts of the library in the next major release.
 
 ## Uninstall previous versions
 
-**Ember Simple Auth 1.0.0 is only distributed as an Ember CLI Addon** and drops
-the previous bower distribution as well as the individual
-`ember-cli-simple-auth-*` packages. The first step when upgrading to 1.0.0 is to
-uninstall these packages from the application. To do that simply remove the
-`ember-simple-auth` package from `bower.json` as well as all
-`ember-cli-simple-auth-*` packages from `packages.json`.
+**Ember Simple Auth 1.0.0 is only distributed as an Ember CLI Addon** and drops the previous bower distribution as well as the individual `ember-cli-simple-auth-*` packages. The first step when upgrading to 1.0.0 is to uninstall these packages from the application. To do that simply remove the `ember-simple-auth` package from `bower.json` as well as all `ember-cli-simple-auth-*` packages from `packages.json`.
 
 ## Install 1.0.0
 
@@ -36,10 +24,7 @@ ember install ember-simple-auth
 
 ## Fix the imports
 
-With 1.0.0 all modules that it defines now live in the `ember-simple-auth`
-namespace as opposed to the `simple-auth` namespace of previous versions. All
-the `import` statements that import code from Ember Simple Auth need to be
-updated accordingly, e.g.
+With 1.0.0 all modules that it defines now live in the `ember-simple-auth` namespace as opposed to the `simple-auth` namespace of previous versions. All the `import` statements that import code from Ember Simple Auth need to be updated accordingly, e.g.
 
 ```js
 {% raw %}
@@ -55,20 +40,11 @@ import ApplicationRouteMixin from 'ember-simple-auth/mixins/application-route-mi
 {% endraw %}
 ```
 
-Also the modules for the OAuth 2.0 authenticator and authorizer have been
-renamed from just `oauth2` to `oauth2-password-grant` and `oauth2-bearer`
-respectively so that `'simple-auth/authenticators/oauth2'` is now
-`'ember-simple-auth/authenticators/oauth2-password-grant'` and
-`'simple-auth/authorizers/oauth2'` is now
-`'ember-simple-auth/authorizers/oauth2-bearer'`.
+Also the modules for the OAuth 2.0 authenticator and authorizer have been renamed from just `oauth2` to `oauth2-password-grant` and `oauth2-bearer` respectively so that `'simple-auth/authenticators/oauth2'` is now `'ember-simple-auth/authenticators/oauth2-password-grant'` and `'simple-auth/authorizers/oauth2'` is now `'ember-simple-auth/authorizers/oauth2-bearer'`.
 
 ## Inject the session service
 
-With Ember Simple Auth 1.0.0 the **session is no longer automatically injected
-into all routes, controllers and components** but instead is **now available as
-an [Ember.Service](http://emberjs.com/api/classes/Ember.Service.html)** so in
-all routes, controllers and components that use the session (or back a template
-that uses it), that session service needs to be injected, e.g.:
+With Ember Simple Auth 1.0.0 the **session is no longer automatically injected into all routes, controllers and components** but instead is **now available as an [Ember.Service](http://emberjs.com/api/classes/Ember.Service.html)** so in all routes, controllers and components that use the session (or back a template that uses it), that session service needs to be injected, e.g.:
 
 ```js
 {% raw %}
@@ -82,12 +58,7 @@ export default Ember.Controller.extend({
 
 ## Define Authenticators and Authorizers
 
-Ember Simple Auth 1.0.0 does not automatically merge all the predefined
-authenticators and authorizers into the application anymore but instead
-**requires authenticators and authorizers the application actually uses to be
-defined explicitly**. So if you e.g. were previously using the OAuth 2.0
-authenticator simply define an authenticator that extends the OAuth 2.0
-authenticator in `app/authenticators`:
+Ember Simple Auth 1.0.0 does not automatically merge all the predefined authenticators and authorizers into the application anymore but instead **requires authenticators and authorizers the application actually uses to be defined explicitly**. So if you e.g. were previously using the OAuth 2.0 authenticator simply define an authenticator that extends the OAuth 2.0 authenticator in `app/authenticators`:
 
 ```js
 {% raw %}
@@ -100,9 +71,7 @@ export default OAuth2PasswordGrant.extend({
 {% endraw %}
 ```
 
-In addition to the renamed module, the signature of the OAuth 2.0 authenticator
-has changed as well so that it now expects dedicated arguments for the user’s
-identification and password instead of one object containing both values, so
+In addition to the renamed module, the signature of the OAuth 2.0 authenticator has changed as well so that it now expects dedicated arguments for the user’s identification and password instead of one object containing both values, so
 
 ```js
 {% raw %}
@@ -127,20 +96,11 @@ this.get('session').authenticate(
 {% endraw %}
 ```
 
-Also authenticators and authorizers are not configured via
-`config/environment.js` anymore but instead the respective properties are simply
-overridden in the extended classes as for the `serverTokenRevocationEndpoint`
-property in the example above.
+Also authenticators and authorizers are not configured via `config/environment.js` anymore but instead the respective properties are simply overridden in the extended classes as for the `serverTokenRevocationEndpoint` property in the example above.
 
 ## Setup authorization
 
-Ember Simple Auth’s **old auto-authorization mechanism** was complex (especially
-when working with cross origin requests where configuring the
-`crossOriginWhitelist` was causing big problems for many people) and **has been
-removed in 1.0.0**. Instead authorization is now explicit. To authorize a block
-of code use the
-[session service’s `authorize` method](http://ember-simple-auth.com/api/classes/SessionService.html#method_authorize),
-e.g.:
+Ember Simple Auth’s **old auto-authorization mechanism** was complex (especially when working with cross origin requests where configuring the `crossOriginWhitelist` was causing big problems for many people) and **has been removed in 1.0.0**. Instead authorization is now explicit. To authorize a block of code use the [session service’s `authorize` method](http://ember-simple-auth.com/api/classes/SessionService.html#method_authorize), e.g.:
 
 ```js
 {% raw %}
@@ -153,10 +113,7 @@ this.get('session').authorize(
 {% endraw %}
 ```
 
-If the application uses Ember Data, you can authorize all of the requests it
-sends to the API by using the new
-[`DataAdapterMixin`](http://ember-simple-auth.com/api/classes/DataAdapterMixin.html),
-e.g.:
+If the application uses Ember Data, you can authorize all of the requests it sends to the API by using the new [`DataAdapterMixin`](http://ember-simple-auth.com/api/classes/DataAdapterMixin.html), e.g.:
 
 ```js
 {% raw %}
@@ -172,16 +129,11 @@ export default DS.JSONAPIAdapter.extend(DataAdapterMixin, {
 
 ## Migrating custom sessions
 
-While previous versions of Ember Simple Auth allowed to configure a custom
-session class in order to add properties and methods to the session, Ember
-Simple Auth 1.0.0 makes the session private and only exposes the session
-service. In order to migrate a custom session class to work with the service
-there are 2 options.
+While previous versions of Ember Simple Auth allowed to configure a custom session class in order to add properties and methods to the session, Ember Simple Auth 1.0.0 makes the session private and only exposes the session service. In order to migrate a custom session class to work with the service there are 2 options.
 
 ### Extend the session service
 
-You can simply extend the session service and add custom properties and methods
-in the subclass, e.g.:
+You can simply extend the session service and add custom properties and methods in the subclass, e.g.:
 
 ```js
 {% raw %}
@@ -207,8 +159,7 @@ export default SessionService.extend({
 
 ### Create dedicated services
 
-You can also create dedicated services that use the session service internally,
-e.g.:
+You can also create dedicated services that use the session service internally, e.g.:
 
 ```js
 {% raw %}
@@ -231,29 +182,13 @@ export default Ember.Service.extend({
 {% endraw %}
 ```
 
-In this case the session service remains unchanged and whenever you need the
-currently authenticated account you’d use the `session-account` service to get
-that.
+In this case the session service remains unchanged and whenever you need the currently authenticated account you’d use the `session-account` service to get that.
 
-Both solutions work fine but **the latter results in cleaner code and better
-separation of concerns.**
+Both solutions work fine but **the latter results in cleaner code and better separation of concerns.**
 
 ## Session Stores
 
-Previous versions of Ember Simple Auth allowed the session store to be
-configured in `config/environment.js`. **Ember Simple Auth 1.0.0 removes that
-configuration setting and will always use the `'application'` session store**.
-If not overridden by the application that session store will be an instance of
-the new
-[`AdaptiveStore`](http://ember-simple-auth.com/api/classes/AdaptiveStore.html)
-that internally uses the
-[`LocalStorageStore`](http://ember-simple-auth.com/api/classes/LocalStorageStore.html)
-if `localStorage` storage is available and the
-[`CookieStore`](http://ember-simple-auth.com/api/classes/CookieStore.html) if it
-is not. To customize the application store, define it in
-`app/session-stores/application.js`, extend a predefined session store and
-customize properties (as done for authenticators and authorizers as described
-above) or implement a fully custom store, e.g.:
+Previous versions of Ember Simple Auth allowed the session store to be configured in `config/environment.js`. **Ember Simple Auth 1.0.0 removes that configuration setting and will always use the `'application'` session store**. If not overridden by the application that session store will be an instance of the new [`AdaptiveStore`](http://ember-simple-auth.com/api/classes/AdaptiveStore.html) that internally uses the [`LocalStorageStore`](http://ember-simple-auth.com/api/classes/LocalStorageStore.html) if `localStorage` storage is available and the [`CookieStore`](http://ember-simple-auth.com/api/classes/CookieStore.html) if it is not. To customize the application store, define it in `app/session-stores/application.js`, extend a predefined session store and customize properties (as done for authenticators and authorizers as described above) or implement a fully custom store, e.g.:
 
 ```js
 {% raw %}
@@ -266,16 +201,11 @@ export default CookieStore.extend({
 {% endraw %}
 ```
 
-**Ember Simple Auth 1.0.0 will also automatically use the
-[`EphemeralStore`](http://ember-simple-auth.com/api/classes/EphemeralStore.html)
-when running tests** so there is no need anymore to configure that for the test
-environment (in fact the configuration setting has been removed).
+**Ember Simple Auth 1.0.0 will also automatically use the [`EphemeralStore`](http://ember-simple-auth.com/api/classes/EphemeralStore.html) when running tests** so there is no need anymore to configure that for the test environment (in fact the configuration setting has been removed).
 
 ## Update acceptance tests
 
-While previous versions of Ember Simple Auth automatically injected the test
-helpers, version 1.0.0 requires them to be imported in the respective acceptance
-tests, e.g.:
+While previous versions of Ember Simple Auth automatically injected the test helpers, version 1.0.0 requires them to be imported in the respective acceptance tests, e.g.:
 
 ```js
 {% raw %}
@@ -305,22 +235,8 @@ authenticateSession(App);
 
 ## Update the application route if necessary
 
-The
-[`ApplicationRouteMixin`](http://ember-simple-auth.com/api/classes/ApplicationRouteMixin.html)
-in Ember Simple Auth 1.0.0 now only defines the two methods
-[`sessionAuthenticated`](http://ember-simple-auth.com/api/classes/ApplicationRouteMixin.html#method_sessionAuthenticated)
-and
-[`sessionInvalidated`](http://ember-simple-auth.com/api/classes/ApplicationRouteMixin.html#method_sessionInvalidated)
-as opposed to the previous four actions. If the application overrides any of
-these actions it would now have to override these methods.
+The [`ApplicationRouteMixin`](http://ember-simple-auth.com/api/classes/ApplicationRouteMixin.html) in Ember Simple Auth 1.0.0 now only defines the two methods [`sessionAuthenticated`](http://ember-simple-auth.com/api/classes/ApplicationRouteMixin.html#method_sessionAuthenticated) and [`sessionInvalidated`](http://ember-simple-auth.com/api/classes/ApplicationRouteMixin.html#method_sessionInvalidated) as opposed to the previous four actions. If the application overrides any of these actions it would now have to override these methods.
 
 ## Wrapping up
 
-I hope this gives a good overview of how upgrading an Ember application to Ember
-Simple Auth 1.0.0 works. **There is lots of documentation available** in the
-[README](https://github.com/mainmatter/ember-simple-auth#readme) and the
-[API Docs](http://ember-simple-auth.com/api/index.html). You might also want to
-check out the
-[dummy application](https://github.com/mainmatter/ember-simple-auth/tree/master/tests/dummy)
-in the github repo and the
-[intro video on the website](http://ember-simple-auth.com).
+I hope this gives a good overview of how upgrading an Ember application to Ember Simple Auth 1.0.0 works. **There is lots of documentation available** in the [README](https://github.com/mainmatter/ember-simple-auth#readme) and the [API Docs](http://ember-simple-auth.com/api/index.html). You might also want to check out the [dummy application](https://github.com/mainmatter/ember-simple-auth/tree/master/tests/dummy) in the github repo and the [intro video on the website](http://ember-simple-auth.com).
diff --git a/src/posts/2015-12-03-ember-cli-deploy-notifications.md b/src/posts/2015-12-03-ember-cli-deploy-notifications.md
index 9e8c08e56c..0b7a735185 100644
--- a/src/posts/2015-12-03-ember-cli-deploy-notifications.md
+++ b/src/posts/2015-12-03-ember-cli-deploy-notifications.md
@@ -2,40 +2,25 @@
 title: "ember-cli-deploy-notifications"
 authorHandle: LevelbossMike
 bio: "Full-Stack Engineer, Ember CLI Deploy core team member"
-description:
-  "Michael Klein introduces ember-cli-deploy-notifications, an ember-cli-deploy
-  plugin for invoking arbitrary webhooks during the deployment process."
+description: "Michael Klein introduces ember-cli-deploy-notifications, an ember-cli-deploy plugin for invoking arbitrary webhooks during the deployment process."
 tags: ember
 tagline: |
   <p>A few weeks ago a new version of the <em>&quot;official&quot;</em> ember deployment solution <a href="http://ember-cli-deploy.com/">ember-cli-deploy</a> was released:</p> <blockquote> <p>ember-cli-deploy 0.5 is now released and ready for use with a great docs site and already-rich plugin ecosystem: &lt;a href=&quot;https://t.co/6yhjmjQrYD&quot;&gt;https://t.co/6yhjmjQrYD&lt;/a&gt; &lt;author&gt;Luke Melia (@lukemelia) &lt;a href=&quot;https://twitter.com/lukemelia/status/659787938625134592&quot;&gt;29. Oktober 2015&lt;/a&gt;&lt;/author&gt;</p> </blockquote>
 ---
 
-Aaron Chambers and me gave detailed walkthroughs of the basic ideas behind the
-pipeline at the [Ember-London](https://vimeo.com/139125310) and
-[Ember.js-Munich](https://www.youtube.com/watch?v=d4xwIv_9Cg0) meetups
-respectively.
+Aaron Chambers and me gave detailed walkthroughs of the basic ideas behind the pipeline at the [Ember-London](https://vimeo.com/139125310) and [Ember.js-Munich](https://www.youtube.com/watch?v=d4xwIv_9Cg0) meetups respectively.
 
-The new release **encourages heavy use of
-[deploy plugins](http://emberobserver.com/categories/ember-cli-deploy-plugins)
-that all implement different parts of a deployment via
-[hooks](http://ember-cli-deploy.com/docs/v0.5.x/pipeline-hooks/)** and are
-themselves Ember CLI addons. What wasn’t available though was a plugin for
-notifying external webservices (e.g. an error-tracking service) during or after
-deployments so we decided to write one.
+The new release **encourages heavy use of [deploy plugins](http://emberobserver.com/categories/ember-cli-deploy-plugins) that all implement different parts of a deployment via [hooks](http://ember-cli-deploy.com/docs/v0.5.x/pipeline-hooks/)** and are themselves Ember CLI addons. What wasn’t available though was a plugin for notifying external webservices (e.g. an error-tracking service) during or after deployments so we decided to write one.
 
 ## Introducing ember-cli-deploy-notifications
 
-[ember-cli-deploy-notifications](https://github.com/mainmatter/ember-cli-deploy-notifications)
-**makes it easy to notify external services** by adding them to a
-`notifications.services.<service>` property in `config/deploy.js`. First you
-have to install the addon:
+[ember-cli-deploy-notifications](https://github.com/mainmatter/ember-cli-deploy-notifications) **makes it easy to notify external services** by adding them to a `notifications.services.<service>` property in `config/deploy.js`. First you have to install the addon:
 
 ```bash
 ember install ember-cli-deploy-notifications
 ```
 
-The second step is to configure the services that you want to notify while
-executing the deployment pipeline.
+The second step is to configure the services that you want to notify while executing the deployment pipeline.
 
 ```js
 {% raw %}
@@ -60,30 +45,19 @@ module.exports = function (deployTarget) {
 {% endraw %}
 ```
 
-Every time a new revision gets activated now by `ember-cli-deploy`,
-`ember-cli-deploy-notifications` will sent a `POST` request to the bugsnag
-service to notify it of the newly activated deployment revision.
+Every time a new revision gets activated now by `ember-cli-deploy`, `ember-cli-deploy-notifications` will sent a `POST` request to the bugsnag service to notify it of the newly activated deployment revision.
 
 ## Customization
 
-We figured out that there are a lot of different internal and external services
-that users of ember-cli-deploy wanted to notify when executing the deploy
-pipeline. Thus **we wanted to make `ember-cli-deploy-notifications` as flexible
-as possible but still keep things easy and simple** for the most basic use
-cases.
+We figured out that there are a lot of different internal and external services that users of ember-cli-deploy wanted to notify when executing the deploy pipeline. Thus **we wanted to make `ember-cli-deploy-notifications` as flexible as possible but still keep things easy and simple** for the most basic use cases.
 
-Based on that assumption we came up with the idea of _"preconfigured"_ and
-_"custom"_ services.
+Based on that assumption we came up with the idea of _"preconfigured"_ and _"custom"_ services.
 
 ### Custom services
 
-**Services need to be configured with values for `url`, `headers`, `method` and
-`body`**. We figured out that these are all the necessary parts of a webservice
-request that you need to be able to customize.
+**Services need to be configured with values for `url`, `headers`, `method` and `body`**. We figured out that these are all the necessary parts of a webservice request that you need to be able to customize.
 
-**Additionally you need to provide a property named the same as the hook that
-you want the service to be notified on** when running through the deploy
-pipeline (as we wouldn’t know when to notify a service otherwise):
+**Additionally you need to provide a property named the same as the hook that you want the service to be notified on** when running through the deploy pipeline (as we wouldn’t know when to notify a service otherwise):
 
 ```js
 {% raw %}
@@ -117,16 +91,9 @@ module.exports = function (deployTarget) {
 {% endraw %}
 ```
 
-`url`, `headers`, `method` and `body` are the basic ideas behind the service
-abstraction in ember-cli-deploy-notifications but to keep things simple you
-don’t have to provide `headers` and `method` for every custom service as these
-properties will default to `{}` and `'POST'` respectively.
+`url`, `headers`, `method` and `body` are the basic ideas behind the service abstraction in ember-cli-deploy-notifications but to keep things simple you don’t have to provide `headers` and `method` for every custom service as these properties will default to `{}` and `'POST'` respectively.
 
-As you can see service configuration properties can either be defined directly
-or generated dynamically based on the
-[deployment context](http://ember-cli-deploy.com/docs/v0.5.x/deployment-context/).
-`this` will always point to the service’s configuration itself in all of these
-functions which enables you to do things like this:
+As you can see service configuration properties can either be defined directly or generated dynamically based on the [deployment context](http://ember-cli-deploy.com/docs/v0.5.x/deployment-context/). `this` will always point to the service’s configuration itself in all of these functions which enables you to do things like this:
 
 ```js
 {% raw %}
@@ -156,8 +123,7 @@ module.exports = function(deployTarget) {
 {% endraw %}
 ```
 
-The configuration properties named the same as ember-cli-deploy’s pipeline-hooks
-can also be used to override configuration defaults on a per hook basis:
+The configuration properties named the same as ember-cli-deploy’s pipeline-hooks can also be used to override configuration defaults on a per hook basis:
 
 ```js
 {% raw %}
@@ -191,15 +157,9 @@ module.exports = function (deployTarget) {
 
 ### Preconfigured services
 
-As we wanted to make it as easy as possible to get started with
-ember-cli-deploy-notifications **there are already some preconfigured
-services**.
+As we wanted to make it as easy as possible to get started with ember-cli-deploy-notifications **there are already some preconfigured services**.
 
-Preconfigured services differ from custom services in the fact that the
-community has already provided a default configuration for these services. **For
-example the popular error tracking service [bugsnag](http://bugsnag.com) is
-already preconfigured which makes it easy to use out of the box** with
-ember-cli-deploy-notifications:
+Preconfigured services differ from custom services in the fact that the community has already provided a default configuration for these services. **For example the popular error tracking service [bugsnag](http://bugsnag.com) is already preconfigured which makes it easy to use out of the box** with ember-cli-deploy-notifications:
 
 ```js
 {% raw %}
@@ -227,13 +187,6 @@ There is also a preconfigured service for slack.
 
 ## Next Steps
 
-**We are excited to share this small ember-cli-deploy plugin with the ember
-community and would like to hear your feedback!** We are already using it in
-client projects and, though pretty small, found it to be a very useful addition
-to our deployment workflow.
+**We are excited to share this small ember-cli-deploy plugin with the ember community and would like to hear your feedback!** We are already using it in client projects and, though pretty small, found it to be a very useful addition to our deployment workflow.
 
-Please refer to the project’s
-[README](https://github.com/mainmatter/ember-cli-deploy-notifications#readme)
-for more detailed information about the plugin and don’t hesitate to open issues
-or ask questions, we’re happy to support you in setting up a great deployment
-workflow for your Ember applications.
+Please refer to the project’s [README](https://github.com/mainmatter/ember-cli-deploy-notifications#readme) for more detailed information about the plugin and don’t hesitate to open issues or ask questions, we’re happy to support you in setting up a great deployment workflow for your Ember applications.
diff --git a/src/posts/2016-03-04-ember-test-selectors.md b/src/posts/2016-03-04-ember-test-selectors.md
index 97fc63060d..30249cbfa8 100644
--- a/src/posts/2016-03-04-ember-test-selectors.md
+++ b/src/posts/2016-03-04-ember-test-selectors.md
@@ -2,9 +2,7 @@
 title: Using better element selectors in Ember.js tests
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces the release of ember-test-selectors, an addon that
-  enables better element selectors in Ember.js tests."
+description: "Marco Otte-Witte announces the release of ember-test-selectors, an addon that enables better element selectors in Ember.js tests."
 tags: ember
 tagline: |
   <p>We just released <a href="https://github.com/mainmatter/ember-test-selectors">ember-test-selectors</a>, an <strong>Ember Addon that enables better element selectors in Ember.js tests</strong>. It removes all data attributes starting with <code>data-test-</code> from the application's templates in the <code>production</code> environment so that these attributes can be used to select elements with in acceptance and integration tests without polluting the markup that is delivered to the end user.</p>
@@ -12,15 +10,11 @@ tagline: |
 
 ## Why even use `data` attributes as test selectors?
 
-Integration and acceptance tests usually **interact with and assert on the
-presence of certain elements** in the markup that an application renders. These
-elements are identified using CSS selectors. Most projects use one of three
-approaches for CSS selectors in tests:
+Integration and acceptance tests usually **interact with and assert on the presence of certain elements** in the markup that an application renders. These elements are identified using CSS selectors. Most projects use one of three approaches for CSS selectors in tests:
 
 ### Selectors based on HTML structure
 
-This approach simply selects elements by their position in the rendered HTML.
-For the following template:
+This approach simply selects elements by their position in the rendered HTML. For the following template:
 
 ```html
 <article>
@@ -29,9 +23,7 @@ For the following template:
 </article>
 ```
 
-one might select the post's title with the selector `'article h1'`. Of course
-this breaks when changing the `<h1>` to a `<h2>` while the functionality being
-tested is probably not affected by that change.
+one might select the post's title with the selector `'article h1'`. Of course this breaks when changing the `<h1>` to a `<h2>` while the functionality being tested is probably not affected by that change.
 
 ### Selectors based on CSS classes
 
@@ -46,19 +38,13 @@ This approach selects elements by CSS classes. For the following template:
 {% endraw %}
 ```
 
-one might select the post title with the selector `'.post-title'`. This of
-course breaks when the CSS class is changed or renamed, although that would only
-be a visual change which shouldn't affect the tests at all.
+one might select the post title with the selector `'.post-title'`. This of course breaks when the CSS class is changed or renamed, although that would only be a visual change which shouldn't affect the tests at all.
 
-Many projects use CSS classes with special prefixes that are only used for
-testing to overcome this problem like `'js-post-title'`. While that approach is
-definitely more stable it is often hard to maintain. Also it doesn't easily
-allow to encode additional information like e.g. the post's id.
+Many projects use CSS classes with special prefixes that are only used for testing to overcome this problem like `'js-post-title'`. While that approach is definitely more stable it is often hard to maintain. Also it doesn't easily allow to encode additional information like e.g. the post's id.
 
 ### Selectors based on `data` attributes
 
-This approach uses HTML 5 `data` attributes to select elements. For the
-following template:
+This approach uses HTML 5 `data` attributes to select elements. For the following template:
 
 ```hbs
 {% raw %}
@@ -69,14 +55,7 @@ following template:
 {% endraw %}
 ```
 
-one would select the post's title with the selector
-`*[data-test-selector="post-title"]` (which selects any element with a
-`data-test-selector` attribute that has the value `"post-title"`). While the
-selector is arguably a bit longer this approach **clearly separates the test
-selectors from the rest of the markup and is resilient to change** as the
-attribute can be applied to any element rendering the post's title, regardless
-of the HTML structure, CSS classes etc. Also it easily allows encoding more data
-in the markup like e.g. the post's id:
+one would select the post's title with the selector `*[data-test-selector="post-title"]` (which selects any element with a `data-test-selector` attribute that has the value `"post-title"`). While the selector is arguably a bit longer this approach **clearly separates the test selectors from the rest of the markup and is resilient to change** as the attribute can be applied to any element rendering the post's title, regardless of the HTML structure, CSS classes etc. Also it easily allows encoding more data in the markup like e.g. the post's id:
 
 ```hbs
 {% raw %}
@@ -90,9 +69,7 @@ in the markup like e.g. the post's id:
 {% endraw %}
 ```
 
-`ember-test-selectors` makes sure to remove all these `data` attributes in the
-`production` environment so that **users will have perfectly clean HTML
-delivered**:
+`ember-test-selectors` makes sure to remove all these `data` attributes in the `production` environment so that **users will have perfectly clean HTML delivered**:
 
 ```html
 <article>
@@ -103,17 +80,7 @@ delivered**:
 
 ## Future Plans
 
-{% raw %} We have some future plans for ember-test-selectors to make working
-with data attributes as test selectors even more convenient:
-
-- custom test helpers that find elements by data attributes so that you don't
-  have to write the quite long selectors yourselves; probably sth. like
-  `findViaTestSelector('selector', 'post-title')`,
-  [https://github.com/mainmatter/ember-test-selectors/issues/8](https://github.com/mainmatter/ember-test-selectors/issues/8)
-- template helpers that generate data attributes for elements, e.g.
-  `<h1 {{test-selector="post-title"}}>{{post.title}}</h1>` which would result in
-  `<h1 data-test-selector="post-title">{{post.title}}</h1>` or
-  `<div {{test-selector post}}>…</div>` which would result in
-  `<div data-test-selector="post-1">…</div>`,
-  [https://github.com/mainmatter/ember-test-selectors/issues/9](https://github.com/mainmatter/ember-test-selectors/issues/9)
-  {% endraw %}
+{% raw %} We have some future plans for ember-test-selectors to make working with data attributes as test selectors even more convenient:
+
+- custom test helpers that find elements by data attributes so that you don't have to write the quite long selectors yourselves; probably sth. like `findViaTestSelector('selector', 'post-title')`, [https://github.com/mainmatter/ember-test-selectors/issues/8](https://github.com/mainmatter/ember-test-selectors/issues/8)
+- template helpers that generate data attributes for elements, e.g. `<h1 {{test-selector="post-title"}}>{{post.title}}</h1>` which would result in `<h1 data-test-selector="post-title">{{post.title}}</h1>` or `<div {{test-selector post}}>…</div>` which would result in `<div data-test-selector="post-1">…</div>`, [https://github.com/mainmatter/ember-test-selectors/issues/9](https://github.com/mainmatter/ember-test-selectors/issues/9) {% endraw %}
diff --git a/src/posts/2016-12-06-out-of-the-box-fastboot-support-in-ember-simple-auth.md b/src/posts/2016-12-06-out-of-the-box-fastboot-support-in-ember-simple-auth.md
index f774564d27..9a270a533d 100644
--- a/src/posts/2016-12-06-out-of-the-box-fastboot-support-in-ember-simple-auth.md
+++ b/src/posts/2016-12-06-out-of-the-box-fastboot-support-in-ember-simple-auth.md
@@ -2,9 +2,7 @@
 title: Out-of-the-box FastBoot support in Ember Simple Auth
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte announces out-of-the-box support for FastBoot in Ember
-  Simple Auth and explains how it works using ember-cookies."
+description: "Marco Otte-Witte announces out-of-the-box support for FastBoot in Ember Simple Auth and explains how it works using ember-cookies."
 tags: ember
 tagline: |
   <p>Ever since <a href="https://www.youtube.com/watch?v=o12-90Dm-Qs">FastBoot was first announced at EmberConf 2015</a> it was clear to us that we wanted to have out-of-the-box support for it in Ember Simple Auth. Our goal was to make sure that Ember Simple Auth did not keep anyone from adopting FastBoot and adopting FastBoot would not result in people having to figure out their own authentication and authorization solutions. Today we're happy to announce the availability of <a href="https://github.com/mainmatter/ember-simple-auth/releases/tag/1.2.0-beta.1">Ember Simple Auth 1.2.0-beta.1</a>, the <strong>first release with out-of-the-box support for FastBoot</strong>.</p>
@@ -12,46 +10,15 @@ tagline: |
 
 ## Seamless Session Synchronization
 
-Ember Simple Auth 1.2 seamlessly <strong>synchronizes the session state between
-the browser and FastBoot server</strong>. When a user logs in to an Ember.js
-application and refreshes the page or comes back to the app later - triggering a
-request that's handled by the FastBoot server - Ember Simple Auth will send the
-session state along with that request, pick it up in the app instance that's
-running in the FastBoot server and <strong>make sure the Ember route is being
-loaded and rendered in the correct session context</strong>. If the session
-turns out to be invalid for some reason, the server will invalidate it and the
-user will be redirected to the login page via a proper HTTP redirect.
+Ember Simple Auth 1.2 seamlessly <strong>synchronizes the session state between the browser and FastBoot server</strong>. When a user logs in to an Ember.js application and refreshes the page or comes back to the app later - triggering a request that's handled by the FastBoot server - Ember Simple Auth will send the session state along with that request, pick it up in the app instance that's running in the FastBoot server and <strong>make sure the Ember route is being loaded and rendered in the correct session context</strong>. If the session turns out to be invalid for some reason, the server will invalidate it and the user will be redirected to the login page via a proper HTTP redirect.
 
 ## Under the hood
 
-Ember Simple Auth has always had the concept of session stores that persist the
-session state so that it survives page reloads (or users leaving the app and
-coming back later). <strong>One of these session stores turned out to be the
-perfect fit for the aforementioned session syncing mechanism – the cookie
-session store</strong>. Browsers will automatically send cookies for a
-particular origin along with any request to that origin. Also, servers can
-modify cookies sent by the browser and include updates in the response that the
-browser will automatically pick up - effectively enabling bidirectional state
-synchronization.
-
-The main challenge with enabling the cookie session store to run both in the
-browser as well as in Node though was that the APIs for cookie handling are
-obviously totally different in both environments. In the browser there is
-`document.cookie` while in server apps running in Node, cookies are being read
-and written via the `Cookie` and `Set-Cookie` headers. That meant we had to come
-up with a way to read and write cookies via a common interface that we could
-rely on in the cookie session store and that abstracted these environment
-specific APIs under the hood (much like what
-<a href="https://github.com/tomdale/ember-network">ember-network</a> does for
-the <a href="https://github.com/tomdale/ember-network">fetch API</a>). Therefore
-we created
-<strong><a href="https://github.com/mainmatter/ember-cookies">ember-cookies</a>
-which is a cookies abstraction that works in the browser as well as in
-Node</strong> and that's now being used internally by the cookie session store.
-
-ember-cookies exposes a cookies service with
-<a href="https://github.com/mainmatter/ember-cookies#api">`read`, `write` and
-`clear` methods</a>:
+Ember Simple Auth has always had the concept of session stores that persist the session state so that it survives page reloads (or users leaving the app and coming back later). <strong>One of these session stores turned out to be the perfect fit for the aforementioned session syncing mechanism – the cookie session store</strong>. Browsers will automatically send cookies for a particular origin along with any request to that origin. Also, servers can modify cookies sent by the browser and include updates in the response that the browser will automatically pick up - effectively enabling bidirectional state synchronization.
+
+The main challenge with enabling the cookie session store to run both in the browser as well as in Node though was that the APIs for cookie handling are obviously totally different in both environments. In the browser there is `document.cookie` while in server apps running in Node, cookies are being read and written via the `Cookie` and `Set-Cookie` headers. That meant we had to come up with a way to read and write cookies via a common interface that we could rely on in the cookie session store and that abstracted these environment specific APIs under the hood (much like what <a href="https://github.com/tomdale/ember-network">ember-network</a> does for the <a href="https://github.com/tomdale/ember-network">fetch API</a>). Therefore we created <strong><a href="https://github.com/mainmatter/ember-cookies">ember-cookies</a> which is a cookies abstraction that works in the browser as well as in Node</strong> and that's now being used internally by the cookie session store.
+
+ember-cookies exposes a cookies service with <a href="https://github.com/mainmatter/ember-cookies#api">`read`, `write` and `clear` methods</a>:
 
 <!-- prettier-ignore -->
 ```js
@@ -75,9 +42,7 @@ export default Ember.Controller.extend({
 
 ## Using Ember Simple Auth with FastBoot
 
-As most of Ember Simple Auth's support for FastBoot is based on the cookie
-session store, <strong>enabling FastBoot support is as easy as defining the
-application session store</strong> as:
+As most of Ember Simple Auth's support for FastBoot is based on the cookie session store, <strong>enabling FastBoot support is as easy as defining the application session store</strong> as:
 
 ```js
 {% raw %}
@@ -88,53 +53,25 @@ export default Cookie.extend();
 {% endraw %}
 ```
 
-If you're interested in learning more about the underlying concepts check out
-the
-<a href="https://www.youtube.com/watch?v=jcAgi7fpTw8&index=6&list=PL4eq2DPpyBbmrPasP06vK7cUkPUCNn_rW">talk
-about Authentication and Session Management in FastBoot</a> that I gave at
-<a href="http://embercamp.com">EmberCamp</a> in London in June.
+If you're interested in learning more about the underlying concepts check out the <a href="https://www.youtube.com/watch?v=jcAgi7fpTw8&index=6&list=PL4eq2DPpyBbmrPasP06vK7cUkPUCNn_rW">talk about Authentication and Session Management in FastBoot</a> that I gave at <a href="http://embercamp.com">EmberCamp</a> in London in June.
 
 ## Other Changes and Fixes
 
-Out-of-the-box support for FastBoot is likely the most prominent addition in
-this release but there are <strong>quite some other changes</strong> as well,
-including:
+Out-of-the-box support for FastBoot is likely the most prominent addition in this release but there are <strong>quite some other changes</strong> as well, including:
 
-- The default cookie names that the cookie session store uses are now compliant
-  with RFC 2616, see
-  <a href="https://github.com/mainmatter/ember-simple-auth/pull/978">#978</a>
-- Server responses are now validated in authenticators, preventing successful
-  logins when required data is actually missing, see
-  <a href="https://github.com/mainmatter/ember-simple-auth/pull/957">#957</a>
-- The OAuth 2.0 Password Grant authenticator can now send custom headers along
-  with authentication requests, see
-  <a href="https://github.com/mainmatter/ember-simple-auth/pull/1018">#1018</a>
+- The default cookie names that the cookie session store uses are now compliant with RFC 2616, see <a href="https://github.com/mainmatter/ember-simple-auth/pull/978">#978</a>
+- Server responses are now validated in authenticators, preventing successful logins when required data is actually missing, see <a href="https://github.com/mainmatter/ember-simple-auth/pull/957">#957</a>
+- The OAuth 2.0 Password Grant authenticator can now send custom headers along with authentication requests, see <a href="https://github.com/mainmatter/ember-simple-auth/pull/1018">#1018</a>
 
 In addition to these changes, fixed issues include:
 
-- Routes like the login route can now be configured inline in routes using the
-  respective mixins as opposed to `config/environment.js`, see
-  <a href="https://github.com/mainmatter/ember-simple-auth/pull/1041">#1041</a>
-- The cookie session store will now rewrite its cookies when any of its
-  configurable properties (like cookie name) change, see
-  <a href="https://github.com/mainmatter/ember-simple-auth/pull/1056">#1056</a>
+- Routes like the login route can now be configured inline in routes using the respective mixins as opposed to `config/environment.js`, see <a href="https://github.com/mainmatter/ember-simple-auth/pull/1041">#1041</a>
+- The cookie session store will now rewrite its cookies when any of its configurable properties (like cookie name) change, see <a href="https://github.com/mainmatter/ember-simple-auth/pull/1056">#1056</a>
 
 ## A Community Effort
 
-This certainly is one of the larger releases in Ember Simple Auth's history and
-<strong>a lot of people have helped to make it happen</strong>. We'd like to
-thank all of our (at the time of this writing)
-<a href="https://github.com/mainmatter/ember-simple-auth/graphs/contributors">141
-contributors</a>, with particular mention to
-<a href="https://github.com/stevenwu">Steven Wu</a>,
-<a href="https://github.com/kylemellander">Kyle Mellander</a>,
-<a href="https://github.com/arjansingh">Arjan Singh</a> and
-<a href="https://github.com/josemarluedke">Josemar Luedke</a> for awesome
-contributions to the Fastboot effort and ember-cookies.
+This certainly is one of the larger releases in Ember Simple Auth's history and <strong>a lot of people have helped to make it happen</strong>. We'd like to thank all of our (at the time of this writing) <a href="https://github.com/mainmatter/ember-simple-auth/graphs/contributors">141 contributors</a>, with particular mention to <a href="https://github.com/stevenwu">Steven Wu</a>, <a href="https://github.com/kylemellander">Kyle Mellander</a>, <a href="https://github.com/arjansingh">Arjan Singh</a> and <a href="https://github.com/josemarluedke">Josemar Luedke</a> for awesome contributions to the Fastboot effort and ember-cookies.
 
 ## Try it!
 
-As this is a beta release, <strong>there are probably some rough edges</strong>.
-We'd like everyone to try it, regardless of whether they're using Fastboot
-already or not and <strong>report bugs, outdated or bad documentation etc. on
-<a href="https://github.com/mainmatter/ember-simple-auth/releases">github</a></strong>.
+As this is a beta release, <strong>there are probably some rough edges</strong>. We'd like everyone to try it, regardless of whether they're using Fastboot already or not and <strong>report bugs, outdated or bad documentation etc. on <a href="https://github.com/mainmatter/ember-simple-auth/releases">github</a></strong>.
diff --git a/src/posts/2017-01-13-ember-test-selectors.md b/src/posts/2017-01-13-ember-test-selectors.md
index 16a995f5f8..3e27a447e9 100644
--- a/src/posts/2017-01-13-ember-test-selectors.md
+++ b/src/posts/2017-01-13-ember-test-selectors.md
@@ -2,10 +2,7 @@
 title: New features for ember-test-selectors
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek announces new features in ember-test-selectors such as
-  automatic binding of data-test-* properties and how these are stripped in
-  production."
+description: "Tobias Bieniek announces new features in ember-test-selectors such as automatic binding of data-test-* properties and how these are stripped in production."
 tags: ember
 tagline: |
   <p>In March 2016 we have released the first version of <a href="https://github.com/mainmatter/ember-test-selectors">ember-test-selectors</a> and today we are proud to present you our next milestone: <code>0.1.0</code>.</p> <p>While <code>0.1.0</code> does not sound like much has changed, the addon has actually gained a lot of new functionality and should be considered our release candidate for <code>1.0.0</code>.</p> <p>This blog post will highlight the major changes in this release, and will give you a short introduction into <em>how</em> we have implemented these new features.</p>
@@ -13,10 +10,7 @@ tagline: |
 
 ## Automatic binding of `data-test-*` properties
 
-As you may know from our
-[previous blog post](/blog/2016/03/04/ember-test-selectors) on this topic, the
-goal of this addon is to let you use attributes starting with `data-test-` in
-your templates:
+As you may know from our [previous blog post](/blog/2016/03/04/ember-test-selectors) on this topic, the goal of this addon is to let you use attributes starting with `data-test-` in your templates:
 
 ```handlebars
 {% raw %}
@@ -27,8 +21,7 @@ your templates:
 {% endraw %}
 ```
 
-... so that you can use these as selectors in your acceptance and integration
-tests:
+... so that you can use these as selectors in your acceptance and integration tests:
 
 ```js
 {% raw %}
@@ -37,15 +30,9 @@ assert.equal(find(testSelector('post-title')).text(), 'my first blog post');
 {% endraw %}
 ```
 
-While this worked well on HTML tags, using the same pattern on components was a
-little more complicated. The assigned `data-test-*` properties needed to be
-bound to HTML attributes by adding them to the `attributeBindings` array on the
-component class.
+While this worked well on HTML tags, using the same pattern on components was a little more complicated. The assigned `data-test-*` properties needed to be bound to HTML attributes by adding them to the `attributeBindings` array on the component class.
 
-One of the major changes in this new release is that modifying the
-`attributeBindings` array is now done automatically for you, so that you can
-just assign `data-test-*` properties in your templates and they will
-automatically appear on the `<div>` tag wrapping the component:
+One of the major changes in this new release is that modifying the `attributeBindings` array is now done automatically for you, so that you can just assign `data-test-*` properties in your templates and they will automatically appear on the `<div>` tag wrapping the component:
 
 ```handlebars
 {% raw %}
@@ -61,29 +48,11 @@ automatically appear on the `<div>` tag wrapping the component:
 
 ### How we implemented this
 
-Since we wanted to make this feature available on all components by default we
-had to `reopen()` the `Ember.Component` class, figure out the list of
-`data-test-*` properties on the component, and then add them to the
-`attributeBindings` array.
-
-The natural way to do this within an addon is using an
-[initializer](https://guides.emberjs.com/v2.10.0/applications/initializers/), so
-that is what we
-[did](https://github.com/mainmatter/ember-test-selectors/blob/v0.1.0/addon/initializers/ember-test-selectors.js#L5-L10).
-Instead of putting all the logic in the initializer itself, we have extracted it
-into a
-[`bindDataTestAttributes()`](https://github.com/mainmatter/ember-test-selectors/blob/v0.1.0/addon/utils/bind-data-test-attributes.js)
-function, which we were now able to
-[unit test](https://github.com/mainmatter/ember-test-selectors/blob/v0.1.0/tests/unit/utils/bind-data-test-attributes-test.js)
-separately.
-
-As we are committed to not including any unnecessary code in your production
-builds, we also had to make sure to not include the initializer and utility
-function in there. Since both of those are part of our `addon` and `app`
-folders, which are included in your builds by default, we borrowed a
-["trick"](https://github.com/ember-cli/ember-cli-chai/blob/master/index.js#L119-L123)
-from [ember-cli-chai](https://github.com/ember-cli/ember-cli-chai/) which only
-includes both folders if we are in [testing mode](#testing-in-production-mode).
+Since we wanted to make this feature available on all components by default we had to `reopen()` the `Ember.Component` class, figure out the list of `data-test-*` properties on the component, and then add them to the `attributeBindings` array.
+
+The natural way to do this within an addon is using an [initializer](https://guides.emberjs.com/v2.10.0/applications/initializers/), so that is what we [did](https://github.com/mainmatter/ember-test-selectors/blob/v0.1.0/addon/initializers/ember-test-selectors.js#L5-L10). Instead of putting all the logic in the initializer itself, we have extracted it into a [`bindDataTestAttributes()`](https://github.com/mainmatter/ember-test-selectors/blob/v0.1.0/addon/utils/bind-data-test-attributes.js) function, which we were now able to [unit test](https://github.com/mainmatter/ember-test-selectors/blob/v0.1.0/tests/unit/utils/bind-data-test-attributes-test.js) separately.
+
+As we are committed to not including any unnecessary code in your production builds, we also had to make sure to not include the initializer and utility function in there. Since both of those are part of our `addon` and `app` folders, which are included in your builds by default, we borrowed a ["trick"](https://github.com/ember-cli/ember-cli-chai/blob/master/index.js#L119-L123) from [ember-cli-chai](https://github.com/ember-cli/ember-cli-chai/) which only includes both folders if we are in [testing mode](#testing-in-production-mode).
 
 ```js
 {% raw %}
@@ -107,30 +76,15 @@ module.exports = {
 {% endraw %}
 ```
 
-**UPDATE:** After releasing `0.1.0` we were notified that this feature was not
-working for component integration tests, which was actually a pretty obvious
-problem as initializers are not running for these kinds of tests. After thinking
-about the issue for a few hours we came up with a solution that seems to work
-even better now. Instead of calling `Component.reopen()` in an initializer we
-are now doing it in a file in our `vendor` folder, which is always being run
-before any tests are executed.
+**UPDATE:** After releasing `0.1.0` we were notified that this feature was not working for component integration tests, which was actually a pretty obvious problem as initializers are not running for these kinds of tests. After thinking about the issue for a few hours we came up with a solution that seems to work even better now. Instead of calling `Component.reopen()` in an initializer we are now doing it in a file in our `vendor` folder, which is always being run before any tests are executed.
 
-We have released `0.1.1` including this change and are now also warning you if
-you try to use `data-test-*` attributes on tagless components.
+We have released `0.1.1` including this change and are now also warning you if you try to use `data-test-*` attributes on tagless components.
 
 ## Stripping out `data-test-*` attributes in templates
 
-Our initial goal with this library was stripping our `data-test-*` attributes
-from HTML tags in your templates. In the previous section we implemented
-automatic bindings for `data-test-*` properties on components now too, but these
-properties were not stripped from the template yet.
+Our initial goal with this library was stripping our `data-test-*` attributes from HTML tags in your templates. In the previous section we implemented automatic bindings for `data-test-*` properties on components now too, but these properties were not stripped from the template yet.
 
-To modify templates from within an addon our best bet was to use an
-<abbr title="Abstract Syntax Tree">AST</abbr> transform on the Handlebars AST,
-that we get from the template parser. This can be accomplished by registering a
-Handlebars AST plugin in the
-[`setupPreprocessorRegistry()`](https://ember-cli.com/api/classes/Addon.html#method_setupPreprocessorRegistry)
-hook of the addon:
+To modify templates from within an addon our best bet was to use an <abbr title="Abstract Syntax Tree">AST</abbr> transform on the Handlebars AST, that we get from the template parser. This can be accomplished by registering a Handlebars AST plugin in the [`setupPreprocessorRegistry()`](https://ember-cli.com/api/classes/Addon.html#method_setupPreprocessorRegistry) hook of the addon:
 
 <!-- prettier-ignore -->
 ```js
@@ -151,9 +105,7 @@ module.exports = {
 {% endraw %}
 ```
 
-While this AST transform already existed in the previous releases, it was only
-able to handle `data-test-*` attributes on HTML tags (called `ElementNode`), but
-not on curly components yet:
+While this AST transform already existed in the previous releases, it was only able to handle `data-test-*` attributes on HTML tags (called `ElementNode`), but not on curly components yet:
 
 ```js
 {% raw %}
@@ -177,11 +129,9 @@ module.exports = class {
 {% endraw %}
 ```
 
-You can try out what this transform does in the
-[AST explorer](https://astexplorer.net/#/5ZDpdTbKwL).
+You can try out what this transform does in the [AST explorer](https://astexplorer.net/#/5ZDpdTbKwL).
 
-Fortunately for us the code to make this AST transform work for curly components
-is very similar:
+Fortunately for us the code to make this AST transform work for curly components is very similar:
 
 ```js
 {% raw %}
@@ -193,16 +143,11 @@ if (node.type === 'MustacheStatement' || node.type === 'BlockStatement') {
 {% endraw %}
 ```
 
-If you try the same example template in the
-[AST explorer](https://astexplorer.net/#/8wkrolD3V0), but with the modified
-transform code, you will notice that the `data-test-comment-id=comment.id` part
-of the `some-component` invocation is now gone.
+If you try the same example template in the [AST explorer](https://astexplorer.net/#/8wkrolD3V0), but with the modified transform code, you will notice that the `data-test-comment-id=comment.id` part of the `some-component` invocation is now gone.
 
 ## Stripping out `data-test-*` properties in JS files
 
-While one way of assigning data attributes to a component is in the template,
-data attributes can also be defined as properties on the component class. So
-instead of assigning `data-test-comment-id` inside the loop:
+While one way of assigning data attributes to a component is in the template, data attributes can also be defined as properties on the component class. So instead of assigning `data-test-comment-id` inside the loop:
 
 ```handlebars
 {% raw %}
@@ -212,8 +157,7 @@ instead of assigning `data-test-comment-id` inside the loop:
 {% endraw %}
 ```
 
-... we could also use a computed property inside the component that mirrors
-`comment.id`:
+... we could also use a computed property inside the component that mirrors `comment.id`:
 
 ```js
 {% raw %}
@@ -224,16 +168,9 @@ export default Ember.Component({
 {% endraw %}
 ```
 
-Unfortunately we have now have a property that is not stripped by the AST
-transform described in the previous section. At this point we could have used a
-similar strategy as before and added a JavaScript preprocessor, that strips all
-those properties from the code, but instead we hooked into the existing
-JavaScript processing pipeline using [Babel](http://babeljs.io/).
+Unfortunately we have now have a property that is not stripped by the AST transform described in the previous section. At this point we could have used a similar strategy as before and added a JavaScript preprocessor, that strips all those properties from the code, but instead we hooked into the existing JavaScript processing pipeline using [Babel](http://babeljs.io/).
 
-Fortunately for us the fantastic [AST explorer](https://astexplorer.net/) also
-supports prototyping Babel plugins and so we came up with a simple
-[plugin](https://astexplorer.net/#/xd5PB1rSD6) that basically just removes
-`data-test-*` properties from all the objects in your code:
+Fortunately for us the fantastic [AST explorer](https://astexplorer.net/) also supports prototyping Babel plugins and so we came up with a simple [plugin](https://astexplorer.net/#/xd5PB1rSD6) that basically just removes `data-test-*` properties from all the objects in your code:
 
 ```js
 {% raw %}
@@ -253,11 +190,7 @@ module.exports = function (babel) {
 {% endraw %}
 ```
 
-With the Babel plugin done, all we had left to do was making sure that your app
-actually uses that plugin at build time. While this is not quite public API and
-may change in the future we have found a way to accomplish that in the official
-[ember-cli-htmlbars-inline-precompile](https://github.com/ember-cli/ember-cli-htmlbars-inline-precompile/blob/v0.3.6/index.js#L64-L69)
-addon:
+With the Babel plugin done, all we had left to do was making sure that your app actually uses that plugin at build time. While this is not quite public API and may change in the future we have found a way to accomplish that in the official [ember-cli-htmlbars-inline-precompile](https://github.com/ember-cli/ember-cli-htmlbars-inline-precompile/blob/v0.3.6/index.js#L64-L69) addon:
 
 ```js
 {% raw %}
@@ -285,29 +218,13 @@ module.exports = {
 
 ## Testing in `production` mode
 
-In our previous releases we had offered an `environments` option to let you
-choose when to strip attributes and when to keep them in the templates. The
-default of this option was set to `['production']`, which made sense at the
-time.
-
-Since then we had discovered though that this will keep you from running your
-tests in `production` mode using `ember test --environment=production`. Instead
-of just checking the `environment` we are now making use of the
-([not yet documented](https://github.com/ember-cli/ember-cli/issues/6656))
-`tests` property on the `EmberApp` class in Ember CLI.
-
-This property will be `true` when using the `development` environment with
-either `ember build`, `ember serve` or `ember test`, or it will be `true` when
-using `ember test --environment=production`. That makes sure that we still strip
-all the `data-test-*` attributes from your code in production builds, but you
-should now again be able to also test your production builds using test
-selectors.
-
-Since we previously offered an option to override our defaults, we were
-committed to doing the same for the new defaults. For this we have deprecated
-this existing `environments` option, and introduced a new `strip` option, which
-can be set to `true` or `false`, but defaults to the `tests` property described
-above:
+In our previous releases we had offered an `environments` option to let you choose when to strip attributes and when to keep them in the templates. The default of this option was set to `['production']`, which made sense at the time.
+
+Since then we had discovered though that this will keep you from running your tests in `production` mode using `ember test --environment=production`. Instead of just checking the `environment` we are now making use of the ([not yet documented](https://github.com/ember-cli/ember-cli/issues/6656)) `tests` property on the `EmberApp` class in Ember CLI.
+
+This property will be `true` when using the `development` environment with either `ember build`, `ember serve` or `ember test`, or it will be `true` when using `ember test --environment=production`. That makes sure that we still strip all the `data-test-*` attributes from your code in production builds, but you should now again be able to also test your production builds using test selectors.
+
+Since we previously offered an option to override our defaults, we were committed to doing the same for the new defaults. For this we have deprecated this existing `environments` option, and introduced a new `strip` option, which can be set to `true` or `false`, but defaults to the `tests` property described above:
 
 ```js
 {% raw %}
@@ -319,17 +236,11 @@ var app = new EmberApp({
 {% endraw %}
 ```
 
-Note that using the `environments` option still works, but is deprecated and
-will be removed by the time we release `1.0.0`.
+Note that using the `environments` option still works, but is deprecated and will be removed by the time we release `1.0.0`.
 
 ## Simplified `testSelector()` import
 
-The `testSelector()` helper function can be used to simplify building the
-CSS/jQuery selector strings used for `find()` or `this.$()` in your tests.
-Previously you had to import that function from
-`<app-name>/tests/helpers/ember-test-selectors`, but since our `addon` folder is
-now removed from the build in production we were able to simplify that import to
-just this:
+The `testSelector()` helper function can be used to simplify building the CSS/jQuery selector strings used for `find()` or `this.$()` in your tests. Previously you had to import that function from `<app-name>/tests/helpers/ember-test-selectors`, but since our `addon` folder is now removed from the build in production we were able to simplify that import to just this:
 
 ```js
 {% raw %}
@@ -337,11 +248,6 @@ import testSelector from 'ember-test-selectors';
 {% endraw %}
 ```
 
-We hope you enjoyed reading about our progress on this project and we would love
-to get feedback on what else we can improve. Feel free to
-[reach out](https://github.com/mainmatter/ember-test-selectors/issues/new)!
+We hope you enjoyed reading about our progress on this project and we would love to get feedback on what else we can improve. Feel free to [reach out](https://github.com/mainmatter/ember-test-selectors/issues/new)!
 
-**Note:** The code examples in this blog posts are simplified to be easier to
-digest. Please refer to the
-[actual implementation](https://github.com/mainmatter/ember-test-selectors) if
-you want to see all the glory details.
+**Note:** The code examples in this blog posts are simplified to be easier to digest. Please refer to the [actual implementation](https://github.com/mainmatter/ember-test-selectors) if you want to see all the glory details.
diff --git a/src/posts/2017-02-01-class-based-computed-properties.md b/src/posts/2017-02-01-class-based-computed-properties.md
index 355abf5237..86ab67347e 100644
--- a/src/posts/2017-02-01-class-based-computed-properties.md
+++ b/src/posts/2017-02-01-class-based-computed-properties.md
@@ -2,9 +2,7 @@
 title: Class based Computed Properties
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte introduces a mechanism for class based computed properties
-  in Ember.js and how those can be used instead of helpers."
+description: "Marco Otte-Witte introduces a mechanism for class based computed properties in Ember.js and how those can be used instead of helpers."
 tags: ember
 tagline: |
   <p>We think Computed Properties in Ember are awesome. We also think they <a href="https://speakerdeck.com/marcoow/templates-and-logic-in-ember">are in many cases the better alternative to template helpers</a> as they allow for cleaner separation of where a computation is triggered and the implementation of that computation. In some cases though it is currently very hard to do things in Computed Properties (and Computed Property macros in particular) that are possible with Class based helpers. With the <strong>introduction of Class based Computed Properties</strong> we're aiming at making these scenarios solvable easily.</p>
@@ -12,13 +10,9 @@ tagline: |
 
 ## Computed Properties and Computed Property Macros
 
-Computed Properties are among the first things developers new to Ember learn.
-They are a great way of defining dependencies between data points in the
-application and **ensuring the UI stays consistent as these data points
-change**.
+Computed Properties are among the first things developers new to Ember learn. They are a great way of defining dependencies between data points in the application and **ensuring the UI stays consistent as these data points change**.
 
-Ember comes with a set of macros that implement property logic that most
-applications need and allow for short and expressive definitions like
+Ember comes with a set of macros that implement property logic that most applications need and allow for short and expressive definitions like
 
 ```js
 {% raw %}
@@ -26,22 +20,13 @@ isActive: Ember.computed.equal('state', 'isActive');
 {% endraw %}
 ```
 
-There are addons that provide even more macros for common use cases like
-[ember-cpm](https://github.com/cibernox/ember-cpm) or
-[ember-awesome-macros](https://github.com/kellyselden/ember-awesome-macros).
+There are addons that provide even more macros for common use cases like [ember-cpm](https://github.com/cibernox/ember-cpm) or [ember-awesome-macros](https://github.com/kellyselden/ember-awesome-macros).
 
 ## Where Computed Property Macros fall short today
 
-**Computed Properties are very similar to template helpers** in the way that
-both are [pure functions](https://en.wikipedia.org/wiki/Pure_function) that can
-only depend on their inputs. While a template helpers receives its inputs as
-arguments, **Computed Properties define their inputs as dependent keys**.
+**Computed Properties are very similar to template helpers** in the way that both are [pure functions](https://en.wikipedia.org/wiki/Pure_function) that can only depend on their inputs. While a template helpers receives its inputs as arguments, **Computed Properties define their inputs as dependent keys**.
 
-In some cases pure functions are not sufficient though as the computation in the
-template helper or computed property also depends on global state or the inputs
-cannot statically be listed in the helper or property definition. This is the
-case for example for computations on collections when it is unknown upfront on
-which property of each element in the collection the computation depends, e.g.
+In some cases pure functions are not sufficient though as the computation in the template helper or computed property also depends on global state or the inputs cannot statically be listed in the helper or property definition. This is the case for example for computations on collections when it is unknown upfront on which property of each element in the collection the computation depends, e.g.
 
 ```js
 {% raw %}
@@ -49,14 +34,9 @@ filteredUsers: filterByProperty('users' 'filter')
 {% endraw %}
 ```
 
-Here what we would like to do is filter the `users` array by the value of the
-`filter` property of the context. E.g. when `filter` is `'isActive'` we'd expect
-`filteredUsers` to contain all active users, when `filter` is `'isBlocked'` we'd
-expect it to contain all blocked users and so on.
+Here what we would like to do is filter the `users` array by the value of the `filter` property of the context. E.g. when `filter` is `'isActive'` we'd expect `filteredUsers` to contain all active users, when `filter` is `'isBlocked'` we'd expect it to contain all blocked users and so on.
 
-With template helpers and the
-[ember-composable-helpers](https://github.com/DockYard/ember-composable-helpers)
-addon, we're be able to write something like this in the template:
+With template helpers and the [ember-composable-helpers](https://github.com/DockYard/ember-composable-helpers) addon, we're be able to write something like this in the template:
 
 ```hbs
 {% raw %}
@@ -66,25 +46,13 @@ addon, we're be able to write something like this in the template:
 {% endraw %}
 ```
 
-and because the
-[`filter-by` helper is a Class based helper](https://github.com/DockYard/ember-composable-helpers/blob/master/addon/helpers/filter-by.js)
-this actually works and the DOM updates correctly whenever the value of the
-`filter` property or e.g. the `isActive` property of any user changes.
+and because the [`filter-by` helper is a Class based helper](https://github.com/DockYard/ember-composable-helpers/blob/master/addon/helpers/filter-by.js) this actually works and the DOM updates correctly whenever the value of the `filter` property or e.g. the `isActive` property of any user changes.
 
-With Computed Properties **it is not currently possible to implement something
-like this** (at least not as a reusable macro).
+With Computed Properties **it is not currently possible to implement something like this** (at least not as a reusable macro).
 
 ## Enter Class based Computed Properties
 
-With the Class based Computed Properties that
-[ember-classy-computed](https://github.com/mainmatter/ember-classy-computed)
-introduces it is **actually possible now to implement something like the above
-mentioned `filterByProperty` macro**. The computed property returned by that
-macro can now correctly be invalidated when any of the user's `isActive`,
-`isBlocked` etc. properties change although it is not actually possible to know
-what these properties might be upfront. This **allows keeping the filtering
-logic in JavaScript as opposed to in the template** when using a Class based
-template helper:
+With the Class based Computed Properties that [ember-classy-computed](https://github.com/mainmatter/ember-classy-computed) introduces it is **actually possible now to implement something like the above mentioned `filterByProperty` macro**. The computed property returned by that macro can now correctly be invalidated when any of the user's `isActive`, `isBlocked` etc. properties change although it is not actually possible to know what these properties might be upfront. This **allows keeping the filtering logic in JavaScript as opposed to in the template** when using a Class based template helper:
 
 ```js
 {% raw %}
@@ -145,21 +113,8 @@ export default ClassBasedComputedProperty.property(DynamicFilterByComputed);
 {% endraw %}
 ```
 
-Comparing this code to the implementation of the
-[`filter-by` helper](https://github.com/DockYard/ember-composable-helpers/blob/master/addon/helpers/filter-by.js)
-mentioned above you will recognize that both are almost identical. This
-illustrates very well what Class based Computed Properties are: a way to **use
-the same mechanisms that are already established for Class based template
-helpers for Computed Properties** as well.
+Comparing this code to the implementation of the [`filter-by` helper](https://github.com/DockYard/ember-composable-helpers/blob/master/addon/helpers/filter-by.js) mentioned above you will recognize that both are almost identical. This illustrates very well what Class based Computed Properties are: a way to **use the same mechanisms that are already established for Class based template helpers for Computed Properties** as well.
 
 ## Notice
 
-**[ember-classy-computed](https://github.com/mainmatter/ember-classy-computed)
-is currently at a very early stage** and we haven't thoroughly tested the
-implementation just yet. We have also not done any benchmarking to get a better
-understanding of what the performance implications are. That is to say, **while
-we encourage everyone to try this out, be aware you're currently doing so at
-your own risk** as this is most likely not production ready (yet). We have the
-feeling though that this will be a valuable addition to Computed Properties in
-the future and can close the gap that currently exists between Computed
-Properties and template helpers.
+**[ember-classy-computed](https://github.com/mainmatter/ember-classy-computed) is currently at a very early stage** and we haven't thoroughly tested the implementation just yet. We have also not done any benchmarking to get a better understanding of what the performance implications are. That is to say, **while we encourage everyone to try this out, be aware you're currently doing so at your own risk** as this is most likely not production ready (yet). We have the feeling though that this will be a valuable addition to Computed Properties in the future and can close the gap that currently exists between Computed Properties and template helpers.
diff --git a/src/posts/2017-02-13-npm-libs-in-ember-cli.md b/src/posts/2017-02-13-npm-libs-in-ember-cli.md
index 7468ca6ade..1bda11c4d6 100644
--- a/src/posts/2017-02-13-npm-libs-in-ember-cli.md
+++ b/src/posts/2017-02-13-npm-libs-in-ember-cli.md
@@ -2,9 +2,7 @@
 title: Using npm libraries in Ember CLI
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek introduces a mechanism for using arbitrary npm libraries in
-  Ember CLI applications and explains how that works under the hood."
+description: "Tobias Bieniek introduces a mechanism for using arbitrary npm libraries in Ember CLI applications and explains how that works under the hood."
 tags: ember
 og:
   image: /assets/images/posts/2017-02-13-npm-libs-in-ember-cli/og-image.jpg
@@ -14,16 +12,13 @@ tagline: |
 
 ## Status Quo
 
-The way to import Bower libraries into your app consists of three major steps.
-First we will have to install the library. We will use the popular
-[Moment.js][moment.js] library as an example here:
+The way to import Bower libraries into your app consists of three major steps. First we will have to install the library. We will use the popular [Moment.js][moment.js] library as an example here:
 
 ```
 bower install --save moment
 ```
 
-Secondly we will import it into the Ember CLI build pipeline by adding the
-following line to our `ember-cli-build.js` file:
+Secondly we will import it into the Ember CLI build pipeline by adding the following line to our `ember-cli-build.js` file:
 
 ```js
 {% raw %}
@@ -31,19 +26,15 @@ app.import('bower_components/moment/moment.js');
 {% endraw %}
 ```
 
-This `import()` call tells Ember CLI to add the `moment.js` file to the
-generated `vendor.js` file to make the `moment` global available to the app.
+This `import()` call tells Ember CLI to add the `moment.js` file to the generated `vendor.js` file to make the `moment` global available to the app.
 
-As we prefer to use ES6 imports instead of globals we will generate a so-called
-"vendor shim" which essentially just wraps the global and provides us with a way
-to import it as an ES6 module:
+As we prefer to use ES6 imports instead of globals we will generate a so-called "vendor shim" which essentially just wraps the global and provides us with a way to import it as an ES6 module:
 
 ```
 ember generate vendor-shim moment
 ```
 
-Running this command will generate a `vendor/shims/moment.js` file that looks
-like this:
+Running this command will generate a `vendor/shims/moment.js` file that looks like this:
 
 ```js
 {% raw %}
@@ -59,20 +50,11 @@ like this:
 {% endraw %}
 ```
 
-This looks a little cryptic at first, but once you understand the individual
-parts it starts to make sense.
+This looks a little cryptic at first, but once you understand the individual parts it starts to make sense.
 
-The files that the Ember CLI build pipeline generates use the [Asynchronous
-Module Definition][amd] (or shorter: AMD). The `define()` call in the code above
-defines a new AMD module with the name `moment` and the return value of the
-`vendorModule` function describes what the module exports, or what we can import
-from that module in our own code. In this case we export an object with a
-`default` property that contains the `moment` global. You can find more
-information on "default exports" and ES6 modules in general in the
-[Exploring ES6](http://exploringjs.com/es6/ch_modules.html) ebook.
+The files that the Ember CLI build pipeline generates use the [Asynchronous Module Definition][amd] (or shorter: AMD). The `define()` call in the code above defines a new AMD module with the name `moment` and the return value of the `vendorModule` function describes what the module exports, or what we can import from that module in our own code. In this case we export an object with a `default` property that contains the `moment` global. You can find more information on "default exports" and ES6 modules in general in the [Exploring ES6](http://exploringjs.com/es6/ch_modules.html) ebook.
 
-To use this vendor shim we will have to `app.import()` it like we did with the
-library itself:
+To use this vendor shim we will have to `app.import()` it like we did with the library itself:
 
 ```js
 {% raw %}
@@ -84,13 +66,9 @@ We are now able to use `import moment from 'moment';` in our Ember code.
 
 ## App vs. Addon
 
-The above instructions work great for apps, but what about addons? The
-`ember-cli-build.js` file for addons is only relevant for building the dummy app
-of the addon, but not for any other app using the addon. That means we can't
-just call `app.import()` in the `ember-cli-build.js` file like we did above.
+The above instructions work great for apps, but what about addons? The `ember-cli-build.js` file for addons is only relevant for building the dummy app of the addon, but not for any other app using the addon. That means we can't just call `app.import()` in the `ember-cli-build.js` file like we did above.
 
-The solution to that is using the [`included()`][included-hook] in the
-`index.js` file of the addon:
+The solution to that is using the [`included()`][included-hook] in the `index.js` file of the addon:
 
 ```js
 {% raw %}
@@ -102,34 +80,20 @@ included() {
 {% endraw %}
 ```
 
-Note that the `this.import()` method is only available starting with Ember CLI
-2.7. You can easily polyfill it though if you want to support Ember CLI releases
-below that. Have a look at the
-[ember-simple-auth](https://github.com/mainmatter/ember-simple-auth/blob/1ca4ae678b7be9905076762220dcd9fcb0f27ac0/index.js#L24-L39)
-code to find out how to do it.
+Note that the `this.import()` method is only available starting with Ember CLI 2.7. You can easily polyfill it though if you want to support Ember CLI releases below that. Have a look at the [ember-simple-auth](https://github.com/mainmatter/ember-simple-auth/blob/1ca4ae678b7be9905076762220dcd9fcb0f27ac0/index.js#L24-L39) code to find out how to do it.
 
-This seems to work fine now if we are just looking at the dummy app, but in
-reality it will not work yet for any other apps. The reason for this is that the
-`bower_components` folder above refers to the `bower_components` folder of the
-"host app", not of the addon itself. That means we will have to
-`bower install --save moment` into the host app itself and there are two ways to
-do it:
+This seems to work fine now if we are just looking at the dummy app, but in reality it will not work yet for any other apps. The reason for this is that the `bower_components` folder above refers to the `bower_components` folder of the "host app", not of the addon itself. That means we will have to `bower install --save moment` into the host app itself and there are two ways to do it:
 
 - the lazy way: tell the users in the `README` file to install it like that
-- the comfortable way: install it automatically for them using an Ember CLI
-  blueprint
+- the comfortable way: install it automatically for them using an Ember CLI blueprint
 
-Since we want to make it as easy for our users as possible we will prefer the
-second solution, which is not actually that hard to implement either. First we
-will have to generate a blueprint that matches the package name of our addon. So
-if our addon was called `ember-moment` we would run:
+Since we want to make it as easy for our users as possible we will prefer the second solution, which is not actually that hard to implement either. First we will have to generate a blueprint that matches the package name of our addon. So if our addon was called `ember-moment` we would run:
 
 ```
 ember generate blueprint ember-moment
 ```
 
-This will generate a `blueprints/ember-moment/index.js` file in which we will
-have to implement two hooks:
+This will generate a `blueprints/ember-moment/index.js` file in which we will have to implement two hooks:
 
 ```js
 {% raw %}
@@ -143,44 +107,19 @@ module.exports = {
 {% endraw %}
 ```
 
-The `normalizeEntityName` hook is usually used to e.g. read the name of the
-route you want to generate with `ember generate route <routename>`. Since this
-is the default blueprint which will be executed automatically when the our addon
-is installed through `ember install ember-moment` we don't need this method and
-have to overwrite it to make sure it does not complain about a missing name.
-
-The `afterInstall` hook is the important part. The
-[`addBowerPackageToProject()`](https://ember-cli.com/api/classes/Blueprint.html#method_addBowerPackageToProject)
-method installs the `moment` Bower package into the application by adding it to
-the host app `bower.json` file. That way the Moment.js files will be present in
-the top level `bower_components` folder of the application instead of being
-available only inside of the addon. Since the `addBowerPackageToProject()`
-method returns a `Promise` we have to return it from the `afterInstall` hook to
-make sure that Ember CLI waits for the installation to finish.
+The `normalizeEntityName` hook is usually used to e.g. read the name of the route you want to generate with `ember generate route <routename>`. Since this is the default blueprint which will be executed automatically when the our addon is installed through `ember install ember-moment` we don't need this method and have to overwrite it to make sure it does not complain about a missing name.
+
+The `afterInstall` hook is the important part. The [`addBowerPackageToProject()`](https://ember-cli.com/api/classes/Blueprint.html#method_addBowerPackageToProject) method installs the `moment` Bower package into the application by adding it to the host app `bower.json` file. That way the Moment.js files will be present in the top level `bower_components` folder of the application instead of being available only inside of the addon. Since the `addBowerPackageToProject()` method returns a `Promise` we have to return it from the `afterInstall` hook to make sure that Ember CLI waits for the installation to finish.
 
 ## npm vs. Bower
 
-> &quot;What&#39;s bower?&quot; > &quot;A package manager, install it with
-> npm.&quot; > &quot;What&#39;s npm?&quot; > &quot;A package manager, you can
-> install it with brew&quot; > &quot;What&#39;s brew?&quot; ... <author>Stefan
-> Baumgartner (@ddprrt)
-> <a href="https://twitter.com/ddprrt/status/529909875347030016">5. November
-> 2014</a></author>
+> &quot;What&#39;s bower?&quot; > &quot;A package manager, install it with npm.&quot; > &quot;What&#39;s npm?&quot; > &quot;A package manager, you can install it with brew&quot; > &quot;What&#39;s brew?&quot; ... <author>Stefan Baumgartner (@ddprrt) <a href="https://twitter.com/ddprrt/status/529909875347030016">5. November 2014</a></author>
 
-In an effort to simplify the situation the Ember team decided to focus on npm in
-the future. Bower support will still be available to support older addons for
-now, but might be deprecated at some point. That means that we should modify our
-`ember-moment` addon above to install Moment.js via npm instead of Bower.
+In an effort to simplify the situation the Ember team decided to focus on npm in the future. Bower support will still be available to support older addons for now, but might be deprecated at some point. That means that we should modify our `ember-moment` addon above to install Moment.js via npm instead of Bower.
 
-Fortunately for us Moment.js is also distributed on npm so we can just
-`npm install --save moment` instead of using Bower and we're done, right? Well,
-not quite. Unfortunately for the time being things are a little more
-complicated, but the Ember CLI team has plans to make it easier in the future.
+Fortunately for us Moment.js is also distributed on npm so we can just `npm install --save moment` instead of using Bower and we're done, right? Well, not quite. Unfortunately for the time being things are a little more complicated, but the Ember CLI team has plans to make it easier in the future.
 
-Let's start with the simple part: Installing via npm instead of Bower. Instead
-of using `addBowerPackageToProject()` to install Moment.js we can use the
-[`addPackageToProject()`](https://ember-cli.com/api/classes/Blueprint.html#method_addPackageToProject)
-method instead:
+Let's start with the simple part: Installing via npm instead of Bower. Instead of using `addBowerPackageToProject()` to install Moment.js we can use the [`addPackageToProject()`](https://ember-cli.com/api/classes/Blueprint.html#method_addPackageToProject) method instead:
 
 ```js
 {% raw %}
@@ -192,31 +131,17 @@ afterInstall() {
 
 That was easy! So where is the problem now?
 
-Remember how we called `this.import()` to import the `moment.js` file into the
-build pipeline and the `vendor.js` file? The `import()` method currently only
-works for files inside the `bower_components` and `vendor` folders, but not the
-`node_modules` folder. This was done for reasons of build performance but might
-change at some point in the future once other issues are resolved. As we cannot
-simply import `moment` from the `node_modules` folder we have to find another
-way for loading the newly installed dependency into the app.
+Remember how we called `this.import()` to import the `moment.js` file into the build pipeline and the `vendor.js` file? The `import()` method currently only works for files inside the `bower_components` and `vendor` folders, but not the `node_modules` folder. This was done for reasons of build performance but might change at some point in the future once other issues are resolved. As we cannot simply import `moment` from the `node_modules` folder we have to find another way for loading the newly installed dependency into the app.
 
-At this point we could just stop and give up, but instead we will use a
-workaround that "moves" the file into our `vendor` folder and import it from
-there. Instead of actually moving it as part of the installation process though
-we tell Ember CLI to move it automatically as part of the build process.
+At this point we could just stop and give up, but instead we will use a workaround that "moves" the file into our `vendor` folder and import it from there. Instead of actually moving it as part of the installation process though we tell Ember CLI to move it automatically as part of the build process.
 
-To implement this we will need the fundamental
-[broccoli-funnel](https://github.com/broccolijs/broccoli-funnel) and
-[broccoli-merge-trees](https://github.com/broccolijs/broccoli-merge-trees) npm
-packages:
+To implement this we will need the fundamental [broccoli-funnel](https://github.com/broccolijs/broccoli-funnel) and [broccoli-merge-trees](https://github.com/broccolijs/broccoli-merge-trees) npm packages:
 
 ```
 npm install --save broccoli-funnel broccoli-merge-trees
 ```
 
-Next we will implement the `treeForVendor()` hook in our `index.js` file and
-adjust the `moment.js` import in the `included()` hook to point to
-`vendor/moment.js` instead:
+Next we will implement the `treeForVendor()` hook in our `index.js` file and adjust the `moment.js` import in the `included()` hook to point to `vendor/moment.js` instead:
 
 ```js
 {% raw %}
@@ -247,28 +172,15 @@ module.exports = {
 {% endraw %}
 ```
 
-Let me explain what we did here. The `vendorTree` argument holds the actual
-content of our `vendor` folder as we can see it in our addon. Next we create a
-new `Funnel` tree, which is a fancy way of saying: import files into the build
-pipeline. Essentially we just lookup the `moment.js` file inside the
-`node_modules/moment` folder of the host app and wrap that in a Broccoli tree.
-The last step merges the `vendorTree` and the `momentTree` into a single tree
-which now contains the `moment.js` file and our vendor shim for the `vendor`
-folder.
+Let me explain what we did here. The `vendorTree` argument holds the actual content of our `vendor` folder as we can see it in our addon. Next we create a new `Funnel` tree, which is a fancy way of saying: import files into the build pipeline. Essentially we just lookup the `moment.js` file inside the `node_modules/moment` folder of the host app and wrap that in a Broccoli tree. The last step merges the `vendorTree` and the `momentTree` into a single tree which now contains the `moment.js` file and our vendor shim for the `vendor` folder.
 
-If you want to learn more about Broccoli and how the build pipeline works I
-recommend watching Estelle DeBlois explain it in her fantastic EmberConf talk:
-[Dissecting an Ember CLI Build](https://youtu.be/hNwgp9alwKg).
+If you want to learn more about Broccoli and how the build pipeline works I recommend watching Estelle DeBlois explain it in her fantastic EmberConf talk: [Dissecting an Ember CLI Build](https://youtu.be/hNwgp9alwKg).
 
-Now that we've imported the `moment.js` file into our `vendor` tree we can
-finally `import()` it in the `included()` hook and everything works again.
+Now that we've imported the `moment.js` file into our `vendor` tree we can finally `import()` it in the `included()` hook and everything works again.
 
 ## npm dependencies
 
-As we are using npm now we can also take advantage of the way that npm resolves
-dependencies. That means instead of using a blueprint to install the npm package
-into the host app we declare `moment` as a dependency of the addon instead in
-our `package.json` file:
+As we are using npm now we can also take advantage of the way that npm resolves dependencies. That means instead of using a blueprint to install the npm package into the host app we declare `moment` as a dependency of the addon instead in our `package.json` file:
 
 ```js
 {% raw %}on
@@ -280,12 +192,7 @@ our `package.json` file:
 {% endraw %}
 ```
 
-Since npm deduplicates packages during installation we can not be certain about
-the path where `moment` is actually installed though. We need to use a resolver
-algorithm to find the file inside the `node_modules` folder. Fortunately Node.js
-has that algorithm built-in and we can just use it through the
-`require.resolve()` function. All we have to do now is modify the `momentTree`
-code like this:
+Since npm deduplicates packages during installation we can not be certain about the path where `moment` is actually installed though. We need to use a resolver algorithm to find the file inside the `node_modules` folder. Fortunately Node.js has that algorithm built-in and we can just use it through the `require.resolve()` function. All we have to do now is modify the `momentTree` code like this:
 
 ```js
 {% raw %}
@@ -295,28 +202,17 @@ var momentTree = new Funnel(path.dirname(require.resolve('moment/moment.js')), {
 {% endraw %}
 ```
 
-Note that we are passing the path to the `moment` **folder**, not to the
-`moment.js` file itself, to the `Funnel` constructor.
+Note that we are passing the path to the `moment` **folder**, not to the `moment.js` file itself, to the `Funnel` constructor.
 
-Everything should work fine now and we can remove the `ember-moment` blueprint
-and the `moment` dependency from the host app again since that is now a
-subdependency via `ember-moment`.
+Everything should work fine now and we can remove the `ember-moment` blueprint and the `moment` dependency from the host app again since that is now a subdependency via `ember-moment`.
 
-If you want to see these things applied to a real addon visit the code of the
-[`ember-cli-moment-shim`](https://github.com/jasonmit/ember-cli-moment-shim)
-addon and have a look at their `index.js` file. They do support fastboot too
-though which makes the code a little more complicated compared to our simplified
-example here.
+If you want to see these things applied to a real addon visit the code of the [`ember-cli-moment-shim`](https://github.com/jasonmit/ember-cli-moment-shim) addon and have a look at their `index.js` file. They do support fastboot too though which makes the code a little more complicated compared to our simplified example here.
 
 ## App vs. Addon again
 
-Now that we have converted our `ember-moment` addon to use npm instead of Bower,
-how could we do the same if we wanted to use Moment.js in our app directly
-without an additional addon?
+Now that we have converted our `ember-moment` addon to use npm instead of Bower, how could we do the same if we wanted to use Moment.js in our app directly without an additional addon?
 
-Unfortunately there is currently no perfect solution for this and the best way
-is using an [in-repo-addon](https://ember-cli.com/extending/#in-repo-addons) for
-that. You could for example generate a `ember-moment` in-repo-addon:
+Unfortunately there is currently no perfect solution for this and the best way is using an [in-repo-addon](https://ember-cli.com/extending/#in-repo-addons) for that. You could for example generate a `ember-moment` in-repo-addon:
 
 ```
 ember generate in-repo-addon ember-moment
@@ -326,11 +222,7 @@ and use the same code as above inside the `lib/ember-moment/index.js` file.
 
 ## Next: CommonJS and ES6 modules
 
-Things get a little more complicated when you want to use npm packages that are
-not distributed in a prebuilt form like Moment.js. If they instead export only
-CommonJS modules or ES6 modules we will need to add a few more plugins to the
-build pipeline to make this work and we will explain how to do that in a future
-blog post.
+Things get a little more complicated when you want to use npm packages that are not distributed in a prebuilt form like Moment.js. If they instead export only CommonJS modules or ES6 modules we will need to add a few more plugins to the build pipeline to make this work and we will explain how to do that in a future blog post.
 
 [ember-source]: https://www.npmjs.com/package/ember-source
 [bower]: https://bower.io/
diff --git a/src/posts/2017-03-21-on-computed-properties-vs-helpers.md b/src/posts/2017-03-21-on-computed-properties-vs-helpers.md
index 863e82428a..efc65b9b72 100644
--- a/src/posts/2017-03-21-on-computed-properties-vs-helpers.md
+++ b/src/posts/2017-03-21-on-computed-properties-vs-helpers.md
@@ -2,9 +2,7 @@
 title: On Computed Properties vs. Helpers
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte discusses differences between computed properties and
-  helpers and explains pros and cons of each alternative."
+description: "Marco Otte-Witte discusses differences between computed properties and helpers and explains pros and cons of each alternative."
 tags: ember
 og:
   image: /assets/images/posts/2017-03-21-on-computed-properties-vs-helpers/og-image.jpg
@@ -14,12 +12,9 @@ tagline: |
 
 ## Computed Properties
 
-Computed Properties allow defining properties as functions of other properties.
-Ember automatically re-evaluates computed properties (lazily) when any of its
-dependents change so that they don't get out of sync.
+Computed Properties allow defining properties as functions of other properties. Ember automatically re-evaluates computed properties (lazily) when any of its dependents change so that they don't get out of sync.
 
-Here's a simple example of a computed property that is `true` when the `age`
-property is at least `65`:
+Here's a simple example of a computed property that is `true` when the `age` property is at least `65`:
 
 ```js
 {% raw %}
@@ -29,14 +24,9 @@ isSenior: computed('age', function () {
 {% endraw %}
 ```
 
-The `age` property is listed as a dependency of the `isSenior` property, thus
-the `isSenior` property will be invalidated whenever the `age` property changes
-and re-evaluated the next time it is accessed (unless it is used in a template
-in which case the property is immediately re-evaluated so that the UI stays in
-sync with the underlying data).
+The `age` property is listed as a dependency of the `isSenior` property, thus the `isSenior` property will be invalidated whenever the `age` property changes and re-evaluated the next time it is accessed (unless it is used in a template in which case the property is immediately re-evaluated so that the UI stays in sync with the underlying data).
 
-The `isSenior` property can then be used in a template (we're assuming it is
-defined on the `user` here):
+The `isSenior` property can then be used in a template (we're assuming it is defined on the `user` here):
 
 ```hbs
 {% raw %}
@@ -51,9 +41,7 @@ defined on the `user` here):
 
 ## Template Helpers
 
-The above example **could just as easily be implemented using a template
-helper**. Instead of defining the `isSenior` property with its dependents
-upfront, one could define an `lte` helper like this:
+The above example **could just as easily be implemented using a template helper**. Instead of defining the `isSenior` property with its dependents upfront, one could define an `lte` helper like this:
 
 ```js
 {% raw %}
@@ -78,36 +66,17 @@ and move the comparison into the template:
 
 ## What's the difference?
 
-Both alternatives are obviously very similar - both compare the user's `age`
-property with a comparison value and depending on the outcome of that comparison
-render some nodes to the DOM (or don't render them). The main difference is that
-**with the computed property that comparison lives in the template context** and
-is only invoked from the template (via the `isSenior` identifier) while **when
-using a helper the comparison is defined inline right in the template** itself.
+Both alternatives are obviously very similar - both compare the user's `age` property with a comparison value and depending on the outcome of that comparison render some nodes to the DOM (or don't render them). The main difference is that **with the computed property that comparison lives in the template context** and is only invoked from the template (via the `isSenior` identifier) while **when using a helper the comparison is defined inline right in the template** itself.
 
-This might not seem like a big thing but there actually are some differences
-between the two alternatives that have consequences on certain aspects of the
-application.
+This might not seem like a big thing but there actually are some differences between the two alternatives that have consequences on certain aspects of the application.
 
 ### Separation vs. Unification
 
-The main difference is that with the computed property solution, the logic and
-its internals are separated from the template. The **logic lives in the template
-context and appears as a black box to the template** which merely uses some
-named properties - this is actually quite **similar to a class exposing named
-methods** where the caller of these methods does not have to worry about their
-internals as long as it's clear what they are supposed to be used for.
+The main difference is that with the computed property solution, the logic and its internals are separated from the template. The **logic lives in the template context and appears as a black box to the template** which merely uses some named properties - this is actually quite **similar to a class exposing named methods** where the caller of these methods does not have to worry about their internals as long as it's clear what they are supposed to be used for.
 
-With the **template helpers solution though both the rendering as well as the
-logic are merged in the template**. That means that understanding and
-maintaining the template includes understanding all of the logic encoded in the
-helper invocations.
+With the **template helpers solution though both the rendering as well as the logic are merged in the template**. That means that understanding and maintaining the template includes understanding all of the logic encoded in the helper invocations.
 
-While the complexity that's added to the template in the above example is fairly
-limited of course, this point gets more obvious when looking at a slightly more
-involved example. Assume there is a collection of users from which we want to
-select a random one with a `status` of `'active'`. A computed property returning
-such a user could look like this:
+While the complexity that's added to the template in the above example is fairly limited of course, this point gets more obvious when looking at a slightly more involved example. Assume there is a collection of users from which we want to select a random one with a `status` of `'active'`. A computed property returning such a user could look like this:
 
 ```js
 {% raw %}
@@ -118,8 +87,7 @@ userToDisplay: computed('users.@each.state', function () {
 {% endraw %}
 ```
 
-Rendering that user's `name` then is as easy as using the `userToDisplay`
-property in the template:
+Rendering that user's `name` then is as easy as using the `userToDisplay` property in the template:
 
 ```hbs
 {% raw %}
@@ -127,9 +95,7 @@ property in the template:
 {% endraw %}
 ```
 
-Comparing this to a solution that moves all of the logic for selecting the user
-into the template via helpers illustrates how much harder it becomes to
-understand the template now:
+Comparing this to a solution that moves all of the logic for selecting the user into the template via helpers illustrates how much harder it becomes to understand the template now:
 
 ```hbs
 {% raw %}
@@ -139,46 +105,21 @@ understand the template now:
 {% endraw %}
 ```
 
-Instead of hiding this complexity behind a named interface all of it is right
-there in the template and cannot be ignored as it can be when using a computed
-property.
+Instead of hiding this complexity behind a named interface all of it is right there in the template and cannot be ignored as it can be when using a computed property.
 
 ### Testability
 
-Another consequence of **moving logic into the template is that the logic itself
-becomes harder to test**. While logic that lives in the template context in the
-form of computed properties is easily unit-testable, **logic that lives in the
-template can only be tested by actually rendering the template** which again
-leads to a few other consequences:
-
-- Tests become slower to execute as it's obviously slower to render than not to
-  render.
-- Each test case becomes more complex. While unit tests can assert on the value
-  of the computed property (e.g. `asser.equal(user.get('isSenior') true)`),
-  (integration) tests for logic inside of templates have to assert on the
-  presence or absence of DOM nodes (e.g.
-  `assert.ok(find(testSelector('senior-flag')))`) which obviously is a much more
-  indirect way of testing the same thing.
-- Test cases (potentially) require more and unrelated context to be set up.
-  While unit tests for computed properties only require the dependent properties
-  of the computed property under test to be set up, rendering a template
-  requires the full context for that template to be set up which might include
-  elements that are unrelated to the current test case.
+Another consequence of **moving logic into the template is that the logic itself becomes harder to test**. While logic that lives in the template context in the form of computed properties is easily unit-testable, **logic that lives in the template can only be tested by actually rendering the template** which again leads to a few other consequences:
+
+- Tests become slower to execute as it's obviously slower to render than not to render.
+- Each test case becomes more complex. While unit tests can assert on the value of the computed property (e.g. `asser.equal(user.get('isSenior') true)`), (integration) tests for logic inside of templates have to assert on the presence or absence of DOM nodes (e.g. `assert.ok(find(testSelector('senior-flag')))`) which obviously is a much more indirect way of testing the same thing.
+- Test cases (potentially) require more and unrelated context to be set up. While unit tests for computed properties only require the dependent properties of the computed property under test to be set up, rendering a template requires the full context for that template to be set up which might include elements that are unrelated to the current test case.
 
 ### Helpers don't always work as expected
 
-One of the main reasons that we hear why people prefer template helpers over
-computed properties is the fact that computed properties need to list their
-dependent keys. **Especially newcomers to Ember.js are afraid of forgetting a
-key or making a mistake** (especially when it comes to collections) which can
-lead to hard to track down errors (see below for a potential fix for the need to
-specify dependent keys at all). **Template helpers instead don't need to list
-dependencies and are automatically re-executed** when any of their arguments
-change. While that is true in most cases there are some edge cases where
-**helpers might actually not work as expected**.
+One of the main reasons that we hear why people prefer template helpers over computed properties is the fact that computed properties need to list their dependent keys. **Especially newcomers to Ember.js are afraid of forgetting a key or making a mistake** (especially when it comes to collections) which can lead to hard to track down errors (see below for a potential fix for the need to specify dependent keys at all). **Template helpers instead don't need to list dependencies and are automatically re-executed** when any of their arguments change. While that is true in most cases there are some edge cases where **helpers might actually not work as expected**.
 
-Consider a slightly modified version of the above example that compares the
-user's `age` property with a comparison value:
+Consider a slightly modified version of the above example that compares the user's `age` property with a comparison value:
 
 ```hbs
 {% raw %}
@@ -188,8 +129,7 @@ user's `age` property with a comparison value:
 {% endraw %}
 ```
 
-Here, the internals of the comparison logic have been moved into the `is-senior`
-helper:
+Here, the internals of the comparison logic have been moved into the `is-senior` helper:
 
 ```js
 {% raw %}
@@ -199,22 +139,11 @@ export default Ember.Helper.helper(function ([user]) {
 {% endraw %}
 ```
 
-The problem with this solution is that the DOM does not get updated when the
-user's `age` property changes. While arguments that are passed to helpers are
-observed by Ember automatically and the **helper will be re-executed when any of
-these arguments change to a different value, the same is not true when any
-property on any of the arguments changes**. In this case changes of the user's
-`age` property would go unnoticed and the DOM would get out of sync with the
-underlying data.
+The problem with this solution is that the DOM does not get updated when the user's `age` property changes. While arguments that are passed to helpers are observed by Ember automatically and the **helper will be re-executed when any of these arguments change to a different value, the same is not true when any property on any of the arguments changes**. In this case changes of the user's `age` property would go unnoticed and the DOM would get out of sync with the underlying data.
 
 ### Performance
 
-In general, **performance should be more or less on par for computed properties
-and template helpers** in comparable scenarios. There's one slight difference
-though in the way that helpers and computed properties work that can have
-relevant performance implications though: **all arguments passed to helpers are
-eagerly evaluated before the helper function is invoked**. This is a major
-difference compared to computed properties actually.
+In general, **performance should be more or less on par for computed properties and template helpers** in comparable scenarios. There's one slight difference though in the way that helpers and computed properties work that can have relevant performance implications though: **all arguments passed to helpers are eagerly evaluated before the helper function is invoked**. This is a major difference compared to computed properties actually.
 
 Consider this example:
 
@@ -226,9 +155,7 @@ Consider this example:
 {% endraw %}
 ```
 
-Here, both `propA` and `propB` will be eagerly evaluated before being passed to
-the `and` helper. Comparing this to the same logic implemented as a computed
-property makes the difference clear:
+Here, both `propA` and `propB` will be eagerly evaluated before being passed to the `and` helper. Comparing this to the same logic implemented as a computed property makes the difference clear:
 
 ```js
 {% raw %}
@@ -238,76 +165,29 @@ areBothTruthy: computed('propA', 'propB', function () {
 {% endraw %}
 ```
 
-As the `&&` operator will actually short-circuit execution when
-`this.get('propA')` is false, `this.get('propB')` will never be evaluated in
-these cases while both properties will always be eagerly evaluated when using a
-helper. If calculating `propB` is a costly operation that is obviously not
-desirable but something that cannot actually be prevented with template helpers.
+As the `&&` operator will actually short-circuit execution when `this.get('propA')` is false, `this.get('propB')` will never be evaluated in these cases while both properties will always be eagerly evaluated when using a helper. If calculating `propB` is a costly operation that is obviously not desirable but something that cannot actually be prevented with template helpers.
 
 ## Pick one
 
-As shown above there are many cases in which either computed properties or
-template helpers can be used to implement the same functionality. There are
-**some drawbacks though that template helpers come with while not actually
-providing any additional value** in these scenarios.
-
-We at Mainmatter prefer computed properties over template helpers in all of our
-projects and are putting some effort in making computed properties better.
-[ember-classy-computed](https://github.com/mainmatter/ember-classy-computed) for
-example introduces a mechanism for class based computed properties that is
-actually quite similar to class based helpers. We are also currently
-[experimenting with computed properties that automatically track their dependent keys](https://github.com/mainmatter/ember-auto-computed)
-which would obviously remove a lot of complexity and eliminate people's fear to
-accidentally omit a dependency or specify a wrong one (besides that there could
-even be performance improvements as there could be less invalidations).
-
-There is also a **bunch of great computed property macro addons** like
-[ember-cpm](https://github.com/cibernox/ember-cpm) by
-[Miguel Camba](https://github.com/cibernox) and
-[ember-awesome-macros](https://github.com/kellyselden/ember-awesome-macros) and
-[ember-macro-helpers](https://github.com/kellyselden/ember-macro-helpers) by
-[Kelly Selden](https://github.com/kellyselden) who has done a lot of great work
-making computed properties easier accessible and more powerful recently. Check
-out
-[Kelly's talk on computed properties he gave at the recent Ember.js SF meetup](http://slides.com/kellyselden/the-world-of-ember-macros-and-how-to-create-your-own-2#/43).
+As shown above there are many cases in which either computed properties or template helpers can be used to implement the same functionality. There are **some drawbacks though that template helpers come with while not actually providing any additional value** in these scenarios.
+
+We at Mainmatter prefer computed properties over template helpers in all of our projects and are putting some effort in making computed properties better. [ember-classy-computed](https://github.com/mainmatter/ember-classy-computed) for example introduces a mechanism for class based computed properties that is actually quite similar to class based helpers. We are also currently [experimenting with computed properties that automatically track their dependent keys](https://github.com/mainmatter/ember-auto-computed) which would obviously remove a lot of complexity and eliminate people's fear to accidentally omit a dependency or specify a wrong one (besides that there could even be performance improvements as there could be less invalidations).
+
+There is also a **bunch of great computed property macro addons** like [ember-cpm](https://github.com/cibernox/ember-cpm) by [Miguel Camba](https://github.com/cibernox) and [ember-awesome-macros](https://github.com/kellyselden/ember-awesome-macros) and [ember-macro-helpers](https://github.com/kellyselden/ember-macro-helpers) by [Kelly Selden](https://github.com/kellyselden) who has done a lot of great work making computed properties easier accessible and more powerful recently. Check out [Kelly's talk on computed properties he gave at the recent Ember.js SF meetup](http://slides.com/kellyselden/the-world-of-ember-macros-and-how-to-create-your-own-2#/43).
 
 ### Pure Functions
 
-One thing I hear a lot is that template helpers are better than computed
-properties because helpers are (supposed to be) pure functions. While **pure
-functions are great** and helpers are (unless you make a mistake) pure
-functions, **computed properties are actually pure functions as well** so this
-is not something that speaks for either of the alternatives.
-
-For some context: a pure function is a function that only depends on its inputs
-and will return the same value for the same inputs each time it is called. A
-pure function also has no side effects. While this is true for helpers it is
-obviously true for computed properties with the only distinction that **a
-computed property's inputs are called its dependent keys**. Of course there's
-also class based helpers whose whole purpose is to enable template helpers that
-can depend on global state and thus are not pure functions (and the same concept
-exists for computed properties with ember-classy-computed now).
+One thing I hear a lot is that template helpers are better than computed properties because helpers are (supposed to be) pure functions. While **pure functions are great** and helpers are (unless you make a mistake) pure functions, **computed properties are actually pure functions as well** so this is not something that speaks for either of the alternatives.
+
+For some context: a pure function is a function that only depends on its inputs and will return the same value for the same inputs each time it is called. A pure function also has no side effects. While this is true for helpers it is obviously true for computed properties with the only distinction that **a computed property's inputs are called its dependent keys**. Of course there's also class based helpers whose whole purpose is to enable template helpers that can depend on global state and thus are not pure functions (and the same concept exists for computed properties with ember-classy-computed now).
 
 ### Original concerns of the template layer
 
-The intention of this post is not to say template helpers are bad and computed
-properties should be used for everything. That would be a pretty ignorant
-statement to make. **There are original concerns of the template layer that are
-best implemented in helpers** - typical examples being translating strings,
-formatting numbers or dates etc. We use template helpers almost exclusively for
-this kind of functionality which is usually only a small part part of any
-application though - we often only have a few helpers defined even in pretty big
-and involved applications.
+The intention of this post is not to say template helpers are bad and computed properties should be used for everything. That would be a pretty ignorant statement to make. **There are original concerns of the template layer that are best implemented in helpers** - typical examples being translating strings, formatting numbers or dates etc. We use template helpers almost exclusively for this kind of functionality which is usually only a small part part of any application though - we often only have a few helpers defined even in pretty big and involved applications.
 
 ### Missing a property context
 
-There is one slightly more evolved scenario where computed properties cannot
-easily be used instead of template helpers to achieve the same functionality.
-That is when there is **no context the computed property could be defined on or
-the context it would be needed on is unrelated to the template context**. One
-example for this is a component that renders a list of items and keeps track of
-which of these items is currently selected. The easiest way to do something like
-that using template helpers would look something like this:
+There is one slightly more evolved scenario where computed properties cannot easily be used instead of template helpers to achieve the same functionality. That is when there is **no context the computed property could be defined on or the context it would be needed on is unrelated to the template context**. One example for this is a component that renders a list of items and keeps track of which of these items is currently selected. The easiest way to do something like that using template helpers would look something like this:
 
 ```hbs
 {% raw %}
@@ -319,14 +199,9 @@ that using template helpers would look something like this:
 {% endraw %}
 ```
 
-This isn't as straight forward to replace with a computed property as the
-previous examples. While defining an `isSelected` property on the template
-context isn't possible as the property is needed per item in the list, the
-property can also not be defined on the items as the items have no notion of the
-list component or how that keeps track of the selected element at all.
+This isn't as straight forward to replace with a computed property as the previous examples. While defining an `isSelected` property on the template context isn't possible as the property is needed per item in the list, the property can also not be defined on the items as the items have no notion of the list component or how that keeps track of the selected element at all.
 
-The solution to this problem is to construct a new context that has access to
-both the item as well as the component:
+The solution to this problem is to construct a new context that has access to both the item as well as the component:
 
 ```js
 {% raw %}
@@ -342,8 +217,7 @@ _listItems: computed('items.[]', 'selectedItem', function() {
 {% endraw %}
 ```
 
-The template iterates over this wrapper collection instead of the original
-collection then:
+The template iterates over this wrapper collection instead of the original collection then:
 
 ```hbs
 {% raw %}
@@ -355,21 +229,10 @@ collection then:
 {% endraw %}
 ```
 
-This pattern - **defining a wrapper context that combines two or more other
-contexts** - should work in similar scenarios as well.
+This pattern - **defining a wrapper context that combines two or more other contexts** - should work in similar scenarios as well.
 
 ## Conclusion
 
-Computed properties and template helpers are both valuable parts of the Ember
-framework and **both have their use cases**. Being aware of which one is best
-suited for which use case and what the consequences and drawbacks are when
-picking either one is crucial for **preventing long term maintainability
-issues**.
-
-Computed properties are powerful already and will continue to improve with tools
-like [ember-cpm](https://github.com/cibernox/ember-cpm),
-[ember-awesome-macros](https://github.com/kellyselden/ember-awesome-macros),
-[ember-macro-helpers](https://github.com/kellyselden/ember-macro-helpers) and
-eventually perhaps computed properties that automatically track their
-dependencies. Before turning towards a seemingly easier alternative, have a
-close look at the consequences of your decision though.
+Computed properties and template helpers are both valuable parts of the Ember framework and **both have their use cases**. Being aware of which one is best suited for which use case and what the consequences and drawbacks are when picking either one is crucial for **preventing long term maintainability issues**.
+
+Computed properties are powerful already and will continue to improve with tools like [ember-cpm](https://github.com/cibernox/ember-cpm), [ember-awesome-macros](https://github.com/kellyselden/ember-awesome-macros), [ember-macro-helpers](https://github.com/kellyselden/ember-macro-helpers) and eventually perhaps computed properties that automatically track their dependencies. Before turning towards a seemingly easier alternative, have a close look at the consequences of your decision though.
diff --git a/src/posts/2017-08-28-creating-web-components-with-glimmer.md b/src/posts/2017-08-28-creating-web-components-with-glimmer.md
index 4cea44293f..e36aac6aca 100644
--- a/src/posts/2017-08-28-creating-web-components-with-glimmer.md
+++ b/src/posts/2017-08-28-creating-web-components-with-glimmer.md
@@ -2,32 +2,19 @@
 title: Creating Web Components with Glimmer
 authorHandle: jjordan_dev
 bio: "Senior Frontend Engineer, Ember Learning core team member"
-description:
-  "Jessica Jordan explains what web components (aka custom elements) are and
-  shows how they can be built using Glimmer.js."
+description: "Jessica Jordan explains what web components (aka custom elements) are and shows how they can be built using Glimmer.js."
 tags: ember
 tagline: |
   <p>At <a href="https://youtu.be/TEuY4GqwrUE?t=58m43s">this year's EmberConf the Ember core team officially announced</a> the release of <a href="https://glimmerjs.com/">Glimmer</a> - a light-weight JavaScript library aimed to provide a useful toolset for <strong>creating fast and reusable UI components</strong>. Powered by the already battle-tested Ember-CLI, developers can build their Glimmer apps in an easy and efficient manner as they already came to love building applications in Ember.js before.</p>
 ---
 
-In addition to building standalone Glimmer applications, the library allows the
-creation of components **according to the Custom Elements v1 specification**,
-making it possible to build native web components which can be reused across all
-kinds of front end stacks.
+In addition to building standalone Glimmer applications, the library allows the creation of components **according to the Custom Elements v1 specification**, making it possible to build native web components which can be reused across all kinds of front end stacks.
 
 ## What's in the Custom Elements v1 specification
 
-The **Custom Elements spec** describes a technology which is - alongside of HTML
-templates, Shadow DOM and HTML imports - an integral part of the
-[current Web Component specification](https://www.w3.org/wiki/WebComponents/).
-The Custom Elements spec describes capabilities for creating custom HTML
-elements which can be used just like native HTML elements: `<my-customelement>`.
+The **Custom Elements spec** describes a technology which is - alongside of HTML templates, Shadow DOM and HTML imports - an integral part of the [current Web Component specification](https://www.w3.org/wiki/WebComponents/). The Custom Elements spec describes capabilities for creating custom HTML elements which can be used just like native HTML elements: `<my-customelement>`.
 
-The
-[current version of this specification](https://www.w3.org/TR/custom-elements/)
-defines a `CustomElementRegistry` interface global which is available as the
-`customElements` global in the browser. Custom elements are based on extensions
-of the native `HTMLElement` base class:
+The [current version of this specification](https://www.w3.org/TR/custom-elements/) defines a `CustomElementRegistry` interface global which is available as the `customElements` global in the browser. Custom elements are based on extensions of the native `HTMLElement` base class:
 
 ```js
 {% raw %}
@@ -37,9 +24,7 @@ class CustomElementClass extends HTMLElement {
 {% endraw %}
 ```
 
-The `CustomElementRegistry`'s `define` method can subsequently be used to
-register custom elements, e.g. a custom element named `my-customelement`, would
-be registered as follows:
+The `CustomElementRegistry`'s `define` method can subsequently be used to register custom elements, e.g. a custom element named `my-customelement`, would be registered as follows:
 
 ```js
 {% raw %}
@@ -51,8 +36,7 @@ customElements.define('my-customelement', CustomElementClass);
 {% endraw %}
 ```
 
-Finally, a custom element that has been registered via the
-`CustomElementRegistry` can simply be used anywhere in HTML like any other tag:
+Finally, a custom element that has been registered via the `CustomElementRegistry` can simply be used anywhere in HTML like any other tag:
 
 ```html
 <!doctype html>
@@ -67,81 +51,39 @@ Finally, a custom element that has been registered via the
 </html>
 ```
 
-Being able to encapsulate functionality this way and to be able to reuse it via
-HTML markup is powerful for several reasons:
-
-First, it enables usage of these components **beyond the boundaries of a single
-front-end tech stack**, including the diverse set of client-side JavaScript
-frameworks out there. Imagine being able to develop a menu header once and to
-reuse it across all the different applications that are built in the scope of
-your project, no matter if these applications were built upon React or Ember.
-This also furthers even greater efforts to create well-maintained and highly
-flexible widgets, not only on a project's or company's scale, but also in terms
-of open-source as an even greater community of developers will be interested in
-creating and using that e.g. one well-built `date-picker` component. Imagine if
-the community behind the `ember-power-datepicker`, `react-datepicker`,
-`angular-datepicker` and others could funnel their work into creating one
-component that is of great benefit to all of these JavaScript communities at
-once.
-
-Second, the **standalone and self-contained** nature of web components creates
-an API, that is not only straight-forward to use, but is also easy to reason
-about; a well-structured web component will bring in all the dependencies needed
-for its core functionality and will be configured - if needed at all - with
-string based HTML attributes alone - making the final **mark up** very
-**descriptive**. Advanced users will still be able to configure additional, more
-specific functionality, as e.g. event listeners, via JavaScript themselves on
-top of that.
-
-Third, using web components is very easy as only **knowledge of the HTML markup
-language is required** to do so. Using the basic and likely most well-known
-language of the web alone, it **empowers an even larger community of
-developers** to build their websites and web apps with and upon web components.
+Being able to encapsulate functionality this way and to be able to reuse it via HTML markup is powerful for several reasons:
+
+First, it enables usage of these components **beyond the boundaries of a single front-end tech stack**, including the diverse set of client-side JavaScript frameworks out there. Imagine being able to develop a menu header once and to reuse it across all the different applications that are built in the scope of your project, no matter if these applications were built upon React or Ember. This also furthers even greater efforts to create well-maintained and highly flexible widgets, not only on a project's or company's scale, but also in terms of open-source as an even greater community of developers will be interested in creating and using that e.g. one well-built `date-picker` component. Imagine if the community behind the `ember-power-datepicker`, `react-datepicker`, `angular-datepicker` and others could funnel their work into creating one component that is of great benefit to all of these JavaScript communities at once.
+
+Second, the **standalone and self-contained** nature of web components creates an API, that is not only straight-forward to use, but is also easy to reason about; a well-structured web component will bring in all the dependencies needed for its core functionality and will be configured - if needed at all - with string based HTML attributes alone - making the final **mark up** very **descriptive**. Advanced users will still be able to configure additional, more specific functionality, as e.g. event listeners, via JavaScript themselves on top of that.
+
+Third, using web components is very easy as only **knowledge of the HTML markup language is required** to do so. Using the basic and likely most well-known language of the web alone, it **empowers an even larger community of developers** to build their websites and web apps with and upon web components.
 
 Let’s now dive into how we can create our own custom elements using Glimmer.
 
 ## Glimmer Web Component Example: A Reusable Open Street Map
 
-A common use case for a reusable component is the interactive view of a street
-map which usually can be embedded into websites and apps quickly with some
-configuration using services like the Google Maps API or Leaflet. What if we
-could create our own custom element that can simply be shared and reused using
-HTML alone?
+A common use case for a reusable component is the interactive view of a street map which usually can be embedded into websites and apps quickly with some configuration using services like the Google Maps API or Leaflet. What if we could create our own custom element that can simply be shared and reused using HTML alone?
 
-In the following we will **create a simple street map** based on
-[Leaflet.js](http://leafletjs.com/) which can be re-used as such a custom
-element in any other application or static website:
+In the following we will **create a simple street map** based on [Leaflet.js](http://leafletjs.com/) which can be re-used as such a custom element in any other application or static website:
 
 ![Screenshot of Final Glimmer Map Component Example - Open Street Map View Centered on Munich](/assets/images/posts/2017-08-30-creating-web-components-with-glimmer/glimmer-map-screenshot-final.jpg#@1200-2400)
 
-You can also check out the project on
-[Github](https://github.com/jessica-jordan/glimmer-map).
+You can also check out the project on [Github](https://github.com/jessica-jordan/glimmer-map).
 
 ### Starting a new Glimmer Web Component Project
 
-To get started with an initial, running project setup, we will be using
-[Ember CLI](https://ember-cli.com/) for scaffolding and configuration of our
-Glimmer app. From `ember-cli@2.14.0` onwards, we can get started to create a
-Glimmer-backed web component by using the `ember new` generator, the
-[respective glimmer blueprint](https://github.com/glimmerjs/glimmer-blueprint)
-and the `--web-component` flag:
+To get started with an initial, running project setup, we will be using [Ember CLI](https://ember-cli.com/) for scaffolding and configuration of our Glimmer app. From `ember-cli@2.14.0` onwards, we can get started to create a Glimmer-backed web component by using the `ember new` generator, the [respective glimmer blueprint](https://github.com/glimmerjs/glimmer-blueprint) and the `--web-component` flag:
 
 ```bash
 ember new glimmer-map -b @glimmer/blueprint --web-component
 ```
 
-generating the needed scaffolding for our first Glimmer app. As soon as the
-Glimmer app is booted up via a simple `ember serve` and we navigate to the
-typical `http://localhost:4200`, we will find that our first component project
-is already rendered with a "Welcome to Glimmer!" headline:
+generating the needed scaffolding for our first Glimmer app. As soon as the Glimmer app is booted up via a simple `ember serve` and we navigate to the typical `http://localhost:4200`, we will find that our first component project is already rendered with a "Welcome to Glimmer!" headline:
 
 ![Screenshot of First Page of a New Glimmer App - Headline: Hello Glimmer!](/assets/images/posts/2017-08-30-creating-web-components-with-glimmer/glimmer-map-startup.png#@1200-2400)
 
-Let's have a look at our project's file structure as well; following the new
-folder structure planned out in the
-[module unification RFC](https://github.com/emberjs/rfcs/pull/143) we can
-already find our `component.ts` and `template.hbs` files for creating our
-component co-located in the same directory below the `src` directory:
+Let's have a look at our project's file structure as well; following the new folder structure planned out in the [module unification RFC](https://github.com/emberjs/rfcs/pull/143) we can already find our `component.ts` and `template.hbs` files for creating our component co-located in the same directory below the `src` directory:
 
 ```
 src
@@ -161,13 +103,7 @@ src
     └── test-helper.ts
 ```
 
-Having a closer look at the app setup in
-`glimmer-web-component/src/initialize-custom-elements.ts`, we can see how the
-Glimmer app is started up and rendered as a custom element. Under the hood,
-Glimmer’s `renderComponent` API is taking care of initial setup and rendering of
-the component into the aforementioned placeholder in the DOM and the
-`initializeCustomElements` API for registering the component as a native custom
-element:
+Having a closer look at the app setup in `glimmer-web-component/src/initialize-custom-elements.ts`, we can see how the Glimmer app is started up and rendered as a custom element. Under the hood, Glimmer’s `renderComponent` API is taking care of initial setup and rendering of the component into the aforementioned placeholder in the DOM and the `initializeCustomElements` API for registering the component as a native custom element:
 
 ```ts
 function initializeCustomElement(app: Application, name: string): void {
@@ -195,21 +131,13 @@ function initializeCustomElement(app: Application, name: string): void {
 }
 ```
 
-The final line makes use of the `CustomElementRegistry`'s `define` method to
-register the `GlimmerElement` class as a custom element, just as we expect it
-from the Custom Elements specification. Interesting to note here as well is the
-call to the `assignAttributes` method, ensuring that any top-level attributes
-defined on our custom element are later on also mapped to attributes on our
-rendered Glimmer component.
+The final line makes use of the `CustomElementRegistry`'s `define` method to register the `GlimmerElement` class as a custom element, just as we expect it from the Custom Elements specification. Interesting to note here as well is the call to the `assignAttributes` method, ensuring that any top-level attributes defined on our custom element are later on also mapped to attributes on our rendered Glimmer component.
 
-So, after having that quick dive into how our component is spun up in Glimmer,
-let’s get started developing it:
+So, after having that quick dive into how our component is spun up in Glimmer, let’s get started developing it:
 
 ### Developing a Web Component with Glimmer's API
 
-So far the blueprint for our main component module has already been setup by
-Ember CLI's generator. The class used for generating our `glimmer-map` component
-is now defined in `src/ui/components/glimmer-map/component.ts`:
+So far the blueprint for our main component module has already been setup by Ember CLI's generator. The class used for generating our `glimmer-map` component is now defined in `src/ui/components/glimmer-map/component.ts`:
 
 ```ts
 // src/ui/components/glimmer-map/component.ts
@@ -218,21 +146,13 @@ import Component from "@glimmer/component";
 export default class GlimmerMap extends Component {}
 ```
 
-As we would like to create a map based on `Leaflet.js`, let's also get that
-dependency installed in our project:
+As we would like to create a map based on `Leaflet.js`, let's also get that dependency installed in our project:
 
 ```bash
 yarn add --dev leaflet
 ```
 
-Similar to many other npm packages that you will find out there, the Leaflet
-dependency exports its internals via **the CommonJS module** syntax. Since the
-[glimmer-application-pipeline](https://github.com/glimmerjs/glimmer-application-pipeline)
-only supports the import of modules following the ES6 syntax out of the box, we
-can make ends meet by configuring rollup in our `ember-cli-build.js` as
-[also seen in the glimmer-application-pipeline documentation](https://github.com/glimmerjs/glimmer-application-pipeline#importing-commonjs-modules)
-and install the `rollup-plugin-node-resolve` and `rollup-plugin-commonjs`
-dependencies:
+Similar to many other npm packages that you will find out there, the Leaflet dependency exports its internals via **the CommonJS module** syntax. Since the [glimmer-application-pipeline](https://github.com/glimmerjs/glimmer-application-pipeline) only supports the import of modules following the ES6 syntax out of the box, we can make ends meet by configuring rollup in our `ember-cli-build.js` as [also seen in the glimmer-application-pipeline documentation](https://github.com/glimmerjs/glimmer-application-pipeline#importing-commonjs-modules) and install the `rollup-plugin-node-resolve` and `rollup-plugin-commonjs` dependencies:
 
 ```bash
 yarn add --dev rollup-plugin-node-resolve
@@ -274,9 +194,7 @@ import L from "leaflet";
 export default class GlimmerMap extends Component {}
 ```
 
-Now for creating and rendering the map, let's use the component's
-`didInsertElement` lifecycle hook to ensure that the Glimmer component has been
-inserted into the DOM already before the map instance is created and rendered:
+Now for creating and rendering the map, let's use the component's `didInsertElement` lifecycle hook to ensure that the Glimmer component has been inserted into the DOM already before the map instance is created and rendered:
 
 ```ts
 // src/ui/components/glimmer-map/component.ts
@@ -320,11 +238,7 @@ With this setup, our map already renders for the map points set intially:
 
 ![Screenshot of Open Street Map View of First Pass on the Glimmer Map Component](/assets/images/posts/2017-08-30-creating-web-components-with-glimmer/glimmer-map-screenshot.jpg#@1200-2400)
 
-We also aim to make our map respond to user input. Specifically, we would like
-to be able to set the marker to different locations on the map using a property
-for the longitude (`lon`) and the latitude (`lat`) easily. To allow any property
-changes to be reflected in the component's DOM, we can make use of the
-`@tracked` decorator:
+We also aim to make our map respond to user input. Specifically, we would like to be able to set the marker to different locations on the map using a property for the longitude (`lon`) and the latitude (`lat`) easily. To allow any property changes to be reflected in the component's DOM, we can make use of the `@tracked` decorator:
 
 ```ts
 // src/ui/components/glimmer-map/component.ts
@@ -338,9 +252,7 @@ export default class GlimmerMap extends Component {
 }
 ```
 
-Anytime there is a change to one of the tracked properties' values, a re-render
-of the component with a newly updated DOM will follow. And promote the changes
-to these properties via actions by updating our template
+Anytime there is a change to one of the tracked properties' values, a re-render of the component with a newly updated DOM will follow. And promote the changes to these properties via actions by updating our template
 
 ```hbs
 {% raw %}
@@ -387,27 +299,17 @@ export default class GlimmerMap extends Component {
 }
 ```
 
-With this we are already done and can get started with distributing our
-component.
+With this we are already done and can get started with distributing our component.
 
 ## Reusing Glimmer components as custom elements
 
-As mentioned in the beginning of this article, the current blueprint for Glimmer
-web components comes with a wrapper for being able to package and reuse our
-Glimmer components as custom elements. To **create the assets** needed for
-reusage, let’s build those like we are already used to when building Ember apps:
+As mentioned in the beginning of this article, the current blueprint for Glimmer web components comes with a wrapper for being able to package and reuse our Glimmer components as custom elements. To **create the assets** needed for reusage, let’s build those like we are already used to when building Ember apps:
 
 ```bash
 ember build --production
 ```
 
-This will store all the assets needed for reusing our custom element in the
-`/dist` directory of the project. For our example, only the `app.js` file has to
-be copied to be reused in our target app where we would like to use the
-`glimmer-map` web component. Adding in the external stylesheet for the styles of
-our map, as well as a
-[polyfill for ensuring cross-browser support for all custom element features](https://github.com/webcomponents/webcomponentsjs)
-finalizes our example:
+This will store all the assets needed for reusing our custom element in the `/dist` directory of the project. For our example, only the `app.js` file has to be copied to be reused in our target app where we would like to use the `glimmer-map` web component. Adding in the external stylesheet for the styles of our map, as well as a [polyfill for ensuring cross-browser support for all custom element features](https://github.com/webcomponents/webcomponentsjs) finalizes our example:
 
 ```html
 // your/other/app/template/or/plain/html/page.html
@@ -430,8 +332,7 @@ finalizes our example:
 </html>
 ```
 
-And finally, we can see our Glimmer-based street map being rendered just as seen
-below:
+And finally, we can see our Glimmer-based street map being rendered just as seen below:
 
 <script src="https://cdnjs.cloudflare.com/ajax/libs/webcomponentsjs/1.0.8/webcomponents-lite.js"></script>
 <link rel="stylesheet" href="https://unpkg.com/leaflet@1.2.0/dist/leaflet.css"
@@ -441,12 +342,4 @@ below:
 
 ## And the Glimmer Component story is not over yet
 
-Many more interesting developments are upcoming around Glimmer and the
-[glimmer-component](https://github.com/glimmerjs/glimmer-component) and
-[glimmer-web-component](https://github.com/glimmerjs/glimmer-web-component)
-modules specifically. For further reading, please check out another great
-discussion about the implementation of upcoming APIs according to the web
-component specification on
-[here](https://github.com/glimmerjs/glimmer-web-component/issues/19), check out
-[my talk on current state of web components and Glimmer’s place in it](https://www.youtube.com/watch?v=OzFgDBJcWuU)
-and stay tuned for our future blog post on testing Glimmer components.
+Many more interesting developments are upcoming around Glimmer and the [glimmer-component](https://github.com/glimmerjs/glimmer-component) and [glimmer-web-component](https://github.com/glimmerjs/glimmer-web-component) modules specifically. For further reading, please check out another great discussion about the implementation of upcoming APIs according to the web component specification on [here](https://github.com/glimmerjs/glimmer-web-component/issues/19), check out [my talk on current state of web components and Glimmer’s place in it](https://www.youtube.com/watch?v=OzFgDBJcWuU) and stay tuned for our future blog post on testing Glimmer components.
diff --git a/src/posts/2017-09-17-magic-test-data.md b/src/posts/2017-09-17-magic-test-data.md
index d5d8e5b85a..e50201037f 100644
--- a/src/posts/2017-09-17-magic-test-data.md
+++ b/src/posts/2017-09-17-magic-test-data.md
@@ -2,16 +2,13 @@
 title: Magic Data in Tests
 authorHandle: geekygrappler
 bio: "Senior Frontend Engineer"
-description:
-  "Andy Brown explains the AAA principle for writing good tests and discusses
-  what the negative consequences of not adhering to it are."
+description: "Andy Brown explains the AAA principle for writing good tests and discusses what the negative consequences of not adhering to it are."
 tags: misc
 tagline: |
   <p>Often when working on large codebases, my changes break some existing tests. While I would prefer my coding to be perfect, it's highly unlikely that I'll ever achieve the state of coding zen, so it's nice to know I have a test suite to catch me when I fall. Given that the codebase is large and in the majority not written by me, I tend to be introduced to code via the test files. One important principle I've started to follow when writing and refactoring tests is AAA.</p>
 ---
 
-The [AAA principle](http://wiki.c2.com/?ArrangeActAssert) for testing is Arrange
-Act Assert and it's Amazing. The TL;DR is:
+The [AAA principle](http://wiki.c2.com/?ArrangeActAssert) for testing is Arrange Act Assert and it's Amazing. The TL;DR is:
 
 - Setup the data/inputs for the code you're testing (Arrange)
 - Invoke the code you are testing (Act)
@@ -36,13 +33,11 @@ test('toLowerCase makes string all lower case', function (assert) {
 
 If you have a test that doesn't Arrange, your test may be brittle.
 
-Don't believe me? Lets go through a real life example. You are tasked with
-making a country/language picker for a website that looks something like this.
+Don't believe me? Lets go through a real life example. You are tasked with making a country/language picker for a website that looks something like this.
 
 ![Country picker component](/assets/images/posts/2017-09-25-magic-test-data/tl-country-picker.png)
 
-You will probably have a hardcoded list of countries that your website supports
-somewhere in your app.
+You will probably have a hardcoded list of countries that your website supports somewhere in your app.
 
 ```js
 {% raw %}
@@ -64,11 +59,9 @@ export default [
 {% endraw %}
 ```
 
-We need to write a function that adds a url pointing to an image of the country
-flag so that the component can display that flag image.
+We need to write a function that adds a url pointing to an image of the country flag so that the component can display that flag image.
 
-So we write a component, here we're using Ember, but the principle is similar
-for any JS framework or vanilla JS.
+So we write a component, here we're using Ember, but the principle is similar for any JS framework or vanilla JS.
 
 ```js
 {% raw %}
@@ -109,8 +102,7 @@ I don't think it's a good test though.
 
 <strong>The test is brittle.</strong>
 
-Let's say our business development team have made inroads into Bulgaria and now
-we need to add it to the the list of countries and locales.
+Let's say our business development team have made inroads into Bulgaria and now we need to add it to the the list of countries and locales.
 
 ```js
 {% raw %}
@@ -138,19 +130,11 @@ export default [
 {% endraw %}
 ```
 
-The test will now fail without us having changed the code. No code change, no
-behaviour change, but failing tests. The definition of a brittle test. The test
-relies on magic data from an external file, namely `COUNTRIES`. It may only take
-the original writer of the test minutes to figure out why the test fails, but it
-might take any one new to the code unit a bit longer to figure out why.
+The test will now fail without us having changed the code. No code change, no behaviour change, but failing tests. The definition of a brittle test. The test relies on magic data from an external file, namely `COUNTRIES`. It may only take the original writer of the test minutes to figure out why the test fails, but it might take any one new to the code unit a bit longer to figure out why.
 
-What you should do is _Arrange_ the data. When you do this it becomes clear that
-the function is simply adding a key, and it won't break due to external data
-changes. All you care about is that given a starting set of data, after applying
-your function you get the resultant set of data, as clearly defined in the test.
+What you should do is _Arrange_ the data. When you do this it becomes clear that the function is simply adding a key, and it won't break due to external data changes. All you care about is that given a starting set of data, after applying your function you get the resultant set of data, as clearly defined in the test.
 
-First we need to stop using a constant directly in our component. This way we
-can override the `countries` property in the test and _arrange_ the data.
+First we need to stop using a constant directly in our component. This way we can override the `countries` property in the test and _arrange_ the data.
 
 ```js
 {% raw %}
@@ -205,8 +189,7 @@ test('displayCountries will add a flag key to a country object', function (asser
 {% endraw %}
 ```
 
-I feel much better about this test. It is no longer brittle as it's not
-dependent on an external `JSON` file.
+I feel much better about this test. It is no longer brittle as it's not dependent on an external `JSON` file.
 
 And I get to commit GoT & LOTR to the code base.
 
diff --git a/src/posts/2017-10-24-high-level-assertions-with-qunit-dom.md b/src/posts/2017-10-24-high-level-assertions-with-qunit-dom.md
index c058d0564a..fb1410e040 100644
--- a/src/posts/2017-10-24-high-level-assertions-with-qunit-dom.md
+++ b/src/posts/2017-10-24-high-level-assertions-with-qunit-dom.md
@@ -2,17 +2,13 @@
 title: High Level Assertions with qunit-dom
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek introduces qunit-dom, an extension for qunit that allows
-  writing more expressive and less complex UI tests using high level DOM
-  assertions."
+description: "Tobias Bieniek introduces qunit-dom, an extension for qunit that allows writing more expressive and less complex UI tests using high level DOM assertions."
 tags: javascript
 tagline: |
   <p>At <a href="https://emberfest.eu/">EmberFest</a> this year we presented and released <a href="https://github.com/mainmatter/qunit-dom"><code>qunit-dom</code></a>. A plugin for <a href="https://qunitjs.com/">QUnit</a> providing High Level DOM Assertions with the goal to reduce test complexity for all QUnit users. This blog post will show you how to write simpler tests using <code>async/await</code> and <code>qunit-dom</code>.</p>
 ---
 
-As an introduction to what this means let's start with an example template for
-an Ember app that we will write a test for:
+As an introduction to what this means let's start with an example template for an Ember app that we will write a test for:
 
 ```handlebars
 {% raw %}
@@ -27,8 +23,7 @@ an Ember app that we will write a test for:
 {% endraw %}
 ```
 
-From the template above you can see that we have essentially two states that we
-need to test: one with and one without a `username` property being set.
+From the template above you can see that we have essentially two states that we need to test: one with and one without a `username` property being set.
 
 ## Status Quo
 
@@ -57,22 +52,13 @@ test('frontpage should be welcoming', function (assert) {
 {% endraw %}
 ```
 
-First we will `visit` the index page `andThen` check if the welcome message
-matches our expectation. Next we will `fill` an `<input>` field with a custom
-`username` like "John Doe" `andThen` finally we will check if the welcome
-message was updated correctly.
+First we will `visit` the index page `andThen` check if the welcome message matches our expectation. Next we will `fill` an `<input>` field with a custom `username` like "John Doe" `andThen` finally we will check if the welcome message was updated correctly.
 
 ## Promise chains
 
-If you've used [Ember.js](https://emberjs.com/) for some time you will probably
-be used to the `andThen` blocks above. One of the reasons for them to exist is
-that Ember.js is older than the `Promise` implementation that came with ES6 and
-before that existed there was already a need for handling async behavior in
-tests.
+If you've used [Ember.js](https://emberjs.com/) for some time you will probably be used to the `andThen` blocks above. One of the reasons for them to exist is that Ember.js is older than the `Promise` implementation that came with ES6 and before that existed there was already a need for handling async behavior in tests.
 
-Since Ember.js has kept up very well with the latest developments in JavaScript
-you can also use a `Promise` chain instead of the `andThen` blocks which would
-look like this:
+Since Ember.js has kept up very well with the latest developments in JavaScript you can also use a `Promise` chain instead of the `andThen` blocks which would look like this:
 
 ```js
 {% raw %}
@@ -95,28 +81,17 @@ test('frontpage should be welcoming', function (assert) {
 {% endraw %}
 ```
 
-While that code makes it more obvious that we are dealing with asynchronous code
-here, it also make the code a little harder to read. Which is one of the reasons
-why a lot of Ember developers still prefer the `andThen` blocks over using
-`Promise` chains.
+While that code makes it more obvious that we are dealing with asynchronous code here, it also make the code a little harder to read. Which is one of the reasons why a lot of Ember developers still prefer the `andThen` blocks over using `Promise` chains.
 
 ## async/await
 
-In one of the recent changes to the JavaScript language (or ECMAScript to be
-precise) two new keywords were introduced to simplify dealing with `Promises`:
-`async` and `await`.
+In one of the recent changes to the JavaScript language (or ECMAScript to be precise) two new keywords were introduced to simplify dealing with `Promises`: `async` and `await`.
 
-Whenever you mark a `function` as `async` it will automatically return a
-`Promise` and once you `return` something from that function it will `resolve`
-that `Promise`. Similarly if you `throw` an error it will `reject` the
-`Promise`.
+Whenever you mark a `function` as `async` it will automatically return a `Promise` and once you `return` something from that function it will `resolve` that `Promise`. Similarly if you `throw` an error it will `reject` the `Promise`.
 
-But the real power comes with the `await` keyword that can only be used inside
-of `async` functions. Using `await` you can wait on another `Promise` before
-resolving or rejecting the `Promise` of your own `async` function.
+But the real power comes with the `await` keyword that can only be used inside of `async` functions. Using `await` you can wait on another `Promise` before resolving or rejecting the `Promise` of your own `async` function.
 
-That description was pretty abstract so let's look at an example using the
-`Promise` chain above:
+That description was pretty abstract so let's look at an example using the `Promise` chain above:
 
 ```js
 {% raw %}
@@ -137,23 +112,15 @@ test('frontpage should be welcoming', async function (assert) {
 {% endraw %}
 ```
 
-As you can see this looks a lot more readable than what we had before and almost
-like the synchronous code we usually write.
+As you can see this looks a lot more readable than what we had before and almost like the synchronous code we usually write.
 
-The assertions (the lines starting with `assert.`) however are still quite hard
-to read, and it takes a short while to figure out what the intent of that
-assertion was.
+The assertions (the lines starting with `assert.`) however are still quite hard to read, and it takes a short while to figure out what the intent of that assertion was.
 
 ## chai and chai-dom
 
-If you're using [Mocha](https://mochajs.org/) and [Chai](http://chaijs.com/) to
-write your tests, you are already used to more readable assertions since Chai
-emphasizes an "expressive language and readable style" for their assertions.
+If you're using [Mocha](https://mochajs.org/) and [Chai](http://chaijs.com/) to write your tests, you are already used to more readable assertions since Chai emphasizes an "expressive language and readable style" for their assertions.
 
-Fortunately for Chai there is a plugin called
-[`chai-dom`](https://github.com/nathanboktae/chai-dom) which provides even
-better assertions so that we could rewrite our assertions above to something
-like:
+Fortunately for Chai there is a plugin called [`chai-dom`](https://github.com/nathanboktae/chai-dom) which provides even better assertions so that we could rewrite our assertions above to something like:
 
 ```js
 {% raw %}
@@ -167,21 +134,13 @@ expect(find('h1.title')).to.have.class('has-username');
 {% endraw %}
 ```
 
-`chai-dom` is also supported by default in `ember-cli-chai`, so if you used
-`ember-cli-chai` today you only need to `npm install --save-dev chai-dom`,
-restart Ember CLI and now you can use the additional assertions that `chai-dom`
-provides.
+`chai-dom` is also supported by default in `ember-cli-chai`, so if you used `ember-cli-chai` today you only need to `npm install --save-dev chai-dom`, restart Ember CLI and now you can use the additional assertions that `chai-dom` provides.
 
 ## qunit-dom
 
-While `ember-cli-chai` also works with QUnit it is essentially just a hack and
-not really supported properly by QUnit or Chai so be careful if you're using it.
+While `ember-cli-chai` also works with QUnit it is essentially just a hack and not really supported properly by QUnit or Chai so be careful if you're using it.
 
-As we were getting more and more annoyed by the hard-to-read assertions when
-using QUnit we were starting to wonder if it would be possible to build
-something like `chai-dom` but for QUnit instead and how that would look like.
-After a bit of brainstorming we figured we would want our assertions to look
-roughly like this:
+As we were getting more and more annoyed by the hard-to-read assertions when using QUnit we were starting to wonder if it would be possible to build something like `chai-dom` but for QUnit instead and how that would look like. After a bit of brainstorming we figured we would want our assertions to look roughly like this:
 
 ```js
 {% raw %}
@@ -197,39 +156,21 @@ assert.dom('h1.title').hasClass('has-username');
 
 Compared to what we started with this:
 
-- automatically finds the correct element on the `document` (or `#ember-testing`
-  element) based on the selector passed into the `dom()` function
-- collapses whitespace according to the HTML spec to get rid of the irrelevant
-  `\n` part of the expected string
-- provides readable high level assertions for the most common checks on DOM
-  elements
+- automatically finds the correct element on the `document` (or `#ember-testing` element) based on the selector passed into the `dom()` function
+- collapses whitespace according to the HTML spec to get rid of the irrelevant `\n` part of the expected string
+- provides readable high level assertions for the most common checks on DOM elements
 
-As you might have figured out by now we've not just planned how it could look,
-we've also built and released it at <https://github.com/mainmatter/qunit-dom>.
+As you might have figured out by now we've not just planned how it could look, we've also built and released it at <https://github.com/mainmatter/qunit-dom>.
 
-One additional advantage for Ember.js users is that it automatically hooks
-itself into the build pipeline of your projects, so all you need to do is
-`ember install qunit-dom`, and then you can immediately start using it!
+One additional advantage for Ember.js users is that it automatically hooks itself into the build pipeline of your projects, so all you need to do is `ember install qunit-dom`, and then you can immediately start using it!
 
-You can find examples of what assertions are available in the
-[README](https://github.com/mainmatter/qunit-dom#qunit-dom) of the project and
-even more information in the
-[API reference](https://github.com/mainmatter/qunit-dom/blob/master/API.md).
+You can find examples of what assertions are available in the [README](https://github.com/mainmatter/qunit-dom#qunit-dom) of the project and even more information in the [API reference](https://github.com/mainmatter/qunit-dom/blob/master/API.md).
 
 ## qunit-dom-codemod
 
-During the EmberFest conference we realized that while a lot of people would
-probably appreciate what we had built, nobody would go over their thousands of
-existing assertions and rewrite them all to use `qunit-dom`. Since a lot of the
-existing assertions in our client projects followed similar patterns we figured
-it might be possible to build a
-[codemod](https://medium.com/airbnb-engineering/turbocharged-javascript-refactoring-with-codemods-b0cae8b326b9)
-that did most of the rewriting automatically for us.
+During the EmberFest conference we realized that while a lot of people would probably appreciate what we had built, nobody would go over their thousands of existing assertions and rewrite them all to use `qunit-dom`. Since a lot of the existing assertions in our client projects followed similar patterns we figured it might be possible to build a [codemod](https://medium.com/airbnb-engineering/turbocharged-javascript-refactoring-with-codemods-b0cae8b326b9) that did most of the rewriting automatically for us.
 
-After that initial thought we started working and after only a few minutes we
-already had a working proof-of-concept including passing tests. Since then we
-have put in some more work into the codemod and are happy to share it with you
-at <https://github.com/mainmatter/qunit-dom-codemod>.
+After that initial thought we started working and after only a few minutes we already had a working proof-of-concept including passing tests. Since then we have put in some more work into the codemod and are happy to share it with you at <https://github.com/mainmatter/qunit-dom-codemod>.
 
 All you need to do is install `jscodeshift` (the thing that runs the codemod):
 
@@ -245,8 +186,4 @@ jscodeshift -t https://raw.githubusercontent.com/mainmatter/qunit-dom-codemod/ma
 
 ## Conclusion
 
-Moving the tests to `async/await` and `qunit-dom` makes them a lot more readable
-and easier to understand for new developers and is just a few keystrokes away if
-you're already using Ember.js for your frontend projects. If you need help
-refactoring your tests or even your production code to be more structured and
-understandable feel free to [contact us](/contact/).
+Moving the tests to `async/await` and `qunit-dom` makes them a lot more readable and easier to understand for new developers and is just a few keystrokes away if you're already using Ember.js for your frontend projects. If you need help refactoring your tests or even your production code to be more structured and understandable feel free to [contact us](/contact/).
diff --git a/src/posts/2017-11-17-ember-test-selectors-road-to-1-0.md b/src/posts/2017-11-17-ember-test-selectors-road-to-1-0.md
index c5125766eb..885601a212 100644
--- a/src/posts/2017-11-17-ember-test-selectors-road-to-1-0.md
+++ b/src/posts/2017-11-17-ember-test-selectors-road-to-1-0.md
@@ -2,9 +2,7 @@
 title: "ember-test-selectors: The road to 1.0"
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek goes through what happened in ember-test-selectors during the
-  past year and what the roadmap towards a 1.0 release is."
+description: "Tobias Bieniek goes through what happened in ember-test-selectors during the past year and what the roadmap towards a 1.0 release is."
 tags: ember
 tagline: |
   <p>Back in January we wrote about the <a href="/blog/2017/01/13/ember-test-selectors">latest changes</a> in <a href="https://github.com/mainmatter/ember-test-selectors"><code>ember-test-selectors</code></a> and how we implemented them. Since then we adjusted a few things and this blog post should give you an idea what has happened so far and what else will happen before we feel comfortable promoting the addon to v1.0.0.</p>
@@ -20,8 +18,7 @@ In HTML it is possible to add attributes to an element that don't have a value:
 {% endraw %}
 ```
 
-In Ember.js templates the same is possible for HTML elements, but for components
-everything is a little different.
+In Ember.js templates the same is possible for HTML elements, but for components everything is a little different.
 
 ```handlebars
 {% raw %}
@@ -29,17 +26,11 @@ everything is a little different.
 {% endraw %}
 ```
 
-The above snippet does compile, but instead of setting a `data-test-user-list`
-property on the `user-list` component it will take the value of the
-`data-test-user-list` property on the parent component and pass that as a
-positional parameter to the `user-list` component.
+The above snippet does compile, but instead of setting a `data-test-user-list` property on the `user-list` component it will take the value of the `data-test-user-list` property on the parent component and pass that as a positional parameter to the `user-list` component.
 
-In v0.2.0 of `ember-test-selectors` we introduced another Handlebars AST
-transform which transforms all such valueless `data-test-foo` instances to
-`data-test-foo=true` by default.
+In v0.2.0 of `ember-test-selectors` we introduced another Handlebars AST transform which transforms all such valueless `data-test-foo` instances to `data-test-foo=true` by default.
 
-While that seems like a convenient thing, it has drawbacks and does not always
-work as expected, as you can see in the following template:
+While that seems like a convenient thing, it has drawbacks and does not always work as expected, as you can see in the following template:
 
 ```handlebars
 {% raw %}
@@ -51,13 +42,9 @@ work as expected, as you can see in the following template:
 {% endraw %}
 ```
 
-The issue here is that Handlebars expects positional parameters in front of any
-named parameters and will throw an error otherwise. It is common however to put
-the more important things first in a component invocation which conflicts with
-having to put the valueless `data-test-*` attributes first as seen above.
+The issue here is that Handlebars expects positional parameters in front of any named parameters and will throw an error otherwise. It is common however to put the more important things first in a component invocation which conflicts with having to put the valueless `data-test-*` attributes first as seen above.
 
-Due to these problems we believe it is best to be explicit about these
-attributes and always declare them with a value:
+Due to these problems we believe it is best to be explicit about these attributes and always declare them with a value:
 
 ```handlebars
 {% raw %}
@@ -65,51 +52,27 @@ attributes and always declare them with a value:
 {% endraw %}
 ```
 
-We will deprecate the usage of valueless `data-test-*` attributes on components
-in an upcoming release and remove the transform completely for the v1.0.0
-release.
+We will deprecate the usage of valueless `data-test-*` attributes on components in an upcoming release and remove the transform completely for the v1.0.0 release.
 
 ## v0.3.0: Support for Babel 6
 
-This year (2017) the Ember ecosystem finally moved from Babel 5 to Babel 6,
-which happened mostly without issues for app developers as it was just a
-dependency upgrade from `ember-cli-babel@5` to `ember-cli-babel@6`. Some app
-developers might think they are still only using Babel 5 for their app, but it
-is very likely that some of their addons are already using Babel 6 under the
-hood since all Ember addons controls their own transpilation.
+This year (2017) the Ember ecosystem finally moved from Babel 5 to Babel 6, which happened mostly without issues for app developers as it was just a dependency upgrade from `ember-cli-babel@5` to `ember-cli-babel@6`. Some app developers might think they are still only using Babel 5 for their app, but it is very likely that some of their addons are already using Babel 6 under the hood since all Ember addons controls their own transpilation.
 
-For addons that rely on Babel transforms the upgrade unfortunately was not quite
-as smooth, as the Babel transforms API had changed significantly with Babel 6.
+For addons that rely on Babel transforms the upgrade unfortunately was not quite as smooth, as the Babel transforms API had changed significantly with Babel 6.
 
-As `ember-test-selectors` relies on Babel transforms we needed to figure out a
-solution to this problem. We wanted to support both Babel 5 and Babel 6 in the
-same addon instead of having to publish two different variants of the addon each
-targeting a different Babel version.
+As `ember-test-selectors` relies on Babel transforms we needed to figure out a solution to this problem. We wanted to support both Babel 5 and Babel 6 in the same addon instead of having to publish two different variants of the addon each targeting a different Babel version.
 
-Fortunately at [EmberConf](http://emberconf.com/) in March we found a solution:
-The addon now checks the dependencies of your project and figures out which
-version of `ember-cli-babel` you use. Based on that information we inject
-different Babel transforms into the build pipeline so that we can support both
-major Babel versions with the same addon.
+Fortunately at [EmberConf](http://emberconf.com/) in March we found a solution: The addon now checks the dependencies of your project and figures out which version of `ember-cli-babel` you use. Based on that information we inject different Babel transforms into the build pipeline so that we can support both major Babel versions with the same addon.
 
 ## v0.3.4: Support for test-selectors in nested addons
 
-In April we were notified by [Luke Melia](https://github.com/lukemelia) that
-test-selectors in templates in an addon that he extracted were stripped
-unconditionally. It turned out that if `ember-test-selectors` was used as a
-nested addon some of the build logic that we had in place was not working
-properly.
+In April we were notified by [Luke Melia](https://github.com/lukemelia) that test-selectors in templates in an addon that he extracted were stripped unconditionally. It turned out that if `ember-test-selectors` was used as a nested addon some of the build logic that we had in place was not working properly.
 
-A few days later Luke provided us with a repository that reproduced his problem.
-Using his reproduction we have been able to fix the issue and it is now possible
-to also use `ember-test-selectors` as a nested addon dependency and rely on
-correct test-selector stripping depending on the build environment.
+A few days later Luke provided us with a repository that reproduced his problem. Using his reproduction we have been able to fix the issue and it is now possible to also use `ember-test-selectors` as a nested addon dependency and rely on correct test-selector stripping depending on the build environment.
 
 ## v0.3.7: Deprecation of the `testSelector` helper function
 
-A few weeks later [Kelly Selden](https://github.com/kellyselden) triggered a
-[conversation](https://github.com/mainmatter/ember-test-selectors/issues/121)
-about the `testSelector` helper function in `ember-test-selectors`.
+A few weeks later [Kelly Selden](https://github.com/kellyselden) triggered a [conversation](https://github.com/mainmatter/ember-test-selectors/issues/121) about the `testSelector` helper function in `ember-test-selectors`.
 
 The purpose of the `testSelector` function is turning:
 
@@ -129,39 +92,17 @@ let bar = '[data-test-bar="baz"]';
 {% endraw %}
 ```
 
-After discussing back and forth and coming up with
-[alternative APIs](https://github.com/mainmatter/ember-test-selectors/pull/122)
-we decided the best way forward was actually to not use any helpers at all. This
-has the advantage of not hiding the actual CSS selector that is being used and
-requiring less knowledge of how `ember-test-selectors` works to understand what
-any test code is doing.
+After discussing back and forth and coming up with [alternative APIs](https://github.com/mainmatter/ember-test-selectors/pull/122) we decided the best way forward was actually to not use any helpers at all. This has the advantage of not hiding the actual CSS selector that is being used and requiring less knowledge of how `ember-test-selectors` works to understand what any test code is doing.
 
-Following the discussion we have deprecated the `testSelector` helper function
-and will remove it before releasing v1.0.0. If you have used the function a lot
-there is a third-party
-[codemod](https://github.com/lorcan/test-selectors-codemod) that might be able
-to save you a few minutes or hours by converting the code for you automatically.
+Following the discussion we have deprecated the `testSelector` helper function and will remove it before releasing v1.0.0. If you have used the function a lot there is a third-party [codemod](https://github.com/lorcan/test-selectors-codemod) that might be able to save you a few minutes or hours by converting the code for you automatically.
 
 ## v0.3.8: Support for Ember 1.11 and 1.12
 
-Only a few weeks ago [Chris Garrett](https://github.com/pzuraq/), better known
-as @pzuraq, approached us about supporting Ember 1.11 and 1.12 in
-`ember-test-selectors`. He was working on some projects that were started in the
-early days of Ember and to be able to upgrade them confidently to a newer Ember
-version he needed to write better tests. For those tests he wanted to use
-test-selectors, but since they required a newer Ember version he was stuck in a
-vicious circle.
-
-It seemed that the main issue with Ember 1.11/1.12 support was that our template
-AST transforms were failing and as a first attempt we simply disabled them
-completely which resolved the problem. Unfortunately that meant that
-test-selectors were no longer stripped at all from the templates which did not
-seem like a good solution to us so we dug deeper.
-
-Thanks to [ember-try](https://github.com/ember-cli/ember-try) it was very fast
-and easy to try out our addon on many different Ember versions and we quickly
-discovered that the Handlebars AST had changed between Ember 1.12 and 1.13 in a
-way that caused our transforms to crash.
+Only a few weeks ago [Chris Garrett](https://github.com/pzuraq/), better known as @pzuraq, approached us about supporting Ember 1.11 and 1.12 in `ember-test-selectors`. He was working on some projects that were started in the early days of Ember and to be able to upgrade them confidently to a newer Ember version he needed to write better tests. For those tests he wanted to use test-selectors, but since they required a newer Ember version he was stuck in a vicious circle.
+
+It seemed that the main issue with Ember 1.11/1.12 support was that our template AST transforms were failing and as a first attempt we simply disabled them completely which resolved the problem. Unfortunately that meant that test-selectors were no longer stripped at all from the templates which did not seem like a good solution to us so we dug deeper.
+
+Thanks to [ember-try](https://github.com/ember-cli/ember-try) it was very fast and easy to try out our addon on many different Ember versions and we quickly discovered that the Handlebars AST had changed between Ember 1.12 and 1.13 in a way that caused our transforms to crash.
 
 The AST for a template like:
 
@@ -215,21 +156,12 @@ MustacheStatement {
 }
 ```
 
-As you can see the AST looks almost similar, but not exactly the same. In the
-end we figured out we could check if the `MustacheStatement` has a `sexpr`
-property, and in that case use the `hash` property inside of that instead.
+As you can see the AST looks almost similar, but not exactly the same. In the end we figured out we could check if the `MustacheStatement` has a `sexpr` property, and in that case use the `hash` property inside of that instead.
 
-Once we had that conditional in place all our tests were 🍏 again and we were
-able to adjust our range of supported Ember versions all the way down to Ember
-1.11.
+Once we had that conditional in place all our tests were 🍏 again and we were able to adjust our range of supported Ember versions all the way down to Ember 1.11.
 
 ## Conclusion
 
-A lot of things have happened on the project this year and we will continue to
-iterate forward on this. One exciting enhancement that we are looking into is
-adding support for [glimmer.js](https://glimmerjs.com/) to the addon. This will
-likely not be done by the time we release v1.0.0, but will be something for us
-to work on in the next year.
+A lot of things have happened on the project this year and we will continue to iterate forward on this. One exciting enhancement that we are looking into is adding support for [glimmer.js](https://glimmerjs.com/) to the addon. This will likely not be done by the time we release v1.0.0, but will be something for us to work on in the next year.
 
-If you have questions on how to best take advantage of test-selectors or how to
-structure your tests in general make sure to [contact us](/contact/).
+If you have questions on how to best take advantage of test-selectors or how to structure your tests in general make sure to [contact us](/contact/).
diff --git a/src/posts/2017-12-04-enginification.md b/src/posts/2017-12-04-enginification.md
index d07fa71fb7..fff51851af 100644
--- a/src/posts/2017-12-04-enginification.md
+++ b/src/posts/2017-12-04-enginification.md
@@ -2,9 +2,7 @@
 title: Enginification
 authorHandle: pangratz
 bio: "Full-Stack Engineer, Ember Data core team member"
-description:
-  "Clemens Müller gives an overview of Ember Engines and shows how they can be
-  used to reduce the footprint of big applications for an improved startup time."
+description: "Clemens Müller gives an overview of Ember Engines and shows how they can be used to reduce the footprint of big applications for an improved startup time."
 tags: ember
 tagline: |
   <p>We recently improved the initial load time of an Ember.js app for mobile clients, by using <a href="http://ember-engines.com/">Ember Engines</a> and leveraging that to lazily loaded parts of the app's code. In this blog post we're going to show how we extracted the engine out of the app and discuss some smaller issues we ran into along the way and how we solved them. So let's dive right in!</p>
@@ -12,16 +10,9 @@ tagline: |
 
 ## Status quo
 
-The app is a mobile ticket counter for rail tickets. The basic flow through the
-app is as follows: a user enters an departure and arrival station and specifies
-the dates and passengers of the journey. After a search is initiated the results
-are shown, a specific trip is chosen, details like seating preference and
-passenger details are entered, the payment is processed and at the end, the
-details of the booked trip are shown and the purchased tickets can be
-downloaded.
+The app is a mobile ticket counter for rail tickets. The basic flow through the app is as follows: a user enters an departure and arrival station and specifies the dates and passengers of the journey. After a search is initiated the results are shown, a specific trip is chosen, details like seating preference and passenger details are entered, the payment is processed and at the end, the details of the booked trip are shown and the purchased tickets can be downloaded.
 
-At the moment Ember.js v2.14 is used and the app has 39 routes, 28 services, 77
-components, 24 models which result in the following asset sizes:
+At the moment Ember.js v2.14 is used and the app has 39 routes, 28 services, 77 components, 24 models which result in the following asset sizes:
 
 | Asset       | Size                          |
 | ----------- | ----------------------------- |
@@ -29,27 +20,15 @@ components, 24 models which result in the following asset sizes:
 | `vendor.js` | 1.51 MB (342.87 KB gzipped)   |
 | `app.css`   | 104.31 KB (19.25 KB gzipped)  |
 
-Taken from the
-[Ember Engine RFC](https://github.com/emberjs/rfcs/blob/master/text/0010-engines.md):
+Taken from the [Ember Engine RFC](https://github.com/emberjs/rfcs/blob/master/text/0010-engines.md):
 
-> Engines allow multiple logical applications to be composed together into a
-> single application from the user's perspective.
+> Engines allow multiple logical applications to be composed together into a single application from the user's perspective.
 
-As users need to fill in the search form - specify what kind of ticket they are
-looking for and for which connection - before they can even proceed to the next
-step, there is no reason to load all of the code that supports the subsequent
-booking flow on application startup. All of that code can be loaded lazily once
-the user proceeds to the next step by actually initiating a search or even while
-they are filling out the login form.
+As users need to fill in the search form - specify what kind of ticket they are looking for and for which connection - before they can even proceed to the next step, there is no reason to load all of the code that supports the subsequent booking flow on application startup. All of that code can be loaded lazily once the user proceeds to the next step by actually initiating a search or even while they are filling out the login form.
 
 ## Extract common functionality used in app into an addon
 
-One fundamental design principle of engines is that they are isolated from the
-hosting app. It is possible to pass in services from the hosting app but apart
-from that, engines don't have access to anything of the app which mounts the
-engine. In order for components, helpers and styles to be accessible from both
-the host app and the engine, those common elements need to be put into an addon,
-which then the app and the engine depend on.
+One fundamental design principle of engines is that they are isolated from the hosting app. It is possible to pass in services from the hosting app but apart from that, engines don't have access to anything of the app which mounts the engine. In order for components, helpers and styles to be accessible from both the host app and the engine, those common elements need to be put into an addon, which then the app and the engine depend on.
 
 We're using an in repo addon for that:
 
@@ -57,9 +36,7 @@ We're using an in repo addon for that:
 ember generate in-repo-addon common
 ```
 
-After the addon is created, we want to move common components and helpers into
-the addon. Let's look at the `loading-indicator` component: it shows a loading
-animation of 3 dots, which is used in the host app and the engine:
+After the addon is created, we want to move common components and helpers into the addon. Let's look at the `loading-indicator` component: it shows a loading animation of 3 dots, which is used in the host app and the engine:
 
 ```shell
 ember generate component loading-indicator --in-repo common
@@ -75,9 +52,7 @@ git mv app/templates/components/loading-indicator.hbs \
 git add lib/common/app/components/loading-indicator.js
 ```
 
-Since the component is now located within the `addon` folder, we need to modify
-`lib/common/addon/components/loading-indicator.js` so the correct layout is
-used:
+Since the component is now located within the `addon` folder, we need to modify `lib/common/addon/components/loading-indicator.js` so the correct layout is used:
 
 ```js
 {% raw %}
@@ -92,11 +67,7 @@ export default Component.extend({
 {% endraw %}
 ```
 
-The application uses
-[ember-cli-sass](https://github.com/aexmachina/ember-cli-sass) for its styles
-and defines a number of variables for colors, sizes etc. In order for those to
-be accessible from both the host app and the engine, these style definitions
-need to be moved into the common addon as well:
+The application uses [ember-cli-sass](https://github.com/aexmachina/ember-cli-sass) for its styles and defines a number of variables for colors, sizes etc. In order for those to be accessible from both the host app and the engine, these style definitions need to be moved into the common addon as well:
 
 ```shell
 git mv app/styles/vars.scss \
@@ -112,9 +83,7 @@ git mv app/styles/components/loading-indicator.scss \
        lib/common/app/styles/common/components/
 ```
 
-Apart from this, we also need to create a file which includes all the styles
-from the common components and helpers. By this all the styles from the `common`
-addon are included in the hosting app:
+Apart from this, we also need to create a file which includes all the styles from the common components and helpers. By this all the styles from the `common` addon are included in the hosting app:
 
 ```scss
 // lib/common/app/styles/common.scss
@@ -122,9 +91,7 @@ addon are included in the hosting app:
 @import "common/components/loading-indicator";
 ```
 
-Within the app we import the style definitions for the common addon, so all the
-styles for the components are included and we can use the `variables`, `colors`
-and `mixins` defined in the common addon.
+Within the app we import the style definitions for the common addon, so all the styles for the components are included and we can use the `variables`, `colors` and `mixins` defined in the common addon.
 
 ```scss
 // app/styles/app.scss
@@ -132,29 +99,19 @@ and `mixins` defined in the common addon.
 @import "common";
 ```
 
-After all that is done, we now have all common components and helpers, as well
-as common style definitions moved into the addon. The next step is to finally
-create the engine, which will contain most of the application code.
+After all that is done, we now have all common components and helpers, as well as common style definitions moved into the addon. The next step is to finally create the engine, which will contain most of the application code.
 
 ## Move functionality into engine
 
-An engine is basically an Ember.js addon. Since the engine won't be reused
-within another application, we decided to go with the in-repo solution for the
-engine as well:
+An engine is basically an Ember.js addon. Since the engine won't be reused within another application, we decided to go with the in-repo solution for the engine as well:
 
 ```shell
 ember generate in-repo-addon booking-flow
 ```
 
-After that, setting up the in-repo engine according to
-[the guides](http://ember-engines.com/guide/creating-an-engine) is pretty
-straight forward. At the end of that we have an engine, located at
-`lib/booking-flow`, so now it's time to move relevant routes, components,
-templates, ... out of `app/` into it.
+After that, setting up the in-repo engine according to [the guides](http://ember-engines.com/guide/creating-an-engine) is pretty straight forward. At the end of that we have an engine, located at `lib/booking-flow`, so now it's time to move relevant routes, components, templates, ... out of `app/` into it.
 
-The first thing we want to do is to depend on the `common` in-repo addon, so we
-can re-use the common elements within the engine. Let's take a look at
-`lib/booking-flow/package.json`:
+The first thing we want to do is to depend on the `common` in-repo addon, so we can re-use the common elements within the engine. Let's take a look at `lib/booking-flow/package.json`:
 
 ```js
 {% raw %}on
@@ -173,16 +130,9 @@ can re-use the common elements within the engine. Let's take a look at
 {% endraw %}
 ```
 
-After that we can start to move all the routes, components, services which are
-only used within the booking-flow engine into the corresponding folders within
-`lib/booking-flow/addon/`. The nice thing about Ember Engines is that they don't
-introduce any new concepts in terms of location of the files. So a simple
-`git mv` does the trick.
+After that we can start to move all the routes, components, services which are only used within the booking-flow engine into the corresponding folders within `lib/booking-flow/addon/`. The nice thing about Ember Engines is that they don't introduce any new concepts in terms of location of the files. So a simple `git mv` does the trick.
 
-The booking-flow addon should use the same style definitions as the hosting app,
-so we'd like to import the common style definitions within the booking-flow
-engines styles. For the imports to work properly, we need to add the path to the
-`common` addon to the `sassOptions` of the engine:
+The booking-flow addon should use the same style definitions as the hosting app, so we'd like to import the common style definitions within the booking-flow engines styles. For the imports to work properly, we need to add the path to the `common` addon to the `sassOptions` of the engine:
 
 ```js
 {% raw %}
@@ -203,9 +153,7 @@ module.exports = EngineAddon.extend({
 {% endraw %}
 ```
 
-By this we can import the variables, colors and mixins in the engines' style
-definitions. And since we namespaced the files in the `common` addon under the
-`common/` folder, we get distinct import paths:
+By this we can import the variables, colors and mixins in the engines' style definitions. And since we namespaced the files in the `common` addon under the `common/` folder, we get distinct import paths:
 
 ```scss
 // lib/booking-flow/addon/styles/components/booking-button.scss
@@ -221,16 +169,11 @@ definitions. And since we namespaced the files in the `common` addon under the
 }
 ```
 
-So now we have moved all the non-essential logic not needed at the beginning of
-the app into an in-repo engine. As a next optimization, let's make use of a
-nifty feature of Ember Engines…
+So now we have moved all the non-essential logic not needed at the beginning of the app into an in-repo engine. As a next optimization, let's make use of a nifty feature of Ember Engines…
 
 ## Make it lazy
 
-After we extracted the `common` addon and the `booking-flow` engine, we are
-ready to load the engine lazily to actually reduce the amount of JavaScript that
-needs to be loaded, parsed and compiled to boot up the application. This is as
-hard work as switching a boolean:
+After we extracted the `common` addon and the `booking-flow` engine, we are ready to load the engine lazily to actually reduce the amount of JavaScript that needs to be loaded, parsed and compiled to boot up the application. This is as hard work as switching a boolean:
 
 ```js
 {% raw %}
@@ -252,23 +195,17 @@ module.exports = EngineAddon.extend({
 {% endraw %}
 ```
 
-And et voilà: we now have 3 new, separate assets, which are loaded on demand
-once we navigate into a route within the engine. Since the initial assets only
-contain the essential logic needed for the search, they have shrunken in size as
-well:
+And et voilà: we now have 3 new, separate assets, which are loaded on demand once we navigate into a route within the engine. Since the initial assets only contain the essential logic needed for the search, they have shrunken in size as well:
 
-| Asset                    | Before                        | After                        |
-| ------------------------ | ----------------------------- | ---------------------------- |
-| `app.js`                 | 627.03 KB (117.22 KB gzipped) | 375.01 KB (78.23 KB gzipped) |
-| `vendor.js`              | 1.51 MB (342.87 KB gzipped)   | 1.6 MB (364.5 KB gzipped)    |
-| `app.css`                | 104.31 KB (19.25 KB gzipped)  | 58.65 KB (12.17 KB gzipped)  |
-| `booking-flow.js`        |                               | 290.47 KB (48.48 KB gzipped) |
-| `booking-flow-vendor.js` |                               | 117 B (127 B gzipped)        |
-| `booking-flow.css`       |                               | 45.24 KB (7.97 KB gzipped)   |
+| Asset | Before | After |
+| --- | --- | --- |
+| `app.js` | 627.03 KB (117.22 KB gzipped) | 375.01 KB (78.23 KB gzipped) |
+| `vendor.js` | 1.51 MB (342.87 KB gzipped) | 1.6 MB (364.5 KB gzipped) |
+| `app.css` | 104.31 KB (19.25 KB gzipped) | 58.65 KB (12.17 KB gzipped) |
+| `booking-flow.js` |  | 290.47 KB (48.48 KB gzipped) |
+| `booking-flow-vendor.js` |  | 117 B (127 B gzipped) |
+| `booking-flow.css` |  | 45.24 KB (7.97 KB gzipped) |
 
 ## Conclusion
 
-We created an in-repo addon for commonly used components, helpers and style
-definitions. After that, everything which is not needed for the initial search
-screen has been moved into an in-repo engine. This helped us reduce the size of
-the initially served assets.
+We created an in-repo addon for commonly used components, helpers and style definitions. After that, everything which is not needed for the initial search screen has been moved into an in-repo engine. This helped us reduce the size of the initially served assets.
diff --git a/src/posts/2018-01-24-ember-freestyle.md b/src/posts/2018-01-24-ember-freestyle.md
index 696f4b0cc3..f814075a91 100644
--- a/src/posts/2018-01-24-ember-freestyle.md
+++ b/src/posts/2018-01-24-ember-freestyle.md
@@ -2,9 +2,7 @@
 title: "Using ember-freestyle as a component playground"
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek gives an overview of how ember-freestyle can be used in
-  Ember.js applications for building and testing components in isolation."
+description: "Tobias Bieniek gives an overview of how ember-freestyle can be used in Ember.js applications for building and testing components in isolation."
 tags: ember
 tagline: |
   <p>A component playground is an application that you can use to test out and play around with your custom components in isolation from the rest of your project. In the React and Vue ecosystem <a href="https://storybook.js.org/">Storybook</a> is a quite popular project that implements such a component playground as part of your app. In the Ember ecosystem we have the <a href="http://ember-freestyle.com/"><code>ember-freestyle</code></a> addon that can be used for this purpose. This blog post will show you how to install <code>ember-freestyle</code> in your app and how to use it to build and test components in isolation.</p>
@@ -12,60 +10,32 @@ tagline: |
 
 ## Component Playgrounds
 
-You might be wondering "Why would would I need something like this? I can just
-test my components in the app!" and you're right. But imagine building a
-reasonably large application with dozens of routes, hundreds of components and
-thousands of possible component states. Checking all of these component states
-manually on the different routes that they are appearing on is a very time
-consuming task. A component playground solves this by allowing you to display
-multiple component states next to each other on a single page to give you a much
-better and quicker overview of how the component will look like in the end.
-
-Another big advantage of using component playgrounds is that it forces you to
-build reusable components that are isolated from the app's business logic and
-layout. That means they don't depend on any state or actions in your
-controllers, routes and ideally services, but only on the data and action
-handlers that are passed into them.
-
-If you want to know more about why component playgrounds are useful in general I
-recommend reading this great blog post ["UI component explorers — your new
-favorite tool"][ui-component-explorers] by Dominic Nguyen that explains the
-benefits very well.
-
-[ui-component-explorers]:
-  https://blog.hichroma.com/the-crucial-tool-for-modern-frontend-engineers-fb849b06187a
+You might be wondering "Why would would I need something like this? I can just test my components in the app!" and you're right. But imagine building a reasonably large application with dozens of routes, hundreds of components and thousands of possible component states. Checking all of these component states manually on the different routes that they are appearing on is a very time consuming task. A component playground solves this by allowing you to display multiple component states next to each other on a single page to give you a much better and quicker overview of how the component will look like in the end.
+
+Another big advantage of using component playgrounds is that it forces you to build reusable components that are isolated from the app's business logic and layout. That means they don't depend on any state or actions in your controllers, routes and ideally services, but only on the data and action handlers that are passed into them.
+
+If you want to know more about why component playgrounds are useful in general I recommend reading this great blog post ["UI component explorers — your new favorite tool"][ui-component-explorers] by Dominic Nguyen that explains the benefits very well.
+
+[ui-component-explorers]: https://blog.hichroma.com/the-crucial-tool-for-modern-frontend-engineers-fb849b06187a
 
 ## Installing `ember-freestyle`
 
-Installing and configuring `ember-freestyle` correctly is unfortunately a little
-complicated right now so if you want to take a look at the final outcome, you
-can skip forward to the ["Using `ember-freestyle`"](#using-ember-freestyle)
-section for now.
+Installing and configuring `ember-freestyle` correctly is unfortunately a little complicated right now so if you want to take a look at the final outcome, you can skip forward to the ["Using `ember-freestyle`"](#using-ember-freestyle) section for now.
 
-Before we start installing anything we should make sure we know what situation
-we would like to be in at the end. Our plan is to use `ember-freestyle` to
-generate a component playground at the `/freestyle` route, that is only
-available during development and does not affect the final asset sizes of the
-production build.
+Before we start installing anything we should make sure we know what situation we would like to be in at the end. Our plan is to use `ember-freestyle` to generate a component playground at the `/freestyle` route, that is only available during development and does not affect the final asset sizes of the production build.
 
-Let's start by following the official instructions on the `ember-freestyle`
-website:
+Let's start by following the official instructions on the `ember-freestyle` website:
 
 - `ember install ember-freestyle`
 - Add `this.route('freestyle');` to the `app/router.js` file
 
 ### Adjusting the `application` template
 
-If you try this in a fresh new Ember app, run the development server using
-`ember serve` and visit `http://localhost:4200/freestyle` you will notice the
-first problem: The `ember-freestyle` components are appearing underneath the
-`{{welcome-page}}` component:
+If you try this in a fresh new Ember app, run the development server using `ember serve` and visit `http://localhost:4200/freestyle` you will notice the first problem: The `ember-freestyle` components are appearing underneath the `{{welcome-page}}` component:
 
 ![Screenshot](/assets/images/posts/2017-12-07-ember-freestyle/freestyle-underneath-welcome-page.png)
 
-This is obviously not what we want. To fix this we will need to adjust the
-`app/templates/application.hbs` file and wrap the existing contents in a
-condition:
+This is obviously not what we want. To fix this we will need to adjust the `app/templates/application.hbs` file and wrap the existing contents in a condition:
 
 ```diff-hbs
 {% raw %}
@@ -81,12 +51,7 @@ condition:
 {% endraw %}
 ```
 
-`onFreestyleRoute` is a property on the `application` controller that will be
-set to `true` once we visit the `/freestyle` route and and back to `false` once
-we leave it again. This can be implemented in the `app/routes/freestyle.js`
-file, and since that does not exist yet, we can generate it using
-`ember generate route freestyle` (choose not to overwrite the existing
-template!) and then adjusting it like this:
+`onFreestyleRoute` is a property on the `application` controller that will be set to `true` once we visit the `/freestyle` route and and back to `false` once we leave it again. This can be implemented in the `app/routes/freestyle.js` file, and since that does not exist yet, we can generate it using `ember generate route freestyle` (choose not to overwrite the existing template!) and then adjusting it like this:
 
 ```js
 {% raw %}
@@ -104,17 +69,13 @@ export default Route.extend({
 {% endraw %}
 ```
 
-If you check `/freestyle` again you should see that now the only thing that is
-displayed is the `ember-freestyle` guide. 🎉
+If you check `/freestyle` again you should see that now the only thing that is displayed is the `ember-freestyle` guide. 🎉
 
 ### Removing `ember-freestyle` from the production build
 
-Once you try to ship this to production you might notice another issue: your
-asset size has increased significantly, so it seems that `ember-freestyle` is
-not disabled for production builds by default. Let's fix this!
+Once you try to ship this to production you might notice another issue: your asset size has increased significantly, so it seems that `ember-freestyle` is not disabled for production builds by default. Let's fix this!
 
-According to the `ember-freestyle` documentation we are supposed to "blacklist"
-the addon in the `ember-cli-build.js` file of our app:
+According to the `ember-freestyle` documentation we are supposed to "blacklist" the addon in the `ember-cli-build.js` file of our app:
 
 ```js
 {% raw %}
@@ -134,24 +95,13 @@ module.exports = function (defaults) {
 {% endraw %}
 ```
 
-Great! Now our asset size is back to normal. Wait... it is smaller now, but
-still not quite back to what we had before. 🤔
+Great! Now our asset size is back to normal. Wait... it is smaller now, but still not quite back to what we had before. 🤔
 
-The code above only removes all the components from the build that
-`ember-freestyle` brings with it itself. That means components like
-`{{freestyle-guide}}` and `{{freestyle-usage}}` are no longer part of the
-production build, but the `freestyle` controller, route and template are still
-included.
+The code above only removes all the components from the build that `ember-freestyle` brings with it itself. That means components like `{{freestyle-guide}}` and `{{freestyle-usage}}` are no longer part of the production build, but the `freestyle` controller, route and template are still included.
 
-The solution to this problem is moving the `freestyle` files into a dedicated
-`in-repo-addon` and then blacklisting that one too. First we generate a new
-`in-repo-addon` using `ember generate in-repo-addon freestyle`. After that we
-move `app/controllers/freestyle.js` to
-`lib/freestyle/app/controllers/freestyle.js` and do the same for the `freestyle`
-route and template.
+The solution to this problem is moving the `freestyle` files into a dedicated `in-repo-addon` and then blacklisting that one too. First we generate a new `in-repo-addon` using `ember generate in-repo-addon freestyle`. After that we move `app/controllers/freestyle.js` to `lib/freestyle/app/controllers/freestyle.js` and do the same for the `freestyle` route and template.
 
-Next we will add our new `freestyle` in-repo-addon to the `pluginsToBlacklist`
-list above:
+Next we will add our new `freestyle` in-repo-addon to the `pluginsToBlacklist` list above:
 
 ```js
 {% raw %}
@@ -160,10 +110,7 @@ let pluginsToBlacklist =
 {% endraw %}
 ```
 
-Finally we need to adjust the paths that `ember-freestyle` uses to search for
-the code snippets that show how the component is used in a host application. For
-that we will add a `snippetSearchPaths` property in the `ember-cli-build.js`
-file:
+Finally we need to adjust the paths that `ember-freestyle` uses to search for the code snippets that show how the component is used in a host application. For that we will add a `snippetSearchPaths` property in the `ember-cli-build.js` file:
 
 ```js
 {% raw %}
@@ -176,28 +123,15 @@ let app = new EmberApp(defaults, {
 {% endraw %}
 ```
 
-If you now restart the development server and check the `/freestyle` route you
-should see that everything is working as before, but if instead you run
-`ember serve -prod` you will notice that you only see a blank page because the
-`freestyle` controller, route and template are no longer available. If you would
-like to use your default 404 page instead you can put the
-`this.route('freestyle');` call in the `router.js` file in a condition that
-checks `if (config.environment === 'development')`.
+If you now restart the development server and check the `/freestyle` route you should see that everything is working as before, but if instead you run `ember serve -prod` you will notice that you only see a blank page because the `freestyle` controller, route and template are no longer available. If you would like to use your default 404 page instead you can put the `this.route('freestyle');` call in the `router.js` file in a condition that checks `if (config.environment === 'development')`.
 
-This leaves us with only the single condition in the `application` template and
-the `this.route('freestyle');` call in the `router.js` file that we ship to
-production. While we could put in some effort to remove those too the situation
-is good enough and we can finally focus on putting content into our new
-component playground! 🎉
+This leaves us with only the single condition in the `application` template and the `this.route('freestyle');` call in the `router.js` file that we ship to production. While we could put in some effort to remove those too the situation is good enough and we can finally focus on putting content into our new component playground! 🎉
 
 ## Using `ember-freestyle`
 
-The good news is that **using** `ember-freestyle` is much easier than setting it
-up correctly!
+The good news is that **using** `ember-freestyle` is much easier than setting it up correctly!
 
-Let's pretend we are writing a component called `styled-button`. We can create a
-new file at `app/components/styled-button.js` and put the following content in
-it:
+Let's pretend we are writing a component called `styled-button`. We can create a new file at `app/components/styled-button.js` and put the following content in it:
 
 ```js
 {% raw %}
@@ -210,8 +144,7 @@ export default Component.extend({
 {% endraw %}
 ```
 
-In addition to that we'll add some styles for this button to our
-`app/styles/app.css` file:
+In addition to that we'll add some styles for this button to our `app/styles/app.css` file:
 
 ```css
 .styled-button {
@@ -224,8 +157,7 @@ In addition to that we'll add some styles for this button to our
 }
 ```
 
-Finally we will add the button to our component playground by editing the
-`lib/freestyle/app/templates/freestyle.hbs` template:
+Finally we will add the button to our component playground by editing the `lib/freestyle/app/templates/freestyle.hbs` template:
 
 ```handlebars
 {% raw %}
@@ -249,21 +181,12 @@ Finally we will add the button to our component playground by editing the
 {% endraw %}
 ```
 
-If we now visit `http://localhost:4200/freestyle` we will see a new "Components"
-section in the sidebar on the left that includes our "styled-button" subsection.
-Once we click on that we will see our `styled-button` usage examples including
-the snippets there were used to display them:
+If we now visit `http://localhost:4200/freestyle` we will see a new "Components" section in the sidebar on the left that includes our "styled-button" subsection. Once we click on that we will see our `styled-button` usage examples including the snippets there were used to display them:
 
 ![Screenshot](/assets/images/posts/2017-12-07-ember-freestyle/styled-button.png#@900-1800)
 
-As this blog post has gotten much longer than intended already I'll leave it up
-to your imagination what other things you can put into such a component
-playground. In a follow-up post we will soon discuss how to extract subsections
-into components and how to automatically discover and inject them into the main
-template.
+As this blog post has gotten much longer than intended already I'll leave it up to your imagination what other things you can put into such a component playground. In a follow-up post we will soon discuss how to extract subsections into components and how to automatically discover and inject them into the main template.
 
-Finally I would like to thank [Chris LoPresto][chris-lopresto] and the other
-contributors for working on `ember-freestyle` and would encourage you to give it
-a try!
+Finally I would like to thank [Chris LoPresto][chris-lopresto] and the other contributors for working on `ember-freestyle` and would encourage you to give it a try!
 
 [chris-lopresto]: https://github.com/chrislopresto
diff --git a/src/posts/2018-02-14-handling-webhooks-in-phoenix.md b/src/posts/2018-02-14-handling-webhooks-in-phoenix.md
index 0e820ce1fd..6a5e221d80 100644
--- a/src/posts/2018-02-14-handling-webhooks-in-phoenix.md
+++ b/src/posts/2018-02-14-handling-webhooks-in-phoenix.md
@@ -2,9 +2,7 @@
 title: Handling Webhooks in Phoenix
 authorHandle: niklas_long
 bio: "Backend Engineer, author of Breethe API"
-description:
-  "Niklas Long introduces an effective and simple approach for handling incoming
-  webhook requests in Phoenix applications with advanced routing."
+description: "Niklas Long introduces an effective and simple approach for handling incoming webhook requests in Phoenix applications with advanced routing."
 tags: elixir
 tagline: |
   <p>I recently had to implement a controller, which took care of receiving and processing webhooks. The thing is, the application had to handle webhooks which often contained very different information, and they were all going to one route and one controller action. This didn't really seem to fit with my goal of keeping controller actions concise and focused. So I set out to find a better solution.</p>
@@ -12,15 +10,11 @@ tagline: |
 
 ## tl;dr
 
-Use `forward` on `MyApp.Router` to forward the request (`%Conn{}`) to a custom
-plug (`MyApp.Plugs.WebhookShunt`) which maps `%Conn{}` to a route (and thus a
-controller action) defined on `MyApp.WebhookRouter`, based on the data in the
-request body.
+Use `forward` on `MyApp.Router` to forward the request (`%Conn{}`) to a custom plug (`MyApp.Plugs.WebhookShunt`) which maps `%Conn{}` to a route (and thus a controller action) defined on `MyApp.WebhookRouter`, based on the data in the request body.
 
 I.e.,
 
-`%Conn{}` -> `Router` -> `WebhookShunt` -> `WebhookRouter` ->
-`WebhookController`
+`%Conn{}` -> `Router` -> `WebhookShunt` -> `WebhookRouter` -> `WebhookController`
 
 ## lv;e (long version; enjoy!)
 
@@ -30,12 +24,9 @@ Let's restate the problem:
 - there are many different possible request payloads
 - application requires different computation depending on payload
 
-Let's say we're receiving webhooks which contain an `event` key in the request
-body. It describes the event which triggered the webhook and we can use it to
-determine what code we are going to run.
+Let's say we're receiving webhooks which contain an `event` key in the request body. It describes the event which triggered the webhook and we can use it to determine what code we are going to run.
 
-Below was my first and somewhat naïve implementation. This is what the router
-looked like:
+Below was my first and somewhat naïve implementation. This is what the router looked like:
 
 ```elixir
 scope "/", MyAppWeb do
@@ -56,12 +47,9 @@ def hook(conn, params) do
 end
 ```
 
-All incoming webhooks go to the same route and therefore, the same controller
-action.
+All incoming webhooks go to the same route and therefore, the same controller action.
 
-It took three refactors to get to a satisfactory solution. I will, however,
-explain each one in this post, as they are logical steps in reaching the final
-solution and proved interesting learning opportunities:
+It took three refactors to get to a satisfactory solution. I will, however, explain each one in this post, as they are logical steps in reaching the final solution and proved interesting learning opportunities:
 
 1. Multiple function clauses for controller action
 2. Plug called from endpoint
@@ -69,11 +57,7 @@ solution and proved interesting learning opportunities:
 
 ## Multiple function clauses
 
-Let's start separating the computation into smaller fragments by moving the
-pattern matching from the `case` statement to the function's definition. We are
-still using only one route and only one controller action, but we write multiple
-clauses of that function to match a certain value of the `event` key in the
-params.
+Let's start separating the computation into smaller fragments by moving the pattern matching from the `case` statement to the function's definition. We are still using only one route and only one controller action, but we write multiple clauses of that function to match a certain value of the `event` key in the params.
 
 Here's our controller with the multiple clauses:
 
@@ -84,18 +68,11 @@ def hook(conn, %{"event" => "multiplication"} = params), do: multiply(params)
 def hook(conn, %{"event" => "division"} = params), do: divide(params)
 ```
 
-The request payload will match the clauses for the `hook/2` function and execute
-different functions depending on what `event` was passed in. This refactor is a
-step in the right direction, but it still doesn't fit well with the idea that a
-controller action should handle one specific request. The router serves no real
-purpose, as there is still only one route, and our code has the potential to get
-very messy.
+The request payload will match the clauses for the `hook/2` function and execute different functions depending on what `event` was passed in. This refactor is a step in the right direction, but it still doesn't fit well with the idea that a controller action should handle one specific request. The router serves no real purpose, as there is still only one route, and our code has the potential to get very messy.
 
 ## Shunting incoming connections
 
-What if we could interfere with the incoming webhook before it hits the router?
-We could then modify the path of the request depending on the params, match a
-route and execute the corresponding controller action.
+What if we could interfere with the incoming webhook before it hits the router? We could then modify the path of the request depending on the params, match a route and execute the corresponding controller action.
 
 The router would look something like this:
 
@@ -117,25 +94,11 @@ def multiply(conn, params), do: #handle multiplication
 def divide(conn, params), do: #handle division
 ```
 
-In this case, each controller action serves a specific function, the router maps
-each incoming request to these actions and the code is easily maintainable,
-well-structured and won't become jumbled over time. To achieve this, however, we
-need to change a couple of things.
-
-First off, we need to interfere with the incoming request before it hits the
-router so it will match our new routes. This is because the webhook callback url
-is always the same and doesn't depend on what event triggered it e.g.,
-`"my_app_url/webhook"`. You would think we could create a plug for this and
-simply add it to a custom pipeline for the routes. The problem with this, is the
-router will invoke the pipeline **after** it matches a route. Therefore, we
-cannot modify the request's path in this pipeline and expect it to match our
-`addition`, `subtraction`, `multiplication` or `division` routes. If we want our
-new routes to match, we need to intercept the `%Conn{}` in a plug called in the
-endpoint. The endpoint handles starting the web server and transforming requests
-through several defined plugs before calling the router.
-
-Let's add a plug called `MyApp.WebhookShunt` to the endpoint, just before the
-router.
+In this case, each controller action serves a specific function, the router maps each incoming request to these actions and the code is easily maintainable, well-structured and won't become jumbled over time. To achieve this, however, we need to change a couple of things.
+
+First off, we need to interfere with the incoming request before it hits the router so it will match our new routes. This is because the webhook callback url is always the same and doesn't depend on what event triggered it e.g., `"my_app_url/webhook"`. You would think we could create a plug for this and simply add it to a custom pipeline for the routes. The problem with this, is the router will invoke the pipeline **after** it matches a route. Therefore, we cannot modify the request's path in this pipeline and expect it to match our `addition`, `subtraction`, `multiplication` or `division` routes. If we want our new routes to match, we need to intercept the `%Conn{}` in a plug called in the endpoint. The endpoint handles starting the web server and transforming requests through several defined plugs before calling the router.
+
+Let's add a plug called `MyApp.WebhookShunt` to the endpoint, just before the router.
 
 ```elixir
 defmodule MyApp.Endpoint do
@@ -145,8 +108,7 @@ defmodule MyApp.Endpoint do
 end
 ```
 
-And let's create a file called `webhook_shunt.ex` and add it to our `plugs`
-folder:
+And let's create a file called `webhook_shunt.ex` and add it to our `plugs` folder:
 
 ```elixir
 defmodule MyAppWeb.Plug.WebhookShunt do
@@ -158,22 +120,14 @@ defmodule MyAppWeb.Plug.WebhookShunt do
 end
 ```
 
-The core components of a Phoenix application are plugs. This includes endpoints,
-routers and controllers. There are two flavors of `Plug`, function plugs and
-module plugs. We'll be using the latter in this example, but I highly suggest
-checking out the [docs](https://hexdocs.pm/plug/readme.html).
+The core components of a Phoenix application are plugs. This includes endpoints, routers and controllers. There are two flavors of `Plug`, function plugs and module plugs. We'll be using the latter in this example, but I highly suggest checking out the [docs](https://hexdocs.pm/plug/readme.html).
 
-Let's examine the code above, you'll notice there are two functions already
-defined:
+Let's examine the code above, you'll notice there are two functions already defined:
 
-- `init/1` which initializes any arguments or options to be passed to `call/2`
-  (executed at compile time)
-- `call/2` which transforms the connection (it's actually a simple function plug
-  and is executed at run time)
+- `init/1` which initializes any arguments or options to be passed to `call/2` (executed at compile time)
+- `call/2` which transforms the connection (it's actually a simple function plug and is executed at run time)
 
-Both of these need to be implemented in a module plug. Let's modify `call/2` to
-match the `addition` event in the request payload and change the request path to
-the route we defined for addition:
+Both of these need to be implemented in a module plug. Let's modify `call/2` to match the `addition` event in the request payload and change the request path to the route we defined for addition:
 
 ```elixir
 defmodule MyAppWeb.Plug.WebhookShunt do
@@ -193,48 +147,30 @@ defmodule MyAppWeb.Plug.WebhookShunt do
 end
 ```
 
-`change_path_info/2` changes the `path_info` property on the `%Conn{}`, based on
-the request payload matched in `call/2`, in this case to `"webhook/addition"`.
-You'll notice I also added a no-op function clause for `call/2`. If other routes
-are added and don't need to be manipulated in the same way as the ones above, we
-need to make sure the request gets through to the router unmodified.
+`change_path_info/2` changes the `path_info` property on the `%Conn{}`, based on the request payload matched in `call/2`, in this case to `"webhook/addition"`. You'll notice I also added a no-op function clause for `call/2`. If other routes are added and don't need to be manipulated in the same way as the ones above, we need to make sure the request gets through to the router unmodified.
 
-This strategy isn't great, however. We are placing code in the endpoint, which
-will be executed no matter what the request path is. Furthermore, the endpoint
-is only supposed to (from the
-[docs](https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#content)):
+This strategy isn't great, however. We are placing code in the endpoint, which will be executed no matter what the request path is. Furthermore, the endpoint is only supposed to (from the [docs](https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#content)):
 
-- provide a wrapper for starting and stopping the endpoint as part of a
-  supervision tree
+- provide a wrapper for starting and stopping the endpoint as part of a supervision tree
 - define an initial plug pipeline for requests to pass through
 - host web specific configuration for your application
 
-Interfering with the request to map it to a route at this point would be
-unidiomatic Phoenix. It would also make the app slower, and harder to maintain
-and debug.
+Interfering with the request to map it to a route at this point would be unidiomatic Phoenix. It would also make the app slower, and harder to maintain and debug.
 
 ## Forwarding conn to the shunt and calling another router
 
-Instead of intercepting the `%Conn{}` in the endpoint, we could forward it from
-the application's main router to the `WebhookShunt`, modify it and call a second
-router whose sole purpose would be to handle the incoming webhooks.
+Instead of intercepting the `%Conn{}` in the endpoint, we could forward it from the application's main router to the `WebhookShunt`, modify it and call a second router whose sole purpose would be to handle the incoming webhooks.
 
 1. The request hits router which has one path for all webhooks (`"/webhook"`)
-2. `%Conn{}` is forwarded to the `WebhookShunt` which modifies the path based on
-   the request payload
-3. The `WebhookShunt` calls the `WebhookRouter`, passing it the modified
-   `%Conn{}`
-4. The `WebhookRouter` matches the `%Conn{}` path and calls the appropriate
-   action on the `WebhookController`
+2. `%Conn{}` is forwarded to the `WebhookShunt` which modifies the path based on the request payload
+3. The `WebhookShunt` calls the `WebhookRouter`, passing it the modified `%Conn{}`
+4. The `WebhookRouter` matches the `%Conn{}` path and calls the appropriate action on the `WebhookController`
 
 I.e.,
 
-`%Conn{}` -> `Router` -> `WebhookShunt` -> `WebhookRouter` ->
-`WebhookController`
+`%Conn{}` -> `Router` -> `WebhookShunt` -> `WebhookRouter` -> `WebhookController`
 
-I think this approach is better. We don't need to modify the endpoint, the
-router simply forwards anything that matches the webhook path to the shunt and
-the app's concerns are clearly separated.
+I think this approach is better. We don't need to modify the endpoint, the router simply forwards anything that matches the webhook path to the shunt and the app's concerns are clearly separated.
 
 Let's set up our webhook path in `router.ex`:
 
@@ -244,12 +180,9 @@ scope "/", MyAppWeb do
 end
 ```
 
-As long as your external APIs makes a request to this path when you do the setup
-for the webhook callbacks, every incoming request to this path will be forwarded
-to the `WebhookShunt`.
+As long as your external APIs makes a request to this path when you do the setup for the webhook callbacks, every incoming request to this path will be forwarded to the `WebhookShunt`.
 
-Let's refactor `call/2` to handle all events by replacing the hardcoded
-`"addition"` event and path with the `event` variable:
+Let's refactor `call/2` to handle all events by replacing the hardcoded `"addition"` event and path with the `event` variable:
 
 ```elixir
 defmodule MyAppWeb.Plugs.WebhookShunt do
@@ -268,18 +201,11 @@ defmodule MyAppWeb.Plugs.WebhookShunt do
 end
 ```
 
-With this refactor, all our routes must follow the `"webhook/event"` pattern. In
-more complex applications, you might not be able to conveniently use the event
-name as a part of the path but the principle remains the same.
+With this refactor, all our routes must follow the `"webhook/event"` pattern. In more complex applications, you might not be able to conveniently use the event name as a part of the path but the principle remains the same.
 
-You'll notice I've removed the no-op `call/2` function clause. This is because
-we no longer have to handle all potential requests like we did in the endpoint;
-we can focus entirely on the webhhooks. Now, if we receive a request with an
-event which doesn't match a route, Phoenix will raise an error, which is what we
-want as we don't know how to handle that request.
+You'll notice I've removed the no-op `call/2` function clause. This is because we no longer have to handle all potential requests like we did in the endpoint; we can focus entirely on the webhhooks. Now, if we receive a request with an event which doesn't match a route, Phoenix will raise an error, which is what we want as we don't know how to handle that request.
 
-Note: if you can't configure your API to send only the webhooks you're
-interested in handling, you should write some code to take care of that.
+Note: if you can't configure your API to send only the webhooks you're interested in handling, you should write some code to take care of that.
 
 Let's also create `webhook_router.ex` in the `_web` directory:
 
@@ -296,9 +222,7 @@ defmodule MyAppWeb.WebhookRouter do
 end
 ```
 
-The `WebhookRouter` is called from the `WebhookShunt` with
-`WebhookRouter.call(conn, opts)`, and maps the modified `%Conn{}`s to the
-appropriate controller action on the `WebhookController`, which looks like this:
+The `WebhookRouter` is called from the `WebhookShunt` with `WebhookRouter.call(conn, opts)`, and maps the modified `%Conn{}`s to the appropriate controller action on the `WebhookController`, which looks like this:
 
 ```elixir
 def add(conn, params), do: #handle addition
@@ -307,9 +231,6 @@ def multiply(conn, params), do: #handle multiplication
 def divide(conn, params), do: #handle division
 ```
 
-I think this last solution ticks all the boxes. Externally, there is still only
-one webhook callback url; internally, we have a route and a controller action
-for each event our application needs to handle. Our concerns are therefore
-clearly separated, making the application extensible and easy to maintain.
+I think this last solution ticks all the boxes. Externally, there is still only one webhook callback url; internally, we have a route and a controller action for each event our application needs to handle. Our concerns are therefore clearly separated, making the application extensible and easy to maintain.
 
 So there you have it, handling webhooks in Phoenix.
diff --git a/src/posts/2018-05-30-a-little-encouragement-goes-a-long-way-in-2018.md b/src/posts/2018-05-30-a-little-encouragement-goes-a-long-way-in-2018.md
index e5b1e359be..a6d1c43f84 100644
--- a/src/posts/2018-05-30-a-little-encouragement-goes-a-long-way-in-2018.md
+++ b/src/posts/2018-05-30-a-little-encouragement-goes-a-long-way-in-2018.md
@@ -2,205 +2,56 @@
 title: A Little Encouragement Goes a Long Way in 2018
 authorHandle: jjordan_dev
 bio: "Senior Frontend Engineer, Ember Learning core team member"
-description:
-  "Jessica Jordan shares her thoughts for Ember.js in the coming year in
-  response to the Ember 2018 Roadmap Call for Blog Posts."
+description: "Jessica Jordan shares her thoughts for Ember.js in the coming year in response to the Ember 2018 Roadmap Call for Blog Posts."
 tags: ember
 tagline: |
   <p>In May 2018, Ember Core team member Katie Gengler published <a href="https://www.emberjs.com/blog/2018/05/02/ember-2018-roadmap-call-for-posts.html">Ember's 2018 Roadmap: A Call for Blog Posts</a>. With this call-to-action she invites the community to give feedback on their hopes and wishes for Ember moving forward. In this context, I also want to share some of my own thoughts on Ember and what I'd be excited to see in its nearest future.</p>
 ---
 
-> The Ember team would like you to write a blog post to propose goals and
-> direction for Ember in the remainder of 2018. The content of these posts will
-> help us to draft our first Roadmap RFC.
-
-First off, I'm confident that Ember already has done a lot to allow me and many
-others to create great and maintainable applications. And it has done so very
-early on. For a while naming conventions and a CLI-driven approach to scaffold,
-build & serve apps have been hallmarks of Ember as a framework for the ambitious
-developer. Other framework ecosystems are also adopting similar approaches to
-increase developer productivity
-([1](https://github.com/angular/angular-cli/tree/v1.6.8#cli-for-angular-applications-based-on-the-ember-cli-project),
-[2](https://hackernoon.com/structuring-projects-and-naming-components-in-react-1261b6e18d76))
-and are having immense success with them.
-
-Other productivity improvements that emerged with Ember include its well-planned
-release cycle
-([3](https://www.emberjs.com/blog/2013/09/06/new-ember-release-process.html))
-that has been put into practice during the v1.x era as early as 5 years ago, and
-the ongoing support through LTS releases
-([4](https://emberjs.com/blog/2016/02/25/announcing-embers-first-lts.html?utm_source=javascriptweekly&utm_medium=email))
-for more than 2 years. This mature and dependable release process has not only
-been extremely progressive back then, but in fact it still is. Furthermore, the
-current testing story in Ember has evolved to be one of the most outstanding
-community solutions in the JavaScript realm: The modern QUnit Testing API
-([5](https://rwjblue.com/2017/10/23/ember-qunit-simplication/)) that ships with
-v3.x apps out of the box in combination with the simple interface of
-`@ember/test-helpers`
-([6](https://github.com/emberjs/ember-test-helpers/blob/master/API.md)) improves
-the readability of tests massively and also makes async testing more than
-straightforward.
-
-These are some of the many examples in which Ember.js has repeatedly proven
-itself to be a community solution that really empowers its users to get things
-done. This is why Ember is a truly productive JavaScript framework.
-
-Not only in the past has Ember proven to put new ideas into practice in the
-ecosystem of front-end web development; recent experiments with WebAssembly in
-the Glimmer VM ([7](https://youtu.be/NhtpXs0ZtUc?t=35m56s)) signal that Ember.js
-will continue to run on its innovative trajectory. New features in Ember are in
-fact often ahead of its time. This is why Ember is a truly progressive
-JavaScript framework.
-
-Progressive technologies give developers a head start in exploring new ways of
-writing applications. Progressive technologies will draw the interest of many
-new, early-adopting developers to communities. But progressiveness also poses
-challenges: depending on their own experience level and the amount of work they
-spent on critically evaluating a new feature a developer may or may not fully
-grasp its meaning and extent early on. E.g. a JavaScript developer who entered
-the field recently, might not be aware yet that a CLI can help them immensely in
-building and serving their app. Even a person with extensive experience in one
-certain programming language might not be aware of the challenges they might
-encounter developing JavaScript applications specifically and overlook the
-benefits of a progressive feature like WebAssembly easily.
-
-This makes me think that making features understandable to a diverse set of
-people does not only include explaining how technologies work, but also why they
-are so useful.
-
-I already believe that Ember.js is a great choice for any web developer who
-wants to create scalable applications today. There's really not much I could
-wish for on a technical level. Instead when I think about what I wish for Ember,
-_visibility_ comes to my mind. I'd love both Ember's core characteristics and
-its cutting-edge features to be understood by even more people; even by those
-who haven't had much experience in using it to see its worthwhile benefits in
-the long-run of a project. I believe Ember's bottleneck for adoption and
-community growth isn't about technical aspects, it's about visibility and
-outreach.
+> The Ember team would like you to write a blog post to propose goals and direction for Ember in the remainder of 2018. The content of these posts will help us to draft our first Roadmap RFC.
+
+First off, I'm confident that Ember already has done a lot to allow me and many others to create great and maintainable applications. And it has done so very early on. For a while naming conventions and a CLI-driven approach to scaffold, build & serve apps have been hallmarks of Ember as a framework for the ambitious developer. Other framework ecosystems are also adopting similar approaches to increase developer productivity ([1](https://github.com/angular/angular-cli/tree/v1.6.8#cli-for-angular-applications-based-on-the-ember-cli-project), [2](https://hackernoon.com/structuring-projects-and-naming-components-in-react-1261b6e18d76)) and are having immense success with them.
+
+Other productivity improvements that emerged with Ember include its well-planned release cycle ([3](https://www.emberjs.com/blog/2013/09/06/new-ember-release-process.html)) that has been put into practice during the v1.x era as early as 5 years ago, and the ongoing support through LTS releases ([4](https://emberjs.com/blog/2016/02/25/announcing-embers-first-lts.html?utm_source=javascriptweekly&utm_medium=email)) for more than 2 years. This mature and dependable release process has not only been extremely progressive back then, but in fact it still is. Furthermore, the current testing story in Ember has evolved to be one of the most outstanding community solutions in the JavaScript realm: The modern QUnit Testing API ([5](https://rwjblue.com/2017/10/23/ember-qunit-simplication/)) that ships with v3.x apps out of the box in combination with the simple interface of `@ember/test-helpers` ([6](https://github.com/emberjs/ember-test-helpers/blob/master/API.md)) improves the readability of tests massively and also makes async testing more than straightforward.
+
+These are some of the many examples in which Ember.js has repeatedly proven itself to be a community solution that really empowers its users to get things done. This is why Ember is a truly productive JavaScript framework.
+
+Not only in the past has Ember proven to put new ideas into practice in the ecosystem of front-end web development; recent experiments with WebAssembly in the Glimmer VM ([7](https://youtu.be/NhtpXs0ZtUc?t=35m56s)) signal that Ember.js will continue to run on its innovative trajectory. New features in Ember are in fact often ahead of its time. This is why Ember is a truly progressive JavaScript framework.
+
+Progressive technologies give developers a head start in exploring new ways of writing applications. Progressive technologies will draw the interest of many new, early-adopting developers to communities. But progressiveness also poses challenges: depending on their own experience level and the amount of work they spent on critically evaluating a new feature a developer may or may not fully grasp its meaning and extent early on. E.g. a JavaScript developer who entered the field recently, might not be aware yet that a CLI can help them immensely in building and serving their app. Even a person with extensive experience in one certain programming language might not be aware of the challenges they might encounter developing JavaScript applications specifically and overlook the benefits of a progressive feature like WebAssembly easily.
+
+This makes me think that making features understandable to a diverse set of people does not only include explaining how technologies work, but also why they are so useful.
+
+I already believe that Ember.js is a great choice for any web developer who wants to create scalable applications today. There's really not much I could wish for on a technical level. Instead when I think about what I wish for Ember, _visibility_ comes to my mind. I'd love both Ember's core characteristics and its cutting-edge features to be understood by even more people; even by those who haven't had much experience in using it to see its worthwhile benefits in the long-run of a project. I believe Ember's bottleneck for adoption and community growth isn't about technical aspects, it's about visibility and outreach.
 
 ## A Gap in Visibility
 
-As any other open-source project, the development of Ember lives and thrives
-through the time and amount of work that is being put into it. In contrast to
-some other major JavaScript frameworks, Ember is not being backed up by one
-single major company - neither financially nor contribution-wise. Instead
-Ember's user base is diverse in its professional backgrounds and interests. And
-this makes Ember more independent and free to evolve according to real developer
-needs instead of company requirements which is an amazing advantage.
-
-But who's putting in the time and effort to maintain such an independent
-project? For a huge part, Ember's community does, and it does so in their free
-time. Countless contributors work on improvements, bug fixes and features in the
-early hours preceding their day jobs, on their weekends, their time-off - to
-bring forward a software project which can compete with other major frameworks.
-And this in itself is remarkable.
-
-This is why Ember truly is a framework of the community, by the community, for
-the community.
-
-And this community effort is also what keeps Ember visible in the current
-front-end ecosystem. In the end, who's stepping up to blog about latest
-features, to screencast debugging sessions, to demo Ember at their local meetup,
-to distribute Zoey stickers among their friends, to give talks on how to build
-an Ember app or to improve, fix and update any of the official online resources
-of Ember?
-
-It's not only the Ember Core or the Ember Learning Team who does all of this -
-it's also you and me and us.
-
-Taking the opportunity to change the way Ember is represented in the world to
-further its adoption is an open issue everyone can work on. Ember is still a
-somewhat hidden gem
-([8](http://blog.agilityworks.co.uk/our-blog/a-hidden-gem-ember-js)) and it
-keeps on "quietly shipping new cutting-edge features to its users"
-([9](https://twitter.com/sugarpirate_/status/923620576970731520)). But I don't
-believe it has to be this way with a little help from the community.
-
-Of course, there are those who already have a clear vision in mind right now and
-who are making consistent efforts to create online tutorials, write blog posts,
-give talks, send pull requests to the Ember.js website repository
-([10](https://github.com/emberjs/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Amerged))
-and much more without any prompting. What I'd wish for Ember's 2018 Roadmap
-though is to find ways to **lower the entry barriers** for newcomers to get
-started in their attempt to advocate Ember and to be creative on how to
-**encourage a sense of empowerment** in the wider community regarding outreach
-efforts.
+As any other open-source project, the development of Ember lives and thrives through the time and amount of work that is being put into it. In contrast to some other major JavaScript frameworks, Ember is not being backed up by one single major company - neither financially nor contribution-wise. Instead Ember's user base is diverse in its professional backgrounds and interests. And this makes Ember more independent and free to evolve according to real developer needs instead of company requirements which is an amazing advantage.
+
+But who's putting in the time and effort to maintain such an independent project? For a huge part, Ember's community does, and it does so in their free time. Countless contributors work on improvements, bug fixes and features in the early hours preceding their day jobs, on their weekends, their time-off - to bring forward a software project which can compete with other major frameworks. And this in itself is remarkable.
+
+This is why Ember truly is a framework of the community, by the community, for the community.
+
+And this community effort is also what keeps Ember visible in the current front-end ecosystem. In the end, who's stepping up to blog about latest features, to screencast debugging sessions, to demo Ember at their local meetup, to distribute Zoey stickers among their friends, to give talks on how to build an Ember app or to improve, fix and update any of the official online resources of Ember?
+
+It's not only the Ember Core or the Ember Learning Team who does all of this - it's also you and me and us.
+
+Taking the opportunity to change the way Ember is represented in the world to further its adoption is an open issue everyone can work on. Ember is still a somewhat hidden gem ([8](http://blog.agilityworks.co.uk/our-blog/a-hidden-gem-ember-js)) and it keeps on "quietly shipping new cutting-edge features to its users" ([9](https://twitter.com/sugarpirate_/status/923620576970731520)). But I don't believe it has to be this way with a little help from the community.
+
+Of course, there are those who already have a clear vision in mind right now and who are making consistent efforts to create online tutorials, write blog posts, give talks, send pull requests to the Ember.js website repository ([10](https://github.com/emberjs/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Amerged)) and much more without any prompting. What I'd wish for Ember's 2018 Roadmap though is to find ways to **lower the entry barriers** for newcomers to get started in their attempt to advocate Ember and to be creative on how to **encourage a sense of empowerment** in the wider community regarding outreach efforts.
 
 ## Closing the Visibility Gap
 
-I believe one of the biggest actions that could be taken to make contribution to
-anything that is outreach-related easier is by increasing the discoverability of
-discussion channels and already ongoing Github projects and related issues. On
-the Ember Community Slack chat, most notably the
-[#st-website](https://embercommunity.slack.com/messages/CAHEZTMBK/),
-[#wb-marketing](https://embercommunity.slack.com/messages/C36ETE3DK/) and
-[#topic-talks](https://embercommunity.slack.com/messages/C9RSE508J/) channels
-are great first points of contact for anyone who was interested in helping out
-with marketing efforts to find something to help out with. I believe making
-these channels more discoverable for new developers, e.g. from having a
-noticeable call-to-action on the Ember.js website ([11](https://emberjs.com/))
-or a dedicated, search-engine optimized landing page already goes a long way.
-
-The Learning Team and the community have already leveraged many amazing
-initiatives recently, including a massive technical upgrade of the official
-Guides which makes it even easier for developers to contribute
-([12](https://guides.emberjs.com/)), the release of a status board to keep
-potential contributors informed which initiatives are still ongoing and require
-help ([13](https://emberjs.com/statusboard/)), making blog content discoverable
-([14](https://github.com/emberjs/website/pull/3280)), creating a printable mini
-book about the framework
-([15](https://github.com/ember-learn/the-shortest-ember-book)), publishing
-project-related updates through a newsletter every single week
-([16](https://the-emberjs-times.ongoodbits.com/)) and many others. Speaking
-about these initiatives more openly and often might also draw interest of
-developers who don't know yet what to work on or what to start off with. In my
-opinion the increased leverage of the RFC (Request for Comments) process adopted
-by the Rust Community ([17](http://rust-lang.github.io/rfcs/)), Quest issues for
-breaking down major work packages on these official resources, and the creation
-of Strike Teams for agile collaboration will also deepen community interest,
-increase a sense of ownership of how decisions are made and allow people to
-succeed on their possibly first OSS issue easily.
-
-Also supporting both new and current speakers in finding events, a good talk
-topic and in prepping and rehearsing a presentation is another great way to
-encourage the community in their sense of empowerement. In fact, the Women
-Helping Women Program ([18](https://emberwomen.com/)) has already been doing an
-amazing job in supporting new speakers for years and it might be due to this
-very program, that Ember managed to achieve record numbers of excellent talks
-presented by women speakers at its conferences in the past. Encouraging even
-larger parts of the community to speak and highlight Ember allows many great
-talks to come: I'd love to see so many of the cool and new things that recently
-landed or are just on their way to land in Ember highlighted: This year's
-EmberConf Opening Keynote by Ember Core Team members Yehuda Katz & Tom Dale
-([19](https://www.youtube.com/watch?v=NhtpXs0ZtUc)) at EmberConf is among others
-([20](https://twitter.com/skillsmatter/status/984752827904950273),
-[21](https://www.youtube.com/watch?v=8D-O4cSteRk)) an inspiring example of this
-type of advocacy for Ember. I feel that beyond that there is a quite urgent need
-for "introduction" type talks which are appealing to developers of any
-experience level and any (JavaScript) background. Features of Ember that might
-have already been around for a while and which have become obvious to the
-regular Ember user still need to be highlighted to audiences who are not that
-familiar with Ember yet on a regular basis. Therefore I'm confident supporting
-speakers in promoting their own "Why Ember" type of presentations to events
-outside of the Ember ecosystem is one of the most useful measures we as a
-community can take to advocate Ember as a framework.
+I believe one of the biggest actions that could be taken to make contribution to anything that is outreach-related easier is by increasing the discoverability of discussion channels and already ongoing Github projects and related issues. On the Ember Community Slack chat, most notably the [#st-website](https://embercommunity.slack.com/messages/CAHEZTMBK/), [#wb-marketing](https://embercommunity.slack.com/messages/C36ETE3DK/) and [#topic-talks](https://embercommunity.slack.com/messages/C9RSE508J/) channels are great first points of contact for anyone who was interested in helping out with marketing efforts to find something to help out with. I believe making these channels more discoverable for new developers, e.g. from having a noticeable call-to-action on the Ember.js website ([11](https://emberjs.com/)) or a dedicated, search-engine optimized landing page already goes a long way.
+
+The Learning Team and the community have already leveraged many amazing initiatives recently, including a massive technical upgrade of the official Guides which makes it even easier for developers to contribute ([12](https://guides.emberjs.com/)), the release of a status board to keep potential contributors informed which initiatives are still ongoing and require help ([13](https://emberjs.com/statusboard/)), making blog content discoverable ([14](https://github.com/emberjs/website/pull/3280)), creating a printable mini book about the framework ([15](https://github.com/ember-learn/the-shortest-ember-book)), publishing project-related updates through a newsletter every single week ([16](https://the-emberjs-times.ongoodbits.com/)) and many others. Speaking about these initiatives more openly and often might also draw interest of developers who don't know yet what to work on or what to start off with. In my opinion the increased leverage of the RFC (Request for Comments) process adopted by the Rust Community ([17](http://rust-lang.github.io/rfcs/)), Quest issues for breaking down major work packages on these official resources, and the creation of Strike Teams for agile collaboration will also deepen community interest, increase a sense of ownership of how decisions are made and allow people to succeed on their possibly first OSS issue easily.
+
+Also supporting both new and current speakers in finding events, a good talk topic and in prepping and rehearsing a presentation is another great way to encourage the community in their sense of empowerement. In fact, the Women Helping Women Program ([18](https://emberwomen.com/)) has already been doing an amazing job in supporting new speakers for years and it might be due to this very program, that Ember managed to achieve record numbers of excellent talks presented by women speakers at its conferences in the past. Encouraging even larger parts of the community to speak and highlight Ember allows many great talks to come: I'd love to see so many of the cool and new things that recently landed or are just on their way to land in Ember highlighted: This year's EmberConf Opening Keynote by Ember Core Team members Yehuda Katz & Tom Dale ([19](https://www.youtube.com/watch?v=NhtpXs0ZtUc)) at EmberConf is among others ([20](https://twitter.com/skillsmatter/status/984752827904950273), [21](https://www.youtube.com/watch?v=8D-O4cSteRk)) an inspiring example of this type of advocacy for Ember. I feel that beyond that there is a quite urgent need for "introduction" type talks which are appealing to developers of any experience level and any (JavaScript) background. Features of Ember that might have already been around for a while and which have become obvious to the regular Ember user still need to be highlighted to audiences who are not that familiar with Ember yet on a regular basis. Therefore I'm confident supporting speakers in promoting their own "Why Ember" type of presentations to events outside of the Ember ecosystem is one of the most useful measures we as a community can take to advocate Ember as a framework.
 
 ## Wishing Upon a Vocal Community
 
-These are some of the ideas that came to my mind when thinking about what I'd
-wish for Ember in 2018. I'd like to see Ember's community grow even further and
-I believe one major way to achieve this goal is by improving its visibility -
-the degree by which it is seen by those who are already becoming part of the
-community and also by those outside of it.
-
-In my opinion more explicit call-to-actions can have a big impact on the sense
-of community empowerment to make Ember visible: Being vocal about current
-outreach efforts that require community help, making those initiatives more
-discoverable and prompting the community to take action - just as has been done
-in this very call for blog posts
-([22](https://www.emberjs.com/blog/2018/05/02/ember-2018-roadmap-call-for-posts.html)) -
-are some of the options that I believe should be leveraged even further.
-
-Ember is still a hidden gem but I'm confident that this can and will change. And
-with a little encouragement I believe there's no one who could do a better job
-at this than us - the community.
+These are some of the ideas that came to my mind when thinking about what I'd wish for Ember in 2018. I'd like to see Ember's community grow even further and I believe one major way to achieve this goal is by improving its visibility - the degree by which it is seen by those who are already becoming part of the community and also by those outside of it.
+
+In my opinion more explicit call-to-actions can have a big impact on the sense of community empowerment to make Ember visible: Being vocal about current outreach efforts that require community help, making those initiatives more discoverable and prompting the community to take action - just as has been done in this very call for blog posts ([22](https://www.emberjs.com/blog/2018/05/02/ember-2018-roadmap-call-for-posts.html)) - are some of the options that I believe should be leveraged even further.
+
+Ember is still a hidden gem but I'm confident that this can and will change. And with a little encouragement I believe there's no one who could do a better job at this than us - the community.
diff --git a/src/posts/2018-06-05-ember-component-playground.md b/src/posts/2018-06-05-ember-component-playground.md
index 7704b532bb..f54dccb0f0 100644
--- a/src/posts/2018-06-05-ember-component-playground.md
+++ b/src/posts/2018-06-05-ember-component-playground.md
@@ -2,10 +2,7 @@
 title: "Autodiscovery for the Ember.js component playground"
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek introduces a mechanism for automatically discovering new
-  components in Ember.js applications and showing them in an ember-freestyle
-  playground."
+description: "Tobias Bieniek introduces a mechanism for automatically discovering new components in Ember.js applications and showing them in an ember-freestyle playground."
 tags: ember
 tagline: |
   <p>In our <a href="/blog/2018/01/24/ember-freestyle">previous post</a> about <a href="http://ember-freestyle.com/"><code>ember-freestyle</code></a> we have setup a component playground for our Ember.js application. In this post we will discuss how to implement &quot;convention over configuration&quot; for it by automatically discovering new components and showing them in the playground.</p>
@@ -13,8 +10,7 @@ tagline: |
 
 ## Status Quo
 
-You may remember that last time we closed with our `freestyle.hbs` template
-looking roughly like this:
+You may remember that last time we closed with our `freestyle.hbs` template looking roughly like this:
 
 ```handlebars
 {% raw %}
@@ -38,13 +34,9 @@ looking roughly like this:
 {% endraw %}
 ```
 
-If we now start to add subsections for all the components in our app you can
-imagine that our `freestyle.hbs` would soon grow out of proportion. As with any
-other template in Ember.js we can tackle that problem by extracting components.
+If we now start to add subsections for all the components in our app you can imagine that our `freestyle.hbs` would soon grow out of proportion. As with any other template in Ember.js we can tackle that problem by extracting components.
 
-In this case we can create a
-`lib/freestyle/app/templates/components/usage/styled-button.hbs` file that looks
-like this:
+In this case we can create a `lib/freestyle/app/templates/components/usage/styled-button.hbs` file that looks like this:
 
 ```handlebars
 {% raw %}
@@ -68,28 +60,17 @@ and in the `freestyle.hbs` template we use the following snippet instead:
 {% endraw %}
 ```
 
-Now we would still have to add a subsection and a component for every component
-in our app that we want to include in the component playground, but overall the
-situation has gotten a lot more manageable.
+Now we would still have to add a subsection and a component for every component in our app that we want to include in the component playground, but overall the situation has gotten a lot more manageable.
 
-But there is always a way to improve the current situation so let's play around
-a little...
+But there is always a way to improve the current situation so let's play around a little...
 
 ## Autodiscovery
 
-What if we could ask Ember what "usage components" it knows about and then
-render them automatically in the `freestyle.hbs` template...? 🤔
+What if we could ask Ember what "usage components" it knows about and then render them automatically in the `freestyle.hbs` template...? 🤔
 
-It turns out the `loader.js` dependency that every Ember.js project has provides
-us with an API to do exactly that. If we `import require from 'require';` and
-then look at `require.entries` we will see a map of all the known module names
-in your app and their corresponding module functions. We only care about the
-module names though so we can use `Object.keys(require.entries)` to get a list
-of all those module names.
+It turns out the `loader.js` dependency that every Ember.js project has provides us with an API to do exactly that. If we `import require from 'require';` and then look at `require.entries` we will see a map of all the known module names in your app and their corresponding module functions. We only care about the module names though so we can use `Object.keys(require.entries)` to get a list of all those module names.
 
-Next, we need to filter the list so that it only includes our "usage
-components". We can do so by using the `.filter()` method and checking for the
-right prefix:
+Next, we need to filter the list so that it only includes our "usage components". We can do so by using the `.filter()` method and checking for the right prefix:
 
 ```js
 {% raw %}
@@ -111,14 +92,9 @@ This should produce a list that looks roughly like this:
 {% endraw %}
 ```
 
-To be able to use those as component names in our template we will have to do a
-few more things though. We will need to strip the
-`myapp/templates/components/usage/` prefix and then we should sort the list
-alphabetically, so that the order in the component playground is more
-predictable.
+To be able to use those as component names in our template we will have to do a few more things though. We will need to strip the `myapp/templates/components/usage/` prefix and then we should sort the list alphabetically, so that the order in the component playground is more predictable.
 
-In the end our `lib/freestyle/controllers/freestyle.js` will look roughly like
-this:
+In the end our `lib/freestyle/controllers/freestyle.js` will look roughly like this:
 
 ```js
 {% raw %}
@@ -143,10 +119,7 @@ function findUsageComponents() {
 {% endraw %}
 ```
 
-{% raw %} With that JavaScript code out of the way we can focus on our template.
-Here, we now have a `components` list available with the names of all our "usage
-components". As usual with lists we will use a `{{#each}}` block to iterate over
-it: {% endraw %}
+{% raw %} With that JavaScript code out of the way we can focus on our template. Here, we now have a `components` list available with the names of all our "usage components". As usual with lists we will use a `{{#each}}` block to iterate over it: {% endraw %}
 
 ```handlebars
 {% raw %}
@@ -166,13 +139,8 @@ it: {% endraw %}
 {% endraw %}
 ```
 
-If we visit the `/freestyle` route now, we should see a list of all our "usage
-components" that Ember.js knows about and usage examples for all of them.
+If we visit the `/freestyle` route now, we should see a list of all our "usage components" that Ember.js knows about and usage examples for all of them.
 
 ## Summary
 
-Just like Ember.js is able to automatically find components, models, and other
-modules when you put them in the right folder, our component playground can now
-do the same thing. "Convention over Configuration" saves us from the extra work
-of having to manually maintain the `freestyle.hbs` template by discovering the
-content automatically.
+Just like Ember.js is able to automatically find components, models, and other modules when you put them in the right folder, our component playground can now do the same thing. "Convention over Configuration" saves us from the extra work of having to manually maintain the `freestyle.hbs` template by discovering the content automatically.
diff --git a/src/posts/2018-06-11-actix.md b/src/posts/2018-06-11-actix.md
index 4051cc49aa..4e629c382f 100644
--- a/src/posts/2018-06-11-actix.md
+++ b/src/posts/2018-06-11-actix.md
@@ -2,9 +2,7 @@
 title: "actix – an actor framework for the Rust programming language"
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek gives an overview of actix, an actor framework written in the
-  Rust programming language."
+description: "Tobias Bieniek gives an overview of actix, an actor framework written in the Rust programming language."
 tags: rust
 og:
   image: /assets/images/posts/2018-06-11-actix/og-image.jpg
@@ -16,47 +14,23 @@ tagline: |
 
 What is Rust?
 
-Aside from being "an iron oxide" according to [Wikipedia][wikipedia], Rust is
-also the name of a programming language that was originally invented by Graydon
-Hoare back in 2006. You can think about it as an interesting mix of high-level
-languages like JavaScript or Ruby and low-level high-performance languages like
-C++.
-
-Similar to C++ it is a compiled language without a garbage collector. The fact
-that it usually uses LLVM to compile to machine code means that a lot of the
-optimizations that were developed to compile C/C++ code can also be applied to
-Rust programs.
-
-Similar to JavaScript or Python the language often feels more high-level than
-C/C++, and it has a built-in dependency manager called `cargo`. This is somewhat
-similar to `npm` in JavaScript or `bundler` in Ruby, with the main difference
-that `cargo` is also used to build and test your applications and libraries.
-
-The main advantage over all the other languages is safety. The Rust compiler is
-often quite strict on what data you are allowed to access at what point in the
-application logic, because it knows about concepts like threads and potential
-race conditions. This might not seem relevant to JavaScript developers, but even
-there with nested callbacks you might easily run into a situation where the
-thing you're trying to access has been deleted already. This issue is impossible
-with Rust.
-
-Why would you use it? It is very fast, it can be embedded into scripting
-languages if raw speed is needed, it can compile to WebAssembly, and most of
-all, it is much safer than C++, which would also be a candidate for all the
-previous points.
+Aside from being "an iron oxide" according to [Wikipedia][wikipedia], Rust is also the name of a programming language that was originally invented by Graydon Hoare back in 2006. You can think about it as an interesting mix of high-level languages like JavaScript or Ruby and low-level high-performance languages like C++.
+
+Similar to C++ it is a compiled language without a garbage collector. The fact that it usually uses LLVM to compile to machine code means that a lot of the optimizations that were developed to compile C/C++ code can also be applied to Rust programs.
+
+Similar to JavaScript or Python the language often feels more high-level than C/C++, and it has a built-in dependency manager called `cargo`. This is somewhat similar to `npm` in JavaScript or `bundler` in Ruby, with the main difference that `cargo` is also used to build and test your applications and libraries.
+
+The main advantage over all the other languages is safety. The Rust compiler is often quite strict on what data you are allowed to access at what point in the application logic, because it knows about concepts like threads and potential race conditions. This might not seem relevant to JavaScript developers, but even there with nested callbacks you might easily run into a situation where the thing you're trying to access has been deleted already. This issue is impossible with Rust.
+
+Why would you use it? It is very fast, it can be embedded into scripting languages if raw speed is needed, it can compile to WebAssembly, and most of all, it is much safer than C++, which would also be a candidate for all the previous points.
 
 How to get started? Follow the instructions at [rustup.rs][rustup]
 
 ## Actors
 
-The "actor model" is the main primitive that powers the [Erlang] programming
-language and its descendant, [Elixir]. It describes a programming model that
-simplifies the development of concurrent and multi-threaded applications or even
-applications that run distributed on multiple machines.
+The "actor model" is the main primitive that powers the [Erlang] programming language and its descendant, [Elixir]. It describes a programming model that simplifies the development of concurrent and multi-threaded applications or even applications that run distributed on multiple machines.
 
-An actor is a thing that can only be interacted with using "messages". A message
-can basically be anything that the actor can understand and in response to a
-message an actor is allowed to do several things, including:
+An actor is a thing that can only be interacted with using "messages". A message can basically be anything that the actor can understand and in response to a message an actor is allowed to do several things, including:
 
 - send a response
 - send messages to other actors
@@ -82,24 +56,15 @@ class CounterActor {
 {% endraw %}
 ```
 
-The `CounterActor` class in this example is initialized with an internal state
-called `count` that is set to zero and it responds to `plus-one` messages by
-increasing the `count` state and returning the new value.
+The `CounterActor` class in this example is initialized with an internal state called `count` that is set to zero and it responds to `plus-one` messages by increasing the `count` state and returning the new value.
 
-The complexity of actors is relatively low, and that is because the complexity
-is usually hidden in the actor frameworks that are used to run these types of
-primitives in the end. One example of such an actor framework is [actix], which
-we will have a closer look at now.
+The complexity of actors is relatively low, and that is because the complexity is usually hidden in the actor frameworks that are used to run these types of primitives in the end. One example of such an actor framework is [actix], which we will have a closer look at now.
 
 ## actix
 
-[actix] is the low-level actor framework that powers [actix-web][actix-web], a
-[high-performance][performance] web framework for the [Rust][rust] programming
-language.
+[actix] is the low-level actor framework that powers [actix-web][actix-web], a [high-performance][performance] web framework for the [Rust][rust] programming language.
 
-While [actix-web][actix-web] is interesting and worth another blog post, we will
-focus on the low-level primitive [actix][actix] for now as it is vital to
-understanding the higher level concepts.
+While [actix-web][actix-web] is interesting and worth another blog post, we will focus on the low-level primitive [actix][actix] for now as it is vital to understanding the higher level concepts.
 
 To get started with actix, let's port our `CounterActor` above to Rust:
 
@@ -140,39 +105,19 @@ impl Handler<PlusOne> for CounterActor {
 }
 ```
 
-Since Rust is a typed language all structures need to be declared upfront. In
-the snippet above we first import all the necessary things from the
-`actix::prelude` module, and then we define how a `PlusOne` message should look
-like. In the JavaScript implementation the `message` had a `type` property, but
-since we have a strict type system available in Rust there is no need to
-explicitly declare that. That leaves us with an empty `PlusOne` message,
-indicated by the `struct PlusOne` which does not have any content. The message
-does have a `Result` type though, defined by `type Result = u32;` which means
-"unsigned 32 bit integer".
-
-The `CounterActor` implementation is another `struct` which is roughly similar
-to a `class` in JavaScript. It does implement several "traits", which is very
-roughly what are called "interfaces" in e.g. TypeScript or Java.
-
-The `Actor` trait defines that `CounterActor` is in fact an actor that complies
-with the necessary interface to be run by the actix framework. The `Context`
-type declaration can be used for more advanced implementations, but for now we
-can use the default implementation that is provided by actix itself.
-
-Finally we implement the `Handler` trait for the `PlusOne` message that we
-defined earlier. In the `handle()` method we increment the `count` state and
-then return the new value to tell actix that this is our response to the
-message.
+Since Rust is a typed language all structures need to be declared upfront. In the snippet above we first import all the necessary things from the `actix::prelude` module, and then we define how a `PlusOne` message should look like. In the JavaScript implementation the `message` had a `type` property, but since we have a strict type system available in Rust there is no need to explicitly declare that. That leaves us with an empty `PlusOne` message, indicated by the `struct PlusOne` which does not have any content. The message does have a `Result` type though, defined by `type Result = u32;` which means "unsigned 32 bit integer".
+
+The `CounterActor` implementation is another `struct` which is roughly similar to a `class` in JavaScript. It does implement several "traits", which is very roughly what are called "interfaces" in e.g. TypeScript or Java.
+
+The `Actor` trait defines that `CounterActor` is in fact an actor that complies with the necessary interface to be run by the actix framework. The `Context` type declaration can be used for more advanced implementations, but for now we can use the default implementation that is provided by actix itself.
+
+Finally we implement the `Handler` trait for the `PlusOne` message that we defined earlier. In the `handle()` method we increment the `count` state and then return the new value to tell actix that this is our response to the message.
 
 ### Running our `CounterActor`
 
-While building the actor was relatively easy, running it is unfortunately still
-a little hard while Rust figures out its version of `async/await` (see
-[`futures-await`][futures-await]).
+While building the actor was relatively easy, running it is unfortunately still a little hard while Rust figures out its version of `async/await` (see [`futures-await`][futures-await]).
 
-The following code will startup our actor, send a message, wait for the
-response, send another message, wait for the response and finally exit the
-application:
+The following code will startup our actor, send a message, wait for the response, send another message, wait for the response and finally exit the application:
 
 ```rust
 let sys = actix::System::new("test");
@@ -198,59 +143,30 @@ Arbiter::handle().spawn(result);
 sys.run();
 ```
 
-The first thing to do when using actix actors is to set up a [`System`][system],
-that handles all those actor interactions for us. We do so by calling
-`actix::System::new()` and passing it a name.
-
-Next we start an [`Arbiter`][artiter] in a new thread, that runs our
-`CounterActor`. If that sounds like a foreign language to you, don't worry, I
-had the same feeling at first. For now all you need to know is that `Syn` means
-that it is running in a separate thread, and that the `Arbiter` is the thing
-that controls that thread.
-
-The `Arbiter::start()` call returns an `Addr` (short for address), that we can
-use to talk to the actor. The `Addr` struct has methods like `send()` that can
-be used to send messages to the actor and receive their responses.
-
-Rust is very strict around data ownership, and the "borrow checker" makes sure
-that data access can only happen in safe ways. Since we use the `counter`
-variable for the first `send()` call, we are (at least currently) not allowed to
-reuse it inside the callback. Instead we need to create a `clone()` and use that
-one instead.
-
-The large code structure in the middle of the snippet looks roughly like a
-Promise-chain in JavaScript, and it is exactly that. The `counter.send()` call
-returns what Rust calls a `Future`. A `Future` (like a `Promise`) has several
-methods that can be used to assemble a sort of pipeline of how to handle the
-result that the `Future` will at some point return.
-
-In this specific case we use `.and_then()` to wait for the result of the
-`PlusOne` message, then print it out to the console, and then fire off another
-`PlusOne` message. Once that second message has returned we print the response
-again and then use a special system arbiter call to exit the process.
-
-The major difference between a `Promise` in JavaScript and a `Future` in Rust is
-that a `Promise` automatically runs when it is created, but a `Future` needs to
-be started explicitly. This difference exists for performance reasons, and
-because in JavaScript there is no such thing as running on different threads.
-
-To start the `Future` that we have assembled we use the
-`Arbiter::handle().spawn()` function, and then finally start the `System` once
-everything is wired up correctly to block the current thread until all actors
-have finished running.
+The first thing to do when using actix actors is to set up a [`System`][system], that handles all those actor interactions for us. We do so by calling `actix::System::new()` and passing it a name.
+
+Next we start an [`Arbiter`][artiter] in a new thread, that runs our `CounterActor`. If that sounds like a foreign language to you, don't worry, I had the same feeling at first. For now all you need to know is that `Syn` means that it is running in a separate thread, and that the `Arbiter` is the thing that controls that thread.
+
+The `Arbiter::start()` call returns an `Addr` (short for address), that we can use to talk to the actor. The `Addr` struct has methods like `send()` that can be used to send messages to the actor and receive their responses.
+
+Rust is very strict around data ownership, and the "borrow checker" makes sure that data access can only happen in safe ways. Since we use the `counter` variable for the first `send()` call, we are (at least currently) not allowed to reuse it inside the callback. Instead we need to create a `clone()` and use that one instead.
+
+The large code structure in the middle of the snippet looks roughly like a Promise-chain in JavaScript, and it is exactly that. The `counter.send()` call returns what Rust calls a `Future`. A `Future` (like a `Promise`) has several methods that can be used to assemble a sort of pipeline of how to handle the result that the `Future` will at some point return.
+
+In this specific case we use `.and_then()` to wait for the result of the `PlusOne` message, then print it out to the console, and then fire off another `PlusOne` message. Once that second message has returned we print the response again and then use a special system arbiter call to exit the process.
+
+The major difference between a `Promise` in JavaScript and a `Future` in Rust is that a `Promise` automatically runs when it is created, but a `Future` needs to be started explicitly. This difference exists for performance reasons, and because in JavaScript there is no such thing as running on different threads.
+
+To start the `Future` that we have assembled we use the `Arbiter::handle().spawn()` function, and then finally start the `System` once everything is wired up correctly to block the current thread until all actors have finished running.
 
 ## Summary
 
-This blog post covered some of the basic concepts of writing actors using the
-actix framework for Rust. In a follow-up post we will look into writing a small
-TCP client using these primitives, which can for example be used to forward
-traffic to websocket clients or just log the received messages to the console.
+This blog post covered some of the basic concepts of writing actors using the actix framework for Rust. In a follow-up post we will look into writing a small TCP client using these primitives, which can for example be used to forward traffic to websocket clients or just log the received messages to the console.
 
 [rustup]: https://rustup.rs/
 [wikipedia]: https://en.wikipedia.org/wiki/Rust
 [erlang]: https://www.erlang.org/
-[performance]:
-  https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext
+[performance]: https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext
 [actix-web]: https://github.com/actix/actix-web
 [futures-await]: https://github.com/alexcrichton/futures-await
 [system]: https://actix.rs/actix/actix/struct.System.html
diff --git a/src/posts/2018-06-18-intl-polyfill-loading.md b/src/posts/2018-06-18-intl-polyfill-loading.md
index b957f7264a..843a566fea 100644
--- a/src/posts/2018-06-18-intl-polyfill-loading.md
+++ b/src/posts/2018-06-18-intl-polyfill-loading.md
@@ -2,9 +2,7 @@
 title: "ember-intl data loading patterns"
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek shows how to load the necessary polyfills for the Intl API in
-  older browsers most effectively when using ember-intl."
+description: "Tobias Bieniek shows how to load the necessary polyfills for the Intl API in older browsers most effectively when using ember-intl."
 tags: ember
 tagline: |
   <p>At Mainmatter we ❤️ <a href="https://github.com/ember-intl/ember-intl">ember-intl</a> and use it for all our projects where translations or other localizations are needed. ember-intl is based on the native <a href="https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Intl">Intl APIs</a> that were introduced in <a href="https://caniuse.com/#feat=internationalization">all newer browsers</a> a while ago. Unfortunately some users are still using browsers that don't support them and this blog post will show you our preferred way to load the necessary polyfill and the associated data.</p>
@@ -12,16 +10,9 @@ tagline: |
 
 ## Loading Translations
 
-Let's first start with how translations are loaded in ember-intl. By default
-ember-intl will bundle all translations into your `app.js` file, which works
-okay for small projects, but if you want to support more than 2-3 languages and
-have a significant number of translations this will quickly bloat your bundle
-size out of proportion.
+Let's first start with how translations are loaded in ember-intl. By default ember-intl will bundle all translations into your `app.js` file, which works okay for small projects, but if you want to support more than 2-3 languages and have a significant number of translations this will quickly bloat your bundle size out of proportion.
 
-The solution to this problem is "side-loading". After you have determined what
-language/locale your users would like to see you load the translations using an
-AJAX request and after that has finished you call `setLocale()` to activate the
-new translations. It looks roughly like this:
+The solution to this problem is "side-loading". After you have determined what language/locale your users would like to see you load the translations using an AJAX request and after that has finished you call `setLocale()` to activate the new translations. It looks roughly like this:
 
 ```js
 {% raw %}
@@ -38,17 +29,9 @@ async beforeModel() {
 {% endraw %}
 ```
 
-To make this work we need to tell ember-intl that it should no longer bundle the
-translations in the `app.js` file, and instead it should write them out as JSON
-files into our `dist` folder. We can do so by opening the `config/ember-intl.js`
-file, and adjusting the `publicOnly` property to `true`. If we now call
-`ember build` and look at the `dist` folder we will see a `translations`
-subfolder including JSON files for all existing translations.
+To make this work we need to tell ember-intl that it should no longer bundle the translations in the `app.js` file, and instead it should write them out as JSON files into our `dist` folder. We can do so by opening the `config/ember-intl.js` file, and adjusting the `publicOnly` property to `true`. If we now call `ember build` and look at the `dist` folder we will see a `translations` subfolder including JSON files for all existing translations.
 
-We would like to make our translation loading code look a little simpler from
-the outside, so what we could do is add a `loadTranslations()` method to the
-`intl` service itself. For that we create a `myapp/app/services/intl.js` file
-like this:
+We would like to make our translation loading code look a little simpler from the outside, so what we could do is add a `loadTranslations()` method to the `intl` service itself. For that we create a `myapp/app/services/intl.js` file like this:
 
 ```js
 {% raw %}
@@ -79,17 +62,11 @@ async beforeModel() {
 {% endraw %}
 ```
 
-If we now open our app in the browser and look at the "Network" tab of the
-browser we should see the app making an AJAX request for the translations before
-it starts. 🎉
+If we now open our app in the browser and look at the "Network" tab of the browser we should see the app making an AJAX request for the translations before it starts. 🎉
 
 ## Loading the Intl.js polyfill
 
-As mentioned in the intro
-[some browsers](https://caniuse.com/#feat=internationalization) need a polyfill
-for the new `Intl` APIs. ember-intl makes this easy for us as it supports an
-`autoPolyfill` option in its config file. Setting this option to `true` will
-automatically add script tags like this to your `index.html` file:
+As mentioned in the intro [some browsers](https://caniuse.com/#feat=internationalization) need a polyfill for the new `Intl` APIs. ember-intl makes this easy for us as it supports an `autoPolyfill` option in its config file. Setting this option to `true` will automatically add script tags like this to your `index.html` file:
 
 ```html
 <script src="/assets/intl/intl.min.js"></script>
@@ -98,19 +75,11 @@ automatically add script tags like this to your `index.html` file:
 <script src="/assets/intl/locales/fr.js"></script>
 ```
 
-That is a nice first step, but should not be used for any real user-facing apps.
-The reason for this is that it adds a significant number of additional HTTP
-requests to the startup time of your app, and those requests aren't even that
-small. `intl.min.js` downloads roughly 40 kB and each locale script another 25
-kB of uncompressed JavaScript code. It would be much better if we would only
-load them if the browser actually needed the polyfill...
+That is a nice first step, but should not be used for any real user-facing apps. The reason for this is that it adds a significant number of additional HTTP requests to the startup time of your app, and those requests aren't even that small. `intl.min.js` downloads roughly 40 kB and each locale script another 25 kB of uncompressed JavaScript code. It would be much better if we would only load them if the browser actually needed the polyfill...
 
-Let's turn off the `autoPolyfill` option and implement lazy loading of the
-polyfill files instead.
+Let's turn off the `autoPolyfill` option and implement lazy loading of the polyfill files instead.
 
-The first thing we need for this is a function that downloads JS code and then
-runs it. We could hack something together with `fetch()` and `eval()`, but there
-is a better solution:
+The first thing we need for this is a function that downloads JS code and then runs it. We could hack something together with `fetch()` and `eval()`, but there is a better solution:
 
 ```js
 {% raw %}
@@ -125,11 +94,9 @@ function loadJS(url) {
 {% endraw %}
 ```
 
-The above function creates a `<script>` tag, sets the passed in `url` on it, and
-returns a `Promise` that resolves once the script has loaded.
+The above function creates a `<script>` tag, sets the passed in `url` on it, and returns a `Promise` that resolves once the script has loaded.
 
-With the `loadJS` helper function in place we can add a `loadPolyfill()` method
-to our `intl` service:
+With the `loadJS` helper function in place we can add a `loadPolyfill()` method to our `intl` service:
 
 ```js
 {% raw %}
@@ -157,19 +124,12 @@ async beforeModel() {
 {% endraw %}
 ```
 
-If you visit the app in your regular browser now you should _not_ see any
-request for the `intl.min.js` file. But if you open the app in IE10 (e.g. via
-<https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/>) you should
-see the polyfill being loaded.
+If you visit the app in your regular browser now you should _not_ see any request for the `intl.min.js` file. But if you open the app in IE10 (e.g. via <https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/>) you should see the polyfill being loaded.
 
-Unfortunately we're not done yet. While we have loaded the polyfill correctly,
-we also need to load the locale data for the polyfill depending on what locale
-the user chooses. For that reason we implement two more methods on the `intl`
-service:
+Unfortunately we're not done yet. While we have loaded the polyfill correctly, we also need to load the locale data for the polyfill depending on what locale the user chooses. For that reason we implement two more methods on the `intl` service:
 
 - a `loadPolyfillData()` method
-- a `loadLocale()` method that combines `loadTranslations()` and
-  `loadPolyfillData()`
+- a `loadLocale()` method that combines `loadTranslations()` and `loadPolyfillData()`
 
 ```js
 {% raw %}
@@ -204,21 +164,12 @@ export default IntlService.extend({
 {% endraw %}
 ```
 
-If we now switch our `application` route implementation from
-`loadTranslations()` to `loadLocale()` we should see the locale data being
-requested in IE10.
+If we now switch our `application` route implementation from `loadTranslations()` to `loadLocale()` we should see the locale data being requested in IE10.
 
-In case you're wondering what "locale data" actually means: it includes
-information for the Intl.js polyfill on how to format dates, time and numbers
-and several other things that are handled in a locale-aware way in the Intl API.
+In case you're wondering what "locale data" actually means: it includes information for the Intl.js polyfill on how to format dates, time and numbers and several other things that are handled in a locale-aware way in the Intl API.
 
 ## Summary
 
-In this blog post we have learned how to reduce our bundle size in several ways
-when using the [ember-intl][ember-intl] addon. We are now loading only the code
-and data that we actually need for the specific browser. Most users don't pay
-the extra cost of loading the polyfill and related data, and for the browsers
-that do need it, it's available on demand.
+In this blog post we have learned how to reduce our bundle size in several ways when using the [ember-intl][ember-intl] addon. We are now loading only the code and data that we actually need for the specific browser. Most users don't pay the extra cost of loading the polyfill and related data, and for the browsers that do need it, it's available on demand.
 
-If you have any questions about these patterns or need help implementing them in
-your apps feel free to [contact us](/contact/).
+If you have any questions about these patterns or need help implementing them in your apps feel free to [contact us](/contact/).
diff --git a/src/posts/2018-06-27-actix-tcp-client.md b/src/posts/2018-06-27-actix-tcp-client.md
index 708bf9cf30..ad6a4b7440 100644
--- a/src/posts/2018-06-27-actix-tcp-client.md
+++ b/src/posts/2018-06-27-actix-tcp-client.md
@@ -2,9 +2,7 @@
 title: "actix – a basic TCP client"
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek shows how actix, the actor framework written in Rust, can be
-  used to build a basic TCP client."
+description: "Tobias Bieniek shows how actix, the actor framework written in Rust, can be used to build a basic TCP client."
 tags: rust
 og:
   image: /assets/images/posts/2018-06-27-actix-tcp-client/og-image.jpg
@@ -12,24 +10,15 @@ tagline: |
   <p>In our <a href="/blog/2018/06/11/actix/">last post</a> about <a href="https://actix.rs/">actix</a> we introduced you to the <a href="https://rust-lang.org/">Rust</a> programming language and the actix actor framework. This week we will build a basic TCP client with actix.</p>
 ---
 
-**Since we have written this blog post actix 0.6 was released with several
-breaking changes. The content of this blog post is conceptually still relevant
-though and the code examples should work fine if you make sure to use the
-correct dependency versions.**
+**Since we have written this blog post actix 0.6 was released with several breaking changes. The content of this blog post is conceptually still relevant though and the code examples should work fine if you make sure to use the correct dependency versions.**
 
 ## The Goal
 
-Our goal in this blog post is to build an `Actor` that connects to a certain TCP
-server, listens for new messages and forwards them to another `recipient` actor.
-For simplicity we'll assume that the server is using a line break after each
-message.
+Our goal in this blog post is to build an `Actor` that connects to a certain TCP server, listens for new messages and forwards them to another `recipient` actor. For simplicity we'll assume that the server is using a line break after each message.
 
 ## Project Setup
 
-In our last post we explained that the easiest solution to install Rust is
-currently [rustup.rs](https://rustup.rs/). Once you have followed the
-instructions there you should have access to the `cargo` build tool on your
-command line.
+In our last post we explained that the easiest solution to install Rust is currently [rustup.rs](https://rustup.rs/). Once you have followed the instructions there you should have access to the `cargo` build tool on your command line.
 
 Creating a new project for Rust is easy with `cargo`:
 
@@ -37,15 +26,9 @@ Creating a new project for Rust is easy with `cargo`:
 cargo new actix-tcp-example
 ```
 
-This will create a new binary project for you with the basic file structures
-already in place. The `cargo new` command also supports a `--lib` option, which
-will create a library project instead. The difference between them is that
-binary projects have a `main()` function and get compiled to executables, while
-library projects are used to share code and functionality at
-[crates.io](https://crates.io).
+This will create a new binary project for you with the basic file structures already in place. The `cargo new` command also supports a `--lib` option, which will create a library project instead. The difference between them is that binary projects have a `main()` function and get compiled to executables, while library projects are used to share code and functionality at [crates.io](https://crates.io).
 
-Fun fact: did you know that [crates.io][crates] is an open-source project itself
-and built with Rust and [Ember.js][ember]?
+Fun fact: did you know that [crates.io][crates] is an open-source project itself and built with Rust and [Ember.js][ember]?
 
 [crates]: https://github.com/rust-lang/crates.io
 [ember]: https://emberjs.com/
@@ -56,29 +39,19 @@ Now that we have created the project let's see if it runs:
 cargo run
 ```
 
-If everything went well you should see `cargo` compiling the project and
-afterwards running it, resulting in "Hello, world!" being printed in your
-Terminal.
+If everything went well you should see `cargo` compiling the project and afterwards running it, resulting in "Hello, world!" being printed in your Terminal.
 
 ## The Actor
 
-Before we can start to implement our TCP client actor we need to tell `cargo`
-about the `actix` dependency. For that we open the `Cargo.toml` file in the
-project and add the following line _after_ the `[dependencies]` declaration:
+Before we can start to implement our TCP client actor we need to tell `cargo` about the `actix` dependency. For that we open the `Cargo.toml` file in the project and add the following line _after_ the `[dependencies]` declaration:
 
 ```toml
 actix = "0.5"
 ```
 
-Now, whenever we build the project again, `cargo` will make sure to download the
-necessary dependencies from crates.io and build them before building the actual
-project. `cargo` is using a build cache though, so don't worry if it takes a
-long time if you first try to build it. The following builds should be much
-faster.
+Now, whenever we build the project again, `cargo` will make sure to download the necessary dependencies from crates.io and build them before building the actual project. `cargo` is using a build cache though, so don't worry if it takes a long time if you first try to build it. The following builds should be much faster.
 
-It's time to implement a basic `Actor` as the base for our experiment. We don't
-want to worry too much about project organization for now, so let's implement it
-right in the `src/main.rs` file:
+It's time to implement a basic `Actor` as the base for our experiment. We don't want to worry too much about project organization for now, so let's implement it right in the `src/main.rs` file:
 
 ```rust
 extern crate actix;
@@ -92,9 +65,7 @@ impl Actor for TcpClientActor {
 }
 ```
 
-First we tell Rust that the `actix` module is coming from an external crate.
-Next we import the most important `actix` traits with the `use` keyword. And
-finally we implement the most basic `Actor` possible.
+First we tell Rust that the `actix` module is coming from an external crate. Next we import the most important `actix` traits with the `use` keyword. And finally we implement the most basic `Actor` possible.
 
 Starting `cargo run` again will show us the following warning though:
 
@@ -108,9 +79,7 @@ warning: struct is never used: `TcpClientActor`
   = note: #[warn(dead_code)] on by default
 ```
 
-... which makes sense since we haven't actually used the actor anywhere yet.
-Let's change that! We'll update the `main()` function with a few lines of code
-that should start our actor and then wait for it to shutdown at some point:
+... which makes sense since we haven't actually used the actor anywhere yet. Let's change that! We'll update the `main()` function with a few lines of code that should start our actor and then wait for it to shutdown at some point:
 
 ```rust
 fn main() {
@@ -134,17 +103,13 @@ impl Actor for TcpClientActor {
 }
 ```
 
-If we use `cargo run` again, the "TcpClientActor started!" message should appear
-on the screen, and the app should keep running because we have implemented
-nothing that would stop the actor.
+If we use `cargo run` again, the "TcpClientActor started!" message should appear on the screen, and the app should keep running because we have implemented nothing that would stop the actor.
 
 First milestone achieved! 🎉
 
 ## DNS resolution and TCP connection
 
-Now that we have setup the basic scaffolding of our `Actor`, let's try to
-connect to a real TCP server. I'll first show you the code and then we'll
-discuss what it does step-by-step:
+Now that we have setup the basic scaffolding of our `Actor`, let's try to connect to a real TCP server. I'll first show you the code and then we'll discuss what it does step-by-step:
 
 ```rust
 use actix::actors::{Connect, Connector};
@@ -174,58 +139,36 @@ fn started(&mut self, ctx: &mut Self::Context) {
 }
 ```
 
-The first new thing here is `Connector::from_registry()`. `actix` comes with a
-small number of built-in actors and one of them is the so-called `Connector`.
-The `Connector` actor can be used to perform DNS lookups, or connect to remote
-servers via TCP, which is exactly what we want!
+The first new thing here is `Connector::from_registry()`. `actix` comes with a small number of built-in actors and one of them is the so-called `Connector`. The `Connector` actor can be used to perform DNS lookups, or connect to remote servers via TCP, which is exactly what we want!
 
-The `Connector::from_registry()` function returns an `Addr` instance for the
-`Connector` and we can use the `send()` method on it to send a `Connect` message
-and wait for the answer (using a `Future`).
+The `Connector::from_registry()` function returns an `Addr` instance for the `Connector` and we can use the `send()` method on it to send a `Connect` message and wait for the answer (using a `Future`).
 
-Next we use the `into_actor()` modifier to transform the `Future` into another
-kind of `Future`, where we get passed not only the result, but also the actor
-instance and the context in any callbacks that we implement. This is helpful to
-work around the Rust compiler complaining about lifetime issues.
+Next we use the `into_actor()` modifier to transform the `Future` into another kind of `Future`, where we get passed not only the result, but also the actor instance and the context in any callbacks that we implement. This is helpful to work around the Rust compiler complaining about lifetime issues.
 
-Now we're ready to use the result and we do so by implementing a callback for
-the `map()` method. We'll keep it simple for now and just print a message to the
-terminal whether the connection was successful or not.
+Now we're ready to use the result and we do so by implementing a callback for the `map()` method. We'll keep it simple for now and just print a message to the terminal whether the connection was successful or not.
 
-Since we have to handle two different kinds of errors here (`ConnectorError` and
-`MailboxError`) we have to implement two different error handlers too. They have
-the same code but since the error classes are different, they can't easily share
-the same implementation unfortunately.
+Since we have to handle two different kinds of errors here (`ConnectorError` and `MailboxError`) we have to implement two different error handlers too. They have the same code but since the error classes are different, they can't easily share the same implementation unfortunately.
 
-Finally, we block the current thread using the `wait()` method until the
-`Future` is resolved.
+Finally, we block the current thread using the `wait()` method until the `Future` is resolved.
 
-As usual, we will `cargo run` again and if everything works properly we should
-see "TcpClientActor connected!" being printed to the Terminal.
+As usual, we will `cargo run` again and if everything works properly we should see "TcpClientActor connected!" being printed to the Terminal.
 
-Great! We have successfully opened up a TCP connection to the
-`towel.blinkenlights.nl` server and if you're curious what kind of server that
-is: keep reading! 😉
+Great! We have successfully opened up a TCP connection to the `towel.blinkenlights.nl` server and if you're curious what kind of server that is: keep reading! 😉
 
 ## Reading TCP streams
 
-For the next part we'll need two more dependencies: `tokio-io` and
-`tokio-codec`. [tokio][tokio] is the low-level network IO library that `actix`
-is using underneath.
+For the next part we'll need two more dependencies: `tokio-io` and `tokio-codec`. [tokio][tokio] is the low-level network IO library that `actix` is using underneath.
 
 [tokio]: https://tokio.rs/
 
-The version of `actix` that we are currently using (v0.5.8) has dependencies on
-v0.1 of the `tokio` libraries, so to avoid unnecessary conflicts we will use the
-same versions. Let's add the new dependencies to the `Cargo.toml` file:
+The version of `actix` that we are currently using (v0.5.8) has dependencies on v0.1 of the `tokio` libraries, so to avoid unnecessary conflicts we will use the same versions. Let's add the new dependencies to the `Cargo.toml` file:
 
 ```toml
 tokio-codec = "0.1"
 tokio-io = "0.1"
 ```
 
-and the necessary `extern crate` definitions to the top of the `src/main.rs`
-file:
+and the necessary `extern crate` definitions to the top of the `src/main.rs` file:
 
 ```rust
 extern crate tokio_codec;
@@ -239,14 +182,9 @@ use tokio_codec::{FramedRead, LinesCodec};
 use tokio_io::AsyncRead;
 ```
 
-You may have noticed that when we ran `cargo run` earlier the compiler was
-complaining about the `stream` variable not being used. Let's fix that by
-reading something from the TCP stream.
+You may have noticed that when we ran `cargo run` earlier the compiler was complaining about the `stream` variable not being used. Let's fix that by reading something from the TCP stream.
 
-A `TcpStream` in the context of `tokio` is the wording for the TCP connection
-between a client and a server, and includes both the read and write parts of the
-connection. Since we only care about the read part for now we should split the
-stream into the two parts and focus on the read part for now:
+A `TcpStream` in the context of `tokio` is the wording for the TCP connection between a client and a server, and includes both the read and write parts of the connection. Since we only care about the read part for now we should split the stream into the two parts and focus on the read part for now:
 
 ```rust
 Ok(stream) => {
@@ -256,11 +194,7 @@ Ok(stream) => {
 }
 ```
 
-Now we have a read part (`r`) that we can call `read()` on and a write part
-(`w`) that we could call `write()` on. Unfortunately the [Read][read] and
-[Write][write] traits only operate on `u8` arrays though, so for our purpose of
-reading strings separated by line breaks this isn't quite a user friendly as we
-would like.
+Now we have a read part (`r`) that we can call `read()` on and a write part (`w`) that we could call `write()` on. Unfortunately the [Read][read] and [Write][write] traits only operate on `u8` arrays though, so for our purpose of reading strings separated by line breaks this isn't quite a user friendly as we would like.
 
 [read]: https://doc.rust-lang.org/std/io/trait.Read.html
 [write]: https://doc.rust-lang.org/std/io/trait.Write.html
@@ -271,11 +205,7 @@ Fortunately, `tokio` has a solution for that:
 let line_reader = FramedRead::new(r, LinesCodec::new());
 ```
 
-This combination of `LinesCodec` and `FramedRead` from the `tokio-codecs` crate
-can be used to work with the `Read` trait in a more comfortable way. The
-`FramedRead` instance acts as an asynchronous stream of values that we could
-call `poll()` on, or we'll attach it to the actor in a more convenient way by
-implementing the `StreamHandler` trait from `actix`:
+This combination of `LinesCodec` and `FramedRead` from the `tokio-codecs` crate can be used to work with the `Read` trait in a more comfortable way. The `FramedRead` instance acts as an asynchronous stream of values that we could call `poll()` on, or we'll attach it to the actor in a more convenient way by implementing the `StreamHandler` trait from `actix`:
 
 ```rust
 impl StreamHandler<String, std::io::Error> for TcpClientActor {
@@ -293,17 +223,13 @@ ctx.add_stream(line_reader);
 
 right below the line that constructs the `FramedRead` instance.
 
-I won't spoiler anything, but take a bit of time and see what happens now if you
-start `cargo run` again... 🚀
+I won't spoiler anything, but take a bit of time and see what happens now if you start `cargo run` again... 🚀
 
 ## Forward messages to other actors
 
-In case you're still reading, let's implement the final part of our goal:
-forwarding received messages to another actor.
+In case you're still reading, let's implement the final part of our goal: forwarding received messages to another actor.
 
-Before we can forward any messages we first need to define how such a message
-will look like. As explained in the last blog post about actix we can do so by
-implementing the `Message` trait, or deriving it automatically in most cases:
+Before we can forward any messages we first need to define how such a message will look like. As explained in the last blog post about actix we can do so by implementing the `Message` trait, or deriving it automatically in most cases:
 
 ```rust
 #[derive(Message)]
@@ -312,8 +238,7 @@ pub struct ReceivedLine {
 }
 ```
 
-Now that we know how the message looks like we should implement a second actor
-that can receive such messages and print them to the terminal:
+Now that we know how the message looks like we should implement a second actor that can receive such messages and print them to the terminal:
 
 ```rust
 pub struct ConsoleLogger;
@@ -331,17 +256,9 @@ impl Handler<ReceivedLine> for ConsoleLogger {
 }
 ```
 
-At this point the above implementation should contain no surprises anymore. The
-`ConsoleLogger` actor implementation looks roughly like the other actors we have
-already implemented in this and the previous blog post. All it does is listen
-for `ReceivedLine` messages, and print them to the terminal once received.
+At this point the above implementation should contain no surprises anymore. The `ConsoleLogger` actor implementation looks roughly like the other actors we have already implemented in this and the previous blog post. All it does is listen for `ReceivedLine` messages, and print them to the terminal once received.
 
-Next, we will need to adjust our `TcpClientActor` implementation to no longer
-print messages by itself, but instead forward them to the second actor. For that
-the `TcpClientActor` needs to know where to send them. We could save the
-`Addr<_, ConsoleLogger>` instance in the `TcpClientActor` struct, but that would
-create a tight coupling between those actors, and we want the `TcpClientActor`
-implementation to be as generic as possible.
+Next, we will need to adjust our `TcpClientActor` implementation to no longer print messages by itself, but instead forward them to the second actor. For that the `TcpClientActor` needs to know where to send them. We could save the `Addr<_, ConsoleLogger>` instance in the `TcpClientActor` struct, but that would create a tight coupling between those actors, and we want the `TcpClientActor` implementation to be as generic as possible.
 
 The more generic solution is to use the `Recipient` struct of `actix`:
 
@@ -363,11 +280,9 @@ impl StreamHandler<String, io::Error> for TcpClientActor {
 }
 ```
 
-This implementation will try to send a `ReceivedLine` message to the `recipient`
-and print an error to the terminal if it fails.
+This implementation will try to send a `ReceivedLine` message to the `recipient` and print an error to the terminal if it fails.
 
-The final missing piece now is to start the `ConsoleLogger` actor in the
-`main()` function and pass its address to the `TcpClientActor`:
+The final missing piece now is to start the `ConsoleLogger` actor in the `main()` function and pass its address to the `TcpClientActor`:
 
 ```rust
 fn main() {
@@ -383,17 +298,10 @@ fn main() {
 }
 ```
 
-After everything is assembled back together let's use `cargo run` again and we
-will see that everything still works! 🎥
+After everything is assembled back together let's use `cargo run` again and we will see that everything still works! 🎥
 
 ## Summary
 
-We hope that by now you're a little more comfortable around actors and how to
-use and implement them in Rust. This blog post has shown how two actors can work
-together without any tight coupling other than the messages they exchange. We
-have also demonstrated how to use an actor as a TCP client, which can be used as
-a gateway for other actors that want to share the same connection to the server.
-In the next blog post of this series we will explore how to send messages and
-keep connections and actors alive using the `Supervisor`.
+We hope that by now you're a little more comfortable around actors and how to use and implement them in Rust. This blog post has shown how two actors can work together without any tight coupling other than the messages they exchange. We have also demonstrated how to use an actor as a TCP client, which can be used as a gateway for other actors that want to share the same connection to the server. In the next blog post of this series we will explore how to send messages and keep connections and actors alive using the `Supervisor`.
 
 👋
diff --git a/src/posts/2018-07-03-building-a-pwa-with-glimmer-js.md b/src/posts/2018-07-03-building-a-pwa-with-glimmer-js.md
index 3b2fad0fdc..cf029d81d4 100644
--- a/src/posts/2018-07-03-building-a-pwa-with-glimmer-js.md
+++ b/src/posts/2018-07-03-building-a-pwa-with-glimmer-js.md
@@ -2,9 +2,7 @@
 title: "Building a PWA with Glimmer.js"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte dives deep into the details of how Mainmatter built Breethe,
-  an open source progressive web app, with Glimmer.js."
+description: "Marco Otte-Witte dives deep into the details of how Mainmatter built Breethe, an open source progressive web app, with Glimmer.js."
 tags: ember
 og:
   image: /assets/images/posts/2018-07-03-building-a-pwa-with-glimmer-js/og-image.jpg
@@ -14,34 +12,17 @@ tagline: |
 
 ## Breethe
 
-While this project was mostly meant as a technology spike to validate Glimmer's
-suitability for real projects as well as testing some techniques for running and
-serving web apps that we had in our minds for some time, we wanted to build
-something useful and meaningful. What we came up with is
-[Breethe](https://breethe.app), a progressive web app that gives users quick and
-easy access to air quality data for locations around the world. Pollution and
-global warming are getting worse rather than better and having easy access to
-data that shows how bad the situation actually is, is the first step for
-everyone to question their decisions and maybe change a few things in their
-daily lives.
+While this project was mostly meant as a technology spike to validate Glimmer's suitability for real projects as well as testing some techniques for running and serving web apps that we had in our minds for some time, we wanted to build something useful and meaningful. What we came up with is [Breethe](https://breethe.app), a progressive web app that gives users quick and easy access to air quality data for locations around the world. Pollution and global warming are getting worse rather than better and having easy access to data that shows how bad the situation actually is, is the first step for everyone to question their decisions and maybe change a few things in their daily lives.
 
 ![Video of the Breethe PWA](/assets/images/posts/2018-07-03-building-a-pwa-with-glimmer-js/breethe-video.gif)
 
-The application is open source and
-[available on GitHub](https://github.com/mainmatter/breethe-client).
+The application is open source and [available on GitHub](https://github.com/mainmatter/breethe-client).
 
 ## Glimmer.js
 
-Glimmer.js is a thin component library built on top of Ember.js's rendering
-engine, the Glimmer VM. It is optimized for small application bundle sizes and
-maximum runtime performance and thus a great fit for situations where a
-full-featured framework like Ember.js is not needed and too heavyweight.
+Glimmer.js is a thin component library built on top of Ember.js's rendering engine, the Glimmer VM. It is optimized for small application bundle sizes and maximum runtime performance and thus a great fit for situations where a full-featured framework like Ember.js is not needed and too heavyweight.
 
-Glimmer.js provides functionality for defining, composing and rendering
-components and keeps the DOM in sync with the component tree's internal state.
-It uses Ember CLI, the battle-tested command-line interface tool (CLI) from the
-Ember project, to help create and manage applications. Glimmer.js is written in
-TypeScript and so are applications built with it.
+Glimmer.js provides functionality for defining, composing and rendering components and keeps the DOM in sync with the component tree's internal state. It uses Ember CLI, the battle-tested command-line interface tool (CLI) from the Ember project, to help create and manage applications. Glimmer.js is written in TypeScript and so are applications built with it.
 
 Glimmer.js templates use Handlebars-like syntax, e.g.:
 
@@ -57,28 +38,17 @@ Glimmer.js templates use Handlebars-like syntax, e.g.:
 {% endraw %}
 ```
 
-These templates then get compiled to bytecode that the Glimmer VM (yes, this is
-a full-fledged VM that runs inside the JavaScript VM inside the browser)
-processes and translates into DOM operations. For a detailed overview of how
-that works and why it results in very small bundle sizes as well as super fast
-initial and update renders, watch the talk I gave at the
-[Ember.js Munich](https://www.meetup.com/Ember-js-Munich/) meetup last year:
+These templates then get compiled to bytecode that the Glimmer VM (yes, this is a full-fledged VM that runs inside the JavaScript VM inside the browser) processes and translates into DOM operations. For a detailed overview of how that works and why it results in very small bundle sizes as well as super fast initial and update renders, watch the talk I gave at the [Ember.js Munich](https://www.meetup.com/Ember-js-Munich/) meetup last year:
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/vIRZDCyfOJc?rel=0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
 ## Building Breethe with Glimmer.js
 
-The Breethe app consists of two main screens, the Start page with the search
-form and the results page that shows the data and an air quality score for a
-particular location. These two screens are implemented via two components so
-that depending on the current state of the app, the correct one is rendered.
+The Breethe app consists of two main screens, the Start page with the search form and the results page that shows the data and an air quality score for a particular location. These two screens are implemented via two components so that depending on the current state of the app, the correct one is rendered.
 
 ![The two main screens of the Breethe PWA](/assets/images/posts/2018-07-03-building-a-pwa-with-glimmer-js/breethe-screens.png#@600-1200)
 
-As Glimmer.js is _"only"_ a UI component library and does not include any
-routing functionality, we used the [Navigo](https://github.com/krasimir/navigo)
-router to set up logic that maps the current URL to the corresponding
-application state and vice versa:
+As Glimmer.js is _"only"_ a UI component library and does not include any routing functionality, we used the [Navigo](https://github.com/krasimir/navigo) router to set up logic that maps the current URL to the corresponding application state and vice versa:
 
 ```ts
 _setupRouting() {
@@ -103,16 +73,7 @@ _setupRouting() {
 }
 ```
 
-First of all, we create a new router instance. We then map URLs to the
-corresponding states of the app. The routes `/`, `/search` and
-`/search/:searchTerm` all map to the `MODE_SEARCH` mode that renders the search
-form and search results if there are any. The `/location/:locationId` route maps
-to the `MODE_RESULTS` mode that renders a particular location's data and quality
-score. We use the `mode` property in two tracked properties `isSearchMode` and
-`isResultsMode`.
-[Tracked properties](https://glimmerjs.com/guides/tracked-properties) are
-Glimmer's equivalent to Ember's computed properties and will result in the
-component being re-rendered when their value changes.
+First of all, we create a new router instance. We then map URLs to the corresponding states of the app. The routes `/`, `/search` and `/search/:searchTerm` all map to the `MODE_SEARCH` mode that renders the search form and search results if there are any. The `/location/:locationId` route maps to the `MODE_RESULTS` mode that renders a particular location's data and quality score. We use the `mode` property in two tracked properties `isSearchMode` and `isResultsMode`. [Tracked properties](https://glimmerjs.com/guides/tracked-properties) are Glimmer's equivalent to Ember's computed properties and will result in the component being re-rendered when their value changes.
 
 ```ts
 @tracked('mode')
@@ -126,8 +87,7 @@ get isResultsMode(): boolean {
 }
 ```
 
-These tracked properties are then used in the template to render the respective
-component for the current mode:
+These tracked properties are then used in the template to render the respective component for the current mode:
 
 ```hbs
 {% raw %}
@@ -139,13 +99,9 @@ component for the current mode:
 {% endraw %}
 ```
 
-You might notice the `@` prefix of the `searchTerm` and `locationId` properties
-that are set on the components. This prefix distinguishes properties that are to
-be passed to the component instance as opposed to attributes that will be
-applied to the component's root DOM element.
+You might notice the `@` prefix of the `searchTerm` and `locationId` properties that are set on the components. This prefix distinguishes properties that are to be passed to the component instance as opposed to attributes that will be applied to the component's root DOM element.
 
-The `Search` component renders the `SearchForm` component that implements the
-text field for the search term and the button to submit the search:
+The `Search` component renders the `SearchForm` component that implements the text field for the search term and the button to submit the search:
 
 ```hbs
 {% raw %}
@@ -153,10 +109,7 @@ text field for the search term and the button to submit the search:
 {% endraw %}
 ```
 
-{% raw %} `@onSubmit={{action searchByTerm}}` assigns the `searchByTerm` method
-of the `Search` component as an action to the `@onSubmit` property of the
-`SearchForm` component. Whenever the search form is submitted, the `SearchForm`
-component invokes the assigned action: {% endraw %}
+{% raw %} `@onSubmit={{action searchByTerm}}` assigns the `searchByTerm` method of the `Search` component as an action to the `@onSubmit` property of the `SearchForm` component. Whenever the search form is submitted, the `SearchForm` component invokes the assigned action: {% endraw %}
 
 ```ts
 submitSearch(event) {
@@ -166,10 +119,7 @@ submitSearch(event) {
  }
 ```
 
-The last line calls the assigned action and thus invokes the `searchByTerm`
-method on the `Search` component. That method enables the loading state on the
-component, loads locations matching the search term, assigns them to its
-`locations` property and disables the loading state again:
+The last line calls the assigned action and thus invokes the `searchByTerm` method on the `Search` component. That method enables the loading state on the component, loads locations matching the search term, assigns them to its `locations` property and disables the loading state again:
 
 ```ts
 async searchByTerm(searchTerm) {
@@ -182,9 +132,7 @@ async searchByTerm(searchTerm) {
 }
 ```
 
-The `loading` and `locations` properties are tracked properties so that changing
-them results in the component to be re-rendered. They are used in the template
-like this:
+The `loading` and `locations` properties are tracked properties so that changing them results in the component to be re-rendered. They are used in the template like this:
 
 ```hbs
 {% raw %}
@@ -206,51 +154,23 @@ like this:
 {% endraw %}
 ```
 
-This is just a brief overview of how an application built with Glimmer.js works.
-We will cover some of these things in more detail in future posts, particularly
-how we load and manage data with Orbit.js. For a closer look on the inner
-workings of Breethe, check out the
-[code on github](https://github.com/mainmatter/breethe-client).
+This is just a brief overview of how an application built with Glimmer.js works. We will cover some of these things in more detail in future posts, particularly how we load and manage data with Orbit.js. For a closer look on the inner workings of Breethe, check out the [code on github](https://github.com/mainmatter/breethe-client).
 
 ## From Glimmer.js to Ember.js
 
-Besides making the Glimmer VM available to be used outside of Ember.js and
-offering a solution for situations where bundle size and load time performance
-is of crucial importance, Glimmer.js also serves as a testbed for new features
-and changes that will later make their way into the Ember.js framework. It is
-not bound to the strong stability guarantees that Ember.js offers and thus a
-great environment for experimenting with new approaches to existing problems
-that will usually require a few iterations until the API becomes stable.
-
-Some new things that originate in experiments done in Glimmer.js have already
-found their way back into Ember.js (at least in some form):
-
-- The `@` syntax as shown above that clearly distinguishes properties that are
-  set on a component instance vs. attributes that are set on a component's root
-  DOM element -
-  [this PR](https://github.com/emberjs/ember.js/commit/4bd3d7b882484919682ab0cdb57f81584abc503a)
-  enables the feature flag by default.
-- The possibility to use ES2015 classes instead of Ember.js' own object model -
-  see
-  [this blog post](https://medium.com/build-addepar/es-classes-in-ember-js-63e948e9d78e)
-  for more information.
-- Template-only components that do not have a wrapping `<div>` - can be enabled
-  as an [optional feature](https://github.com/emberjs/ember-optional-features).
-
-Eventually it will be possible to seamlessly use Glimmer.js components in
-Ember.js applications (see the
-[quest issue](https://github.com/emberjs/ember.js/issues/16301) for more
-information). That will also enable _"upgrading"_ Glimmer.js applications to
-Ember.js once they reach a certain size and complexity and the additional
-features and concepts that Ember.js provides over Glimmer.js justify a more
-heavyweight framework.
+Besides making the Glimmer VM available to be used outside of Ember.js and offering a solution for situations where bundle size and load time performance is of crucial importance, Glimmer.js also serves as a testbed for new features and changes that will later make their way into the Ember.js framework. It is not bound to the strong stability guarantees that Ember.js offers and thus a great environment for experimenting with new approaches to existing problems that will usually require a few iterations until the API becomes stable.
+
+Some new things that originate in experiments done in Glimmer.js have already found their way back into Ember.js (at least in some form):
+
+- The `@` syntax as shown above that clearly distinguishes properties that are set on a component instance vs. attributes that are set on a component's root DOM element - [this PR](https://github.com/emberjs/ember.js/commit/4bd3d7b882484919682ab0cdb57f81584abc503a) enables the feature flag by default.
+- The possibility to use ES2015 classes instead of Ember.js' own object model - see [this blog post](https://medium.com/build-addepar/es-classes-in-ember-js-63e948e9d78e) for more information.
+- Template-only components that do not have a wrapping `<div>` - can be enabled as an [optional feature](https://github.com/emberjs/ember-optional-features).
+
+Eventually it will be possible to seamlessly use Glimmer.js components in Ember.js applications (see the [quest issue](https://github.com/emberjs/ember.js/issues/16301) for more information). That will also enable _"upgrading"_ Glimmer.js applications to Ember.js once they reach a certain size and complexity and the additional features and concepts that Ember.js provides over Glimmer.js justify a more heavyweight framework.
 
 ## Testing
 
-Glimmer.js' testing APIs are very similar to what Ember.js uses for
-[component tests](https://guides.emberjs.com/release/testing/testing-components/).
-The idea is to render a particular component with a given set of properties and
-attributes and assert on the generated DOM:
+Glimmer.js' testing APIs are very similar to what Ember.js uses for [component tests](https://guides.emberjs.com/release/testing/testing-components/). The idea is to render a particular component with a given set of properties and attributes and assert on the generated DOM:
 
 ```js
 {% raw %}
@@ -287,36 +207,14 @@ module('Component: MeasurementRow', function (hooks) {
 {% endraw %}
 ```
 
-This test case tests the `MeasurementRow` component by passing a set of
-properties and asserting that the DOM contains the expected elements with the
-expected content. The key element to notice is the invocation of
-`setupRenderingTest` which sets the test case up as a rendering test. Rendering
-tests have a `render` method that takes a template and renders that into the
-testing container. The rendered component's root element can then be accessed
-via the test's `containerElement` property.
-
-We use `data-test-` attributes in this test to select elements in the DOM (e.g.
-`this.containerElement.querySelector('[data-test-measurement-label]')`). That
-allows using expressive selectors in tests without relying on DOM structure or
-CSS class names. As these attributes are only needed for testing, we strip them
-from the templates in production builds so that we don't grow the bundle size
-unnecessarily. For a full-featured addon that makes that approach conveniently
-available for Ember.js applications, check out
-[the `ember-test-selectors` addon](https://ember-test-selectors.com).
-
-Glimmer.js' testing APIs still have some shortcomings (see
-[this issue](https://github.com/glimmerjs/glimmer.js/issues/14)) and are not
-entirely ready for prime time. In order to test some more advanced component
-behaviors, we use [Puppeteer](https://pptr.dev) to run the entire application in
-a headless browser.
+This test case tests the `MeasurementRow` component by passing a set of properties and asserting that the DOM contains the expected elements with the expected content. The key element to notice is the invocation of `setupRenderingTest` which sets the test case up as a rendering test. Rendering tests have a `render` method that takes a template and renders that into the testing container. The rendered component's root element can then be accessed via the test's `containerElement` property.
+
+We use `data-test-` attributes in this test to select elements in the DOM (e.g. `this.containerElement.querySelector('[data-test-measurement-label]')`). That allows using expressive selectors in tests without relying on DOM structure or CSS class names. As these attributes are only needed for testing, we strip them from the templates in production builds so that we don't grow the bundle size unnecessarily. For a full-featured addon that makes that approach conveniently available for Ember.js applications, check out [the `ember-test-selectors` addon](https://ember-test-selectors.com).
+
+Glimmer.js' testing APIs still have some shortcomings (see [this issue](https://github.com/glimmerjs/glimmer.js/issues/14)) and are not entirely ready for prime time. In order to test some more advanced component behaviors, we use [Puppeteer](https://pptr.dev) to run the entire application in a headless browser.
 
 ## Outlook
 
-In future posts, we will look at some specific aspects of the application in
-more detail, including service workers and offline functionality (and testing
-that with Puppeteer), server side rendering (which enables progressive
-enhancement where JavaScript is not even needed in the browser anymore to be
-able to use the application) and how we optimized the app's CSS using
-[css-blocks](http://css-blocks.com).
+In future posts, we will look at some specific aspects of the application in more detail, including service workers and offline functionality (and testing that with Puppeteer), server side rendering (which enables progressive enhancement where JavaScript is not even needed in the browser anymore to be able to use the application) and how we optimized the app's CSS using [css-blocks](http://css-blocks.com).
 
 Stay tuned 👋
diff --git a/src/posts/2018-07-24-from-spa-to-pwa.md b/src/posts/2018-07-24-from-spa-to-pwa.md
index 4d191f9508..079d6ab72f 100644
--- a/src/posts/2018-07-24-from-spa-to-pwa.md
+++ b/src/posts/2018-07-24-from-spa-to-pwa.md
@@ -2,9 +2,7 @@
 title: "From SPA to PWA"
 authorHandle: marcoow
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte goes over the characteristics of progressive web apps and
-  shows how to make the next step from a SPA to a PWA."
+description: "Marco Otte-Witte goes over the characteristics of progressive web apps and shows how to make the next step from a SPA to a PWA."
 tags: javascript
 og:
   image: /assets/images/posts/2018-07-24-from-spa-to-pwa/og-image.jpg
@@ -14,124 +12,51 @@ tagline: |
 
 ## Breethe
 
-Throughout this post, we will use [Breethe](https://breethe.app) as an example.
-Breethe is a Progressive Web App that gives users quick and easy access to air
-quality data for locations around the world. Pollution and global warming are
-getting worse rather than better and having access to data that shows the depth
-of the situation is the first step for everyone to question their decisions and
-maybe change a few things in their daily lives.
+Throughout this post, we will use [Breethe](https://breethe.app) as an example. Breethe is a Progressive Web App that gives users quick and easy access to air quality data for locations around the world. Pollution and global warming are getting worse rather than better and having access to data that shows the depth of the situation is the first step for everyone to question their decisions and maybe change a few things in their daily lives.
 
 ![Video of the Breethe PWA](/assets/images/posts/2018-07-24-from-spa-to-pwa/breethe-video.gif)
 
-The application is [open source](https://github.com/mainmatter/breethe-client)
-and we encourage everyone interested to look through the source for reference.
-To learn more about how we built Breethe with
-[Glimmer.js](http://glimmerjs.com), refer to the
-[previous post in this series](/blog/2018/07/03/building-a-pwa-with-glimmer-js).
-None of the contents in this post are specific to Glimmer.js in any way though,
-but all generally applicable to all frontend stacks.
+The application is [open source](https://github.com/mainmatter/breethe-client) and we encourage everyone interested to look through the source for reference. To learn more about how we built Breethe with [Glimmer.js](http://glimmerjs.com), refer to the [previous post in this series](/blog/2018/07/03/building-a-pwa-with-glimmer-js). None of the contents in this post are specific to Glimmer.js in any way though, but all generally applicable to all frontend stacks.
 
 ## Progressive Web Apps
 
-In short, Progressive Web Apps are **web apps that look and behave like native
-apps**. While the idea of building apps with web technologies has been around
-for a long time, it never really took off until recently. In fact, Steve Jobs
-himself introduced the idea at WWDC 2007, just shortly after the unveiling of
-the orignal iPhone:
+In short, Progressive Web Apps are **web apps that look and behave like native apps**. While the idea of building apps with web technologies has been around for a long time, it never really took off until recently. In fact, Steve Jobs himself introduced the idea at WWDC 2007, just shortly after the unveiling of the orignal iPhone:
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/y1B2c3ZD9fk?start=4451" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
 
-Unfortunately that idea was one of the few of Jobs' that never really took off.
-In fact, Apple released the first native SDK for the iPhone in 2008. That change
-in strategy lead to a huge market for native mobile apps and played a
-significant role in mobile devices becoming ever more ubiquitous over the past
-decade.
-
-While native apps enable great things and previously unforeseen use cases, they
-come with some drawbacks. They generally
-[show high conversion rates](https://jmango360.com/wiki/mobile-app-vs-mobile-website-statistics/)
-which is the main reason why marketing departments keep pushing for them. On the
-downside though, they have some significant drawbacks, the main one being that
-apps have to be downloaded and installed which can be a significant effort for
-users for several reasons (ultimately leading to the question of how many
-potential users are lost before they even install the app where they then
-**could** have been successfully converted):
-
-- users that are on the mobile website already, when asked to install the app,
-  need to leave that website, go to the app store, download the app and continue
-  through the installation process
-- once the app is installed, all input that potentially was made on the website
-  before is lost and needs to be restored besides users potentially needing to
-  login in the app again
-- native apps are
-  [relatively large on average](https://sweetpricing.com/blog/2017/02/average-app-file-size/),
-  leading to long download times which are particularly painful on less reliable
-  mobile connections
-
-In contrast, **web apps are easily accessible via the browser** without forcing
-users to go through an app store and installation process and load almost
-instantaneously - if done right, even on unreliable mobile connections.
-
-Another advantage of native apps is mostly a historic one now. Historically,
-native apps were able to offer a better user experience both in terms of the
-purely visual experience and also in terms of features. With the quickly
-evolving web platform and capabilities of modern browsers, this is no longer the
-case though and **web apps are now capable of offering equal if not better user
-experiences compared to native apps**. Combined with almost instantaneous load
-times and superior discoverability, Progressive Web Apps are clearly the better
-choice than native apps in a large number of scenarios now –
-[Appscope](https://appsco.pe) is a great resource for discovering PWAs of all
-kinds.
-
-This has only been the case relatively recently though. While Chrome and Firefox
-supported Service Workers (which are the main building block for PWAs) for quite
-some time, two major browsers were falling behind - namely Safari and Internet
-Explorer. These two (actually not Internet Explorer but its successor
-[Edge](https://www.microsoft.com/de-de/windows/microsoft-edge)) have finally
-caught up recently and
-[Service Workers are now supported by all major browsers](https://caniuse.com/#feat=serviceworkers),
-making Progressive Web Apps a viable alternative to native apps for most
-businesses with approximately 84% of the global user base on browsers and OSes
-capable of running PWAs as of July 2018.
-
-A decade after the introduction of the original iPhone (and a detour via the
-[multi-billion native app economy](https://www.appannie.com/en/insights/market-data/predictions-app-economy-2018/)),
-Progressive Web Apps are ready to be used and they are here to stay. And we are
-only getting started - as Progressive Web Apps have only recently really took
-off, **it's fair to expect massive improvements in terms of what's possible over
-the next coming years**.
+Unfortunately that idea was one of the few of Jobs' that never really took off. In fact, Apple released the first native SDK for the iPhone in 2008. That change in strategy lead to a huge market for native mobile apps and played a significant role in mobile devices becoming ever more ubiquitous over the past decade.
+
+While native apps enable great things and previously unforeseen use cases, they come with some drawbacks. They generally [show high conversion rates](https://jmango360.com/wiki/mobile-app-vs-mobile-website-statistics/) which is the main reason why marketing departments keep pushing for them. On the downside though, they have some significant drawbacks, the main one being that apps have to be downloaded and installed which can be a significant effort for users for several reasons (ultimately leading to the question of how many potential users are lost before they even install the app where they then **could** have been successfully converted):
+
+- users that are on the mobile website already, when asked to install the app, need to leave that website, go to the app store, download the app and continue through the installation process
+- once the app is installed, all input that potentially was made on the website before is lost and needs to be restored besides users potentially needing to login in the app again
+- native apps are [relatively large on average](https://sweetpricing.com/blog/2017/02/average-app-file-size/), leading to long download times which are particularly painful on less reliable mobile connections
+
+In contrast, **web apps are easily accessible via the browser** without forcing users to go through an app store and installation process and load almost instantaneously - if done right, even on unreliable mobile connections.
+
+Another advantage of native apps is mostly a historic one now. Historically, native apps were able to offer a better user experience both in terms of the purely visual experience and also in terms of features. With the quickly evolving web platform and capabilities of modern browsers, this is no longer the case though and **web apps are now capable of offering equal if not better user experiences compared to native apps**. Combined with almost instantaneous load times and superior discoverability, Progressive Web Apps are clearly the better choice than native apps in a large number of scenarios now – [Appscope](https://appsco.pe) is a great resource for discovering PWAs of all kinds.
+
+This has only been the case relatively recently though. While Chrome and Firefox supported Service Workers (which are the main building block for PWAs) for quite some time, two major browsers were falling behind - namely Safari and Internet Explorer. These two (actually not Internet Explorer but its successor [Edge](https://www.microsoft.com/de-de/windows/microsoft-edge)) have finally caught up recently and [Service Workers are now supported by all major browsers](https://caniuse.com/#feat=serviceworkers), making Progressive Web Apps a viable alternative to native apps for most businesses with approximately 84% of the global user base on browsers and OSes capable of running PWAs as of July 2018.
+
+A decade after the introduction of the original iPhone (and a detour via the [multi-billion native app economy](https://www.appannie.com/en/insights/market-data/predictions-app-economy-2018/)), Progressive Web Apps are ready to be used and they are here to stay. And we are only getting started - as Progressive Web Apps have only recently really took off, **it's fair to expect massive improvements in terms of what's possible over the next coming years**.
 
 ## What are PWAs?
 
 Progressive Web Apps have some distinct characteristics, the main ones being:
 
-- **Progressiveness**: they work for every user, regardless of their device or
-  browser of choice; depending on the capabilities of that environment, they
-  will enable more or less of their functionality
+- **Progressiveness**: they work for every user, regardless of their device or browser of choice; depending on the capabilities of that environment, they will enable more or less of their functionality
 - **Responsiveness**: they fit any form factor and screen sizes
-- **Connectivity Independence**: they work on low quality networks or without
-  any network at all (and thus fully offline)
-- **App-likeliness**: they offer the rich user experience that users know and
-  love from native apps
-- **Installability**: they can be installed on the user's home screen without
-  having to go through an app store
+- **Connectivity Independence**: they work on low quality networks or without any network at all (and thus fully offline)
+- **App-likeliness**: they offer the rich user experience that users know and love from native apps
+- **Installability**: they can be installed on the user's home screen without having to go through an app store
 
-We will be focussing on two of these characteristics in this article -
-Installability and Connectivity Independence.
+We will be focussing on two of these characteristics in this article - Installability and Connectivity Independence.
 
 ## Installability
 
-Progressive Web apps can be installed on the user's home screen and thus _"taken
-out of the browser"_ so that they mingle with the user's native apps without the
-user noticing a difference. That characteristic is enabled by the
-[_"App Manifest"_](https://developers.google.com/web/fundamentals/web-app-manifest/)
-that describes how an app is supposed to behave when run _"outside"_ of the
-browser. The App Manifest is a simple JSON file with key/value pairs that
-configure the main aspects of the app.
+Progressive Web apps can be installed on the user's home screen and thus _"taken out of the browser"_ so that they mingle with the user's native apps without the user noticing a difference. That characteristic is enabled by the [_"App Manifest"_](https://developers.google.com/web/fundamentals/web-app-manifest/) that describes how an app is supposed to behave when run _"outside"_ of the browser. The App Manifest is a simple JSON file with key/value pairs that configure the main aspects of the app.
 
-The
-[App Manifest for Breethe](https://github.com/mainmatter/breethe-client/blob/master/public/manifest.webmanifest)
-looks like this:
+The [App Manifest for Breethe](https://github.com/mainmatter/breethe-client/blob/master/public/manifest.webmanifest) looks like this:
 
 ```js
 {% raw %}on
@@ -167,51 +92,28 @@ The manifest is presented to the browser via a `meta` tag:
 <link rel="manifest" href="/manifest.webmanifest" />
 ```
 
-The main keys in the manifest are `name`, `icons`, `background_color`,
-`start_url`, `display` and `orientation`:
+The main keys in the manifest are `name`, `icons`, `background_color`, `start_url`, `display` and `orientation`:
 
-- `name`: the name of the app that will be shown on the user's home screen once
-  the app is installed
-- `icons`: icons in various sizes to use for the app on the home screen, the
-  task switcher and elsewhere
-- `background_color`: sets the color for the splash screen that is shown when
-  the app is started from the home screen
+- `name`: the name of the app that will be shown on the user's home screen once the app is installed
+- `icons`: icons in various sizes to use for the app on the home screen, the task switcher and elsewhere
+- `background_color`: sets the color for the splash screen that is shown when the app is started from the home screen
 - `start_url`: the URL to load when the app is started from the home screen
-- `display`: tells the browser how to display the app when started from the home
-  screen; this should usually be `"standalone"`
-- `orientation`: the orientation to launch the app with if only one orientation
-  is supported
+- `display`: tells the browser how to display the app when started from the home screen; this should usually be `"standalone"`
+- `orientation`: the orientation to launch the app with if only one orientation is supported
 
 Breethe, when installed to the user's home screen on iOS shows up like this:
 
 ![The Breethe app icon on the home screen](/assets/images/posts/2018-07-24-from-spa-to-pwa/breethe-app-icon.png)
 
-When launched from the home screen, it starts up like a native app, without any
-browser UI:
+When launched from the home screen, it starts up like a native app, without any browser UI:
 
 ![The Breethe PWA starting up standalone](/assets/images/posts/2018-07-24-from-spa-to-pwa/breethe-startup-standalone.gif)
 
 ## Connectivity Independence
 
-The main requirement for any web application to be able to work independently of
-the network is that it **must be able to start up while there is no network at
-all** and the device is offline. For a browser-based application designed to
-load all required assets remotely, that is no easy task. One of the first
-approaches for achieving this was
-[Google Gears](<https://en.wikipedia.org/wiki/Gears_(software)>). Gears was
-released as early as 2007 as a proprietary extension for Chrome and allowed
-offline usage of e.g. Gmail. Gears never really took off in the broader
-ecosystem and was discontinued in 2010.
-
-Many of the original ideas behind Gears found their way into the HTML5 spec
-though, in particular the idea of Gear's `LocalServer` module that allowed
-running a local server inside of the browser. That server would be able to
-handle any requests made by the browser instead of actually sending the request
-over the network. This is essentially (besides some other features) what service
-workers offer. They are standalone pieces of JavaScript code that get installed
-into the users browser and are subsequently able to intercept any request that
-the browser makes and serve the response from their internal cache instead of
-relying on the remote server's response.
+The main requirement for any web application to be able to work independently of the network is that it **must be able to start up while there is no network at all** and the device is offline. For a browser-based application designed to load all required assets remotely, that is no easy task. One of the first approaches for achieving this was [Google Gears](<https://en.wikipedia.org/wiki/Gears_(software)>). Gears was released as early as 2007 as a proprietary extension for Chrome and allowed offline usage of e.g. Gmail. Gears never really took off in the broader ecosystem and was discontinued in 2010.
+
+Many of the original ideas behind Gears found their way into the HTML5 spec though, in particular the idea of Gear's `LocalServer` module that allowed running a local server inside of the browser. That server would be able to handle any requests made by the browser instead of actually sending the request over the network. This is essentially (besides some other features) what service workers offer. They are standalone pieces of JavaScript code that get installed into the users browser and are subsequently able to intercept any request that the browser makes and serve the response from their internal cache instead of relying on the remote server's response.
 
 Installing a service worker is as simple as running a little script:
 
@@ -225,18 +127,9 @@ Installing a service worker is as simple as running a little script:
 </script>
 ```
 
-This calls the navigator's `serviceWorker` API's `register` method (if the
-browser supports that API), passing the name of the JavaScript file with the
-service worker code as an argument. The `register` method returns a promise that
-rejects if the service worker could not be registered successfully.
+This calls the navigator's `serviceWorker` API's `register` method (if the browser supports that API), passing the name of the JavaScript file with the service worker code as an argument. The `register` method returns a promise that rejects if the service worker could not be registered successfully.
 
-Once the service worker is registered, it will start receiving various events
-during the
-[service worker lifecycle](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Basic_architecture).
-The first event in that lifecycle is the _"install"_ event which is typically
-used to pre-cache resources and thus make them available for later offline use.
-In the Breethe PWA, we use that event to preload all of the app's essential
-resources:
+Once the service worker is registered, it will start receiving various events during the [service worker lifecycle](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#Basic_architecture). The first event in that lifecycle is the _"install"_ event which is typically used to pre-cache resources and thus make them available for later offline use. In the Breethe PWA, we use that event to preload all of the app's essential resources:
 
 <!-- prettier-ignore -->
 ```js
@@ -266,14 +159,9 @@ self.addEventListener('install', function(event) {
 {% endraw %}
 ```
 
-Here, when the _"install"_ event is fired, we open the service worker cache,
-request the critical assets and store them in the service worker's cache.
+Here, when the _"install"_ event is fired, we open the service worker cache, request the critical assets and store them in the service worker's cache.
 
-The next event in the lifecycle is the _"activate"_ event that is typically used
-to delete old caches so that when the service worker is updated, no stale data
-is left on the user's device. In the Breethe PWA, we only use one cache and when
-the service worker is activated, simply delete all caches that are not that
-current one:
+The next event in the lifecycle is the _"activate"_ event that is typically used to delete old caches so that when the service worker is updated, no stale data is left on the user's device. In the Breethe PWA, we only use one cache and when the service worker is activated, simply delete all caches that are not that current one:
 
 ```js
 {% raw %}
@@ -294,13 +182,7 @@ self.addEventListener('activate', function (event) {
 {% endraw %}
 ```
 
-After the service worker is installed and activated, it starts receiving
-_"fetch"_ events whenever the browser makes a request for any remote resource.
-This is the relevant event that we need to listen for in order to make sure the
-PWA can start up successfully if the device is offline. In the case of an SPA
-where there only is one HTML document (which is `index.html`), this is as easy
-as always serving that from the service worker's cache when the original request
-fails:
+After the service worker is installed and activated, it starts receiving _"fetch"_ events whenever the browser makes a request for any remote resource. This is the relevant event that we need to listen for in order to make sure the PWA can start up successfully if the device is offline. In the case of an SPA where there only is one HTML document (which is `index.html`), this is as easy as always serving that from the service worker's cache when the original request fails:
 
 ```js
 {% raw %}
@@ -316,37 +198,13 @@ self.addEventListener('fetch', function (event) {
 {% endraw %}
 ```
 
-Here, we first check whether the request is asking for an HTML document (in
-reality in Breethe,
-[we check a few other things as well](https://github.com/mainmatter/breethe-client/blob/master/lib/service-worker/workers/service-worker.js#L88))
-and if that is the case, try making the request and loading the resource from
-the network first. If that fails and the promise returned from `fetch` rejects
-(one possible reason for that being that the device is offline), we simply serve
-the `index.html` from the service worker's cache so that the app can start up
-successfully in the browser. All of the application's assets that are referenced
-in `index.html` are cached to and served from the service worker's cache as well
-in a
-[separate event handler](https://github.com/mainmatter/breethe-client/blob/master/lib/service-worker/workers/service-worker.js#L65).
-
-Allowing apps to start up offline with Service Workers is very straight forward
-and does not even require implementing a whole lot of logic -
-[Breethe's service worker](https://github.com/mainmatter/breethe-client/blob/master/lib/service-worker/workers/service-worker.js)
-does not even have 100 lines of code. Of course being able to start up the app
-while the device is offline only solves half of the problem though when all of
-the app's data is loaded from a remote API and thus would be unavailable when
-offline.
+Here, we first check whether the request is asking for an HTML document (in reality in Breethe, [we check a few other things as well](https://github.com/mainmatter/breethe-client/blob/master/lib/service-worker/workers/service-worker.js#L88)) and if that is the case, try making the request and loading the resource from the network first. If that fails and the promise returned from `fetch` rejects (one possible reason for that being that the device is offline), we simply serve the `index.html` from the service worker's cache so that the app can start up successfully in the browser. All of the application's assets that are referenced in `index.html` are cached to and served from the service worker's cache as well in a [separate event handler](https://github.com/mainmatter/breethe-client/blob/master/lib/service-worker/workers/service-worker.js#L65).
+
+Allowing apps to start up offline with Service Workers is very straight forward and does not even require implementing a whole lot of logic - [Breethe's service worker](https://github.com/mainmatter/breethe-client/blob/master/lib/service-worker/workers/service-worker.js) does not even have 100 lines of code. Of course being able to start up the app while the device is offline only solves half of the problem though when all of the app's data is loaded from a remote API and thus would be unavailable when offline.
 
 ## Offline Data
 
-The web platform provides a number of APIs for storing data in the browser and
-thus making it available for offline use. The
-[WebStorage API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API)
-defines `localStorage` and `sessionStorage` which can be used for storing
-key/value pairs. Cookies have been around for quite some time and not only can
-they be used for tracking users or keeping their sessions alive when the browser
-is closed but also for storing simple data. When dealing with bigger, structured
-datasets though, the storage API of choice is generally
-[`IndexedDB`](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API).
+The web platform provides a number of APIs for storing data in the browser and thus making it available for offline use. The [WebStorage API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API) defines `localStorage` and `sessionStorage` which can be used for storing key/value pairs. Cookies have been around for quite some time and not only can they be used for tracking users or keeping their sessions alive when the browser is closed but also for storing simple data. When dealing with bigger, structured datasets though, the storage API of choice is generally [`IndexedDB`](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API).
 
 `IndexedDB` is a transactional database system, similar to SQL-based RDBMS:
 
@@ -366,18 +224,9 @@ openRequest.onsuccess = function (event) {
 {% endraw %}
 ```
 
-`IndexedDB`'s API can be a bit cumbersome to use though which is why instead of
-interfacing with it directly, developers typically leverage libraries that
-abstract its complexity behind more convenient APIs. For Breethe, we used
-[Orbit.js](http://orbitjs.com) but there are other libraries like
-[PouchDB](https://pouchdb.com) or
-[localForage](https://localforage.github.io/localForage/).
+`IndexedDB`'s API can be a bit cumbersome to use though which is why instead of interfacing with it directly, developers typically leverage libraries that abstract its complexity behind more convenient APIs. For Breethe, we used [Orbit.js](http://orbitjs.com) but there are other libraries like [PouchDB](https://pouchdb.com) or [localForage](https://localforage.github.io/localForage/).
 
-Orbit.js works based on a schema definition that defines the models it operates
-on, their attributes and relationships. In the case of Breethe which works with
-measurement locations and data points,
-[the schema](https://github.com/mainmatter/breethe-client/blob/master/src/utils/data/schema.ts)
-looks like this:
+Orbit.js works based on a schema definition that defines the models it operates on, their attributes and relationships. In the case of Breethe which works with measurement locations and data points, [the schema](https://github.com/mainmatter/breethe-client/blob/master/src/utils/data/schema.ts) looks like this:
 
 ```typescript
 import { SchemaSettings } from "@orbit/data";
@@ -418,10 +267,7 @@ export const schema: SchemaSettings = {
 };
 ```
 
-The `location` model represents a measurement location that air quality data has
-been recorded for. Each location has a number of `measurements` that represent
-individual data points for particular parameters, e.g. 42.38 µg/m³ for Ozone
-(O₃). With that schema, a store can be instantiated:
+The `location` model represents a measurement location that air quality data has been recorded for. Each location has a number of `measurements` that represent individual data points for particular parameters, e.g. 42.38 µg/m³ for Ozone (O₃). With that schema, a store can be instantiated:
 
 ```typescript
 import Store from "@orbit/store";
@@ -430,9 +276,7 @@ import schema from "./schema";
 const store = new Store({ schema });
 ```
 
-Stores in Orbit.js are backed by sources. In the case of Breethe, we use a
-[json:api](http://jsonapi.org) source for loading data from a
-[server API](https://github.com/mainmatter/breethe-server):
+Stores in Orbit.js are backed by sources. In the case of Breethe, we use a [json:api](http://jsonapi.org) source for loading data from a [server API](https://github.com/mainmatter/breethe-server):
 
 ```typescript
 import JSONAPISource from "@orbit/jsonapi";
@@ -444,9 +288,7 @@ const remote = new JSONAPISource({
 });
 ```
 
-In order to be able to use the data loaded from the remote store when the app is
-offline, Breethe defines a second source that is backed by `IndexedDB` and that
-all data that enters the store via the remote source is synced into:
+In order to be able to use the data loaded from the remote store when the app is offline, Breethe defines a second source that is backed by `IndexedDB` and that all data that enters the store via the remote source is synced into:
 
 ```typescript
 import IndexedDBSource from "@orbit/indexeddb";
@@ -462,46 +304,17 @@ store.on("transform", transform => {
 });
 ```
 
-With this setup, all data that gets loaded by the app while the device is online
-is available for later offline use, where it will be read from `IndexedDB`
-instead. This mechanism works the other way round as well of course, such that
-the app could buffer any modifications to data in the store in `IndexedDB` while
-offline and then sync these changes back to the remote API once the device comes
-back online - refer to the [Orbit.js docs](http://orbitjs.com/v0.15/guide/) for
-more information about advanced mechanics like this.
+With this setup, all data that gets loaded by the app while the device is online is available for later offline use, where it will be read from `IndexedDB` instead. This mechanism works the other way round as well of course, such that the app could buffer any modifications to data in the store in `IndexedDB` while offline and then sync these changes back to the remote API once the device comes back online - refer to the [Orbit.js docs](http://orbitjs.com/v0.15/guide/) for more information about advanced mechanics like this.
 
-With the combination of service workers and `IndexedDB`, PWAs are fully
-independent of the network status and offer the same experience as native apps
-when the device is offline. Modern libraries like Orbit.js make it easy to
-manage data independently of the network condition and abstract most of the
-details behind convenient APIs.
+With the combination of service workers and `IndexedDB`, PWAs are fully independent of the network status and offer the same experience as native apps when the device is offline. Modern libraries like Orbit.js make it easy to manage data independently of the network condition and abstract most of the details behind convenient APIs.
 
 ## Testing
 
-Testing is an essential part of modern software engineering and we at Mainmatter
-(and I'm sure this is true for anyone reading this as well) would **never ship
-code that is not fully tested** - as we could not know whether the code actually
-works or whether we subsequently break it when making changes. The first thing
-that comes to mind when thinking about tests are typically unit tests that test
-a small part of an app (a unit) in isolation. Depending on the framework of
-choice and its testing philosophy and tools, there might also be means of
-[higher level test](https://guides.emberjs.com/release/testing/testing-components/)
-that test larger subsets of an app (and we have
-[quite](https://github.com/mainmatter/breethe-client/blob/master/src/ui/components/MeasurementRow/component-test.ts)
-[a lot](https://github.com/mainmatter/breethe-client/blob/master/src/ui/components/SearchForm/component-test.ts)
-of these for Breethe).
-
-Testing PWAs, in particular their offline behavior, is slightly different though
-as it requires the correct interplay of various parts that cannot be isolated
-well - namely the app itself, the service worker, storage APIs like `IndexedDB`
-and the browser. A proper PWA test suite needs to take all of these parts into
-account and have a higher level perspective on the system under test than is the
-case in a unit test. A great tool for tests like these is Google's
-[puppeteer](https://pptr.dev) that allows running and controlling a headless
-instance of Chrome.
-
-Combining puppeteer with mocha allows for writing high level test cases that
-test a PWA in its entirety:
+Testing is an essential part of modern software engineering and we at Mainmatter (and I'm sure this is true for anyone reading this as well) would **never ship code that is not fully tested** - as we could not know whether the code actually works or whether we subsequently break it when making changes. The first thing that comes to mind when thinking about tests are typically unit tests that test a small part of an app (a unit) in isolation. Depending on the framework of choice and its testing philosophy and tools, there might also be means of [higher level test](https://guides.emberjs.com/release/testing/testing-components/) that test larger subsets of an app (and we have [quite](https://github.com/mainmatter/breethe-client/blob/master/src/ui/components/MeasurementRow/component-test.ts) [a lot](https://github.com/mainmatter/breethe-client/blob/master/src/ui/components/SearchForm/component-test.ts) of these for Breethe).
+
+Testing PWAs, in particular their offline behavior, is slightly different though as it requires the correct interplay of various parts that cannot be isolated well - namely the app itself, the service worker, storage APIs like `IndexedDB` and the browser. A proper PWA test suite needs to take all of these parts into account and have a higher level perspective on the system under test than is the case in a unit test. A great tool for tests like these is Google's [puppeteer](https://pptr.dev) that allows running and controlling a headless instance of Chrome.
+
+Combining puppeteer with mocha allows for writing high level test cases that test a PWA in its entirety:
 
 ```js
 {% raw %}
@@ -550,30 +363,10 @@ describe('when offline', function () {
 {% endraw %}
 ```
 
-This test uses
-[puppeteer's API](https://github.com/GoogleChrome/puppeteer/blob/v1.5.0/docs/api.md)
-to create a new browser object (which will start an actual instance of Chrome in
-the background), open a page, interact with DOM elements and assert on their
-presence and state. It starts by going through the app's main flow once so data
-is loaded from the API and `IndexedDB` is populated. It then disables the
-network (`page.setOfflineMode(true)`), reloads the page (which is then served
-from the service worker that was registered during first load) and asserts on
-the DOM correctly being generated from the data read from `IndexedDB`.
-
-A testing setup like this makes it easy to achieve decent test coverage for
-PWAs, testing all of the parts involved - the app itself but also the service
-worker and storage APIs like `IndexedDB`. These test are even reasonably fast to
-execute -
-[Breethe's suite of puppeteer tests](https://github.com/mainmatter/breethe-client/tree/master/integration-tests)
-completes in around 1min.
+This test uses [puppeteer's API](https://github.com/GoogleChrome/puppeteer/blob/v1.5.0/docs/api.md) to create a new browser object (which will start an actual instance of Chrome in the background), open a page, interact with DOM elements and assert on their presence and state. It starts by going through the app's main flow once so data is loaded from the API and `IndexedDB` is populated. It then disables the network (`page.setOfflineMode(true)`), reloads the page (which is then served from the service worker that was registered during first load) and asserts on the DOM correctly being generated from the data read from `IndexedDB`.
+
+A testing setup like this makes it easy to achieve decent test coverage for PWAs, testing all of the parts involved - the app itself but also the service worker and storage APIs like `IndexedDB`. These test are even reasonably fast to execute - [Breethe's suite of puppeteer tests](https://github.com/mainmatter/breethe-client/tree/master/integration-tests) completes in around 1min.
 
 ## Outlook
 
-This post and the
-[previous one](/blog/2018/07/03/building-a-pwa-with-glimmer-js) have given an
-overview of how to write an SPA (in this case with Glimmer.js) and then turning
-that into a [Progressive Web App](http://breethe.app). With Breethe, we haven't
-stopped there though but employed server side rendering to combine the
-advantages of a PWA with those of classic server rendered websites. In the next
-post in this series, we will have a detailed look at what specifically those
-advantages are and how we were able to achieve them.
+This post and the [previous one](/blog/2018/07/03/building-a-pwa-with-glimmer-js) have given an overview of how to write an SPA (in this case with Glimmer.js) and then turning that into a [Progressive Web App](http://breethe.app). With Breethe, we haven't stopped there though but employed server side rendering to combine the advantages of a PWA with those of classic server rendered websites. In the next post in this series, we will have a detailed look at what specifically those advantages are and how we were able to achieve them.
diff --git a/src/posts/2018-11-27-open-source-maintenance.md b/src/posts/2018-11-27-open-source-maintenance.md
index f831c8e970..02c8630070 100644
--- a/src/posts/2018-11-27-open-source-maintenance.md
+++ b/src/posts/2018-11-27-open-source-maintenance.md
@@ -2,9 +2,7 @@
 title: "Open Source Maintenance"
 authorHandle: tobiasbieniek
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek introduces best practices for simplifying and speeding up his
-  work on open-source and other projects."
+description: "Tobias Bieniek introduces best practices for simplifying and speeding up his work on open-source and other projects."
 tags: misc
 tagline: |
   <p>People often ask us how we can handle maintaining a large number of open-source projects. In this blog post we will introduce you to some of out internal best practices we have developed or discovered to simplify and speed up working on open-source and other projects.</p>
@@ -12,42 +10,19 @@ tagline: |
 
 ## Git
 
-Version control systems have always been an important part of professional
-software development, but the development of [git] over a decade ago and the
-subsequent development of [GitHub] has made version control mainstream for open
-source projects.
+Version control systems have always been an important part of professional software development, but the development of [git] over a decade ago and the subsequent development of [GitHub] has made version control mainstream for open source projects.
 
-While many tutorials focus on using Git from the command line, we have found
-that using a graphical user interface to visualize the history graph can make it
-quite a bit easier for beginners to understand what is going on. One good
-example of such a tool is [Fork], which is freely available for Windows and
-macOS:
+While many tutorials focus on using Git from the command line, we have found that using a graphical user interface to visualize the history graph can make it quite a bit easier for beginners to understand what is going on. One good example of such a tool is [Fork], which is freely available for Windows and macOS:
 
 ![Screenshot of Fork](/assets/images/posts/2018-11-27-open-source-maintenance/git-fork.png#@1173-2346)
 
-When working on multiple different projects, it is useful to rely on similar
-conventions, for example, when naming things. In the context of Git this is most
-relevant when naming
-[remotes](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes), tags
-and branches.
-
-When we publish new releases we "tag" the release commits with a tag name like
-`v1.2.3`, corresponding to the new version. When working in the JavaScript
-ecosystem we use `yarn version` (or `npm version`) to automatically adjust the
-`version` field in the `package.json` file, commit the change and finally create
-a tag on the new commit.
-
-For branches we use the default `master` branch as our main development branch.
-Feature branches are named after the thing that they are implementing or fixing
-and ideally only contain isolated, focused changes. Similar to the tag names we
-sometimes keep version branches around to support older releases with names like
-`v1.x` or `v2.3.x`.
-
-For remotes we use `upstream`, `origin` and for all other remotes the GitHub (or
-GitLab, BitBucket, etc.) username of the remote owner. `upstream` means the main
-project on GitHub and `origin` is my personal fork where I push feature
-branches, which will turn into PRs against the `upstream` repository. Here is an
-example for our `qunit-dom` project on my machine:
+When working on multiple different projects, it is useful to rely on similar conventions, for example, when naming things. In the context of Git this is most relevant when naming [remotes](https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes), tags and branches.
+
+When we publish new releases we "tag" the release commits with a tag name like `v1.2.3`, corresponding to the new version. When working in the JavaScript ecosystem we use `yarn version` (or `npm version`) to automatically adjust the `version` field in the `package.json` file, commit the change and finally create a tag on the new commit.
+
+For branches we use the default `master` branch as our main development branch. Feature branches are named after the thing that they are implementing or fixing and ideally only contain isolated, focused changes. Similar to the tag names we sometimes keep version branches around to support older releases with names like `v1.x` or `v2.3.x`.
+
+For remotes we use `upstream`, `origin` and for all other remotes the GitHub (or GitLab, BitBucket, etc.) username of the remote owner. `upstream` means the main project on GitHub and `origin` is my personal fork where I push feature branches, which will turn into PRs against the `upstream` repository. Here is an example for our `qunit-dom` project on my machine:
 
 | Name         | URL                                       |
 | ------------ | ----------------------------------------- |
@@ -56,24 +31,20 @@ example for our `qunit-dom` project on my machine:
 | `lukemelia`  | `git@github.com:lukemelia/qunit-dom.git`  |
 | `jackbeegan` | `git@github.com:jackbeegan/qunit-dom.git` |
 
-Why is this useful? Because it allows us to define
-[shell aliases](https://shapeshed.com/unix-alias/) for some of the most commonly
-used git commands for which we don't use a graphical user interface. Here are a
-few examples of things we regularly use:
-
-| Alias | Command                       | Description                                                                                           |
-| ----- | ----------------------------- | ----------------------------------------------------------------------------------------------------- |
-| `cl`  | `git clone`                   | Clones a repository                                                                                   |
-| `clu` | `git clone --origin=upstream` | Clones a repository, and uses `upstream` as the default remote name                                   |
-| `ao`  | `git remote add origin`       | Adds a new remote called `origin`                                                                     |
-| `gfu` | `git fetch upstream`          | Updates the local copies of the `upstream` remote branches                                            |
-| `gfo` | `git fetch origin`            | Updates the local copies of the `origin` remote branches                                              |
-| `gp`  | `git push`                    | Pushes the current branch to the corresponding remote                                                 |
-| `gph` | `git push -u origin HEAD`     | Pushes the current branch as a new branch to the `origin` remote                                      |
+Why is this useful? Because it allows us to define [shell aliases](https://shapeshed.com/unix-alias/) for some of the most commonly used git commands for which we don't use a graphical user interface. Here are a few examples of things we regularly use:
+
+| Alias | Command | Description |
+| --- | --- | --- |
+| `cl` | `git clone` | Clones a repository |
+| `clu` | `git clone --origin=upstream` | Clones a repository, and uses `upstream` as the default remote name |
+| `ao` | `git remote add origin` | Adds a new remote called `origin` |
+| `gfu` | `git fetch upstream` | Updates the local copies of the `upstream` remote branches |
+| `gfo` | `git fetch origin` | Updates the local copies of the `origin` remote branches |
+| `gp` | `git push` | Pushes the current branch to the corresponding remote |
+| `gph` | `git push -u origin HEAD` | Pushes the current branch as a new branch to the `origin` remote |
 | `gpf` | `git push --force-with-lease` | Pushes the current branch to the corresponding remote, overwriting the existing history of the branch |
 
-With these commands we can already speed up our workflow quite significantly.
-Here is an example for working on `qunit-dom` from zero to open pull request:
+With these commands we can already speed up our workflow quite significantly. Here is an example for working on `qunit-dom` from zero to open pull request:
 
 ```bash
 clu git@github.com:mainmatter/qunit-dom.git
@@ -87,147 +58,68 @@ gph
 
 ## Tests
 
-Having a good test suite is very important to be able to change code and be
-confident that the change is not breaking anything. This is one of the major
-reasons why we love [Ember.js], because it comes with a great testing system
-out-of-the-box and allows us to write tests for all of the critical parts of the
-apps that we develop.
+Having a good test suite is very important to be able to change code and be confident that the change is not breaking anything. This is one of the major reasons why we love [Ember.js], because it comes with a great testing system out-of-the-box and allows us to write tests for all of the critical parts of the apps that we develop.
 
-You can find more information on testing in Ember.js on the official
-[guides](https://guides.emberjs.com/release/testing/).
+You can find more information on testing in Ember.js on the official [guides](https://guides.emberjs.com/release/testing/).
 
-But this topic not limited to just Ember.js, other ecosystems have similar
-tools. For Node.js the most popular testing solutions these days are [Jest] and
-[Mocha]. In the [Rust] ecosystem testing is already built into their package
-manager [cargo], but there are
-[plenty of crates](https://github.com/rust-unofficial/awesome-rust#testing) to
-make testing even more pleasant, including the very valuable [proptest] crate.
+But this topic not limited to just Ember.js, other ecosystems have similar tools. For Node.js the most popular testing solutions these days are [Jest] and [Mocha]. In the [Rust] ecosystem testing is already built into their package manager [cargo], but there are [plenty of crates](https://github.com/rust-unofficial/awesome-rust#testing) to make testing even more pleasant, including the very valuable [proptest] crate.
 
 ## Linting
 
-Similar to testing frameworks, a lot of ecosystems have tools to run "static
-analysis" on your code to find bugs before you even run the applications. These
-tools are often called "Linters".
+Similar to testing frameworks, a lot of ecosystems have tools to run "static analysis" on your code to find bugs before you even run the applications. These tools are often called "Linters".
 
-A very popular linter in the JavaScript world is [ESLint], which we often run in
-combination with [Prettier], to also ensure that our code is formatted in a
-consistent way.
+A very popular linter in the JavaScript world is [ESLint], which we often run in combination with [Prettier], to also ensure that our code is formatted in a consistent way.
 
-Again, similar tools also exist in other ecosystems like Rust ([clippy] and
-[rustfmt]), Python ([pyflakes] and [black]) or Elixir (`mix format`).
+Again, similar tools also exist in other ecosystems like Rust ([clippy] and [rustfmt]), Python ([pyflakes] and [black]) or Elixir (`mix format`).
 
 ## Continuous Integration
 
-The above points about testing and linting are nice to have, but if nobody runs
-your tests then they don't provide any value. This is where continuous
-integration (or short "CI") systems come into play. These kinds of systems are
-coupled to your version control servers and automatically run linting checks and
-tests whenever you upload new commits to the server.
-
-Most of the time we use [TravisCI] for this purpose, which is coupled to GitHub,
-free for open source projects, and supports running your tests on Linux and
-macOS, and will soon support Windows too. Alternatives include the CI service
-that is integrated into [GitLab], [CircleCI] (based on Docker images) and
-[AppVeyor], which we currently use to test Windows support on projects where
-this is relevant.
-
-One important thing to mention here is that CI can not only run your test suite
-but can often also do other things like publishing new versions of your
-projects. On most of our projects we have configured TravisCI to automatically
-publish new releases to [npm] whenever we push a new Git tag to the server. You
-can find instruction on how to configure this in their official
-[documentation](https://docs.travis-ci.com/user/deployment/npm/).
+The above points about testing and linting are nice to have, but if nobody runs your tests then they don't provide any value. This is where continuous integration (or short "CI") systems come into play. These kinds of systems are coupled to your version control servers and automatically run linting checks and tests whenever you upload new commits to the server.
+
+Most of the time we use [TravisCI] for this purpose, which is coupled to GitHub, free for open source projects, and supports running your tests on Linux and macOS, and will soon support Windows too. Alternatives include the CI service that is integrated into [GitLab], [CircleCI] (based on Docker images) and [AppVeyor], which we currently use to test Windows support on projects where this is relevant.
+
+One important thing to mention here is that CI can not only run your test suite but can often also do other things like publishing new versions of your projects. On most of our projects we have configured TravisCI to automatically publish new releases to [npm] whenever we push a new Git tag to the server. You can find instruction on how to configure this in their official [documentation](https://docs.travis-ci.com/user/deployment/npm/).
 
 ## Semantic Versioning
 
-Semantic Versioning (or short "semver") is a way to assign meaning to version
-numbers, and specifically to version number changes. The official
-[specification](https://semver.org/) is a little longer, but there are five
-important rules:
-
-1. version numbers have three main parts called major, minor and patch version
-   (Example: `v3.0.1`, major is `3`, minor is `0` and patch version is `1`)
-2. when your release includes any changes that might break the apps of existing
-   users you should increase the **major** version
-3. when your release includes only bug fixes you should increase the **patch**
-   version
+Semantic Versioning (or short "semver") is a way to assign meaning to version numbers, and specifically to version number changes. The official [specification](https://semver.org/) is a little longer, but there are five important rules:
+
+1. version numbers have three main parts called major, minor and patch version (Example: `v3.0.1`, major is `3`, minor is `0` and patch version is `1`)
+2. when your release includes any changes that might break the apps of existing users you should increase the **major** version
+3. when your release includes only bug fixes you should increase the **patch** version
 4. for all other changes you should increase the **minor** version
-5. if your version is below `v1.0.0` (e.g. `v0.4.3`) you can release breaking
-   changes without increasing the major version because the project is
-   considered "unstable"
-
-Since the majority of package managers including [yarn], [cargo], [hex] and
-[bundler] follow these semantics when resolving dependencies, it is very
-important to comply with these rules. But they are also useful in order for your
-users to get a sense of what they can expect from a new release.
-
-While this can be controversial, we consider dropping support for older Node.js,
-Elixir, Ruby, Rust, or other language releases a breaking change. This means
-that if your package
-[declares](https://docs.npmjs.com/files/package.json#engines) that it works with
-Node.js 4, and you release a new version that needs at least Node.js 6, then you
-should increase the **major** version.
+5. if your version is below `v1.0.0` (e.g. `v0.4.3`) you can release breaking changes without increasing the major version because the project is considered "unstable"
+
+Since the majority of package managers including [yarn], [cargo], [hex] and [bundler] follow these semantics when resolving dependencies, it is very important to comply with these rules. But they are also useful in order for your users to get a sense of what they can expect from a new release.
+
+While this can be controversial, we consider dropping support for older Node.js, Elixir, Ruby, Rust, or other language releases a breaking change. This means that if your package [declares](https://docs.npmjs.com/files/package.json#engines) that it works with Node.js 4, and you release a new version that needs at least Node.js 6, then you should increase the **major** version.
 
 ## Dependency Update Services
 
-Any sufficiently large open source project has at least a few dependencies that
-it is built upon, and even smaller projects typically have at least a dependency
-on a test framework. While keeping the dependencies of a single project
-up-to-date is a manageable task, it is becoming a full-time job once you
-maintain a larger number of separate projects.
-
-Fortunately for us this is a task that can be automated quite well, at least if
-you have a good test suite and continuous integration set up. While we first
-used [Greenkeeper] for this task, we have lately transitioned to using
-[dependabot], which supports not only npm, but all sorts of different package
-managers, language ecosystems, and even monorepos.
-
-Dependabot will automatically open Pull Requests on your projects whenever one
-of your dependencies has published a new version. This will cause your CI
-service to run the test suite against that new dependency version and tell you
-whether it is compatible with your code or not. If configured, dependabot can
-also automatically merge those Pull Requests once CI has finished and the test
-suite passed.
+Any sufficiently large open source project has at least a few dependencies that it is built upon, and even smaller projects typically have at least a dependency on a test framework. While keeping the dependencies of a single project up-to-date is a manageable task, it is becoming a full-time job once you maintain a larger number of separate projects.
+
+Fortunately for us this is a task that can be automated quite well, at least if you have a good test suite and continuous integration set up. While we first used [Greenkeeper] for this task, we have lately transitioned to using [dependabot], which supports not only npm, but all sorts of different package managers, language ecosystems, and even monorepos.
+
+Dependabot will automatically open Pull Requests on your projects whenever one of your dependencies has published a new version. This will cause your CI service to run the test suite against that new dependency version and tell you whether it is compatible with your code or not. If configured, dependabot can also automatically merge those Pull Requests once CI has finished and the test suite passed.
 
 ## Changelogs
 
-While Semantic Versioning helps your users to know if they need to expect
-breaking changes from a release, it is much better to have a human-readable list
-of changes that went into a release. This is what a "Changelog" is for.
-Typically this is a `CHANGELOG.md` file in the root folder of your project that
-lists all your released versions including the changes that went into each
-release.
-
-It can be quite tedious to write these things by hand, but fortunately there are
-generators that can do most of the work for us. These generators can be divided
-into two groups:
-
-1. the first group is based on
-   [semantic commit messages](https://seesparkbox.com/foundry/semantic_commit_messages)
-   and lists all of the commits that are part of a certain release
-2. the second group is based upon GitHub Pull Requests (or similar) and uses
-   issue/PR labels to categorize changes
-
-While "semantic commit messages" seem to be quite popular we prefer the second
-group of changelog generators, as listing each commit often results in a long
-list of very fine-grained changes that are not directly helpful to the user.
-
-Instead we use [lerna-changelog] to generate our changelogs from all of the
-merged pull requests that went into each of the releases. To make this work
-properly it is important to focus each pull request on only one single, logical
-change, and label it properly as either `enhancement`, `bug`, `breaking`, or any
-of the other supported/configured labels. To ensure that all of our projects use
-the same set of labels we use [github-label-sync].
-
-An
-[example changelog](https://github.com/mainmatter/qunit-dom/blob/master/CHANGELOG.md)
-can be seen on our qunit-dom project.
+While Semantic Versioning helps your users to know if they need to expect breaking changes from a release, it is much better to have a human-readable list of changes that went into a release. This is what a "Changelog" is for. Typically this is a `CHANGELOG.md` file in the root folder of your project that lists all your released versions including the changes that went into each release.
+
+It can be quite tedious to write these things by hand, but fortunately there are generators that can do most of the work for us. These generators can be divided into two groups:
+
+1. the first group is based on [semantic commit messages](https://seesparkbox.com/foundry/semantic_commit_messages) and lists all of the commits that are part of a certain release
+2. the second group is based upon GitHub Pull Requests (or similar) and uses issue/PR labels to categorize changes
+
+While "semantic commit messages" seem to be quite popular we prefer the second group of changelog generators, as listing each commit often results in a long list of very fine-grained changes that are not directly helpful to the user.
+
+Instead we use [lerna-changelog] to generate our changelogs from all of the merged pull requests that went into each of the releases. To make this work properly it is important to focus each pull request on only one single, logical change, and label it properly as either `enhancement`, `bug`, `breaking`, or any of the other supported/configured labels. To ensure that all of our projects use the same set of labels we use [github-label-sync].
+
+An [example changelog](https://github.com/mainmatter/qunit-dom/blob/master/CHANGELOG.md) can be seen on our qunit-dom project.
 
 ## Summary
 
-We hope that this blog post helped you improve your processes and speed up your
-own development. If you need help with any of these topics or if you have
-questions we encourage you to [contact us](/contact/)!
+We hope that this blog post helped you improve your processes and speed up your own development. If you need help with any of these topics or if you have questions we encourage you to [contact us](/contact/)!
 
 [git]: https://git-scm.com/
 [github]: https://github.com/
diff --git a/src/posts/2018-12-10-assert-your-style.md b/src/posts/2018-12-10-assert-your-style.md
index 6282a182d2..539c14e139 100644
--- a/src/posts/2018-12-10-assert-your-style.md
+++ b/src/posts/2018-12-10-assert-your-style.md
@@ -2,9 +2,7 @@
 title: "Assert Your Style - Testing CSS in Ember Apps"
 authorHandle: jjordan_dev
 bio: "Senior Frontend Engineer, Ember Learning core team member"
-description:
-  "Jessica Jordan explains approaches and patterns for testing styles in
-  Ember.js applications."
+description: "Jessica Jordan explains approaches and patterns for testing styles in Ember.js applications."
 tags: javascript
 og:
   image: /assets/images/posts/2018-12-10-assert-your-style/og-image.jpg
@@ -12,18 +10,13 @@ tagline: |
   <p>Sometimes you really want to make sure that your web application looks good; and that it keeps doing so in the future. <strong>Automated tests</strong> are an important foundation for making your application's appearance future-proof and this may involve the integration of a screenshot-based testing tool like <a href="https://percy.io/">Percy.io</a> or <a href="https://github.com/HuddleEng/PhantomCSS">PhantomCSS</a>.</p> <p>But writing your own <strong>visual regression tests</strong> for critical styles in your application can be really useful, too - and it can be easily done on top of that!</p>
 ---
 
-These are a few approaches you can choose from to assert against the styling of
-your web page as part of your automated integration and acceptance test suite:
+These are a few approaches you can choose from to assert against the styling of your web page as part of your automated integration and acceptance test suite:
 
 ## Testing Inline Styles of a HTML Element
 
-Although it's a good practice to keep your HTML and your CSS entirely separate,
-**inline styles** on components and other elements in your application are
-sometimes necessary to be able to apply CSS property values that change
-dynamically. And testing those styles can be important, too.
+Although it's a good practice to keep your HTML and your CSS entirely separate, **inline styles** on components and other elements in your application are sometimes necessary to be able to apply CSS property values that change dynamically. And testing those styles can be important, too.
 
-Imagine you created a component with an inline style attached to it assigning a
-variable blue background color to it:
+Imagine you created a component with an inline style attached to it assigning a variable blue background color to it:
 
 ```js
 {% raw %}
@@ -49,8 +42,7 @@ export default Component.extend({
 {% endraw %}
 ```
 
-Using `ember-test-selectors` to apply `data-` attributes to this component, you
-can make it easier to interact with your component later on in the test.
+Using `ember-test-selectors` to apply `data-` attributes to this component, you can make it easier to interact with your component later on in the test.
 
 ```bash
 ember install ember-test-selectors
@@ -83,13 +75,9 @@ export default Component.extend({
 {% endraw %}
 ```
 
-To learn more about the rationale behind `ember-test-selectors`, be sure to also
-[give this introduction a read](/blog/2017/11/17/ember-test-selectors-road-to-1-0).
+To learn more about the rationale behind `ember-test-selectors`, be sure to also [give this introduction a read](/blog/2017/11/17/ember-test-selectors-road-to-1-0).
 
-Using the
-[HTMLElement.style](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/style)
-API, we can assert if the correct background color has been applied to our
-component:
+Using the [HTMLElement.style](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/style) API, we can assert if the correct background color has been applied to our component:
 
 ```js
 {% raw %}
@@ -112,48 +100,21 @@ module('Integration | Component | mainmatter-logo-tile', function (hooks) {
 {% endraw %}
 ```
 
-`HTMLElement.style` allows to check for the value of **individual CSS
-properties**. The same API can also be used to assign new values for any CSS
-property programmatically. You can read more about
-[the style attribute in the MDN docs on HTMLElement.style here](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/style).
+`HTMLElement.style` allows to check for the value of **individual CSS properties**. The same API can also be used to assign new values for any CSS property programmatically. You can read more about [the style attribute in the MDN docs on HTMLElement.style here](https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/style).
 
-A major **benefit** of testing **CSS properties** directly is that it allows us
-to derive information on how inline styles are applied to elements in our
-application. This is particularly useful if we want to test **dynamic styles**.
+A major **benefit** of testing **CSS properties** directly is that it allows us to derive information on how inline styles are applied to elements in our application. This is particularly useful if we want to test **dynamic styles**.
 
-**Testing inline styles** also has its **drawbacks** though: these styles don't
-necessarily reflect the way the element is ultimately rendered on the page. In
-this situation the assertion against an element's **computed style** provides
-much more insight.
+**Testing inline styles** also has its **drawbacks** though: these styles don't necessarily reflect the way the element is ultimately rendered on the page. In this situation the assertion against an element's **computed style** provides much more insight.
 
 ## Testing Computed Styles of a HTML Element
 
-At times you also want to check against the actual **computed value** of your
-element in your tests. Some CSS definitions require the browser to resolve the
-basic computation, the actual computed styles will be applied during rendering.
-For example, in the case of an element with a percentage-based width defined via
-CSS stylesheets (e.g. `width: 80%`), the computed style will resolve to
-`width: 800px` if the element happens to be a relatively positioned
-(`position: relative`) child element of another DOM node with a computed width
-of `1000px`. If the element's parent element turns out to have a width of
-`500px` though, the computed width of the "80% wide" child will resolve to a
-mere `400px`.
-
-Computed styles provide information about the styles that are **ultimately
-assigned** to an element. Due to
-[CSS specificity](https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)
-browsers will decide which CSS property value either defined in a CSS stylesheet
-or an inline style is most relevant and this value will also be reflected in the
-element's computed styles.
-
-The
-[getComputedStyle method](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle)
-will return an object containing these most relevant style values. In contrast
-to the object returned from `HTMLElement.style` the return value of
-`getComputedStyle` is read-only.
-
-Therefore the `getComputedStyle` method is the ideal candidate for asserting
-styles of an element in rendering tests:
+At times you also want to check against the actual **computed value** of your element in your tests. Some CSS definitions require the browser to resolve the basic computation, the actual computed styles will be applied during rendering. For example, in the case of an element with a percentage-based width defined via CSS stylesheets (e.g. `width: 80%`), the computed style will resolve to `width: 800px` if the element happens to be a relatively positioned (`position: relative`) child element of another DOM node with a computed width of `1000px`. If the element's parent element turns out to have a width of `500px` though, the computed width of the "80% wide" child will resolve to a mere `400px`.
+
+Computed styles provide information about the styles that are **ultimately assigned** to an element. Due to [CSS specificity](https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity) browsers will decide which CSS property value either defined in a CSS stylesheet or an inline style is most relevant and this value will also be reflected in the element's computed styles.
+
+The [getComputedStyle method](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle) will return an object containing these most relevant style values. In contrast to the object returned from `HTMLElement.style` the return value of `getComputedStyle` is read-only.
+
+Therefore the `getComputedStyle` method is the ideal candidate for asserting styles of an element in rendering tests:
 
 ```js
 {% raw %}
@@ -184,14 +145,9 @@ module('Integration | Component | mainmatter-logo-tile', function (hooks) {
 
 ## Easy Style Assertions with qunit-dom
 
-Now we know how we can write style-related tests for our automated test process
-that assert that the expected styles are applied to elements on the web page.
+Now we know how we can write style-related tests for our automated test process that assert that the expected styles are applied to elements on the web page.
 
-But there's an even easier way to assert the computed styles of elements in your
-**QUnit test suite**. Since
-[v0.8.1](https://twitter.com/mainmatter/status/1065913669995978752) of
-[qunit-dom](/blog/2017/10/24/high-level-assertions-with-qunit-dom) you can make
-your tests truly ✨
+But there's an even easier way to assert the computed styles of elements in your **QUnit test suite**. Since [v0.8.1](https://twitter.com/mainmatter/status/1065913669995978752) of [qunit-dom](/blog/2017/10/24/high-level-assertions-with-qunit-dom) you can make your tests truly ✨
 
 Check it [out](https://github.com/mainmatter/qunit-dom):
 
@@ -205,8 +161,7 @@ or
 yarn add --dev qunit-dom
 ```
 
-In your rendering test you're now able to check for the component's style using
-the `hasStyle` method:
+In your rendering test you're now able to check for the component's style using the `hasStyle` method:
 
 ```js
 {% raw %}
@@ -230,14 +185,10 @@ module('Integration | Component | mainmatter-logo-tile', function (hooks) {
 {% endraw %}
 ```
 
-You can read more about the usage of the `.hasStyle` method in the
-[API documentation](https://github.com/mainmatter/qunit-dom/blob/master/API.md#hasStyle).
+You can read more about the usage of the `.hasStyle` method in the [API documentation](https://github.com/mainmatter/qunit-dom/blob/master/API.md#hasStyle).
 
 ---
 
-There are different ways to assert against inline styles and computed styles in
-your application and if you're using Ember & QUnit,
-[qunit-dom](https://github.com/mainmatter/qunit-dom) is your best bet to make
-your style tests easy to write and read.
+There are different ways to assert against inline styles and computed styles in your application and if you're using Ember & QUnit, [qunit-dom](https://github.com/mainmatter/qunit-dom) is your best bet to make your style tests easy to write and read.
 
 Questions? Suggestions? [Contact us!](/contact/)
diff --git a/src/posts/2018-12-20-factories-best-practices.md b/src/posts/2018-12-20-factories-best-practices.md
index 4b363a5894..599cab383c 100644
--- a/src/posts/2018-12-20-factories-best-practices.md
+++ b/src/posts/2018-12-20-factories-best-practices.md
@@ -3,61 +3,24 @@ title: "Factories best practices"
 authorHandle: geekygrappler
 tags: testing
 bio: "Senior Frontend Engineer"
-description:
-  "Andy Brown introduces best practices for using factories in order to make
-  your colleagues' and your own future self's lives easier."
+description: "Andy Brown introduces best practices for using factories in order to make your colleagues' and your own future self's lives easier."
 tagline: |
   <p>Writing tests is like drinking beer 🍻. When you first try it, the taste is really quite unpalatable, but everyone else around you is doing it and they seem to be enjoying it. You've heard about all the benefits of it, people won't stop telling you how great it is, how it changed their lives for the better. Also there is a lot of peer pressure and judgement involved, don't be that dev... so you conceal your grimace and keep trying it, on a daily basis here at Mainmatter. And just like beer, in no time at all, on a long hot day, when you feel yourself tiring of writing all those features and tweaking all that CSS, you realise that what you need to relax is to write a good, concise, logical, cool and refreshing test. At least that's been my experience and I want to share a few tips for factories so that your tests are easy for your <s>friends</s>, <s>colleagues</s>, the next developer to read.</p>
 ---
 
 ## AAA
 
-Before I dive into factories, firstly I want to mention AAA: Arrange, Act,
-Assert. I covered this paradigm over [here](/blog/2017/09/17/magic-test-data/),
-and I still stand by it. It's the most important thing you can do to make your
-tests straight forward and understandable for others.
+Before I dive into factories, firstly I want to mention AAA: Arrange, Act, Assert. I covered this paradigm over [here](/blog/2017/09/17/magic-test-data/), and I still stand by it. It's the most important thing you can do to make your tests straight forward and understandable for others.
 
 ## Factories > Fixtures
 
-Fixtures are hard coded data, a file with data representing a model in it, or
-any data that your application needs. Factories generate data dynamically, using
-functions, and can be called upon during the test with parameters passed to
-manipulate to output data.
-
-I would strongly discourage the use of fixtures. There are many excellent posts
-out there comparing factories and fixtures, and, apart from the ones that are
-wrong, they all say that factories > fixtures 🎉. I want to focus on one
-particular use case I've seen a few times, which often leads to the inclusion of
-fixtures in a mostly factory based test suite.
-
-In most applications there is often one gnarly model. In ecommerce applications
-it tends to be something like `order`. This will have many `products`, belong to
-a `user`, may have some reference to a `payment` and `delivery`, maybe it will
-have some kind of self referential relationship, or polymorphic relationship.
-You get the picture, it's got a lot of stuff, it's grown over time to become and
-all-encompassing monster and it _will_ make your head hurt to think about it.
-It's often in these situtaion that we reach for a fixture, sometimes we even
-copy and paste a response from our production API 😱.
-
-The full API response fixture is the worst kind of fixture and it is a code
-smell. It means that rather than creating a declarative test that will help
-future developers (and your future self) understand what parts of this model are
-important for a particular test and how the model works, you get a 1,203 line
-json file. If I ever see a fixture like this while fixing a broken test, I have
-to replace it with a factory. I don't do this because I like creating extra work
-for myself, believe me, I don't. I do it because I don't understand what
-specific parts of that model were important to the test by looking at the
-fixture. In order to fix the test I need to figure out how the model works. I
-try to build a mental picture of the model and create the data for the test
-using a factory (often many factories pulled together), so it's clear and
-concise what parts of the `order` are required for the
-`orders with multiple deliveries arriving on the same day, only show 1 estimated delivery date not multiple`
-test. In this test (which is fantastically named), I can expect to see an
-`order` factory which has a `delivery` factory with more than one delivery, but
-all planned for the same day. All the other parts of the `order` model are
-likely not relevant to this test, so don't include them, or leave them as the
-defaults. Some pseudocode as we're so far into the post without a single line of
-it.
+Fixtures are hard coded data, a file with data representing a model in it, or any data that your application needs. Factories generate data dynamically, using functions, and can be called upon during the test with parameters passed to manipulate to output data.
+
+I would strongly discourage the use of fixtures. There are many excellent posts out there comparing factories and fixtures, and, apart from the ones that are wrong, they all say that factories > fixtures 🎉. I want to focus on one particular use case I've seen a few times, which often leads to the inclusion of fixtures in a mostly factory based test suite.
+
+In most applications there is often one gnarly model. In ecommerce applications it tends to be something like `order`. This will have many `products`, belong to a `user`, may have some reference to a `payment` and `delivery`, maybe it will have some kind of self referential relationship, or polymorphic relationship. You get the picture, it's got a lot of stuff, it's grown over time to become and all-encompassing monster and it _will_ make your head hurt to think about it. It's often in these situtaion that we reach for a fixture, sometimes we even copy and paste a response from our production API 😱.
+
+The full API response fixture is the worst kind of fixture and it is a code smell. It means that rather than creating a declarative test that will help future developers (and your future self) understand what parts of this model are important for a particular test and how the model works, you get a 1,203 line json file. If I ever see a fixture like this while fixing a broken test, I have to replace it with a factory. I don't do this because I like creating extra work for myself, believe me, I don't. I do it because I don't understand what specific parts of that model were important to the test by looking at the fixture. In order to fix the test I need to figure out how the model works. I try to build a mental picture of the model and create the data for the test using a factory (often many factories pulled together), so it's clear and concise what parts of the `order` are required for the `orders with multiple deliveries arriving on the same day, only show 1 estimated delivery date not multiple` test. In this test (which is fantastically named), I can expect to see an `order` factory which has a `delivery` factory with more than one delivery, but all planned for the same day. All the other parts of the `order` model are likely not relevant to this test, so don't include them, or leave them as the defaults. Some pseudocode as we're so far into the post without a single line of it.
 
 ```js
 {% raw %}
@@ -89,11 +52,7 @@ test('orders with deliveries from different carriers arriving on the same day, o
 
 ## Fun fun factories 🏭
 
-This is the part where young me thinks old me is a boring loser. Don't give your
-factories fun names 🙅‍♂️. Often with factory libraries you will be able to have a
-default model, e.g. `user` and you'll be able to have named factories e.g.
-`specialUser`. What is quite fun is to have themed names for your factories, for
-example:
+This is the part where young me thinks old me is a boring loser. Don't give your factories fun names 🙅‍♂️. Often with factory libraries you will be able to have a default model, e.g. `user` and you'll be able to have named factories e.g. `specialUser`. What is quite fun is to have themed names for your factories, for example:
 
 ```js
 {% raw %}
@@ -116,14 +75,7 @@ Factory.define({
 {% endraw %}
 ```
 
-Now while it's fun to have Game of Thrones characters in your testing code base,
-it is a terrible practice. At the moment the difference between Jon and Rob is
-quite clear, and if I was writing a test about inheritance of Winterfell, it
-would be clear with a quick scan of the factory file, what the difference
-between Jon and Rob is, regardless of whether I've watched GoT or not. However,
-even though I know nothing about this ficticious GoT app, I can promise you one
-thing, the model will grow with time and the list of attrs will start to grow
-for both of our heroes. Let me give one scenario for what could happen:
+Now while it's fun to have Game of Thrones characters in your testing code base, it is a terrible practice. At the moment the difference between Jon and Rob is quite clear, and if I was writing a test about inheritance of Winterfell, it would be clear with a quick scan of the factory file, what the difference between Jon and Rob is, regardless of whether I've watched GoT or not. However, even though I know nothing about this ficticious GoT app, I can promise you one thing, the model will grow with time and the list of attrs will start to grow for both of our heroes. Let me give one scenario for what could happen:
 
 ```js
 {% raw %}
@@ -206,14 +158,7 @@ Factory.define({
 {% endraw %}
 ```
 
-Now my example is a bit of fun, but my point is this: If you create wittily
-themed named factories, the attributes they contain will be unclear to everyone
-but you (and even to you on day 102). Often you will have a bare minimum number
-of attributes required for a certain model, e.g. every user must have a name and
-an email or the app will implode, and these things should live in the `default`
-factory. If you need to modify the default, and admin users are a good example
-of this, then keep the modification simple and make it obvious from the name
-what properties are changing.
+Now my example is a bit of fun, but my point is this: If you create wittily themed named factories, the attributes they contain will be unclear to everyone but you (and even to you on day 102). Often you will have a bare minimum number of attributes required for a certain model, e.g. every user must have a name and an email or the app will implode, and these things should live in the `default` factory. If you need to modify the default, and admin users are a good example of this, then keep the modification simple and make it obvious from the name what properties are changing.
 
 ```js
 {% raw %}
@@ -232,21 +177,15 @@ Factory.define({
 {% endraw %}
 ```
 
-But of course **you should not do this(!)**, even with sensible naming, because
-it will become a dumping ground for each attribute a test requires if it
-involves an admin user.
+But of course **you should not do this(!)**, even with sensible naming, because it will become a dumping ground for each attribute a test requires if it involves an admin user.
 
 Which leads me onto my final topic.
 
 ## Declarative factories
 
-Don't use named factories or traits, they're an antipattern\*. The admin user is
-again a good example where you might be tempted to use one of these. If your
-model is such that `isAdmin` boolean is all that is needed to make someone an
-admin then your test should be.
+Don't use named factories or traits, they're an antipattern\*. The admin user is again a good example where you might be tempted to use one of these. If your model is such that `isAdmin` boolean is all that is needed to make someone an admin then your test should be.
 
-<small>\* I think, I'm not really sure what an antipattern is, but humour
-me.</small>
+<small>\* I think, I'm not really sure what an antipattern is, but humour me.</small>
 
 ```js
 {% raw %}
@@ -263,15 +202,7 @@ test('Admin users are taken to the dashboard on login', async function(assert) {
 {% endraw %}
 ```
 
-This declarative factory use is slightly longer than `make('admin_user')` (👈
-named factory) or `make('user', 'isAdmin')` (👈 trait), but it's far superior,
-like the difference between Jon 💘 and Rob 💀. Yes both the named factory and
-the trait tell a reader that you're testing an admin (user), but the declarative
-factory version used here also tells the reader how a user becomes an admin,
-i.e. which properties are specifically important to adminship. Even if you
-require a few more attributes to become an admin, I would still recommend
-listing those attributes in the test, again informing any reader what attributes
-are related to becoming an admin.
+This declarative factory use is slightly longer than `make('admin_user')` (👈 named factory) or `make('user', 'isAdmin')` (👈 trait), but it's far superior, like the difference between Jon 💘 and Rob 💀. Yes both the named factory and the trait tell a reader that you're testing an admin (user), but the declarative factory version used here also tells the reader how a user becomes an admin, i.e. which properties are specifically important to adminship. Even if you require a few more attributes to become an admin, I would still recommend listing those attributes in the test, again informing any reader what attributes are related to becoming an admin.
 
 ```js
 {% raw %}
@@ -291,43 +222,19 @@ test('Admin users are taken to the dashboard on login', async function(assert) {
 {% endraw %}
 ```
 
-If this list becomes quite long and it is used in a lot of places, and I mean
-very long and _a lot_ of places, then maybe you could switch to a named factory
-or trait, but you would need to police it quite strictly and ensure that nothing
-else is added to that definition. What will happen is that developers add the
-attribute they need for their specific test to the definition, rather than
-writing it in the test, not realising that this attribute will now be created
-unneccessarily in all tests using this named factory or trait. This won't break
-those tests (usually), they'll be fine, but it leads to bloated factories and
-developers unaware of which attributes are strictly relevant to the test they're
-trying to fix.
+If this list becomes quite long and it is used in a lot of places, and I mean very long and _a lot_ of places, then maybe you could switch to a named factory or trait, but you would need to police it quite strictly and ensure that nothing else is added to that definition. What will happen is that developers add the attribute they need for their specific test to the definition, rather than writing it in the test, not realising that this attribute will now be created unneccessarily in all tests using this named factory or trait. This won't break those tests (usually), they'll be fine, but it leads to bloated factories and developers unaware of which attributes are strictly relevant to the test they're trying to fix.
 
 ## Don't use Mirage for tests - Ember bonus topic 🐹
 
-Let me premise this section by saying I have always been a Mirage fanboy. I have
-used it in a great number of my own personal projects for prototyping. I am not
-throwing shade at the project or any of it's creators/contributors. I simply
-have developed a strong opinion on where use of Mirage is appropriate. I prefer
-using
-[ember-data-factory-guy](https://github.com/danielspaniel/ember-data-factory-guy)
-(Factory Guy) in tests.
+Let me premise this section by saying I have always been a Mirage fanboy. I have used it in a great number of my own personal projects for prototyping. I am not throwing shade at the project or any of it's creators/contributors. I simply have developed a strong opinion on where use of Mirage is appropriate. I prefer using [ember-data-factory-guy](https://github.com/danielspaniel/ember-data-factory-guy) (Factory Guy) in tests.
 
 My arguments for not using Mirage:
 
 #### 1. Running a server for unit/integration tests
 
-In my opinion the main use for Mirage is as a rapid prototyping tool. It can
-also be used for testing, but by default, only testing in acceptance tests.
-Mirage provides you with a Javascript server that runs in the browser and
-intercepts API requests, responding to them before a network request is even
-made, either those requests made by your application in `dev` or those made
-during acceptance tests.
+In my opinion the main use for Mirage is as a rapid prototyping tool. It can also be used for testing, but by default, only testing in acceptance tests. Mirage provides you with a Javascript server that runs in the browser and intercepts API requests, responding to them before a network request is even made, either those requests made by your application in `dev` or those made during acceptance tests.
 
-If you want to use Mirage in testing, and you write more than acceptance tests
-then you will need to use a
-['hack' or 'workaround'](http://www.ember-cli-mirage.com/versions/v0.4.x/manually-starting-mirage/)
-to manually start and stop the mirage server during integration and unit tests.
-And you definitely should be writing integration and unit tests.
+If you want to use Mirage in testing, and you write more than acceptance tests then you will need to use a ['hack' or 'workaround'](http://www.ember-cli-mirage.com/versions/v0.4.x/manually-starting-mirage/) to manually start and stop the mirage server during integration and unit tests. And you definitely should be writing integration and unit tests.
 
 #### 2. Test Clarity
 
@@ -351,15 +258,9 @@ test('The page shows me all the foos', async function (assert) {
 {% endraw %}
 ```
 
-It's not bad, we are at least following AAA, but there is a step that is
-unclear, between adding foos to the server and them appearing on the page. The
-details of that are contained in Mirage's config file. Take a look at the
-equivalent test with Factory Guy for the data and
-[Pretender](https://github.com/pretenderjs/pretender) for mocking API calls
-(Mirage uses this under the hood\*).
+It's not bad, we are at least following AAA, but there is a step that is unclear, between adding foos to the server and them appearing on the page. The details of that are contained in Mirage's config file. Take a look at the equivalent test with Factory Guy for the data and [Pretender](https://github.com/pretenderjs/pretender) for mocking API calls (Mirage uses this under the hood\*).
 
-<small>\*Factory Guy also uses pretender under the hood to mock API calls for
-certain helper functions that you can use with Factory Guy if you want.</small>
+<small>\*Factory Guy also uses pretender under the hood to mock API calls for certain helper functions that you can use with Factory Guy if you want.</small>
 
 ```js
 {% raw %}
@@ -383,12 +284,7 @@ test('The page shows me all the foos', async function (assert) {
 {% endraw %}
 ```
 
-Here we're being a little more explicit in the test. Put yourself in the shoes
-of a junior developer. The Mirage test shows me _more_ Ember magic, even though
-they promised me there is a lot less magic now than there used to be in 2012.
-The factory test is more explicit, it tells us that visiting `/foos` url will
-trigger a `GET` request to `/api/foos` and we return a list of foos. It's a
-small difference but will help a junior to realise what
+Here we're being a little more explicit in the test. Put yourself in the shoes of a junior developer. The Mirage test shows me _more_ Ember magic, even though they promised me there is a lot less magic now than there used to be in 2012. The factory test is more explicit, it tells us that visiting `/foos` url will trigger a `GET` request to `/api/foos` and we return a list of foos. It's a small difference but will help a junior to realise what
 
 ```js
 {% raw %}
@@ -402,22 +298,9 @@ is actually doing.
 
 #### 3. Duplication & Complexity
 
-Mirage builds a server, with a database and its own ORM (Object-Relational
-Mapping). This is quite a complex and interesting set up. Mirage attempts to
-extract away this complexity and provide you with a simple API in order to
-prototype and test, which it does quite well. Unfortunately one of the drawbacks
-of this complexity is that Mirage uses a system of factory and model files to
-generate your data for the server. The model files are used to declare
-relationships and the factory files used to create default values or fake data.
-
-Factory Guy doesn't need to have a model file because it is much simpler. It
-creates ember data models or JSON objects and returns them directly in tests
-without creating a server. Factory Guy therefore uses your app's model files
-along with its factory files and doesn't require any extra model files. Mirage
-creates its own set of models on the 'server' to return in API calls and be
-turned into ember data models by your app. The duplication and extra complexity
-may appear minor, but I have often spent serious time debugging Mirage when its
-ORM has not produced the data exactly how I expected.
+Mirage builds a server, with a database and its own ORM (Object-Relational Mapping). This is quite a complex and interesting set up. Mirage attempts to extract away this complexity and provide you with a simple API in order to prototype and test, which it does quite well. Unfortunately one of the drawbacks of this complexity is that Mirage uses a system of factory and model files to generate your data for the server. The model files are used to declare relationships and the factory files used to create default values or fake data.
+
+Factory Guy doesn't need to have a model file because it is much simpler. It creates ember data models or JSON objects and returns them directly in tests without creating a server. Factory Guy therefore uses your app's model files along with its factory files and doesn't require any extra model files. Mirage creates its own set of models on the 'server' to return in API calls and be turned into ember data models by your app. The duplication and extra complexity may appear minor, but I have often spent serious time debugging Mirage when its ORM has not produced the data exactly how I expected.
 
 ## Conclusion
 
@@ -425,5 +308,4 @@ I've been told it is always good to finish with a strong conclusion.
 
 ![Strong gif](/assets/images/posts/2018-12-20-factories-best-practices/strong.gif)
 
-I hope you enjoyed this post and will start using factories over fixtures and
-using named factories / traits more sparingly.
+I hope you enjoyed this post and will start using factories over fixtures and using named factories / traits more sparingly.
diff --git a/src/posts/2019-02-11-ember-js-film-berlin.md b/src/posts/2019-02-11-ember-js-film-berlin.md
index 2206306fb6..8e81f847a0 100644
--- a/src/posts/2019-02-11-ember-js-film-berlin.md
+++ b/src/posts/2019-02-11-ember-js-film-berlin.md
@@ -3,9 +3,7 @@ title: "Ember.js: The Documentary - Berlin Screening"
 authorHandle: mrmrcoleman
 tags: ember
 bio: "Communications and Community Outreach Specialist"
-description:
-  'Mark Coleman announces the screening of "Ember.js: The Documentary" in
-  Berlin, Feb. 11th 2019.'
+description: 'Mark Coleman announces the screening of "Ember.js: The Documentary" in Berlin, Feb. 11th 2019.'
 tagline: |
   <p>Following on from last week's premiere in Amsterdam the new <a href="https://www.honeypot.io/">HoneyPot</a> film <strong>'Ember: A Mini Documentary'</strong> will be shown in Berlin this evening (2019-02-11).</p> <p>The film is a deep dive into the world of Ember.js and includes an interview with our CEO Marco Otte-Witte. After the screening Jessica Jordan from Mainmatter will present '<strong>Everything They Didn't Tell You About the Ember Community'</strong> which will be followed by a Q&amp;A.</p>
 ---
@@ -17,15 +15,11 @@ Here's the agenda from the meetup page:
 - 18.30 - 19.00: Doors open + drinks & snacks!
 - 19.00 - 19.15: Intro from documentary makers Honeypot
 - 19.15 - 19.45: Screening of Ember.js: The Documentary
-- 19.45 - 20.15: Jessica Jordan: Everything They Didn't Tell You About the Ember
-  Community (+Q&A)
+- 19.45 - 20.15: Jessica Jordan: Everything They Didn't Tell You About the Ember Community (+Q&A)
 - 20.15 - 22.00: Networking, mingling, drinking and partying.
 
-Grab a spot while you still can:
-[https://www.meetup.com/Honeypot_Berlin/events/258352778/](https://www.meetup.com/Honeypot_Berlin/events/258352778/)
+Grab a spot while you still can: [https://www.meetup.com/Honeypot_Berlin/events/258352778/](https://www.meetup.com/Honeypot_Berlin/events/258352778/)
 
-Check the trailer here:
-[https://www.youtube.com/watch?v=V0AC3Z1WIcc](https://www.youtube.com/watch?v=V0AC3Z1WIcc)
+Check the trailer here: [https://www.youtube.com/watch?v=V0AC3Z1WIcc](https://www.youtube.com/watch?v=V0AC3Z1WIcc)
 
-We'd like to thank HoneyPot for making this film and we hope the evening is a
-great success!
+We'd like to thank HoneyPot for making this film and we hope the evening is a great success!
diff --git a/src/posts/2019-03-13-elixir-umbrella-mox.md b/src/posts/2019-03-13-elixir-umbrella-mox.md
index 6235c9a018..b377885191 100644
--- a/src/posts/2019-03-13-elixir-umbrella-mox.md
+++ b/src/posts/2019-03-13-elixir-umbrella-mox.md
@@ -3,51 +3,27 @@ title: Elixir Umbrella Applications and Testing with Mox
 authorHandle: niklas_long
 tags: elixir
 bio: "Backend Engineer, author of Breethe API"
-description:
-  "Niklas Long shows how Elixir Umbrella applications not only improve the
-  organization of a code base but also allow for an improved testing setup."
+description: "Niklas Long shows how Elixir Umbrella applications not only improve the organization of a code base but also allow for an improved testing setup."
 tagline: |
   <p>What's the big deal with Elixir umbrellas?</p> <p>An Elixir umbrella is a container for mix apps; a structure useful to separate the application's concerns as each app is contained within its own mix project.</p> <p>Why is this cool?</p> <p>Because it's like Lego and Lego is cool.</p> <p>Who's Mox you ask?</p> <p>Mox is cool too... Let's dive in!</p>
 ---
 
 ## Breethe
 
-Throughout this post, we will use [Breethe](https://breethe.app) as an example.
-Breethe is a Progressive Web App that gives users quick and easy access to air
-quality data for locations around the world. Pollution and global warming are
-getting worse. The first step to understanding and solving these problems is to
-raise awareness by providing everyone with easy access to accurate data.
+Throughout this post, we will use [Breethe](https://breethe.app) as an example. Breethe is a Progressive Web App that gives users quick and easy access to air quality data for locations around the world. Pollution and global warming are getting worse. The first step to understanding and solving these problems is to raise awareness by providing everyone with easy access to accurate data.
 
 ![Video of the Breethe PWA](/assets/images/posts/2018-07-24-from-spa-to-pwa/breethe-video.gif)
 
-The application is [open source](https://github.com/mainmatter/breethe-server)
-and we encourage everyone interested to look through the source for reference.
-The server for this application was implemented using an
-[Elixir](https://elixir-lang.org) umbrella application which will be the focus
-of this post. The client for Breethe was built with
-[Glimmer.js](http://glimmerjs.com), which we discussed in previous posts:
+The application is [open source](https://github.com/mainmatter/breethe-server) and we encourage everyone interested to look through the source for reference. The server for this application was implemented using an [Elixir](https://elixir-lang.org) umbrella application which will be the focus of this post. The client for Breethe was built with [Glimmer.js](http://glimmerjs.com), which we discussed in previous posts:
 
 - [From SPA to PWA](/blog/2018/07/24/from-spa-to-pwa)
 - [Building a PWA with Glimmer.js](/blog/2018/07/03/building-a-pwa-with-glimmer-js/)
 
 ## Umbrella applications and separating concerns
 
-When we first started building Breethe, we asked ourselves a simple question
-which would dictate the structure of the application and our motivation for
-using an umbrella app to organise our code. This question was: what if we want
-to change our air quality data provider? It turns out this wasn't just
-speculation as we are now in the process of doing just that and our decision to
-use an umbrella app will make the process tremendously easy.
-
-Using an umbrella allowed us to split our server into two very distinct
-applications, communicating together by way of rigorously defined APIs. The
-first application functions as the data handling entity of the project - named
-_breethe_ (see below). It communicates with the air quality data provider (a
-third-party API) to gather the data, then processes and caches it for future
-use. The second application in the umbrella is the web interface built with
-Phoenix - named _breethe_web_. It requests the data from the first application,
-serializes it to JSON and delivers the payload to the client in compliance with
-the [JSON:API specification](https://jsonapi.org/).
+When we first started building Breethe, we asked ourselves a simple question which would dictate the structure of the application and our motivation for using an umbrella app to organise our code. This question was: what if we want to change our air quality data provider? It turns out this wasn't just speculation as we are now in the process of doing just that and our decision to use an umbrella app will make the process tremendously easy.
+
+Using an umbrella allowed us to split our server into two very distinct applications, communicating together by way of rigorously defined APIs. The first application functions as the data handling entity of the project - named _breethe_ (see below). It communicates with the air quality data provider (a third-party API) to gather the data, then processes and caches it for future use. The second application in the umbrella is the web interface built with Phoenix - named _breethe_web_. It requests the data from the first application, serializes it to JSON and delivers the payload to the client in compliance with the [JSON:API specification](https://jsonapi.org/).
 
 Here's an overview of the umbrella structure used for Breethe:
 
@@ -69,18 +45,9 @@ apps
     └── test
 ```
 
-We have defined a clear boundary between the business logic and the webserver.
-This is cool because the umbrella becomes modular like Lego and who doesn't like
-Lego? Need to change the air quality data provider? No problem, simply change
-the data application, leaving the webserver untouched as long as the data app
-continues to implement the same interface. The same would work the other way
-round if we wanted to change the webserver.
+We have defined a clear boundary between the business logic and the webserver. This is cool because the umbrella becomes modular like Lego and who doesn't like Lego? Need to change the air quality data provider? No problem, simply change the data application, leaving the webserver untouched as long as the data app continues to implement the same interface. The same would work the other way round if we wanted to change the webserver.
 
-However, for this approach to work well, the APIs used to communicate between
-the different applications in the umbrella need to be carefully defined. We want
-to keep the interfaces as little as possible to keep complexity contained. As an
-example, here are the publicly available functions on the _breethe_ app in the
-umbrella:
+However, for this approach to work well, the APIs used to communicate between the different applications in the umbrella need to be carefully defined. We want to keep the interfaces as little as possible to keep complexity contained. As an example, here are the publicly available functions on the _breethe_ app in the umbrella:
 
 ```elixir
 # apps/breethe/lib/breethe.ex
@@ -93,33 +60,13 @@ def search_locations(lat, lon), do: # ...
 def search_measurements(location_id), do: # ...
 ```
 
-Equally, these are the only functions the Phoenix web app (or any other app in
-the umbrella) can call on the _breethe_ app. These principles are of course not
-only applicable at the top level of the application but also within its internal
-logical contexts. For example, within the _breethe_ app, we have isolated the
-functions explicitly making requests to third-party APIs and abstracted them
-away behind an interface. This, again, reduces complexity and facilitates
-testing as we can isolate the different components of the business logic. This
-philosophy lends itself very well to being tested using Mox.
+Equally, these are the only functions the Phoenix web app (or any other app in the umbrella) can call on the _breethe_ app. These principles are of course not only applicable at the top level of the application but also within its internal logical contexts. For example, within the _breethe_ app, we have isolated the functions explicitly making requests to third-party APIs and abstracted them away behind an interface. This, again, reduces complexity and facilitates testing as we can isolate the different components of the business logic. This philosophy lends itself very well to being tested using Mox.
 
 ## Testing domains independently using Mox
 
-[Mox](https://github.com/plataformatec/mox), as the name suggests, is a library
-that defines mocks bound to specific behaviours. A behaviour is a set of
-function signatures that must be implemented by a module. Consequently, Mox
-guarantees the mocks for a module be consistent with the original functions they
-replace during testing. This rigidity makes the tests more maintainable and
-requires that the behaviours for each module be meticulously defined; precisely
-the qualities desired when implementing the APIs within our umbrella.
-
-For example, let's consider mocking the public API for the _breethe_ application
-when testing _breethe_web_. As the bridge between the two is only composed of
-the four functions shown in the previous section, mocking the _breethe_
-application's public interface when testing the webserver only requires mocking
-those four functions. Naturally, this is only reasonable if we separately test
-the _breethe_ application in full, from interface to database. Crucially, it is
-the singularity of the interface which allows this degree of separation between
-the two applications in the umbrella both in testing and in production.
+[Mox](https://github.com/plataformatec/mox), as the name suggests, is a library that defines mocks bound to specific behaviours. A behaviour is a set of function signatures that must be implemented by a module. Consequently, Mox guarantees the mocks for a module be consistent with the original functions they replace during testing. This rigidity makes the tests more maintainable and requires that the behaviours for each module be meticulously defined; precisely the qualities desired when implementing the APIs within our umbrella.
+
+For example, let's consider mocking the public API for the _breethe_ application when testing _breethe_web_. As the bridge between the two is only composed of the four functions shown in the previous section, mocking the _breethe_ application's public interface when testing the webserver only requires mocking those four functions. Naturally, this is only reasonable if we separately test the _breethe_ application in full, from interface to database. Crucially, it is the singularity of the interface which allows this degree of separation between the two applications in the umbrella both in testing and in production.
 
 Let's take a look at the controller action for a location search by id:
 
@@ -143,9 +90,7 @@ The interesting part is in the call to the _breethe_ application:
 |> @source.get_location()
 ```
 
-The reason we're using the `@source` module attribute is to be able to switch
-between the mock and the real function defined on the _breethe_ application;
-this is defined in the config files:
+The reason we're using the `@source` module attribute is to be able to switch between the mock and the real function defined on the _breethe_ application; this is defined in the config files:
 
 ```elixir
 # config/config.exs
@@ -155,15 +100,9 @@ config :breethe_web, source: Breethe
 config :breethe_web, source: Breethe.Mock
 ```
 
-By default `@source` points to the `Breethe` module - the _breethe_
-application's public API used in production and development. During testing it
-switches to the `Breethe.Mock` module, which defines the mocks.
+By default `@source` points to the `Breethe` module - the _breethe_ application's public API used in production and development. During testing it switches to the `Breethe.Mock` module, which defines the mocks.
 
-The test for this controller action is meant to check two things. Firstly, that
-the router redirects the connection to the appropriate controller action.
-Secondly, that the controller action processes the call and queries the
-_breethe_ application correctly using the right function defined on the latter's
-API - in this case `get_location(location_id)`.
+The test for this controller action is meant to check two things. Firstly, that the router redirects the connection to the appropriate controller action. Secondly, that the controller action processes the call and queries the _breethe_ application correctly using the right function defined on the latter's API - in this case `get_location(location_id)`.
 
 ```elixir
 # apps/breethe_web/test/breethe_web/controllers/location_controller_test.exs
@@ -187,28 +126,20 @@ end
 
 I've broken it down into its four main parts:
 
-1. It sets up the test data with
-   [ExMachina](https://github.com/thoughtbot/ex_machina). <br/><br/>
+1. It sets up the test data with [ExMachina](https://github.com/thoughtbot/ex_machina). <br/><br/>
 
 ```elixir
 location = insert(:location, measurements: [])
 ```
 
-2. It defines a mock in the `Breethe.Mock` module for the
-   `get_location(location_id)` function defined in the _breethe_ application's
-   API and sets the return value to the location we created at 1. The mock is
-   passed as an argument to the `expect` clause which verifies the mock is
-   executed during the test (instead of the real function). <br/><br/>
+2. It defines a mock in the `Breethe.Mock` module for the `get_location(location_id)` function defined in the _breethe_ application's API and sets the return value to the location we created at 1. The mock is passed as an argument to the `expect` clause which verifies the mock is executed during the test (instead of the real function). <br/><br/>
 
 ```elixir
 Breethe.Mock
 |> expect(:get_location, fn _location_id -> location end)
 ```
 
-As long as we’ve established the callback in the behaviour implemented by the
-Breethe module, we don’t need to explicitly define the Breethe.Mock module (Mox
-creates it). Here's the callback for this particular function (for reference, it
-isn't coded in the test).
+As long as we’ve established the callback in the behaviour implemented by the Breethe module, we don’t need to explicitly define the Breethe.Mock module (Mox creates it). Here's the callback for this particular function (for reference, it isn't coded in the test).
 
 ```elixir
 # apps/breethe/lib/breethe.ex
@@ -217,16 +148,13 @@ defmodule Behaviour do
 end
 ```
 
-3. It builds a connection and makes a call to the webserver's route designed to
-   handle a location search by id. <br/><br/>
+3. It builds a connection and makes a call to the webserver's route designed to handle a location search by id. <br/><br/>
 
 ```elixir
 conn = get(build_conn(), "api/locations/#{location.id}", [])
 ```
 
-4. It tests the JSON response (abridged for brevity) is correct by asserting on
-   the attributes of the location created in 1. and returned from the mock in 2.
-   <br/><br/>
+4. It tests the JSON response (abridged for brevity) is correct by asserting on the attributes of the location created in 1. and returned from the mock in 2. <br/><br/>
 
 ```elixir
 assert json_response(conn, 200) == %{
@@ -236,26 +164,14 @@ assert json_response(conn, 200) == %{
         }
 ```
 
-Using mocks greatly simplifies the testing process. Each test can be smaller and
-more specific. Each test is faster as we are not making calls to the database or
-external systems; we are only running the anonymous functions that define the
-mocks. For instance, the mock in our example above only executes:
+Using mocks greatly simplifies the testing process. Each test can be smaller and more specific. Each test is faster as we are not making calls to the database or external systems; we are only running the anonymous functions that define the mocks. For instance, the mock in our example above only executes:
 
 ```elixir
 fn _location_id -> location end
 ```
 
-Finally, each mock is self-contained in the test defining it and the callback
-insures the mock matches the original function signature. The result is robust,
-fast and modularised tests.
+Finally, each mock is self-contained in the test defining it and the callback insures the mock matches the original function signature. The result is robust, fast and modularised tests.
 
 ## Conclusion
 
-Elixir umbrella apps shine when structuring projects containing clear boundaries
-between their constituent parts. The philosophy they implement deeply resembles
-that of functional programming (and Lego), where small building blocks combine
-into a larger whole. It is however important to be precise when defining the
-internal APIs of the application as they act as the glue holding everything
-together. Lastly, Mox is a wonderful tool for testing. Not only does it make
-mocking APIs very simple and elegant, it also encourages best practices such as
-defining behaviours to keep the code consistent and robust.
+Elixir umbrella apps shine when structuring projects containing clear boundaries between their constituent parts. The philosophy they implement deeply resembles that of functional programming (and Lego), where small building blocks combine into a larger whole. It is however important to be precise when defining the internal APIs of the application as they act as the glue holding everything together. Lastly, Mox is a wonderful tool for testing. Not only does it make mocking APIs very simple and elegant, it also encourages best practices such as defining behaviours to keep the code consistent and robust.
diff --git a/src/posts/2019-03-29-qonto-project.md b/src/posts/2019-03-29-qonto-project.md
index 82240f802c..14085c989a 100644
--- a/src/posts/2019-03-29-qonto-project.md
+++ b/src/posts/2019-03-29-qonto-project.md
@@ -3,49 +3,23 @@ title: Qonto project
 authorHandle: mrmrcoleman
 tags: mainmatter
 bio: "Communications and Community Outreach Specialist"
-description:
-  'Mark Coleman announces our new client Qonto, a Paris based VC funded Fintech
-  startup who are "the ideal banking alternative for freelancers, startups and
-  SMEs."'
+description: 'Mark Coleman announces our new client Qonto, a Paris based VC funded Fintech startup who are "the ideal banking alternative for freelancers, startups and SMEs."'
 tagline: |
   <p>We're very pleased to announce that we've started working with <a href="https://qonto.eu/">Qonto</a>, a Paris based VC funded Fintech startup who are &quot;the ideal banking alternative for freelancers, startups and SMEs.&quot;</p>
 ---
 
 ![Qonto Logo](/assets/images/posts/2019-03-29-qonto-project/qonto-logo.png)
 
-Qonto reached out to Mainmatter looking for a combination of added engineering
-power and outside expertise to help their in-house engineers improve, we call
-this [Team reinforcement](/services/team-reinforcement/).
-
-This method of working sees our technology experts merge with our client's
-in-house engineering teams to share their know-how. Mainmatter engineers
-spearhead and guide new development initiatives while establishing best
-practices and transferring knowledge to in-house engineers on the job via
-reviews and pairing sessions.
-
-Just as with previous Team reinforcement projects like
-[trainline](/cases/trainline/) this approach brings "double value for the
-client" says simlpabs CEO Marco Otte-Witte, "short term value is added by the
-client immediately gaining more engineering power, but additional long term
-value is added through improved architecture, code quality, processes and
-leveled up in-house engineers."
-
-Mainmatter engineers Tobias Bieniek and Ricardo Mendes who are both Ember.js
-core members are working on the Qonto project. They started by analyzing Qonto's
-code and found the templates were using the rather antiquated Emblem.js which
-nobody was really happy with but was difficult to migrate away from. To tackle
-this Tobias created and open sourced
-[emblem-migrator](https://github.com/mainmatter/emblem-migrator/) which Qonto
-and all other Emblem.js users can now use.
-
-Next Mainmatter engineers identified that Qonto's test suite speed was impeding
-progress. They showed Qonto's engineers how to analyse the underlying causes and
-then half the testing time.
-
-Both migrating away from Emblem.js and halving the test suite running time
-happened in the first week!
-
-Mainmatter CEO Marco Otte-Witte says "I'm really pleased that Mainmatter have
-been able to add so much value in such a short amount of time proving that our
-Team reinforcement method works. We're all looking forward to continuing the
-project and helping Qonto to succeed in their highly competitive market."
+Qonto reached out to Mainmatter looking for a combination of added engineering power and outside expertise to help their in-house engineers improve, we call this [Team reinforcement](/services/team-reinforcement/).
+
+This method of working sees our technology experts merge with our client's in-house engineering teams to share their know-how. Mainmatter engineers spearhead and guide new development initiatives while establishing best practices and transferring knowledge to in-house engineers on the job via reviews and pairing sessions.
+
+Just as with previous Team reinforcement projects like [trainline](/cases/trainline/) this approach brings "double value for the client" says simlpabs CEO Marco Otte-Witte, "short term value is added by the client immediately gaining more engineering power, but additional long term value is added through improved architecture, code quality, processes and leveled up in-house engineers."
+
+Mainmatter engineers Tobias Bieniek and Ricardo Mendes who are both Ember.js core members are working on the Qonto project. They started by analyzing Qonto's code and found the templates were using the rather antiquated Emblem.js which nobody was really happy with but was difficult to migrate away from. To tackle this Tobias created and open sourced [emblem-migrator](https://github.com/mainmatter/emblem-migrator/) which Qonto and all other Emblem.js users can now use.
+
+Next Mainmatter engineers identified that Qonto's test suite speed was impeding progress. They showed Qonto's engineers how to analyse the underlying causes and then half the testing time.
+
+Both migrating away from Emblem.js and halving the test suite running time happened in the first week!
+
+Mainmatter CEO Marco Otte-Witte says "I'm really pleased that Mainmatter have been able to add so much value in such a short amount of time proving that our Team reinforcement method works. We're all looking forward to continuing the project and helping Qonto to succeed in their highly competitive market."
diff --git a/src/posts/2019-04-05-spas-pwas-and-ssr.md b/src/posts/2019-04-05-spas-pwas-and-ssr.md
index d9750b541a..2ae757dc6a 100644
--- a/src/posts/2019-04-05-spas-pwas-and-ssr.md
+++ b/src/posts/2019-04-05-spas-pwas-and-ssr.md
@@ -3,9 +3,7 @@ title: "SPAs, PWAs and SSR"
 authorHandle: marcoow
 tags: javascript
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte dives deep into different approaches for building web apps
-  like SPAs, PWAs, SSR and how they all can be combined for the best result."
+description: "Marco Otte-Witte dives deep into different approaches for building web apps like SPAs, PWAs, SSR and how they all can be combined for the best result."
 og:
   image: /assets/images/posts/2019-04-05-spas-pwas-and-ssr/og-image.jpg
 tagline: |
@@ -14,218 +12,87 @@ tagline: |
 
 ## Desktop-grade apps
 
-Modern websites are in many cases not really websites anymore, but in fact full
-blown apps with desktop-grade feature sets and user experiences that happen to
-run in a browser as opposed to standalone apps. While the much-loved
-[Spacejam Website](https://www.spacejam.com/archive/spacejam/movie/jam.htm) was
-a pretty standard page in terms of interactivity and design only about 2 decades
-ago
+Modern websites are in many cases not really websites anymore, but in fact full blown apps with desktop-grade feature sets and user experiences that happen to run in a browser as opposed to standalone apps. While the much-loved [Spacejam Website](https://www.spacejam.com/archive/spacejam/movie/jam.htm) was a pretty standard page in terms of interactivity and design only about 2 decades ago
 
 ![Screenshot of the Spacejam Website](/assets/images/posts/2019-03-16-spas-pwas-and-ssr/spacejam.png#@600-1200)
 
-we can now go to [Google Maps](https://www.google.com/maps), zoom and rotate the
-earth in 3D space, measure distances between arbitrary points and have a look at
-our neighbor's backyard:
+we can now go to [Google Maps](https://www.google.com/maps), zoom and rotate the earth in 3D space, measure distances between arbitrary points and have a look at our neighbor's backyard:
 
 ![Video of Google Maps](/assets/images/posts/2019-03-16-spas-pwas-and-ssr/maps.gif)
 
-All of this functionality, interactivity and visual appeal comes at a cost
-though, mainly in the the form of JavaScript code. The median size of JavaScript
-used on pages across the Internet is now
-[ca. 400KB on the desktop and ca. 360KB on mobile devices](https://httparchive.org/reports/state-of-javascript),
-an increase of ca. 36% and ca. 50% respectively over the past 3 years. All of
-this JavaScript not only has to be loaded via often spotty connections but also
-parsed, compiled and executed - often on mobile devices that are far less
-powerful than the average desktop or notebook computer (have a look at
-[Addy Osmani's in-depth post on the matter](https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4)
-for more details).
-
-What all this leads to is that for many of these highly-interactive,
-feature-rich and shiny apps that are being built today, the first impression
-that users get is often this:
+All of this functionality, interactivity and visual appeal comes at a cost though, mainly in the the form of JavaScript code. The median size of JavaScript used on pages across the Internet is now [ca. 400KB on the desktop and ca. 360KB on mobile devices](https://httparchive.org/reports/state-of-javascript), an increase of ca. 36% and ca. 50% respectively over the past 3 years. All of this JavaScript not only has to be loaded via often spotty connections but also parsed, compiled and executed - often on mobile devices that are far less powerful than the average desktop or notebook computer (have a look at [Addy Osmani's in-depth post on the matter](https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4) for more details).
+
+What all this leads to is that for many of these highly-interactive, feature-rich and shiny apps that are being built today, the first impression that users get is often this:
 
 ![Video of a loading JS app](/assets/images/posts/2019-03-16-spas-pwas-and-ssr/loading.gif)
 
 ## SPAs
 
-While JavaScript-heavy apps can be slow to start initially, the big benefit of
-the Single Page App approach is that once the application has started up in the
-browser, it is running continuously and handles route changes in the browser so
-that no subsequent page loads are necessary &mdash; SPAs trade a slow initial
-load for fast or often immediate subsequent route changes.
+While JavaScript-heavy apps can be slow to start initially, the big benefit of the Single Page App approach is that once the application has started up in the browser, it is running continuously and handles route changes in the browser so that no subsequent page loads are necessary &mdash; SPAs trade a slow initial load for fast or often immediate subsequent route changes.
 
-The initial response though that delivers the user's first impression will often
-be either empty or just a basic loading state as shown above. Only after the
-application's JavaScript has been loaded, parsed, compiled and executed, can the
-application start up and render anything meaningful on the screen. This results
-in relatively slow _time to first meaningful paint_ (TTFMP) and _time to
-interactive_ (TTI) metrics.
+The initial response though that delivers the user's first impression will often be either empty or just a basic loading state as shown above. Only after the application's JavaScript has been loaded, parsed, compiled and executed, can the application start up and render anything meaningful on the screen. This results in relatively slow _time to first meaningful paint_ (TTFMP) and _time to interactive_ (TTI) metrics.
 
 #### TTFMP: Time to first meaningful paint
 
-This is the time when the browser can first paint any **meaningful** content on
-the screen. While the time to first paint metric simply measures the first time
-**anything** is painted (which would be when the loading spinner is painted in
-the above example), for an SPA the time to first **meaningful** paint only
-occurs once the app has started and the actual UI is painted on the screen.
+This is the time when the browser can first paint any **meaningful** content on the screen. While the time to first paint metric simply measures the first time **anything** is painted (which would be when the loading spinner is painted in the above example), for an SPA the time to first **meaningful** paint only occurs once the app has started and the actual UI is painted on the screen.
 
 #### TTI: Time to interactive
 
-This is the time when the app is first usable and able to react to user inputs.
-In the above example of the SPA, time to interactive and time to first
-meaningful paint happen at the same time which is when the app has fully started
-up, has painted the UI on screen and is waiting for user input.
+This is the time when the app is first usable and able to react to user inputs. In the above example of the SPA, time to interactive and time to first meaningful paint happen at the same time which is when the app has fully started up, has painted the UI on screen and is waiting for user input.
 
 ## The App Shell Model
 
-One popular approach for improving the startup experience of JavaScript-heavy
-applications is called the
-[App Shell Model](https://developers.google.com/web/fundamentals/architecture/app-shell).
-The idea behind this concept is that instead of responding to the user's first
-request with an empty HTML document with only some script tags and maybe a
-loading spinner, the server would respond with the minimal set of code that is
-necessary for rendering the app's minimal UI and making it interactive. In most
-cases, that would be the visual framework of the app's main blocks and some
-barebones functionality associated to that (e.g. a working slideout menu without
-the individual menu items actually being functional).
-
-Although this does not improve the app's _TTFMP_ or _TTI_, at least it gives the
-user a first visual impression of what the app will look like once it has
-started up. Of course the app shell can be cached in the browser using a service
-worker so that for subsequent visits it can be served from that instantly.
+One popular approach for improving the startup experience of JavaScript-heavy applications is called the [App Shell Model](https://developers.google.com/web/fundamentals/architecture/app-shell). The idea behind this concept is that instead of responding to the user's first request with an empty HTML document with only some script tags and maybe a loading spinner, the server would respond with the minimal set of code that is necessary for rendering the app's minimal UI and making it interactive. In most cases, that would be the visual framework of the app's main blocks and some barebones functionality associated to that (e.g. a working slideout menu without the individual menu items actually being functional).
+
+Although this does not improve the app's _TTFMP_ or _TTI_, at least it gives the user a first visual impression of what the app will look like once it has started up. Of course the app shell can be cached in the browser using a service worker so that for subsequent visits it can be served from that instantly.
 
 ## Back to SSR
 
-The only really effective solution though for solving the problem of the
-meaningless initial UI - be it an empty page, a loading indicator or an app
-shell - is to leverage server-side rendering and respond with the full UI or
-something that's close to it for the initial request.
-
-Of course it wouldn't be advisable to go back to classic server-side rendered
-websites completely, dropping all of the benefits that Single Page Apps come
-with (instance page transitions once the app has started, rich user interfaces
-that would be almost impossible to build with server side rendering, etc.) A
-better approach is to run the same single page app that is shipped to the
-browser on the server side as well as follows:
-
-- the server responds to `GET` requests for all routes the single page app
-  supports
-- once a request comes in, the server constructs an application state from the
-  request path and potentially additional data like a session cookie and injects
-  that into the app
-- it then executes the app and renders the app's UI into a string, leveraging
-  libraries like [SimpleDOM](https://github.com/ember-fastboot/simple-dom) or
-  [jsdom](https://github.com/jsdom/jsdom)
+The only really effective solution though for solving the problem of the meaningless initial UI - be it an empty page, a loading indicator or an app shell - is to leverage server-side rendering and respond with the full UI or something that's close to it for the initial request.
+
+Of course it wouldn't be advisable to go back to classic server-side rendered websites completely, dropping all of the benefits that Single Page Apps come with (instance page transitions once the app has started, rich user interfaces that would be almost impossible to build with server side rendering, etc.) A better approach is to run the same single page app that is shipped to the browser on the server side as well as follows:
+
+- the server responds to `GET` requests for all routes the single page app supports
+- once a request comes in, the server constructs an application state from the request path and potentially additional data like a session cookie and injects that into the app
+- it then executes the app and renders the app's UI into a string, leveraging libraries like [SimpleDOM](https://github.com/ember-fastboot/simple-dom) or [jsdom](https://github.com/jsdom/jsdom)
 - that string is then served as the response to the browser's initial request
-- the pre-rendered response still contains all `<script>` tags so that the
-  browser would load and execute these scripts and start up the app in the
-  browser as usual
+- the pre-rendered response still contains all `<script>` tags so that the browser would load and execute these scripts and start up the app in the browser as usual
 
 ![Diagram of the approach](/assets/images/posts/2019-03-16-spas-pwas-and-ssr/diagram.png#@600-1200)
 
-With this setup, the _TTFMP_ metric is dramatically improved. Although users
-still have to wait for the app's JavaScript to load and the app to start before
-they are able to use it, instead of only being shown a meaningless UI while they
-wait for that to happen, they see the app's full UI immediately as that is
-served in the response to the initial request. The initial UI can even be partly
-interactive - elements like links or even functional elements like hover menus
-that can be implemented in CSS only will already be usable before the app has
-started up.
+With this setup, the _TTFMP_ metric is dramatically improved. Although users still have to wait for the app's JavaScript to load and the app to start before they are able to use it, instead of only being shown a meaningless UI while they wait for that to happen, they see the app's full UI immediately as that is served in the response to the initial request. The initial UI can even be partly interactive - elements like links or even functional elements like hover menus that can be implemented in CSS only will already be usable before the app has started up.
 
 ## SPA + SSR + PWA
 
-Combining SPAs with classic SSR, we get the best of both worlds - a fast _TTFMP_
-plus the benefits of an SPA like immediate page transitions, vivid UX etc. On
-top of that, patterns of PWAs can be added, for example caching the initial
-pre-rendered response in a service worker so that it can be shown immediately on
-subsequent visits or showing the app shell from the service worker cache and
-then injecting the SSR response into that which is likely available before the
-app has started up.
-
-SPAs, SSR and PWAs are not orthogonal concepts that are exclusive of each other
-but are actually complementary. SSR can be leveraged for a fast _TTFMP_ and some
-very basic functionality like links etc. Once the JavaScript referenced in the
-SSR response has been loaded, the SPA starts up in the browser, takes over the
-DOM and intercepts all subsequent route changes and handles them immediately in
-the browser. And finally concepts of PWAs like effective client-side caching and
-offline functionality via service workers can be added on top for maximal
-performance and the optimum user experience.
+Combining SPAs with classic SSR, we get the best of both worlds - a fast _TTFMP_ plus the benefits of an SPA like immediate page transitions, vivid UX etc. On top of that, patterns of PWAs can be added, for example caching the initial pre-rendered response in a service worker so that it can be shown immediately on subsequent visits or showing the app shell from the service worker cache and then injecting the SSR response into that which is likely available before the app has started up.
+
+SPAs, SSR and PWAs are not orthogonal concepts that are exclusive of each other but are actually complementary. SSR can be leveraged for a fast _TTFMP_ and some very basic functionality like links etc. Once the JavaScript referenced in the SSR response has been loaded, the SPA starts up in the browser, takes over the DOM and intercepts all subsequent route changes and handles them immediately in the browser. And finally concepts of PWAs like effective client-side caching and offline functionality via service workers can be added on top for maximal performance and the optimum user experience.
 
 ## Deployment
 
-When leveraging SSR for SPAs, it is important to get some aspects of the
-deployment right. Pre-rendering the application for the first request is only an
-improvement over the classic way of serving an SPA and should not be a
-requirement to use the app. Neither should it slow down delivery of the app. To
-make sure these requirements are met, it is important to make sure of two
-things:
-
-- The pre-rendering must run within a timeout so that if for some reason it
-  takes longer than x ms or whatever a reasonable threshold for a particular app
-  might be, the server cancels the pre-renderer and instead serves the SPA the
-  classic way (which is responding with the static, empty HTML file).
-- Likewise, errors in the pre-renderer should not be forwarded to the users and
-  thus block them from booting the app in the browser. Whenever the pre-renderer
-  encounters an error, it should fall back to serving the app the classic SPA
-  way just like if it runs into the timeout.
+When leveraging SSR for SPAs, it is important to get some aspects of the deployment right. Pre-rendering the application for the first request is only an improvement over the classic way of serving an SPA and should not be a requirement to use the app. Neither should it slow down delivery of the app. To make sure these requirements are met, it is important to make sure of two things:
+
+- The pre-rendering must run within a timeout so that if for some reason it takes longer than x ms or whatever a reasonable threshold for a particular app might be, the server cancels the pre-renderer and instead serves the SPA the classic way (which is responding with the static, empty HTML file).
+- Likewise, errors in the pre-renderer should not be forwarded to the users and thus block them from booting the app in the browser. Whenever the pre-renderer encounters an error, it should fall back to serving the app the classic SPA way just like if it runs into the timeout.
 
 ## Breethe
 
-We implemented the patterns described in this post in
-[Breethe](https://breethe.app), a PWA for accessing air quality data for
-locations around the world that we built as a tech showcase. Breethe is
-completely open source and
-[available on github](https://github.com/mainmatter/breethe-client) and we
-encourage everyone interested in the topic to check it out for reference.
+We implemented the patterns described in this post in [Breethe](https://breethe.app), a PWA for accessing air quality data for locations around the world that we built as a tech showcase. Breethe is completely open source and [available on github](https://github.com/mainmatter/breethe-client) and we encourage everyone interested in the topic to check it out for reference.
 
 ![Video of Breethe](/assets/images/posts/2019-03-16-spas-pwas-and-ssr/breethe.gif)
 
 ## Drawbacks
 
-Server-side-rendering an SPA comes with a drawback which is added latency. When
-serving an SPA as a static HTML file that contains only a loading state or an
-app shell, the HTML file can be served from a CDN which reduces latency. When
-serving the response for the initial request from a Node server, there will
-always be some additional latency. The Node server will likely not be running on
-an edge note in a CDN, thus connecting to it will take the user slightly longer
-than connecting to an edge node. Also, the server takes some time to run the
-app, capture what it renders and respond with that, adding further latency.
-Thus, the browser will know slightly later which scripts to load and thus start
-loading them slightly later which leads to a longer _TTI_.
-
-However, with average _TTI_ measurements in the range of several seconds for
-many sites in particular when requested from mobile devices, an added latency of
-a few hundred milliseconds might be well worth it in many cases. Without SSR,
-_TTFMP_ is generally equal to _TTI_ for SPAs and PWAs - with SSR, _TTFMP_ occurs
-as soon as the initial response is received while _TTI_ is only slightly
-delayed. So while the user needs to wait slightly longer for the app to be fully
-started up, the app's UI (and content) is available pretty much immediately.
-Whether that is a valuable improvement is a case-by-case decision of course. In
-the example of Breethe, when looking at the result page for a particular
-location, it's a pretty obvious decision:
+Server-side-rendering an SPA comes with a drawback which is added latency. When serving an SPA as a static HTML file that contains only a loading state or an app shell, the HTML file can be served from a CDN which reduces latency. When serving the response for the initial request from a Node server, there will always be some additional latency. The Node server will likely not be running on an edge note in a CDN, thus connecting to it will take the user slightly longer than connecting to an edge node. Also, the server takes some time to run the app, capture what it renders and respond with that, adding further latency. Thus, the browser will know slightly later which scripts to load and thus start loading them slightly later which leads to a longer _TTI_.
+
+However, with average _TTI_ measurements in the range of several seconds for many sites in particular when requested from mobile devices, an added latency of a few hundred milliseconds might be well worth it in many cases. Without SSR, _TTFMP_ is generally equal to _TTI_ for SPAs and PWAs - with SSR, _TTFMP_ occurs as soon as the initial response is received while _TTI_ is only slightly delayed. So while the user needs to wait slightly longer for the app to be fully started up, the app's UI (and content) is available pretty much immediately. Whether that is a valuable improvement is a case-by-case decision of course. In the example of Breethe, when looking at the result page for a particular location, it's a pretty obvious decision:
 
 ![Breethe - results for Muncich](/assets/images/posts/2019-03-16-spas-pwas-and-ssr/breethe-results.png)
 
-While the user might need to wait for a few seconds (e.g. on a low performance
-mobile device with a spotty network connection) for the app to have fully
-started up and be interactive, the air quality data that they are interested in
-is available immediately.
+While the user might need to wait for a few seconds (e.g. on a low performance mobile device with a spotty network connection) for the app to have fully started up and be interactive, the air quality data that they are interested in is available immediately.
 
 ## Progressive Enhancement
 
-The possibilities of combining SPAs with SSR and PWA mechanics do not end with
-the above described patterns though but we can go a step further. As it turns
-out, leveraging SSR for an SPA enables to also leverage **Progressive
-Enhancement** patterns so that the initial response can be functional beyond
-just links and interactive elements built in CSS. Many things we're all doing in
-JavaScript in SPAs these days have equivalents in pure HTML. These might not be
-as powerful and elaborate as what can be done with modern JavaScript but they
-can serve as a fallback for when the app's JavaScript is slow to load or fails
-to load completely. That way we're coming back full circle to a concept from 1
-or 2 decades ago where JavaScript enhances the HTML document rather than
-generating it - and all that while we're using an SPA that is completely written
-in JavaScript but that we're also running in the server side so that users don't
-necessarily have to wait until the app runs in their browsers.
-
-I will elaborate on how exactly the approach works in the next post of this
-series so stay tuned!
+The possibilities of combining SPAs with SSR and PWA mechanics do not end with the above described patterns though but we can go a step further. As it turns out, leveraging SSR for an SPA enables to also leverage **Progressive Enhancement** patterns so that the initial response can be functional beyond just links and interactive elements built in CSS. Many things we're all doing in JavaScript in SPAs these days have equivalents in pure HTML. These might not be as powerful and elaborate as what can be done with modern JavaScript but they can serve as a fallback for when the app's JavaScript is slow to load or fails to load completely. That way we're coming back full circle to a concept from 1 or 2 decades ago where JavaScript enhances the HTML document rather than generating it - and all that while we're using an SPA that is completely written in JavaScript but that we're also running in the server side so that users don't necessarily have to wait until the app runs in their browsers.
+
+I will elaborate on how exactly the approach works in the next post of this series so stay tuned!
diff --git a/src/posts/2019-04-24-dependency-updates-for-gitlab.md b/src/posts/2019-04-24-dependency-updates-for-gitlab.md
index f7e47e65d3..84723f5b50 100644
--- a/src/posts/2019-04-24-dependency-updates-for-gitlab.md
+++ b/src/posts/2019-04-24-dependency-updates-for-gitlab.md
@@ -3,63 +3,34 @@ title: "Automated dependency updates for your internal GitLab server️"
 authorHandle: tobiasbieniek
 tags: misc
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek shares how to set up the Renovate bot for automatic dependency
-  updates with self-hosted internal GitLab servers."
+description: "Tobias Bieniek shares how to set up the Renovate bot for automatic dependency updates with self-hosted internal GitLab servers."
 og:
   image: /assets/images/posts/2019-04-24-dependency-updates-for-gitlab/og-image.jpg
 tagline: |
   <p>Are your dependencies hopelessly outdated? Would you need to hire another developer just to keep up with the maintenance work of keeping them up-to-date? If those questions match your project then this blog post is for you. Keep reading and we will show you how to solve a lot of these issues with some easy to use tools.</p>
 ---
 
-In our previous blog post on [Open Source Maintenance][open-source-maintenance]
-we revealed that we are big fans of dependency update services like
-[Greenkeeper][greenkeeper] or [dependabot][dependabot].
+In our previous blog post on [Open Source Maintenance][open-source-maintenance] we revealed that we are big fans of dependency update services like [Greenkeeper][greenkeeper] or [dependabot][dependabot].
 
-These services help you reduce the burden of maintaining a project by creating
-pull requests for you whenever there is a dependency that can be updated. That
-could be because of new features in those dependencies or more importantly
-because of bugs or security issues. dependabot will even label the PR with
-`security` in those cases!
+These services help you reduce the burden of maintaining a project by creating pull requests for you whenever there is a dependency that can be updated. That could be because of new features in those dependencies or more importantly because of bugs or security issues. dependabot will even label the PR with `security` in those cases!
 
 ## Renovate
 
-Another similar service is called [Renovate][renovate]. The main difference:
-Renovate is an open source project that you can run yourself, if you want to.
-The hosted service works fine if your project is on [GitHub][gh] or
-[GitLab][gl], but if you're using a self-hosted internal GitLab server you will
-have to run the service yourself. Fear not, this sounds a lot more complicated
-than it actually is, and the rest of this blog post will show you how to do it.
-
-Before we start, let's make sure we are all in the same boat. The most common
-setup we have found when working with our clients is running GitLab on a
-self-hosted server within the corporate firewall and VPN. Most of the time that
-includes using [GitLab CI][gl-ci] to run the test suite for new commits or merge
-requests. This blog post is assuming the above setup and having GitLab CI set up
-to use the "[Docker executor][docker-executor]".
-
-To give you a rough idea of how we will set this up: Renovate will use a
-dedicated user account on your GitLab instance to open merge requests. It will
-also have a dedicated repository for the main configuration and GitLab CI on
-that repository will take care of regularly running the Renovate bot.
+Another similar service is called [Renovate][renovate]. The main difference: Renovate is an open source project that you can run yourself, if you want to. The hosted service works fine if your project is on [GitHub][gh] or [GitLab][gl], but if you're using a self-hosted internal GitLab server you will have to run the service yourself. Fear not, this sounds a lot more complicated than it actually is, and the rest of this blog post will show you how to do it.
+
+Before we start, let's make sure we are all in the same boat. The most common setup we have found when working with our clients is running GitLab on a self-hosted server within the corporate firewall and VPN. Most of the time that includes using [GitLab CI][gl-ci] to run the test suite for new commits or merge requests. This blog post is assuming the above setup and having GitLab CI set up to use the "[Docker executor][docker-executor]".
+
+To give you a rough idea of how we will set this up: Renovate will use a dedicated user account on your GitLab instance to open merge requests. It will also have a dedicated repository for the main configuration and GitLab CI on that repository will take care of regularly running the Renovate bot.
 
 Now, let's get started setting this up!
 
 ## GitLab User Account
 
-Depending on how your GitLab instance is set up you can either sign up a new
-account for our renovate bot yourself, or you may have to ask your admins to
-create a new account for you.
+Depending on how your GitLab instance is set up you can either sign up a new account for our renovate bot yourself, or you may have to ask your admins to create a new account for you.
 
-Once that account exists, we will have to create a "Personal Access Token" for
-the account, so that our Renovate bot can use it without us having to give it
-the password directly. This is important, because when you give away the
-password the account can be hijacked, but when you only give away a token you
-have control over the actions that can be performed with that token.
+Once that account exists, we will have to create a "Personal Access Token" for the account, so that our Renovate bot can use it without us having to give it the password directly. This is important, because when you give away the password the account can be hijacked, but when you only give away a token you have control over the actions that can be performed with that token.
 
-To create such a token, follow the instructions in the
-[GitLab docs](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html).
-In short:
+To create such a token, follow the instructions in the [GitLab docs](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html). In short:
 
 - Go to the "Settings > Access Tokens" page
 - Enter "Renovate" as the "Name"
@@ -67,25 +38,15 @@ In short:
 - Click the "Create personal access token" button
 - Save the generated token somewhere until we need it later
 
-Finally, make sure that our new GitLab account has access to the projects that
-you want it to run on. It will need to have at least "Developer" permissions so
-that the bot is able to create branches and push updates to those branches.
+Finally, make sure that our new GitLab account has access to the projects that you want it to run on. It will need to have at least "Developer" permissions so that the bot is able to create branches and push updates to those branches.
 
 ## Renovate Repository
 
-As mentioned before, we will put the main configuration file into a dedicated
-repository. You can create the repository either under your personal account,
-the new Renovate account or, ideally, in the same GitLab group where you keep
-all your other projects.
+As mentioned before, we will put the main configuration file into a dedicated repository. You can create the repository either under your personal account, the new Renovate account or, ideally, in the same GitLab group where you keep all your other projects.
 
-Let's start off with a blank repository and then we will add the necessary files
-as we go. Once the repository is created, `git clone` it to your local machine
-so that we can create some content.
+Let's start off with a blank repository and then we will add the necessary files as we go. Once the repository is created, `git clone` it to your local machine so that we can create some content.
 
-Renovate is a JavaScript-based project, but it supports updating dependencies of
-a lot of other languages too. Because it is based on JavaScript we will use
-`npm` (or `yarn` if you prefer) to install it and for that the first file we
-will create is the `package.json` file:
+Renovate is a JavaScript-based project, but it supports updating dependencies of a lot of other languages too. Because it is based on JavaScript we will use `npm` (or `yarn` if you prefer) to install it and for that the first file we will create is the `package.json` file:
 
 <!-- prettier-ignore -->
 ```js
@@ -107,25 +68,15 @@ will create is the `package.json` file:
 {% endraw %}
 ```
 
-Afterwards, run `npm install` in the repository to install the `renovate`
-package into the `node_modules` folder. This step should also create a
-`package-lock.json` file which we will commit to the repository together with
-the new `package.json` file.
+Afterwards, run `npm install` in the repository to install the `renovate` package into the `node_modules` folder. This step should also create a `package-lock.json` file which we will commit to the repository together with the new `package.json` file.
 
-You may have noticed that `git status` shows you a lot of new files in the
-`node_modules` folder, so the next quick step we will do is create a
-`.gitignore` file, with just `node_modules` in it, to ignore that folder from
-now on.
+You may have noticed that `git status` shows you a lot of new files in the `node_modules` folder, so the next quick step we will do is create a `.gitignore` file, with just `node_modules` in it, to ignore that folder from now on.
 
 Great, we're almost there!
 
 ## Renovate Configuration
 
-The last step before we can try things out is adding that main configuration
-file, that we've been talking about before. Renovate expects this to be called
-`config.js`, so let's create a file with that name. Inside of it we will
-configure how Renovate will behave by default. Note that most of this can be
-overridden on a per-repository basis.
+The last step before we can try things out is adding that main configuration file, that we've been talking about before. Renovate expects this to be called `config.js`, so let's create a file with that name. Inside of it we will configure how Renovate will behave by default. Note that most of this can be overridden on a per-repository basis.
 
 <!-- prettier-ignore -->
 ```js
@@ -155,15 +106,9 @@ module.exports = {
 {% endraw %}
 ```
 
-The first section of the file above tells our Renovate bot how to talk to our
-self-hosted GitLab instance. Afterwards we tell it on which repositories it
-should run, we configure how much log output we want to see and what the
-`renovate.json` config file should look like that it will add to each repository
-in the first merge request.
+The first section of the file above tells our Renovate bot how to talk to our self-hosted GitLab instance. Afterwards we tell it on which repositories it should run, we configure how much log output we want to see and what the `renovate.json` config file should look like that it will add to each repository in the first merge request.
 
-You may have noticed that we did not put the `token` in the config file
-directly, instead we use an environment variable so that someone with read
-access to the repository can't easily steal it.
+You may have noticed that we did not put the `token` in the config file directly, instead we use an environment variable so that someone with read access to the repository can't easily steal it.
 
 Now let's run it! Open up a terminal, navigate to the repository and run:
 
@@ -171,39 +116,23 @@ Now let's run it! Open up a terminal, navigate to the repository and run:
 npm run renovate -- --dry-run
 ```
 
-Don't worry, the `--dry-run` means it won't actually do anything yet but it will
-show you what it would do. Most likely you will be greeted by an error like
-this:
+Don't worry, the `--dry-run` means it won't actually do anything yet but it will show you what it would do. Most likely you will be greeted by an error like this:
 
 > Fatal error: No authentication found
 
-Which makes sense, because we haven't set up the `RENOVATE_TOKEN` environment
-variable yet. Instead of doing that, let's quickly paste our generated token
-into the `config.js` file: e.g. `token: 'WCufshK3rDP1yemwkWQc'`, save and try
-again.
+Which makes sense, because we haven't set up the `RENOVATE_TOKEN` environment variable yet. Instead of doing that, let's quickly paste our generated token into the `config.js` file: e.g. `token: 'WCufshK3rDP1yemwkWQc'`, save and try again.
 
-You should now see our little bot do its work, analyze the current state of your
-projects and figure out what it needs to do next.
+You should now see our little bot do its work, analyze the current state of your projects and figure out what it needs to do next.
 
-Before we commit this configuration file to the project make sure to change the
-`token` line back to use the `RENOVATE_TOKEN` and then commit the file and push
-it to the repository.
+Before we commit this configuration file to the project make sure to change the `token` line back to use the `RENOVATE_TOKEN` and then commit the file and push it to the repository.
 
 ## Using GitLab CI
 
-We now have a way to run our Renovate bot manually, but that is not what we
-want. We want to automate all the things! ... and GitLab CI is a great way to do
-just that.
+We now have a way to run our Renovate bot manually, but that is not what we want. We want to automate all the things! ... and GitLab CI is a great way to do just that.
 
-The first thing we need to do is teach GitLab CI about our `RENOVATE_TOKEN`
-environment variable. We can do so on the "Settings > CI / CD" page of our
-project in GitLab. In the "Variables" section enter `RENOVATE_TOKEN` as the
-"variable key" and your generated token (e.g. `WCufshK3rDP1yemwkWQc`) as the
-"variable value". Finally, make sure that the "Protected" switch is turned on
-and then press the "Save variables" button.
+The first thing we need to do is teach GitLab CI about our `RENOVATE_TOKEN` environment variable. We can do so on the "Settings > CI / CD" page of our project in GitLab. In the "Variables" section enter `RENOVATE_TOKEN` as the "variable key" and your generated token (e.g. `WCufshK3rDP1yemwkWQc`) as the "variable value". Finally, make sure that the "Protected" switch is turned on and then press the "Save variables" button.
 
-Now we will set up the GitLab CI job that will run our bot. For that we need to
-create another file in the repository called `.gitlab-ci.yml`:
+Now we will set up the GitLab CI job that will run our bot. For that we need to create another file in the repository called `.gitlab-ci.yml`:
 
 ```yaml
 image: node:10
@@ -221,30 +150,20 @@ run:
     - npm run renovate
 ```
 
-Commit that file to the repository, push the changes and ... nothing happens.
-Why? Because our new `run` job will only run when triggered by something called
-"schedules". Let's configure a schedule then!
+Commit that file to the repository, push the changes and ... nothing happens. Why? Because our new `run` job will only run when triggered by something called "schedules". Let's configure a schedule then!
 
-In the "CI / CD" menu of the project on GitLab you should find a menu entry
-called "Schedules". Clicking on that will take you to a page with a "New
-schedule" button, which we will immediately click too. The "Schedule a new
-pipeline" form should now show up in your browser and we will fill it like this:
+In the "CI / CD" menu of the project on GitLab you should find a menu entry called "Schedules". Clicking on that will take you to a page with a "New schedule" button, which we will immediately click too. The "Schedule a new pipeline" form should now show up in your browser and we will fill it like this:
 
 - Description: "Hourly run"
 - Interval Pattern: Custom (`0 * * * *`)
 - Target Branch: `master`
 - Active: Yes, please!
 
-Now, click the "Save pipeline schedule" button and GitLab will take you back to
-the "Schedules" page showing our newly created schedule.
+Now, click the "Save pipeline schedule" button and GitLab will take you back to the "Schedules" page showing our newly created schedule.
 
-Aaaand that's it! Some time in the next hour GitLab CI should trigger the `run`
-job, that will run our Renovate bot, and that will create merge requests on your
-configured repositories.
+Aaaand that's it! Some time in the next hour GitLab CI should trigger the `run` job, that will run our Renovate bot, and that will create merge requests on your configured repositories.
 
-If you need more help getting this set up or if you want to talk about any of
-the topics here in more detail please do [contact us](/contact/)! If you enjoyed
-this blog post you can also let us know via [Twitter].
+If you need more help getting this set up or if you want to talk about any of the topics here in more detail please do [contact us](/contact/)! If you enjoyed this blog post you can also let us know via [Twitter].
 
 [open-source-maintenance]: /blog/2018/11/27/open-source-maintenance/
 [greenkeeper]: https://greenkeeper.io/
diff --git a/src/posts/2019-07-15-sentry-and-ember.md b/src/posts/2019-07-15-sentry-and-ember.md
index 5802c8dc64..7005de7e48 100644
--- a/src/posts/2019-07-15-sentry-and-ember.md
+++ b/src/posts/2019-07-15-sentry-and-ember.md
@@ -3,9 +3,7 @@ title: "Sentry error reporting for Ember.js"
 authorHandle: tobiasbieniek
 tags: ember
 bio: "Senior Frontend Engineer, Ember CLI core team member"
-description:
-  "Tobias Bieniek explains how to set up Sentry for Ember.js applications using
-  @sentry/browser instead of the now unnecessary ember-cli-sentry."
+description: "Tobias Bieniek explains how to set up Sentry for Ember.js applications using @sentry/browser instead of the now unnecessary ember-cli-sentry."
 og:
   image: /assets/images/posts/2019-07-15-sentry-and-ember/og-image.jpg
 tagline: |
@@ -14,19 +12,11 @@ tagline: |
 
 ## ember-cli-sentry
 
-The [`ember-cli-sentry`][ember-cli-sentry] addon has been around since 2015 and
-nicely integrates the [`raven-js`][raven-js] library with Ember.js. What is
-`raven-js`? It is the official browser JavaScript client for Sentry.
+The [`ember-cli-sentry`][ember-cli-sentry] addon has been around since 2015 and nicely integrates the [`raven-js`][raven-js] library with Ember.js. What is `raven-js`? It is the official browser JavaScript client for Sentry.
 
-Well... it **was** the official browser JavaScript client for Sentry. In 2018 it
-has been replaced by [`@sentry/browser`][sentry-browser] with an entirely new
-API.
+Well... it **was** the official browser JavaScript client for Sentry. In 2018 it has been replaced by [`@sentry/browser`][sentry-browser] with an entirely new API.
 
-What does that mean for `ember-cli-sentry`? We don't know! We have been
-experimenting with `@sentry/browser` though and we are starting to think that a
-dedicated Ember.js addon for Sentry might not be needed anymore. In the rest of
-this post we will show you how we integrated `@sentry/browser` into one of our
-apps and how to migrate from `ember-cli-sentry` to `@sentry/browser`.
+What does that mean for `ember-cli-sentry`? We don't know! We have been experimenting with `@sentry/browser` though and we are starting to think that a dedicated Ember.js addon for Sentry might not be needed anymore. In the rest of this post we will show you how we integrated `@sentry/browser` into one of our apps and how to migrate from `ember-cli-sentry` to `@sentry/browser`.
 
 ## Sourcemaps
 
@@ -41,14 +31,9 @@ TypeError: Cannot read property 'name' of undefined
   at n.search(/assets/vendor-394212fdd48a8a8e9508401b5be54d75.js:9793:162)
 ```
 
-Sourcemaps allow you to map from compiled and minified code to the original code
-you wrote in your editor. That makes it a lot easier to decipher stack traces
-like the one above because it will show you the actual file and function names.
+Sourcemaps allow you to map from compiled and minified code to the original code you wrote in your editor. That makes it a lot easier to decipher stack traces like the one above because it will show you the actual file and function names.
 
-By default in Ember.js, sourcemaps are disabled for production builds. In this
-case we would like to have them though, so that Sentry has access to them and
-can decipher the cryptic stack traces for us. We can enable sourcemap generation
-for all environments in the `ember-cli-build.js` file:
+By default in Ember.js, sourcemaps are disabled for production builds. In this case we would like to have them though, so that Sentry has access to them and can decipher the cryptic stack traces for us. We can enable sourcemap generation for all environments in the `ember-cli-build.js` file:
 
 <!-- prettier-ignore -->
 ```js
@@ -61,26 +46,15 @@ let app = new EmberApp(defaults, {
 {% endraw %}
 ```
 
-If you now run `ember build --prod` it should generate `.map` files next to the
-JavaScript files in the `dist/assets/` folder. Make sure to upload those files
-to your server too, so that Sentry can access them.
+If you now run `ember build --prod` it should generate `.map` files next to the JavaScript files in the `dist/assets/` folder. Make sure to upload those files to your server too, so that Sentry can access them.
 
-In case you don't want other people to be able to read your original source code
-you can also upload the sourcemaps directly to Sentry. If you use
-[`ember-cli-deploy`][ember-cli-deploy] to publish your apps then you can use the
-[`ember-cli-deploy-sentry`][ember-cli-deploy-sentry] addon to do this
-automatically for each deployment.
+In case you don't want other people to be able to read your original source code you can also upload the sourcemaps directly to Sentry. If you use [`ember-cli-deploy`][ember-cli-deploy] to publish your apps then you can use the [`ember-cli-deploy-sentry`][ember-cli-deploy-sentry] addon to do this automatically for each deployment.
 
 ## Setting up `@sentry/browser`
 
-`ember-cli-sentry` uses an instance-initializer to automatically configure and
-initialize the `raven-js` library. Those initializers are great for certain
-cases, but it could happen that a bug in a different initializer is triggered
-before the Sentry client was setup to listen for errors. For this reason we will
-not use an initializer to setup `@sentry/browser`.
+`ember-cli-sentry` uses an instance-initializer to automatically configure and initialize the `raven-js` library. Those initializers are great for certain cases, but it could happen that a bug in a different initializer is triggered before the Sentry client was setup to listen for errors. For this reason we will not use an initializer to setup `@sentry/browser`.
 
-Instead, we will adjust our `app/app.js` file to initialize `@sentry/browser`
-right before we start the app:
+Instead, we will adjust our `app/app.js` file to initialize `@sentry/browser` right before we start the app:
 
 <!-- prettier-ignore -->
 ```js
@@ -95,8 +69,7 @@ const App = Application.extend({
 {% endraw %}
 ```
 
-From the above snippet you can see that we chose to put the Sentry-specific
-logic into a separate file: `app/sentry.js`. That file looks roughly like this:
+From the above snippet you can see that we chose to put the Sentry-specific logic into a separate file: `app/sentry.js`. That file looks roughly like this:
 
 <!-- prettier-ignore -->
 ```js
@@ -115,10 +88,7 @@ export function startSentry() {
 {% endraw %}
 ```
 
-First we import the `@sentry/browser` library into the file using a
-[wildcard import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#Import_an_entire_module's_contents)
-and we import their official Ember.js plugin from the `@sentry/integrations`
-package:
+First we import the `@sentry/browser` library into the file using a [wildcard import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#Import_an_entire_module's_contents) and we import their official Ember.js plugin from the `@sentry/integrations` package:
 
 <!-- prettier-ignore -->
 ```js
@@ -128,31 +98,23 @@ import { Ember } from '@sentry/integrations/esm/ember';
 {% endraw %}
 ```
 
-We are using `@sentry/integrations/esm/ember` here instead of just
-`@sentry/integrations` because we want to make sure that we only bundle the
-Ember.js plugin, but not e.g. the Vue plugin too.
+We are using `@sentry/integrations/esm/ember` here instead of just `@sentry/integrations` because we want to make sure that we only bundle the Ember.js plugin, but not e.g. the Vue plugin too.
 
-At this point you might be wondering: but, we never installed those libraries?!
-And you are totally right! At this point we need to install the libraries using
-your favorite JavaScript package manager. In this case we'll use `yarn`:
+At this point you might be wondering: but, we never installed those libraries?! And you are totally right! At this point we need to install the libraries using your favorite JavaScript package manager. In this case we'll use `yarn`:
 
 <!-- prettier-ignore -->
 ```bash
 yarn add @sentry/browser @sentry/integrations
 ```
 
-To make those available in the app we'll also need `ember-auto-import`, which
-makes importing from `node_modules` much easier:
+To make those available in the app we'll also need `ember-auto-import`, which makes importing from `node_modules` much easier:
 
 <!-- prettier-ignore -->
 ```bash
 yarn add --dev ember-auto-import
 ```
 
-Now we have everything we need installed and can go on with the snippet above.
-You can see that the `Sentry.init()` call uses the `sentry` object from your
-application configuration, so let's add that to the `config/environment.js`
-file:
+Now we have everything we need installed and can go on with the snippet above. You can see that the `Sentry.init()` call uses the `sentry` object from your application configuration, so let's add that to the `config/environment.js` file:
 
 <!-- prettier-ignore -->
 ```js
@@ -173,16 +135,11 @@ module.exports = function(environment) {
 {% endraw %}
 ```
 
-... and we're done! `@sentry/browser` is now sufficiently set up and will report
-any errors on the page to the server configured in the `dsn` property above.
+... and we're done! `@sentry/browser` is now sufficiently set up and will report any errors on the page to the server configured in the `dsn` property above.
 
 ## Filtering Errors
 
-Some errors we just don't care about. One example of that is the
-`TransitionAborted` error that the Ember.js router reports when a route
-transition was cancelled. We can ignore such errors by implementing the
-[`beforeSend()`](https://docs.sentry.io/error-reporting/configuration/filtering/?platform=browsernpm#before-send)
-hook of `@sentry/browser`:
+Some errors we just don't care about. One example of that is the `TransitionAborted` error that the Ember.js router reports when a route transition was cancelled. We can ignore such errors by implementing the [`beforeSend()`](https://docs.sentry.io/error-reporting/configuration/filtering/?platform=browsernpm#before-send) hook of `@sentry/browser`:
 
 <!-- prettier-ignore -->
 ```js
@@ -206,8 +163,7 @@ Sentry.init({
 
 ## Manually Reporting Errors
 
-With `ember-cli-sentry` you could use the `raven` service to manually report
-messages or exceptions to Sentry. With `@sentry/browser` you can do the same:
+With `ember-cli-sentry` you could use the `raven` service to manually report messages or exceptions to Sentry. With `@sentry/browser` you can do the same:
 
 <!-- prettier-ignore -->
 ```js
@@ -222,15 +178,9 @@ Sentry.captureException(new Error('with stack trace!! ✨'));
 
 ## Adding Additional Context
 
-Sentry, by default, records the IP of the user that has experienced the error.
-But when your app has user accounts and an authentication system, it is much
-more useful to know which specific user this has happened to. `@sentry/browser`
-allows us to add additional context to the events it sends to the server.
+Sentry, by default, records the IP of the user that has experienced the error. But when your app has user accounts and an authentication system, it is much more useful to know which specific user this has happened to. `@sentry/browser` allows us to add additional context to the events it sends to the server.
 
-We could do that manually in the `beforeSend()` hook, but it is much easier to
-use the
-[`configureScope()`](https://docs.sentry.io/enriching-error-data/scopes/?platform=browsernpm#configuring-the-scope)
-function for this:
+We could do that manually in the `beforeSend()` hook, but it is much easier to use the [`configureScope()`](https://docs.sentry.io/enriching-error-data/scopes/?platform=browsernpm#configuring-the-scope) function for this:
 
 <!-- prettier-ignore -->
 ```js
@@ -244,11 +194,7 @@ Sentry.configureScope(scope => {
 {% endraw %}
 ```
 
-This will automatically add the user information for all errors/events that
-follow after this call. If you only want to add such information for a single
-event you can use the
-[`withScope()`](https://docs.sentry.io/enriching-error-data/scopes/?platform=browsernpm#local-scopes)
-function instead.
+This will automatically add the user information for all errors/events that follow after this call. If you only want to add such information for a single event you can use the [`withScope()`](https://docs.sentry.io/enriching-error-data/scopes/?platform=browsernpm#local-scopes) function instead.
 
 ## Testing
 
@@ -265,23 +211,15 @@ this.owner.register('service:raven', Service.extend({
 {% endraw %}
 ```
 
-But with `@sentry/browser` this becomes a little more complicated since there is
-no service anymore that could be mocked like that. We have experimented with
-this and found that pushing an additional scope on the stack and configuring a
-mock client for that scope seems to result in a useful way to assert whether an
-exception was correctly reported.
+But with `@sentry/browser` this becomes a little more complicated since there is no service anymore that could be mocked like that. We have experimented with this and found that pushing an additional scope on the stack and configuring a mock client for that scope seems to result in a useful way to assert whether an exception was correctly reported.
 
-The details of this require its own blog post though, since they are a little
-less straight-forward than what we described above.
+The details of this require its own blog post though, since they are a little less straight-forward than what we described above.
 
-If you have questions, want to know more or need help setting all of this up for
-your apps please [contact us][contact]. We're happy to help!
+If you have questions, want to know more or need help setting all of this up for your apps please [contact us][contact]. We're happy to help!
 
 [ember-cli-sentry]: https://github.com/ember-cli-sentry/ember-cli-sentry
-[raven-js]:
-  https://github.com/getsentry/sentry-javascript/tree/master/packages/raven-js
-[sentry-browser]:
-  https://github.com/getsentry/sentry-javascript/tree/master/packages/browser
+[raven-js]: https://github.com/getsentry/sentry-javascript/tree/master/packages/raven-js
+[sentry-browser]: https://github.com/getsentry/sentry-javascript/tree/master/packages/browser
 [ember-cli-deploy]: https://github.com/ember-cli-deploy/ember-cli-deploy
 [ember-cli-deploy-sentry]: https://github.com/dschmidt/ember-cli-deploy-sentry
 [ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
diff --git a/src/posts/2019-11-11-why-companies-invest-in-oss.md b/src/posts/2019-11-11-why-companies-invest-in-oss.md
index 528ba936cc..ce8cad238f 100644
--- a/src/posts/2019-11-11-why-companies-invest-in-oss.md
+++ b/src/posts/2019-11-11-why-companies-invest-in-oss.md
@@ -3,10 +3,7 @@ title: "Why Companies Invest In Open-Source and Why Yours Should, Too"
 authorHandle: jjordan_dev
 tags: opensource
 bio: "Senior Frontend Engineer, Ember Learning Core team member"
-description:
-  "Jessica Jordan details how Mainmatter makes contributions to open-source
-  software work as a regular practice and how companies can benefit from an
-  investment into OSS."
+description: "Jessica Jordan details how Mainmatter makes contributions to open-source software work as a regular practice and how companies can benefit from an investment into OSS."
 og:
   image: /assets/images/posts/2019-11-11-why-companies-invest-in-oss/og-image.jpg
 tagline: |
@@ -15,206 +12,76 @@ tagline: |
 
 ## What Is Open-Source?
 
-Open-source describes a decentralised approach in which knowledge and material
-products are developed. Even though the open-source development model can be
-applied to many different types of products, I will only focus on the
-open-source development of **software** (OSS) in this post.
+Open-source describes a decentralised approach in which knowledge and material products are developed. Even though the open-source development model can be applied to many different types of products, I will only focus on the open-source development of **software** (OSS) in this post.
 
-The outcomes of open-source development are usually any or a combination of the
-following
-[[1](http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/OpenSource/p32-o_reilly.pdf)]:
+The outcomes of open-source development are usually any or a combination of the following [[1](http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/OpenSource/p32-o_reilly.pdf)]:
 
 - free software
 - publicly available source code of said software
 - related documentation which is publicly available and free
-- possibility to share and redistribute software and/or documentation in
-  modified or non-modified manner as defined by the License
-
-Open-source software has become an important corner stone of almost any business
-that operates today. According to a previous survey less than 3% of respondents
-mentioned that their business doesn't rely on OSS in any way and indicating that
-the vast majority of companies use OSS: either for product development or for
-running business infrastructure
-[[2](https://www.slideshare.net/blackducksoftware/2015-future-of-open-source-survey-results/9-SECTION2CORPORATEUSE2XSINCE_2010USE_OF_OPEN_SOURCE)].
-It was estimated that in 2016 alone, about 95% of commercial software products
-world wide were including OSS components
-[[3](https://core.ac.uk/reader/41824124)].
-
-The reasons for the popularity of OSS are manifold: OSS allows businesses to
-deliver more stable and more secure digital products in a shorter timespan.
-Additionally, overall cost for the development of these products is reduced,
-since part of the product development and maintenance is shared with a group of
-peers external to the business [[4](https://core.ac.uk/reader/41824081)].
-
-The mere usage of OSS is already established as a commonly accepted practice for
-businesses. The sole use of OSS is also known as **OSS acquisition**
-[[4](https://core.ac.uk/reader/41824081)].
-
-The popularity of OSS acquisition is explained by its significant returns. But
-how does the acceptance of OSS acquisition relate to **OSS integration** - a
-business's practice to contribute back to the open-source projects they're
-using? Are there any benefits of investing money and developer time into
-engaging with open-source communities and co-create OSS with said communities?
-And if so, do these benefits outweigh the costs of cutting back on time spent
-directly on product and business development?
+- possibility to share and redistribute software and/or documentation in modified or non-modified manner as defined by the License
+
+Open-source software has become an important corner stone of almost any business that operates today. According to a previous survey less than 3% of respondents mentioned that their business doesn't rely on OSS in any way and indicating that the vast majority of companies use OSS: either for product development or for running business infrastructure [[2](https://www.slideshare.net/blackducksoftware/2015-future-of-open-source-survey-results/9-SECTION2CORPORATEUSE2XSINCE_2010USE_OF_OPEN_SOURCE)]. It was estimated that in 2016 alone, about 95% of commercial software products world wide were including OSS components [[3](https://core.ac.uk/reader/41824124)].
+
+The reasons for the popularity of OSS are manifold: OSS allows businesses to deliver more stable and more secure digital products in a shorter timespan. Additionally, overall cost for the development of these products is reduced, since part of the product development and maintenance is shared with a group of peers external to the business [[4](https://core.ac.uk/reader/41824081)].
+
+The mere usage of OSS is already established as a commonly accepted practice for businesses. The sole use of OSS is also known as **OSS acquisition** [[4](https://core.ac.uk/reader/41824081)].
+
+The popularity of OSS acquisition is explained by its significant returns. But how does the acceptance of OSS acquisition relate to **OSS integration** - a business's practice to contribute back to the open-source projects they're using? Are there any benefits of investing money and developer time into engaging with open-source communities and co-create OSS with said communities? And if so, do these benefits outweigh the costs of cutting back on time spent directly on product and business development?
 
 ## Investment in OSS Is an Investment in Team Development
 
-Developers may spend time contributing to OSS by participating in a wide range
-of different tasks, including active development of open-source tools and
-software, writing documentation for OSS, managing projects, participating in
-community management and more.
-
-Many of these tasks provide multi-level learning opportunities for employees in
-regards of their **technical skills**. Apart from offering a wide selection of
-tasks that meet contributors' needs and interests which help to expand an
-employee's skill set
-[[5](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.462.2007&rep=rep1&type=pdf)],
-OSS also provides the chance for mentorship. Developers who contribute to
-open-source can therefore deepen already existing technical skills and acquire
-entirely new ones. By picking up work tasks that meet their current experience
-level freely without the constraints that are oftentimes imposed in their
-day-to-day work, developers find a unique opportunity to expand their technical
-qualifications.
-
-As active members of open-source communities, developers may hone their
-**organisational skill set** by managing open-source projects, collaborating
-with globally distributed teams both online and offline and leading initiatives
-in an environment with a usually simple, clear-cut organisational structure
-[[6](https://digital-library.theiet.org/content/conferences/10.1049/ic_20040267)].
-
-Finally, when following an intrinsic motivation to contribute to OSS,
-engineering teams can benefit from open-source work in regards to well-being.
-Apart from an investment into their own professional capital by widening their
-skill set, participation in open-source communities oftentimes has altruistic
-motives - the ambition to give back to the community from which developers
-already have benefitted. A sense of belonging to a particular open-source
-community and wanting to be an active part of it as well as the recognition by
-community peers are driving factors for OSS contributions to developers
-[[7](https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1559&context=jais)].
-
-The value that engineers themselves see in their contributions to open-source,
-has also been a central topic in a series of interviews of regular contributors
-to EmberJS - a JavaScript framework for building client-side single page
-applications. In the conversation with community members, some stated that the
-impact of their work on a wider ecosystem of framework users was perceived as
-motivating
-[[8](https://discuss.emberjs.com/t/i-contribute-to-ember-with-bekzod-khaitbaev/16085)].
-Others mentioned professional growth in terms of team organisation and
-leadership as a primary goal for their OSS work
-[[9](https://discuss.emberjs.com/t/i-contribute-to-ember-with-jen-weber/16110)].
-
-Being able to follow their intrinsic motivation, exercising autonomy and
-competence as part of contributing to OSS is key to increased work satisfaction
-for many developers
-[[7](https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1559&context=jais)].
+Developers may spend time contributing to OSS by participating in a wide range of different tasks, including active development of open-source tools and software, writing documentation for OSS, managing projects, participating in community management and more.
+
+Many of these tasks provide multi-level learning opportunities for employees in regards of their **technical skills**. Apart from offering a wide selection of tasks that meet contributors' needs and interests which help to expand an employee's skill set [[5](https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.462.2007&rep=rep1&type=pdf)], OSS also provides the chance for mentorship. Developers who contribute to open-source can therefore deepen already existing technical skills and acquire entirely new ones. By picking up work tasks that meet their current experience level freely without the constraints that are oftentimes imposed in their day-to-day work, developers find a unique opportunity to expand their technical qualifications.
+
+As active members of open-source communities, developers may hone their **organisational skill set** by managing open-source projects, collaborating with globally distributed teams both online and offline and leading initiatives in an environment with a usually simple, clear-cut organisational structure [[6](https://digital-library.theiet.org/content/conferences/10.1049/ic_20040267)].
+
+Finally, when following an intrinsic motivation to contribute to OSS, engineering teams can benefit from open-source work in regards to well-being. Apart from an investment into their own professional capital by widening their skill set, participation in open-source communities oftentimes has altruistic motives - the ambition to give back to the community from which developers already have benefitted. A sense of belonging to a particular open-source community and wanting to be an active part of it as well as the recognition by community peers are driving factors for OSS contributions to developers [[7](https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1559&context=jais)].
+
+The value that engineers themselves see in their contributions to open-source, has also been a central topic in a series of interviews of regular contributors to EmberJS - a JavaScript framework for building client-side single page applications. In the conversation with community members, some stated that the impact of their work on a wider ecosystem of framework users was perceived as motivating [[8](https://discuss.emberjs.com/t/i-contribute-to-ember-with-bekzod-khaitbaev/16085)]. Others mentioned professional growth in terms of team organisation and leadership as a primary goal for their OSS work [[9](https://discuss.emberjs.com/t/i-contribute-to-ember-with-jen-weber/16110)].
+
+Being able to follow their intrinsic motivation, exercising autonomy and competence as part of contributing to OSS is key to increased work satisfaction for many developers [[7](https://aisel.aisnet.org/cgi/viewcontent.cgi?article=1559&context=jais)].
 
 ## Investment in OSS Will Boost Your Talent Strategy
 
-A process for providing compensated work time for their engineers to work on
-OSS, benefits a company's talent strategy: Increased work satisfaction aids
-**talent retainment**. By being an active part of OSS communities, either by
-paying developers to contribute to open-source projects or sponsoring events or
-project initiatives, companies directly invest in their employer branding and
-expose their brand to large developer communities in a targeted manner. This
-helps immensely with identifying experienced talent whose skill set matches well
-with the requirements of a business's engineering projects
-[[10](https://opensource.org/node/1006)]. Developers who are interested in
-working at companies that encourage and facilitate learning and professional
-growth via OSS work are in turn motivated to join respective companies
-[[11](https://www.infoq.com/news/2019/03/open-source-benefits/)], indicating a
-compound effect of open-source focussed employer branding.
+A process for providing compensated work time for their engineers to work on OSS, benefits a company's talent strategy: Increased work satisfaction aids **talent retainment**. By being an active part of OSS communities, either by paying developers to contribute to open-source projects or sponsoring events or project initiatives, companies directly invest in their employer branding and expose their brand to large developer communities in a targeted manner. This helps immensely with identifying experienced talent whose skill set matches well with the requirements of a business's engineering projects [[10](https://opensource.org/node/1006)]. Developers who are interested in working at companies that encourage and facilitate learning and professional growth via OSS work are in turn motivated to join respective companies [[11](https://www.infoq.com/news/2019/03/open-source-benefits/)], indicating a compound effect of open-source focussed employer branding.
 
 ## How the Benefits of OSS Integration Outweigh the Costs
 
-Many companies hesitate to contribute in the context of OSS projects. Business
-owners need to compare the cost of several **downsides of OSS integration**
-against the potential benefits. Some of the disadvantages of OSS contribution
-include the risk of **loosing intellectual property** when open-sourcing
-internal software, the **cost for maintaining** one's own and external OSS
-projects and the risk to **reveal knowledge** about critical business processes
-to competitors.
-
-Previous case studies were able to confirm that the benefits of OSS integration
-often outweigh its cost and that returns are especially significant if the
-projects are of interest to other businesses.
-[[12](https://www.researchgate.net/profile/Joachim_Henkel/publication/251228522_Open_Source_Software_from_Commercial_Firms_-_Tools_Complements_and_Collective_Invention/links/54c3bb140cf219bbe4ec1cf5/Open-Source-Software-from-Commercial-Firms-Tools-Complements-and-Collective-Invention.pdf)].
-Businesses can employ profitable strategies by paying the **cost of OSS
-contribution** and benefitting from its returns on many levels.
+Many companies hesitate to contribute in the context of OSS projects. Business owners need to compare the cost of several **downsides of OSS integration** against the potential benefits. Some of the disadvantages of OSS contribution include the risk of **loosing intellectual property** when open-sourcing internal software, the **cost for maintaining** one's own and external OSS projects and the risk to **reveal knowledge** about critical business processes to competitors.
+
+Previous case studies were able to confirm that the benefits of OSS integration often outweigh its cost and that returns are especially significant if the projects are of interest to other businesses. [[12](https://www.researchgate.net/profile/Joachim_Henkel/publication/251228522_Open_Source_Software_from_Commercial_Firms_-_Tools_Complements_and_Collective_Invention/links/54c3bb140cf219bbe4ec1cf5/Open-Source-Software-from-Commercial-Firms-Tools-Complements-and-Collective-Invention.pdf)]. Businesses can employ profitable strategies by paying the **cost of OSS contribution** and benefitting from its returns on many levels.
 
 ## Investment in OSS in Practice
 
-Even if the benefits of OSS for training your team and improving your talent
-strategy seem promising, you may still wonder **how** you can implement a
-successful process for your business to contribute back to open-source. Adapting
-the process to short-term or long-term business needs is crucial to make the
-investment into OSS work alongside ongoing product development or infrastructure
-work.
-
-As a consulting company, Mainmatter also operates under time and project
-constraints. Still, open-source is at the heart of our company's work and
-besides contributing to EmberJS via our core team engagements, we maintain over
-a dozen of tools and libraries written in JavaScript and other programming
-languages and which are well-adopted in the open-source community
-[[13](/ember-consulting/)]. Being aware that providing value for OSS is
-important, but takes time, we dedicate regular time for engineers and designers
-to work on open-source projects using the **20% time method**.
+Even if the benefits of OSS for training your team and improving your talent strategy seem promising, you may still wonder **how** you can implement a successful process for your business to contribute back to open-source. Adapting the process to short-term or long-term business needs is crucial to make the investment into OSS work alongside ongoing product development or infrastructure work.
+
+As a consulting company, Mainmatter also operates under time and project constraints. Still, open-source is at the heart of our company's work and besides contributing to EmberJS via our core team engagements, we maintain over a dozen of tools and libraries written in JavaScript and other programming languages and which are well-adopted in the open-source community [[13](/ember-consulting/)]. Being aware that providing value for OSS is important, but takes time, we dedicate regular time for engineers and designers to work on open-source projects using the **20% time method**.
 
 ### How Does the 20% Time Method Work?
 
-The 20% time method allocates a fifth of an engineer's compensated working time
-for open-source projects and related activities, including development,
-community management or writing blog posts. At Mainmatter, we ensure that each
-IT and design professional has access to 20% time and makes use of it on a
-weekly basis: this boils down to 4 days of client work and 1 day of 20% time in
-a regular work week. Projects that our consultants work on generate tangible
-outcomes which are shared with the team or the wider open-source community
-regularly. Some of these tangible outcomes among many others at our company
-include:
+The 20% time method allocates a fifth of an engineer's compensated working time for open-source projects and related activities, including development, community management or writing blog posts. At Mainmatter, we ensure that each IT and design professional has access to 20% time and makes use of it on a weekly basis: this boils down to 4 days of client work and 1 day of 20% time in a regular work week. Projects that our consultants work on generate tangible outcomes which are shared with the team or the wider open-source community regularly. Some of these tangible outcomes among many others at our company include:
 
 - releases of company owned open-source projects, e.g. Ember addons
-- code contributions to open-source projects owned by other organizations, e.g.
-  the EmberJS library or The Ember Times community newsletter
-- blog posts about best practices in software, design, marketing and other
-  company expertises
-- organizing OSS community events, e.g. our Ember beginner's workshop for those
-  underrepresented in tech or conferences such as Emberfest
+- code contributions to open-source projects owned by other organizations, e.g. the EmberJS library or The Ember Times community newsletter
+- blog posts about best practices in software, design, marketing and other company expertises
+- organizing OSS community events, e.g. our Ember beginner's workshop for those underrepresented in tech or conferences such as Emberfest
 - presenting at international conferences such as EmberConf or ReactiveConf
 
-Using the 20% time method allows us as a company to provide time for **learning
-and training** to each team member **equally** and in good **balance** with the
-main tasks of our business. Allowing developers to choose the initiatives they
-want to work on freely is an important characteristic of our approach as well;
-this provides the greatest potential for professional growth that suits a team
-member's existing expertise and **inherent interests**. As a side effect, our
-hiring process benefits from these efforts both in terms of **talent
-acquisition** and **talent retention**. Finally, many of the outcomes of our
-team's 20% time contributes to awareness of the company's brand; which in turn
-is crucial for any B2B business's **client acquisition** process.
+Using the 20% time method allows us as a company to provide time for **learning and training** to each team member **equally** and in good **balance** with the main tasks of our business. Allowing developers to choose the initiatives they want to work on freely is an important characteristic of our approach as well; this provides the greatest potential for professional growth that suits a team member's existing expertise and **inherent interests**. As a side effect, our hiring process benefits from these efforts both in terms of **talent acquisition** and **talent retention**. Finally, many of the outcomes of our team's 20% time contributes to awareness of the company's brand; which in turn is crucial for any B2B business's **client acquisition** process.
 
 ## If Your Business Contributes to OSS, You Are in Good Company
 
-Many businesses already found a way to provide time for their engineering and
-product teams using either the 20% time method or differing approaches.
-According to the results of a recent survey about open-source adaptation in
-companies, 67% of respondents stated that they were contributing back to OSS
-[[14](https://www.slideshare.net/blackducksoftware/2016-future-of-open-source-survey-results)].
+Many businesses already found a way to provide time for their engineering and product teams using either the 20% time method or differing approaches. According to the results of a recent survey about open-source adaptation in companies, 67% of respondents stated that they were contributing back to OSS [[14](https://www.slideshare.net/blackducksoftware/2016-future-of-open-source-survey-results)].
 
-OSS development and engagement is hence already a well-adopted approach by
-businesses today and might even become increasingly popular in the future.
+OSS development and engagement is hence already a well-adopted approach by businesses today and might even become increasingly popular in the future.
 
 ## So Should You Pay Your Team to Work on OSS?
 
-In this post we took a look at the impact of dedicating time on contributing to
-open-source. If you want to benefit from the education and training
-opportunities that OSS offers or if you are in need to improve your business's
-talent strategy, it becomes clear that implementing a process that allows your
-engineers to work on OSS will set your business up for success.
+In this post we took a look at the impact of dedicating time on contributing to open-source. If you want to benefit from the education and training opportunities that OSS offers or if you are in need to improve your business's talent strategy, it becomes clear that implementing a process that allows your engineers to work on OSS will set your business up for success.
 
-If you have any questions on how to get started with contributing to open-source
-at your company, [send us a message](/contact/). You can also book
-[a workshop for your engineering team](/services/workshops/) to jump start the
-process of contributing.
+If you have any questions on how to get started with contributing to open-source at your company, [send us a message](/contact/). You can also book [a workshop for your engineering team](/services/workshops/) to jump start the process of contributing.
 
 ## Sources
 
@@ -233,6 +100,4 @@ process of contributing.
 - [13: "Europe's leading Ember experts". Mainmatter. 2019.](/ember-consulting/)
 - [14: "2016 - Future of Open Source Survey Results". Black Duck by Synopsys. 2016](https://www.slideshare.net/blackducksoftware/2016-future-of-open-source-survey-results)
 
-This post is based on the talk
-["That's what you get for letting your developers work on open-source"](https://speakerdeck.com/jessicajordanjs/thats-what-youre-gonna-get-for-letting-your-developers-work-on-open-source)
-at [HiveConf 2019](https://hive.honeypot.io/hiveconf-2019/).
+This post is based on the talk ["That's what you get for letting your developers work on open-source"](https://speakerdeck.com/jessicajordanjs/thats-what-youre-gonna-get-for-letting-your-developers-work-on-open-source) at [HiveConf 2019](https://hive.honeypot.io/hiveconf-2019/).
diff --git a/src/posts/2019-12-20-clarity-in-templates.md b/src/posts/2019-12-20-clarity-in-templates.md
index 08fc36cf7f..bac0f48741 100644
--- a/src/posts/2019-12-20-clarity-in-templates.md
+++ b/src/posts/2019-12-20-clarity-in-templates.md
@@ -3,9 +3,7 @@ title: "Bringing clarity to templates through Ember Octane"
 authorHandle: locks
 tags: ember
 bio: "Senior Frontend Engineer, Ember Framework and Learning Core teams member"
-description:
-  "Ricardo Mendes explains how Ember templates have evolved in the path to Ember
-  Octane to bring more clarity for developers."
+description: "Ricardo Mendes explains how Ember templates have evolved in the path to Ember Octane to bring more clarity for developers."
 og:
   image: /assets/images/posts/2019-12-20-clarity-in-templates/og-image.jpg
 tagline: |
@@ -14,34 +12,15 @@ tagline: |
 
 ## Ember Octane and editions
 
-As a framework that values stability and providing its users solid upgrade
-paths, Ember has accrued its fair share of idiosyncrasies. One of the more
-demonstrable consequences of this is the so called pit of incoherence, alluded
-to in the
-[opening keynote of EmberConf 2019](https://www.youtube.com/watch?v=zYwdBcmz6VI):
-APIs are introduced that move the framework to a new mental model, but that
-mental model isn't complete yet. This leaves users unsure of which APIs to use
-when, and how the interop might work.
-
-This is where editions come into play. The main goal of editions is to document
-and present a new and coherent mental model that developers can adhere to, while
-keeping compatibility with existing APIs. This is done in one of two ways,
-either a new API that can coexist with existing ones is introduced, or an
-optional feature that users can opt into is introduced. This allows for new
-applications to have the optional features and default blueprints of the newer
-editions, while existing applications can update their codebase at their own
-pace.
-
-In this blog post we will address some changes to templates that were introduced
-with Ember Octane in mind, the first planned edition for the Ember.js framework.
-You can read more about Octane in the
-[official edition page](https://emberjs.com/editions/octane).
+As a framework that values stability and providing its users solid upgrade paths, Ember has accrued its fair share of idiosyncrasies. One of the more demonstrable consequences of this is the so called pit of incoherence, alluded to in the [opening keynote of EmberConf 2019](https://www.youtube.com/watch?v=zYwdBcmz6VI): APIs are introduced that move the framework to a new mental model, but that mental model isn't complete yet. This leaves users unsure of which APIs to use when, and how the interop might work.
+
+This is where editions come into play. The main goal of editions is to document and present a new and coherent mental model that developers can adhere to, while keeping compatibility with existing APIs. This is done in one of two ways, either a new API that can coexist with existing ones is introduced, or an optional feature that users can opt into is introduced. This allows for new applications to have the optional features and default blueprints of the newer editions, while existing applications can update their codebase at their own pace.
+
+In this blog post we will address some changes to templates that were introduced with Ember Octane in mind, the first planned edition for the Ember.js framework. You can read more about Octane in the [official edition page](https://emberjs.com/editions/octane).
 
 ## Ambiguity
 
-{% raw %} In Ember templates, interpolation of dynamic values is done through
-curly braces, `{{}}`. Given this is the only syntax for dynamic values, there is
-an ambiguity problem at times. Let us look at a template: {% endraw %}
+{% raw %} In Ember templates, interpolation of dynamic values is done through curly braces, `{{}}`. Given this is the only syntax for dynamic values, there is an ambiguity problem at times. Let us look at a template: {% endraw %}
 
 ```hbs
 {% raw %}
@@ -61,19 +40,13 @@ an ambiguity problem at times. Let us look at a template: {% endraw %}
 {% endraw %}
 ```
 
-Looking only at the template, can we be certain where `title` comes from?
-Whether `post-body` and `comment` are helpers or components? We can generously
-assume that `comment` is a component as it is receiving an action, but when
-scanning the file it is indistinguishable from `if`, `each`, and other
-templating constructs.
+Looking only at the template, can we be certain where `title` comes from? Whether `post-body` and `comment` are helpers or components? We can generously assume that `comment` is a component as it is receiving an action, but when scanning the file it is indistinguishable from `if`, `each`, and other templating constructs.
 
 We will work step by step to remove ambiguity where we can.
 
 ### Disambiguating properties
 
-We will start by marking which dynamic values come from the component's
-JavaScript. These are called properties. To do that we are going to consult the
-JavaScript file to see which properties it might define:
+We will start by marking which dynamic values come from the component's JavaScript. These are called properties. To do that we are going to consult the JavaScript file to see which properties it might define:
 
 ```js
 {% raw %}
@@ -97,8 +70,7 @@ export default Component.extend({
 {% endraw %}
 ```
 
-We see that `title` is a computed property, and `commentsExpanded` is a boolean
-defined in the class definition, so we will update the template accordingly:
+We see that `title` is a computed property, and `commentsExpanded` is a boolean defined in the class definition, so we will update the template accordingly:
 
 ```hbs
 {% raw %}
@@ -118,23 +90,13 @@ defined in the class definition, so we will update the template accordingly:
 {% endraw %}
 ```
 
-The great thing about this feature is that all versions of Ember support it, so
-you can start annotating properties in your templates today. You can also
-enforce that no new implicit `this` are added to templates by configuring the
-appropriate
-[`ember-template-lint`](https://github.com/ember-template-lint/ember-template-lint)
-rule.
+The great thing about this feature is that all versions of Ember support it, so you can start annotating properties in your templates today. You can also enforce that no new implicit `this` are added to templates by configuring the appropriate [`ember-template-lint`](https://github.com/ember-template-lint/ember-template-lint) rule.
 
 ### Disambiguating named arguments
 
-Next we will turn our attention to named arguments. We give this name to values
-that we pass into components when we use them. Since components do not have
-access to the context where they are called in, this is the primary way to pass
-information into them.
+Next we will turn our attention to named arguments. We give this name to values that we pass into components when we use them. Since components do not have access to the context where they are called in, this is the primary way to pass information into them.
 
-To see what we are passing into our `blog/post` component, we need to see how it
-is used in our application. To do this, we will check a route template, namely
-the template for the `blog` route, where the component is used:
+To see what we are passing into our `blog/post` component, we need to see how it is used in our application. To do this, we will check a route template, namely the template for the `blog` route, where the component is used:
 
 ```hbs
 {% raw %}
@@ -143,9 +105,7 @@ the template for the `blog` route, where the component is used:
 {% endraw %}
 ```
 
-We can see that when calling the component, we are passing in `post` and
-`onReportComment`. The syntax to mark them as named argument is a `@` prefix, so
-let us update our template:
+We can see that when calling the component, we are passing in `post` and `onReportComment`. The syntax to mark them as named argument is a `@` prefix, so let us update our template:
 
 ```hbs
 {% raw %}
@@ -165,36 +125,19 @@ let us update our template:
 {% endraw %}
 ```
 
-We have improved our template a further step, now we can tell properties and
-named arguments apart. Next we will dive into component invocation.
+We have improved our template a further step, now we can tell properties and named arguments apart. Next we will dive into component invocation.
 
-If you wish to use named arguments in your application, you can use
-[`ember-named-arguments-polyfill`](https://github.com/rwjblue/ember-named-arguments-polyfill)
-for Ember.js versions older than 3.1.
+If you wish to use named arguments in your application, you can use [`ember-named-arguments-polyfill`](https://github.com/rwjblue/ember-named-arguments-polyfill) for Ember.js versions older than 3.1.
 
-Named arguments mostly apply to components, since they are the piece of Ember
-that is explicitly invoked by developers unlike route templates which the
-framework renders for you.
+Named arguments mostly apply to components, since they are the piece of Ember that is explicitly invoked by developers unlike route templates which the framework renders for you.
 
-Note that `@model` was introduced by
-[RFC #523 "Model Argument for Route Templates"](https://emberjs.github.io/rfcs/0523-model-argument-for-route-templates.html)
-so that you can refer directly to the model that was passed to a route template.
+Note that `@model` was introduced by [RFC #523 "Model Argument for Route Templates"](https://emberjs.github.io/rfcs/0523-model-argument-for-route-templates.html) so that you can refer directly to the model that was passed to a route template.
 
 ### Disambiguating components
 
-After the last change, it would be nice to have a way to disambiguate component
-invocations from other kinds of dynamic interpolations. Fortunately, a new
-syntax was introduced by
-[RFC #311 "Angle Bracket Invocation"](https://emberjs.github.io/rfcs/0311-angle-bracket-invocation.html),
-that allows us to do just that. Using angle bracket invocation also enables us
-to distinguish between named arguments passed to the component, and HTML
-attributes passed to the component. HTML attributes and `...attributes` will be
-covered in a future post.
+After the last change, it would be nice to have a way to disambiguate component invocations from other kinds of dynamic interpolations. Fortunately, a new syntax was introduced by [RFC #311 "Angle Bracket Invocation"](https://emberjs.github.io/rfcs/0311-angle-bracket-invocation.html), that allows us to do just that. Using angle bracket invocation also enables us to distinguish between named arguments passed to the component, and HTML attributes passed to the component. HTML attributes and `...attributes` will be covered in a future post.
 
-To update, we replace curly braces with an HTML-like `<>` syntax–hence angle
-bracket invocation,–using capital case for the name of the component, `::`
-instead of `/` for nested components, and prefixing named arguments with `@`.
-Here is how the above `blog` and `blog/post` templates look like once updated:
+To update, we replace curly braces with an HTML-like `<>` syntax–hence angle bracket invocation,–using capital case for the name of the component, `::` instead of `/` for nested components, and prefixing named arguments with `@`. Here is how the above `blog` and `blog/post` templates look like once updated:
 
 ```hbs
 {% raw %}
@@ -221,38 +164,20 @@ Here is how the above `blog` and `blog/post` templates look like once updated:
 {% endraw %}
 ```
 
-To use this feature in older versions of Ember and its dependencies, you can use
-[`ember-angle-bracket-invocation-polyfilll`](https://github.com/rwjblue/ember-angle-bracket-invocation-polyfill).
+To use this feature in older versions of Ember and its dependencies, you can use [`ember-angle-bracket-invocation-polyfilll`](https://github.com/rwjblue/ember-angle-bracket-invocation-polyfill).
 
-With just a couple of tweaks, we now have much more clarity when reading a
-template, and the need to consult additional files is lessened:
+With just a couple of tweaks, we now have much more clarity when reading a template, and the need to consult additional files is lessened:
 
-- `{{this.title}}` is a property that comes from the JavaScript file of the
-  component;
+- `{{this.title}}` is a property that comes from the JavaScript file of the component;
 - `<PostBody />` is a component invocation;
 - `{{@post}}` is a named argument that is passed to the component when invoked;
 - `{{this.commentsExpanded}}` is also a property;
 - `if` and `each` are templating constructs
-- `commentObject` is a block argument that is available inside the `each` block
-  scope
+- `commentObject` is a block argument that is available inside the `each` block scope
 - `<Comment />` is a component invocation
 
-These were not the only improvements made to Ember's templating engine, or even
-to components. Also introduced to the framework were the ability to pass HTML
-attributes to components and apply them with `...attributes`, a simplification
-of DOM event handling with the
-[`on`](https://emberjs.github.io/rfcs/0471-on-modifier.html) and
-[`fn`](https://emberjs.github.io/rfcs/0470-fn-helper.html) modifiers replacing
-`action`, the ability for users to create
-[custom element modifiers](https://github.com/ember-modifier/ember-modifier)
-like the built-in `action`, `on`, and `fn`,
-[rendering lifecycle element modifiers](https://github.com/emberjs/ember-render-modifiers),
-and
-[Glimmer components](https://emberjs.github.io/rfcs/0416-glimmer-components.html).
-
-These new features will be covered in upcoming posts, so be sure to keep an eye
-out for them!
-
-If you are looking for help to update your codebase to these new idioms, or you
-want to level up your engineering team, make sure to [contact us](/contact/) so
-we can work together towards achieving your goals.
+These were not the only improvements made to Ember's templating engine, or even to components. Also introduced to the framework were the ability to pass HTML attributes to components and apply them with `...attributes`, a simplification of DOM event handling with the [`on`](https://emberjs.github.io/rfcs/0471-on-modifier.html) and [`fn`](https://emberjs.github.io/rfcs/0470-fn-helper.html) modifiers replacing `action`, the ability for users to create [custom element modifiers](https://github.com/ember-modifier/ember-modifier) like the built-in `action`, `on`, and `fn`, [rendering lifecycle element modifiers](https://github.com/emberjs/ember-render-modifiers), and [Glimmer components](https://emberjs.github.io/rfcs/0416-glimmer-components.html).
+
+These new features will be covered in upcoming posts, so be sure to keep an eye out for them!
+
+If you are looking for help to update your codebase to these new idioms, or you want to level up your engineering team, make sure to [contact us](/contact/) so we can work together towards achieving your goals.
diff --git a/src/posts/2020-01-31-how-to-over-engineer-a-static-page.md b/src/posts/2020-01-31-how-to-over-engineer-a-static-page.md
index 4351a8359f..0726eea74b 100644
--- a/src/posts/2020-01-31-how-to-over-engineer-a-static-page.md
+++ b/src/posts/2020-01-31-how-to-over-engineer-a-static-page.md
@@ -3,10 +3,7 @@ title: "How to over-engineer a static page"
 authorHandle: marcoow
 tags: javascript
 bio: "Founding Director of Mainmatter, author of Ember Simple Auth"
-description:
-  "Marco Otte-Witte on how we rebuilt simplabs.com and optimized it for maximum
-  performance leveraging static pre-rendering and client-side rehydration,
-  advanced bundling and caching and service workers."
+description: "Marco Otte-Witte on how we rebuilt simplabs.com and optimized it for maximum performance leveraging static pre-rendering and client-side rehydration, advanced bundling and caching and service workers."
 og:
   image: /assets/images/posts/2020-01-31-how-to-over-engineer-a-static-page/og-image.jpg
 tagline: |
@@ -17,224 +14,66 @@ tagline: |
 
 Our goals for the new website were manifold:
 
-- We wanted to update the rather
-  [antiquated design of the old site](https://web.archive.org/web/20181021095200/https://simplabs.com/)
-  and create a modern design language that represented our identity well and was
-  build on a design system that we could build on in the future (the details of
-  which are to be covered in a separate, future post).
-- We wanted to keep creating and maintaining content for the site as simple as
-  it was with the previous site that was built on Jekyll and published via
-  GitHub Pages; for example adding new blog posts should remain as easy as
-  adding a new Markdown file with some front matter.
-- Although we are [huge fans of Elixir and Phoenix](/expertise/elixir-phoenix/)
-  we did not want to create an API server for the site that would serve content
-  etc. as that would have added quite some unnecessary complexity and should
-  generally not be necessary for a static site like ours anyway where all
-  content is known upfront and nothing ever needs to be calculated dynamically
-  on the server.
-- We wanted to have best in class performance so that the site would load as
-  fast as possible even in slow network situations and even without JavaScript
-  as well as offline of course.
+- We wanted to update the rather [antiquated design of the old site](https://web.archive.org/web/20181021095200/https://simplabs.com/) and create a modern design language that represented our identity well and was build on a design system that we could build on in the future (the details of which are to be covered in a separate, future post).
+- We wanted to keep creating and maintaining content for the site as simple as it was with the previous site that was built on Jekyll and published via GitHub Pages; for example adding new blog posts should remain as easy as adding a new Markdown file with some front matter.
+- Although we are [huge fans of Elixir and Phoenix](/expertise/elixir-phoenix/) we did not want to create an API server for the site that would serve content etc. as that would have added quite some unnecessary complexity and should generally not be necessary for a static site like ours anyway where all content is known upfront and nothing ever needs to be calculated dynamically on the server.
+- We wanted to have best in class performance so that the site would load as fast as possible even in slow network situations and even without JavaScript as well as offline of course.
 
 ## Static Prerendering + Rehydration and CSR
 
-Since the site is entirely static content, it was clear we wanted to serve
-pre-rendered HTML files for all pages – there was no point delaying the first
-paint until some JavaScript bundle was loaded. Those static HTML documents would
-be served via a CDN for an optimal Time to First Byte
-([TTFB](https://en.wikipedia.org/wiki/Time_to_first_byte)). As the pages were
-pre-rendered and did not depend on any client-side JavaScript, that would also
-result in a fast First Contentful Paint
-([FCP](https://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint)).
-Since there is no interactivity on any of the pages really, once the pages are
-rendered by the browser, they are also immediately interactive, meaning that
-Time to Interactive
-([TTI](https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive))
-is essentially the same as FCP in our case.
-
-However, one of the advantages of client-side rendering is that all subsequent
-page transitions after the initial render can be handled purely on the client
-side without the need to make (and wait for the response to) any additional
-requests. In order to combine that benefit with those of serving pre-rendered
-HTML documents, we wrote the site as a single-page app so that the client-side
-app would rehydrate on top of the pre-rendered DOM once the JavaScript was
-loaded and the app started. If that happens before a user clicks any of the
-links on any of the pages, the page transition would be handled purely on the
-client side and thus be instant. If a link is clicked **before** the app is
-running in the client, that click would simply result in a regular navigation
-request that would be responded to with another pre-rendered HTML document from
-the CDN. In that sense, the client-side app
-[progressively enhances](https://en.wikipedia.org/wiki/Progressive_enhancement)
-the static HTML document - if it is running, page transitions will be purely
-client-side and instant, if it is not (yet) running, clicks on links will simply
-be regular navigation requests.
+Since the site is entirely static content, it was clear we wanted to serve pre-rendered HTML files for all pages – there was no point delaying the first paint until some JavaScript bundle was loaded. Those static HTML documents would be served via a CDN for an optimal Time to First Byte ([TTFB](https://en.wikipedia.org/wiki/Time_to_first_byte)). As the pages were pre-rendered and did not depend on any client-side JavaScript, that would also result in a fast First Contentful Paint ([FCP](https://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint)). Since there is no interactivity on any of the pages really, once the pages are rendered by the browser, they are also immediately interactive, meaning that Time to Interactive ([TTI](https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive)) is essentially the same as FCP in our case.
+
+However, one of the advantages of client-side rendering is that all subsequent page transitions after the initial render can be handled purely on the client side without the need to make (and wait for the response to) any additional requests. In order to combine that benefit with those of serving pre-rendered HTML documents, we wrote the site as a single-page app so that the client-side app would rehydrate on top of the pre-rendered DOM once the JavaScript was loaded and the app started. If that happens before a user clicks any of the links on any of the pages, the page transition would be handled purely on the client side and thus be instant. If a link is clicked **before** the app is running in the client, that click would simply result in a regular navigation request that would be responded to with another pre-rendered HTML document from the CDN. In that sense, the client-side app [progressively enhances](https://en.wikipedia.org/wiki/Progressive_enhancement) the static HTML document - if it is running, page transitions will be purely client-side and instant, if it is not (yet) running, clicks on links will simply be regular navigation requests.
 
 ### Glimmer.js
 
-Since we are huge fans of Ember.js and are heavily connected with the community,
-supporting it and even directly involved in its core team, we wanted to stay in
-the ecosystem to build our own site as well. While Ember.js is a great fit for
-ambitious apps like [travel booking systems](/cases/trainline/) or
-[appointment scheduling systems](/cases/timify/) that implement significant
-client side logic though, for a static page like ours it would admittedly not
-have been an ideal fit – we would simply not have needed or used much of what it
-comes with. Ember.js' lightweight sister project
-[Glimmer.js](https://glimmerjs.com) provides exactly what we need though, which
-is a system for defining and rendering components and trees of components that
-would get re-rendered upon changes to the application state.
-
-The only client-side state that our application maintains is the currently
-active route that maps to a particular component that renders the page for that
-route. Leveraging [Navigo](https://github.com/krasimir/navigo) for the routing
-and combining that with Glimmer.js for the rendering we started out with a
-custom micro-framework with a size of only around 30KB of JavaScript. Given that
-we didn't even require the JS to be loaded in order for the page to be rendered
-or ready to use at all, that seemed pretty good. Our main JavaScript bundle that
-contains Glimmer.js, Navigo and **all** of the main site's content only weighs
-in at around 70KB (as of the writing of this post) and once that is loaded
-**all** of the main site is running in the browser, meaning no additional
-network requests are necessary when browsing the site.
+Since we are huge fans of Ember.js and are heavily connected with the community, supporting it and even directly involved in its core team, we wanted to stay in the ecosystem to build our own site as well. While Ember.js is a great fit for ambitious apps like [travel booking systems](/cases/trainline/) or [appointment scheduling systems](/cases/timify/) that implement significant client side logic though, for a static page like ours it would admittedly not have been an ideal fit – we would simply not have needed or used much of what it comes with. Ember.js' lightweight sister project [Glimmer.js](https://glimmerjs.com) provides exactly what we need though, which is a system for defining and rendering components and trees of components that would get re-rendered upon changes to the application state.
+
+The only client-side state that our application maintains is the currently active route that maps to a particular component that renders the page for that route. Leveraging [Navigo](https://github.com/krasimir/navigo) for the routing and combining that with Glimmer.js for the rendering we started out with a custom micro-framework with a size of only around 30KB of JavaScript. Given that we didn't even require the JS to be loaded in order for the page to be rendered or ready to use at all, that seemed pretty good. Our main JavaScript bundle that contains Glimmer.js, Navigo and **all** of the main site's content only weighs in at around 70KB (as of the writing of this post) and once that is loaded **all** of the main site is running in the browser, meaning no additional network requests are necessary when browsing the site.
 
 ### Statically Prerendering
 
-Statically pre-rendering a client-side app at build time is relatively straight
-forward. As part of our Netlify deployment, we build the app and start a small
-Express Server that serves it. We then visit each of the routes with a headless
-instance of Chrome using Puppeteer, take a snapshot of the page's DOM and save
-that to a respectively named file. All of these HTML files, along with the app
-itself and all other assets, then get uploaded to the CDN to be served from
-there.
+Statically pre-rendering a client-side app at build time is relatively straight forward. As part of our Netlify deployment, we build the app and start a small Express Server that serves it. We then visit each of the routes with a headless instance of Chrome using Puppeteer, take a snapshot of the page's DOM and save that to a respectively named file. All of these HTML files, along with the app itself and all other assets, then get uploaded to the CDN to be served from there.
 
 ## Maintaining content
 
-Although we were switching to a significantly more advanced setup than what we
-had with the previous Jekyll-based site, we did not want to give up the easy
-maintenance of content, specifically for blog posts and similar content that we
-wanted to keep in Markdown files as we used to. Writing a new post should remain
-as easy as adding a new markdown file with some front matter and
-Markdown-formatted content. At the same time, we did not want to rely on an API
-for loading the content of particular pages dynamically as that would have added
-significant additional complexity and none of our data actually needed to be
-computed on demand on the server as all of it is indeed static and known
-upfront. Leveraging Glimmer.js' Broccoli-based build pipeline, we set up a
-process that reads in all files in a directory and converts the Markdown files
-into Glimmer.js components at build time.
-
-That way we are generating dedicated components for all posts that are all
-mapped to their own routes. We also generate the components for the
-[blog listing page(s)](https://web.archive.org/web/20181021095200/https://simplabs.com/blog/)
-and the ones that
-[list all posts by a particular author](https://web.archive.org/web/20181021095200/https://simplabs.com/blog/author/marcoow).
-This approach basically moves what would typically be done by an API server at
-runtime (retrieving content from a repository that grows and changes over time)
-to build time, much like what the [Jamstack](https://jamstack.org) advocates for
-(and tools like [Empress](https://github.com/empress),
-[VuePress](https://vuepress.vuejs.org) or [Gatsby](https://www.gatsbyjs.org)
-would have done out of the box 😀). The same approach is used for other parts of
-the website that grow and change over time and that we want to be able to
-maintain content for with little effort like the
-[calendar](https://web.archive.org/web/20181021095200/https://simplabs.com/calendar/)
-or
-[talks catalog](https://web.archive.org/web/20181021095200/https://simplabs.com/talks/).
+Although we were switching to a significantly more advanced setup than what we had with the previous Jekyll-based site, we did not want to give up the easy maintenance of content, specifically for blog posts and similar content that we wanted to keep in Markdown files as we used to. Writing a new post should remain as easy as adding a new markdown file with some front matter and Markdown-formatted content. At the same time, we did not want to rely on an API for loading the content of particular pages dynamically as that would have added significant additional complexity and none of our data actually needed to be computed on demand on the server as all of it is indeed static and known upfront. Leveraging Glimmer.js' Broccoli-based build pipeline, we set up a process that reads in all files in a directory and converts the Markdown files into Glimmer.js components at build time.
+
+That way we are generating dedicated components for all posts that are all mapped to their own routes. We also generate the components for the [blog listing page(s)](https://web.archive.org/web/20181021095200/https://simplabs.com/blog/) and the ones that [list all posts by a particular author](https://web.archive.org/web/20181021095200/https://simplabs.com/blog/author/marcoow). This approach basically moves what would typically be done by an API server at runtime (retrieving content from a repository that grows and changes over time) to build time, much like what the [Jamstack](https://jamstack.org) advocates for (and tools like [Empress](https://github.com/empress), [VuePress](https://vuepress.vuejs.org) or [Gatsby](https://www.gatsbyjs.org) would have done out of the box 😀). The same approach is used for other parts of the website that grow and change over time and that we want to be able to maintain content for with little effort like the [calendar](https://web.archive.org/web/20181021095200/https://simplabs.com/calendar/) or [talks catalog](https://web.archive.org/web/20181021095200/https://simplabs.com/talks/).
 
 ## Bundling and Caching
 
-When all of a site's content is encoded in components that are written in
-JavaScript, that means that JavaScript bundle will significantly grow over time.
-In order to avoid that **all** of our users had to load **all** of the site's
-content on each visit, we wanted to split the JavaScript into separate bundles
-so that everyone only needs to load what is (likely to be) relevant for them.
-Anything that was not loaded already would be loaded lazily once the user
-navigated to the respective part of the site (and ideally be served from the
-service worker cache - more on that below). One approach for achieving such a
-split is to split individual bundles for all of the pages in a site but that
-means that any page transitions will result in an additional request to load the
-bundle that contains the content for the particular target page. We knew we did
-not want that but handle as many page transitions purely on the client side
-without the need for additional network requests as we could.
-
-The approach that we went with was to define bundle boundaries on usage patterns
-and split along those so that only few network requests would be necessary to
-load the JavaScript bundles that were actually relevant for a particular user.
-Our site now has a multitude of bundles:
-
-- the main bundle that contains Glimmer.js itself as well as **all** of the main
-  site's content; that is about 70KB as of the writing of this post
-- the bundles for each of the blog's listing pages as well as individual bundles
-  for each post; these are relatively small but change frequently of course
-- bundles for rarely accessed pages like
-  [imprint](https://web.archive.org/web/20181021095200/https://simplabs.com/imprint/)
-  and
-  [privacy policy](https://web.archive.org/web/20181021095200/https://simplabs.com/privacy/)
-  that have a significant size (around 11KB as of the writing of this post) but
-  contain content that is accessed only by very few users
-- additional bundles for more frequently changing content like the
-  [calendar](https://web.archive.org/web/20181021095200/https://simplabs.com/calendar/)
-  or
-  [talks catalog](https://web.archive.org/web/20181021095200/https://simplabs.com/talks/)
-- a bundle that contains a component that lists the most recent blog posts for a
-  particular topic that; that component gets included on
-  [pages within the main site](https://web.archive.org/web/20181021095200/https://simplabs.com/ember-consulting/)
+When all of a site's content is encoded in components that are written in JavaScript, that means that JavaScript bundle will significantly grow over time. In order to avoid that **all** of our users had to load **all** of the site's content on each visit, we wanted to split the JavaScript into separate bundles so that everyone only needs to load what is (likely to be) relevant for them. Anything that was not loaded already would be loaded lazily once the user navigated to the respective part of the site (and ideally be served from the service worker cache - more on that below). One approach for achieving such a split is to split individual bundles for all of the pages in a site but that means that any page transitions will result in an additional request to load the bundle that contains the content for the particular target page. We knew we did not want that but handle as many page transitions purely on the client side without the need for additional network requests as we could.
+
+The approach that we went with was to define bundle boundaries on usage patterns and split along those so that only few network requests would be necessary to load the JavaScript bundles that were actually relevant for a particular user. Our site now has a multitude of bundles:
+
+- the main bundle that contains Glimmer.js itself as well as **all** of the main site's content; that is about 70KB as of the writing of this post
+- the bundles for each of the blog's listing pages as well as individual bundles for each post; these are relatively small but change frequently of course
+- bundles for rarely accessed pages like [imprint](https://web.archive.org/web/20181021095200/https://simplabs.com/imprint/) and [privacy policy](https://web.archive.org/web/20181021095200/https://simplabs.com/privacy/) that have a significant size (around 11KB as of the writing of this post) but contain content that is accessed only by very few users
+- additional bundles for more frequently changing content like the [calendar](https://web.archive.org/web/20181021095200/https://simplabs.com/calendar/) or [talks catalog](https://web.archive.org/web/20181021095200/https://simplabs.com/talks/)
+- a bundle that contains a component that lists the most recent blog posts for a particular topic that; that component gets included on [pages within the main site](https://web.archive.org/web/20181021095200/https://simplabs.com/ember-consulting/)
 
 ### Bundles and Caching
 
-Another factor to take into account when defining bundle boundaries is the
-stability of each bundle in the sense of how often it is going to change over
-time. Our main bundle that contains Glimmer.js and the site's main content is
-relatively stable and will typically not change for longer periods of time
-(potentially weeks or months). That means once it is cached in a user's browser,
-there is a good chance they will be able to reuse it from cache upon their next
-visit. If we had included all of the components for all of the blog posts in
-that main bundle though, we would not only have steadily grown that bundle over
-time but also invalidated the users's cache for it every time we released a new
-post. The same is true for the component that renders a list of recent posts for
-a particular topic. As that component is always needed along with components
-that are part of the main bundle as it is rendered on the respective pages, we
-could have included it right with the main bundle, but that would likewise have
-meant invalidating the main bundle with every blog post which would have
-resulted in a poor utilisation of our user's caches.
+Another factor to take into account when defining bundle boundaries is the stability of each bundle in the sense of how often it is going to change over time. Our main bundle that contains Glimmer.js and the site's main content is relatively stable and will typically not change for longer periods of time (potentially weeks or months). That means once it is cached in a user's browser, there is a good chance they will be able to reuse it from cache upon their next visit. If we had included all of the components for all of the blog posts in that main bundle though, we would not only have steadily grown that bundle over time but also invalidated the users's cache for it every time we released a new post. The same is true for the component that renders a list of recent posts for a particular topic. As that component is always needed along with components that are part of the main bundle as it is rendered on the respective pages, we could have included it right with the main bundle, but that would likewise have meant invalidating the main bundle with every blog post which would have resulted in a poor utilisation of our user's caches.
 
 ### Caching Strategies
 
-As described, we optimized our bundles for cache-ability. Since we also use
-fingerprinted asset names (or actually
-[get them for free out of the box since Glimmer.js uses Ember CLI](https://ember-cli.com/user-guide/#fingerprinting-and-cdn-urls)),
-we can let our user's browsers cache all resources indefinitely using immutable
-caching:
+As described, we optimized our bundles for cache-ability. Since we also use fingerprinted asset names (or actually [get them for free out of the box since Glimmer.js uses Ember CLI](https://ember-cli.com/user-guide/#fingerprinting-and-cdn-urls)), we can let our user's browsers cache all resources indefinitely using immutable caching:
 
 ```
 cache-control: public,max-age=31536000,immutable
 ```
 
-The `immutable` caching directive tells the browser that the respective resource
-can never change and may be cached indefinitely. The `max-age` directive is only
-necessary as a fallback for browsers that
-[do not support immutable caching](https://caniuse.com/#feat=mdn-http_headers_cache-control_immutable).
-An immutable resource that the browser has cached will be available instantly on
-the next visit to the respective page and should generally have the same
-performance characteristics as a resource cached in a service worker's cache.
+The `immutable` caching directive tells the browser that the respective resource can never change and may be cached indefinitely. The `max-age` directive is only necessary as a fallback for browsers that [do not support immutable caching](https://caniuse.com/#feat=mdn-http_headers_cache-control_immutable). An immutable resource that the browser has cached will be available instantly on the next visit to the respective page and should generally have the same performance characteristics as a resource cached in a service worker's cache.
 
 ### Service Worker
 
-Of course we also install a service worker that caches all of the page's
-resources to further improve caching and make the page work offline. The service
-worker loads of the JavaScript bundles described above into its cache eagerly.
-So even some of the pages' content is split into separate bundles that are
-loaded lazily, when that lazy load is triggered the respective bundle is likely
-to be in the service worker's cache already and be served from there so that the
-page transition can still be instant without a network request.
+Of course we also install a service worker that caches all of the page's resources to further improve caching and make the page work offline. The service worker loads of the JavaScript bundles described above into its cache eagerly. So even some of the pages' content is split into separate bundles that are loaded lazily, when that lazy load is triggered the respective bundle is likely to be in the service worker's cache already and be served from there so that the page transition can still be instant without a network request.
 
 #### Static Prerendering and service workers
 
-When using service workers on a site with statically pre-rendered HTML, there is
-one caveat to be aware of when it comes to serving HTML from the service worker
-when the device is offline. Since every route on the page has its own HTML page
-that contains precisely the content for that page, not all HTML requests can be
-served with the same response from the service worker. Since the JavaScript
-bundle will be served from the service worker as well when the page starts
-offline, serving a pre-rendered HTML document is not necessary anyway though as
-there is no significant delay for loading the JavaScript. Instead, we can simply
-serve an empty HTML document in this scenario. That document only contains a
+When using service workers on a site with statically pre-rendered HTML, there is one caveat to be aware of when it comes to serving HTML from the service worker when the device is offline. Since every route on the page has its own HTML page that contains precisely the content for that page, not all HTML requests can be served with the same response from the service worker. Since the JavaScript bundle will be served from the service worker as well when the page starts offline, serving a pre-rendered HTML document is not necessary anyway though as there is no significant delay for loading the JavaScript. Instead, we can simply serve an empty HTML document in this scenario. That document only contains a
 
 ```html
 <div id="app"></div>
@@ -244,53 +83,18 @@ in its `<body>` that the application will render into once it starts up.
 
 ## More
 
-All of the above has lead to a result we are pretty happy with. While the design
-of our new page is for everyone to judge based on their own taste maybe, the
-performance numbers speak a clear language.
+All of the above has lead to a result we are pretty happy with. While the design of our new page is for everyone to judge based on their own taste maybe, the performance numbers speak a clear language.
 
 ![Screenshot](/assets/images/posts/2020-01-31-how-to-over-engineer-a-static-page/lighthouse.png#@900-1800)
 
-We were able to get there without giving up on the ease of maintenance of the
-content so that writing a new blog post is as easy as adding a Markdown file and
-opening a pull request.
-
-And even though we spent an unreasonable amount of time and effort during the
-course of the project, there are many more things that we did not do or that I
-couldn't cover in this article but that should be considered best practices when
-optimizing for performance:
-
-- CSS and optimizing it has huge potential to have significant positive impact
-  on a site's performance (and sink lots of time 🎉); we used
-  [CSS Blocks](https://css-blocks.com) which is great but worth a blog post of
-  its own so I won't go into any details here.
-- Images and their formats are a huge topic as well when it comes to performance
-  and there are many low hanging fruits where simple changes can have a
-  significant positive impact on a site's performance; things like inlining SVGs
-  (or not if they are big or change often), using progressive JPGs or
-  base64-encoded background images that get swapped out with the actual image
-  after page load are to be named as well as using progressive images to avoid
-  huge payloads on small viewports.
-- Third-parties can have a significant negative impact on a site's performance
-  and should generally be avoided (for example, you'll want to serve fonts from
-  your own domain).
-- Optimizing for performance is an ongoing project and not a one-off effort;
-  there needs to be tooling in place to be aware of degrations and accidental
-  mistakes, e.g. you could have Lighthouse integrated into your Github Pipeline
-  (ideally for every route of the app), jobs that tell you how much weight a
-  change adds to which bundles and which bundles it invalidates etc.
-- Knowing is better than guessing and if you really care about your site's
-  performance you need to measure using
-  [RUM](https://en.wikipedia.org/wiki/Real_user_monitoring).
-
-By spending a significant (and maybe unreasonable) amount of time and energy we
-ended up with the highly optimized site you're looking at. The downside is we
-ended up with our own custom static site generator essentially that we now need
-to maintain ourselves (one of the reasons why we recommend using a fully
-integrated framework like
-[Ember.js](https://web.archive.org/web/20181021095200/https://simplabs.com/ember-consulting/)
-instead of compiling your own custom framework out of a bunch of micro
-libraries). However, it was definitely an interesting experiment and we hope you
-take some inspiration out of the patterns and mechanisms we describe in this
-post. If you are struggling with performance in your Ember.js or Glimmer.js or
-other apps, feel free to [reach out and talk to our experts](/contact/) to see
-how we can help.
+We were able to get there without giving up on the ease of maintenance of the content so that writing a new blog post is as easy as adding a Markdown file and opening a pull request.
+
+And even though we spent an unreasonable amount of time and effort during the course of the project, there are many more things that we did not do or that I couldn't cover in this article but that should be considered best practices when optimizing for performance:
+
+- CSS and optimizing it has huge potential to have significant positive impact on a site's performance (and sink lots of time 🎉); we used [CSS Blocks](https://css-blocks.com) which is great but worth a blog post of its own so I won't go into any details here.
+- Images and their formats are a huge topic as well when it comes to performance and there are many low hanging fruits where simple changes can have a significant positive impact on a site's performance; things like inlining SVGs (or not if they are big or change often), using progressive JPGs or base64-encoded background images that get swapped out with the actual image after page load are to be named as well as using progressive images to avoid huge payloads on small viewports.
+- Third-parties can have a significant negative impact on a site's performance and should generally be avoided (for example, you'll want to serve fonts from your own domain).
+- Optimizing for performance is an ongoing project and not a one-off effort; there needs to be tooling in place to be aware of degrations and accidental mistakes, e.g. you could have Lighthouse integrated into your Github Pipeline (ideally for every route of the app), jobs that tell you how much weight a change adds to which bundles and which bundles it invalidates etc.
+- Knowing is better than guessing and if you really care about your site's performance you need to measure using [RUM](https://en.wikipedia.org/wiki/Real_user_monitoring).
+
+By spending a significant (and maybe unreasonable) amount of time and energy we ended up with the highly optimized site you're looking at. The downside is we ended up with our own custom static site generator essentially that we now need to maintain ourselves (one of the reasons why we recommend using a fully integrated framework like [Ember.js](https://web.archive.org/web/20181021095200/https://simplabs.com/ember-consulting/) instead of compiling your own custom framework out of a bunch of micro libraries). However, it was definitely an interesting experiment and we hope you take some inspiration out of the patterns and mechanisms we describe in this post. If you are struggling with performance in your Ember.js or Glimmer.js or other apps, feel free to [reach out and talk to our experts](/contact/) to see how we can help.
diff --git a/src/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com.md b/src/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com.md
index 3450649798..ea6e6dcb53 100644
--- a/src/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com.md
+++ b/src/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com.md
@@ -3,10 +3,7 @@ title: "The little changes that helped to transform an RFC into emberjs.com"
 authorHandle: pichfl
 tags: design
 bio: "Consultant for Design & Technology"
-description:
-  "Florian Pichler highlights details of the just released overhaul of the
-  landing page for Ember.js, looking specifically at how a distributed team of
-  volunteers can achieve consistent design."
+description: "Florian Pichler highlights details of the just released overhaul of the landing page for Ember.js, looking specifically at how a distributed team of volunteers can achieve consistent design."
 og:
   image: /assets/images/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com/og-image.jpg
 tagline: |
@@ -17,94 +14,54 @@ tagline: |
 
 ![Side by side comparison of the original website mockup from the RFC and the final mockup created by me](/assets/images/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com/before-after.jpg#full@1200-2761)
 
-<small>You can also download a
-[full sized comparision, side by side](https://user-images.githubusercontent.com/194641/75565735-c9559700-5a4e-11ea-8dd2-5bae88a694e0.jpg).
-Be warned, it is huge.</small>
+<small>You can also download a [full sized comparision, side by side](https://user-images.githubusercontent.com/194641/75565735-c9559700-5a4e-11ea-8dd2-5bae88a694e0.jpg). Be warned, it is huge.</small>
 
 ## Large changes
 
-After a discussion with the Ember Learning Core team, the "Try out" section was
-removed. There wasn't enough time left to create the section in a meaningful way
-and it didn't communicate the real strengths of Ember.js.
+After a discussion with the Ember Learning Core team, the "Try out" section was removed. There wasn't enough time left to create the section in a meaningful way and it didn't communicate the real strengths of Ember.js.
 
-We unfolded the tabs in the Batteries included section, so the core benefits of
-Ember are visible right away. This gave us a chance to add playful illustrations
-and lighten up the otherwise quite technical content.
+We unfolded the tabs in the Batteries included section, so the core benefits of Ember are visible right away. This gave us a chance to add playful illustrations and lighten up the otherwise quite technical content.
 
 ## Little changes, big effort
 
 ### A new font for Ember.js
 
-The font choice for the original RFC was lovely, and we are big fans of the
-Metric fonts by Klimt, but it was necessary to find a solution that is open
-source and does not involve licensing costs. After testing eight or more other
-alternatives, we settled on an excellent open source font:
+The font choice for the original RFC was lovely, and we are big fans of the Metric fonts by Klimt, but it was necessary to find a solution that is open source and does not involve licensing costs. After testing eight or more other alternatives, we settled on an excellent open source font:
 
 ![Font sample for Inter font](/assets/images/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com/inter.png#@860-1720)
 
-Meet [**Inter**](https://rsms.me/inter/), the new font representing Ember.js
-typographically in written word. It is not only well suited and tailor-made for
-user interfaces in general, but provides an exceptional range of cuts for all
-applications. It is both friendly and has an earnest quality that balances well
-against the playfulness of the Ember.js logo and mascots.
+Meet [**Inter**](https://rsms.me/inter/), the new font representing Ember.js typographically in written word. It is not only well suited and tailor-made for user interfaces in general, but provides an exceptional range of cuts for all applications. It is both friendly and has an earnest quality that balances well against the playfulness of the Ember.js logo and mascots.
 
 ### Typography
 
-The new website now has a typographic scale which provides not only a range of
-font sizes and appropriate line spacings, but also includes harmonic offsets
-that can be applied across the design, making it easy to add white space and
-layout organization to any element on a page.
+The new website now has a typographic scale which provides not only a range of font sizes and appropriate line spacings, but also includes harmonic offsets that can be applied across the design, making it easy to add white space and layout organization to any element on a page.
 
 ### Half a gradient of colors
 
 ![Slate gradient, Ember brand color with gradiated variations](/assets/images/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com/gradient.png#@860-1720)
 
-The RFC mockup introduces a new slate color to mark a new era for Ember. The
-Ember red represents the community. The new slate stands for the professionalism
-and strong foundation in quality. In short, they are meant to symbolize that
-Ember's strength lies in its an amazing community and reliability for
-businesses.
+The RFC mockup introduces a new slate color to mark a new era for Ember. The Ember red represents the community. The new slate stands for the professionalism and strong foundation in quality. In short, they are meant to symbolize that Ember's strength lies in its an amazing community and reliability for businesses.
 
-As you might have noticed, we are still lacking secondary colors, which are not
-settled yet and will become part of the second pass of changes to the Ember.js
-website ecosystem.
+As you might have noticed, we are still lacking secondary colors, which are not settled yet and will become part of the second pass of changes to the Ember.js website ecosystem.
 
 ## Style guide
 
-Having a mockup is nice, but it doesn't solve the complex task of building a
-theater of pages and small web apps which in total represents the online
-presence of Ember. We now have a living breathing style guide, which is both an
-ember-cli addon that can be consumed by the website and all the adjacent
-projects, but also live documentation that can be viewed online and, no
-surprise, is an Ember application itself, thanks to the magic of
-[empress][empress] and [ember-styleguide][ember-styleguide].
+Having a mockup is nice, but it doesn't solve the complex task of building a theater of pages and small web apps which in total represents the online presence of Ember. We now have a living breathing style guide, which is both an ember-cli addon that can be consumed by the website and all the adjacent projects, but also live documentation that can be viewed online and, no surprise, is an Ember application itself, thanks to the magic of [empress][empress] and [ember-styleguide][ember-styleguide].
 
 [empress]: https://github.com/empress/field-guide
 [ember-styleguide]: https://github.com/ember-learn/ember-styleguide/pull/145
 
-The style guide provides both actual Ember components that can be applied to any
-Ember project and a full set of CSS custom properties and helpers which make it
-easy to create good looking pages from scratch.
+The style guide provides both actual Ember components that can be applied to any Ember project and a full set of CSS custom properties and helpers which make it easy to create good looking pages from scratch.
 
 ![Examples for components created for the Ember Style Guide project](/assets/images/posts/2020-02-28-the-little-changes-that-helped-to-transform-an-RFC-into-emberjs-com/components.png#full@860-1720)
 
-Beyond the purely visual aspects of the design, I also introduced some
-lightweight CSS helpers for things like spacing, font sizes, grid and layout.
-Some of them were inspired by [Tailwind][tailwind], while others are explicitly
-narrow in their options to ensure overall consistency and to make them easier
-for contributors of the website to work with. Take a look at the [styleguide
-preview][styleguide-preview] to learn more about this.
+Beyond the purely visual aspects of the design, I also introduced some lightweight CSS helpers for things like spacing, font sizes, grid and layout. Some of them were inspired by [Tailwind][tailwind], while others are explicitly narrow in their options to ensure overall consistency and to make them easier for contributors of the website to work with. Take a look at the [styleguide preview][styleguide-preview] to learn more about this.
 
 [tailwind]: https://tailwindcss.com
 [styleguide-preview]: https://deploy-preview-145--ember-styleguide.netlify.com/
 
 ## Thanks
 
-Allocated time donated by Mainmatter allowed me and others to bring the
-styleguide and overall design of the website to what you can see online now. I
-was very honored by being invited to this project and my design changes were
-just an ever so small piece of the huge effort that went into the website from
-every single human on this team.
+Allocated time donated by Mainmatter allowed me and others to bring the styleguide and overall design of the website to what you can see online now. I was very honored by being invited to this project and my design changes were just an ever so small piece of the huge effort that went into the website from every single human on this team.
 
-I'm glad we made it, and I'm looking forward to contributing more and updating
-all the other aspecs of the Ember.js website landscape soon.
+I'm glad we made it, and I'm looking forward to contributing more and updating all the other aspecs of the Ember.js website landscape soon.
diff --git a/src/posts/2020-03-27-porting-a-site-to-ember-with-percy.md b/src/posts/2020-03-27-porting-a-site-to-ember-with-percy.md
index 71b94b50fd..c09a95456e 100644
--- a/src/posts/2020-03-27-porting-a-site-to-ember-with-percy.md
+++ b/src/posts/2020-03-27-porting-a-site-to-ember-with-percy.md
@@ -3,9 +3,7 @@ title: "Porting a site to Ember using Percy"
 authorHandle: real_ate
 tags: ember
 bio: "Senior Software Engineer, Ember Learning Core Team member"
-description:
-  "Chris Manson details a novel way to use Percy for tracking approximation of a
-  visual baseline when porting a site from one technology to another."
+description: "Chris Manson details a novel way to use Percy for tracking approximation of a visual baseline when porting a site from one technology to another."
 og:
   image: /assets/images/posts/2020-03-27-porting-a-site-to-ember-with-percy/og-image.jpg
 tagline: |
@@ -14,102 +12,47 @@ tagline: |
 
 ## Motivation
 
-This was one of the first steps in the long road to _Emberify_ and redesign the
-Ember website by first converting the architecture away from an old (and hard to
-maintain) Ruby middleman app, to a modern Static Single Page Application that is
-a dream to contribute to! This technique was first used to convert the
-[Ember Guides](https://guides.emberjs.com) to an Ember app and was then later
-used to convert the main [Ember Website](https://emberjs.com).
+This was one of the first steps in the long road to _Emberify_ and redesign the Ember website by first converting the architecture away from an old (and hard to maintain) Ruby middleman app, to a modern Static Single Page Application that is a dream to contribute to! This technique was first used to convert the [Ember Guides](https://guides.emberjs.com) to an Ember app and was then later used to convert the main [Ember Website](https://emberjs.com).
 
-The technique described below is a slightly novel way of using Percy, instead of
-tracking changes over the course of an active project we are using Percy to
-bootstrap our migration effort and make sure our ported app looks the same when
-it is done.
+The technique described below is a slightly novel way of using Percy, instead of tracking changes over the course of an active project we are using Percy to bootstrap our migration effort and make sure our ported app looks the same when it is done.
 
 ## Strict Requirements
 
-The point of this project was to change the technology that powered the Ember
-Guides without altering the look or feel of the site for end users. There were
-many factors that we needed to consider, but this post only looking at the
-design.
-
-We decided early on that we would not accept any functionality changes or minor
-design improvements as part of this project, in an effort to keep the initial
-project scope as small as possible and to improve the likelihood that we would
-ship the end product in a reasonable timeframe. While we weren't opposed to
-improving the end-user experience for this application, our objective was to
-make it **easier** to contribute improvements to the Ember Guides application.
-With this in mind we decided to release the technology re-write first, without
-noticeably changing anything! This allowed us to have a straightforward
-requirement: **if it looks the same we can ship it.**
+The point of this project was to change the technology that powered the Ember Guides without altering the look or feel of the site for end users. There were many factors that we needed to consider, but this post only looking at the design.
+
+We decided early on that we would not accept any functionality changes or minor design improvements as part of this project, in an effort to keep the initial project scope as small as possible and to improve the likelihood that we would ship the end product in a reasonable timeframe. While we weren't opposed to improving the end-user experience for this application, our objective was to make it **easier** to contribute improvements to the Ember Guides application. With this in mind we decided to release the technology re-write first, without noticeably changing anything! This allowed us to have a straightforward requirement: **if it looks the same we can ship it.**
 
 ## Enter Percy, stage right
 
-I had heard a lot about [Percy](https://percy.io/) over the years, being a part
-of the Ember community! It's a great product and something that is well-aligned
-philosophically with Ember. If you have ever had the pleasure to use Percy you
-will know that it has had a lot of thought put into it and it Just Works™️ when
-you start working with it.
+I had heard a lot about [Percy](https://percy.io/) over the years, being a part of the Ember community! It's a great product and something that is well-aligned philosophically with Ember. If you have ever had the pleasure to use Percy you will know that it has had a lot of thought put into it and it Just Works™️ when you start working with it.
 
-For those of you who don't know what Percy is, on their website they describe
-themselves as "Your all-in-one visual review platform". Just like Code Reviews
-and Pull requests, Percy allows you to view any **visual changes** as a result
-of the work that you are doing on an application. I have also heard it referred
-to as a "visual regression test system", but in practice it is much more than
-that. 😂
+For those of you who don't know what Percy is, on their website they describe themselves as "Your all-in-one visual review platform". Just like Code Reviews and Pull requests, Percy allows you to view any **visual changes** as a result of the work that you are doing on an application. I have also heard it referred to as a "visual regression test system", but in practice it is much more than that. 😂
 
-This got me thinking; if you can use Percy for visual regression tests, then why
-can't you use it to do an overarching regression test for porting the technology
-powering your website, sort of like a "migration regression test". After a bit
-of experimentation that is what we decided to do.
+This got me thinking; if you can use Percy for visual regression tests, then why can't you use it to do an overarching regression test for porting the technology powering your website, sort of like a "migration regression test". After a bit of experimentation that is what we decided to do.
 
 ## Setting up the baseline
 
-The first time you run Percy it takes a snapshot of all pages on your site and
-uses these as the "baseline" for which any subsequent change needs to be
-compared against.
+The first time you run Percy it takes a snapshot of all pages on your site and uses these as the "baseline" for which any subsequent change needs to be compared against.
 
-Note: Percy doesn't always take a snapshot of your entire site; it depends on
-how you integrate their SDKs with your application. For the purpose of this
-article (and during the guides migration) we are using the "static site" command
-line interface to upload to Percy, which loops through all of your html files
-and effectively uploads snapshots for all pages of your site.
+Note: Percy doesn't always take a snapshot of your entire site; it depends on how you integrate their SDKs with your application. For the purpose of this article (and during the guides migration) we are using the "static site" command line interface to upload to Percy, which loops through all of your html files and effectively uploads snapshots for all pages of your site.
 
-Once you have this baseline loaded for your "master" branch, you can setup Percy
-in your Continuous Integration (CI) service so that every Pull Request (PR) you
-make will be **compared against the baseline** and you will see a visual diff of
-what the site used to look like against the current changes.
+Once you have this baseline loaded for your "master" branch, you can setup Percy in your Continuous Integration (CI) service so that every Pull Request (PR) you make will be **compared against the baseline** and you will see a visual diff of what the site used to look like against the current changes.
 
 ![An example of the Percy interface](/assets/images/posts/2020-03-27-porting-a-site-to-ember-with-percy/percy-example.png#@920-1920)
 
 ### Getting a copy of the existing site
 
-The first thing that we need in this process is a local copy of the existing
-site we are planning to port. If you look at the
-[documentation for using the Percy command line client](https://docs.percy.io/docs/command-line-client)
-it tells you that you should build your static site locally and then point the
-CLI client to the output folder.
+The first thing that we need in this process is a local copy of the existing site we are planning to port. If you look at the [documentation for using the Percy command line client](https://docs.percy.io/docs/command-line-client) it tells you that you should build your static site locally and then point the CLI client to the output folder.
 
-As I briefly mentioned earlier, part of the issue with the old infrastructure
-for the Ember Guides was that it was so hard to contribute to that it was almost
-impossible to get working locally. If we can avoid having to run the Ruby
-middleman setup locally, that would be a better approach, so another way to get
-a static copy of the website would be to pretend that we're Google for a few
-minutes and just crawl the site to download it locally.
+As I briefly mentioned earlier, part of the issue with the old infrastructure for the Ember Guides was that it was so hard to contribute to that it was almost impossible to get working locally. If we can avoid having to run the Ruby middleman setup locally, that would be a better approach, so another way to get a static copy of the website would be to pretend that we're Google for a few minutes and just crawl the site to download it locally.
 
-If you are on a Linux machine you probably have `wget` installed, it is a
-particularly useful tool to download single files quickly and easily. If you are
-on macOS then you will probably need to use [Homebrew](https://brew.sh/) to
-install it:
+If you are on a Linux machine you probably have `wget` installed, it is a particularly useful tool to download single files quickly and easily. If you are on macOS then you will probably need to use [Homebrew](https://brew.sh/) to install it:
 
 ```bash
 brew install wget
 ```
 
-Before working on this project I didn't actually realise that, not only can you
-use `wget` to download single files but you can also use it to crawl and
-download entire websites! Here is the command that I'm using to download the
-entire [Ember Website](https://emberjs.com):
+Before working on this project I didn't actually realise that, not only can you use `wget` to download single files but you can also use it to crawl and download entire websites! Here is the command that I'm using to download the entire [Ember Website](https://emberjs.com):
 
 ```bash
 wget --recursive \
@@ -120,26 +63,13 @@ wget --recursive \
      emberjs.com
 ```
 
-Note: I'm running these commands on macOS with `wget` version _1.19.5_ so you
-might need to confirm these arguments for your platform and `wget` version.
+Note: I'm running these commands on macOS with `wget` version _1.19.5_ so you might need to confirm these arguments for your platform and `wget` version.
 
-If you Google "crawl website with wget" or "download entire site with wget" you
-will undoubtedly get quite a few variations of the above set of arguments to the
-`wget` command. Most of these arguments are self-explanatory (and it could be an
-exercise for you to check the wget man page to see exactly what they do) but if
-you are planning to run this on your own site I would recommend using the
-`--domains` option, and you might want to also look into `--reject-regex`.
+If you Google "crawl website with wget" or "download entire site with wget" you will undoubtedly get quite a few variations of the above set of arguments to the `wget` command. Most of these arguments are self-explanatory (and it could be an exercise for you to check the wget man page to see exactly what they do) but if you are planning to run this on your own site I would recommend using the `--domains` option, and you might want to also look into `--reject-regex`.
 
-When crawling sites with something like `wget` things can very quickly get out
-of hand. If your site has external links to other domains and you don't limit
-the domains you want to download with `--domains` you can very quickly end up
-downloading the whole internet!
+When crawling sites with something like `wget` things can very quickly get out of hand. If your site has external links to other domains and you don't limit the domains you want to download with `--domains` you can very quickly end up downloading the whole internet!
 
-`--reject-regex` is also a useful tool if you have some subfolders that have
-dynamically generated content. When we first ran this command on the Ember
-website the blog was available at https://emberjs.com/blog and had 220+ pages
-that would be downloaded in our crawl. 😬 Adding the following line to our
-`wget` command would have excluded that whole directory
+`--reject-regex` is also a useful tool if you have some subfolders that have dynamically generated content. When we first ran this command on the Ember website the blog was available at https://emberjs.com/blog and had 220+ pages that would be downloaded in our crawl. 😬 Adding the following line to our `wget` command would have excluded that whole directory
 
 ```
 --reject-regex '/blog/*'
@@ -147,22 +77,15 @@ that would be downloaded in our crawl. 😬 Adding the following line to our
 
 ### Verifying all the pages are there
 
-After running the above command we have a folder `emberjs.com` that contains a
-static copy of the Ember Website. We now need to list all of the pages and make
-sure that we're happy that we've captured all of the necessary pages.
+After running the above command we have a folder `emberjs.com` that contains a static copy of the Ember Website. We now need to list all of the pages and make sure that we're happy that we've captured all of the necessary pages.
 
-Thankfully we used `--html-extension` which will make sure that all html files
-end with `.html` so we can run a simple `find` command in that folder to list
-the pages:
+Thankfully we used `--html-extension` which will make sure that all html files end with `.html` so we can run a simple `find` command in that folder to list the pages:
 
 ```bash
 find . -iname '*.html'
 ```
 
-You should now go through and prune any html files that you don't want to use
-and make sure that everything you expect to be there is. In our case it was
-listing quite a few "query param" pages that we really didn't care about so we
-just needed to delete them.
+You should now go through and prune any html files that you don't want to use and make sure that everything you expect to be there is. In our case it was listing quite a few "query param" pages that we really didn't care about so we just needed to delete them.
 
 ```
 ./mascots?filter=zoey.html
@@ -173,37 +96,21 @@ just needed to delete them.
 ./mascots?filter=conference.html
 ```
 
-If you have access to the output directory of the application that you're trying
-to migrate then you won't need to go through this step of cleaning up so I would
-recommend that if you can.
+If you have access to the output directory of the application that you're trying to migrate then you won't need to go through this step of cleaning up so I would recommend that if you can.
 
 ### Uploading to Percy
 
-It is worth referring to the instructions
-https://docs.percy.io/docs/command-line-client but for us we are running the
-following command:
+It is worth referring to the instructions https://docs.percy.io/docs/command-line-client but for us we are running the following command:
 
 ```bash
 PERCY_TOKEN=not_our_real_token PERCY_BRANCH=master percy snapshot emberjs.com
 ```
 
-In this example emberjs.com is the name of the folder that was created with the
-`wget` command. We need to provide the `PERCY_BRANCH` in our case because Percy
-is supposed to be run in conjunction with your Version Control System (VCS) and
-since we just have a folder instead of a git repository it won't autodetect our
-branch. We want it to be our `master` branch because this is going to serve as
-the baseline around which all of the rest of the application will be built.
+In this example emberjs.com is the name of the folder that was created with the `wget` command. We need to provide the `PERCY_BRANCH` in our case because Percy is supposed to be run in conjunction with your Version Control System (VCS) and since we just have a folder instead of a git repository it won't autodetect our branch. We want it to be our `master` branch because this is going to serve as the baseline around which all of the rest of the application will be built.
 
 ## Setting up Percy for the Ember Application
 
-The
-[official documentation for the Percy Ember integration](https://docs.percy.io/docs/ember)
-is fantastic and I would **highly** recommend that you check it out. We need to
-set up a very slightly custom implementation for our needs because we would like
-the snapshots that were generated from the Percy CLI to match the snapshots from
-the ember application. The simplest way to do this is for us to define the
-mapping manually, here is what that mapping looks like in the ember-website
-testing code:
+The [official documentation for the Percy Ember integration](https://docs.percy.io/docs/ember) is fantastic and I would **highly** recommend that you check it out. We need to set up a very slightly custom implementation for our needs because we would like the snapshots that were generated from the Percy CLI to match the snapshots from the ember application. The simplest way to do this is for us to define the mapping manually, here is what that mapping looks like in the ember-website testing code:
 
 ```javascript
 // This is used to map the current **new** routes to what they used to be in the
@@ -242,10 +149,7 @@ const pages = [
 ];
 ```
 
-With this defined all we need to do is to loop through this array in an Ember
-Acceptance test, use the `visit()` API to navigate to the specified route and
-then use the Percy Ember testing API to take a snapshot. It's important to pass
-the title into the snapshot so that we can match against the legacy application.
+With this defined all we need to do is to loop through this array in an Ember Acceptance test, use the `visit()` API to navigate to the specified route and then use the Percy Ember testing API to take a snapshot. It's important to pass the title into the snapshot so that we can match against the legacy application.
 
 Here is what that code looks like in the ember-website:
 
@@ -256,39 +160,18 @@ for (let config of pages) {
 }
 ```
 
-Even though I've copied most of the implementation into this post you can
-[see it all in action directly in the source code of the ember-website project](https://github.com/ember-learn/ember-website/blob/401a638dbb65191d1273de8336525bf9df6b53bc/tests/acceptance/visual-regression-test.js#L1)
+Even though I've copied most of the implementation into this post you can [see it all in action directly in the source code of the ember-website project](https://github.com/ember-learn/ember-website/blob/401a638dbb65191d1273de8336525bf9df6b53bc/tests/acceptance/visual-regression-test.js#L1)
 
 ## Open a PR, Iterate on the design, Ship when green
 
-At this point, it's time to open a PR to test your Percy integration. This will
-create a Percy build that will be a comparison to the baseline that we set up
-previously. **Note:** it's important to do this in a PR and not on your `master`
-branch directly because Percy will automatically "approve" changes that are
-pushed to your master branch. Once you open the PR, if you have followed the
-Percy installation instructions correctly, Percy will start to build your visual
-diff.
-
-The examples shown in this post have been leading up to
-[an actual PR on the ember-website project](https://github.com/ember-learn/ember-website/pull/185)
-and you will see in the CI checks for that PR that the initial Percy build is
-failing. If you saw the visual diff you would have seen that there was quite
-some work that needed to be done before this was ready to go live, but I never
-said that this would do all the work for you! 😂
-
-What Percy is really giving you here is the confidence to know when the project
-is ready to be shipped. If you can constrain the requirements to "make it look
-like it did before", and you can avoid "feature creep", then you will know with
-confidence that it is ready to deploy when you have a passing CI and your Percy
-build shows no changes. If Percy is happy then you can deploy with confidence.
+At this point, it's time to open a PR to test your Percy integration. This will create a Percy build that will be a comparison to the baseline that we set up previously. **Note:** it's important to do this in a PR and not on your `master` branch directly because Percy will automatically "approve" changes that are pushed to your master branch. Once you open the PR, if you have followed the Percy installation instructions correctly, Percy will start to build your visual diff.
+
+The examples shown in this post have been leading up to [an actual PR on the ember-website project](https://github.com/ember-learn/ember-website/pull/185) and you will see in the CI checks for that PR that the initial Percy build is failing. If you saw the visual diff you would have seen that there was quite some work that needed to be done before this was ready to go live, but I never said that this would do all the work for you! 😂
+
+What Percy is really giving you here is the confidence to know when the project is ready to be shipped. If you can constrain the requirements to "make it look like it did before", and you can avoid "feature creep", then you will know with confidence that it is ready to deploy when you have a passing CI and your Percy build shows no changes. If Percy is happy then you can deploy with confidence.
 
 ## Summary
 
-This is a useful technique that we have now used successfully twice to port
-large projects from Ruby middleman to Ember in the Ember Learning Team, and
-while it is not exactly using Percy as it was designed, it is a very useful
-technique to have in your tool belt.
+This is a useful technique that we have now used successfully twice to port large projects from Ruby middleman to Ember in the Ember Learning Team, and while it is not exactly using Percy as it was designed, it is a very useful technique to have in your tool belt.
 
-If you have a project that you are thinking of porting to EmberJS and would like
-to discuss it with us, or if you have any general questions about this topic we
-encourage you to [contact us](/contact/)!
+If you have a project that you are thinking of porting to EmberJS and would like to discuss it with us, or if you have any general questions about this topic we encourage you to [contact us](/contact/)!
diff --git a/src/posts/2020-05-04-facilitate-client-onboarding.md b/src/posts/2020-05-04-facilitate-client-onboarding.md
index 3b816c3917..c4ad8308b7 100644
--- a/src/posts/2020-05-04-facilitate-client-onboarding.md
+++ b/src/posts/2020-05-04-facilitate-client-onboarding.md
@@ -3,9 +3,7 @@ title: "How to Improve Kick-off Meetings to Spark Collaboration"
 authorHandle: ghislaineguerin
 tags: design
 bio: "Process Designer and Facilitator"
-description:
-  "Ghislaine Guerin presents techniques for getting the most out of kick-off
-  meetings."
+description: "Ghislaine Guerin presents techniques for getting the most out of kick-off meetings."
 og:
   image: /assets/images/posts/2020-05-04-facilitate-client-onboarding/og-image.jpg
 tagline: |
@@ -14,20 +12,11 @@ tagline: |
 
 ![kick-off-arches](/assets/images/posts/2020-05-04-facilitate-client-onboarding/kick-off-arches.png#@1440-2880)
 
-At Mainmatter, we believe in working alongside clients throughout projects not
-only as a way to get better outcomes but also because we aim to build
-relationships rather than just projects.
+At Mainmatter, we believe in working alongside clients throughout projects not only as a way to get better outcomes but also because we aim to build relationships rather than just projects.
 
-Kick-off meetings are one of the first things we tackle as part of our process
-to deliver digital products, whether it is creating an app from scratch or a
-website. We use them to set the beginning of a new project and bring the client
-on board.
+Kick-off meetings are one of the first things we tackle as part of our process to deliver digital products, whether it is creating an app from scratch or a website. We use them to set the beginning of a new project and bring the client on board.
 
-I want to present an approach to kick-off meetings that can spark collaboration
-early in the project and create common ground between the client and the team.
-To envision the type of meeting that would undoubtedly be worth the time of
-everyone attending and produce a mindset that is distinctly different from the
-typical frame with which most software projects are conducted.
+I want to present an approach to kick-off meetings that can spark collaboration early in the project and create common ground between the client and the team. To envision the type of meeting that would undoubtedly be worth the time of everyone attending and produce a mindset that is distinctly different from the typical frame with which most software projects are conducted.
 
 **Most kick-off meetings follow this plan:**
 
@@ -40,126 +29,58 @@ typical frame with which most software projects are conducted.
 
 #### Kick-Off Meetings Are More Than Just Checklists
 
-To be clear, I think those are good points to cover; however, treating this as a
-checklist won't produce any lasting impact on participants. We've all been to
-many meetings where we just want to get back to work. For that reason, an
-intentional facilitated approach is required to make these points come to life
-and spark real and honest discussion.
+To be clear, I think those are good points to cover; however, treating this as a checklist won't produce any lasting impact on participants. We've all been to many meetings where we just want to get back to work. For that reason, an intentional facilitated approach is required to make these points come to life and spark real and honest discussion.
 
 ### Team Introductions Can Serve as a Way to Communicate Organizational and Team Culture
 
-Most teams undergo a gradual process before they can reach peak performance. In
-the initial forming stage, there is a mix of emotions, ranging from excitement
-to anxiety that can affect performance. The same is true for team and client
-interactions at the start of a project. Shared culture can have a significant
-influence on how fast we can advance as a team.
+Most teams undergo a gradual process before they can reach peak performance. In the initial forming stage, there is a mix of emotions, ranging from excitement to anxiety that can affect performance. The same is true for team and client interactions at the start of a project. Shared culture can have a significant influence on how fast we can advance as a team.
 
-Starting with a strong notion of the shared culture of a team will influence
-interactions with the client. If things are left unsaid, we risk filling that
-space with assumptions and unwritten rules.
+Starting with a strong notion of the shared culture of a team will influence interactions with the client. If things are left unsaid, we risk filling that space with assumptions and unwritten rules.
 
-So, how can those invisible parts be made visible during an introduction? Next
-time you introduce yourself, make a conscious decision to share your
-expectations, what you like and dislike, and maybe dare to be more personal.
+So, how can those invisible parts be made visible during an introduction? Next time you introduce yourself, make a conscious decision to share your expectations, what you like and dislike, and maybe dare to be more personal.
 
 #### Example:
 
-"Hello, my name is Ghislaine, and I will be **working with you** on the design
-aspects of this project. I've read your brief, and I find **challenges like
-yours fascinating** from a design perspective, especially when it comes to users
-creating value for others. I hope to **learn more from your vision** throughout
-this project and know that I am always open to discuss things briefly, even if
-unrelated to the project, feel free to **send an email if you have any
-questions**."
+"Hello, my name is Ghislaine, and I will be **working with you** on the design aspects of this project. I've read your brief, and I find **challenges like yours fascinating** from a design perspective, especially when it comes to users creating value for others. I hope to **learn more from your vision** throughout this project and know that I am always open to discuss things briefly, even if unrelated to the project, feel free to **send an email if you have any questions**."
 
-By being more intentional about what we say during team introductions, we can
-communicate additional layers of behaviors we like, how people can address us,
-what we expect from them, and what we bring to the table beside our work.
+By being more intentional about what we say during team introductions, we can communicate additional layers of behaviors we like, how people can address us, what we expect from them, and what we bring to the table beside our work.
 
 ### Helping the Client Describe Their Journey Through Active Listening
 
-The role of clients in projects is significant not only for the obvious reason
-that they are the ones whom the project is built for but also because they have
-a great influence on the course of action.
+The role of clients in projects is significant not only for the obvious reason that they are the ones whom the project is built for but also because they have a great influence on the course of action.
 
-A study by the PMI (Project Management Institute) concluded that one of the
-biggest reasons for project failure is due to clients realizing new needs during
-the design and production phases. Because the client has been overexposed to
-their idea, they mistakenly assume that some details of their journey or
-motivations aren't relevant to share. The issue is that when clients cannot
-clearly describe the problem they are trying to solve at the start, their needs
-may turn self-contradicting throughout the project.
+A study by the PMI (Project Management Institute) concluded that one of the biggest reasons for project failure is due to clients realizing new needs during the design and production phases. Because the client has been overexposed to their idea, they mistakenly assume that some details of their journey or motivations aren't relevant to share. The issue is that when clients cannot clearly describe the problem they are trying to solve at the start, their needs may turn self-contradicting throughout the project.
 
 #### Listen Actively and Delay Judgement
 
 ![SCARF MODEL](/assets/images/posts/2020-05-04-facilitate-client-onboarding/scarf.png#@1024-2048)
 
-It is not hard to find incongruencies or faults when someone is presenting an
-idea, even more so if it's the first time we are exposed to it. We can help the
-client connect and provide all the details if we take an active listener
-position and delay offering suggestions or advice. It is even better if we can
-ask questions that lead them to be more critical of their assumptions.
+It is not hard to find incongruencies or faults when someone is presenting an idea, even more so if it's the first time we are exposed to it. We can help the client connect and provide all the details if we take an active listener position and delay offering suggestions or advice. It is even better if we can ask questions that lead them to be more critical of their assumptions.
 
-The reason why this approach works is best explained using the SCARF model from
-the domain of neuroscience. This model provides a framework to understand the
-common factors leading to threat responses and how we can change directions to
-more collaborative win-win scenarios.
+The reason why this approach works is best explained using the SCARF model from the domain of neuroscience. This model provides a framework to understand the common factors leading to threat responses and how we can change directions to more collaborative win-win scenarios.
 
-To put it simply, it states that when sensing a threat we turn to avoidance,
-while rewards make us move towards a situation. This is why active listening is
-so effective, as we reduce the feeling of a threat if attention is being paid to
-our efforts. Enabling this state can produce a willingness to move through
-difficult things, take risks, and try new solutions.
+To put it simply, it states that when sensing a threat we turn to avoidance, while rewards make us move towards a situation. This is why active listening is so effective, as we reduce the feeling of a threat if attention is being paid to our efforts. Enabling this state can produce a willingness to move through difficult things, take risks, and try new solutions.
 
 ### How do we discuss project goals?
 
-Project goals might be the most critical aspect of this process; after all,
-there'd be no need to meet or create something if we had no expectations for a
-project's outcome. However, if those expectations aren't clear for everyone, we
-might find conflict down the road, and while that's a natural part of projects,
-confronting them early is the best way to ensure a smooth process.
+Project goals might be the most critical aspect of this process; after all, there'd be no need to meet or create something if we had no expectations for a project's outcome. However, if those expectations aren't clear for everyone, we might find conflict down the road, and while that's a natural part of projects, confronting them early is the best way to ensure a smooth process.
 
-Talking about problems at the very beginning can be quite hard. And I know
-because I've been there too. That is until I started my path as a facilitator
-and experienced the value behind exposing those problems and facing uncertainty
-from the very beginning.
+Talking about problems at the very beginning can be quite hard. And I know because I've been there too. That is until I started my path as a facilitator and experienced the value behind exposing those problems and facing uncertainty from the very beginning.
 
 #### Recognizing and Avoiding Groupthink
 
 ![Circle of Influence](/assets/images/posts/2020-05-04-facilitate-client-onboarding/circle.png#@1024-2048)
 
-Groupthink — the preference of harmony instead and avoidance of conflict within
-groups — can cause teams to make sub-optimal decisions when they prioritize
-conformity over critical reasoning or evaluation. Although it is unintentional,
-recognizing it and creating spaces for debate can lead to teams that tolerate
-ambiguity together.
-
-An excellent way to spark debate is to place the goals and outcomes into the
-'Circle of Influence'. This is a tool that can help teams discuss goals from a
-place of ownership and shared responsibility. The idea is to place the goals
-into each sphere of the diagram and explain the reasons why we think we have or
-lack control over any desired outcome and things we can do to influence them
-positively or reduce the impact of negative factors.
-
-It works because, when we can accept our lack of control over something, we
-ignite the team's creative engine and figure out ways to influence a more
-successful outcome. We might not be able to implement a fully-fledged feature
-that would guarantee an advantage, but accepting that might open up unforeseen
-possibilities.
-
-I like to use the example of Notion, considered now one of the best apps in its
-category with over 1 million users. It tells the story of how their team managed
-to rise back up from failure and perform exponentially better only after they
-run out of cash. A constraint mindset can be the optimal way of creating
-unparalleled solutions.
+Groupthink — the preference of harmony instead and avoidance of conflict within groups — can cause teams to make sub-optimal decisions when they prioritize conformity over critical reasoning or evaluation. Although it is unintentional, recognizing it and creating spaces for debate can lead to teams that tolerate ambiguity together.
+
+An excellent way to spark debate is to place the goals and outcomes into the 'Circle of Influence'. This is a tool that can help teams discuss goals from a place of ownership and shared responsibility. The idea is to place the goals into each sphere of the diagram and explain the reasons why we think we have or lack control over any desired outcome and things we can do to influence them positively or reduce the impact of negative factors.
+
+It works because, when we can accept our lack of control over something, we ignite the team's creative engine and figure out ways to influence a more successful outcome. We might not be able to implement a fully-fledged feature that would guarantee an advantage, but accepting that might open up unforeseen possibilities.
+
+I like to use the example of Notion, considered now one of the best apps in its category with over 1 million users. It tells the story of how their team managed to rise back up from failure and perform exponentially better only after they run out of cash. A constraint mindset can be the optimal way of creating unparalleled solutions.
 
 ## Next Steps
 
-The facilitator role should continue to be present during the rest of the
-project. However, a good start will help everyone handle uncertainty and
-conflict a lot better, especially during the most challenging parts, but also to
-celebrate our shared achievements.
+The facilitator role should continue to be present during the rest of the project. However, a good start will help everyone handle uncertainty and conflict a lot better, especially during the most challenging parts, but also to celebrate our shared achievements.
 
-To learn more, check out our [playbook](/playbook/). It contains a general
-overview of our process and how we work together to deliver ambitious projects
-for our clients.
+To learn more, check out our [playbook](/playbook/). It contains a general overview of our process and how we work together to deliver ambitious projects for our clients.
diff --git a/src/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app.md b/src/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app.md
index 4d5c5f28e1..8b09801359 100644
--- a/src/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app.md
+++ b/src/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app.md
@@ -3,37 +3,20 @@ title: "How to improve the accessibility of your existing Ember app"
 authorHandle: sami_dbc
 tags: ember
 bio: "Senior Frontend Engineer"
-description:
-  "Samanta de Barros on how to test the accessibility of your Ember app and what
-  accessibility considerations you should have when creating forms in Ember."
+description: "Samanta de Barros on how to test the accessibility of your Ember app and what accessibility considerations you should have when creating forms in Ember."
 og:
   image: /assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/og-image.jpg
 tagline: |
   <p>Making sure your web app is accessible can be a daunting task. Just as having a good testing suite or an app that's responsive and works well across devices, it seems easier to achieve when you're starting a new project than when working with an existing app. Knowing where to start can be tough, therefore we've outlined how to implement accessibility tests in Ember alongside a very common case: forms.</p>
 ---
 
-For some time now, there's been an ongoing effort in the Ember community to make
-accessibility an integral part of the framework. A handful of tools and
-resources have been created to give developers an easier time building
-accessible apps. One interesting tool, in particular, is
-[ember-a11y-testing](https://github.com/ember-a11y/ember-a11y-testing), which
-helps detect accessibility violations during both testing and development.
-
-While working on a client project, we decided to improve the accessibility of
-that app, and using this tool in our tests seemed like it would be a good start.
-The first question we came across was, **what's the best way to introduce these
-tests when you have an app with an already big testing suite?**
-
-At the time, the best answer for us was to create dedicated acceptance tests for
-accessibility, that would go through a couple of important flows within the app
-rather than add those checks on the already existing tests. The reason for this
-was that we were dealing with an incomplete testing suite where tests didn't
-follow the same patterns, some would test flows, others would test just parts of
-a page, so it was hard to define where to add the accessibility checks so they
-would bring the most value.
-
-To add accessibility checks, simply install the add-on and use it in your tests,
-here's an example of an acceptance test:
+For some time now, there's been an ongoing effort in the Ember community to make accessibility an integral part of the framework. A handful of tools and resources have been created to give developers an easier time building accessible apps. One interesting tool, in particular, is [ember-a11y-testing](https://github.com/ember-a11y/ember-a11y-testing), which helps detect accessibility violations during both testing and development.
+
+While working on a client project, we decided to improve the accessibility of that app, and using this tool in our tests seemed like it would be a good start. The first question we came across was, **what's the best way to introduce these tests when you have an app with an already big testing suite?**
+
+At the time, the best answer for us was to create dedicated acceptance tests for accessibility, that would go through a couple of important flows within the app rather than add those checks on the already existing tests. The reason for this was that we were dealing with an incomplete testing suite where tests didn't follow the same patterns, some would test flows, others would test just parts of a page, so it was hard to define where to add the accessibility checks so they would bring the most value.
+
+To add accessibility checks, simply install the add-on and use it in your tests, here's an example of an acceptance test:
 
 ```js
 {% raw %}
@@ -59,12 +42,7 @@ module('Acceptance | accessibility check', function (hooks) {
 {% endraw %}
 ```
 
-You can also add these validations to integration tests. While you are creating
-integration tests for components, you could easily add a few extra tests that
-check for accessibility issues. If you already have well-tested components, it
-could be interesting to adopt the accessibility checks as part of the
-development process, making sure that both new components and improvements to
-existing components don't introduce any violations of accessibility rules
+You can also add these validations to integration tests. While you are creating integration tests for components, you could easily add a few extra tests that check for accessibility issues. If you already have well-tested components, it could be interesting to adopt the accessibility checks as part of the development process, making sure that both new components and improvements to existing components don't introduce any violations of accessibility rules
 
 ```js
 {% raw %}
@@ -88,28 +66,13 @@ module('Component | login-form', function (hooks) {
 {% endraw %}
 ```
 
-The `a11yAudit` helper will inspect the rendered page or component and it will
-raise an error if it finds any accessibility violations. The great thing about
-this is that it will list all violations with the respective severities and will
-even include a link to documentation for that rule, which includes an
-explanation of why the rule exists and how to fix it. For instance,
-[here's the information](https://dequeuniversity.com/rules/axe/3.5/autocomplete-valid?application=axeAPI)
-for one of the validation errors we're getting.
+The `a11yAudit` helper will inspect the rendered page or component and it will raise an error if it finds any accessibility violations. The great thing about this is that it will list all violations with the respective severities and will even include a link to documentation for that rule, which includes an explanation of why the rule exists and how to fix it. For instance, [here's the information](https://dequeuniversity.com/rules/axe/3.5/autocomplete-valid?application=axeAPI) for one of the validation errors we're getting.
 
 ![example of errors thrown by a11y in an acceptance test](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/acceptance-test-error.png#@1024-2048)
 
-One issue we ran into, was that these tests brought up a lot of accessibility
-violations, some of which we couldn't just fix on our own. For example, several
-of the errors were due to color contrast issues, in a lot of cases, deciding on
-(and changing) color schemes may not be entirely in your power, and it can
-involve discussions with designers, product owners, and may even be influenced
-by branding, but you can and should use this information to spark those
-discussions and promote change.
+One issue we ran into, was that these tests brought up a lot of accessibility violations, some of which we couldn't just fix on our own. For example, several of the errors were due to color contrast issues, in a lot of cases, deciding on (and changing) color schemes may not be entirely in your power, and it can involve discussions with designers, product owners, and may even be influenced by branding, but you can and should use this information to spark those discussions and promote change.
 
-If you're in the same situation and fixing those errors is not something that
-can be done all at once, you can opt for muting validations and taking an
-incremental approach to making these improvements (similar to the upgrade path
-in Ember where you can mute deprecations and work on them step by step).
+If you're in the same situation and fixing those errors is not something that can be done all at once, you can opt for muting validations and taking an incremental approach to making these improvements (similar to the upgrade path in Ember where you can mute deprecations and work on them step by step).
 
 ```js
 {% raw %}
@@ -138,8 +101,7 @@ test('sign in page has no accessibility issues', async function (assert) {
 {% endraw %}
 ```
 
-If you happen to have a very long list of rules to mutate, you may want to do
-something like:
+If you happen to have a very long list of rules to mutate, you may want to do something like:
 
 ```js
 {% raw %}
@@ -166,31 +128,17 @@ test('sign in page has no accessibility issues', async function (assert) {
 
 You can then re-enable the rules one by one as you fix the violations.
 
-The [ember-a11y-testing](https://github.com/ember-a11y/ember-a11y-testing)
-add-on provides other helpers, options and can even be used in development to
-detect these issues visually while you work,
-[so don't forget to read the docs!](https://github.com/ember-a11y/ember-a11y-testing)
+The [ember-a11y-testing](https://github.com/ember-a11y/ember-a11y-testing) add-on provides other helpers, options and can even be used in development to detect these issues visually while you work, [so don't forget to read the docs!](https://github.com/ember-a11y/ember-a11y-testing)
 
 ## A few accessibility considerations when implementing forms
 
-Back to our existing app case, we realized that using the test information and
-fixing identified issues as an effort in itself (independent from feature
-development) would take a lot of time and was going to be a tough sell. So we
-decided to start acting on these improvements gradually, and taking a more
-mindful approach when developing, trying not to introduce new issues and make
-improvements where possible. One of these opportunities presented itself when
-making improvements to a relatively simple page with a form.
+Back to our existing app case, we realized that using the test information and fixing identified issues as an effort in itself (independent from feature development) would take a lot of time and was going to be a tough sell. So we decided to start acting on these improvements gradually, and taking a more mindful approach when developing, trying not to introduce new issues and make improvements where possible. One of these opportunities presented itself when making improvements to a relatively simple page with a form.
 
-Here are some of the things we had to improve, and why you should keep them in
-mind.
+Here are some of the things we had to improve, and why you should keep them in mind.
 
 ### Labels, labels, labels
 
-This may seem obvious, but your inputs should have labels that indicate what
-information is required. The maybe not so obvious part is that labels should be
-linked to those inputs. As an example, the failing test above: the labels exist
-and are visually on top of the inputs, but in the HTML it is not clear the label
-belongs to that input.
+This may seem obvious, but your inputs should have labels that indicate what information is required. The maybe not so obvious part is that labels should be linked to those inputs. As an example, the failing test above: the labels exist and are visually on top of the inputs, but in the HTML it is not clear the label belongs to that input.
 
 ```html
 <div id="ember8" class="x-label ember-view">
@@ -206,11 +154,7 @@ belongs to that input.
 </div>
 ```
 
-There are different options to fix this: rearrange the HTML and have the label
-wrap the input, use the `for` attribute on the label to point to the input's
-`id`, using `aria-labeledby` on the input to point to the label's `id`, or if
-none of this is an option that works in your case, use `aria-label` on your
-input as shown below:
+There are different options to fix this: rearrange the HTML and have the label wrap the input, use the `for` attribute on the label to point to the input's `id`, using `aria-labeledby` on the input to point to the label's `id`, or if none of this is an option that works in your case, use `aria-label` on your input as shown below:
 
 ```html
 <input
@@ -224,35 +168,13 @@ Ideally, this should match the visual label to avoid any possible confusion.
 
 ### Labels and placeholders that make sense
 
-Missing labels are one of the possible violations that
-[ember-a11y-testing](https://github.com/ember-a11y/ember-a11y-testing) will
-detect for you, but having labels that make sense, on their own and in the
-context of the form and page, is something that only you can do, no automatic
-tools will do it for you (as far as I know). To understand why and also to have
-a better idea of how accessible your app is, I highly suggest using a screen
-reader to navigate your page and try to perform the action you want your users
-to perform (in this case, filling out a form and submitting it). I can assure
-you if you've never done it before, it will be mind-opening.
-
-Now, I know using a screen reader is not something everyone is acquainted with
-(I wasn't), you can find resources on how to start
-([like this one](http://uncaughtreferenceerror.com/a-crash-course-to-screenreaders-for-sighted-developers/))
-and if you use a Mac for development, you can use Voice Over which already comes
-installed. Just think of it as another tool that should be part of your
-development process.
+Missing labels are one of the possible violations that [ember-a11y-testing](https://github.com/ember-a11y/ember-a11y-testing) will detect for you, but having labels that make sense, on their own and in the context of the form and page, is something that only you can do, no automatic tools will do it for you (as far as I know). To understand why and also to have a better idea of how accessible your app is, I highly suggest using a screen reader to navigate your page and try to perform the action you want your users to perform (in this case, filling out a form and submitting it). I can assure you if you've never done it before, it will be mind-opening.
+
+Now, I know using a screen reader is not something everyone is acquainted with (I wasn't), you can find resources on how to start ([like this one](http://uncaughtreferenceerror.com/a-crash-course-to-screenreaders-for-sighted-developers/)) and if you use a Mac for development, you can use Voice Over which already comes installed. Just think of it as another tool that should be part of your development process.
 
 ### Groups of fields
 
-Another interesting case we came across was a group of inputs we had for
-entering a date. There were three inputs, for the day, month and year and they
-had the placeholders "DD", "MM", "YYYY". This may seem clear enough when looking
-at the whole page, but can be strange when you're using your keyboard to
-navigate and listen 'DD' as the whole explanation for the field. Even having
-labels such as 'Day', 'Month', 'Year' may not be sufficient context. In this
-case, we found that using `fieldset` was a good option. When you have a
-`fieldset` with a legend, the screen reader will include this information when
-giving you the information of an input it contains. This is what the screen
-reader says when the legend is present:
+Another interesting case we came across was a group of inputs we had for entering a date. There were three inputs, for the day, month and year and they had the placeholders "DD", "MM", "YYYY". This may seem clear enough when looking at the whole page, but can be strange when you're using your keyboard to navigate and listen 'DD' as the whole explanation for the field. Even having labels such as 'Day', 'Month', 'Year' may not be sufficient context. In this case, we found that using `fieldset` was a good option. When you have a `fieldset` with a legend, the screen reader will include this information when giving you the information of an input it contains. This is what the screen reader says when the legend is present:
 
 ![image of screen reader info for an input in a group with fieldset legend](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/group-with-fieldset-legend.png#@1024-2048)
 
@@ -260,47 +182,27 @@ Versus when it's not:
 
 ![image of screen reader info for an input in a group without a fieldset legend](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/group-without-fieldset-legend.png#@1024-2048)
 
-Another case where you should consider using a `fieldset` is whenever you have
-big forms that may have a logical grouping of fields, for instance, a group of
-inputs relating to an address inside a bigger form.
+Another case where you should consider using a `fieldset` is whenever you have big forms that may have a logical grouping of fields, for instance, a group of inputs relating to an address inside a bigger form.
 
 ![address form example](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/address-form.png#@900-1800)
 
-In such cases, it is better to use a `fieldset` with a `legend`,
-`<legend>Postal address</legend>`, instead of a heading element and a `div`
-grouping the fields.
+In such cases, it is better to use a `fieldset` with a `legend`, `<legend>Postal address</legend>`, instead of a heading element and a `div` grouping the fields.
 
 ### Tab index
 
-If you have a well-structured page and you're not rearranging input orders by
-CSS or JS, your best bet is to just rely on the browser and not set a tab index
-value on your inputs. This will ensure that when navigating with the keyboard
-you will move through the form as you would expect, in the order the elements
-are shown on the screen.
+If you have a well-structured page and you're not rearranging input orders by CSS or JS, your best bet is to just rely on the browser and not set a tab index value on your inputs. This will ensure that when navigating with the keyboard you will move through the form as you would expect, in the order the elements are shown on the screen.
 
-This is not always possible, and in some cases, you will have to resort to
-setting `tabindex` to make sure the keyboard navigation is consistent. Always
-make sure to test these cases manually, there's nothing more frustrating than
-having the inputs being skipped or having a jumping order when using only the
-keyboard to fill out forms.
+This is not always possible, and in some cases, you will have to resort to setting `tabindex` to make sure the keyboard navigation is consistent. Always make sure to test these cases manually, there's nothing more frustrating than having the inputs being skipped or having a jumping order when using only the keyboard to fill out forms.
 
 ### Visually indicating focus
 
-For those sighted users that rely on keyboard navigation, being able to
-determine visually when an input is focused is also important. When using native
-inputs with their default styles, the browser will take care of this for you.
-But we often rely on custom implementations of inputs to make them more visually
-appealing and forget to set specific styles for the focused state. This can
-create a scenario where you tab through the fields of your form and have no idea
-where exactly you're focused until you try to enter some content.
+For those sighted users that rely on keyboard navigation, being able to determine visually when an input is focused is also important. When using native inputs with their default styles, the browser will take care of this for you. But we often rely on custom implementations of inputs to make them more visually appealing and forget to set specific styles for the focused state. This can create a scenario where you tab through the fields of your form and have no idea where exactly you're focused until you try to enter some content.
 
-One scenario where this might happen is when the `outline` of elements is set to
-none. This is usually to avoid the browser's default outline.
+One scenario where this might happen is when the `outline` of elements is set to none. This is usually to avoid the browser's default outline.
 
 ![select-with-default-outline](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/select-with-default-outline.png#@700-1400)
 
-In this scenario, don't forget to set a style for the `:focus` state. For
-instance, the following can be achieved by the CSS below.
+In this scenario, don't forget to set a style for the `:focus` state. For instance, the following can be achieved by the CSS below.
 
 ![select-with-custom-outline](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/select-with-custom-outline.png#@700-1400)
 
@@ -310,16 +212,12 @@ select:focus {
 }
 ```
 
-Another scenario is when creating custom checkboxes, which usually involve not
-showing an actual checkbox. This may be a more complicated case, but if your
-custom implementation includes a hidden checkbox, you can use that to set the
-focused style. If not, you should reconsider your implementation.
+Another scenario is when creating custom checkboxes, which usually involve not showing an actual checkbox. This may be a more complicated case, but if your custom implementation includes a hidden checkbox, you can use that to set the focused style. If not, you should reconsider your implementation.
 
-For example, the following checkbox can be implemented with the code below,
-where the actual checkbox is hidden but is still used for the states.
+For example, the following checkbox can be implemented with the code below, where the actual checkbox is hidden but is still used for the states.
 
-| unfocused                                                                                                                                | checked                                                                                                                                | focused                                                                                                                              |
-| ---------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| unfocused | checked | focused |
+| --- | --- | --- |
 | ![custom-checkbox-unfocused](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/custom-checkbox-unfocused.png) | ![custom-checkbox-unfocused](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/custom-checkbox-checked.png) | ![custom-checkbox-focused](/assets/images/posts/2020-06-02-how-to-improve-the-accessibility-of-your-app/custom-checkbox-focused.png) |
 
 ```html
@@ -368,16 +266,6 @@ input[type="checkbox"].custom-checkbox:focus + *::before {
 
 ### Enter should submit your form
 
-Another thing you should always check is being able to submit the form using
-just the keyboard. Especially when developing an Ember app, you may implement
-forms that don't include an actual `form` element. Whether that's the case or
-not, at least the submit button should respond to `Enter`, and why not... even
-the other fields.
-
-This is by no means a comprehensive list, there are other accessibility
-considerations to have in mind when working with forms, such as making sure
-errors are detected by the screen reader, that custom components behave well
-when using just the keyboard, etc. The important thing to remember is you're not
-alone in this, there are [tools](https://github.com/ember-a11y/ember-a11y) and
-[resources](https://guides.emberjs.com/release/accessibility/components/) to
-help, and if you don't know where to start, start with the tests.
+Another thing you should always check is being able to submit the form using just the keyboard. Especially when developing an Ember app, you may implement forms that don't include an actual `form` element. Whether that's the case or not, at least the submit button should respond to `Enter`, and why not... even the other fields.
+
+This is by no means a comprehensive list, there are other accessibility considerations to have in mind when working with forms, such as making sure errors are detected by the screen reader, that custom components behave well when using just the keyboard, etc. The important thing to remember is you're not alone in this, there are [tools](https://github.com/ember-a11y/ember-a11y) and [resources](https://guides.emberjs.com/release/accessibility/components/) to help, and if you don't know where to start, start with the tests.
diff --git a/src/posts/2020-06-10-the-state-of-pwa-support-on-mobile-and-desktop-in-2020.md b/src/posts/2020-06-10-the-state-of-pwa-support-on-mobile-and-desktop-in-2020.md
index d3279a5a8e..cec69292fb 100644
--- a/src/posts/2020-06-10-the-state-of-pwa-support-on-mobile-and-desktop-in-2020.md
+++ b/src/posts/2020-06-10-the-state-of-pwa-support-on-mobile-and-desktop-in-2020.md
@@ -3,9 +3,7 @@ title: "The state of PWA support on mobile and desktop in 2020"
 authorHandle: arthurpoot
 tags: pwas
 bio: Digital Marketing Analyst and Business Developer
-description:
-  "Arthur Poot presents an overview of the possibilities that PWAs offer and the
-  level of support different browsers and OSs offer in 2020."
+description: "Arthur Poot presents an overview of the possibilities that PWAs offer and the level of support different browsers and OSs offer in 2020."
 og:
   image: /assets/images/posts/2020-06-10-the-state-of-pwa-support-on-mobile-and-desktop-in-2020/og-image.jpg
 tagline: |
@@ -18,92 +16,44 @@ tagline: |
 
 ### Which devices support PWAs?
 
-The answer to that question depends largely on your users' browsers and how you
-define what a PWA is. Almost all browsers in use support the basic functionality
-of PWAs: offline capability. 94.28% of people worldwide are using a browser
-version that supports offline apps through service workers (see
-[source](https://caniuse.com/#feat=serviceworkers)).
+The answer to that question depends largely on your users' browsers and how you define what a PWA is. Almost all browsers in use support the basic functionality of PWAs: offline capability. 94.28% of people worldwide are using a browser version that supports offline apps through service workers (see [source](https://caniuse.com/#feat=serviceworkers)).
 
 ### Which devices allow the installation of PWAs?
 
-A PWA only blends in with native apps downloaded from an app store if it has an
-app icon on the user’s home screen or desktop. Installing a PWA is now possible
-on almost any device, except for wearables and TVs.
+A PWA only blends in with native apps downloaded from an app store if it has an app icon on the user’s home screen or desktop. Installing a PWA is now possible on almost any device, except for wearables and TVs.
 
-On mobile devices, the user experience of installing PWAs varies widely. It
-ranges from downloading a PWA from Google's Play Store like a native app to
-opening the options menu and clicking _"Add to home screen"_ on iOS devices with
-a Safari browser.
+On mobile devices, the user experience of installing PWAs varies widely. It ranges from downloading a PWA from Google's Play Store like a native app to opening the options menu and clicking _"Add to home screen"_ on iOS devices with a Safari browser.
 
-Installing PWAs on desktop devices is widely supported as well, but not that
-common yet. Chrome on Windows and macOS now offers the possibility to install
-apps in a seamless way. On Windows and ChromeOS you can even download PWAs
-straight from the Microsoft Store and Play Store. Maybe these developments will
-increase the adoption of Progressive Web Apps on the desktop.
+Installing PWAs on desktop devices is widely supported as well, but not that common yet. Chrome on Windows and macOS now offers the possibility to install apps in a seamless way. On Windows and ChromeOS you can even download PWAs straight from the Microsoft Store and Play Store. Maybe these developments will increase the adoption of Progressive Web Apps on the desktop.
 
 ### What native hardware features are accessible by PWAs?
 
-Mobile devices are packed with sensors. There are accelerometers, gyroscopes to
-detect the direction and movement of the device, which could be handy for
-certain games or detecting screen rotation. Or GPS to provide more accurate
-location data than IP addresses. Android allows access to almost all its
-hardware through PWAs, from enabling and disabling bluetooth to GPS. On the
-other hand, Apple has been very protective of PWAs accessing hardware or app
-context. See the table above for the full list.
-
-On the desktop, native hardware features are mostly limited to the harddrive,
-camera, and microphone as well as geolocation. Like any browser or app, it
-neatly prompts the user to give or block access to the hardware. There just
-aren't that many native sensors in a desktop device, except hardware that plugs
-directly into the OS environment (e.g. bluetooth headphones, hard drives, or USB
-devices).
+Mobile devices are packed with sensors. There are accelerometers, gyroscopes to detect the direction and movement of the device, which could be handy for certain games or detecting screen rotation. Or GPS to provide more accurate location data than IP addresses. Android allows access to almost all its hardware through PWAs, from enabling and disabling bluetooth to GPS. On the other hand, Apple has been very protective of PWAs accessing hardware or app context. See the table above for the full list.
+
+On the desktop, native hardware features are mostly limited to the harddrive, camera, and microphone as well as geolocation. Like any browser or app, it neatly prompts the user to give or block access to the hardware. There just aren't that many native sensors in a desktop device, except hardware that plugs directly into the OS environment (e.g. bluetooth headphones, hard drives, or USB devices).
 
 ### What native software features are accessible by PWAs?
 
-For a PWA to be fully indistinguishable from a native app, it needs to blend in
-with the native user interactions offered by the operating software. For
-example, native push notifications, keyboard shortcuts, and gestures give that
-native feeling.
+For a PWA to be fully indistinguishable from a native app, it needs to blend in with the native user interactions offered by the operating software. For example, native push notifications, keyboard shortcuts, and gestures give that native feeling.
 
-On mobile devices most basic software features are now supported, such as the
-swipe back and switch-app gestures. Both Android and iOS also allow auto-filling
-credentials and easy payment options like Apple Pay and Android Pay.
+On mobile devices most basic software features are now supported, such as the swipe back and switch-app gestures. Both Android and iOS also allow auto-filling credentials and easy payment options like Apple Pay and Android Pay.
 
-In terms of native software features, desktops are limited to what a browser is
-allowed to do. Chrome supports push notifications on macOS, just like most
-browsers on Windows PCs.
+In terms of native software features, desktops are limited to what a browser is allowed to do. Chrome supports push notifications on macOS, just like most browsers on Windows PCs.
 
 ## Comparing PWA features
 
-The infographic above shows an overview of supported features, but before you
-start comparing it is good to answer the following questions:
+The infographic above shows an overview of supported features, but before you start comparing it is good to answer the following questions:
 
 ### Which OS does your target audience use?
 
-Each OS has different users. Designers, developers and the youth use macOS,
-while employees of many corporates spend most of their time on Windows PCs. iOS
-is not as big as Android. Only in the United States, more than 20% of the online
-population is on an iPhone or iPad. So it really depends on what audience you
-try to serve. The best way to find out on which device your users are is to look
-in Google Analytics under the Audience tab and then click Technology.
+Each OS has different users. Designers, developers and the youth use macOS, while employees of many corporates spend most of their time on Windows PCs. iOS is not as big as Android. Only in the United States, more than 20% of the online population is on an iPhone or iPad. So it really depends on what audience you try to serve. The best way to find out on which device your users are is to look in Google Analytics under the Audience tab and then click Technology.
 
 ### Do I really need this feature? If so, is there a workaround?
 
-The lack of support for push notifications on iOS devices is an often-heard
-argument for building native applications over PWAs. Only around 55% of all
-users allow push notifications at all though and the opening rate is only ca.
-50%. So only if you need instant actions of users with high frequency (like with
-messaging apps), you would need push notifications; but for the rest, text
-messages, email or in-app notifications are perfectly suitable replacements.
+The lack of support for push notifications on iOS devices is an often-heard argument for building native applications over PWAs. Only around 55% of all users allow push notifications at all though and the opening rate is only ca. 50%. So only if you need instant actions of users with high frequency (like with messaging apps), you would need push notifications; but for the rest, text messages, email or in-app notifications are perfectly suitable replacements.
 
 ## Conclusion
 
 **PWAs are not the future, they are ready today.**
 
-PWAs can do a lot more than just two years ago and the capabilities are still
-improving rapidly. Google, Apple, and Microsoft are prioritising PWA support
-more than ever. The basic features of PWAs, such as offline capacity and
-install-ability, are supported by almost all mobile and desktop devices in use
-today. Only some native features are still not supported, especially on iOS
-devices. However, do you really need those native features? If so, is there a
-workaround that is as useful or even better to achieve the same goal?
+PWAs can do a lot more than just two years ago and the capabilities are still improving rapidly. Google, Apple, and Microsoft are prioritising PWA support more than ever. The basic features of PWAs, such as offline capacity and install-ability, are supported by almost all mobile and desktop devices in use today. Only some native features are still not supported, especially on iOS devices. However, do you really need those native features? If so, is there a workaround that is as useful or even better to achieve the same goal?
diff --git a/src/posts/2020-06-17-failing-and-winning-at-planning-software-projects.md b/src/posts/2020-06-17-failing-and-winning-at-planning-software-projects.md
index 6561caf0a3..c365d14795 100644
--- a/src/posts/2020-06-17-failing-and-winning-at-planning-software-projects.md
+++ b/src/posts/2020-06-17-failing-and-winning-at-planning-software-projects.md
@@ -3,9 +3,7 @@ title: "Failing (and winning) at planning software projects"
 authorHandle: marcoow
 tags: process
 bio: "Founder and Managing Director of Mainmatter"
-description:
-  "Marco Otte-Witte gives detailed advice on planning software projects and
-  scoping as well as preparing work in an iterative process."
+description: "Marco Otte-Witte gives detailed advice on planning software projects and scoping as well as preparing work in an iterative process."
 og:
   image: /assets/images/posts/2020-06-17-failing-and-winning-at-planning-software-projects/og-image.jpg
 tagline: |
@@ -14,341 +12,106 @@ tagline: |
 
 ## Planning on the Macro Level
 
-When it comes to planning software projects on the macro level, there's two
-extremes – trying to plan everything up-front or accepting the impossibility of
-getting that right and not bothering to plan anything at all. While most teams
-will find themselves somewhere in the middle between those two, it's still worth
-reviewing them in a bit more detail.
+When it comes to planning software projects on the macro level, there's two extremes – trying to plan everything up-front or accepting the impossibility of getting that right and not bothering to plan anything at all. While most teams will find themselves somewhere in the middle between those two, it's still worth reviewing them in a bit more detail.
 
 ### Over-planning
 
-Historically, in a [waterfall](https://en.wikipedia.org/wiki/Waterfall_model)
-based world, over-planning was widely used. The idea behind this approach is to
-plan out the entirety of the project up-front in excessive detail, project that
-plan on to a timeline and then execute it. Teams practicing over-planning would
-write long and detailed specifications that describe all aspects of the project.
-They would then break that specification down into a backlog of smaller tasks,
-estimate that backlog somehow and extrapolate how long the project will take;
-eventually leading to statements like _"We can build the social network for
-elephants as described in the 587 page long specification in 67 weeks and it
-will cost a total of 1.34 Mio. €"_.
-
-As we all know now this almost never works as planned, deadlines are missed and
-budgets overrun –
-[as countless examples show](https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects).
+Historically, in a [waterfall](https://en.wikipedia.org/wiki/Waterfall_model) based world, over-planning was widely used. The idea behind this approach is to plan out the entirety of the project up-front in excessive detail, project that plan on to a timeline and then execute it. Teams practicing over-planning would write long and detailed specifications that describe all aspects of the project. They would then break that specification down into a backlog of smaller tasks, estimate that backlog somehow and extrapolate how long the project will take; eventually leading to statements like _"We can build the social network for elephants as described in the 587 page long specification in 67 weeks and it will cost a total of 1.34 Mio. €"_.
+
+As we all know now this almost never works as planned, deadlines are missed and budgets overrun – [as countless examples show](https://en.wikipedia.org/wiki/List_of_failed_and_overbudget_custom_software_projects).
 
 ### Under-planning
 
-The opposite of that approach is doing only very little or no up-front planning
-at all and just running off. While that removes a lot of pressure from
-development teams (designers and engineers in particular), other stakeholders
-that have legitimate needs with regards to predictability and insight into a
-project's progress are left in the cold. The marketing team will not know when
-to book the billboards in the local zoo and the product experts can't set up the
-user testing session with a group of sample elephants as they don't know what
-features they will be able to test when or whether there will be a coherent set
-of functionality that even makes sense as a unit at any time at all.
+The opposite of that approach is doing only very little or no up-front planning at all and just running off. While that removes a lot of pressure from development teams (designers and engineers in particular), other stakeholders that have legitimate needs with regards to predictability and insight into a project's progress are left in the cold. The marketing team will not know when to book the billboards in the local zoo and the product experts can't set up the user testing session with a group of sample elephants as they don't know what features they will be able to test when or whether there will be a coherent set of functionality that even makes sense as a unit at any time at all.
 
 ### Failing agilely
 
-No teams (that I have seen at least 🤞) in reality strictly practice either of
-these two extremes. The classic waterfall model fortunately is a thing of the
-past now and the shortcomings of having a team just run off with no plan are too
-obvious for anyone to be brave (or naive) enough to try it. In fact, developing
-products iteratively following an _"agile"_ process (whatever precisely that
-term might mean for any particular team) is a widely accepted technique now.
-That way, the scope and thus complexity and risk is significantly reduced per
-iteration (often referred to as
-["sprints"](<https://en.wikipedia.org/wiki/Scrum_(software_development)#Sprint>)
-– which I think is a horrible term but that's a blog post of its own right) into
-something much more manageable. All planning is then based on estimates of
-relatively small tasks (using e.g.
-[story points](https://en.wikipedia.org/wiki/Planning_poker)) and productivity
-measures based on those estimates (the team's
-["velocity"](<https://en.wikipedia.org/wiki/Velocity_(software_development)>)).
-
-In reality however, adopting an agile, iterative process (whether that's
-[Scrum](<https://en.wikipedia.org/wiki/Scrum_(software_development)>), a team's
-own interpretation of it or something completely different) will not magically
-solve all of the above problems. Teams will still face budget overruns and not
-be able to give reliable estimates even given the short time horizon of a two
-week iteration. Unforeseen and unplanned-for complexities and challenges will
-still be uncovered only after a task was started, many tasks will span multiple
-sprints unexpectedly and already completed features will regularly have to be
-revisited and changed even before launching an MVP.
-
-Having moved planning from the macro level where it did reside with the classic
-waterfall approach to the micro level of an iteration, that level is also where
-the problems were moved to.
+No teams (that I have seen at least 🤞) in reality strictly practice either of these two extremes. The classic waterfall model fortunately is a thing of the past now and the shortcomings of having a team just run off with no plan are too obvious for anyone to be brave (or naive) enough to try it. In fact, developing products iteratively following an _"agile"_ process (whatever precisely that term might mean for any particular team) is a widely accepted technique now. That way, the scope and thus complexity and risk is significantly reduced per iteration (often referred to as ["sprints"](<https://en.wikipedia.org/wiki/Scrum_(software_development)#Sprint>) – which I think is a horrible term but that's a blog post of its own right) into something much more manageable. All planning is then based on estimates of relatively small tasks (using e.g. [story points](https://en.wikipedia.org/wiki/Planning_poker)) and productivity measures based on those estimates (the team's ["velocity"](<https://en.wikipedia.org/wiki/Velocity_(software_development)>)).
+
+In reality however, adopting an agile, iterative process (whether that's [Scrum](<https://en.wikipedia.org/wiki/Scrum_(software_development)>), a team's own interpretation of it or something completely different) will not magically solve all of the above problems. Teams will still face budget overruns and not be able to give reliable estimates even given the short time horizon of a two week iteration. Unforeseen and unplanned-for complexities and challenges will still be uncovered only after a task was started, many tasks will span multiple sprints unexpectedly and already completed features will regularly have to be revisited and changed even before launching an MVP.
+
+Having moved planning from the macro level where it did reside with the classic waterfall approach to the micro level of an iteration, that level is also where the problems were moved to.
 
 ## Planning on the Micro Level
 
-Planning on the micro level of an iteration means scoping, bundling and
-estimating concrete, actionable units of work. There are countless names for
-these units which depend on the particular process or tool in use but in reality
-it doesn't matter whether you call them issues, (user) stories or TODOs, whether
-you organize them in trees with several levels of subtasks and/or overarching
-epics – what they are is tasks that one or several team members can work on and
-complete, ideally in relatively short time (like a few days at most). A bundle
-of tasks defines the scope of an iteration which is what we're planning for on
-the micro level.
+Planning on the micro level of an iteration means scoping, bundling and estimating concrete, actionable units of work. There are countless names for these units which depend on the particular process or tool in use but in reality it doesn't matter whether you call them issues, (user) stories or TODOs, whether you organize them in trees with several levels of subtasks and/or overarching epics – what they are is tasks that one or several team members can work on and complete, ideally in relatively short time (like a few days at most). A bundle of tasks defines the scope of an iteration which is what we're planning for on the micro level.
 
 ### Isn't a plan just a guess anyway?
 
-There's a very popular quote from the team behind
-[Basecamp](https://basecamp.com), a bootstrapped company that built a hugely
-successful project management SaaS with the same name:
+There's a very popular quote from the team behind [Basecamp](https://basecamp.com), a bootstrapped company that built a hugely successful project management SaaS with the same name:
 
 [_"Planning is guessing."_](https://m.signalvnoise.com/planning-is-guessing/)
 
-Basecamp explain the idea in more detail in their bestselling book
-[_"Rework"_](https://basecamp.com/books/rework). The quote is both great and
-widely misunderstood. What it means is that anything beyond a pretty small scope
-is inherently not plannable and any plan anyone makes up for it, is essentially
-nothing more than a guess. As explained above that is very much true at the
-macro level where scope and complexity are way too big for anyone to be able to
-fully grasp. What the quote does not mean however, is that you can never prepare
-and pre–assess any work when the scope is limited – which is the fact on the
-micro level of an iteration.
-
-Yet, many project teams use _"planning is guessing"_ as an excuse to refuse
-doing any thorough up-front analysis or preparation of tasks at all. Even if
-teams spend time on preparing work before starting it, that preparation is often
-superficial only, leaving a lot of uncertainty and risk to be uncovered only
-after work on a task has started. Understanding any task fully and in its
-entirety does of course require actively working on and in fact completing the
-task. It is however very well possible to analyze tasks to uncover hidden
-complexity, dependencies and implications – not only from an engineering
-perspective but also from the perspectives of other stakeholders like design,
-product, marketing etc.
-
-Thorough analysis and preparation of tasks will help in understanding the scope
-of the tasks, identifying dependent work that needs to be done before or in
-consequence or weighing alternative implementation options against each other as
-well as against other priorities. All that reduces the uncertainty that is
-associated with a task and even while you won't be able to fully eliminate all
-uncertainty, eliminating a big part or maybe most of it significantly improves
-the reliability of estimates and minimizes unplanned work that is usually
-necessary when running into unforeseen complications only after work has
-started.
+Basecamp explain the idea in more detail in their bestselling book [_"Rework"_](https://basecamp.com/books/rework). The quote is both great and widely misunderstood. What it means is that anything beyond a pretty small scope is inherently not plannable and any plan anyone makes up for it, is essentially nothing more than a guess. As explained above that is very much true at the macro level where scope and complexity are way too big for anyone to be able to fully grasp. What the quote does not mean however, is that you can never prepare and pre–assess any work when the scope is limited – which is the fact on the micro level of an iteration.
+
+Yet, many project teams use _"planning is guessing"_ as an excuse to refuse doing any thorough up-front analysis or preparation of tasks at all. Even if teams spend time on preparing work before starting it, that preparation is often superficial only, leaving a lot of uncertainty and risk to be uncovered only after work on a task has started. Understanding any task fully and in its entirety does of course require actively working on and in fact completing the task. It is however very well possible to analyze tasks to uncover hidden complexity, dependencies and implications – not only from an engineering perspective but also from the perspectives of other stakeholders like design, product, marketing etc.
+
+Thorough analysis and preparation of tasks will help in understanding the scope of the tasks, identifying dependent work that needs to be done before or in consequence or weighing alternative implementation options against each other as well as against other priorities. All that reduces the uncertainty that is associated with a task and even while you won't be able to fully eliminate all uncertainty, eliminating a big part or maybe most of it significantly improves the reliability of estimates and minimizes unplanned work that is usually necessary when running into unforeseen complications only after work has started.
 
 ## Winning at Planning through Preparation
 
-In order to improve planning on the micro level, it is essential to conduct
-thorough preparation. I will present four key techniques that are essential for
-effective preparation of tasks and that Mainmatter has been practicing
-successfully for years.
+In order to improve planning on the micro level, it is essential to conduct thorough preparation. I will present four key techniques that are essential for effective preparation of tasks and that Mainmatter has been practicing successfully for years.
 
 ### 1. The source of tasks
 
-First, let's look at where the work that a product team conducts typically
-originates from. In most cases, there are more or less only two sources –
-feature stories that are defined by the product team and technical changes like
-refactorings driven by the engineering team. Ideally both kinds of work are
-equally represented as tasks although in many cases that is not the case for
-purely technical work. Since that work happens anyway though, not representing
-it as individual tasks is a big mistake and leads to part of the work that is
-happening not being visible to all stakeholders with all of the negative
-consequences that come with that.
-
-So let's assume **all** work that is happening in a project is equally
-represented as tasks. Still, in many cases stakeholders would only define their
-own tasks without receiving much input from each other. Each stakeholder then
-pushes for their tasks to be planned for in a particular iteration. That is not
-an effective way of collaborating though and generally not in the best interest
-of the success of the project. A successful project needs to take all of the
-stakeholder's individual perspectives and priorities into account. After all,
-neither focusing on features only and giving up technical aspects like long-term
-maintainability and extensibility of the product, nor refactoring the code to
-perfection but only shipping too little too late, will result in a success for
-the business.
+First, let's look at where the work that a product team conducts typically originates from. In most cases, there are more or less only two sources – feature stories that are defined by the product team and technical changes like refactorings driven by the engineering team. Ideally both kinds of work are equally represented as tasks although in many cases that is not the case for purely technical work. Since that work happens anyway though, not representing it as individual tasks is a big mistake and leads to part of the work that is happening not being visible to all stakeholders with all of the negative consequences that come with that.
+
+So let's assume **all** work that is happening in a project is equally represented as tasks. Still, in many cases stakeholders would only define their own tasks without receiving much input from each other. Each stakeholder then pushes for their tasks to be planned for in a particular iteration. That is not an effective way of collaborating though and generally not in the best interest of the success of the project. A successful project needs to take all of the stakeholder's individual perspectives and priorities into account. After all, neither focusing on features only and giving up technical aspects like long-term maintainability and extensibility of the product, nor refactoring the code to perfection but only shipping too little too late, will result in a success for the business.
 
 #### Communication 💬 and Collaboration 🤝
 
-Successful teams communicate openly and directly and collaborate closely. While
-this might read like an obvious statement, in reality there is often lots of
-room for improvement. Many teams build walls between stakeholders when they
-really would all have to collaborate – from product experts to engineering and
-design but also marketing, finance and potentially others. That collaboration
-starts with agreeing what work should be done in which order and to what level
-of depth. Having a collaborative process for this in place makes the entire
-development process more effective by eliminating unnecessary complexity or
-preventing longer-term decline of a team's velocity.
-
-In many cases for example, there will be different ways to implement a
-particular feature that the product experts want to add with drastically
-different levels of associated development complexity. Often, it might not
-matter much from a product perspective which of these alternatives is chosen and
-finding that out early can save the designers and engineers a substantial amount
-of time and effort. In other cases, the engineering team might see the necessity
-for particular refactorings but there might be conflicting commitments that the
-marketing team has to fulfill which justify delaying the refactoring to a later
-iteration. In other cases yet, a refactoring might have substantial positive
-consequences for the product also from a user's perspective which would lead to
-wide support of the undertaking from all stakeholders. Uncovering all these
-situations is only possible by communicating and collaborating, not only when
-conducting work but already when scoping and planning it. Yet again, as obvious
-as this might seem, many teams struggle hard with the consequences of not being
-as open.
+Successful teams communicate openly and directly and collaborate closely. While this might read like an obvious statement, in reality there is often lots of room for improvement. Many teams build walls between stakeholders when they really would all have to collaborate – from product experts to engineering and design but also marketing, finance and potentially others. That collaboration starts with agreeing what work should be done in which order and to what level of depth. Having a collaborative process for this in place makes the entire development process more effective by eliminating unnecessary complexity or preventing longer-term decline of a team's velocity.
+
+In many cases for example, there will be different ways to implement a particular feature that the product experts want to add with drastically different levels of associated development complexity. Often, it might not matter much from a product perspective which of these alternatives is chosen and finding that out early can save the designers and engineers a substantial amount of time and effort. In other cases, the engineering team might see the necessity for particular refactorings but there might be conflicting commitments that the marketing team has to fulfill which justify delaying the refactoring to a later iteration. In other cases yet, a refactoring might have substantial positive consequences for the product also from a user's perspective which would lead to wide support of the undertaking from all stakeholders. Uncovering all these situations is only possible by communicating and collaborating, not only when conducting work but already when scoping and planning it. Yet again, as obvious as this might seem, many teams struggle hard with the consequences of not being as open.
 
 #### Rotating Responsibility
 
-In our projects, we leverage an iteration lead role. The iteration lead is
-responsible for identifying, scoping and preparing all work that is planned to
-happen in a particular iteration. They will collect input from all stakeholders,
-prepare proper tasks for each request (more on what a proper task is below),
-prioritize tasks and present the result to the product team before kicking off
-an iteration. Of course, the iteration lead cannot have all of the detailed
-knowledge that each stakeholder has about their field and they are not supposed
-to – they will reach out to the respective experts, bring people together and
-make sure communication happens.
+In our projects, we leverage an iteration lead role. The iteration lead is responsible for identifying, scoping and preparing all work that is planned to happen in a particular iteration. They will collect input from all stakeholders, prepare proper tasks for each request (more on what a proper task is below), prioritize tasks and present the result to the product team before kicking off an iteration. Of course, the iteration lead cannot have all of the detailed knowledge that each stakeholder has about their field and they are not supposed to – they will reach out to the respective experts, bring people together and make sure communication happens.
 
 ![The Iteration Lead role](/assets/images/posts/2020-06-17-failing-and-winning-at-planning-software-projects/iteration-lead.png#@1000-2000)
 
-The iteration lead role is not fixed to a particular member of the product team
-but set up as a rotating role among the **entire** team instead – every other
-iteration the role moves on to a new team member so that every product or
-marketing expert, designer or engineer will assume it periodically. Rotating the
-role among the entire team is a great way to ensure people get to understand and
-appreciate each stakeholder's perspective and are not stuck with their own point
-of view only. That appreciation is not only beneficial for the team spirit but
-also significantly improves collaboration in our experience. We do not even work
-with project managers at all and depend on the iteration lead role instead. In
-fact, we see the project manager role – at least in its classic shape as someone
-directing the product team – as an organizational anti-pattern that is most
-often necessary only as a consequence of teams that are really dysfunctional at
-their core.
+The iteration lead role is not fixed to a particular member of the product team but set up as a rotating role among the **entire** team instead – every other iteration the role moves on to a new team member so that every product or marketing expert, designer or engineer will assume it periodically. Rotating the role among the entire team is a great way to ensure people get to understand and appreciate each stakeholder's perspective and are not stuck with their own point of view only. That appreciation is not only beneficial for the team spirit but also significantly improves collaboration in our experience. We do not even work with project managers at all and depend on the iteration lead role instead. In fact, we see the project manager role – at least in its classic shape as someone directing the product team – as an organizational anti-pattern that is most often necessary only as a consequence of teams that are really dysfunctional at their core.
 
 ### 2. Focussing on the present
 
-As described above, many teams will prepare and maintain an extensive backlog
-filled with all tasks that anyone ever brought up or that are expected to
-eventually be required for a particular project. What seems like a good idea in
-order to have a more complete understanding of the entirety of a project, in an
-iterative process the only work that ever matters is what the team is currently
-doing and what is being prepared and planned for the next iteration. Everything
-else can safely be ignored as it is completely unknown in which way a particular
-task will be addressed in the future or whether it will be at all. Everyone has
-seen projects with huge backlogs that seem to imply lots and lots of work that
-still needs to be done while everyone knows that 90% of the tasks will likely
-never be taken on and 75% of them are already outdated anyway (these are made-up
-numbers only backed by my personal experience ✌️).
-
-Actively keeping a backlog is most often simply a waste of time. That is not
-only the case for feature tasks but also for bug reports – a bug that has not
-been addressed for the past six months is unlikely to be addressed in the coming
-six months. At the same time it also is unlikely to be really relevant to anyone
-and thus unlikely to ever be solved at all (unless it is solved automatically as
-a consequence of a change to the underlying functionality maybe).
+As described above, many teams will prepare and maintain an extensive backlog filled with all tasks that anyone ever brought up or that are expected to eventually be required for a particular project. What seems like a good idea in order to have a more complete understanding of the entirety of a project, in an iterative process the only work that ever matters is what the team is currently doing and what is being prepared and planned for the next iteration. Everything else can safely be ignored as it is completely unknown in which way a particular task will be addressed in the future or whether it will be at all. Everyone has seen projects with huge backlogs that seem to imply lots and lots of work that still needs to be done while everyone knows that 90% of the tasks will likely never be taken on and 75% of them are already outdated anyway (these are made-up numbers only backed by my personal experience ✌️).
+
+Actively keeping a backlog is most often simply a waste of time. That is not only the case for feature tasks but also for bug reports – a bug that has not been addressed for the past six months is unlikely to be addressed in the coming six months. At the same time it also is unlikely to be really relevant to anyone and thus unlikely to ever be solved at all (unless it is solved automatically as a consequence of a change to the underlying functionality maybe).
 
 ### 3. Scoping and analysis
 
-Once work has been sourced from the project stakeholders, it needs to be well
-understood and scoped. This is a critical step in order to fully understand the
-tasks in their entirety and prevent the team from running into unforeseen
-problems once the work has started. Of course, it is not possible to always
-prevent all problems that might occur at a later point altogether but the more
-that is uncovered and addressed earlier rather than later, the smoother
-completing each task will go.
-
-First, all of a task's preconditions must be met before it can be worked on at
-all. That can include designs being ready or user tests having been conducted
-and analysed. It might also mean contracts with external providers have been
-signed or marketing campaigns have been booked. Just as important as the
-preconditions are a task's consequences which can be technical ones but also
-related to features or design – a technical change might require a change to the
-deployment and monitoring systems; changing feature A might also require
-adapting feature B in an unrelated part of the application so that both features
-make sense together; switching to a new design for forms might have consequences
-for the application's accessibility and marketing materials outside of the
-application. Most of such consequences can usually be identified and planned for
-up-front – in many cases even with relatively little effort.
-
-Lastly, fully understanding a task should result in the ability to break it down
-into a series of steps that need to be performed in order to complete it. These
-steps do not need to be extremely fine-grained (_"change line x in file y to
-z"_) or be limited to what the engineering team needs to do. Instead, they
-should reflect on a high level **all** changes that need to be made to all
-aspects of the application and related systems to complete the task. Sometimes
-it turns out that for a particular task it is not possible yet to identify and
-clearly describe these steps. In these cases, it is recommendable to conduct a
-spike and prepare a prototype for the aspect that is yet unclear first in order
-to understand it better. While this technique comes from the engineering world,
-it is not limited to it and is just as valuable for designers and product
-experts as well (e.g. for validating particular feature flows or design
-approaches with real users before implementing it).
-
-Some teams are adopting full-on
-[RFC processes](https://en.wikipedia.org/wiki/Request_for_Comments) for scoping
-and defining work like this. In an RFC process, someone or a group of people
-would write a document explaining an intended change in relative detail, then
-ask all affected stakeholders (or anyone really) for feedback until consensus is
-reached and the RFC is ready to be implemented. While that can come with
-formalities and process overhead that might not always be justified, it is
-generally a good approach and ensures the above points are addressed. Generally,
-an RFC process is likely the better suited the wider the topic of a task is and
-the larger the team size is. For smaller teams, it might be sufficient to
-collaboratively edit a task in the respective tool directly.
+Once work has been sourced from the project stakeholders, it needs to be well understood and scoped. This is a critical step in order to fully understand the tasks in their entirety and prevent the team from running into unforeseen problems once the work has started. Of course, it is not possible to always prevent all problems that might occur at a later point altogether but the more that is uncovered and addressed earlier rather than later, the smoother completing each task will go.
+
+First, all of a task's preconditions must be met before it can be worked on at all. That can include designs being ready or user tests having been conducted and analysed. It might also mean contracts with external providers have been signed or marketing campaigns have been booked. Just as important as the preconditions are a task's consequences which can be technical ones but also related to features or design – a technical change might require a change to the deployment and monitoring systems; changing feature A might also require adapting feature B in an unrelated part of the application so that both features make sense together; switching to a new design for forms might have consequences for the application's accessibility and marketing materials outside of the application. Most of such consequences can usually be identified and planned for up-front – in many cases even with relatively little effort.
+
+Lastly, fully understanding a task should result in the ability to break it down into a series of steps that need to be performed in order to complete it. These steps do not need to be extremely fine-grained (_"change line x in file y to z"_) or be limited to what the engineering team needs to do. Instead, they should reflect on a high level **all** changes that need to be made to all aspects of the application and related systems to complete the task. Sometimes it turns out that for a particular task it is not possible yet to identify and clearly describe these steps. In these cases, it is recommendable to conduct a spike and prepare a prototype for the aspect that is yet unclear first in order to understand it better. While this technique comes from the engineering world, it is not limited to it and is just as valuable for designers and product experts as well (e.g. for validating particular feature flows or design approaches with real users before implementing it).
+
+Some teams are adopting full-on [RFC processes](https://en.wikipedia.org/wiki/Request_for_Comments) for scoping and defining work like this. In an RFC process, someone or a group of people would write a document explaining an intended change in relative detail, then ask all affected stakeholders (or anyone really) for feedback until consensus is reached and the RFC is ready to be implemented. While that can come with formalities and process overhead that might not always be justified, it is generally a good approach and ensures the above points are addressed. Generally, an RFC process is likely the better suited the wider the topic of a task is and the larger the team size is. For smaller teams, it might be sufficient to collaboratively edit a task in the respective tool directly.
 
 ### 4. Writing it all down
 
-The final step for proper preparation of tasks is to write all of the
-information acquired in the previous steps down in the tool of choice. As stated
-above, it does not matter what tool that is – good tasks share some common
-characteristics that are independent of any particular tool:
-
-- They describe what is to be done and why, potentially accompanied by
-  screenshots, mockups/sketches or other visuals that help understand the
-  desired outcome; it is also beneficial to add a summary of the task's history,
-  covering previous related changes or alternative approaches that have been
-  ruled out in the process of scoping the task and also providing the reasons
-  for those decisions.
-- They include reproduction steps if the task describes a bug; ideally those are
-  visualized with a screen recording or other media.
-- They list concrete steps that must be taken in order to complete the task (see
-  [_"3. Scoping and analysis"_](#3-scoping-and-analysis) above).
-- They include all necessary materials that are needed for the task; this could
-  be visual assets, links to online documentation for third party libraries or
-  APIs or contact details for external parties involved in an issue etc.
-- They reference any open questions that need to be answered, or risks that have
-  been identified but could not be resolved up-front and that might prevent the
-  task from being completed.
-- They are a discrete unit of work; tasks should only contain related
-  requirements and ideally not represent more than a few days of work - larger
-  tasks can often be broken down into multiple smaller ones, possibly even
-  allowing for work to happen simultaneously.
+The final step for proper preparation of tasks is to write all of the information acquired in the previous steps down in the tool of choice. As stated above, it does not matter what tool that is – good tasks share some common characteristics that are independent of any particular tool:
+
+- They describe what is to be done and why, potentially accompanied by screenshots, mockups/sketches or other visuals that help understand the desired outcome; it is also beneficial to add a summary of the task's history, covering previous related changes or alternative approaches that have been ruled out in the process of scoping the task and also providing the reasons for those decisions.
+- They include reproduction steps if the task describes a bug; ideally those are visualized with a screen recording or other media.
+- They list concrete steps that must be taken in order to complete the task (see [_"3. Scoping and analysis"_](#3-scoping-and-analysis) above).
+- They include all necessary materials that are needed for the task; this could be visual assets, links to online documentation for third party libraries or APIs or contact details for external parties involved in an issue etc.
+- They reference any open questions that need to be answered, or risks that have been identified but could not be resolved up-front and that might prevent the task from being completed.
+- They are a discrete unit of work; tasks should only contain related requirements and ideally not represent more than a few days of work - larger tasks can often be broken down into multiple smaller ones, possibly even allowing for work to happen simultaneously.
 
 ![A well prepared task](/assets/images/posts/2020-06-17-failing-and-winning-at-planning-software-projects/issue.png#@1000-2000)
 
-A well prepared task would enable any member of the product team that is an
-expert in the respective field to take on and complete the task. However, tasks
-are not only written for the team member that will work on them but also for any
-other stakeholder that has an interest in the project and needs to know what is
-going on at any time – be it at the time the task is actively planned or being
-worked on or later when trying to understand why something was done
-retroactively, what the intentions and considerations were at the time etc.
+A well prepared task would enable any member of the product team that is an expert in the respective field to take on and complete the task. However, tasks are not only written for the team member that will work on them but also for any other stakeholder that has an interest in the project and needs to know what is going on at any time – be it at the time the task is actively planned or being worked on or later when trying to understand why something was done retroactively, what the intentions and considerations were at the time etc.
 
 ## Conclusion
 
-Teams are not successful because they adopt a particular process (and
-potentially even get themselves certified) or adopt the latest and greatest
-project management tools. Success is mostly enabled through relatively simple
-values:
-
-- open and direct communication as well as close collaboration among **all**
-  stakeholders
-- identifying and resolving as much uncertainty and uncovering as much hidden
-  complexity as possible on the task level **before** work on the task starts
-- **ignoring** all work that is not known to be relevant at the time an
-  iteration is planned and executed
+Teams are not successful because they adopt a particular process (and potentially even get themselves certified) or adopt the latest and greatest project management tools. Success is mostly enabled through relatively simple values:
+
+- open and direct communication as well as close collaboration among **all** stakeholders
+- identifying and resolving as much uncertainty and uncovering as much hidden complexity as possible on the task level **before** work on the task starts
+- **ignoring** all work that is not known to be relevant at the time an iteration is planned and executed
 - being **detailed** (potentially overly detailed) when describing tasks
 
-Doing all this thoroughly requires a bit of extra time (the iteration lead would
-easily be occupied a few days per week with that in addition to the time the
-respective experts for each topic invest to give their input). However, thanks
-to much improved effectiveness as well as the benefits of improved certainty and
-planability, that time pays off manyfold.
+Doing all this thoroughly requires a bit of extra time (the iteration lead would easily be occupied a few days per week with that in addition to the time the respective experts for each topic invest to give their input). However, thanks to much improved effectiveness as well as the benefits of improved certainty and planability, that time pays off manyfold.
 
-We have written all of the values and techniques introduced in this post in much
-more detail in our [playbook](/playbook) and welcome everyone to adapt these
-patterns and share their experience and feedback with us.
+We have written all of the values and techniques introduced in this post in much more detail in our [playbook](/playbook) and welcome everyone to adapt these patterns and share their experience and feedback with us.
diff --git a/src/posts/2020-06-25-writing-rust-nifs-for-elixir-with-rustler.md b/src/posts/2020-06-25-writing-rust-nifs-for-elixir-with-rustler.md
index 9b734f10bb..a6558f404a 100644
--- a/src/posts/2020-06-25-writing-rust-nifs-for-elixir-with-rustler.md
+++ b/src/posts/2020-06-25-writing-rust-nifs-for-elixir-with-rustler.md
@@ -3,37 +3,22 @@ title: Writing Rust NIFs for Elixir With Rustler
 authorHandle: niklas_long
 tags: [elixir, rust]
 bio: "Backend Engineer, author of Breethe API"
-description:
-  "Niklas Long describes the upcoming changes to Rustler and how it simplifies
-  implementing NIFs."
+description: "Niklas Long describes the upcoming changes to Rustler and how it simplifies implementing NIFs."
 og:
   image: /assets/images/posts/2020-06-25-writing-rust-nifs-for-elixir-with-rustler/og-image.jpg
 tagline: |
   <p>A Native Implemented Function is implemented in C (or Rust when using <a href="https://github.com/rusterlium/rustler">Rustler</a>) and can be called from Elixir or Erlang just like any other function. It's the simplest and fastest way to run native code from Erlang but it does come with a caveat: a crash in a NIF can bring down the whole BEAM. This makes Rust a safer option than C for implementing NIFs as its type system and ownership model guarantee memory and thread-safety.</p>
 ---
 
-Rustler is a fantastic project built to make writing Rust NIFs a simple process;
-and the upcoming v0.22 release will provide a much cleaner syntax to do so. The
-library handles encoding and decoding Rust values into Erlang terms, catches
-Rust panics before they unwind to C and _should_ make it impossible to crash the
-BEAM from a Rust NIF.
+Rustler is a fantastic project built to make writing Rust NIFs a simple process; and the upcoming v0.22 release will provide a much cleaner syntax to do so. The library handles encoding and decoding Rust values into Erlang terms, catches Rust panics before they unwind to C and _should_ make it impossible to crash the BEAM from a Rust NIF.
 
 ## Getting started with Rustler
 
-One of my first forays into Rust-implemented NIFs was while building a
-micro-library providing Base64 encoding and decoding, creatively named
-[base64](https://github.com/niklaslong/base64). It's utterly pointless as that
-functionality comes built-in to Elixir but I wanted to start with something
-simple. On the plus side, this meant I could easily compare the performance of
-the NIF version to the Elixir implementation which can be found in the
-[`Base` module](https://hexdocs.pm/elixir/Base.html).
+One of my first forays into Rust-implemented NIFs was while building a micro-library providing Base64 encoding and decoding, creatively named [base64](https://github.com/niklaslong/base64). It's utterly pointless as that functionality comes built-in to Elixir but I wanted to start with something simple. On the plus side, this meant I could easily compare the performance of the NIF version to the Elixir implementation which can be found in the [`Base` module](https://hexdocs.pm/elixir/Base.html).
 
-The library consists of two functions: `encode/2` and `decode/2` and it's using
-[rust-base64](https://github.com/marshallpierce/rust-base64) to do the heavy
-lifting in the NIFs. Let's walk through how this all works.
+The library consists of two functions: `encode/2` and `decode/2` and it's using [rust-base64](https://github.com/marshallpierce/rust-base64) to do the heavy lifting in the NIFs. Let's walk through how this all works.
 
-To get started, we need a new mix project with rustler installed as a
-dependency.
+To get started, we need a new mix project with rustler installed as a dependency.
 
 ```bash
 mix new base64
@@ -43,8 +28,7 @@ mix rustler.new
 # follow rustler instructions
 ```
 
-Let's explore the project's resulting structure (I've left out the usual Elixir
-files and directories and focused on `lib` and `native`):
+Let's explore the project's resulting structure (I've left out the usual Elixir files and directories and focused on `lib` and `native`):
 
 ```
 .
@@ -60,17 +44,11 @@ files and directories and focused on `lib` and `native`):
 ```
 
 - `lib` will contain Elixir code (like any standard mix project).
-- `base64.ex` will contain the stubs to our NIFs. This is the Elixir module the
-  NIF module will be registered to.
-- `native` will be home to the Rust code. In fact, a cargo package has been
-  created within this directory (in this case named `base64_nif`).
+- `base64.ex` will contain the stubs to our NIFs. This is the Elixir module the NIF module will be registered to.
+- `native` will be home to the Rust code. In fact, a cargo package has been created within this directory (in this case named `base64_nif`).
 - `lib.rs` will contain the NIFs.
 
-The Rust NIFs are compiled and linked into a shared library loaded by Erlang
-code at runtime. Elixir (or Erlang) implementations of the functions are also
-necessary. These are usually minimal stubs defining the name and arity of the
-NIFs and serve as fallback implementations if the NIFs aren't loaded. Let's
-start with the Elixir stubs.
+The Rust NIFs are compiled and linked into a shared library loaded by Erlang code at runtime. Elixir (or Erlang) implementations of the functions are also necessary. These are usually minimal stubs defining the name and arity of the NIFs and serve as fallback implementations if the NIFs aren't loaded. Let's start with the Elixir stubs.
 
 ```elixir
 # lib/base64.ex
@@ -88,16 +66,9 @@ defmodule Base64 do
 end
 ```
 
-The first line is configuration and lets Rustler know what Rust crate to compile
-for the Elixir module.
+The first line is configuration and lets Rustler know what Rust crate to compile for the Elixir module.
 
-As mentioned above, `decode/2` and `encode/2` don't actually implement any
-decoding or encoding; they simply call `error/0` if the NIFs can't be found.
-However, the names and the arguments must match in both the Rust and Elixir
-implementations. Both functions take in a `binary` to be encoded or decoded and
-an `atom` for configuration as different character sets that can be used
-(url-safe, without padding, etc...). The default is fittingly set to
-`:standard`. The Rust NIFs are implemented as follows.
+As mentioned above, `decode/2` and `encode/2` don't actually implement any decoding or encoding; they simply call `error/0` if the NIFs can't be found. However, the names and the arguments must match in both the Rust and Elixir implementations. Both functions take in a `binary` to be encoded or decoded and an `atom` for configuration as different character sets that can be used (url-safe, without padding, etc...). The default is fittingly set to `:standard`. The Rust NIFs are implemented as follows.
 
 ```rust
 // native/base64_nif/src/lib.rs
@@ -137,33 +108,17 @@ fn match_config(option: Atom) -> base64::Config {
 rustler::init!("Elixir.Base64", [decode, encode]);
 ```
 
-The last line is interesting: `rustler::init` is a procedural macro that allows
-the use of `#[rustler::nif]` to annotate functions to be wrapped as NIFs. It
-takes in the name of the Elixir module in which the stubs are defined (in this
-case `"Elixir.Base64"`) and an array containing the names of the functions
-annotated as NIFs (in this case `[decode, encode]`). In short, this links
-everything together.
-
-The use statements at the top of the file are importing the
-[rust-base64 crate](https://github.com/marshallpierce/rust-base64) (`base64`)
-mentioned earlier, which we'll use for encoding and decoding, and the
-`rustler::Atom` type which allows us to represent an Elixir/Erlang `atom` in
-Rust. Both the `rustler` and `base64` crates have been added to the `Cargo.toml`
-dependencies.
-
-The `rustler::atoms` macro defines Rust functions that return Erlang atoms; in
-this case, the possible options for the `encode/2` and `decode/2` functions.
-
-Finally, we come to the NIF definitions. The functions take in a `String` and a
-`rustler::Atom`, and return a `String`. This is consistent with the Elixir
-stubs, as are the names. In this case, the conversions between Rust values and
-Elixir terms are conveniently handled by Rustler. However, for more complex
-types, this may need to be implemented manually.
+The last line is interesting: `rustler::init` is a procedural macro that allows the use of `#[rustler::nif]` to annotate functions to be wrapped as NIFs. It takes in the name of the Elixir module in which the stubs are defined (in this case `"Elixir.Base64"`) and an array containing the names of the functions annotated as NIFs (in this case `[decode, encode]`). In short, this links everything together.
+
+The use statements at the top of the file are importing the [rust-base64 crate](https://github.com/marshallpierce/rust-base64) (`base64`) mentioned earlier, which we'll use for encoding and decoding, and the `rustler::Atom` type which allows us to represent an Elixir/Erlang `atom` in Rust. Both the `rustler` and `base64` crates have been added to the `Cargo.toml` dependencies.
+
+The `rustler::atoms` macro defines Rust functions that return Erlang atoms; in this case, the possible options for the `encode/2` and `decode/2` functions.
+
+Finally, we come to the NIF definitions. The functions take in a `String` and a `rustler::Atom`, and return a `String`. This is consistent with the Elixir stubs, as are the names. In this case, the conversions between Rust values and Elixir terms are conveniently handled by Rustler. However, for more complex types, this may need to be implemented manually.
 
 ## How does it compare to the Elixir implementation?
 
-Rust is fast. Really fast. This was my set-up (using
-[benchee](https://github.com/bencheeorg/benchee)):
+Rust is fast. Really fast. This was my set-up (using [benchee](https://github.com/bencheeorg/benchee)):
 
 ```
 Operating System: macOS
@@ -174,9 +129,7 @@ Elixir 1.10.2
 Erlang 22.3.2
 ```
 
-I used _hello world_ as the short string and Sarah Kay’s poem
-_[B (If I Should Have a Daughter)](https://www.youtube.com/watch?v=0snNB1yS3IE)_
-as the longer string.
+I used _hello world_ as the short string and Sarah Kay’s poem _[B (If I Should Have a Daughter)](https://www.youtube.com/watch?v=0snNB1yS3IE)_ as the longer string.
 
 Decoding:
 
@@ -206,18 +159,10 @@ Rust Nif encode           941.14 K
 Elixir/Erlang encode      615.62 K - 1.53x slower +0.56 μs
 ```
 
-As the data to encode or decode becomes larger, the overhead of creating the
-NIFs becomes smaller and the gains in speed are impressive. These results were
-obtained with fairly small data and so the potential performance gains possible
-by leveraging Rust NIFs when dealing with CPU-intensive tasks are exciting.
+As the data to encode or decode becomes larger, the overhead of creating the NIFs becomes smaller and the gains in speed are impressive. These results were obtained with fairly small data and so the potential performance gains possible by leveraging Rust NIFs when dealing with CPU-intensive tasks are exciting.
 
-I left out the memory usage comparisons but the Elixir/Erlang implementations
-used 3-5x more memory than the NIFs.
+I left out the memory usage comparisons but the Elixir/Erlang implementations used 3-5x more memory than the NIFs.
 
 ## TL;DR: Rustler makes it easy to implement NIFs
 
-Other than the `#[rustler::nif]` function annotations and the `rustler::init`
-call, nothing more is required to implement Rust NIFs with Rustler. The
-boilerplate and the complexities of translating Rust values to Erlang terms
-being handled by the library, there's little resistance to leveraging the power
-of Rust in Elixir/Erlang.
+Other than the `#[rustler::nif]` function annotations and the `rustler::init` call, nothing more is required to implement Rust NIFs with Rustler. The boilerplate and the complexities of translating Rust values to Erlang terms being handled by the library, there's little resistance to leveraging the power of Rust in Elixir/Erlang.
diff --git a/src/posts/2020-08-03-the-true-cost-of-a-quickfix.md b/src/posts/2020-08-03-the-true-cost-of-a-quickfix.md
index 1dbec74060..fde69d7541 100644
--- a/src/posts/2020-08-03-the-true-cost-of-a-quickfix.md
+++ b/src/posts/2020-08-03-the-true-cost-of-a-quickfix.md
@@ -3,38 +3,24 @@ title: The True Cost Of A Quickfix
 authorHandle: patsy_issa_p
 tags: process
 bio: "Senior Frontend Engineer"
-description:
-  "Patsy Issa makes the case for refactoring legacy code sooner rather than
-  later"
+description: "Patsy Issa makes the case for refactoring legacy code sooner rather than later"
 og:
   image: /assets/images/posts/2020-08-03-the-true-cost-of-a-quickfix/og-image.jpg
 tagline: |
   <p>Picture this, a sprint is underway, development is running smoothly, then QA reports a rather odd bug, you begin to investigate and lo and behold you find the following comment:</p> <pre><code class="language-javascript">// Dear programmer: // When I wrote this code, only god and I knew how it worked // Now, only god knows </code></pre>
 ---
 
-While avoiding code that resulted in such comments was harder to enforce in the
-pre-framework era, opinionated frameworks such as
-[Ember.js](https://emberjs.com/) offer us concrete ways to ship code with
-confidence. This is known as the ember happy path, code smells can be identified
-when an implementation strays away from the path.
+While avoiding code that resulted in such comments was harder to enforce in the pre-framework era, opinionated frameworks such as [Ember.js](https://emberjs.com/) offer us concrete ways to ship code with confidence. This is known as the ember happy path, code smells can be identified when an implementation strays away from the path.
 
-In an ideal world, such problems can be caught early enough in the planning
-cycle by collaborating closely among all stakeholders, making sure that design,
-development and product work together towards finding functional solutions that
-are worthy of our users' trust.
+In an ideal world, such problems can be caught early enough in the planning cycle by collaborating closely among all stakeholders, making sure that design, development and product work together towards finding functional solutions that are worthy of our users' trust.
 
-Delivering products with sustainable foundations is a core value that we hold
-dear at Mainmatter. Such foundations, while relatively easy to set up on a
-greenfield project are an entirely different story in any long-lived project
-that might not have started with a solid foundation.
+Delivering products with sustainable foundations is a core value that we hold dear at Mainmatter. Such foundations, while relatively easy to set up on a greenfield project are an entirely different story in any long-lived project that might not have started with a solid foundation.
 
-**"So how do I tackle refactoring legacy code that has made its way into
-multiple core systems?"**
+**"So how do I tackle refactoring legacy code that has made its way into multiple core systems?"**
 
 ### Stop development, fix it now!
 
-While all too tempting this approach has quite a heavy list of pre-requisites in
-order to be successful:
+While all too tempting this approach has quite a heavy list of pre-requisites in order to be successful:
 
 - Tasks have already been scoped out and achievable goals are set
 - The refactoring effort does not block mission-critical features
@@ -42,56 +28,32 @@ order to be successful:
 - The total cost and lead time impact must be justifiable to stakeholders
 - A robust and comprehensive test suite
 
-Often, teams with deadlines will have maintenance periods where engineers are
-allocated time to "fix" the codebase. Time and time again I have seen this
-pattern repeated with similar outcomes, overrun budgets and half-finished
-long-lived branches.
+Often, teams with deadlines will have maintenance periods where engineers are allocated time to "fix" the codebase. Time and time again I have seen this pattern repeated with similar outcomes, overrun budgets and half-finished long-lived branches.
 
-As we tally up the costs (dev/design/product/... time, loss of competitiveness,
-etc...), it is important to keep in mind that this is a one-time investment we
-pay for a more standardized codebase with a reduced chance of future feature
-work delay.
+As we tally up the costs (dev/design/product/... time, loss of competitiveness, etc...), it is important to keep in mind that this is a one-time investment we pay for a more standardized codebase with a reduced chance of future feature work delay.
 
 ### Stop! Quick-fix time!
 
-A scenario we are all too familiar with, everything is going according to plan,
-development is running smoothly, marketing is preparing their release post. Then
-the (un)expected happens, a part that seemed unrelated starts breaking.
+A scenario we are all too familiar with, everything is going according to plan, development is running smoothly, marketing is preparing their release post. Then the (un)expected happens, a part that seemed unrelated starts breaking.
 
-A common approach, that has long term implications, is to run a quick analysis,
-attempt to pinpoint the issue and patch it in time to meet the deadline. While
-this may address our short-term needs, if not followed up with a code audit and
-analysis, it will come back to haunt us.
+A common approach, that has long term implications, is to run a quick analysis, attempt to pinpoint the issue and patch it in time to meet the deadline. While this may address our short-term needs, if not followed up with a code audit and analysis, it will come back to haunt us.
 
-Just recently I experience a situation where a quick fix implemented six months
-ago set us back a total of two weeks. Further investigation revealed that the
-code causing this was committed, by someone that was no longer on the team, a
-little over **three years** ago.
+Just recently I experience a situation where a quick fix implemented six months ago set us back a total of two weeks. Further investigation revealed that the code causing this was committed, by someone that was no longer on the team, a little over **three years** ago.
 
-Any long-lived codebase that does not have regular code audits, will at one
-point or another have parts that are not understood by the current team.
+Any long-lived codebase that does not have regular code audits, will at one point or another have parts that are not understood by the current team.
 
-Unlike the previous method; the cost for this approach depends, among other
-things, on the time the quick-fix spends as tech debt and the future features it
-impacts.
+Unlike the previous method; the cost for this approach depends, among other things, on the time the quick-fix spends as tech debt and the future features it impacts.
 
-> An atomic habit is a regular practice or routine that is not only small and
-> easy to do but is also the source of incredible power; a component of the
-> system of compound growth. Bad habits repeat themselves again and again not
-> because you don't want to change, but because you have the wrong system for
-> change <author>Atomic Habits by James Clear</author>
+> An atomic habit is a regular practice or routine that is not only small and easy to do but is also the source of incredible power; a component of the system of compound growth. Bad habits repeat themselves again and again not because you don't want to change, but because you have the wrong system for change <author>Atomic Habits by James Clear</author>
 
 ### Prevention
 
-Once the issue is resolved, the system in place must be revisited and improved
-to reduce the probability of running into similar problems in the future.
+Once the issue is resolved, the system in place must be revisited and improved to reduce the probability of running into similar problems in the future.
 
 Sustainable development habits must be put in place:
 
 - Training and leveling-up existing staff resulting in higher code quality
-- Reducing the
-  [bus factor](https://en.wikipedia.org/wiki/Bus_factor#:~:text=The%20bus%20factor%20is%20a,truck%20number%2C%20or%20lorry%20factor.)
-  by pairing and knowledge sharing through collaboration
+- Reducing the [bus factor](https://en.wikipedia.org/wiki/Bus_factor#:~:text=The%20bus%20factor%20is%20a,truck%20number%2C%20or%20lorry%20factor.) by pairing and knowledge sharing through collaboration
 - Code audits when a team member leaves, walkthroughs when a new one joins
 
 To name a few, we go into greater detail in our [Playbook](/playbook/)!
diff --git a/src/posts/2020-08-28-testing-the-miragejs-setup.md b/src/posts/2020-08-28-testing-the-miragejs-setup.md
index 31946addb4..f8497d8ce1 100644
--- a/src/posts/2020-08-28-testing-the-miragejs-setup.md
+++ b/src/posts/2020-08-28-testing-the-miragejs-setup.md
@@ -3,8 +3,7 @@ title: "Testing your Mirage.js setup"
 authorHandle: tobiasbieniek
 tags: ember
 bio: "Senior Frontend Engineer"
-description:
-  "Tobias Bieniek explains how to write tests for your Mirage.js mock API setup."
+description: "Tobias Bieniek explains how to write tests for your Mirage.js mock API setup."
 og:
   image: /assets/images/posts/2020-08-28-testing-the-miragejs-setup/og-image.jpg
 tagline: |
@@ -13,21 +12,11 @@ tagline: |
 
 ## Where do we put those tests?
 
-Before we start writing tests we need to figure out where to put all those new
-tests. In the case of an Ember.js app there is a top-level `tests` folder, where
-these new tests would probably feel right at home. But inside of the folder
-there are only `acceptance`, `helpers`, `integration`, and `unit` subfolders.
-None of that really matches what we're building here so we decided to put all of
-our Mirage-related tests into a `tests/mirage/` folder. Note that
-"Mirage-related" means the tests that are testing our Mirage.js setup, not the
-other tests that are just **using** the setup.
+Before we start writing tests we need to figure out where to put all those new tests. In the case of an Ember.js app there is a top-level `tests` folder, where these new tests would probably feel right at home. But inside of the folder there are only `acceptance`, `helpers`, `integration`, and `unit` subfolders. None of that really matches what we're building here so we decided to put all of our Mirage-related tests into a `tests/mirage/` folder. Note that "Mirage-related" means the tests that are testing our Mirage.js setup, not the other tests that are just **using** the setup.
 
 ## Testing `GET` Requests
 
-Let's start with a simple example. We have created a `user` model in Mirage.js,
-and a corresponding `this.get('/users/:id')` shorthand route handler. Now we
-want to check if the serialization layer in Mirage.js works as expected. For
-that we will create a new test file `tests/mirage/user/get-test.js`:
+Let's start with a simple example. We have created a `user` model in Mirage.js, and a corresponding `this.get('/users/:id')` shorthand route handler. Now we want to check if the serialization layer in Mirage.js works as expected. For that we will create a new test file `tests/mirage/user/get-test.js`:
 
 ```js
 {% raw %}
@@ -67,23 +56,13 @@ module('Mirage | User', function (hooks) {
 {% endraw %}
 ```
 
-You can see here that we are first creating the test resource in the Mirage.js
-database (the `server.create()` call), and then we use the regular `fetch()` API
-to perform a network request and see what Mirage.js returns. We check if the
-correct HTTP status code is returned and then compare the resulting JSON payload
-with our expectation.
+You can see here that we are first creating the test resource in the Mirage.js database (the `server.create()` call), and then we use the regular `fetch()` API to perform a network request and see what Mirage.js returns. We check if the correct HTTP status code is returned and then compare the resulting JSON payload with our expectation.
 
-You may have noticed that we hardcoded the `id` in this example. This works in
-simple cases like this, but if, for example, your API is using random UUIDs then
-hardcoding things like this just doesn't work. What we could use instead is:
-`id: user.id`.
+You may have noticed that we hardcoded the `id` in this example. This works in simple cases like this, but if, for example, your API is using random UUIDs then hardcoding things like this just doesn't work. What we could use instead is: `id: user.id`.
 
 ## `matchJson()`
 
-When writing such API tests it can often happen that `assert.deepEqual()` just
-does not provide enough flexibility. To resolve this problem we have integrated
-the [match-json] JS library into our tests, which makes assertions against
-nested values in the JSON payload much easier to write.
+When writing such API tests it can often happen that `assert.deepEqual()` just does not provide enough flexibility. To resolve this problem we have integrated the [match-json] JS library into our tests, which makes assertions against nested values in the JSON payload much easier to write.
 
 [match-json]: https://github.com/ozkxr/match-json
 
@@ -102,9 +81,7 @@ QUnit.assert.matchJson = function (actual, expected, message) {
 {% endraw %}
 ```
 
-This imports the `match-json` library, and introduces a new type of assertion on
-the `assert` object that is available in QUnit tests. We can now write
-assertions like:
+This imports the `match-json` library, and introduces a new type of assertion on the `assert` object that is available in QUnit tests. We can now write assertions like:
 
 ```js
 {% raw %}
@@ -121,12 +98,7 @@ assert.matchJson(responsePayload, {
 
 ## Testing Edge Cases
 
-One advantage of testing the Mirage.js setup is that we can make sure that edge
-cases also work similar to the production API. For example, if we want to ensure
-that our Mirage.js setup returns a "404 Not Found" HTTP status if the requested
-user does not exist, we can skip the `server.create()` call at the start of the
-test, perform the `fetch()` request, and then check for the expected
-`response.status` value:
+One advantage of testing the Mirage.js setup is that we can make sure that edge cases also work similar to the production API. For example, if we want to ensure that our Mirage.js setup returns a "404 Not Found" HTTP status if the requested user does not exist, we can skip the `server.create()` call at the start of the test, perform the `fetch()` request, and then check for the expected `response.status` value:
 
 ```js
 {% raw %}
@@ -139,8 +111,7 @@ test('returns HTTP 404 if the requested user does not exist', async function (as
 
 ## Testing `PUT` requests
 
-Similar to read-only `GET` requests, we can also test e.g. `PUT` requests, that
-mutate the existing resource:
+Similar to read-only `GET` requests, we can also test e.g. `PUT` requests, that mutate the existing resource:
 
 ```js
 {% raw %}
@@ -176,15 +147,10 @@ module('GET /users/:id', function () {
 {% endraw %}
 ```
 
-You can see that the test looks fairly similar to the `GET` request test, except
-that pass an options object to the `fetch()` function, where we specify that
-this is a `PUT` request, and what the request payload will be.
+You can see that the test looks fairly similar to the `GET` request test, except that pass an options object to the `fetch()` function, where we specify that this is a `PUT` request, and what the request payload will be.
 
-Similar strategies can also be applied for `DELETE` and `POST` requests, but we
-will leave that as an exercise for our readers... 😉
+Similar strategies can also be applied for `DELETE` and `POST` requests, but we will leave that as an exercise for our readers... 😉
 
-Finally, if you want more information on how we make sure that our mock APIs
-always match the production API or you need more help implementing these things
-in your own project, please [contact us]! 👋
+Finally, if you want more information on how we make sure that our mock APIs always match the production API or you need more help implementing these things in your own project, please [contact us]! 👋
 
 [contact us]: https://mainmatter.com/contact/
diff --git a/src/posts/2020-10-05-simpler-and-more-powerful-components-in-ember-octane-with-glimmer-components.md b/src/posts/2020-10-05-simpler-and-more-powerful-components-in-ember-octane-with-glimmer-components.md
index b42674c5d1..61eda605ab 100644
--- a/src/posts/2020-10-05-simpler-and-more-powerful-components-in-ember-octane-with-glimmer-components.md
+++ b/src/posts/2020-10-05-simpler-and-more-powerful-components-in-ember-octane-with-glimmer-components.md
@@ -1,12 +1,9 @@
 ---
-title:
-  "Simpler and more powerful components in Ember Octane with Glimmer Components"
+title: "Simpler and more powerful components in Ember Octane with Glimmer Components"
 authorHandle: locks
 tags: ember
 bio: "Senior Frontend Engineer, Ember Framework and Learning Core teams member"
-description:
-  "Ricardo Mendes explains how Glimmer components provide a simpler and clearer,
-  yet more powerful, component layer for Ember Octane applications."
+description: "Ricardo Mendes explains how Glimmer components provide a simpler and clearer, yet more powerful, component layer for Ember Octane applications."
 og:
   image: /assets/images/posts/2020-10-05-simpler-and-more-powerful-components-in-ember-octane-with-glimmer-components/og-image.jpg
 tagline: |
@@ -15,39 +12,21 @@ tagline: |
 
 ## Introducing Glimmer components
 
-The release of the
-[Ember Octane edition](https://blog.emberjs.com/2019/12/20/octane-is-here.html)
-back in December was one of Ember's biggest releases, bringing with it modern
-and streamlined APIs. At the core of the release are
-[tracked properties](https://guides.emberjs.com/release/in-depth-topics/autotracking-in-depth/)
-and Glimmer components. While Octane has been out for quite some time, and
-subsequently Glimmer components, you are likely using Ember (or "classic")
-components in your application. To give some context as to the impact of Glimmer
-components in the Ember mental model, I'll be introducing Glimmer components
-from the viewpoint of classic Components.
+The release of the [Ember Octane edition](https://blog.emberjs.com/2019/12/20/octane-is-here.html) back in December was one of Ember's biggest releases, bringing with it modern and streamlined APIs. At the core of the release are [tracked properties](https://guides.emberjs.com/release/in-depth-topics/autotracking-in-depth/) and Glimmer components. While Octane has been out for quite some time, and subsequently Glimmer components, you are likely using Ember (or "classic") components in your application. To give some context as to the impact of Glimmer components in the Ember mental model, I'll be introducing Glimmer components from the viewpoint of classic Components.
 
 The key points we will be addressing in this post are:
 
-- Glimmer components use native `class` syntax and do not extend from
-  `EmberObject`.
+- Glimmer components use native `class` syntax and do not extend from `EmberObject`.
 - Separation of internal state (properties) and external state (arguments).
 - HTML-first approach makes for a much simpler API surface.
 
 ## Native `class`
 
-The first thing that catches the eye is that Glimmer components have a different
-base class with a radically different API (see
-[Ember Component](https://api.emberjs.com/ember/3.21/classes/Component) vs
-[Glimmer component](https://api.emberjs.com/ember/3.21/modules/@glimmer%2Fcomponent)).
+The first thing that catches the eye is that Glimmer components have a different base class with a radically different API (see [Ember Component](https://api.emberjs.com/ember/3.21/classes/Component) vs [Glimmer component](https://api.emberjs.com/ember/3.21/modules/@glimmer%2Fcomponent)).
 
-With the new Glimmer component implementation you are expected to use the native
-`class` syntax, but it also changes something more important: a Glimmer
-component no longer inherits from `EmberObject`. Now you should use native
-getters and setters, as well as tracked properties.
+With the new Glimmer component implementation you are expected to use the native `class` syntax, but it also changes something more important: a Glimmer component no longer inherits from `EmberObject`. Now you should use native getters and setters, as well as tracked properties.
 
-How you define the component actions also requires an adjustment. First, a bit
-of historical context. One of the first proposals for Ember components had
-actions defined as a member function of the component, like so:
+How you define the component actions also requires an adjustment. First, a bit of historical context. One of the first proposals for Ember components had actions defined as a member function of the component, like so:
 
 ```javascript
 export default Component.extend({
@@ -57,11 +36,7 @@ export default Component.extend({
 });
 ```
 
-Unfortunately, due to the API surface of components and the fact that one of the
-component lifecycle hooks was named `destroy`, that meant that users would
-unknowingly override component hooks and introduce strange bugs to their
-application. To address this, a system was conceived where you define component
-actions in the actions hash:
+Unfortunately, due to the API surface of components and the fact that one of the component lifecycle hooks was named `destroy`, that meant that users would unknowingly override component hooks and introduce strange bugs to their application. To address this, a system was conceived where you define component actions in the actions hash:
 
 ```javascript
 export default Component.extend({
@@ -73,14 +48,9 @@ export default Component.extend({
 });
 ```
 
-But now that Glimmer components have quite a small API surface (roughly
-`willDestroy`, `isDestroying` and `isDestroyed`), we can go back to defining
-them as methods in the component, and then refer to them directly in the
-template.
+But now that Glimmer components have quite a small API surface (roughly `willDestroy`, `isDestroying` and `isDestroyed`), we can go back to defining them as methods in the component, and then refer to them directly in the template.
 
-So putting these things together, let's look at a component that receives a type
-of pasta and a type of sauce and displays it with a button to order. The
-component is invoked like so:
+So putting these things together, let's look at a component that receives a type of pasta and a type of sauce and displays it with a button to order. The component is invoked like so:
 
 ```handlebars
 {% raw %}
@@ -141,37 +111,19 @@ export default class OrderPasta extends Component {
 {% endraw %}
 ```
 
-I won't go into details on the `action` to `on` modifier changes, but notice how
-in the Glimmer component we reference the callback directly, we used a native
-getter, and we defined the action handler as a decorated method. You might also
-have noticed that in the Glimmer component code I have referred to the passed-in
-values as `this.args`, which brings us to our next point.
+I won't go into details on the `action` to `on` modifier changes, but notice how in the Glimmer component we reference the callback directly, we used a native getter, and we defined the action handler as a decorated method. You might also have noticed that in the Glimmer component code I have referred to the passed-in values as `this.args`, which brings us to our next point.
 
 ## Separation of properties and arguments
 
-One behavior of classic components that can sneak up on even more experienced
-developers is the fact that classic components reflect passed-in state
-(arguments) onto internal state (properties). This has a big implication. Since
-properties and arguments are directly linked in classic components, you can
-effectively override any property from the outside by calling the component with
-an argument with the same name. You cannot refer to the argument's original
-value from within the component.
+One behavior of classic components that can sneak up on even more experienced developers is the fact that classic components reflect passed-in state (arguments) onto internal state (properties). This has a big implication. Since properties and arguments are directly linked in classic components, you can effectively override any property from the outside by calling the component with an argument with the same name. You cannot refer to the argument's original value from within the component.
 
-Glimmer components do away with this behavior by separating arguments into the
-`args` property of the component, and by making named argument bindings
-read-only, which gives developers a better guarantee that the data flow in a
-component tree isn't accidentally two-way bound.
+Glimmer components do away with this behavior by separating arguments into the `args` property of the component, and by making named argument bindings read-only, which gives developers a better guarantee that the data flow in a component tree isn't accidentally two-way bound.
 
-Now developers have to be more explicit about certain patterns, for example
-default values for component properties.
+Now developers have to be more explicit about certain patterns, for example default values for component properties.
 
-Let's take the previous `OrderPasta` component and make the pasta type optional.
-I will only include the code necessary for this change to keep the code samples
-focused.
+Let's take the previous `OrderPasta` component and make the pasta type optional. I will only include the code necessary for this change to keep the code samples focused.
 
-For the Ember component, we can see that adding a property with the proper name
-is enough. If the component is invoked with a different `pasta` argument, this
-will be overwritten.
+For the Ember component, we can see that adding a property with the proper name is enough. If the component is invoked with a different `pasta` argument, this will be overwritten.
 
 ```javascript
 /// app/components/order-pasta.js
@@ -182,10 +134,7 @@ export default Component.extend({
 });
 ```
 
-For the Glimmer component we have to do a bit more legwork. We'll assume that
-`pasta` can change over time, so we will add a native getter so it gets
-automatically updated. We will also need to change our `dishName` getter to
-refer to the property instead.
+For the Glimmer component we have to do a bit more legwork. We'll assume that `pasta` can change over time, so we will add a native getter so it gets automatically updated. We will also need to change our `dishName` getter to refer to the property instead.
 
 ```javascript
 // app/components/order-pasta.js
@@ -200,36 +149,15 @@ export default class OrderPasta extends Component {
 }
 ```
 
-As you can see, we can now reason about the code locally instead of having to
-rely on the framework knowledge that `pasta` would be overwritten. We can use
-the name `pasta` for both the property and the argument because the syntax makes
-it clear which is which. If you need access to the argument you use
-`this.args.pasta` in the class or `{{@pasta}}` in the template. If you need to
-access the property, you use `this.pasta` in the class and `{{this.pasta}}` in
-the template.
-
-If you checked the API documentation linked at the beginning of the blog post,
-you might still be wondering how Glimmer components managed to reduce the API
-surface so much. We will not be covering lifecycle hooks in this post (which
-account for the removal of `didInsertElement`, `didReceiveAttrs`, `didRender`,
-`didUpdate`, `didUpdateAttrs`, `willRender`, `willUpdate`), instead we will be
-focusing on the APIs that allows one to customize the wrapper element of Ember
-Components.
+As you can see, we can now reason about the code locally instead of having to rely on the framework knowledge that `pasta` would be overwritten. We can use the name `pasta` for both the property and the argument because the syntax makes it clear which is which. If you need access to the argument you use `this.args.pasta` in the class or `{{@pasta}}` in the template. If you need to access the property, you use `this.pasta` in the class and `{{this.pasta}}` in the template.
+
+If you checked the API documentation linked at the beginning of the blog post, you might still be wondering how Glimmer components managed to reduce the API surface so much. We will not be covering lifecycle hooks in this post (which account for the removal of `didInsertElement`, `didReceiveAttrs`, `didRender`, `didUpdate`, `didUpdateAttrs`, `willRender`, `willUpdate`), instead we will be focusing on the APIs that allows one to customize the wrapper element of Ember Components.
 
 ## HTML-first APIs
 
-Ember components have been around since before the 1.0 release, where they were
-introduced as isolated
-[views](https://api.emberjs.com/ember/1.0/classes/Ember.View). Views are long
-gone from everyday applications, but their legacy still lives on in Ember
-components. Ember components have a very distinct characteristic, the
-component's template is wrapped by a hidden element, `<div>` by default. To
-customize this element, you have to use certain APIs in the component's class,
-like `tagName`, `classNameBindings` and `attributeBindings`.
+Ember components have been around since before the 1.0 release, where they were introduced as isolated [views](https://api.emberjs.com/ember/1.0/classes/Ember.View). Views are long gone from everyday applications, but their legacy still lives on in Ember components. Ember components have a very distinct characteristic, the component's template is wrapped by a hidden element, `<div>` by default. To customize this element, you have to use certain APIs in the component's class, like `tagName`, `classNameBindings` and `attributeBindings`.
 
-Let us go with a practical example to make it clearer. We are going to make a
-button component that receives a `primary` CSS class and a `disabled` HTML
-attribute. The component template itself will be the content for the button.
+Let us go with a practical example to make it clearer. We are going to make a button component that receives a `primary` CSS class and a `disabled` HTML attribute. The component template itself will be the content for the button.
 
 ```javascript
 // app/components/my-button.js
@@ -274,16 +202,9 @@ Now you can call `MyButton` and dynamically change the class and the attribute:
 {% endraw %}
 ```
 
-You might look at this example and think, why are we using JavaScript to specify
-how we want the HTML to look when we have templates and I would agree with you.
-More than that, the Ember team agrees with you, that's why Glimmer components no
-longer have an implicit wrapper element so now you can configure this in the
-component's template itself. This, coupled with being able to specify HTML
-attributes and the new `...attributes` make template-only components much more
-feasible.
+You might look at this example and think, why are we using JavaScript to specify how we want the HTML to look when we have templates and I would agree with you. More than that, the Ember team agrees with you, that's why Glimmer components no longer have an implicit wrapper element so now you can configure this in the component's template itself. This, coupled with being able to specify HTML attributes and the new `...attributes` make template-only components much more feasible.
 
-Let's implement `MyButton` in Glimmer. As mentioned, we are moving the code from
-the component class to the template, so we don't need the JavaScript file.
+Let's implement `MyButton` in Glimmer. As mentioned, we are moving the code from the component class to the template, so we don't need the JavaScript file.
 
 ```handlebars
 {% raw %} // app/components/my-button.hbs
@@ -293,15 +214,9 @@ the component class to the template, so we don't need the JavaScript file.
 {% endraw %}
 ```
 
-{% raw %} Much more straightforward! In
-`{{if @buttonType @buttonType 'primary'}}` we are saying that the value should
-be `primary` if `@buttonType` is not defined, and in `...attribute` we are
-telling Ember where to put any HTML attributes that are passed in when calling
-the component. {% endraw %}
+{% raw %} Much more straightforward! In `{{if @buttonType @buttonType 'primary'}}` we are saying that the value should be `primary` if `@buttonType` is not defined, and in `...attribute` we are telling Ember where to put any HTML attributes that are passed in when calling the component. {% endraw %}
 
-In this case we do not want to pass `class` as an HTML attribute when calling
-the component because `class` is special in that it merged together the existing
-classes in the component with whatever you pass to the component:
+In this case we do not want to pass `class` as an HTML attribute when calling the component because `class` is special in that it merged together the existing classes in the component with whatever you pass to the component:
 
 ````handlebars
 {% raw %} // app/components/my-button.hbs
@@ -318,10 +233,7 @@ Renders:
 <button class="primary two">Multiple classes</button>
 ```
 
-For the sake of exemplifying `attributeBindings` I glossed over the fact that
-Ember will apply any HTML attributes you pass to an Ember component to the
-implicit wrapper element. Now that we are explicitly using `...attributes` in
-our Glimmer component, we need to update how we're calling the component:
+For the sake of exemplifying `attributeBindings` I glossed over the fact that Ember will apply any HTML attributes you pass to an Ember component to the implicit wrapper element. Now that we are explicitly using `...attributes` in our Glimmer component, we need to update how we're calling the component:
 
 ```handlebars
 {% raw %}
@@ -343,24 +255,10 @@ our Glimmer component, we need to update how we're calling the component:
 {% endraw %}
 ```
 
-A common point of dissatisfaction with frameworks, including Ember, is the so
-called "magic". This is when the framework does something for you that you have
-no insight into, so you may not understand what is happening or why. For
-example, Ember components having an implicit wrapper element, and Ember
-automatically applying `...attributes` to it.
-
-With the introduction of Glimmer components in the Octane edition plus the
-template improvements already mentioned in a previous post, Ember has made it
-much easier to reason locally about your component. By keeping layout logic in
-the layout, instead of the component class you only have to look in one place to
-know what the component will render. By moving towards native JavaScript syntax
-and functionality, Ember has diminished the uncertainty of whether a certain
-functionality is provided by Ember or by JavaScript.
-
-I hope this exploration of Glimmer components and Ember components was useful
-for you and at the very least gave you a renewed appreciation for the Octane
-Edition design effort.
-
-If you are looking for help migrating your codebase to these new idioms, or you
-want to level up your engineering team, [contact us](/contact/) so we can work
-together towards achieving your goals.
+A common point of dissatisfaction with frameworks, including Ember, is the so called "magic". This is when the framework does something for you that you have no insight into, so you may not understand what is happening or why. For example, Ember components having an implicit wrapper element, and Ember automatically applying `...attributes` to it.
+
+With the introduction of Glimmer components in the Octane edition plus the template improvements already mentioned in a previous post, Ember has made it much easier to reason locally about your component. By keeping layout logic in the layout, instead of the component class you only have to look in one place to know what the component will render. By moving towards native JavaScript syntax and functionality, Ember has diminished the uncertainty of whether a certain functionality is provided by Ember or by JavaScript.
+
+I hope this exploration of Glimmer components and Ember components was useful for you and at the very least gave you a renewed appreciation for the Octane Edition design effort.
+
+If you are looking for help migrating your codebase to these new idioms, or you want to level up your engineering team, [contact us](/contact/) so we can work together towards achieving your goals.
diff --git a/src/posts/2020-11-02-bringing-matrix-to-elixir.md b/src/posts/2020-11-02-bringing-matrix-to-elixir.md
index ff0f5abd20..09b5a75c1d 100644
--- a/src/posts/2020-11-02-bringing-matrix-to-elixir.md
+++ b/src/posts/2020-11-02-bringing-matrix-to-elixir.md
@@ -10,59 +10,25 @@ tagline: |
   <p><a href="https://matrix.org">Matrix</a> is an open-source, end-to-end encrypted, real-time, open standard communication protocol designed to protect people's privacy. The technology has applications not only in messaging and Voice over IP (VoIP) but similarly in Internet of Things (IoT), Augmented Reality (AR) and Virtual Reality (VR).</p>
 ---
 
-Introduced in 2014, Matrix is backed by [Element](https://element.io/about)
-(formerly New Vector), the company behind the
-[Element Matrix client](https://element.io/) (formerly Riot). Adopters include
-the
-[French government](https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed-as-the-basis-for-frances-secure-instant-messenger-app),
-the US government, [Mozilla](https://wiki.mozilla.org/Matrix),
-[Purism](https://matrix.org/blog/2017/08/24/the-librem-5-from-purism-a-matrix-native-smartphone),
-[Germany's Ministry of Defence](https://www.heise.de/newsticker/meldung/Open-Source-Bundeswehr-baut-eigene-verschluesselte-Messenger-App-4623404.html)
-and the
-[German education system](https://sifted.eu/articles/element-germany-deal/).
-
-In May of this year, I began work on a
-[Matrix SDK for Elixir](https://github.com/niklaslong/matrix-elixir-sdk) with
-the aim of simplifying the process of Matrix-enabling Elixir applications. It is
-early days for the project but if you are interested in contributing (all skill
-levels welcome) or using the SDK as a foundation for another project, please let
-me know!
+Introduced in 2014, Matrix is backed by [Element](https://element.io/about) (formerly New Vector), the company behind the [Element Matrix client](https://element.io/) (formerly Riot). Adopters include the [French government](https://matrix.org/blog/2018/04/26/matrix-and-riot-confirmed-as-the-basis-for-frances-secure-instant-messenger-app), the US government, [Mozilla](https://wiki.mozilla.org/Matrix), [Purism](https://matrix.org/blog/2017/08/24/the-librem-5-from-purism-a-matrix-native-smartphone), [Germany's Ministry of Defence](https://www.heise.de/newsticker/meldung/Open-Source-Bundeswehr-baut-eigene-verschluesselte-Messenger-App-4623404.html) and the [German education system](https://sifted.eu/articles/element-germany-deal/).
+
+In May of this year, I began work on a [Matrix SDK for Elixir](https://github.com/niklaslong/matrix-elixir-sdk) with the aim of simplifying the process of Matrix-enabling Elixir applications. It is early days for the project but if you are interested in contributing (all skill levels welcome) or using the SDK as a foundation for another project, please let me know!
 
 ## Federation of homeservers
 
-Matrix is structured around the federation of homeservers, that is to say the
-continuous synchronisation of event history between homeservers via the
-Server-Server API.
+Matrix is structured around the federation of homeservers, that is to say the continuous synchronisation of event history between homeservers via the Server-Server API.
 
 ![The Matrix Architecture](/assets/images/posts/2020-11-02-bringing-matrix-to-elixir/matrix_architecture.png)
 
-Each user is registered on a single homeserver, ideally hosted by themselves,
-and can join rooms to communicate with others. A room is a shared history of
-events associated with its members. The history is copied in full on each
-member's homeserver and all copies are synchronised in real-time. Fundamentally,
-a room is a decentralised data store with no single point of control or failure.
+Each user is registered on a single homeserver, ideally hosted by themselves, and can join rooms to communicate with others. A room is a shared history of events associated with its members. The history is copied in full on each member's homeserver and all copies are synchronised in real-time. Fundamentally, a room is a decentralised data store with no single point of control or failure.
 
-Matrix was designed from the start to exchange data with other platforms such as
-WhatsApp, Slack, iMessage, Email, Discord, IRC and many more. This is known as
-bridging and makes Matrix an attractive one-stop solution to interface with
-these services. As an example, Alice on Matrix, could seamlessly communicate
-with Bob on Freenode and Chris on Slack. Crucially, bridges connect separate
-communities and as such represent a workable migration path from walled garden
-networks.
+Matrix was designed from the start to exchange data with other platforms such as WhatsApp, Slack, iMessage, Email, Discord, IRC and many more. This is known as bridging and makes Matrix an attractive one-stop solution to interface with these services. As an example, Alice on Matrix, could seamlessly communicate with Bob on Freenode and Chris on Slack. Crucially, bridges connect separate communities and as such represent a workable migration path from walled garden networks.
 
 ## Getting started with the SDK
 
-As mentioned above, all changes in a room's state are described by events. They
-can represent any data, from users joining a room or sending messages, to image
-uploads and VoIP call setup. Let's dip our toes into Matrix by creating a guest
-account on `matrix.org` and reading events from the `#elixirsdktest:matrix.org`
-room.
+As mentioned above, all changes in a room's state are described by events. They can represent any data, from users joining a room or sending messages, to image uploads and VoIP call setup. Let's dip our toes into Matrix by creating a guest account on `matrix.org` and reading events from the `#elixirsdktest:matrix.org` room.
 
-I've written
-[an example script](https://github.com/niklaslong/matrix-elixir-sdk/blob/master/examples/guest_login.exs)
-to do this and will be going through the crucial parts below. If you'd like to
-try it out yourself, clone the repo and run (assuming you have Elixir
-installed):
+I've written [an example script](https://github.com/niklaslong/matrix-elixir-sdk/blob/master/examples/guest_login.exs) to do this and will be going through the crucial parts below. If you'd like to try it out yourself, clone the repo and run (assuming you have Elixir installed):
 
 ```
 mix deps.get
@@ -100,16 +66,9 @@ The `Request.register_guest/1` call returns a struct:
 }
 ```
 
-The SDK was designed to be modular and is structured with the `Request` module
-at its core. The module does no IO on its own and returns a struct used by the
-HTTP client to make the requests. This allows users to leverage only the
-functionality they need and are not tied into any unnecessary dependencies. By
-default the SDK uses [Tesla](https://github.com/teamon/tesla) configured with
-[Mint](https://github.com/elixir-mint/mint) but this approach makes it very easy
-to use any other HTTP client with a small amount of glue code.
+The SDK was designed to be modular and is structured with the `Request` module at its core. The module does no IO on its own and returns a struct used by the HTTP client to make the requests. This allows users to leverage only the functionality they need and are not tied into any unnecessary dependencies. By default the SDK uses [Tesla](https://github.com/teamon/tesla) configured with [Mint](https://github.com/elixir-mint/mint) but this approach makes it very easy to use any other HTTP client with a small amount of glue code.
 
-To execute the request, `Client.do_request/1` is called with the struct and the
-response looks something like this:
+To execute the request, `Client.do_request/1` is called with the struct and the response looks something like this:
 
 ```elixir
 %Tesla.Env{
@@ -125,19 +84,13 @@ response looks something like this:
 }
 ```
 
-It returns an access token (shortened for brevity). This token can be used to
-authenticate most Matrix endpoints (some don't require authentication at all).
-Likewise, standard user accounts, not covered here, use tokens as authentication
-once a login flow has been completed.
+It returns an access token (shortened for brevity). This token can be used to authenticate most Matrix endpoints (some don't require authentication at all). Likewise, standard user accounts, not covered here, use tokens as authentication once a login flow has been completed.
 
-Naming for all user accounts follows the convention of `@name:server.url`. For
-guest accounts, the name is a number generated by the server, e.g., `user_id`
-above.
+Naming for all user accounts follows the convention of `@name:server.url`. For guest accounts, the name is a number generated by the server, e.g., `user_id` above.
 
 ### Joining a room
 
-Once we have an access token, we can attempt to join a room allowing guest
-access, such as `#elixirsdktest:matrix.org`:
+Once we have an access token, we can attempt to join a room allowing guest access, such as `#elixirsdktest:matrix.org`:
 
 ```elixir
 # examples/guest_login.exs
@@ -151,11 +104,7 @@ room = "#elixirsdktest:matrix.org"
   |> Client.do_request()
 ```
 
-The first request should return a `403` and a link to accept the Matrix terms
-and conditions. Let's open the link in a browser, read and accept the terms (if
-we agree with them), and give it another go. If you're using the script, it will
-prompt you to do exactly this before trying the request again. If all is well,
-the response should be similar to this:
+The first request should return a `403` and a link to accept the Matrix terms and conditions. Let's open the link in a browser, read and accept the terms (if we agree with them), and give it another go. If you're using the script, it will prompt you to do exactly this before trying the request again. If all is well, the response should be similar to this:
 
 ```elixir
 %Tesla.Env{
@@ -166,16 +115,11 @@ the response should be similar to this:
 }
 ```
 
-The call returns a `200` and the `room_id`. You may have noticed this isn't the
-same as `#elixirsdktest:matrix.org` used to make the request. The latter is an
-alias. They allow users to refer to rooms more conveniently instead of using
-long IDs such as `!shAQDWZCviggxGBINv:matrix.org`. Both are valid, however, and
-can be used interchangeably with most endpoints.
+The call returns a `200` and the `room_id`. You may have noticed this isn't the same as `#elixirsdktest:matrix.org` used to make the request. The latter is an alias. They allow users to refer to rooms more conveniently instead of using long IDs such as `!shAQDWZCviggxGBINv:matrix.org`. Both are valid, however, and can be used interchangeably with most endpoints.
 
 ### Reading events
 
-The next step is to read events from the homeserver. This can be achieved with a
-call to `sync/2`.
+The next step is to read events from the homeserver. This can be achieved with a call to `sync/2`.
 
 ```elixir
 # examples/guest_login.exs
@@ -186,10 +130,7 @@ call to `sync/2`.
   |> Client.do_request()
 ```
 
-Syncing is complex and I won't be going into any great detail here. At a high
-level, all events from a user's joined rooms will be included in the response.
-These are categorised in the payload. For simplicity here is the structure of
-the information returned:
+Syncing is complex and I won't be going into any great detail here. At a high level, all events from a user's joined rooms will be included in the response. These are categorised in the payload. For simplicity here is the structure of the information returned:
 
 ```elixir
 %{
@@ -207,10 +148,7 @@ the information returned:
 }
 ```
 
-In essence, the response is a linear event history for a user and can be used by
-a client to reconstruct a room's state. Pagination is handled by way of
-pagination tokens like `prev_batch` and can be leveraged in subsequent `sync`
-calls.
+In essence, the response is a linear event history for a user and can be used by a client to reconstruct a room's state. Pagination is handled by way of pagination tokens like `prev_batch` and can be leveraged in subsequent `sync` calls.
 
 Events look like this:
 
@@ -230,39 +168,16 @@ Events look like this:
 }
 ```
 
-This is the `join` event for the account used in this example. It has some
-`content`, a `type`, and some other associated meta-data.
+This is the `join` event for the account used in this example. It has some `content`, a `type`, and some other associated meta-data.
 
-This is where I'll end this short introduction, however, please check the
-[documentation](https://hexdocs.pm/matrix_sdk/) for more information on the
-currently implemented endpoints.
+This is where I'll end this short introduction, however, please check the [documentation](https://hexdocs.pm/matrix_sdk/) for more information on the currently implemented endpoints.
 
 ## What's next?
 
-The Elixir SDK currently wraps part of the Client-Server API and v0.1 was
-released to allow interested parties to begin experimenting. However, work
-continues as there are a number of endpoints waiting to be implemented. There
-are discussions underway about introducing a parse response stack and structural
-changes to the library. Additionally, Olm will soon be added as a dependency to
-the SDK in order to support encryption.
-
-Olm is an implementation of the
-[Double Ratchet Algorithm](https://signal.org/docs/specifications/doubleratchet)
-written in C/C++ and exposed as a C API. It is used by Matrix to implement
-encryption, both for individual and group messaging. The
-[Elixir/Erlang bindings](https://github.com/niklaslong/olm-elixir) are a first
-step towards implementing end-to-end encryption in the SDK. I started it as a
-separate project as it could conceivably be used in non-Matrix based
-applications. The library is implemented using C NIFs and currently lacks
-support for group sessions (coming soon). The first release candidate has been
-published to hex.
-
-The long-term goal is to provide all the tools necessary to build Matrix-enabled
-applications in Elixir, from clients to homeservers. Matrix is experimenting
-with P2P by bundling clients and homeservers together on the user's device. This
-could lead to interesting implementations in Elixir, potentially targeting
-WebAssembly thanks to [Lumen](https://github.com/lumen/lumen).
-
-It is my belief that Elixir can be a powerful tool in decentralising the web.
-Projects like Matrix are vitally important and I hope the SDK will encourage
-creators to start projects in this problem space.
+The Elixir SDK currently wraps part of the Client-Server API and v0.1 was released to allow interested parties to begin experimenting. However, work continues as there are a number of endpoints waiting to be implemented. There are discussions underway about introducing a parse response stack and structural changes to the library. Additionally, Olm will soon be added as a dependency to the SDK in order to support encryption.
+
+Olm is an implementation of the [Double Ratchet Algorithm](https://signal.org/docs/specifications/doubleratchet) written in C/C++ and exposed as a C API. It is used by Matrix to implement encryption, both for individual and group messaging. The [Elixir/Erlang bindings](https://github.com/niklaslong/olm-elixir) are a first step towards implementing end-to-end encryption in the SDK. I started it as a separate project as it could conceivably be used in non-Matrix based applications. The library is implemented using C NIFs and currently lacks support for group sessions (coming soon). The first release candidate has been published to hex.
+
+The long-term goal is to provide all the tools necessary to build Matrix-enabled applications in Elixir, from clients to homeservers. Matrix is experimenting with P2P by bundling clients and homeservers together on the user's device. This could lead to interesting implementations in Elixir, potentially targeting WebAssembly thanks to [Lumen](https://github.com/lumen/lumen).
+
+It is my belief that Elixir can be a powerful tool in decentralising the web. Projects like Matrix are vitally important and I hope the SDK will encourage creators to start projects in this problem space.
diff --git a/src/posts/2020-11-09-pro-bono-open-call.md b/src/posts/2020-11-09-pro-bono-open-call.md
index 0c786b275a..d3c2ae9114 100644
--- a/src/posts/2020-11-09-pro-bono-open-call.md
+++ b/src/posts/2020-11-09-pro-bono-open-call.md
@@ -1,7 +1,5 @@
 ---
-title:
-  "Calling all tech founders: we are seeking startups for pro-bono product
-  design!"
+title: "Calling all tech founders: we are seeking startups for pro-bono product design!"
 authorHandle: msmarhigh
 tags: design
 bio: "Director of Product Design"
@@ -14,49 +12,23 @@ tagline: |
 
 ## Seeking applicants for pro-bono product design
 
-Mainmatter is a digital product consultancy with an emphasis on sustainable
-success. We have a proven track record of successful projects for international
-clients, ranging from startups to Fortune Global 500 enterprises. To learn more
-about our approach, take a look at our [services](/services/launch-your-idea/)
-and [Playbook](/playbook).
+Mainmatter is a digital product consultancy with an emphasis on sustainable success. We have a proven track record of successful projects for international clients, ranging from startups to Fortune Global 500 enterprises. To learn more about our approach, take a look at our [services](/services/launch-your-idea/) and [Playbook](/playbook).
 
 ### Anyone from an underrepresented group in tech is welcome to apply
 
-In an effort to support the creation of an equal playing field, we invite
-applicants from **underrepresented groups in tech** to apply for pro-bono
-product design. We especially invite and welcome women, Black, Indigenous &
-People of Color, QTIBIPOC/LGBTQIA+ people, people with disabilities, and people
-facing economic or social hardships.
+In an effort to support the creation of an equal playing field, we invite applicants from **underrepresented groups in tech** to apply for pro-bono product design. We especially invite and welcome women, Black, Indigenous & People of Color, QTIBIPOC/LGBTQIA+ people, people with disabilities, and people facing economic or social hardships.
 
 We will offer one of the following services:
 
-- **Product strategy (moderation of a 2-week design sprint):** we will work with
-  you and your team to validate an idea in a 1-week design sprint, and then
-  iterate and improve on that idea on the following week. At the end of the 2
-  weeks, you will have a tested prototype of an idea for your product, which you
-  can show to potential users or investors as well as an understanding of how to
-  move the idea forward. This service is ideal for teams that have a product and
-  design team, and who along with the decision-making team are able to work with
-  us remotely for the entirety of two weeks. It is also a great kickoff for an
-  MVP project.
-- **Design system strategy and kickoff:** we will have a workshop consultation
-  for the transition of your digital product into a design systems methodology.
-  The consultation will include technical implementation suggestions and the
-  inventory of your existing interface. After that, our product designer will
-  mentor your team for 3 weeks, collaborating to create the initial design
-  structure and an organizational workflow to optimize collaboration between
-  your team. At the end of this period, your team will be knowledgeable on how
-  to successfully work with a design system.
+- **Product strategy (moderation of a 2-week design sprint):** we will work with you and your team to validate an idea in a 1-week design sprint, and then iterate and improve on that idea on the following week. At the end of the 2 weeks, you will have a tested prototype of an idea for your product, which you can show to potential users or investors as well as an understanding of how to move the idea forward. This service is ideal for teams that have a product and design team, and who along with the decision-making team are able to work with us remotely for the entirety of two weeks. It is also a great kickoff for an MVP project.
+- **Design system strategy and kickoff:** we will have a workshop consultation for the transition of your digital product into a design systems methodology. The consultation will include technical implementation suggestions and the inventory of your existing interface. After that, our product designer will mentor your team for 3 weeks, collaborating to create the initial design structure and an organizational workflow to optimize collaboration between your team. At the end of this period, your team will be knowledgeable on how to successfully work with a design system.
 
 ## Criteria
 
-- From an underrepresented diversity group in tech (underrepresented groups
-  include: women, Black, Indigenous & People of Color, QTIBIPOC/LGBTQIA+ people,
-  people with disabilities, and people facing economic or social hardships)
+- From an underrepresented diversity group in tech (underrepresented groups include: women, Black, Indigenous & People of Color, QTIBIPOC/LGBTQIA+ people, people with disabilities, and people facing economic or social hardships)
 - In a European time zone
 - In need of product design support
-- Comfortable having our project featured on our website and social media
-  channels
+- Comfortable having our project featured on our website and social media channels
 - Willing to share the project on their social media
 - Nice to have: in the sustainability, mobility, or education space
 
diff --git a/src/posts/2020-11-16-the-guide-to-making-remote-work-work.md b/src/posts/2020-11-16-the-guide-to-making-remote-work-work.md
index 04d2015cdd..a422efe6a4 100644
--- a/src/posts/2020-11-16-the-guide-to-making-remote-work-work.md
+++ b/src/posts/2020-11-16-the-guide-to-making-remote-work-work.md
@@ -3,9 +3,7 @@ title: "The guide to making remote work work"
 authorHandle: marcoow
 tags: process
 bio: "Founder and Managing Director of Mainmatter"
-description:
-  "Marco Otte-Witte shares insights gained in many years of successfully
-  operating Mainmatter as a fully remote company."
+description: "Marco Otte-Witte shares insights gained in many years of successfully operating Mainmatter as a fully remote company."
 og:
   image: /assets/images/posts/2020-11-16-the-guide-to-making-remote-work-work/og-image.jpg
 tagline: |
@@ -14,294 +12,87 @@ tagline: |
 
 ## Remotely happy
 
-There are plenty of reasons to adopt a remote working model. Employees get to
-choose where to live independently of where they work and save a lot of time and
-money on sometimes long commutes (which is also great for the climate – with all
-the focus currently being on Covid 19 we must not forget about the real
-existential crisis humanity is facing after all). Companies also benefit as they
-can attract the best talent from anywhere and are not limited in terms of who
-they can hire by their location.
-
-Yet, even as employees and companies alike are eager to adopt remote work and in
-theory all the required infrastructure and tools are available, it is still not
-easy to get right. Many teams and companies are struggling to go remote and
-yearn for the return of the days of the office. The reality is those days are
-not going to come back in many industries though and making remote work a
-success is going to be one of the key challenges many companies will be facing
-in the coming years.
-
-We have run Mainmatter as a remote company since the beginning. In the early
-days, we faced many of the same challenges other teams are struggling with now.
-Over time, we overcame each one, and learned a lot along the way. Today, we have
-team members in six countries across Europe with people working from co-working
-offices in Berlin, kitchens in Augsburg, sheds in Dublin, or even from a
-sailboat in Portugal. And we're not the only ones enjoying the many advantages
-of working remotely – 90% of remote workers say they plan to remain remote for
-the rest of their careers and 94% would even encourage others to work remotely
-as well according to
-[a study by Buffer](https://buffer.com/resources/state-remote-work-2018/) that
-was conducted in 2018.
+There are plenty of reasons to adopt a remote working model. Employees get to choose where to live independently of where they work and save a lot of time and money on sometimes long commutes (which is also great for the climate – with all the focus currently being on Covid 19 we must not forget about the real existential crisis humanity is facing after all). Companies also benefit as they can attract the best talent from anywhere and are not limited in terms of who they can hire by their location.
+
+Yet, even as employees and companies alike are eager to adopt remote work and in theory all the required infrastructure and tools are available, it is still not easy to get right. Many teams and companies are struggling to go remote and yearn for the return of the days of the office. The reality is those days are not going to come back in many industries though and making remote work a success is going to be one of the key challenges many companies will be facing in the coming years.
+
+We have run Mainmatter as a remote company since the beginning. In the early days, we faced many of the same challenges other teams are struggling with now. Over time, we overcame each one, and learned a lot along the way. Today, we have team members in six countries across Europe with people working from co-working offices in Berlin, kitchens in Augsburg, sheds in Dublin, or even from a sailboat in Portugal. And we're not the only ones enjoying the many advantages of working remotely – 90% of remote workers say they plan to remain remote for the rest of their careers and 94% would even encourage others to work remotely as well according to [a study by Buffer](https://buffer.com/resources/state-remote-work-2018/) that was conducted in 2018.
 
 ## A remote culture
 
-Adopting a remote working model does not necessarily have to mean for everyone
-to go remote immediately. It can of course be adopted completely and for
-everyone but also partially or incrementally as an option only while still
-keeping the office for everyone who likes to continue working from it. However,
-it is an all–or–nothing kind of change in terms of working culture regardless of
-how many team members will actually be working remotely. Remote work requires
-fundamentally different practices when it comes to collaboration and management
-and a lot of attention to aspects that are less relevant when the entire team
-works from the same location.
-
-Possibly the single most important of these aspects is transparency and the flow
-and sharing of information. While diagrams, concepts, or calendars pinned to the
-wall (or the sticky-notes sprint board that has turned into a status symbol for
-teams that "do agile" in the past years) are reasonable and probably good tools
-for sharing information among people that all work from the same location, in a
-remote environment, these practices don't work. All information shared in such
-ways will be completely invisible for everyone who is not in the office,
-excluding remote team members from participating in decision-making processes
-and preventing them from effectively contributing to the common goal.
+Adopting a remote working model does not necessarily have to mean for everyone to go remote immediately. It can of course be adopted completely and for everyone but also partially or incrementally as an option only while still keeping the office for everyone who likes to continue working from it. However, it is an all–or–nothing kind of change in terms of working culture regardless of how many team members will actually be working remotely. Remote work requires fundamentally different practices when it comes to collaboration and management and a lot of attention to aspects that are less relevant when the entire team works from the same location.
+
+Possibly the single most important of these aspects is transparency and the flow and sharing of information. While diagrams, concepts, or calendars pinned to the wall (or the sticky-notes sprint board that has turned into a status symbol for teams that "do agile" in the past years) are reasonable and probably good tools for sharing information among people that all work from the same location, in a remote environment, these practices don't work. All information shared in such ways will be completely invisible for everyone who is not in the office, excluding remote team members from participating in decision-making processes and preventing them from effectively contributing to the common goal.
 
 ![Burn down your sticky notes walls](/assets/images/posts/2020-11-16-the-guide-to-making-remote-work-work/burn-down-your-sticky-notes-walls.jpg#@1000-2000)
 
-While direct communication in the office is not something anyone should
-prohibit, all the information and decisions that are made in any conversations
-must be made transparent to the entire team. Writing summaries and protocols of
-face-to-face conversations or communicating via a chat tool although sitting at
-the desk next to the person one is having a conversation with feels strange in
-the beginning. It is however a necessary prerequisite for making remote work
-work at all and failing to do it properly will alienate remote teammates. In
-that way, the pandemic that forced teams to go fully remote all at once at the
-same time might even have made the transition easier rather than harder for them
-because everyone was in the same position and shared the same perspective.
+While direct communication in the office is not something anyone should prohibit, all the information and decisions that are made in any conversations must be made transparent to the entire team. Writing summaries and protocols of face-to-face conversations or communicating via a chat tool although sitting at the desk next to the person one is having a conversation with feels strange in the beginning. It is however a necessary prerequisite for making remote work work at all and failing to do it properly will alienate remote teammates. In that way, the pandemic that forced teams to go fully remote all at once at the same time might even have made the transition easier rather than harder for them because everyone was in the same position and shared the same perspective.
 
 ### Cultivating Trust
 
-Another very important cultural aspect to consider when a team goes fully or
-partly remote is trust. Many managers' first reaction, when faced with their
-teams working remotely, is asking
+Another very important cultural aspect to consider when a team goes fully or partly remote is trust. Many managers' first reaction, when faced with their teams working remotely, is asking
 
 _"How can I know my team actually works when everyone is sitting at home?"_
 
-Just because managers cannot **see** the work happening does not mean it does
-not happen. Managers' desire to micro-manage teams is an equally bad habit
-regardless of whether the team is remote or not – yet, remote teams seem to
-increase that desire, often resulting in managers being on everyone's back
-constantly and consistently even more than with all of the team working from the
-office. However, the occasional check-in for a status update is just as
-interruptive remotely as it is in the office.
+Just because managers cannot **see** the work happening does not mean it does not happen. Managers' desire to micro-manage teams is an equally bad habit regardless of whether the team is remote or not – yet, remote teams seem to increase that desire, often resulting in managers being on everyone's back constantly and consistently even more than with all of the team working from the office. However, the occasional check-in for a status update is just as interruptive remotely as it is in the office.
 
 ![Direct messages are interruptive and keep people from working](/assets/images/posts/2020-11-16-the-guide-to-making-remote-work-work/slack.png#@1000-2000)
 
-The reality is that remote workers are likely more productive rather than less
-as they will find it easier to focus and be less stressed according to the
-[State of Remote Work 2019 report by OWLLabs](https://www.owllabs.com/hubfs/Owl%20Labs%202019%20State%20of%20Remote%20Work%20Report%20PDF.pdf).
-Building up that trust and allowing people uninterrupted time to focus while
-giving up on micro-management practices is going to be a task for many managers
-to learn over the next years.
+The reality is that remote workers are likely more productive rather than less as they will find it easier to focus and be less stressed according to the [State of Remote Work 2019 report by OWLLabs](https://www.owllabs.com/hubfs/Owl%20Labs%202019%20State%20of%20Remote%20Work%20Report%20PDF.pdf). Building up that trust and allowing people uninterrupted time to focus while giving up on micro-management practices is going to be a task for many managers to learn over the next years.
 
 ## Infrastructure and tooling
 
-Working remotely requires adapting a number of infrastructure and tooling. There
-are a plethora of great tools available and many companies are even using some
-of them already. Which exact tools a team uses is not even so relevant and there
-are plenty of options available – mostly those fall into three categories:
+Working remotely requires adapting a number of infrastructure and tooling. There are a plethora of great tools available and many companies are even using some of them already. Which exact tools a team uses is not even so relevant and there are plenty of options available – mostly those fall into three categories:
 
 - tools for ad-hoc, real-time communication
 - tools for knowledge management and sharing
 - tools for organizing work and communicating status
 
-While it is important to have tools for all of these use cases, it is equally
-important to keep the total number of tools in use to a minimum to prevent
-chaos. There is always going to be the new hip tool that everyone wants to try
-and doing so often silently makes that new tool part of the de-facto toolset a
-team uses, growing that little by little over time. Eventually, teams then end
-up with entire landscapes of tools, where nobody knows what kind of information
-goes where and although each tool is perfectly good in isolation, in combination
-they cause more confusion than they support the team.
+While it is important to have tools for all of these use cases, it is equally important to keep the total number of tools in use to a minimum to prevent chaos. There is always going to be the new hip tool that everyone wants to try and doing so often silently makes that new tool part of the de-facto toolset a team uses, growing that little by little over time. Eventually, teams then end up with entire landscapes of tools, where nobody knows what kind of information goes where and although each tool is perfectly good in isolation, in combination they cause more confusion than they support the team.
 
 ### Tools for ad-hoc, real-time communication
 
-Team chat tools like Slack (or Microsoft Teams for the more classic companies)
-have seen widespread adoption over the past years and there are only a few
-companies that don't use any of those at this point. They have developed into
-the backbone for remote work for many teams. While in an office environment,
-sending someone or a group of people a chat message saves you having to walk
-over to a separate room or building, in a remote environment it is the **only**
-way to reach out to someone directly (unless you call the person but who does
-phone calls anymore?). What's easy to forget is how interruptive these tools can
-be. Sending someone a chat message always implies urgency. Even if we all know
-the majority of chat messages we get are in fact not urgent, it's hard to ignore
-someone who just starts talking (writing) to you.
-
-While most remote workers experience it is easier to focus, a liberal
-communication style on team chat can demolish a lot of that increased focus
-again. For effective communication, it is important to be respectful of other
-people's time and need to focus on their work. Not everything is urgent all of
-the time and justifies notifying a coworker or even a group of people. The fact
-that you feel like you need something now doesn't necessarily mean someone else
-should stop what they are currently doing to answer you. In many cases, sending
-a good old email that is going to be less intrusive and more respectful of the
-recipient's time is the better communication option compared to sending the
-person a message on team chat asking for something that could totally wait until
-tomorrow as well.
-
-At the same time, it is important to keep people in the loop and ensure
-transparency of communication when using any kind of communication tool.
-Communication that happens via direct messages between two people is invisible
-to everyone else, while it might actually be relevant to others as well. As a
-rule of thumb, we recommend keeping everything in public channels unless the
-topic is strictly confidential or private in nature.
-
-Although the information in public channels will be accessible to everyone, it
-is important to understand any real-time communication tool is essentially
-ephemeral in nature. While that is not technically correct and most tools do in
-fact store all communication indefinitely, even with built-in search
-functionality it is practically impossible to find a piece of information you
-are looking for that was discussed for example in some Slack channel (you likely
-don't even remember which one) the day before. So while team chat is a good
-mechanism to communicate among the team in a low effort, informal way, any
-information or decisions that are made via it need to eventually make their way
-into other, more permanent, and organized systems.
+Team chat tools like Slack (or Microsoft Teams for the more classic companies) have seen widespread adoption over the past years and there are only a few companies that don't use any of those at this point. They have developed into the backbone for remote work for many teams. While in an office environment, sending someone or a group of people a chat message saves you having to walk over to a separate room or building, in a remote environment it is the **only** way to reach out to someone directly (unless you call the person but who does phone calls anymore?). What's easy to forget is how interruptive these tools can be. Sending someone a chat message always implies urgency. Even if we all know the majority of chat messages we get are in fact not urgent, it's hard to ignore someone who just starts talking (writing) to you.
+
+While most remote workers experience it is easier to focus, a liberal communication style on team chat can demolish a lot of that increased focus again. For effective communication, it is important to be respectful of other people's time and need to focus on their work. Not everything is urgent all of the time and justifies notifying a coworker or even a group of people. The fact that you feel like you need something now doesn't necessarily mean someone else should stop what they are currently doing to answer you. In many cases, sending a good old email that is going to be less intrusive and more respectful of the recipient's time is the better communication option compared to sending the person a message on team chat asking for something that could totally wait until tomorrow as well.
+
+At the same time, it is important to keep people in the loop and ensure transparency of communication when using any kind of communication tool. Communication that happens via direct messages between two people is invisible to everyone else, while it might actually be relevant to others as well. As a rule of thumb, we recommend keeping everything in public channels unless the topic is strictly confidential or private in nature.
+
+Although the information in public channels will be accessible to everyone, it is important to understand any real-time communication tool is essentially ephemeral in nature. While that is not technically correct and most tools do in fact store all communication indefinitely, even with built-in search functionality it is practically impossible to find a piece of information you are looking for that was discussed for example in some Slack channel (you likely don't even remember which one) the day before. So while team chat is a good mechanism to communicate among the team in a low effort, informal way, any information or decisions that are made via it need to eventually make their way into other, more permanent, and organized systems.
 
 #### Video Conferencing
 
-Besides text-based communication systems, of course, video conferences play a
-major role in remote work as well. That way of communication has seen a huge
-boost in adoption during the pandemic with everyone isolating at home and many
-people using video calls for the first time even (I'm sure everyone had their
-_"Dad, the camera is pointing on the floor"_ moments). While late adopters
-expectedly struggled with the technology, many remote teams experience similar
-problems during their daily work lives. Poor audio or video quality, dogs
-barking in the background, calls starting 10min late until everyone has figured
-out their setup, etc. are common problems for many teams and have a severe
-negative effect on meeting efficiency.
-
-All these problems are easy to prevent when following a number of simple
-practices:
-
-- There needs to be proper audio and video hardware in place. For two or more
-  people joining a call together that means a proper conference speaker that
-  ensures people on the other end will be able to hear everyone in the room even
-  if more than one person speaks at the same time and ideally a wall-mounted
-  webcam that shows the entire room. For people joining individually, it means
-  they must use headsets that ensure good audio quality and do not also capture
-  all of their surroundings.
-- Turning cameras on so people can see each other makes a big difference in
-  communication style – seeing someone's facial expression when they say
-  something can often prevent misinterpreting what they are saying. And people
-  can still be as slovenly as they like – dressing the upper body is totally
-  enough for a video call after all.
-- Muting yourself when you're not speaking is good practice but don't forget to
-  unmute yourself when you want to say something – luckily most platforms have
-  notifications now that warn people if they are speaking while being muted.
-- Choosing an appropriate place for joining calls is a matter of respect for the
-  other participants. While joining from a nice café or the beach might seem
-  like a good idea, it is likely distracting for everyone else who will be
-  exposed to the background noises, people walking around in the periphery,
-  waiters interrupting, etc.
+Besides text-based communication systems, of course, video conferences play a major role in remote work as well. That way of communication has seen a huge boost in adoption during the pandemic with everyone isolating at home and many people using video calls for the first time even (I'm sure everyone had their _"Dad, the camera is pointing on the floor"_ moments). While late adopters expectedly struggled with the technology, many remote teams experience similar problems during their daily work lives. Poor audio or video quality, dogs barking in the background, calls starting 10min late until everyone has figured out their setup, etc. are common problems for many teams and have a severe negative effect on meeting efficiency.
+
+All these problems are easy to prevent when following a number of simple practices:
+
+- There needs to be proper audio and video hardware in place. For two or more people joining a call together that means a proper conference speaker that ensures people on the other end will be able to hear everyone in the room even if more than one person speaks at the same time and ideally a wall-mounted webcam that shows the entire room. For people joining individually, it means they must use headsets that ensure good audio quality and do not also capture all of their surroundings.
+- Turning cameras on so people can see each other makes a big difference in communication style – seeing someone's facial expression when they say something can often prevent misinterpreting what they are saying. And people can still be as slovenly as they like – dressing the upper body is totally enough for a video call after all.
+- Muting yourself when you're not speaking is good practice but don't forget to unmute yourself when you want to say something – luckily most platforms have notifications now that warn people if they are speaking while being muted.
+- Choosing an appropriate place for joining calls is a matter of respect for the other participants. While joining from a nice café or the beach might seem like a good idea, it is likely distracting for everyone else who will be exposed to the background noises, people walking around in the periphery, waiters interrupting, etc.
 
 ### Tools for knowledge management and sharing
 
-Knowledge and information management is critical for every team and as mentioned
-previously access to all relevant information and transparency for everyone is
-essential for successful remote teams. Tools for that like Notion, Confluence or
-Basecamp allow collaboratively creating, sharing, and keeping relevant
-information. They are the remote equivalents of whiteboards and the place where
-feature descriptions or strategy documents live. They must allow everyone to
-contribute to the information, have versioning so people can understand who made
-what change when, and have commenting functionality so that people can have
-discussions about the content.
+Knowledge and information management is critical for every team and as mentioned previously access to all relevant information and transparency for everyone is essential for successful remote teams. Tools for that like Notion, Confluence or Basecamp allow collaboratively creating, sharing, and keeping relevant information. They are the remote equivalents of whiteboards and the place where feature descriptions or strategy documents live. They must allow everyone to contribute to the information, have versioning so people can understand who made what change when, and have commenting functionality so that people can have discussions about the content.
 
 ### Tools for organizing work and communicating status
 
-Tools that track individual work items are the main means of organizing work
-among remote teams and clearly communicate the status of each item to everyone.
-Options for such tools include Trello, Jira as well as even GitHub or GitLab.
-They are not for tracking individual team members' progress and performance but
-help teams synchronize. Properly describing the work each item represents,
-keeping its status up to date as well as linking relevant information and
-decisions to the respective item are essential practices to allow teams to
-understand what others are working on and how that might influence what every
-team member does.
+Tools that track individual work items are the main means of organizing work among remote teams and clearly communicate the status of each item to everyone. Options for such tools include Trello, Jira as well as even GitHub or GitLab. They are not for tracking individual team members' progress and performance but help teams synchronize. Properly describing the work each item represents, keeping its status up to date as well as linking relevant information and decisions to the respective item are essential practices to allow teams to understand what others are working on and how that might influence what every team member does.
 
 ### The three A's
 
-Whenever switching from a working model that is focussed around an office to a
-remote one that will be entirely based on cloud-based tools, it is important to
-keep what I'd call the three A's in mind:
-
-- **Accessibility**: tools being accessible to everyone who needs them might
-  sound trivial but in reality is often a bigger issue than one might think.
-  People are struggling with remembering URLs or accounts for tools or VPNs
-  might be unstable. And of course accessibility for people with special needs
-  is critical as well to not exclude entire groups of people entirely. Anyone
-  who is not able to access a particular tool is effectively blocked from
-  contributing their work altogether.
-- **Availability**: any set of tools a team might choose must also be available.
-  The tools a team uses constitute its backbone and if they are not available
-  for some reason, the entire team will be blocked from doing any work. While
-  many companies desire to self-host everything in an effort to be on top of
-  their infrastructure, in my experience that's often the worst choice and leads
-  to friction and people being blocked – unless you're a company that
-  specializes in hosting these kinds of tools, you'll likely do a much worse job
-  doing so than any third party provider you'd be paying to host things for you!
-- **Acceptance**: in particular teams and companies that adopt remote work and
-  the respective tools relatively new often struggle with a lack of acceptance
-  of these tools among the team. People would sometimes stick to their old
-  habits, bypassing the tools, and by that add lots of friction for everyone
-  else. It is critical for every member of a remote team to understand that
-  opting out of using the tools that are put in place means opting out of
-  collaboration altogether and not only poses an annoyance for coworkers but
-  also directly hurts the entire team's productivity.
+Whenever switching from a working model that is focussed around an office to a remote one that will be entirely based on cloud-based tools, it is important to keep what I'd call the three A's in mind:
+
+- **Accessibility**: tools being accessible to everyone who needs them might sound trivial but in reality is often a bigger issue than one might think. People are struggling with remembering URLs or accounts for tools or VPNs might be unstable. And of course accessibility for people with special needs is critical as well to not exclude entire groups of people entirely. Anyone who is not able to access a particular tool is effectively blocked from contributing their work altogether.
+- **Availability**: any set of tools a team might choose must also be available. The tools a team uses constitute its backbone and if they are not available for some reason, the entire team will be blocked from doing any work. While many companies desire to self-host everything in an effort to be on top of their infrastructure, in my experience that's often the worst choice and leads to friction and people being blocked – unless you're a company that specializes in hosting these kinds of tools, you'll likely do a much worse job doing so than any third party provider you'd be paying to host things for you!
+- **Acceptance**: in particular teams and companies that adopt remote work and the respective tools relatively new often struggle with a lack of acceptance of these tools among the team. People would sometimes stick to their old habits, bypassing the tools, and by that add lots of friction for everyone else. It is critical for every member of a remote team to understand that opting out of using the tools that are put in place means opting out of collaboration altogether and not only poses an annoyance for coworkers but also directly hurts the entire team's productivity.
 
 ## Distributed together
 
-A challenge that many people adopting remote work face is loneliness. 20% of
-remote workers say they feel lonely occasionally according to a the latest
-[State of Remote Work report by Buffer (2020)](https://lp.buffer.com/state-of-remote-work-2020).
-Also working from their homes is not for everyone and some people need a clear
-separation between their work and private environments or want to be among
-others during the day. However, a remote working model does not necessarily
-require everyone to work alone or from their homes. Teams can still have an
-optional office or people could work from coworking locations where they are
-surrounded by others although those people might not be their immediate
-teammates. After all, remote work is all about options, not about forcing a
-particular working environment on anyone. At Mainmatter, we give everyone the
-freedom to choose the work location that is best for them and the only things we
-ask for are to ensure a proper internet connection and for everyone to be in
-similar timezones – other companies with a less collaborative working style
-might not even require that and would sometimes allow people to work from
-anywhere on earth really.
-
-Besides everyone feeling comfortable about their individual work environments,
-it is also important to keep up a feeling of belonging together and, in fact,
-being part of one team although everyone is physically distributed. As everyone
-experienced firsthand throughout the pandemic, video calls are not the same as
-direct, face-to-face interaction. In our experience, it is essential for
-everyone to meet each other in the same location at least twice per year. We
-organize team building events where we all come together for a day or two and do
-something nice together. These events are not about work since all of that can
-be done remotely as well – we use them purely to enable direct social
-interaction and keep up our notion of belonging together. Other companies do
-similar things, sometimes flying in hundreds of people from all across the
-globe. While that implies substantial cost, that cost is paid back manifold
-through a boosted team spirit that makes people enjoy work more, relate to their
-teammates and their individual situations, and finally making collaboration
-smoother and more efficient.
+A challenge that many people adopting remote work face is loneliness. 20% of remote workers say they feel lonely occasionally according to a the latest [State of Remote Work report by Buffer (2020)](https://lp.buffer.com/state-of-remote-work-2020). Also working from their homes is not for everyone and some people need a clear separation between their work and private environments or want to be among others during the day. However, a remote working model does not necessarily require everyone to work alone or from their homes. Teams can still have an optional office or people could work from coworking locations where they are surrounded by others although those people might not be their immediate teammates. After all, remote work is all about options, not about forcing a particular working environment on anyone. At Mainmatter, we give everyone the freedom to choose the work location that is best for them and the only things we ask for are to ensure a proper internet connection and for everyone to be in similar timezones – other companies with a less collaborative working style might not even require that and would sometimes allow people to work from anywhere on earth really.
+
+Besides everyone feeling comfortable about their individual work environments, it is also important to keep up a feeling of belonging together and, in fact, being part of one team although everyone is physically distributed. As everyone experienced firsthand throughout the pandemic, video calls are not the same as direct, face-to-face interaction. In our experience, it is essential for everyone to meet each other in the same location at least twice per year. We organize team building events where we all come together for a day or two and do something nice together. These events are not about work since all of that can be done remotely as well – we use them purely to enable direct social interaction and keep up our notion of belonging together. Other companies do similar things, sometimes flying in hundreds of people from all across the globe. While that implies substantial cost, that cost is paid back manifold through a boosted team spirit that makes people enjoy work more, relate to their teammates and their individual situations, and finally making collaboration smoother and more efficient.
 
 ![Spending time together physically is extra important when everyone is distributed](/assets/images/posts/2020-11-16-the-guide-to-making-remote-work-work/oktoberfest.jpg#@1000-2000)
 
-These kinds of events are not possible during the pandemic unfortunately. And
-while there is no substitute for these events we need not despair. There are
-plenty of alternatives that help us all to get through these times with our
-personal environment and similar things can be done in the professional
-environment as well. Options start with regular calls with the entire team so
-that everyone sees each other every now and then, even if it's just on camera.
-It doesn't need to stop there though – you can do virtual drink-ups, game
-sessions, hackathons, and plenty of other activities. These are invaluable for
-making sure teams don't forget the faces and people behind the screen names they
-interact with during work. And when we can, we'll all meet our friends as well
-as our coworkers again and celebrate together 🎉.
+These kinds of events are not possible during the pandemic unfortunately. And while there is no substitute for these events we need not despair. There are plenty of alternatives that help us all to get through these times with our personal environment and similar things can be done in the professional environment as well. Options start with regular calls with the entire team so that everyone sees each other every now and then, even if it's just on camera. It doesn't need to stop there though – you can do virtual drink-ups, game sessions, hackathons, and plenty of other activities. These are invaluable for making sure teams don't forget the faces and people behind the screen names they interact with during work. And when we can, we'll all meet our friends as well as our coworkers again and celebrate together 🎉.
diff --git a/src/posts/2020-12-15-building-prototypes-with-emberjs-and-ember-hotspots.md b/src/posts/2020-12-15-building-prototypes-with-emberjs-and-ember-hotspots.md
index 0b30b51d8e..a4c1819e61 100644
--- a/src/posts/2020-12-15-building-prototypes-with-emberjs-and-ember-hotspots.md
+++ b/src/posts/2020-12-15-building-prototypes-with-emberjs-and-ember-hotspots.md
@@ -3,9 +3,7 @@ title: "Building prototypes with Ember.js"
 authorHandle: pichfl
 tags: ember
 bio: "Consultant for Design & Technology"
-description:
-  "Create click dummies and prototypes that can grow over your initial ideas
-  with ease and the full force of the Ember.js ecosystem."
+description: "Create click dummies and prototypes that can grow over your initial ideas with ease and the full force of the Ember.js ecosystem."
 og:
   image: /assets/images/posts/2020-12-15-building-prototypes-with-emberjs-and-ember-hotspots/og-image.jpg
 tagline: |
@@ -16,82 +14,45 @@ tagline: |
 
 In short, we are talking about adding interaction to static images.
 
-You lay out a background layer image which provides the overall look for the
-idea you want to present and add as many interactive elements on top of that. As
-most designs are centered in the browser, it would be nice to start out with a
-centered background. It would also be great to be able to show and hide elements
-on the fly. Also it is important that all images are loaded before you start
-navigating the demo so it doesn't look broken.
+You lay out a background layer image which provides the overall look for the idea you want to present and add as many interactive elements on top of that. As most designs are centered in the browser, it would be nice to start out with a centered background. It would also be great to be able to show and hide elements on the fly. Also it is important that all images are loaded before you start navigating the demo so it doesn't look broken.
 
-Thankfully, all of the above should be and in fact is achievable in a new
-Ember.js addon.
+Thankfully, all of the above should be and in fact is achievable in a new Ember.js addon.
 
 ### Steps involved
 
 1. Creating a new ember-cli addon
 2. Finding and preloading all images necessary for your prototype
 3. Creating a component for backgrounds providing a canvas for your prototype
-4. Creating a component for hotspots which can be used to trigger actions or
-   navigate to other pages
+4. Creating a component for hotspots which can be used to trigger actions or navigate to other pages
 5. Combining everything into a demo application
 
 ### Creating a new ember-cli addon
 
-The [ember-cli](https://github.com/ember-cli/ember-cli) makes
-[creating a new addon](https://cli.emberjs.com/release/writing-addons/intro-tutorial/)
-straight forward.
+The [ember-cli](https://github.com/ember-cli/ember-cli) makes [creating a new addon](https://cli.emberjs.com/release/writing-addons/intro-tutorial/) straight forward.
 
-I prefer using yarn for package management, I'll add the `--yarn` flag when
-running the ember-cli command.
+I prefer using yarn for package management, I'll add the `--yarn` flag when running the ember-cli command.
 
 ```shell
 ember addon ember-hotspots --yarn
 ```
 
-Details of this process can be read up in the tutorial, we'll use the included
-`dummy` application to play with the things we build and start generating our
-first component straight away.
+Details of this process can be read up in the tutorial, we'll use the included `dummy` application to play with the things we build and start generating our first component straight away.
 
 ### Finding and preloading images
 
-To ensure that a demo runs successfully and a potential user doesn't end up with
-blank spaces or slow loading or missing images, it is necessary to preload all
-necessary images. It also helps to know the image dimensions beforehand so the
-browser can reserve screen space for them. The latter also allows creating
-hotspots or overlays that are sized by their image content.
-
-My initial approach to this is creating a JSON file at build time which contains
-paths and sizes of all images relevant to the hotspots. This allows me to load
-the images as needed, gives me metadata ahead of their load and allows me to
-verify that the image files referenced in the hotspots do exist in case I need
-to detect spelling errors or wrongly named files.
-
-Even though using Ember.js on a daily basis, I rarely dig into the deeper
-plumbing behind the scenes of ember-cli and it's Broccoli build pipeline. This
-project allowed me to get a first introduction into the finer details.
-
-While it did look complex at first, Broccoli turned out to be approachable, as
-long as you can navigate the code and work by looking at other plugins and
-addons. The docs are there, even for
-[creating plugins yourself](https://broccoli.build/plugins.html#example-plugin),
-but it's always hard
-[to draw the rest of the owl](https://knowyourmeme.com/memes/how-to-draw-an-owl).
-
-Broccoli works by creating file trees and filtering them through funnels. It
-relies on the actual file system. Generating new files into your app comes down
-to using the default Node.js APIs. Ha! I know these! Off to a good start.
-
-I ended up building a small Broccoli plugin that uses
-[walk-sync](https://www.npmjs.com/package/walk-sync) to find images in the
-public folder and applies [image-size](https://www.npmjs.com/package/image-size)
-to retrieve the actual file dimensions which is then written into a mapping
-file. Much like with iOS development I detect if the filename ends in `@2x` and
-return only half the actual width and height of those images for a crisper
-experience on high resolution screens like most mobile displays.
-
-The resulting JSON is passed into the public folder of the consuming application
-and can be fetched by a service that manages global state for the individual
-hotspots and backgrounds.
+To ensure that a demo runs successfully and a potential user doesn't end up with blank spaces or slow loading or missing images, it is necessary to preload all necessary images. It also helps to know the image dimensions beforehand so the browser can reserve screen space for them. The latter also allows creating hotspots or overlays that are sized by their image content.
+
+My initial approach to this is creating a JSON file at build time which contains paths and sizes of all images relevant to the hotspots. This allows me to load the images as needed, gives me metadata ahead of their load and allows me to verify that the image files referenced in the hotspots do exist in case I need to detect spelling errors or wrongly named files.
+
+Even though using Ember.js on a daily basis, I rarely dig into the deeper plumbing behind the scenes of ember-cli and it's Broccoli build pipeline. This project allowed me to get a first introduction into the finer details.
+
+While it did look complex at first, Broccoli turned out to be approachable, as long as you can navigate the code and work by looking at other plugins and addons. The docs are there, even for [creating plugins yourself](https://broccoli.build/plugins.html#example-plugin), but it's always hard [to draw the rest of the owl](https://knowyourmeme.com/memes/how-to-draw-an-owl).
+
+Broccoli works by creating file trees and filtering them through funnels. It relies on the actual file system. Generating new files into your app comes down to using the default Node.js APIs. Ha! I know these! Off to a good start.
+
+I ended up building a small Broccoli plugin that uses [walk-sync](https://www.npmjs.com/package/walk-sync) to find images in the public folder and applies [image-size](https://www.npmjs.com/package/image-size) to retrieve the actual file dimensions which is then written into a mapping file. Much like with iOS development I detect if the filename ends in `@2x` and return only half the actual width and height of those images for a crisper experience on high resolution screens like most mobile displays.
+
+The resulting JSON is passed into the public folder of the consuming application and can be fetched by a service that manages global state for the individual hotspots and backgrounds.
 
 ```js
 {% raw %}
@@ -119,13 +80,9 @@ module.exports = class SizeUpImages extends Plugin {
 
 #### Notes on the process
 
-Going down this path made me realize that the addons `index.js` is just a small
-module that is executed by Node.js, meaning you can reach for anything that
-works in other node modules as well.
+Going down this path made me realize that the addons `index.js` is just a small module that is executed by Node.js, meaning you can reach for anything that works in other node modules as well.
 
-The `contentFor()` hook inside an Ember addon runs on initial startup only, the
-experience is about the same as with ember-cli-build.js changes that require a
-restart. This hook is helpful if you want to push things to your index.html.
+The `contentFor()` hook inside an Ember addon runs on initial startup only, the experience is about the same as with ember-cli-build.js changes that require a restart. This hook is helpful if you want to push things to your index.html.
 
 ```js
 {% raw %}
@@ -170,24 +127,13 @@ module.exports = {
 
 ### Building the components
 
-The addon will provide two main building blocks which can be used to diplay an
-image and add interactive areas to it.
+The addon will provide two main building blocks which can be used to diplay an image and add interactive areas to it.
 
-One for inert backgrounds which can act as a container and show a large image
-that is commonly horizontally centered, allowing designers to provide mockups
-with extended background design on each side so the mockup doesn't look cut off
-when resizing the browser.
+One for inert backgrounds which can act as a container and show a large image that is commonly horizontally centered, allowing designers to provide mockups with extended background design on each side so the mockup doesn't look cut off when resizing the browser.
 
-Another for interactive hotspots that can be layed out and moved about relative
-to a background.
+Another for interactive hotspots that can be layed out and moved about relative to a background.
 
-`<EhBackground />` provides the background images. Reading from the image map we
-generated above it also checks if you are referencing an existing image and
-warns if no match was found. The component is otherwise quite simple. It
-generates a wrapping `<div>` with a custom `style` attribute which contains the
-`background-image` url as well as two CSS custom properties for `width` and
-`height` of the container. Using CSS custom properties allows easy access to the
-width when styling child elements of this component.
+`<EhBackground />` provides the background images. Reading from the image map we generated above it also checks if you are referencing an existing image and warns if no match was found. The component is otherwise quite simple. It generates a wrapping `<div>` with a custom `style` attribute which contains the `background-image` url as well as two CSS custom properties for `width` and `height` of the container. Using CSS custom properties allows easy access to the width when styling child elements of this component.
 
 ```hbs
 {% raw %}
@@ -227,31 +173,15 @@ export default class EHBackgroundComponent extends Component {
 }
 ```
 
-`<EhHotspot />` is a little more complex, mostly because I wanted to cover some
-common use cases out of the box. One neat aspect is the positioning, which is
-done relative to the centered background image and relies on the inherited CSS
-custom properties and `calc()` instead of manually setting values with
-JavaScript.
+`<EhHotspot />` is a little more complex, mostly because I wanted to cover some common use cases out of the box. One neat aspect is the positioning, which is done relative to the centered background image and relies on the inherited CSS custom properties and `calc()` instead of manually setting values with JavaScript.
 
-Hotspots accept multiple arguments. You can pass a route name (as a string) to
-make them transition to a new route. You can pass an `@action` to make them
-trigger that action. You can also adjust the trigger event (which defaults to
-`click`) and even use a custom `hover` trigger to create hover effects in your
-mockup.
+Hotspots accept multiple arguments. You can pass a route name (as a string) to make them transition to a new route. You can pass an `@action` to make them trigger that action. You can also adjust the trigger event (which defaults to `click`) and even use a custom `hover` trigger to create hover effects in your mockup.
 
-Using a global service, all hotspots also get a special CSS class name in case
-you click and hold anywhere on the page. This is used with a CSS animation to
-visualize all hotspots on a page by highlighting them blue after a short
-interval.
+Using a global service, all hotspots also get a special CSS class name in case you click and hold anywhere on the page. This is used with a CSS animation to visualize all hotspots on a page by highlighting them blue after a short interval.
 
-You can use the `(array)` helper to pass in coordinates to a hotspot like so:
-`@rect=(array 0 0)`. Just like the background, the component will also validate
-passed in image `@src` against the generated asset list. While hotspots do not
-necessarily require an image to work, adding an image makes them more versatile.
+You can use the `(array)` helper to pass in coordinates to a hotspot like so: `@rect=(array 0 0)`. Just like the background, the component will also validate passed in image `@src` against the generated asset list. While hotspots do not necessarily require an image to work, adding an image makes them more versatile.
 
-All that's necessary to implement such an effect is a `@tracked` property that
-is read by all hotspots and is set to `true` when a global `mousedown` event is
-detected and `false` on the corresponding `mouseup`.
+All that's necessary to implement such an effect is a `@tracked` property that is read by all hotspots and is set to `true` when a global `mousedown` event is detected and `false` on the corresponding `mouseup`.
 
 ```hbs
 {% raw %}
@@ -347,36 +277,16 @@ export default class EHHotspotComponent extends Component {
 {% endraw %}
 ```
 
-This is the resulting code for a small and simple click dummy. It uses
-[ember-truth-helpers](https://github.com/jmurphyau/ember-truth-helpers), which
-allows us to apply some logic directly in the templates.
+This is the resulting code for a small and simple click dummy. It uses [ember-truth-helpers](https://github.com/jmurphyau/ember-truth-helpers), which allows us to apply some logic directly in the templates.
 
-It opens a menu that only appears when clicking on the menu button (which is
-part of the background image). It also has two hotspots that show an image when
-hovering over them.
+It opens a menu that only appears when clicking on the menu button (which is part of the background image). It also has two hotspots that show an image when hovering over them.
 
-Next step for this mockup would be to add `@route` arguments to the buttons so
-they not only have a hover effect, but also navigate to a new page with a
-different `<EhBackground />` and more functionality.
+Next step for this mockup would be to add `@route` arguments to the buttons so they not only have a hover effect, but also navigate to a new page with a different `<EhBackground />` and more functionality.
 
-For further inspiration look at
-[the dummy application](https://mainmatter.github.io/ember-hotspots/) that is
-part of the [ember-hotspots](https://github.com/mainmatter/ember-hotspots).
+For further inspiration look at [the dummy application](https://mainmatter.github.io/ember-hotspots/) that is part of the [ember-hotspots](https://github.com/mainmatter/ember-hotspots).
 
-The resulting Ember.js addon shows how little code is necessary to bring ideas
-to live thanks to the tools that make up the Ember.js ecosystem. There is a lot
-of potential in this concept beyond just small small click dummies. I want to
-explore the options of including this into existing applications and maybe even
-add support for animations in the future.
+The resulting Ember.js addon shows how little code is necessary to bring ideas to live thanks to the tools that make up the Ember.js ecosystem. There is a lot of potential in this concept beyond just small small click dummies. I want to explore the options of including this into existing applications and maybe even add support for animations in the future.
 
 ### To be continued…
 
-Is a custom Broccoli plugin the right way to build this tool? Maybe. There are
-multiple existing and battle tested addons which provide building blocks for all
-steps necessary. There is
-[ember-cli-ifa](https://github.com/adopted-ember-addons/ember-cli-ifa) which
-gives your app a fingerprinted list of all your assets, including any images.
-[ember-cli-workbox](https://github.com/BBVAEngineering/ember-cli-workbox) allows
-preloading assets via service workers. The options for improvements without
-requiring any user of this addon to change their workflow or even adjust their
-own code is one of the more powerful aspects of the Ember.js ecosystem.
+Is a custom Broccoli plugin the right way to build this tool? Maybe. There are multiple existing and battle tested addons which provide building blocks for all steps necessary. There is [ember-cli-ifa](https://github.com/adopted-ember-addons/ember-cli-ifa) which gives your app a fingerprinted list of all your assets, including any images. [ember-cli-workbox](https://github.com/BBVAEngineering/ember-cli-workbox) allows preloading assets via service workers. The options for improvements without requiring any user of this addon to change their workflow or even adjust their own code is one of the more powerful aspects of the Ember.js ecosystem.
diff --git a/src/posts/2020-12-31-xml-and-rust.md b/src/posts/2020-12-31-xml-and-rust.md
index a83cdaa1a7..20ca46338e 100644
--- a/src/posts/2020-12-31-xml-and-rust.md
+++ b/src/posts/2020-12-31-xml-and-rust.md
@@ -9,25 +9,15 @@ tagline: |
   <p>Last week we spent some time researching the current state of <a href="https://en.wikipedia.org/wiki/XML">XML</a> parsing and writing in the <a href="https://www.rust-lang.org">Rust</a> ecosystem. For a small side project we needed to read an XML file and turn its content into regular Rust <code>structs</code>. This blog post is a summary of what approaches we looked into, their tradeoffs and what we finally decided to use.</p>
 ---
 
-The first thing we did when researching this topic was to go to [crates.io] and
-search for "XML". The first result is the [`xml`](https://crates.io/crates/xml)
-crate, but with only one v0.0.1 release and not a lot of downloads that didn't
-seem like a good candidate. Looking further there was also
-[`xml-rs`](https://crates.io/crates/xml-rs) with 4 million downloads total. That
-seemed more encouraging so we looked into it.
+The first thing we did when researching this topic was to go to [crates.io] and search for "XML". The first result is the [`xml`](https://crates.io/crates/xml) crate, but with only one v0.0.1 release and not a lot of downloads that didn't seem like a good candidate. Looking further there was also [`xml-rs`](https://crates.io/crates/xml-rs) with 4 million downloads total. That seemed more encouraging so we looked into it.
 
 [crates.io]: https://crates.io
 
-The README of `xml-rs` says that it was inspired by the "Java Streaming API for
-XML (StAX)" and that it contains a "pull parser". What does that mean? 🤔
+The README of `xml-rs` says that it was inspired by the "Java Streaming API for XML (StAX)" and that it contains a "pull parser". What does that mean? 🤔
 
 ## Streaming XML Events
 
-Generally, there are two different ways of parsing XML, and in Rust there are
-actually three, all of which we will try to explain in this post. The first one,
-and the one that all the others are built upon, is the event stream approach. In
-this case the parser looks at the XML file character by character and triggers
-events after certain things have been read. Let's look at a quick example:
+Generally, there are two different ways of parsing XML, and in Rust there are actually three, all of which we will try to explain in this post. The first one, and the one that all the others are built upon, is the event stream approach. In this case the parser looks at the XML file character by character and triggers events after certain things have been read. Let's look at a quick example:
 
 ```xml
 <DocumentElement param="value">
@@ -71,39 +61,19 @@ EndElement(DocumentElement)
 EndDocument
 ```
 
-This approach of reading XML is quite low-level, since we would need to write a
-lot of code to continuously transform this stream of events into Rust `structs`.
-It does have its advantages though, because it allows us to read and parse files
-that are much larger than the available memory of our machine. Sometimes,
-[when all you have is a 38GB XML file](https://usethe.computer/posts/14-xmhell.html),
-this can be very much worth it.
+This approach of reading XML is quite low-level, since we would need to write a lot of code to continuously transform this stream of events into Rust `structs`. It does have its advantages though, because it allows us to read and parse files that are much larger than the available memory of our machine. Sometimes, [when all you have is a 38GB XML file](https://usethe.computer/posts/14-xmhell.html), this can be very much worth it.
 
-While looking some more into streaming XML parsers for Rust, we noticed that
-there is also the [`quick-xml`](https://crates.io/crates/quick-xml) crate. As
-the name says, it is quick, and by quick we mean 10-50 times faster than
-`xml-rs`! 😱
+While looking some more into streaming XML parsers for Rust, we noticed that there is also the [`quick-xml`](https://crates.io/crates/quick-xml) crate. As the name says, it is quick, and by quick we mean 10-50 times faster than `xml-rs`! 😱
 
-For our particular use case speed is not that important and the files are
-usually only a couple of megabytes, but if we had to decide between `xml-rs` and
-`quick-xml` we certainly would use the latter in the future.
+For our particular use case speed is not that important and the files are usually only a couple of megabytes, but if we had to decide between `xml-rs` and `quick-xml` we certainly would use the latter in the future.
 
 ## DOM parsing
 
-"DOM" stands for "Document Object Model" and is the second parsing approach that
-we want to look at. As we mentioned before, this approach is based on the
-streaming events approach, and turns those events into a generic tree of XML
-elements.
+"DOM" stands for "Document Object Model" and is the second parsing approach that we want to look at. As we mentioned before, this approach is based on the streaming events approach, and turns those events into a generic tree of XML elements.
 
-In the Rust ecosystem, there appear to be two major crates for this:
-[`xmltree`](https://crates.io/crates/xmltree) and
-[`minidom`](https://crates.io/crates/minidom). The former is based on `xml-rs`,
-while `minidom` is based on `quick-xml` instead. That alone should already say
-enough about the speed differences between the two crates. In our tests
-`minidom` was significantly faster than `xmltree`, and we did not find any
-significant disadvantages over `xmltree` so let's focus on `minidom` for now.
+In the Rust ecosystem, there appear to be two major crates for this: [`xmltree`](https://crates.io/crates/xmltree) and [`minidom`](https://crates.io/crates/minidom). The former is based on `xml-rs`, while `minidom` is based on `quick-xml` instead. That alone should already say enough about the speed differences between the two crates. In our tests `minidom` was significantly faster than `xmltree`, and we did not find any significant disadvantages over `xmltree` so let's focus on `minidom` for now.
 
-We will use the same example XML file as above, but this time we will parse it
-using the minidom crate:
+We will use the same example XML file as above, but this time we will parse it using the minidom crate:
 
 ```rust
 let root: minidom::Element = string.parse().unwrap();
@@ -146,32 +116,17 @@ Element {
 }
 ```
 
-The `Element` is a `struct` provided by the `minidom` crate and it easily allows
-us to read the name of the root element, or the content of the child elements.
-Ultimately, this is very similar to how the DOM in the browser works.
+The `Element` is a `struct` provided by the `minidom` crate and it easily allows us to read the name of the root element, or the content of the child elements. Ultimately, this is very similar to how the DOM in the browser works.
 
-This approach does have one disadvantage though, it needs to read the whole file
-into memory to create this tree of elements. This means that it is not suited
-when parsing huge XML files that simply don't fit into the memory of your
-machine. But, most XML files are probably not dozens of gigabytes in size, so
-depending on your use case, this tradeoff might be worth the simplified code
-that it results in.
+This approach does have one disadvantage though, it needs to read the whole file into memory to create this tree of elements. This means that it is not suited when parsing huge XML files that simply don't fit into the memory of your machine. But, most XML files are probably not dozens of gigabytes in size, so depending on your use case, this tradeoff might be worth the simplified code that it results in.
 
 ## `serde`
 
-"Deserialization" is essentially just another word for "parsing", and if we are
-talking about deserializing data then there is one crate in the Rust ecosystem
-that can't be ignored: [`serde`](https://crates.io/crates/serde).
+"Deserialization" is essentially just another word for "parsing", and if we are talking about deserializing data then there is one crate in the Rust ecosystem that can't be ignored: [`serde`](https://crates.io/crates/serde).
 
-`serde` can be used with a variety of different serializers and deserializers
-and allows us to parse files directly into Rust `structs`.
+`serde` can be used with a variety of different serializers and deserializers and allows us to parse files directly into Rust `structs`.
 
-For our particular use case there is a crate called
-[`serde-xml-rs`](https://crates.io/crates/serde-xml-rs), which integrates
-`xml-rs` with `serde`. But `xml-rs` is so slooooow! Luckily there is also an
-alternative that uses `quick-xml`, and it is... `quick-xml` itself. The
-`quick-xml` crate has an optional `serialize` feature which directly provides
-`serde` integration.
+For our particular use case there is a crate called [`serde-xml-rs`](https://crates.io/crates/serde-xml-rs), which integrates `xml-rs` with `serde`. But `xml-rs` is so slooooow! Luckily there is also an alternative that uses `quick-xml`, and it is... `quick-xml` itself. The `quick-xml` crate has an optional `serialize` feature which directly provides `serde` integration.
 
 The code to use `quick-xml` with `serde` looks something roughly like this:
 
@@ -186,39 +141,15 @@ struct Document {
 let doc: Document = quick_xml::de::from_str(xml).unwrap();
 ```
 
-First, we define a `Document` struct, and we declare that a `Deserialize`
-implementation should be derived for it using the `derive` feature of `serde`.
-Then we use the `serde` integration of `quick-xml` to deserialize our XML string
-to a `Document` instance.
-
-This is nice, because it automatically can produce a parsing error when the
-`<FirstElement>` is missing inside the `<DocumentElement>`. But it has one small
-flaw, it does not differentiate between attributes on an element and the child
-elements of an element. If we were to serialize this `struct` back to XML it
-would actually turn the `param` into a `<Param>value</Param>` child element. 😥
-
-Unfortunately, it looks like this is currently something that is hard to
-implement properly with `serde` itself. Due to this, there are a number of
-serde-like crates, specifically for the purpose of supporting XML. Some examples
-of this are [`strong-xml`](https://crates.io/crates/strong-xml) and
-[`yaserde`](https://crates.io/crates/yaserde). These crates allow you to put a
-specific attribute on the field in the `struct` (e.g. `#[yaserde(attribute)]`),
-which tells the serializer to write this as an element attribute, instead of a
-child node.
-
-The primary advantage of this approach is that you can directly parse your data
-into `structs` that match the types of the data that your parsing, compared to
-the generic `Element` struct that you get when you parse it into a DOM
-structure. For example, you can specify `foo: i32`, and if the XML has a `foo`
-attribute that does not parse into a number you will get a parse error. If you
-are certain about the format of your data then this might be a good approach to
-use, but it does have the disadvantage of being less flexible in terms of
-partially broken data.
-
-In our use case we needed to read a file with multiple records inside of it. We
-can't be sure that each record is valid, but if we hit an invalid record we
-would still like to be able to use the other records, so the structure we would
-like to have is something like this:
+First, we define a `Document` struct, and we declare that a `Deserialize` implementation should be derived for it using the `derive` feature of `serde`. Then we use the `serde` integration of `quick-xml` to deserialize our XML string to a `Document` instance.
+
+This is nice, because it automatically can produce a parsing error when the `<FirstElement>` is missing inside the `<DocumentElement>`. But it has one small flaw, it does not differentiate between attributes on an element and the child elements of an element. If we were to serialize this `struct` back to XML it would actually turn the `param` into a `<Param>value</Param>` child element. 😥
+
+Unfortunately, it looks like this is currently something that is hard to implement properly with `serde` itself. Due to this, there are a number of serde-like crates, specifically for the purpose of supporting XML. Some examples of this are [`strong-xml`](https://crates.io/crates/strong-xml) and [`yaserde`](https://crates.io/crates/yaserde). These crates allow you to put a specific attribute on the field in the `struct` (e.g. `#[yaserde(attribute)]`), which tells the serializer to write this as an element attribute, instead of a child node.
+
+The primary advantage of this approach is that you can directly parse your data into `structs` that match the types of the data that your parsing, compared to the generic `Element` struct that you get when you parse it into a DOM structure. For example, you can specify `foo: i32`, and if the XML has a `foo` attribute that does not parse into a number you will get a parse error. If you are certain about the format of your data then this might be a good approach to use, but it does have the disadvantage of being less flexible in terms of partially broken data.
+
+In our use case we needed to read a file with multiple records inside of it. We can't be sure that each record is valid, but if we hit an invalid record we would still like to be able to use the other records, so the structure we would like to have is something like this:
 
 ```rust
 struct Document {
@@ -226,25 +157,18 @@ struct Document {
 }
 ```
 
-It seems that all the serde-like crates currently don't support this kind of
-error recovery, so if you need it then your best bet is probably to use the DOM
-parsing approach from above.
+It seems that all the serde-like crates currently don't support this kind of error recovery, so if you need it then your best bet is probably to use the DOM parsing approach from above.
 
 ## Conclusion
 
-As you can see, all of these approaches have their advantages and disadvantages,
-and we can't recommend one over the other in general. We have come up with a
-rule of thumb though:
+As you can see, all of these approaches have their advantages and disadvantages, and we can't recommend one over the other in general. We have come up with a rule of thumb though:
 
 - when you have huge XML files it's best to use the streaming event parser
 
-- when you are certain about the structure of the XML data and don't need any
-  error recovery then use a serde-like crate
+- when you are certain about the structure of the XML data and don't need any error recovery then use a serde-like crate
 
-- finally, for most other use cases you can use a crate like `minidom` to parse
-  into generic `Element` structs
+- finally, for most other use cases you can use a crate like `minidom` to parse into generic `Element` structs
 
-We hope that this short intro to XML parsing in Rust was helpful to you and if
-you have any questions do not hesitate to [contact] us. We're happy to help!
+We hope that this short intro to XML parsing in Rust was helpful to you and if you have any questions do not hesitate to [contact] us. We're happy to help!
 
 [contact]: https://mainmatter.com/contact/
diff --git a/src/posts/2021-01-29-web-animations-intro.md b/src/posts/2021-01-29-web-animations-intro.md
index 2f25861842..e0d4ce9a2c 100644
--- a/src/posts/2021-01-29-web-animations-intro.md
+++ b/src/posts/2021-01-29-web-animations-intro.md
@@ -11,18 +11,11 @@ tagline: |
 
 ## The status quo of animating the web
 
-Currently, there are two animation techniques that are commonly used on the web:
-CSS transitions/animations and animating through JavaScript by modifying inline
-styles.
+Currently, there are two animation techniques that are commonly used on the web: CSS transitions/animations and animating through JavaScript by modifying inline styles.
 
 ### CSS transitions and animations
 
-[CSS transitions](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions)
-are a basic but powerful way to define a transition between two CSS states of a
-DOM element. They provide limited control, but due to their simplicity it's
-often the preferred way to implement basic animations like hover effects on a
-button. Transitions happen automatically between values of a CSS attribute with
-a given timing function, delay and duration.
+[CSS transitions](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions) are a basic but powerful way to define a transition between two CSS states of a DOM element. They provide limited control, but due to their simplicity it's often the preferred way to implement basic animations like hover effects on a button. Transitions happen automatically between values of a CSS attribute with a given timing function, delay and duration.
 
 ```css
 .my-button {
@@ -35,12 +28,7 @@ a given timing function, delay and duration.
 }
 ```
 
-[CSS animations](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations)
-offer more control over timing and easing. They can run for a given duration,
-have a delay and an iteration count. The animation itself is specified with
-keyframes allowing the creation of more complicated animation effects that are
-not possible with CSS transitions. CSS animations are usually triggered by
-adding or removing a CSS class to an element with JavaScript.
+[CSS animations](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations) offer more control over timing and easing. They can run for a given duration, have a delay and an iteration count. The animation itself is specified with keyframes allowing the creation of more complicated animation effects that are not possible with CSS transitions. CSS animations are usually triggered by adding or removing a CSS class to an element with JavaScript.
 
 ```css
 @keyframes fade-in-keyframes {
@@ -60,29 +48,15 @@ adding or removing a CSS class to an element with JavaScript.
 }
 ```
 
-Both of these offer JavaScript events like `animationend` which allow you to
-react to an animation that finished, though it can still be hard to synchronize
-animations with application state due to the way animations have to be started.
-They are a powerful, declarative and performant way to do animations on
-individual elements.
+Both of these offer JavaScript events like `animationend` which allow you to react to an animation that finished, though it can still be hard to synchronize animations with application state due to the way animations have to be started. They are a powerful, declarative and performant way to do animations on individual elements.
 
 ### Animating with JavaScript
 
-JavaScript based animation loops are the status quo for doing complex
-animations. Animation libraries like
-[ember-animated](https://ember-animation.github.io/ember-animated/) and
-[framer-motion](https://www.framer.com/motion/) or older libraries like
-[Velocity.js](http://velocityjs.org/) and
-[script.aculo.us](https://github.com/madrobby/scriptaculous) are built around
-this technique.
+JavaScript based animation loops are the status quo for doing complex animations. Animation libraries like [ember-animated](https://ember-animation.github.io/ember-animated/) and [framer-motion](https://www.framer.com/motion/) or older libraries like [Velocity.js](http://velocityjs.org/) and [script.aculo.us](https://github.com/madrobby/scriptaculous) are built around this technique.
 
-With a JavaScript based animation loop there is full control over timing and
-state. This makes it possible to take other elements into account. For example,
-you could take measurements of an element A and animate an element B from the
-position and size of element A to element B's natural position.
+With a JavaScript based animation loop there is full control over timing and state. This makes it possible to take other elements into account. For example, you could take measurements of an element A and animate an element B from the position and size of element A to element B's natural position.
 
-A basic animation loop takes a source and target state and based on a timing
-function calculate what the state for the current frame should be.
+A basic animation loop takes a source and target state and based on a timing function calculate what the state for the current frame should be.
 
 ```javascript
 let sourceOpacity = 0;
@@ -116,45 +90,21 @@ function step(time) {
 window.requestAnimationFrame(step);
 ```
 
-In the past, animation loops with JavaScript had to be done through
-`setInterval` to get an approximate 60 frames per second animation. Nowadays the
-`requestAnimationFrame` API exists which results in smoother animation as the
-browser will call it right before the next repaint. Browsers can also pause
-`requestAnimationFrame` when a tab is out of focus to prevent inactive tabs from
-running expensive animations at high framerates.
-
-In addition, this animation technique requires the need for manual interpolation
-of the values we might want to animate. This can be difficult for complex values
-like `color` or `clipPath`, yet also gives opportunity to do different kinds of
-interpolation than what the browser does by default, which can be especially
-relevant for non-trivial values like a color space.
-
-While this animation technique is very powerful it does result in a lot of
-calculations being made every frame for the duration of the animation. This
-might result in stutter or delay especially if something else is happening on
-the page. Examples are a router transition to another page or some data fetching
-and parsing. The browser also has limited ways to optimise such animations as it
-only knows about the current frame and cannot completely offload the animation
-to the GPU.
+In the past, animation loops with JavaScript had to be done through `setInterval` to get an approximate 60 frames per second animation. Nowadays the `requestAnimationFrame` API exists which results in smoother animation as the browser will call it right before the next repaint. Browsers can also pause `requestAnimationFrame` when a tab is out of focus to prevent inactive tabs from running expensive animations at high framerates.
+
+In addition, this animation technique requires the need for manual interpolation of the values we might want to animate. This can be difficult for complex values like `color` or `clipPath`, yet also gives opportunity to do different kinds of interpolation than what the browser does by default, which can be especially relevant for non-trivial values like a color space.
+
+While this animation technique is very powerful it does result in a lot of calculations being made every frame for the duration of the animation. This might result in stutter or delay especially if something else is happening on the page. Examples are a router transition to another page or some data fetching and parsing. The browser also has limited ways to optimise such animations as it only knows about the current frame and cannot completely offload the animation to the GPU.
 
 ## Web Animations API
 
-The [Web Animations API] is a relatively new addition to the browser and is
-still very much in development. It promises to combine the benefits of CSS
-Transitions/Animations and JavaScript based animations.
+The [Web Animations API] is a relatively new addition to the browser and is still very much in development. It promises to combine the benefits of CSS Transitions/Animations and JavaScript based animations.
 
-All popular browsers have now implemented the minimum features necessary to do
-complex animations and a
-[polyfill](https://github.com/web-animations/web-animations-js) which adds
-support for the Web Animations API to older browsers is available. It's time we
-tried it out!
+All popular browsers have now implemented the minimum features necessary to do complex animations and a [polyfill](https://github.com/web-animations/web-animations-js) which adds support for the Web Animations API to older browsers is available. It's time we tried it out!
 
 ### The basics
 
-The main interface for Web Animations is the `Element.animate` function. It can
-be called on a DOM Element, takes an array of keyframes as the first argument
-and options as the second argument. On first sight the API is very similar to
-CSS animations.
+The main interface for Web Animations is the `Element.animate` function. It can be called on a DOM Element, takes an array of keyframes as the first argument and options as the second argument. On first sight the API is very similar to CSS animations.
 
 ```html
 <div id="circle"></div>
@@ -168,12 +118,9 @@ CSS animations.
 </script>
 ```
 
-We'll need only a "from" and a "to" keyframe for now. The easing we set will
-define the timing function used to interpolate between the keyframes. For now,
-we will use the most basic one: "linear".
+We'll need only a "from" and a "to" keyframe for now. The easing we set will define the timing function used to interpolate between the keyframes. For now, we will use the most basic one: "linear".
 
-In addition to that there's some useful timing related functionality on the
-animation instance we can use.
+In addition to that there's some useful timing related functionality on the animation instance we can use.
 
 ```javascript
 // our animation instance
@@ -199,8 +146,7 @@ With these building blocks we can start creating more complex animations.
 
 ### Moving an element around
 
-Let's create an animation which applies a CSS transform to move the element from
-one position to another.
+Let's create an animation which applies a CSS transform to move the element from one position to another.
 
 ```javascript
 element.animate(
@@ -212,15 +158,11 @@ element.animate(
 );
 ```
 
-This will transform the element 100 pixels to the right from its original
-position in 1 second with a linear timing function. When the animation is done,
-its effects on the element are automatically removed.
+This will transform the element 100 pixels to the right from its original position in 1 second with a linear timing function. When the animation is done, its effects on the element are automatically removed.
 
 ![Basic move animation](/assets/images/posts/2021-01-29-web-animations-intro/video1.mp4#video)
 
-Like with CSS animations we need to specify a fill option to specify in what way
-we want the animation's effects to be retained. We can specify `fill: forwards`
-so our final state is retained.
+Like with CSS animations we need to specify a fill option to specify in what way we want the animation's effects to be retained. We can specify `fill: forwards` so our final state is retained.
 
 ```javascript
 element.animate(
@@ -233,38 +175,21 @@ element.animate(
 );
 ```
 
-Our animation now behaves as we would expect and retains the styles specified in
-the final keyframe.
+Our animation now behaves as we would expect and retains the styles specified in the final keyframe.
 
 ![Basic move animation that retains final state](/assets/images/posts/2021-01-29-web-animations-intro/video2.mp4#video)
 
-Alternatively the `animation.commitStyles()` feature can be used to put the
-current animation state in the DOM as inline styles. The animation itself can
-then safely be cancelled so the browser can free up the resources it consumes.
+Alternatively the `animation.commitStyles()` feature can be used to put the current animation state in the DOM as inline styles. The animation itself can then safely be cancelled so the browser can free up the resources it consumes.
 
 ### Cancelling and resuming an animation
 
-Cancellation is an important part of real-world animations. Animations take time
-to complete and in that time the user might have interacted with the page in a
-way where the running animation does not make sense anymore. In most cases when
-an animation is interrupted, another animation will be started. This could be
-the same animation in reverse or an entirely different one. In any case we will
-want to start the animation from the element's current state.
+Cancellation is an important part of real-world animations. Animations take time to complete and in that time the user might have interacted with the page in a way where the running animation does not make sense anymore. In most cases when an animation is interrupted, another animation will be started. This could be the same animation in reverse or an entirely different one. In any case we will want to start the animation from the element's current state.
 
-In theory, you only need to specify a "to" keyframe which would make it trivial
-to cancel an animation as the browser will calculate the "from" position based
-on the current state. Unfortunately not all browsers currently support that
-behaviour meaning we'll have to be a little more elaborate for now.
+In theory, you only need to specify a "to" keyframe which would make it trivial to cancel an animation as the browser will calculate the "from" position based on the current state. Unfortunately not all browsers currently support that behaviour meaning we'll have to be a little more elaborate for now.
 
-In order to cancel the current animation (if any) we'll need to take a few
-steps. Before trying to calculate our starting keyframe we'll need to pause the
-currently running animation (if any). Then we'll need to get the current
-transform present on our element. Finally, we can start the new animation.
+In order to cancel the current animation (if any) we'll need to take a few steps. Before trying to calculate our starting keyframe we'll need to pause the currently running animation (if any). Then we'll need to get the current transform present on our element. Finally, we can start the new animation.
 
-Let's abstract our animation into a `move` function which takes `transformStart`
-and `transformEnd` string arguments. We'll also add `animateRight` and
-`animateLeft` functions which are hooked up to two buttons, so we can run the
-animations by clicking those buttons.
+Let's abstract our animation into a `move` function which takes `transformStart` and `transformEnd` string arguments. We'll also add `animateRight` and `animateLeft` functions which are hooked up to two buttons, so we can run the animations by clicking those buttons.
 
 ```html
 <button onclick="animateLeft()">Left</button>
@@ -297,35 +222,19 @@ animations by clicking those buttons.
 </script>
 ```
 
-Rapidly clicking the buttons interchangeably now shows a pretty jarring
-animation!
+Rapidly clicking the buttons interchangeably now shows a pretty jarring animation!
 
 ![Basic move animation](/assets/images/posts/2021-01-29-web-animations-intro/video3.mp4#video)
 
-This is a good time to take a look at the developer tools to find out what's
-going on. Note that you will not see the animated styles appear in the DOM as
-you might be used to with JavaScript based animation. You can see the effect
-they have in the computed styles and animation sections of the browser's
-developer tools.
+This is a good time to take a look at the developer tools to find out what's going on. Note that you will not see the animated styles appear in the DOM as you might be used to with JavaScript based animation. You can see the effect they have in the computed styles and animation sections of the browser's developer tools.
 
-From the "Animations" pane we can slow down the animation to 25% of the original
-speed to make it easier to see what is going on. We can also replay previous
-animations. When we click the "Left" button while the animation is happening
-we'll see that the animation is not starting at the correct point.
+From the "Animations" pane we can slow down the animation to 25% of the original speed to make it easier to see what is going on. We can also replay previous animations. When we click the "Left" button while the animation is happening we'll see that the animation is not starting at the correct point.
 
 ![Debugging an animation using developer tools](/assets/images/posts/2021-01-29-web-animations-intro/devtools.mp4#video)
 
-This happens because we explicitly specify a starting keyframe which is
-obviously an incorrect starting point if we interrupt the animation in the
-middle.
+This happens because we explicitly specify a starting keyframe which is obviously an incorrect starting point if we interrupt the animation in the middle.
 
-We can fix this by first pausing the animation. Next we can utilise the global
-`getComputedStyle(element)` function to retrieve the current styles for our
-element. We'll take the computed `transform` style as the starting point for our
-keyframe. After doing this we can cancel the current animation to free up
-browser resources and start the new animation. Let's modify our functions
-accordingly. We also no longer have a need to pass in a `transformStart`
-argument, as we will calculate that dynamically from now on.
+We can fix this by first pausing the animation. Next we can utilise the global `getComputedStyle(element)` function to retrieve the current styles for our element. We'll take the computed `transform` style as the starting point for our keyframe. After doing this we can cancel the current animation to free up browser resources and start the new animation. Let's modify our functions accordingly. We also no longer have a need to pass in a `transformStart` argument, as we will calculate that dynamically from now on.
 
 ```javascript
 function move(transformEnd) {
@@ -345,25 +254,13 @@ function animateLeft() {
 }
 ```
 
-Pressing the left or right button while an animation is running will now
-correctly cancel the running animation.
+Pressing the left or right button while an animation is running will now correctly cancel the running animation.
 
 ![Cancellable move animation](/assets/images/posts/2021-01-29-web-animations-intro/video4.mp4#video)
 
-There is still a problem though! We have set a fixed duration for our animation.
-This means that if we cancel the animation after for example 0.5 seconds it will
-still take the full 1 second to revert the animation even though we're only
-moving half the distance. Remembering the Web Animations basics mentioned
-earlier, there is a way to get timing information from an animation. We can use
-that information to correctly calculate the duration for our animation to
-achieve a constant velocity.
-
-Let's modify our move function again. We'll need to get the `activeDuration` and
-`progress` of the running animation. We can call
-`currentAnimation.effect.getComputedTiming()` which will provide us with the
-values we need. We can calculate the target duration with the following formula
-`duration = duration - (activeDuration - progress * activeDuration)` where
-duration is our default duration of 1 second;
+There is still a problem though! We have set a fixed duration for our animation. This means that if we cancel the animation after for example 0.5 seconds it will still take the full 1 second to revert the animation even though we're only moving half the distance. Remembering the Web Animations basics mentioned earlier, there is a way to get timing information from an animation. We can use that information to correctly calculate the duration for our animation to achieve a constant velocity.
+
+Let's modify our move function again. We'll need to get the `activeDuration` and `progress` of the running animation. We can call `currentAnimation.effect.getComputedTiming()` which will provide us with the values we need. We can calculate the target duration with the following formula `duration = duration - (activeDuration - progress * activeDuration)` where duration is our default duration of 1 second;
 
 ```javascript
 function move(transformEnd) {
@@ -397,32 +294,25 @@ function move(transformEnd) {
 }
 ```
 
-After this change our animations will always run with a constant velocity, no
-matter when the running animation is cancelled. The final result can be seen in
-this [CodePen](https://codepen.io/nickschot/pen/LYbPBmW).
+After this change our animations will always run with a constant velocity, no matter when the running animation is cancelled. The final result can be seen in this [CodePen](https://codepen.io/nickschot/pen/LYbPBmW).
 
 ![Cancellable move animation with constant velocity](/assets/images/posts/2021-01-29-web-animations-intro/video5.mp4#video)
 
 ### When an animation finishes
 
-It is likely you need to do something after an animation completes. The Web
-Animations API provides a couple of options to do this. Firstly there is the
-`Animation.onfinish` handler which runs the given function after the animation
-completes.
+It is likely you need to do something after an animation completes. The Web Animations API provides a couple of options to do this. Firstly there is the `Animation.onfinish` handler which runs the given function after the animation completes.
 
 ```javascript
 currentAnimation.onfinish = () => console.log("animation finished!");
 ```
 
-Secondly there is also the `Animation.finished` promise, which resolves when the
-animation finishes.
+Secondly there is also the `Animation.finished` promise, which resolves when the animation finishes.
 
 ```javascript
 currentAnimation.finished.then(() => console.log("animation finished!"));
 ```
 
-These functions behave a bit differently when an animation is cancelled. The
-`onfinish` hook is never called. Fortunately an `oncancel` hook also exists.
+These functions behave a bit differently when an animation is cancelled. The `onfinish` hook is never called. Fortunately an `oncancel` hook also exists.
 
 ```javascript
 // handling cancellation with hooks
@@ -430,8 +320,7 @@ currentAnimation.onfinish = () => console.log("animation finished!");
 currentAnimation.oncancel = () => console.error("animation cancelled.");
 ```
 
-The `finished` promise will throw an error which we will need to handle. We can
-of course also utilize async/await.
+The `finished` promise will throw an error which we will need to handle. We can of course also utilize async/await.
 
 ```javascript
 // handling cancellation with promises
@@ -449,11 +338,6 @@ try {
 
 ## Conclusion
 
-With this we now have a basic understanding of the Web Animations API and can
-create moderately complex animations for a given element controller from
-JavaScript. From this basic understanding we can start thinking about expanding
-this to more complex use cases such as animating between elements and pages.
-Furthermore, we can think about using more advanced timing functions, their
-benefits and implications.
+With this we now have a basic understanding of the Web Animations API and can create moderately complex animations for a given element controller from JavaScript. From this basic understanding we can start thinking about expanding this to more complex use cases such as animating between elements and pages. Furthermore, we can think about using more advanced timing functions, their benefits and implications.
 
 [contact]: https://mainmatter.com/contact/
diff --git a/src/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity.md b/src/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity.md
index ce9e27d8a6..f503220499 100644
--- a/src/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity.md
+++ b/src/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity.md
@@ -3,10 +3,7 @@ title: "Ember.js in 2021 – a beacon of productivity"
 authorHandle: marcoow
 tags: ember
 bio: "Founder and Managing Director of Mainmatter"
-description:
-  "Marco Otte-Witte makes the case for Ember in 2021 and explains why he
-  considers the framework a beacon of productivity in the middle of a roaring
-  sea of complexity"
+description: "Marco Otte-Witte makes the case for Ember in 2021 and explains why he considers the framework a beacon of productivity in the middle of a roaring sea of complexity"
 og:
   image: /assets/images/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity/og-image.jpg
 tagline: |
@@ -15,323 +12,82 @@ tagline: |
 
 ### Mainmatter ❤️ Ember
 
-To be completely transparent, I'm heavily biased towards Ember. With Mainmatter,
-I founded what is now the
-[leading Ember consultancy in Europe](/ember-consulting/). We've helped many
-teams successfully build, evolve and maintain large applications with Ember over
-the years. Some of our team members are involved in the Ember core team and we
-maintain a number of widely adopted libraries in the ecosystem.
-[We're one of the official sponsors of the framework even](https://emberjs.com/sponsors).
-With all that experience and also some experience with teams using other
-technology stacks, I think we do have a view on frontend development that's
-maybe a bit different from other teams' views and because of that, it is worth
-sharing.
+To be completely transparent, I'm heavily biased towards Ember. With Mainmatter, I founded what is now the [leading Ember consultancy in Europe](/ember-consulting/). We've helped many teams successfully build, evolve and maintain large applications with Ember over the years. Some of our team members are involved in the Ember core team and we maintain a number of widely adopted libraries in the ecosystem. [We're one of the official sponsors of the framework even](https://emberjs.com/sponsors). With all that experience and also some experience with teams using other technology stacks, I think we do have a view on frontend development that's maybe a bit different from other teams' views and because of that, it is worth sharing.
 
 ## The Status Quo of Frontend Engineering
 
-There have been huge amounts of progress in the frontend engineering world over
-the past 10 years or so. Back when Ember was first released,
-[jQuery](https://jquery.com/) (and sometimes even
-[Prototype](http://prototypejs.org/)) were still the go-to solutions for making
-otherwise static and server-rendered pages dynamic. And while jQuery remains
-[the most used JavaScript library on the web to date](https://w3techs.com/technologies/history_overview/javascript_library/all/q),
-techniques introduced first by Ember and Angular.js (and later React and others)
-are now widely accepted and adopted. While frontend engineering was something
-that many _"real"_ developers would look down on only a few years ago and that
-was often merely an afterthought, the field has been professionalized
-significantly and now gets the attention it deserves. That does not only
-acknowledge the fact that frontend development is hugely challenging but also
-its significance for businesses due to the direct impact on the end users'
-experience.
+There have been huge amounts of progress in the frontend engineering world over the past 10 years or so. Back when Ember was first released, [jQuery](https://jquery.com/) (and sometimes even [Prototype](http://prototypejs.org/)) were still the go-to solutions for making otherwise static and server-rendered pages dynamic. And while jQuery remains [the most used JavaScript library on the web to date](https://w3techs.com/technologies/history_overview/javascript_library/all/q), techniques introduced first by Ember and Angular.js (and later React and others) are now widely accepted and adopted. While frontend engineering was something that many _"real"_ developers would look down on only a few years ago and that was often merely an afterthought, the field has been professionalized significantly and now gets the attention it deserves. That does not only acknowledge the fact that frontend development is hugely challenging but also its significance for businesses due to the direct impact on the end users' experience.
 
 [![Yehuda Katz (@wycats) on Twitter](/assets/images/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity/wycats-tweet.png#plain@600-1200)](https://twitter.com/wycats/status/930463710941872128)
 
-Things haven't slowed down in the world of frontend development though. In fact,
-quite the opposite – we are seeing innovation and change at an extremely high
-and seemingly still accelerating pace. JavaScript has become the
-[world's dominant language](https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages)
-and is the default answer many developers have to just about anything they might
-be dealing with on the web
-([you can even write your CSS in JS now 🙀](https://en.wikipedia.org/wiki/CSS-in-JS)).
-And while innovation and exploring possibilities and new approaches are great,
-the fact that a huge community of developers is collectively on the lookout for
-the next big thing and everyone is only waiting to jump on the next bandwagon
-does more harm than might be apparent at first glance. It's easy to
-underestimate the cost that comes with the churn that adopting new approaches
-over-eagerly brings with it which is often only to realize later the hype train
-has changed direction again and what you bet on has now turned into a dead-end.
+Things haven't slowed down in the world of frontend development though. In fact, quite the opposite – we are seeing innovation and change at an extremely high and seemingly still accelerating pace. JavaScript has become the [world's dominant language](https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages) and is the default answer many developers have to just about anything they might be dealing with on the web ([you can even write your CSS in JS now 🙀](https://en.wikipedia.org/wiki/CSS-in-JS)). And while innovation and exploring possibilities and new approaches are great, the fact that a huge community of developers is collectively on the lookout for the next big thing and everyone is only waiting to jump on the next bandwagon does more harm than might be apparent at first glance. It's easy to underestimate the cost that comes with the churn that adopting new approaches over-eagerly brings with it which is often only to realize later the hype train has changed direction again and what you bet on has now turned into a dead-end.
 
 [![Lee Robinson (@leeerob) on Twitter](/assets/images/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity/leeerob-tweet.png#plain@600-1200)](https://mobile.twitter.com/leeerob/status/1353523847937536000)
 
 ### The Complexity Fetish
 
-I think that complexity is fetishized in the frontend world in a way – mainly
-due to two sentiments. One is simply ego. As the virologists and epidemiologists
-say (and we all have learned in the past year), _"there's no glory in
-prevention"_. And just like that there's (surprisingly) little glory to be found
-in steadily shipping real product value based on solutions to common problems
-others have found before you and encoded in frameworks based on strong
-conventions. On the other hand, there's all the engineering glory to be found in
-figuring out the best™ way to address a particular problem and taming low-level
-complexity even if all that work is not contributing to executing on a product
-and business vision – taking on such problems is often done for the glory alone,
-regardless of whether the problem has been solved before or even poses a
-challenge in the respective project at all. Having ported a React app step by
-step from Redux over MobX to hooks and beyond over the course of the past few
-years likely was an exciting engineering journey and came with a whole bunch of
-interesting and challenging work. However, the cost-benefit relationship of all
-the time spent on the endeavor might be questionable.
-
-[Chris Manson](https://mainmatter.com/blog/author/real_ate) from the Mainmatter
-and [Ember Learning Core](https://emberjs.com/teams/) teams recently told me the
-story of an engineer he was talking to at a conference. They understood and
-completely agreed with the value that Ember provided as a full-featured,
-batteries included frontend application framework that enables teams to build
-skyscrapers starting from the 20th floor instead of beginning with laying the
-foundation. Yet they said they would never propose the framework to their boss
-because then they wouldn't get to write as much code for solving low level
-problems they found particularly exciting because _"Ember does it all for you"_.
-While that **can** be a valid reason not to choose a technical solution at
-times, in most cases shipping **is** important and should be the main driver for
-decisions.
-
-The other sentiment that I believe contributes to the complexity fetish is a
-desire to be in control of ever every single aspect and detail of one's app.
-That might be driven partly by the Node community's – highly questionable in my
-opinion – love relationship with micro packages where applications are made up
-of a carefully assembled combination of tiny libraries that perfectly cater to a
-particular application's very special needs – or in most cases, the personal
-preferences of the engineer(s) setting up the project. Many teams I've talked to
-over the years have strongly held opinions about what particular routing library
-they need, why they cannot use the state management patterns of framework X but
-have to use a different micro-library etc. And while many of these arguments
-will make some sense from a purely technical point of view, the practical impact
-is more often than not neglectable or irrelevant even. What's certain though is
-that all the time and effort spent on assembling (and then maintaining) these
-highly customized ad-hoc frameworks is **not** going into building and improving
-real products for real users.
+I think that complexity is fetishized in the frontend world in a way – mainly due to two sentiments. One is simply ego. As the virologists and epidemiologists say (and we all have learned in the past year), _"there's no glory in prevention"_. And just like that there's (surprisingly) little glory to be found in steadily shipping real product value based on solutions to common problems others have found before you and encoded in frameworks based on strong conventions. On the other hand, there's all the engineering glory to be found in figuring out the best™ way to address a particular problem and taming low-level complexity even if all that work is not contributing to executing on a product and business vision – taking on such problems is often done for the glory alone, regardless of whether the problem has been solved before or even poses a challenge in the respective project at all. Having ported a React app step by step from Redux over MobX to hooks and beyond over the course of the past few years likely was an exciting engineering journey and came with a whole bunch of interesting and challenging work. However, the cost-benefit relationship of all the time spent on the endeavor might be questionable.
+
+[Chris Manson](https://mainmatter.com/blog/author/real_ate) from the Mainmatter and [Ember Learning Core](https://emberjs.com/teams/) teams recently told me the story of an engineer he was talking to at a conference. They understood and completely agreed with the value that Ember provided as a full-featured, batteries included frontend application framework that enables teams to build skyscrapers starting from the 20th floor instead of beginning with laying the foundation. Yet they said they would never propose the framework to their boss because then they wouldn't get to write as much code for solving low level problems they found particularly exciting because _"Ember does it all for you"_. While that **can** be a valid reason not to choose a technical solution at times, in most cases shipping **is** important and should be the main driver for decisions.
+
+The other sentiment that I believe contributes to the complexity fetish is a desire to be in control of ever every single aspect and detail of one's app. That might be driven partly by the Node community's – highly questionable in my opinion – love relationship with micro packages where applications are made up of a carefully assembled combination of tiny libraries that perfectly cater to a particular application's very special needs – or in most cases, the personal preferences of the engineer(s) setting up the project. Many teams I've talked to over the years have strongly held opinions about what particular routing library they need, why they cannot use the state management patterns of framework X but have to use a different micro-library etc. And while many of these arguments will make some sense from a purely technical point of view, the practical impact is more often than not neglectable or irrelevant even. What's certain though is that all the time and effort spent on assembling (and then maintaining) these highly customized ad-hoc frameworks is **not** going into building and improving real products for real users.
 
 ## Ember: Turning Complexity into Simplicity
 
-Contrary to that, Ember takes these low level and mostly unimportant
-[bike-shedding](https://en.wikipedia.org/wiki/Law_of_triviality) decisions out
-of the hands of developers. It is a full-featured, batteries-included framework
-and like similar solutions for the backend like Ruby on Rails, it provides
-everything one needs to build an app in a coherent way with a consistent API
-where the individual parts all work together seamlessly since they were meant to
-work together from the beginning. Because of that, it doesn't allow the level of
-freedom and fine-grained control over every little detail that many are looking
-for in the frontend world as mentioned above. And while that might sound
-unappealing to many, it's actually its biggest strength as it allows teams to
-focus on executing on their product and company vision and shipping real value
-for their users.
+Contrary to that, Ember takes these low level and mostly unimportant [bike-shedding](https://en.wikipedia.org/wiki/Law_of_triviality) decisions out of the hands of developers. It is a full-featured, batteries-included framework and like similar solutions for the backend like Ruby on Rails, it provides everything one needs to build an app in a coherent way with a consistent API where the individual parts all work together seamlessly since they were meant to work together from the beginning. Because of that, it doesn't allow the level of freedom and fine-grained control over every little detail that many are looking for in the frontend world as mentioned above. And while that might sound unappealing to many, it's actually its biggest strength as it allows teams to focus on executing on their product and company vision and shipping real value for their users.
 
 ### Essential vs. accidental complexity
 
-Writing any software system means dealing with a large amount of complexity.
-That complexity comes in two forms (see
-[Fred Brooks' famous paper on the topic](https://en.wikipedia.org/wiki/No_Silver_Bullet)):
-essential complexity and accidental complexity. Essential complexity is how hard
-something is to do, regardless of one's experience, the technology used, etc.
-It's an inherent property of the problem you're solving. Adding two numbers is
-generally a relatively low complexity task while building a social network has
-much higher complexity in comparison. On the other hand, accidental complexity
-is the part of the complexity that is not inherent to the problem one is solving
-but introduced as part of the solution. Adding two numbers in C++ is more
-complex than doing the same thing in JavaScript, as in C++ you have to worry
-about memory management, you have to compile, etc. – all of that isn't necessary
-for JavaScript which thus leads to lower accidental complexity.
-
-Frameworks like Ember are all about reducing the amount of accidental complexity
-that the developers have to deal with. Since Ember takes care of all or the vast
-majority of aspects of the application that are not an essential part of the
-particular application's problem domain (e.g. routing, data loading, etc.), it
-takes all of the accidental complexity associated with these aspects out of the
-hands of the developers. They instead can focus on tackling the essential
-complexity only. Clearly separating the aspects the developer is in control of
-from everything else is therefore a
-[liberating constraint](https://wiki.c2.com/?LiberatingConstraint) – it
-liberates developers from getting side-tracked and spending time on
-non-essential aspects and enables them to spend their time and effort where they
-truly add value. In contrast to that, building on micro packages and aiming for
-fine-grained control over all of an application's aspects will necessarily
-resurface all the accidental complexity associated with those and put the
-responsibility for them back into the hands of developers. They now have to deal
-with webpack configurations, integration between packages, etc. All effort and
-time spent on these tasks are not going into delivering product value for real
-users.
+Writing any software system means dealing with a large amount of complexity. That complexity comes in two forms (see [Fred Brooks' famous paper on the topic](https://en.wikipedia.org/wiki/No_Silver_Bullet)): essential complexity and accidental complexity. Essential complexity is how hard something is to do, regardless of one's experience, the technology used, etc. It's an inherent property of the problem you're solving. Adding two numbers is generally a relatively low complexity task while building a social network has much higher complexity in comparison. On the other hand, accidental complexity is the part of the complexity that is not inherent to the problem one is solving but introduced as part of the solution. Adding two numbers in C++ is more complex than doing the same thing in JavaScript, as in C++ you have to worry about memory management, you have to compile, etc. – all of that isn't necessary for JavaScript which thus leads to lower accidental complexity.
+
+Frameworks like Ember are all about reducing the amount of accidental complexity that the developers have to deal with. Since Ember takes care of all or the vast majority of aspects of the application that are not an essential part of the particular application's problem domain (e.g. routing, data loading, etc.), it takes all of the accidental complexity associated with these aspects out of the hands of the developers. They instead can focus on tackling the essential complexity only. Clearly separating the aspects the developer is in control of from everything else is therefore a [liberating constraint](https://wiki.c2.com/?LiberatingConstraint) – it liberates developers from getting side-tracked and spending time on non-essential aspects and enables them to spend their time and effort where they truly add value. In contrast to that, building on micro packages and aiming for fine-grained control over all of an application's aspects will necessarily resurface all the accidental complexity associated with those and put the responsibility for them back into the hands of developers. They now have to deal with webpack configurations, integration between packages, etc. All effort and time spent on these tasks are not going into delivering product value for real users.
 
 [![Chad Fowler (@chadfowler) on Twitter](/assets/images/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity/chadfowler-tweet.png#plain@600-1200)](https://twitter.com/chadfowler/status/646624348028190720)
 
-At Mainmatter, we have seen many teams struggling with all kinds of problems in
-web projects and helped them overcome those. In none of those cases were those
-problems caused by how frameworks like Ember or Rails handle the non-essential
-aspects of applications. Most of the time what leads to problems is teams
-struggling to organize code in a maintainable and extensible way in areas where
-frameworks leave freedom and do not provide strong conventions (typical examples
-being shaping and orchestrating components in Ember or organizing business logic
-in Rails apps) – in fact, the worst kinds of problems typically arise where
-teams build their own extensions to frameworks that add large amounts of
-accidental complexity and create more problems than they solve. I have seen at
-least eight different approaches to organizing business logic in custom
-constructs in Rails apps during my career and every single one eventually lead
-to a dead end. The same can be said for inventing custom data management
-libraries instead of relying on solutions like
-[ember-data](https://github.com/emberjs/data) or [Orbit](https://orbitjs.com).
-
-> With Ember, we have built a consistent codebase of a couple apps and and
-> addons. It is shared by 25 front-end engineers, spread over a few teams. In an
-> early phase, we could focus on providing new features for our clients. Later,
-> while keeping this focus, we could evolve the codebase in a non-disruptive
-> way.
+At Mainmatter, we have seen many teams struggling with all kinds of problems in web projects and helped them overcome those. In none of those cases were those problems caused by how frameworks like Ember or Rails handle the non-essential aspects of applications. Most of the time what leads to problems is teams struggling to organize code in a maintainable and extensible way in areas where frameworks leave freedom and do not provide strong conventions (typical examples being shaping and orchestrating components in Ember or organizing business logic in Rails apps) – in fact, the worst kinds of problems typically arise where teams build their own extensions to frameworks that add large amounts of accidental complexity and create more problems than they solve. I have seen at least eight different approaches to organizing business logic in custom constructs in Rails apps during my career and every single one eventually lead to a dead end. The same can be said for inventing custom data management libraries instead of relying on solutions like [ember-data](https://github.com/emberjs/data) or [Orbit](https://orbitjs.com).
+
+> With Ember, we have built a consistent codebase of a couple apps and and addons. It is shared by 25 front-end engineers, spread over a few teams. In an early phase, we could focus on providing new features for our clients. Later, while keeping this focus, we could evolve the codebase in a non-disruptive way.
 >
-> Ember and its ecosystem have given us enough stability to invest in our
-> product and in the development of our engineers' skills.
-> <author>[Cyrille David](https://github.com/dcyriller), Head of Front-End,
-> Qonto</author>
+> Ember and its ecosystem have given us enough stability to invest in our product and in the development of our engineers' skills. <author>[Cyrille David](https://github.com/dcyriller), Head of Front-End, Qonto</author>
 
 ## Stability without Stagnation
 
-The fact that Ember hides most of the accidental complexity and takes control
-over these aspects of applications doesn't mean nothing can ever change in the
-framework and no progress can be had. There **is** steady and substantial
-progress in the framework but Ember shields developers from having to deal with
-the involved churn as much as possible. Instead, Ember constantly ships
-improvements in backwards compatible minor releases with clear upgrade paths,
-following its [release strategy](https://emberjs.com/releases) which emphasizes
-stability. That allows teams to keep up with recent developments and benefit
-from innovation in the frontend field while minimizing the incurred cost like
-the team at CLARK:
+The fact that Ember hides most of the accidental complexity and takes control over these aspects of applications doesn't mean nothing can ever change in the framework and no progress can be had. There **is** steady and substantial progress in the framework but Ember shields developers from having to deal with the involved churn as much as possible. Instead, Ember constantly ships improvements in backwards compatible minor releases with clear upgrade paths, following its [release strategy](https://emberjs.com/releases) which emphasizes stability. That allows teams to keep up with recent developments and benefit from innovation in the frontend field while minimizing the incurred cost like the team at CLARK:
 
 [![Jan Buschtoens (@buschtoens) on Twitter](/assets/images/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity/buschtoens-tweet.png#plain@600-1200)](https://twitter.com/buschtoens/status/1352734272675840006)
 
-All changes to Ember itself go through the
-[RFC process](https://github.com/emberjs/rfcs), are validated and tested in real
-apps through the canary and beta releases before being rolled out to the
-community. Once that happens, the previous APIs will remain available but be
-deprecated along with extensive documentation for migrating to the new paradigms
-(and in many cases there will be codemods even for automating the task; there's
-also [a dedicated app](https://upgrade.emberjs.com) listing the changes between
-two versions and the changes necessary for upgrading). So instead of every
-single team paying the cost for exploration and experimentation, the framework
-and community pay that cost once, for the entire community to benefit afterward.
-That's what the Ember community also refers to as the
-[safety of the herd](https://embermap.com/notes/62-safety-of-the-herd).
+All changes to Ember itself go through the [RFC process](https://github.com/emberjs/rfcs), are validated and tested in real apps through the canary and beta releases before being rolled out to the community. Once that happens, the previous APIs will remain available but be deprecated along with extensive documentation for migrating to the new paradigms (and in many cases there will be codemods even for automating the task; there's also [a dedicated app](https://upgrade.emberjs.com) listing the changes between two versions and the changes necessary for upgrading). So instead of every single team paying the cost for exploration and experimentation, the framework and community pay that cost once, for the entire community to benefit afterward. That's what the Ember community also refers to as the [safety of the herd](https://embermap.com/notes/62-safety-of-the-herd).
 
 And Ember has seen many substantial changes to its core concepts over the years:
 
 - [introducing a completely new component API](https://guides.emberjs.com/release/upgrading/current-edition/glimmer-components/)
-- [replacing the core rendering engine of the framework](https://blog.emberjs.com/ember-2-10-released/#changesinemberjs210)
-  ([Glimmer VM](https://github.com/glimmerjs/glimmer-vm))
+- [replacing the core rendering engine of the framework](https://blog.emberjs.com/ember-2-10-released/#changesinemberjs210) ([Glimmer VM](https://github.com/glimmerjs/glimmer-vm))
 - [removing its custom object model and adopting native classes](https://guides.emberjs.com/release/upgrading/current-edition/native-classes/)
 
-Each of those changes were substantial updates to the Ember programming model.
-Yet, each one was released in a way that made it easy for the entire community
-to follow along. The entire ecosystem revolving around a single defined set of
-techniques and practices while making sure no project is left behind and stuck
-on old patterns prevents fragmentation. Everyone in the community has a
-collective interest in supporting, maintaining, and evolving the same set of
-tools and the entire community will collectively make sure those continue to
-work and work well for everyone using Ember. There is no risk on individual
-teams and projects being left on their own because they bet on the wrong horse
-that ends up not being actively maintained so that the teams would either have
-to take over maintenance themselves or switch to a different solution which
-would often result in large refactorings, again directing time and effort into
-dealing with accidental complexity rather than essential complexity and
-generating product value.
+Each of those changes were substantial updates to the Ember programming model. Yet, each one was released in a way that made it easy for the entire community to follow along. The entire ecosystem revolving around a single defined set of techniques and practices while making sure no project is left behind and stuck on old patterns prevents fragmentation. Everyone in the community has a collective interest in supporting, maintaining, and evolving the same set of tools and the entire community will collectively make sure those continue to work and work well for everyone using Ember. There is no risk on individual teams and projects being left on their own because they bet on the wrong horse that ends up not being actively maintained so that the teams would either have to take over maintenance themselves or switch to a different solution which would often result in large refactorings, again directing time and effort into dealing with accidental complexity rather than essential complexity and generating product value.
 
 ## The right tool for the right job
 
-As laid out above, Ember is a full-featured application framework that contains
-coherent building blocks and concepts for all aspects that real-world
-applications face and that are not inherently coupled to their problem domain.
-While Ember encapsulates the internals of these concepts so developers do not
-have to deal with them, all these concepts are still present and contribute to
-the framework's public API and general architecture that one is exposed to when
-working on an Ember project. This often leads to criticism focussed on the fact
-that there is a lot to learn with Ember and some or much of that might not be
-necessary for a particular project
-
-> I just want to build a calculator widget for my static site – why do I need to
-> worry about routing, data loading, error states, etc. for that?
+As laid out above, Ember is a full-featured application framework that contains coherent building blocks and concepts for all aspects that real-world applications face and that are not inherently coupled to their problem domain. While Ember encapsulates the internals of these concepts so developers do not have to deal with them, all these concepts are still present and contribute to the framework's public API and general architecture that one is exposed to when working on an Ember project. This often leads to criticism focussed on the fact that there is a lot to learn with Ember and some or much of that might not be necessary for a particular project
+
+> I just want to build a calculator widget for my static site – why do I need to worry about routing, data loading, error states, etc. for that?
 >
 > – someone who should have chosen React
 
-Comments like that are hard to counter. Of course, there's no good reason why
-anyone should have to set up a
-[route structure](https://guides.emberjs.com/release/routing/) along with a
-[template hierarchy](https://guides.emberjs.com/release/routing/rendering-a-template/)
-or understand what
-[adapters](https://guides.emberjs.com/release/models/customizing-adapters/) or
-[serializers](https://guides.emberjs.com/release/models/customizing-serializers/)
-are when the application they are building does not need any of that anyway. In
-reality, though, this doesn't imply Ember is unnecessarily bloated or overly
-complex but the complaining person turned to a tool that serves a different
-purpose than what they need for their particular job in the first place.
-
-Even though the boundaries are sometimes blurry, there still is a substantial
-difference between static or only partly dynamic web **sites** (like your
-favorite news outlet's site or most e-commerce sites) and full-on web **apps**
-(e.g. social networks like Facebook or LinkedIn or dashboard-style apps like the
-online banking UI that [Qonto](https://qonto.com) is building). These different
-use cases also come with different characteristics and requirements in terms of
-interactivity, (load time) performance, and user expectations. Aral Balkan wrote
-an
-[interesting post in 2013](https://ar.al/notes/the-documents-to-applications-continuum/)
-on the topic in which he introduces what he calls the
-_"Documents-to-Applications Continuum"_ – and what he said almost 8 years ago,
-still applies today. Ember's sweet spot is all the way on the _"Applications"_
-side of that spectrum:
+Comments like that are hard to counter. Of course, there's no good reason why anyone should have to set up a [route structure](https://guides.emberjs.com/release/routing/) along with a [template hierarchy](https://guides.emberjs.com/release/routing/rendering-a-template/) or understand what [adapters](https://guides.emberjs.com/release/models/customizing-adapters/) or [serializers](https://guides.emberjs.com/release/models/customizing-serializers/) are when the application they are building does not need any of that anyway. In reality, though, this doesn't imply Ember is unnecessarily bloated or overly complex but the complaining person turned to a tool that serves a different purpose than what they need for their particular job in the first place.
+
+Even though the boundaries are sometimes blurry, there still is a substantial difference between static or only partly dynamic web **sites** (like your favorite news outlet's site or most e-commerce sites) and full-on web **apps** (e.g. social networks like Facebook or LinkedIn or dashboard-style apps like the online banking UI that [Qonto](https://qonto.com) is building). These different use cases also come with different characteristics and requirements in terms of interactivity, (load time) performance, and user expectations. Aral Balkan wrote an [interesting post in 2013](https://ar.al/notes/the-documents-to-applications-continuum/) on the topic in which he introduces what he calls the _"Documents-to-Applications Continuum"_ – and what he said almost 8 years ago, still applies today. Ember's sweet spot is all the way on the _"Applications"_ side of that spectrum:
 
 ![The Documents-to-Applications Continuum](/assets/images/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity/documents-to-applications-continuum.svg)
 
-There are plenty of other and better options for other kinds of projects (and
-for static content sites, I'd argue any client-side framework is the wrong
-choice more often than not anyway – however, admittedly we went through the
-[exercise of completely over-engineering a static site](/blog/2020/01/31/how-to-over-engineer-a-static-page/)
-as well to learn that the hard way). The point is, **if you're not building a
-web application, don't look at a web application framework to build it with.**
-Yet, many teams would do that and then be disappointed that the framework they
-tried does not turn out to be a great fit. To me, that's a bit like complaining
-SpaceX's rockets aren't great to do grocery shopping with. A rocket not being an
-ideal choice for that task doesn't mean it's a bad rocket, just that advanced
-technology designed for tackling challenging tasks isn't necessarily also a
-great fit for simpler tasks.
+There are plenty of other and better options for other kinds of projects (and for static content sites, I'd argue any client-side framework is the wrong choice more often than not anyway – however, admittedly we went through the [exercise of completely over-engineering a static site](/blog/2020/01/31/how-to-over-engineer-a-static-page/) as well to learn that the hard way). The point is, **if you're not building a web application, don't look at a web application framework to build it with.** Yet, many teams would do that and then be disappointed that the framework they tried does not turn out to be a great fit. To me, that's a bit like complaining SpaceX's rockets aren't great to do grocery shopping with. A rocket not being an ideal choice for that task doesn't mean it's a bad rocket, just that advanced technology designed for tackling challenging tasks isn't necessarily also a great fit for simpler tasks.
 
 ## A productive future with Ember
 
-Ember has never been the coolest kid on the block and probably never will be.
-Building on solutions others have found before you isn't a particularly
-attractive outlook for many developers. It takes quite a bit of experience and
-reflection to let go of one's vanity and accept that the less you do yourself
-and the more you build on existing, proven solutions, the better of an
-engineering job you're actually doing and the better your work is in the
-interest of the company you build or work for which is ultimately the top
-priority as it is what's paying the bills and salaries. Ember developers
-[frequently are the highest-paid and most senior in the annual state of JS survey](https://2019.stateofjs.com/front-end-frameworks/#front_end_frameworks_salary_heatmap)
-and I don't think that's a coincidence.
+Ember has never been the coolest kid on the block and probably never will be. Building on solutions others have found before you isn't a particularly attractive outlook for many developers. It takes quite a bit of experience and reflection to let go of one's vanity and accept that the less you do yourself and the more you build on existing, proven solutions, the better of an engineering job you're actually doing and the better your work is in the interest of the company you build or work for which is ultimately the top priority as it is what's paying the bills and salaries. Ember developers [frequently are the highest-paid and most senior in the annual state of JS survey](https://2019.stateofjs.com/front-end-frameworks/#front_end_frameworks_salary_heatmap) and I don't think that's a coincidence.
 
 [![Vlad Mihalcea (@vlad_mihalcea) on Twitter](/assets/images/posts/2021-03-12-Ember.js-in-2021---a-beacon-of-productivity/vlad_mihalcea-tweet.png#plain@600-1200)](https://twitter.com/vlad_mihalcea/status/1350775611434930177)
 
-Ember has been an enabler of great productivity for many teams for almost a
-decade and I'm sure it's going to continue to be that. It's changed and improved
-a lot since its first release and is now in better shape than ever with its
-[Octane edition](https://emberjs.com/editions/octane/). All those changes and
-improvements were introduced with minimal effort for teams to stay up to date
-and migrate their apps in small steps over time. There also is little to no
-fragmentation within the community – everyone using Ember.js is basing their
-work on the same idioms and techniques, all originating from the same highly
-cohesive ecosystem. And when more changes and improvements are to come in the
-future, they will be battle-tested **before** migrating the community, and that
-migration will take everyone along, leaving no app behind.
-
-[Qonto](https://qonto.com) and [CLARK](http://clark.de) are two great examples
-of teams executing on their product vision steadily and sustainably. The
-companies are two of the most successful and fastest-growing FinTechs in Europe
-and have scaled their teams significantly over the past few years while
-continuing to ship steadily and sustainably. But they are not the only ones
-using Ember successfully of course – others include companies building ambitious
-apps with large and growing teams like LinkedIn, Apple, Square, Heroku,
-Intercom, and many more. All those teams might generate little fuzz and hype but
-ship product value constantly and will continue to do so building on Ember which
-will keep lifting them to new heights for the time to come.
+Ember has been an enabler of great productivity for many teams for almost a decade and I'm sure it's going to continue to be that. It's changed and improved a lot since its first release and is now in better shape than ever with its [Octane edition](https://emberjs.com/editions/octane/). All those changes and improvements were introduced with minimal effort for teams to stay up to date and migrate their apps in small steps over time. There also is little to no fragmentation within the community – everyone using Ember.js is basing their work on the same idioms and techniques, all originating from the same highly cohesive ecosystem. And when more changes and improvements are to come in the future, they will be battle-tested **before** migrating the community, and that migration will take everyone along, leaving no app behind.
+
+[Qonto](https://qonto.com) and [CLARK](http://clark.de) are two great examples of teams executing on their product vision steadily and sustainably. The companies are two of the most successful and fastest-growing FinTechs in Europe and have scaled their teams significantly over the past few years while continuing to ship steadily and sustainably. But they are not the only ones using Ember successfully of course – others include companies building ambitious apps with large and growing teams like LinkedIn, Apple, Square, Heroku, Intercom, and many more. All those teams might generate little fuzz and hype but ship product value constantly and will continue to do so building on Ember which will keep lifting them to new heights for the time to come.
diff --git a/src/posts/2021-03-15-trying-your-github-actions-locally.md b/src/posts/2021-03-15-trying-your-github-actions-locally.md
index 419633ee52..e0ea3089cb 100644
--- a/src/posts/2021-03-15-trying-your-github-actions-locally.md
+++ b/src/posts/2021-03-15-trying-your-github-actions-locally.md
@@ -10,37 +10,15 @@ tagline: |
   <p>If, like me, configuring <a href="https://docs.github.com/en/actions">GitHub Actions</a> is not your thing and you find yourself wanting to try something before actually pushing it to GitHub (and having to see the effects on real-life), follow this step by step of how to run your GitHub Actions on your own computer.</p>
 ---
 
-GitHub Actions is a service from GitHub that allows you to automate certain
-tasks of your development cycle, right from your repository. It allows you to
-define a series of commands to be run on specified events, and takes care of
-executing those commands and providing you feedback. You can for instance, run
-tests when code is pushed to a branch, or do a deployment when code is merged to
-master.
-
-You may run into the situation where you have to change your action, push it,
-and wait for GitHub to run it to see if your changes work as intended. In my
-case, I wanted to test an action that is in charge of releasing
-[ember-simple-auth](https://github.com/mainmatter/ember-simple-auth), to see if
-the change I had made worked as I intended. I wanted to avoid having to make a
-release for this and see it fail. After some digging, I couldn't find a way to
-do a dry run of the action from GitHub, but I found
-[act](https://github.com/nektos/act), a library that lets you run your GitHub
-Actions locally.
-
-The library requires Docker, where it builds the images defined in your actions
-and later runs them. So you'll have to install that first. After Docker and
-[act]() are installed, you can start trying out your actions! There are two ways
-to achieve that: telling `act` to trigger an event (see
-[list of events](https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads))
-or to run a job by passing its name.
-
-To trigger an event, from your project folder, you can run `act event_name`. The
-default event is `push` (no need to pass it as an argument). To run a specific
-job, you can do `act -j job_name`.
-
-You can also list all the available actions in your project folder by running
-`act -l`, or run `act event_name -l` to see all the actions run for a specific
-event.
+GitHub Actions is a service from GitHub that allows you to automate certain tasks of your development cycle, right from your repository. It allows you to define a series of commands to be run on specified events, and takes care of executing those commands and providing you feedback. You can for instance, run tests when code is pushed to a branch, or do a deployment when code is merged to master.
+
+You may run into the situation where you have to change your action, push it, and wait for GitHub to run it to see if your changes work as intended. In my case, I wanted to test an action that is in charge of releasing [ember-simple-auth](https://github.com/mainmatter/ember-simple-auth), to see if the change I had made worked as I intended. I wanted to avoid having to make a release for this and see it fail. After some digging, I couldn't find a way to do a dry run of the action from GitHub, but I found [act](https://github.com/nektos/act), a library that lets you run your GitHub Actions locally.
+
+The library requires Docker, where it builds the images defined in your actions and later runs them. So you'll have to install that first. After Docker and [act]() are installed, you can start trying out your actions! There are two ways to achieve that: telling `act` to trigger an event (see [list of events](https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads)) or to run a job by passing its name.
+
+To trigger an event, from your project folder, you can run `act event_name`. The default event is `push` (no need to pass it as an argument). To run a specific job, you can do `act -j job_name`.
+
+You can also list all the available actions in your project folder by running `act -l`, or run `act event_name -l` to see all the actions run for a specific event.
 
 As an example, our release workflow looks something like this:
 
@@ -74,27 +52,21 @@ jobs:
 
 On every push of a tag, we release whatever is in that tag to npm.
 
-To try it out, we can run `act -j release` which uses the job name. When doing
-so, you will see an output that's roughly like this:
+To try it out, we can run `act -j release` which uses the job name. When doing so, you will see an output that's roughly like this:
 
 ![Example output of running act](/assets/images/posts/2021-03-15-trying-github-actions-locally/act-run.mp4#video)
 
-In my case, I wanted to make sure the `npm` tarball included the `README` file,
-which is shown in the publish output here:
+In my case, I wanted to make sure the `npm` tarball included the `README` file, which is shown in the publish output here:
 
 ![Partial view of npm publish output where README file can be seen](/assets/images/posts/2021-03-15-trying-github-actions-locally/readme-output.png#@800-1600)
 
 After that, I committed my changes with confidence.
 
-P.S.: `act` is still under development, occasionally you may run into errors
-like these: {% raw %}
+P.S.: `act` is still under development, occasionally you may run into errors like these: {% raw %}
 
 ```
 Error: yaml: unmarshal errors:
   line 92: cannot unmarshal !!str `${{ mat...` into bool
 ```
 
-It could mean a specific syntax is not yet supported, in this case, the use of
-`${{...}}` in `continue-on-error`. Since this wasn't part of the
-workflow/actions I wanted to try, I just worked around that by commenting that
-line so `act` wouldn't fail when parsing my actions. {% endraw %}
+It could mean a specific syntax is not yet supported, in this case, the use of `${{...}}` in `continue-on-error`. Since this wasn't part of the workflow/actions I wanted to try, I just worked around that by commenting that line so `act` wouldn't fail when parsing my actions. {% endraw %}
diff --git a/src/posts/2021-05-26-keeping-a-clean-git-history.md b/src/posts/2021-05-26-keeping-a-clean-git-history.md
index ec317f1ea7..2992b10f83 100644
--- a/src/posts/2021-05-26-keeping-a-clean-git-history.md
+++ b/src/posts/2021-05-26-keeping-a-clean-git-history.md
@@ -13,330 +13,132 @@ tagline: |
   <p>This post is designed to help you form a solid mental model while working with Git both professionally and in an open source project, and how to ensure you are following best practices to make the process easier for everyone.</p>
 ---
 
-This topic was inspired by some of my pairing sessions with my colleague
-[Tobias Bieniek](https://twitter.com/tobiasbieniek) and the concepts laid out in
-this post have become invaluable to me while working with open source
-development. If you haven't already checked out
-[Tobias' blog on Open Source maintenance](/blog/2018/11/27/open-source-maintenance/)
-I would highly recommend checking it out after reading this post 🎉
+This topic was inspired by some of my pairing sessions with my colleague [Tobias Bieniek](https://twitter.com/tobiasbieniek) and the concepts laid out in this post have become invaluable to me while working with open source development. If you haven't already checked out [Tobias' blog on Open Source maintenance](/blog/2018/11/27/open-source-maintenance/) I would highly recommend checking it out after reading this post 🎉
 
 ## Git complexities
 
-Git can sometimes be complex to get your head around. Most of us learn Git up to
-a point where we're happy to use it day-to-day and then stick to the few
-commands that we are comfortable with without trying anything too fancy. Most of
-the time this works out, but then every so often we do something wrong or
-someone asks us to rebase or "squash" something and we either panic and/or mess
-up our git repo 😫 This is such a common feeling that sites like
-[Oh shit, git!](https://ohshitgit.com/) have cropped up to help us _get out of
-our messes_.
-
-It's my belief that a number of factors have held developers back from becoming
-super productive with Git, and with a bit of guidance in pairing sessions I can
-usually help people to unlock their full potential while using Git. This
-potential I am talking about is not anything so complex as dealing with the
-reflog, or knowing anything about blobs or the internals of Git, I am just
-talking about people feeling comfortable understanding branches, rebasing,
-cherrypicking, and have the ability to clean up a branch before submitting it to
-a Pull Request (PR).
-
-The most egregious thing that holds back people's understanding of Git is the
-concept that "if you don't use git on the command line then you're not a real
-developer" and this idea it needs to die. Sure there are plenty of places in the
-tech community where we have a gatekeeper problem, but this particular idea of
-"you're not a real developer if you don't do X" is the most pervasive and
-destructive. The fact that we funnel so many junior and intermediate developers
-into using git on the command line, I believe, has significantly hampered their
-ability to truly master Git.
-
-This is why, whenever I get the chance, I always recommend people to just
-download [Fork](https://git-fork.com/). I have always been a visual learner so
-when I think about Git I very much **see** the branching model in my head. Even
-if you don't know exactly what you're looking at when you see the Fork
-interface, you will pick up the concepts of branching in Git much faster when
-you see a command's effect on the tree visualisation rather than an abstract set
-of characters in the command line.
+Git can sometimes be complex to get your head around. Most of us learn Git up to a point where we're happy to use it day-to-day and then stick to the few commands that we are comfortable with without trying anything too fancy. Most of the time this works out, but then every so often we do something wrong or someone asks us to rebase or "squash" something and we either panic and/or mess up our git repo 😫 This is such a common feeling that sites like [Oh shit, git!](https://ohshitgit.com/) have cropped up to help us _get out of our messes_.
+
+It's my belief that a number of factors have held developers back from becoming super productive with Git, and with a bit of guidance in pairing sessions I can usually help people to unlock their full potential while using Git. This potential I am talking about is not anything so complex as dealing with the reflog, or knowing anything about blobs or the internals of Git, I am just talking about people feeling comfortable understanding branches, rebasing, cherrypicking, and have the ability to clean up a branch before submitting it to a Pull Request (PR).
+
+The most egregious thing that holds back people's understanding of Git is the concept that "if you don't use git on the command line then you're not a real developer" and this idea it needs to die. Sure there are plenty of places in the tech community where we have a gatekeeper problem, but this particular idea of "you're not a real developer if you don't do X" is the most pervasive and destructive. The fact that we funnel so many junior and intermediate developers into using git on the command line, I believe, has significantly hampered their ability to truly master Git.
+
+This is why, whenever I get the chance, I always recommend people to just download [Fork](https://git-fork.com/). I have always been a visual learner so when I think about Git I very much **see** the branching model in my head. Even if you don't know exactly what you're looking at when you see the Fork interface, you will pick up the concepts of branching in Git much faster when you see a command's effect on the tree visualisation rather than an abstract set of characters in the command line.
 
 ![Screenshot of Fork with a number of branches](/assets/images/posts/2021-05-26-keeping-a-clean-git-history/fork-screenshot.png)
 
 ## It's all in the eye of the reviewer
 
-So what is the point of mastering Git and becoming a rebasing wizard with the
-ability to rewrite history like you are Hermione Granger wielding a time turner‽
-
-The point of this post is not to get everyone rebasing their branches for the
-sake of feeling cool, but instead I hope that more people learn **just enough**
-Git skills to achieve one simple goal: make your pull requests more focused and
-understandable to improve their chance of getting merged quickly (or even
-getting merged at all).
-
-Making sure your pull requests have a good Git history can really streamline the
-review process for your colleagues or maintainers of Open Source projects, and
-has the added benefit of keeping the Git history clean in the long run. This
-will help your colleagues, or even your future self, understand the thought
-process behind your PR if you ever need to go back and do some code archaeology
-to figure out why something was added or changed in the codebase.
-
-Open source projects tend to receive a large number of PRs out of the blue, some
-of them are great but sometimes you get the dreaded "rewrite all your code" PR.
-These are often very hard to ever get merged (if you would even want to merge
-them) because they end up touching too much stuff in the same PR and can make it
-next to impossible to review properly.
-
-I like to say to people interested in getting involved in OSS "the smaller the
-PR the more likely it will be to get merged". This doesn't just apply to
-external contributors. When I'm working on any Open Source project that I
-manage, I try to take this into account and split any large rewrite or
-substantial change into a series of smaller iterations.
-
-It is also important to note that when I refer to a "change" I'm not referring
-to the classic Git reporting of _number of lines changed_. We are not computers
-and we don't really care how many bits were flipped in a Pull Request. What we
-really care about is the **number of concepts** that changed in a particular PR.
-I have discussed this a bit with my colleagues and the best example I can come
-up with is that I don't mind a PR that fixes 1000 instances of a linting rule as
-long as it's the **same conceptual change** in all lines that are changed. If
-you change 10 instances of one rule and 1 instance of another rule, the
-cognitive load of reviewing that PR becomes too much.
-
-While this post inspired by my work in open source, I have also recently given a
-[Git Workshop](https://mainmatter.com/resources/workshop/effective-git) for a
-client where we communicated the exact same concepts: "the smaller the PR the
-more likely it will be to get merged quickly". And if you or your employer cares
-about efficiency then this can only be a good thing 😉
+So what is the point of mastering Git and becoming a rebasing wizard with the ability to rewrite history like you are Hermione Granger wielding a time turner‽
+
+The point of this post is not to get everyone rebasing their branches for the sake of feeling cool, but instead I hope that more people learn **just enough** Git skills to achieve one simple goal: make your pull requests more focused and understandable to improve their chance of getting merged quickly (or even getting merged at all).
+
+Making sure your pull requests have a good Git history can really streamline the review process for your colleagues or maintainers of Open Source projects, and has the added benefit of keeping the Git history clean in the long run. This will help your colleagues, or even your future self, understand the thought process behind your PR if you ever need to go back and do some code archaeology to figure out why something was added or changed in the codebase.
+
+Open source projects tend to receive a large number of PRs out of the blue, some of them are great but sometimes you get the dreaded "rewrite all your code" PR. These are often very hard to ever get merged (if you would even want to merge them) because they end up touching too much stuff in the same PR and can make it next to impossible to review properly.
+
+I like to say to people interested in getting involved in OSS "the smaller the PR the more likely it will be to get merged". This doesn't just apply to external contributors. When I'm working on any Open Source project that I manage, I try to take this into account and split any large rewrite or substantial change into a series of smaller iterations.
+
+It is also important to note that when I refer to a "change" I'm not referring to the classic Git reporting of _number of lines changed_. We are not computers and we don't really care how many bits were flipped in a Pull Request. What we really care about is the **number of concepts** that changed in a particular PR. I have discussed this a bit with my colleagues and the best example I can come up with is that I don't mind a PR that fixes 1000 instances of a linting rule as long as it's the **same conceptual change** in all lines that are changed. If you change 10 instances of one rule and 1 instance of another rule, the cognitive load of reviewing that PR becomes too much.
+
+While this post inspired by my work in open source, I have also recently given a [Git Workshop](https://mainmatter.com/resources/workshop/effective-git) for a client where we communicated the exact same concepts: "the smaller the PR the more likely it will be to get merged quickly". And if you or your employer cares about efficiency then this can only be a good thing 😉
 
 ## Smallest number of commits for the smallest conceptual change
 
-So far I have been writing in terms of abstract ideas. This may be useful to a
-few people but I think most people would find it a bit difficult to convert what
-I have said so far into meaningful strategies to improve their Pull Requests in
-future. Let's look at a concrete example that illustrates the point that I'm
-trying to make with this blog.
+So far I have been writing in terms of abstract ideas. This may be useful to a few people but I think most people would find it a bit difficult to convert what I have said so far into meaningful strategies to improve their Pull Requests in future. Let's look at a concrete example that illustrates the point that I'm trying to make with this blog.
 
-Let's assume you now have a good "small" PR. I am calling this "small" because
-it might have a lot of lines changed, but it is only one **conceptual** change
-as I described in the last section. This PR of yours may be small from a
-conceptual perspective, but it may have taken you quite a few commits to
-complete it. Here is an example PR that I know has too many commits:
-https://github.com/ember-learn/guides-app/pull/19
+Let's assume you now have a good "small" PR. I am calling this "small" because it might have a lot of lines changed, but it is only one **conceptual** change as I described in the last section. This PR of yours may be small from a conceptual perspective, but it may have taken you quite a few commits to complete it. Here is an example PR that I know has too many commits: https://github.com/ember-learn/guides-app/pull/19
 
-If you look at the
-[list of commits](https://github.com/ember-learn/guides-app/pull/19/commits) you
-will see commit messages that look like:
+If you look at the [list of commits](https://github.com/ember-learn/guides-app/pull/19/commits) you will see commit messages that look like:
 
 - Testing Percy integration
 - Revert "testing percy integration"
 - fixing the Percy ignore rules
 
-This is a great example of something that isn't very helpful for people
-reviewing, and it also doesn't tell us anything meaningful about the work that
-was done. This is essentially showing everyone your **failed experiments** and
-is one of the examples of things that are so objectively unhelpful that we can
-even make a rule about it:
+This is a great example of something that isn't very helpful for people reviewing, and it also doesn't tell us anything meaningful about the work that was done. This is essentially showing everyone your **failed experiments** and is one of the examples of things that are so objectively unhelpful that we can even make a rule about it:
 
-> Rule 1: Don't waste your reviewer's time by showing them all your failed
-> experiments in your Git history.
+> Rule 1: Don't waste your reviewer's time by showing them all your failed experiments in your Git history.
 
-Some people might see commits like this and use this as a justification to
-recommend squashing commits when merging this PR. I happen to disagree with this
-sentiment because I believe this wipes out all the history of what happened in
-this PR. Git history is fundamentally useful, as long as it is clean.
+Some people might see commits like this and use this as a justification to recommend squashing commits when merging this PR. I happen to disagree with this sentiment because I believe this wipes out all the history of what happened in this PR. Git history is fundamentally useful, as long as it is clean.
 
-In case anyone doesn't know exactly what I mean by "squashing commits when
-merging this PR" let me show you the Git history when you do a squash-merge and
-compare it to a merge-commit. Here is a screenshot of what the branch looks like
-before you have merged anything:
+In case anyone doesn't know exactly what I mean by "squashing commits when merging this PR" let me show you the Git history when you do a squash-merge and compare it to a merge-commit. Here is a screenshot of what the branch looks like before you have merged anything:
 
 ![Screenshot of a branch that is ready to be merged](/assets/images/posts/2021-05-26-keeping-a-clean-git-history/pr-ready.png)
 
-The following photo is what it looks like when you create a merge commit when
-merging on Github (the default behaviour):
+The following photo is what it looks like when you create a merge commit when merging on Github (the default behaviour):
 
 ![Screenshot of a the branch merged using a merge commit](/assets/images/posts/2021-05-26-keeping-a-clean-git-history/merge-commit.png)
 
-This next photo is the same merge action on Github but this time using the
-"squash and merge" functionality of Github:
+This next photo is the same merge action on Github but this time using the "squash and merge" functionality of Github:
 
 ![Screenshot of a the branch merged using a squash commit](/assets/images/posts/2021-05-26-keeping-a-clean-git-history/squash-commit.png)
 
-You might think that there isn't much of a difference between these screenshots,
-and from a "code on disk" perspective you would be right. The same code will be
-in the `master` branch at the end of both of these operations, but as you can
-see the history is very different. You are only able to see the previous commits
-in this example because they are still on the remote `origin/feature/deploy`
-branch and I have a local copy of that branch on my computer. If you delete that
-remote branch all other contributors to this repo in the future would see a
-history that looks a little bit more like this:
+You might think that there isn't much of a difference between these screenshots, and from a "code on disk" perspective you would be right. The same code will be in the `master` branch at the end of both of these operations, but as you can see the history is very different. You are only able to see the previous commits in this example because they are still on the remote `origin/feature/deploy` branch and I have a local copy of that branch on my computer. If you delete that remote branch all other contributors to this repo in the future would see a history that looks a little bit more like this:
 
 ![Screenshot of a the branch merged using a squash commit](/assets/images/posts/2021-05-26-keeping-a-clean-git-history/actual-history-after-squash.png)
 
-As I mentioned at the beginning of this post, you should always be thinking
-about brave explorers that may be digging into the history of your code a year
-from now trying to figure out what was done and **why** it was done that way. A
-single commit that has a diff with `+4,762 −1,368` changes will be very hard to
-understand and will likely slow down anyone who is doing serious code
-archaeology.
-
-These examples all come from a branch that I created for a now deprecated
-repository. As it turns out, the branch was so big and the history was so
-unhelpful that whoever merged that branch chose to squash and merge so the
-history was lost. I was only able to revive the history for these examples using
-some extreme git mastery that is far above what a reasonable code archaeologist
-should be expected to do when trying to figure out what happened, and which also
-doesn't work if you're trying to do a git-bisect to find the source of an issue.
-
-The answer to this problem is to maintain a Git history closest to the **true
-essence** of the work done, creating a number of small PRs that each makes **one
-releasable change** to the codebase and keeping the number of commits as low as
-possible. The question becomes, how can we effectively do that?
+As I mentioned at the beginning of this post, you should always be thinking about brave explorers that may be digging into the history of your code a year from now trying to figure out what was done and **why** it was done that way. A single commit that has a diff with `+4,762 −1,368` changes will be very hard to understand and will likely slow down anyone who is doing serious code archaeology.
+
+These examples all come from a branch that I created for a now deprecated repository. As it turns out, the branch was so big and the history was so unhelpful that whoever merged that branch chose to squash and merge so the history was lost. I was only able to revive the history for these examples using some extreme git mastery that is far above what a reasonable code archaeologist should be expected to do when trying to figure out what happened, and which also doesn't work if you're trying to do a git-bisect to find the source of an issue.
+
+The answer to this problem is to maintain a Git history closest to the **true essence** of the work done, creating a number of small PRs that each makes **one releasable change** to the codebase and keeping the number of commits as low as possible. The question becomes, how can we effectively do that?
 
 ## Rebasing, fixups, and moderate git mastery - a case study
 
-I'm going to spend some time actually fixing the PR that I was using as an
-example in the previous section. This way you can see a practical example and
-see a good before-and-after shot to compare the difference. I will also go into
-some detail about each technique that I will use to actually perform the changes
-in question.
-
-Some of the techniques that I will be using are rebase, interactive rebase,
-fixup, cherrypicking, and commit splitting. Reading this list you might feel
-like this article is targeted at the advanced Git user, but I would say that
-this is not the case. With a tiny bit of guidance I believe every developer can
-start making use of these powerful intermediate git tools and improve their
-workflows.
-
-First things first, if you want to follow along with my examples you will need
-to install the Git client called [Fork](https://git-fork.com/). I now use Fork
-exclusively when I'm trying to do anything that requires you to have an image of
-the Git history in your mind. This is mainly because it gives you such a great
-visualisation of the history and you can actively see the effect your changes
-have. Each of the examples in the previous section are screenshots from Fork.
-
-It is also worth mentioning that using Fork is not something that I consider
-optional for the techniques that I am about to go through. Sure you can achieve
-everything that I'm about to show you using only the command line, but I have
-seen much more experienced developers than I struggle and make catastrophic
-mistakes while using git on the command line. When people see examples of what I
-do regularly with git and think I'm some sort of Git wizard, I usually tell them
-that I'm just playing the game on easy mode using a visual Git tool like Fork.
-If you take anything away from this article let it be to ignore any gatekeepers
-in the industry that might tell you "you're not a real developer if you don't
-use Git on the command line" and just start using Fork for 90% of the operations
-that you do with Git.
-
-Now it's time to get started. The first thing that I like to do when trying to
-split a giant PR into multiple smaller PRs is to go through each of the commits
-and see very roughly what they are doing. This gives you a feeling for what the
-overall PR is trying to achieve and it should allow you to locate any smaller
-issues that can be fixed right away. To do this I literally just click through
-each commit on the branch and browse some of the changes in Fork, starting at
-the **bottom** of the branch in Fork because the oldest commit is at the bottom
-and the newest is at the top.
+I'm going to spend some time actually fixing the PR that I was using as an example in the previous section. This way you can see a practical example and see a good before-and-after shot to compare the difference. I will also go into some detail about each technique that I will use to actually perform the changes in question.
+
+Some of the techniques that I will be using are rebase, interactive rebase, fixup, cherrypicking, and commit splitting. Reading this list you might feel like this article is targeted at the advanced Git user, but I would say that this is not the case. With a tiny bit of guidance I believe every developer can start making use of these powerful intermediate git tools and improve their workflows.
+
+First things first, if you want to follow along with my examples you will need to install the Git client called [Fork](https://git-fork.com/). I now use Fork exclusively when I'm trying to do anything that requires you to have an image of the Git history in your mind. This is mainly because it gives you such a great visualisation of the history and you can actively see the effect your changes have. Each of the examples in the previous section are screenshots from Fork.
+
+It is also worth mentioning that using Fork is not something that I consider optional for the techniques that I am about to go through. Sure you can achieve everything that I'm about to show you using only the command line, but I have seen much more experienced developers than I struggle and make catastrophic mistakes while using git on the command line. When people see examples of what I do regularly with git and think I'm some sort of Git wizard, I usually tell them that I'm just playing the game on easy mode using a visual Git tool like Fork. If you take anything away from this article let it be to ignore any gatekeepers in the industry that might tell you "you're not a real developer if you don't use Git on the command line" and just start using Fork for 90% of the operations that you do with Git.
+
+Now it's time to get started. The first thing that I like to do when trying to split a giant PR into multiple smaller PRs is to go through each of the commits and see very roughly what they are doing. This gives you a feeling for what the overall PR is trying to achieve and it should allow you to locate any smaller issues that can be fixed right away. To do this I literally just click through each commit on the branch and browse some of the changes in Fork, starting at the **bottom** of the branch in Fork because the oldest commit is at the bottom and the newest is at the top.
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/0l4hvOa4bac?rel=0" title="Embedded video of browsing the git history" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-Looking through the commits I have already seen a whole bunch of simple issues
-that could be fixed. The most obvious and easiest to fix is the pair of commits
-`testing percy integration` and `Revert "testing percy integration"`. This is a
-perfect example of the thing I said earlier in this post where you **should not
-show the reviewer your failed experiments**. If our branch didn't have either of
-these commits the outcome would be exactly the same, so let's remove them!
+Looking through the commits I have already seen a whole bunch of simple issues that could be fixed. The most obvious and easiest to fix is the pair of commits `testing percy integration` and `Revert "testing percy integration"`. This is a perfect example of the thing I said earlier in this post where you **should not show the reviewer your failed experiments**. If our branch didn't have either of these commits the outcome would be exactly the same, so let's remove them!
 
-Note: Instead of trying to write out the full instructions of how to make these
-changes I will demonstrate each of the techniques used in the rest of this post
-in an embedded video. This has the benefit of being able to see the exact steps
-that I need to do in Fork to achieve the intended goal and avoids any chance
-that I missed a step in my description.
+Note: Instead of trying to write out the full instructions of how to make these changes I will demonstrate each of the techniques used in the rest of this post in an embedded video. This has the benefit of being able to see the exact steps that I need to do in Fork to achieve the intended goal and avoids any chance that I missed a step in my description.
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/HbWmZbhN-A4?rel=0" title="Embedded video of removing reverted commit" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-The next thing that I'm going to demonstrate is using the "fixup" command when
-in an interactive rebase. This is another useful tool when trying to not show
-the reviewer any of your failed experiments. The way I like to think of this
-particular technique is that, firstly, all the commits in your PR should be
-considered as being _additive_ in that they are adding a feature or a concept to
-the codebase (even if you're actually deleting files). Each of the commits
-should be building on top of each other to get from the current state of the
-repo to the added concept, and you should do that in a straight line and not
-zig-zag back on yourself. What this means in practice is that you should
-**never** see a commit that "fixes lint" on something that was added in a
-previous commit. So let's **fixup** some of these "fix lint". Commits now.
+The next thing that I'm going to demonstrate is using the "fixup" command when in an interactive rebase. This is another useful tool when trying to not show the reviewer any of your failed experiments. The way I like to think of this particular technique is that, firstly, all the commits in your PR should be considered as being _additive_ in that they are adding a feature or a concept to the codebase (even if you're actually deleting files). Each of the commits should be building on top of each other to get from the current state of the repo to the added concept, and you should do that in a straight line and not zig-zag back on yourself. What this means in practice is that you should **never** see a commit that "fixes lint" on something that was added in a previous commit. So let's **fixup** some of these "fix lint". Commits now.
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/_20fveDyDEI?rel=0" title="Embedded video of using fixup to remove fix lint commits" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-Looking through some of the other commits I can see there is one that fixes some
-lint issues that were actually introduced in multiple different commits. This
-makes it a tiny bit more difficult to fixup because we can't just apply it to a
-single commit in our existing history. The way around this is to split this
-single commit into multiple commits using the "edit" command during an
-interactive rebase:
+Looking through some of the other commits I can see there is one that fixes some lint issues that were actually introduced in multiple different commits. This makes it a tiny bit more difficult to fixup because we can't just apply it to a single commit in our existing history. The way around this is to split this single commit into multiple commits using the "edit" command during an interactive rebase:
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/4JSRVws9a2k?rel=0" title="Embedded video of using edit in an interactive rebase" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-Once the commit has been split we can then use fixup again exactly as we did in
-the previous example.
+Once the commit has been split we can then use fixup again exactly as we did in the previous example.
 
-Now that we have the skills needed to cleanup all the "fix" commits, I'm going
-to go ahead and apply these techniques to the rest of the branch. Just to be
-clear, I'm not going to use any techniques other than what I have explained so
-far in this post.
+Now that we have the skills needed to cleanup all the "fix" commits, I'm going to go ahead and apply these techniques to the rest of the branch. Just to be clear, I'm not going to use any techniques other than what I have explained so far in this post.
 
-After about 20 minutes of investigating and rebasing I have ended up with a new
-history that is a significant improvement from what we had before
+After about 20 minutes of investigating and rebasing I have ended up with a new history that is a significant improvement from what we had before
 
 ![Screenshot of an improved history in Fork](/assets/images/posts/2021-05-26-keeping-a-clean-git-history/improved-history.png)
 
-This has improved the commit list from 34 commits to 22! But this is still far
-too many commits for a single reviewer to be expected to look at all at once.
-The problem that we currently face is that there are multiple "features" or
-"logical changes" happening in this branch, and if we were to convert this
-branch into a PR then we would be breaking one of my only rules: a PR should
-only be making a single logical change.
+This has improved the commit list from 34 commits to 22! But this is still far too many commits for a single reviewer to be expected to look at all at once. The problem that we currently face is that there are multiple "features" or "logical changes" happening in this branch, and if we were to convert this branch into a PR then we would be breaking one of my only rules: a PR should only be making a single logical change.
 
-So let's start pulling out some logical Pull requests! I'll start with a super
-simple one to demonstrate using interactive rebase or cherry-pick to pull out a
-single commit.
+So let's start pulling out some logical Pull requests! I'll start with a super simple one to demonstrate using interactive rebase or cherry-pick to pull out a single commit.
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/h5f8ibnEm0c?rel=0" title="Embedded video of creating a new branch for a pull request" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-As you can see in the video, creating the new branch using interactive rebase or
-using cherrypicking results in identical branches. It doesn't matter which
-method that you use but I would recommend getting comfortable with each method
-as they both can be useful depending on the situation. Once you have this branch
-you can go through your normal process of pushing to GitHub and opening a PR.
-Once that PR is merged we will then need to rebase our feature branch on master,
-which should usually automatically remove the commits that we split out into the
-other PR. This time it just needs to be a standard rebase without using
-interactive rebase, and it should cause no issues. I have included a quick video
-of that process for completeness:
+As you can see in the video, creating the new branch using interactive rebase or using cherrypicking results in identical branches. It doesn't matter which method that you use but I would recommend getting comfortable with each method as they both can be useful depending on the situation. Once you have this branch you can go through your normal process of pushing to GitHub and opening a PR. Once that PR is merged we will then need to rebase our feature branch on master, which should usually automatically remove the commits that we split out into the other PR. This time it just needs to be a standard rebase without using interactive rebase, and it should cause no issues. I have included a quick video of that process for completeness:
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/xEnwBpDBXNg?rel=0" title="Embedded video of rebasing on master after pull request was merged" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-And that's it! I have now shown you all of the techniques that you need to be
-able to clean up your git history and truly make your reviewer's days better. I
-would encourage you to try out these techniques and get more comfortable with
-them over time, and hopefully you will start reaching for these techniques on a
-regular basis.
+And that's it! I have now shown you all of the techniques that you need to be able to clean up your git history and truly make your reviewer's days better. I would encourage you to try out these techniques and get more comfortable with them over time, and hopefully you will start reaching for these techniques on a regular basis.
 
-I've spent a little bit of time applying the techniques described above to the
-rest of the commits in the `feature/deploy` branch as a demonstration of what it
-will ultimately look like. Here it is for reference:
+I've spent a little bit of time applying the techniques described above to the rest of the commits in the `feature/deploy` branch as a demonstration of what it will ultimately look like. Here it is for reference:
 
 ![Screenshot of the finished version of the branch with everything cleaned up](/assets/images/posts/2021-05-26-keeping-a-clean-git-history/finished-version.png)
 
-This screenshot is a perfect example of a git history in my opinion. It has
-plenty of very small PRs that only have one commit in them, allowing the PR to
-be reviewed and merged very quickly. It also has clear and understandable
-commits in the larger PRs that can be reviewed commit-by-commit if the reviewer
-would prefer, while still encapsulating the similar commits in a branch (and not
-over-splitting branches and PRs).
+This screenshot is a perfect example of a git history in my opinion. It has plenty of very small PRs that only have one commit in them, allowing the PR to be reviewed and merged very quickly. It also has clear and understandable commits in the larger PRs that can be reviewed commit-by-commit if the reviewer would prefer, while still encapsulating the similar commits in a branch (and not over-splitting branches and PRs).
 
 ## Summary
 
-When I started writing this post I didn't expect it to be quite as long as it
-turned out, but hopefully this can be a holistic guide for anyone who is using
-Git but doesn't have a clear mental model for best practices around PRs,
-merging, squashing, and rebasing.
+When I started writing this post I didn't expect it to be quite as long as it turned out, but hopefully this can be a holistic guide for anyone who is using Git but doesn't have a clear mental model for best practices around PRs, merging, squashing, and rebasing.
 
-While everything in this post is completely optional, I hope that you can see
-the benefits and maybe adopt some of the ideas in your own workflow.
+While everything in this post is completely optional, I hope that you can see the benefits and maybe adopt some of the ideas in your own workflow.
diff --git a/src/posts/2021-06-02-how-to-create-an-interface-inventory.md b/src/posts/2021-06-02-how-to-create-an-interface-inventory.md
index 6aa9b72295..e77e9577cf 100644
--- a/src/posts/2021-06-02-how-to-create-an-interface-inventory.md
+++ b/src/posts/2021-06-02-how-to-create-an-interface-inventory.md
@@ -12,80 +12,53 @@ tagline: |
 
 ## Interface inventories 101
 
-An interface inventory is a categorized collection of every piece of design that
-makes up our digital product. They help us capture the status quo of every style
-(e.g. colors, typography, spacing, borders) and components of a user interface.
+An interface inventory is a categorized collection of every piece of design that makes up our digital product. They help us capture the status quo of every style (e.g. colors, typography, spacing, borders) and components of a user interface.
 
 There are many benefits for creating one:
 
-1. They help us gain clarity regarding which design components make up a digital
-   product.
+1. They help us gain clarity regarding which design components make up a digital product.
 2. Help us discover and analyze unintentional inconsistencies between them.
-3. Is a conversation starter for our team on how to refactor design with a
-   pattern-based approach.
+3. Is a conversation starter for our team on how to refactor design with a pattern-based approach.
 4. It serves as a blueprint for a pattern library.
-5. And last but not least, it is an aid to communicate and gain buy-in from
-   stakeholders to establish a design system.
+5. And last but not least, it is an aid to communicate and gain buy-in from stakeholders to establish a design system.
 
 ![An interface inventory displaying the button category](/assets/images/posts/2021-06-02-interface-inventory/interface_inventory.jpg#@800-1600)
 
 ## When should you start?
 
-An interface inventory can be done at any phase of the product development
-process. Some teams start when kicking off a redesign or if they are struggling
-with confusion due to inconsistencies. However, there also may be no perfect
-time to start. If you and your team don't have a clear overview of your digital
-design, use that as a sign to get started with an interface inventory.
+An interface inventory can be done at any phase of the product development process. Some teams start when kicking off a redesign or if they are struggling with confusion due to inconsistencies. However, there also may be no perfect time to start. If you and your team don't have a clear overview of your digital design, use that as a sign to get started with an interface inventory.
 
 ## Planning the project
 
-When planning an interface inventory, we can lean on Nielsen Norman Group's
-[guidelines for content inventory and auditing](https://www.nngroup.com/articles/content-audits/).
-These ensure we are thinking of people, process, and tools:
+When planning an interface inventory, we can lean on Nielsen Norman Group's [guidelines for content inventory and auditing](https://www.nngroup.com/articles/content-audits/). These ensure we are thinking of people, process, and tools:
 
 ### 1. People
 
-- Establish ownership: Ensure there is a person responsible for both the process
-  of creating an inventory and the artifacts that are created as a result.
-- Involve others early on: Inform stakeholders, designers, developers, and
-  product managers–anyone working on building the digital product. Agree on the
-  inventory criteria (e.g. color, spacing, typography, borders, sizes).
-- Provide meaningful updates: Others are more likely to trust and care about
-  what you do with the interface if you keep them meaningfully informed. Don't
-  overwhelm with detail, and end with a funny gif (always end with a gif!).
+- Establish ownership: Ensure there is a person responsible for both the process of creating an inventory and the artifacts that are created as a result.
+- Involve others early on: Inform stakeholders, designers, developers, and product managers–anyone working on building the digital product. Agree on the inventory criteria (e.g. color, spacing, typography, borders, sizes).
+- Provide meaningful updates: Others are more likely to trust and care about what you do with the interface if you keep them meaningfully informed. Don't overwhelm with detail, and end with a funny gif (always end with a gif!).
 
 ### 2. Process
 
-- Develop a "baby steps" mindset: Break up the effort in small increments. Start
-  with a manageable yet impactful subset.
-- Prioritize core features, the happy path (the optimal user journey), or the
-  top-level navigation.
-- Divide and conquer with collaborators. Give a concrete example of the process
-  of capturing design for the inventory.
+- Develop a "baby steps" mindset: Break up the effort in small increments. Start with a manageable yet impactful subset.
+- Prioritize core features, the happy path (the optimal user journey), or the top-level navigation.
+- Divide and conquer with collaborators. Give a concrete example of the process of capturing design for the inventory.
 
 ### 3. Tools
 
-- Choose a tool that has a low learning curve. Use something that is already in
-  your toolset and is familiar to collaborators.
-- Explore automation tools to gather data. However, ensure people handle the
-  audit portion.
-- Time-box it (e.g. an initial period of 6 weeks). Make some meaningful progress
-  and gain momentum.
+- Choose a tool that has a low learning curve. Use something that is already in your toolset and is familiar to collaborators.
+- Explore automation tools to gather data. However, ensure people handle the audit portion.
+- Time-box it (e.g. an initial period of 6 weeks). Make some meaningful progress and gain momentum.
 
 ## Step-by-step process
 
 ### Step 1: Identify the scope
 
-Start off by identifying which part of your digital product you will be creating
-an inventory of first. You can decide on starting an inventory of the happy
-path, your core features, or your website's top-level navigation.
+Start off by identifying which part of your digital product you will be creating an inventory of first. You can decide on starting an inventory of the happy path, your core features, or your website's top-level navigation.
 
 ### Step 2: Identify which characteristics you want to inventory
 
-An interface inventory includes specific characteristics which are captured at
-several layers. For example, a component (a button) can be captured as such, as
-well as through the foundational styles that create it (colors, typography,
-icons, spacing).
+An interface inventory includes specific characteristics which are captured at several layers. For example, a component (a button) can be captured as such, as well as through the foundational styles that create it (colors, typography, icons, spacing).
 
 Use the following as a guideline:
 
@@ -114,70 +87,41 @@ Components are reusable UI elements made with foundations:
 
 ### Step 3: Observe the existing CSS
 
-When making an inventory of the foundations, [CSS stats](https://cssstats.com/)
-can be a good place to start. CSS Stats is a free and open-source tool to help
-visualize stylesheets. You can gain insights on existing layout and structure
-(display, float, width, height), spacing (padding & margin), skins (color,
-background color, border color, box-shadow), typography (font family, size,
-weight, alignment, line height, etc.. ), and border styles.
+When making an inventory of the foundations, [CSS stats](https://cssstats.com/) can be a good place to start. CSS Stats is a free and open-source tool to help visualize stylesheets. You can gain insights on existing layout and structure (display, float, width, height), spacing (padding & margin), skins (color, background color, border color, box-shadow), typography (font family, size, weight, alignment, line height, etc.. ), and border styles.
 
 ![An interface inventory displaying the icon category](/assets/images/posts/2021-06-02-interface-inventory/css-stats.png#@800-1600)
 
 ### Step 4: Manually capture styles in your selected inventory scope
 
-Although it might be tempting to run CSS Stats and call it a day, we recommend
-using it only as a first step and manually inspecting all elements in your
-chosen scope. This helps us gain an understanding of what is being used where,
-which is essential in step 5 (auditing our inventory).
-
-In order to capture styles, use your browser's developer tools to inspect the
-page. Knowing how to use the developer tools is certainly a skill that I
-recommend all designers and product experts to add to their tool belt. On
-Chrome, right-click anywhere, and click "Inspect" from the bottom of the menu.
-
-As an alternative, there are many browser extensions made to identify certain
-properties on the page, for example:
-[WhatFont](https://chrome.google.com/webstore/detail/whatfont/jabopobgcpjmedljpbcaablpmlmfcogm?hl=en)
-to identify fonts or
-[ColorZilla](https://chrome.google.com/webstore/detail/colorzilla/bhlhnicpbhignbdhedgjhgdocnmhomnp/related?hl=en)
-to get the color of any pixel.
-
-For icons, imagery, and components, simply take screenshots and organize them.
-You can use existing pattern libraries as a reference, take a look at this
-([curated list](https://designsystemsrepo.com/design-systems)) for inspiration.
-
-Keep in mind the different kinds of design patterns and use them as a guide for
-organizing your interface:
-
-- **Functional:** Reusable parts of an interface. E.g. header, form elements,
-  menu.
-- **Perceptual:** Describing the brand or aesthetics. E.g. iconography and
-  imagery styles, colors, typography, spacing and layout, shapes, design motifs,
-  interactions, animations, sounds.
-- **Platform-specific:** Desktop vs mobile (web), and iOS vs Android (native
-  apps).
-- **Domain-specific:** E-commerce (product displays, shopping cart, checkout),
-  data analysis (grids, charts, visualizations), online learning (progress
-  indicators, discussion threads).
-- **Persuasive:** Cognition, game mechanics (unlock features), perception and
-  memory (chunking), feedback, social (liking, social proof).
+Although it might be tempting to run CSS Stats and call it a day, we recommend using it only as a first step and manually inspecting all elements in your chosen scope. This helps us gain an understanding of what is being used where, which is essential in step 5 (auditing our inventory).
+
+In order to capture styles, use your browser's developer tools to inspect the page. Knowing how to use the developer tools is certainly a skill that I recommend all designers and product experts to add to their tool belt. On Chrome, right-click anywhere, and click "Inspect" from the bottom of the menu.
+
+As an alternative, there are many browser extensions made to identify certain properties on the page, for example: [WhatFont](https://chrome.google.com/webstore/detail/whatfont/jabopobgcpjmedljpbcaablpmlmfcogm?hl=en) to identify fonts or [ColorZilla](https://chrome.google.com/webstore/detail/colorzilla/bhlhnicpbhignbdhedgjhgdocnmhomnp/related?hl=en) to get the color of any pixel.
+
+For icons, imagery, and components, simply take screenshots and organize them. You can use existing pattern libraries as a reference, take a look at this ([curated list](https://designsystemsrepo.com/design-systems)) for inspiration.
+
+Keep in mind the different kinds of design patterns and use them as a guide for organizing your interface:
+
+- **Functional:** Reusable parts of an interface. E.g. header, form elements, menu.
+- **Perceptual:** Describing the brand or aesthetics. E.g. iconography and imagery styles, colors, typography, spacing and layout, shapes, design motifs, interactions, animations, sounds.
+- **Platform-specific:** Desktop vs mobile (web), and iOS vs Android (native apps).
+- **Domain-specific:** E-commerce (product displays, shopping cart, checkout), data analysis (grids, charts, visualizations), online learning (progress indicators, discussion threads).
+- **Persuasive:** Cognition, game mechanics (unlock features), perception and memory (chunking), feedback, social (liking, social proof).
 
 ### Step 5: Audit your inventory
 
-An audit examines and evaluates the quality of the interface in the inventory.
-The goal of an audit is to uncover:
+An audit examines and evaluates the quality of the interface in the inventory. The goal of an audit is to uncover:
 
 - Unintentional inconsistencies
 - Outdated interface
 - Gaps that new interface patterns could fill
 - If a piece of interface should be deprecated
-- Whether our design is meeting or failing guidelines (accessibility, examples,
-  patterns, principles, usage, tone of voice)
+- Whether our design is meeting or failing guidelines (accessibility, examples, patterns, principles, usage, tone of voice)
 
 &nbsp;
 
-This is an example of a typography inventory. In this case, the inventory
-criteria that were relevant are:
+This is an example of a typography inventory. In this case, the inventory criteria that were relevant are:
 
 - Font size
 - Line height
@@ -185,44 +129,14 @@ criteria that were relevant are:
 
 ![An interface inventory displaying the typography category](/assets/images/posts/2021-06-02-interface-inventory/typography_inventory.png#@800-1600)
 
-Notice that font family and weight were not inventoried, as they were irrelevant
-for my goal at the time: to understand what font sizes existed in the live
-website so that I could start working with them when I designed new patterns. I
-gathered this information for both of our breakpoints (mobile and desktop). The
-first step in my audit was to determine whether the color contrast passes or
-fails the
-[WCAG AA accessibility guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/).
-I used WebAIM's
-[Color Contrast Checker](https://webaim.org/resources/contrastchecker/). From
-here I am able to make informed decisions regarding which font styles should be
-deprecated, and which ones should be used in any new component I create.
-
-As another example, an icon inventory. We can see the plethora of styles and
-colors used. In this case, breaking them down further into detailed criteria was
-not necessary as it was clear that we would use an icon library to replace most
-of them. The inventory helped us make an assessment of what should stay or go
-and create guidelines for the future.
+Notice that font family and weight were not inventoried, as they were irrelevant for my goal at the time: to understand what font sizes existed in the live website so that I could start working with them when I designed new patterns. I gathered this information for both of our breakpoints (mobile and desktop). The first step in my audit was to determine whether the color contrast passes or fails the [WCAG AA accessibility guidelines](https://www.w3.org/WAI/standards-guidelines/wcag/). I used WebAIM's [Color Contrast Checker](https://webaim.org/resources/contrastchecker/). From here I am able to make informed decisions regarding which font styles should be deprecated, and which ones should be used in any new component I create.
+
+As another example, an icon inventory. We can see the plethora of styles and colors used. In this case, breaking them down further into detailed criteria was not necessary as it was clear that we would use an icon library to replace most of them. The inventory helped us make an assessment of what should stay or go and create guidelines for the future.
 
 ![An interface inventory displaying the icon category](/assets/images/posts/2021-06-02-interface-inventory/icon_inventory.png#@800-1600)
 
 ### Step 6: Create a game plan with your team
 
-Once the inventory has been created and audited, it's time to meet relevant
-stakeholders and come up with a game plan to remove unintentional
-inconsistencies and improve the existing interface. The goal should be to
-transition into a pattern-based approach, and in the long run, an interface
-inventory can serve as a blueprint for the creation of a pattern library. Since
-it is a visual side-by-side comparison of the existing interface, it helps us
-communicate the status quo in a tangible way, and it's very effective when
-sharing it with stakeholders that are further removed from the digital product
-design and development process (ahem...people that decide on budgets and
-resources).
-
-Interface inventories are small but meaningful when transitioning to a design
-system approach. Making one can help get the ball rolling in your team as they
-help us align and bring in momentum. And know this: even if you do the inventory
-and audit on your own, you are never alone. Consider joining the
-[design systems community on Slack](https://design.systems/slack/) (it's a great
-place to ask questions or get feedback regarding this process), or
-[hire a facilitator](/services/workshops/design-system-kickoff-interface-inventory/)
-to help make this project a success.
+Once the inventory has been created and audited, it's time to meet relevant stakeholders and come up with a game plan to remove unintentional inconsistencies and improve the existing interface. The goal should be to transition into a pattern-based approach, and in the long run, an interface inventory can serve as a blueprint for the creation of a pattern library. Since it is a visual side-by-side comparison of the existing interface, it helps us communicate the status quo in a tangible way, and it's very effective when sharing it with stakeholders that are further removed from the digital product design and development process (ahem...people that decide on budgets and resources).
+
+Interface inventories are small but meaningful when transitioning to a design system approach. Making one can help get the ball rolling in your team as they help us align and bring in momentum. And know this: even if you do the inventory and audit on your own, you are never alone. Consider joining the [design systems community on Slack](https://design.systems/slack/) (it's a great place to ask questions or get feedback regarding this process), or [hire a facilitator](/services/workshops/design-system-kickoff-interface-inventory/) to help make this project a success.
diff --git a/src/posts/2021-07-13-effective-infrastructure-for-efficient-development-workflows.md b/src/posts/2021-07-13-effective-infrastructure-for-efficient-development-workflows.md
index b6e434fc0c..bd67869ac6 100644
--- a/src/posts/2021-07-13-effective-infrastructure-for-efficient-development-workflows.md
+++ b/src/posts/2021-07-13-effective-infrastructure-for-efficient-development-workflows.md
@@ -3,9 +3,7 @@ title: "Effective infrastructure for efficient development workflows"
 authorHandle: marcoow
 tags: process
 bio: "Founder and Managing Director of Mainmatter"
-description:
-  "Marco Otte-Witte on how highly automated and integrated development
-  infrastructure enables simpler and more effective workflows."
+description: "Marco Otte-Witte on how highly automated and integrated development infrastructure enables simpler and more effective workflows."
 og:
   image: /assets/images/posts/2021-07-13-effective-infrastructure-for-efficient-development-workflows/og-image.jpg
 tagline: |
@@ -14,268 +12,88 @@ tagline: |
 
 ## The machine that builds the machine
 
-Elon Musk famously talks about the real challenge that Tesla faced/s isn't
-building cars but building and running the factories for building cars at scale.
-He refers to the factories as _"the machine that builds the machine"_ and while
-the factories aren't still fully autonomous and can't build cars without human
-labor, those humans' productivity is multiplied manyfold through highly
-automated and integrated production processes. The same applies to software
-development – the code isn't going to write itself anytime soon (although
-[we're getting closer to that situation step-by-step](http://copilot.github.com)),
-but with the help of integrated and automated infrastructure, developers are
-enabled to write code more efficiently, faster, and with more certainty.
-
-At the core of every development team's developer workflow, there is git (of
-course [other](https://www.perforce.com) [version](http://darcs.net)
-[control](https://subversion.apache.org) [systems](http://www.nongnu.org/cvs/)
-exist as well, but in reality, almost everyone is using git these days). And
-while git's cheap and simple (admittedly not everyone agrees about that)
-branching model makes it easy for developers to code away in their own branch as
-well as rebase and merge their branches back together, the real challenge that
-teams are facing is orchestrating just that so that one person's changes
-propagate to the codebases others are working on and merged code ends up in the
-production system fast, predictably and with certainty.
-
-Most teams rely on one of two techniques for managing branches and getting
-merged code deployed to production:
-
-- `main` branch plus feature branches: once a pull request is merged, the new
-  version of the `main` branch is deployed to production automatically.
-- `main` or `production` branch, `development` branch and feature branches
-  branched off of that: pull requests are merged into `development`, and that
-  branch is merged into `production` in intervals following some sort of
-  schedule or process.
+Elon Musk famously talks about the real challenge that Tesla faced/s isn't building cars but building and running the factories for building cars at scale. He refers to the factories as _"the machine that builds the machine"_ and while the factories aren't still fully autonomous and can't build cars without human labor, those humans' productivity is multiplied manyfold through highly automated and integrated production processes. The same applies to software development – the code isn't going to write itself anytime soon (although [we're getting closer to that situation step-by-step](http://copilot.github.com)), but with the help of integrated and automated infrastructure, developers are enabled to write code more efficiently, faster, and with more certainty.
+
+At the core of every development team's developer workflow, there is git (of course [other](https://www.perforce.com) [version](http://darcs.net) [control](https://subversion.apache.org) [systems](http://www.nongnu.org/cvs/) exist as well, but in reality, almost everyone is using git these days). And while git's cheap and simple (admittedly not everyone agrees about that) branching model makes it easy for developers to code away in their own branch as well as rebase and merge their branches back together, the real challenge that teams are facing is orchestrating just that so that one person's changes propagate to the codebases others are working on and merged code ends up in the production system fast, predictably and with certainty.
+
+Most teams rely on one of two techniques for managing branches and getting merged code deployed to production:
+
+- `main` branch plus feature branches: once a pull request is merged, the new version of the `main` branch is deployed to production automatically.
+- `main` or `production` branch, `development` branch and feature branches branched off of that: pull requests are merged into `development`, and that branch is merged into `production` in intervals following some sort of schedule or process.
 
 ## Multi-branch setups
 
-While in reality there are thousands of variations of the latter approach, they
-are essentially all the same. The goal of those multi-branch setups is to add a
-safety net between a pull request being merged and the code being deployed to
-the production system. Whenever _"enough"_ changes have accumulated in the
-`development` branch (or a scheduled release date has been reached), those
-changes would typically go through some kind of testing process where they would
-be checked for correctness (and potentially fixed) before eventually making
-their way to the production system(s).
+While in reality there are thousands of variations of the latter approach, they are essentially all the same. The goal of those multi-branch setups is to add a safety net between a pull request being merged and the code being deployed to the production system. Whenever _"enough"_ changes have accumulated in the `development` branch (or a scheduled release date has been reached), those changes would typically go through some kind of testing process where they would be checked for correctness (and potentially fixed) before eventually making their way to the production system(s).
 
 That results in all kinds of inefficiencies though:
 
-- When bugs come up in the `development` branch it's often unclear where they
-  originate; all kinds of unrelated changes have been merged together in the
-  branch so it's unclear whether a bug originates in the pull request that
-  implemented the respective feature or whether it is only caused by the
-  combination of those changes with others.
-- Once bugs or unmet requirements are identified, the developers responsible for
-  the changes will have switched to a different task already since there's a
-  delay between the merge of their PR to the `develop` branch and the
-  testing/validation being performed on that branch. They now have to get back
-  to something they considered done already, get all the context in their minds
-  again while at the same time leaving whatever they are working on now behind,
-  potentially causing problems for others that might be dependant on that work
-  so that in the worst case whole cascades of focus and context switches are
-  triggered.
-- Changes can only be released to production with a delay. Something might be
-  done in one week but could potentially only be released the next week or even
-  later when the next release is scheduled or the testing cycle completes.
-- Sometimes these branching models are so complex that developers don't always
-  understand where to branch from, where to merge back and how to resolve the
-  conflicts that might occur along the way (after all, rebasing git branches on
-  top of each other is a key technique to master with git but in reality not
-  something that all developers are comfortable doing).
-
-In fact, these branching models and the inefficient workflows they force
-developer teams into are almost always only necessary due to a lack of powerful
-infrastructure. If that infrastructure is in place with proper automation and
-integration, teams are enabled to adopt a much simpler model and workflow:
+- When bugs come up in the `development` branch it's often unclear where they originate; all kinds of unrelated changes have been merged together in the branch so it's unclear whether a bug originates in the pull request that implemented the respective feature or whether it is only caused by the combination of those changes with others.
+- Once bugs or unmet requirements are identified, the developers responsible for the changes will have switched to a different task already since there's a delay between the merge of their PR to the `develop` branch and the testing/validation being performed on that branch. They now have to get back to something they considered done already, get all the context in their minds again while at the same time leaving whatever they are working on now behind, potentially causing problems for others that might be dependant on that work so that in the worst case whole cascades of focus and context switches are triggered.
+- Changes can only be released to production with a delay. Something might be done in one week but could potentially only be released the next week or even later when the next release is scheduled or the testing cycle completes.
+- Sometimes these branching models are so complex that developers don't always understand where to branch from, where to merge back and how to resolve the conflicts that might occur along the way (after all, rebasing git branches on top of each other is a key technique to master with git but in reality not something that all developers are comfortable doing).
+
+In fact, these branching models and the inefficient workflows they force developer teams into are almost always only necessary due to a lack of powerful infrastructure. If that infrastructure is in place with proper automation and integration, teams are enabled to adopt a much simpler model and workflow:
 
 ## Single `main` branch with auto-deployment
 
-A branching model with a single `main` branch and feature branches that are
-branched off of that and merged back right into it, is conceptually much simpler
-obviously. Furthermore, deploying all changes that are merged back into the
-`main` branch immediately and automatically, dramatically improves the workflow:
-
-- Changes can be tested in isolation so it's clear what causes bugs that are
-  found in the process (unless the bug exists in production already, it has to
-  be the changes in the respective branch since everything else is just like in
-  production).
-- Developers will not have progressed to a different task yet. Their pull
-  request is still open and a short feedback loop gives them all the feedback
-  they need when they need it, thus reducing the need for context switches later
-  on.
-- Changes can be released to production fast without the need to wait for a
-  release date to arrive or enough other changes to have accumulated to
-  _"justify"_ a release.
-- There's never any uncertainty about what base branch to branch off from, where
-  to merge something into, what branch to rebase on what base etc.
+A branching model with a single `main` branch and feature branches that are branched off of that and merged back right into it, is conceptually much simpler obviously. Furthermore, deploying all changes that are merged back into the `main` branch immediately and automatically, dramatically improves the workflow:
+
+- Changes can be tested in isolation so it's clear what causes bugs that are found in the process (unless the bug exists in production already, it has to be the changes in the respective branch since everything else is just like in production).
+- Developers will not have progressed to a different task yet. Their pull request is still open and a short feedback loop gives them all the feedback they need when they need it, thus reducing the need for context switches later on.
+- Changes can be released to production fast without the need to wait for a release date to arrive or enough other changes to have accumulated to _"justify"_ a release.
+- There's never any uncertainty about what base branch to branch off from, where to merge something into, what branch to rebase on what base etc.
 
 ![Single `main` branch workflow](/assets/images/posts/2021-07-13-effective-infrastructure-for-efficient-development-workflows/workflow.png#@800-1600)
 
-Of course, the challenge is to do all the testing (and QA in the wider sense)
-that happens based on some sort of schedule or process in multi-branch models,
-for every single pull request – and ideally for multiple pull requests in
-parallel to achieve high throughput. **This is where infrastructure and
-automation come in.**
+Of course, the challenge is to do all the testing (and QA in the wider sense) that happens based on some sort of schedule or process in multi-branch models, for every single pull request – and ideally for multiple pull requests in parallel to achieve high throughput. **This is where infrastructure and automation come in.**
 
 ### Testing (sub)systems in isolation
 
-The main building block of any effective developer infrastructure is of course a
-good Continuous Integration (CI) system. The most basic task of which being to
-run automated checks on a set of code changes to establish baseline correctness.
-
-Typically the foundation of those checks are some sort of unit tests (or
-whatever concept the language/framework of choice uses) to ensure the code in
-fact does what it is supposed to. They also help to catch regressions early on
-in cases where a change to one feature causes another, seemingly unrelated one
-to break. Good test coverage and a fast and stable CI system that runs tests are
-an absolute requirement for any development team to be successful. While that's
-something that's not really new or controversial in our industry, there's more
-than just unit tests that can be leveraged to ensure a set of changes is correct
-and doesn't lead to regressions
-
-- Visual regression testing can be used to ensure the code doesn't just **work**
-  correctly but the UI it generates also looks right (and doesn't change in
-  unexpected ways). Visual testing tools like [Percy](http://percy.io) will
-  report any visual deviation from a baseline caused by a set of code changes
-  and developers will manually approve (or revert) every single one of those.
-  That makes all UI changes intentional and avoids accidental changes. Once the
-  visual changes are approved and the respective code is merged back, they
-  become part of the visual baseline the next PR is compared against, etc.
-- Linting and static analysis, in general, can be a powerful tool to find more
-  errors and inconsistencies than just particular lines that go against an
-  agreed-upon coding style. You could lint translation files to ensure all
-  language files have the same set of keys to prevent missing translations or
-  prevent the use of `document.cookie` in case you don't want your web app to be
-  required to render a cookie banner – there are countless opportunities and I
-  personally believe there's still a lot to do in that area that could have huge
-  positive impacts on developer teams' efficiency.
-- For server systems with databases, migrations can be run against (anonymized)
-  snapshots of the production database(s) to ensure they in fact modify the data
-  as expected and won't run into unforeseen errors during deployment. It's also
-  advisable to test that the server system's currently deployed code runs
-  correctly with a migration applied and without it since that's usually what
-  will happen when a deployment is rolled back – while it's easy to roll back
-  code changes, rolling back migrations is often not an option or the migration
-  has to run and complete before the respective code changes can be deployed at
-  all.
-- For server systems it's also essential to test the deployment of the code
-  itself as well as rolling back that deployment. Like with testing migrations,
-  this should be done with an (anonymized) snapshot of the production database
-  and all tests should be run on the system after the rollback to ensure it
-  still operates correctly.
-
-This list isn't even nearly complete. Carefully analyzing any system and its
-history of issues usually reveals countless opportunities to automate checks
-that would have prevented those issues or can help prevent other issues in the
-future.
-
-All of these techniques test one (sub)system in isolation. However, many systems
-today aren't built as monoliths but as networks of multiple, distributed systems
-– e.g. single page apps (SPAs) with their respective server backends or
-microservice architectures. In order to be able to auto-deploy any of the
-individual subsystems of such architectures, it's critical to validate they
-operate correctly in combination with all other subsystems.
+The main building block of any effective developer infrastructure is of course a good Continuous Integration (CI) system. The most basic task of which being to run automated checks on a set of code changes to establish baseline correctness.
+
+Typically the foundation of those checks are some sort of unit tests (or whatever concept the language/framework of choice uses) to ensure the code in fact does what it is supposed to. They also help to catch regressions early on in cases where a change to one feature causes another, seemingly unrelated one to break. Good test coverage and a fast and stable CI system that runs tests are an absolute requirement for any development team to be successful. While that's something that's not really new or controversial in our industry, there's more than just unit tests that can be leveraged to ensure a set of changes is correct and doesn't lead to regressions
+
+- Visual regression testing can be used to ensure the code doesn't just **work** correctly but the UI it generates also looks right (and doesn't change in unexpected ways). Visual testing tools like [Percy](http://percy.io) will report any visual deviation from a baseline caused by a set of code changes and developers will manually approve (or revert) every single one of those. That makes all UI changes intentional and avoids accidental changes. Once the visual changes are approved and the respective code is merged back, they become part of the visual baseline the next PR is compared against, etc.
+- Linting and static analysis, in general, can be a powerful tool to find more errors and inconsistencies than just particular lines that go against an agreed-upon coding style. You could lint translation files to ensure all language files have the same set of keys to prevent missing translations or prevent the use of `document.cookie` in case you don't want your web app to be required to render a cookie banner – there are countless opportunities and I personally believe there's still a lot to do in that area that could have huge positive impacts on developer teams' efficiency.
+- For server systems with databases, migrations can be run against (anonymized) snapshots of the production database(s) to ensure they in fact modify the data as expected and won't run into unforeseen errors during deployment. It's also advisable to test that the server system's currently deployed code runs correctly with a migration applied and without it since that's usually what will happen when a deployment is rolled back – while it's easy to roll back code changes, rolling back migrations is often not an option or the migration has to run and complete before the respective code changes can be deployed at all.
+- For server systems it's also essential to test the deployment of the code itself as well as rolling back that deployment. Like with testing migrations, this should be done with an (anonymized) snapshot of the production database and all tests should be run on the system after the rollback to ensure it still operates correctly.
+
+This list isn't even nearly complete. Carefully analyzing any system and its history of issues usually reveals countless opportunities to automate checks that would have prevented those issues or can help prevent other issues in the future.
+
+All of these techniques test one (sub)system in isolation. However, many systems today aren't built as monoliths but as networks of multiple, distributed systems – e.g. single page apps (SPAs) with their respective server backends or microservice architectures. In order to be able to auto-deploy any of the individual subsystems of such architectures, it's critical to validate they operate correctly in combination with all other subsystems.
 
 ### Testing all subsystems together
 
-The key technique for testing a multitude of subsystems together of course is
-end-to-end testing (sometimes also referred to as _"integration"_ or
-_"acceptance"_ testing – the terminology is a bit unclear in practice, asking
-four different people would typically result in five different opinions on the
-exact meaning of each of these terms). For a proper end-to-end test, a pull
-request that changes the code of one subsystem is tested together with the
-respective deployed revisions of all other subsystems. That allows catching
-situations where changes to the one subsystem, while completely consistent and
-correct within that subsystem, cause problems when interfacing with other
-subsystems. Typical examples for such situations would be backward-incompatible
-API changes that would cause errors for any client of the API that hasn't been
-updated yet.
-
-Running such tests requires the ability to spin up a complete system including
-all of the subsystems on demand. Typically that is achieved by containerizing
-all of the systems so that a set of interconnected containers could be started
-up on the CI server. In the case of a web app that would mean serving the
-frontend app as well as running the API server in two containers and then
-running a headless browser to send requests to the frontend app (which would
-make requests against the backend) and asserting on the response.
-
-Besides the simple ability to run these containers any time, another aspect of
-this is to maintain an example data set to load into those containers so that
-that data can be used in the end-to-end tests. Such datasets are typically
-maintained in the form of seed scripts that generate a number of well-defined
-resources. If such a setup isn't considered early in the project, this is
-particularly hard to build later on when there is a plethora of different
-resource types and data stores already – maintaining and evolving that data set
-along with the code is much easier and efficient.
-
-End-to-end tests aren't the only valuable thing that is enabled by the ability
-to spin up instances of the system on demand though:
-
-- Providing fully functional
-  [preview systems](https://github.com/mainmatter/playbook/tree/master/src/development-process#preview-systems)
-  for every pull request allows getting stakeholder approval. If there's a
-  preview link in every pull request that points to what's essentially the same
-  system that the end-to-end tests run against, allows product managers,
-  designers, and other stakeholders to see a new feature in action before it is
-  deployed to production. That way they can give feedback while the developer is
-  still actively working on the task which again shortens the feedback loop.
-- That same system can also be used to do manual QA on a feature. Not everything
-  can be automatically tested all the time – sometimes it's just necessary for a
-  human to check for example whether an animation _"feels"_ good.
-- To some extent, such an on-demand system could also be used for testing the
-  performance characteristics of a change. While a containerized system that's
-  spun up for testing purposes only will never use the same resources or
-  experience the same load as the real production system, of course, it might be
-  sufficient to get an idea for the performance characteristics of a feature and
-  help to identify problems earlier rather than later.
-
-With all this infrastructure in place, it's possible to move all of the testing
-and validation that's done en-block after a whole bunch of pull requests have
-been merged in a multi-branch model to the point **before** every individual
-pull request is merged. Once it passes all these checks, it can be merged into
-the `main` branch and auto-deployed to production with confidence. In fact, this
-process can even lead to **increased confidence** in comparison to scheduled big
-releases since every single deployment is now also much smaller in scope which
-already reduces risk.
+The key technique for testing a multitude of subsystems together of course is end-to-end testing (sometimes also referred to as _"integration"_ or _"acceptance"_ testing – the terminology is a bit unclear in practice, asking four different people would typically result in five different opinions on the exact meaning of each of these terms). For a proper end-to-end test, a pull request that changes the code of one subsystem is tested together with the respective deployed revisions of all other subsystems. That allows catching situations where changes to the one subsystem, while completely consistent and correct within that subsystem, cause problems when interfacing with other subsystems. Typical examples for such situations would be backward-incompatible API changes that would cause errors for any client of the API that hasn't been updated yet.
+
+Running such tests requires the ability to spin up a complete system including all of the subsystems on demand. Typically that is achieved by containerizing all of the systems so that a set of interconnected containers could be started up on the CI server. In the case of a web app that would mean serving the frontend app as well as running the API server in two containers and then running a headless browser to send requests to the frontend app (which would make requests against the backend) and asserting on the response.
+
+Besides the simple ability to run these containers any time, another aspect of this is to maintain an example data set to load into those containers so that that data can be used in the end-to-end tests. Such datasets are typically maintained in the form of seed scripts that generate a number of well-defined resources. If such a setup isn't considered early in the project, this is particularly hard to build later on when there is a plethora of different resource types and data stores already – maintaining and evolving that data set along with the code is much easier and efficient.
+
+End-to-end tests aren't the only valuable thing that is enabled by the ability to spin up instances of the system on demand though:
+
+- Providing fully functional [preview systems](https://github.com/mainmatter/playbook/tree/master/src/development-process#preview-systems) for every pull request allows getting stakeholder approval. If there's a preview link in every pull request that points to what's essentially the same system that the end-to-end tests run against, allows product managers, designers, and other stakeholders to see a new feature in action before it is deployed to production. That way they can give feedback while the developer is still actively working on the task which again shortens the feedback loop.
+- That same system can also be used to do manual QA on a feature. Not everything can be automatically tested all the time – sometimes it's just necessary for a human to check for example whether an animation _"feels"_ good.
+- To some extent, such an on-demand system could also be used for testing the performance characteristics of a change. While a containerized system that's spun up for testing purposes only will never use the same resources or experience the same load as the real production system, of course, it might be sufficient to get an idea for the performance characteristics of a feature and help to identify problems earlier rather than later.
+
+With all this infrastructure in place, it's possible to move all of the testing and validation that's done en-block after a whole bunch of pull requests have been merged in a multi-branch model to the point **before** every individual pull request is merged. Once it passes all these checks, it can be merged into the `main` branch and auto-deployed to production with confidence. In fact, this process can even lead to **increased confidence** in comparison to scheduled big releases since every single deployment is now also much smaller in scope which already reduces risk.
 
 ### Post deployment
 
-With all that testing and automation in place, it is still possible for things
-to blow up in production of course. Besides having error tracking with tools
-like [Bugsnag](http://bugsnag.com) or others in place, the ideal infrastructure
-also includes a process for running automated smoke tests against the production
-system after every single deployment.
+With all that testing and automation in place, it is still possible for things to blow up in production of course. Besides having error tracking with tools like [Bugsnag](http://bugsnag.com) or others in place, the ideal infrastructure also includes a process for running automated smoke tests against the production system after every single deployment.
 
-These are quite similar in nature to the end-to-end tests with the main
-difference that they run against the production system. Typically those tests
-would focus on the main flows of an application that also have the highest
-relevance for the business:
+These are quite similar in nature to the end-to-end tests with the main difference that they run against the production system. Typically those tests would focus on the main flows of an application that also have the highest relevance for the business:
 
 - Can new users still sign up?
 - Does the payment flow still work?
 - Are the features that are critical to users still functional?
 
-One concern when running anything automated against the production system –
-potentially many times per day – is the amount of test data that is being
-produced in the process and that could potentially interfere with analytics or
-show up for real users. One way to address that (in the case of web
-applications) is to set a custom header that identifies the client as a test
-client so that the server can schedule the generated data to be deleted later on
-or otherwise be filtered from anything real users can see.
+One concern when running anything automated against the production system – potentially many times per day – is the amount of test data that is being produced in the process and that could potentially interfere with analytics or show up for real users. One way to address that (in the case of web applications) is to set a custom header that identifies the client as a test client so that the server can schedule the generated data to be deleted later on or otherwise be filtered from anything real users can see.
 
 ## Efficient development workflows based on effective infrastructure
 
-An efficient workflow based on effective infrastructure as described in this
-post undoubtedly raises teams to new levels of productivity. Admittedly, it
-takes time and effort to set it all up but the productivity gains easily
-outweigh the cost. In particular, when considered early on in a project, that
-cost isn't even as substantial as it might seem. The cost however of **not**
-having infrastructure like this once it's absolutely needed, which is when
-trying to scale a team up without scaling down its relative velocity at the same
-time, is certainly much higher.
+An efficient workflow based on effective infrastructure as described in this post undoubtedly raises teams to new levels of productivity. Admittedly, it takes time and effort to set it all up but the productivity gains easily outweigh the cost. In particular, when considered early on in a project, that cost isn't even as substantial as it might seem. The cost however of **not** having infrastructure like this once it's absolutely needed, which is when trying to scale a team up without scaling down its relative velocity at the same time, is certainly much higher.
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/3K9jQfpkGWU?rel=0" title="Three pillars of successful digital product development - Product Circle - December 2020" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
-_Mainmatter is a digital product development consultancy that helps teams ship
-better software faster, more predictably, and with higher quality. If you're
-interested in how we could help improve your infrastructure and workflow,
-[schedule a call with us](/contact/)._
+_Mainmatter is a digital product development consultancy that helps teams ship better software faster, more predictably, and with higher quality. If you're interested in how we could help improve your infrastructure and workflow, [schedule a call with us](/contact/)._
diff --git a/src/posts/2021-08-26-managing-modals-in-ember.md b/src/posts/2021-08-26-managing-modals-in-ember.md
index 2665ce4449..ea9f4875a5 100644
--- a/src/posts/2021-08-26-managing-modals-in-ember.md
+++ b/src/posts/2021-08-26-managing-modals-in-ember.md
@@ -3,26 +3,20 @@ title: "Managing modal dialogs in Ember.js with Promises"
 authorHandle: pichfl
 tags: ember
 bio: "Consultant for Technology and Design at Mainmatter"
-description:
-  "Exploring better and easier handling of modal dialogs in Ember.js
-  applications"
+description: "Exploring better and easier handling of modal dialogs in Ember.js applications"
 og:
   image: /assets/images/posts/2021-08-26-managing-modals-in-ember/og-image.jpg
 tagline: |
   <p>Modal dialogs are about as widespread as they are missunderstood. No matter if you call them modal windows, popups, popovers, overlays, or dialogs: A thing that asks a question or presents a subordinate task; a general annoyance to developers and accessibility experts alike.</p> <p>Even if you use them rarely, most applications will need modal dialogs at some point to ask existential questions. The app asks your user and waits to resolve its uncertainty by their answer.</p>
 ---
 
-Waiting, resolving. JavaScript promises provide an excellent pattern for
-managing modals. A rough concept could work like this:
+Waiting, resolving. JavaScript promises provide an excellent pattern for managing modals. A rough concept could work like this:
 
 1. Call a method which creates a promise
 2. Render a modal into the DOM, pass in a callback to resolve the promise
 3. Resolve the promise to unrender the modal and pass back a result
 
-[Tobias](https://github.com/Turbo87) made
-[Ember Promise Modals](https://mainmatter.github.io/ember-promise-modals/) so we
-don't have to implement this on our own. With this addon, can launch any
-component as a modal, wait for a result, and continue with our apps workflow.
+[Tobias](https://github.com/Turbo87) made [Ember Promise Modals](https://mainmatter.github.io/ember-promise-modals/) so we don't have to implement this on our own. With this addon, can launch any component as a modal, wait for a result, and continue with our apps workflow.
 
 ![Video showing a basic Ember Promise Modals dialog in action](/assets/images/posts/2021-08-26-managing-modals-in-ember/epm.mp4#video)
 
@@ -35,18 +29,9 @@ let result = await this.modals.open('name-of-your-component', {
 {% endraw %}
 ```
 
-This will trigger a modal dialog, which automatically gains focus for its first
-focussable element and keyboard accessibility including support for closing the
-dialog with <kbd>ESC</kbd> as required by
-[WAI ARIA best practices](https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal)
-thanks to the included [focus-trap](https://github.com/davidtheclark/focus-trap)
-integration. It will dim the underlying content for you with a customizable
-backdrop also.
+This will trigger a modal dialog, which automatically gains focus for its first focussable element and keyboard accessibility including support for closing the dialog with <kbd>ESC</kbd> as required by [WAI ARIA best practices](https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal) thanks to the included [focus-trap](https://github.com/davidtheclark/focus-trap) integration. It will dim the underlying content for you with a customizable backdrop also.
 
-The passed component recieve optional data as `@data` and a `@close` action,
-which will close the modal and resolve the promise. Anything passed to the
-action will become the value the promise resolves with, making it easy to
-communicate data in the preferred Data-Down-Actions-Up pattern of Ember.js.
+The passed component recieve optional data as `@data` and a `@close` action, which will close the modal and resolve the promise. Anything passed to the action will become the value the promise resolves with, making it easy to communicate data in the preferred Data-Down-Actions-Up pattern of Ember.js.
 
 ```hbs
 {% raw %}
@@ -62,11 +47,7 @@ communicate data in the preferred Data-Down-Actions-Up pattern of Ember.js.
 
 ### CSS based animations
 
-For the first stable release, [Nick](https://github.com/nickschot) and
-[myself](https://github.com/pichfl) added native CSS animations using
-`CSS @keyframes`, which allow for full control over how dialogs and the dimming
-backdrop appear and disappear on the screen without hogging render performance.
-A nice and swift default animation is provided out of the box.
+For the first stable release, [Nick](https://github.com/nickschot) and [myself](https://github.com/pichfl) added native CSS animations using `CSS @keyframes`, which allow for full control over how dialogs and the dimming backdrop appear and disappear on the screen without hogging render performance. A nice and swift default animation is provided out of the box.
 
 If you don't like the default, how about something a little more menacing?
 
@@ -87,10 +68,8 @@ If you don't like the default, how about something a little more menacing?
 }
 
 :root {
-  --epm-animation-modal-in: var(--epm-animation-modal-in-duration) ease-out var(
-      --epm-animation-modal-in-delay
-    )
-    forwards spiral-in;
+  --epm-animation-modal-in: var(--epm-animation-modal-in-duration) ease-out
+    var(--epm-animation-modal-in-delay) forwards spiral-in;
   --epm-animation-modal-in-duration: 0.7s;
 }
 ```
diff --git a/src/posts/2021-11-09-automating-ember-learning-releases-with-rust.md b/src/posts/2021-11-09-automating-ember-learning-releases-with-rust.md
index e3ed5adc46..ed5f852698 100644
--- a/src/posts/2021-11-09-automating-ember-learning-releases-with-rust.md
+++ b/src/posts/2021-11-09-automating-ember-learning-releases-with-rust.md
@@ -3,9 +3,7 @@ title: "Automating Ember releases with Rust"
 authorHandle: locks
 tags: "ember"
 bio: "Senior Frontend Engineer, Ember Framework and Learning Core teams member"
-description:
-  "Ricardo Mendes discusses a command-line tool built in Rust that automates the
-  releases process for the Ember Core Learning Team"
+description: "Ricardo Mendes discusses a command-line tool built in Rust that automates the releases process for the Ember Core Learning Team"
 og:
   image: /assets/images/posts/2021-11-09-automating-ember-learning-releases-with-rust/og-image.jpg
 tagline: |
@@ -14,50 +12,18 @@ tagline: |
 
 ## Release process for the Ember project
 
-An Ember project release involves 4 different Core teams: Framework, Data, CLI
-and Learning. The release is usually done over the period of a week, because
-some steps of the release depend on previous steps being completed. The steps
-are as follows:
-
-- The Framework team releases the new version of the Ember npm package,
-  [ember-source](https://www.npmjs.com/package/ember-source). This package
-  contains the Ember framework code that is bundled with the app, and provides
-  the `@ember` module imports that developers use when developing.
-- The Data team updates their dependency on `ember-source`, tests that
-  everything is working as expected and releases a new version of
-  [ember-data](https://www.npmjs.com/package/ember-data). This package contains
-  the code for the Ember Data library, which is Ember's default data management
-  solution. You can read more in the
-  [Ember Data guides](https://guides.emberjs.com/release/models/).
-- The CLI team updates the `ember-source` and `ember-data` dependencies in the
-  [application](https://github.com/ember-cli/ember-cli/tree/master/blueprints/app)
-  and
-  [addon](https://github.com/ember-cli/ember-cli/tree/master/blueprints/addon)
-  blueprints, tests that everything works as expected and releases a new version
-  of [ember-cli](https://www.npmjs.com/package/ember-cli). `ember-cli` is a
-  command-line application that makes it easy to create, build, test and serve
-  applications locally, as well as generating code such as components, routes
-  and controllers. You can read more in the
-  [Ember CLI guides](https://cli.emberjs.com/release/).
-- The Learning team releases the relevant versions of the
-  [Guides](https://guides.emberjs.com/) and the
-  [API documentation](https://api.emberjs.com/ember/release), updates the
-  [Releases page](https://emberjs.com/releases/), releases any relevant
-  [Deprecations](https://deprecations.emberjs.com/), and finally coordinates and
-  releases the [release blog post](https://blog.emberjs.com/tag/releases).
-
-The [release blog post](https://blog.emberjs.com/tag/releases) marks the
-official release of a new project version, since it means that all of the
-sub-projects and relevant documentation is ready and tested for developers to
-use and consult.
+An Ember project release involves 4 different Core teams: Framework, Data, CLI and Learning. The release is usually done over the period of a week, because some steps of the release depend on previous steps being completed. The steps are as follows:
+
+- The Framework team releases the new version of the Ember npm package, [ember-source](https://www.npmjs.com/package/ember-source). This package contains the Ember framework code that is bundled with the app, and provides the `@ember` module imports that developers use when developing.
+- The Data team updates their dependency on `ember-source`, tests that everything is working as expected and releases a new version of [ember-data](https://www.npmjs.com/package/ember-data). This package contains the code for the Ember Data library, which is Ember's default data management solution. You can read more in the [Ember Data guides](https://guides.emberjs.com/release/models/).
+- The CLI team updates the `ember-source` and `ember-data` dependencies in the [application](https://github.com/ember-cli/ember-cli/tree/master/blueprints/app) and [addon](https://github.com/ember-cli/ember-cli/tree/master/blueprints/addon) blueprints, tests that everything works as expected and releases a new version of [ember-cli](https://www.npmjs.com/package/ember-cli). `ember-cli` is a command-line application that makes it easy to create, build, test and serve applications locally, as well as generating code such as components, routes and controllers. You can read more in the [Ember CLI guides](https://cli.emberjs.com/release/).
+- The Learning team releases the relevant versions of the [Guides](https://guides.emberjs.com/) and the [API documentation](https://api.emberjs.com/ember/release), updates the [Releases page](https://emberjs.com/releases/), releases any relevant [Deprecations](https://deprecations.emberjs.com/), and finally coordinates and releases the [release blog post](https://blog.emberjs.com/tag/releases).
+
+The [release blog post](https://blog.emberjs.com/tag/releases) marks the official release of a new project version, since it means that all of the sub-projects and relevant documentation is ready and tested for developers to use and consult.
 
 ### The Learning team process
 
-As you might have noticed in the list above, the Learning team touches on
-several projects during the course of the release process. The team maintains a
-handbook with all the steps of the
-[Ember release process](https://github.com/ember-learn/handbook/blob/main/ember-releases.md).
-At the time of writing, they are:
+As you might have noticed in the list above, the Learning team touches on several projects during the course of the release process. The team maintains a handbook with all the steps of the [Ember release process](https://github.com/ember-learn/handbook/blob/main/ember-releases.md). At the time of writing, they are:
 
 1. Guides
 2. API documentation
@@ -69,54 +35,27 @@ At the time of writing, they are:
 8. Ember Wikipedia
 9. Release bot
 
-The steps are a mix of easily automated tasks and tasks that necessitate manual
-intervention.
+The steps are a mix of easily automated tasks and tasks that necessitate manual intervention.
 
-I started automating this process by creating bash scripts for the Guides
-project. The bash scripts turn the manual steps into a guided process with
-minimal interface and error handling around them. The scripts assume that you
-have the project cloned and does some housekeeping to make sure you don't
-accidentally lose any work you were doing when you trigger the release script.
-This will be relevant later on.
+I started automating this process by creating bash scripts for the Guides project. The bash scripts turn the manual steps into a guided process with minimal interface and error handling around them. The scripts assume that you have the project cloned and does some housekeeping to make sure you don't accidentally lose any work you were doing when you trigger the release script. This will be relevant later on.
 
-Codifying the steps in bash was a big improvement, but we ran into some minor
-issues. The first of which is that bash is not a language the developer in the
-team are deeply familiar with. This is fine for small scripts, but as soon as
-you try to introduce error handling and better ergonomics for the caller of the
-script, it becomes considerably harder to write the necessary bash code.
+Codifying the steps in bash was a big improvement, but we ran into some minor issues. The first of which is that bash is not a language the developer in the team are deeply familiar with. This is fine for small scripts, but as soon as you try to introduce error handling and better ergonomics for the caller of the script, it becomes considerably harder to write the necessary bash code.
 
-The other reason is that bash is not natively supported on Windows. There are
-ways to run bash on Windows systems, but we wanted to reduce incidental
-dependencies in order to make releases portable and easier for the user.
+The other reason is that bash is not natively supported on Windows. There are ways to run bash on Windows systems, but we wanted to reduce incidental dependencies in order to make releases portable and easier for the user.
 
-So to run all of the steps you would need to clone the relevant repositories and
-follow the release handbook line by line to make sure you get the order correct.
+So to run all of the steps you would need to clone the relevant repositories and follow the release handbook line by line to make sure you get the order correct.
 
 ## Creating tool-new-release
 
-There was still a lot of automation left on the table, so I got to work figuring
-out how to improve the situation. When picking what technology I would use for
-the tool I had two main concerns: portability, and ease of packaging as a
-binary.
+There was still a lot of automation left on the table, so I got to work figuring out how to improve the situation. When picking what technology I would use for the tool I had two main concerns: portability, and ease of packaging as a binary.
 
-At the time I was dabbling in Rust and had already made a couple of tools for
-myself using that language, so I decided to give Rust a go. Picking Rust also
-had the benefit of giving me a single binary that a maintainer can download and
-run, not having to deal with runtime and dependencies versions. And so, work
-started on [tool-new-release](https://github.com/ember-learn/tool-new-release/).
+At the time I was dabbling in Rust and had already made a couple of tools for myself using that language, so I decided to give Rust a go. Picking Rust also had the benefit of giving me a single binary that a maintainer can download and run, not having to deal with runtime and dependencies versions. And so, work started on [tool-new-release](https://github.com/ember-learn/tool-new-release/).
 
 ### First steps
 
 #### Handling Git
 
-The first things I needed were a library to handle `git` operations, and a
-library to generate temporary folders that I could clone the repositories into.
-The decision to clone the relevant repositories into temporary folders was
-twofold: ensure the tool is working with the most recent commits of the
-repository, and clean up the repositories after the tool was done running. I
-decided to go with [`git2-rs`](https://docs.rs/git2/0.13.22/git2/) and
-[`tempfile`](https://docs.rs/tempfile/3.2.0/tempfile/), which looks something
-like this:
+The first things I needed were a library to handle `git` operations, and a library to generate temporary folders that I could clone the repositories into. The decision to clone the relevant repositories into temporary folders was twofold: ensure the tool is working with the most recent commits of the repository, and clean up the repositories after the tool was done running. I decided to go with [`git2-rs`](https://docs.rs/git2/0.13.22/git2/) and [`tempfile`](https://docs.rs/tempfile/3.2.0/tempfile/), which looks something like this:
 
 ```rust
 use tempfile::tempdir;
@@ -127,18 +66,11 @@ folder.push("guides-source");
 let repo = Repository::clone("https://github.com/ember-learn/guides-source.git", &folder)?;
 ```
 
-In the actual tool a temporary folder is created at the top that is then fed to
-the different steps so they can manage the cloning they need to do.
+In the actual tool a temporary folder is created at the top that is then fed to the different steps so they can manage the cloning they need to do.
 
 #### Shelling out
 
-Determined to have a viable release tool as quickly as possible and afterwards
-iterate for improvements, I decided to call the `Bash` scripts already present
-in the
-[`guides-source` repository](https://github.com/ember-learn/guides-source/tree/5ec89c42179aa41cbb00a25ef9244e14977a0e72/scripts)
-using
-[`std::process::Command`](https://doc.rust-lang.org/std/process/struct.Command.html)
-from Rust's standard library:
+Determined to have a viable release tool as quickly as possible and afterwards iterate for improvements, I decided to call the `Bash` scripts already present in the [`guides-source` repository](https://github.com/ember-learn/guides-source/tree/5ec89c42179aa41cbb00a25ef9244e14977a0e72/scripts) using [`std::process::Command`](https://doc.rust-lang.org/std/process/struct.Command.html) from Rust's standard library:
 
 ```rust
 use std::process::Command;
@@ -153,17 +85,11 @@ Command::new("npm")
     .expect("Failed to release guides.");
 ```
 
-While shelling out did not improve on the portability problem, making the tool
-do something useful was a motivator to keep developing it.
+While shelling out did not improve on the portability problem, making the tool do something useful was a motivator to keep developing it.
 
 #### Providing command-line arguments
 
-Next I added [`structopt`](https://docs.rs/structopt/0.3.23/structopt/) to
-provide command-line argument parsing. This would be useful to allow the user to
-select which project they want to run the release steps for, to provide the
-target version, and more. `structopt` makes it really straightforward to
-implement interfaces using native Rust structures. Here's an example of a
-`--project` flag that accepts either `Guides` or `Api` as values:
+Next I added [`structopt`](https://docs.rs/structopt/0.3.23/structopt/) to provide command-line argument parsing. This would be useful to allow the user to select which project they want to run the release steps for, to provide the target version, and more. `structopt` makes it really straightforward to implement interfaces using native Rust structures. Here's an example of a `--project` flag that accepts either `Guides` or `Api` as values:
 
 ```rust
 #[derive(Debug, StructOpt)]
@@ -181,8 +107,7 @@ struct Opts {
 }
 ```
 
-I want to note that this also gives us documentation via the `--help` flag out
-of the box:
+I want to note that this also gives us documentation via the `--help` flag out of the box:
 
 ```bash
 $ tool-new-release --help
@@ -199,30 +124,16 @@ OPTIONS:
     -p, --project <project>    Pick which project to run the deploy pipeline for [possible values: Guides, Api]
 ```
 
-Now that I had the basics of the tool working for Guides and API documentation,
-it was time to make it available for other people.
+Now that I had the basics of the tool working for Guides and API documentation, it was time to make it available for other people.
 
 ### Releasing the tool
 
-I wanted the tool to be useable from Linux, Windows and macOS so I had to figure
-out a way to build the Rust project to those targets. Since the project is
-hosted on GitHub, I could use GitHub Actions to build the project for me, and
-then make a release.
+I wanted the tool to be useable from Linux, Windows and macOS so I had to figure out a way to build the Rust project to those targets. Since the project is hosted on GitHub, I could use GitHub Actions to build the project for me, and then make a release.
 
-After some research I was able to put together a GitHub Action workflow. You can
-see it currently look like in the repository's
-[`workflows` directory](https://github.com/ember-learn/tool-new-release/tree/main/.github/workflows)
-and if you have any suggestions, please
-[let me know](https://twitter.com/locks)! The project is still a work in
-progress so you might find things that are not done optimally.
+After some research I was able to put together a GitHub Action workflow. You can see it currently look like in the repository's [`workflows` directory](https://github.com/ember-learn/tool-new-release/tree/main/.github/workflows) and if you have any suggestions, please [let me know](https://twitter.com/locks)! The project is still a work in progress so you might find things that are not done optimally.
 
-There's two things I'd like to point out in the workflow. One is that I ended up
-using [`musl`](https://musl.libc.org/) through `rustup` in order to build the
-Linux binary. The other is that I'm currently publishing the binary as a
-_draft_, so it will not show up on the homepage of the repository.
+There's two things I'd like to point out in the workflow. One is that I ended up using [`musl`](https://musl.libc.org/) through `rustup` in order to build the Linux binary. The other is that I'm currently publishing the binary as a _draft_, so it will not show up on the homepage of the repository.
 
 ## Next steps
 
-Now that the Core Learning team had a working tool, it was time to codify the
-rest of the steps and apply some improvements to make the tool easier to use and
-to maintain. I will cover that and more in future posts, so keep an eye out!
+Now that the Core Learning team had a working tool, it was time to codify the rest of the steps and apply some improvements to make the tool easier to use and to maintain. I will cover that and more in future posts, so keep an eye out!
diff --git a/src/posts/2021-11-26-publish-on-npm.md b/src/posts/2021-11-26-publish-on-npm.md
index 0b856b5a3f..4b0879fb37 100644
--- a/src/posts/2021-11-26-publish-on-npm.md
+++ b/src/posts/2021-11-26-publish-on-npm.md
@@ -3,9 +3,7 @@ title: "3 ways you can improve your npm publish"
 authorHandle: tobiasbieniek
 tags: javascript
 bio: "Senior Software Engineer"
-description:
-  "Tobias Bieniek explains mechanisms for automating npm releases for reduced
-  effort and improved reliability with lerna-changelog and release-it."
+description: "Tobias Bieniek explains mechanisms for automating npm releases for reduced effort and improved reliability with lerna-changelog and release-it."
 og:
   image: /assets/images/posts/2021-11-26-publish-on-npm/og-image.jpg
 tagline: |
@@ -16,25 +14,13 @@ imageAlt: "Woman reading code documentation at her laptop"
 
 ## Let CI do the work
 
-While you can run `npm publish` locally, it can cause issues. I'm personally
-using [JetBrains IntelliJ](https://www.jetbrains.com/idea/) to develop software
-and it puts an `.idea` folder in each project. I've stopped counting how many
-times I've accidentally published this folder to npm in the past…
+While you can run `npm publish` locally, it can cause issues. I'm personally using [JetBrains IntelliJ](https://www.jetbrains.com/idea/) to develop software and it puts an `.idea` folder in each project. I've stopped counting how many times I've accidentally published this folder to npm in the past…
 
-I've managed to not commit this folder to any of our git repositories because
-I've set up a
-[global `.gitignore` file](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer),
-but unfortunately no such thing exists for `.npmignore` files. 😢
+I've managed to not commit this folder to any of our git repositories because I've set up a [global `.gitignore` file](https://docs.github.com/en/get-started/getting-started-with-git/ignoring-files#configuring-ignored-files-for-all-repositories-on-your-computer), but unfortunately no such thing exists for `.npmignore` files. 😢
 
-There are obviously other ways to avoid this issue, but we've found that one of
-the easiest ways is to just not publish from your local machine, and instead
-have your CI workflow publish the package whenever you push a tag to the
-repository. As an added benefit: you'll never forget to push the tag to the
-repository because it's now required to actually publish the package! 🥳
+There are obviously other ways to avoid this issue, but we've found that one of the easiest ways is to just not publish from your local machine, and instead have your CI workflow publish the package whenever you push a tag to the repository. As an added benefit: you'll never forget to push the tag to the repository because it's now required to actually publish the package! 🥳
 
-How to set this up largely depends on what CI system you are using. For our
-open-source projects we use GitHub Actions these days, and a typical `release`
-workflow file looks like this:
+How to set this up largely depends on what CI system you are using. For our open-source projects we use GitHub Actions these days, and a typical `release` workflow file looks like this:
 
 ```yaml
 name: Release
@@ -63,26 +49,15 @@ jobs:
 
 Let's go through this file step by step…
 
-The `name` field describes what this workflow will be called in the GitHub
-Actions user interface.
+The `name` field describes what this workflow will be called in the GitHub Actions user interface.
 
-The `on` object specifies when this workflow should run. In this case we are
-configuring it to run whenever a tag is pushed to the repository, and the `*`
-wildcard means that we don't care about what the exact tag name is.
+The `on` object specifies when this workflow should run. In this case we are configuring it to run whenever a tag is pushed to the repository, and the `*` wildcard means that we don't care about what the exact tag name is.
 
-`jobs` is a bit misleading, because in this workflow we only have a single job:
-`release`. In this job we will first copy the code onto the CI machine
-(`checkout`), and then setup Node.js. It is important here to explicitly specify
-the `registry-url` because otherwise the following `npm publish` command won't
-work. Here, we just use the official npm registry, but it is equally possible to
-publish packages to a company-internal private registry, if needed.
+`jobs` is a bit misleading, because in this workflow we only have a single job: `release`. In this job we will first copy the code onto the CI machine (`checkout`), and then setup Node.js. It is important here to explicitly specify the `registry-url` because otherwise the following `npm publish` command won't work. Here, we just use the official npm registry, but it is equally possible to publish packages to a company-internal private registry, if needed.
 
-Lastly, we call `npm publish`. For this to succeed we need to be logged in…
-which we are not 🙈
+Lastly, we call `npm publish`. For this to succeed we need to be logged in… which we are not 🙈
 
-An alternative to using `npm login` on CI is providing an "access token" through
-e.g. the `NODE_AUTH_TOKEN` environment variable. But where do you get such a
-token? The answer is: on the npm website:
+An alternative to using `npm login` on CI is providing an "access token" through e.g. the `NODE_AUTH_TOKEN` environment variable. But where do you get such a token? The answer is: on the npm website:
 
 - Go to <https://www.npmjs.com>
 - Log in, if you haven't already
@@ -92,54 +67,29 @@ token? The answer is: on the npm website:
 - Select the "Automation" token type
 - Click the "Generate Token" button
 
-Now you can copy the newly generated token and save it as a `NPM_TOKEN` secret
-in the settings of your GitHub repository.
+Now you can copy the newly generated token and save it as a `NPM_TOKEN` secret in the settings of your GitHub repository.
 
-While this generally works great for us, there are currently at least two
-downsides of this approach that you should be aware of:
+While this generally works great for us, there are currently at least two downsides of this approach that you should be aware of:
 
-- There is no difference anymore between commit/push access and publish access.
-  This means that anyone that can push to your repository can now also publish
-  new releases on npm. This is usually not a big problem, but you should be
-  aware that it removes one of the security layers from the publishing process
-  in favor of the CI publishing convenience.
+- There is no difference anymore between commit/push access and publish access. This means that anyone that can push to your repository can now also publish new releases on npm. This is usually not a big problem, but you should be aware that it removes one of the security layers from the publishing process in favor of the CI publishing convenience.
 
-- The generated npm token currently provides publish access to **all** npm
-  packages that the account has access to. Fixing this is on the roadmap of the
-  npm team, and at some point you will be able to generate tokens that can only
-  access a subset of your projects.
+- The generated npm token currently provides publish access to **all** npm packages that the account has access to. Fixing this is on the roadmap of the npm team, and at some point you will be able to generate tokens that can only access a subset of your projects.
 
-For us, the convenience of only having to push a tag currently outweighs the
-disadvantages mentioned above, but it is still valuable to know what the
-tradeoffs are.
+For us, the convenience of only having to push a tag currently outweighs the disadvantages mentioned above, but it is still valuable to know what the tradeoffs are.
 
 ## Keep a change log
 
-When you see that one of your dependencies has an update available, how do you
-figure out what changed between your current version and the update?
+When you see that one of your dependencies has an update available, how do you figure out what changed between your current version and the update?
 
-You can look at the diff of the two versions, but that usually requires somewhat
-deep knowledge of how the dependency works internally. In an ideal world every
-project would have a `CHANGELOG.md` file, that describes what has changed
-between the individual versions. Unfortunately, not all projects keep such a
-file because maintaining such a file is often perceived as a significant
-workload.
+You can look at the diff of the two versions, but that usually requires somewhat deep knowledge of how the dependency works internally. In an ideal world every project would have a `CHANGELOG.md` file, that describes what has changed between the individual versions. Unfortunately, not all projects keep such a file because maintaining such a file is often perceived as a significant workload.
 
-To reduce the work that is needed to maintain a changelog file we can use
-changelog generators. These tools usually look at the git commits between the
-current version and the last release and output an overview of what the relevant
-changes were.
+To reduce the work that is needed to maintain a changelog file we can use changelog generators. These tools usually look at the git commits between the current version and the last release and output an overview of what the relevant changes were.
 
 The changelog generator that we like to use at Mainmatter is: [lerna-changelog].
 
 [lerna-changelog]: https://github.com/lerna/lerna-changelog
 
-We don't want to go into too much detail here, but this is essentially how it
-works: lerna-changelog looks at the commits and searches for commit messages
-that look like pull-request merge commits. It then requests more information
-about the corresponding pull-requests from the GitHub API, including the labels
-of that pull-request. Next, it groups the PRs by their labels and outputs them
-based on that grouping.
+We don't want to go into too much detail here, but this is essentially how it works: lerna-changelog looks at the commits and searches for commit messages that look like pull-request merge commits. It then requests more information about the corresponding pull-requests from the GitHub API, including the labels of that pull-request. Next, it groups the PRs by their labels and outputs them based on that grouping.
 
 Here is an example of the lerna-changelog changelog itself:
 
@@ -148,18 +98,13 @@ Here is an example of the lerna-changelog changelog itself:
 
 #### :bug: Bug Fix
 
-- [#296](https://github.com/lerna/lerna-changelog/pull/296) Omit commiters line
-  when all are filtered out ([@petrch87](https://github.com/petrch87))
-- [#398](https://github.com/lerna/lerna-changelog/pull/398) Fix handling of
-  --next-version-from-metadata option
-  ([@contolini](https://github.com/contolini))
+- [#296](https://github.com/lerna/lerna-changelog/pull/296) Omit commiters line when all are filtered out ([@petrch87](https://github.com/petrch87))
+- [#398](https://github.com/lerna/lerna-changelog/pull/398) Fix handling of --next-version-from-metadata option ([@contolini](https://github.com/contolini))
 
 #### :house: Internal
 
-- [#494](https://github.com/lerna/lerna-changelog/pull/494) Update yargs to
-  v17.x ([@Turbo87](https://github.com/Turbo87))
-- [#493](https://github.com/lerna/lerna-changelog/pull/493) CI: Run
-  `pnpm install` before `npm publish` ([@Turbo87](https://github.com/Turbo87))
+- [#494](https://github.com/lerna/lerna-changelog/pull/494) Update yargs to v17.x ([@Turbo87](https://github.com/Turbo87))
+- [#493](https://github.com/lerna/lerna-changelog/pull/493) CI: Run `pnpm install` before `npm publish` ([@Turbo87](https://github.com/Turbo87))
 
 #### Committers: 3
 
@@ -168,8 +113,7 @@ Here is an example of the lerna-changelog changelog itself:
 - Tobias Bieniek ([@Turbo87](https://github.com/Turbo87))
 ```
 
-One thing to be aware of is that lerna-changelog will only include PRs in the
-changelog that have one of these supported labels:
+One thing to be aware of is that lerna-changelog will only include PRs in the changelog that have one of these supported labels:
 
 - `breaking` (💥 Breaking Change)
 - `enhancement` (🚀 Enhancement)
@@ -177,31 +121,21 @@ changelog that have one of these supported labels:
 - `documentation` (📝 Documentation)
 - `internal` (🏠 Internal)
 
-These labels are configurable, but using a label that is not configured might
-cause the PR to not show up in the listing. This behavior is an ongoing
-discussion and might change in the future, but this is currently how it works.
+These labels are configurable, but using a label that is not configured might cause the PR to not show up in the listing. This behavior is an ongoing discussion and might change in the future, but this is currently how it works.
 
-The way to use lerna-changelog is: when you bump the `version` in your
-`package.json` file, commit that change, and tag the commit, but you should also
-update the `CHANGELOG.md` with the latest changes for that particular version:
+The way to use lerna-changelog is: when you bump the `version` in your `package.json` file, commit that change, and tag the commit, but you should also update the `CHANGELOG.md` with the latest changes for that particular version:
 
 ```bash
 npx lerna-changelog
 ```
 
-lerna-changelog usually figures out automatically what the last published
-version was, but if that does not work you can help by providing the `--from`
-CLI option. Similarly, if it can't figure out the GitHub URL of the project, you
-can help by setting it manually via `--repo`.
+lerna-changelog usually figures out automatically what the last published version was, but if that does not work you can help by providing the `--from` CLI option. Similarly, if it can't figure out the GitHub URL of the project, you can help by setting it manually via `--repo`.
 
 ## Automate everything
 
-Now that we've made our publishing process more complicated again by needing to
-update the changelog, let's simplify it by automating everything. 🤖
+Now that we've made our publishing process more complicated again by needing to update the changelog, let's simplify it by automating everything. 🤖
 
-There is a CLI tool on npm called
-[`release-it`](https://github.com/release-it/release-it), which describes itself
-as:
+There is a CLI tool on npm called [`release-it`](https://github.com/release-it/release-it), which describes itself as:
 
 > Generic CLI tool to automate versioning and package publishing related tasks
 
@@ -233,51 +167,26 @@ module.exports = {
 {% endraw %}
 ```
 
-In the `plugins` section we specify that we want to use the
-[`release-it-lerna-changelog`](https://github.com/rwjblue/release-it-lerna-changelog)
-plugin to integrate lerna-changelog in our release process.
+In the `plugins` section we specify that we want to use the [`release-it-lerna-changelog`](https://github.com/rwjblue/release-it-lerna-changelog) plugin to integrate lerna-changelog in our release process.
 
-The `git` section configures what the commit message and tag names are supposed
-to look like, and in the `github` section we specify that we would also like to
-automatically create a "Release" on GitHub with the corresponding changelog
-attached.
+The `git` section configures what the commit message and tag names are supposed to look like, and in the `github` section we specify that we would also like to automatically create a "Release" on GitHub with the corresponding changelog attached.
 
-Finally, we want to take advantage of our automatic CI publishing process, so we
-tell `release-it` to not run `npm publish` for us.
+Finally, we want to take advantage of our automatic CI publishing process, so we tell `release-it` to not run `npm publish` for us.
 
-After adding `release-it` and `release-it-lerna-changelog` as dev dependencies,
-and putting the configuration above in a `.release-it.js` file we can run the
-tool to see how it works:
+After adding `release-it` and `release-it-lerna-changelog` as dev dependencies, and putting the configuration above in a `.release-it.js` file we can run the tool to see how it works:
 
 ```bash
 npx release-it
 ```
 
-The first thing that `release-it` does is assembling the changelog, so that you
-can better judge whether this should be a major, minor or patch release.
-Conveniently, it asks you this exact question right after showing you the
-changelog preview.
-
-Once you have chosen the version number, it will update the `version` field in
-the `package.json` file and update the `CHANGELOG.md`. Afterwards it will ask
-you to confirm that the files should be committed like this, and if you confirm,
-it will ask you whether the new commit should now be tagged. The cool part is
-that you can abort at any time and `release-it` will automatically clean up and
-revert you to the same state as before.
-
-The final two confirmations are for pushing the commit and tag to GitHub and
-then creating the Release on GitHub. Once all of this is confirmed you can sit
-back and watch the CI machines take over.
-
-To summarize, releasing a new version is now only a matter of running
-`release-it`, choosing a version number and then confirming a few actions, which
-usually shouldn't take more than a few seconds. As a bonus, this updated release
-process will automatically maintain the `CHANGELOG.md` file for you!
-
-The instructions in this blog post were primarily aimed at JavaScript projects
-that are hosted on GitHub, but we've also set up similar processes, tools and
-automations for projects on private GitLab instances, Rust projects, and also
-with different changelog generators. If you need any help setting this up, don't
-hesitate to [contact] us.
+The first thing that `release-it` does is assembling the changelog, so that you can better judge whether this should be a major, minor or patch release. Conveniently, it asks you this exact question right after showing you the changelog preview.
+
+Once you have chosen the version number, it will update the `version` field in the `package.json` file and update the `CHANGELOG.md`. Afterwards it will ask you to confirm that the files should be committed like this, and if you confirm, it will ask you whether the new commit should now be tagged. The cool part is that you can abort at any time and `release-it` will automatically clean up and revert you to the same state as before.
+
+The final two confirmations are for pushing the commit and tag to GitHub and then creating the Release on GitHub. Once all of this is confirmed you can sit back and watch the CI machines take over.
+
+To summarize, releasing a new version is now only a matter of running `release-it`, choosing a version number and then confirming a few actions, which usually shouldn't take more than a few seconds. As a bonus, this updated release process will automatically maintain the `CHANGELOG.md` file for you!
+
+The instructions in this blog post were primarily aimed at JavaScript projects that are hosted on GitHub, but we've also set up similar processes, tools and automations for projects on private GitLab instances, Rust projects, and also with different changelog generators. If you need any help setting this up, don't hesitate to [contact] us.
 
 [contact]: https://mainmatter.com/contact/
diff --git a/src/posts/2021-12-08-validations-in-ember-apps.md b/src/posts/2021-12-08-validations-in-ember-apps.md
index 7b3ce956f7..b4263ebf1d 100644
--- a/src/posts/2021-12-08-validations-in-ember-apps.md
+++ b/src/posts/2021-12-08-validations-in-ember-apps.md
@@ -3,9 +3,7 @@ title: "Data validation in Ember with Yup"
 authorHandle: BobrImperator
 tags: ember
 bio: "Software Developer"
-description:
-  "Bartlomiej Dudzik shows how you can easily create validations wrapper based
-  on a library of your liking."
+description: "Bartlomiej Dudzik shows how you can easily create validations wrapper based on a library of your liking."
 og:
   image: /assets/images/posts/2021-12-08-validations-in-ember-apps/og-image.jpg
 tagline: |
@@ -15,11 +13,7 @@ imageAlt: Data validation in Ember with Yup illustration
 
 ### Quick look at Yup
 
-Yup provides factory methods for different data types that you can use to
-construct schemas and their constraints for your data. The following code
-imports the `string` schema, and calls the `required` and `email` methods to
-describe what type of data is allowed. The returned schema `emailRequired`
-validates values to be "a valid non-empty string that matches an email pattern".
+Yup provides factory methods for different data types that you can use to construct schemas and their constraints for your data. The following code imports the `string` schema, and calls the `required` and `email` methods to describe what type of data is allowed. The returned schema `emailRequired` validates values to be "a valid non-empty string that matches an email pattern".
 
 ```javascript
 import { string } from "yup";
@@ -33,8 +27,7 @@ emailRequired.isValid("wrong.email.com").then(function (valid) {
 
 #### Describing objects with Yup
 
-Let's see how we can create a schema that describes some complex data. Here's
-some example found in the Yup docs:
+Let's see how we can create a schema that describes some complex data. Here's some example found in the Yup docs:
 
 ```javascript
 import { object, string, number, date } from "yup";
@@ -50,8 +43,7 @@ const schema = object().shape({
 });
 ```
 
-`object().shape()` takes an object as an argument whose key values are other Yup
-schemas, then it returns a schema that we can cast or validate against i.e
+`object().shape()` takes an object as an argument whose key values are other Yup schemas, then it returns a schema that we can cast or validate against i.e
 
 ```javascript
 schema
@@ -121,32 +113,18 @@ export default class YupValidations {
 
 That's it :) Let's go through it real quick.
 
-There are 4 properties defined `context`, `schema`, `shape` and `error` which is
-`@tracked`.
+There are 4 properties defined `context`, `schema`, `shape` and `error` which is `@tracked`.
 
-- `context` is either the data or the whole instance of the object we're
-  validating.
+- `context` is either the data or the whole instance of the object we're validating.
 - `shape` the expected shape of the data; this is used to create `schema`
 - `schema` is a Yup schema created from `shape`
-- `error` is a `ValidationError` thrown by `schema.validate()` when the data
-  doesn't match the `schema`.
-
-The constructor takes 2 arguments `context` and `shape`, we set those on the
-instance as well as create `schema` off of `shape`.
-
-- `fieldErrors` is a computed property that returns an object which keys are
-  paths to the schemas that failed validations. The object is created by
-  reducing a list of errors read from `ValidationError`.
-
-- `validate` is an asynchronous method that calls `validate` on our `schema`,
-  awaits the result, resets errors if validations pass, otherwise catches an
-  error and sets it on the class instance. It's important that the
-  `abortEarly: false` option is passed to `schema.validate()` as otherwise if
-  any field would throw an error, it would stop validating the rest of the data,
-  which is not desired. Furthermore `validate` receives data returned from
-  `#validationProperties`, the reason for that being Ember Proxies. In order to
-  correctly support proxies, e.g Ember-Data models, we need to grab data from
-  `context` with the help of `getProperties`.
+- `error` is a `ValidationError` thrown by `schema.validate()` when the data doesn't match the `schema`.
+
+The constructor takes 2 arguments `context` and `shape`, we set those on the instance as well as create `schema` off of `shape`.
+
+- `fieldErrors` is a computed property that returns an object which keys are paths to the schemas that failed validations. The object is created by reducing a list of errors read from `ValidationError`.
+
+- `validate` is an asynchronous method that calls `validate` on our `schema`, awaits the result, resets errors if validations pass, otherwise catches an error and sets it on the class instance. It's important that the `abortEarly: false` option is passed to `schema.validate()` as otherwise if any field would throw an error, it would stop validating the rest of the data, which is not desired. Furthermore `validate` receives data returned from `#validationProperties`, the reason for that being Ember Proxies. In order to correctly support proxies, e.g Ember-Data models, we need to grab data from `context` with the help of `getProperties`.
 
 #### Usage
 
@@ -167,12 +145,9 @@ export default class UserModel extends Model {
 }
 ```
 
-We instantiate YupValidations and pass it some arguments, a User model instance,
-and Yup **shape**.
+We instantiate YupValidations and pass it some arguments, a User model instance, and Yup **shape**.
 
-Later, inside a form component I'd like to be able to just call
-`YupValidations#validate` method which returns a Promise that resolves to a
-Boolean.
+Later, inside a form component I'd like to be able to just call `YupValidations#validate` method which returns a Promise that resolves to a Boolean.
 
 ```javascript
 import Component from "@glimmer/component";
@@ -195,10 +170,7 @@ export default class UserFormComponent extends Component {
 }
 ```
 
-Further on, there's an `ErrorMessage` component that receives a **list** of
-error messages and handles them in some way. Normally we'd show
-internationalized messages with the help of `ember-intl`, but in our case we'll
-just show their keys directly like so:
+Further on, there's an `ErrorMessage` component that receives a **list** of error messages and handles them in some way. Normally we'd show internationalized messages with the help of `ember-intl`, but in our case we'll just show their keys directly like so:
 
 ```hbs
 {% raw %}
@@ -222,13 +194,9 @@ Finally the component invocation:
 
 #### Internationalization
 
-Yup by default returns messages in plain text based on some built-in templates
-and some way of concatenation. That's not an option for us though because in
-Ember apps we normally use `ember-intl` for translating text. Luckily Yup allows
-to use functions that will produce messages.
+Yup by default returns messages in plain text based on some built-in templates and some way of concatenation. That's not an option for us though because in Ember apps we normally use `ember-intl` for translating text. Luckily Yup allows to use functions that will produce messages.
 
-The full list of messages can be found in
-[Yup's source code](https://github.com/jquense/yup/blob/master/src/locale.ts)
+The full list of messages can be found in [Yup's source code](https://github.com/jquense/yup/blob/master/src/locale.ts)
 
 ```javascript
 import { setLocale } from ‘yup’;
@@ -256,12 +224,7 @@ setLocale({
 })
 ```
 
-`locale` is a higher order function that returns a function that is later used
-by Yup to produce our messages. The first argument it takes is a translation key
-of our liking that would then be consumed by `ember-intl` e.g `field.invalid`.
-The second argument is a list of fields it should get from `validationParams`
-that we receive from Yup, the parameters could have values like `min` and `max`
-that would be passed to `ember-intl` `t` helper.
+`locale` is a higher order function that returns a function that is later used by Yup to produce our messages. The first argument it takes is a translation key of our liking that would then be consumed by `ember-intl` e.g `field.invalid`. The second argument is a list of fields it should get from `validationParams` that we receive from Yup, the parameters could have values like `min` and `max` that would be passed to `ember-intl` `t` helper.
 
 At the end of the day the produced messages will look like this:
 
@@ -281,15 +244,13 @@ At the end of the day the produced messages will look like this:
 }
 ```
 
-Let's see what messages are returned after the `User` model is validated when
-the form is submitted:
+Let's see what messages are returned after the `User` model is validated when the form is submitted:
 
 ![Internationalized user fields demo](/assets/images/posts/2021-12-08-validations-in-ember-apps/form-user-1.gif)
 
 ### Validating related schemas
 
-As you could see before, pets aren't being validated yet. There are 2 things
-that need to be done first:
+As you could see before, pets aren't being validated yet. There are 2 things that need to be done first:
 
 - Create validations for the `Pet` model.
 - Validate pets when the user is validated.
@@ -312,18 +273,12 @@ export default class PetModel extends Model {
 }
 ```
 
-Now let's take a look at the code for connecting the validations for `User` and
-`Pet`. This will validate pets when a `User` is validated.
+Now let's take a look at the code for connecting the validations for `User` and `Pet`. This will validate pets when a `User` is validated.
 
-Yup has a public API for extending schemas as well as creating custom tests,
-both can be used to create the connection we want.
+Yup has a public API for extending schemas as well as creating custom tests, both can be used to create the connection we want.
 
-- `addMethod` accepts a schema, a name of a method that is to be added on the
-  target schema, as well as a function.
-- `mixed#test` is a method that exists on all schemas, it can be used in
-  multiple ways, but in this case the only thing we need to know is that it's a
-  method that receives a function as an argument, and the function it receives
-  has to return a promise that returns `true` or `false`.
+- `addMethod` accepts a schema, a name of a method that is to be added on the target schema, as well as a function.
+- `mixed#test` is a method that exists on all schemas, it can be used in multiple ways, but in this case the only thing we need to know is that it's a method that receives a function as an argument, and the function it receives has to return a promise that returns `true` or `false`.
 
 #### belongsTo
 
@@ -337,10 +292,7 @@ addMethod(object, "relationship", function () {
 });
 ```
 
-This bit is fairly straightforward, we add a `relationship` method to the
-`object` schema. When `relationship` is called, it adds a custom test that
-receives `value` which is an instance of a model. After that it's just a matter
-of accessing the validaitons wrapper and running it's `validate` method.
+This bit is fairly straightforward, we add a `relationship` method to the `object` schema. When `relationship` is called, it adds a custom test that receives `value` which is an instance of a model. After that it's just a matter of accessing the validaitons wrapper and running it's `validate` method.
 
 #### hasMany
 
@@ -362,14 +314,9 @@ addMethod(array, "relationship", function () {
 });
 ```
 
-`hasMany` relationships are pretty much the same as `belongsTo`. The only
-difference is that the `hasMany` promise-proxy needs to be transformed into an
-array that Yup will be able to handle which is done by calling `toArray`. Then
-the test validates all object in the array and check whether all validations
-return `true`.
+`hasMany` relationships are pretty much the same as `belongsTo`. The only difference is that the `hasMany` promise-proxy needs to be transformed into an array that Yup will be able to handle which is done by calling `toArray`. Then the test validates all object in the array and check whether all validations return `true`.
 
-That's it – now we need to modify the `User` model by adding `pets` to its
-validations.
+That's it – now we need to modify the `User` model by adding `pets` to its validations.
 
 ```javascript
 import Model, { attr, hasMany } from "@ember-data/model";
@@ -394,9 +341,7 @@ export default class UserModel extends Model {
 
 ### Conditional validations
 
-There are times when you need to do some conditional validations based on some
-different state. Here we'll have a really weird requirement where `pet.name` is
-only required when the user is not allergic.
+There are times when you need to do some conditional validations based on some different state. Here we'll have a really weird requirement where `pet.name` is only required when the user is not allergic.
 
 ```javascript
 import Model, { attr, hasMany } from "@ember-data/model";
@@ -446,19 +391,12 @@ export default class PetModel extends Model {
 }
 ```
 
-`Pet` now implements the conditional `name` validation by calling the `when`
-method of the `string` schema. The `when` method accepts a list of names of
-dependent properties, then we pass an object which specifies that the `name`
-attribute is not required when `isUserAllergic` is `true`.
+`Pet` now implements the conditional `name` validation by calling the `when` method of the `string` schema. The `when` method accepts a list of names of dependent properties, then we pass an object which specifies that the `name` attribute is not required when `isUserAllergic` is `true`.
 
 ![Internationalized user and pet fields demo](/assets/images/posts/2021-12-08-validations-in-ember-apps/conditional-form-user-3.gif)
 
 ### Summary
 
-We've taken a look at an alternative approach to validating data in our apps.
-Now it's easier than ever to integrate with 3rd party libraries with mostly just
-Ember proxies standing on our way. I also find it beneficial to be able to use
-something like Yup for teams that work in many environments.
+We've taken a look at an alternative approach to validating data in our apps. Now it's easier than ever to integrate with 3rd party libraries with mostly just Ember proxies standing on our way. I also find it beneficial to be able to use something like Yup for teams that work in many environments.
 
-The complete source code used in this blog post can be found here:
-https://github.com/BobrImperator/emberfest-validations
+The complete source code used in this blog post can be found here: https://github.com/BobrImperator/emberfest-validations
diff --git a/src/posts/2022-03-07-better-code-with-lint-to-the-future.md b/src/posts/2022-03-07-better-code-with-lint-to-the-future.md
index a8aadb5bb4..d266478c5b 100644
--- a/src/posts/2022-03-07-better-code-with-lint-to-the-future.md
+++ b/src/posts/2022-03-07-better-code-with-lint-to-the-future.md
@@ -3,10 +3,7 @@ title: "Better code with lint-to-the-future"
 authorHandle: real_ate
 tags: misc
 bio: "Senior Software Engineer, Ember Learning Core Team member"
-description:
-  'Chris Manson walks you through his new project "lint-to-the-future",
-  demonstrating how to easily add and update lint rules with the help of the
-  tool.'
+description: 'Chris Manson walks you through his new project "lint-to-the-future", demonstrating how to easily add and update lint rules with the help of the tool.'
 og:
   image: /assets/images/posts/2022-03-07-better-code-with-lint-to-the-future/og-image.jpg
 tagline: |
@@ -16,16 +13,8 @@ tagline: |
   going to make that process a breeze.</p>
 ---
 
-Having lint rules implemented from the beginning of your project is a great way
-to make sure that your codebase stays neat. However, adding a new lint rule or
-even updating your framework-specific lint rules can be quite challenging: this
-is exactly what lint-to-the-future is designed to help you with. It is not a
-tool to replace eslint or any of your linting tools, but rather a handy helper
-that integrates with your existing workflow to help you progressively update
-large codebases.
+Having lint rules implemented from the beginning of your project is a great way to make sure that your codebase stays neat. However, adding a new lint rule or even updating your framework-specific lint rules can be quite challenging: this is exactly what lint-to-the-future is designed to help you with. It is not a tool to replace eslint or any of your linting tools, but rather a handy helper that integrates with your existing workflow to help you progressively update large codebases.
 
-In the following video, I'll demonstrate how to make use of lint-to-the-future’s
-command-line tool to help you enable a new lint rule while overcoming the
-problem of "lint rule explosion".
+In the following video, I'll demonstrate how to make use of lint-to-the-future’s command-line tool to help you enable a new lint rule while overcoming the problem of "lint rule explosion".
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/bsDFXjDKjPc" title="Embedded video of the introduction to lint-to-the-future" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
diff --git a/src/posts/2022-03-17-dynamic-components-embroider.md b/src/posts/2022-03-17-dynamic-components-embroider.md
index 994b7eb0e2..519ea08a95 100644
--- a/src/posts/2022-03-17-dynamic-components-embroider.md
+++ b/src/posts/2022-03-17-dynamic-components-embroider.md
@@ -5,9 +5,7 @@ tags: ember
 bio: "Senior Software Engineer"
 og:
   image: /assets/images/posts/2022-03-17-dynamic-components-embroider/og-image.jpg
-description:
-  "Nick Schot explains how to make dynamic component invocation work with
-  Embroider's static analysis."
+description: "Nick Schot explains how to make dynamic component invocation work with Embroider's static analysis."
 tagline: |
   <p><a href="https://github.com/embroider-build/embroider">Embroider</a> is the future for building Ember apps. It unlocks features like
   splitting code per route by statically analyzing your codebase and dependencies.
@@ -19,12 +17,7 @@ tagline: |
 
 ## What are dynamic components?
 
-{% raw %} Dynamic components are components resolved at run-time rather than
-hardcoding the component to use. Ember provides a component helper which takes
-an argument that is the dasherized string representation of the component path:
-`{{component "my-component"}}` or `{{component "folder/another-component"}}`.
-This is great for addons like ember-promise-modals as in this case it allows us
-to open a modal from javascript. {% endraw %}
+{% raw %} Dynamic components are components resolved at run-time rather than hardcoding the component to use. Ember provides a component helper which takes an argument that is the dasherized string representation of the component path: `{{component "my-component"}}` or `{{component "folder/another-component"}}`. This is great for addons like ember-promise-modals as in this case it allows us to open a modal from javascript. {% endraw %}
 
 ```javascript
 @service modals;
@@ -35,34 +28,21 @@ confirm() {
 }
 ```
 
-Internally ember-promise-modals uses the component helper to render these
-modals.
+Internally ember-promise-modals uses the component helper to render these modals.
 
 ## Then what is the problem?
 
-In order to make Embroider's route-splitting feature, which enables per-route
-optimized bundles with ideally only the components required for that route,
-Embroider needs to be able to statically resolve components at build time. This
-is not guaranteed with the component helper syntax. Hypothetically one could
-receive the component name from an API call, meaning there is no way to know
-this at build time.
+In order to make Embroider's route-splitting feature, which enables per-route optimized bundles with ideally only the components required for that route, Embroider needs to be able to statically resolve components at build time. This is not guaranteed with the component helper syntax. Hypothetically one could receive the component name from an API call, meaning there is no way to know this at build time.
 
 Fortunately, Embroider provides a few tools for us to make this work.
 
 ## Making old addons work in your Embroider Optimized app using `packageRules`
 
-`packageRules` are more of a compatability feature rather than being the ideal
-solution. They provide a way to tell Embroider what it needs to do. The main use
-case is for addons out of your control and/or addons that have not been updated
-yet to be fully Embroider optimized. By default Embroider currently ships
-`packageRules` for a few widely used addons so that they'll work out of the box.
+`packageRules` are more of a compatability feature rather than being the ideal solution. They provide a way to tell Embroider what it needs to do. The main use case is for addons out of your control and/or addons that have not been updated yet to be fully Embroider optimized. By default Embroider currently ships `packageRules` for a few widely used addons so that they'll work out of the box.
 
-Now let's see if we can make ember-promise-modals <= 2 work with Embroider
-through `packageRules`.
+Now let's see if we can make ember-promise-modals <= 2 work with Embroider through `packageRules`.
 
-If you have created an Embroider enabled app (for example through
-`ember new my-app --embroider`) your `ember-cli-build.js` file will contain a
-section that looks like this:
+If you have created an Embroider enabled app (for example through `ember new my-app --embroider`) your `ember-cli-build.js` file will contain a section that looks like this:
 
 ```javascript
 const { Webpack } = require("@embroider/webpack");
@@ -75,9 +55,7 @@ return require("@embroider/compat").compatBuild(app, Webpack, {
 });
 ```
 
-In order to be able to use route-splitting, we'll first have to enable all of
-Embroider's flags. Normally you would do this one by one, but in this case the
-only problem we're going to run into is with the `staticComponents` flag.
+In order to be able to use route-splitting, we'll first have to enable all of Embroider's flags. Normally you would do this one by one, but in this case the only problem we're going to run into is with the `staticComponents` flag.
 
 ```javascript
 const { Webpack } = require("@embroider/webpack");
@@ -94,19 +72,13 @@ return require("@embroider/compat").compatBuild(app, Webpack, {
 });
 ```
 
-When now trying to run the app with ember-promise-modals, we'll run into a
-compilation error.
+When now trying to run the app with ember-promise-modals, we'll run into a compilation error.
 
 ```shell
 Unsafe dynamic component: @modal._name in node_modules/ember-promise-modals/templates/components/modal.hbs
 ```
 
-This means Embroider detected a call to the component helper with a variable
-`@modal._name`. To try and resolve this, let's add a `packageRules` section for
-the `EpmModal` component. This component takes a `@modal` argument which is an
-object that also contains the `_name` property as shown in the error that
-Embroider threw. We can tell Embroider that this argument represents a component
-name. The layout of the component also needs to be explicitly passed.
+This means Embroider detected a call to the component helper with a variable `@modal._name`. To try and resolve this, let's add a `packageRules` section for the `EpmModal` component. This component takes a `@modal` argument which is an object that also contains the `_name` property as shown in the error that Embroider threw. We can tell Embroider that this argument represents a component name. The layout of the component also needs to be explicitly passed.
 
 ```javascript
 const { Webpack } = require('@embroider/webpack');
@@ -128,27 +100,13 @@ return require('@embroider/compat').compatBuild(app, Webpack, {
 });
 ```
 
-If we now run the app Embroider will no longer throw build-time errors and our
-modal will work. An unfortunate side-effect of this setup is that it will not
-result in the `<ExampleModal/>` component being split from the main bundle if
-you enable route-splitting. In order to get that working we'll have to dig a
-little deeper, but the `packageRules` approach is a good way to unblock a
-project from using a fully enabled Embroider with addons that do not have full
-Embroider support.
+If we now run the app Embroider will no longer throw build-time errors and our modal will work. An unfortunate side-effect of this setup is that it will not result in the `<ExampleModal/>` component being split from the main bundle if you enable route-splitting. In order to get that working we'll have to dig a little deeper, but the `packageRules` approach is a good way to unblock a project from using a fully enabled Embroider with addons that do not have full Embroider support.
 
 ## Updating your addon or dynamically invoked components to be Embroider Optimized
 
-In order to let Embroider know how to handle our dynamic modal component, we
-need to use the `ensure-safe-component` helper that Embroider provides. This
-helper will turn a component class into a component definition that can be
-invoked in the template. If just the name of a component is passed, it will use
-the old curly component resolver to get the component definition, but also throw
-a deprecation warning that you'll need to pass the component class when using
-Embroider. For comprehensive documentation see:
-[Replacing the Component Helper](https://github.com/embroider-build/embroider/blob/5fd49b50dd82bf7ceb6adeefa12efc2b85f92cd2/REPLACING-COMPONENT-HELPER.md)
+In order to let Embroider know how to handle our dynamic modal component, we need to use the `ensure-safe-component` helper that Embroider provides. This helper will turn a component class into a component definition that can be invoked in the template. If just the name of a component is passed, it will use the old curly component resolver to get the component definition, but also throw a deprecation warning that you'll need to pass the component class when using Embroider. For comprehensive documentation see: [Replacing the Component Helper](https://github.com/embroider-build/embroider/blob/5fd49b50dd82bf7ceb6adeefa12efc2b85f92cd2/REPLACING-COMPONENT-HELPER.md)
 
-In ember-promise-modals dynamic modal components are internally invoked with the
-component helper as follows:
+In ember-promise-modals dynamic modal components are internally invoked with the component helper as follows:
 
 ```handlebars
 {% raw %}
@@ -156,9 +114,7 @@ component helper as follows:
 {% endraw %}
 ```
 
-The relevant bit for us here is the first argument `@modal._name` which is the
-name of the modal component, say `example-modal`. We can wrap this with the
-`ensure-safe-component` helper that Embroider provides like this:
+The relevant bit for us here is the first argument `@modal._name` which is the name of the modal component, say `example-modal`. We can wrap this with the `ensure-safe-component` helper that Embroider provides like this:
 
 ```handlebars
 {% raw %}
@@ -180,9 +136,7 @@ Or if we want to use angle bracket syntax:
 {% endraw %}
 ```
 
-The other thing we need to change is the way we pass the component to
-ember-promise-modals in our app. We are currently still passing the
-`<ExampleModal/>` component as a dynamic string.
+The other thing we need to change is the way we pass the component to ember-promise-modals in our app. We are currently still passing the `<ExampleModal/>` component as a dynamic string.
 
 ```javascript
 @service modals;
@@ -193,8 +147,7 @@ confirm() {
 }
 ```
 
-If we were to start our app now (with `staticComponents: false`), we would get
-the following deprecation message:
+If we were to start our app now (with `staticComponents: false`), we would get the following deprecation message:
 
 ```
 DEPRECATION: You're trying to invoke the component "example-modal"
@@ -202,11 +155,7 @@ DEPRECATION: You're trying to invoke the component "example-modal"
 [deprecation id: ensure-safe-component.string] See https://github.com/embroider-build/embroider/blob/master/ADDON-AUTHOR-GUIDE.md#when-youre-passing-a-component-to-someone-else for more details.
 ```
 
-We can update our app code to actually import the component class so that
-Embroider can statically resolve this component. This will also make the
-deprecation message disappear. Note that this will _only_ work for co-located
-components or classic components that explicitly have their template definition
-set on the component class using `layout`.
+We can update our app code to actually import the component class so that Embroider can statically resolve this component. This will also make the deprecation message disappear. Note that this will _only_ work for co-located components or classic components that explicitly have their template definition set on the component class using `layout`.
 
 ```javascript
 import ExampleModal from '../components/example-modal';
@@ -221,9 +170,7 @@ confirm() {
 }
 ```
 
-After re-enabling `staticComponents: true`, the last thing we need to do is
-enable route-splitting in our app. This can be done by modifying the `router.js`
-file to use `@embroider/router`...
+After re-enabling `staticComponents: true`, the last thing we need to do is enable route-splitting in our app. This can be done by modifying the `router.js` file to use `@embroider/router`...
 
 ```javascript
 // app/router.js
@@ -239,9 +186,7 @@ export default class Router extends EmberRouter {
 Router.map(function () {});
 ```
 
-...and by configuring the `splitAtRoutes` feature in `ember-cli-build.js`. We
-can do this by adding the route names we want to split or by providing a regex.
-Our full configuration will now look like this:
+...and by configuring the `splitAtRoutes` feature in `ember-cli-build.js`. We can do this by adding the route names we want to split or by providing a regex. Our full configuration will now look like this:
 
 ```javascript
 const { Webpack } = require("@embroider/webpack");
@@ -259,16 +204,10 @@ return require("@embroider/compat").compatBuild(app, Webpack, {
 });
 ```
 
-If we now start our Embroider enabled app, we will see that our
-`<ExampleModal/>` component is in a separate javascript chunk which is
-dynamically loaded when the route where it is invoked is opened by the user.
+If we now start our Embroider enabled app, we will see that our `<ExampleModal/>` component is in a separate javascript chunk which is dynamically loaded when the route where it is invoked is opened by the user.
 
 ## Conclusion
 
-Even if you're still using addons that are not fully Embroider compatible, you
-might still be able to make them work by utilizing the `packageRules`
-configuration option. For properly updating an addon that requires dynamic
-components we can use `ensureSafeComponent` to make them compatible with
-Embroider and unlock the route-splitting feature.
+Even if you're still using addons that are not fully Embroider compatible, you might still be able to make them work by utilizing the `packageRules` configuration option. For properly updating an addon that requires dynamic components we can use `ensureSafeComponent` to make them compatible with Embroider and unlock the route-splitting feature.
 
 [contact]: /contact/
diff --git a/src/posts/2022-03-30-getting-started-wth-code-mods.md b/src/posts/2022-03-30-getting-started-wth-code-mods.md
index 38c48a2845..16a78c4055 100644
--- a/src/posts/2022-03-30-getting-started-wth-code-mods.md
+++ b/src/posts/2022-03-30-getting-started-wth-code-mods.md
@@ -3,9 +3,7 @@ title: "Code mods in JavaScript and how to get started creating your own"
 authorHandle: Mikek2252
 tags: javascript
 bio: "Senior Software Engineer"
-description:
-  "Michael Kerr gives a quick introduction into code mods in JavaScript and how
-  to create your own."
+description: "Michael Kerr gives a quick introduction into code mods in JavaScript and how to create your own."
 og:
   image: /assets/images/posts/2022-03-30-getting-started-with-code-mods/og-image.jpg
 tagline: |
@@ -19,8 +17,7 @@ tagline: |
   one.</p>
 ---
 
-For example updating the following code sample from concatenating with the `+`
-operator to using a template literal.
+For example updating the following code sample from concatenating with the `+` operator to using a template literal.
 
 ```javascript
 // Before
@@ -29,22 +26,13 @@ let message = "Hello, " + name;
 let message = `Hello, ${name}`;
 ```
 
-In the Ember community we love code mods: when deprecations in the framework are
-added, there is a good chance that a code mod is created in order to help
-everyone migrate their code. The Ember community even has an entire github
-organization dedicated to code mods which you can check out here:
-[https://github.com/ember-codemods](https://github.com/ember-codemods).
+In the Ember community we love code mods: when deprecations in the framework are added, there is a good chance that a code mod is created in order to help everyone migrate their code. The Ember community even has an entire github organization dedicated to code mods which you can check out here: [https://github.com/ember-codemods](https://github.com/ember-codemods).
 
-Despite the already great array of code mods available, there may not be one
-that covers your needs or fixes your problem. Fear not: making your own isn’t as
-complicated as it may seem.
+Despite the already great array of code mods available, there may not be one that covers your needs or fixes your problem. Fear not: making your own isn’t as complicated as it may seem.
 
 ## Setting up your code mod project
 
-Creating the initial project for a JavaScript or Handlebars code mod could not
-be simpler thanks to [Robert Jackson's](https://github.com/rwjblue)
-[codemod-cli tool](https://github.com/rwjblue/codemod-cli). What is left for you
-to do is run the following command and you will have all your prerequisites.
+Creating the initial project for a JavaScript or Handlebars code mod could not be simpler thanks to [Robert Jackson's](https://github.com/rwjblue) [codemod-cli tool](https://github.com/rwjblue/codemod-cli). What is left for you to do is run the following command and you will have all your prerequisites.
 
 ```
 npx codemod-cli new &lt;project-name&gt;
@@ -53,14 +41,11 @@ npx codemod-cli new &lt;project-name&gt;
 // you can have multiple code mods in this project!.
 ```
 
-Once your project has been created, make sure to `cd <project-name>` and install
-your dependencies via your chosen package manager.
+Once your project has been created, make sure to `cd <project-name>` and install your dependencies via your chosen package manager.
 
 ## Creating your code mod
 
-Now that the project has been setup and our dependences have been installed it's
-time to create our code mod. For the purpose of this post, we will create a rule
-for the string concatenation with the plus operator to a template literal.
+Now that the project has been setup and our dependences have been installed it's time to create our code mod. For the purpose of this post, we will create a rule for the string concatenation with the plus operator to a template literal.
 
 To create the rule boiler plate, all we need to do is run the following command:
 
@@ -68,18 +53,11 @@ To create the rule boiler plate, all we need to do is run the following command:
 npx codemod-cli generate codemod &lt;name of codemod&gt;
 ```
 
-Once the command has finished, you should see a new folder with the name of your
-code mod. Inside of it, you should find a folder for your test fixtures along
-with an `index.js` and `test.js` file.
+Once the command has finished, you should see a new folder with the name of your code mod. Inside of it, you should find a folder for your test fixtures along with an `index.js` and `test.js` file.
 
 ## Setting up your test fixtures
 
-Before I start writing the code mod itself, I like to set up the test fixtures.
-Inside your `__testfixtures__`, you should already have an `*.input.js` file and
-an `*.output,js`. The `input.js` file should contain the 'input' code, or in
-other words the code to be changed and the `*.output.js` should contain what you
-expect the code to be after the code mod has ran. This is what it would look
-like for my example:
+Before I start writing the code mod itself, I like to set up the test fixtures. Inside your `__testfixtures__`, you should already have an `*.input.js` file and an `*.output,js`. The `input.js` file should contain the 'input' code, or in other words the code to be changed and the `*.output.js` should contain what you expect the code to be after the code mod has ran. This is what it would look like for my example:
 
 `basic.input.js`
 
@@ -99,13 +77,11 @@ If you need to add any more text fixtures you can run the following command:
 npx codemod-cli generate fixture &lt;name of codemod&gt; &lt;name of fixture&gt;
 ```
 
-Or simply just create your own `fixture-name.input.js` and
-`fixture-name.output.js` in the same folder.
+Or simply just create your own `fixture-name.input.js` and `fixture-name.output.js` in the same folder.
 
 ## Creating the code mod
 
-Once everything has been set up and you have your test fixtures, it is time to
-start writing.
+Once everything has been set up and you have your test fixtures, it is time to start writing.
 
 If you open up your `index.js` file you should find an example code mod:
 
@@ -126,19 +102,13 @@ module.exports = function transformer(file, api) {
 module.exports.type = "js";
 ```
 
-This example finds all `identifiers`(the name for a variable) and reverses the
-name.
+This example finds all `identifiers`(the name for a variable) and reverses the name.
 
-Our first step is to add the correct identifier parameter for the find function.
-The easiest way to do this is to use [astexplorer.net](https://astexplorer.net/)
-which can show you code broken down into an abstract syntax tree or AST.
+Our first step is to add the correct identifier parameter for the find function. The easiest way to do this is to use [astexplorer.net](https://astexplorer.net/) which can show you code broken down into an abstract syntax tree or AST.
 
 ![AST Explorer](/assets/images/posts/2022-03-30-getting-started-with-code-mods/astExplorer.png)
 
-With the autofocus check box enabled, it will highlight the tree and the code to
-help show you what node is what. Using this we can see that `'Hello, ' + name;`
-is a `BinaryExpression`. So let's update our code with the correct Identifier
-and instead of using the `.forEach` we will add `.replaceWith`.
+With the autofocus check box enabled, it will highlight the tree and the code to help show you what node is what. Using this we can see that `'Hello, ' + name;` is a `BinaryExpression`. So let's update our code with the correct Identifier and instead of using the `.forEach` we will add `.replaceWith`.
 
 ```javascript
 const { getParser } = require("codemod-cli").jscodeshift;
@@ -157,16 +127,11 @@ module.exports = function transformer(file, api) {
 module.exports.type = "js";
 ```
 
-To convert from a `BinaryExpression` to a `TemplateLiteral` we will need to
-return a `TemplateLiteral` node from the `replaceWith` function. As we are using
-the babel parser, we can use https://babeljs.io/docs/en/babel-types to help us
-work out what we need to create a `TemplateLiteral`.
+To convert from a `BinaryExpression` to a `TemplateLiteral` we will need to return a `TemplateLiteral` node from the `replaceWith` function. As we are using the babel parser, we can use https://babeljs.io/docs/en/babel-types to help us work out what we need to create a `TemplateLiteral`.
 
 ![TemplateLiteral Documentation](/assets/images/posts/2022-03-30-getting-started-with-code-mods/templateLiteral.png)
 
-`TemplateLiteral`s require an array of `TemplateElement`s, which will be the
-strings and an array of expressions being the variables. So for now we can
-update our code to look like this:
+`TemplateLiteral`s require an array of `TemplateElement`s, which will be the strings and an array of expressions being the variables. So for now we can update our code to look like this:
 
 ```javascript
 module.exports = function transformer(file, api) {
@@ -187,8 +152,7 @@ module.exports = function transformer(file, api) {
 module.exports.type = "js";
 ```
 
-If we were to run the tests now with this transformation you will see that it
-now replaces all `BinaryExpression`s with an empty `TemplateLiteral`;
+If we were to run the tests now with this transformation you will see that it now replaces all `BinaryExpression`s with an empty `TemplateLiteral`;
 
 ```javascript
 let message = "hello " + name;
@@ -196,13 +160,7 @@ let message = "hello " + name;
 let message = ``;
 ```
 
-Now we have a `TemplateLiteral` we need to extract the information from our
-`BinaryExpression` to add to our `TemplateLiteral`. A `BinaryExpression` has
-three attributes: `operator`, `left` and `right`. We need to check both `left`
-and `right` nodes to see if either is a `StringLiteral` or whether it is an
-`Identifier`/variable. If the node is a `StringLiteral`, it needs to be
-converted to a `TemplateElement`. If the node is an `Identifier`, we need to add
-it to the expressions array.
+Now we have a `TemplateLiteral` we need to extract the information from our `BinaryExpression` to add to our `TemplateLiteral`. A `BinaryExpression` has three attributes: `operator`, `left` and `right`. We need to check both `left` and `right` nodes to see if either is a `StringLiteral` or whether it is an `Identifier`/variable. If the node is a `StringLiteral`, it needs to be converted to a `TemplateElement`. If the node is an `Identifier`, we need to add it to the expressions array.
 
 That leaves us with this code:
 
@@ -241,14 +199,8 @@ Now let's run our test case to see if it passes.
 
 ![Test success screenshot](/assets/images/posts/2022-03-30-getting-started-with-code-mods/test-success-screenshot.png)
 
-_Note: `is idempotent` is a test added by codemod-cli to check that rerunning
-the code mod will always give the same result_
+_Note: `is idempotent` is a test added by codemod-cli to check that rerunning the code mod will always give the same result_
 
-That test case has passed, but as you may have noticed by now, this
-implementation has many limitations: what happens if we use a number instead of
-a string or have multiple `BinaryExpression`s, or a minus is used instead of a
-plus? Well that is where I will leave you to try and add some of your own test
-cases and see if you can tackle some of the limitations within this code mod.
+That test case has passed, but as you may have noticed by now, this implementation has many limitations: what happens if we use a number instead of a string or have multiple `BinaryExpression`s, or a minus is used instead of a plus? Well that is where I will leave you to try and add some of your own test cases and see if you can tackle some of the limitations within this code mod.
 
-If you would like to learn more about code mods and AST's check out
-[our AST workshop](https://github.com/mainmatter/ast-workshop).
+If you would like to learn more about code mods and AST's check out [our AST workshop](https://github.com/mainmatter/ast-workshop).
diff --git a/src/posts/2022-05-11-what-to-do-if-you-dont-feel-heard-at-work.md b/src/posts/2022-05-11-what-to-do-if-you-dont-feel-heard-at-work.md
index 120f15781c..c00d82e161 100644
--- a/src/posts/2022-05-11-what-to-do-if-you-dont-feel-heard-at-work.md
+++ b/src/posts/2022-05-11-what-to-do-if-you-dont-feel-heard-at-work.md
@@ -5,10 +5,7 @@ tags: company-culture
 bio: "Software Engineer"
 og:
   image: /assets/images/posts/2022-05-11-what-to-do-if-you-dont-feel-heard-at-work/og-image.jpg
-description:
-  Oscar Dominguez writes to himself of the past and tries to make him realize
-  that a better world is possible. There are companies where employees are
-  listened to and their opinions are taken into consideration.
+description: Oscar Dominguez writes to himself of the past and tries to make him realize that a better world is possible. There are companies where employees are listened to and their opinions are taken into consideration.
 tagline: |
   <p>86%</p>
   <p>That is the number of people who don't feel heard **fairly or equally** at their
@@ -30,39 +27,27 @@ How **connected** do you feel to:
 
 If your answer is
 
-> 😔 "_I feel_ _disconnected. I tried to share my ideas but all of them got
-> discarded so I got tired of bringing suggestions.”_
+> 😔 "_I feel_ _disconnected. I tried to share my ideas but all of them got discarded so I got tired of bringing suggestions.”_
 
-> 😩 “Oh my God, it’s Monday again. I hate this project. I don’t like the
-> direction in which this is going.”
+> 😩 “Oh my God, it’s Monday again. I hate this project. I don’t like the direction in which this is going.”
 
 > 🙁 “Hmm, _I don’t know... It is what it is..."_
 
 keep reading because you are not alone.
 
-According to
-[a global research](https://www.forbes.com/sites/carolinecenizalevine/2021/06/23/new-survey-shows-the-business-benefit-of-feeling-heard--5-ways-to-build-inclusive-teams/?sh=1ccf117d5f0c)
-carried out across 11 countries by
-[The Workforce Institute](https://www.workforceinstitute.org/) at
-[UKG](https://www.ukg.com/), the vast majority (86%) of employees feel people at
-their organisation are not heard fairly or equally — and nearly half (47%) say
-that underrepresented voices remain undervalued by employers.
+According to [a global research](https://www.forbes.com/sites/carolinecenizalevine/2021/06/23/new-survey-shows-the-business-benefit-of-feeling-heard--5-ways-to-build-inclusive-teams/?sh=1ccf117d5f0c) carried out across 11 countries by [The Workforce Institute](https://www.workforceinstitute.org/) at [UKG](https://www.ukg.com/), the vast majority (86%) of employees feel people at their organisation are not heard fairly or equally — and nearly half (47%) say that underrepresented voices remain undervalued by employers.
 
 It happened to me in the past and, worry not, there is a solution for it! 😀 🥳
 
 ## The art of listening
 
-As professionals, we **want to feel we are being heard.** When that does not
-happen, a feeling of **disconnection** arises.
+As professionals, we **want to feel we are being heard.** When that does not happen, a feeling of **disconnection** arises.
 
-This happened to me in the past and the following questions came to my mind by
-then:
+This happened to me in the past and the following questions came to my mind by then:
 
 - Is this feeling **normal**?
-- Am I being **selfish**? I should be focusing on the company’s mission instead,
-  right? They are paying me for that.
-- Is there something I can do on my end? The others are the ones not listening
-  to me, there’s nothing I can do.
+- Am I being **selfish**? I should be focusing on the company’s mission instead, right? They are paying me for that.
+- Is there something I can do on my end? The others are the ones not listening to me, there’s nothing I can do.
 
 Let’s answer question by question:
 
@@ -77,69 +62,48 @@ As professionals we want:
 - to help others
 - to grow
 
-When this does not happen we feel frustrated and this frustration **ends up
-impacting the relationship** with our **team**, the **project** in which we are
-participating, or even our relationship with our **company**.
+When this does not happen we feel frustrated and this frustration **ends up impacting the relationship** with our **team**, the **project** in which we are participating, or even our relationship with our **company**.
 
-> Am I being selfish? I should be focusing on the company’s mission instead,
-> right? They are paying me for that.
+> Am I being selfish? I should be focusing on the company’s mission instead, right? They are paying me for that.
 
-No, you are not being selfish. Your company needs you to be happy and enjoy your
-job.
+No, you are not being selfish. Your company needs you to be happy and enjoy your job.
 
-When this happens, you show all your potential as a professional. Your team, the
-product and your company benefit from it. Your company is paying you for that,
-for your maximum potential. It’s a win-win!
+When this happens, you show all your potential as a professional. Your team, the product and your company benefit from it. Your company is paying you for that, for your maximum potential. It’s a win-win!
 
 If this is not happening, there is something wrong that needs to be fixed:
 
 1. **Are you aligned with your company and team values?**
-2. Is your vision of your **career path aligned with** the idea **your company**
-   has in mind?
+2. Is your vision of your **career path aligned with** the idea **your company** has in mind?
 
-If the answer is yes, keep reading because there’s probably something you can do
-about it.
+If the answer is yes, keep reading because there’s probably something you can do about it.
 
 If the answer is no, this probably means you need a change.
 
-> Is there something I can do on my end? The problem is others not listening to
-> me, there’s nothing I can control.
+> Is there something I can do on my end? The problem is others not listening to me, there’s nothing I can control.
 
-Yes, you can. You can’t control what others do unless you have very good
-hypnosis skills but you can decide to perceive this as a problem or not. What if
-you try to take the initiative? Let’s show the rest how _The Art of Listening_
-is and spread it to the world.
+Yes, you can. You can’t control what others do unless you have very good hypnosis skills but you can decide to perceive this as a problem or not. What if you try to take the initiative? Let’s show the rest how _The Art of Listening_ is and spread it to the world.
 
 ## Take initiative with empathy
 
-I’m pretty sure you have already tried to give your opinion to improve a
-feature, a process, a team ceremony... but nothing happened. No feedback, or
-automatically rejected.
+I’m pretty sure you have already tried to give your opinion to improve a feature, a process, a team ceremony... but nothing happened. No feedback, or automatically rejected.
 
-I know, it’s very frustrating and you got tired of it. Maybe you stopped trying.
-The key question here is: Do you know why? Why did you not get feedback or why
-did it get rejected?
+I know, it’s very frustrating and you got tired of it. Maybe you stopped trying. The key question here is: Do you know why? Why did you not get feedback or why did it get rejected?
 
 ### Identify the problem/s
 
-Let’s assume the best of the intentions from your teammates, the stakeholders,
-the company or whoever should be the one listening to you. Why would they ignore
-you? Or automatically reject you?
+Let’s assume the best of the intentions from your teammates, the stakeholders, the company or whoever should be the one listening to you. Why would they ignore you? Or automatically reject you?
 
 The list of possibilities is long:
 
 - There is no time to attend my petition or suggestion
 - It is not a priority for them
 - There is not a clear process for me to share my thoughts
-- I’m not involved when decisions are discussed and taken and when I discover
-  them it’s late.
+- I’m not involved when decisions are discussed and taken and when I discover them it’s late.
 - etc.
 
-The list is long and it varies depending on the week, a moment of the day or a
-topic.
+The list is long and it varies depending on the week, a moment of the day or a topic.
 
-The very first step is to **identify the problem/s that are making your message
-go unheard by the rest.**
+The very first step is to **identify the problem/s that are making your message go unheard by the rest.**
 
 Once that is clear, we can come up with solutions.
 
@@ -153,76 +117,50 @@ Especially at the beginning, if the list is long, choose the topics which are:
 - more significant for your team
 - more significant for your company
 
-Don’t worry, there will be time for the rest. Or maybe they were not that
-important in the end 🙂
+Don’t worry, there will be time for the rest. Or maybe they were not that important in the end 🙂
 
 ### Propose solutions with empathy
 
-I’m sure you already tried to use the processes in place to communicate your
-opinion, but this is not working so we need to come up with solutions.
+I’m sure you already tried to use the processes in place to communicate your opinion, but this is not working so we need to come up with solutions.
 
-To be effective, these solutions need to be empathetic with all parts. If they
-look good to you but they are not taking into consideration other parts involved
-in the conversation, it means they won’t get traction.
+To be effective, these solutions need to be empathetic with all parts. If they look good to you but they are not taking into consideration other parts involved in the conversation, it means they won’t get traction.
 
-Is the process in place being empathetic with all parts? No? Let’s change it!
-Maybe it needs to change the channel, to use a meeting instead of being
-asynchronous to make it happen. Or the other way around, to be asynchronous
-because there is no time for meetings. Think about the proposal you want to talk
-about, think about the receptors and what could work for them.
+Is the process in place being empathetic with all parts? No? Let’s change it! Maybe it needs to change the channel, to use a meeting instead of being asynchronous to make it happen. Or the other way around, to be asynchronous because there is no time for meetings. Think about the proposal you want to talk about, think about the receptors and what could work for them.
 
 ### Lead by example
 
-You want to feel listened but, are you a good listener? If you make your
-colleagues feel heard maybe they replicate it. Don’t you think? 😜
+You want to feel listened but, are you a good listener? If you make your colleagues feel heard maybe they replicate it. Don’t you think? 😜
 
 Check these tips:
 
 - **Pay attention**. Make sure the other feels heard, not only listened to.
-- Show that you are **engaged with what’s been told**. Use your body language
-  and gestures to give feedback to the other.
+- Show that you are **engaged with what’s been told**. Use your body language and gestures to give feedback to the other.
 - Ask with **curiosity, not judgement**
 - **Don’t interrupt**
 
 ## Conclusion
 
-Not feeling heard at your company
-[is a global problem lots of employees suffer worldwide](https://www.forbes.com/sites/carolinecenizalevine/2021/06/23/new-survey-shows-the-business-benefit-of-feeling-heard--5-ways-to-build-inclusive-teams/?sh=1ccf117d5f0c).
-You are not alone.
+Not feeling heard at your company [is a global problem lots of employees suffer worldwide](https://www.forbes.com/sites/carolinecenizalevine/2021/06/23/new-survey-shows-the-business-benefit-of-feeling-heard--5-ways-to-build-inclusive-teams/?sh=1ccf117d5f0c). You are not alone.
 
-The first exercise you need to do is to assure you are aligned with your company
-and team values. Some questions from a book I just read may help you:
+The first exercise you need to do is to assure you are aligned with your company and team values. Some questions from a book I just read may help you:
 
-> _Should we not evaluate our jobs according to how much they help us find
-> meaning and love in life? Do our jobs help us learn more about the purpose of
-> our lives? Do they develop our level of self-insight and self-awareness? How
-> good are we at creating meaningfulness for our colleagues?_
+> _Should we not evaluate our jobs according to how much they help us find meaning and love in life? Do our jobs help us learn more about the purpose of our lives? Do they develop our level of self-insight and self-awareness? How good are we at creating meaningfulness for our colleagues?_
 
-_One Life: How we forgot to live meaningful lives_ by
-**[Morten Albæk](https://en.wikipedia.org/wiki/Morten_Alb%C3%A6k)**
+_One Life: How we forgot to live meaningful lives_ by **[Morten Albæk](https://en.wikipedia.org/wiki/Morten_Alb%C3%A6k)**
 
-This article tries to recollect some ideas and positive actions you can take to
-try to make you feel heard at work through the art of being a good listener.
-Take the initiative to dominate this art while being empathetic with the others:
+This article tries to recollect some ideas and positive actions you can take to try to make you feel heard at work through the art of being a good listener. Take the initiative to dominate this art while being empathetic with the others:
 
 - [Identify the problem/s](/blog/2022/05/11/what-to-do-if-you-dont-feel-heard-at-work/#identify-the-problems)
 - [Choose your battles](/blog/2022/05/11/what-to-do-if-you-dont-feel-heard-at-work/#choose-your-battles)
 - [Propose solutions with empathy](/blog/2022/05/11/what-to-do-if-you-dont-feel-heard-at-work/#propose-solutions-with-empathy)
 - [Lead by example](/blog/2022/05/11/what-to-do-if-you-dont-feel-heard-at-work/#lead-by-example)
 
-We would love to hear your personal experience on this topic. Do you have any
-tip or story you would like to share with us and the rest of the readers? Feel
-free to comment on our [Twitter](https://twitter.com/mainmatter) or
-[LinkedIn](https://www.linkedin.com/company/mainmatter/).
+We would love to hear your personal experience on this topic. Do you have any tip or story you would like to share with us and the rest of the readers? Feel free to comment on our [Twitter](https://twitter.com/mainmatter) or [LinkedIn](https://www.linkedin.com/company/mainmatter/).
 
 ---
 
 ## Resources
 
-- [The Art of Listening](https://www.youtube.com/watch?v=qpnNsSyDw-g&ab_channel=SimonSinek)
-  by [Simon Sinek](https://simonsinek.com/)
-- [New Survey Shows The Business Benefit Of Feeling Heard – 5 Ways To Build Inclusive Teams](https://www.forbes.com/sites/carolinecenizalevine/2021/06/23/new-survey-shows-the-business-benefit-of-feeling-heard--5-ways-to-build-inclusive-teams/?sh=1ccf117d5f0c)
-  by
-  [Caroline Ceniza-Levine](https://www.forbes.com/sites/carolinecenizalevine/)
-- [One Life: How we forgot to live meaningful lives](https://www.goodreads.com/book/show/48725742-one-life?from_search=true&from_srp=true&qid=Dq8fa2WmC6&rank=1)
-  by [Morten Albæk](https://en.wikipedia.org/wiki/Morten_Alb%C3%A6k)
+- [The Art of Listening](https://www.youtube.com/watch?v=qpnNsSyDw-g&ab_channel=SimonSinek) by [Simon Sinek](https://simonsinek.com/)
+- [New Survey Shows The Business Benefit Of Feeling Heard – 5 Ways To Build Inclusive Teams](https://www.forbes.com/sites/carolinecenizalevine/2021/06/23/new-survey-shows-the-business-benefit-of-feeling-heard--5-ways-to-build-inclusive-teams/?sh=1ccf117d5f0c) by [Caroline Ceniza-Levine](https://www.forbes.com/sites/carolinecenizalevine/)
+- [One Life: How we forgot to live meaningful lives](https://www.goodreads.com/book/show/48725742-one-life?from_search=true&from_srp=true&qid=Dq8fa2WmC6&rank=1) by [Morten Albæk](https://en.wikipedia.org/wiki/Morten_Alb%C3%A6k)
diff --git a/src/posts/2022-05-19-journey-of-a-junior-software-engineer.md b/src/posts/2022-05-19-journey-of-a-junior-software-engineer.md
index 728c0aa050..61b7d8dbfe 100644
--- a/src/posts/2022-05-19-journey-of-a-junior-software-engineer.md
+++ b/src/posts/2022-05-19-journey-of-a-junior-software-engineer.md
@@ -5,11 +5,7 @@ tags: process
 bio: "Junior Software-Engineer"
 og:
   image: /assets/images/posts/2022-05-19-journey-of-a-junior-software-engineer/og-image.jpg
-description:
-  "Inês Silva is currently the only junior software-engineer at Mainmatter. She
-  shares how it is to onboard into your 1st software engineer job, and how her
-  week at Mainmatter looks like. Also, she gives 5 main tips for other junior
-  software engineers."
+description: "Inês Silva is currently the only junior software-engineer at Mainmatter. She shares how it is to onboard into your 1st software engineer job, and how her week at Mainmatter looks like. Also, she gives 5 main tips for other junior software engineers."
 tagline: |
   <p>When do we look for our <strong>first job as software engineers</strong> some questions might
   pop up like - <strong>How will my week look like?</strong> <strong>What will be the most
@@ -21,59 +17,39 @@ tagline: |
   some <strong>tips</strong> on the way based on the challenges I faced 💪</p>
 ---
 
-My journey at Mainmatter started in July of 2021: soon it will be 11 months that
-I’m here.
+My journey at Mainmatter started in July of 2021: soon it will be 11 months that I’m here.
 
-Before landing here, I did a 4 months internship as a Ruby backend engineer 💎 I
-wanted to continue to improve my backend knowledge and discover the frontend
-world (that I had so little insight into before)
+Before landing here, I did a 4 months internship as a Ruby backend engineer 💎 I wanted to continue to improve my backend knowledge and discover the frontend world (that I had so little insight into before)
 
-I can stop here for the **#1 Tip** - **If you don’t know,** **start as
-full-stack.**
+I can stop here for the **#1 Tip** - **If you don’t know,** **start as full-stack.**
 
-This way, you can get a better picture of both frontend and backend parts of a
-project and then find what fits you better or just stay in both worlds.
+This way, you can get a better picture of both frontend and backend parts of a project and then find what fits you better or just stay in both worlds.
 
 After the internship, I landed at Mainmatter for my 1st job 🙌
 
-Here, I immediately started working on a web app for an IT security company. The
-stack was Next.js & Typescript.
+Here, I immediately started working on a web app for an IT security company. The stack was Next.js & Typescript.
 
-As I said before I had very little experience with the frontend world, and
-apparently with git. 😅
+As I said before I had very little experience with the frontend world, and apparently with git. 😅
 
-My first struggles were git-related problems - I feel this is the thing that
-developers tend to be overconfident about.
+My first struggles were git-related problems - I feel this is the thing that developers tend to be overconfident about.
 
-In university, every time we started a project using git we would drop it at
-some point and we would go to the archaic system of copy-pasting code between
-us. 🥲
+In university, every time we started a project using git we would drop it at some point and we would go to the archaic system of copy-pasting code between us. 🥲
 
 This was no proper way of working so my **#2 Tip - Get git rolling**
 
-You will never be alone in a project, so force yourself to learn tools that will
-make you more efficient at working as a team.
+You will never be alone in a project, so force yourself to learn tools that will make you more efficient at working as a team.
 
-Most of my colleagues always use the terminal so I found it easier to go along
-with this method (plus it gives you that hacker look 😎) but there is an
-interface option [Github Desktop](https://desktop.github.com/).
+Most of my colleagues always use the terminal so I found it easier to go along with this method (plus it gives you that hacker look 😎) but there is an interface option [Github Desktop](https://desktop.github.com/).
 
 Time to jump to **#3 tip - Keep a learning journal.**
 
-Since I was documenting all of my git struggles, I will give you a glimpse at
-what my notion notes were looking like in my second week here 😂:
+Since I was documenting all of my git struggles, I will give you a glimpse at what my notion notes were looking like in my second week here 😂:
 
 ![My note taking with notion](/assets/images/posts/2022-05-19-journey-of-a-junior-software-engineer/my-notion-notes-eg1.png)
 
 ![](/assets/images/posts/2022-05-19-journey-of-a-junior-software-engineer/my-notion-notes-eg2.png)
 
-Git merge vs Git rebase was a frequent debate, and according to my notes, I
-found this enlightening video on the
-[topic](https://www.youtube.com/watch?v=CRlGDDprdOQ&ab_channel=Academind). Then,
-when I was finally becoming more comfortable with which commands I should use,
-they told me to tidy my git history 🧹 -
-[this post](https://mainmatter.com/blog/2021/05/26/keeping-a-clean-git-history/)
-done by Chris came in handy.
+Git merge vs Git rebase was a frequent debate, and according to my notes, I found this enlightening video on the [topic](https://www.youtube.com/watch?v=CRlGDDprdOQ&ab_channel=Academind). Then, when I was finally becoming more comfortable with which commands I should use, they told me to tidy my git history 🧹 - [this post](https://mainmatter.com/blog/2021/05/26/keeping-a-clean-git-history/) done by Chris came in handy.
 
 As I showed above, I keep a journal where I note down:
 
@@ -81,48 +57,29 @@ As I showed above, I keep a journal where I note down:
 - key ideas on topics I researched
 - things I should search more about
 
-I believe the junior phase can be the most overwhelming one: your learning curve
-is in skyrocket mode 🚀! With all this new info coming all the time, I find it
-helpful to write everything down as a way to organize the new content in my
-head. Also, since a lot of errors I was seeing would show up again, I could find
-what I did & re-apply it.
+I believe the junior phase can be the most overwhelming one: your learning curve is in skyrocket mode 🚀! With all this new info coming all the time, I find it helpful to write everything down as a way to organize the new content in my head. Also, since a lot of errors I was seeing would show up again, I could find what I did & re-apply it.
 
-Nowadays, I need to take notes less and less and even the pace slowed down from
-week logs to month logs 😆 as you can see by my notion pages:
+Nowadays, I need to take notes less and less and even the pace slowed down from week logs to month logs 😆 as you can see by my notion pages:
 
 ![My pages organization in notion](/assets/images/posts/2022-05-19-journey-of-a-junior-software-engineer/my-notion-pages.png)
 
-After git problems, the second position on the podium of challenges goes to
-testing 🏆
+After git problems, the second position on the podium of challenges goes to testing 🏆
 
 That being said we go for the **#4 Tip - Get your hands-on testing**
 
-I don’t know how it works in other degrees, but I didn’t write a single test for
-my programs until I enter the professional world.
+I don’t know how it works in other degrees, but I didn’t write a single test for my programs until I enter the professional world.
 
-Since I’m working here, I’ve been using a JS testing framework,
-_[Jest](https://jestjs.io/)_ and a
-[\*react testing library](https://testing-library.com/docs/react-testing-library/intro/).\*
+Since I’m working here, I’ve been using a JS testing framework, _[Jest](https://jestjs.io/)_ and a [\*react testing library](https://testing-library.com/docs/react-testing-library/intro/).\*
 
-Until recently, I have wondered: ‘My code is done, why am I wasting my time with
-this?’ - especially when a lot of times I was losing more time in writing tests
-than actual code. 😅 However, a few weeks ago, the moment came when I thanked
-myself for having tests. 💡 I have been working on a project since September so
-at this point it is getting pretty big.
+Until recently, I have wondered: ‘My code is done, why am I wasting my time with this?’ - especially when a lot of times I was losing more time in writing tests than actual code. 😅 However, a few weeks ago, the moment came when I thanked myself for having tests. 💡 I have been working on a project since September so at this point it is getting pretty big.
 
-We are in the process of adding validations in user forms, and the tests are
-functioning like a bulletproof jacket. 🛡️
+We are in the process of adding validations in user forms, and the tests are functioning like a bulletproof jacket. 🛡️
 
-Multiple times I thought that my code was working well but then I ran the tests
-and realized I was breaking the code of other features. 🥲
+Multiple times I thought that my code was working well but then I ran the tests and realized I was breaking the code of other features. 🥲
 
-My previous mentor once told me that he prefers to write the tests before his
-code as a way of breaking down the steps of the problem and building confidence
-in his code.
+My previous mentor once told me that he prefers to write the tests before his code as a way of breaking down the steps of the problem and building confidence in his code.
 
-This style of programming is called TDD - test-driven development. In my head it
-looked weird - “how can I write a test before having the code?”, but I have
-started to do it now:
+This style of programming is called TDD - test-driven development. In my head it looked weird - “how can I write a test before having the code?”, but I have started to do it now:
 
 ```jsx
 describe("professional info is", () => {
@@ -146,75 +103,41 @@ describe("professional info is", () => {
 
 ```
 
-I needed to add a validation for an input and I started with the code above,
-after which I would go to my validation function and change it until I made sure
-I was throwing an invalid response for null values.
+I needed to add a validation for an input and I started with the code above, after which I would go to my validation function and change it until I made sure I was throwing an invalid response for null values.
 
-Testing, it’s still not my cup of tea. I want to invest more in learning about
-it and it will probably be more enjoyable once I get better at it, so I will try
-to get my colleagues to pair program with me about this.
+Testing, it’s still not my cup of tea. I want to invest more in learning about it and it will probably be more enjoyable once I get better at it, so I will try to get my colleagues to pair program with me about this.
 
-Speaking of mentors, I’m going to my last tip **#5 tip - get a mentor and jump
-into pair programming sessions**.
+Speaking of mentors, I’m going to my last tip **#5 tip - get a mentor and jump into pair programming sessions**.
 
-The way this goes depends on the environment within your company. Unfortunately,
-I see a lot of juniors that tell me that they never did pair programming with a
-colleague or that they get judged by the amount of time they need to accomplish
-their tasks.
+The way this goes depends on the environment within your company. Unfortunately, I see a lot of juniors that tell me that they never did pair programming with a colleague or that they get judged by the amount of time they need to accomplish their tasks.
 
-If you land in a new job where nobody is showing availability to help you out -
-you are in the wrong place.
+If you land in a new job where nobody is showing availability to help you out - you are in the wrong place.
 
-During my first 3 months at Mainmatter, I was probably pair programming at least
-once a week, sometimes more. Right now I'm doing it less often, which is
-natural - the more you progress the more independent you become.
+During my first 3 months at Mainmatter, I was probably pair programming at least once a week, sometimes more. Right now I'm doing it less often, which is natural - the more you progress the more independent you become.
 
-However, I do want to go back to more regular pair programming sessions - not
-only is it a great way of learning, but it also makes you understand your
-colleagues' thinking flow better, which makes reviewing each other's code
-easier.
+However, I do want to go back to more regular pair programming sessions - not only is it a great way of learning, but it also makes you understand your colleagues' thinking flow better, which makes reviewing each other's code easier.
 
 ### So, how is my week as a junior dev looking now?
 
-- I keep working with React: it has some tricky concepts that I’m still trying
-  to fully understand, like dealing with the state of components.
-- We have 1 day per week to work on open source/learning. I’m using mine to
-  create a personal website in Ember which has been a great way of learning
-  while doing a project that I like.
-- I’m part of the culture team - we discuss topics that aim for a continuous
-  good team environment. I’m organizing the Lunch & Learn event once a month
-  which was born from these meetings.
-- I’m having 🇫🇷 lessons, I'm happy that Mainmatter allows me to grow in other
-  fields!
+- I keep working with React: it has some tricky concepts that I’m still trying to fully understand, like dealing with the state of components.
+- We have 1 day per week to work on open source/learning. I’m using mine to create a personal website in Ember which has been a great way of learning while doing a project that I like.
+- I’m part of the culture team - we discuss topics that aim for a continuous good team environment. I’m organizing the Lunch & Learn event once a month which was born from these meetings.
+- I’m having 🇫🇷 lessons, I'm happy that Mainmatter allows me to grow in other fields!
 
   ## Conclusion
 
-  As (junior) software engineers, you probably have been googling and reading
-  from websites the whole day already, so we love tldr part don't we?
+  As (junior) software engineers, you probably have been googling and reading from websites the whole day already, so we love tldr part don't we?
 
 Let me sum up my **tips** for you:
 
-- **#1 If you don't know, apply for full-stack jobs.** The software development
-  world is a wide place, if you don't know where you fit the best.
-- **#2 Get git rolling.** You will never work alone, so invest a lot of learning
-  time in tools that will make you work efficiently in a team like Git.
-- **#3 Keep a learning journal** As juniors, our learning curve is on skyrocket
-  mode, even tho we deal with computers we don't operate like them, note down
-  your daily challenges and how you overcame them, maybe you will not read it
-  later but it will help you tidy in your mind all the new information.
-- **#4 Get your hands-on testing** I think if, before your 1st job, you were
-  only doing personal and academic projects you were probably not introduced to
-  testing, it may look like a waste of time at the beginning of a project but
-  you will be thankfull when it will act like a bug-proof shield later on 🛡
-- **#5 Get a mentor and jump into pair programming sessions**. Nothing speeds up
-  our learning than having a mentor. You get to understand each other's ways of
-  thinking, making code reviews easier. Also, being a remote software engineer
-  can become pretty lonely, and this can counterbalance that.
-
-Et voilá! I hope the Inês from the future will look back at this and see how
-much she progressed!
+- **#1 If you don't know, apply for full-stack jobs.** The software development world is a wide place, if you don't know where you fit the best.
+- **#2 Get git rolling.** You will never work alone, so invest a lot of learning time in tools that will make you work efficiently in a team like Git.
+- **#3 Keep a learning journal** As juniors, our learning curve is on skyrocket mode, even tho we deal with computers we don't operate like them, note down your daily challenges and how you overcame them, maybe you will not read it later but it will help you tidy in your mind all the new information.
+- **#4 Get your hands-on testing** I think if, before your 1st job, you were only doing personal and academic projects you were probably not introduced to testing, it may look like a waste of time at the beginning of a project but you will be thankfull when it will act like a bug-proof shield later on 🛡
+- **#5 Get a mentor and jump into pair programming sessions**. Nothing speeds up our learning than having a mentor. You get to understand each other's ways of thinking, making code reviews easier. Also, being a remote software engineer can become pretty lonely, and this can counterbalance that.
+
+Et voilá! I hope the Inês from the future will look back at this and see how much she progressed!
 
 As for my fellow, junior software engineers, I hope this helped you in some way.
 
-Feel free to share your challenges and progress with me. 🙂 Keep learning & stay
-curious!
+Feel free to share your challenges and progress with me. 🙂 Keep learning & stay curious!
diff --git a/src/posts/2022-06-23-the-perfect-hash-function.md b/src/posts/2022-06-23-the-perfect-hash-function.md
index 73a0d95fc5..9d55a0fda8 100644
--- a/src/posts/2022-06-23-the-perfect-hash-function.md
+++ b/src/posts/2022-06-23-the-perfect-hash-function.md
@@ -3,10 +3,7 @@ title: "rust-phf: the perfect hash function"
 authorHandle: tobiasbieniek
 tags: rust
 bio: "Senior Software Engineer"
-description:
-  "Tobias Bieniek made MIME type handling in the crates.io server infinitely
-  faster by using perfect hash functions with the rust-phf crate and moving work
-  from runtime to compile time."
+description: "Tobias Bieniek made MIME type handling in the crates.io server infinitely faster by using perfect hash functions with the rust-phf crate and moving work from runtime to compile time."
 og:
   image: /assets/images/posts/2022-06-23-the-perfect-hash-function/og-image.jpg
 tagline: |
@@ -15,29 +12,18 @@ tagline: |
   generation.</p>
 ---
 
-Let's start at the beginning. [crates.io] is the package registry of the [Rust]
-programming language, or in simpler terms: the place where you can download all
-the dependencies of your apps. The crates.io server itself is also built with
-Rust, and specifically with an HTTP framework called `conduit`.
+Let's start at the beginning. [crates.io] is the package registry of the [Rust] programming language, or in simpler terms: the place where you can download all the dependencies of your apps. The crates.io server itself is also built with Rust, and specifically with an HTTP framework called `conduit`.
 
 [crates.io]: https://crates.io/
 [rust]: https://www.rust-lang.org/
 
-`conduit` has a component called `conduit-static`, which is responsible for
-efficiently serving static files to the users. `conduit-static` is itself
-relying on a package called `conduit-mime-types`, which is the main focus of
-this story. The purpose of this package is to map filename extensions to [MIME
-types] and vice-versa.
+`conduit` has a component called `conduit-static`, which is responsible for efficiently serving static files to the users. `conduit-static` is itself relying on a package called `conduit-mime-types`, which is the main focus of this story. The purpose of this package is to map filename extensions to [MIME types] and vice-versa.
 
-[mime types]:
-  https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types
+[mime types]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types
 
-In other words: if you call `get_mime_type("xls")` the function should return
-`Some("application/vnd.ms-excel")` and if you call
-`get_extension("application/vnd.ms-excel")` it should return `Some("xls")`.
+In other words: if you call `get_mime_type("xls")` the function should return `Some("application/vnd.ms-excel")` and if you call `get_extension("application/vnd.ms-excel")` it should return `Some("xls")`.
 
-The most naive implementation would use a list of filename extension and MIME
-type records:
+The most naive implementation would use a list of filename extension and MIME type records:
 
 ```
 ...
@@ -47,57 +33,29 @@ xps = application/vnd.ms-xpsdocument
 ...
 ```
 
-and it would then search through the list to find a matching filename extension
-or MIME type. While this works fine if you only have few entries in that list,
-it slows down significantly the more records you add to that list.
+and it would then search through the list to find a matching filename extension or MIME type. While this works fine if you only have few entries in that list, it slows down significantly the more records you add to that list.
 
-One way of improving the situation is to use hashmaps. These data structures
-calculate a hash of the thing you pass in, and then efficiently look-up the
-other thing that might be associated with this hash. These hashmaps also become
-slower the more records you put into them, but their performance is still much,
-much better compared to linear lists.
+One way of improving the situation is to use hashmaps. These data structures calculate a hash of the thing you pass in, and then efficiently look-up the other thing that might be associated with this hash. These hashmaps also become slower the more records you put into them, but their performance is still much, much better compared to linear lists.
 
 ## How it started
 
-The original implementation of `conduit-mime-types` was already using two
-hashmaps, one for extension to MIME type mapping, and a second one for MIME type
-to extension mapping. Both of these hashmaps were filled by an `initialize()`
-function, which read a JSON file and then transformed the data into these
-mappings.
+The original implementation of `conduit-mime-types` was already using two hashmaps, one for extension to MIME type mapping, and a second one for MIME type to extension mapping. Both of these hashmaps were filled by an `initialize()` function, which read a JSON file and then transformed the data into these mappings.
 
-While this initialization step wasn't particularly slow, it still took quite a
-few unnecessary milliseconds. In fact, it used to be slow enough that we even
-found a benchmark in the project which measured the initialization speed.
-Needless to say that we got
-[nerd sniped](https://en.wikipedia.org/wiki/Nerd_sniping) by this benchmark to
-improve the initialization speed.
+While this initialization step wasn't particularly slow, it still took quite a few unnecessary milliseconds. In fact, it used to be slow enough that we even found a benchmark in the project which measured the initialization speed. Needless to say that we got [nerd sniped](https://en.wikipedia.org/wiki/Nerd_sniping) by this benchmark to improve the initialization speed.
 
 ## Step 1: Code generation
 
-While JSON can be parsed at
-[blazing speed](https://github.com/simdjson/simdjson) these days, it is still
-slower than not having to parse it at all. Our first step towards a more
-efficient implementation was to get rid of the JSON parsing step.
+While JSON can be parsed at [blazing speed](https://github.com/simdjson/simdjson) these days, it is still slower than not having to parse it at all. Our first step towards a more efficient implementation was to get rid of the JSON parsing step.
 
-How did we get rid of the parsing step? Well, we didn't, but we did move it from
-run time to development time. We wrote a small script that parsed the JSON file
-and generated Rust code based on the content of the JSON file. The only thing
-that was left in the initialization code was transforming the statically bundled
-MIME type data into the hashmap records. This step resulted in a roughly 80%
-performance improvement.
+How did we get rid of the parsing step? Well, we didn't, but we did move it from run time to development time. We wrote a small script that parsed the JSON file and generated Rust code based on the content of the JSON file. The only thing that was left in the initialization code was transforming the statically bundled MIME type data into the hashmap records. This step resulted in a roughly 80% performance improvement.
 
-You can find the corresponding pull request
-[here](https://github.com/conduit-rust/conduit-mime-types/pull/17)
+You can find the corresponding pull request [here](https://github.com/conduit-rust/conduit-mime-types/pull/17)
 
 ## Step 2: Automatic code generation
 
-While this approach was working quite well, it resulted is a small maintenance
-overhead because the code generation script would have to be run each time the
-raw JSON data was edited.
+While this approach was working quite well, it resulted is a small maintenance overhead because the code generation script would have to be run each time the raw JSON data was edited.
 
-One alternative is to automatically generate the code at compile-time. This can
-be achieved by creating a `build.rs` file next to the `Cargo.toml` file of your
-library:
+One alternative is to automatically generate the code at compile-time. This can be achieved by creating a `build.rs` file next to the `Cargo.toml` file of your library:
 
 ```rust
 use std::env;
@@ -112,59 +70,30 @@ fn main() {
 }
 ```
 
-The `main()` function of this file will be executed automatically before your
-library is compiled, and you can use it to generate arbitrary code files that
-the rest of your code can then import, or rather `include!(...)`.
+The `main()` function of this file will be executed automatically before your library is compiled, and you can use it to generate arbitrary code files that the rest of your code can then import, or rather `include!(...)`.
 
-While this admittedly decreased our build speed, it also meant that the raw JSON
-data and the generated code file could no longer diverge and cause subtle bugs.
-In practice the build speed degradation was barely measurable though, since the
-compilation of the code itself already took a significant amount of time.
+While this admittedly decreased our build speed, it also meant that the raw JSON data and the generated code file could no longer diverge and cause subtle bugs. In practice the build speed degradation was barely measurable though, since the compilation of the code itself already took a significant amount of time.
 
 ## Step 3: Perfect hash functions
 
-As we mentioned earlier, we still had an initialization step which transformed
-that raw data in the generated code file to the hashmap records. This was
-necessary because Rust currently does not support `static` hashmaps, which would
-be necessary to have them generated at compile time. Luckily, there are
-alternatives.
+As we mentioned earlier, we still had an initialization step which transformed that raw data in the generated code file to the hashmap records. This was necessary because Rust currently does not support `static` hashmaps, which would be necessary to have them generated at compile time. Luckily, there are alternatives.
 
-While looking for a solution to the problem we stumbled upon the [rust-phf]
-crate, which has the tagline: "Compile time static maps for Rust". Exactly what
-we needed!
+While looking for a solution to the problem we stumbled upon the [rust-phf] crate, which has the tagline: "Compile time static maps for Rust". Exactly what we needed!
 
 [rust-phf]: https://github.com/rust-phf/rust-phf
 
-It was relatively straight-forward to modify our `build.rs` file and take
-advantage of the `phf_codegen` crate to generate the necessary two maps at
-compile time for us. The resulting maps have an API that is roughly similar to
-the regular hashmaps in Rust, but all we really needed was the `.get()` method
-anyway.
+It was relatively straight-forward to modify our `build.rs` file and take advantage of the `phf_codegen` crate to generate the necessary two maps at compile time for us. The resulting maps have an API that is roughly similar to the regular hashmaps in Rust, but all we really needed was the `.get()` method anyway.
 
-We now had gotten rid of all the content of the initialization step, reducing
-the time to run that step to essentially zero. Through some clever math we
-determined that by removing the step we had made it infinitely faster, and we
-could now get rid of the corresponding benchmark too.
+We now had gotten rid of all the content of the initialization step, reducing the time to run that step to essentially zero. Through some clever math we determined that by removing the step we had made it infinitely faster, and we could now get rid of the corresponding benchmark too.
 
-Not only that, we also improved the lookup speed. `rust-phf` is using "perfect
-hash functions", as the name suggests. This means that it generates hash maps
-that don't have any collisions, which makes the lookup code much more efficient.
-The downside of these maps is that they have to recalculate the whole map if you
-insert any records, but since we were dealing with read-only data this downside
-was irrelevant to us.
+Not only that, we also improved the lookup speed. `rust-phf` is using "perfect hash functions", as the name suggests. This means that it generates hash maps that don't have any collisions, which makes the lookup code much more efficient. The downside of these maps is that they have to recalculate the whole map if you insert any records, but since we were dealing with read-only data this downside was irrelevant to us.
 
-You can take a look at the pull request that introduced `rust-phf` in
-`conduit-mime-types`
-[here](https://github.com/conduit-rust/conduit-mime-types/pull/18).
+You can take a look at the pull request that introduced `rust-phf` in `conduit-mime-types` [here](https://github.com/conduit-rust/conduit-mime-types/pull/18).
 
 ## Conclusion
 
-If you have read-only mappings that you want to use in your Rust code, then the
-`rust-phf` project can give you significant speed improvements by moving some of
-the work to compile time.
+If you have read-only mappings that you want to use in your Rust code, then the `rust-phf` project can give you significant speed improvements by moving some of the work to compile time.
 
-We hope that this short story about our work on `conduit-mime-types` was helpful
-to you. If you have any questions do not hesitate to [contact] us. We're happy
-to help!
+We hope that this short story about our work on `conduit-mime-types` was helpful to you. If you have any questions do not hesitate to [contact] us. We're happy to help!
 
 [contact]: /contact/
diff --git a/src/posts/2022-08-09-scaling-tech-teams.md b/src/posts/2022-08-09-scaling-tech-teams.md
index 2244e01b90..b0bb4fb249 100644
--- a/src/posts/2022-08-09-scaling-tech-teams.md
+++ b/src/posts/2022-08-09-scaling-tech-teams.md
@@ -3,9 +3,7 @@ title: "Scaling Tech Teams"
 authorHandle: marcoow
 tags: process
 bio: "Founder and Managing Director of Mainmatter"
-description:
-  "Marco Otte-Witte shares learnings around growing tech teams and how to avoid
-  typical mistakes."
+description: "Marco Otte-Witte shares learnings around growing tech teams and how to avoid typical mistakes."
 og:
   image: /assets/images/posts/2022-08-09-scaling-tech-teams/og-image.jpg
 tagline: |
@@ -22,222 +20,61 @@ tagline: |
 
 ## Mentoring and Growth
 
-While many teams start out with a small number of experienced experts, growth
-beyond a certain threshold requires opening up to less experienced people as
-well. And with the changing composition of a team also come changing needs –
-less experienced engineers won't be able to contribute to the codebase to the
-same extent that more senior people would. They need additional guidance and
-mentoring and will get frustrated and burned out without it. At the same time,
-given support, they will more often than not excel and become senior engineers
-themselves. That said, a common mistake we see many teams make is to just add
-beginners to their teams without putting any real thought into what kind of
-guidance they will need, only to be surprised a few months later when the people
-leave again. That's not only a bad experience for the less experienced engineer
-who probably was eager to learn and motivated when they started but also a
-missed opportunity for the company that could have added a valuable member to
-their team.
-
-Ines from the Mainmatter team wrote about
-[her journey as a beginner engineer](/blog/2022/05/19/journey-of-a-junior-software-engineer/)
-– it's a great post I recommend beginners as well as experienced engineers read.
-One of Inês' main points is:
-
-> If you land in a new job where nobody is showing availability to help you
-> out - you are in the wrong place.
-
-Supporting less experienced engineers in making impactful contributions to
-codebase can (and should) happen in many ways. First, remove any accidental
-complexity from the process and infrastructure that would impose an extra wall
-to climb over for any engineer at the beginning of their career. For example,
-while experienced engineers might be able to set up a bunch of dependant
-services and run a variety of micro-services directly on their machine, that
-might be a blocker for a beginner – containerizing the complete development
-environment before introducing beginners to the team can likely prevent a lot of
-frustration and wasted time and is beneficial to the rest of the team as well.
-
-Preparing work thoroughly can go a long way in supporting less experienced
-engineers as well. Instead of assigning underspecified tasks where lots is still
-left to be figured out, analyze the status quo and plan what steps need to be
-taken to get to the desired goal before starting to write code. That way,
-beginners have a trail to follow and blockers or uncertainties can be uncovered
-and resolved before they hit a wall mid-way through their work. For more
-guidance on efficient preparation of work, check our [playbook](/playbook) as
-well.
+While many teams start out with a small number of experienced experts, growth beyond a certain threshold requires opening up to less experienced people as well. And with the changing composition of a team also come changing needs – less experienced engineers won't be able to contribute to the codebase to the same extent that more senior people would. They need additional guidance and mentoring and will get frustrated and burned out without it. At the same time, given support, they will more often than not excel and become senior engineers themselves. That said, a common mistake we see many teams make is to just add beginners to their teams without putting any real thought into what kind of guidance they will need, only to be surprised a few months later when the people leave again. That's not only a bad experience for the less experienced engineer who probably was eager to learn and motivated when they started but also a missed opportunity for the company that could have added a valuable member to their team.
+
+Ines from the Mainmatter team wrote about [her journey as a beginner engineer](/blog/2022/05/19/journey-of-a-junior-software-engineer/) – it's a great post I recommend beginners as well as experienced engineers read. One of Inês' main points is:
+
+> If you land in a new job where nobody is showing availability to help you out - you are in the wrong place.
+
+Supporting less experienced engineers in making impactful contributions to codebase can (and should) happen in many ways. First, remove any accidental complexity from the process and infrastructure that would impose an extra wall to climb over for any engineer at the beginning of their career. For example, while experienced engineers might be able to set up a bunch of dependant services and run a variety of micro-services directly on their machine, that might be a blocker for a beginner – containerizing the complete development environment before introducing beginners to the team can likely prevent a lot of frustration and wasted time and is beneficial to the rest of the team as well.
+
+Preparing work thoroughly can go a long way in supporting less experienced engineers as well. Instead of assigning underspecified tasks where lots is still left to be figured out, analyze the status quo and plan what steps need to be taken to get to the desired goal before starting to write code. That way, beginners have a trail to follow and blockers or uncertainties can be uncovered and resolved before they hit a wall mid-way through their work. For more guidance on efficient preparation of work, check our [playbook](/playbook) as well.
 
 ![A well prepared issue provides beginners with a
 trail to follow](/assets/images/posts/2022-08-09-scaling-tech-teams/issue.svg#plain)
 
-Analyzing and preparing work is also a nice exercise for a beginner and an
-experienced engineer to do together. Generally, closely collaborating with and
-observing more experienced people is a great way to learn – whether it's pair
-programming or working on other tasks like figuring out what needs to be done
-for a particular issue. Additionally, there are other ways of teaching of course
-like giving deep explanations for why a particular change might be brought up
-during a code review or running workshops on particular topics that people are
-struggling with. We have worked with a number of fast-growing teams over the
-years and seen many beginners excel and turn into experienced senior engineers
-given the right support over the years – find out about our
-[Team reinforcement](/services/team-reinforcement/) offering to learn more.
+Analyzing and preparing work is also a nice exercise for a beginner and an experienced engineer to do together. Generally, closely collaborating with and observing more experienced people is a great way to learn – whether it's pair programming or working on other tasks like figuring out what needs to be done for a particular issue. Additionally, there are other ways of teaching of course like giving deep explanations for why a particular change might be brought up during a code review or running workshops on particular topics that people are struggling with. We have worked with a number of fast-growing teams over the years and seen many beginners excel and turn into experienced senior engineers given the right support over the years – find out about our [Team reinforcement](/services/team-reinforcement/) offering to learn more.
 
 ## Code Health and Tech Debt
 
-The negative impacts of low code health and technical debt are widely understood
-in our industry by now. When it comes to scaling teams though, the topic becomes
-even more relevant – whether bad code affects the productivity of a team of 5 or
-a team of 50 just makes a huge difference. The bigger a team gets, the higher
-the price tag is on unaddressed tech debt, in particular with more beginners on
-a team that might not be as comfortable working around it. Accepting tech debt
-as an impediment not only to the productivity but to the scalability of a team
-as such is crucial (one of our client calls this Scaling work instead of tech
-debt). **Plan time for working on code health and prioritize it together with
-feature work – it will have equal relevance for the sustainability of your
-product**!
+The negative impacts of low code health and technical debt are widely understood in our industry by now. When it comes to scaling teams though, the topic becomes even more relevant – whether bad code affects the productivity of a team of 5 or a team of 50 just makes a huge difference. The bigger a team gets, the higher the price tag is on unaddressed tech debt, in particular with more beginners on a team that might not be as comfortable working around it. Accepting tech debt as an impediment not only to the productivity but to the scalability of a team as such is crucial (one of our client calls this Scaling work instead of tech debt). **Plan time for working on code health and prioritize it together with feature work – it will have equal relevance for the sustainability of your product**!
 
 ## Developer Infrastructure
 
-Related to tech debt is developer infrastructure – the bigger a team gets, the
-bigger the negative impact of subpar infrastructure is going to be. A flaky test
-server, slow deployment processes or unavailable tools will slow down or in the
-worst case block a large and growing number of people. For the same reason,
-there's also no room for any manual elements in the infrastructure or processes
-– manual QA or deployment for example will quickly turn into bottlenecks and
-impede the productivity of the entire team. Instead, in order to let teams focus
-on their work and enable them to ship constantly, **double down on highly
-integrated and automated pipelines – all time invested on these will pay off
-manyfold later on**. I wrote more about the elements of such infrastructure in
-an
-[earlier post](/blog/2021/07/13/effective-infrastructure-for-efficient-development-workflows/).
+Related to tech debt is developer infrastructure – the bigger a team gets, the bigger the negative impact of subpar infrastructure is going to be. A flaky test server, slow deployment processes or unavailable tools will slow down or in the worst case block a large and growing number of people. For the same reason, there's also no room for any manual elements in the infrastructure or processes – manual QA or deployment for example will quickly turn into bottlenecks and impede the productivity of the entire team. Instead, in order to let teams focus on their work and enable them to ship constantly, **double down on highly integrated and automated pipelines – all time invested on these will pay off manyfold later on**. I wrote more about the elements of such infrastructure in an [earlier post](/blog/2021/07/13/effective-infrastructure-for-efficient-development-workflows/).
 
 ### Invest in Developer Enablement
 
-Once past a certain size, it often even makes sense to task a smaller number of
-engineers exclusively with making everyone else more productive. That team would
-focus on building, maintaining, and optimizing the internal developer platform
-that all of the other engineers base their work on (a team like that would often
-be referred to as a
-[Platform Engineering](https://platformengineering.org/blog/what-is-platform-engineering)
-or Platform Development team). Since this kind of work has increasing leverage
-with a growing number of total people on the team, the cost-benefit analysis is
-often obvious and makes a decision for such a team trivial. A Platform
-Engineering team can e.g. build abstractions to make working with particular
-aspects of the codebase easier, automate checks for particular patterns to avoid
-rework, optimize tooling to shorten compile or testing times. While all of these
-things might only result in relatively small productivity improvements per
-individual engineer, as these changes affect every single engineer on the team,
-they have a big impact overall.
+Once past a certain size, it often even makes sense to task a smaller number of engineers exclusively with making everyone else more productive. That team would focus on building, maintaining, and optimizing the internal developer platform that all of the other engineers base their work on (a team like that would often be referred to as a [Platform Engineering](https://platformengineering.org/blog/what-is-platform-engineering) or Platform Development team). Since this kind of work has increasing leverage with a growing number of total people on the team, the cost-benefit analysis is often obvious and makes a decision for such a team trivial. A Platform Engineering team can e.g. build abstractions to make working with particular aspects of the codebase easier, automate checks for particular patterns to avoid rework, optimize tooling to shorten compile or testing times. While all of these things might only result in relatively small productivity improvements per individual engineer, as these changes affect every single engineer on the team, they have a big impact overall.
 
 ## The Limits of Scope
 
-While a small team of engineers might be able collaborate on a single codebase
-efficiently, that becomes ever harder the bigger the team and the codebase with
-it grows. At a certain point, nobody will be able to capture the system in its
-entirety anymore which will lead to inconsistency and thus inefficiency – people
-will solve the same problem over and over as they're not aware of existing
-solutions that might be reusable, different parts of the codebase might actually
-be conflicting with each other, etc.
-
-The only option there is to address this problem is often to split things up
-into smaller chunks – decomposing the large system and the team that maintains
-it into smaller subsystems that are each maintained by their own teams (kind of
-[Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law) but in reverse).
-Each of these subsystems will be limited to a reduced scope which enables teams
-to actually be on top of all of that. Also subsystems only need to be consistent
-within themselves and there is new freedom for teams to make different
-technology choices for their subsystems which can also be a great driver for
-motivation.
-
-Where the boundaries between the individual subsystems are of course depends on
-the respective project. There are also many ways of splitting up a big system
-into subsystems – from keeping a central codebase but enforcing boundaries
-between subsystems via architecture and tooling, to splitting into completely
-separate products or going the micro-service/frontends route. There's no one
-strategy that will work in all cases as different approaches will have pros and
-cons in different situations. The one rule to keep in mind is that the less
-interaction and fewer dependencies there are between the subsystems, the easier
-things are going to be.
-
-Splitting systems into subsystems comes at a substantial cost though and should
-generally not be something that's decided for lightly. While limiting
-cross-dependencies between subsystems and the teams managing them is a good
-goal, it's rarely possible in reality to completely achieve. So while many
-things get easier after the split, some things also get significantly harder
-(e.g. code reuse across subsystems or synchronization between the teams
-maintaining different subsystems). One mistake I've seen a few times over the
-years is making this split too early or even building systems like this from the
-beginning. Teams doing that end up paying a high cost for virtually no benefit
-as they are not yet feeling the pain that this kind of architecture would solve.
-**Decompose systems when you feel real pain but not before**.
+While a small team of engineers might be able collaborate on a single codebase efficiently, that becomes ever harder the bigger the team and the codebase with it grows. At a certain point, nobody will be able to capture the system in its entirety anymore which will lead to inconsistency and thus inefficiency – people will solve the same problem over and over as they're not aware of existing solutions that might be reusable, different parts of the codebase might actually be conflicting with each other, etc.
+
+The only option there is to address this problem is often to split things up into smaller chunks – decomposing the large system and the team that maintains it into smaller subsystems that are each maintained by their own teams (kind of [Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law) but in reverse). Each of these subsystems will be limited to a reduced scope which enables teams to actually be on top of all of that. Also subsystems only need to be consistent within themselves and there is new freedom for teams to make different technology choices for their subsystems which can also be a great driver for motivation.
+
+Where the boundaries between the individual subsystems are of course depends on the respective project. There are also many ways of splitting up a big system into subsystems – from keeping a central codebase but enforcing boundaries between subsystems via architecture and tooling, to splitting into completely separate products or going the micro-service/frontends route. There's no one strategy that will work in all cases as different approaches will have pros and cons in different situations. The one rule to keep in mind is that the less interaction and fewer dependencies there are between the subsystems, the easier things are going to be.
+
+Splitting systems into subsystems comes at a substantial cost though and should generally not be something that's decided for lightly. While limiting cross-dependencies between subsystems and the teams managing them is a good goal, it's rarely possible in reality to completely achieve. So while many things get easier after the split, some things also get significantly harder (e.g. code reuse across subsystems or synchronization between the teams maintaining different subsystems). One mistake I've seen a few times over the years is making this split too early or even building systems like this from the beginning. Teams doing that end up paying a high cost for virtually no benefit as they are not yet feeling the pain that this kind of architecture would solve. **Decompose systems when you feel real pain but not before**.
 
 ## Process
 
-Another critical requirement for being able to scale tech teams is establishing
-a process that enables that. The main aspect of such a process is early and
-close collaboration between stakeholders. While classic agile processes are
-often driven exclusively by product needs, they result in a lot of inefficiency
-when engineering figures out how to make a plan set by product a reality. Often,
-there would have been easier and more efficient alternatives to reach the same
-or an equal goal. The larger a team becomes, the more expensive the consequences
-of these inefficiencies are.
+Another critical requirement for being able to scale tech teams is establishing a process that enables that. The main aspect of such a process is early and close collaboration between stakeholders. While classic agile processes are often driven exclusively by product needs, they result in a lot of inefficiency when engineering figures out how to make a plan set by product a reality. Often, there would have been easier and more efficient alternatives to reach the same or an equal goal. The larger a team becomes, the more expensive the consequences of these inefficiencies are.
 
 ![Source and shape work collaborating with all stakeholders from the get-to](/assets/images/posts/2022-08-09-scaling-tech-teams/work-sourcing.svg#plain)
 
-So instead of a linear process where product sets a plan based purely on their
-perspective that engineering then tries to convert into code, the two work
-together from the beginning. Based on the high level product strategy, they work
-out the most efficient way to reach a goal, considering both the user needs as
-well as technical complexities and feasibility. That way, the team reaches goals
-more efficiently instead spending valuable time working against each other or
-trying to realize plans that were flawed from the get-go.
+So instead of a linear process where product sets a plan based purely on their perspective that engineering then tries to convert into code, the two work together from the beginning. Based on the high level product strategy, they work out the most efficient way to reach a goal, considering both the user needs as well as technical complexities and feasibility. That way, the team reaches goals more efficiently instead spending valuable time working against each other or trying to realize plans that were flawed from the get-go.
 
 ## Remotely international
 
-Everyone knows that remote work is here to stay, in the tech industry at least.
-Even though the pandemic situation would allow for it in many places, only few
-teams go back to working from the office full-time. When it comes to scaling
-tech teams, hiring remotely is often a prerequisite to even finding people to
-hire and thus being able to scale at all. Even if a team is located in one of
-the hotspots where there are lots of developers in the place in theory, demand
-is likely high as well so that hiring locally would be no feasible option. So in
-the end, everyone ends up hiring people remotely which usually also means
-internationally.
-
-While I have written about making
-[remote work work](/blog/2020/11/16/the-guide-to-making-remote-work-work/)
-before, there are two points to consider in particular when starting to
-internationalize the team. As obvious as it might be, the first point is still
-something teams forget and pay a high price for later: everything you do you
-need to do in English. Hiring internationally means people will not speak the
-local language and everyone will end up doing everything in English. If that
-fact hasn't been taken into account from the get-go and there's essential
-material (documentation, users stories, issues, etc.) that are only available in
-german or french or whatever, all of these materials are inaccessible to people
-that don't understand those languages and will have to be translated or
-recreated eventually. **Keeping everything in English from the beginning is easy
-to forget but absolutely essential to be able to internationalize a team later
-on**.
-
-The second point when it comes to scaling internationally is timezones. While
-it's not important that everyone is around during the exact same times (after
-all, people would start and end work at different times in an office as well),
-it does make a difference whether there's a few hours of overlap or none at all.
-While both setups can work and there are a lot of companies that have teams
-distributed between the US West Coast and Asia where there's virtually no
-overlap ever in people's working hours, it definitely is easier if there's at
-least a few hours of overlap. So based on our experience at Mainmatter, I'd say
-**if you can, try and limit your team to be across 3-4 timezones max** – that
-not only makes communication easier but it also means people will still be
-relatively close together which makes it easier (and more environmentally
-friendly) to bring everyone together every once in a while to keep up team
-spirit.
+Everyone knows that remote work is here to stay, in the tech industry at least. Even though the pandemic situation would allow for it in many places, only few teams go back to working from the office full-time. When it comes to scaling tech teams, hiring remotely is often a prerequisite to even finding people to hire and thus being able to scale at all. Even if a team is located in one of the hotspots where there are lots of developers in the place in theory, demand is likely high as well so that hiring locally would be no feasible option. So in the end, everyone ends up hiring people remotely which usually also means internationally.
+
+While I have written about making [remote work work](/blog/2020/11/16/the-guide-to-making-remote-work-work/) before, there are two points to consider in particular when starting to internationalize the team. As obvious as it might be, the first point is still something teams forget and pay a high price for later: everything you do you need to do in English. Hiring internationally means people will not speak the local language and everyone will end up doing everything in English. If that fact hasn't been taken into account from the get-go and there's essential material (documentation, users stories, issues, etc.) that are only available in german or french or whatever, all of these materials are inaccessible to people that don't understand those languages and will have to be translated or recreated eventually. **Keeping everything in English from the beginning is easy to forget but absolutely essential to be able to internationalize a team later on**.
+
+The second point when it comes to scaling internationally is timezones. While it's not important that everyone is around during the exact same times (after all, people would start and end work at different times in an office as well), it does make a difference whether there's a few hours of overlap or none at all. While both setups can work and there are a lot of companies that have teams distributed between the US West Coast and Asia where there's virtually no overlap ever in people's working hours, it definitely is easier if there's at least a few hours of overlap. So based on our experience at Mainmatter, I'd say **if you can, try and limit your team to be across 3-4 timezones max** – that not only makes communication easier but it also means people will still be relatively close together which makes it easier (and more environmentally friendly) to bring everyone together every once in a while to keep up team spirit.
 
 ## You're not alone
 
-After all, scaling tech teams is a human effort as well and like all efforts
-that involve a group of people, can and will be challenging. However, keeping a
-few things in mind and ensuring a solid foundation that support the scalability
-of a team is helpful.
+After all, scaling tech teams is a human effort as well and like all efforts that involve a group of people, can and will be challenging. However, keeping a few things in mind and ensuring a solid foundation that support the scalability of a team is helpful.
 
-If you're experiencing growing pains you'd like to get some help with, please
-contact us and we'd be happy to chat. We've worked with a number of growing
-teams and companies over the years including Qonto, Trainline, and Sage and are
-happy to share our learnings!
+If you're experiencing growing pains you'd like to get some help with, please contact us and we'd be happy to chat. We've worked with a number of growing teams and companies over the years including Qonto, Trainline, and Sage and are happy to share our learnings!
diff --git a/src/posts/2022-08-24-cookbook-ember-app-to-css-modules.md b/src/posts/2022-08-24-cookbook-ember-app-to-css-modules.md
index 1f95ce7b7e..2b66dbac8f 100644
--- a/src/posts/2022-08-24-cookbook-ember-app-to-css-modules.md
+++ b/src/posts/2022-08-24-cookbook-ember-app-to-css-modules.md
@@ -3,10 +3,7 @@ title: "Cookbook: migrate an existing Ember app to CSS modules"
 authorHandle: academierenards
 tags: open-source
 bio: "Senior software engineer"
-description:
-  "Tutorial to start with ember-css-modules in an existing Ember app. It aims at
-  discovering ember-css-module from a practical perspective to get a different
-  view on the doc."
+description: "Tutorial to start with ember-css-modules in an existing Ember app. It aims at discovering ember-css-module from a practical perspective to get a different view on the doc."
 og:
   image: /assets/images/posts/2022-08-24-cookbook-ember-app-to-css-modules/og-image.jpg
 tagline: |
@@ -21,98 +18,59 @@ tagline: |
 This article is exactly what you are looking for if:
 
 - You are already comfortable with Ember.
-- You know a bit of theory about what CSS modules are but you have never worked
-  with them before.
-- It is the first time you set up
-  [`ember-css-modules`](https://github.com/salsify/ember-css-modules) in an
-  existing Ember app that already contains a global CSS setup.
+- You know a bit of theory about what CSS modules are but you have never worked with them before.
+- It is the first time you set up [`ember-css-modules`](https://github.com/salsify/ember-css-modules) in an existing Ember app that already contains a global CSS setup.
 
 This article might get your interest if:
 
 - You don't know a thing about CSS modules.
-- After we've solved the previous point, you want to discover how CSS modules
-  can be used in an Ember context.
+- After we've solved the previous point, you want to discover how CSS modules can be used in an Ember context.
 
 ### A word about CSS modules
 
-To style an application with CSS, the minimum you need is one CSS file included
-on the page. Even when split into different files, having one CSS scope that
-applies globally on the whole page has some downsides in big and complex
-applications. For instance, managing the styles of reusable components is
-sometimes challenging. Also, the life of an application is made of turnover,
-it's never easy for newcomers to identify dead code, resulting in overly heavy
-and hard-to-clean CSS rules.
+To style an application with CSS, the minimum you need is one CSS file included on the page. Even when split into different files, having one CSS scope that applies globally on the whole page has some downsides in big and complex applications. For instance, managing the styles of reusable components is sometimes challenging. Also, the life of an application is made of turnover, it's never easy for newcomers to identify dead code, resulting in overly heavy and hard-to-clean CSS rules.
 
-CSS modules aim to overcome these challenges as a technique to scope CSS classes
-locally, for instance to individual components. To read more about the general
-concept, have a look at the
-[documentation on Github](https://github.com/css-modules/css-modules).
+CSS modules aim to overcome these challenges as a technique to scope CSS classes locally, for instance to individual components. To read more about the general concept, have a look at the [documentation on Github](https://github.com/css-modules/css-modules).
 
 ### A word about `ember-css-modules`
 
-[`ember-css-modules`](https://github.com/salsify/ember-css-modules) is a nice
-addon that lets developers easily integrate the CSS modules approach to the
-implementation of their Ember apps and addons.
+[`ember-css-modules`](https://github.com/salsify/ember-css-modules) is a nice addon that lets developers easily integrate the CSS modules approach to the implementation of their Ember apps and addons.
 
-Installing `ember-css-modules` in an existing Ember app triggers some breaking
-changes in the way the developer should handle the app styles. If the developer
-is not familiar with CSS modules in the first place, they might have a hard time
-figuring out how to set up and start the migration at their own pace. The
-present tutorial is intended to be used as a quick start cookbook to achieve
-this.
+Installing `ember-css-modules` in an existing Ember app triggers some breaking changes in the way the developer should handle the app styles. If the developer is not familiar with CSS modules in the first place, they might have a hard time figuring out how to set up and start the migration at their own pace. The present tutorial is intended to be used as a quick start cookbook to achieve this.
 
 ### A word about `less` and `sass`
 
-The usage of [less](https://lesscss.org/) and
-[sass](https://sass-lang.com/guide) will not be mentioned in this tutorial,
-though they are
-[compatible with `ember-css-modules`](https://github.com/salsify/ember-css-modules/blob/master/docs/PREPROCESSORS.md).
+The usage of [less](https://lesscss.org/) and [sass](https://sass-lang.com/guide) will not be mentioned in this tutorial, though they are [compatible with `ember-css-modules`](https://github.com/salsify/ember-css-modules/blob/master/docs/PREPROCESSORS.md).
 
 ## Migration tutorial
 
-Let's start working. We'll take the
-[SuperRentals app](https://guides.emberjs.com/release/tutorial/part-1/) as an
-example. SuperRentals is the great tutorial part of the Ember guides to
-introduce the main Ember features. As the purpose of the SuperRentals app is to
-teach Ember and writing CSS is irrelevant to the matter, the CSS to style the
-app is provided as a single `app.css` free to download (linked somewhere in the
-first pages of Part 1), so newcomers don't have to write it themselves as they
-walk through the tutorial.
+Let's start working. We'll take the [SuperRentals app](https://guides.emberjs.com/release/tutorial/part-1/) as an example. SuperRentals is the great tutorial part of the Ember guides to introduce the main Ember features. As the purpose of the SuperRentals app is to teach Ember and writing CSS is irrelevant to the matter, the CSS to style the app is provided as a single `app.css` free to download (linked somewhere in the first pages of Part 1), so newcomers don't have to write it themselves as they walk through the tutorial.
 
 So let's make the SuperRentals app ready for migration to CSS modules.
 
 ### Install `ember-css-modules` (and break your app)
 
-Let's suppose we have finished implementing the SuperRentals app. The following
-screenshot shows the page as it should be in your browser, with the nice styling
-provided in the tutorial:
+Let's suppose we have finished implementing the SuperRentals app. The following screenshot shows the page as it should be in your browser, with the nice styling provided in the tutorial:
 
 ![SuperRentals with global CSS](/assets/images/posts/2022-08-24-cookbook-ember-app-to-css-modules/screen-1.png)
 
-To use CSS modules, let's install
-[`ember-css-modules`](https://github.com/salsify/ember-css-modules):
+To use CSS modules, let's install [`ember-css-modules`](https://github.com/salsify/ember-css-modules):
 
 ```
 ember install ember-css-modules
 ```
 
-The addon does not contain any blueprints, the installation command simply adds
-the dependency to `package.json` and modifies the lock file.
+The addon does not contain any blueprints, the installation command simply adds the dependency to `package.json` and modifies the lock file.
 
 Let's run the local server again and see how our app is doing:
 
 ![SuperRentals styles are broken](/assets/images/posts/2022-08-24-cookbook-ember-app-to-css-modules/screen-2.png)
 
-Ouch, all the styles are broken. What we see now in the browser is very similar
-to a page with no CSS at all. To understand what is going on let's use the
-inspector tab of the browser's debugger.
+Ouch, all the styles are broken. What we see now in the browser is very similar to a page with no CSS at all. To understand what is going on let's use the inspector tab of the browser's debugger.
 
 ### Understanding CSS classes isolation
 
-If we compare the previously styled app and the version we have now, we notice
-that Tomster (the Ember hamster mascot) is missing at the top right of the
-screen. Let's find the element that should display Tomster in the DOM. The image
-shows using the following approach:
+If we compare the previously styled app and the version we have now, we notice that Tomster (the Ember hamster mascot) is missing at the top right of the screen. Let's find the element that should display Tomster in the DOM. The image shows using the following approach:
 
 ```html
 <!-- app/components/jumbos.hbs -->
@@ -143,19 +101,9 @@ Now, let's have a look at the CSS applied on the `<div>` element:
 
 ![Tomster div highlighted in the DOM](/assets/images/posts/2022-08-24-cookbook-ember-app-to-css-modules/screen-3.png)
 
-Only two CSS rules apply on the Tomster `<div>`. The first one is a global rule
-to reset margins. The second one defines the font family and line height set on
-elements such as `body`, `h` titles, `p`, `div`, etc... The CSS classes
-responsible for showing Tomster are `.right` and `.tomster`, but the rules
-corresponding to these classes are no longer there! that's why the Tomster image
-is no longer visible on screen.
+Only two CSS rules apply on the Tomster `<div>`. The first one is a global rule to reset margins. The second one defines the font family and line height set on elements such as `body`, `h` titles, `p`, `div`, etc... The CSS classes responsible for showing Tomster are `.right` and `.tomster`, but the rules corresponding to these classes are no longer there! that's why the Tomster image is no longer visible on screen.
 
-In the section of the inspector dedicated to CSS description, when a style
-applies to the selected element, we can see the name of the CSS file this style
-comes from. On the screenshot above, it comes from `super-rental-typescript`,
-which is the name of this demo application (the final "s" on "rentals" was
-forgotten ^^' and it was first implemented as a migration test to TypeScript).
-The file name is clickable and lets you see the content of the whole CSS file.
+In the section of the inspector dedicated to CSS description, when a style applies to the selected element, we can see the name of the CSS file this style comes from. On the screenshot above, it comes from `super-rental-typescript`, which is the name of this demo application (the final "s" on "rentals" was forgotten ^^' and it was first implemented as a migration test to TypeScript). The file name is clickable and lets you see the content of the whole CSS file.
 
 At the top of the file, we read:
 
@@ -202,23 +150,13 @@ At the bottom of the file, we read:
 }
 ```
 
-And here is the explanation about our missing Tomster. With `ember-css-modules`
-installed, all the class selectors present in `app.css` end with a custom id.
-However, this custom id is not present in our component's template: we still
-have `class="right tomster"`. As a result, no CSS class is found for `.right`
-and `.tomster` and no style applies. On the contrary, the rules defined for main
-elements like `div` match by the element itself and thus keep applying.
+And here is the explanation about our missing Tomster. With `ember-css-modules` installed, all the class selectors present in `app.css` end with a custom id. However, this custom id is not present in our component's template: we still have `class="right tomster"`. As a result, no CSS class is found for `.right` and `.tomster` and no style applies. On the contrary, the rules defined for main elements like `div` match by the element itself and thus keep applying.
 
-`ember-css-modules` relies on class selectors to isolate the CSS and prevent it
-from applying globally. The isolation system applies to every CSS file,
-including those located in the main `styles` folder rather than alongside a
-component.
+`ember-css-modules` relies on class selectors to isolate the CSS and prevent it from applying globally. The isolation system applies to every CSS file, including those located in the main `styles` folder rather than alongside a component.
 
 ### Fix the setup with `:global`
 
-Before starting to actively use CSS modules across the app, we should fix the
-styles and allow `app.css` to apply globally as it did before. To do so, we can
-use the `:global` pseudoselector:
+Before starting to actively use CSS modules across the app, we should fix the styles and allow `app.css` to apply globally as it did before. To do so, we can use the `:global` pseudoselector:
 
 ```css
 /* app/styles/app.css */
@@ -243,27 +181,13 @@ And let's see what happens in the browser:
 
 ![Tomster shows again](/assets/images/posts/2022-08-24-cookbook-ember-app-to-css-modules/screen-4.png)
 
-Tomster is back! If we take a new look at the generated CSS file in the
-browser's inspector, we can see this time the classes `.right` and `.tomster`
-don't have custom ids. The `:global` pseudoselector indicates these classes are
-global classes that should apply to the whole page. So we are back to classic
-CSS, with rules defined in `app.css` which apply to the page elements through
-`class` attributes. By using the `:global` pseudoselector on the whole existing
-CSS, we can style the whole app exactly as it was before installing
-`ember-css-modules`, and from there we can serenely start to use some CSS
-modules.
+Tomster is back! If we take a new look at the generated CSS file in the browser's inspector, we can see this time the classes `.right` and `.tomster` don't have custom ids. The `:global` pseudoselector indicates these classes are global classes that should apply to the whole page. So we are back to classic CSS, with rules defined in `app.css` which apply to the page elements through `class` attributes. By using the `:global` pseudoselector on the whole existing CSS, we can style the whole app exactly as it was before installing `ember-css-modules`, and from there we can serenely start to use some CSS modules.
 
 ### Start using CSS modules
 
-In the SuperRentals app, the Tomster `<div>` element is written in the `<Jumbo>`
-component's template (this component is instantiated at the top of each page).
-So let's create the CSS file alongside the template. In the present example, the
-file is `app/components/jumbo.css` as the app has a classic structure with
-co-location.
+In the SuperRentals app, the Tomster `<div>` element is written in the `<Jumbo>` component's template (this component is instantiated at the top of each page). So let's create the CSS file alongside the template. In the present example, the file is `app/components/jumbo.css` as the app has a classic structure with co-location.
 
-It would probably make sense if the `.right` class remains a global class that
-can be assigned to different elements of the page. But let's make the `.tomster`
-class local:
+It would probably make sense if the `.right` class remains a global class that can be assigned to different elements of the page. But let's make the `.tomster` class local:
 
 ```css
 /* app/styles/app.css */
@@ -298,27 +222,12 @@ Everything should show as before:
 
 ![Tomster still shows as expected](/assets/images/posts/2022-08-24-cookbook-ember-app-to-css-modules/screen-5.png)
 
-If we look one more time at the CSS classes in the inspector, we'll see that
-class `.right` is still applied globally, but `.tomster` selector now owns a
-custom id used to isolate the CSS. The syntax
-`<div class="right" local-class="tomster"></div>` we used in the template
-resulted in `<div class="right _tomster_1myv6d"></div>` in the browser so the
-class attributes and the generated CSS rules match.
+If we look one more time at the CSS classes in the inspector, we'll see that class `.right` is still applied globally, but `.tomster` selector now owns a custom id used to isolate the CSS. The syntax `<div class="right" local-class="tomster"></div>` we used in the template resulted in `<div class="right _tomster_1myv6d"></div>` in the browser so the class attributes and the generated CSS rules match.
 
 ## Conclusion
 
-We have drawn the big picture about how `ember-css-modules` isolates CSS. The
-way custom ids are assigned to selectors in a given CSS file is key to
-understanding and starting to work with `ember-css-modules`. With this in mind,
-it is up to you to continue digging and deduce the best way to organize CSS in
-your specific project.
-
-As a next step, why don't you have a look at the
-[composition feature](https://github.com/salsify/ember-css-modules#styling-reuse)?
-At first glance and without reading the docs carefully enough, it might look
-like "importing a CSS rule content", but that's not it. It is rather about
-adding to an element with a `local-class` an additional `local-class` coming
-from another file. So by using `composes` once, many different rules can
-suddenly apply to the element.
+We have drawn the big picture about how `ember-css-modules` isolates CSS. The way custom ids are assigned to selectors in a given CSS file is key to understanding and starting to work with `ember-css-modules`. With this in mind, it is up to you to continue digging and deduce the best way to organize CSS in your specific project.
+
+As a next step, why don't you have a look at the [composition feature](https://github.com/salsify/ember-css-modules#styling-reuse)? At first glance and without reading the docs carefully enough, it might look like "importing a CSS rule content", but that's not it. It is rather about adding to an element with a `local-class` an additional `local-class` coming from another file. So by using `composes` once, many different rules can suddenly apply to the element.
 
 I hope you enjoyed this tutorial :)
diff --git a/src/posts/2022-09-18-simplabs-becomes-mainmatter.md b/src/posts/2022-09-18-simplabs-becomes-mainmatter.md
index cdcc87765b..1dd31184b8 100644
--- a/src/posts/2022-09-18-simplabs-becomes-mainmatter.md
+++ b/src/posts/2022-09-18-simplabs-becomes-mainmatter.md
@@ -3,9 +3,7 @@ title: "simplabs becomes Mainmatter"
 authorHandle: marcoow
 tags: mainmatter
 bio: "Marco Otte-Witte"
-description:
-  "Marco Otte-Witte shares some background on the rebranding from simplabs to
-  Mainmatter."
+description: "Marco Otte-Witte shares some background on the rebranding from simplabs to Mainmatter."
 og:
   image: /assets/images/posts/2022-09-18-simplabs-becomes-mainmatter/og-image.jpg
 tagline: |
@@ -14,20 +12,9 @@ image: "/assets/images/posts/2022-09-18-simplabs-becomes-mainmatter/mainmatter.s
 imageAlt: "The Mainmatter logo"
 ---
 
-Mainmatter – or simplabs before this day – is 7.5 years old now. It was founded
-in March 2015 and has since grown into a team of 20+ people across 11 countries.
-Over the years we have completed 30+ project with more than 20 different clients
-from small startups to big corporates. Engineers from our team have given
-countless talks at international conferences and we're even running some of our
-own events (check out our [events page](/events/)).
-
-Yet, we never had a professionally thought through and worked out brand in all
-these years. I had started using simplabs.com as my personal website ca. 15
-years ago and when founding the company built a brand around that domain I
-already had. I got the blue ball logo (which reminds some of the Scottish flag,
-others of a cake diagram with missing labels but doesn't really **mean**
-anything to anyone) from [99designs](https://99designs.de), picked a font that I
-liked, combined the 2, and done was the brand.
+Mainmatter – or simplabs before this day – is 7.5 years old now. It was founded in March 2015 and has since grown into a team of 20+ people across 11 countries. Over the years we have completed 30+ project with more than 20 different clients from small startups to big corporates. Engineers from our team have given countless talks at international conferences and we're even running some of our own events (check out our [events page](/events/)).
+
+Yet, we never had a professionally thought through and worked out brand in all these years. I had started using simplabs.com as my personal website ca. 15 years ago and when founding the company built a brand around that domain I already had. I got the blue ball logo (which reminds some of the Scottish flag, others of a cake diagram with missing labels but doesn't really **mean** anything to anyone) from [99designs](https://99designs.de), picked a font that I liked, combined the 2, and done was the brand.
 
 The very first version of the logo looked like this:
 
@@ -39,99 +26,42 @@ and over time evolved into this:
 
 ## simplabs as in simplicity
 
-The idea behind the name simplabs was that simplicity is key in software
-projects, a realization that every engineer will have in some form or another
-during their career. The _"labs"_ suffix didn't really mean much at all and I
-picked it mostly because it was kind of fashionable at the time (like leaving
-out vowels was a few years before – anyone remember
-[twttr.com](http://twttr.com)?) There were always problems with the name
-however, the main one being that a lot of people misunderstood the name as
-"simple labs" which is the opposite of what I wanted to express – achieving
-simplicity is very much not simple after all! Another problem was that while
-simplicity is worth striving for, it's just a means to achieve other values but
-not a value on its own. Simplicity in code makes it easier to build great
-products, deliver business value and follow through on goals which is what's
-actually relevant. Thus, overall our brand was never really aligned with what we
-stand for and deliver to the teams we work with.
+The idea behind the name simplabs was that simplicity is key in software projects, a realization that every engineer will have in some form or another during their career. The _"labs"_ suffix didn't really mean much at all and I picked it mostly because it was kind of fashionable at the time (like leaving out vowels was a few years before – anyone remember [twttr.com](http://twttr.com)?) There were always problems with the name however, the main one being that a lot of people misunderstood the name as "simple labs" which is the opposite of what I wanted to express – achieving simplicity is very much not simple after all! Another problem was that while simplicity is worth striving for, it's just a means to achieve other values but not a value on its own. Simplicity in code makes it easier to build great products, deliver business value and follow through on goals which is what's actually relevant. Thus, overall our brand was never really aligned with what we stand for and deliver to the teams we work with.
 
 ## What we stand for
 
-The first thing we had to do to come up with a new brand that sent a clearer
-message with better focus was to figure out what that message should be. Like
-many other teams before us, we had to look at what we were already doing and
-find out what the core of that was – what the main value proposition of our
-services is. Also like many other teams before us, we did so by writing down an
-elevator pitch:
-
-> We teach, cross-pollinate, and collaborate with our clients to develop digital
-> products and practices they can build on. We don’t care for trends or theory
-> if the results are impractical, so we strive for effective and pragmatic
-> solutions for complex problems.
+The first thing we had to do to come up with a new brand that sent a clearer message with better focus was to figure out what that message should be. Like many other teams before us, we had to look at what we were already doing and find out what the core of that was – what the main value proposition of our services is. Also like many other teams before us, we did so by writing down an elevator pitch:
+
+> We teach, cross-pollinate, and collaborate with our clients to develop digital products and practices they can build on. We don’t care for trends or theory if the results are impractical, so we strive for effective and pragmatic solutions for complex problems.
 >
-> Through guidance and knowledge transfer, we take a long-term view, rather than
-> chasing a short-term high, enabling our clients to shape the future of their
-> digital products. <author>the Mainmatter Team</author>
-
-The core of our work has always been to build foundations that enable teams to
-be successful and deliver value. Doing so we focus on results and real value
-delivered as opposed to following trends or theories blindly (for example, in a
-world that's crazy in love with React, we still see a lot of value in
-[Ember.js](/ember-consulting/) for many use cases). While we deliver real
-products and most of our team writes code most of the time, we also spend a lot
-of time guiding and supporting others, enabling their long term success – even
-beyond the time they work with us. Overall, what we strive for is long-term,
-sustainable value as opposed to short-term highs.
-
-Our next step was to define some key brand personality traits that capture the
-essence of the above. We ended up with:
-
-- **Wisdom**: We strive for mastery in what we do and will share what we know
-  with others to enable them get better as well.
-- **Simplicity**: We turn complexity into simplicity to remain focused on what
-  matters instead of solving non-essential problems.
-- **Engagement**: We care about what we do and the communities we are a part of
-  – whether that's a project team or an open source community.
+> Through guidance and knowledge transfer, we take a long-term view, rather than chasing a short-term high, enabling our clients to shape the future of their digital products. <author>the Mainmatter Team</author>
+
+The core of our work has always been to build foundations that enable teams to be successful and deliver value. Doing so we focus on results and real value delivered as opposed to following trends or theories blindly (for example, in a world that's crazy in love with React, we still see a lot of value in [Ember.js](/ember-consulting/) for many use cases). While we deliver real products and most of our team writes code most of the time, we also spend a lot of time guiding and supporting others, enabling their long term success – even beyond the time they work with us. Overall, what we strive for is long-term, sustainable value as opposed to short-term highs.
+
+Our next step was to define some key brand personality traits that capture the essence of the above. We ended up with:
+
+- **Wisdom**: We strive for mastery in what we do and will share what we know with others to enable them get better as well.
+- **Simplicity**: We turn complexity into simplicity to remain focused on what matters instead of solving non-essential problems.
+- **Engagement**: We care about what we do and the communities we are a part of – whether that's a project team or an open source community.
 
 ## Mainmatter
 
-All this eventually lead to the name "Mainmatter" we're releasing today. Our
-main value proposition is supporting clients in having a stronger focus on
-whatever is their main matter, the core of their business – whether that's
+All this eventually lead to the name "Mainmatter" we're releasing today. Our main value proposition is supporting clients in having a stronger focus on whatever is their main matter, the core of their business – whether that's
 
 - by augmenting tech teams and helping them deliver results in time and quality
-- by helping companies ship products while building the foundation to support
-  their future evolution and maintenance
-- or by mentoring teams to be more efficient in the long terms (and beyond the
-  time they work with us)
+- by helping companies ship products while building the foundation to support their future evolution and maintenance
+- or by mentoring teams to be more efficient in the long terms (and beyond the time they work with us)
 
-To go with the name we created a completely new visual identity. While that's
-still relatively simple and on point overall, it's significantly bolder and more
-vivid than what we had before:
+To go with the name we created a completely new visual identity. While that's still relatively simple and on point overall, it's significantly bolder and more vivid than what we had before:
 
 ![The Mainmatter visual identity](/assets/images/posts/2022-09-18-simplabs-becomes-mainmatter/visual-identity.jpg#full)
 
-If you're interested in more details around the Mainmatter brand, check out our
-[brand styleguide](/assets/images/posts/2022-09-18-simplabs-becomes-mainmatter/Mainmatter-styleguide.pdf).
+If you're interested in more details around the Mainmatter brand, check out our [brand styleguide](/assets/images/posts/2022-09-18-simplabs-becomes-mainmatter/Mainmatter-styleguide.pdf).
 
 ## What else does this mean?
 
-It's important to us to be very clear that this rebranding does not have any
-other implications – **we remain the same company and same team doing the same
-work as before, just under a new name**. We're not taking funding, haven't sold
-the company and aren't making any similar changes that would influence
-Mainmatter's path forward. We remain committed to delivering great work for the
-teams we work with as well as to our engagement in open source – be it as a
-[sponsor of the Ember.js project](https://emberjs.com/sponsors/), a
-[Silver member of the Rust Foundation](https://foundation.rust-lang.org/members/),
-or a
-[Founding Sponsor of the Erlang Ecosystem Foundation](https://erlef.org/sponsors).
-Of course we will also continue running and supporting conferences and other
-events like [EuroRust](http://eurorust.eu), [EmberFest](http://emberfest.eu),
-and [Ember Europe](http://embereurope.org).
+It's important to us to be very clear that this rebranding does not have any other implications – **we remain the same company and same team doing the same work as before, just under a new name**. We're not taking funding, haven't sold the company and aren't making any similar changes that would influence Mainmatter's path forward. We remain committed to delivering great work for the teams we work with as well as to our engagement in open source – be it as a [sponsor of the Ember.js project](https://emberjs.com/sponsors/), a [Silver member of the Rust Foundation](https://foundation.rust-lang.org/members/), or a [Founding Sponsor of the Erlang Ecosystem Foundation](https://erlef.org/sponsors). Of course we will also continue running and supporting conferences and other events like [EuroRust](http://eurorust.eu), [EmberFest](http://emberfest.eu), and [Ember Europe](http://embereurope.org).
 
 ## A bright future ahead
 
-We are looking forward to a bright future as Mainmatter and are excited about
-future projects and clients to come! If you want to be one of them, please don't
-hesitate to [contact us](/contact) to talk about **how Mainmatter can help
-you**.
+We are looking forward to a bright future as Mainmatter and are excited about future projects and clients to come! If you want to be one of them, please don't hesitate to [contact us](/contact) to talk about **how Mainmatter can help you**.
diff --git a/src/posts/2022-09-22-selfsigned-certificates-for-development.md b/src/posts/2022-09-22-selfsigned-certificates-for-development.md
index adb68194ad..a21bb03fc8 100644
--- a/src/posts/2022-09-22-selfsigned-certificates-for-development.md
+++ b/src/posts/2022-09-22-selfsigned-certificates-for-development.md
@@ -14,54 +14,35 @@ image: "/assets/images/posts/2022-09-22-selfsigned-certificates-for-development/
 imageAlt: "A grid of lockets representing a safe connection in your browser"
 ---
 
-While working on a recent client project I had to test for secure cookies and to
-do so needed to test on an HTTPS connection.
+While working on a recent client project I had to test for secure cookies and to do so needed to test on an HTTPS connection.
 
-Serving HTTPS locally is a function built into most web servers and frameworks,
-but the tricky part is to get the necessary certificates. You can generate these
-by hand, but there is a better way.
+Serving HTTPS locally is a function built into most web servers and frameworks, but the tricky part is to get the necessary certificates. You can generate these by hand, but there is a better way.
 
-Instead of getting your hands dirty with `openssl` and such, meet a little
-helper called [mkcert][mkcert].
+Instead of getting your hands dirty with `openssl` and such, meet a little helper called [mkcert][mkcert].
 
 [mkcert]: https://github.com/FiloSottile/mkcert/
 
-Not only does it streamline the process of creating self-signed certificates
-that are great for development, but it also does away with the warning about
-said certificates by automatically installing a locally-trusted root certificate
-to your machine and integrating it with your browsers, giving you that nice
-little green lock for confident client presentations.
+Not only does it streamline the process of creating self-signed certificates that are great for development, but it also does away with the warning about said certificates by automatically installing a locally-trusted root certificate to your machine and integrating it with your browsers, giving you that nice little green lock for confident client presentations.
 
-It's nice because it just works and even more so, it works on macOS, Linux, and
-even Windows. Follow the instructions in the projects [README.md][readme] and
-you're ready.
+It's nice because it just works and even more so, it works on macOS, Linux, and even Windows. Follow the instructions in the projects [README.md][readme] and you're ready.
 
 ## Use `mkcert` with [ember-cli][ember-cli]
 
-Since the project I was working on happens to be built with Ember.js, here is
-how you use it together with its CLI.
+Since the project I was working on happens to be built with Ember.js, here is how you use it together with its CLI.
 
 ### Step 1: Enable SSL in ember-cli
 
-`ember serve` supports `--ssl`, `--ssl-key` and `--ssl-cert` to set all
-necessary input through the command line, but I would recommend generating the
-keys in the place it expects them to reduce clutter.
+`ember serve` supports `--ssl`, `--ssl-key` and `--ssl-cert` to set all necessary input through the command line, but I would recommend generating the keys in the place it expects them to reduce clutter.
 
-If you generate the necessary files in `./ssl` where ember-cli expects them by
-default, you only need to add the `--ssl` flag.
+If you generate the necessary files in `./ssl` where ember-cli expects them by default, you only need to add the `--ssl` flag.
 
-If you want to serve your project with SSL all the time, you can even put
-`"ssl": true` inside your `.ember-cli` configuration file, removing the need for
-the flag.
+If you want to serve your project with SSL all the time, you can even put `"ssl": true` inside your `.ember-cli` configuration file, removing the need for the flag.
 
-Adding the `ssl-key` and `ssl-cert` paths there would work as well, but I think
-the default location is fine, so we will continue with that.
+Adding the `ssl-key` and `ssl-cert` paths there would work as well, but I think the default location is fine, so we will continue with that.
 
 ### Step 2: Generate all necessary files
 
-We need to generate the `.crt` and `.key` files, as well as make sure that their
-location will be created when cloning the repository whilst ensuring that the
-actual files are never committed.
+We need to generate the `.crt` and `.key` files, as well as make sure that their location will be created when cloning the repository whilst ensuring that the actual files are never committed.
 
 ```bash
 # ember-cli looks for key files in ./ssl relative to the project root
@@ -74,11 +55,7 @@ touch ./ssl/.gitkeep
 echo -en '# Ignore self-signed certificates created by mkcert\n /ssl/server.crt\n/ssl/server.key\n' >> .gitignore
 ```
 
-Now you can run `mkcert` to create your certificate. Consider making this
-command a run script by adding it to the `scripts` section in your
-`package.json`, or creating a shell script file from it that can be added to
-your repository. If you don't want to do either, you should consider documenting
-it in your `README.md` at least.
+Now you can run `mkcert` to create your certificate. Consider making this command a run script by adding it to the `scripts` section in your `package.json`, or creating a shell script file from it that can be added to your repository. If you don't want to do either, you should consider documenting it in your `README.md` at least.
 
 ```bash
 # Add additional hosts separated by spaces after localhost if necessary
@@ -87,23 +64,15 @@ mkcert -install -cert-file ./ssl/server.crt -key-file ./ssl/server.key localhost
 
 ### Step 3: Profit
 
-Your frontend application is served on `https://localhost:4200` now, allowing
-all the things you would expect from a properly SSL encrypted server connection
-and in turn, allowing you to replicate and debug real-world situations with
-ease.
+Your frontend application is served on `https://localhost:4200` now, allowing all the things you would expect from a properly SSL encrypted server connection and in turn, allowing you to replicate and debug real-world situations with ease.
 
 ## Use `mkcert` with [fastify][fastify]
 
-When I need to create a quick API and don’t want to use [Rust with
-Actix][actix], I often find myself reaching for fastify. It's a lot like the
-Express.js used by ember-cli internally, but has a few nice extras and I
-happened to have used it recently.
+When I need to create a quick API and don’t want to use [Rust with Actix][actix], I often find myself reaching for fastify. It's a lot like the Express.js used by ember-cli internally, but has a few nice extras and I happened to have used it recently.
 
-If you want to serve HTTP/2 over HTTPS for your fastify API, you will also need
-certificates.
+If you want to serve HTTP/2 over HTTPS for your fastify API, you will also need certificates.
 
-[The documentation for this][fastify-https] is quite straightforward. The
-example there expects `fastify.key` and `fastify.cert` in a `https` folder.
+[The documentation for this][fastify-https] is quite straightforward. The example there expects `fastify.key` and `fastify.cert` in a `https` folder.
 
 Consider the following structure in your project:
 
@@ -141,36 +110,23 @@ Generate the mentioned files like this:
 mkcert -install -cert-file ./https/fastify.cert -key-file ./https/fastify.key localhost
 ```
 
-You can now run `node ./src/main.js` and visit `https://localhost:3000` with SSL
-encryption and your local browser will show a green checkmark as well!
+You can now run `node ./src/main.js` and visit `https://localhost:3000` with SSL encryption and your local browser will show a green checkmark as well!
 
 ## Caveats
 
-First, you must never share the `rootCA-key.pem` file created by `mkcert` with
-anyone. It must not leave your computer as it would give an attacker power to
-intercept any secure request to your machine. Handle with care.
+First, you must never share the `rootCA-key.pem` file created by `mkcert` with anyone. It must not leave your computer as it would give an attacker power to intercept any secure request to your machine. Handle with care.
 
-Second, the root certificate is what makes your browsers accept the self-signed
-certificates created by `mkcert` as valid. That means, only _you_ alone get the
-benefit of the green lock in _your_ browser. Sharing your development server
-with someone else on your network or even trying to use them in a public
-scenario would lead to browsers warning visitors about invalid certificates.
+Second, the root certificate is what makes your browsers accept the self-signed certificates created by `mkcert` as valid. That means, only _you_ alone get the benefit of the green lock in _your_ browser. Sharing your development server with someone else on your network or even trying to use them in a public scenario would lead to browsers warning visitors about invalid certificates.
 
-Do not use this in production. It's a neat thing that helps you get your job as
-a developer done, but once you move to production, you should look for other
-options.
+Do not use this in production. It's a neat thing that helps you get your job as a developer done, but once you move to production, you should look for other options.
 
 One of those options would of course be [Let's Encrypt][letsencrypt].
 
-Yes, you could also use that locally, but from my experience, if you are looking
-for a quick way to run a local development server with SSL, [mkcert][mkcert]
-really works like a charm.
+Yes, you could also use that locally, but from my experience, if you are looking for a quick way to run a local development server with SSL, [mkcert][mkcert] really works like a charm.
 
 [actix]: https://actix.rs/docs/http2/
 [ember-cli]: https://cli.emberjs.com/
-[fastify-https]:
-  https://www.fastify.io/docs/latest/Reference/HTTP2/#secure-https
+[fastify-https]: https://www.fastify.io/docs/latest/Reference/HTTP2/#secure-https
 [fastify]: https://www.fastify.io
 [letsencrypt]: https://letsencrypt.org
-[readme]:
-  https://github.com/FiloSottile/mkcert/blob/master/README.md#installation
+[readme]: https://github.com/FiloSottile/mkcert/blob/master/README.md#installation
diff --git a/src/posts/2022-09-29-pnpm.md b/src/posts/2022-09-29-pnpm.md
index c0c59ca47c..9126125cac 100644
--- a/src/posts/2022-09-29-pnpm.md
+++ b/src/posts/2022-09-29-pnpm.md
@@ -4,9 +4,7 @@ authorHandle: tobiasbieniek
 twitter: tobiasbieniek
 tags: javascript
 bio: "Senior Software Engineer"
-description:
-  "Tobias Bieniek reveals his secret to saving many GB of disk space when
-  working with JavaScript projects."
+description: "Tobias Bieniek reveals his secret to saving many GB of disk space when working with JavaScript projects."
 og:
   image: /assets/images/posts/2022-09-29-pnpm/og-image.jpg
 tagline: |
@@ -21,42 +19,19 @@ tagline: |
 
 ## The status quo
 
-Let's start by getting an understanding of why things are the way they are.
-[Chesterton] would be proud…
-
-Back in the days when computers were first created there were no package
-managers. There weren't even packages. Things were just being copied around and
-nobody had heard of "versions" yet.
-
-At some point a few clever developers thought that it might be nice to share
-reusable pieces of code across applications and thus "packages" were born. One
-major downside of the early package infrastructure was that packages were shared
-across the operating system. That means, if you have two applications and both
-need a particular, but different, version of a package, you're essentially
-screwed.
-
-Believe it or not, this is basically how everything in the Python and Ruby
-worlds work. These days there are ways to work around this and have an
-"environment" (with its packages) per project, but it is still quite hard to
-have multiple versions of the same package within such an environment.
-
-When [npm] came around, they realized that this sort of thing wasn't very
-scalable and set out to fix this issue. Their main idea: instead of putting
-packages in some operating system folder the packages would be kept directly in
-the folder of each project. But also, each of the packages could also have other
-packages as dependencies within it. This is how the `node_modules` folder was
-born.
-
-They formalized a rather simple [algorithm] to find the packages in the nearest
-`node_modules` folder: if you call `require('chesterton')` in a file, then it
-will look for a `node_modules` folder in the same folder as the file, and, if
-found, it will look for a `chesterton` folder inside it. If neither exists, it
-will look in the _parent_ folder of the file for a `node_modules/chesterton`
-folder. And if that does not exist, it will look in the _parent parent_ folder,
-and so on, and so on…
-
-The beauty of this algorithm is that it allows us to have complicated dependency
-graphs:
+Let's start by getting an understanding of why things are the way they are. [Chesterton] would be proud…
+
+Back in the days when computers were first created there were no package managers. There weren't even packages. Things were just being copied around and nobody had heard of "versions" yet.
+
+At some point a few clever developers thought that it might be nice to share reusable pieces of code across applications and thus "packages" were born. One major downside of the early package infrastructure was that packages were shared across the operating system. That means, if you have two applications and both need a particular, but different, version of a package, you're essentially screwed.
+
+Believe it or not, this is basically how everything in the Python and Ruby worlds work. These days there are ways to work around this and have an "environment" (with its packages) per project, but it is still quite hard to have multiple versions of the same package within such an environment.
+
+When [npm] came around, they realized that this sort of thing wasn't very scalable and set out to fix this issue. Their main idea: instead of putting packages in some operating system folder the packages would be kept directly in the folder of each project. But also, each of the packages could also have other packages as dependencies within it. This is how the `node_modules` folder was born.
+
+They formalized a rather simple [algorithm] to find the packages in the nearest `node_modules` folder: if you call `require('chesterton')` in a file, then it will look for a `node_modules` folder in the same folder as the file, and, if found, it will look for a `chesterton` folder inside it. If neither exists, it will look in the _parent_ folder of the file for a `node_modules/chesterton` folder. And if that does not exist, it will look in the _parent parent_ folder, and so on, and so on…
+
+The beauty of this algorithm is that it allows us to have complicated dependency graphs:
 
 ```
 our-app
@@ -65,113 +40,65 @@ our-app
    └─ one-dependency@0.4.2
 ```
 
-Don't get me wrong, I'm not saying complicated dependency graphs are necessarily
-a good thing, but in some cases they are hard to avoid. If necessary, I'd rather
-have two versions of the same dependency in a project, than not be able to use
-the dependency at all.
+Don't get me wrong, I'm not saying complicated dependency graphs are necessarily a good thing, but in some cases they are hard to avoid. If necessary, I'd rather have two versions of the same dependency in a project, than not be able to use the dependency at all.
 
-Anyway, that's how we got into this mess… Now let's see how we can get back out
-of it!
+Anyway, that's how we got into this mess… Now let's see how we can get back out of it!
 
 ## Plug and maybe Play… sometimes
 
-For years, the way npm did things was the established practice and any attempts
-of changing the status quo failed. With [yarn], a new package manager was born
-that challenged a lot of things in the npm ecosystem… except for the
-`node_modules` structure. 😢
+For years, the way npm did things was the established practice and any attempts of changing the status quo failed. With [yarn], a new package manager was born that challenged a lot of things in the npm ecosystem… except for the `node_modules` structure. 😢
 
-Well, that's not entirely correct. After years of development the yarn team
-finally came up with what they called "Plug'n'Play mode" (or "PnP" for short).
-This new mode promised us to share the dependencies across the whole machine
-while still allowing us to have multiple versions of the same package installed.
-😍
+Well, that's not entirely correct. After years of development the yarn team finally came up with what they called "Plug'n'Play mode" (or "PnP" for short). This new mode promised us to share the dependencies across the whole machine while still allowing us to have multiple versions of the same package installed. 😍
 
-Unfortunately, this new mode had one major downside: It monkey patched the
-`require()` function in Node.js, because it needed to essentially override the
-`node_modules` lookup algorithm. 😫
+Unfortunately, this new mode had one major downside: It monkey patched the `require()` function in Node.js, because it needed to essentially override the `node_modules` lookup algorithm. 😫
 
-While this worked well in small, controlled environments, it eventually became
-clear that this was not a good long-term solution. There are still plenty of
-tools in the npm ecosystem that don't support this mode well, or even at all.
+While this worked well in small, controlled environments, it eventually became clear that this was not a good long-term solution. There are still plenty of tools in the npm ecosystem that don't support this mode well, or even at all.
 
 We need a different solution!
 
 ## The shiny future
 
-Remember the title of the blog post? One character to rule them all, one
-character to find them, … No, wait that was something different.
+Remember the title of the blog post? One character to rule them all, one character to find them, … No, wait that was something different.
 
 Ah, right, "one character saved 50 GB of disk space". That one character is… P.
 
-It is the (first) P in [pnpm]. The simple solution: use `pnpm install` instead
-of `npm install`. Done!
+It is the (first) P in [pnpm]. The simple solution: use `pnpm install` instead of `npm install`. Done!
 
-If you're wondering "why P?", well, the P stands for
-[**performance**](https://pnpm.io/faq#what-does-pnpm-stand-for).
+If you're wondering "why P?", well, the P stands for [**performance**](https://pnpm.io/faq#what-does-pnpm-stand-for).
 
-But let me explain… `pnpm` managed to fulfil the promise that `yarn` made with
-its PnP mode, but without having to monkey patch anything. Instead, it is using
-[hard links] in a clever way, allowing the regular `node_modules` algorithm to
-work as intended, but still only having a single copy of each package version on
-the disk.
+But let me explain… `pnpm` managed to fulfil the promise that `yarn` made with its PnP mode, but without having to monkey patch anything. Instead, it is using [hard links] in a clever way, allowing the regular `node_modules` algorithm to work as intended, but still only having a single copy of each package version on the disk.
 
 Fun fact: Did you notice how "PnP mode" starts with the letters `pnpm`? 😄
 
-Twitter user `xiaokedada` has created a nice
-[overview image](https://twitter.com/xiaokedada/status/1471691763102679041) on
-how pnpm creates its folder structure:
+Twitter user `xiaokedada` has created a nice [overview image](https://twitter.com/xiaokedada/status/1471691763102679041) on how pnpm creates its folder structure:
 
 ![Overview of pnpm folder structure](/assets/images/posts/2022-09-29-pnpm/pnpm-folder-structure.jpeg)
 
-This might seem complicated at first, but it is relatively straight forward. On
-the right hand side, we have the global pnpm store, that contains all the
-packages and package versions that pnpm has downloaded to your machine. Each
-package version only exists exactly once in this store, and the `node_modules`
-folder in your projects are linking to this global store (dark red lines).
+This might seem complicated at first, but it is relatively straight forward. On the right hand side, we have the global pnpm store, that contains all the packages and package versions that pnpm has downloaded to your machine. Each package version only exists exactly once in this store, and the `node_modules` folder in your projects are linking to this global store (dark red lines).
 
-In the `node_modules` folder of our project we have a `bar` folder which points
-to the `bar` dependency of our project. However, there is also a hidden `.pnpm`
-folder which contains the real magic. Inside this folder are folders for every
-single package/version combination that is being used in your project.
+In the `node_modules` folder of our project we have a `bar` folder which points to the `bar` dependency of our project. However, there is also a hidden `.pnpm` folder which contains the real magic. Inside this folder are folders for every single package/version combination that is being used in your project.
 
-This includes our own dependency `bar` in the `bar@1.0.0` folder, but inside
-this `node_module/.pnpm/bar@1.0.0` folder is not the dependency itself, but
-instead just another `node_modules` folder, with another `bar` folder inside of
-it, linking to the global pnpm store.
+This includes our own dependency `bar` in the `bar@1.0.0` folder, but inside this `node_module/.pnpm/bar@1.0.0` folder is not the dependency itself, but instead just another `node_modules` folder, with another `bar` folder inside of it, linking to the global pnpm store.
 
 Whoa… that's complicated!
 
-But there is a reason for this complicated folder layout. From the perspective
-of the `bar` package we will need access to the `foo` dependency, and we will
-need to access the correct version of it. That's why the
-`node_modules/.pnpm/bar@1.0.0/node_modules/foo` folder is just a link to the
-`node_modules/.pnpm/foo@1.0.0/node_modules/foo` folder, which itself links to
-the global pnpm store again.
+But there is a reason for this complicated folder layout. From the perspective of the `bar` package we will need access to the `foo` dependency, and we will need to access the correct version of it. That's why the `node_modules/.pnpm/bar@1.0.0/node_modules/foo` folder is just a link to the `node_modules/.pnpm/foo@1.0.0/node_modules/foo` folder, which itself links to the global pnpm store again.
 
-**tl;dr** the complicated folder layout ensures that every package has access to
-its dependencies in the right version, but not anything else.
+**tl;dr** the complicated folder layout ensures that every package has access to its dependencies in the right version, but not anything else.
 
 ## Conclusion
 
-While pnpm has been around for quite a while, it has lately started to gain more
-momentum, with quite a few high profile projects migrating to it.
+While pnpm has been around for quite a while, it has lately started to gain more momentum, with quite a few high profile projects migrating to it.
 
-At Mainmatter we have started to convert a few of our own projects to it, and
-let me tell you that the 50 GB of saved disk space are not a joke. Some of us
-had dozens of individual Ember.js apps and addons installed, all using a roughly
-similar dependency tree. When you get to reduce all of these duplicated
-dependencies to just one copy per machine it quickly adds up.
+At Mainmatter we have started to convert a few of our own projects to it, and let me tell you that the 50 GB of saved disk space are not a joke. Some of us had dozens of individual Ember.js apps and addons installed, all using a roughly similar dependency tree. When you get to reduce all of these duplicated dependencies to just one copy per machine it quickly adds up.
 
-While pnpm is certainly not without its issues either, it currently appears to
-be the least bad solution in the JavaScript ecosystem. We encourage you to try
-it out and message us if you hit any issues.
+While pnpm is certainly not without its issues either, it currently appears to be the least bad solution in the JavaScript ecosystem. We encourage you to try it out and message us if you hit any issues.
 
 Finally, a huge **thank you** to the lead pnpm maintainer, [Zoltan Kochan]!
 
 [chesterton]: https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
 [npm]: https://www.npmjs.com/package/npm
-[algorithm]:
-  https://nodejs.org/api/modules.html#loading-from-node_modules-folders
+[algorithm]: https://nodejs.org/api/modules.html#loading-from-node_modules-folders
 [yarn]: https://yarnpkg.com
 [pnpm]: https://pnpm.io
 [hard links]: https://en.wikipedia.org/wiki/Hard_link
diff --git a/src/posts/2022-10-12-making-a-strategic-bet-on-rust.md b/src/posts/2022-10-12-making-a-strategic-bet-on-rust.md
index 8ed3fa8620..e3a92ca6c3 100644
--- a/src/posts/2022-10-12-making-a-strategic-bet-on-rust.md
+++ b/src/posts/2022-10-12-making-a-strategic-bet-on-rust.md
@@ -3,9 +3,7 @@ title: "Making a strategic bet on Rust"
 authorHandle: marcoow
 tags: rust
 bio: "Marco Otte-Witte"
-description:
-  "Mainmatter is making a strategic bet on Rust to become the leading
-  consultancy to help teams adopt Rust for web projects."
+description: "Mainmatter is making a strategic bet on Rust to become the leading consultancy to help teams adopt Rust for web projects."
 og:
   image: /assets/images/posts/2022-10-12-making-a-strategic-bet-on-rust/og-image.jpg
 tagline: |
@@ -20,111 +18,41 @@ image: "/assets/images/posts/2022-10-12-making-a-strategic-bet-on-rust/mainmatte
 imageAlt: "Mainmatter loves Rust"
 ---
 
-Rust makes a level of efficiency and performance accessible to a wider audience
-of engineering teams that was previously out of reach. While C and C++ have
-allowed building highly efficient systems for decades, they come with so many
-footguns that only extremely skilled and experienced teams can dare to build
-anything substantial with them – and
-[even those end up with systems that have plenty of problems](https://www.memorysafety.org/about/).
-Now, with Rust, everyone can build systems with the same level of efficiency and
-performance without having to worry about most of said footguns. Building on
-Rust, systems will not only be just as fast as an equivalent system written in C
-but also more stable and robust. In addition to ensuring memory safety, Rust's
-rich type system and concepts like the `Option` and `Result` types further
-increase confidence by encouraging solid error handling through concepts built
-into the language itself.
-
-Yet, Rust enables all that without sacrificing expressiveness of the language,
-productivity, and developer experience. Modern language concepts like pattern
-matching and generics, the integrated
-[package manager](https://doc.rust-lang.org/cargo/) and solid development tools,
-all make working with Rust a breeze.
+Rust makes a level of efficiency and performance accessible to a wider audience of engineering teams that was previously out of reach. While C and C++ have allowed building highly efficient systems for decades, they come with so many footguns that only extremely skilled and experienced teams can dare to build anything substantial with them – and [even those end up with systems that have plenty of problems](https://www.memorysafety.org/about/). Now, with Rust, everyone can build systems with the same level of efficiency and performance without having to worry about most of said footguns. Building on Rust, systems will not only be just as fast as an equivalent system written in C but also more stable and robust. In addition to ensuring memory safety, Rust's rich type system and concepts like the `Option` and `Result` types further increase confidence by encouraging solid error handling through concepts built into the language itself.
+
+Yet, Rust enables all that without sacrificing expressiveness of the language, productivity, and developer experience. Modern language concepts like pattern matching and generics, the integrated [package manager](https://doc.rust-lang.org/cargo/) and solid development tools, all make working with Rust a breeze.
 
 ## Rust on the Web
 
-So where do we see Rust fitting in for web projects? Around 12 years after the
-language's creation, the ecosystem is still relatively young, yet mature enough
-for a variety of use cases already:
-
-- **Native extensions** written in Rust (via FFI/NIF mechanisms) can be used to
-  speed up parts of existing systems written in Ruby, Elixir, Node, and many
-  other languages, by orders of magnitude and provide an easy onramp to
-  introducing Rust into a team's tech stack.
-- **Isolated subsystems** of larger server systems with very specific
-  requirements in terms of performance and robustness are great candidates to
-  build in Rust – whether those are individual services in a microservices
-  architecture or layers in multi-layered systems.
-- Similar to subsystems, **downstream systems** for e.g. data processing and
-  similar tasks with relatively limited scope but hard requirements regarding
-  efficiency will often benefit hugely from being implemented in Rust.
-
-While all these are relatively isolated use cases with limited scope, we believe
-that **eventually Rust will be a reasonable choice for building complete API
-servers** as well although as of yet that problem space still requires some
-exploration to develop and establish best practices and architectures. We're
-excited to bring in our years-long experience building web apps of all kinds and
-be a part of this exploration – for the benefit of the clients we work with as
-well as the ecosystem overall. Establishing these patterns and building
-consensus across the community will eventually drive adoption of Rust on the web
-even further as it makes Rust more accessible for more teams.
-
-And of course there's also WASM – while that sees quite some adoption outside of
-the browser (e.g. via the
-[WebAssembly Micro Runtime](https://github.com/bytecodealliance/wasm-micro-runtime))
-recently, it was originally built to enable an entirely new category of apps to
-run in browsers. Except for some high visibility examples
-([Figma](https://www.figma.com/) likely being the most well known), it remains
-slightly unclear how the average team would leverage WASM and what real world
-use cases are. Yet, we're excited to explore this space more and support the
-teams we work with experimenting what potential WASM can have for them.
+So where do we see Rust fitting in for web projects? Around 12 years after the language's creation, the ecosystem is still relatively young, yet mature enough for a variety of use cases already:
+
+- **Native extensions** written in Rust (via FFI/NIF mechanisms) can be used to speed up parts of existing systems written in Ruby, Elixir, Node, and many other languages, by orders of magnitude and provide an easy onramp to introducing Rust into a team's tech stack.
+- **Isolated subsystems** of larger server systems with very specific requirements in terms of performance and robustness are great candidates to build in Rust – whether those are individual services in a microservices architecture or layers in multi-layered systems.
+- Similar to subsystems, **downstream systems** for e.g. data processing and similar tasks with relatively limited scope but hard requirements regarding efficiency will often benefit hugely from being implemented in Rust.
+
+While all these are relatively isolated use cases with limited scope, we believe that **eventually Rust will be a reasonable choice for building complete API servers** as well although as of yet that problem space still requires some exploration to develop and establish best practices and architectures. We're excited to bring in our years-long experience building web apps of all kinds and be a part of this exploration – for the benefit of the clients we work with as well as the ecosystem overall. Establishing these patterns and building consensus across the community will eventually drive adoption of Rust on the web even further as it makes Rust more accessible for more teams.
+
+And of course there's also WASM – while that sees quite some adoption outside of the browser (e.g. via the [WebAssembly Micro Runtime](https://github.com/bytecodealliance/wasm-micro-runtime)) recently, it was originally built to enable an entirely new category of apps to run in browsers. Except for some high visibility examples ([Figma](https://www.figma.com/) likely being the most well known), it remains slightly unclear how the average team would leverage WASM and what real world use cases are. Yet, we're excited to explore this space more and support the teams we work with experimenting what potential WASM can have for them.
 
 ![Mainmatter + Rust = 🚀🔥🚀](/assets/images/posts/2022-10-12-making-a-strategic-bet-on-rust/mainmatter-rust-rocket.png)
 
 ## Rust is a competitive advantage
 
-Rust gives teams access to a level of efficiency, performance, and robustness
-that's far beyond that of most other technologies commonly used for web apps.
-Web apps written in Rust will have **better response times while requiring fewer
-resources** which saves money and energy (Shane Miller and Carl Lerche gave a
-[talk about how using Rust helps minimizing the environmental impact](https://www.youtube.com/watch?v=yQZaBtUjQ1w)
-of the systems we all build every day at AWS re:Invent 2021).
-
-At the same time, **teams working with Rust can have more confidence in their
-code** because of Rust's rich type system and modern language concepts that
-eliminate entire classes of errors. That does not only make code more stable at
-runtime and less likely to run into unforeseen errors in production, but also
-makes it easier to make changes to systems and maintain them over time compared
-to dynamically typed languages (going back to strongly typed languages appears
-to be a general trend in the industry, most prominently to be observed by the
-huge success that TypeScript had over the past few years).
-
-Finally, building systems in Rust is a competitive advantage in an industry that
-continues to fight for the best talents like no other. As mentioned above, Rust
-has been
-[voted the most loved language](https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages)
-seven years in a row and literally *every engineer in the world*™ is eager to
-work with it. Companies that can hire for Rust (and are willing to up-level
-people that are new to the language), will have no problems finding people for
-years to come.
+Rust gives teams access to a level of efficiency, performance, and robustness that's far beyond that of most other technologies commonly used for web apps. Web apps written in Rust will have **better response times while requiring fewer resources** which saves money and energy (Shane Miller and Carl Lerche gave a [talk about how using Rust helps minimizing the environmental impact](https://www.youtube.com/watch?v=yQZaBtUjQ1w) of the systems we all build every day at AWS re:Invent 2021).
+
+At the same time, **teams working with Rust can have more confidence in their code** because of Rust's rich type system and modern language concepts that eliminate entire classes of errors. That does not only make code more stable at runtime and less likely to run into unforeseen errors in production, but also makes it easier to make changes to systems and maintain them over time compared to dynamically typed languages (going back to strongly typed languages appears to be a general trend in the industry, most prominently to be observed by the huge success that TypeScript had over the past few years).
+
+Finally, building systems in Rust is a competitive advantage in an industry that continues to fight for the best talents like no other. As mentioned above, Rust has been [voted the most loved language](https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages) seven years in a row and literally *every engineer in the world*™ is eager to work with it. Companies that can hire for Rust (and are willing to up-level people that are new to the language), will have no problems finding people for years to come.
 
 ## Mainmatter ❤️ Rust
 
-We believe betting on Rust will benefit the teams we work with and enable a
-bright future for Mainmatter at the same time. We're looking forward to
-<strong>helping our clients adopt Rust for their web projects through
-[Team reinforcement](/services/team-reinforcement/)</strong>
+We believe betting on Rust will benefit the teams we work with and enable a bright future for Mainmatter at the same time. We're looking forward to <strong>helping our clients adopt Rust for their web projects through [Team reinforcement](/services/team-reinforcement/)</strong>
 
 We've invested in Rust quite significantly already by
 
-- joining the Rust Foundation as a
-  [Silver member](https://foundation.rust-lang.org/members/)
-- having several people on the team help maintain [crates.io](https://crates.io)
-  on company time for several years now
+- joining the Rust Foundation as a [Silver member](https://foundation.rust-lang.org/members/)
+- having several people on the team help maintain [crates.io](https://crates.io) on company time for several years now
 - running Rust workshops to help teams get started with the language
-- creating [EuroRust](https://eurorust.eu), the conference for the European Rust
-  community
+- creating [EuroRust](https://eurorust.eu), the conference for the European Rust community
 
-We're looking forward to continue these investments, extending our involvement
-with Rust even more over the next years and helping teams find their path
-towards Rust. If you're **interested in Rust and want to adopt it in your
-organization**, [reach out](/contact/)!
+We're looking forward to continue these investments, extending our involvement with Rust even more over the next years and helping teams find their path towards Rust. If you're **interested in Rust and want to adopt it in your organization**, [reach out](/contact/)!
diff --git a/src/posts/2022-12-09-sending-emails-from-the-edge-with-rust.md b/src/posts/2022-12-09-sending-emails-from-the-edge-with-rust.md
index a65a036e3e..13021e37db 100644
--- a/src/posts/2022-12-09-sending-emails-from-the-edge-with-rust.md
+++ b/src/posts/2022-12-09-sending-emails-from-the-edge-with-rust.md
@@ -3,9 +3,7 @@ title: "Sending Emails from the Edge with Rust"
 authorHandle: marcoow
 tags: rust
 bio: "Marco Otte-Witte"
-description:
-  "Marco Otte-Witte explains how to send emails via the Sendgrid API from a WASM
-  edge function written in Rust."
+description: "Marco Otte-Witte explains how to send emails via the Sendgrid API from a WASM edge function written in Rust."
 og:
   image: /assets/images/posts/2022-12-09-sending-emails-from-the-edge-with-rust/og-image.jpg
 tagline: |
@@ -15,11 +13,7 @@ image: "/assets/images/posts/2022-12-09-sending-emails-from-the-edge-with-rust/r
 imageAlt: "A pattern of the Rust logo, a letter icon and a server icon"
 ---
 
-If you want to send emails, you'll typically use a third party service for that.
-There are many options that all have their pros and cons – we chose
-[Sendgrid](http://sendgrid.com). Whatever service you end up choosing, they'll
-provide some kind of HTTP API for sending emails. In the case of Sendgrid that
-looks roughly like this:
+If you want to send emails, you'll typically use a third party service for that. There are many options that all have their pros and cons – we chose [Sendgrid](http://sendgrid.com). Whatever service you end up choosing, they'll provide some kind of HTTP API for sending emails. In the case of Sendgrid that looks roughly like this:
 
 ```bash
 curl --request POST \
@@ -29,19 +23,9 @@ curl --request POST \
   --data '{"personalizations":[{"to":[{"email":"john.doe@example.com"}],"subject":"Hello, World!"}],"content": [{"type": "text/plain", "value": "Heya!"}],"from":{"email":"sam.smith@example.com"}}'
 ```
 
-You send a `POST` request to `https://api.sendgrid.com/v3/mail/send` with a JSON
-body that contains the recipient's and sender's email addresses, the subject and
-the actual message. The API key that Sendgrid provides and uses to ensure the
-request comes from a subscribed user – and which one – is sent as a bearer token
-in the `Authorization` header. That key is also the only real reason why we
-can't just call the Sendgrid API directly from the browser – if we included the
-key in the website's source, we'd be making it publicly available and everyone
-could use it to send emails via our Sendgrid account. So we need to keep the
-code that calls the Sendgrid API on a server (the edge function we're writing)
-and then call that from the browser.
+You send a `POST` request to `https://api.sendgrid.com/v3/mail/send` with a JSON body that contains the recipient's and sender's email addresses, the subject and the actual message. The API key that Sendgrid provides and uses to ensure the request comes from a subscribed user – and which one – is sent as a bearer token in the `Authorization` header. That key is also the only real reason why we can't just call the Sendgrid API directly from the browser – if we included the key in the website's source, we'd be making it publicly available and everyone could use it to send emails via our Sendgrid account. So we need to keep the code that calls the Sendgrid API on a server (the edge function we're writing) and then call that from the browser.
 
-The JavaScript code that handles submission of our contact form (the `<form>`'s
-`submit` event) in the browser looks roughly like this:
+The JavaScript code that handles submission of our contact form (the `<form>`'s `submit` event) in the browser looks roughly like this:
 
 ```js
 fetch("https://contact.mainmatter.dev/send", {
@@ -53,33 +37,17 @@ fetch("https://contact.mainmatter.dev/send", {
 });
 ```
 
-We're making a POST request to our edge function with the data the user put in
-the contact form's fields sent as JSON in the request body. So in essence, the
-edge function acts as a proxy – it translates requests that users' browsers make
-to the edge function into requests from the edge function to the Sendgrid API.
+We're making a POST request to our edge function with the data the user put in the contact form's fields sent as JSON in the request body. So in essence, the edge function acts as a proxy – it translates requests that users' browsers make to the edge function into requests from the edge function to the Sendgrid API.
 
 ## Cloudflare Workers
 
-As mentioned above, there are quite a few providers to pick from when you want
-to run WASM on the edge these days – among others,
-[Vercel](https://vercel.com/docs/concepts/functions/edge-functions/wasm),
-[Netlify](https://docs.netlify.com/edge-functions/overview/),
-[Fastly](https://developer.fastly.com/learning/compute/), and
-[Cloudflare](https://developers.cloudflare.com/workers/tutorials/hello-world-rust/)
-all have offerings. For our mailer, we chose Cloudflare – their CLI tool
-[Wrangler](https://github.com/cloudflare/wrangler2) makes it easy to develop and
-deploy your code and hides all of the JavaScript wrapper code that's necessary
-to run WASM in V8.
-
-Wrangler can be used to create a new project and will set up the necessary
-structure and build configuration. Cloudflare also wrote the
-[`worker` crate](https://crates.io/crates/worker) which provides some handy APIs
-that make writing your worker in Rust easier.
+As mentioned above, there are quite a few providers to pick from when you want to run WASM on the edge these days – among others, [Vercel](https://vercel.com/docs/concepts/functions/edge-functions/wasm), [Netlify](https://docs.netlify.com/edge-functions/overview/), [Fastly](https://developer.fastly.com/learning/compute/), and [Cloudflare](https://developers.cloudflare.com/workers/tutorials/hello-world-rust/) all have offerings. For our mailer, we chose Cloudflare – their CLI tool [Wrangler](https://github.com/cloudflare/wrangler2) makes it easy to develop and deploy your code and hides all of the JavaScript wrapper code that's necessary to run WASM in V8.
+
+Wrangler can be used to create a new project and will set up the necessary structure and build configuration. Cloudflare also wrote the [`worker` crate](https://crates.io/crates/worker) which provides some handy APIs that make writing your worker in Rust easier.
 
 ## Implementing the Mailer
 
-_The complete code of our website mailer is
-[available on GitHub](https://github.com/mainmatter/mainmatter-website-mailer)._
+_The complete code of our website mailer is [available on GitHub](https://github.com/mainmatter/mainmatter-website-mailer)._
 
 The basic structure for our mailer worker looks like this:
 
@@ -101,17 +69,9 @@ pub async fn main(req: Request, env: Env, _ctx: worker::Context) -> WorkerResult
 }
 ```
 
-We're importing the structs and attributes we need from the `worker` crate and
-define a `main` function that responds to `fetch` events (i.e. incoming
-requests). Inside of that function, we use the `Router` provided by the `worker`
-package to handle requests based on the path and method – in this case we're
-only interested in `POST` requests to the `/send` path.
+We're importing the structs and attributes we need from the `worker` crate and define a `main` function that responds to `fetch` events (i.e. incoming requests). Inside of that function, we use the `Router` provided by the `worker` package to handle requests based on the path and method – in this case we're only interested in `POST` requests to the `/send` path.
 
-Since we'll get the message details like the sender's name, email address and
-the message text in the request body as JSON, we need to convert that JSON
-string into something we can work with. We can use the
-[`serde` crate](https://crates.io/crates/serde) to deserialize the string into a
-struct:
+Since we'll get the message details like the sender's name, email address and the message text in the request body as JSON, we need to convert that JSON string into something we can work with. We can use the [`serde` crate](https://crates.io/crates/serde) to deserialize the string into a struct:
 
 ```rust
 use serde::Deserialize;
@@ -142,9 +102,7 @@ pub async fn main(req: Request, env: Env, _ctx: worker::Context) -> WorkerResult
 }
 ```
 
-If deserializing the request body into a `Payload` fails, we simply respond with
-status 422. Otherwise we can go on to send the message. Let's look at how that
-works:
+If deserializing the request body into a `Payload` fails, we simply respond with status 422. Otherwise we can go on to send the message. Let's look at how that works:
 
 ```rust
 use reqwest::Client;
@@ -216,35 +174,15 @@ pub async fn send_message(payload: Payload, api_key: &str) -> WorkerResult<Respo
 }
 ```
 
-We extracted the actual logic to send the message into the `send_message`
-function. That function receives the `Payload` as well as the Sendgrid API key
-that we get from the worker context (see the
-[Cloudflare docs](https://developers.cloudflare.com/workers/platform/environment-variables/)
-for information on how to set up secrets for workers).
-
-The function constructs the request body to send to Sendgrid (setting a default
-message body if it's empty as Sendgrid doesn't allow empty messages) as a JSON
-string using the
-[`serde_json` crate's `json!` macro](https://docs.rs/serde_json/1.0.89/serde_json/macro.json.html).
-It then sends the request to the Sendgrid API (we use the
-[`reqwest` crate](https://crates.io/crates/reqwest) here but there are other
-options as well) and if that succeeds with status code 202 (indicating the
-message was sent), returns an `ok` response.
-
-**And that's already all there is to it!** Of course, there are some details
-left out in this example like
-[CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) and logging.
-Refer to the
-[GitHub repository](https://github.com/mainmatter/mainmatter-website-mailer) for
-the complete code but it's not really much more than the above.
+We extracted the actual logic to send the message into the `send_message` function. That function receives the `Payload` as well as the Sendgrid API key that we get from the worker context (see the [Cloudflare docs](https://developers.cloudflare.com/workers/platform/environment-variables/) for information on how to set up secrets for workers).
+
+The function constructs the request body to send to Sendgrid (setting a default message body if it's empty as Sendgrid doesn't allow empty messages) as a JSON string using the [`serde_json` crate's `json!` macro](https://docs.rs/serde_json/1.0.89/serde_json/macro.json.html). It then sends the request to the Sendgrid API (we use the [`reqwest` crate](https://crates.io/crates/reqwest) here but there are other options as well) and if that succeeds with status code 202 (indicating the message was sent), returns an `ok` response.
+
+**And that's already all there is to it!** Of course, there are some details left out in this example like [CORS](https://en.wikipedia.org/wiki/Cross-origin_resource_sharing) and logging. Refer to the [GitHub repository](https://github.com/mainmatter/mainmatter-website-mailer) for the complete code but it's not really much more than the above.
 
 ## Testing
 
-Having written the above code, of course we'd like to test it as well to ensure
-it indeed works correctly and to avoid future regressions. Since we're compiling
-this to WASM, we cannot simply use Rust's standard `[test]` attribute; instead,
-we need to use the
-[`wasm-bindgen` crate](https://crates.io/crates/wasm-bindgen):
+Having written the above code, of course we'd like to test it as well to ensure it indeed works correctly and to avoid future regressions. Since we're compiling this to WASM, we cannot simply use Rust's standard `[test]` attribute; instead, we need to use the [`wasm-bindgen` crate](https://crates.io/crates/wasm-bindgen):
 
 ```rust
 use wasm_bindgen_test::*;
@@ -257,21 +195,13 @@ async fn it_works() {
 }
 ```
 
-To run the tests in a headless Chrome instance, we use the
-[`wasm-pack` crate](https://crates.io/crates/wasm-pack):
+To run the tests in a headless Chrome instance, we use the [`wasm-pack` crate](https://crates.io/crates/wasm-pack):
 
 ```bash
 wasm-pack test --headless --chrome
 ```
 
-The next challenge is that we don't want the code to actually request the
-Sendgrid API and send out real emails during tests. Thus, we need to mock those
-API calls – however, the problem there is that the available crates for mocking
-HTTP requests do not work in WASM. So we need to find another approach for
-mocking out Sendgrid. A straight-forward approach is to just move the code we
-want to mock into its own function and then pass that in to the `send_message`
-function. With that structure, we can simply pass a different function that does
-not actually call the Sendgrid API in the tests:
+The next challenge is that we don't want the code to actually request the Sendgrid API and send out real emails during tests. Thus, we need to mock those API calls – however, the problem there is that the available crates for mocking HTTP requests do not work in WASM. So we need to find another approach for mocking out Sendgrid. A straight-forward approach is to just move the code we want to mock into its own function and then pass that in to the `send_message` function. With that structure, we can simply pass a different function that does not actually call the Sendgrid API in the tests:
 
 ```rust
 #[event(fetch, respond_with_errors)]
@@ -347,15 +277,7 @@ async fn request_sendgrid(api_key: &str, data: String) -> Result<u16, NetworkErr
 }
 ```
 
-Here we extracted a function `request_sendgrid` that encapsulates the code that
-calls the Sendgrid API and that we don't want to run during tests. The
-`send_message` function's signature has been changed so that it accepts a
-function argument it will call to make the request. The worker's request handler
-in the router simply passes in the `request_sendgrid` function to
-`send_message`. So overall, nothing has really changed and everything works
-exactly as it did before. But in the tests, we can now pass in our own function
-that will not actually request the Sendgrid API, but rather returns a response
-right away:
+Here we extracted a function `request_sendgrid` that encapsulates the code that calls the Sendgrid API and that we don't want to run during tests. The `send_message` function's signature has been changed so that it accepts a function argument it will call to make the request. The worker's request handler in the router simply passes in the `request_sendgrid` function to `send_message`. So overall, nothing has really changed and everything works exactly as it did before. But in the tests, we can now pass in our own function that will not actually request the Sendgrid API, but rather returns a response right away:
 
 ```rust
 use mainmatter_website_mailer::{send_message, NetworkError, Payload};
@@ -381,20 +303,8 @@ async fn it_works_for_the_happy_path() {
 }
 ```
 
-Using this approach, we can of course also assert that the correct request body
-is sent to the Sendgrid API, errors are handled correctly, etc. Refer to the
-[GitHub repository](https://github.com/mainmatter/mainmatter-website-mailer/blob/main/tests/send_message.rs)
-for the complete test suite.
+Using this approach, we can of course also assert that the correct request body is sent to the Sendgrid API, errors are handled correctly, etc. Refer to the [GitHub repository](https://github.com/mainmatter/mainmatter-website-mailer/blob/main/tests/send_message.rs) for the complete test suite.
 
 ## Should you do this?
 
-One question that remains is whether Rust/WASM is really needed here. You could
-argue this isn't a reasonable use case for Rust/WASM and you'd probably be
-right. We wrote a simply proxy service (for which we also don't expect a lot of
-traffic) where performance is almost entirely bound by network IO – there's no
-computationally expensive processing going on (you could argue almost no
-processing at all) – which would typically be the main reason why you'd choose
-Rust/WASM. However, [we love Rust](/rust-consulting/) and wouldn't have wanted
-to let an opportunity to use it pass unused. So in short, would we recommend
-people to implement their mailers in Rust? – maybe not, just using JavaScript
-might be simpler. Was it fun writing this? Yes, definitely 😍
+One question that remains is whether Rust/WASM is really needed here. You could argue this isn't a reasonable use case for Rust/WASM and you'd probably be right. We wrote a simply proxy service (for which we also don't expect a lot of traffic) where performance is almost entirely bound by network IO – there's no computationally expensive processing going on (you could argue almost no processing at all) – which would typically be the main reason why you'd choose Rust/WASM. However, [we love Rust](/rust-consulting/) and wouldn't have wanted to let an opportunity to use it pass unused. So in short, would we recommend people to implement their mailers in Rust? – maybe not, just using JavaScript might be simpler. Was it fun writing this? Yes, definitely 😍
diff --git a/src/posts/2023-01-24-sveltekit-super-rentals.md b/src/posts/2023-01-24-sveltekit-super-rentals.md
index 41d1d71f76..a5fa79fc89 100644
--- a/src/posts/2023-01-24-sveltekit-super-rentals.md
+++ b/src/posts/2023-01-24-sveltekit-super-rentals.md
@@ -3,9 +3,7 @@ title: "A practical first look at the Svelte framework"
 authorHandle: beerinho
 tags: [svelte]
 bio: "Daniel Beer"
-description:
-  "Taking a practical look at the Svelte framework by rebuilding the Ember super
-  rentals app in SvelteKit."
+description: "Taking a practical look at the Svelte framework by rebuilding the Ember super rentals app in SvelteKit."
 og:
   image: /assets/images/posts/2023-01-24-sveltekit-super-rentals/og-image.jpg
 tagline: |
@@ -15,58 +13,33 @@ image: "/assets/images/posts/2023-01-24-sveltekit-super-rentals/header-illustrat
 imageAlt: "The Svelte logo on a gray background picture"
 ---
 
-{% raw %} As with all new JS frameworks, there is a big buzz surrounding
-SvelteKit, and for good reason, its underlying library - SvelteJS - has been
-consistently popular since it emerged in 2019 (according to the
-[stateofjs polls](https://2021.stateofjs.com/en-US/libraries/front-end-frameworks))
-and it looks like that popularity is only increasing.
-
-And like all new JS frameworks, it’s also difficult to understand the benefits
-and drawbacks of a new technology without getting hands-on with it, and with
-SvelteKit releasing version 1.0 and becoming "production ready", now is the
-perfect time to jump in and see how it fares against EmberJS.
-
-The Svelte site has a nice
-[Tutorial playground area](https://svelte.dev/tutorial/basics) that is useful to
-understand the concepts behind the library. However, because it is focused on
-the component side of Svelte (as opposed to the framework, SvelteKit), there
-isn’t any formal guide to help you get up and running with a real world
-application using SvelteKit. Thankfully, EmberJS has a fairly thorough
-[Tutorial](https://guides.emberjs.com/release/tutorial/part-1/) that is great
-for introducing the principles of the framework; so we will be cross-pollinating
-and using SvelteKit to build the Ember-Super-Rentals demo app. And while we’re
-at it, we can also draw some comparisons between the frameworks.
-
-This is what we will have by the end of this tutorial:
-![Screenshot of finished super-rentals app](/assets/images/posts/2023-01-24-sveltekit-super-rentals/finished-app.png)
-
-I have broken this demo app down into the same chunks as is done in the Ember
-Super Rentals tutorial, so feel free to follow along with both tutorials at the
-same time.
-
-You can also find snapshots of this tutorial as separate tags in the
-[github repo](https://github.com/mainmatter/sveltekit-super-rentals/tags).
-
-To see the final app on Netlify, click
-[here](https://sveltekit-super-rentals.netlify.app/).
+{% raw %} As with all new JS frameworks, there is a big buzz surrounding SvelteKit, and for good reason, its underlying library - SvelteJS - has been consistently popular since it emerged in 2019 (according to the [stateofjs polls](https://2021.stateofjs.com/en-US/libraries/front-end-frameworks)) and it looks like that popularity is only increasing.
+
+And like all new JS frameworks, it’s also difficult to understand the benefits and drawbacks of a new technology without getting hands-on with it, and with SvelteKit releasing version 1.0 and becoming "production ready", now is the perfect time to jump in and see how it fares against EmberJS.
+
+The Svelte site has a nice [Tutorial playground area](https://svelte.dev/tutorial/basics) that is useful to understand the concepts behind the library. However, because it is focused on the component side of Svelte (as opposed to the framework, SvelteKit), there isn’t any formal guide to help you get up and running with a real world application using SvelteKit. Thankfully, EmberJS has a fairly thorough [Tutorial](https://guides.emberjs.com/release/tutorial/part-1/) that is great for introducing the principles of the framework; so we will be cross-pollinating and using SvelteKit to build the Ember-Super-Rentals demo app. And while we’re at it, we can also draw some comparisons between the frameworks.
+
+This is what we will have by the end of this tutorial: ![Screenshot of finished super-rentals app](/assets/images/posts/2023-01-24-sveltekit-super-rentals/finished-app.png)
+
+I have broken this demo app down into the same chunks as is done in the Ember Super Rentals tutorial, so feel free to follow along with both tutorials at the same time.
+
+You can also find snapshots of this tutorial as separate tags in the [github repo](https://github.com/mainmatter/sveltekit-super-rentals/tags).
+
+To see the final app on Netlify, click [here](https://sveltekit-super-rentals.netlify.app/).
 
 ## Let’s get started
 
 To kick things off, let’s create a new blank SvelteKit project.
 
-We’re going to skip TypeScript because, to quote Sweet Brown, “Ain’t nobody got
-time for that”. The rest of it is fairly straightforward, we will create a new
-project with the command:
+We’re going to skip TypeScript because, to quote Sweet Brown, “Ain’t nobody got time for that”. The rest of it is fairly straightforward, we will create a new project with the command:
 
 ```
 npm create svelte@latest svelte-super-rentals
 ```
 
-And when prompted, we will opt in for ESLint and Prettier to keep our code
-looking nice and uniform.
+And when prompted, we will opt in for ESLint and Prettier to keep our code looking nice and uniform.
 
-We will also opt in for Playwright browser testing. There is the option to add
-Vitest for unit testing. but for this tutorial we will just use Playwright.
+We will also opt in for Playwright browser testing. There is the option to add Vitest for unit testing. but for this tutorial we will just use Playwright.
 
 ```bash
 Repos % npm create svelte@latest svelte-super-rentals
@@ -164,21 +137,13 @@ And just like that, we have an empty SvelteKit project!
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/1.1-orientation)
 
-To keep this simple, we’re going to use the styles and assets from the
-Ember-Super-Rentals app and just copy them over into our project. I won’t paste
-them in here as the style sheet is pretty big and not worth the page space. If
-you want to see it, feel free to check out the repo on GitHub.
+To keep this simple, we’re going to use the styles and assets from the Ember-Super-Rentals app and just copy them over into our project. I won’t paste them in here as the style sheet is pretty big and not worth the page space. If you want to see it, feel free to check out the repo on GitHub.
 
-The [Tomster image](https://guides.emberjs.com/downloads/teaching-tomster.png)
-will go into a newly created `images` folder inside the `static` folder that was
-created by SvelteKit.
+The [Tomster image](https://guides.emberjs.com/downloads/teaching-tomster.png) will go into a newly created `images` folder inside the `static` folder that was created by SvelteKit.
 
-The
-[Styles](https://github.com/ember-learn/super-rentals/blob/super-rentals-tutorial-output/app/styles/app.css)
-will also go in the `static` folder, but just in a file we will name `app.css`.
+The [Styles](https://github.com/ember-learn/super-rentals/blob/super-rentals-tutorial-output/app/styles/app.css) will also go in the `static` folder, but just in a file we will name `app.css`.
 
-We will then update the `routes/+page.svelte` component so that we can see the
-basic shape of the site as well as the image of the Tomster.
+We will then update the `routes/+page.svelte` component so that we can see the basic shape of the site as well as the image of the Tomster.
 
 ```html
 // routes/+page.svelte
@@ -191,17 +156,13 @@ basic shape of the site as well as the image of the Tomster.
 </div>
 ```
 
-And when we serve the app we are greeted by the friendly face of Tomster but it
-doesn’t do much yet.
+And when we serve the app we are greeted by the friendly face of Tomster but it doesn’t do much yet.
 
 ![Screenshot of the state of the app after 'orientation'](/assets/images/posts/2023-01-24-sveltekit-super-rentals/end-of-orientation.png)
 
-Before we get into adding pages and components, I wanted a point out a couple of
-small “quality of life” adaptations to make the workflow easier going forward.
+Before we get into adding pages and components, I wanted a point out a couple of small “quality of life” adaptations to make the workflow easier going forward.
 
-I updated the playwright config to use a fixed port so that if we are running
-the app (either through `npm run dev` or `npm run test`) we know which port we
-will be on; I then updated the vite config to reflect that same port.
+I updated the playwright config to use a fixed port so that if we are running the app (either through `npm run dev` or `npm run test`) we know which port we will be on; I then updated the vite config to reflect that same port.
 
 ```js
 // playwright.config.js
@@ -240,9 +201,7 @@ const config = {
 export default config;
 ```
 
-I also added the global styles sheet to the `app.html` so that the styles are
-automatically applied to all pages and components, and I can use the global
-classes from wherever needed.
+I also added the global styles sheet to the `app.html` so that the styles are automatically applied to all pages and components, and I can use the global classes from wherever needed.
 
 ```html
 <!-- app.html -->
@@ -268,29 +227,15 @@ classes from wherever needed.
 
 ---
 
-Please do not try to send messages to the email on the contact page, I randomly
-assigned the email address so your email won’t be seen by anyone and will most
-likely just bounce back to you.
+Please do not try to send messages to the email on the contact page, I randomly assigned the email address so your email won’t be seen by anyone and will most likely just bounce back to you.
 
 ---
 
-When it comes to creating routes, there isn’t the same extensive CLI that Ember
-has, so instead we need to manually add the routes that we want in a folder
-structure. So for this example we will be creating `+page.svelte`,
-`about/+page.svelte` & `getting-in-touch/+page.svelte` inside the `routes`
-folder. Although this isn’t a big pain, it would be nice to have something
-similar to the `ember generate route` command that comes with Ember-CLI. I did
-notice the
-[VS Code plugin](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode)
-offers a way to generate SvelteKit files, though I didn’t find this all that
-useful.
+When it comes to creating routes, there isn’t the same extensive CLI that Ember has, so instead we need to manually add the routes that we want in a folder structure. So for this example we will be creating `+page.svelte`, `about/+page.svelte` & `getting-in-touch/+page.svelte` inside the `routes` folder. Although this isn’t a big pain, it would be nice to have something similar to the `ember generate route` command that comes with Ember-CLI. I did notice the [VS Code plugin](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode) offers a way to generate SvelteKit files, though I didn’t find this all that useful.
 
 ![Screenshot of the sveltekit plugin for VS Code](/assets/images/posts/2023-01-24-sveltekit-super-rentals/sveltekit-plugin-vs-code.png)
 
-In SvelteKit we are missing the ability to create a route and give it a
-different name, so we need to be thoughtful about what we want the name of the
-route to be when creating it, as it is a very manual process to adapt a route
-name after it’s created.
+In SvelteKit we are missing the ability to create a route and give it a different name, so we need to be thoughtful about what we want the name of the route to be when creating it, as it is a very manual process to adapt a route name after it’s created.
 
 ```html
 <!-- routes/about/+page.svelte -->
@@ -335,18 +280,7 @@ name after it’s created.
 </div>
 ```
 
-SvelteKit has an interesting naming convention for routes; we can still have
-nested routes and dynamic routes, but now that they have embraced the folder
-based routing system, it means that each route has its own `+page.svelte` file;
-so instead of having `index` and `about` route files, we have folders -
-`+page.svelte` and `about/+page.svelte`. This has been discussed quite
-thoroughly [here](https://github.com/sveltejs/kit/discussions/5748) and while
-some people weren’t too happy with the decision to move so far from a standard
-web routing structure, it does allow us to store server-side logic in the
-conveniently named `+page.server.js` file (note: this is only run on the
-server), as well as the `+page.js` file which is run both on the client during
-browser navigation, and on the server during SSR. So you end up with a file
-structure like this:
+SvelteKit has an interesting naming convention for routes; we can still have nested routes and dynamic routes, but now that they have embraced the folder based routing system, it means that each route has its own `+page.svelte` file; so instead of having `index` and `about` route files, we have folders - `+page.svelte` and `about/+page.svelte`. This has been discussed quite thoroughly [here](https://github.com/sveltejs/kit/discussions/5748) and while some people weren’t too happy with the decision to move so far from a standard web routing structure, it does allow us to store server-side logic in the conveniently named `+page.server.js` file (note: this is only run on the server), as well as the `+page.js` file which is run both on the client during browser navigation, and on the server during SSR. So you end up with a file structure like this:
 
 ```bash
 routes/
@@ -360,19 +294,15 @@ Which can get a little annoying when you end up with tabs like this in your IDE:
 
 ![screenshot of pages in VS Code](/assets/images/posts/2023-01-24-sveltekit-super-rentals/pages-in-vs-code.png)
 
-But hopefully the trade-off is worth it in exchange for the more concise file
-structure
+But hopefully the trade-off is worth it in exchange for the more concise file structure
 
 ### Automated testing:
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/1.3-automated-testing)
 
-[Playwright](https://playwright.dev/docs/intro) was added automatically when we
-created our SvelteKit app and they seem to work great together.
+[Playwright](https://playwright.dev/docs/intro) was added automatically when we created our SvelteKit app and they seem to work great together.
 
-There is already a single test for Playwright that was created when we set up
-the app called `tests/test.js`; we will replace the content of this soon, but
-for now let’s see what happens when we run this test:
+There is already a single test for Playwright that was created when we set up the app called `tests/test.js`; we will replace the content of this soon, but for now let’s see what happens when we run this test:
 
 ```bash
 svelte-super-rentals % npm run test
@@ -416,10 +346,7 @@ Running 1 test using 1 worker
     tests/test.ts:2:1 › about page has expected h1 =================================================
 ```
 
-As we would expect, this test is failing (after a while) because we are
-expecting to find an `h1` on the page with the text “About this app”, which we
-no longer have since we replaced the default content of the file with the HTML
-for the Super Rentals app.
+As we would expect, this test is failing (after a while) because we are expecting to find an `h1` on the page with the text “About this app”, which we no longer have since we replaced the default content of the file with the HTML for the Super Rentals app.
 
 Now let’s update the test so that is passes.
 
@@ -523,37 +450,27 @@ Running 3 tests using 1 worker
   3 passed (4s)
 ```
 
-Playwright also gives us the ability to pause our tests by adding this line into
-our tests when we want to pause.
+Playwright also gives us the ability to pause our tests by adding this line into our tests when we want to pause.
 
 ```js
 await page.pause();
 ```
 
-To resume the tests, open up the devTools console in the browser and run this
-command:
+To resume the tests, open up the devTools console in the browser and run this command:
 
 ```js
 playwright.resume();
 ```
 
-Otherwise you can use the
-[Playwright inspector](https://playwright.dev/docs/inspector) to open a browser
-along with a more in-depth console that will give you the ability to step
-through your tests and see more detail about the current state of the DOM and
-test.
+Otherwise you can use the [Playwright inspector](https://playwright.dev/docs/inspector) to open a browser along with a more in-depth console that will give you the ability to step through your tests and see more detail about the current state of the DOM and test.
 
 ---
 
-This confused me at first as Playwright will stop at each `await` so you will
-need to manually step through the test until you find the part that you want to
-stop it. It is quite intuitive once you realise it might not have paused where
-you expected to begin with.
+This confused me at first as Playwright will stop at each `await` so you will need to manually step through the test until you find the part that you want to stop it. It is quite intuitive once you realise it might not have paused where you expected to begin with.
 
 ---
 
-To open the inspector when running the tests, be sure to specify the `PWDEBUG=1`
-flag when running the tests:
+To open the inspector when running the tests, be sure to specify the `PWDEBUG=1` flag when running the tests:
 
 ```bash
 PWDEBUG=1 npm run test
@@ -563,10 +480,7 @@ PWDEBUG=1 npm run test
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/1.4-component-basics)
 
-Similar to the routes, there is no command to generate components for us, so we
-will create the `src/components` folder along with the
-`src/components/jumbo.svelte` and `src/components/nav-bar.svelte` component
-files
+Similar to the routes, there is no command to generate components for us, so we will create the `src/components` folder along with the `src/components/jumbo.svelte` and `src/components/nav-bar.svelte` component files
 
 ```html
 <!-- components/jumbo.svelte -->
@@ -577,8 +491,7 @@ files
 </div>
 ```
 
-The `<slot/>` here is similar to the `{{yield}}` in Ember, it allows us to use
-this component as a wrapper for more HTML to be passed in from the parent.
+The `<slot/>` here is similar to the `{{yield}}` in Ember, it allows us to use this component as a wrapper for more HTML to be passed in from the parent.
 
 ```html
 <!-- components/nav-bar.svelte -->
@@ -594,9 +507,7 @@ this component as a wrapper for more HTML to be passed in from the parent.
 </nav>
 ```
 
-I then added the alias to the svelte config to make importing files easier -
-this means instead of having a mess of `../../../..` in the module imports, we
-can use `@components` when importing a component into another file
+I then added the alias to the svelte config to make importing files easier - this means instead of having a mess of `../../../..` in the module imports, we can use `@components` when importing a component into another file
 
 ```js
 // svelte.config.js
@@ -669,31 +580,11 @@ Then we will update our usage of these components in our routes
 </Jumbo>
 ```
 
-As you can see, another difference between SvelteKit and Ember is that Ember has
-chosen to separate the template from the component logic, whereas Svelte has
-opted for the single file approach (although this will be added to Ember soon:
-the
-[RFC](https://github.com/emberjs/rfcs/blob/master/text/0779-first-class-component-templates.md#sfcs)
-has already been approved and merged and we are just waiting for it to be
-released now).
-
-In terms of component usage, both Ember and Svelte have a similar approach but
-slightly differing syntax. Both have opted for more native-looking HTML - Ember
-using HBS, while Svelte has opted to extend native HTML and allow us to write
-pure JavaScript in the template. Coming from Ember I found this aspect of Svelte
-to be quite easy to get to grips with, though the naming of component attributes
-can get a little confusing as there is no `@` syntax that Ember uses, so instead
-of `@image` you would have `image`. I’ll discuss this more in the next section
-“More about components”.
-
-Another big difference between the two is that components are always available
-in Ember and you can simply invoke them in the template, whereas in SvelteKit
-you need to import the component in the script tag before you can use it in the
-template. I like the simplicity of Ember’s approach, but it does mean you can
-end up with quite long component names if your app has a lot of component
-nesting - i.e. `<Ui::Layout::Foo::Bar::TwoColumn::AwesomeComponent/>` - whereas
-you likely don’t have this problem in Svelte because you can simply change the
-name of the component when you import it - i.e.
+As you can see, another difference between SvelteKit and Ember is that Ember has chosen to separate the template from the component logic, whereas Svelte has opted for the single file approach (although this will be added to Ember soon: the [RFC](https://github.com/emberjs/rfcs/blob/master/text/0779-first-class-component-templates.md#sfcs) has already been approved and merged and we are just waiting for it to be released now).
+
+In terms of component usage, both Ember and Svelte have a similar approach but slightly differing syntax. Both have opted for more native-looking HTML - Ember using HBS, while Svelte has opted to extend native HTML and allow us to write pure JavaScript in the template. Coming from Ember I found this aspect of Svelte to be quite easy to get to grips with, though the naming of component attributes can get a little confusing as there is no `@` syntax that Ember uses, so instead of `@image` you would have `image`. I’ll discuss this more in the next section “More about components”.
+
+Another big difference between the two is that components are always available in Ember and you can simply invoke them in the template, whereas in SvelteKit you need to import the component in the script tag before you can use it in the template. I like the simplicity of Ember’s approach, but it does mean you can end up with quite long component names if your app has a lot of component nesting - i.e. `<Ui::Layout::Foo::Bar::TwoColumn::AwesomeComponent/>` - whereas you likely don’t have this problem in Svelte because you can simply change the name of the component when you import it - i.e.
 
 ```html
 <script>
@@ -705,24 +596,13 @@ name of the component when you import it - i.e.
 
 ---
 
-_Note: The
-[RFC](https://github.com/emberjs/rfcs/blob/master/text/0779-first-class-component-templates.md)
-which proposes to add this to Ember has been approved and merged and we are now
-just awaiting the release._
+_Note: The [RFC](https://github.com/emberjs/rfcs/blob/master/text/0779-first-class-component-templates.md) which proposes to add this to Ember has been approved and merged and we are now just awaiting the release._
 
 ---
 
-It can be argued that Svelte’s approach could lead to more confusion as the
-names can change depending on how they are imported, meaning it’s not
-immediately obvious which component is which; although this isn't the strongest
-argument as this issue could easily be mitigated by using good naming
-conventions or implementing a lint rule for this.
+It can be argued that Svelte’s approach could lead to more confusion as the names can change depending on how they are imported, meaning it’s not immediately obvious which component is which; although this isn't the strongest argument as this issue could easily be mitigated by using good naming conventions or implementing a lint rule for this.
 
-We also created the `<NavBar>`, which we want to be visible on all pages,
-instead of adding it individually to each page component, we will create a
-`+layout.svelte` component instead. The layout component sits in the nesting
-structure just like the `pages` and will apply a layout to all children routes
-unless otherwise specified.
+We also created the `<NavBar>`, which we want to be visible on all pages, instead of adding it individually to each page component, we will create a `+layout.svelte` component instead. The layout component sits in the nesting structure just like the `pages` and will apply a layout to all children routes unless otherwise specified.
 
 ```html
 <!-- routes/+layout.svelte -->
@@ -735,26 +615,13 @@ unless otherwise specified.
 <slot />
 ```
 
-As mentioned, this will apply the `<NavBar/>` to all pages. The `<slot/>` is
-required and is similar to the `{{outlet}}` in Ember, which allows child routes
-to render content into a specific area of the parent route.
+As mentioned, this will apply the `<NavBar/>` to all pages. The `<slot/>` is required and is similar to the `{{outlet}}` in Ember, which allows child routes to render content into a specific area of the parent route.
 
-If we wanted a different layout for just the `about` page, we could create
-another layout in `routes/about/+layout.svelte` and that would not impact the
-other routes, but would apply a separate layout to all routes nested with
-`/about`.
+If we wanted a different layout for just the `about` page, we could create another layout in `routes/about/+layout.svelte` and that would not impact the other routes, but would apply a separate layout to all routes nested with `/about`.
 
-SvelteKit doesn’t come with a library for testing standalone components but we
-did opt to include Playwright when setting up the project. I initially wanted to
-implement Playwright’s experimental Component Testing library, but as of the
-time of writing this, there are issues with the library that mean I wasn’t able
-to use it in this project (there are other options for unit testing including
-[Vitest](https://vitest.dev/guide/) but for the sake of brevity I’ll just stick
-to e2e testing using Playwright for this example).
+SvelteKit doesn’t come with a library for testing standalone components but we did opt to include Playwright when setting up the project. I initially wanted to implement Playwright’s experimental Component Testing library, but as of the time of writing this, there are issues with the library that mean I wasn’t able to use it in this project (there are other options for unit testing including [Vitest](https://vitest.dev/guide/) but for the sake of brevity I’ll just stick to e2e testing using Playwright for this example).
 
-Instead of writing out the code, let’s try and use
-[Playwright’s test generator](https://playwright.dev/docs/codegen) with the
-command:
+Instead of writing out the code, let’s try and use [Playwright’s test generator](https://playwright.dev/docs/codegen) with the command:
 
 _Note: make sure your app is already running on the port specified_
 
@@ -762,11 +629,7 @@ _Note: make sure your app is already running on the port specified_
 npx playwright codegen localhost:3000
 ```
 
-or by using the “Testing” tab in VS Code to “Record new test…” with the
-[Playwright add-on](https://marketplace.visualstudio.com/items?itemName=ms-playwright.playwright)
-installed. You can then click around your app and you will notice that all of
-your mouse and keyboard actions are captured and you will end up with an output
-in the Playwright inspector that looks something like this
+or by using the “Testing” tab in VS Code to “Record new test…” with the [Playwright add-on](https://marketplace.visualstudio.com/items?itemName=ms-playwright.playwright) installed. You can then click around your app and you will notice that all of your mouse and keyboard actions are captured and you will end up with an output in the Playwright inspector that looks something like this
 
 ```js
 // Go to http://localhost:3000/
@@ -782,9 +645,7 @@ await page.locator('h1:has-text("SuperRentals")').click();
 await expect(page).toHaveURL("http://localhost:3000/");
 ```
 
-Let’s just clean it up a little so we aren’t referencing http://localhost:3000
-directly (referencing localhost:3000 will still work but it just means we will
-always have to use port 3000 for our tests which could cause issues)
+Let’s just clean it up a little so we aren’t referencing http://localhost:3000 directly (referencing localhost:3000 will still work but it just means we will always have to use port 3000 for our tests which could cause issues)
 
 ```js
 // Go to the index route
@@ -800,20 +661,13 @@ await page.locator('h1:has-text("SuperRentals")').click();
 await expect(page).toHaveURL("/");
 ```
 
-While using the Playwright test generator, I loved the simplicity of being able
-to use the UI to test the things that I wanted to assure were actually working
-in the UI, so from this aspect I found it really useful. The main downside I
-found to using the test generator was that it wasn’t so simple to test that
-something was visible. To get around this it required clicking on a
-non-interactive element and then adjusting the test to test the content rather
-than just clicking on the element.
+While using the Playwright test generator, I loved the simplicity of being able to use the UI to test the things that I wanted to assure were actually working in the UI, so from this aspect I found it really useful. The main downside I found to using the test generator was that it wasn’t so simple to test that something was visible. To get around this it required clicking on a non-interactive element and then adjusting the test to test the content rather than just clicking on the element.
 
 ### More about components
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/1.5-more-about-components)
 
-Now let’s create some components that will receive parameters to be handled by
-the component.
+Now let’s create some components that will receive parameters to be handled by the component.
 
 ```html
 <!-- components/rental/image.svelte -->
@@ -828,24 +682,11 @@ the component.
 </div>
 ```
 
-A big difference between Ember and SvelteKit here is that Svelte requires you to
-express which parameters are expected by the component using the `export let`
-syntax. Coming from a JS background, it’s a little confusing to use `export` in
-this way, but in general I prefer having to define the parameters over Glimmers'
-way of have the `this.args` object that can be of any shape. Though this can get
-confusing in Svelte when you have bigger components with more internal as well
-as external attributes, with Svelte it isn’t always clear if the attribute is
-external or internal, whereas the `@`/`this` syntax used in Ember gives a
-clearer distinction here.
-
-`<img {src} {alt} />` is making use of Svelte’s shorthand mechanism: if the
-attribute you are setting has the same name as the variable, you can omit the
-element attribute and Svelte will figure it out for you. This could also be
-expressed as `<img src={src} alt={alt} />`.
-
-Using the new `<RentalImage>` component, let’s create the `<Rental>` component,
-which will just be hardcoded for now to give is some information to see on
-screen.
+A big difference between Ember and SvelteKit here is that Svelte requires you to express which parameters are expected by the component using the `export let` syntax. Coming from a JS background, it’s a little confusing to use `export` in this way, but in general I prefer having to define the parameters over Glimmers' way of have the `this.args` object that can be of any shape. Though this can get confusing in Svelte when you have bigger components with more internal as well as external attributes, with Svelte it isn’t always clear if the attribute is external or internal, whereas the `@`/`this` syntax used in Ember gives a clearer distinction here.
+
+`<img {src} {alt} />` is making use of Svelte’s shorthand mechanism: if the attribute you are setting has the same name as the variable, you can omit the element attribute and Svelte will figure it out for you. This could also be expressed as `<img src={src} alt={alt} />`.
+
+Using the new `<RentalImage>` component, let’s create the `<Rental>` component, which will just be hardcoded for now to give is some information to see on screen.
 
 ```html
 <!-- components/rental/index.svelte -->
@@ -927,10 +768,7 @@ Now let’s add the ability to toggle the size of the image on click.
 {/if}
 ```
 
-This syntax will look very similar to that of Ember, with a few minor changes:
-instead of relying on Glimmer’s `{{on}}` modifier, we user Svelte’s `on:`
-modifier. Then instead of using an `@action` to link the template to the JS as
-we would in Ember, we simply call a regular JS function.
+This syntax will look very similar to that of Ember, with a few minor changes: instead of relying on Glimmer’s `{{on}}` modifier, we user Svelte’s `on:` modifier. Then instead of using an `@action` to link the template to the JS as we would in Ember, we simply call a regular JS function.
 
 But as you can see, the conditional syntax is very similar, where Ember has
 
@@ -956,21 +794,11 @@ Svelte has
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/1.7-reusable-components)
 
-Now, let’s add an external API. For this we will need a Mapbox account and to
-create an access token. You can do so [here](https://www.mapbox.com/signup/).
+Now, let’s add an external API. For this we will need a Mapbox account and to create an access token. You can do so [here](https://www.mapbox.com/signup/).
 
-Because we don’t have the full `environment` config that is present in Ember
-applications, we will need to store our Mapbox access token elsewhere. We could
-do this in a number of places (e.g. in a store, or in the component) but for
-this example, we will use the suggested route. We will create a `.env` file in
-the root of our project and add `PUBLIC_MAPBOX_TOKEN = 'your_access_token’`. It
-is also important to start the key with `PUBLIC_` so that SvelteKit is aware
-that this token is public and will bundle it with all other static public keys
-that can be accessed through `'$env/static/public'`(for more information, read
-[here](https://kit.svelte.dev/docs/modules#$env-static-public)).
+Because we don’t have the full `environment` config that is present in Ember applications, we will need to store our Mapbox access token elsewhere. We could do this in a number of places (e.g. in a store, or in the component) but for this example, we will use the suggested route. We will create a `.env` file in the root of our project and add `PUBLIC_MAPBOX_TOKEN = 'your_access_token’`. It is also important to start the key with `PUBLIC_` so that SvelteKit is aware that this token is public and will bundle it with all other static public keys that can be accessed through `'$env/static/public'`(for more information, read [here](https://kit.svelte.dev/docs/modules#$env-static-public)).
 
-Now that we have the access token stored in our app, we can use it in our new
-`<Map>` component
+Now that we have the access token stored in our app, we can use it in our new `<Map>` component
 
 ```html
 <!-- components/map.svelte -->
@@ -999,24 +827,15 @@ Now that we have the access token stored in our app, we can use it in our new
 
 ---
 
-As you can see, the `img` tag uses the shorthand that was explained earlier in
-the “More about components” section.
+As you can see, the `img` tag uses the shorthand that was explained earlier in the “More about components” section.
 
 ---
 
-There are a couple of things to unwrap in this component. The first is that we
-have two `script` tags: the first has `context="module"`, which means it is only
-instantiated once in the application and the variables will not change. This is
-useful because the `token` and `MAPBOX_API` attributes will be the same for
-every instantiation of the component within our app.
+There are a couple of things to unwrap in this component. The first is that we have two `script` tags: the first has `context="module"`, which means it is only instantiated once in the application and the variables will not change. This is useful because the `token` and `MAPBOX_API` attributes will be the same for every instantiation of the component within our app.
 
-The second `script` is not a module, which means the properties within it can
-change between instances. This is important as we will be using this component
-in multiple places to show the different locations of our rentals.
+The second `script` is not a module, which means the properties within it can change between instances. This is important as we will be using this component in multiple places to show the different locations of our rentals.
 
-The next big difference is the `$` - this defines a computed property which will
-be updated and cause a re-render in the component when it changes. This is very
-similar to a `get` in Ember or a `@tracked` property in Glimmer.
+The next big difference is the `$` - this defines a computed property which will be updated and cause a re-render in the component when it changes. This is very similar to a `get` in Ember or a `@tracked` property in Glimmer.
 
 So in Ember this line would look like:
 
@@ -1033,13 +852,9 @@ or
   src = `${MAPBOX_API}/${this.args.lng},${this.args.lat},${this.args.zoom}/${this.args.width}x${this.args.height}@2x?access_token=${PUBLIC_MAPBOX_TOKEN}`
 ```
 
-_(I noticed that none of this was actually required as the attributes don’t ever
-change after the component is rendered, so this could be a variable on the
-component, but to keep this tutorial in line with the Ember Super Rentals
-tutorial, we’ll keep it this way.)_
+_(I noticed that none of this was actually required as the attributes don’t ever change after the component is rendered, so this could be a variable on the component, but to keep this tutorial in line with the Ember Super Rentals tutorial, we’ll keep it this way.)_
 
-We can then add this new Map component to the bottom of the `article` on our
-`<Rental>` component:
+We can then add this new Map component to the bottom of the `article` on our `<Rental>` component:
 
 ```html
 <!-- components/rental/index.svelte -->
@@ -1065,8 +880,7 @@ We can then add this new Map component to the bottom of the `article` on our
 
 (For now we will just hardcode the details of the map component.)
 
-Finally, let’s update our index page test to expect to see three of these
-components
+Finally, let’s update our index page test to expect to see three of these components
 
 ```js
 // tests/test.js
@@ -1086,19 +900,9 @@ test('visiting /', async ({ page }) => {
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/1.8-working-with-data)
 
-Now we have some nice-looking components but they’re not very interesting yet.
-The component is hardcoded with the rental information which means we just have
-three of the same thing visible. So lets start populating our app with some
-dynamic data - usually this would be populated from a server, but we will be
-sticking with the Ember-super-rentals tutorial and store it inside our app as
-JSON files, you can download the required files
-[here](https://guides.emberjs.com/downloads/data.zip).
+Now we have some nice-looking components but they’re not very interesting yet. The component is hardcoded with the rental information which means we just have three of the same thing visible. So lets start populating our app with some dynamic data - usually this would be populated from a server, but we will be sticking with the Ember-super-rentals tutorial and store it inside our app as JSON files, you can download the required files [here](https://guides.emberjs.com/downloads/data.zip).
 
-As this data isn’t going to change, and we want it to be available in our app
-build, I’m going to store it inside the `static` directory in a new folder
-called `api` alongside our `images` folder. (You can call this folder whatever
-you like, “api” isn’t a special name here), then inside the folder we will have
-our rentals data:
+As this data isn’t going to change, and we want it to be available in our app build, I’m going to store it inside the `static` directory in a new folder called `api` alongside our `images` folder. (You can call this folder whatever you like, “api” isn’t a special name here), then inside the folder we will have our rentals data:
 
 ```
 static/
@@ -1110,11 +914,9 @@ static/
       urban-living.json
 ```
 
-I’ve used the slugs of each rental as the name to make it easier to reference
-and retrieve the file when we “load” the data.
+I’ve used the slugs of each rental as the name to make it easier to reference and retrieve the file when we “load” the data.
 
-As with the `@components` alias, I’ll add the same for the api files to make
-them easier to reference.
+As with the `@components` alias, I’ll add the same for the api files to make them easier to reference.
 
 ```js
 // svelte.config.js
@@ -1127,14 +929,7 @@ them easier to reference.
   ...
 ```
 
-Now we can introduce one of the strengths of SvelteKit, the `+page.server.js`
-file. This can be added to any page in your application that needs to trigger
-something on the server - usually loading/saving data. And this is only run on
-the server, which means you can expose sensitive credentials here without the
-client ever knowing about them. We don’t have any sensitive information in our
-app but it also gives us the benefit of having all of the data loaded and in the
-page source which means that search engine bots are able to crawl it easier,
-increasing its SEO score.
+Now we can introduce one of the strengths of SvelteKit, the `+page.server.js` file. This can be added to any page in your application that needs to trigger something on the server - usually loading/saving data. And this is only run on the server, which means you can expose sensitive credentials here without the client ever knowing about them. We don’t have any sensitive information in our app but it also gives us the benefit of having all of the data loaded and in the page source which means that search engine bots are able to crawl it easier, increasing its SEO score.
 
 ```js
 // routes/+page.server.js
@@ -1163,16 +958,11 @@ export const load = () => {
 
 ---
 
-The `load` function is used to load the relevant data for the page and should
-return an object of the data but can also return a redirect or an error. In this
-scenario, we are mapping the rentals from the `static/api/rentals.json` and
-adding the `type` attribute.
+The `load` function is used to load the relevant data for the page and should return an object of the data but can also return a redirect or an error. In this scenario, we are mapping the rentals from the `static/api/rentals.json` and adding the `type` attribute.
 
 ---
 
-Then to make it available in the page template, we can add it as an expected
-import in the `+page.svelte` file and then replace the hardcoded rentals in the
-template.
+Then to make it available in the page template, we can add it as an expected import in the `+page.svelte` file and then replace the hardcoded rentals in the template.
 
 ```diff-js
 // routes/+page.svelte
@@ -1194,13 +984,9 @@ template.
 ...
 ```
 
-Coming from an Ember background, the `each` block in the template looks very
-familiar and achieves the same goal, looping through the array of rentals and
-passing each rental into the Rental component.
+Coming from an Ember background, the `each` block in the template looks very familiar and achieves the same goal, looping through the array of rentals and passing each rental into the Rental component.
 
-We can then update the `<Rental>` component to receive the rental and use its
-attributes to display the details of the rental instead of the hardcoded data we
-had before
+We can then update the `<Rental>` component to receive the rental and use its attributes to display the details of the rental instead of the hardcoded data we had before
 
 ```diff-js
 // components/rental/index.svelte
@@ -1255,8 +1041,7 @@ had before
 
 ![Screenshot of the current state of the app](/assets/images/posts/2023-01-24-sveltekit-super-rentals/end-of-part-1.png)
 
-And now we have a lovely looking index page that shows us the data for each of
-our rentals.
+And now we have a lovely looking index page that shows us the data for each of our rentals.
 
 Next stop: individual rental pages.
 
@@ -1266,13 +1051,7 @@ Next stop: individual rental pages.
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/2.1-route-params)
 
-To be able to show details of an individual rental, we will be using route
-params to decide which rental we need to load the data for; for this we will
-need to create a new route - `rentals/[slug]/+page.svelte` - the square brackets
-here mean that this section of the url is dynamic, it can be named anything we
-want, but I think “slug” makes the most sense here. And because we need to load
-the data for the rental, we will also be creating a
-`rentals/[slug]/+page.server.js` file.
+To be able to show details of an individual rental, we will be using route params to decide which rental we need to load the data for; for this we will need to create a new route - `rentals/[slug]/+page.svelte` - the square brackets here mean that this section of the url is dynamic, it can be named anything we want, but I think “slug” makes the most sense here. And because we need to load the data for the rental, we will also be creating a `rentals/[slug]/+page.server.js` file.
 
 ```js
 // rentals/[slug]/+page.server.js
@@ -1303,21 +1082,13 @@ export async function load({ params }) {
 }
 ```
 
-We are using the `load` function just as we did in the last section, but this
-time `load` receives an object with the attribute `{ params }` and inside that
-object we can find all of the parameters from the route, in this case we are
-just interested in the `slug` as this is what we will use to find the current
-rental.
+We are using the `load` function just as we did in the last section, but this time `load` receives an object with the attribute `{ params }` and inside that object we can find all of the parameters from the route, in this case we are just interested in the `slug` as this is what we will use to find the current rental.
 
-Because of the way that the imports are handled on the server, we aren’t able to
-access a file using a dynamic name directly, so what we do here instead is get
-all of the files from `@api/rentals/*.json` and then go through that array to
-find the rental of the route we are currently on.
+Because of the way that the imports are handled on the server, we aren’t able to access a file using a dynamic name directly, so what we do here instead is get all of the files from `@api/rentals/*.json` and then go through that array to find the rental of the route we are currently on.
 
 ---
 
-This isn’t ideal, and the loading would normally be done by our back-end, but
-for the limited number of rentals we have, this works nicely.
+This isn’t ideal, and the loading would normally be done by our back-end, but for the limited number of rentals we have, this works nicely.
 
 ---
 
@@ -1389,16 +1160,9 @@ We can then create a page to display this data
 </article>
 ```
 
-As before, we’ll use a `script` tag with `context=”module”` to import things
-that won’t change between instances of the page, and a `script` without the
-context for the attributes that can change. You’ll notice here that we are
-expanding the `data` object and assigning `data.rental` to its own property to
-make it easier to reference in the template. We will implement the “Share on
-Twitter” button later so this is just a placeholder for now.
+As before, we’ll use a `script` tag with `context=”module”` to import things that won’t change between instances of the page, and a `script` without the context for the attributes that can change. You’ll notice here that we are expanding the `data` object and assigning `data.rental` to its own property to make it easier to reference in the template. We will implement the “Share on Twitter” button later so this is just a placeholder for now.
 
-We also need to be able to add a class to the `<Map>` component so that it can
-be styled from the parent, so to do this we will add a new attribute to the
-component.
+We also need to be able to add a class to the `<Map>` component so that it can be styled from the parent, so to do this we will add a new attribute to the component.
 
 ```diff-js
 // components/map.svelte
@@ -1417,16 +1181,9 @@ component.
 ...
 ```
 
-This allows us to add a class to the component from the parent, but because the
-class encapsulation doesn’t work here, we still need to use a global class (like
-the ones we defined in the `global.css`) or use the `:global()` css selector
-which means we need to be careful to make this selector specific so it doesn’t
-leak into other styles. This emphasised how useful Glimmer’s `...attributes`
-syntax is, where you can simply pass any attributes you want from parent to
-child component.
+This allows us to add a class to the component from the parent, but because the class encapsulation doesn’t work here, we still need to use a global class (like the ones we defined in the `global.css`) or use the `:global()` css selector which means we need to be careful to make this selector specific so it doesn’t leak into other styles. This emphasised how useful Glimmer’s `...attributes` syntax is, where you can simply pass any attributes you want from parent to child component.
 
-To give users access to the individual rental detail page, we will update the
-`<Rental>` component to contain a link to the rental detail page
+To give users access to the individual rental detail page, we will update the `<Rental>` component to contain a link to the rental detail page
 
 ```diff-js
 // components/rental/index.svelte
@@ -1444,10 +1201,7 @@ To give users access to the individual rental detail page, we will update the
   ...
 ```
 
-I personally prefer to use `slug` for a human-readable identifier, whereas the
-Ember-super-rentals tutorial references this as the `id`, so here we are linking
-to the `rentals/{rental.id}` which equates to `rentals/grand-old-mansion` as an
-example.
+I personally prefer to use `slug` for a human-readable identifier, whereas the Ember-super-rentals tutorial references this as the `id`, so here we are linking to the `rentals/{rental.id}` which equates to `rentals/grand-old-mansion` as an example.
 
 Finally, we will add a couple of new tests to test this new functionality
 
@@ -1488,10 +1242,7 @@ test('visiting /rentals/grand-old-mansion', async ({ page }) => {
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/2.2-service-injection)
 
-Let’s continue by replacing that placeholder “Share to Twitter” button we
-created in the last section with a real, working button that can share a tweet
-to Twitter. First, we’ll create a new component to house all of this Twitter
-logic
+Let’s continue by replacing that placeholder “Share to Twitter” button we created in the last section with a real, working button that can share a tweet to Twitter. First, we’ll create a new component to house all of this Twitter logic
 
 ```js
 // components/share-button.svelte
@@ -1535,15 +1286,11 @@ logic
 
 ---
 
-The `onMount` function here is very similar to Glimmer components' constructors,
-this is where you store the logic that needs to run before the component is
-rendered, in this scenario we will be populating the URL that we will need to
-create a tweet to share the rental we are looking at.
+The `onMount` function here is very similar to Glimmer components' constructors, this is where you store the logic that needs to run before the component is rendered, in this scenario we will be populating the URL that we will need to create a tweet to share the rental we are looking at.
 
 ---
 
-We will replace the placeholder with this new component on the `rentals/[slug]`
-page
+We will replace the placeholder with this new component on the `rentals/[slug]` page
 
 ```diff-js
 // routes/rentals/[slug]/+page.svelte
@@ -1567,8 +1314,7 @@ page
 ...
 ```
 
-And finally we will extend the ‘viewing the details of a rental property’ test
-to check for this button
+And finally we will extend the ‘viewing the details of a rental property’ test to check for this button
 
 ```diff-js
 // tests/test.js
@@ -1591,12 +1337,7 @@ test('viewing the details of a rental property', async ({ page }) => {
   ...
 ```
 
-In the Ember-super-rentals tutorial, there are steps about how to get the Router
-service to allow these tests to pass, but the Router service doesn’t exist in
-SvelteKit in the same way it does in Ember, so we don’t require anything special
-for the tests; Playwright does give us access to the `page` attribute in the
-tests, so it’s nice and simple to grab the current URL from there to compare
-instead of needing to go through the router.
+In the Ember-super-rentals tutorial, there are steps about how to get the Router service to allow these tests to pass, but the Router service doesn’t exist in SvelteKit in the same way it does in Ember, so we don’t require anything special for the tests; Playwright does give us access to the `page` attribute in the tests, so it’s nice and simple to grab the current URL from there to compare instead of needing to go through the router.
 
 ### Ember Data
 
@@ -1608,12 +1349,9 @@ Because we are not using Ember Data, this part of the tutorial can be skipped
 
 [Repo](https://github.com/mainmatter/sveltekit-super-rentals/tree/2.4-provider-components)
 
-And to round things off, we will be adding the ability to filter our rentals
-based on a text search.
+And to round things off, we will be adding the ability to filter our rentals based on a text search.
 
-Because we essentially already have the index route as a component, we won’t
-need to separate out the rentals into their own component as we can easily keep
-track of the searchQuery directly in the index route.
+Because we essentially already have the index route as a component, we won’t need to separate out the rentals into their own component as we can easily keep track of the searchQuery directly in the index route.
 
 ```html
 <!-- components/rentals-filter.svelte -->
@@ -1635,14 +1373,9 @@ track of the searchQuery directly in the index route.
 <slot {results} />
 ```
 
-So here we are expecting an array of rentals and a query, then doing some very
-basic sanitisation on the query, then if there is a query (it’s not blank or
-undefined) we will filter the rentals based on the sanitisedQuery and then pass
-back the results. This is very similar to Ember in the way we can pass a
-property back to the parent component by setting `{{yield results}}`.
+So here we are expecting an array of rentals and a query, then doing some very basic sanitisation on the query, then if there is a query (it’s not blank or undefined) we will filter the rentals based on the sanitisedQuery and then pass back the results. This is very similar to Ember in the way we can pass a property back to the parent component by setting `{{yield results}}`.
 
-We can then update the index page to keep track of the query and utilise the new
-`<RentalsFilter>` component to display only the filtered rentals
+We can then update the index page to keep track of the query and utilise the new `<RentalsFilter>` component to display only the filtered rentals
 
 ```diff-js
 // routes/+page.svelte
@@ -1680,15 +1413,9 @@ We can then update the index page to keep track of the query and utilise the new
 ...
 ```
 
-Svelte doesn’t have anything like an `<Input>` component, so we will be using
-the standard HTML element and use Svelte’s `bind` property to bind our `query`
-property to the `value` of the input. We then receive the `results` from the
-`<RentalsFilter>` component using `let:results` and using it in a similar way to
-Ember’s `<RentalFilters as |results|>` , you can learn more about slot props
-[here](https://svelte.dev/tutorial/slot-props).
+Svelte doesn’t have anything like an `<Input>` component, so we will be using the standard HTML element and use Svelte’s `bind` property to bind our `query` property to the `value` of the input. We then receive the `results` from the `<RentalsFilter>` component using `let:results` and using it in a similar way to Ember’s `<RentalFilters as |results|>` , you can learn more about slot props [here](https://svelte.dev/tutorial/slot-props).
 
-Finally, we will add a couple more tests to cover the new functionality and then
-we are finished!
+Finally, we will add a couple more tests to cover the new functionality and then we are finished!
 
 ```js
 // tests/test.js
@@ -1741,48 +1468,20 @@ test('the index page updates the results according to the search query', async (
 });
 ```
 
-And there we have it, SvelteKit Super Rentals! (It's not covered as part of this
-tutorial, but you can see the final version deployed to Netlify
-[here](https://sveltekit-super-rentals.netlify.app/))
+And there we have it, SvelteKit Super Rentals! (It's not covered as part of this tutorial, but you can see the final version deployed to Netlify [here](https://sveltekit-super-rentals.netlify.app/))
 
 ### Final Thoughts
 
-I really enjoyed getting stuck in with SvelteKit and I can certainly see the
-appeal of it. It’s a very lightweight framework and in a lot of ways it stays
-very close to native JavaScript, which makes me think it would be a really great
-first framework for people that are new to front-end development, because it
-gives you a great understanding of how JavaScript works in a lot of scenarios,
-which will only help when trying out other frameworks in the future. I feel this
-is almost the opposite of Ember: there are a lot of areas of the framework where
-Ember does the heavy lifting for you, which is great for large applications, but
-possibly not the best place to start if you want to build a base knowledge of
-the underlying technologies.
-
-There were a few areas I did think SvelteKit could learn from Ember though. I
-find writing tests is much more enjoyable in Ember, and I think that shines a
-light on SvelteKit’s test suite as a whole. Ember’s qunit integration allows for
-a very simple way to cover your app with unit, integration and acceptance tests.
-It also allows you to run your tests on the "/tests" route, which I really love.
-
-SvelteKit also offers baked-in testing with Vitest (with
-[testing library](https://testing-library.com/docs/svelte-testing-library/intro/))
-and Playwright, but I don't find them quite as intuitive as qunit (but that
-could come down to my background with Ember). Although I have to admit, the
-Playwright test generator is very cool and certainly streamlines the test
-process. I think it still has some areas of improvement though - such as the
-ability to assert textContent or state, rather than just clicking around the
-app.
-
-Ember Data is a very useful way of knowing the structure of the data coming from
-your BE without needing to use TypeScript - TypeScript can be used natively with
-SvelteKit but does come with the standard overhead that TypeScript brings (e.g.
-native web properties that aren’t correctly typed/typed at all).
+I really enjoyed getting stuck in with SvelteKit and I can certainly see the appeal of it. It’s a very lightweight framework and in a lot of ways it stays very close to native JavaScript, which makes me think it would be a really great first framework for people that are new to front-end development, because it gives you a great understanding of how JavaScript works in a lot of scenarios, which will only help when trying out other frameworks in the future. I feel this is almost the opposite of Ember: there are a lot of areas of the framework where Ember does the heavy lifting for you, which is great for large applications, but possibly not the best place to start if you want to build a base knowledge of the underlying technologies.
+
+There were a few areas I did think SvelteKit could learn from Ember though. I find writing tests is much more enjoyable in Ember, and I think that shines a light on SvelteKit’s test suite as a whole. Ember’s qunit integration allows for a very simple way to cover your app with unit, integration and acceptance tests. It also allows you to run your tests on the "/tests" route, which I really love.
+
+SvelteKit also offers baked-in testing with Vitest (with [testing library](https://testing-library.com/docs/svelte-testing-library/intro/)) and Playwright, but I don't find them quite as intuitive as qunit (but that could come down to my background with Ember). Although I have to admit, the Playwright test generator is very cool and certainly streamlines the test process. I think it still has some areas of improvement though - such as the ability to assert textContent or state, rather than just clicking around the app.
+
+Ember Data is a very useful way of knowing the structure of the data coming from your BE without needing to use TypeScript - TypeScript can be used natively with SvelteKit but does come with the standard overhead that TypeScript brings (e.g. native web properties that aren’t correctly typed/typed at all).
 
 Thank you very much for reading, I hope you enjoyed this dive into SvelteKit.
 
-You can see the full repo here:
-[https://github.com/mainmatter/sveltekit-super-rentals/](https://github.com/mainmatter/sveltekit-super-rentals/tags)
+You can see the full repo here: [https://github.com/mainmatter/sveltekit-super-rentals/](https://github.com/mainmatter/sveltekit-super-rentals/tags)
 
-And the breakdown of the individual parts here:
-[https://github.com/mainmatter/sveltekit-super-rentals/tags](https://github.com/mainmatter/sveltekit-super-rentals/tags)
-{% endraw %}
+And the breakdown of the individual parts here: [https://github.com/mainmatter/sveltekit-super-rentals/tags](https://github.com/mainmatter/sveltekit-super-rentals/tags) {% endraw %}
diff --git a/src/posts/2023-02-01-using-rust-crates-in-elixir.md b/src/posts/2023-02-01-using-rust-crates-in-elixir.md
index c550d8d423..a8dd34358d 100644
--- a/src/posts/2023-02-01-using-rust-crates-in-elixir.md
+++ b/src/posts/2023-02-01-using-rust-crates-in-elixir.md
@@ -3,9 +3,7 @@ title: "Rustler - Using Rust crates in Elixir"
 authorHandle: BobrImperator
 tags: [elixir, rust]
 bio: "Software Developer"
-description:
-  "Bartłomiej Dudzik shows how you can use a Rust crate in Elixir using NIFs
-  with Rustler."
+description: "Bartłomiej Dudzik shows how you can use a Rust crate in Elixir using NIFs with Rustler."
 og:
   image: /assets/images/posts/2023-02-01-using-rust-crates-in-elixir/og-image.jpg
 tagline: |
@@ -15,52 +13,30 @@ image: "/assets/images/posts/2023-02-01-using-rust-crates-in-elixir/header-illus
 imageAlt: "The Rust and Elixir logos on a gray backround picture"
 ---
 
-Rust and Elixir work great combined! Rust and Elixir can help you increase
-performance significantly. Discord
-[shared some details on their blog](https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users)
-(and also wrote about
-[why they switched from Go to Rust](https://discord.com/blog/why-discord-is-switching-from-go-to-rust)).
+Rust and Elixir work great combined! Rust and Elixir can help you increase performance significantly. Discord [shared some details on their blog](https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users) (and also wrote about [why they switched from Go to Rust](https://discord.com/blog/why-discord-is-switching-from-go-to-rust)).
 
-In this blog post, I will show you how easily you can build and use small
-programs inside Elixir using Rustler.
+In this blog post, I will show you how easily you can build and use small programs inside Elixir using Rustler.
 
-I recently needed a function to create and edit PDF files with Elixir for a
-small private project. I searched for some packages and the most notable one for
-Elixir is [elixir-pdf](https://github.com/andrewtimberlake/elixir-pdf), but it
-only offers to create PDFs without additional manipulation. That was fine by me
-since I wanted an excuse to do some more things in Rust anyway, and I found
-[lopdf](https://github.com/J-F-Liu/lopdf).
+I recently needed a function to create and edit PDF files with Elixir for a small private project. I searched for some packages and the most notable one for Elixir is [elixir-pdf](https://github.com/andrewtimberlake/elixir-pdf), but it only offers to create PDFs without additional manipulation. That was fine by me since I wanted an excuse to do some more things in Rust anyway, and I found [lopdf](https://github.com/J-F-Liu/lopdf).
 
-In the beginning, I had written my program as a regular project in Rust i.e.
-`cargo new my_pdf` and then it was happy coding 🙂. I wanted the program to take
-some configuration and create/edit a PDF file based on it.
+In the beginning, I had written my program as a regular project in Rust i.e. `cargo new my_pdf` and then it was happy coding 🙂. I wanted the program to take some configuration and create/edit a PDF file based on it.
 
-After I played around with it, I started wondering “How much work would it be to
-make it an Elixir NIF?”.
+After I played around with it, I started wondering “How much work would it be to make it an Elixir NIF?”.
 
-Turns out - there’s not a whole lot of additional stuff we need to do in order
-to comfortably use crates inside Elixir projects.
+Turns out - there’s not a whole lot of additional stuff we need to do in order to comfortably use crates inside Elixir projects.
 
-[Rustler](https://github.com/rusterlium/rustler) is a library for writing
-[Erlang NIFs](https://www.erlang.org/doc/tutorial/nif.html) in a very easy and
-straightforward way.
+[Rustler](https://github.com/rusterlium/rustler) is a library for writing [Erlang NIFs](https://www.erlang.org/doc/tutorial/nif.html) in a very easy and straightforward way.
 
 There are about 2 things we need to keep in mind and take care of:
 
-- Error handling: there needs to be something that maps Rust errors into Elixir
-  atoms so that we could easily handle them.
-- Rustler traits: typically your functions and structs will need to derive the
-  implementation from appropriate traits so they can be usable inside Elixir
-  (only the public parts of it of course).
+- Error handling: there needs to be something that maps Rust errors into Elixir atoms so that we could easily handle them.
+- Rustler traits: typically your functions and structs will need to derive the implementation from appropriate traits so they can be usable inside Elixir (only the public parts of it of course).
 
 ## Setup
 
-Setting up a project with Rustler is fairly easy. You can find a link to
-instructions here:
-[https://github.com/rusterlium/rustler#getting-started](https://github.com/rusterlium/rustler#getting-started)
+Setting up a project with Rustler is fairly easy. You can find a link to instructions here: [https://github.com/rusterlium/rustler#getting-started](https://github.com/rusterlium/rustler#getting-started)
 
-I’ll assume you have both Elixir and Rust installed in your development
-environment.
+I’ll assume you have both Elixir and Rust installed in your development environment.
 
 1. Create a new Elixir project `mix new rustler_pdf`
 2. Add the `:rustler` dependency in `mix.exs`
@@ -75,10 +51,8 @@ environment.
 3. Download packages: `mix deps.get`
 4. Setup Rustler
    1. Run `mix rustler.new`
-   2. On “Module name” prompt type in `RustlerPdf` (Name of your Elixir module
-      that Rustler registers NIFs to)
-   3. On the “Library name” prompt type in `rustlerpdf` (Name of your cargo
-      crate)
+   2. On “Module name” prompt type in `RustlerPdf` (Name of your Elixir module that Rustler registers NIFs to)
+   3. On the “Library name” prompt type in `rustlerpdf` (Name of your cargo crate)
 5. Configure Rustler
 
    1. Add the Rustler behaviour in `rustler_pdf.ex`
@@ -113,9 +87,7 @@ environment.
 
 ## Implementing the PDF program
 
-I’ll mostly showcase contracts and interfaces of the Rust part of the program.
-If you're interested in the full implementation, you can find it
-[here](https://github.com/BobrImperator/rustler_pdf).
+I’ll mostly showcase contracts and interfaces of the Rust part of the program. If you're interested in the full implementation, you can find it [here](https://github.com/BobrImperator/rustler_pdf).
 
 First off let’s take a look at pure Rust structs and functions.
 
@@ -169,19 +141,13 @@ pub fn read_config() -> PdfWriterConfiguration {
 pub fn create_pdf(config: PdfWriterConfiguration) -> Result<(), std::io::Error> {}
 ```
 
-This is the overview of pretty much the entirety of the Rust implementation
-“minus” the `lopdf` interaction. In general, the idea is that given
-`PdfWriterConfiguration` a `create_pdf` function will create a PDF file. Then I
-want to use those methods directly in Elixir.
+This is the overview of pretty much the entirety of the Rust implementation “minus” the `lopdf` interaction. In general, the idea is that given `PdfWriterConfiguration` a `create_pdf` function will create a PDF file. Then I want to use those methods directly in Elixir.
 
-The only relevant part of the implementation here are the structs themselves, as
-you can see they have `i32`, `f64`, `string`, `tuple`, `struct` and `enum` Rust
-types. Later we’ll see how they map to Elixir data structures.
+The only relevant part of the implementation here are the structs themselves, as you can see they have `i32`, `f64`, `string`, `tuple`, `struct` and `enum` Rust types. Later we’ll see how they map to Elixir data structures.
 
 ## Rustler-ize-it
 
-Now we need to add traits to our data and functions so Rustler knows how to
-marshall the data between Rust and Elixir environments.
+Now we need to add traits to our data and functions so Rustler knows how to marshall the data between Rust and Elixir environments.
 
 ```rust
 // import Rustler traits
@@ -213,14 +179,11 @@ pub struct PdfWriterConfiguration {
 }
 ```
 
-The `NifStruct` `NifUnitEnum` and `module = "Elixir.ModuleName` attributes
-provide implementations and metadata for the languages to communicate.
+The `NifStruct` `NifUnitEnum` and `module = "Elixir.ModuleName` attributes provide implementations and metadata for the languages to communicate.
 
 ### Enum variant with value - `NifTaggedEnum`
 
-An additional note here: I’m using `NifUnitEnum` which is a simple Enum variant.
-If you’d like to use a Rust Enum variant that also carries data, you might use
-`NifTaggedEnum` in order to use such Enums:
+An additional note here: I’m using `NifUnitEnum` which is a simple Enum variant. If you’d like to use a Rust Enum variant that also carries data, you might use `NifTaggedEnum` in order to use such Enums:
 
 ```rust
 use rustler::NifTaggedEnum;
@@ -271,15 +234,9 @@ fn priv_read_config() -> PdfWriterConfiguration {
 }
 ```
 
-The `read_config` function is simple enough that it doesn’t require any
-additional treatment. Since it’s only delivering hardcoded data and is not
-dealing with any kind of IO, it just needs the `#[rustler::nif]` attribute.
+The `read_config` function is simple enough that it doesn’t require any additional treatment. Since it’s only delivering hardcoded data and is not dealing with any kind of IO, it just needs the `#[rustler::nif]` attribute.
 
-I’m also splitting the functions into the plain Rust functions and the public
-ones that Rustler exposes to Elixir. This most definitely should be built as a
-regular Rust crate and another Rustler ‘bridge’ module. I decided to just add
-prefixes here - for the purpose of this post, I believe this simplifies things a
-bit.
+I’m also splitting the functions into the plain Rust functions and the public ones that Rustler exposes to Elixir. This most definitely should be built as a regular Rust crate and another Rustler ‘bridge’ module. I decided to just add prefixes here - for the purpose of this post, I believe this simplifies things a bit.
 
 ```rust
 use rustler::{Atom, Env, Error as RustlerError, NifStruct, NifUnitEnum, Term};
@@ -327,22 +284,15 @@ fn priv_create_pdf(config: PdfWriterConfiguration) -> Result<(), std::io::Error>
 
 `create_pdf` is slightly more complicated as it involves some error handling.
 
-`priv_create_pdf` is dealing with creating an actual file on the filesystem so
-it might result in an error.
+`priv_create_pdf` is dealing with creating an actual file on the filesystem so it might result in an error.
 
-In order to handle that situation, we’ve defined a module called `atoms` which
-uses the `rustler::atoms!` macro to create methods to simplify creating and
-decoding atoms.
+In order to handle that situation, we’ve defined a module called `atoms` which uses the `rustler::atoms!` macro to create methods to simplify creating and decoding atoms.
 
-`io_error_to_term` takes an `std::io::error`, matches on the kind of error and
-translates that into an `Atom`.
+`io_error_to_term` takes an `std::io::error`, matches on the kind of error and translates that into an `Atom`.
 
-As you’ve probably noticed, `create_pdf` expects an `env` argument which is
-always present with all NIFs. Env is used by Rustler for communication and
-encoding/decoding data between the BEAM and Rust.
+As you’ve probably noticed, `create_pdf` expects an `env` argument which is always present with all NIFs. Env is used by Rustler for communication and encoding/decoding data between the BEAM and Rust.
 
-`read_config` and `add` in the previous examples are not using it so it’s
-possible to omit its declaration.
+`read_config` and `add` in the previous examples are not using it so it’s possible to omit its declaration.
 
 ### Exporting NIFs
 
@@ -350,16 +300,11 @@ possible to omit its declaration.
 rustler::init!("Elixir.RustlerPdf", [read_config, create_pdf]);
 ```
 
-At the end of the file, change the `rustler::init!` macro to the above: this
-lets Rustler know to bind `read_config` function to the `Elixir.RustlerPdf`
-module.
+At the end of the file, change the `rustler::init!` macro to the above: this lets Rustler know to bind `read_config` function to the `Elixir.RustlerPdf` module.
 
 ## The Elixir part
 
-Once the Rust crate exports the functions, we need to let the Elixir side know
-what functions are expected to be bound to the module. Note that knowing the
-functions' arities is important here, otherwise you’ll get errors saying that a
-function couldn’t be loaded.
+Once the Rust crate exports the functions, we need to let the Elixir side know what functions are expected to be bound to the module. Note that knowing the functions' arities is important here, otherwise you’ll get errors saying that a function couldn’t be loaded.
 
 ```elixir
 defmodule RustlerPdf do
@@ -372,8 +317,7 @@ defmodule RustlerPdf do
 end
 ```
 
-Now we can use the NIFs like regular Elixir functions. Let’s try it out in the
-interactive console `iex -S mix`
+Now we can use the NIFs like regular Elixir functions. Let’s try it out in the interactive console `iex -S mix`
 
 ```elixir
 [nix-shell:~/Projects/elixir-pdf-experiment/rustler_pdf]$ iex -S mix
@@ -405,13 +349,9 @@ iex(1)> RustlerPdf.read_config()
 iex(2)>
 ```
 
-Notice how the Rust struct now maps to a plain Elixir `map` type with additional
-`__struct__` metadata: this is how Rustler ensures type safety. If the
-`__struct__` would be missing, then we’d get an `ArgumentError` exception.
+Notice how the Rust struct now maps to a plain Elixir `map` type with additional `__struct__` metadata: this is how Rustler ensures type safety. If the `__struct__` would be missing, then we’d get an `ArgumentError` exception.
 
-Out of curiosity I was also benchmarking this implementation against an Elixir
-library called `elixir-pdf`. The Elixir library was roughly 2x slower, but
-interestingly used 1/3 less memory.
+Out of curiosity I was also benchmarking this implementation against an Elixir library called `elixir-pdf`. The Elixir library was roughly 2x slower, but interestingly used 1/3 less memory.
 
 ```elixir
 def benchmark() do
@@ -463,21 +403,11 @@ e_create_pdf         1.17 KB - 0.71x memory usage -0.47656 KB
 
 ### Conclusion
 
-I've shown how you can make use of Rustler in order to add a functionality to
-your Elixir program which natively might not exist. I hope I also managed to
-make you consider using Rust for your next high-peformant and type-safe Elixir
-module.
-
-In my opinion, Rust and Elixir are a great match. Rust offers amazing processing
-performance while Elixir and the BEAM are excellent at low latency connections
-and message passing. With Rustler you don't need to choose between one or
-another, but you could use both instead :) So don't hesitate and experiment,
-it's both fun and productive for the developers and could be very beneficial for
-your bussiness.
-
-Consider taking a brief look at the full implementation of the Rust program
-here:
-[https://github.com/BobrImperator/rustler_pdf](https://github.com/BobrImperator/rustler_pdf)
+I've shown how you can make use of Rustler in order to add a functionality to your Elixir program which natively might not exist. I hope I also managed to make you consider using Rust for your next high-peformant and type-safe Elixir module.
+
+In my opinion, Rust and Elixir are a great match. Rust offers amazing processing performance while Elixir and the BEAM are excellent at low latency connections and message passing. With Rustler you don't need to choose between one or another, but you could use both instead :) So don't hesitate and experiment, it's both fun and productive for the developers and could be very beneficial for your bussiness.
+
+Consider taking a brief look at the full implementation of the Rust program here: [https://github.com/BobrImperator/rustler_pdf](https://github.com/BobrImperator/rustler_pdf)
 
 Further reading:
 
diff --git a/src/posts/2023-02-28-ember-template-assert.md b/src/posts/2023-02-28-ember-template-assert.md
index 7cb776e159..880496fb93 100644
--- a/src/posts/2023-02-28-ember-template-assert.md
+++ b/src/posts/2023-02-28-ember-template-assert.md
@@ -1,12 +1,9 @@
 ---
-title:
-  "Building a template assertion Ember addon that removes itself from production"
+title: "Building a template assertion Ember addon that removes itself from production"
 authorHandle: nickschot
 tags: [ember]
 bio: "Nick Schot"
-description:
-  "Nick Schot explains how to build an Ember addon that completely removes
-  itself from production builds."
+description: "Nick Schot explains how to build an Ember addon that completely removes itself from production builds."
 og:
   image: /assets/images/posts/2023-02-28-ember-template-assert/og-image.jpg
 tagline: |
@@ -16,32 +13,19 @@ image: "/assets/images/posts/2023-02-28-ember-template-assert/header-illustratio
 imageAlt: "The Ember logo on a gray backround picture"
 ---
 
-Ember's `assert` function can be helpful to add checks meant for developers to
-make sure, for example, that the correct data is passed.
+Ember's `assert` function can be helpful to add checks meant for developers to make sure, for example, that the correct data is passed.
 
 ```javascript
 assert("Must pass myArgument", myArgument !== undefined);
 ```
 
-The `assert` statement runs only for development builds and is completely
-stripped from production. This rather useful functionality does by default not
-have an equal in an Ember template. This could be a useful addition especially
-for template-only components, which have no JavaScript backing class. As such
-we'll create this helper and use this as an opportunity to show how to strip
-such an addon completely from production builds.
+The `assert` statement runs only for development builds and is completely stripped from production. This rather useful functionality does by default not have an equal in an Ember template. This could be a useful addition especially for template-only components, which have no JavaScript backing class. As such we'll create this helper and use this as an opportunity to show how to strip such an addon completely from production builds.
 
 ## The `assert` helper
 
-The helper itself is quite minimal, since we only need to wrap the original
-`assert` function provided by Ember in a helper. We can first use ember-cli to
-generate a helper with `ember g helper assert`. In an addon this will generate 3
-files. The file where our implementation will be `/addon/helpers/assert.js`, a
-re-export that will make the helper discoverable by Ember apps
-`/app/helpers/assert.js`, and a test file.
+The helper itself is quite minimal, since we only need to wrap the original `assert` function provided by Ember in a helper. We can first use ember-cli to generate a helper with `ember g helper assert`. In an addon this will generate 3 files. The file where our implementation will be `/addon/helpers/assert.js`, a re-export that will make the helper discoverable by Ember apps `/app/helpers/assert.js`, and a test file.
 
-Note that from Ember 4.5 onwards it is also possible to use plain functions as
-helpers, removing the need to wrap the function in a `helper()` call. For
-backward compatibility reasons, however, we will keep it for now.
+Note that from Ember 4.5 onwards it is also possible to use plain functions as helpers, removing the need to wrap the function in a `helper()` call. For backward compatibility reasons, however, we will keep it for now.
 
 ```javascript
 // addon/helpers/assert.js
@@ -56,11 +40,7 @@ export default helper(function templateAssert([message, condition]) {
 
 ## Testing an assertion
 
-Testing an assertion is slightly tricky, since by default an assertion will
-cause an uncaught error which crashes the app (and tests). In order to prevent
-this from happening we can add a custom `Ember.onerror` hook for our test and
-handle the assertion error there. This will make our test look like the
-following:
+Testing an assertion is slightly tricky, since by default an assertion will cause an uncaught error which crashes the app (and tests). In order to prevent this from happening we can add a custom `Ember.onerror` hook for our test and handle the assertion error there. This will make our test look like the following:
 
 ```javascript
 test("it fails to render when the assertion is falsy", async function (assert) {
@@ -81,24 +61,15 @@ test("it fails to render when the assertion is falsy", async function (assert) {
 
 ## Removing helper invocations from production using an AST-transform
 
-In order to remove helper invocations from consuming app code, we will need to
-add an AST-transform. In our case we'll specifically need to write a transform
-for the `htmlbars-ast-plugin`, which turns `.hbs` template files into an AST.
+In order to remove helper invocations from consuming app code, we will need to add an AST-transform. In our case we'll specifically need to write a transform for the `htmlbars-ast-plugin`, which turns `.hbs` template files into an AST.
 
 ### Writing the AST transform
 
-What we want to do is make sure we remove all calls of
-{% raw %}`{{assert}}`{% endraw %} from the templates in production builds. If we
-do not remove these, apart from shipping unnecessary code, Ember would also
-throw an error after we remove the helper code itself from the build in the next
-step. To figure out what exactly we need to do we can make use of
-[ast-explorer](https://astexplorer.net/#/gist/a62cdfd01800c7c97d67fdffe1ef03ea/ac85caf41c1af25787c5ae4b0d741cbea7fe903c).
+What we want to do is make sure we remove all calls of {% raw %}`{{assert}}`{% endraw %} from the templates in production builds. If we do not remove these, apart from shipping unnecessary code, Ember would also throw an error after we remove the helper code itself from the build in the next step. To figure out what exactly we need to do we can make use of [ast-explorer](https://astexplorer.net/#/gist/a62cdfd01800c7c97d67fdffe1ef03ea/ac85caf41c1af25787c5ae4b0d741cbea7fe903c).
 
 ![Screenshot of ast-explorer example](/assets/images/posts/2023-02-28-ember-template-assert/ast-explorer.png)
 
-Looking at our sample code, we can see that the `assert` shows up as a node of
-type "MustacheStatement" with `path.original` as `assert`. We can use this
-information to write a small visitor statement in the following format:
+Looking at our sample code, we can see that the `assert` shows up as a node of type "MustacheStatement" with `path.original` as `assert`. We can use this information to write a small visitor statement in the following format:
 
 ```javascript
 // /lib/ast-transform.js
@@ -140,16 +111,11 @@ visitor = {
 };
 ```
 
-By returning `null` it will remove all Mustache statements (any template
-statement that has handlebars syntax like {% raw %}`{{...}}`{% endraw %}) with
-the name `assert`. Since we want to remove all assert statements, there's no
-need to look at the arguments that are passed in to the assert helper.
+By returning `null` it will remove all Mustache statements (any template statement that has handlebars syntax like {% raw %}`{{...}}`{% endraw %}) with the name `assert`. Since we want to remove all assert statements, there's no need to look at the arguments that are passed in to the assert helper.
 
 ### Setting up `htmlbars-ast-plugin`
 
-Next we need to hook up our new AST transform tp the build process. To do that
-we need to add some configuration to the addon's `index.js` file to tell
-ember-cli about our new AST transform.
+Next we need to hook up our new AST transform tp the build process. To do that we need to add some configuration to the addon's `index.js` file to tell ember-cli about our new AST transform.
 
 ```javascript
 // /index.js
@@ -186,17 +152,11 @@ module.exports = {
 };
 ```
 
-Note that we only load the plugin in production environments, since we don't
-want to remove {% raw %}`{{assert}}`{% endraw %} from templates in development
-or test environments.
+Note that we only load the plugin in production environments, since we don't want to remove {% raw %}`{{assert}}`{% endraw %} from templates in development or test environments.
 
 ## Removing the helper code itself from production
 
-In order to remove our addon files from production builds, we can rely on a
-plugin for broccoli called `broccoli-funnel`. It will allow us to specify file
-paths that need to be filtered from the addon's file tree. After adding the
-`broccoli-funnel` dependency, we can modify `index.js` again to add the
-following section:
+In order to remove our addon files from production builds, we can rely on a plugin for broccoli called `broccoli-funnel`. It will allow us to specify file paths that need to be filtered from the addon's file tree. After adding the `broccoli-funnel` dependency, we can modify `index.js` again to add the following section:
 
 ```javascript
   treeForAddon(tree) {
@@ -213,19 +173,11 @@ following section:
   }
 ```
 
-Of course, like the AST transform, we only want to remove the helper from the
-build in production environments which we achieve by checking
-`app.isProduction`. We can remove the file from the build by specifying
-`exclude: ['helpers/assert.js']` which matches the file path of the helper
-itself in the addon directory - `addon/helpers/assert.js`.
+Of course, like the AST transform, we only want to remove the helper from the build in production environments which we achieve by checking `app.isProduction`. We can remove the file from the build by specifying `exclude: ['helpers/assert.js']` which matches the file path of the helper itself in the addon directory - `addon/helpers/assert.js`.
 
-However, we also need to remove the helper re-export from the app folder -
-`app/helpers/assert.js`. The very similar hook called `treeForApp` can be used
-for this purpose. It handles everything in the `app` folder of your v1 Ember
-addon.
+However, we also need to remove the helper re-export from the app folder - `app/helpers/assert.js`. The very similar hook called `treeForApp` can be used for this purpose. It handles everything in the `app` folder of your v1 Ember addon.
 
-Let's start with abstracting our existing addon tree filter code a bit to make
-it reusable:
+Let's start with abstracting our existing addon tree filter code a bit to make it reusable:
 
 ```javascript
 _filterAssertHelper(tree) {
@@ -246,8 +198,7 @@ treeForAddon(tree) {
 }
 ```
 
-We now only need to add the following to also filter the re-export
-`app/helpers/assert.js`.
+We now only need to add the following to also filter the re-export `app/helpers/assert.js`.
 
 ```javascript
 treeForApp(tree) {
@@ -255,9 +206,7 @@ treeForApp(tree) {
 }
 ```
 
-To verify that we have done the right thing we can use a package called
-`broccoli-stew`. It provides a log utility that will output the tree it's passed
-to the console.
+To verify that we have done the right thing we can use a package called `broccoli-stew`. It provides a log utility that will output the tree it's passed to the console.
 
 By modifying the `_filterAssertHelper` function as follows:
 
@@ -288,16 +237,8 @@ ember-template-assert addon tree
    └── helpers/assert.js
 ```
 
-If we run the app with `ember s --environment=production` the output should no
-longer show our assert helper, meaning the helper was successfully removed from
-the build.
+If we run the app with `ember s --environment=production` the output should no longer show our assert helper, meaning the helper was successfully removed from the build.
 
 ## Conclusion
 
-While this is a small example where the benefits of removal are limited, one can
-think of more comprehensive debugging tools that benefit from being removed from
-production builds. This will allow you to have useful dev-time tools without the
-fear of increasing bundle size. At the same time we've created a small but
-useful helper for template-only components that can help prevent incorrect usage
-of these components. The final `ember-template-assert` addon can be found here:
-[https://github.com/mainmatter/ember-template-assert](https://github.com/mainmatter/ember-template-assert).
+While this is a small example where the benefits of removal are limited, one can think of more comprehensive debugging tools that benefit from being removed from production builds. This will allow you to have useful dev-time tools without the fear of increasing bundle size. At the same time we've created a small but useful helper for template-only components that can help prevent incorrect usage of these components. The final `ember-template-assert` addon can be found here: [https://github.com/mainmatter/ember-template-assert](https://github.com/mainmatter/ember-template-assert).
diff --git a/src/posts/2023-06-09-securing-the-ecosystems-investment-in-emberjs.md b/src/posts/2023-06-09-securing-the-ecosystems-investment-in-emberjs.md
index 9cef86d751..30f7e93b90 100644
--- a/src/posts/2023-06-09-securing-the-ecosystems-investment-in-emberjs.md
+++ b/src/posts/2023-06-09-securing-the-ecosystems-investment-in-emberjs.md
@@ -3,10 +3,7 @@ title: "Securing the ecosystem’s investment in Ember.js"
 authorHandle: marcoow
 tags: [ember]
 bio: "Marco Otte-Witte"
-description:
-  "Marco Otte-Witte shares the background behind the initiative to ship
-  Embroider and secure Ember's future Mainmatter is working on with sponsors
-  like TicketSolve and Intercom."
+description: "Marco Otte-Witte shares the background behind the initiative to ship Embroider and secure Ember's future Mainmatter is working on with sponsors like TicketSolve and Intercom."
 og:
   image: /assets/images/posts/2023-06-09-securing-the-ecosystems-investment-in-emberjs/og-image.jpg
 tagline: |
@@ -19,151 +16,67 @@ imageAlt: "The Ember logo on a gray backround picture"
 
 ## The Status Quo
 
-At the time of this writing, only few apps and teams are using Embroider (and
-only a fraction of the ones that do, use the optimized mode which is really the
-one that matters). Embroider is also not enabled by default in the blueprints
-for new apps (or addons) and many addons in the ecosystem still need to be
-migrated to support it.
+At the time of this writing, only few apps and teams are using Embroider (and only a fraction of the ones that do, use the optimized mode which is really the one that matters). Embroider is also not enabled by default in the blueprints for new apps (or addons) and many addons in the ecosystem still need to be migrated to support it.
 
 ### Risk of Fragmentation
 
-While some teams managed to get their applications running in Embroider safe
-mode, if only part of the ecosystem migrates to Embroider, **we’re at the risk
-of fragmenting the ecosystem and community.** The worst case scenario would be
-ending up with 2 camps: Embroider and Non-Embroider. The longer we remain in
-this intermediate state of ongoing migration, the higher the likelihood is for
-that to happen.
-
-The imminent risk of a fragmented community is threatening to break one of
-Ember’s key promises – the fact that the community is aligned around a set of
-patterns and practices that _"just work"_ (what has been referred to as _“the
-safety of the herd”_). In a fragmented ecosystem where addons, patterns, and
-architectures cannot easily be shared, cross-pollination and sharing of
-solutions we all benefit from in the ecosystem at the moment will become much
-harder and much less effective. We're back to being on our own instead of being
-part of a herd that moves collectively.
+While some teams managed to get their applications running in Embroider safe mode, if only part of the ecosystem migrates to Embroider, **we’re at the risk of fragmenting the ecosystem and community.** The worst case scenario would be ending up with 2 camps: Embroider and Non-Embroider. The longer we remain in this intermediate state of ongoing migration, the higher the likelihood is for that to happen.
+
+The imminent risk of a fragmented community is threatening to break one of Ember’s key promises – the fact that the community is aligned around a set of patterns and practices that _"just work"_ (what has been referred to as _“the safety of the herd”_). In a fragmented ecosystem where addons, patterns, and architectures cannot easily be shared, cross-pollination and sharing of solutions we all benefit from in the ecosystem at the moment will become much harder and much less effective. We're back to being on our own instead of being part of a herd that moves collectively.
 
 ### Bundle Sizes and Build Performance
 
-Without Embroider, it remains hard for teams working with Ember to **leverage
-techniques like bundle splitting**. Many applications suffer from large bundles
-and their impact on runtime performance, yet there is no straight-forward way to
-decrease bundle sizes.
+Without Embroider, it remains hard for teams working with Ember to **leverage techniques like bundle splitting**. Many applications suffer from large bundles and their impact on runtime performance, yet there is no straight-forward way to decrease bundle sizes.
 
-The same applies to build performance: build times in Ember can be long, in
-particular for large applications. Only with Embroider we get access to modern
-build tooling like [Vite](https://vitejs.dev),
-[Turbopack](https://turbo.build/pack), etc. which offer **orders-of-magnitude
-faster builds than what's currently possible**.
+The same applies to build performance: build times in Ember can be long, in particular for large applications. Only with Embroider we get access to modern build tooling like [Vite](https://vitejs.dev), [Turbopack](https://turbo.build/pack), etc. which offer **orders-of-magnitude faster builds than what's currently possible**.
 
 ## Keep Ember ~~weird~~ relevant
 
-The risk of fragmentation and the gap to competing technologies regarding bundle
-sizes and build times **represents a threat to Ember and all teams that have
-built on it**. Eventually, teams might decide to leave Ember, it might become
-hard(er) to attract engineers to work on Ember projects, and the ecosystem might
-shrink overall which leads to less work going into the project and less progress
-being made. On the other hand, once Embroider ships, Ember will be in good shape
-for the future and make a significant leap forward.
+The risk of fragmentation and the gap to competing technologies regarding bundle sizes and build times **represents a threat to Ember and all teams that have built on it**. Eventually, teams might decide to leave Ember, it might become hard(er) to attract engineers to work on Ember projects, and the ecosystem might shrink overall which leads to less work going into the project and less progress being made. On the other hand, once Embroider ships, Ember will be in good shape for the future and make a significant leap forward.
 
 ### The Initiative
 
-In late 2022, Mainmatter started to reach out to companies that have invested in
-Ember with an idea: we wanted to put a team to work on Embroider full-time,
-finish the package itself, make it the standard for new apps and addons, and get
-it adopted across the ecosystem. We believe that **a team working on Embroider
-as their main and only priority** would have a huge impact on the project and
-get it over the finish line. As much as everyone in the Ember ecosystem
-appreciates Ed’s work and the work of
-[other contributors](https://github.com/embroider-build/embroider/graphs/contributors)
-(without which we wouldn’t even be in the position to think about how we take
-the last steps), a full-time team will be able to make progress at an increased
-pace. Mainmatter as a consultancy is in a unique position to do this kind of
-work since focusing on technical topics is at the core of what we do – we don’t
-need to pull people out of product work, negotiate that with product managers,
-get approval from project stakeholders, etc.
-
-We were able to get a number of companies on board as sponsors of the initiative
-quickly. All of those companies understand that investing in this initiative
-means ensuring the longevity of the investment they made into Ember.js by
-building their applications on top of it. They understand they cannot expect the
-technical foundations of their applications to evolve and be maintained somehow
-automatically at all times but they need to be an active contributor to the
-evolution and maintenance that's essential for their businesses. **By sharing
-the investment collectively among a group of sponsors via this initiative, each
-party only gives a little but will get the full value in the end.**
-
-We’re thankful to [Ticketsolve](https://www.ticketsolve.com/),
-[Intercom](https://www.intercom.com/),
-[OTA Insight](https://www.otainsight.com/),
-[HashiCorp](https://www.hashicorp.com/), [XBE](https://www.x-b-e.com/),
-[Isaac Lee](https://crunchingnumbers.live/),
-[Balint Erdi](https://balinterdi.com/), [HotDoc](https://www.hotdoc.com.au/),
-[solute](https://www.solute.de/), [Triptyk](https://www.triptyk.eu/),
-[redpencil](https://redpencil.io/), [Productive](https://productive.io/), and
-[Skovik](http://skovik.com) for sponsoring and supporting the initiative!
+In late 2022, Mainmatter started to reach out to companies that have invested in Ember with an idea: we wanted to put a team to work on Embroider full-time, finish the package itself, make it the standard for new apps and addons, and get it adopted across the ecosystem. We believe that **a team working on Embroider as their main and only priority** would have a huge impact on the project and get it over the finish line. As much as everyone in the Ember ecosystem appreciates Ed’s work and the work of [other contributors](https://github.com/embroider-build/embroider/graphs/contributors) (without which we wouldn’t even be in the position to think about how we take the last steps), a full-time team will be able to make progress at an increased pace. Mainmatter as a consultancy is in a unique position to do this kind of work since focusing on technical topics is at the core of what we do – we don’t need to pull people out of product work, negotiate that with product managers, get approval from project stakeholders, etc.
+
+We were able to get a number of companies on board as sponsors of the initiative quickly. All of those companies understand that investing in this initiative means ensuring the longevity of the investment they made into Ember.js by building their applications on top of it. They understand they cannot expect the technical foundations of their applications to evolve and be maintained somehow automatically at all times but they need to be an active contributor to the evolution and maintenance that's essential for their businesses. **By sharing the investment collectively among a group of sponsors via this initiative, each party only gives a little but will get the full value in the end.**
+
+We’re thankful to [Ticketsolve](https://www.ticketsolve.com/), [Intercom](https://www.intercom.com/), [OTA Insight](https://www.otainsight.com/), [HashiCorp](https://www.hashicorp.com/), [XBE](https://www.x-b-e.com/), [Isaac Lee](https://crunchingnumbers.live/), [Balint Erdi](https://balinterdi.com/), [HotDoc](https://www.hotdoc.com.au/), [solute](https://www.solute.de/), [Triptyk](https://www.triptyk.eu/), [redpencil](https://redpencil.io/), [Productive](https://productive.io/), and [Skovik](http://skovik.com) for sponsoring and supporting the initiative!
 
 ![a collage of the logos and names of the sponsors: Ticketsolve, Intercom, OTA Insight, HashiCorp, XBE, Isaac Lee, Balint Erdi, HotDoc, solute, Triptyk, redpencil, Productive](/assets/images/posts/2023-06-09-securing-the-ecosystems-investment-in-emberjs/sponsors.png)
 
 ## The Roadmap
 
-Work on the initiative has started already on June 1st. The project is lead on
-Mainmatter's side by [Chris Manson](https://twitter.com/real_ate). Our team of
-course operates completely in the open since all work is happening in the
-[Embroider](http://github.com/embroider-build/embroider),
-[RFCs](https://github.com/emberjs/rfcs), and related repositories.
+Work on the initiative has started already on June 1st. The project is lead on Mainmatter's side by [Chris Manson](https://twitter.com/real_ate). Our team of course operates completely in the open since all work is happening in the [Embroider](http://github.com/embroider-build/embroider), [RFCs](https://github.com/emberjs/rfcs), and related repositories.
 
 We have agreed with the sponsors on a roadmap focusing on five main points:
 
 ### 1. Finishing Embroider itself
 
-Embroider is relatively stable but there are still bugs to uncover and fix. We
-anticipate this to be the main part of the initiative as a substantial amount of
-work needs to be done still to smooth all of Embroider’s rough edges.
-
-Besides that, there is work that needs to happen in the wider Ember project.
-Specifically, that is:
-
-- preparing an RFC for the V2 addon format being the default blueprint for newly
-  created addons
-- preparing an RFC (and eventually a spec) for
-  [engines](http://ember-engines.com) in an Embroider world
-- preparing an RFC for a spec for build-time plugins or alternatively compiling
-  documentation for authoring code that hooks into the Ember build
-- shipping [ember-source](https://www.npmjs.com/package/ember-source) itself as
-  a V2 addon
+Embroider is relatively stable but there are still bugs to uncover and fix. We anticipate this to be the main part of the initiative as a substantial amount of work needs to be done still to smooth all of Embroider’s rough edges.
+
+Besides that, there is work that needs to happen in the wider Ember project. Specifically, that is:
+
+- preparing an RFC for the V2 addon format being the default blueprint for newly created addons
+- preparing an RFC (and eventually a spec) for [engines](http://ember-engines.com) in an Embroider world
+- preparing an RFC for a spec for build-time plugins or alternatively compiling documentation for authoring code that hooks into the Ember build
+- shipping [ember-source](https://www.npmjs.com/package/ember-source) itself as a V2 addon
 - preparing an RFC for a V2 application format
 
 ### 2. Making Embroider maintainable
 
-The bus factor for the Embroider project is essentially 1 at the moment. That
-needs to be changed so a larger group of people in the community can take over
-ownership of Embroider and be responsible for maintaining it which requires
-better documentation as well as actively involving and teaching more people.
+The bus factor for the Embroider project is essentially 1 at the moment. That needs to be changed so a larger group of people in the community can take over ownership of Embroider and be responsible for maintaining it which requires better documentation as well as actively involving and teaching more people.
 
 ### 3. Shifting the Ecosystem
 
-We’ll work on attracting contributions from the community to ensure the most
-important addons in the ecosystem are compatible with Embroider. We’ll also work
-on putting the infrastructure in place to make it as easy as possible for
-drive-by contributors to have a real impact
+We’ll work on attracting contributions from the community to ensure the most important addons in the ecosystem are compatible with Embroider. We’ll also work on putting the infrastructure in place to make it as easy as possible for drive-by contributors to have a real impact
 
-- We’re already working on setting up a dashboard on
-  [emberobserver.com](http://emberobserver.com) that shows the Embroider support
-  status of the top addons in the ecosystem. That makes it easy to quickly see
-  where contributions are needed.
-- We’ll actively market that dashboard as well as push for external
-  contributions to the effort.
-- Our team will invest some of their open source time (20% of every engineer’s
-  time) on working through the dashboard.
+- We’re already working on setting up a dashboard on [emberobserver.com](http://emberobserver.com) that shows the Embroider support status of the top addons in the ecosystem. That makes it easy to quickly see where contributions are needed.
+- We’ll actively market that dashboard as well as push for external contributions to the effort.
+- Our team will invest some of their open source time (20% of every engineer’s time) on working through the dashboard.
 
 ### 4. Making Embroider Mainstream
 
-Eventually, we want to make Embroider mainstream across the community to align
-the ecosystem and avoid fragmentation. Specifically, that means making the V2
-addon structure the default for new addons as well as making Embroider the
-default build system for new apps. Both tasks will likely require new RFCs and
-consultation across the core teams.
+Eventually, we want to make Embroider mainstream across the community to align the ecosystem and avoid fragmentation. Specifically, that means making the V2 addon structure the default for new addons as well as making Embroider the default build system for new apps. Both tasks will likely require new RFCs and consultation across the core teams.
 
 ### 5. Next Steps
 
@@ -171,16 +84,6 @@ As a last step, we’ll build an initial version of an Ember plugin for Vite.
 
 ## Join and secure your investment in Ember.js!
 
-We’re thrilled about the fact that a number of **companies that have invested in
-Ember.js came together to secure those investments and fund this initiative**.
-While we were optimistic we’d get funding for this, we couldn’t be sure when we
-first pitched the idea. It’s great to see how many companies understand the
-relevance of investing into the longevity of the technical foundations they
-build on.
-
-While the above roadmap will mean a huge step forward though, that’s not where
-it ends. More work will need to be done to evolve the prototype Ember plugin for
-Vite into a stable solution that teams can reliably bet on for the future. **We
-hope we can get more sponsors on board as we go and extend the scope of the
-initiative.** If you want to get involved and secure your investment in
-Ember.js, [reach out](/contact/)!
+We’re thrilled about the fact that a number of **companies that have invested in Ember.js came together to secure those investments and fund this initiative**. While we were optimistic we’d get funding for this, we couldn’t be sure when we first pitched the idea. It’s great to see how many companies understand the relevance of investing into the longevity of the technical foundations they build on.
+
+While the above roadmap will mean a huge step forward though, that’s not where it ends. More work will need to be done to evolve the prototype Ember plugin for Vite into a stable solution that teams can reliably bet on for the future. **We hope we can get more sponsors on board as we go and extend the scope of the initiative.** If you want to get involved and secure your investment in Ember.js, [reach out](/contact/)!
diff --git a/src/posts/2023-06-16-open-source-experimental-branding-templates.md b/src/posts/2023-06-16-open-source-experimental-branding-templates.md
index d1a2690b21..7d3294081c 100644
--- a/src/posts/2023-06-16-open-source-experimental-branding-templates.md
+++ b/src/posts/2023-06-16-open-source-experimental-branding-templates.md
@@ -3,113 +3,62 @@ title: "Open-source Experimental Branding Templates"
 authorHandle: davidhajba
 tags: [open-source, branding]
 bio: David Hajba
-description:
-  "David Hajba, Art Director at Mainmatter created open source experimental
-  branding templates. In this blog post, he talks about the journey & experience"
+description: "David Hajba, Art Director at Mainmatter created open source experimental branding templates. In this blog post, he talks about the journey & experience"
 og:
   image: /assets/images/posts/2023-06-16-open-source-experimental-branding-templates/og-image.jpg
 tagline: |
   <p>How can a visual designer work and collaborate on open-source projects? As an applied art service provider/ex-freelancer, my projects always started with a client and project requirements. The number of projects I did for myself just for fun was significantly shrinking, especially since becoming a first-time father. At Mainmatter everyone spends 20% of their time as an active member of the open-source community, so I had to find a way.</p>
 
 image: "/assets/images/posts/2023-06-16-open-source-experimental-branding-templates/header-illustration.jpg"
-imageAlt:
-  "a large white geometrical shape of a bug on a purple/salmon color geometrical
-  abstract background"
+imageAlt: "a large white geometrical shape of a bug on a purple/salmon color geometrical abstract background"
 ---
 
 ## The idea
 
-Among the fields I have experience in, Branding and UI/UX seemed the best choice
-for starting a new open-source project. The idea came quickly: I decided to
-create Branding and UI/UX Templates for fellow designers. In the past months, I
-have dedicated one day of my work week, my "20% time", to the conception and
-realization of this project and I will be showcasing the results in this post.
+Among the fields I have experience in, Branding and UI/UX seemed the best choice for starting a new open-source project. The idea came quickly: I decided to create Branding and UI/UX Templates for fellow designers. In the past months, I have dedicated one day of my work week, my "20% time", to the conception and realization of this project and I will be showcasing the results in this post.
 
 ## The journey & experience
 
-After getting used to rules and requirements, at first it felt kind of strange
-to have all the freedom of the world - I can do anything I want as long as the
-results are interesting and motivating for others.
+After getting used to rules and requirements, at first it felt kind of strange to have all the freedom of the world - I can do anything I want as long as the results are interesting and motivating for others.
 
-At this point, I had a voice in my head - that most of the designers would hear
-I assume - "Let’s imagine a fictional client or project that I have to find a
-solution for". Instead of this, I thought: "What if I turn the whole process
-upside down and create something based on my gut feelings, combining surprise
-elements together and see what comes out? "
+At this point, I had a voice in my head - that most of the designers would hear I assume - "Let’s imagine a fictional client or project that I have to find a solution for". Instead of this, I thought: "What if I turn the whole process upside down and create something based on my gut feelings, combining surprise elements together and see what comes out? "
 
-The first concept quickly turned boring and I started feeling a bit skeptical
-about my idea. But instead of giving up, that brought me closer to what I really
-wanted. Extraordinary. Surprising. Anything but boring.
+The first concept quickly turned boring and I started feeling a bit skeptical about my idea. But instead of giving up, that brought me closer to what I really wanted. Extraordinary. Surprising. Anything but boring.
 
 ## Concept 2
 
 ![Hero Concept 2 Screenshot](/assets/images/posts/2023-06-16-open-source-experimental-branding-templates/concept_2.jpg)
 
-[Preview](https://scene.zeplin.io/project/6455081b1dc67b3c0c397b0e/screen/646f712c6f352921c02462e6)
-[Download Sketch file](https://drive.google.com/drive/folders/1Ns0HDHztA8Ki6v8kp8L9NoxP69fI7D-c)
+[Preview](https://scene.zeplin.io/project/6455081b1dc67b3c0c397b0e/screen/646f712c6f352921c02462e6) [Download Sketch file](https://drive.google.com/drive/folders/1Ns0HDHztA8Ki6v8kp8L9NoxP69fI7D-c)
 
-I was searching among Google fonts when I found the most ridiculous but
-well-designed font I've ever seen, called "Nabla". I knew I had to start
-something with it. I don’t think I would ever suggest using a similar font to a
-client in a real-world situation, so this project was the perfect opportunity to
-experiment with it.
+I was searching among Google fonts when I found the most ridiculous but well-designed font I've ever seen, called "Nabla". I knew I had to start something with it. I don’t think I would ever suggest using a similar font to a client in a real-world situation, so this project was the perfect opportunity to experiment with it.
 
-Here things became interesting: I started to combine the font with captivating
-cloud illustrations, focusing on using soft and warm color tones while
-maintaining the balance with the Circular Std font, which has a strong geometric
-typeface.
+Here things became interesting: I started to combine the font with captivating cloud illustrations, focusing on using soft and warm color tones while maintaining the balance with the Circular Std font, which has a strong geometric typeface.
 
-Based on the overall impression I was getting from the design, I decided to use
-some professional Chinese street photography. It was hard to find exactly what I
-was looking for, but after hours of searching through seas of stock photos, I
-finally came across the perfect pictures for this project. These naturally led
-me into trying some traditional Chinese typography (which I never did before).
-It was very satisfying and lots of fun.
+Based on the overall impression I was getting from the design, I decided to use some professional Chinese street photography. It was hard to find exactly what I was looking for, but after hours of searching through seas of stock photos, I finally came across the perfect pictures for this project. These naturally led me into trying some traditional Chinese typography (which I never did before). It was very satisfying and lots of fun.
 
-I'm quite happy with the overall result and I believe it would look great for a
-fashion brand with a young target group within the Chinese market, or any other
-market with a strong connection to China.
+I'm quite happy with the overall result and I believe it would look great for a fashion brand with a young target group within the Chinese market, or any other market with a strong connection to China.
 
 ## Concept 3
 
 ![Hero Concept 3 Screenshot](/assets/images/posts/2023-06-16-open-source-experimental-branding-templates/concept_3.jpg)
 
-[Preview](https://scene.zeplin.io/project/6455081b1dc67b3c0c397b0e/screen/64709e41b998e22206a0ad16)
-[Download Sketch file](https://drive.google.com/drive/folders/1Ns0HDHztA8Ki6v8kp8L9NoxP69fI7D-c)
+[Preview](https://scene.zeplin.io/project/6455081b1dc67b3c0c397b0e/screen/64709e41b998e22206a0ad16) [Download Sketch file](https://drive.google.com/drive/folders/1Ns0HDHztA8Ki6v8kp8L9NoxP69fI7D-c)
 
-Berlin is a costant inspiration for creative people. Even a poster on the street
-can turn into something great: this is how Concept 3 was born. I decided to play
-around with brutal geometric shapes and patterns, with strong but not too
-saturated colors.
+Berlin is a costant inspiration for creative people. Even a poster on the street can turn into something great: this is how Concept 3 was born. I decided to play around with brutal geometric shapes and patterns, with strong but not too saturated colors.
 
-​The Larken font immediately seemed a good fit here. I remembered this font from
-the past work: it is a very special bohemian font, between modern and classic,
-elegant and crazy. The brutal geometric shapes required some smaller details for
-balance so I found a package with some interesting bugs illustrations which I
-modified to make them symmetrical and complement the concept better.
+​The Larken font immediately seemed a good fit here. I remembered this font from the past work: it is a very special bohemian font, between modern and classic, elegant and crazy. The brutal geometric shapes required some smaller details for balance so I found a package with some interesting bugs illustrations which I modified to make them symmetrical and complement the concept better.
 
-This idea has a quite versatile usage and of course the illustration package can
-be changed to match specific contexts.
+This idea has a quite versatile usage and of course the illustration package can be changed to match specific contexts.
 
 ## Concept 4
 
 ![Hero Concept 4 Screenshot](/assets/images/posts/2023-06-16-open-source-experimental-branding-templates/concept_4.jpg)
 
-[Preview](https://scene.zeplin.io/project/6455081b1dc67b3c0c397b0e/screen/64709e5e678ed3223e6f312a)
-[Download Sketch file](https://drive.google.com/drive/folders/1Ns0HDHztA8Ki6v8kp8L9NoxP69fI7D-c)
+[Preview](https://scene.zeplin.io/project/6455081b1dc67b3c0c397b0e/screen/64709e5e678ed3223e6f312a) [Download Sketch file](https://drive.google.com/drive/folders/1Ns0HDHztA8Ki6v8kp8L9NoxP69fI7D-c)
 
-Extremely condensed fonts were always something I wanted to try on the web but
-never had the chance to. Concept 4 seemed just the perfect time to experiment
-with them. After finding the ‘Rama Gothic C’ font which I considered the best
-designed in this category, I started to test different concepts. My idea quickly
-turned into a slideshow-style website combining colorful surfaces with
-typography playfulness, and wonderful monochrome photography with center-aligned
-overlay color circles, highlighting important parts of the image.
+Extremely condensed fonts were always something I wanted to try on the web but never had the chance to. Concept 4 seemed just the perfect time to experiment with them. After finding the ‘Rama Gothic C’ font which I considered the best designed in this category, I started to test different concepts. My idea quickly turned into a slideshow-style website combining colorful surfaces with typography playfulness, and wonderful monochrome photography with center-aligned overlay color circles, highlighting important parts of the image.
 
 ## Conclusion
 
-It was very valuable for me to experience the freedom of creating Branding
-templates without any rules or requirements and it has surely motivated me to
-suggest braver and more outstanding elements in real-life projects as well. I
-hope these templates will be just as useful and fun to work with - or implement
-further - for the designer community, as it was for me to create them.
+It was very valuable for me to experience the freedom of creating Branding templates without any rules or requirements and it has surely motivated me to suggest braver and more outstanding elements in real-life projects as well. I hope these templates will be just as useful and fun to work with - or implement further - for the designer community, as it was for me to create them.
diff --git a/src/posts/2023-06-28-present-and-future-of-rust-with-luca-palmieri.md b/src/posts/2023-06-28-present-and-future-of-rust-with-luca-palmieri.md
index 3528a38805..b274064184 100644
--- a/src/posts/2023-06-28-present-and-future-of-rust-with-luca-palmieri.md
+++ b/src/posts/2023-06-28-present-and-future-of-rust-with-luca-palmieri.md
@@ -1,13 +1,9 @@
 ---
-title:
-  "Adopting Rust: present and future of the Rust Web Ecosystem - with Luca
-  Palmieri"
+title: "Adopting Rust: present and future of the Rust Web Ecosystem - with Luca Palmieri"
 authorHandle: marcoow
 tags: [rust]
 bio: "Marco Otte-Witte"
-description:
-  "Luca Palmieri and Marco Otte-Witte discuss the present and future of the Rust
-  Web Ecosystem."
+description: "Luca Palmieri and Marco Otte-Witte discuss the present and future of the Rust Web Ecosystem."
 og:
   image: /assets/images/posts/2023-06-28-present-and-future-of-rust-with-luca-palmieri/og-image.jpg
 tagline: |
@@ -17,40 +13,16 @@ image: "/assets/images/posts/2023-06-28-present-and-future-of-rust-with-luca-pal
 imageAlt: "The Rust logo on a gray background"
 ---
 
-Luca shared his personal experience with Rust adoption, starting with his work
-at TrueLayer, where he successfully transitioned from a predominantly C#
-environment to Rust, driven by the need for better maintainability, correctness,
-scalability, and latency. Despite initial concerns about hiring and lacking
-expertise, the project was a success, leading to enhanced job satisfaction,
-streamlined recruitment, and the creation of reliable and performant services.
-
-Luca then talked about his book "Zero To Production In Rust: An Introduction To
-Backend Development" with which he aimed to bridge the gap between introductory
-resources and real-world application development in Rust. The book guides
-readers through the process of building a production-ready Rust application with
-a hands-on approach, covering crucial topics such as observability, testing,
-security, and more.
-
-At AWS, the investment made in Rust is evident through their deployment of Rust
-code in critical products and services, Luca explained. Projects like
-Firecracker and the AWS SDK for Rust highlight the language's potential and
-AWS's belief in its usefulness.
-
-While the challenges stemming from constantly evolving libraries and new
-versions persist, Rust has consistently demonstrated its potential for web
-services. Due to its expressive type system, safety features, and exceptional
-performance, the Rust Web ecosystem is currently gaining momentum, Luca and
-Marco agreed. With the continued investment from industry leaders like AWS, the
-ecosystem is certainly set to continue evolving in the future.
-
-Rust's appeal is undeniable, positioning it as a compelling choice for a wide
-range of applications. As Rust continues to integrate into libraries and
-frameworks across ecosystems, developers increasingly reap the benefits of its
-power. Whether seeking predictable performance, improved scalability, or reduced
-infrastructure costs, Rust is a versatile language to consider when building
-high-performance and robust software solutions.
-
-Check out the full interview below and don’t hesitate to contact us to learn how
-your company could benefit from adopting Rust.
+Luca shared his personal experience with Rust adoption, starting with his work at TrueLayer, where he successfully transitioned from a predominantly C# environment to Rust, driven by the need for better maintainability, correctness, scalability, and latency. Despite initial concerns about hiring and lacking expertise, the project was a success, leading to enhanced job satisfaction, streamlined recruitment, and the creation of reliable and performant services.
+
+Luca then talked about his book "Zero To Production In Rust: An Introduction To Backend Development" with which he aimed to bridge the gap between introductory resources and real-world application development in Rust. The book guides readers through the process of building a production-ready Rust application with a hands-on approach, covering crucial topics such as observability, testing, security, and more.
+
+At AWS, the investment made in Rust is evident through their deployment of Rust code in critical products and services, Luca explained. Projects like Firecracker and the AWS SDK for Rust highlight the language's potential and AWS's belief in its usefulness.
+
+While the challenges stemming from constantly evolving libraries and new versions persist, Rust has consistently demonstrated its potential for web services. Due to its expressive type system, safety features, and exceptional performance, the Rust Web ecosystem is currently gaining momentum, Luca and Marco agreed. With the continued investment from industry leaders like AWS, the ecosystem is certainly set to continue evolving in the future.
+
+Rust's appeal is undeniable, positioning it as a compelling choice for a wide range of applications. As Rust continues to integrate into libraries and frameworks across ecosystems, developers increasingly reap the benefits of its power. Whether seeking predictable performance, improved scalability, or reduced infrastructure costs, Rust is a versatile language to consider when building high-performance and robust software solutions.
+
+Check out the full interview below and don’t hesitate to contact us to learn how your company could benefit from adopting Rust.
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/Xb7NokhAVKI?rel=0" title="Embedded video of Luca's interview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
diff --git a/src/posts/2023-07-03-from-react-to-ember-building-a-blog.md b/src/posts/2023-07-03-from-react-to-ember-building-a-blog.md
index 367ee549f9..4e9b9cc3d7 100644
--- a/src/posts/2023-07-03-from-react-to-ember-building-a-blog.md
+++ b/src/posts/2023-07-03-from-react-to-ember-building-a-blog.md
@@ -3,12 +3,7 @@ title: "From React To Ember: Building a Personal Website"
 authorHandle: inesoaresilva
 tags: [ember, react]
 bio: "Inês Silva"
-description:
-  "Inês Silva explains her experience moving from React to Ember when building
-  her personal website/blog. She explains the process behind the major website
-  features, the challenges she faced, and how she overcame them. At the same
-  time, she compares the differences of the development process between Ember
-  and React."
+description: "Inês Silva explains her experience moving from React to Ember when building her personal website/blog. She explains the process behind the major website features, the challenges she faced, and how she overcame them. At the same time, she compares the differences of the development process between Ember and React."
 og:
   image: /assets/images/posts/2023-07-03-from-react-to-ember-building-a-blog/og-image.jpg
 tagline: |
@@ -21,95 +16,48 @@ imageAlt: "The Ember logo on a gray backround picture"
 
 ### You might want to read this if
 
-- You would like to create your own website/blog (if you decide to use Ember.js
-  maybe you can get ideas from here)
+- You would like to create your own website/blog (if you decide to use Ember.js maybe you can get ideas from here)
 - You already know React, and you are curious about Ember.js.
 
 ## The start
 
-In 2013, I embarked on my first blogging journey on Blogspot. It lasted for two
-years, but as university life took over, my time became limited, and I gradually
-lost touch with that blog. Nonetheless, I still longed for a space on the
-internet where I could freely express my thoughts. As my career in the tech
-world progressed, I knew it was time to build my own website.
-
-The amount of different tools for creating a website and the fact that I had
-never done one on my own before, felt overwhelming. I shared my issues with my
-working colleague, Chris. From that day forward, we began scheduling weekly pair
-programming sessions. Chris became my accountability partner and mentor,
-bringing immense value to my journey. 💜
-
-Working at a consultancy company like Mainmatter means that you don't always
-collaborate with everyone on the team. Chris and I never had the opportunity to
-work together on a client project. I really enjoyed having the chance to
-collaborate with someone outside of my usual circle. As a junior developer,
-these sessions have proven to be incredibly valuable for me.
-
-![Pair programming session with Chris running lighthouse to check my website performace. ](/assets/images/posts/2023-07-03-from-react-to-ember-building-a-blog/calls-with-chris.png)_Chris
-and I in one of our pair programming sessions. This one was about improving the
-performance of my website, so we were running lighthouse. Spoiler alert - not
-efficiently rendering my photos was my big issue._
+In 2013, I embarked on my first blogging journey on Blogspot. It lasted for two years, but as university life took over, my time became limited, and I gradually lost touch with that blog. Nonetheless, I still longed for a space on the internet where I could freely express my thoughts. As my career in the tech world progressed, I knew it was time to build my own website.
+
+The amount of different tools for creating a website and the fact that I had never done one on my own before, felt overwhelming. I shared my issues with my working colleague, Chris. From that day forward, we began scheduling weekly pair programming sessions. Chris became my accountability partner and mentor, bringing immense value to my journey. 💜
+
+Working at a consultancy company like Mainmatter means that you don't always collaborate with everyone on the team. Chris and I never had the opportunity to work together on a client project. I really enjoyed having the chance to collaborate with someone outside of my usual circle. As a junior developer, these sessions have proven to be incredibly valuable for me.
+
+![Pair programming session with Chris running lighthouse to check my website performace. ](/assets/images/posts/2023-07-03-from-react-to-ember-building-a-blog/calls-with-chris.png)_Chris and I in one of our pair programming sessions. This one was about improving the performance of my website, so we were running lighthouse. Spoiler alert - not efficiently rendering my photos was my big issue._
 
 ## From React to Ember
 
-When I joined the company, I initially worked with React, and I was the only one
-who didn't have experience working with Ember. This sparked my curiosity to
-learn at least what it looked like.
+When I joined the company, I initially worked with React, and I was the only one who didn't have experience working with Ember. This sparked my curiosity to learn at least what it looked like.
 
-Chris has been working with this framework for 10 years, so starting those pair
-programming sessions with him seemed like the perfect way to start learning
-Ember.
+Chris has been working with this framework for 10 years, so starting those pair programming sessions with him seemed like the perfect way to start learning Ember.
 
 ## Design Mockups
 
-To me, designing a mockup of the website was an important step to kick off the
-project. It helped me visualize my ideas of what I wanted the website to look
-like. It got me learning a bit more about UI/UX, and I used Figma as a sketching
-tool. I've worked with Sketch on other projects, but I still find Figma easier
-to use and more intuitive. I collected some inspiration and colors I liked. Then
-I started with the landing page, and I kept going from there.
+To me, designing a mockup of the website was an important step to kick off the project. It helped me visualize my ideas of what I wanted the website to look like. It got me learning a bit more about UI/UX, and I used Figma as a sketching tool. I've worked with Sketch on other projects, but I still find Figma easier to use and more intuitive. I collected some inspiration and colors I liked. Then I started with the landing page, and I kept going from there.
 
-Florian from our team (our design ninja) gave me a tip to use actual content on
-my mockups instead of using the classic 'Lorem Ipsum' placeholders - you better
-perceive the distance between the elements and how the font feels with your
-text.
+Florian from our team (our design ninja) gave me a tip to use actual content on my mockups instead of using the classic 'Lorem Ipsum' placeholders - you better perceive the distance between the elements and how the font feels with your text.
 
-![Figma document of the mobile and desktop designs for my website. ](/assets/images/posts/2023-07-03-from-react-to-ember-building-a-blog/figma-mockups.png)_Figma
-document of the mobile and desktop designs for my website._
+![Figma document of the mobile and desktop designs for my website. ](/assets/images/posts/2023-07-03-from-react-to-ember-building-a-blog/figma-mockups.png)_Figma document of the mobile and desktop designs for my website._
 
 ## Coding
 
-To begin the coding journey, I followed the
-[quick start guide](https://guides.emberjs.com/release/getting-started/quick-start/).
-I created my first route - an 'About Me' page, made my first component -
-`<Header>`, and my first routes navigation Home ↔ About Me.
-
-My first coding challenge was ‘_How to create a dropdown in Ember?_’. (now I’m
-having flashbacks from whenever I asked Chris _how do you do this in Ember?,_ he
-would answer _There is no such thing as "in Ember". This is just javascript._
-😆)
-
-As I transitioned from working with React to Ember, I noticed a shift in
-thinking. Ember introduced me to the handlebars templating language and a
-different project structure, where each component had its dedicated folder
-containing adapters, controllers, models, and templates. It felt a bit
-overwhelming initially, especially compared to React, where all the logic
-sometimes resided in a single file.
-
-Another challenge I encountered was finding updated documentation. When googling
-my struggles, I often stumbled upon outdated resources or, in some cases, no
-solutions at all. The Ember community, being smaller than the React community,
-naturally had fewer online resources, which increased the learning curve for a
-beginner like me.
-
-Overall, my transition from React to an Ember project proved to be a valuable
-learning experience, allowing me to explore new perspectives and expand my skill
-set.
+To begin the coding journey, I followed the [quick start guide](https://guides.emberjs.com/release/getting-started/quick-start/). I created my first route - an 'About Me' page, made my first component - `<Header>`, and my first routes navigation Home ↔ About Me.
+
+My first coding challenge was ‘_How to create a dropdown in Ember?_’. (now I’m having flashbacks from whenever I asked Chris _how do you do this in Ember?,_ he would answer _There is no such thing as "in Ember". This is just javascript._ 😆)
+
+As I transitioned from working with React to Ember, I noticed a shift in thinking. Ember introduced me to the handlebars templating language and a different project structure, where each component had its dedicated folder containing adapters, controllers, models, and templates. It felt a bit overwhelming initially, especially compared to React, where all the logic sometimes resided in a single file.
+
+Another challenge I encountered was finding updated documentation. When googling my struggles, I often stumbled upon outdated resources or, in some cases, no solutions at all. The Ember community, being smaller than the React community, naturally had fewer online resources, which increased the learning curve for a beginner like me.
+
+Overall, my transition from React to an Ember project proved to be a valuable learning experience, allowing me to explore new perspectives and expand my skill set.
 
 ### First Coding Challenge
 
-Picking up the question from my 1st coding challenge. I made that dropdown
-🙌🏼 and here is what it looks like:
+Picking up the question from my 1st coding challenge. I made that dropdown 🙌🏼 and here is what it looks like:
 
 ```handlebars
 {% raw %} // dropdown.hbs
@@ -157,97 +105,41 @@ export default class Dropdown extends Component {
 {% endraw %}
 ```
 
-I mean, for someone coming from React, there was a lot of new stuff going on in
-these two files.
+I mean, for someone coming from React, there was a lot of new stuff going on in these two files.
 
-Also, going back to using the `this.` keyword brought me memories from my
-classes at university and how understanding this concept was the boss level of
-object-oriented programming. 😂
+Also, going back to using the `this.` keyword brought me memories from my classes at university and how understanding this concept was the boss level of object-oriented programming. 😂
 
 Let me break down what is happening in my `<Dropdown>`:
 
-_Note, I want to say that this is probably not the most helpful dropdown
-component since I can only its title is customizable. In my case, I ended up not
-reusing it, so I didn’t feel the need to make it more customizable._
-
-- My dropdown component has a button that renders a
-  {% raw %}`{{@title}}`{% endraw %}. In React, this would be the `props.title`.
-- Then I have a `<div>` that will receive {% raw %}`{{yield}}`{% endraw %}. This
-  was a new keyword for me as well. The yield acts like a placeholder, and if I
-  use `<Dropdown>` in another component, which is the case in the _header.bhs_,
-  what I pass within the open and closing tags of my component will be rendered
-  in the place of{% raw %}`{{yield}}`{% endraw %}. The equivalent of this in
-  React would be the “children” property.
-- In here
-  {% raw %}`class='dropdown-button {{if this.open "focus"}}'`{% endraw %}, I’m
-  dynamically changing the button class name so that when the open variable is
-  set to true, I add ‘focus’ to the class name, which is how I apply the yellow
-  color to the dropdown title when the user opens it. Same happens with
-  {% raw %}`<div class='dropdown-list {{if this.open "show"}}'>`{% endraw %}.
-- Next, we have {% raw %}`{{on 'click' this.dropdown}}`{% endraw %}, this
-  instructs my app to run the `dropdown()`function (defined in the _dropdown.js_
-  file) after the user clicks on the button.
+_Note, I want to say that this is probably not the most helpful dropdown component since I can only its title is customizable. In my case, I ended up not reusing it, so I didn’t feel the need to make it more customizable._
+
+- My dropdown component has a button that renders a {% raw %}`{{@title}}`{% endraw %}. In React, this would be the `props.title`.
+- Then I have a `<div>` that will receive {% raw %}`{{yield}}`{% endraw %}. This was a new keyword for me as well. The yield acts like a placeholder, and if I use `<Dropdown>` in another component, which is the case in the _header.bhs_, what I pass within the open and closing tags of my component will be rendered in the place of{% raw %}`{{yield}}`{% endraw %}. The equivalent of this in React would be the “children” property.
+- In here {% raw %}`class='dropdown-button {{if this.open "focus"}}'`{% endraw %}, I’m dynamically changing the button class name so that when the open variable is set to true, I add ‘focus’ to the class name, which is how I apply the yellow color to the dropdown title when the user opens it. Same happens with {% raw %}`<div class='dropdown-list {{if this.open "show"}}'>`{% endraw %}.
+- Next, we have {% raw %}`{{on 'click' this.dropdown}}`{% endraw %}, this instructs my app to run the `dropdown()`function (defined in the _dropdown.js_ file) after the user clicks on the button.
 - Time to dive into _dropdown.js_ file associated to my component:
-  - Pretty much all my components have these 3 imports in their javascript
-    files:
-    - `Component` is a class from the Glimmer library (DOM rendering engine made
-      by the ember team) that allows me to define the behavior of my component
-      and its UI logic. In the latest versions of React, functional components
-      were introduced, meaning that they can be defined using regular JavaScript
-      functions - this way, there is no need to extend a class from a Component
-      base class.
-    - `{action}` is a decorator coming from the `@ember/object` module. It is
-      Ember's own object model, it allows me to define an event handler, in this
-      case, the `dropdown()` function that gets triggered when the user clicks
-      on the button. `@action` here works similarly to `bind()` in JavaScript -
-      when I use `this.open` inside of my Dropdown class in the dropdown.js
-      file, I need to find a way to make sure `this` refers to the same context
-      as the one used in the template (Dropdown.hbs file), and `@action` does
-      this for us. This way, when calling the `dropdown()` function from the
-      template the right context (`this`) gets passed to it. React doesn't have
-      decorators in their official API, we typically use regular functions as
-      event handlers directly.
-    - And the last import {% raw %}`{tracked}`{% endraw %} from
-      `@glimmer/tracking`. This is a module provided by glimmer framework that
-      tells my code to keep an eye on a variable, in my case, the variable
-      "open". This way, my app knows that when the value of this property
-      changes, changes in the UI will be triggered. In React, we typically
-      achieve this functionality using the built-in state management and the
-      `useState` hook. In my website this translates to - whenever a user clicks
-      on the button, the value of the tracked variable changes, which controls
-      the visibility of the dropdown's children and applies specific CSS
-      classes.
-- Finally, it's time to look at the last file - the template where I use my
-  `<Dropdown>` component, **header.hbs.**:
-  - I’m passing to the `<Dropdown>` a list of `<LinkTo>`. The latter component
-    allows me to create a link to a route, while the `@model` argument, allows
-    my app to know which data to retrieve when clicking on that route.
+  - Pretty much all my components have these 3 imports in their javascript files:
+    - `Component` is a class from the Glimmer library (DOM rendering engine made by the ember team) that allows me to define the behavior of my component and its UI logic. In the latest versions of React, functional components were introduced, meaning that they can be defined using regular JavaScript functions - this way, there is no need to extend a class from a Component base class.
+    - `{action}` is a decorator coming from the `@ember/object` module. It is Ember's own object model, it allows me to define an event handler, in this case, the `dropdown()` function that gets triggered when the user clicks on the button. `@action` here works similarly to `bind()` in JavaScript - when I use `this.open` inside of my Dropdown class in the dropdown.js file, I need to find a way to make sure `this` refers to the same context as the one used in the template (Dropdown.hbs file), and `@action` does this for us. This way, when calling the `dropdown()` function from the template the right context (`this`) gets passed to it. React doesn't have decorators in their official API, we typically use regular functions as event handlers directly.
+    - And the last import {% raw %}`{tracked}`{% endraw %} from `@glimmer/tracking`. This is a module provided by glimmer framework that tells my code to keep an eye on a variable, in my case, the variable "open". This way, my app knows that when the value of this property changes, changes in the UI will be triggered. In React, we typically achieve this functionality using the built-in state management and the `useState` hook. In my website this translates to - whenever a user clicks on the button, the value of the tracked variable changes, which controls the visibility of the dropdown's children and applies specific CSS classes.
+- Finally, it's time to look at the last file - the template where I use my `<Dropdown>` component, **header.hbs.**:
+  - I’m passing to the `<Dropdown>` a list of `<LinkTo>`. The latter component allows me to create a link to a route, while the `@model` argument, allows my app to know which data to retrieve when clicking on that route.
 
 ### Rendering My Blogposts
 
 1. **Finding a tool to publish my posts**
 
-   After giving the shape I wanted to my website, the question for one of the
-   key features was: "How do I create a not-so-complicated system that allows me
-   to publish blog posts? Am I going to create HTML pages every time?"
+   After giving the shape I wanted to my website, the question for one of the key features was: "How do I create a not-so-complicated system that allows me to publish blog posts? Am I going to create HTML pages every time?"
 
-   Chris proposed an approach: "Let’s create posts using markdown files." He
-   said we could use `ember-cli-showdown`.
+   Chris proposed an approach: "Let’s create posts using markdown files." He said we could use `ember-cli-showdown`.
 
-   This addon converts my markdown into HTLM, so I don’t need to do the tedious
-   & time-consuming job of writing an HTML file every time I want to publish a
-   new post. It was a deal. 🤝
+   This addon converts my markdown into HTLM, so I don’t need to do the tedious & time-consuming job of writing an HTML file every time I want to publish a new post. It was a deal. 🤝
 
 2. **Combining my posts information with the tool**
 
-   _"How can I extract what I write in my markdown files into my HTML
-   templates?"_ Another plugin enters the room: welcome to
-   [**Broccoli-Static-Site-Json.**](https://www.npmjs.com/package/broccoli-static-site-json)
-   👋🏼 It generates a JSON API of the content of my markdowns. Let me guide you
-   through the process:
+   _"How can I extract what I write in my markdown files into my HTML templates?"_ Another plugin enters the room: welcome to [**Broccoli-Static-Site-Json.**](https://www.npmjs.com/package/broccoli-static-site-json) 👋🏼 It generates a JSON API of the content of my markdowns. Let me guide you through the process:
 
-   - I need to define what data will populate my JSON API and to do it, I define
-     a ‘Post’ model. It looks like this:
+   - I need to define what data will populate my JSON API and to do it, I define a ‘Post’ model. It looks like this:
 
    ```js
    //app/models/post.js
@@ -263,12 +155,9 @@ reusing it, so I didn’t feel the need to make it more customizable._
    }
    ```
 
-   Now that I have that defined, I need to tell the broccoli addon what
-   attributes to use when building the JSON API.
+   Now that I have that defined, I need to tell the broccoli addon what attributes to use when building the JSON API.
 
-   Let’s add that in `/lib/content-generator/index.js` (a file coming from the
-   in-repo Ember addon that you can use to add broccoli-static-site-json to your
-   project):
+   Let’s add that in `/lib/content-generator/index.js` (a file coming from the in-repo Ember addon that you can use to add broccoli-static-site-json to your project):
 
    ```js
    //lib/content-generator/index.js
@@ -280,19 +169,9 @@ reusing it, so I didn’t feel the need to make it more customizable._
    });
    ```
 
-   I start by specifying the location of the API information, which, in my case,
-   is stored in my markdown files located under 'data/post'.
+   I start by specifying the location of the API information, which, in my case, is stored in my markdown files located under 'data/post'.
 
-   The 'type' parameter defines the name of the JSON:API document. The name you
-   assign to the 'type' parameter gets pluralized, so for the next attribute, it
-   should be 'data/posts'. Next, I define the attributes I want to include.
-   Additionally, I utilize the last configuration variable, `collate`, which
-   allows me to query all of my content at once, using 'findAll'. This is
-   particularly useful when I need to retrieve all posts. Now, let's move on to
-   the fun part 🙌🏼 - creating a template that will structure the information
-   from the markdown files. We'll then utilize our newly created API to populate
-   the template. To exemplify this, I'm going to show my `post-preview`
-   template:
+   The 'type' parameter defines the name of the JSON:API document. The name you assign to the 'type' parameter gets pluralized, so for the next attribute, it should be 'data/posts'. Next, I define the attributes I want to include. Additionally, I utilize the last configuration variable, `collate`, which allows me to query all of my content at once, using 'findAll'. This is particularly useful when I need to retrieve all posts. Now, let's move on to the fun part 🙌🏼 - creating a template that will structure the information from the markdown files. We'll then utilize our newly created API to populate the template. To exemplify this, I'm going to show my `post-preview` template:
 
 ### What they see
 
@@ -342,33 +221,17 @@ date: 2022-12-16T00:00:00.000Z
 ---
 ```
 
-This is information that all the posts will have - title, category, description,
-image and date. I’m keeping this as Frontmatter (metadata in Markdown files)
-because when my markdown is being converted into static JSON, each of my
-frontmatter keys will become keys in the JSON API. This way, I can access their
-data from my templates, e.g {% raw %}`{{@post.category}}`{% endraw %} ,
-{% raw %}`{{@post.image}}`{% endraw %}.
+This is information that all the posts will have - title, category, description, image and date. I’m keeping this as Frontmatter (metadata in Markdown files) because when my markdown is being converted into static JSON, each of my frontmatter keys will become keys in the JSON API. This way, I can access their data from my templates, e.g {% raw %}`{{@post.category}}`{% endraw %} , {% raw %}`{{@post.image}}`{% endraw %}.
 
 ## Deploying
 
-“Ok, I have the main functionalities running and my design is more or less close
-to what I sketched, time to make it public 😱”. It is very easy to fall in a
-situation where we say to ourselves that a project is still not ready to be
-shipped. There was a moment where Chris made me wear my Product Manager hat, and
-told me: "Write down the minimum features you need to make it functional till
-you deploy it”. This help me prioritize what I really needed and keep my focus.
+“Ok, I have the main functionalities running and my design is more or less close to what I sketched, time to make it public 😱”. It is very easy to fall in a situation where we say to ourselves that a project is still not ready to be shipped. There was a moment where Chris made me wear my Product Manager hat, and told me: "Write down the minimum features you need to make it functional till you deploy it”. This help me prioritize what I really needed and keep my focus.
 
-I got myself a domain at [namecheap](https://www.namecheap.com/) and I used
-[netlify](https://www.netlify.com/) to deploy it.
+I got myself a domain at [namecheap](https://www.namecheap.com/) and I used [netlify](https://www.netlify.com/) to deploy it.
 
 I faced some challenges with the deployment:
 
-1. Image fingerprinting The photos were not loading on the deployed website.
-   Why? Ember was adding a hash to my photo sources, e.g - from ‘work-in-cv.jpg’
-   it would become ‘work-in-cv-h4323524hgs.jpg’. In my HTML the photo source
-   would still be the one without the hash, but that path would not exist
-   anymore. How did I fix it? I specified on ember-cli-build what type of files
-   I wanted to get fingerprinted:
+1. Image fingerprinting The photos were not loading on the deployed website. Why? Ember was adding a hash to my photo sources, e.g - from ‘work-in-cv.jpg’ it would become ‘work-in-cv-h4323524hgs.jpg’. In my HTML the photo source would still be the one without the hash, but that path would not exist anymore. How did I fix it? I specified on ember-cli-build what type of files I wanted to get fingerprinted:
 
 ```js
 //ember-cli-build.js
@@ -384,31 +247,18 @@ module.exports = function (defaults) {
 
 2. Routes were not found
 
-Ember is a SPA (Single Page Application)- it loads a single HTML page and then
-dynamically updates its content as the user interacts with the application
-without requiring full page reloads from the server each time. Therefore SPA
-websites provide a smoother user experience.
+Ember is a SPA (Single Page Application)- it loads a single HTML page and then dynamically updates its content as the user interacts with the application without requiring full page reloads from the server each time. Therefore SPA websites provide a smoother user experience.
 
-The downside of this approach is that if we directly request to the web server a
-specific URL, e.g., /blog/post, the server won't find a file at the specified
-path and responds with a 404. This happens because the server is only aware of
-the index page and serves this page for all URLs within the application. It is
-Ember's JavaScript code that takes care of rendering the appropriate content
-based on the requested route.
+The downside of this approach is that if we directly request to the web server a specific URL, e.g., /blog/post, the server won't find a file at the specified path and responds with a 404. This happens because the server is only aware of the index page and serves this page for all URLs within the application. It is Ember's JavaScript code that takes care of rendering the appropriate content based on the requested route.
 
 To handle direct URLs requests to the web server, there are two approaches:
 
 1. Creating HTML files in the paths of the routes.
-2. We tell Netlify to give us the index.html when we get a 404 error, and Ember
-   decides what page we will render.
+2. We tell Netlify to give us the index.html when we get a 404 error, and Ember decides what page we will render.
 
-I chose the first solution - it is better for content websites, and we want SEO
-(Search Engine Optimization).
+I chose the first solution - it is better for content websites, and we want SEO (Search Engine Optimization).
 
-To help me with this, let me introduce another addon,
-[**Prember**](https://github.com/ef4/prember). You just need to tell Prember
-which URLs you want converted into static HTML websites, and the addon does it
-for you in build time.
+To help me with this, let me introduce another addon, [**Prember**](https://github.com/ef4/prember). You just need to tell Prember which URLs you want converted into static HTML websites, and the addon does it for you in build time.
 
 Here is how I specified them:
 
@@ -429,8 +279,7 @@ module.exports = function (defaults) {
 };
 ```
 
-How do I keep Prember aware of the URLs of my posts (since I’ll keep adding new
-ones)?
+How do I keep Prember aware of the URLs of my posts (since I’ll keep adding new ones)?
 
 I built a function to help me with this, which you can see in the code above:
 
@@ -441,62 +290,26 @@ let posts = fs.readdirSync("data/post").map(file => {
 });
 ```
 
-I create a posts array that is populated with all the files I have under
-data/post directory. I make some changes before I save it to my array, the files
-there look like this _working-from-cv.md_, I remove the _.md_ and I attach
-_posts/_, so at the end I have an array of the URLs to my posts that look like
-this _posts/working-from-cv_.
+I create a posts array that is populated with all the files I have under data/post directory. I make some changes before I save it to my array, the files there look like this _working-from-cv.md_, I remove the _.md_ and I attach _posts/_, so at the end I have an array of the URLs to my posts that look like this _posts/working-from-cv_.
 
-Now, I just need to add the array containing all the URLs to my posts with all
-the other URLs for the other pages -
-`urls: ['/', '/about-me', '/contact', '/posts', ...posts]`, with `…posts`,
-javascript will deconstruct my array and add its values to the urls array.
+Now, I just need to add the array containing all the URLs to my posts with all the other URLs for the other pages - `urls: ['/', '/about-me', '/contact', '/posts', ...posts]`, with `…posts`, javascript will deconstruct my array and add its values to the urls array.
 
 ## My Thoughts About This Project
 
 Seven months have passed since I released my website.
 
-It was rewarding to learn and use my current knowledge to create a website that
-would match my personality: it felt like decorating a house. 😆 I started by
-collecting inspiration from other websites, then I sketched how I wanted the
-pages to look in Figma, and finally, I started coding. Having the sketches in
-the first place helped me a lot throughout the process. I also realized that
-some design choices were harder to implement than I thought, so I kept embracing
-some improvisation. 😅
-
-After I deployed it, I made some improvements, primarily related to the
-performance. By running Lighthouse, I saw that my biggest issue was not being
-efficient when loading my images. I recently added a little reaction button at
-the end of my posts. (inspired by Josh Comeau's website).
-
-I don't have a long experience in web development, so for me, going from react
-to ember it wasn't the smoothest transition as I found Ember a bit harder. I
-guess every framework has its pros and cons. In React, dealing with component
-states can become messy; in Ember, you don't need to care about it. In Ember,
-having all these separate files that target the same page can create confusion -
-controllers, .js, .hbs. However, some people prefer this approach. In the end,
-choices like these are very subjective.
-
-Ember has a more traditional approach to object-oriented programming. It
-resembled what I learned at university way more.
-
-Regarding the type of project I built - a personal website/blog. I might be
-falling into the group of the people who create a blog and never post on it. 🙈
-I think I put a lot of pressure when I start working on a post, and I made them
-very long - this adds friction to posting regularly. Also, when I designed how
-to present the information, I just kept long posts in mind.
-
-My pieces of advice are: choose a publishing tool that is easy enough - the
-markdown files approach is working well for me; when sketching your website,
-keep short posts in mind as well.
-
-Since almost every human is an internet user nowadays, it is nice to have your
-own website where you can share your work and interests - you can end up meeting
-more people with the same interests as you and possibly initiate cool work
-collaborations.
-
-If you want to check my internet corner you can access it
-[here](https://inesoaresilva.com/), there you can find another blog post about
-my journey building the project. What are your thoughts about having a personal
-website? Feel free to reach out to me with feedback or to discuss about this
-topic. 😄👋🏼
+It was rewarding to learn and use my current knowledge to create a website that would match my personality: it felt like decorating a house. 😆 I started by collecting inspiration from other websites, then I sketched how I wanted the pages to look in Figma, and finally, I started coding. Having the sketches in the first place helped me a lot throughout the process. I also realized that some design choices were harder to implement than I thought, so I kept embracing some improvisation. 😅
+
+After I deployed it, I made some improvements, primarily related to the performance. By running Lighthouse, I saw that my biggest issue was not being efficient when loading my images. I recently added a little reaction button at the end of my posts. (inspired by Josh Comeau's website).
+
+I don't have a long experience in web development, so for me, going from react to ember it wasn't the smoothest transition as I found Ember a bit harder. I guess every framework has its pros and cons. In React, dealing with component states can become messy; in Ember, you don't need to care about it. In Ember, having all these separate files that target the same page can create confusion - controllers, .js, .hbs. However, some people prefer this approach. In the end, choices like these are very subjective.
+
+Ember has a more traditional approach to object-oriented programming. It resembled what I learned at university way more.
+
+Regarding the type of project I built - a personal website/blog. I might be falling into the group of the people who create a blog and never post on it. 🙈 I think I put a lot of pressure when I start working on a post, and I made them very long - this adds friction to posting regularly. Also, when I designed how to present the information, I just kept long posts in mind.
+
+My pieces of advice are: choose a publishing tool that is easy enough - the markdown files approach is working well for me; when sketching your website, keep short posts in mind as well.
+
+Since almost every human is an internet user nowadays, it is nice to have your own website where you can share your work and interests - you can end up meeting more people with the same interests as you and possibly initiate cool work collaborations.
+
+If you want to check my internet corner you can access it [here](https://inesoaresilva.com/), there you can find another blog post about my journey building the project. What are your thoughts about having a personal website? Feel free to reach out to me with feedback or to discuss about this topic. 😄👋🏼
diff --git a/src/posts/2023-08-01-pitching-rust-to-decision-makers-with-joel-marcey.md b/src/posts/2023-08-01-pitching-rust-to-decision-makers-with-joel-marcey.md
index 1ae46a1e1b..26f61f32d8 100644
--- a/src/posts/2023-08-01-pitching-rust-to-decision-makers-with-joel-marcey.md
+++ b/src/posts/2023-08-01-pitching-rust-to-decision-makers-with-joel-marcey.md
@@ -3,9 +3,7 @@ title: "Pitching Rust to decision-makers - with Joel Marcey"
 authorHandle: marcoow
 tags: [rust]
 bio: "Marco Otte-Witte"
-description:
-  "Joel Marcey and Marco Otte-Witte talk about approaches for pitching Rust to
-  decision-makers."
+description: "Joel Marcey and Marco Otte-Witte talk about approaches for pitching Rust to decision-makers."
 og:
   image: /assets/images/posts/2023-08-01-pitching-rust-to-decision-makers-with-joel-marcey/og-image.jpg
 tagline: |
@@ -15,27 +13,10 @@ image: "/assets/images/posts/2023-08-01-pitching-rust-to-decision-makers-with-jo
 imageAlt: "Joel's picture on a gray background"
 ---
 
-Joel Marcey, Director of Technology at the Rust Foundation, and Marco
-Otte-Witte, Founder of Mainmatter, discuss the benefits and disadvantages of
-Rust and how to pitch it to decision-makers. Joel also talks about the Rust
-Foundation’s goals and his role within it. He goes on to share success stories
-from companies such as 1password, KDAB, Tweede golf, and Meta.
+Joel Marcey, Director of Technology at the Rust Foundation, and Marco Otte-Witte, Founder of Mainmatter, discuss the benefits and disadvantages of Rust and how to pitch it to decision-makers. Joel also talks about the Rust Foundation’s goals and his role within it. He goes on to share success stories from companies such as 1password, KDAB, Tweede golf, and Meta.
 
-Marco and Joel then review Rust’s benefits, including safety, efficiency, and
-security, and highlight its stability and reliability improvements that allow
-developers to catch whole classes of errors at build time instead of runtime.
-Joel also mentions the productivity and maintainability gains that people
-typically see when switching to Rust and Marco points out how the more dynamic,
-untyped languages, that are typically used in web development, all go back to
-types for that exact reason.
+Marco and Joel then review Rust’s benefits, including safety, efficiency, and security, and highlight its stability and reliability improvements that allow developers to catch whole classes of errors at build time instead of runtime. Joel also mentions the productivity and maintainability gains that people typically see when switching to Rust and Marco points out how the more dynamic, untyped languages, that are typically used in web development, all go back to types for that exact reason.
 
-Finally, the conversation shifts to the topic of pitching Rust adoption to
-decision-makers. Joel explains that Rust is now typically already in the
-conversation whenever a language is chosen and that it’s always crucial to be
-upfront about the disadvantages of Rust, like the steep learning curve, and to
-make clear what use cases it is not suitable for, like frontend web development.
-Lastly, Joel highlights the importance of focusing on Rust’s stability,
-security, and significant operational cost reduction due to its efficiency, when
-pitching.
+Finally, the conversation shifts to the topic of pitching Rust adoption to decision-makers. Joel explains that Rust is now typically already in the conversation whenever a language is chosen and that it’s always crucial to be upfront about the disadvantages of Rust, like the steep learning curve, and to make clear what use cases it is not suitable for, like frontend web development. Lastly, Joel highlights the importance of focusing on Rust’s stability, security, and significant operational cost reduction due to its efficiency, when pitching.
 
 <iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/T951xRBcGD8" title="Embedded video of Joel's interview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
diff --git a/src/posts/2023-08-14-the-case-for-rust-on-the-web.md b/src/posts/2023-08-14-the-case-for-rust-on-the-web.md
index bfd785c9c3..94980b548c 100644
--- a/src/posts/2023-08-14-the-case-for-rust-on-the-web.md
+++ b/src/posts/2023-08-14-the-case-for-rust-on-the-web.md
@@ -3,148 +3,54 @@ title: "The Case for Rust on the Web"
 authorHandle: marcoow
 tags: [rust]
 bio: "Marco Otte-Witte"
-description:
-  "Marco Otte-Witte explains why Mainmatter believes Rust has a bright future
-  for web backend development."
+description: "Marco Otte-Witte explains why Mainmatter believes Rust has a bright future for web backend development."
 og:
   image: /assets/images/posts/2023-08-14-the-case-for-rust-on-the-web/og-image.png
-tagline:
-  '<p>Mainmatter <a href="/blog/2022/10/12/making-a-strategic-bet-on-rust/">made
-  a strategic bet on Rust for the web</a> in the last year. Our goal is to guide
-  teams during the process of adopting Rust in web environments and we''re on
-  our way towards reaching that goal: we started the EuroRust conference, we
-  joined the Rust Foundation, we hired Rust expert and author <a
-  href="http://twitter.com/algo_luca/">Luca Palmieri</a> as our Principal
-  Engineering Consultant and are working on a number of Rust projects internally
-  as well as in the open source space.</p><p>In this post, I want to share why
-  we''re confident taking that bet and why we believe Rust has a great future
-  ahead of it in the web and cloud space.</p>'
+tagline: '<p>Mainmatter <a href="/blog/2022/10/12/making-a-strategic-bet-on-rust/">made a strategic bet on Rust for the web</a> in the last year. Our goal is to guide teams during the process of adopting Rust in web environments and we''re on our way towards reaching that goal: we started the EuroRust conference, we joined the Rust Foundation, we hired Rust expert and author <a href="http://twitter.com/algo_luca/">Luca Palmieri</a> as our Principal Engineering Consultant and are working on a number of Rust projects internally as well as in the open source space.</p><p>In this post, I want to share why we''re confident taking that bet and why we believe Rust has a great future ahead of it in the web and cloud space.</p>'
 image: "/assets/images/posts/2023-08-14-the-case-for-rust-on-the-web/header.png"
 imageAlt: "The Rust logo on top of a stylized world map"
 ---
 
-Rust has received a lot of developer attention and love ever since it entered
-the stage around a decade ago. And it's not only the developers that love the
-language – the decision makers at the big corporates agree Rust is a great
-technology to build on and the language has seen a lot of adoption throughout
-the industry over the past few years. AWS uses Rust heavily
-[for their platform](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/),
-Google uses it
-[in Android](https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html),
-Microsoft uses it
-[in Windows](https://www.theregister.com/2023/04/27/microsoft_windows_rust/).
-Essentially, Rust is on track to replace C and C++ in many of the domains those
-were used before: systems programming, operating systems, all kinds of embedded
-systems, low level tooling, as well as in games and game engines.
-
-Yet, we believe Rust has even more potential and a great future in other areas:
-the web and the cloud. Rust might not be an obvious choice there - those are not
-areas where many teams were previously using a low-level language like C or C++.
-Nonetheless, we believe that Rust can bring the development of web backends to
-the next level, giving teams access to capabilities that were previously out of
-reach – what those are we'll see in more detail below. We can already see quite
-a few companies using Rust successfully in the web and the cloud, even though
-Rust is still young and evolving in these areas:
-[Truelayer](http://truelayer.com), [Discord](http://discord.com),
-[Temporal](http://temporal.io), [Nando's](https://nandos.co.uk),
-[svix](http://svix.com), [Wingback](https://www.wingback.com/), and many others.
+Rust has received a lot of developer attention and love ever since it entered the stage around a decade ago. And it's not only the developers that love the language – the decision makers at the big corporates agree Rust is a great technology to build on and the language has seen a lot of adoption throughout the industry over the past few years. AWS uses Rust heavily [for their platform](https://aws.amazon.com/blogs/opensource/sustainability-with-rust/), Google uses it [in Android](https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html), Microsoft uses it [in Windows](https://www.theregister.com/2023/04/27/microsoft_windows_rust/). Essentially, Rust is on track to replace C and C++ in many of the domains those were used before: systems programming, operating systems, all kinds of embedded systems, low level tooling, as well as in games and game engines.
+
+Yet, we believe Rust has even more potential and a great future in other areas: the web and the cloud. Rust might not be an obvious choice there - those are not areas where many teams were previously using a low-level language like C or C++. Nonetheless, we believe that Rust can bring the development of web backends to the next level, giving teams access to capabilities that were previously out of reach – what those are we'll see in more detail below. We can already see quite a few companies using Rust successfully in the web and the cloud, even though Rust is still young and evolving in these areas: [Truelayer](http://truelayer.com), [Discord](http://discord.com), [Temporal](http://temporal.io), [Nando's](https://nandos.co.uk), [svix](http://svix.com), [Wingback](https://www.wingback.com/), and many others.
 
 ## What?
 
-Around 8 years after its 1.0 release, Rust is still a relative young ecosystem.
-Yet, it's reached a level of maturity that makes it a viable choice to build
-real applications and Rust's web ecosystem is no exception there. Rust is
-clearly ready for the web as [arewewebyet.org](http://arewewebyet.org) confirms:
+Around 8 years after its 1.0 release, Rust is still a relative young ecosystem. Yet, it's reached a level of maturity that makes it a viable choice to build real applications and Rust's web ecosystem is no exception there. Rust is clearly ready for the web as [arewewebyet.org](http://arewewebyet.org) confirms:
 
 ![arewewebyet.org](/assets/images/posts/2023-08-14-the-case-for-rust-on-the-web/arewewebyet.png)
 
-First of all, there's [tokio](http://tokio.rs), an asynchronous runtime that's a
-solid and performant foundation for networking applications. On top of that,
-there's mature and well-maintained web frameworks like
-[axum](http://github.com/tokio-rs/axum/) and [actix-web](https://actix.rs).
-There's mature drivers for all of the relevant datastores as well as ORMs.
-Finally, you can find libraries covering all other relevant aspects for building
-web apps, such as (de-)serialization, internationalisation, templating,
-observability, etc. Overall, Rust provides solid and stable building blocks for
-building ambitious web backends.
+First of all, there's [tokio](http://tokio.rs), an asynchronous runtime that's a solid and performant foundation for networking applications. On top of that, there's mature and well-maintained web frameworks like [axum](http://github.com/tokio-rs/axum/) and [actix-web](https://actix.rs). There's mature drivers for all of the relevant datastores as well as ORMs. Finally, you can find libraries covering all other relevant aspects for building web apps, such as (de-)serialization, internationalisation, templating, observability, etc. Overall, Rust provides solid and stable building blocks for building ambitious web backends.
 
 ## Why?
 
-Of course one might ask: why should you care? What could motivate a team that
-already uses Ruby, Java, Elixir, TypeScript, Go, or whatever else, to adopt
-Rust? There are two key aspects that make Rust a great choice for building for
-the web:
+Of course one might ask: why should you care? What could motivate a team that already uses Ruby, Java, Elixir, TypeScript, Go, or whatever else, to adopt Rust? There are two key aspects that make Rust a great choice for building for the web:
 
 - its efficiency and performance
 - the reliability and maintainability gains brought by its type system
 
 ### Efficiency and Performance
 
-Rust is famously efficient and performant. It will easily outperform languages
-like JavaScript, Ruby, Python, etc. that are commonly used for web applications,
-by several orders of magnitude. Other languages may have a higher performance
-ceiling (e.g. Java or C# or Go), but you need to invest serious engineering
-effort to come close to the level of performance offered by Rust's toolkit out
-of the box. In addition, Rust has a key advantage: it doesn't bundle a garbage
-collector. Garbage-collected languages can be plenty fast, but they are not
-**consistently** performant at all times. The garbage collector will introduce
-pauses in order to free unused memory, negatively impacting the tail latency
-(p95/p99) of your applications. Rust doesn't have this problem: it can deliver
-consistent performance without those spikes.
+Rust is famously efficient and performant. It will easily outperform languages like JavaScript, Ruby, Python, etc. that are commonly used for web applications, by several orders of magnitude. Other languages may have a higher performance ceiling (e.g. Java or C# or Go), but you need to invest serious engineering effort to come close to the level of performance offered by Rust's toolkit out of the box. In addition, Rust has a key advantage: it doesn't bundle a garbage collector. Garbage-collected languages can be plenty fast, but they are not **consistently** performant at all times. The garbage collector will introduce pauses in order to free unused memory, negatively impacting the tail latency (p95/p99) of your applications. Rust doesn't have this problem: it can deliver consistent performance without those spikes.
 
 ![Performance charts of garbage-collected languages and non-garbage-collected languages](/assets/images/posts/2023-08-14-the-case-for-rust-on-the-web/perf-charts.png)
 
-C and C++ are the only other languages that allowed for such stable and
-consistent performance. Unfortunately, they are full of pitfalls and
-opportunities for shooting yourself in the foot, in particular by making
-mistakes doing manual memory management. As Linus Torvalds, the creator of
-Linux, says:
-
-> "[…] it is so close to the hardware that you can do anything with it. It is
-> dangerous. It's like juggling chainsaws. I also see that it does have a lot of
-> pitfalls and they're easy to overlook. <author>Linus Torvalds</author>
-
-Because of these dangers of C and C++, both languages are really only usable
-when you're an expert in them or have an expert team – if you don't, you end up
-with systems that will be unstable and full of security vulnerabilities. In the
-web field though, nobody has that expertise as everyone mostly uses very
-different languages like JavaScript, Python, Ruby, Elixir, etc. That way, Rust
-not coming with the same pitfalls, empowers developers to build software at
-levels of efficiency that were previously out of reach for them. Rust will
-typically outperform other technologies commonly used to build web backends by
-several orders of magnitude while at the same time keeping a significantly lower
-memory footprint.
-
-Of course, if your Rust web server can respond to requests in a fraction of the
-time compared to other technologies, it also means it can respond to the same
-number of requests with a fraction of the servers, which again means a fraction
-of the hosting cost. That difference has real financial consequences – as great
-as cloud hosting is, it's certainly not cheap. Being able to just switch off a
-substantial amount of cloud servers can easily be a reduction of hundreds of
-thousands of Euros per month even for small to mid-sized products and companies.
-
-> […] our Python services average about 50 req/s, NodeJS around 100 req/s, and
-> Rust hits about 690 req/s. We can fit 4 Rust services on a k8 EKS node that
-> would normally host a single Python service. <author>someone on
-> reddit.com</author>
-
-Financial savings aren't even the whole story though. Using fewer servers also
-means using less energy. As good as running data centers on renewables is, the
-greenest energy still is the energy we don't use. And while it would be
-ridiculous to claim Rust is going to solve the climate crisis, it's important to
-acknowledge that the software we all write uses real resources and thus has an
-impact on the real world. Our industry has a tendency to forget about the
-resources our work consumes, although the
-[ICT sector accounts for 8-10% of the European CO2 emissions](https://ictfootprint.eu/en/about/ict-carbon-footprint/ict-carbon-footprint)
-– if we can use resource more efficiently and get the same output for less
-input, that's an aspect to consider when choosing a technology.
+C and C++ are the only other languages that allowed for such stable and consistent performance. Unfortunately, they are full of pitfalls and opportunities for shooting yourself in the foot, in particular by making mistakes doing manual memory management. As Linus Torvalds, the creator of Linux, says:
+
+> "[…] it is so close to the hardware that you can do anything with it. It is dangerous. It's like juggling chainsaws. I also see that it does have a lot of pitfalls and they're easy to overlook. <author>Linus Torvalds</author>
+
+Because of these dangers of C and C++, both languages are really only usable when you're an expert in them or have an expert team – if you don't, you end up with systems that will be unstable and full of security vulnerabilities. In the web field though, nobody has that expertise as everyone mostly uses very different languages like JavaScript, Python, Ruby, Elixir, etc. That way, Rust not coming with the same pitfalls, empowers developers to build software at levels of efficiency that were previously out of reach for them. Rust will typically outperform other technologies commonly used to build web backends by several orders of magnitude while at the same time keeping a significantly lower memory footprint.
+
+Of course, if your Rust web server can respond to requests in a fraction of the time compared to other technologies, it also means it can respond to the same number of requests with a fraction of the servers, which again means a fraction of the hosting cost. That difference has real financial consequences – as great as cloud hosting is, it's certainly not cheap. Being able to just switch off a substantial amount of cloud servers can easily be a reduction of hundreds of thousands of Euros per month even for small to mid-sized products and companies.
+
+> […] our Python services average about 50 req/s, NodeJS around 100 req/s, and Rust hits about 690 req/s. We can fit 4 Rust services on a k8 EKS node that would normally host a single Python service. <author>someone on reddit.com</author>
+
+Financial savings aren't even the whole story though. Using fewer servers also means using less energy. As good as running data centers on renewables is, the greenest energy still is the energy we don't use. And while it would be ridiculous to claim Rust is going to solve the climate crisis, it's important to acknowledge that the software we all write uses real resources and thus has an impact on the real world. Our industry has a tendency to forget about the resources our work consumes, although the [ICT sector accounts for 8-10% of the European CO2 emissions](https://ictfootprint.eu/en/about/ict-carbon-footprint/ict-carbon-footprint) – if we can use resource more efficiently and get the same output for less input, that's an aspect to consider when choosing a technology.
 
 ### Reliability and Maintainability
 
-While performance and efficiency might be the most obvious reasons to choose
-Rust for a project, they are not the only ones. Other, maybe more relevant
-reasons in many cases, are the reliability and maintainability gains that Rust's
-strong type system unlocks.
+While performance and efficiency might be the most obvious reasons to choose Rust for a project, they are not the only ones. Other, maybe more relevant reasons in many cases, are the reliability and maintainability gains that Rust's strong type system unlocks.
 
 Snippets like this one are fairly typical for a web application (Ruby on Rails):
 
@@ -170,33 +76,11 @@ end
 user.activate(Time.now)
 ```
 
-While this code is quite succinct and pleasant to read and writing code like
-this will let you reach your goal fast, there are problems. In this (admittedly
-simple) example, while we can see the user's attributes, we don't know what
-rules there might be around those (e.g., if `active` is `true`,
-`activation_date` must be set as well probably? If `active` is `false`,
-presumably `activation_date` should be `nil`?). In order to validate these
-assumption, one has to look into the implementation of the `activate` method
-which means relatively high effort is required to get to the information.
-
-Looking at the invocation of the `activate` method, we can't know whether it
-might raise an error or what timezone we're supposed to pass the time in. And
-while Ruby might be a bit of an extreme example given its notorious flexibility,
-many of these problems can be found in other languages as well. Let's look at
-Java, as an example. We would still have no way to encode the rules around the
-`active` and `activation_date` attributes in the type system, nor when things
-can be `null` and we risk getting `NullPointerException`s at runtime.
-
-These issues become more and more relevant over time as the codebase grows and
-the team working on it grows as well, or just changes as some people leave and
-others join. It is no longer true that everyone working on the codebase has a
-perfect mental model of the entire application and all the implicit assumptions
-being made throughout the codebase. Instead understanding those concepts will
-require people to carefully read through classes and methods and tests. That
-task becomes more and more unrealistic over time, in particular for new joiners
-of which there tend to be plenty in long living codebases over time. That not
-only decreases efficiency but also likely results in increased error rates in
-production as people not familiar with the application make mistakes.
+While this code is quite succinct and pleasant to read and writing code like this will let you reach your goal fast, there are problems. In this (admittedly simple) example, while we can see the user's attributes, we don't know what rules there might be around those (e.g., if `active` is `true`, `activation_date` must be set as well probably? If `active` is `false`, presumably `activation_date` should be `nil`?). In order to validate these assumption, one has to look into the implementation of the `activate` method which means relatively high effort is required to get to the information.
+
+Looking at the invocation of the `activate` method, we can't know whether it might raise an error or what timezone we're supposed to pass the time in. And while Ruby might be a bit of an extreme example given its notorious flexibility, many of these problems can be found in other languages as well. Let's look at Java, as an example. We would still have no way to encode the rules around the `active` and `activation_date` attributes in the type system, nor when things can be `null` and we risk getting `NullPointerException`s at runtime.
+
+These issues become more and more relevant over time as the codebase grows and the team working on it grows as well, or just changes as some people leave and others join. It is no longer true that everyone working on the codebase has a perfect mental model of the entire application and all the implicit assumptions being made throughout the codebase. Instead understanding those concepts will require people to carefully read through classes and methods and tests. That task becomes more and more unrealistic over time, in particular for new joiners of which there tend to be plenty in long living codebases over time. That not only decreases efficiency but also likely results in increased error rates in production as people not familiar with the application make mistakes.
 
 The same code snippet as above but in Rust is much clearer and expressive:
 
@@ -233,225 +117,82 @@ impl User {
 }
 ```
 
-First of all, for the user model, we can use Rust's `enum` with associated data.
-That way, it's completely clear what inactive and active users look like and
-what attributes can be expected to be set in what scenarios – in fact, active
-and inactive users do not even have the same attributes but each only has the
-ones that make sense for the respective user state they represent. Also the
-attribute's types are clearly defined – not only is Rust typed while Ruby is
-untyped obviously but the types are also very precise so that e.g. for the
-`activation_date` field, the expected timezone is right in the type as well.
-
-The signature of the `activate` function also encodes, explicitly, a lot of the
-information that was implicit in the Rails example. Again, the expected timezone
-for the `activation_date` is right in the type, and also the function returns
-[Rust's `Result`](https://doc.rust-lang.org/1.68.2/std/result/enum.Result.html)
-which clearly communicates that errors might occur when calling it. In fact, the
-Rust compiler will require both the success and error variant of the `Result` to
-be handled so that no unhandled runtime exceptions can occur.
-
-Additionally, the `activation_date` argument of the function is always
-guaranteed to have a value when the function is called since Rust does not have
-a concept of implicit nullability (as opposed to e.g. Java). If the
-`activation_date` _could_ potentially not have a value at the place where its
-calculated, it would probably be an
-[`Option<DateTime<Utc>>`](https://doc.rust-lang.org/1.68.2/std/option/enum.Option.html)
-which could not be passed to the `activate` function as its a different type
-than the expected `DateTime<Utc>`. The Rust compiler would only allow the code
-path for the `Some` variant of that `Option` to result in an invocation of the
-`activate` method so that `activation_date` is guaranteed to have a value when
-the function runs.
-
-While this is obviously a rather simple example, it illustrates the two main
-advantages of Rust well:
-
-- Many of the concepts and rules that were implicit in the Rails example are
-  explicitly communicated through types in the Rust code. Active and inactive
-  users can be clearly distinguished, and for the date fields even the expected
-  timezone is encoded in the types. That expressiveness makes the code much more
-  approachable, in particular to newcomers to the codebase, thus resulting in
-  improved maintainability.
-- Rust substantially improves reliability as well since whole classes of errors
-  that are common in other languages (including typed languages such as Java or
-  Go) will be detected at compile time instead of runtime. The compiler
-  guarantees the `activation_date` argument of the `activate` function to have a
-  value and any error that's potentially returned by the function to be handled.
-
-Overall, the improvements in reliability and maintainability that Rust comes
-with are often overlooked while everyone is focussed on Rust's performance.
-However, in many cases these benefits might be more relevant for a project's
-long term success than sheer performance numbers.
+First of all, for the user model, we can use Rust's `enum` with associated data. That way, it's completely clear what inactive and active users look like and what attributes can be expected to be set in what scenarios – in fact, active and inactive users do not even have the same attributes but each only has the ones that make sense for the respective user state they represent. Also the attribute's types are clearly defined – not only is Rust typed while Ruby is untyped obviously but the types are also very precise so that e.g. for the `activation_date` field, the expected timezone is right in the type as well.
+
+The signature of the `activate` function also encodes, explicitly, a lot of the information that was implicit in the Rails example. Again, the expected timezone for the `activation_date` is right in the type, and also the function returns [Rust's `Result`](https://doc.rust-lang.org/1.68.2/std/result/enum.Result.html) which clearly communicates that errors might occur when calling it. In fact, the Rust compiler will require both the success and error variant of the `Result` to be handled so that no unhandled runtime exceptions can occur.
+
+Additionally, the `activation_date` argument of the function is always guaranteed to have a value when the function is called since Rust does not have a concept of implicit nullability (as opposed to e.g. Java). If the `activation_date` _could_ potentially not have a value at the place where its calculated, it would probably be an [`Option<DateTime<Utc>>`](https://doc.rust-lang.org/1.68.2/std/option/enum.Option.html) which could not be passed to the `activate` function as its a different type than the expected `DateTime<Utc>`. The Rust compiler would only allow the code path for the `Some` variant of that `Option` to result in an invocation of the `activate` method so that `activation_date` is guaranteed to have a value when the function runs.
+
+While this is obviously a rather simple example, it illustrates the two main advantages of Rust well:
+
+- Many of the concepts and rules that were implicit in the Rails example are explicitly communicated through types in the Rust code. Active and inactive users can be clearly distinguished, and for the date fields even the expected timezone is encoded in the types. That expressiveness makes the code much more approachable, in particular to newcomers to the codebase, thus resulting in improved maintainability.
+- Rust substantially improves reliability as well since whole classes of errors that are common in other languages (including typed languages such as Java or Go) will be detected at compile time instead of runtime. The compiler guarantees the `activation_date` argument of the `activate` function to have a value and any error that's potentially returned by the function to be handled.
+
+Overall, the improvements in reliability and maintainability that Rust comes with are often overlooked while everyone is focussed on Rust's performance. However, in many cases these benefits might be more relevant for a project's long term success than sheer performance numbers.
 
 ## How & Where?
 
-As Rust's main advantages are reliability, maintainability, efficiency, and
-performance, use cases for the language are obviously ones where these four
-aspects are particularly relevant. While one could say those aspects are always
-relevant and generally be correct saying that, the benefits come at a cost that
-needs to be accounted for.
+As Rust's main advantages are reliability, maintainability, efficiency, and performance, use cases for the language are obviously ones where these four aspects are particularly relevant. While one could say those aspects are always relevant and generally be correct saying that, the benefits come at a cost that needs to be accounted for.
 
-Overall, Rust still requires a higher upfront investment than other
-technologies, in particular compared to those commonly used in web projects:
+Overall, Rust still requires a higher upfront investment than other technologies, in particular compared to those commonly used in web projects:
 
 ![Chart showing the initial effort for building on Rust compared to other languages](/assets/images/posts/2023-08-14-the-case-for-rust-on-the-web/initial-effort.png)
 
-While languages like JavaScript and Ruby are made for getting results fast, Rust
-deliberately doesn't leave as much freedom and requires a program to pass all of
-the compiler's checks before one gets to a working result. That requires higher
-initial effort for building an application with Rust compared to those
-languages. Additionally, there's a mountain people need to climb before they're
-productive with Rust at all – that is mastering Rust's unique ownership system.
+While languages like JavaScript and Ruby are made for getting results fast, Rust deliberately doesn't leave as much freedom and requires a program to pass all of the compiler's checks before one gets to a working result. That requires higher initial effort for building an application with Rust compared to those languages. Additionally, there's a mountain people need to climb before they're productive with Rust at all – that is mastering Rust's unique ownership system.
 
-However, when looking beyond the initial stages of a project and expanding the
-view on a longer time horizon where aspects like maintainability, reliability,
-and stability become exceedingly important, the picture changes as the effort
-for working on Rust projects goes down over time:
+However, when looking beyond the initial stages of a project and expanding the view on a longer time horizon where aspects like maintainability, reliability, and stability become exceedingly important, the picture changes as the effort for working on Rust projects goes down over time:
 
 ![Chart showing the effort required for building and maintaining Rust applications over time](/assets/images/posts/2023-08-14-the-case-for-rust-on-the-web/total-effort.png)
 
-Rust apps being more reliable and thus requiring less time invested into bug
-fixing, as well as being more maintainable and thus easier to work on
-efficiently with growing and changing teams, results in effort going down over
-time. That tends to be the other way round for other languages where effort goes
-up over time as the impact of reliability and maintainability challenges becomes
-bigger and more costly as the team grows. The additional investment made in the
-beginning when using Rust pays dividends over time.
+Rust apps being more reliable and thus requiring less time invested into bug fixing, as well as being more maintainable and thus easier to work on efficiently with growing and changing teams, results in effort going down over time. That tends to be the other way round for other languages where effort goes up over time as the impact of reliability and maintainability challenges becomes bigger and more costly as the team grows. The additional investment made in the beginning when using Rust pays dividends over time.
 
 ### Use Cases & Adoption Paths
 
-Based on Rust's strengths and effort curve, whenever evaluating whether or not
-to choose Rust for a particular case, the main questions to answer are:
+Based on Rust's strengths and effort curve, whenever evaluating whether or not to choose Rust for a particular case, the main questions to answer are:
 
-- Does the team have Rust expertise already (and many teams that don't use Rust
-  already actually have expertise because so many developers code in Rust in
-  their freetime)?
+- Does the team have Rust expertise already (and many teams that don't use Rust already actually have expertise because so many developers code in Rust in their freetime)?
 - What are the requirements regarding reliability?
 - What are the plans for long term maintenance?
-- What scale is the system being built for and thus how much money could Rust
-  potentially save in terms of hosting?
-- Based on the answers to the above questions, is the additional initial
-  investment worth it?
-
-While in some cases the conclusion will be that the additional initial
-investment is not worth it, for some cases the assessment will be clearly in
-Rust's favor. Some typical use cases we're seeing include:
-
-- For core business systems that implement the key business logic for a product,
-  aspects like reliability and long-term maintainability are primary concerns.
-- For financial systems, there is generally little tolerance for bugs and the
-  improved stability that Rust leads to can be a deciding factor. Plus,
-  performance is a key requirement with a clear financial impact in specific
-  scenarios (e.g. trading systems).
-- Any system that must be able to deliver high throughput and performance will
-  clearly benefit from Rust. Systems like proxy servers that sit in front of a
-  number of microservices must have minimal overhead and consistent performance.
-  Garbage collected languages with their unreliable performance characteristics
-  are typically not an option in these cases.
-- Finally, for any system that is run at large scale, there are big saving
-  potentials in terms of hosting costs.
-
-Once a decision for Rust has been made, there's two main adoption paths – either
-an entire application is (re-)written from scratch in Rust or you are looking at
-incremental adoption alongside other technologies.
+- What scale is the system being built for and thus how much money could Rust potentially save in terms of hosting?
+- Based on the answers to the above questions, is the additional initial investment worth it?
+
+While in some cases the conclusion will be that the additional initial investment is not worth it, for some cases the assessment will be clearly in Rust's favor. Some typical use cases we're seeing include:
+
+- For core business systems that implement the key business logic for a product, aspects like reliability and long-term maintainability are primary concerns.
+- For financial systems, there is generally little tolerance for bugs and the improved stability that Rust leads to can be a deciding factor. Plus, performance is a key requirement with a clear financial impact in specific scenarios (e.g. trading systems).
+- Any system that must be able to deliver high throughput and performance will clearly benefit from Rust. Systems like proxy servers that sit in front of a number of microservices must have minimal overhead and consistent performance. Garbage collected languages with their unreliable performance characteristics are typically not an option in these cases.
+- Finally, for any system that is run at large scale, there are big saving potentials in terms of hosting costs.
+
+Once a decision for Rust has been made, there's two main adoption paths – either an entire application is (re-)written from scratch in Rust or you are looking at incremental adoption alongside other technologies.
 
 #### (Re-)Starting Fresh
 
-Whether an existing system is being replaced or something entirely new is being
-started, the Rust ecosystem is mature enough to build complete backends as
-explained above. While there might be no full-featured, batteries-included
-framework that handles all aspects of a big web backend application like a "Rust
-on Rails" just yet, all of the building blocks like web frameworks, ORMs, etc.
-exist and can be assembled together to cover all aspects that need to be handled
-in a full web backend.
-
-One thing to keep in mind when starting a project from scratch: Rust isn't
-necessarily your friend for prototyping and explorative coding, the kind taking
-place when the project domain might not be fully understood and the team might
-not have a clear idea of the final architecture they are going for. While
-technologies like Ruby on Rails are specifically built for that kind of work but
-then show their shortcomings over time, Rust is the other way round, as
-mentioned before. The same mechanisms that lead to improved reliability and
-maintainability make it harder to experiment since Rust requires the entire
-codebase to be consistent at all times. Because of that, it may be easier to
-replace an existing system with a Rust implementation instead of starting from a
-blank slate.
+Whether an existing system is being replaced or something entirely new is being started, the Rust ecosystem is mature enough to build complete backends as explained above. While there might be no full-featured, batteries-included framework that handles all aspects of a big web backend application like a "Rust on Rails" just yet, all of the building blocks like web frameworks, ORMs, etc. exist and can be assembled together to cover all aspects that need to be handled in a full web backend.
+
+One thing to keep in mind when starting a project from scratch: Rust isn't necessarily your friend for prototyping and explorative coding, the kind taking place when the project domain might not be fully understood and the team might not have a clear idea of the final architecture they are going for. While technologies like Ruby on Rails are specifically built for that kind of work but then show their shortcomings over time, Rust is the other way round, as mentioned before. The same mechanisms that lead to improved reliability and maintainability make it harder to experiment since Rust requires the entire codebase to be consistent at all times. Because of that, it may be easier to replace an existing system with a Rust implementation instead of starting from a blank slate.
 
 #### Incremental Adoption
 
-While every engineer likes a greenfield project, incremental adoption paths are
-typically easier to manage. Instead of rewriting entire applications in Rust,
-it's usually much more straightforward to extract individual aspects of existing
-systems into Rust (micro) services. For these kinds of projects, the lack of
-full-featured macro frameworks is also less critical, as much of the aspects
-that such frameworks would cover might not be relevant for these projects at all
-due to their limited scope.
-
-Overall, incremental adoption by (re-)implementing individual aspects of
-existing systems in Rust is the typical adoption path we're seeing. The reduced
-scope of such projects also reduces the overall risk – teams can evaluate
-whether Rust works for them without making a huge commitment. If they run into
-challenges working with Rust, no huge investment has been made and the decision
-is typically reversible without huge cost. If a team succeeds with Rust though,
-their success will typically inspire others and lead to more and more adoption
-throughout an organization.
-
-An even easier adoption path than building (micro) services is writing native
-extensions in Rust. Teams that have existing Node/Ruby/Elixir/Python/etc.
-applications that might suffer from performance or stability issues, might
-choose to rewrite parts of those applications in Rust and directly integrate the
-Rust code with their existing applications as native extensions (to learn
-[how that works in Elixir, have a look at Bart's post on the topic](https://mainmatter.com/blog/2023/02/01/using-rust-crates-in-elixir/)).
-While that used to require writing C or C++ code in most languages and thus
-wasn't a feasible option for most teams, Rust opens up that possibility. Like
-(micro) services, native extensions are a great first step on an incremental
-adoption path while keeping risk at a minimum.
+While every engineer likes a greenfield project, incremental adoption paths are typically easier to manage. Instead of rewriting entire applications in Rust, it's usually much more straightforward to extract individual aspects of existing systems into Rust (micro) services. For these kinds of projects, the lack of full-featured macro frameworks is also less critical, as much of the aspects that such frameworks would cover might not be relevant for these projects at all due to their limited scope.
+
+Overall, incremental adoption by (re-)implementing individual aspects of existing systems in Rust is the typical adoption path we're seeing. The reduced scope of such projects also reduces the overall risk – teams can evaluate whether Rust works for them without making a huge commitment. If they run into challenges working with Rust, no huge investment has been made and the decision is typically reversible without huge cost. If a team succeeds with Rust though, their success will typically inspire others and lead to more and more adoption throughout an organization.
+
+An even easier adoption path than building (micro) services is writing native extensions in Rust. Teams that have existing Node/Ruby/Elixir/Python/etc. applications that might suffer from performance or stability issues, might choose to rewrite parts of those applications in Rust and directly integrate the Rust code with their existing applications as native extensions (to learn [how that works in Elixir, have a look at Bart's post on the topic](https://mainmatter.com/blog/2023/02/01/using-rust-crates-in-elixir/)). While that used to require writing C or C++ code in most languages and thus wasn't a feasible option for most teams, Rust opens up that possibility. Like (micro) services, native extensions are a great first step on an incremental adoption path while keeping risk at a minimum.
 
 ## Where to?
 
-Rust is undoubtedly a great choice for building web applications in many cases.
-It offers significantly better efficiency and performance as well as improved
-reliability and maintainability compared to other technologies commonly used for
-building web applications. That increased value that Rust delivers comes at the
-cost of higher initial effort than for other technologies though. However, that
-doesn't have to stay like that forever and over time the initial effort required
-for adopting and building with Rust will go down, making it a viable choice for
-even more teams and projects.
+Rust is undoubtedly a great choice for building web applications in many cases. It offers significantly better efficiency and performance as well as improved reliability and maintainability compared to other technologies commonly used for building web applications. That increased value that Rust delivers comes at the cost of higher initial effort than for other technologies though. However, that doesn't have to stay like that forever and over time the initial effort required for adopting and building with Rust will go down, making it a viable choice for even more teams and projects.
 
 ![The initial effort required for building applications with Rust will go down over time](/assets/images/posts/2023-08-14-the-case-for-rust-on-the-web/reduce-effort.png)
 
-The language itself will continue to evolve and become more approachable. At the
-same time, frameworks and libraries will also continue to evolve and improve
-their concepts and APIs, making them easier to use. The ease of use of libraries
-like e.g. [express.js](http://expressjs.com) from the Node ecosystem is the
-benchmark that maintainers of web frameworks in Rust like
-[Rob Ede](http://twitter.com/robjtede), maintainer of [actix](http://actix.rs),
-are aiming for. While an ambitious goal, it's actually one that's possible to
-reach in the mid future.
-
-In parallel to existing frameworks and libraries like actix and axum continue to
-improve, new frameworks will be built at higher abstraction levels as well. As
-more teams adopt Rust for web backends, the community will explore and evaluate
-approaches, learn from evaluating those in different use cases, and collectively
-settle on a set of patterns and architectures. Eventually, we'll see
-full-featured macro-frameworks like a "Rust on Rails" that will significantly
-simplify building web applications in Rust.
-
-And the future in which Rust is easier to approach and adopting it doesn't come
-at an additional initial cost, isn't so far away even. Google, who have been
-adopting Rust significantly for years,
-[recently shared they don't really see a productivity penalty for Rust compared to any other language they use](https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html):
-
-> "Overall, we’ve seen no data to indicate that there is any productivity
-> penalty for Rust relative to any other language these developers previously
-> used at Google. <author>Lars Bergstrom, Google</author>
-
-While it might be questionable how that experience translates to other teams and
-companies, it is a strong positive signal for sure.
-
-We at Mainmatter are highly optimistic that Rust will take off in the web and
-cloud space in the coming months and years and for that reason have
-[made a strategic bet on Rust](/blog/2022/10/12/making-a-strategic-bet-on-rust/).
-We believe that Rust is the first step towards a new era of web development
-where developers can levarage a technology that allows them to reach higher and
-previously unthinkable levels of efficiency, stability, reliability, and
-maintainability without giving up on developer experience and productivity.
+The language itself will continue to evolve and become more approachable. At the same time, frameworks and libraries will also continue to evolve and improve their concepts and APIs, making them easier to use. The ease of use of libraries like e.g. [express.js](http://expressjs.com) from the Node ecosystem is the benchmark that maintainers of web frameworks in Rust like [Rob Ede](http://twitter.com/robjtede), maintainer of [actix](http://actix.rs), are aiming for. While an ambitious goal, it's actually one that's possible to reach in the mid future.
+
+In parallel to existing frameworks and libraries like actix and axum continue to improve, new frameworks will be built at higher abstraction levels as well. As more teams adopt Rust for web backends, the community will explore and evaluate approaches, learn from evaluating those in different use cases, and collectively settle on a set of patterns and architectures. Eventually, we'll see full-featured macro-frameworks like a "Rust on Rails" that will significantly simplify building web applications in Rust.
+
+And the future in which Rust is easier to approach and adopting it doesn't come at an additional initial cost, isn't so far away even. Google, who have been adopting Rust significantly for years, [recently shared they don't really see a productivity penalty for Rust compared to any other language they use](https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html):
+
+> "Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. <author>Lars Bergstrom, Google</author>
+
+While it might be questionable how that experience translates to other teams and companies, it is a strong positive signal for sure.
+
+We at Mainmatter are highly optimistic that Rust will take off in the web and cloud space in the coming months and years and for that reason have [made a strategic bet on Rust](/blog/2022/10/12/making-a-strategic-bet-on-rust/). We believe that Rust is the first step towards a new era of web development where developers can levarage a technology that allows them to reach higher and previously unthinkable levels of efficiency, stability, reliability, and maintainability without giving up on developer experience and productivity.
diff --git a/src/posts/2023-08-21-build-vs-hire.md b/src/posts/2023-08-21-build-vs-hire.md
index 42633cdfe8..2beef8a929 100644
--- a/src/posts/2023-08-21-build-vs-hire.md
+++ b/src/posts/2023-08-21-build-vs-hire.md
@@ -1,13 +1,9 @@
 ---
-title:
-  "How expensive is setting up your own team vs. hiring one that is ready-to-go?"
+title: "How expensive is setting up your own team vs. hiring one that is ready-to-go?"
 authorHandle: sarahlorenzu
 tags: [startups]
 bio: "Sarah Lorenz"
-description:
-  "Sarah Lorenz explores the advantages and disadvantages of building a tech
-  team versus hiring one. She suggests a hybrid method, Team reinforcement, and
-  shares Mainmatter’s experience with it in previous projects."
+description: "Sarah Lorenz explores the advantages and disadvantages of building a tech team versus hiring one. She suggests a hybrid method, Team reinforcement, and shares Mainmatter’s experience with it in previous projects."
 og:
   image: /assets/images/posts/2023-08-21-build-vs-hire/og-image.jpg
 tagline: |
@@ -17,105 +13,67 @@ image: "/assets/images/posts/2023-08-21-build-vs-hire/header-illustration.jpg"
 imageAlt: "A rocket icon on a grey image background"
 ---
 
-{% from "quote.njk" import quote %}
-{% from "logo-list.njk" import logoList with context%}
+{% from "quote.njk" import quote %} {% from "logo-list.njk" import logoList with context%}
 
 ## Build vs. Hire
 
 Why decide if you can benefit from both? - Augment!
 
-When building a technical team, there are two main options: You can build your
-own team from scratch or hire a ready-made one. Each approach has its pros and
-cons that can significantly impact your project's cost and efficiency. However,
-there is also a third option: You can get external help while you build internal
-capacity/capability.
+When building a technical team, there are two main options: You can build your own team from scratch or hire a ready-made one. Each approach has its pros and cons that can significantly impact your project's cost and efficiency. However, there is also a third option: You can get external help while you build internal capacity/capability.
 
 ## Building Your Own Team:
 
 #### Building your own tech team involves hiring individuals, onboarding, and making them work as a team.
 
-This process can be challenging and time-consuming. Finding the right people
-with the **necessary skills** and **experience** isn’t always easy, and
-establishing a fully functional team can take several months. Training and
-onboarding programs may be required to align the team with the project's goals
-and the company's processes and technologies.
+This process can be challenging and time-consuming. Finding the right people with the **necessary skills** and **experience** isn’t always easy, and establishing a fully functional team can take several months. Training and onboarding programs may be required to align the team with the project's goals and the company's processes and technologies.
 
 #### The recruitment process alone represents a significant cost for companies.
 
-Job postings, application processing, interviews, and other related activities
-require both time and financial resources. On average, it costs six to nine
-times an employee's monthly salary to replace them and train a newly hired
-employee. Supervisors' valuable time spent monitoring the training progress must
-also be considered.
+Job postings, application processing, interviews, and other related activities require both time and financial resources. On average, it costs six to nine times an employee's monthly salary to replace them and train a newly hired employee. Supervisors' valuable time spent monitoring the training progress must also be considered.
 
 #### The new hire needs the proper infrastructure to be able to start working.
 
-Additionally, companies must invest in infrastructure and provide the necessary
-resources for their newly hired team members.
+Additionally, companies must invest in infrastructure and provide the necessary resources for their newly hired team members.
 
 #### There’s a bookkeeping difference.
 
-Working with externals is a cash expense, while hiring is an ongoing expense in
-the books/long-term commitment.
+Working with externals is a cash expense, while hiring is an ongoing expense in the books/long-term commitment.
 
 ## Hiring a Ready-Made Team:
 
 #### Alternatively, you can opt to hire a ready-made tech team.
 
-This often involves collaborating with an agency that specializes in assembling
-teams of experienced professionals who have already worked together and have a
-proven track record of successful project delivery. This approach offers several
-benefits.
+This often involves collaborating with an agency that specializes in assembling teams of experienced professionals who have already worked together and have a proven track record of successful project delivery. This approach offers several benefits.
 
 #### Hiring a ready-made team can be more cost-effective and time-efficient.
 
-Firstly, agencies have already invested in recruiting and onboarding their team
-members, eliminating the need for individual hiring and training processes. As a
-result, you can save significantly on recruitment and training costs.
-Additionally, ready-made teams are generally well-versed in working together,
-which can lead to increased efficiency and a shorter time to market.
+Firstly, agencies have already invested in recruiting and onboarding their team members, eliminating the need for individual hiring and training processes. As a result, you can save significantly on recruitment and training costs. Additionally, ready-made teams are generally well-versed in working together, which can lead to increased efficiency and a shorter time to market.
 
 #### Opting for a ready-made team may mean sacrificing some degree of control.
 
-While you can still communicate your project requirements and provide guidance,
-you may have limited influence over the team's composition and processes.
+While you can still communicate your project requirements and provide guidance, you may have limited influence over the team's composition and processes.
 
 #### You are at risk for a long-term dependency.
 
-If you don’t have and don’t build up internal capability, you’ll be fully
-dependent on the agency.
+If you don’t have and don’t build up internal capability, you’ll be fully dependent on the agency.
 
 ## A Hybrid Approach: Team reinforcement
 
 ### Gradually build internal capacity while leveraging the expertise and efficiency of external professionals.
 
-Instead of first hiring and assembling the team and waiting until they are
-established enough to build a product, you can work with a partner that augments
-your team.
+Instead of first hiring and assembling the team and waiting until they are established enough to build a product, you can work with a partner that augments your team.
 
-You can start building while hiring and establishing your own team in parallel.
-By working closely with a partner, you can bridge the gap between your current
-internal capabilities and the requirements of your project. Furthermore, you
-build up internal capability and eventually will be able to continue without the
-partner.
+You can start building while hiring and establishing your own team in parallel. By working closely with a partner, you can bridge the gap between your current internal capabilities and the requirements of your project. Furthermore, you build up internal capability and eventually will be able to continue without the partner.
 
 #### You can also build on something you have no prior experience with yourself.
 
-Team reinforcement is a great way to get started with new technologies. Through
-methodologies like Pair-programming, mentoring, and strategic support, we at
-Mainmatter help you to make the right tech stack decision, train your team and
-build the product at the same time.
+Team reinforcement is a great way to get started with new technologies. Through methodologies like Pair-programming, mentoring, and strategic support, we at Mainmatter help you to make the right tech stack decision, train your team and build the product at the same time.
 
-At Mainmatter, we understand the challenges of assembling a tech team and the
-importance of building product- and tech know-how. We offer expertise and
-guidance to help you make the right decisions and support you throughout the
-process. [Contact us](https://mainmatter.com/startups/) to explore how we can
-assist you in taking the next steps toward building your ideal tech team.
+At Mainmatter, we understand the challenges of assembling a tech team and the importance of building product- and tech know-how. We offer expertise and guidance to help you make the right decisions and support you throughout the process. [Contact us](https://mainmatter.com/startups/) to explore how we can assist you in taking the next steps toward building your ideal tech team.
 
 We successfuly augmented the teams of
 
-{% set logoCompanies = ['Qonto', 'Trainline', 'Timify', 'Cardstack', 'Generali', 'Experteer'] %}
-{{ logoList(logoCompanies, animate=false) }}
+{% set logoCompanies = ['Qonto', 'Trainline', 'Timify', 'Cardstack', 'Generali', 'Experteer'] %} {{ logoList(logoCompanies, animate=false) }}
 
 {% set content = {
   "text": "Mainmatter enabled us to take our Product Development Organization to the  next level. They work closely with our team and help us establish new  practices while simultaneously delivering on our day to day product  initiatives. Their technical and organizational expertise and fresh views  allow us to set up the foundation for future success.",
diff --git a/src/posts/2023-09-06-krakens-migration-to-rust-microservices.md b/src/posts/2023-09-06-krakens-migration-to-rust-microservices.md
index d31b9739c4..f9f6cbcf5f 100644
--- a/src/posts/2023-09-06-krakens-migration-to-rust-microservices.md
+++ b/src/posts/2023-09-06-krakens-migration-to-rust-microservices.md
@@ -3,9 +3,7 @@ title: "Kraken’s migration to Rust microservices - with Rob Ede"
 authorHandle: marcoow
 tags: [rust]
 bio: "Marco Otte-Witte"
-description:
-  "Rob Ede and Marco Otte-Witte discuss Kraken's migration from Java to Rust
-  microservices and the evolution of actix."
+description: "Rob Ede and Marco Otte-Witte discuss Kraken's migration from Java to Rust microservices and the evolution of actix."
 og:
   image: /assets/images/posts/2023-09-06-krakens-migration-to-rust-microservices/og-image.jpg
 tagline: |
@@ -15,20 +13,10 @@ image: "/assets/images/posts/2023-09-06-krakens-migration-to-rust-microservices/
 imageAlt: "Rob's picture on a gray background"
 ---
 
-Rob Ede, Senior Rust Engineer at Kraken and lead maintainer of the actix
-project, and Mainmatter’s Founder Marco Otte-Witte discuss the history of the
-actix and actix-web projects, and how Rob became a maintainer.
+Rob Ede, Senior Rust Engineer at Kraken and lead maintainer of the actix project, and Mainmatter’s Founder Marco Otte-Witte discuss the history of the actix and actix-web projects, and how Rob became a maintainer.
 
-Marco and Rob talk about Kraken’s migration to Rust microservices and the
-significant performance improvements, massive drop in memory usage, and
-substantial reductions in AWS spending it brought along. They also emphasize the
-stability advancements that Rust provides, and Rob highlights that errors like
-null pointer exceptions that were frequent in Java are no longer possible in
-Rust.
+Marco and Rob talk about Kraken’s migration to Rust microservices and the significant performance improvements, massive drop in memory usage, and substantial reductions in AWS spending it brought along. They also emphasize the stability advancements that Rust provides, and Rob highlights that errors like null pointer exceptions that were frequent in Java are no longer possible in Rust.
 
-Finally, they discuss updates in Rust’s web development ecosystem and actix
-specifically, and Rob shares his view on how improvements in the language and
-framework space will eventually lead to a future where web development in Rust
-can be as approachable as development with e.g. express.js.
+Finally, they discuss updates in Rust’s web development ecosystem and actix specifically, and Rob shares his view on how improvements in the language and framework space will eventually lead to a future where web development in Rust can be as approachable as development with e.g. express.js.
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/4J7FChl7jfw?si=TJ0C_i22L6gHDUpz" title="Embedded video of Rob's interview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
diff --git a/src/posts/2023-09-15-value-of-unguided-work.md b/src/posts/2023-09-15-value-of-unguided-work.md
index 55b7e7a4af..052740bcd1 100644
--- a/src/posts/2023-09-15-value-of-unguided-work.md
+++ b/src/posts/2023-09-15-value-of-unguided-work.md
@@ -3,10 +3,7 @@ title: "The Value of Unguided Work"
 authorHandle: sarahlorenzu
 tags: [culture]
 bio: "Sarah Lorenz"
-description:
-  "Sarah Lorenz uncovers the value of unguided work for companies. She goes
-  through the steps to implement this practice, Mainmatter's experience with it,
-  and useful tips."
+description: "Sarah Lorenz uncovers the value of unguided work for companies. She goes through the steps to implement this practice, Mainmatter's experience with it, and useful tips."
 og:
   image: /assets/images/posts/2023-09-15-value-of-unguided-work/og-image.jpg
 tagline: |
@@ -18,81 +15,40 @@ imageAlt: "A rocket icon on a grey image background"
 
 ## Embracing Experimentation and Failure
 
-1. **Team Culture and Mindset**: Cultivating a culture that allows for
-   experimentation and failure is critical. Encourage open communication and
-   reassure team members that trying new ideas and learning from mistakes is not
-   only accepted but celebrated. Acknowledge and reward innovation efforts,
-   regardless of their outcome.
-2. **Solid Tools and Infrastructure**: To effectively foster unguided work,
-   organizations must provide their teams with the right tools and
-   infrastructure. Version control systems like Git, collaboration platforms
-   like Slack and Notion, and solid continuous integration and deployment
-   pipelines are essential to streamline development processes and enable rapid
-   experimentation.
-3. **Bug Prevention Mechanisms**: While it is essential to avoid bugs, it is
-   equally important to set up an environment that minimizes the impact of bugs.
-   Implement automated testing and robust monitoring systems to detect and
-   prevent potential problems early.
+1. **Team Culture and Mindset**: Cultivating a culture that allows for experimentation and failure is critical. Encourage open communication and reassure team members that trying new ideas and learning from mistakes is not only accepted but celebrated. Acknowledge and reward innovation efforts, regardless of their outcome.
+2. **Solid Tools and Infrastructure**: To effectively foster unguided work, organizations must provide their teams with the right tools and infrastructure. Version control systems like Git, collaboration platforms like Slack and Notion, and solid continuous integration and deployment pipelines are essential to streamline development processes and enable rapid experimentation.
+3. **Bug Prevention Mechanisms**: While it is essential to avoid bugs, it is equally important to set up an environment that minimizes the impact of bugs. Implement automated testing and robust monitoring systems to detect and prevent potential problems early.
 
 ## Mainmatter's Experience with Unguided Work
 
-At Mainmatter, we've seen the transformative power of unguided work in action.
-Here are a few key aspects of our experience:
+At Mainmatter, we've seen the transformative power of unguided work in action. Here are a few key aspects of our experience:
 
 ### Open Source Work: A Testament to Unguided Collaboration
 
-Open Source projects epitomize the value of unguided work. Hundreds of thousands
-of developers worldwide contribute to these projects, often in their spare time,
-without direct supervision. This collaborative and unguided approach has given
-rise to some of the most influential and widely used software in the world, such
-as Rust.
+Open Source projects epitomize the value of unguided work. Hundreds of thousands of developers worldwide contribute to these projects, often in their spare time, without direct supervision. This collaborative and unguided approach has given rise to some of the most influential and widely used software in the world, such as Rust.
 
 ### Embracing Flexibility: Working Whenever and Wherever
 
-The traditional 9-to-5 work model is no longer the only viable option. Embracing
-unguided work means acknowledging that people can be at their best at different
-times and locations. Offering flexibility in working hours and remote work
-options empowers individuals to find their optimal productivity zones and leads
-to better work-life balance.
+The traditional 9-to-5 work model is no longer the only viable option. Embracing unguided work means acknowledging that people can be at their best at different times and locations. Offering flexibility in working hours and remote work options empowers individuals to find their optimal productivity zones and leads to better work-life balance.
 
 ### Async Work and Distributed Teams
 
-Moving away from traditional meeting-heavy approaches, asynchronous
-communication has become a hallmark of unguided work. Distributed teams can
-collaborate effectively through platforms like Notion and GitHub, reducing the
-need for constant synchronous meetings.
+Moving away from traditional meeting-heavy approaches, asynchronous communication has become a hallmark of unguided work. Distributed teams can collaborate effectively through platforms like Notion and GitHub, reducing the need for constant synchronous meetings.
 
-Shopify introduced its Meeting Cost Calculator in July 2023, helping estimate
-the cost of meetings. By getting rid of three meetings a week per person, the
-company expects a 15% cost reduction. (Read
-[more](https://edition.cnn.com/2023/07/12/tech/shopify-meeting-cost-calculator/index.html))
+Shopify introduced its Meeting Cost Calculator in July 2023, helping estimate the cost of meetings. By getting rid of three meetings a week per person, the company expects a 15% cost reduction. (Read [more](https://edition.cnn.com/2023/07/12/tech/shopify-meeting-cost-calculator/index.html))
 
-![Shopify's meeting cost calculator](/assets/images/posts/2023-09-15-value-of-unguided-work/shopify-meeting-cost-calculator.jpg)
-_Source: Spotify_
+![Shopify's meeting cost calculator](/assets/images/posts/2023-09-15-value-of-unguided-work/shopify-meeting-cost-calculator.jpg) _Source: Spotify_
 
 ### Time for Experimentation and Learning
 
-Following the concept promoted by Google, our team members spend 20% of their
-work time on open source projects and experimenting with new ideas. This
-"creative time" has yielded remarkable results, as several innovations have
-found their way into new projects.
+Following the concept promoted by Google, our team members spend 20% of their work time on open source projects and experimenting with new ideas. This "creative time" has yielded remarkable results, as several innovations have found their way into new projects.
 
 ## Rethinking Project Management
 
-In the context of unguided work, the role of project management evolves. Instead
-of rigidly being on top of progress and timelines, letting go of those
-constraints is at the core of unguided work. Teams experiment, learn, and adapt
-constantly, with project management’s main role being to make sure things are on
-track in the right general direction.
+In the context of unguided work, the role of project management evolves. Instead of rigidly being on top of progress and timelines, letting go of those constraints is at the core of unguided work. Teams experiment, learn, and adapt constantly, with project management’s main role being to make sure things are on track in the right general direction.
 
-Solid developer tooling, infrastructure, and practices enable teams to
-experiment and fail without causing havoc. We’ve worked with many international
-teams over the years and helped them set up and improve automatic testing and
-deployment, incremental rollout strategies, quality assurance, and other
-mechanisms that can raise a team’s ability to experiment.
+Solid developer tooling, infrastructure, and practices enable teams to experiment and fail without causing havoc. We’ve worked with many international teams over the years and helped them set up and improve automatic testing and deployment, incremental rollout strategies, quality assurance, and other mechanisms that can raise a team’s ability to experiment.
 
-[Reach out](https://mainmatter.com/contact/) to talk about how we can help your
-team.
+[Reach out](https://mainmatter.com/contact/) to talk about how we can help your team.
 
-Find [further information](https://mainmatter.com/startups/) on how we can help
-you to burst through the bottleneck.
+Find [further information](https://mainmatter.com/startups/) on how we can help you to burst through the bottleneck.
diff --git a/src/posts/2023-09-18-integrate-storybook-in-svelte-doing-it-the-svelte-way.md b/src/posts/2023-09-18-integrate-storybook-in-svelte-doing-it-the-svelte-way.md
index aa9e919a69..00305cd230 100644
--- a/src/posts/2023-09-18-integrate-storybook-in-svelte-doing-it-the-svelte-way.md
+++ b/src/posts/2023-09-18-integrate-storybook-in-svelte-doing-it-the-svelte-way.md
@@ -3,34 +3,17 @@ title: "Integrate Storybook in Svelte: Doing it the Svelte-way"
 authorHandle: oscard0m_
 tags: [svelte, storybook]
 bio: "Óscar Domínguez Celada"
-description:
-  "Óscar Domínguez Celada explores the transformation of integrating Storybook
-  with Svelte projects, focusing on the addon-svelte-csf for a more native
-  Svelte experience."
+description: "Óscar Domínguez Celada explores the transformation of integrating Storybook with Svelte projects, focusing on the addon-svelte-csf for a more native Svelte experience."
 og:
   image: /assets/images/posts/2023-09-18-integrate-storybook-in-svelte-doing-it-the-svelte-way/og-image.jpg
-tagline:
-  'Using <a href="https://storybook.js.org/">Storybook</a> in your <a
-  href="https://svelte.dev/">Svelte</a> project? Annoyed by the fact of not
-  being able to write your stories using Svelte syntax out of the box? I have
-  good news for you: it''s possible and it''s easy!'
+tagline: 'Using <a href="https://storybook.js.org/">Storybook</a> in your <a href="https://svelte.dev/">Svelte</a> project? Annoyed by the fact of not being able to write your stories using Svelte syntax out of the box? I have good news for you: it''s possible and it''s easy!'
 image: "/assets/images/posts/2023-09-18-integrate-storybook-in-svelte-doing-it-the-svelte-way/header-illustration.jpg"
 imageAlt: "The Svelte logo on a gray background picture"
 ---
 
-In the web development space, [Storybook](https://storybookjs.org) is one of the
-main choices for developing UI components and pages in isolation, especially
-within a Design System framework. Out of the box, Storybook expects you to write
-stories in a JS file. The API is a composition of JS Objects and properties.
-While this is very versatile and does not fit the syntax used in
-[Svelte](https://www.filmaffinity.com/es/film562915.html) so the experience of
-integrating Svelte Components with Storybook feels a bit unnatural.
+In the web development space, [Storybook](https://storybookjs.org) is one of the main choices for developing UI components and pages in isolation, especially within a Design System framework. Out of the box, Storybook expects you to write stories in a JS file. The API is a composition of JS Objects and properties. While this is very versatile and does not fit the syntax used in [Svelte](https://www.filmaffinity.com/es/film562915.html) so the experience of integrating Svelte Components with Storybook feels a bit unnatural.
 
-Fortunately, there's an addon in Storybook's ecosystem to solve this:
-[addon-svelte-csf](https://github.com/storybookjs/addon-svelte-csf). This addon
-pivots us from the conventional to a more Svelte-centric way of integrating with
-Storybook. In this guide, I'll walk you through how this transition can happen
-in your Svelte/SvelteKit projects.
+Fortunately, there's an addon in Storybook's ecosystem to solve this: [addon-svelte-csf](https://github.com/storybookjs/addon-svelte-csf). This addon pivots us from the conventional to a more Svelte-centric way of integrating with Storybook. In this guide, I'll walk you through how this transition can happen in your Svelte/SvelteKit projects.
 
 ---
 
@@ -38,8 +21,7 @@ in your Svelte/SvelteKit projects.
 
 - Familiarity with [Svelte](https://svelte.dev).
 - An existing Svelte/SvelteKit project.
-- Installed versions of [Node](https://nodejs.org) and
-  [npm](https://www.npmjs.com/)/[pnpm](https://pnpm.io/)/[yarn](https://yarnpkg.com/).
+- Installed versions of [Node](https://nodejs.org) and [npm](https://www.npmjs.com/)/[pnpm](https://pnpm.io/)/[yarn](https://yarnpkg.com/).
 
 ---
 
@@ -57,10 +39,7 @@ pnpm dlx storybook@latest init
 yarn dlx storybook@latest init
 ```
 
-This command will set up the initial configuration and dependencies. It should
-automatically detect Svelte and install the necessary addons. If you find any
-issues, check
-[the Storybook docs for troubleshooting](https://storybook.js.org/docs/svelte/get-started/install).
+This command will set up the initial configuration and dependencies. It should automatically detect Svelte and install the necessary addons. If you find any issues, check [the Storybook docs for troubleshooting](https://storybook.js.org/docs/svelte/get-started/install).
 
 ### Integrating the `addon-svelte-csf`
 
@@ -74,8 +53,7 @@ pnpm install --save-dev @storybook/addon-svelte-csf
 yarn add --dev @storybook/addon-svelte-csf
 ```
 
-Integrate the addon into your project by updating the `.storybook/main.js`
-configuration:
+Integrate the addon into your project by updating the `.storybook/main.js` configuration:
 
 ```diff-js
 module.exports = {
@@ -86,8 +64,7 @@ module.exports = {
 
 ### Developing the First Story
 
-Let’s use a foundational `Button.svelte` component in `src/components/` as an
-example:
+Let’s use a foundational `Button.svelte` component in `src/components/` as an example:
 
 ```html
 <script>
@@ -98,8 +75,7 @@ example:
 <button type="{type}">{label}</button>
 ```
 
-Before using `addon-svelte-csf`, the corresponding Story would have looked
-something like this:
+Before using `addon-svelte-csf`, the corresponding Story would have looked something like this:
 
 ```js
 // Button.stories.js
@@ -140,8 +116,7 @@ export const withLongText = {
 };
 ```
 
-But when using `addon-svelte-csf`, the corresponding Story looks something like
-this:
+But when using `addon-svelte-csf`, the corresponding Story looks something like this:
 
 ```jsx
 <script>
@@ -167,9 +142,7 @@ this:
 />
 ```
 
-Isn't it nice to write our component stories directly in Svelte? With
-`addon-svelte-csf`, we can leverage the full power of Svelte syntax and avoid
-the need to define stories as JavaScript objects.
+Isn't it nice to write our component stories directly in Svelte? With `addon-svelte-csf`, we can leverage the full power of Svelte syntax and avoid the need to define stories as JavaScript objects.
 
 ### Launching Storybook
 
@@ -185,23 +158,13 @@ yarn storybook
 
 - Navigate to the provided URL to inspect the Button component in action.
 
-Congratulations! You built your first Story using Svelte syntax! As you continue
-building more components, you might want to explore:
+Congratulations! You built your first Story using Svelte syntax! As you continue building more components, you might want to explore:
 
 - Multiple stories for diverse components.
 - Leveraging `args` for dynamic prop management.
 - Organizing components methodically.
 - The usage of Storybook's `context` and `decorators`
 
-I also invite you to take a look into
-[addon-svelte-csf's source code](https://github.com/storybookjs/addon-svelte-csf)
-and the story examples in its repository as inspiration.
-
-Lastly, a massive thank you to Jon McClure
-([@hobbes7878](https://github.com/hobbes7878)), Jeppe Reinhold
-([@JReinhold](https://github.com/JReinhold)), Jérémie
-([@j3rem1e](https://github.com/j3rem1e)), Ian VanSchooten
-([IanVS](https://github.com/IanVS)), Michael Shilman
-([shilman](https://github.com/shilman)), and the entire Storybook team. Their
-tireless work ensures we benefit from a seamless developer experience. Here's to
-the collaborative spirit of the open-source community!
+I also invite you to take a look into [addon-svelte-csf's source code](https://github.com/storybookjs/addon-svelte-csf) and the story examples in its repository as inspiration.
+
+Lastly, a massive thank you to Jon McClure ([@hobbes7878](https://github.com/hobbes7878)), Jeppe Reinhold ([@JReinhold](https://github.com/JReinhold)), Jérémie ([@j3rem1e](https://github.com/j3rem1e)), Ian VanSchooten ([IanVS](https://github.com/IanVS)), Michael Shilman ([shilman](https://github.com/shilman)), and the entire Storybook team. Their tireless work ensures we benefit from a seamless developer experience. Here's to the collaborative spirit of the open-source community!
diff --git a/src/posts/2023-09-28-exploring-rusts-impact-on-costs-and-efficiency.md b/src/posts/2023-09-28-exploring-rusts-impact-on-costs-and-efficiency.md
index 8211960a35..ad188e2a81 100644
--- a/src/posts/2023-09-28-exploring-rusts-impact-on-costs-and-efficiency.md
+++ b/src/posts/2023-09-28-exploring-rusts-impact-on-costs-and-efficiency.md
@@ -1,14 +1,9 @@
 ---
-title:
-  "Exploring Rust's impact on efficiency and cost-savings - with Stefan
-  Baumgartner"
+title: "Exploring Rust's impact on efficiency and cost-savings - with Stefan Baumgartner"
 authorHandle: marcoow
 tags: [rust]
 bio: "Marco Otte-Witte"
-description:
-  "Stefan Baumgartner and Marco Otte-Witte discuss the impact of Rust on
-  efficiency and operating costs and Stefan's experience learning and teaching
-  Rust."
+description: "Stefan Baumgartner and Marco Otte-Witte discuss the impact of Rust on efficiency and operating costs and Stefan's experience learning and teaching Rust."
 og:
   image: /assets/images/posts/2023-09-28-exploring-rusts-impact-on-costs-and-efficiency/og-image.png
 tagline: |
@@ -18,35 +13,12 @@ image: "/assets/images/posts/2023-09-28-exploring-rusts-impact-on-costs-and-effi
 imageAlt: "Stefan's picture on a gray background"
 ---
 
-According to Marco Otte-Witte, Founder of Mainmatter, and Stefan Baumgartner,
-Senior Product Architect at Dynatrace, Rust allows developers to write more
-stable software with fewer maintenance issues and higher efficiency, resulting
-in cost savings for companies. In the interview, Stefan shared his experience
-introducing Rust to Dynatrace’s platform, and how they delivered a functioning
-prototype within a few days for a particular use case. Ever since, his team at
-Dynatrace has been able to maintain and run the Rust-based product smoothly with
-minimal issues, proving that Rust is a stable and efficient language for such
-projects.
+According to Marco Otte-Witte, Founder of Mainmatter, and Stefan Baumgartner, Senior Product Architect at Dynatrace, Rust allows developers to write more stable software with fewer maintenance issues and higher efficiency, resulting in cost savings for companies. In the interview, Stefan shared his experience introducing Rust to Dynatrace’s platform, and how they delivered a functioning prototype within a few days for a particular use case. Ever since, his team at Dynatrace has been able to maintain and run the Rust-based product smoothly with minimal issues, proving that Rust is a stable and efficient language for such projects.
 
-The conversation then moves to Stefan's personal experience with programming
-languages and his journey to learning and teaching Rust. He discussed his
-background with languages like C, C++, and C# and his first transition to web
-development with JavaScript.
+The conversation then moves to Stefan's personal experience with programming languages and his journey to learning and teaching Rust. He discussed his background with languages like C, C++, and C# and his first transition to web development with JavaScript.
 
-Stefan highlights the importance of understanding memory management and
-low-level concepts when programming, which Rust enforces and guides programmers
-through. He debated how teaching Rust to others, especially those familiar with
-dynamic or scripted languages, brings a fresh perspective and empowers
-developers to write efficient and reliable software. Learning Rust may be more
-challenging for those already accustomed to certain concepts like automatic
-garbage collection, as they need to adapt to a new way of dealing with
-obstacles. Therefore – Stefan explained - it is important to provide learners
-with concrete problems to solve when teaching Rust and encourage them to work
-towards a goal.
+Stefan highlights the importance of understanding memory management and low-level concepts when programming, which Rust enforces and guides programmers through. He debated how teaching Rust to others, especially those familiar with dynamic or scripted languages, brings a fresh perspective and empowers developers to write efficient and reliable software. Learning Rust may be more challenging for those already accustomed to certain concepts like automatic garbage collection, as they need to adapt to a new way of dealing with obstacles. Therefore – Stefan explained - it is important to provide learners with concrete problems to solve when teaching Rust and encourage them to work towards a goal.
 
-Lastly, Stefan discusses different timelines from his own experience and
-suggested that having mentors and guidance throughout the learning process is
-essential for success in Rust due to its explicit decision-making requirements
-and complex concepts.
+Lastly, Stefan discusses different timelines from his own experience and suggested that having mentors and guidance throughout the learning process is essential for success in Rust due to its explicit decision-making requirements and complex concepts.
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/KTJIsicwW5s?si=fk_MRap9FIzbP44U" title="Embedded video of Stefan's interview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
diff --git a/src/posts/2023-11-02-unlocking-rusts-power-through-mentorship-and-knowledge-spreading.md b/src/posts/2023-11-02-unlocking-rusts-power-through-mentorship-and-knowledge-spreading.md
index 21ae553271..a39f30e8bf 100644
--- a/src/posts/2023-11-02-unlocking-rusts-power-through-mentorship-and-knowledge-spreading.md
+++ b/src/posts/2023-11-02-unlocking-rusts-power-through-mentorship-and-knowledge-spreading.md
@@ -3,10 +3,7 @@ title: "Unlocking Rust’s Power through Mentorship and Knowledge Spreading"
 authorHandle: marcoow
 tags: [rust]
 bio: "Marco Otte-Witte"
-description:
-  "Tim McNamara and Marco Otte-Witte talk about the importance of knowledge
-  spreading for successful Rust adoption and the impact of Rust on energy
-  savings and efficiency."
+description: "Tim McNamara and Marco Otte-Witte talk about the importance of knowledge spreading for successful Rust adoption and the impact of Rust on energy savings and efficiency."
 og:
   image: /assets/images/posts/2023-11-02-unlocking-rusts-power-through-mentorship-and-knowledge-spreading/og-image.jpg
 tagline: |
@@ -16,38 +13,12 @@ image: "/assets/images/posts/2023-11-02-unlocking-rusts-power-through-mentorship
 imageAlt: "Tim's picture on a gray background"
 ---
 
-Tim McNamara, a Rust expert with a background in teaching the language at AWS
-and author of
-"[Rust in Action](https://www.amazon.de/Rust-Action-Tim-Mcnamara/dp/1617294551)”
-and Marco Otte-Witte, Founder of Mainmatter recently talked about adopting Rust.
-Tim starts by sharing why in his experience Rust is not as hard to learn as many
-people think it is. The language supports engineers to develop a better
-understanding of how programs work in general and ultimately become better
-engineers overall. Google just recently shared that they do not see any negative
-impact on productivity with Rust compared to other languages. Rust enables
-engineers to move faster writing code as they know they can't make common
-mistakes as the compiler would catch those.
+Tim McNamara, a Rust expert with a background in teaching the language at AWS and author of "[Rust in Action](https://www.amazon.de/Rust-Action-Tim-Mcnamara/dp/1617294551)” and Marco Otte-Witte, Founder of Mainmatter recently talked about adopting Rust. Tim starts by sharing why in his experience Rust is not as hard to learn as many people think it is. The language supports engineers to develop a better understanding of how programs work in general and ultimately become better engineers overall. Google just recently shared that they do not see any negative impact on productivity with Rust compared to other languages. Rust enables engineers to move faster writing code as they know they can't make common mistakes as the compiler would catch those.
 
-Tim goes on to talk about the recent growth that Rust has seen among larger
-companies and encourages smaller organizations to adopt it as well. He
-underscores Rust's advantages over dynamic languages, which were more popular in
-the past, particularly its robust type system, strictness, and benefits for
-long-term maintainability. Tim and Marco talk about how the industry is turning
-back to where it was before in a way with a shift in focus back to types,
-stability, and strictness after a period of time that focused on dynamic,
-untyped languages and short time from idea to working prototype. That is mainly
-driven by the need for long-term maintainability which is becoming critical now
-for apps that were written 10-15y ago in dynamic languages. Those have now
-reached an age where the maintainability problems with dynamic languages like
-Ruby become obvious and painful.
+Tim goes on to talk about the recent growth that Rust has seen among larger companies and encourages smaller organizations to adopt it as well. He underscores Rust's advantages over dynamic languages, which were more popular in the past, particularly its robust type system, strictness, and benefits for long-term maintainability. Tim and Marco talk about how the industry is turning back to where it was before in a way with a shift in focus back to types, stability, and strictness after a period of time that focused on dynamic, untyped languages and short time from idea to working prototype. That is mainly driven by the need for long-term maintainability which is becoming critical now for apps that were written 10-15y ago in dynamic languages. Those have now reached an age where the maintainability problems with dynamic languages like Ruby become obvious and painful.
 
-Tim and Marco also talk about the fact that many engineers remain unaware of how
-inefficient most software is in terms of energy consumption. Rust can reduce
-energy usage by up to 95%, significantly impacting global resource conservation.
+Tim and Marco also talk about the fact that many engineers remain unaware of how inefficient most software is in terms of energy consumption. Rust can reduce energy usage by up to 95%, significantly impacting global resource conservation.
 
-Finally, they emphasize the need for senior engineers who are proficient in Rust
-to mentor juniors within companies in order to make Rust adoption a success.
-Spreading Rust knowledge is critical to avoid dependencies on isolated groups of
-developers, ensuring successful integration across the organization.
+Finally, they emphasize the need for senior engineers who are proficient in Rust to mentor juniors within companies in order to make Rust adoption a success. Spreading Rust knowledge is critical to avoid dependencies on isolated groups of developers, ensuring successful integration across the organization.
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/nPFXIBbjJuM?si=eQDXD1KvBpMF-dY9" title="Embedded video of Tim's interview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
diff --git a/src/posts/2023-11-03-the-case-against-project-managers.md b/src/posts/2023-11-03-the-case-against-project-managers.md
index f707f29dac..c176af6259 100644
--- a/src/posts/2023-11-03-the-case-against-project-managers.md
+++ b/src/posts/2023-11-03-the-case-against-project-managers.md
@@ -3,9 +3,7 @@ title: "The Case against Project Managers"
 authorHandle: sarahlorenzu
 tags: [startups]
 bio: "Sarah Lorenz"
-description:
-  "Sarah Lorenz explains the reasons not to have a classic project manager role
-  and introduces Mainmatter's approach to self-managed teams."
+description: "Sarah Lorenz explains the reasons not to have a classic project manager role and introduces Mainmatter's approach to self-managed teams."
 og:
   image: /assets/images/posts/2023-11-03-the-case-against-project-managers/og-image.jpeg
 tagline: |
@@ -17,76 +15,30 @@ imageAlt: "A rocket icon on a grey image background"
 
 ## The Communication Conundrum
 
-One of the main problem with dedicated project manager roles is they can hinder
-direct communication between project stakeholders (typically product, design,
-engineering). In some cases, project managers would even deliberately block
-direct interaction in an attempt to "protect" team members from external
-influences in order to allow them to focus better (as in, “developers should
-stay in the flow and write code – talking to a product manager will only
-interrupt them”). That lack of direct communication necessarily leads to
-important details getting lost in translation.
+One of the main problem with dedicated project manager roles is they can hinder direct communication between project stakeholders (typically product, design, engineering). In some cases, project managers would even deliberately block direct interaction in an attempt to "protect" team members from external influences in order to allow them to focus better (as in, “developers should stay in the flow and write code – talking to a product manager will only interrupt them”). That lack of direct communication necessarily leads to important details getting lost in translation.
 
 ## The Disproportionate Influence of Stakeholders
 
-No direct communication happening between the stakeholders also makes it hard if
-not impossible to understand and appreciate each other’s perspectives. Without
-that though, teams won’t be aligned on a common goal typically and won’t be able
-to move towards a goal collectively. In project teams, just like in real life,
-everyone gets a little and needs to give a little. If people don’t appreciate
-each other’s points of view though, they typically are less willing to make
-sacrifices as they can’t see the need for things other stakeholders are asking
-for. That almost always ends up with project teams where all stakeholder groups
-work against each other, each one trying to get as much as possible while giving
-as little as they can.
-
-In many such cases, one stakeholder group ends up being the most powerful, and
-getting the most for themselves – that stakeholder ends up dominating the
-project direction and disregards the motivations and goals of the other
-stakeholders. As a result, project outcomes may only meet the needs of some
-stakeholders but not those of the others, ultimately leading to project failure.
-
-The strongest stakeholder group is often product management. They have an
-interest in shipping features obviously and that group dominating the product
-leads to the needs of designers and engineers receiving less attention. In many
-cases that can lead to projects that build up significant technical debt as the
-engineers aren’t heard with their needs for too long – eventually that will slow
-down productivity and in the worst case stall all progress. If all stakeholders
-receive equal attention from the beginning, these situations can typically be
-avoided.
+No direct communication happening between the stakeholders also makes it hard if not impossible to understand and appreciate each other’s perspectives. Without that though, teams won’t be aligned on a common goal typically and won’t be able to move towards a goal collectively. In project teams, just like in real life, everyone gets a little and needs to give a little. If people don’t appreciate each other’s points of view though, they typically are less willing to make sacrifices as they can’t see the need for things other stakeholders are asking for. That almost always ends up with project teams where all stakeholder groups work against each other, each one trying to get as much as possible while giving as little as they can.
+
+In many such cases, one stakeholder group ends up being the most powerful, and getting the most for themselves – that stakeholder ends up dominating the project direction and disregards the motivations and goals of the other stakeholders. As a result, project outcomes may only meet the needs of some stakeholders but not those of the others, ultimately leading to project failure.
+
+The strongest stakeholder group is often product management. They have an interest in shipping features obviously and that group dominating the product leads to the needs of designers and engineers receiving less attention. In many cases that can lead to projects that build up significant technical debt as the engineers aren’t heard with their needs for too long – eventually that will slow down productivity and in the worst case stall all progress. If all stakeholders receive equal attention from the beginning, these situations can typically be avoided.
 
 ## Rethinking the Role of the Project Manager
 
-Rather than abolishing project management in general, we advocate a revised
-approach. We see project management as a facilitating role that acts as a
-moderator or communications coach, thus focuses on facilitating collaboration
-and fostering a productive team environment. This may include moderating
-meetings, introducing workshop techniques, and promoting effective communication
-– all that to enable smoother and more efficient **direct communication between
-the project stakeholders**.
+Rather than abolishing project management in general, we advocate a revised approach. We see project management as a facilitating role that acts as a moderator or communications coach, thus focuses on facilitating collaboration and fostering a productive team environment. This may include moderating meetings, introducing workshop techniques, and promoting effective communication – all that to enable smoother and more efficient **direct communication between the project stakeholders**.
 
 ## Redefining Iteration Leadership
 
-We further promote the concept of an "iteration lead" role. For each development
-iteration (or “sprint” if you will), one team member assumes this role and is
-responsible for sourcing and planning the work for the iteration, as well as
-ensuring smooth execution. The iteration lead's duties rotate among all team
-members unless they choose to opt out. All team members from all stakeholder
-groups assuming the iteration lead role regularly ensures that no single
-stakeholder group will end up outweighing the others and ensures everyone
-communicates with all of the other stakeholders regularly.
+We further promote the concept of an "iteration lead" role. For each development iteration (or “sprint” if you will), one team member assumes this role and is responsible for sourcing and planning the work for the iteration, as well as ensuring smooth execution. The iteration lead's duties rotate among all team members unless they choose to opt out. All team members from all stakeholder groups assuming the iteration lead role regularly ensures that no single stakeholder group will end up outweighing the others and ensures everyone communicates with all of the other stakeholders regularly.
 
 ## Improved Productivity and Morale
 
-We have seen this evolution of project leadership leading to improved
-productivity in many different projects. At the same time, it leads to improved
-morale and a less confrontational work environment and overall atmosphere in
-project teams.
+We have seen this evolution of project leadership leading to improved productivity in many different projects. At the same time, it leads to improved morale and a less confrontational work environment and overall atmosphere in project teams.
 
-If you’re interested in establishing the “iteration lead” approach in your own
-team, check out our [Playbook](/playbook/) or reach out and we’ll be happy to
-talk.
+If you’re interested in establishing the “iteration lead” approach in your own team, check out our [Playbook](/playbook/) or reach out and we’ll be happy to talk.
 
 [Reach out](/contact/) to talk about how we can help your team.
 
-Find [further information](/startups/) on how we can help you to burst through
-the bottleneck.
+Find [further information](/startups/) on how we can help you to burst through the bottleneck.
diff --git a/src/posts/2023-11-16-embroider-initiative-progress-update.md b/src/posts/2023-11-16-embroider-initiative-progress-update.md
index 74961c1683..e97cf0f3c2 100644
--- a/src/posts/2023-11-16-embroider-initiative-progress-update.md
+++ b/src/posts/2023-11-16-embroider-initiative-progress-update.md
@@ -3,419 +3,134 @@ title: "Embroider Initiative: Progress Update"
 authorHandle: real_ate
 tags: [ember]
 bio: "Chris Manson"
-description:
-  "Chris Manson gives an update on the work the Mainmatter team has done on the
-  Embroider initiative so far, the achievements that have been made and what the
-  next steps ahead are."
+description: "Chris Manson gives an update on the work the Mainmatter team has done on the Embroider initiative so far, the achievements that have been made and what the next steps ahead are."
 og:
   image: /assets/images/posts/2023-11-16-embroider-initiative-progress-update/og-image.jpeg
 tagline: |
   <p>This post covers the progress over the last few months on <a href="https://github.com/embroider-build/embroider">the Embroider project</a> that has been made through Mainmatter's <a href="/ember-initiative/">Embroider Initiative</a>. While this isn't a comprehensive update, it should give you a taste of the significant progress we've made and understand some of the challenges that are still remaining.</p>
 image: /assets/images/posts/2023-11-16-embroider-initiative-progress-update/header-visual.jpeg
-imageAlt:
-  "The ember logo on a background showing people working together on a laptop"
+imageAlt: "The ember logo on a background showing people working together on a laptop"
 ---
 
-For anyone who has clicked the link to this blog post but doesn't already know,
-Embroider is a new build pipeline that compiles Ember apps into spec-compliant,
-modern JavaScript. Before Embroider, it was somewhat difficult to participate in
-modern build-tooling optimisations such as code-splitting and tree-shaking.
-Embroider allows you to opt-into these behaviours out of the box.
-
-Embroider is of critical importance for the entire Ember ecosystem, yet has been
-in development for many years with no clear end in sight. The Embroider
-Initiative is spearheaded by Mainmatter with the support of a group of sponsors
-to help speed up development on Embroider so that we can make it the default
-build system for newly generated Ember apps as soon as possible. This will allow
-Ember developers to continue leveraging its advantages while benefiting from a
-modern build system. We hope to see Ember apps being built with Vite before the
-end of the year.
+For anyone who has clicked the link to this blog post but doesn't already know, Embroider is a new build pipeline that compiles Ember apps into spec-compliant, modern JavaScript. Before Embroider, it was somewhat difficult to participate in modern build-tooling optimisations such as code-splitting and tree-shaking. Embroider allows you to opt-into these behaviours out of the box.
+
+Embroider is of critical importance for the entire Ember ecosystem, yet has been in development for many years with no clear end in sight. The Embroider Initiative is spearheaded by Mainmatter with the support of a group of sponsors to help speed up development on Embroider so that we can make it the default build system for newly generated Ember apps as soon as possible. This will allow Ember developers to continue leveraging its advantages while benefiting from a modern build system. We hope to see Ember apps being built with Vite before the end of the year.
 
 The Embroider Initiative aims to:
 
-1. **Finish Embroider** itself by assigning experienced Ember engineers
-   full-time to the project. This covers development work on Embroider and its
-   dependencies, as well as helping backers setting it up in their repos to
-   uncover and fix edge cases.
-2. **Make Embroider maintainable** by decentralizing technical knowledge beyond
-   the project's core developer [Ed Faulkner](https://github.com/ef4) and thus
-   [improving the bus factor](https://en.wikipedia.org/wiki/Bus_factor).
-   Mainmatter makes use of the apprenticeship model to onboard and train new
-   developers on the intricate parts of the project.
-3. **Shift the ecosystem and make Embroider mainstream** by making it easier to
-   generate Embroider-optimized Ember apps and supporting addon developers make
-   their addons compatible with Embroider.
-
-**To reach these goals and keep up the momentum, the project needs your
-financial support. Please [get in touch](/contact) to learn how to directly
-benefit from this investment.**
-
-Mainmatter founder and director Marco Otte-Witte recently
-[talked about the Embroider Initiative and open source funding in general at EmberFest in Madrid](https://www.youtube.com/watch?v=QMUm6UOoNRs).
-He detailed how important the Initiative is to the future of Ember itself and to
-all companies that have built on Ember and need to secure the investments they
-have made in Ember. He also went into detail about the Embroider Initiative in
-his
-[original blog post that announced the initiative](https://mainmatter.com/blog/2023/06/09/securing-the-ecosystems-investment-in-emberjs/).
-This blog post will dive into the things our team has been able to achieve up
-until now.
+1. **Finish Embroider** itself by assigning experienced Ember engineers full-time to the project. This covers development work on Embroider and its dependencies, as well as helping backers setting it up in their repos to uncover and fix edge cases.
+2. **Make Embroider maintainable** by decentralizing technical knowledge beyond the project's core developer [Ed Faulkner](https://github.com/ef4) and thus [improving the bus factor](https://en.wikipedia.org/wiki/Bus_factor). Mainmatter makes use of the apprenticeship model to onboard and train new developers on the intricate parts of the project.
+3. **Shift the ecosystem and make Embroider mainstream** by making it easier to generate Embroider-optimized Ember apps and supporting addon developers make their addons compatible with Embroider.
+
+**To reach these goals and keep up the momentum, the project needs your financial support. Please [get in touch](/contact) to learn how to directly benefit from this investment.**
+
+Mainmatter founder and director Marco Otte-Witte recently [talked about the Embroider Initiative and open source funding in general at EmberFest in Madrid](https://www.youtube.com/watch?v=QMUm6UOoNRs). He detailed how important the Initiative is to the future of Ember itself and to all companies that have built on Ember and need to secure the investments they have made in Ember. He also went into detail about the Embroider Initiative in his [original blog post that announced the initiative](https://mainmatter.com/blog/2023/06/09/securing-the-ecosystems-investment-in-emberjs/). This blog post will dive into the things our team has been able to achieve up until now.
 
 ## Getting Ember to work with Vite
 
-At EmberConf this year [Ed Faulkner](https://github.com/ef4)
-[announced that we were closing in on a Vite plugin for Embroider](https://www.youtube.com/watch?v=8rnmGGY5rhk&t=1723s).
-While that was true at the time, we have learned a lot about the Vite build
-process since then and we know more about the steps that are still required to
-get the Vite integration working.
-
-The Vite app that Ed demoed at EmberConf was a trivial app that is
-[a package in the Embroider monorepo](https://github.com/embroider-build/embroider/tree/main/tests/vite-app)
-and if you wanted to test it yourself then you could either clone the Embroider
-monorepo, or you could clone
-[this repo](https://github.com/mansona/ember-vite-app) which is essentially just
-extracting the same test app into an independent repo. It works, and you can
-even see the incredible rebuild speeds in action.
-
-The issue with this trivial demo is that it doesn't represent an average Ember
-application. There aren't any Ember applications out there that don't have a
-single addon installed. While it's not exactly true that the demo doesn't have
-**any** addons installed, it doesn't have any addons that are doing any real
-work. And, as it turns out, getting dependencies to work right is the challenge
-with the Vite build.
-
-Ed and Mainmatter Senior Engineer Chris Manson have been pairing weekly,
-plugging away at the remaining things that are required to fix the Vite build.
-We are now optimistic we can get to a point where it's possible to build the
-first real-world Ember applications with Vite until the end of the year.
+At EmberConf this year [Ed Faulkner](https://github.com/ef4) [announced that we were closing in on a Vite plugin for Embroider](https://www.youtube.com/watch?v=8rnmGGY5rhk&t=1723s). While that was true at the time, we have learned a lot about the Vite build process since then and we know more about the steps that are still required to get the Vite integration working.
+
+The Vite app that Ed demoed at EmberConf was a trivial app that is [a package in the Embroider monorepo](https://github.com/embroider-build/embroider/tree/main/tests/vite-app) and if you wanted to test it yourself then you could either clone the Embroider monorepo, or you could clone [this repo](https://github.com/mansona/ember-vite-app) which is essentially just extracting the same test app into an independent repo. It works, and you can even see the incredible rebuild speeds in action.
+
+The issue with this trivial demo is that it doesn't represent an average Ember application. There aren't any Ember applications out there that don't have a single addon installed. While it's not exactly true that the demo doesn't have **any** addons installed, it doesn't have any addons that are doing any real work. And, as it turns out, getting dependencies to work right is the challenge with the Vite build.
+
+Ed and Mainmatter Senior Engineer Chris Manson have been pairing weekly, plugging away at the remaining things that are required to fix the Vite build. We are now optimistic we can get to a point where it's possible to build the first real-world Ember applications with Vite until the end of the year.
 
 ## ember-auto-import `allowAppImports`
 
-While the main focus of the Embroider Initiative was always going to be the
-Embroider code base, there are other parts of the ecosystem that will require
-some work to bring them more in line with how we want people to build their
-apps.
-
-If you're already using Embroider, you will know that a lot of the work to
-package your app is done by Webpack. If you're still on a classic build, you may
-not be aware that ember-auto-import uses Webpack under the hood to allow you to
-seamlessly import from `node_modules`. This has been a very useful feature but
-since the acceptance of the
-[v2 addon spec RFC](https://rfcs.emberjs.com/id/0507-embroider-v2-package-format)
-we have noticed that we have a bit of a blindspot in classic builds. Since v2
-addons can't influence the build in any way (effectively making them static
-packages) addon authors need to add extra installation instructions to detail
-how to add a Webpack plugin to their application build config if they still
-wanted to influence the build process in any way. This is perfectly legitimate
-in Embroider but it does not work for classic apps.
-
-The issue is that ember-auto-import was originally designed to only work with
-npm packages, so that means that classic apps couldn't add a Webpack plugin that
-would influence the build process for any files controlled by their app, only
-for files controlled by npm packages or addons. This has been a
-[blocker for some addon developers who want to upgrade their addons to the new v2 format](https://github.com/simonihmig/ember-responsive-image/pull/442)
-and our solution to this problem has been to
-[add a new config to ember-auto-import](https://github.com/embroider-build/ember-auto-import/pull/587)
-to allow you to specify parts of your app that should be under its control.
-
-While this work has been done to facilitate v2 addons having the same install
-instructions for classic ember-cli builds and Embroider apps, this functionality
-could also be considered a way to allow you to opt-in to Embroider on a folder
-by folder basis and when your whole app is being controlled by ember-auto-import
-(and Webpack) the move to embroider should technically require no changes to the
-app.
+While the main focus of the Embroider Initiative was always going to be the Embroider code base, there are other parts of the ecosystem that will require some work to bring them more in line with how we want people to build their apps.
+
+If you're already using Embroider, you will know that a lot of the work to package your app is done by Webpack. If you're still on a classic build, you may not be aware that ember-auto-import uses Webpack under the hood to allow you to seamlessly import from `node_modules`. This has been a very useful feature but since the acceptance of the [v2 addon spec RFC](https://rfcs.emberjs.com/id/0507-embroider-v2-package-format) we have noticed that we have a bit of a blindspot in classic builds. Since v2 addons can't influence the build in any way (effectively making them static packages) addon authors need to add extra installation instructions to detail how to add a Webpack plugin to their application build config if they still wanted to influence the build process in any way. This is perfectly legitimate in Embroider but it does not work for classic apps.
+
+The issue is that ember-auto-import was originally designed to only work with npm packages, so that means that classic apps couldn't add a Webpack plugin that would influence the build process for any files controlled by their app, only for files controlled by npm packages or addons. This has been a [blocker for some addon developers who want to upgrade their addons to the new v2 format](https://github.com/simonihmig/ember-responsive-image/pull/442) and our solution to this problem has been to [add a new config to ember-auto-import](https://github.com/embroider-build/ember-auto-import/pull/587) to allow you to specify parts of your app that should be under its control.
+
+While this work has been done to facilitate v2 addons having the same install instructions for classic ember-cli builds and Embroider apps, this functionality could also be considered a way to allow you to opt-in to Embroider on a folder by folder basis and when your whole app is being controlled by ember-auto-import (and Webpack) the move to embroider should technically require no changes to the app.
 
 ## Progress for Embroider Initiative backers
 
-For the Embroider Initiative to be successful, it needs backing from companies
-that would benefit from a modern and thriving Ember ecosystem. But the benefits
-of sponsoring the project go beyond the end goal.
+For the Embroider Initiative to be successful, it needs backing from companies that would benefit from a modern and thriving Ember ecosystem. But the benefits of sponsoring the project go beyond the end goal.
 
-While all sponsorship tiers (starting at 3k€ for individual supporters) include
-a backer's logo in Mainmatter communication around the Initiative, companies
-committing 18k€ to the project get access to the weekly 1-hour call with the
-team and get opportunities to discuss their technical needs and challenges
-related to Embroider.
+While all sponsorship tiers (starting at 3k€ for individual supporters) include a backer's logo in Mainmatter communication around the Initiative, companies committing 18k€ to the project get access to the weekly 1-hour call with the team and get opportunities to discuss their technical needs and challenges related to Embroider.
 
-Premium tiers of 36k€ and above include a 2-hour weekly private session with
-Mainmatter engineers focused on improving the backer's Ember build. In practice,
-these backers have seen a great return on their investment as the Mainmatter
-Embroider team has been able to deliver dramatic speed improvements to their
-build, removing a bottleneck in their development process. Some issues specific
-to these backers also resulted in solutions that the larger Ember community can
-now benefit from.
+Premium tiers of 36k€ and above include a 2-hour weekly private session with Mainmatter engineers focused on improving the backer's Ember build. In practice, these backers have seen a great return on their investment as the Mainmatter Embroider team has been able to deliver dramatic speed improvements to their build, removing a bottleneck in their development process. Some issues specific to these backers also resulted in solutions that the larger Ember community can now benefit from.
 
 Let's see some success stories in details:
 
 ### Ticketsolve
 
-Like many companies, Ticketsolve has an internal addon that they use throughout
-their other applications. Internal addons are a great place to start when you
-are thinking about upgrading to Embroider for two reasons:
+Like many companies, Ticketsolve has an internal addon that they use throughout their other applications. Internal addons are a great place to start when you are thinking about upgrading to Embroider for two reasons:
 
 1. It's an isolated place to opt into Embroider's stricter requirements
-2. There is a
-   [clear specification](https://github.com/embroider-build/embroider/blob/main/docs/spec.md)
-   of what your v2 addon can do.
-
-Chris' work on improving the ergonomics of the v2 addon blueprint in the early
-weeks of the Embroider Initiative, proved very useful during the process of
-converting Ticketsolve's internal addon.
-
-After the internal addon was fully converted to v2 and deployed to all of
-Ticketsolve's apps, our next step was to add support for
-[GJS files](https://rfcs.emberjs.com/id/0779-first-class-component-templates/)
-in both the internal addon and their applications. The team also worked on the
-ecosystem PRs required to enable GJS support in v2 addons in both a
-`@embroider/addon-dev`
-[PR](https://github.com/embroider-build/embroider/pull/1518) and a
-[PR](https://github.com/embroider-build/addon-blueprint/pull/159) to the
-`@embroider/addon-blueprint`.
-
-Before the Embroider Initiative, Ticketsolve had one of their three apps already
-running Embroider. We worked to update the Embroider version of that app, then
-started to convert the remaining two apps. There were some challenges along the
-way, mostly related to addons that just didn't support Embroider. A great
-example of this is the
-[ember-service-worker](https://github.com/DockYard/ember-service-worker) addon
-which uses the `postprocessTree()` hook that doesn't work with Embroider. We
-updated the addon locally using [`pnpm patch <pkg>`](https://pnpm.io/cli/patch)
-and
-[submitted a PR with the same changes](https://github.com/DockYard/ember-service-worker/pull/230)
-to help the rest of the community.
-
-This is only a fraction of the changes that came out of these pairing sessions,
-but it gives a flavour of the kinds of things that we have been able to achieve.
-While our Chris Manson has been instrumental in helping speed up this work,
-Ticketsolve's engineer [Andreas Minnich](https://github.com/enspandi) deserves a
-shout-out for the colossal amount of work they have put into this effort between
-pairing sessions.
+2. There is a [clear specification](https://github.com/embroider-build/embroider/blob/main/docs/spec.md) of what your v2 addon can do.
+
+Chris' work on improving the ergonomics of the v2 addon blueprint in the early weeks of the Embroider Initiative, proved very useful during the process of converting Ticketsolve's internal addon.
+
+After the internal addon was fully converted to v2 and deployed to all of Ticketsolve's apps, our next step was to add support for [GJS files](https://rfcs.emberjs.com/id/0779-first-class-component-templates/) in both the internal addon and their applications. The team also worked on the ecosystem PRs required to enable GJS support in v2 addons in both a `@embroider/addon-dev` [PR](https://github.com/embroider-build/embroider/pull/1518) and a [PR](https://github.com/embroider-build/addon-blueprint/pull/159) to the `@embroider/addon-blueprint`.
+
+Before the Embroider Initiative, Ticketsolve had one of their three apps already running Embroider. We worked to update the Embroider version of that app, then started to convert the remaining two apps. There were some challenges along the way, mostly related to addons that just didn't support Embroider. A great example of this is the [ember-service-worker](https://github.com/DockYard/ember-service-worker) addon which uses the `postprocessTree()` hook that doesn't work with Embroider. We updated the addon locally using [`pnpm patch <pkg>`](https://pnpm.io/cli/patch) and [submitted a PR with the same changes](https://github.com/DockYard/ember-service-worker/pull/230) to help the rest of the community.
+
+This is only a fraction of the changes that came out of these pairing sessions, but it gives a flavour of the kinds of things that we have been able to achieve. While our Chris Manson has been instrumental in helping speed up this work, Ticketsolve's engineer [Andreas Minnich](https://github.com/enspandi) deserves a shout-out for the colossal amount of work they have put into this effort between pairing sessions.
 
 ### Intercom
 
-Intercom also had an internal addon they wanted to convert to v2 before working
-on converting their main application. Mainmatter worked with them to convert
-that and, incidentally, we also helped them to convert the tests app that was
-documenting the v2 addon to use Embroider with the `staticAddonTestSupportTrees`
-and `staticAddonTrees` flags turned on.
-
-While this work was going on, Intercom Engineer
-[Aaron Chambers](https://github.com/achambers) had setup a CI build step that
-would keep track if the main Intercom app could build with Embroider and if any
-tests were passing. Because of this CI job, Aaron identified a 10x slowdown in
-build times between Embroider v3.1 and v3.2. Chris used a number of pairing
-sessions to dive into the issue and produce a number of flamecharts for their
-Embroider builds to get an insight into what was causing their specific
-slowdown. Those flamecharts were pointing at a particular part of Embroider's
-package cache not working exactly as we intended it to. Ed Faulkner managed to
-pinpoint the problem (while we were discussing it in the "hallway track" of
-[EmberFest](https://emberfest.eu)) and
-[opened a pull-request with the fix](https://github.com/embroider-build/embroider/pull/1609).
-This completely fixed the performance regression for Intercom.
-
-The Mainmatter Embroider team also noticed that Intercom's build was behaving
-differently on CI compared to running the exact same build locally. We tracked
-it down to the fact that Intercom's CI was configured to create a symbolic link
-to an existing `node_modules` folder rather than running a new `npm install` for
-every job. As it turns out, this was the same reason that the CI was failing for
-[Chris' pull request to make Embroider optimised the default](https://github.com/ember-cli/ember-cli/pull/10370)
-when running the command `ember new --embroider`. Chris identified the cause of
-the issue inside Embroider and
-[fixed it](https://github.com/embroider-build/embroider/pull/1622) without the
-need for any assistance from Ed, which also shows the success in making
-Embroider more maintainable by increasing the team size and distributing
-technical knowledge (more about this in the next section).
-
-The rest of the pairing sessions were spent working through issues that were
-causing tests to fail. Some of these issues were systemic and when they were
-fixed they would turn hundreds of tests green (Intercom has a lot of tests),
-while other problems were highly specific and required multiple pairing sessions
-to identify and fix the problem. An example of this would be Intercom's use of
-the charting library [Highcharts](https://www.highcharts.com). When a Highcharts
-user needs to include timezones in their Date axis, the library will check for
-the presence of `window.moment` and use it for any timezone-related
-calculations. This allows the user to have a chance to setup `window.moment` to
-use `moment-timezone` and correctly configure it with the right set of timezone
-data for their application. With the move to Embroider, `window.moment` is no
-longer accidentally set to the correct instance of `moment-timzone` as a
-side-effect of the build system, so Highcharts wasn't finding the right instance
-during its initialisation. It turns out that Highcharts
-[provides a config option](https://api.highcharts.com/highcharts/time.moment),
-`time.moment`, to cover this exact case and, as soon as the team set that
-correctly in the application's charts base class, the x-axis started behaving
-again.
-
-Again, these are only a fraction of the changes that came out of these pairing
-sessions. Both [Aaron Chambers](https://github.com/achambers) and
-[Peter Meehan](https://github.com/22a) were able to achieve a lot of big things
-over the course of the Embroider Initiative for Intercom and our team was more
-than happy to help speed the process along.
+Intercom also had an internal addon they wanted to convert to v2 before working on converting their main application. Mainmatter worked with them to convert that and, incidentally, we also helped them to convert the tests app that was documenting the v2 addon to use Embroider with the `staticAddonTestSupportTrees` and `staticAddonTrees` flags turned on.
+
+While this work was going on, Intercom Engineer [Aaron Chambers](https://github.com/achambers) had setup a CI build step that would keep track if the main Intercom app could build with Embroider and if any tests were passing. Because of this CI job, Aaron identified a 10x slowdown in build times between Embroider v3.1 and v3.2. Chris used a number of pairing sessions to dive into the issue and produce a number of flamecharts for their Embroider builds to get an insight into what was causing their specific slowdown. Those flamecharts were pointing at a particular part of Embroider's package cache not working exactly as we intended it to. Ed Faulkner managed to pinpoint the problem (while we were discussing it in the "hallway track" of [EmberFest](https://emberfest.eu)) and [opened a pull-request with the fix](https://github.com/embroider-build/embroider/pull/1609). This completely fixed the performance regression for Intercom.
+
+The Mainmatter Embroider team also noticed that Intercom's build was behaving differently on CI compared to running the exact same build locally. We tracked it down to the fact that Intercom's CI was configured to create a symbolic link to an existing `node_modules` folder rather than running a new `npm install` for every job. As it turns out, this was the same reason that the CI was failing for [Chris' pull request to make Embroider optimised the default](https://github.com/ember-cli/ember-cli/pull/10370) when running the command `ember new --embroider`. Chris identified the cause of the issue inside Embroider and [fixed it](https://github.com/embroider-build/embroider/pull/1622) without the need for any assistance from Ed, which also shows the success in making Embroider more maintainable by increasing the team size and distributing technical knowledge (more about this in the next section).
+
+The rest of the pairing sessions were spent working through issues that were causing tests to fail. Some of these issues were systemic and when they were fixed they would turn hundreds of tests green (Intercom has a lot of tests), while other problems were highly specific and required multiple pairing sessions to identify and fix the problem. An example of this would be Intercom's use of the charting library [Highcharts](https://www.highcharts.com). When a Highcharts user needs to include timezones in their Date axis, the library will check for the presence of `window.moment` and use it for any timezone-related calculations. This allows the user to have a chance to setup `window.moment` to use `moment-timezone` and correctly configure it with the right set of timezone data for their application. With the move to Embroider, `window.moment` is no longer accidentally set to the correct instance of `moment-timzone` as a side-effect of the build system, so Highcharts wasn't finding the right instance during its initialisation. It turns out that Highcharts [provides a config option](https://api.highcharts.com/highcharts/time.moment), `time.moment`, to cover this exact case and, as soon as the team set that correctly in the application's charts base class, the x-axis started behaving again.
+
+Again, these are only a fraction of the changes that came out of these pairing sessions. Both [Aaron Chambers](https://github.com/achambers) and [Peter Meehan](https://github.com/22a) were able to achieve a lot of big things over the course of the Embroider Initiative for Intercom and our team was more than happy to help speed the process along.
 
 ## Improving the bus factor
 
-The goals of Embroider may seem simple from the outside, i.e. "just use Webpack
-or Vite to build your Ember app", but when digging a bit deeper, it's easy to
-see how complex of a project it really is. This complexity arises from the
-project having challenging design constraints which pose a significant challenge
-to anyone who would like to contribute to the core of Embroider. The main design
-constraint that causes a lot of this complexity arises from the fact that the
-team wants to provide an easy on-ramp for existing Ember apps to convert to
-Embroider, and then slowly move those apps from full-compatibility mode to a
-"fully static" build that can automatically benefit from tree-shaking and
-code-splitting. This means that we need to provide systems that can
-automatically convert the still-supported conventions of an Ember app to fully
-standard compliant ESM code. This is a significant challenge since some of the
-patterns that are still **officially** supported today date back to the 1.x
-series of Ember which was released in 2015.
-
-Because of the overall complexity of project and the rapid iteration of the
-internal architecture, it hasn't been practical to create any documentation that
-could communicate what is going on under the hood. This is illustrated by the
-fact that [Aaron Chambers](https://github.com/achambers) and
-[Peter Meehan](https://github.com/22a) put together a
-[document trying to explain the full architecture of the project](https://github.com/embroider-build/embroider/pull/1459),
-which was completely outdated only less than a month later when Ed Faulkner
-merged
-[the first of many internal refactors](https://github.com/embroider-build/embroider/pull/1435).
-
-To address this challenge, we have adopted an apprenticeship model where
-[Ed Faulkner](https://github.com/ef4/) pairs with Chris every week,
-collaborating on solving complex problems deep within the heart of the Embroider
-codebase. This has made a significant improvement to the
-[bus factor](https://en.wikipedia.org/wiki/Bus_factor) of the Embroider project
-and has also had a deep impact on its velocity.
-
-With our second full-time engineer on the Embroider Initiative,
-[Andrey Mikhaylov](https://github.com/lolmaus/), we have extended the
-apprenticeship model by having Chris and Andrey pair-program for half a day each
-week. This has helped both Chris and Andrey ramp up their knowledge of the
-codebase while improving the overall project's bus factor.
+The goals of Embroider may seem simple from the outside, i.e. "just use Webpack or Vite to build your Ember app", but when digging a bit deeper, it's easy to see how complex of a project it really is. This complexity arises from the project having challenging design constraints which pose a significant challenge to anyone who would like to contribute to the core of Embroider. The main design constraint that causes a lot of this complexity arises from the fact that the team wants to provide an easy on-ramp for existing Ember apps to convert to Embroider, and then slowly move those apps from full-compatibility mode to a "fully static" build that can automatically benefit from tree-shaking and code-splitting. This means that we need to provide systems that can automatically convert the still-supported conventions of an Ember app to fully standard compliant ESM code. This is a significant challenge since some of the patterns that are still **officially** supported today date back to the 1.x series of Ember which was released in 2015.
+
+Because of the overall complexity of project and the rapid iteration of the internal architecture, it hasn't been practical to create any documentation that could communicate what is going on under the hood. This is illustrated by the fact that [Aaron Chambers](https://github.com/achambers) and [Peter Meehan](https://github.com/22a) put together a [document trying to explain the full architecture of the project](https://github.com/embroider-build/embroider/pull/1459), which was completely outdated only less than a month later when Ed Faulkner merged [the first of many internal refactors](https://github.com/embroider-build/embroider/pull/1435).
+
+To address this challenge, we have adopted an apprenticeship model where [Ed Faulkner](https://github.com/ef4/) pairs with Chris every week, collaborating on solving complex problems deep within the heart of the Embroider codebase. This has made a significant improvement to the [bus factor](https://en.wikipedia.org/wiki/Bus_factor) of the Embroider project and has also had a deep impact on its velocity.
+
+With our second full-time engineer on the Embroider Initiative, [Andrey Mikhaylov](https://github.com/lolmaus/), we have extended the apprenticeship model by having Chris and Andrey pair-program for half a day each week. This has helped both Chris and Andrey ramp up their knowledge of the codebase while improving the overall project's bus factor.
 
 ## General stability and ecosystem improvements
 
 ### Providing watch-mode tests for Embroider
 
-Recently, [Godfrey Chan](https://github.com/chancancode) has been discovering
-some places in Embroider and our Webpack plugin that were
-[causing crashes when certain files were added or deleted](https://github.com/embroider-build/embroider/issues/1619).
-He has already come up with a
-[fix for some of the cases](https://github.com/embroider-build/embroider/pull/1620),
-but it showed a blind spot in the team's testing infrastructure that meant we
-weren't testing "watch mode" in Embroider.
-[Preston Sego](https://github.com/NullVoxPopuli) and Chris paired together to
-[add some basic watch mode tests](https://github.com/embroider-build/embroider/pull/1624)
-that would highlight the problem and prove the effectiveness of the fix, but
-they were hit by some strange quirks that prevented the watch-mode tests from
-ever exiting properly on the Windows CI job. Chris spent most of his
-[weekly streaming session on Twitch](https://www.twitch.tv/real_ate) trying to
-[figure out the solution](https://github.com/embroider-build/embroider/pull/1624/files#diff-adeba5225992c6c7545d60355bcb082048a61ff39fdb2d9f5aa0d2c585e8d896R55-R62).
-The team finally got the PR merged and is now ready to start adding more
-expansive watch-mode tests.
+Recently, [Godfrey Chan](https://github.com/chancancode) has been discovering some places in Embroider and our Webpack plugin that were [causing crashes when certain files were added or deleted](https://github.com/embroider-build/embroider/issues/1619). He has already come up with a [fix for some of the cases](https://github.com/embroider-build/embroider/pull/1620), but it showed a blind spot in the team's testing infrastructure that meant we weren't testing "watch mode" in Embroider. [Preston Sego](https://github.com/NullVoxPopuli) and Chris paired together to [add some basic watch mode tests](https://github.com/embroider-build/embroider/pull/1624) that would highlight the problem and prove the effectiveness of the fix, but they were hit by some strange quirks that prevented the watch-mode tests from ever exiting properly on the Windows CI job. Chris spent most of his [weekly streaming session on Twitch](https://www.twitch.tv/real_ate) trying to [figure out the solution](https://github.com/embroider-build/embroider/pull/1624/files#diff-adeba5225992c6c7545d60355bcb082048a61ff39fdb2d9f5aa0d2c585e8d896R55-R62). The team finally got the PR merged and is now ready to start adding more expansive watch-mode tests.
 
 ### `ember-cli-update` supporting v2 addons
 
-`ember-cli-update` is a great asset to the Ember community, and it's a vital
-tool during the push for Embroider and encouraging the community to use the new
-v2 addon blueprint because a lot of the recent changes require updating both a
-dependency version and related configuration.
-
-One issue the team worked through was to fix CI, which had been broken for a
-year. `ember-cli-update` interacts with the npm APIs to discover versions, but a
-change on the npm side prevented it from functioning properly. The solution to
-fixing CI was ultimately updating a dependency, `boilerplate-update`, to use
-[pacote](https://www.npmjs.com/package/pacote) to interact with the npm API.
-Once the upstream dependency was updated, the team only needed to
-[add a few tweaks to ember-cli-update](https://github.com/ember-cli/ember-cli-update/pull/1243)
-to get CI to finally pass. This gave us time and confidence for the rest of the
-project.
-
-The team then worked to get a new release of
-[ember-cli-update](https://github.com/ember-cli/ember-cli-update) so that it
-could update any Ember addon generated with the
-[v2 addon blueprint](https://github.com/embroider-build/addon-blueprint).
-
-`ember-cli-update` works by generating a diff between the version of the
-blueprint that the app or addon was generated with, and the version to update it
-to. Under the hood, this means that `ember-cli-update` will generate a pristine
-new version of the app/addon at its current version, then generates a new
-pristine copy of the target version. It generates a `git diff` between those
-versions then applies that diff to the current app.
-
-Generating these pristine "from" and "to" versions of the blueprint involved a
-custom code-path in `ember-cli-update` that aimed at working around some bugs in
-Node 8. As those workarounds were causing it to fail, Chris'
-[fix for custom blueprints](https://github.com/ember-cli/ember-cli-update/pull/1240)
-involved removing these workarounds.
-[This fix was released in `ember-cli-update v2.0.0`](https://github.com/ember-cli/ember-cli-update/releases/tag/v2.0.0),
-then followed by
-[another release](https://github.com/ember-cli/ember-cli-update/releases/tag/v2.0.1)
-that fixed a small bug. These two releases are a big deal for the wider Ember
-community, especially as its members are encouraged to migrate their existing v1
-addons to v2 addons. They bring an important DX functionality that the Ember
-community has come to expect.
+`ember-cli-update` is a great asset to the Ember community, and it's a vital tool during the push for Embroider and encouraging the community to use the new v2 addon blueprint because a lot of the recent changes require updating both a dependency version and related configuration.
+
+One issue the team worked through was to fix CI, which had been broken for a year. `ember-cli-update` interacts with the npm APIs to discover versions, but a change on the npm side prevented it from functioning properly. The solution to fixing CI was ultimately updating a dependency, `boilerplate-update`, to use [pacote](https://www.npmjs.com/package/pacote) to interact with the npm API. Once the upstream dependency was updated, the team only needed to [add a few tweaks to ember-cli-update](https://github.com/ember-cli/ember-cli-update/pull/1243) to get CI to finally pass. This gave us time and confidence for the rest of the project.
+
+The team then worked to get a new release of [ember-cli-update](https://github.com/ember-cli/ember-cli-update) so that it could update any Ember addon generated with the [v2 addon blueprint](https://github.com/embroider-build/addon-blueprint).
+
+`ember-cli-update` works by generating a diff between the version of the blueprint that the app or addon was generated with, and the version to update it to. Under the hood, this means that `ember-cli-update` will generate a pristine new version of the app/addon at its current version, then generates a new pristine copy of the target version. It generates a `git diff` between those versions then applies that diff to the current app.
+
+Generating these pristine "from" and "to" versions of the blueprint involved a custom code-path in `ember-cli-update` that aimed at working around some bugs in Node 8. As those workarounds were causing it to fail, Chris' [fix for custom blueprints](https://github.com/ember-cli/ember-cli-update/pull/1240) involved removing these workarounds. [This fix was released in `ember-cli-update v2.0.0`](https://github.com/ember-cli/ember-cli-update/releases/tag/v2.0.0), then followed by [another release](https://github.com/ember-cli/ember-cli-update/releases/tag/v2.0.1) that fixed a small bug. These two releases are a big deal for the wider Ember community, especially as its members are encouraged to migrate their existing v1 addons to v2 addons. They bring an important DX functionality that the Ember community has come to expect.
 
 ### Embroider optimised with the `--embroider` flag
 
-Creating a new Ember app with the `embroider` flag
-(`ember new my-super-app --embroider`) generates a "full compat" app were none
-of the
-[Embroider optimisation flags](https://github.com/embroider-build/embroider#options)
-are passed to the build for the developer.
-
-While more existing apps will work with a "full compat" mode, Ember has reached
-a point where it makes sense for **newly generated apps** to start with a high
-water mark so that developers don't accidentally or unconsciously add
-functionality that won't work in a fully optimised Embroider application.
-Developers have the option to turn off any of the optimisation flags, but it
-would be a deliberate choice as they would need to add a specific dependency or
-functionality to their app.
-
-The Mainmatter Embroider team opened a
-[PR to switch the functionality](https://github.com/ember-cli/ember-cli/pull/10370)
-so that passing the `--embroider` flag uses Embroider optimised by default. This
-involved working through issues with some of the slow test suites that rely on a
-custom package caching mechanism. The PR got merged and the functionality will
-be part of Ember v5.5.
+Creating a new Ember app with the `embroider` flag (`ember new my-super-app --embroider`) generates a "full compat" app were none of the [Embroider optimisation flags](https://github.com/embroider-build/embroider#options) are passed to the build for the developer.
+
+While more existing apps will work with a "full compat" mode, Ember has reached a point where it makes sense for **newly generated apps** to start with a high water mark so that developers don't accidentally or unconsciously add functionality that won't work in a fully optimised Embroider application. Developers have the option to turn off any of the optimisation flags, but it would be a deliberate choice as they would need to add a specific dependency or functionality to their app.
+
+The Mainmatter Embroider team opened a [PR to switch the functionality](https://github.com/ember-cli/ember-cli/pull/10370) so that passing the `--embroider` flag uses Embroider optimised by default. This involved working through issues with some of the slow test suites that rely on a custom package caching mechanism. The PR got merged and the functionality will be part of Ember v5.5.
 
 ### `scenario-tester` ESM compatibility
 
-[Scenario tester](https://github.com/embroider-build/scenario-tester) is a
-testing tool that the team makes use of a lot when testing Embroider and
-`ember-auto-import`. It allows us to generate many scenarios with different
-combinations of dependencies. We tried using it outside of Embroider, or more
-specifically outside of a Typescript project, and saw it doesn't work in a CJS
-environment.
-[Chris started the effort to move the Typescript build to output an ESM-compatible build](https://github.com/embroider-build/scenario-tester/pull/18)
-so it can be consumed directly in ESM without a build step. The only remaining
-task is to test if it will work in Embroider before merging and releasing the
-new version.
+[Scenario tester](https://github.com/embroider-build/scenario-tester) is a testing tool that the team makes use of a lot when testing Embroider and `ember-auto-import`. It allows us to generate many scenarios with different combinations of dependencies. We tried using it outside of Embroider, or more specifically outside of a Typescript project, and saw it doesn't work in a CJS environment. [Chris started the effort to move the Typescript build to output an ESM-compatible build](https://github.com/embroider-build/scenario-tester/pull/18) so it can be consumed directly in ESM without a build step. The only remaining task is to test if it will work in Embroider before merging and releasing the new version.
 
 ### Documenting the scenario-tester library.
 
-[`scenario-tester`](https://github.com/ef4/scenario-tester/) is to Embroider
-what `ember-try` is to Ember CLI: it's a tool that lets us perform automated
-tests with various combinations of dependencies, configs and circumstances. The
-approach of `scenario-tester` is different: instead of reinstalling dependencies
-for every test case, it has all dependencies (including all versions of
-dependencies) set up once, saving a lot of time. It leverages
-[fixturify-project](https://github.com/stefanpenner/node-fixturify-project) to
-create and emit to filesystem Ember apps and addons with predefined dependencies
-and configuration, in order to run tests on them.
+[`scenario-tester`](https://github.com/ef4/scenario-tester/) is to Embroider what `ember-try` is to Ember CLI: it's a tool that lets us perform automated tests with various combinations of dependencies, configs and circumstances. The approach of `scenario-tester` is different: instead of reinstalling dependencies for every test case, it has all dependencies (including all versions of dependencies) set up once, saving a lot of time. It leverages [fixturify-project](https://github.com/stefanpenner/node-fixturify-project) to create and emit to filesystem Ember apps and addons with predefined dependencies and configuration, in order to run tests on them.
 
 ### Working on the reverse-exports
 
-During the build, Embroider needs to expose Ember internals to Vite and Webpack
-in a way they can understand and consume. Modern Ember apps can have multiple
-[exports](https://nodejs.org/api/packages.html#package-entry-points) entry
-points in their `package.json` configs. This poses a peculiar challenge for
-Embroider: it needs to know how to reorganize files in an Ember project in such
-a way that they would resolve into paths defined as `exports` values.
-Essentially, this requires resolving `exports` in reverse, and this it what the
-[reverse-exports](https://github.com/embroider-build/embroider/pull/1652/)
-package is for.
+During the build, Embroider needs to expose Ember internals to Vite and Webpack in a way they can understand and consume. Modern Ember apps can have multiple [exports](https://nodejs.org/api/packages.html#package-entry-points) entry points in their `package.json` configs. This poses a peculiar challenge for Embroider: it needs to know how to reorganize files in an Ember project in such a way that they would resolve into paths defined as `exports` values. Essentially, this requires resolving `exports` in reverse, and this it what the [reverse-exports](https://github.com/embroider-build/embroider/pull/1652/) package is for.
 
 ## Call to action
 
-We are hoping we can extend the initiative's budget and timeline to keep up the
-momentum in 2024 and finish the work we started. Please [get in touch](/contact)
-to learn how to support the Embroider Initiative and directly benefit from this
-investment!
+We are hoping we can extend the initiative's budget and timeline to keep up the momentum in 2024 and finish the work we started. Please [get in touch](/contact) to learn how to support the Embroider Initiative and directly benefit from this investment!
diff --git a/src/posts/2023-11-23-setting-up-oauth-with-auth-js-and-sveltekit.md b/src/posts/2023-11-23-setting-up-oauth-with-auth-js-and-sveltekit.md
index 5b81c26024..222ea44359 100644
--- a/src/posts/2023-11-23-setting-up-oauth-with-auth-js-and-sveltekit.md
+++ b/src/posts/2023-11-23-setting-up-oauth-with-auth-js-and-sveltekit.md
@@ -3,12 +3,7 @@ title: "Setting up OAuth with Auth.js in a SvelteKit Project"
 authorHandle: lolmaus
 tags: [svelte, sveltekit, oauth, authjs]
 bio: "Andrey Mikhaylov (lolmaus)"
-description:
-  "Andrey Mikhaylov (lolmaus) provides a step-by-step guide for setting up OAuth
-  authentication using the Auth.js library in a SvelteKit project. He describes
-  a number of pitfalls that may be a source of frustration even to experienced
-  developers, due to error messages being unhelpful — and explains how to get
-  around them."
+description: "Andrey Mikhaylov (lolmaus) provides a step-by-step guide for setting up OAuth authentication using the Auth.js library in a SvelteKit project. He describes a number of pitfalls that may be a source of frustration even to experienced developers, due to error messages being unhelpful — and explains how to get around them."
 og:
   image: /assets/images/posts/2023-11-23-setting-up-oauth-with-auth-js-and-sveltekit/og-image.jpg
 tagline: |
@@ -21,137 +16,76 @@ imageAlt: "The Svelte logo on a gray backround picture"
 
 ## What is OAuth
 
-For the sake of completeness of this article, let’s pretend you don’t already
-know. ;)
+For the sake of completeness of this article, let’s pretend you don’t already know. ;)
 
-In simple words, OAuth is an approach for letting users log into your app
-without having to come up with a username and password. Instead, you rely on
-them being already authenticated with a popular third party service that offers
-OAuth (OAuth provider), such as Google and GitHub.
+In simple words, OAuth is an approach for letting users log into your app without having to come up with a username and password. Instead, you rely on them being already authenticated with a popular third party service that offers OAuth (OAuth provider), such as Google and GitHub.
 
-To do so, your app redirects the user to an OAuth provider. The user approves
-authentication there, and the provider redirects back to the app, where the user
-is now authenticated.
+To do so, your app redirects the user to an OAuth provider. The user approves authentication there, and the provider redirects back to the app, where the user is now authenticated.
 
-If you need to, you can look up more information on OAuth online, where you will
-find plenty of articles for your desired level of depth.
+If you need to, you can look up more information on OAuth online, where you will find plenty of articles for your desired level of depth.
 
 ## What’s Auth.js
 
-[Auth.js](https://authjs.dev) is a library that aims to be a universal
-authentication layer for JS frontend and full-stack apps.
+[Auth.js](https://authjs.dev) is a library that aims to be a universal authentication layer for JS frontend and full-stack apps.
 
-It started as NextAuth, built specifically for the Next.js framework
-(full-stack, React-based), but was later converted into a universal library.
+It started as NextAuth, built specifically for the Next.js framework (full-stack, React-based), but was later converted into a universal library.
 
 ## Gotcha 0: Authentication vs Authorization
 
-There’s a lot of confusion around the terms "authentication" and
-"authorization".
+There’s a lot of confusion around the terms "authentication" and "authorization".
 
-From an academic perspective, “authentication” means verifying who the user is,
-and “authorization” is verifying if the identified user has permission to access
-or do something.
+From an academic perspective, “authentication” means verifying who the user is, and “authorization” is verifying if the identified user has permission to access or do something.
 
-A nice analogy is attending a regulated facility. In order to get in, you first
-need to visit a Pass and Registration Office. You show them your id and they
-issue a daily pass for you. Now you can enter, and every time you need go
-through a security checkpoint, you present your daily pass to a security guard.
-The security guard would then make sure that the pass is still valid and might
-even call the Registration Office to run your pass through their database.
+A nice analogy is attending a regulated facility. In order to get in, you first need to visit a Pass and Registration Office. You show them your id and they issue a daily pass for you. Now you can enter, and every time you need go through a security checkpoint, you present your daily pass to a security guard. The security guard would then make sure that the pass is still valid and might even call the Registration Office to run your pass through their database.
 
-In this analogy, presenting your id to the Pass and Registration office is
-“authentication” — checking that a person is who they claim to be. Presenting
-your daily pass to a security guard is “authorization” — checking if a person is
-allowed to perform an action such as visiting an office. Offices behind security
-checkpoints represent API endpoints.
+In this analogy, presenting your id to the Pass and Registration office is “authentication” — checking that a person is who they claim to be. Presenting your daily pass to a security guard is “authorization” — checking if a person is allowed to perform an action such as visiting an office. Offices behind security checkpoints represent API endpoints.
 
-The problem is that in practice people don’t really distinguish between
-“authentication” and “authorization” that much. You can find these terms used
-interchangeably.
+The problem is that in practice people don’t really distinguish between “authentication” and “authorization” that much. You can find these terms used interchangeably.
 
-People who know there’s a difference between the two terms but aren’t sure which
-one is appropriate in which context, have a loophole: simply say “auth”! 😬 The
-fact that the word “auth” perfectly fits any article and library documentation,
-proves that the two terms are interchangeable _in practice_.
+People who know there’s a difference between the two terms but aren’t sure which one is appropriate in which context, have a loophole: simply say “auth”! 😬 The fact that the word “auth” perfectly fits any article and library documentation, proves that the two terms are interchangeable _in practice_.
 
 ## Gotcha 1: “OAuth” means OAuth 2
 
-There are two versions of the OAuth protocol which are incompatible with each
-other. The modern version is OAuth 2, naturally. That’s what everyone uses.
+There are two versions of the OAuth protocol which are incompatible with each other. The modern version is OAuth 2, naturally. That’s what everyone uses.
 
-When OAuth is mentioned and the version is not specified, it normally means
-OAuth 2. This article does this, too.
+When OAuth is mentioned and the version is not specified, it normally means OAuth 2. This article does this, too.
 
 ## Gotcha 2: OAuth Authentication Flow Types
 
 The OAuth standard offers a choice of four authentication flows:
 
-- **Client credentials** flow — implies passing a key and a secret, useful for
-  server-to-server interactions, such as CI, CLI, etc.
-- **Device authorization** flow — uses a separate device for user authorization,
-  such as a mobile phone. Useful for authenticating devices that have limited
-  user interface: servers, smart TVs, etc.
-- **Implicit** flow — a simple flow, useful for classic frontend-less apps that
-  render HTML on the backend. Should not be used with a frontend, as it would
-  required storing the app secret code in localStorage, which is unsafe.
-  Considered obsolete.
-- **Authorization code** flow — a more involved flow, best suited for web apps.
-  The app secret code is safely stored on the backend, the access token can be
-  stored on the backend too.
+- **Client credentials** flow — implies passing a key and a secret, useful for server-to-server interactions, such as CI, CLI, etc.
+- **Device authorization** flow — uses a separate device for user authorization, such as a mobile phone. Useful for authenticating devices that have limited user interface: servers, smart TVs, etc.
+- **Implicit** flow — a simple flow, useful for classic frontend-less apps that render HTML on the backend. Should not be used with a frontend, as it would required storing the app secret code in localStorage, which is unsafe. Considered obsolete.
+- **Authorization code** flow — a more involved flow, best suited for web apps. The app secret code is safely stored on the backend, the access token can be stored on the backend too.
 
 We will be using the **authorization code** flow.
 
 ## Gotcha 3: You Need a Backend!
 
-OAuth authentication cannot be implemented in a frontend-only app without any
-backend, such as an SPA deployed to GitHub Pages.
+OAuth authentication cannot be implemented in a frontend-only app without any backend, such as an SPA deployed to GitHub Pages.
 
-This is because the app needs to pass a secret token (essentially, a password)
-to the OAuth provider, so that the provider recognizes the app. If you added
-this secret token into the frontend, it would be accessible from the browser to
-everyone on the internet. A malefactor would be able to extract it and implement
-a fake copy of your app that authenticates users for real, stealing their auth
-tokens. As a result, the malefactor would be able to access your app as another
-user.
+This is because the app needs to pass a secret token (essentially, a password) to the OAuth provider, so that the provider recognizes the app. If you added this secret token into the frontend, it would be accessible from the browser to everyone on the internet. A malefactor would be able to extract it and implement a fake copy of your app that authenticates users for real, stealing their auth tokens. As a result, the malefactor would be able to access your app as another user.
 
-For this reason, your frontend app should not authenticate with an OAuth
-provider directly, but rather leave this job to your backend. It’s your backend
-that safely stores the secret token and passes it to the OAuth provider.
+For this reason, your frontend app should not authenticate with an OAuth provider directly, but rather leave this job to your backend. It’s your backend that safely stores the secret token and passes it to the OAuth provider.
 
-Luckily, SvelteKit can work as a full-stack app, with a frontend **and** a
-backend!
+Luckily, SvelteKit can work as a full-stack app, with a frontend **and** a backend!
 
 ## Gotcha 4: The Authorization Code Flow Can Be Implemented in Different Ways
 
-If you search the internet for diagrams explaining the OAuth authorization code
-flow, you’ll notice that they all vary in small details.
+If you search the internet for diagrams explaining the OAuth authorization code flow, you’ll notice that they all vary in small details.
 
 This is because this flow can be implemented in different ways.
 
-For example, one could enable a frontend-only app to authenticate with OAuth by
-setting up a tiny backend microservice such as
-[prose/gatekeeper](https://github.com/prose/gatekeeper) (that you can even
-deploy to Heroku for free!) that will be used for one purpose: storing your
-app’s secret and passing it to an OAuth provider when requested. This approach
-is not very secure, though, as the access token will have to be stored in
-localStorage in the browser, unencrypted and easily accessible to physical users
-and scripts on the same domain.
-
-Many apps and libraries store tokens in localStorage, but some developers and
-security professionals believe this to be unsafe.
-
-Auth.js stores the access token (used to authorize requests to third party APIs
-such as GitHub or Google) on the backend side and uses a Secure, HttpOnly cookie
-to store a session token (used to authorize requests to your own backend). Such
-a cookie can only be intercepted at the moment of issuing. Once set, it cannot
-be accessed or copied from browsers' Dev Tools or JS scripts. This substantially
-improves security.
+For example, one could enable a frontend-only app to authenticate with OAuth by setting up a tiny backend microservice such as [prose/gatekeeper](https://github.com/prose/gatekeeper) (that you can even deploy to Heroku for free!) that will be used for one purpose: storing your app’s secret and passing it to an OAuth provider when requested. This approach is not very secure, though, as the access token will have to be stored in localStorage in the browser, unencrypted and easily accessible to physical users and scripts on the same domain.
+
+Many apps and libraries store tokens in localStorage, but some developers and security professionals believe this to be unsafe.
+
+Auth.js stores the access token (used to authorize requests to third party APIs such as GitHub or Google) on the backend side and uses a Secure, HttpOnly cookie to store a session token (used to authorize requests to your own backend). Such a cookie can only be intercepted at the moment of issuing. Once set, it cannot be accessed or copied from browsers' Dev Tools or JS scripts. This substantially improves security.
 
 ## OAuth Authorization Code Flow with Auth.js
 
-This diagram is different from any other OAuth flow diagram on the internet. It
-precisely reflects the flow that Auth.js specifically is using.
+This diagram is different from any other OAuth flow diagram on the internet. It precisely reflects the flow that Auth.js specifically is using.
 
 ![authorization code flow diagram](/assets/images/posts/2023-11-23-setting-up-oauth-with-auth-js-and-sveltekit/authorization-code-flow-diagram.png)
 
@@ -159,123 +93,78 @@ precisely reflects the flow that Auth.js specifically is using.
 
 2. **The user clicks the "Sign in with GitHub" button.**
 
-3. **Your frontend makes a POST request to your backend** to
-   `http://my-app.example.com:5173/auth/signin/github`. This passes the control
-   flow to the backend, which computes sign-in options for the OAuth provider:
-   callback URL, scopes, etc.
+3. **Your frontend makes a POST request to your backend** to `http://my-app.example.com:5173/auth/signin/github`. This passes the control flow to the backend, which computes sign-in options for the OAuth provider: callback URL, scopes, etc.
 
-4. **Your backend makes a 302 redirect to GitHub** to:
-   `https://github.com/login/oauth/authorize`, passing a number of query params,
-   including:
+4. **Your backend makes a 302 redirect to GitHub** to: `https://github.com/login/oauth/authorize`, passing a number of query params, including:
 
    - `scope` of permissions to request;
    - `client_id` – the id of your app at GitHub;
    - `response_type=code` — the type of OAuth flow to use
-   - `redirect_uri=http://my-app.example.com:5173/auth/callback/github` – your
-     backend endpoint to redirect to.
+   - `redirect_uri=http://my-app.example.com:5173/auth/callback/github` – your backend endpoint to redirect to.
 
-5. **The user authenticates with GitHub** using email and password, if they
-   haven't already.
+5. **The user authenticates with GitHub** using email and password, if they haven't already.
 
-6. **The user authorizes your app to authenticate with GitHub**, if they haven't
-   already.  
-   Yeah, it's a bit of a
-   [Pimp My Ride](/assets/images/posts/2023-11-23-setting-up-oauth-with-auth-js-and-sveltekit/xzibit.jpg)
-   type of situation. 😅
+6. **The user authorizes your app to authenticate with GitHub**, if they haven't already.  
+   Yeah, it's a bit of a [Pimp My Ride](/assets/images/posts/2023-11-23-setting-up-oauth-with-auth-js-and-sveltekit/xzibit.jpg) type of situation. 😅
 
-7. **GitHub makes a 302 redirect to your backend** to
-   `http://my-app.example.com:5173/auth/callback`, passing a `code` query param
-   containing a temporary authorization code.
+7. **GitHub makes a 302 redirect to your backend** to `http://my-app.example.com:5173/auth/callback`, passing a `code` query param containing a temporary authorization code.
 
 8. Two things happen in parallel here:
 
    - The browser waits for your backend to respond.
-   - **The backend makes a direct request to GitHub**, passing the temporary
-     authorization code along with the app's id and secret codes. The browser is
-     not involved with this request.
+   - **The backend makes a direct request to GitHub**, passing the temporary authorization code along with the app's id and secret codes. The browser is not involved with this request.
 
-9. GitHub verifies the id and secret of your app, as well as the temporary
-   authorization code.  
+9. GitHub verifies the id and secret of your app, as well as the temporary authorization code.  
    **GitHub responds to your backend with an access token.**
-10. **Your backend responds to the broswer with a 302 redirect** to a page where
-    the user is supposed to land, e. g. `http://my-app.example.com:5173`.  
-    Here, the backend sets a secure HttpOnly cookie containing a session token
-    that your frontend will use to authorize requests to your backend.
+10. **Your backend responds to the broswer with a 302 redirect** to a page where the user is supposed to land, e. g. `http://my-app.example.com:5173`.  
+    Here, the backend sets a secure HttpOnly cookie containing a session token that your frontend will use to authorize requests to your backend.
 11. **Your frontend takes over** as the browser loads the page.  
     It can now use the cookie to authorize requests to your backend.  
     Requests to GitHub APIs are performed through your backend.
 
 The curious thing to note here is that the authorization code seems redundant.
 
-Normally, the authorization code is used as a measure to prevent the frontend
-from knowing the app secret and the access token.
+Normally, the authorization code is used as a measure to prevent the frontend from knowing the app secret and the access token.
 
-But the way Auth.js implements the flow, the OAuth provider never responds to
-the frontend, only to the backend. This means that steps 7 and 8 could
-hypothetically be skipped.
+But the way Auth.js implements the flow, the OAuth provider never responds to the frontend, only to the backend. This means that steps 7 and 8 could hypothetically be skipped.
 
-Why has OAuth implmented the flow with the authorization code? Many OAuth
-providers do not support the Implicit flow for web apps because it’s potentially
-unsafe and only offer the Authorization code flow, so that’s what Auth.js is
-doing.
+Why has OAuth implmented the flow with the authorization code? Many OAuth providers do not support the Implicit flow for web apps because it’s potentially unsafe and only offer the Authorization code flow, so that’s what Auth.js is doing.
 
 ## Gotcha 5: You Should “Create” a Separate “App” with each OAuth Provider for Every Deployment Environment
 
-In order to let your app authenticate with an OAuth provider, you must access
-the provider’s admin panel and “create an app” in it. This will provide you with
-an ID and secret token for your app to use.
+In order to let your app authenticate with an OAuth provider, you must access the provider’s admin panel and “create an app” in it. This will provide you with an ID and secret token for your app to use.
 
-Some OAuth providers let you define multiple webapp hostnames and callback URLs
-per app, but some important ones such as GitHub, only allow one hostname and one
-callback URL per app. For such providers, you need to “create” a separate “app”
-with the provider for each deployment environment, e.g., local development,
-staging and production. You will end up with three or more sets of app ids and
-secret tokens.
+Some OAuth providers let you define multiple webapp hostnames and callback URLs per app, but some important ones such as GitHub, only allow one hostname and one callback URL per app. For such providers, you need to “create” a separate “app” with the provider for each deployment environment, e.g., local development, staging and production. You will end up with three or more sets of app ids and secret tokens.
 
 ## Gotcha 6: you need a domain for local development
 
-When you run the SvelteKit server for local development, it offers you this url:
-`http://localhost:5173`.
+When you run the SvelteKit server for local development, it offers you this url: `http://localhost:5173`.
 
-The problem with it is that the `localhost` domain is not unique, and some OAuth
-providers will refuse to work with it.
+The problem with it is that the `localhost` domain is not unique, and some OAuth providers will refuse to work with it.
 
-On top of that, building more than one app on `http://localhost:5173` is an
-inconvenience, since cookies and localStorage entries mix up, forcing logouts
-and invalid state.
+On top of that, building more than one app on `http://localhost:5173` is an inconvenience, since cookies and localStorage entries mix up, forcing logouts and invalid state.
 
-For these two reasons, you should use a unique domain that points at `127.0.0.1`
-or `::1` (note that multiple domains can do so).
+For these two reasons, you should use a unique domain that points at `127.0.0.1` or `::1` (note that multiple domains can do so).
 
-You could use a subdomain of your business domain, such as `local.my-app.dev`,
-but there’s another problem with this.
+You could use a subdomain of your business domain, such as `local.my-app.dev`, but there’s another problem with this.
 
 ## Gotcha 7: Some OAuth Providers Refuse to Work with Unencrypted http
 
-The `http` protocol is inherently unsafe and some OAuth providers refuse to work
-with it.
+The `http` protocol is inherently unsafe and some OAuth providers refuse to work with it.
 
-That’s a problem because setting up `https` encryption certificates for _local
-development_ is a tedious hassle, as it requires either paying for certs, or
-using short-lived free ones.
+That’s a problem because setting up `https` encryption certificates for _local development_ is a tedious hassle, as it requires either paying for certs, or using short-lived free ones.
 
-There’s a loophole, though! Use a subdomain on the `example.com` domain, e. g.
-`my-app.example.com`.
+There’s a loophole, though! Use a subdomain on the `example.com` domain, e. g. `my-app.example.com`.
 
-Google, for example, refuses to work with `http://local.my-app.dev` because of
-insecure protocol, but makes an exception for `http://my-app.example.com`, as
-the `example.com` domain is dedicated for testing and development purposes and
-can’t harm any users.
+Google, for example, refuses to work with `http://local.my-app.dev` because of insecure protocol, but makes an exception for `http://my-app.example.com`, as the `example.com` domain is dedicated for testing and development purposes and can’t harm any users.
 
 Google, however, also rejects URLs on made-up top-level domains.
 
 ## How to Create a Subdomain on Example.com
 
-Of course, you can’t register a custom subdomain on the public `example.com`
-domain for everyone to resolve. But you can fake it for local development.
+Of course, you can’t register a custom subdomain on the public `example.com` domain for everyone to resolve. But you can fake it for local development.
 
-To do so, locate the system-wide `hosts` file in your operating system, open it
-for editing with superuser rights and append like this:
+To do so, locate the system-wide `hosts` file in your operating system, open it for editing with superuser rights and append like this:
 
 ```
 {% raw %}127.0.0.1 my-app.example.com
@@ -284,50 +173,33 @@ for editing with superuser rights and append like this:
 
 Changes should become effective immediately on save — on your machine only.
 
-See the externals links section in this
-[Wikipedia article](<https://en.wikipedia.org/wiki/Hosts_(file)>) for detailed
-instructions.
+See the externals links section in this [Wikipedia article](<https://en.wikipedia.org/wiki/Hosts_(file)>) for detailed instructions.
 
 ## Configuring GitHub
 
-1. Visit
-   [https://github.com/settings/developers](https://github.com/settings/developers)
-   and click `New OAuth app`.
+1. Visit [https://github.com/settings/developers](https://github.com/settings/developers) and click `New OAuth app`.
 2. Fill in the form, using the following URLs:
    - Application name: `My App (dev)`
-   - Homepage URL:
-     [http://my-app.example.com:5173](http://fox-and-hound-dev.local:5173/)
-   - Authorization callback URL:
-     [http://my-app.example.com:5173/auth/callback/github](http://fox-and-hound-dev.local:5173/auth/callback/github)
+   - Homepage URL: [http://my-app.example.com:5173](http://fox-and-hound-dev.local:5173/)
+   - Authorization callback URL: [http://my-app.example.com:5173/auth/callback/github](http://fox-and-hound-dev.local:5173/auth/callback/github)
 3. On the next screen, copy the `Client ID` to your password manager.
-4. Click `Generate a new client secret`. Copy the resulting secret token to your
-   password manager. GitHub will not let you see it again!
+4. Click `Generate a new client secret`. Copy the resulting secret token to your password manager. GitHub will not let you see it again!
 
-Reference documentation for Auth.js GitHub Provider:
-[https://authjs.dev/reference/core/providers_github](https://authjs.dev/reference/core/providers_github)
+Reference documentation for Auth.js GitHub Provider: [https://authjs.dev/reference/core/providers_github](https://authjs.dev/reference/core/providers_github)
 
 ## Configuring Google
 
 1. Visit [https://console.cloud.google.com/](https://console.cloud.google.com/).
-2. In the top-left corner of the page, expand the list of projects and click
-   `New project`. Type `My App (dev)` and click `Create`.
-3. On the `Credentials` tab, click `Create credentials` → `OAuth Client ID`.
-   Then Select `Web application`.
-4. Visit `APIs and Services` → `OAuth Consent Screen`
-   [https://console.cloud.google.com/apis/credentials/consent](https://console.cloud.google.com/apis/credentials/consent)
-   and change the `Publishing status` of your app to `Testing`.
-5. Visit `APIs and Services` → `Credentials`
-   [https://console.cloud.google.com/apis/credentials](https://console.cloud.google.com/apis/credentials)
-6. Click `Add URI` for `Authorized Javascript Origins`, use this value:
-   [http://my-app.example.com:5173](http://fox-and-hound.example.com:5173/)
-7. Click `Add URI` for `Authorized redirect URIs`, use this value:
-   [http://my-app.example.com:5173/auth/callback/google](http://my-app.example.com:5173/auth/callback/google)
-8. Copy `Client ID` and `Client Secret` from the right sidebar to your password
-   manager. If no `Client Secret` exists, create one.
+2. In the top-left corner of the page, expand the list of projects and click `New project`. Type `My App (dev)` and click `Create`.
+3. On the `Credentials` tab, click `Create credentials` → `OAuth Client ID`. Then Select `Web application`.
+4. Visit `APIs and Services` → `OAuth Consent Screen` [https://console.cloud.google.com/apis/credentials/consent](https://console.cloud.google.com/apis/credentials/consent) and change the `Publishing status` of your app to `Testing`.
+5. Visit `APIs and Services` → `Credentials` [https://console.cloud.google.com/apis/credentials](https://console.cloud.google.com/apis/credentials)
+6. Click `Add URI` for `Authorized Javascript Origins`, use this value: [http://my-app.example.com:5173](http://fox-and-hound.example.com:5173/)
+7. Click `Add URI` for `Authorized redirect URIs`, use this value: [http://my-app.example.com:5173/auth/callback/google](http://my-app.example.com:5173/auth/callback/google)
+8. Copy `Client ID` and `Client Secret` from the right sidebar to your password manager. If no `Client Secret` exists, create one.
 9. Save.
 
-Reference documentation for Auth.js Google Provider:
-[https://authjs.dev/reference/core/providers_github](https://authjs.dev/reference/core/providers_github)
+Reference documentation for Auth.js Google Provider: [https://authjs.dev/reference/core/providers_github](https://authjs.dev/reference/core/providers_github)
 
 ## Configuring SvelteKit
 
@@ -344,8 +216,7 @@ npm i
 {% endraw %}
 ```
 
-I’ll be using `my-app` as the name of the project and the subdomain. Substitute
-it for your app’s name.
+I’ll be using `my-app` as the name of the project and the subdomain. Substitute it for your app’s name.
 
 ### 1. Install Auth.js
 
@@ -368,22 +239,14 @@ GOOGLE_SECRET="5E17CA-3250e5657D80d848eAa65954822C"
 {% endraw %}
 ```
 
-- `AUTH_SECRET` should be a random string. It’s used to encrypt tokens exchanged
-  between your frontend and your backend. Sadly, it’s not used to encrypt the
-  OAuth access token, since an OAuth provider should be able to read its
-  unencrypted value. It should be at least 32 alphanumeric characters long, the
-  longer the better. You can generate a random string with this console command:
+- `AUTH_SECRET` should be a random string. It’s used to encrypt tokens exchanged between your frontend and your backend. Sadly, it’s not used to encrypt the OAuth access token, since an OAuth provider should be able to read its unencrypted value. It should be at least 32 alphanumeric characters long, the longer the better. You can generate a random string with this console command:
   ```bash
   openssl rand -base64 32
   ```
-  If you don’t have `openssl`, you can generate a random string online
-  [here](https://generate-secret.vercel.app/32). That’s theoretically unsafe,
-  but should be fine for pet projects.
-- `AUTH_TRUST_HOST` must be `true` for all enviromnents except Vercel
-  deployments.
+  If you don’t have `openssl`, you can generate a random string online [here](https://generate-secret.vercel.app/32). That’s theoretically unsafe, but should be fine for pet projects.
+- `AUTH_TRUST_HOST` must be `true` for all enviromnents except Vercel deployments.
 - `GITHUB_ID` — the id of your “app” on GitHub.
-- `GITHUB_SECRET` — the secret token of your app on GitHub. Note that GitHub
-  will only show it once! Don’t lose it, or you’ll have to regenerate it.
+- `GITHUB_SECRET` — the secret token of your app on GitHub. Note that GitHub will only show it once! Don’t lose it, or you’ll have to regenerate it.
 - `GOOGLE_ID` — the id of your “app” on Google.
 - `GOOGLE_SECRET` — the secret token of your app on Google.
 
@@ -406,14 +269,9 @@ export const handle = SvelteKitAuth({
 {% endraw %}
 ```
 
-VS Code with the official Svelte
-[extension](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode)
-installed will automatically recognize the existence of `$env` imports when you
-start the SvelteKit dev server with `npm run dev`.
+VS Code with the official Svelte [extension](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode) installed will automatically recognize the existence of `$env` imports when you start the SvelteKit dev server with `npm run dev`.
 
-If you already have a `handle` hook, you should use the
-[sequence](https://kit.svelte.dev/docs/modules#sveltejs-kit-hooks-sequence)
-function to combine two hooks into one.
+If you already have a `handle` hook, you should use the [sequence](https://kit.svelte.dev/docs/modules#sveltejs-kit-hooks-sequence) function to combine two hooks into one.
 
 ### 4. Load the Session from Your Backend
 
@@ -473,8 +331,7 @@ Add the `{:else}` clause to `{% raw %}{#if $page.data.session}{% endraw %}`:
 {/if} {% endraw %}
 ```
 
-Note that `/auth/signin` is a route automatically generated by
-`@auth/sveltekit`. You don’t need to define it.
+Note that `/auth/signin` is a route automatically generated by `@auth/sveltekit`. You don’t need to define it.
 
 ### 7. Protect a Route from Anonymous Access
 
@@ -503,10 +360,7 @@ Any page such as `src/routes/protected/+page.svelte`:
 {/if} {% endraw %}
 ```
 
-Alternatively, you can redirect from a `+layout.js`, which arguably provides
-better access management. See
-[this StackOverflow question](https://stackoverflow.com/q/74017730/901944) for
-possible ways to do it.
+Alternatively, you can redirect from a `+layout.js`, which arguably provides better access management. See [this StackOverflow question](https://stackoverflow.com/q/74017730/901944) for possible ways to do it.
 
 ### 9. You Rock!
 
@@ -521,22 +375,17 @@ Note that routes under `/auth` such as:
 - `/auth/callback/[provider]`
 - `/auth/signin`
 
-…are routes automatically generated by `@auth/sveltekit`. You don’t need to
-define them.
+…are routes automatically generated by `@auth/sveltekit`. You don’t need to define them.
 
 The former is a backend route where OAuth providers should redirect the user to.
 
-The latter is a frontend route containing sign-in buttons for OAuth providers of
-your choice. The HTML/CSS of buttons will be generated for you by the package.
+The latter is a frontend route containing sign-in buttons for OAuth providers of your choice. The HTML/CSS of buttons will be generated for you by the package.
 
 ## Gotcha 9: Auth.js Is Evolving
 
-As of 2023, the library is relatively new. Its core is more or less stable, but
-its SvelteKit integration claims to be under active development.
+As of 2023, the library is relatively new. Its core is more or less stable, but its SvelteKit integration claims to be under active development.
 
-The implication is that it may receive breaking changes. In order to upgrade to
-future versions you will need to follow the upgrade guide or release notes to
-rewrite some of your code accordingly.
+The implication is that it may receive breaking changes. In order to upgrade to future versions you will need to follow the upgrade guide or release notes to rewrite some of your code accordingly.
 
 Keep that in mind.
 
@@ -544,15 +393,12 @@ Keep that in mind.
 
 `@auth/sveltekit` has an official demo app:
 
-- Live:
-  [https://sveltekit-auth-example.vercel.app](https://sveltekit-auth-example.vercel.app/)
-- Source:
-  [https://github.com/nextauthjs/sveltekit-auth-example](https://github.com/nextauthjs/sveltekit-auth-example)
+- Live: [https://sveltekit-auth-example.vercel.app](https://sveltekit-auth-example.vercel.app/)
+- Source: [https://github.com/nextauthjs/sveltekit-auth-example](https://github.com/nextauthjs/sveltekit-auth-example)
 
 ## Next Steps
 
-The goal of this article is to help you connect all the parts together to
-bootstrap your OAuth adventure.
+The goal of this article is to help you connect all the parts together to bootstrap your OAuth adventure.
 
 Some of aspects not covered are:
 
diff --git a/src/posts/2023-11-28-sveltekit-storybook.md b/src/posts/2023-11-28-sveltekit-storybook.md
index db576aa0d0..df6e84a3b6 100644
--- a/src/posts/2023-11-28-sveltekit-storybook.md
+++ b/src/posts/2023-11-28-sveltekit-storybook.md
@@ -3,9 +3,7 @@ title: "SvelteKit 🤝 Storybook"
 authorHandle: paoloricciuti
 tags: [svelte, storybook]
 bio: "Paolo Ricciuti, Senior Software Engineer"
-description:
-  "Paolo Ricciuti (paoloricciuti) shows the newest addition to Storybook that
-  allows for a tighter integration between Storybook and SvelteKit"
+description: "Paolo Ricciuti (paoloricciuti) shows the newest addition to Storybook that allows for a tighter integration between Storybook and SvelteKit"
 og:
   image: /assets/images/posts/2023-11-28-sveltekit-storybook/og-image.jpg
 tagline: |
@@ -17,65 +15,31 @@ imageAlt: "The Svelte logo on a gray backround picture"
 
 # Storybook 🤝 SvelteKit
 
-Here at Mainmatter we're fans of SvelteKit and use it to build ambitious
-projects with the teams we work with. Storybook was the obvious choice to make
-the onboarding for new devs seamless and allow all project stakeholders to
-follow the development of the internal design system. There was just a small
-problem...
+Here at Mainmatter we're fans of SvelteKit and use it to build ambitious projects with the teams we work with. Storybook was the obvious choice to make the onboarding for new devs seamless and allow all project stakeholders to follow the development of the internal design system. There was just a small problem...
 
 ## The Problem
 
-Storybook has a wonderful Story (pun intended) with Svelte, but the integration
-with SvelteKit was a bit more challenging. SvelteKit is a full-stack framework
-and provides a lot of virtual exports that give your application the needed
-information about its current state. An example of this is the `page` store. It
-gives you information about the route you are on, the data you returned from the
-server, etc.
+Storybook has a wonderful Story (pun intended) with Svelte, but the integration with SvelteKit was a bit more challenging. SvelteKit is a full-stack framework and provides a lot of virtual exports that give your application the needed information about its current state. An example of this is the `page` store. It gives you information about the route you are on, the data you returned from the server, etc.
 
-But when your component is showcased in Storybook it doesn't actually run in
-SvelteKit, which means that the `page` store is empty.
+But when your component is showcased in Storybook it doesn't actually run in SvelteKit, which means that the `page` store is empty.
 
-Granted that using SvelteKit-specific stores inside components is generally
-considered a bad practice (you could just pass the store value as a prop),
-sometimes it is just tedious having to pass a prop every time. For example, if
-you are dealing with i18n, you can return the detected locale from the root
-layout so that every page has access to it. Can you imagine having to pass the
-locale prop to every component when you could just use `$page.data.locale`?
+Granted that using SvelteKit-specific stores inside components is generally considered a bad practice (you could just pass the store value as a prop), sometimes it is just tedious having to pass a prop every time. For example, if you are dealing with i18n, you can return the detected locale from the root layout so that every page has access to it. Can you imagine having to pass the locale prop to every component when you could just use `$page.data.locale`?
 
 ## The Solution
 
-Luckily for us, SvelteKit is just a Vite plugin and Storybook allows you to add
-any Vite plugins to the default ones. Writing a Vite is not that complex, and to
-make this work we just need to override the `alias` config of Vite to point
-every import from `$app/stores` to a file that exports the same functions and
-stores. This way, if you are running your component in a SvelteKit application,
-Svelte will provide those stores, if you run your component in Storybook, the
-file you specify in the `alias` will provide them.
+Luckily for us, SvelteKit is just a Vite plugin and Storybook allows you to add any Vite plugins to the default ones. Writing a Vite is not that complex, and to make this work we just need to override the `alias` config of Vite to point every import from `$app/stores` to a file that exports the same functions and stores. This way, if you are running your component in a SvelteKit application, Svelte will provide those stores, if you run your component in Storybook, the file you specify in the `alias` will provide them.
 
 ## Unveiling `parameters.sveltekit_experimental`
 
-As we've seen, it's possible to mimic the SvelteKit behavior in user-land. But
-if you have to write all of this code every time you want to use Storybook in
-your SvelteKit application, wouldn't it be better to have this provided by
-Storybook itself? That was exactly my thought. At Mainmatter we love to give
-back to the open source that we use every day and we even have a whole day every
-week to work on open source projects. So I got in touch with
-[JReinhold](https://github.com/JReinhold) and after a quick chat, we decided
-that this was a good addition for the `@storybook/sveltekit` and I got to work.
+As we've seen, it's possible to mimic the SvelteKit behavior in user-land. But if you have to write all of this code every time you want to use Storybook in your SvelteKit application, wouldn't it be better to have this provided by Storybook itself? That was exactly my thought. At Mainmatter we love to give back to the open source that we use every day and we even have a whole day every week to work on open source projects. So I got in touch with [JReinhold](https://github.com/JReinhold) and after a quick chat, we decided that this was a good addition for the `@storybook/sveltekit` and I got to work.
 
-As of Storybook v7.6, if you are using the SvelteKit integration, you can now
-specify a new set of parameters for each Story that will allow you to control
-the values of those exports. Let's explore how to use this new feature and what
-benefits it brings to the table.
+As of Storybook v7.6, if you are using the SvelteKit integration, you can now specify a new set of parameters for each Story that will allow you to control the values of those exports. Let's explore how to use this new feature and what benefits it brings to the table.
 
-P.s. here's the
-[link to the PR](https://github.com/storybookjs/storybook/pull/24795) if you are
-curious on how all of this was implemented.
+P.s. here's the [link to the PR](https://github.com/storybookjs/storybook/pull/24795) if you are curious on how all of this was implemented.
 
 ### How to Use It
 
-As you may know, in Storybook you can export the default value from
-`Button.stories.ts` like this:
+As you may know, in Storybook you can export the default value from `Button.stories.ts` like this:
 
 ```ts
 const meta = {
@@ -102,11 +66,7 @@ export const Primary: Story = {
 };
 ```
 
-Each one of these objects has a `parameters` property that is usually used by
-various addons and plugin to customize their behavior. On this object, you can
-add a `sveltekit_experimental` property to use this new feature (yes, it's
-experimental in v7.6 it will probably be out of experimental by v8 which should
-also introduce support for Svelte 5). Let's see how it looks:
+Each one of these objects has a `parameters` property that is usually used by various addons and plugin to customize their behavior. On this object, you can add a `sveltekit_experimental` property to use this new feature (yes, it's experimental in v7.6 it will probably be out of experimental by v8 which should also introduce support for Svelte 5). Let's see how it looks:
 
 ```ts
 export const Primary: Story = {
@@ -144,20 +104,13 @@ export const Primary: Story = {
 };
 ```
 
-well...this was a lot of information packed into a small snippet of code. The
-gist of it is that you have three properties, one for every module exported from
-`$app` plus an `href` property. So, for example, to customize the behavior of
-the `page` store exported from `$app/stores`, you can set
-`sveltekit_experimental.stores.page`, or to customize the behavior of the `goto`
-function exported from `$app/navigation`, you can set
-`sveltekit_experimental.navigation.goto`.
+well...this was a lot of information packed into a small snippet of code. The gist of it is that you have three properties, one for every module exported from `$app` plus an `href` property. So, for example, to customize the behavior of the `page` store exported from `$app/stores`, you can set `sveltekit_experimental.stores.page`, or to customize the behavior of the `goto` function exported from `$app/navigation`, you can set `sveltekit_experimental.navigation.goto`.
 
 Let's see what you can customize.
 
 ### `stores.page`
 
-The object you assign to this property will be the value of the `page` store.
-You are free to assign only a partial (what you need in the story)
+The object you assign to this property will be the value of the `page` store. You are free to assign only a partial (what you need in the story)
 
 ```ts
 export const Primary: Story = {
@@ -181,8 +134,7 @@ export const Primary: Story = {
 
 ### `stores.navigating`
 
-The object you assign to this property will be the value of the `navigating`
-store. You are free to assign only a partial (what you need in the story).
+The object you assign to this property will be the value of the `navigating` store. You are free to assign only a partial (what you need in the story).
 
 ```ts
 export const Primary: Story = {
@@ -208,8 +160,7 @@ export const Primary: Story = {
 
 ### `stores.update`
 
-The object you assign to this property will be the value of the `update` store.
-The value of the store is a boolean.
+The object you assign to this property will be the value of the `update` store. The value of the store is a boolean.
 
 ```ts
 export const Primary: Story = {
@@ -229,10 +180,7 @@ export const Primary: Story = {
 
 ### `navigation.goto`
 
-The function you assign to this property will be called whenever the Story you
-are rendering calls `goto`. You will receive the same parameters passed to the
-`goto` function by the component. If you don't pass any function to this,
-Storybook will log an action in the actions panel.
+The function you assign to this property will be called whenever the Story you are rendering calls `goto`. You will receive the same parameters passed to the `goto` function by the component. If you don't pass any function to this, Storybook will log an action in the actions panel.
 
 ```ts
 export const Primary: Story = {
@@ -254,10 +202,7 @@ export const Primary: Story = {
 
 ### `navigation.invalidate`
 
-The function you assign to this property will be called whenever the Story you
-are rendering calls `invalidate`. You will receive the same parameters passed to
-the `invalidate` function by the component. If you don't pass any function to
-this, Storybook will log an action in the actions panel.
+The function you assign to this property will be called whenever the Story you are rendering calls `invalidate`. You will receive the same parameters passed to the `invalidate` function by the component. If you don't pass any function to this, Storybook will log an action in the actions panel.
 
 ```ts
 export const Primary: Story = {
@@ -279,9 +224,7 @@ export const Primary: Story = {
 
 ### `navigation.invalidateAll`
 
-The function you assign to this property will be called whenever the Story you
-are rendering calls `invalidateAll`. If you don't pass any function to this,
-Storybook will log an action in the actions panel.
+The function you assign to this property will be called whenever the Story you are rendering calls `invalidateAll`. If you don't pass any function to this, Storybook will log an action in the actions panel.
 
 ```ts
 export const Primary: Story = {
@@ -303,12 +246,7 @@ export const Primary: Story = {
 
 ### `navigation.afterNavigate`
 
-Generally, `afterNavigate` is called by SvelteKit after each navigation. This
-doesn't really make sense in Storybook since there's no router involved.
-Instead, if you call `afterNavigate` in your component, the function you passed
-as a parameter will be called on mount. The function you pass takes the
-information about the navigation as an argument and you can specify that
-argument using `navigation.afterNavigate` (you may also pass a partial).
+Generally, `afterNavigate` is called by SvelteKit after each navigation. This doesn't really make sense in Storybook since there's no router involved. Instead, if you call `afterNavigate` in your component, the function you passed as a parameter will be called on mount. The function you pass takes the information about the navigation as an argument and you can specify that argument using `navigation.afterNavigate` (you may also pass a partial).
 
 ```ts
 export const Primary: Story = {
@@ -334,9 +272,7 @@ export const Primary: Story = {
 
 ### `forms.enhance`
 
-If you are using the `enhance` action on a form when inside Storybook, the form
-submission will still be prevented and the function you assign to
-`forms.enhance` will be called.
+If you are using the `enhance` action on a form when inside Storybook, the form submission will still be prevented and the function you assign to `forms.enhance` will be called.
 
 ```ts
 export const Primary: Story = {
@@ -358,20 +294,8 @@ export const Primary: Story = {
 
 ### `hrefs`
 
-By default, every link will log an action to the Actions panel, but if you want
-you can pass another property to the `sveltekit_experimental` parameter. `hrefs`
-is an object where every key is a string that should represent a link inside
-your Story, and the value is typed as such:
-`{ callback: () => void, asRegex?: boolean }`. As you might have guessed, the
-`callback` function will be called whenever the user clicks on an `A` tag that
-has a `href` equal to the key. If you specified `asRegex` as true, the function
-will be called whenever your regular expression matches the `href` attribute of
-the tag.
+By default, every link will log an action to the Actions panel, but if you want you can pass another property to the `sveltekit_experimental` parameter. `hrefs` is an object where every key is a string that should represent a link inside your Story, and the value is typed as such: `{ callback: () => void, asRegex?: boolean }`. As you might have guessed, the `callback` function will be called whenever the user clicks on an `A` tag that has a `href` equal to the key. If you specified `asRegex` as true, the function will be called whenever your regular expression matches the `href` attribute of the tag.
 
 ## Conclusions
 
-And that was it: this was a brief introduction to the new features, and I'm sure
-you will find crazy ways to use those functionalities. I'm so happy to have been
-able to contribute to such a pivotal project, and more so to be able to use
-those features myself! Also, I want to thank Jeppe for helping me become
-familiar with this huge codebase.
+And that was it: this was a brief introduction to the new features, and I'm sure you will find crazy ways to use those functionalities. I'm so happy to have been able to contribute to such a pivotal project, and more so to be able to use those features myself! Also, I want to thank Jeppe for helping me become familiar with this huge codebase.
diff --git a/src/posts/2023-12-13-rust-adoption-playbook-for-ctos-and-engineering-managers.md b/src/posts/2023-12-13-rust-adoption-playbook-for-ctos-and-engineering-managers.md
index 9a86af256e..75806e6dd5 100644
--- a/src/posts/2023-12-13-rust-adoption-playbook-for-ctos-and-engineering-managers.md
+++ b/src/posts/2023-12-13-rust-adoption-playbook-for-ctos-and-engineering-managers.md
@@ -3,10 +3,7 @@ title: "Adopting Rust: the missing playbook for managers and CTOs"
 authorHandle: algo_luca
 tags: [rust]
 bio: "Luca Palmieri, Principal Engineering Consultant"
-description:
-  "You want to kick off your first Rust project. How do you make it a success?
-  Here is a playbook for building your first Rust team and, if all goes well,
-  scaling it up."
+description: "You want to kick off your first Rust project. How do you make it a success? Here is a playbook for building your first Rust team and, if all goes well, scaling it up."
 tagline: |
   <p>
    You want to kick off your first Rust project. How do you make it a success?
@@ -19,16 +16,12 @@ image: "/assets/images/posts/2023-12-13-adopting-rust/header.png"
 imageAlt: "The Rust logo on top of a street map"
 ---
 
-If you look for "Rust adoption" in your favorite search engine, most of the
-content you'll find falls into one of two categories:
+If you look for "Rust adoption" in your favorite search engine, most of the content you'll find falls into one of two categories:
 
-- How to convince your organization to adopt Rust, usually from the point of
-  view of an individual contributor acting as a Rust advocate
+- How to convince your organization to adopt Rust, usually from the point of view of an individual contributor acting as a Rust advocate
 - Survey data on Rust adoption
 
-We feel there's a missing playbook: you are in charge of an engineering
-organization/unit, and you have determined that Rust is a good technology to bet
-on. How do you turn that bet into a success?
+We feel there's a missing playbook: you are in charge of an engineering organization/unit, and you have determined that Rust is a good technology to bet on. How do you turn that bet into a success?
 
 This article is our attempt at filling that gap.
 
@@ -53,206 +46,115 @@ This article is our attempt at filling that gap.
 
 ## Building a team for your first Rust project
 
-You have a meaningful project in mind, and you are considering using Rust for
-it. It's time to build a team!
+You have a meaningful project in mind, and you are considering using Rust for it. It's time to build a team!
 
 ### Should you hire?
 
 We recommend **not to hire additional staff for your first Rust project**.  
-If you go on the job market looking for production Rust expertise, you'll be
-competing with the entire industry for a very limited pool of candidates. It may
-take you months to find and onboard the right people: can your budget and
-project timeline afford that?
+If you go on the job market looking for production Rust expertise, you'll be competing with the entire industry for a very limited pool of candidates. It may take you months to find and onboard the right people: can your budget and project timeline afford that?
 
-Furthermore, it's dangerous to bring people on board for a "Rust job": the
-technology might not be a good fit for your organization in the end. You don't
-want to end up with a team of frustrated Rust experts with no projects to work
-on: it's not going to be a great experience for anyone involved.
+Furthermore, it's dangerous to bring people on board for a "Rust job": the technology might not be a good fit for your organization in the end. You don't want to end up with a team of frustrated Rust experts with no projects to work on: it's not going to be a great experience for anyone involved.
 
 ### Assess the readiness of your existing team
 
-Unless you are a tiny startup, you already have a team that has been working
-with other technologies up until now. Can they be productive with Rust? How long
-will it take them to get up to speed?
+Unless you are a tiny startup, you already have a team that has been working with other technologies up until now. Can they be productive with Rust? How long will it take them to get up to speed?
 
 Assessing their readiness is a key step in determining how to move forward.
 
 #### Previous experience with Rust
 
-First and foremost: look out for the hidden Rust experts in your team. They
-might be using Rust in their spare time, or they might have been using it in
-previous jobs. They can be an invaluable asset for the rest of your team, and
-you should make sure they are involved in the project from the beginning.
+First and foremost: look out for the hidden Rust experts in your team. They might be using Rust in their spare time, or they might have been using it in previous jobs. They can be an invaluable asset for the rest of your team, and you should make sure they are involved in the project from the beginning.
 
-Be careful though: staffing your entire project with Rust experts might not be a
-great idea in the long run. You want to make sure that the codebase is
-accessible to people with less experience with Rust, and that the knowledge is
-shared across the team: that's going to happen organically if you add a few Rust
-novices to the mix.
+Be careful though: staffing your entire project with Rust experts might not be a great idea in the long run. You want to make sure that the codebase is accessible to people with less experience with Rust, and that the knowledge is shared across the team: that's going to happen organically if you add a few Rust novices to the mix.
 
 #### Language proximity
 
-You might not have a hidden Rust expert in your team, but there might be others
-with experience in languages that are close enough to Rust to allow them to
-reach productivity quickly.  
-C and C++ are obvious candidates, but don't discount functional languages: there
-is more than memory management to Rust's learning curve! Having to manage
-nullability (`Option`) and failures (`Result`) as types is a paradigm shift:
-previous experience with functional languages can smooth the transition
-significantly.
+You might not have a hidden Rust expert in your team, but there might be others with experience in languages that are close enough to Rust to allow them to reach productivity quickly.  
+C and C++ are obvious candidates, but don't discount functional languages: there is more than memory management to Rust's learning curve! Having to manage nullability (`Option`) and failures (`Result`) as types is a paradigm shift: previous experience with functional languages can smooth the transition significantly.
 
 #### Willingness to learn
 
-We like to joke about developers spending most of their time chasing the "next
-shiny thing", but don't take that attitude for granted. Is your team excited
-about the prospect of learning a new language? Are they willing to go through
-the discomfort of being a beginner again?
+We like to joke about developers spending most of their time chasing the "next shiny thing", but don't take that attitude for granted. Is your team excited about the prospect of learning a new language? Are they willing to go through the discomfort of being a beginner again?
 
-Don't assume "yes" as the answer. Talk to your team, and make sure that they are
-on board with the idea.  
-This will become less of a factor once you have one or two successful Rust
-projects under your belt, with a mature infrastructure and established code
-practices, but it's a key aspect to keep in mind for your very first project.
+Don't assume "yes" as the answer. Talk to your team, and make sure that they are on board with the idea.  
+This will become less of a factor once you have one or two successful Rust projects under your belt, with a mature infrastructure and established code practices, but it's a key aspect to keep in mind for your very first project.
 
 ### Upskilling your team
 
-_If you found enough Rust experts in your existing organization to staff your
-team, you can skip this section._
+_If you found enough Rust experts in your existing organization to staff your team, you can skip this section._
 
-We'll assume the most common scenario: you have one or two people in your team
-who have played with Rust in their spare time, building a few toy projects, but
-nobody with production experience.  
+We'll assume the most common scenario: you have one or two people in your team who have played with Rust in their spare time, building a few toy projects, but nobody with production experience.  
 How do you get them up to speed?
 
 #### Self-guided learning
 
 There are a lot of great resources out there to learn Rust at your own pace.  
-We recommend a mix of books and hands-on exercises: you can end up spending a
-lot of time reading about Rust, convincing yourself that you are "getting it",
-just to end up with a blank page when you try to write the first non-trivial
-program on your own.
+We recommend a mix of books and hands-on exercises: you can end up spending a lot of time reading about Rust, convincing yourself that you are "getting it", just to end up with a blank page when you try to write the first non-trivial program on your own.
 
-We have collected a vetted list of resources in the
-[Appendix](#appendix:-learning-resources).
+We have collected a vetted list of resources in the [Appendix](#appendix:-learning-resources).
 
 #### Training
 
 Self-learning can play out beautifully, but it may take a while.  
-If you don't have the luxury of time, you can speed up the learning process by
-finding external mentors for your team.
+If you don't have the luxury of time, you can speed up the learning process by finding external mentors for your team.
 
 Workshops are the most common solution.  
-If you have a large team, you can bring in a trainer to run a dedicated
-workshop. If the team is small, you can buy tickets to join a public workshop
-alongside developers from other companies.
+If you have a large team, you can bring in a trainer to run a dedicated workshop. If the team is small, you can buy tickets to join a public workshop alongside developers from other companies.
 
-Interactivity is the key here: you want to make sure that your team has the
-opportunity to ask questions to an experienced Rust mentor to speed up the
-learning process and avoid common pitfalls.
+Interactivity is the key here: you want to make sure that your team has the opportunity to ask questions to an experienced Rust mentor to speed up the learning process and avoid common pitfalls.
 
-To get a sense of what kind of topics a Rust workshop could cover, you can check
-out the [Rust workshops](/services/workshops/rust/) that we offer here at
-Mainmatter.
+To get a sense of what kind of topics a Rust workshop could cover, you can check out the [Rust workshops](/services/workshops/rust/) that we offer here at Mainmatter.
 
 #### Team reinforcement
 
-If the project is important enough, you might want to consider augmenting your
-team with one or two experienced Rust consultants. Embed them in your team:
-they'll be working alongside your engineers, helping them get up to speed,
-steering the project away from common pitfalls, and make sure that the codebase
-is built on solid foundations.
+If the project is important enough, you might want to consider augmenting your team with one or two experienced Rust consultants. Embed them in your team: they'll be working alongside your engineers, helping them get up to speed, steering the project away from common pitfalls, and make sure that the codebase is built on solid foundations.
 
-It allows you to compress the timeline significantly: you can start delivering
-value _while_ your team is learning Rust.
+It allows you to compress the timeline significantly: you can start delivering value _while_ your team is learning Rust.
 
 #### Code audits
 
-If budget is tight, you can consider a code audit as a cheaper alternative to
-Team reinforcement: you hire a consultant for a limited amount of time (e.g. a
-few days) to review your codebase.  
-At the end of the process, you get a report: critical issues that need to be
-addressed urgently, recommendations on how to improve the codebase, and a list
-of best practices that you might want to follow going forward. It becomes a
-technical roadmap that your team can integrate into their future planning.
+If budget is tight, you can consider a code audit as a cheaper alternative to Team reinforcement: you hire a consultant for a limited amount of time (e.g. a few days) to review your codebase.  
+At the end of the process, you get a report: critical issues that need to be addressed urgently, recommendations on how to improve the codebase, and a list of best practices that you might want to follow going forward. It becomes a technical roadmap that your team can integrate into their future planning.
 
-Alternatively, you can engage with a consultant _before_ starting the project:
-they can help you with the initial design and architecture, putting you on the
-right track. They can then pop in again, at regular intervals, to assess the
-situation and provide guidance if the plan needs to be adjusted.
+Alternatively, you can engage with a consultant _before_ starting the project: they can help you with the initial design and architecture, putting you on the right track. They can then pop in again, at regular intervals, to assess the situation and provide guidance if the plan needs to be adjusted.
 
 ## Scaling up your team
 
-Congrats! You've completed your first Rust project: business is thriving, and
-you need to scale up your team to keep up with the demand.  
-If the demand spike is transient, you can hire contractors to help you out. If
-you expect the demand to be long-term, it's time to start hiring.
+Congrats! You've completed your first Rust project: business is thriving, and you need to scale up your team to keep up with the demand.  
+If the demand spike is transient, you can hire contractors to help you out. If you expect the demand to be long-term, it's time to start hiring.
 
 ### The state of the Rust job market
 
-Hiring for Rust positions is **easy**, but attracting talent with Rust
-production experience is **hard**.  
-The language is fairly young and industry adoption has only picked up in the
-last few years, so there are few developers with Rust production horror stories
-to tell.  
-On the other hand, developers are excited about Rust: there are a lot of
-engineers willing to learn it if you can train them; they often won't be
-starting from scratch, having played with Rust in their spare time.
+Hiring for Rust positions is **easy**, but attracting talent with Rust production experience is **hard**.  
+The language is fairly young and industry adoption has only picked up in the last few years, so there are few developers with Rust production horror stories to tell.  
+On the other hand, developers are excited about Rust: there are a lot of engineers willing to learn it if you can train them; they often won't be starting from scratch, having played with Rust in their spare time.
 
-All the experience you've accumulated upskilling the team for your first project
-will come in handy here: you'll just need to repeat the process on a larger
-scale.
+All the experience you've accumulated upskilling the team for your first project will come in handy here: you'll just need to repeat the process on a larger scale.
 
 ### Job boards
 
-On top of the usual job boards, it pays off to advertise your open positions on
-Rust-specific channels. We recommend the following:
+On top of the usual job boards, it pays off to advertise your open positions on Rust-specific channels. We recommend the following:
 
-- Every six weeks, there is a Rust jobs thread on
-  [/r/rust](https://www.reddit.com/r/rust/). It's a great place to advertise
-  your open positions! Go
-  [here](https://www.reddit.com/r/rust/comments/163w6fl/official_rrust_whos_hiring_thread_for_jobseekers/)
-  for the latest thread at the time of writing.
-- Rust-focused events are a great place to find Rust developers. You can find a
-  list of upcoming events, covering both conferences and meetups, on
-  [This week in Rust](https://this-week-in-rust.org/).
+- Every six weeks, there is a Rust jobs thread on [/r/rust](https://www.reddit.com/r/rust/). It's a great place to advertise your open positions! Go [here](https://www.reddit.com/r/rust/comments/163w6fl/official_rrust_whos_hiring_thread_for_jobseekers/) for the latest thread at the time of writing.
+- Rust-focused events are a great place to find Rust developers. You can find a list of upcoming events, covering both conferences and meetups, on [This week in Rust](https://this-week-in-rust.org/).
 
-There are also recruiting agencies who are starting to specialize in Rust. We
-don't have any specific recommendation at this point, but it might be worth
-doing your research.
+There are also recruiting agencies who are starting to specialize in Rust. We don't have any specific recommendation at this point, but it might be worth doing your research.
 
 ## Wrapping up
 
-We've covered a lot of ground in this article, but we hope we've given you a
-good starting point for your Rust journey. If you have any questions, or if
-you'd like help with any of the topics covered in the article (training, team
-reinforcement, code audits, etc.) [get in touch](/contact)!
+We've covered a lot of ground in this article, but we hope we've given you a good starting point for your Rust journey. If you have any questions, or if you'd like help with any of the topics covered in the article (training, team reinforcement, code audits, etc.) [get in touch](/contact)!
 
 ## Appendix: Learning resources
 
-When it comes to books, we recommend one out of the following three as a
-starting point:
-
-- [The Rust Programming Language](https://doc.rust-lang.org/book/) (aka "the
-  book"): the official Rust book. It's a great introduction to the language, and
-  it's kept up to date with the latest changes to the language.
-- [Programming Rust](https://www.oreilly.com/library/view/programming-rust-2nd/9781492052586/):
-  compared to the Rust book, it assumes the reader is a more experienced
-  developer, and it goes into more detail about the language internals.
-- [Rust in Action](https://www.manning.com/books/rust-in-action): a great mix of
-  theory and practice, trying to teach the language by building a lot of small
-  projects.
-
-When it comes to exercises, you should check out:
-[Rustlings](https://github.com/rust-lang/rustlings) and/or
-[the Rust track on Exercism](https://exercism.io/tracks/rust).
-
-Once the team is up to speed with the basics of the language, the learning path
-will diverge depending on the type of software project you are building.  
-If you're dealing with embedded systems,
-[The Embedded Rust Book](https://rust-embedded.github.io/book/) is a great
-resource.  
-If you're building an API or other kinds of backend systems, check out
-[Zero to Production](https://zero2prod.com/).  
-If you need advanced Rust topics,
-[Rust for Rustaceans](https://nostarch.com/rust-rustaceans) and the
-[Rustonomicon](https://doc.rust-lang.org/nomicon/) are the way to go.
+When it comes to books, we recommend one out of the following three as a starting point:
+
+- [The Rust Programming Language](https://doc.rust-lang.org/book/) (aka "the book"): the official Rust book. It's a great introduction to the language, and it's kept up to date with the latest changes to the language.
+- [Programming Rust](https://www.oreilly.com/library/view/programming-rust-2nd/9781492052586/): compared to the Rust book, it assumes the reader is a more experienced developer, and it goes into more detail about the language internals.
+- [Rust in Action](https://www.manning.com/books/rust-in-action): a great mix of theory and practice, trying to teach the language by building a lot of small projects.
+
+When it comes to exercises, you should check out: [Rustlings](https://github.com/rust-lang/rustlings) and/or [the Rust track on Exercism](https://exercism.io/tracks/rust).
+
+Once the team is up to speed with the basics of the language, the learning path will diverge depending on the type of software project you are building.  
+If you're dealing with embedded systems, [The Embedded Rust Book](https://rust-embedded.github.io/book/) is a great resource.  
+If you're building an API or other kinds of backend systems, check out [Zero to Production](https://zero2prod.com/).  
+If you need advanced Rust topics, [Rust for Rustaceans](https://nostarch.com/rust-rustaceans) and the [Rustonomicon](https://doc.rust-lang.org/nomicon/) are the way to go.
diff --git a/src/posts/2024-01-30-ember-guides-fr-git-automation.md b/src/posts/2024-01-30-ember-guides-fr-git-automation.md
index abf6cc6a56..782a178c5b 100644
--- a/src/posts/2024-01-30-ember-guides-fr-git-automation.md
+++ b/src/posts/2024-01-30-ember-guides-fr-git-automation.md
@@ -3,9 +3,7 @@ title: "Automating the maintenance of the Ember Guides in French"
 authorHandle: academierenards
 tags: [ember, node, git]
 bio: "Marine Dunstetter, Senior Software Engineer"
-description:
-  "Marine Dunstetter builds an automation script in Node.js to maintain the
-  translation of the Ember Guides with git and GitHub."
+description: "Marine Dunstetter builds an automation script in Node.js to maintain the translation of the Ember Guides with git and GitHub."
 og:
   image: "/assets/images/posts/2024-01-30-ember-guides-fr-git-automation/og-image.jpg"
 tagline: |
@@ -14,55 +12,26 @@ tagline: |
   </p>
 
 image: "/assets/images/posts/2024-01-30-ember-guides-fr-git-automation/header.jpg"
-imageAlt:
-  "The Ember logo on a grey background picture displaying a robot at work in a
-  factory"
+imageAlt: "The Ember logo on a grey background picture displaying a robot at work in a factory"
 ---
 
-As I am writing this blog post,
-[the Ember Guides](https://guides.emberjs.com/release/) are being translated
-into French. [The French website](https://ember-fr-guides.netlify.app) documents
-only the latest version of Ember (for time and human resources purposes). It
-means that when a new version of Ember is documented in English, we must adjust
-the French website accordingly. Let's say we must _"catch up"_ with the English
-version.
+As I am writing this blog post, [the Ember Guides](https://guides.emberjs.com/release/) are being translated into French. [The French website](https://ember-fr-guides.netlify.app) documents only the latest version of Ember (for time and human resources purposes). It means that when a new version of Ember is documented in English, we must adjust the French website accordingly. Let's say we must _"catch up"_ with the English version.
 
-At EmberFest 2023, I presented the approach used to build the French website,
-and I described
-[the manual process of catching up with English](https://www.youtube.com/watch?v=hTc_vH-AQdk&t=282s)
-when a new version of the docs is released. However, such process is not a
-realistic way to maintain the website in the long run.
+At EmberFest 2023, I presented the approach used to build the French website, and I described [the manual process of catching up with English](https://www.youtube.com/watch?v=hTc_vH-AQdk&t=282s) when a new version of the docs is released. However, such process is not a realistic way to maintain the website in the long run.
 
-Let's go on a journey to automate everything with a Node.js script that will run
-git commands and make requests to GitHub API! 🤖
+Let's go on a journey to automate everything with a Node.js script that will run git commands and make requests to GitHub API! 🤖
 
 **Disclaimer:**
 
-✅ This article will be a technical article to build a modern Node.js script
-from scratch. It aims to be accessible to beginners~intermediates, and we'll use
-the maintenance of the Ember Guides FR as a theme to introduce many concepts
-like using a modern node version, running commands, managing files and making
-API requests. However, it's not a "tutorial", because we create the script in an
-existing app. We don't start from a blank page nor expect you to achieve exactly
-the same thing.
+✅ This article will be a technical article to build a modern Node.js script from scratch. It aims to be accessible to beginners~intermediates, and we'll use the maintenance of the Ember Guides FR as a theme to introduce many concepts like using a modern node version, running commands, managing files and making API requests. However, it's not a "tutorial", because we create the script in an existing app. We don't start from a blank page nor expect you to achieve exactly the same thing.
 
-❌ This article won't be about how to bootstrap a translation project and how to
-organize it to make it work in the long term. I can simply say that automating
-the maintenance where it's possible and being confident in the tools you build
-is a good way to remove pressure and entertain motivation.
+❌ This article won't be about how to bootstrap a translation project and how to organize it to make it work in the long term. I can simply say that automating the maintenance where it's possible and being confident in the tools you build is a good way to remove pressure and entertain motivation.
 
 **Prerequisites:**
 
-- To automate the maintenance, we are going to execute a
-  [Node.js](https://nodejs.org/en) script to write instructions in JavaScript,
-  so we need to have Node.js installed.
-- The article could be easier to follow if you first have a look at
-  [the part of the EmberFest talk related to git](https://www.youtube.com/watch?v=hTc_vH-AQdk&t=282s).
-  At the beginning of each section, I will sum up the information we need in a
-  small paragraph 🐹🎥 _The talk in a nutshell_.
-- Finally, here is how my repository is configured. The French app's repo
-  (`ember-fr-guides-source`) is a fork of the official Ember Guides' repo
-  (`guides-source`):
+- To automate the maintenance, we are going to execute a [Node.js](https://nodejs.org/en) script to write instructions in JavaScript, so we need to have Node.js installed.
+- The article could be easier to follow if you first have a look at [the part of the EmberFest talk related to git](https://www.youtube.com/watch?v=hTc_vH-AQdk&t=282s). At the beginning of each section, I will sum up the information we need in a small paragraph 🐹🎥 _The talk in a nutshell_.
+- Finally, here is how my repository is configured. The French app's repo (`ember-fr-guides-source`) is a fork of the official Ember Guides' repo (`guides-source`):
 
 ```bash
 % git remote -v
@@ -94,23 +63,12 @@ upstream git@github.com:ember-learn/guides-source.git (fetch and push)
 
 ## 1. Writing a modern Node.js script
 
-🐹🎥 _The talk in a nutshell:_ A new version of the Ember Guides was published
-🔥 What are the changes? To visualize them clearly, we can only compare English
-to English: our repository has a protected `ref-upstream` branch that
-corresponds to the English version under translation. We want to compare
-`ref-upstream` to `upstream/master` to see the changes between both English
-versions. If there are changes in files that are not translated yet, we want to
-apply them automatically. If there are changes in files that have been
-translated into French, we want GitHub to open an issue containing the diff. To
-picture this part better, here is the kind of issue we want to open:
-[#213 Translate /addons-and-dependencies/index.md, Ember 5.4](https://github.com/DazzlingFugu/ember-fr-guides-source/issues/213).
+🐹🎥 _The talk in a nutshell:_ A new version of the Ember Guides was published 🔥 What are the changes? To visualize them clearly, we can only compare English to English: our repository has a protected `ref-upstream` branch that corresponds to the English version under translation. We want to compare `ref-upstream` to `upstream/master` to see the changes between both English versions. If there are changes in files that are not translated yet, we want to apply them automatically. If there are changes in files that have been translated into French, we want GitHub to open an issue containing the diff. To picture this part better, here is the kind of issue we want to open: [#213 Translate /addons-and-dependencies/index.md, Ember 5.4](https://github.com/DazzlingFugu/ember-fr-guides-source/issues/213).
 
-Out of this summary, there are a couple of things we already know about our
-script:
+Out of this summary, there are a couple of things we already know about our script:
 
 - It will post an issue on GitHub, which is an asynchronous fetch operation.
-- It will know the versions of Ember we are dealing with, so we can write some
-  beautiful "from Ember 5.4 to Ember 5.5" in the body of the issue.
+- It will know the versions of Ember we are dealing with, so we can write some beautiful "from Ember 5.4 to Ember 5.5" in the body of the issue.
 - It will use GitHub API to post the issue.
 
 Let's start with what we know then.
@@ -125,28 +83,20 @@ You can check by running this command:
 % node -v
 ```
 
-At the moment I am writing this, the latest version is v21.5.0. It lets us use
-modules and syntaxes like `async` and top-level `await` to bring clarity to our
-asynchronous operations. This might be very handy to manage our calls to GitHub
-API later, so let’s make sure we have the latest Node.js. The way to update
-Node.js depends on the tools you used to install it (`brew`, `nvm`, `volta`...)
-If, just like me, you never remember what it was, this could help:
+At the moment I am writing this, the latest version is v21.5.0. It lets us use modules and syntaxes like `async` and top-level `await` to bring clarity to our asynchronous operations. This might be very handy to manage our calls to GitHub API later, so let’s make sure we have the latest Node.js. The way to update Node.js depends on the tools you used to install it (`brew`, `nvm`, `volta`...) If, just like me, you never remember what it was, this could help:
 
 ```js
 % whereis node
 ```
 
-If you're not familiar with running Node.js scripts, here are the basics. In the
-`ember-fr-guides-source` folder, we create a file `scripts/catchup.mjs`:
+If you're not familiar with running Node.js scripts, here are the basics. In the `ember-fr-guides-source` folder, we create a file `scripts/catchup.mjs`:
 
 ```js
 // ember-fr-guides-source/scripts/catchup.mjs
 console.log("I love Ember");
 ```
 
-ℹ️ The `m` in `mjs` stands for [Module](https://docs.fileformat.com/web/mjs/).
-By using modules, we'll be able to use `import` to bring functionality from node
-and external libraries into our script.
+ℹ️ The `m` in `mjs` stands for [Module](https://docs.fileformat.com/web/mjs/). By using modules, we'll be able to use `import` to bring functionality from node and external libraries into our script.
 
 Then, from the terminal, we reach the folder `ember-fr-guides-source` and run:
 
@@ -159,16 +109,9 @@ The output “I love Ember” shows up in the terminal. 🎉
 
 ### b. Running a script with arguments
 
-🤔 If we want to write "from Ember 5.4 to Ember 5.5" in the body of our issue,
-then the script should know these numbers. First, we could declare two variables
-`currentEmberVersion` and `newEmberVersion`. Then we could assign hardcoded
-values `5.4` and `5.5`, but it would be inconvenient: each time we want to run
-the catch-up process in the future, we would have to modify the script. It would
-be better if we could specify the Ember versions in the command line.
+🤔 If we want to write "from Ember 5.4 to Ember 5.5" in the body of our issue, then the script should know these numbers. First, we could declare two variables `currentEmberVersion` and `newEmberVersion`. Then we could assign hardcoded values `5.4` and `5.5`, but it would be inconvenient: each time we want to run the catch-up process in the future, we would have to modify the script. It would be better if we could specify the Ember versions in the command line.
 
-Before running a node script, you can add arguments separated by spaces. When
-the script runs, the arguments will be accessible in `process.argv`. For
-instance, let's add the following log at the beginning of `catchup.mjs`:
+Before running a node script, you can add arguments separated by spaces. When the script runs, the arguments will be accessible in `process.argv`. For instance, let's add the following log at the beginning of `catchup.mjs`:
 
 ```js
 console.log(process.argv);
@@ -189,26 +132,15 @@ Then let's run:
 ]
 ```
 
-We could execute `process.argv.slice(2)` to remove the two first elements, then
-read options by index or using the
-[`indexOf`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexOf)
-function. Another handy solution is to rely on an external library like
-`minimist-lite`. This library maps the options we pass into a dictionary that
-makes the access more intuitive in the code:
+We could execute `process.argv.slice(2)` to remove the two first elements, then read options by index or using the [`indexOf`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/indexOf) function. Another handy solution is to rely on an external library like `minimist-lite`. This library maps the options we pass into a dictionary that makes the access more intuitive in the code:
 
 ```bash
 % npm install minimist-lite --save-dev
 ```
 
-ℹ️ This will add `minimist-lite` to the dev dependencies of our application. In
-our case, `ember-fr-guides-source` is already an Ember application with a
-`package.json`, so we have no problem running `npm install`. If you want to
-import dependencies in a standalone script, outside of an application folder,
-you'll need to initialize a package manager first. For instance, you can
-initialize `npm` with `npm init`.
+ℹ️ This will add `minimist-lite` to the dev dependencies of our application. In our case, `ember-fr-guides-source` is already an Ember application with a `package.json`, so we have no problem running `npm install`. If you want to import dependencies in a standalone script, outside of an application folder, you'll need to initialize a package manager first. For instance, you can initialize `npm` with `npm init`.
 
-We can now import `minimist-lite` in `catchup.mjs` and use it to map our
-options:
+We can now import `minimist-lite` in `catchup.mjs` and use it to map our options:
 
 ```js
 import minimist from "minimist-lite";
@@ -222,14 +154,7 @@ console.log(argv);
 > { _: [], from: 5, to: 5.4, o: 'hey' }
 ```
 
-As you can see, passing an option like `--to=5.4` would result in
-`argv.to === 5.4`, which is perfect. However, we have an issue with version
-numbers ending with `0`: `--from 5.0` would result in `5`. This is because
-`minimist-lite` manages numerical values as proper numbers. If we could indicate
-that options `from` and `to` should be treated as `string` values, this would
-solve our problem. `minimist-lite` can take options to let us specify the type
-of each argument. The documentation is a bit hard to decipher in my personal
-opinion, here is the syntax we need to figure out:
+As you can see, passing an option like `--to=5.4` would result in `argv.to === 5.4`, which is perfect. However, we have an issue with version numbers ending with `0`: `--from 5.0` would result in `5`. This is because `minimist-lite` manages numerical values as proper numbers. If we could indicate that options `from` and `to` should be treated as `string` values, this would solve our problem. `minimist-lite` can take options to let us specify the type of each argument. The documentation is a bit hard to decipher in my personal opinion, here is the syntax we need to figure out:
 
 ```diff
   import minimist from 'minimist-lite';
@@ -239,16 +164,14 @@ opinion, here is the syntax we need to figure out:
   console.log(argv);
 ```
 
-`string` is an option that contains the array of arguments that should be
-handled as `string`:
+`string` is an option that contains the array of arguments that should be handled as `string`:
 
 ```bash
 % node scripts/catchup.mjs --from 5.0 --to=5.4 -o hey
 > { _: [], from: '5.0', to: '5.4', o: 'hey' }
 ```
 
-Now that we have the expected format, let's store the arguments into variables
-that we'll use later in our GitHub issue:
+Now that we have the expected format, let's store the arguments into variables that we'll use later in our GitHub issue:
 
 ```js
 import minimist from "minimist-lite";
@@ -277,21 +200,9 @@ if (newEmberVersion.match(/\d+[.]\d+/g)?.[0] !== newEmberVersion) {
 console.log(`New Ember version documented on upstream: ${newEmberVersion}`);
 ```
 
-ℹ️ `process.exit(9);` forces the process to exit. Any status but `0` indicates
-the process exited with errors. `9` is for invalid arguments. You can see the
-[list of error codes here](https://nodejs.org/api/process.html#exit-codes).
-Also, be aware that if you start async operations in a script and
-`process.exit(n);` executes, then you have no way to know for sure what
-operations the script could perform or not before existing. If for some reason
-all your async operations are not awaited, it's generally better to assign a
-value to `process.exitCode`. `process.exitCode = n;` means that _when the
-process finally exits_, it will exit with code `n`.
-
-ℹ️
-[`match`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match)
-finds all the occurrences of a given regexp in the string and returns them in an
-array. In our case, we expect the first occurrence of `d.d` (digit, dot, digit)
-to exist and to be equal to the argument value:
+ℹ️ `process.exit(9);` forces the process to exit. Any status but `0` indicates the process exited with errors. `9` is for invalid arguments. You can see the [list of error codes here](https://nodejs.org/api/process.html#exit-codes). Also, be aware that if you start async operations in a script and `process.exit(n);` executes, then you have no way to know for sure what operations the script could perform or not before existing. If for some reason all your async operations are not awaited, it's generally better to assign a value to `process.exitCode`. `process.exitCode = n;` means that _when the process finally exits_, it will exit with code `n`.
+
+ℹ️ [`match`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/match) finds all the occurrences of a given regexp in the string and returns them in an array. In our case, we expect the first occurrence of `d.d` (digit, dot, digit) to exist and to be equal to the argument value:
 
 ```bash
 % node scripts/catchup.mjs --from=5.1typo --to=5.4
@@ -306,47 +217,21 @@ Great! Now we have the first piece of information to create a GitHub issue.
 
 ### c. Using an environment variable
 
-Most of the time, when we want to create a new GitHub issue on a repository, we
-do it manually via GitHub UI. We can achieve the same thing using GitHub API.
-[Here is what it looks like](https://docs.github.com/en/rest/issues/issues?apiVersion=2022-11-28#create-an-issue).
-As you can see in the JavaScript tab of the docs, GitHub recommends the usage of
-`Octokit` to interact with the API in JavaScript.
-
-However, our case is pretty simple, and using the regular JavaScript method
-`fetch` with [https://api.github.com/](https://api.github.com/) is also
-possible. I decided to go with `fetch` because I think it’s a bit more
-accessible and generic, you could reuse this blog post more easily for different
-purposes. It’s essentially the same thing, except that we'll set our
-authorization header manually. Among other static things, the authorization
-header contains an `Authorization` field that must be filled with
-`Bearer <YOUR-TOKEN>`.
-
-`<YOUR-TOKEN>` should be replaced with a secret token required by GitHub API to
-authenticate us and make sure we're allowed to use the API the way we try to use
-it. To generate a personal token, log in to your GitHub account and
-[follow this section of the docs](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).
-Once your token is generated, copy it somewhere, in a local file, so you have it
-within easy reach.
-
-🤔 `<YOUR-TOKEN>` is not supposed to change over time (at least not very often),
-but it’s sensitive, so it can’t be hardcoded in the script. We could pass a
-`token` as third argument:
+Most of the time, when we want to create a new GitHub issue on a repository, we do it manually via GitHub UI. We can achieve the same thing using GitHub API. [Here is what it looks like](https://docs.github.com/en/rest/issues/issues?apiVersion=2022-11-28#create-an-issue). As you can see in the JavaScript tab of the docs, GitHub recommends the usage of `Octokit` to interact with the API in JavaScript.
+
+However, our case is pretty simple, and using the regular JavaScript method `fetch` with [https://api.github.com/](https://api.github.com/) is also possible. I decided to go with `fetch` because I think it’s a bit more accessible and generic, you could reuse this blog post more easily for different purposes. It’s essentially the same thing, except that we'll set our authorization header manually. Among other static things, the authorization header contains an `Authorization` field that must be filled with `Bearer <YOUR-TOKEN>`.
+
+`<YOUR-TOKEN>` should be replaced with a secret token required by GitHub API to authenticate us and make sure we're allowed to use the API the way we try to use it. To generate a personal token, log in to your GitHub account and [follow this section of the docs](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic). Once your token is generated, copy it somewhere, in a local file, so you have it within easy reach.
+
+🤔 `<YOUR-TOKEN>` is not supposed to change over time (at least not very often), but it’s sensitive, so it can’t be hardcoded in the script. We could pass a `token` as third argument:
 
 ```bash
 % node scripts/togithub.mjs --from=5.1 --to=5.4 --token="<YOUR-TOKEN>"
 ```
 
-It’s fine, but not good enough. We don’t want to copy the `token` manually from
-somewhere to our command line each time we want to run the script. It would be
-more convenient if the script could read the token by itself.
+It’s fine, but not good enough. We don’t want to copy the `token` manually from somewhere to our command line each time we want to run the script. It would be more convenient if the script could read the token by itself.
 
-A common practice in web projects is to store the secret variables in a file
-`.env` which is added to the `.gitignore` file so we’re sure it won’t be
-committed to GitHub inadvertently. Along with this file, an `.env.example`,
-which contains fake values, is committed to GitHub and describes what secret
-variables the developer should set up to get the project working. The library
-[dotenv](https://www.npmjs.com/package/dotenv) brings this common practice into
-Node.js by providing the variables defined in `.env` through `process.env`:
+A common practice in web projects is to store the secret variables in a file `.env` which is added to the `.gitignore` file so we’re sure it won’t be committed to GitHub inadvertently. Along with this file, an `.env.example`, which contains fake values, is committed to GitHub and describes what secret variables the developer should set up to get the project working. The library [dotenv](https://www.npmjs.com/package/dotenv) brings this common practice into Node.js by providing the variables defined in `.env` through `process.env`:
 
 ```bash
 % npm install dotenv --save-dev
@@ -370,8 +255,7 @@ console.log(process.env.GITHUB_TOKEN);
 > "<YOUR-TOKEN>"
 ```
 
-Let's remove that `console.log`. The token can be read anywhere in the script,
-for instance in a function:
+Let's remove that `console.log`. The token can be read anywhere in the script, for instance in a function:
 
 ```js
 /*
@@ -398,14 +282,7 @@ The script knows all the arguments it needs to automate the process 🎉
 
 ## 2. Using git in a Node.js script
 
-🐹🎥 _The talk in a nutshell:_ A new version of the Ember Guides was published
-🔥 To see the changes, we compare `origin/ref-upstream` to `upstream/master` and
-we print the result in a patch file `english.diff` that shows a list of diff
-blocks. If non-translated files have changes, we apply the changes
-automatically, which means these files are updated locally, which means we have
-to commit them in a working branch. Once that's done, we are officially
-translating the new Ember version, so we reset `origin/ref-upstream` to the same
-state as `upstream/master` to be ready for the next catch-up.
+🐹🎥 _The talk in a nutshell:_ A new version of the Ember Guides was published 🔥 To see the changes, we compare `origin/ref-upstream` to `upstream/master` and we print the result in a patch file `english.diff` that shows a list of diff blocks. If non-translated files have changes, we apply the changes automatically, which means these files are updated locally, which means we have to commit them in a working branch. Once that's done, we are officially translating the new Ember version, so we reset `origin/ref-upstream` to the same state as `upstream/master` to be ready for the next catch-up.
 
 Sounds like the script is going to run a lot of git commands:
 
@@ -417,14 +294,7 @@ Sounds like the script is going to run a lot of git commands:
 
 ### a. Running git commands from a script
 
-First, we want to create a new "catch-up" branch to work on. In the terminal, we
-would do this with `git switch --create <branch-name>`. It would be nice to
-reuse our variable `newEmberVersion` in the name of the branch, both for the
-sake of clarity and to have the possibility to keep several catch-up branches
-locally if we need to. Unfortunately, we can’t write the shell commands we use
-in our terminal directly in the `catchup.mjs` file, because it’s not JavaScript!
-The good news is Node.js embeds a function to answer this problem. It's called
-`execSync`, and it's located in the `child_process` module:
+First, we want to create a new "catch-up" branch to work on. In the terminal, we would do this with `git switch --create <branch-name>`. It would be nice to reuse our variable `newEmberVersion` in the name of the branch, both for the sake of clarity and to have the possibility to keep several catch-up branches locally if we need to. Unfortunately, we can’t write the shell commands we use in our terminal directly in the `catchup.mjs` file, because it’s not JavaScript! The good news is Node.js embeds a function to answer this problem. It's called `execSync`, and it's located in the `child_process` module:
 
 ```js
 import { execSync } from "child_process";
@@ -442,22 +312,11 @@ try {
 }
 ```
 
-ℹ️ `Sync` stands for synchronous. It means the script execution will pause until
-the operation is complete. Node.js generally provides asynchronous functions
-along with a `Sync` version, so you can use one or the other (e.g. `exec` vs
-`execSync`). We'll come back to this later.
+ℹ️ `Sync` stands for synchronous. It means the script execution will pause until the operation is complete. Node.js generally provides asynchronous functions along with a `Sync` version, so you can use one or the other (e.g. `exec` vs `execSync`). We'll come back to this later.
 
-Our code will work once. If we call it twice, it will fail because the branch
-already exists. When the command specified to `execSync` fails, it throws an
-error, which could cause the process to exit immediately. We prevent this
-behavior with the
-[`try...catch`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch)
-block and customize the error message.
+Our code will work once. If we call it twice, it will fail because the branch already exists. When the command specified to `execSync` fails, it throws an error, which could cause the process to exit immediately. We prevent this behavior with the [`try...catch`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch) block and customize the error message.
 
-Great! We can run git commands! 💪 We also want to run `git fetch` and
-`git fetch upstream` to make sure that `origin/ref-upstream` and
-`upstream/master` are both up to date before we start working with them. Let's
-abstract our logic in a function so we don't have to rewrite the log each time:
+Great! We can run git commands! 💪 We also want to run `git fetch` and `git fetch upstream` to make sure that `origin/ref-upstream` and `upstream/master` are both up to date before we start working with them. Let's abstract our logic in a function so we don't have to rewrite the log each time:
 
 ```diff
 + const runShell = (command) => {
@@ -480,10 +339,7 @@ abstract our logic in a function so we don't have to rewrite the log each time:
 
 ### b. Using git diff like a boss
 
-The next step of the process is to generate the diff between
-`origin/ref-upstream` and `upstream/master` to view how the second impacts the
-first. In the talk, I gave several steps to build this command. The one we'll
-describe here is slightly different but does essentially the same thing:
+The next step of the process is to generate the diff between `origin/ref-upstream` and `upstream/master` to view how the second impacts the first. In the talk, I gave several steps to build this command. The one we'll describe here is slightly different but does essentially the same thing:
 
 ```bash
 git diff origin/ref-upstream upstream/master -- guides/release > english.diff
@@ -496,46 +352,21 @@ git diff origin/ref-upstream upstream/master -- guides/release > english.diff
 + Line number 24 in file myFile.md on branch B
 ```
 
-The `--` option allows us to specify a path for the compare operation. We are
-not interested in all the changes in the whole app, we want to patch only the
-markdown files located in `guides/release`.
-
-Then we output the result of this command in one big file called `english.diff`,
-which shows up at the root of the project. It contains one diff block per
-modified markdown file. This is where the manual process becomes a bit heavy:
-
-- We run `git apply english.diff` to automatically apply the changes A → B to
-  all files. But git can do this only if each target file is in English and
-  hasn’t been translated yet. If at least one markdown file has been translated
-  into French, it means both sides have been modified and are now completely
-  different, so git doesn’t know what to do: the whole command fails.
-- For each block causing a failure, we open manually a new issue on GitHub, copy
-  the diff in there (so a translator can tackle it later), and then remove the
-  block from `english.diff`. Then we run `git apply english.diff` again, etc,
-  etc...
-- We do this until `git apply english.diff` finally works because there are only
-  non-translated English files targeted by the remaining diff blocks.
-
-🤔 This iterative process doesn't look easy to automate. We probably need a
-quite different strategy, and we can probably make it simpler to picture!
-
-`git apply` takes a path to a patch file. Instead of running
-`git apply english.diff` and the whole command fails when something goes wrong,
-it would be more convenient to try `git apply` block by block. What if we could
-have one patch file per markdown file? This way we could run
-`git apply file-1.diff`, `git apply file-2.diff`... and perform actions
-depending on the result.
-
-Thanks to `-- guides/release` option, we learned that `git diff` command can
-scope the comparison to a given folder. We could also scope it to one single
-markdown file! So we would run the command with
-`-- [my-file-1].md > [my-file-1].diff` to output all the different patches. But
-how to get the list of markdown files that have been modified in
-`upstream/master`?
-
-`git diff` can help us with another option called `--name-only`. Instead of
-returning all the diff blocks as we saw earlier, it will return only the name of
-the files containing changes!
+The `--` option allows us to specify a path for the compare operation. We are not interested in all the changes in the whole app, we want to patch only the markdown files located in `guides/release`.
+
+Then we output the result of this command in one big file called `english.diff`, which shows up at the root of the project. It contains one diff block per modified markdown file. This is where the manual process becomes a bit heavy:
+
+- We run `git apply english.diff` to automatically apply the changes A → B to all files. But git can do this only if each target file is in English and hasn’t been translated yet. If at least one markdown file has been translated into French, it means both sides have been modified and are now completely different, so git doesn’t know what to do: the whole command fails.
+- For each block causing a failure, we open manually a new issue on GitHub, copy the diff in there (so a translator can tackle it later), and then remove the block from `english.diff`. Then we run `git apply english.diff` again, etc, etc...
+- We do this until `git apply english.diff` finally works because there are only non-translated English files targeted by the remaining diff blocks.
+
+🤔 This iterative process doesn't look easy to automate. We probably need a quite different strategy, and we can probably make it simpler to picture!
+
+`git apply` takes a path to a patch file. Instead of running `git apply english.diff` and the whole command fails when something goes wrong, it would be more convenient to try `git apply` block by block. What if we could have one patch file per markdown file? This way we could run `git apply file-1.diff`, `git apply file-2.diff`... and perform actions depending on the result.
+
+Thanks to `-- guides/release` option, we learned that `git diff` command can scope the comparison to a given folder. We could also scope it to one single markdown file! So we would run the command with `-- [my-file-1].md > [my-file-1].diff` to output all the different patches. But how to get the list of markdown files that have been modified in `upstream/master`?
+
+`git diff` can help us with another option called `--name-only`. Instead of returning all the diff blocks as we saw earlier, it will return only the name of the files containing changes!
 
 To sum it up, here is the kind of implementation we want:
 
@@ -593,27 +424,15 @@ try {
 } // catch(error) { ... }
 ```
 
-That's a great start! There's just this blocking `TODO` (read the content of
-`list.diff`) we need to figure out, we'll come back to it in the next section.
+That's a great start! There's just this blocking `TODO` (read the content of `list.diff`) we need to figure out, we'll come back to it in the next section.
 
 ### c. Managing new markdown files
 
-🤔 We saw quite interesting `git diff` options to create all the resources we
-need. There's one case though, we didn't mention at all. What if some of the
-"changed" files are new files that have been added to the latest Ember docs and
-that don't exist at all in our current branch?
+🤔 We saw quite interesting `git diff` options to create all the resources we need. There's one case though, we didn't mention at all. What if some of the "changed" files are new files that have been added to the latest Ember docs and that don't exist at all in our current branch?
 
-In that case, `git apply` will work like a charm and will create the new English
-file for us, but then... we'll need to open a GitHub issue to alert the
-translators there's something new to translate entirely. It means that the
-answer to the question "Should I open a GitHub issue?" doesn't depend only on
-`git apply`'s success or failure, it also depends on the existence of the file
-in the current branch, and at some point, we should probably track the files
-that need to be posted.
+In that case, `git apply` will work like a charm and will create the new English file for us, but then... we'll need to open a GitHub issue to alert the translators there's something new to translate entirely. It means that the answer to the question "Should I open a GitHub issue?" doesn't depend only on `git apply`'s success or failure, it also depends on the existence of the file in the current branch, and at some point, we should probably track the files that need to be posted.
 
-To check if the file exists on the current branch, we'll import a module called
-`fs` and use the function called `existsSync`. We'll learn more about the `fs`
-module in the next section of the blog post 😉
+To check if the file exists on the current branch, we'll import a module called `fs` and use the function called `existsSync`. We'll learn more about the `fs` module in the next section of the blog post 😉
 
 ```diff
 + import fs from 'fs';
@@ -645,23 +464,16 @@ module in the next section of the blog post 😉
 
 ```
 
-ℹ️ `git apply` runs after we've initialized `isNew`, because it can create the
-missing file and therefore compromise the value.
+ℹ️ `git apply` runs after we've initialized `isNew`, because it can create the missing file and therefore compromise the value.
 
 ### d. Closing commands
 
-There are other git commands we need to include in the script: those happening
-at the end of the process:
+There are other git commands we need to include in the script: those happening at the end of the process:
 
-- If we have local changes, we should commit them and push the catch-up branch
-  to GitHub: this happens when at least one `git apply` worked.
-- Once we're done with everything, we should reset `origin/ref-upstream` to
-  `upstream/master` so we are ready for the next catch-up: this happens each
-  time the process ends without error, even when there were no changes at all in
-  `guides/release`.
+- If we have local changes, we should commit them and push the catch-up branch to GitHub: this happens when at least one `git apply` worked.
+- Once we're done with everything, we should reset `origin/ref-upstream` to `upstream/master` so we are ready for the next catch-up: this happens each time the process ends without error, even when there were no changes at all in `guides/release`.
 
-There's no new concept here, we already have all the knowledge to put this in
-place:
+There's no new concept here, we already have all the knowledge to put this in place:
 
 ```js
 /*
@@ -694,10 +506,7 @@ const closeProcess = pendingDiff => {
 };
 ```
 
-We want `applyPatches` to tell us if at least one patch file couldn't be created
-and if at least one patch could be applied automatically. There are certainly
-different ways to achieve this, but for reasons we'll see in a later section of
-this blog post, let's go with a result code approach:
+We want `applyPatches` to tell us if at least one patch file couldn't be created and if at least one patch could be applied automatically. There are certainly different ways to achieve this, but for reasons we'll see in a later section of this blog post, let's go with a result code approach:
 
 ```diff
   const applyPatches = (files) => {
@@ -762,57 +571,27 @@ So far, we learned how to:
 
 - Run a shell command with `execSync`
 - Output the result of a command in a file
-- Compare branches with `git diff` and a panel of options to make it output
-  information in different shapes
+- Compare branches with `git diff` and a panel of options to make it output information in different shapes
 
-In theory, git does a lot of things for us at this point. "In theory" because
-our array of `files` is still desperately empty! Let's do something about that.
+In theory, git does a lot of things for us at this point. "In theory" because our array of `files` is still desperately empty! Let's do something about that.
 
 ## 3. Managing files with Node.js
 
-🐹🎥 _The talk in a nutshell:_ In the French website, we translate only the
-latest version of Ember, so the UI doesn't have a dropdown to navigate to legacy
-versions. To hide the dropdown automatically, our folders have a slightly
-different scaffolding. The subtlety is that our diff compares the markdown files
-located in `guides/release/`. But in our `master` branch (and our `catchup`
-branch), all these very same files are located directly in `guides/`. It means
-that the command `git apply ${diffName}` will fail to patch the updated files,
-because the script will look for them in `guides/release/` and notice they don't
-exist.
+🐹🎥 _The talk in a nutshell:_ In the French website, we translate only the latest version of Ember, so the UI doesn't have a dropdown to navigate to legacy versions. To hide the dropdown automatically, our folders have a slightly different scaffolding. The subtlety is that our diff compares the markdown files located in `guides/release/`. But in our `master` branch (and our `catchup` branch), all these very same files are located directly in `guides/`. It means that the command `git apply ${diffName}` will fail to patch the updated files, because the script will look for them in `guides/release/` and notice they don't exist.
 
 Here are the conclusions we can draw:
 
-- We need to read `list.diff` and parse the list of filenames in our `files`
-  array. Each item of the array will be a filename starting with
-  `guides/release/`.
-- To make our patch files valid in our scaffolding, we need a way to change the
-  path to `guides/`.
-- If a patch file cannot be applied automatically, we'll reuse its content to
-  create the corresponding GitHub issue. And if we fail to post one GitHub issue
-  among several, it will be easier to open it manually (trying to re-run the
-  script for one given file is currently out of scope), so we'll keep the patch
-  files easy to reach.
+- We need to read `list.diff` and parse the list of filenames in our `files` array. Each item of the array will be a filename starting with `guides/release/`.
+- To make our patch files valid in our scaffolding, we need a way to change the path to `guides/`.
+- If a patch file cannot be applied automatically, we'll reuse its content to create the corresponding GitHub issue. And if we fail to post one GitHub issue among several, it will be easier to open it manually (trying to re-run the script for one given file is currently out of scope), so we'll keep the patch files easy to reach.
 
 ### a. Reading files synchronously
 
-We want to read the content of `list.diff` to extract an array of filenames. To
-deal with files, we’re going to use
-[Node.js File System Module](https://nodejs.org/docs/latest-v21.x/api/fs.html#file-system)
-`fs`. It's the module we imported earlier, when we used `fs.existsSync`! Among
-all the functions this module provides, here are the ones we are interested in
-this time: `fs.readFile` and `fs.readFileSync`, which can read a file and return
-its content.
-
-ℹ️ Just like we saw in the first section with `exec` versus `execSync`, most
-functions of the `fs` module are asynchronous and have a `Sync` alternative. The
-asynchronous functions should generally be preferred whenever it’s possible to
-use them because they allow the process to parallelize some tasks and therefore
-be faster.
-
-But in our case, synchronicity makes more sense: as long as we don’t know the
-content of `list.diff`, we can’t know the list of files to handle next.
-`fs.readFileSync` retrieves the file out of the provided `filename` and returns
-its content:
+We want to read the content of `list.diff` to extract an array of filenames. To deal with files, we’re going to use [Node.js File System Module](https://nodejs.org/docs/latest-v21.x/api/fs.html#file-system) `fs`. It's the module we imported earlier, when we used `fs.existsSync`! Among all the functions this module provides, here are the ones we are interested in this time: `fs.readFile` and `fs.readFileSync`, which can read a file and return its content.
+
+ℹ️ Just like we saw in the first section with `exec` versus `execSync`, most functions of the `fs` module are asynchronous and have a `Sync` alternative. The asynchronous functions should generally be preferred whenever it’s possible to use them because they allow the process to parallelize some tasks and therefore be faster.
+
+But in our case, synchronicity makes more sense: as long as we don’t know the content of `list.diff`, we can’t know the list of files to handle next. `fs.readFileSync` retrieves the file out of the provided `filename` and returns its content:
 
 ```js
 // Read list.diff to extract the list of paths to markdown files
@@ -820,36 +599,17 @@ let data = fs.readFileSync("list.diff", "utf8");
 const files = data.split(/[\n\r]/).filter(name => name.length);
 ```
 
-ℹ️ The first argument of `fs.readFileSync` is a relative path. `list.diff` is
-like `./list.diff`. Also, note that `./` is not the location of the
-`catchup.mjs` script, but it’s from where we are running the script. It means
-that if we are at the root of the `ember-fr-guides-source` folder and we use the
-command `node scripts/catchup.mjs` from there, then `./` is exactly where we
-are: the root of the `ember-fr-guides-source` folder. Here, the filename is
-`./list.diff` because we generated it at the root of the repository.
+ℹ️ The first argument of `fs.readFileSync` is a relative path. `list.diff` is like `./list.diff`. Also, note that `./` is not the location of the `catchup.mjs` script, but it’s from where we are running the script. It means that if we are at the root of the `ember-fr-guides-source` folder and we use the command `node scripts/catchup.mjs` from there, then `./` is exactly where we are: the root of the `ember-fr-guides-source` folder. Here, the filename is `./list.diff` because we generated it at the root of the repository.
 
-The content of `list.diff` contains one line per file name: using a
-[`split`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split)
-by line breakers then filtering potential empty values is enough to create our
-array.
+The content of `list.diff` contains one line per file name: using a [`split`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/split) by line breakers then filtering potential empty values is enough to create our array.
 
-We have our `files` ready, which means we can finally enter the function
-`applyPatches` to generate the patch file `[index].diff` for each of them.
+We have our `files` ready, which means we can finally enter the function `applyPatches` to generate the patch file `[index].diff` for each of them.
 
-🤔 But don't you think it's a bit rough to create all our files at the root of
-the project like this? Couldn't we create our patch files in a dedicated folder?
+🤔 But don't you think it's a bit rough to create all our files at the root of the project like this? Couldn't we create our patch files in a dedicated folder?
 
 ### b. Creating files into a new folder
 
-When you need to create _temporary_ files and folders that are used only by the
-script and then can be deleted at the end of the process, you can use
-[the OS directory for temporary files](https://nodejs.org/api/os.html#ostmpdir)
-to ease the clean-up. Our patch files are not necessarily that kind of temporary
-files. Let's imagine we reuse these files to create 3 GitHub issues and for some
-reason one of the POST requests fails. Today, the easiest way to finish the
-catch-up is to open manually the missing issue, so having the patch file still
-around will become handy. For this reason, we will create the folder permanently
-on the catch-up branch.
+When you need to create _temporary_ files and folders that are used only by the script and then can be deleted at the end of the process, you can use [the OS directory for temporary files](https://nodejs.org/api/os.html#ostmpdir) to ease the clean-up. Our patch files are not necessarily that kind of temporary files. Let's imagine we reuse these files to create 3 GitHub issues and for some reason one of the POST requests fails. Today, the easiest way to finish the catch-up is to open manually the missing issue, so having the patch file still around will become handy. For this reason, we will create the folder permanently on the catch-up branch.
 
 Let’s create a new folder in the scripts folder:
 
@@ -859,9 +619,7 @@ fs.mkdirSync("scripts/patches", { recursive: true });
 console.log("scripts/patches folder created to store the patch files");
 ```
 
-ℹ️ Using the option `recursive: true` will prevent the command from failing if
-the `scripts` folder doesn't exist or there's already a `scripts/patches`
-folder. It's up to you to decide if that case is a problem or not.
+ℹ️ Using the option `recursive: true` will prevent the command from failing if the `scripts` folder doesn't exist or there's already a `scripts/patches` folder. It's up to you to decide if that case is a problem or not.
 
 We now have a good place for our files, so we can create them here:
 
@@ -876,9 +634,7 @@ We now have a good place for our files, so we can create them here:
   }
 ```
 
-The patch files are created in the `scripts/patches` folder. Once the file is
-written, `git apply` runs and... fails with the error "No such file or
-directory". Time to take care of this `guides` versus `guides/release` thing.
+The patch files are created in the `scripts/patches` folder. Once the file is written, `git apply` runs and... fails with the error "No such file or directory". Time to take care of this `guides` versus `guides/release` thing.
 
 ### c. Writing files asynchronously
 
@@ -898,13 +654,7 @@ index 2253b1bdd..6e0e2a99d 100644
 
 ```
 
-There are 4 occurrences of the path `guides/release` and we need to replace them
-with `guides`. It will mean it's the diff between
-`guides/accessibility/components.md` and some fictive
-`guides/accessibility/components.md` coming from the `b` branch. Manually, we
-would do this with “Find and Replace” in the code editor. Instead, let’s do it
-in JavaScript. The replacement function by itself is not the pain point, we've
-already done something similar before:
+There are 4 occurrences of the path `guides/release` and we need to replace them with `guides`. It will mean it's the diff between `guides/accessibility/components.md` and some fictive `guides/accessibility/components.md` coming from the `b` branch. Manually, we would do this with “Find and Replace” in the code editor. Instead, let’s do it in JavaScript. The replacement function by itself is not the pain point, we've already done something similar before:
 
 ```js
 /*
@@ -920,9 +670,7 @@ const unversionPath = stringContent => {
 };
 ```
 
-The question is more about how to use this function to edit files content. Just
-like before, there's a choice to make: `readFile` or `readFileSync`, then
-`writeFile` or `writeFileSync`:
+The question is more about how to use this function to edit files content. Just like before, there's a choice to make: `readFile` or `readFileSync`, then `writeFile` or `writeFileSync`:
 
 ```diff
   const applyPatches = (files) => {
@@ -958,18 +706,9 @@ like before, there's a choice to make: `readFile` or `readFileSync`, then
   }
 ```
 
-With the async method, we don’t know when each "then" will be executed. For
-instance, even if our array is ordered, the file at index 12 could be edited
-before the file at index 3. Would this be a problem in our case? I don’t think
-so. At the end of the day, we want all the files to be edited, we are not
-interested in the execution order. So we can go with the async functions.
+With the async method, we don’t know when each "then" will be executed. For instance, even if our array is ordered, the file at index 12 could be edited before the file at index 3. Would this be a problem in our case? I don’t think so. At the end of the day, we want all the files to be edited, we are not interested in the execution order. So we can go with the async functions.
 
-The asynchronous functions provided by `fs` module are essentially the same as
-the synchronous ones, except that the last argument is a callback function that
-will be executed only once the operation is done. To use the
-[`async/await`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await)
-syntax instead, we can rely on the `fs/promises` module that provides the same
-functions returning a promise.
+The asynchronous functions provided by `fs` module are essentially the same as the synchronous ones, except that the last argument is a callback function that will be executed only once the operation is done. To use the [`async/await`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await) syntax instead, we can rely on the `fs/promises` module that provides the same functions returning a promise.
 
 Here is what the core of the loop should look like:
 
@@ -1008,25 +747,16 @@ const applyPatches = async (files) => { // The function is now async
 }
 ```
 
-🙀 We can't use `async/await` in a `forEach` loop. In the next section, let's
-take a step back and see what the problem is.
+🙀 We can't use `async/await` in a `forEach` loop. In the next section, let's take a step back and see what the problem is.
 
-But let's allow ourselves to be happy with the core of the loop. Inside the
-loop, `git apply` really does what we want it to do! For each patch file created
-and edited, we try to run `git apply`:
+But let's allow ourselves to be happy with the core of the loop. Inside the loop, `git apply` really does what we want it to do! For each patch file created and edited, we try to run `git apply`:
 
-- If the target file is not translated, it works! 🎉 we have the diff
-  automatically applied!
-- If the target file is in French, the command fails. We will reuse the content
-  of the patch file in the body of our GitHub issue.
+- If the target file is not translated, it works! 🎉 we have the diff automatically applied!
+- If the target file is in French, the command fails. We will reuse the content of the patch file in the body of our GitHub issue.
 
 ### d. Waiting for asynchronous operations with `map` and `Promise.all`
 
-Let's go back a second to the script instructions. We have a function
-`applyPatches` that creates all the patch files and tries to apply them. If
-there is at least one markdown file that could be updated automatically, we push
-the changes. If we tracked some patch files that couldn't be applied, we open
-GitHub issues:
+Let's go back a second to the script instructions. We have a function `applyPatches` that creates all the patch files and tries to apply them. If there is at least one markdown file that could be updated automatically, we push the changes. If we tracked some patch files that couldn't be applied, we open GitHub issues:
 
 ```js
 let { filesToPost, hasAutoApply, hasPendingDiff } = applyPatches(files);
@@ -1039,42 +769,15 @@ if (hasAutoApply) {
 }
 ```
 
-The above supposes that once `applyPatches` is executed, `hasAutoApply`,
-`hasPendingDiff` and `filesToPost` have their final value. It used to be the
-case when `applyPatches` was a synchronous function, but we have just made it
-asynchronous. If we simply write the `await` operator before the function
-call... it won't work (at least, not yet). The code will move to the next
-instruction immediately without waiting for `hasAutoApply`, `hasPendingDiff` and
-`filesToPost` to be ready. Why that?
-
-Because of the `forEach` loop in `applyPatches`. We can't use `async/await` in a
-`forEach` loop, because `forEach` is not promise-aware, the iteration doesn't
-return a value so there's no value to potentially wait for, and `forEach` never
-waits to move to the next iteration after an async code is executed. Any value
-returned asynchronously would be ignored. In other words, the `forEach` loop
-starts a series of “read → write” that run in parallel, and as soon as
-everything has started, we leave the loop and the function while the files
-edition is ongoing!
-
-🤔 How do we make sure that all the operations on files are over before
-continuing the execution of the script? It was great to let the script deal with
-all the files as fast as possible without caring about the execution order. If
-we replace `readFile` and `writeFile` with their `Sync` equivalent, we would
-lose this advantage: our script would be slower because it wouldn't be able to
-parallelize the operations.
-
-What we want is to keep the same approach we have now, and do something when we
-know all the files have been handled. To do so, we are going to use the method
-[`map`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map)
-along with the static method
-[`Promise.all`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all)
-provided by JavaScript.
-
-Instead of calling directly the async instructions in a `forEach` loop, we are
-going to store them in an array of promises. Then we'll call
-`await Promise.all(array)` to wait for all the async instructions. This will
-pause the execution until all the promises are fulfilled, and only then we'll
-leave the function:
+The above supposes that once `applyPatches` is executed, `hasAutoApply`, `hasPendingDiff` and `filesToPost` have their final value. It used to be the case when `applyPatches` was a synchronous function, but we have just made it asynchronous. If we simply write the `await` operator before the function call... it won't work (at least, not yet). The code will move to the next instruction immediately without waiting for `hasAutoApply`, `hasPendingDiff` and `filesToPost` to be ready. Why that?
+
+Because of the `forEach` loop in `applyPatches`. We can't use `async/await` in a `forEach` loop, because `forEach` is not promise-aware, the iteration doesn't return a value so there's no value to potentially wait for, and `forEach` never waits to move to the next iteration after an async code is executed. Any value returned asynchronously would be ignored. In other words, the `forEach` loop starts a series of “read → write” that run in parallel, and as soon as everything has started, we leave the loop and the function while the files edition is ongoing!
+
+🤔 How do we make sure that all the operations on files are over before continuing the execution of the script? It was great to let the script deal with all the files as fast as possible without caring about the execution order. If we replace `readFile` and `writeFile` with their `Sync` equivalent, we would lose this advantage: our script would be slower because it wouldn't be able to parallelize the operations.
+
+What we want is to keep the same approach we have now, and do something when we know all the files have been handled. To do so, we are going to use the method [`map`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map) along with the static method [`Promise.all`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all) provided by JavaScript.
+
+Instead of calling directly the async instructions in a `forEach` loop, we are going to store them in an array of promises. Then we'll call `await Promise.all(array)` to wait for all the async instructions. This will pause the execution until all the promises are fulfilled, and only then we'll leave the function:
 
 ```diff
   const applyPatches = async (filename, index) => {
@@ -1119,24 +822,17 @@ leave the function:
   }
 ```
 
-`files.forEach` has become `files.map`: instead of performing instructions at
-each iteration, we rather map our array of filenames to an array of promises.
+`files.forEach` has become `files.map`: instead of performing instructions at each iteration, we rather map our array of filenames to an array of promises.
 
-When we use `return n`, `n` is the data returned by the promise. Each promise
-resolving to an integer means that, when all the promises are fulfilled, the
-`results` returned by `Promise.all` is an array of integers that replaces our
-previous variable `results`.
+When we use `return n`, `n` is the data returned by the promise. Each promise resolving to an integer means that, when all the promises are fulfilled, the `results` returned by `Promise.all` is an array of integers that replaces our previous variable `results`.
 
-With this code, `applyPatches` has become an asynchronous function that we can
-call with `await applyPatches();` and we are all good to post or issues 🎉
+With this code, `applyPatches` has become an asynchronous function that we can call with `await applyPatches();` and we are all good to post or issues 🎉
 
 ## 4. Posting GitHub API requests with Node.js
 
 ### a. Preparing the payload
 
-Let's have a fresh look at the kind of issue we want to open:
-[#213 Translate /addons-and-dependencies/index.md, Ember 5.4](https://github.com/DazzlingFugu/ember-fr-guides-source/issues/213).
-This can be turned into the following payload:
+Let's have a fresh look at the kind of issue we want to open: [#213 Translate /addons-and-dependencies/index.md, Ember 5.4](https://github.com/DazzlingFugu/ember-fr-guides-source/issues/213). This can be turned into the following payload:
 
 ```js
 // The repository of the Ember Guides in French
@@ -1168,23 +864,15 @@ ${diffblock}
 }
 ```
 
-`shorterFilename` is just a way to remove `guides` from the filename to cut the
-issue title down a bit. We can obtain it with a simple
-[`substring`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substring):
+`shorterFilename` is just a way to remove `guides` from the filename to cut the issue title down a bit. We can obtain it with a simple [`substring`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/substring):
 
 ```js
 const shorterName = filename.substring(5);
 ```
 
-`diffblock` is the content of the patch file `diffName` that we write in the
-body of the issue. One little detail to handle is that there are \``` symbols in
-the file content and this can break the body. To solve the problem and because
-we just want to show the diff on GitHub without it being necessarily a valid
-patch file, we can simply remove the \``` symbols from the file.
+`diffblock` is the content of the patch file `diffName` that we write in the body of the issue. One little detail to handle is that there are \``` symbols in the file content and this can break the body. To solve the problem and because we just want to show the diff on GitHub without it being necessarily a valid patch file, we can simply remove the \``` symbols from the file.
 
-Also, the issue body above works only if there _is_ a diff block to paste. If
-the file is new, it means this is the first translation. We can implement a
-function `getIssueBodyDiff` to manage this properly:
+Also, the issue body above works only if there _is_ a diff block to paste. If the file is new, it means this is the first translation. We can implement a function `getIssueBodyDiff` to manage this properly:
 
 ````js
 const getIssueBodyDiff = diffName => {
@@ -1204,9 +892,7 @@ ${diffblock}
 };
 ````
 
-Last but not least, we need a pair `{ filename, diffName }` to know what
-markdown file corresponds to what patch file. This one is quite easy to obtain,
-we can simply turn `filesToPost` into an array of objects:
+Last but not least, we need a pair `{ filename, diffName }` to know what markdown file corresponds to what patch file. This one is quite easy to obtain, we can simply turn `filesToPost` into an array of objects:
 
 ```diff
 // No diff block
@@ -1218,17 +904,11 @@ we can simply turn `filesToPost` into an array of objects:
 + filesToPost.push({ filename: unversionedFileName, diffName });
 ```
 
-Alright! Looks like we have everything we need to complete the payload. Let's
-create a proper request!
+Alright! Looks like we have everything we need to complete the payload. Let's create a proper request!
 
 ### b. Using the fetch API
 
-When we learned how to get the GitHub API `token` earlier, we said that we
-wanted to use the JavaScript method
-[`fetch`](https://developer.mozilla.org/en-US/docs/Web/API/fetch) to request on
-[https://api.github.com/](https://api.github.com/). With a modern Node.js
-version, we don't need any specific import, we can use `fetch` natively. In the
-end, the implementation could look this way:
+When we learned how to get the GitHub API `token` earlier, we said that we wanted to use the JavaScript method [`fetch`](https://developer.mozilla.org/en-US/docs/Web/API/fetch) to request on [https://api.github.com/](https://api.github.com/). With a modern Node.js version, we don't need any specific import, we can use `fetch` natively. In the end, the implementation could look this way:
 
 ```js
 const postIssue = async (file, repo, currentEmberVersion, newEmberVersion) => {
@@ -1278,18 +958,9 @@ for (const file of filesToPost) {
 }
 ```
 
-🤔 This is a regular `for` loop. Using `await` in a good old `for` loop results
-in executing the iterations serially, it pauses the execution and waits for the
-result. It means this code posts the issues one by one. Is it what we want? (of
-course it is 😉)
+🤔 This is a regular `for` loop. Using `await` in a good old `for` loop results in executing the iterations serially, it pauses the execution and waits for the result. It means this code posts the issues one by one. Is it what we want? (of course it is 😉)
 
-In general, you want things to go as fast as possible. But when using GitHub
-API,
-[the recommendation is to send requests serially](https://docs.github.com/en/rest/guides/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#avoid-concurrent-requests),
-so we'll wait for the server to respond before we do the next request. Also,
-let’s follow the documentation's
-[best practices](https://docs.github.com/en/rest/guides/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#pause-between-mutative-requests)
-and set a timeout of 1 second after each request to avoid secondary rate limits:
+In general, you want things to go as fast as possible. But when using GitHub API, [the recommendation is to send requests serially](https://docs.github.com/en/rest/guides/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#avoid-concurrent-requests), so we'll wait for the server to respond before we do the next request. Also, let’s follow the documentation's [best practices](https://docs.github.com/en/rest/guides/best-practices-for-using-the-rest-api?apiVersion=2022-11-28#pause-between-mutative-requests) and set a timeout of 1 second after each request to avoid secondary rate limits:
 
 ```diff
   for (const file of filesToPost) {
@@ -1306,8 +977,7 @@ and set a timeout of 1 second after each request to avoid secondary rate limits:
   }
 ```
 
-Alright! Let's go back for a second to our main `try...catch` and add our loop
-here:
+Alright! Let's go back for a second to our main `try...catch` and add our loop here:
 
 ```diff
     let { filesToPost, hasAutoApply, hasPendingDiff } = await applyPatches(files);
@@ -1322,9 +992,7 @@ here:
 
 ### c. Opening a PR with GitHub API
 
-After we push the changes to GitHub, we can open the "catch-up PR" using GitHub
-API. It's essentially the same thing as GitHub issues, except that you need to
-specify what branch you want to merge into what other branch:
+After we push the changes to GitHub, we can open the "catch-up PR" using GitHub API. It's essentially the same thing as GitHub issues, except that you need to specify what branch you want to merge into what other branch:
 
 ```js
 const openCatchupPR = async (
@@ -1382,36 +1050,13 @@ Sounds like our script is ready to work! We learned how to:
 
 This is it!
 
-There are still a couple of details we can add to improve the script. Here are a
-few examples of things we could do, and there are certainly more:
-
-- rework the logs to have a clear list of "required actions" the developer has
-  to do manually when the process exits with warnings. For instance, if a GitHub
-  issue wasn't posted.
-- if there's a bit more time, offer the possibility to retry sending a failed
-  request.
-- in terms of clean-up, we could also remove the files we created and the
-  `scripts/patches` folder if all the GitHub issues have been posted correctly.
-- replace the usage of `existsSync()` with `await stats()` now that the function
-  calling it is asynchronous.
-
-On a different matter, we could also write some tests to make sure the script
-does what we think it does. Such tests don't exist yet as I am writing these
-lines. To check the render of the issues and what the catch-up PR looks like, I
-did what I usually do: manual process first, then switch to the automation when
-I am clear with what I want. I created a sandbox project that contains only a
-`guides/release/` folder with a couple of fake markdown files, then I forked it
-and added the `catchup.mjs` to the fork along with a package manager to import
-the few dependencies the script needs. By committing to the upstream sandbox, I
-could test many cases, including some that never occurred in the real guides so
-far, like the deletion of markdown files.
-
-As said at the beginning of this article, none of this answers the question "how
-to bootstrap a translation project, what's the best approach to use?". However,
-all the above may have convinced you that maintenance automation is not that big
-of a deal. And it's an iterative process, too. I could have started using this
-script to automate the git commands before it was able to do the API requests. I
-did start using it before it was able to handle new markdown files, and I
-iterated on the code again afterward. Even now that it's complete, there are
-certainly improvements to make, but it doesn't prevent me from using the script
-and saving time today 😉.
+There are still a couple of details we can add to improve the script. Here are a few examples of things we could do, and there are certainly more:
+
+- rework the logs to have a clear list of "required actions" the developer has to do manually when the process exits with warnings. For instance, if a GitHub issue wasn't posted.
+- if there's a bit more time, offer the possibility to retry sending a failed request.
+- in terms of clean-up, we could also remove the files we created and the `scripts/patches` folder if all the GitHub issues have been posted correctly.
+- replace the usage of `existsSync()` with `await stats()` now that the function calling it is asynchronous.
+
+On a different matter, we could also write some tests to make sure the script does what we think it does. Such tests don't exist yet as I am writing these lines. To check the render of the issues and what the catch-up PR looks like, I did what I usually do: manual process first, then switch to the automation when I am clear with what I want. I created a sandbox project that contains only a `guides/release/` folder with a couple of fake markdown files, then I forked it and added the `catchup.mjs` to the fork along with a package manager to import the few dependencies the script needs. By committing to the upstream sandbox, I could test many cases, including some that never occurred in the real guides so far, like the deletion of markdown files.
+
+As said at the beginning of this article, none of this answers the question "how to bootstrap a translation project, what's the best approach to use?". However, all the above may have convinced you that maintenance automation is not that big of a deal. And it's an iterative process, too. I could have started using this script to automate the git commands before it was able to do the API requests. I did start using it before it was able to handle new markdown files, and I iterated on the code again afterward. Even now that it's complete, there are certainly improvements to make, but it doesn't prevent me from using the script and saving time today 😉.
diff --git a/src/posts/2024-02-29-launching-rustrover.md b/src/posts/2024-02-29-launching-rustrover.md
index b3ee138bfd..f3328a748b 100644
--- a/src/posts/2024-02-29-launching-rustrover.md
+++ b/src/posts/2024-02-29-launching-rustrover.md
@@ -3,10 +3,7 @@ title: "Launching RustRover: JetBrains’ Investment in Rust"
 authorHandle: algo_luca
 tags: [rust]
 bio: "Luca Palmieri, Principal Engineering Consultant"
-description:
-  "JetBrains' Vitaly Bragilevsky and Luca Palmieri discuss the reasons behind
-  the launch of RustRover, the current state of Rust's ecosystem, and the status
-  quo of developer tooling for Rust."
+description: "JetBrains' Vitaly Bragilevsky and Luca Palmieri discuss the reasons behind the launch of RustRover, the current state of Rust's ecosystem, and the status quo of developer tooling for Rust."
 og:
   image: "/assets/images/posts/2024-02-29-launching-rustrover/og-image.png"
 tagline: |
@@ -18,28 +15,12 @@ image: "/assets/images/posts/2024-02-29-launching-rustrover/header.jpg"
 imageAlt: "Vitaly's picture on a gray background"
 ---
 
-Vitaly begins the interview by sharing how he went from teaching Haskell to
-promoting Rust and how Rust differs from other languages in memory management.
-Luca and he then discuss how Rust's memory handling can be tricky, especially
-compared to Haskell, and how Rust's way of writing code may be more challenging
-to understand for some developers.
+Vitaly begins the interview by sharing how he went from teaching Haskell to promoting Rust and how Rust differs from other languages in memory management. Luca and he then discuss how Rust's memory handling can be tricky, especially compared to Haskell, and how Rust's way of writing code may be more challenging to understand for some developers.
 
-Vitaly talks about JetBrains’ decision to make a tool just for Rust,
-highlighting their intention of supporting Rust developers. He says there's a
-gap between the number of tools available for Rust and how many people are using
-them and stresses the importance of user feedback to improve said tools. Luca
-adds that there are cultural and educational reasons why Rust developers might
-not use tools like debuggers.
+Vitaly talks about JetBrains’ decision to make a tool just for Rust, highlighting their intention of supporting Rust developers. He says there's a gap between the number of tools available for Rust and how many people are using them and stresses the importance of user feedback to improve said tools. Luca adds that there are cultural and educational reasons why Rust developers might not use tools like debuggers.
 
-Vitaly then discusses JetBrains’ potential role in providing more professional
-tools for Rust as the language becomes more popular in different areas beyond
-web development. He warns that making Rust too complicated might turn some
-people away and emphasizes how JetBrains is working on making it easier for
-developers to learn and use Rust with their tools.
+Vitaly then discusses JetBrains’ potential role in providing more professional tools for Rust as the language becomes more popular in different areas beyond web development. He warns that making Rust too complicated might turn some people away and emphasizes how JetBrains is working on making it easier for developers to learn and use Rust with their tools.
 
-Luca and Vitaly also mention how Rust is becoming more popular for backend
-development because of its performance and safety features. Vitaly concludes the
-interview by encouraging viewers to give feedback on JetBrains' RustRover to
-improve it.
+Luca and Vitaly also mention how Rust is becoming more popular for backend development because of its performance and safety features. Vitaly concludes the interview by encouraging viewers to give feedback on JetBrains' RustRover to improve it.
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/cc-o1UMw__M" title="Embedded video of Vitaly's interview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
diff --git a/src/posts/2024-03-18-cargo-autoinherit.md b/src/posts/2024-03-18-cargo-autoinherit.md
index 3357be49c0..c0abbc5a5b 100644
--- a/src/posts/2024-03-18-cargo-autoinherit.md
+++ b/src/posts/2024-03-18-cargo-autoinherit.md
@@ -3,23 +3,16 @@ title: "cargo-autoinherit: DRY up your workspace dependencies"
 authorHandle: algo_luca
 tags: [rust]
 bio: "Luca Palmieri, Principal Engineering Consultant"
-description:
-  "cargo-autoinherit is a new Cargo subcommand that converts your Cargo
-  workspace to use dependency inheritance, wherever possible. It helps you to
-  keep your dependencies DRY, reducing the risk of version mismatches and
-  unnecessary duplication."
+description: "cargo-autoinherit is a new Cargo subcommand that converts your Cargo workspace to use dependency inheritance, wherever possible. It helps you to keep your dependencies DRY, reducing the risk of version mismatches and unnecessary duplication."
 og:
   image: /assets/images/posts/2024-03-18-cargo-autoinherit/og-image.png
 image: "/assets/images/posts/2024-03-18-cargo-autoinherit/cargo_rust.png"
 imageAlt: "The Rust logo on a background showing cargo containers"
 ---
 
-[`cargo-autoinherit`] is a new Cargo subcommand that automatically DRYs up your
-workspace dependencies using
-[dependency inheritance](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace).
+[`cargo-autoinherit`] is a new Cargo subcommand that automatically DRYs up your workspace dependencies using [dependency inheritance](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace).
 
-You can find prebuilt binaries on
-[GitHub's Releases page](https://github.com/mainmatter/cargo-autoinherit/releases).  
+You can find prebuilt binaries on [GitHub's Releases page](https://github.com/mainmatter/cargo-autoinherit/releases).  
 Alternatively, you can build from source:
 
 ```bash
@@ -37,27 +30,18 @@ cargo install --locked cargo-autoinherit
 
 ## The problem
 
-When you have multiple packages in a Cargo workspace, you often end up depending
-on the same packages in multiple `Cargo.toml` files.  
+When you have multiple packages in a Cargo workspace, you often end up depending on the same packages in multiple `Cargo.toml` files.  
 This duplication can become an issue:
 
-- When you want to update a dependency, you have to update it in multiple
-  places.
-- When you need to add a new dependency, you first have to check if it's already
-  used in another package of your workspace to keep versions in sync.
+- When you want to update a dependency, you have to update it in multiple places.
+- When you need to add a new dependency, you first have to check if it's already used in another package of your workspace to keep versions in sync.
 
 This process is error-prone and tedious.  
-If you mess it up, you end up with different versions of the same dependency
-within your workspace. This can lead to hard-to-debug compilation errors or
-bloat your artifacts with unnecessary copies of the same package.
+If you mess it up, you end up with different versions of the same dependency within your workspace. This can lead to hard-to-debug compilation errors or bloat your artifacts with unnecessary copies of the same package.
 
 ## The solution
 
-The solution to this problem is to use
-[dependency inheritance](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace),
-a recent Cargo feature: you can specify dependencies once, in the root
-`Cargo.toml` of your workspace, and then refer to that centralized list from the
-members' `Cargo.toml` files.
+The solution to this problem is to use [dependency inheritance](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#inheriting-a-dependency-from-a-workspace), a recent Cargo feature: you can specify dependencies once, in the root `Cargo.toml` of your workspace, and then refer to that centralized list from the members' `Cargo.toml` files.
 
 In practice, it looks like this:
 
@@ -77,25 +61,16 @@ Nice and DRY!
 
 ## The casus belli
 
-A couple of weeks ago I had some maintenance work on the agenda: update all
-dependencies in
-[Mainmatter's Rust telemetry workshop](https://github.com/mainmatter/rust-telemetry-workshop).
-Each step of the workshop is a separate Cargo package, for a grand total of 30
-`Cargo.toml` files in a single workspace.
+A couple of weeks ago I had some maintenance work on the agenda: update all dependencies in [Mainmatter's Rust telemetry workshop](https://github.com/mainmatter/rust-telemetry-workshop). Each step of the workshop is a separate Cargo package, for a grand total of 30 `Cargo.toml` files in a single workspace.
 
-When I wrote the workshop, I didn't have the foresight to use dependency
-inheritance. I now had to go through each `Cargo.toml` file, centralize the
-dependencies in the root `Cargo.toml`, and then update the members' `Cargo.toml`
-files to use the new `workspace` syntax.
+When I wrote the workshop, I didn't have the foresight to use dependency inheritance. I now had to go through each `Cargo.toml` file, centralize the dependencies in the root `Cargo.toml`, and then update the members' `Cargo.toml` files to use the new `workspace` syntax.
 
-The work was beyond tedious and I thought: "There must be a tool to automate
-this!"  
+The work was beyond tedious and I thought: "There must be a tool to automate this!"  
 There wasn't, so I wrote one.
 
 ## `cargo-autoinherit`
 
-[`cargo-autoinherit`] is a Cargo subcommand that helps you to keep your
-dependencies DRY.
+[`cargo-autoinherit`] is a Cargo subcommand that helps you to keep your dependencies DRY.
 
 You invoke it from the root of your workspace:
 
@@ -104,15 +79,11 @@ You invoke it from the root of your workspace:
 cargo autoinherit
 ```
 
-It collects all the dependencies used by your workspace members, determines
-which ones can be DRYed and moves them to the `[workspace.dependencies]` section
-of the root `Cargo.toml`. It also takes care of updating the members'
-`Cargo.toml` files, setting the correct `features` field for each package.
+It collects all the dependencies used by your workspace members, determines which ones can be DRYed and moves them to the `[workspace.dependencies]` section of the root `Cargo.toml`. It also takes care of updating the members' `Cargo.toml` files, setting the correct `features` field for each package.
 
 ### Installation
 
-You can find prebuilt binaries on
-[GitHub's Releases page](https://github.com/mainmatter/cargo-autoinherit/releases).  
+You can find prebuilt binaries on [GitHub's Releases page](https://github.com/mainmatter/cargo-autoinherit/releases).  
 Alternatively, you can build from source:
 
 ```bash
@@ -125,13 +96,8 @@ There are a few limitations to be aware of when using `cargo-autoinherit`:
 
 - It won't auto-inherit path dependencies.
 - It won't auto-inherit dependencies from private registries.
-- It will only merge version requirements that are obviously compatible (e.g.
-  `^1.0.0` and `^1.1.5` will be merged to `^1.1.5`, but `^1.0.0` and `>=1,<2`
-  won't be merged).
-
-Beyond known limitations, keep in mind that [`cargo-autoinherit`] is a young
-project. We tested it on a few workspaces, but there might be edge cases we
-haven't encountered yet. If you find a bug, please open an issue on the
-[GitHub repository](https://github.com/mainmatter/cargo-autoinherit).
+- It will only merge version requirements that are obviously compatible (e.g. `^1.0.0` and `^1.1.5` will be merged to `^1.1.5`, but `^1.0.0` and `>=1,<2` won't be merged).
+
+Beyond known limitations, keep in mind that [`cargo-autoinherit`] is a young project. We tested it on a few workspaces, but there might be edge cases we haven't encountered yet. If you find a bug, please open an issue on the [GitHub repository](https://github.com/mainmatter/cargo-autoinherit).
 
 [`cargo-autoinherit`]: https://github.com/mainmatter/cargo-autoinherit
diff --git a/src/posts/2024-03-27-embeddable-ember-apps.md b/src/posts/2024-03-27-embeddable-ember-apps.md
index 63e9637b1f..284212b9b0 100644
--- a/src/posts/2024-03-27-embeddable-ember-apps.md
+++ b/src/posts/2024-03-27-embeddable-ember-apps.md
@@ -3,9 +3,7 @@ title: "Embedding an Ember App with Webpack"
 authorHandle: BobrImperator
 tags: [ember]
 bio: "Software Developer"
-description:
-  "Bartlomiej Dudzik shows how to make an Ember App embeddable in non-Ember
-  projects."
+description: "Bartlomiej Dudzik shows how to make an Ember App embeddable in non-Ember projects."
 og:
   image: /assets/images/posts/2024-03-27-embeddable-ember-apps/og-image.png
 image: /assets/images/posts/2024-03-27-embeddable-ember-apps/header.jpg
@@ -16,21 +14,11 @@ imageAlt: Embeddable Ember Apps image
 
 #### What we're working with
 
-We'll make a simple Ember to-do app (what else could it be :)) that's then
-loaded inside another non-Ember app. Use cases may vary, but probably the two
-most common ones are a widget that requires visualizing data like maps or
-micro-frontends that may need to share data between each other.
+We'll make a simple Ember to-do app (what else could it be :)) that's then loaded inside another non-Ember app. Use cases may vary, but probably the two most common ones are a widget that requires visualizing data like maps or micro-frontends that may need to share data between each other.
 
-The goal of this post is to show how to wrangle Ember's build system and how a
-potential integration between applications could look like.
+The goal of this post is to show how to wrangle Ember's build system and how a potential integration between applications could look like.
 
-The easiest approach for making the app embeddable would be to bundle its
-scripts into single JS and CSS files. This is an additional build step we have
-to handle manually as, by default, Webpack splits code into chunks, and while
-that could be disabled, the Ember-cli itself also always splits code into
-`vendor.js` and `app.js` files. In the "old Ember" we'd use a tool such as
-`ember-cli-concat` to do that, but with Embroider, we need to take care of
-things through Webpack.
+The easiest approach for making the app embeddable would be to bundle its scripts into single JS and CSS files. This is an additional build step we have to handle manually as, by default, Webpack splits code into chunks, and while that could be disabled, the Ember-cli itself also always splits code into `vendor.js` and `app.js` files. In the "old Ember" we'd use a tool such as `ember-cli-concat` to do that, but with Embroider, we need to take care of things through Webpack.
 
 The end goal is to be able to include a script like so:
 
@@ -47,26 +35,17 @@ await app.start();
 
 ##### Combining JS
 
-This, in my opinion, is the most complicated step and unfortunately for the
-wrong reasons. When you're working with Ember, you yourself define and import
-files as ES6 modules. During build, they are then compiled as AMD modules,
-meaning that your application needs to bring a `requirejs` runtime with it.
+This, in my opinion, is the most complicated step and unfortunately for the wrong reasons. When you're working with Ember, you yourself define and import files as ES6 modules. During build, they are then compiled as AMD modules, meaning that your application needs to bring a `requirejs` runtime with it.
 
-What it means for us is that we need to make sure that the `requirejs` runtime
-is the very first thing in the bundle file. Ember apps provide that inside the
-`vendor.js` script that precedes the other scripts inside an `index.html` entry
-point.
+What it means for us is that we need to make sure that the `requirejs` runtime is the very first thing in the bundle file. Ember apps provide that inside the `vendor.js` script that precedes the other scripts inside an `index.html` entry point.
 
-A few Webpack plugins do concatenation, but there's nuance to handling
-concatenation, because we must ensure that the `vendor.js` file is at the top
-and is processed first. For this reason, I recommend rolling out your own.
+A few Webpack plugins do concatenation, but there's nuance to handling concatenation, because we must ensure that the `vendor.js` file is at the top and is processed first. For this reason, I recommend rolling out your own.
 
 The Webpack plugin needs to:
 
 - run after compilation is finished,
 - lookup all the js files it produced,
-- sort files so `vendor` is first (the order of other files and chunks doesn't
-  matter),
+- sort files so `vendor` is first (the order of other files and chunks doesn't matter),
 - concatenate contents of all the JavasSript files into a single file.
 
 ```js
@@ -131,10 +110,7 @@ class FileConcatenationPlugin {
 
 Now `ember-cli-build` needs to be configured:
 
-- set `storeConfigInMeta` to `false` so configuration is defined in
-  `config/environment.js` is embedded directly with the application code as
-  opposed to the default behavior where your configuration would be a part of
-  some separate tag inside `index.html`,
+- set `storeConfigInMeta` to `false` so configuration is defined in `config/environment.js` is embedded directly with the application code as opposed to the default behavior where your configuration would be a part of some separate tag inside `index.html`,
 - use our defined plugin,
 - (optionally) set the Embroider static flags.
 
@@ -171,21 +147,15 @@ module.exports = function (defaults) {
 
 ##### Combining CSS
 
-My recommendation is to opt out of the default styles CSS handling that Ember
-provides and do it on our own. The reason being that `ember-cli` doesn't seem to
-be using Webpack directly and it's not straightforward to know how and when to
-concatenate them.
+My recommendation is to opt out of the default styles CSS handling that Ember provides and do it on our own. The reason being that `ember-cli` doesn't seem to be using Webpack directly and it's not straightforward to know how and when to concatenate them.
 
-Luckily, a basic PostCSS setup isn't scary and is more common nowadays, and even
-recommended.
+Luckily, a basic PostCSS setup isn't scary and is more common nowadays, and even recommended.
 
 First, let's define the styles:
 
 - install packages `npm install postcss-loader mini-css-extract-plugin -D`,
-- create an `app.css` file in the `app` directory - on the same level as
-  `app.js`,
-- scope the styles to `.ember-todo-test` to avoid style collisions with projects
-  that embed the app (especially if you plan to use tools such as tailwind).
+- create an `app.css` file in the `app` directory - on the same level as `app.js`,
+- scope the styles to `.ember-todo-test` to avoid style collisions with projects that embed the app (especially if you plan to use tools such as tailwind).
 
 ```css
 /* app/app.css */
@@ -246,17 +216,11 @@ module.exports = function (defaults) {
 };
 ```
 
-_If you're interested in a full tailwind setup, tailwindcss's official
-documentation has an excellent
-[tutorial](https://tailwindcss.com/docs/guides/emberjs). Only a tiny amount of
-extending what I've already shown is needed._
+_If you're interested in a full tailwind setup, tailwindcss's official documentation has an excellent [tutorial](https://tailwindcss.com/docs/guides/emberjs). Only a tiny amount of extending what I've already shown is needed._
 
 #### Booting up the application on our own terms
 
-The application is only a few lines of code living inside `application.js`,
-`application.hbs` and `app.js` - there's also a `todo-list.gjs` that I won't
-show in this post in order to save some space, but you'll find a link to the
-rest of the code at the bottom.
+The application is only a few lines of code living inside `application.js`, `application.hbs` and `app.js` - there's also a `todo-list.gjs` that I won't show in this post in order to save some space, but you'll find a link to the rest of the code at the bottom.
 
 ```js
 import Controller from "@ember/controller";
@@ -293,20 +257,11 @@ export default class ApplicationController extends Controller {
 {{outlet}} {% endraw %}
 ```
 
-Some of the last shenanigans can be found in the `app.js` file. The only change
-that the default `app.js` has is the `autoboot = false` option. It makes sure
-that the app won't boot by default where usually it'd attempt to load and mount
-itself to `body` or `rootElement` configuration found in
-`config/environment.js`.
+Some of the last shenanigans can be found in the `app.js` file. The only change that the default `app.js` has is the `autoboot = false` option. It makes sure that the app won't boot by default where usually it'd attempt to load and mount itself to `body` or `rootElement` configuration found in `config/environment.js`.
 
-Below it, we add a `MyEmbeddedApp` class wrapper. Its job is to take over the
-App initialization as well as serve as a communication layer between the App and
-whoever uses it.
+Below it, we add a `MyEmbeddedApp` class wrapper. Its job is to take over the App initialization as well as serve as a communication layer between the App and whoever uses it.
 
-There's probably a few different ways to organize this. Here, for simplicity,
-the wrapper talks to the `application` controller directly, but, if you have a
-more complicated use case, you could use services, proper events, and such to do
-the job.
+There's probably a few different ways to organize this. Here, for simplicity, the wrapper talks to the `application` controller directly, but, if you have a more complicated use case, you could use services, proper events, and such to do the job.
 
 ```js
 import Application from "@ember/application";
@@ -374,17 +329,11 @@ class MyEmbeddedApp {
 
 #### Build, Deploy and Use
 
-Now the App can be built: run the build script as usual `npm run build` and
-deploy the `dist` to your static server or publish as an npm package.
+Now the App can be built: run the build script as usual `npm run build` and deploy the `dist` to your static server or publish as an npm package.
 
-Then add `script` and `link` tags pointing to the deployed bundles and
-initialize the App.
+Then add `script` and `link` tags pointing to the deployed bundles and initialize the App.
 
-In this [Embeddable Demo](https://svelte-todo-13xa.onrender.com), the app is
-initialized when a `<div>` element is inserted. The app is initialized twice
-with different configurations; one configuration allows to remove items, the
-other doesn't. Also, both configurations set up a callback that will be called
-when to-do items have changed and will then display their count.
+In this [Embeddable Demo](https://svelte-todo-13xa.onrender.com), the app is initialized when a `<div>` element is inserted. The app is initialized twice with different configurations; one configuration allows to remove items, the other doesn't. Also, both configurations set up a callback that will be called when to-do items have changed and will then display their count.
 
 ```html
 {% raw %}
@@ -449,28 +398,14 @@ when to-do items have changed and will then display their count.
 
 #### Considerations
 
-- The embeddable app is initialized under the assumption that the script was
-  already loaded beforehand, making it difficult when loading asynchronously.
-  Instead of providing and using the bundles directly, it could be a good idea
-  to create a tiny wrapping script whose only job is to append script tags and
-  expose a promise or hook to notify that they're loaded.
-- Depending on the use case, an iframe could be simpler. On the other hand, this
-  approach gives the most flexibility when it's necessary to allow manipulating
-  the embedded app at runtime.
+- The embeddable app is initialized under the assumption that the script was already loaded beforehand, making it difficult when loading asynchronously. Instead of providing and using the bundles directly, it could be a good idea to create a tiny wrapping script whose only job is to append script tags and expose a promise or hook to notify that they're loaded.
+- Depending on the use case, an iframe could be simpler. On the other hand, this approach gives the most flexibility when it's necessary to allow manipulating the embedded app at runtime.
 
 #### Summary
 
-Embedding an Ember app isn't impossible or super hard but it is quirky,
-requiring understanding and working through the nuances of the build step
-responsibilities. Currently, the Embroider build feels like Webpack with
-Ember-cli on top, where we have both old and new systems to be mindful of when
-building the app.
-
-However, there is a future where this will become much easier! The
-[Embroider Initiative](/ember-initiative/) is working its way towards full Vite
-support which should relief Ember from using the AMD format and allow for a much
-easier process where bundler users would only import that single class which
-initializes the App.
+Embedding an Ember app isn't impossible or super hard but it is quirky, requiring understanding and working through the nuances of the build step responsibilities. Currently, the Embroider build feels like Webpack with Ember-cli on top, where we have both old and new systems to be mindful of when building the app.
+
+However, there is a future where this will become much easier! The [Embroider Initiative](/ember-initiative/) is working its way towards full Vite support which should relief Ember from using the AMD format and allow for a much easier process where bundler users would only import that single class which initializes the App.
 
 #### Resources
 
diff --git a/src/posts/2024-04-08-introducing-svelte-promise-modals.md b/src/posts/2024-04-08-introducing-svelte-promise-modals.md
index e016dfd8ff..178aab3ada 100644
--- a/src/posts/2024-04-08-introducing-svelte-promise-modals.md
+++ b/src/posts/2024-04-08-introducing-svelte-promise-modals.md
@@ -3,36 +3,24 @@ title: "Introducing Svelte Promise Modals"
 authorHandle: zeppelin
 tags: [svelte]
 bio: "Gabor Babicz, Senior Software Engineer"
-description:
-  "Gabor Babicz presents Mainmatter's svelte-promise-modals, a library to
-  implement modals in a few lines of code, following the async patterns that are
-  already in your Svelte app"
+description: "Gabor Babicz presents Mainmatter's svelte-promise-modals, a library to implement modals in a few lines of code, following the async patterns that are already in your Svelte app"
 og:
   image: "/assets/images/posts/2024-04-08-introducing-svelte-promise-modals/og-image.png"
 image: "/assets/images/posts/2024-04-08-introducing-svelte-promise-modals/header-visual.png"
 imageAlt: "The Svelte logo on a grey background picture"
 ---
 
-> TL;DR: Mainmatter released a library to implement modals in a few lines of
-> code, following the async patterns that are already in your Svelte app. It's
-> called Svelte Promise Modals and you can find it here:
-> [svelte-promise-modals.com](https://svelte-promise-modals.com)
+> TL;DR: Mainmatter released a library to implement modals in a few lines of code, following the async patterns that are already in your Svelte app. It's called Svelte Promise Modals and you can find it here: [svelte-promise-modals.com](https://svelte-promise-modals.com)
 
-What's your favorite async pattern? I bet it's promises! They're so easy to use,
-we tend to forget sometimes how hard life was when all we had were callbacks.
+What's your favorite async pattern? I bet it's promises! They're so easy to use, we tend to forget sometimes how hard life was when all we had were callbacks.
 
-Let's unwrap async a bit. It's not the first thing that comes to our mind when
-thinking about modal dialogs, right? But if we think about it, they are
-obtaining user input, be it complex data or simple acknowledgment, which is
-inherently async - similarly to fetching data from a server, but instead of API
-calls, we get data back through a user interface.
+Let's unwrap async a bit. It's not the first thing that comes to our mind when thinking about modal dialogs, right? But if we think about it, they are obtaining user input, be it complex data or simple acknowledgment, which is inherently async - similarly to fetching data from a server, but instead of API calls, we get data back through a user interface.
 
 I mean look at the similarities:
 
 ![Comparison of asynchronism of sending a request and opening a modal dialog](/assets/images/posts/2024-04-08-introducing-svelte-promise-modals/async-comparison.png)
 
-Now let's look at the common implementations for the above two, pretty similar
-tasks:
+Now let's look at the common implementations for the above two, pretty similar tasks:
 
 Network request:
 
@@ -78,17 +66,11 @@ Confirmation modal:
 {% endraw %}
 ```
 
-Despite all the similarities in asynchronism, their implementation differs
-greatly. Why are we using ancient async patterns for modals such as callbacks
-and deal with visibility state management ourselves? Wouldn't it be easier to
-just write `let result = await openModal()` and get back the result of the user
-interaction?
+Despite all the similarities in asynchronism, their implementation differs greatly. Why are we using ancient async patterns for modals such as callbacks and deal with visibility state management ourselves? Wouldn't it be easier to just write `let result = await openModal()` and get back the result of the user interaction?
 
-Sure it is, and now we can! Enter **Svelte Promise Modals**, that brings the
-battle-tested _Ember Promise Modals_ to Svelte.
+Sure it is, and now we can! Enter **Svelte Promise Modals**, that brings the battle-tested _Ember Promise Modals_ to Svelte.
 
-Let's write the above two async operations _together_ as we normally would, with
-the ideal API in mind:
+Let's write the above two async operations _together_ as we normally would, with the ideal API in mind:
 
 ```js
 async function clearShoppingList(id) {
@@ -105,30 +87,12 @@ async function clearShoppingList(id) {
 }
 ```
 
-Much cleaner, huh? _Hint: this is exactly the API Svelte Promise Modal
-provides._ No callbacks, no `isModalOpened` - everything is neatly organized.
-
-Now that _our_ developer experience is fixed, we may want to think about our
-users: what is one of the most common usability and accessibility issues with
-modal dialogs? The answer is, without a doubt, the lack of well-constrained
-keyboard navigation. Imagine pressing the TAB key multiple times to jump between
-inputs and buttons. What happens is when we reach the end of the modal dialog,
-the next focusable element will likely be in the document, _underneath the
-modal_. Pressing TAB one too many time, and we're out of our modal, where we
-really shouldn't be in that moment.  
-Luckily, this fundamental use-case is covered out of the box! With Svelte
-Promise Modals, every modal dialog's user input is, _"trapped"_ by using the
-excellent library called `focus-trap`, which ensures navigation between form
-elements won't accidentally leave our users baffled. Pressing the TAB key only
-means that after the last input, the focus is again on the first element _inside
-the modal_.
+Much cleaner, huh? _Hint: this is exactly the API Svelte Promise Modal provides._ No callbacks, no `isModalOpened` - everything is neatly organized.
+
+Now that _our_ developer experience is fixed, we may want to think about our users: what is one of the most common usability and accessibility issues with modal dialogs? The answer is, without a doubt, the lack of well-constrained keyboard navigation. Imagine pressing the TAB key multiple times to jump between inputs and buttons. What happens is when we reach the end of the modal dialog, the next focusable element will likely be in the document, _underneath the modal_. Pressing TAB one too many time, and we're out of our modal, where we really shouldn't be in that moment.  
+Luckily, this fundamental use-case is covered out of the box! With Svelte Promise Modals, every modal dialog's user input is, _"trapped"_ by using the excellent library called `focus-trap`, which ensures navigation between form elements won't accidentally leave our users baffled. Pressing the TAB key only means that after the last input, the focus is again on the first element _inside the modal_.
 
 ![Video showing tab cycle of focusable elements inside a modal dialog](/assets/images/posts/2024-04-08-introducing-svelte-promise-modals/focus-cycle.mp4#video)
 
-With both the developer and the user end of working with modal dialogs being
-modern, usable and accessible, we think you'll love Svelte Promise Modals.  
-There are several topic that are not covered in this blog post, so be sure to
-check out the [website](https://svelte-promise-modals.com) and the
-[README](https://github.com/mainmatter/svelte-promise-modals?tab=readme-ov-file)
-to learn about passing and receiving data to and from the modal, animations,
-type safety, and more!
+With both the developer and the user end of working with modal dialogs being modern, usable and accessible, we think you'll love Svelte Promise Modals.  
+There are several topic that are not covered in this blog post, so be sure to check out the [website](https://svelte-promise-modals.com) and the [README](https://github.com/mainmatter/svelte-promise-modals?tab=readme-ov-file) to learn about passing and receiving data to and from the modal, animations, type safety, and more!
diff --git a/src/posts/2024-04-11-fiberplanes-three-year-rust-journey.md b/src/posts/2024-04-11-fiberplanes-three-year-rust-journey.md
index 276a8e7f79..cdfd738f12 100644
--- a/src/posts/2024-04-11-fiberplanes-three-year-rust-journey.md
+++ b/src/posts/2024-04-11-fiberplanes-three-year-rust-journey.md
@@ -3,10 +3,7 @@ title: "Exploring Fiberplane's 3-Year Rust Journey"
 authorHandle: algo_luca
 tags: [rust]
 bio: "Principal Engineering Consultant"
-description:
-  "Fiberplane's Benno van den Berg and Luca Palmieri discuss Fiberplane’s
-  reasons for choosing Rust and their 3-year experience maintaining a large Rust
-  codebase and building an observability product."
+description: "Fiberplane's Benno van den Berg and Luca Palmieri discuss Fiberplane’s reasons for choosing Rust and their 3-year experience maintaining a large Rust codebase and building an observability product."
 og:
   image: "/assets/images/posts/2024-04-11-fiberplanes-three-year-rust-journey/og-image.png"
 tagline: |
@@ -18,22 +15,10 @@ image: "/assets/images/posts/2024-04-11-fiberplanes-three-year-rust-journey/head
 imageAlt: "Benno's picture on a gray background"
 ---
 
-Benno kicks off the interview by tracing his personal experience switching from
-.NET to Rust and the beginning of his career at
-[Fiberplane](https://fiberplane.com/). He then describes Fiberplane’s current
-offer, which includes a collaborative notebook product and an observability
-product, [Autometrics](https://fiberplane.com/autometrics).
+Benno kicks off the interview by tracing his personal experience switching from .NET to Rust and the beginning of his career at [Fiberplane](https://fiberplane.com/). He then describes Fiberplane’s current offer, which includes a collaborative notebook product and an observability product, [Autometrics](https://fiberplane.com/autometrics).
 
-Benno and Luca discuss Fiberplane’s reasons for choosing Rust and their
-experience thus far with the language. Benno highlights Rust's consistency in
-building API servers and frontend tools and emphasizes the importance of
-automation for the maintaince of large codebases. They also reflect on lessons
-learned from the challenges of working on Fiberplane’s codebase, citing
-monolithic structure and poor organization causing slow compile times.
+Benno and Luca discuss Fiberplane’s reasons for choosing Rust and their experience thus far with the language. Benno highlights Rust's consistency in building API servers and frontend tools and emphasizes the importance of automation for the maintaince of large codebases. They also reflect on lessons learned from the challenges of working on Fiberplane’s codebase, citing monolithic structure and poor organization causing slow compile times.
 
-Benno and Luca conclude the interview by delving into Benno’s tips for Rust job
-seekers from a recruiter’s perspective: he encourages collecting hands-on
-experience with Rust and embracing compiler errors as a guide while learning the
-language.
+Benno and Luca conclude the interview by delving into Benno’s tips for Rust job seekers from a recruiter’s perspective: he encourages collecting hands-on experience with Rust and embracing compiler errors as a guide while learning the language.
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/wCASwxfPBGM" title="Embedded video of Benno's interview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
diff --git a/src/posts/2024-05-29-embroider-update.md b/src/posts/2024-05-29-embroider-update.md
index bf74b48fc5..c667e8ba70 100644
--- a/src/posts/2024-05-29-embroider-update.md
+++ b/src/posts/2024-05-29-embroider-update.md
@@ -3,9 +3,7 @@ title: "Embroider Initiative: Progress Update"
 authorHandle: academierenards
 tags: [ember, embroider]
 bio: "Marine Dunstetter, Senior Software Engineer"
-description:
-  "A summary of the progress over the last six months on the Embroider project
-  that has been made through Mainmatter's Embroider Initiative."
+description: "A summary of the progress over the last six months on the Embroider project that has been made through Mainmatter's Embroider Initiative."
 og:
   image: /assets/images/posts/2024-05-29-embroider-update/og-image.jpg
 tagline: |
@@ -14,158 +12,53 @@ tagline: |
   </p>
 
 image: /assets/images/posts/2024-05-29-embroider-update/header-embroider.jpg
-imageAlt:
-  "The logo of companies supporting the Embroider Initiative on a background
-  showing people working together on a laptop"
+imageAlt: "The logo of companies supporting the Embroider Initiative on a background showing people working together on a laptop"
 ---
 
-In the
-[blog post from November 2023](https://mainmatter.com/blog/2023/11/16/embroider-initiative-progress-update/),
-[Chris Manson](https://github.com/mansona) introduced to you Embroider, the new
-build pipeline that compiles Ember apps into spec-compliant, modern JavaScript.
-If this is the first time you hear about Embroider, we encourage you to read the
-introduction of the November blog post, which explains what Embroider is in more
-detail and presents the Embroider Initiative.
+In the [blog post from November 2023](https://mainmatter.com/blog/2023/11/16/embroider-initiative-progress-update/), [Chris Manson](https://github.com/mansona) introduced to you Embroider, the new build pipeline that compiles Ember apps into spec-compliant, modern JavaScript. If this is the first time you hear about Embroider, we encourage you to read the introduction of the November blog post, which explains what Embroider is in more detail and presents the Embroider Initiative.
 
-The main goal that was set in the last blog was to get our Ember apps building
-with Vite. Not only have we achieved that landmark, but we have moved onto the
-next phase, which brings the wonderful DX improvements that Vite can promise to
-all Ember apps.
+The main goal that was set in the last blog was to get our Ember apps building with Vite. Not only have we achieved that landmark, but we have moved onto the next phase, which brings the wonderful DX improvements that Vite can promise to all Ember apps.
 
 ## Improving how Ember works with Vite
 
-Now that our challenge is no longer to get Ember working with Vite, we need to
-figure out how to optimize the Vite build and maintain the compatibility of all
-classic features. To find a solution, we need to dive into the challenge that an
-Ember build presents.
+Now that our challenge is no longer to get Ember working with Vite, we need to figure out how to optimize the Vite build and maintain the compatibility of all classic features. To find a solution, we need to dive into the challenge that an Ember build presents.
 
 ### How we make it work: the rewritten app
 
-By default, an Ember application cannot be built with Vite. The reason for this
-is because Ember performs some “magic” around resolving imports, relying on
-[AMD modules](https://github.com/emberjs/rfcs/pull/938) and other specific build
-actions, which are incompatible with the Vite resolver. Let’s take an example:
-if you generated an Ember app using the default blueprint, you will get a file
-`app/index.html` which contains a reference to the CSS stylesheet
-`“assets/vendor.css”`. This file is supposed to contain the vendor styles that
-are automatically provided by the Ember addons you use. However, it doesn’t
-exist in your repo: your `app/index.html` points to a file that is literally
-nowhere in your app files. At build time, Ember will go through all the active
-Ember addons used in your app and will emit the `assets/vendor.css` file at some
-point in the build pipeline. This is an Ember-specific behavior that Vite cannot
-deal with. Vite expects the referenced file to exist, it cannot guess how to
-find it or write it.
-
-To solve this issue, when the build starts, Embroider first produces an
-intermediate Ember application that we call the “rewritten app” and outputs it
-to `node_modules/.embroider/rewritten-app`. The rewritten app is slightly
-different from the initial Ember app in that it can be consumed by Vite. For
-instance, it has an `index.html` at the root and it does contain the
-`assets/vendor.css`. This approach allows us to build real-world applications
-with Vite, but also carries performance (and other) downsides: Vite prebuilds
-the app dependencies for optimization purposes, but the rewritten app _is_
-considered a dependency because it lives in a folder in node_modules. Therefore,
-changes in the Ember app that need to be reflected in the rewritten app imply
-changes in a dependency, so Vite has to go through bundling dependencies again
-and we lose the advantage of the prebuild.
+By default, an Ember application cannot be built with Vite. The reason for this is because Ember performs some “magic” around resolving imports, relying on [AMD modules](https://github.com/emberjs/rfcs/pull/938) and other specific build actions, which are incompatible with the Vite resolver. Let’s take an example: if you generated an Ember app using the default blueprint, you will get a file `app/index.html` which contains a reference to the CSS stylesheet `“assets/vendor.css”`. This file is supposed to contain the vendor styles that are automatically provided by the Ember addons you use. However, it doesn’t exist in your repo: your `app/index.html` points to a file that is literally nowhere in your app files. At build time, Ember will go through all the active Ember addons used in your app and will emit the `assets/vendor.css` file at some point in the build pipeline. This is an Ember-specific behavior that Vite cannot deal with. Vite expects the referenced file to exist, it cannot guess how to find it or write it.
+
+To solve this issue, when the build starts, Embroider first produces an intermediate Ember application that we call the “rewritten app” and outputs it to `node_modules/.embroider/rewritten-app`. The rewritten app is slightly different from the initial Ember app in that it can be consumed by Vite. For instance, it has an `index.html` at the root and it does contain the `assets/vendor.css`. This approach allows us to build real-world applications with Vite, but also carries performance (and other) downsides: Vite prebuilds the app dependencies for optimization purposes, but the rewritten app _is_ considered a dependency because it lives in a folder in node_modules. Therefore, changes in the Ember app that need to be reflected in the rewritten app imply changes in a dependency, so Vite has to go through bundling dependencies again and we lose the advantage of the prebuild.
 
 ### How we want to make it work: “inversion of control”
 
-To improve this situation and get all the benefits of using Vite, we have
-started a wide technical topic called “inversion of control”. The idea is the
-following: instead of having Embroider produce a rewritten app, and then passing
-over to Vite once the rewritten app is ready, Vite takes the lead, and when it’s
-unable to resolve Ember-specific requests, it asks Embroider to return the
-information without the need of a rewritten app.
-
-A good example to illustrate this idea is file virtualization. Let’s go back to
-our `vendor.css` case. Before inversion of control, Embroider produces a
-rewritten app that concats all the styles provided by the classic addons into a
-file `assets/vendor.css`, and this file is referenced in the `index.html`. Vite
-has no trouble consuming that. But now, we want to get rid of the rewritten app
-step. To invert the control, we use a special identifier in the `index.html`
-that starts with `@embroider`. For instance: `@embroider/core/vendor.css`. Then,
-we implement our own Vite resolver plugin that is able to recognize this
-identifier and ask Embroider to return the content for this file. Embroider
-executes code that is very similar to the code initially used to create the
-`assets/vendor.css` in the rewritten app, but this time, it doesn’t write any
-file: it just returns the content to Vite as “virtual” content.
+To improve this situation and get all the benefits of using Vite, we have started a wide technical topic called “inversion of control”. The idea is the following: instead of having Embroider produce a rewritten app, and then passing over to Vite once the rewritten app is ready, Vite takes the lead, and when it’s unable to resolve Ember-specific requests, it asks Embroider to return the information without the need of a rewritten app.
+
+A good example to illustrate this idea is file virtualization. Let’s go back to our `vendor.css` case. Before inversion of control, Embroider produces a rewritten app that concats all the styles provided by the classic addons into a file `assets/vendor.css`, and this file is referenced in the `index.html`. Vite has no trouble consuming that. But now, we want to get rid of the rewritten app step. To invert the control, we use a special identifier in the `index.html` that starts with `@embroider`. For instance: `@embroider/core/vendor.css`. Then, we implement our own Vite resolver plugin that is able to recognize this identifier and ask Embroider to return the content for this file. Embroider executes code that is very similar to the code initially used to create the `assets/vendor.css` in the rewritten app, but this time, it doesn’t write any file: it just returns the content to Vite as “virtual” content.
 
 ### On going work
 
-The “inversion of control” topic includes every task that is necessary to remove
-the rewritten app. Among these tasks, we have the virtualization of several
-files, handling the public assets provided by the app and addons, and also
-maintaining the compatibility of classic addons with Embroider by getting
-functionalities like content-for to work with Vite. A wide part of this work has
-already been done: all the app entry points are virtualized, the new authoring
-format for the `index.html` is ready, and we have identified the few pieces we
-still have to work on to maintain the compatibility with the classic world (the
-best example is FastBoot supports).
-
-The task that will close out the “inversion of control” topic will be the one
-that actually turns off the writing of the rewritten app. From this moment, the
-initial Ember app will have to contain everything Vite needs to communicate with
-Embroider. This will also require us to update the application blueprint so
-newly generated Ember apps have everything in place to build with Vite. We're
-hoping to have a preview of this new blueprint ready in the next few days for
-people to try out.
+The “inversion of control” topic includes every task that is necessary to remove the rewritten app. Among these tasks, we have the virtualization of several files, handling the public assets provided by the app and addons, and also maintaining the compatibility of classic addons with Embroider by getting functionalities like content-for to work with Vite. A wide part of this work has already been done: all the app entry points are virtualized, the new authoring format for the `index.html` is ready, and we have identified the few pieces we still have to work on to maintain the compatibility with the classic world (the best example is FastBoot supports).
+
+The task that will close out the “inversion of control” topic will be the one that actually turns off the writing of the rewritten app. From this moment, the initial Ember app will have to contain everything Vite needs to communicate with Embroider. This will also require us to update the application blueprint so newly generated Ember apps have everything in place to build with Vite. We're hoping to have a preview of this new blueprint ready in the next few days for people to try out.
 
 ### The Embroider test suite now uses Vite
 
-Embroider’s test suite relies on minimalist Ember app and addon templates that
-can be overridden and output according to the needs of each test scenario. Some
-of the new functionalities mentioned above required the test suite to build
-these output apps with Vite. It has been a long road, but we are finally there:
-all of Embroider's test suite uses Vite to get the app built.
-
-For the new tests, we started to reorganize things in a way that allows us to
-assert that each functionality behaves as expected in build mode and dev mode:
-the approach that was previously used to start the Ember dev server in one
-specific test file has been refactored to a `CommandWatcher` helper that can be
-imported in tests to easily start Vite and wait for logs that say building is
-complete before asserting.
-
-Also, we improved the existing audit system so that it can interface with both
-the Vite dev server and the build output. Because Vite behaves differently in
-dev mode and build (it essentially just uses Rollup during the build) we need to
-verify that some of the features we are implementing work both when Ember
-developers are developing their app and when they are deploying to production.
-Using this new audit system also allows us to more easily investigate the
-content of the build, e.g. you want to verify a specific piece of code has been
-included into the build, but you don’t know how Rollup is going to organize the
-files, so you don’t know what file to look into to verify that the code is
-present: the audit system is designed to figure this out for you, so you can
-focus on your test's purpose without struggling with Rollup internals.
+Embroider’s test suite relies on minimalist Ember app and addon templates that can be overridden and output according to the needs of each test scenario. Some of the new functionalities mentioned above required the test suite to build these output apps with Vite. It has been a long road, but we are finally there: all of Embroider's test suite uses Vite to get the app built.
+
+For the new tests, we started to reorganize things in a way that allows us to assert that each functionality behaves as expected in build mode and dev mode: the approach that was previously used to start the Ember dev server in one specific test file has been refactored to a `CommandWatcher` helper that can be imported in tests to easily start Vite and wait for logs that say building is complete before asserting.
+
+Also, we improved the existing audit system so that it can interface with both the Vite dev server and the build output. Because Vite behaves differently in dev mode and build (it essentially just uses Rollup during the build) we need to verify that some of the features we are implementing work both when Ember developers are developing their app and when they are deploying to production. Using this new audit system also allows us to more easily investigate the content of the build, e.g. you want to verify a specific piece of code has been included into the build, but you don’t know how Rollup is going to organize the files, so you don’t know what file to look into to verify that the code is present: the audit system is designed to figure this out for you, so you can focus on your test's purpose without struggling with Rollup internals.
 
 ## Reducing the bus factor
 
-In the section “Improving the bus factor” of the November blog post, we
-explained how challenging it is to contribute to the core of Embroider and we
-introduced the apprenticeship model we adopted to address the
-[bus factor](https://en.wikipedia.org/wiki/Bus_factor) issue. This model still
-stands today: Chris pairs with [Ed Faulkner](https://github.com/ef4/) every week
-and now has a solid knowledge of the heart of the Embroider codebase.
+In the section “Improving the bus factor” of the November blog post, we explained how challenging it is to contribute to the core of Embroider and we introduced the apprenticeship model we adopted to address the [bus factor](https://en.wikipedia.org/wiki/Bus_factor) issue. This model still stands today: Chris pairs with [Ed Faulkner](https://github.com/ef4/) every week and now has a solid knowledge of the heart of the Embroider codebase.
 
-Following Andrey Mikhaylov’s departure in March,
-[Marine Dunstetter](https://github.com/BlueCutOfficial) joined the Embroider
-Initiative as a full-time engineer. We have extended the apprenticeship model by
-having Chris and Marine meet and pair regularly each week.
+Following Andrey Mikhaylov’s departure in March, [Marine Dunstetter](https://github.com/BlueCutOfficial) joined the Embroider Initiative as a full-time engineer. We have extended the apprenticeship model by having Chris and Marine meet and pair regularly each week.
 
-> "Marine’s ramp-up was very successful and she has made many impactful
-> contributions to the project over the past three months and we wouldn't be so
-> close to completing the inversion of control work at the time of writing
-> without her!" Chris Manson
+> "Marine’s ramp-up was very successful and she has made many impactful contributions to the project over the past three months and we wouldn't be so close to completing the inversion of control work at the time of writing without her!" Chris Manson
 
 ## Next steps
 
-We are now at the point of wrapping up the technical challenges. We should soon
-have a Vite demo that is a good approximation of the new way to write Ember apps
-and matches the future blueprint. The next phase will be all about communication
-and community work: we want this new fast Embroider + Vite experience to be the
-default experience for all Ember users.
+We are now at the point of wrapping up the technical challenges. We should soon have a Vite demo that is a good approximation of the new way to write Ember apps and matches the future blueprint. The next phase will be all about communication and community work: we want this new fast Embroider + Vite experience to be the default experience for all Ember users.
 
-To keep up to date with the latest developments on the
-[Embroider Initiative](/ember-initiative/), don't miss Chris Manson's talk at
-[EmberConf](https://www.emberconf.com/talks/launching-ember-into-the-future-) on
-May 31st.
+To keep up to date with the latest developments on the [Embroider Initiative](/ember-initiative/), don't miss Chris Manson's talk at [EmberConf](https://www.emberconf.com/talks/launching-ember-into-the-future-) on May 31st.
diff --git a/src/posts/2024-06-07-payment-infrastructure-with-rust.md b/src/posts/2024-06-07-payment-infrastructure-with-rust.md
index fdacca2fa9..5a4073e29e 100644
--- a/src/posts/2024-06-07-payment-infrastructure-with-rust.md
+++ b/src/posts/2024-06-07-payment-infrastructure-with-rust.md
@@ -1,13 +1,9 @@
 ---
-title:
-  "How Nikulipe develops their B2B payment infrastructure with Rust – with
-  Florent Bécart"
+title: "How Nikulipe develops their B2B payment infrastructure with Rust – with Florent Bécart"
 authorHandle: algo_luca
 tags: [rust]
 bio: "Principal Engineering Consultant"
-description:
-  "Nikulipe's Florent Bécart and Luca Palmieri explored Nikulipe's journey using
-  Rust across all layers of their stack to develop payment processing services."
+description: "Nikulipe's Florent Bécart and Luca Palmieri explored Nikulipe's journey using Rust across all layers of their stack to develop payment processing services."
 og:
   image: "/assets/images/posts/2024-06-07-payment-infrastructure-with-rust/og-image.jpg"
 tagline: |
@@ -19,22 +15,10 @@ image: "/assets/images/posts/2024-06-07-payment-infrastructure-with-rust/header-
 imageAlt: "Florent's picture on a gray background"
 ---
 
-Florent begins by discussing Nikulipe's reasons for choosing Rust to develop
-their payment processing services. He mentions Rust's lower operations costs,
-scalability, safety, and added maintainability compared to C as the language's
-main advantages. The borrow checker minimizes vulnerabilities, which is
-particularly critical for a payment infrastructure.
+Florent begins by discussing Nikulipe's reasons for choosing Rust to develop their payment processing services. He mentions Rust's lower operations costs, scalability, safety, and added maintainability compared to C as the language's main advantages. The borrow checker minimizes vulnerabilities, which is particularly critical for a payment infrastructure.
 
-Nikulipe uses Rust across all layers of their stack, which promotes full-stack
-and vertical ownership for their developers. Talking about frontend, Florent
-shares how Nikulipe leveraged tools like Yew and WebAssembly to build an
-internal component library to improve and speed up frontend development.
+Nikulipe uses Rust across all layers of their stack, which promotes full-stack and vertical ownership for their developers. Talking about frontend, Florent shares how Nikulipe leveraged tools like Yew and WebAssembly to build an internal component library to improve and speed up frontend development.
 
-Next, Florent and Luca moved on to the challenges that Nikulipe faced on their
-Rust journey. They discussed Rust's long compile times, Cargo's handling of
-larger workspaces, and the lack of optimization in feature management and
-caching as the primary drawbacks. They end by talking about the obstacles faced
-working with Protobuf in Rust which led to code duplication and further
-complications.
+Next, Florent and Luca moved on to the challenges that Nikulipe faced on their Rust journey. They discussed Rust's long compile times, Cargo's handling of larger workspaces, and the lack of optimization in feature management and caching as the primary drawbacks. They end by talking about the obstacles faced working with Protobuf in Rust which led to code duplication and further complications.
 
 <iframe width="560" height="315" src="https://www.youtube.com/embed/RA-r4F4ZmXM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
diff --git a/src/posts/2024-06-21-shipping-is-a-state-of-mind.md b/src/posts/2024-06-21-shipping-is-a-state-of-mind.md
index 2f7feb96e5..1ca8e1eb78 100644
--- a/src/posts/2024-06-21-shipping-is-a-state-of-mind.md
+++ b/src/posts/2024-06-21-shipping-is-a-state-of-mind.md
@@ -3,435 +3,165 @@ title: "Shipping Is a State of Mind"
 authorHandle: marcoow
 tags: [process]
 bio: "Marco Otte-Witte"
-description:
-  "Marco Otte-Witte explains how, for the leading teams in the industry,
-  shipping is a permanent state rather than an occasional event."
+description: "Marco Otte-Witte explains how, for the leading teams in the industry, shipping is a permanent state rather than an occasional event."
 og:
   image: /assets/images/posts/2024-06-21-shipping-is-a-state-of-mind/og-image.png
-tagline:
-  "<p>Shipping software to production so it’s available to real users is the
-  ultimate goal of every digital product development team. There is no value in
-  specs, designs, or changes committed to git, unless the code has made it to
-  the production system and thus into the hands of users. The best teams ship
-  dozens of times per day, every day, instead of every 2 weeks on particularly
-  designated release days, or only at the end of the sprint – for those teams,
-  shipping is a permanent state rather than an occasional event.</p>"
+tagline: "<p>Shipping software to production so it’s available to real users is the ultimate goal of every digital product development team. There is no value in specs, designs, or changes committed to git, unless the code has made it to the production system and thus into the hands of users. The best teams ship dozens of times per day, every day, instead of every 2 weeks on particularly designated release days, or only at the end of the sprint – for those teams, shipping is a permanent state rather than an occasional event.</p>"
 image: "/assets/images/posts/2024-06-21-shipping-is-a-state-of-mind/header.jpg"
-imageAlt:
-  "Close-up photo of a green rope on a sailboat, with blurred figures in the
-  background and a sail catching the wind against a clear blue sky."
+imageAlt: "Close-up photo of a green rope on a sailboat, with blurred figures in the background and a sail catching the wind against a clear blue sky."
 ---
 
 ## Legacy release processes
 
-Despite the importance of shipping, many teams we work with in our consulting
-projects still follow slow and complex processes for releasing changes to
-production. There are many variations, but usually, these processes look
-something like this:
+Despite the importance of shipping, many teams we work with in our consulting projects still follow slow and complex processes for releasing changes to production. There are many variations, but usually, these processes look something like this:
 
 ![diagram showing a legacy release process with main and develop, feature and hotfix branches](/assets/images/posts/2024-06-21-shipping-is-a-state-of-mind/legacy-process.png)
 
-- There is a `main` branch that contains the code currently running on the
-  production system.
-- Parallel to that, there's a `develop` branch in which the codebase evolves and
-  that's ahead of `main`.
-- The engineers make their changes in dedicated branches for the feature they
-  work on (what you'd call "feature branches" typically). They will occasionally
-  rebase their branch on `develop` but in many cases these branch tend to stay
-  open for 1 to 2 weeks, if not longer.
-- Once the work done in a feature branch is finished, a PR is opened that is
-  reviewed and eventually merged to `develop`.
-- When there are "enough" changes (whatever that means) or when a certain point
-  in time is reached, a `release` branch is branched off from the `develop`
-  branch.
+- There is a `main` branch that contains the code currently running on the production system.
+- Parallel to that, there's a `develop` branch in which the codebase evolves and that's ahead of `main`.
+- The engineers make their changes in dedicated branches for the feature they work on (what you'd call "feature branches" typically). They will occasionally rebase their branch on `develop` but in many cases these branch tend to stay open for 1 to 2 weeks, if not longer.
+- Once the work done in a feature branch is finished, a PR is opened that is reviewed and eventually merged to `develop`.
+- When there are "enough" changes (whatever that means) or when a certain point in time is reached, a `release` branch is branched off from the `develop` branch.
 - That `release` branch then goes through some kind of QA process.
-- Once QA is done and potential bugs have been fixed, the `release` branch is
-  merged back to `main`, which is deployed to production. **This is the big day
-  – everyone’s changes that have been collected on the develop branch for weeks,
-  or months in the worst case, are finally released to the users!**
-- If there's a bug in production, it is fixed in a `hotfix` branch that's
-  branched off of the `main` branch, merged back to it and deployed. The changes
-  are also propagated back to the `develop` branch.
-- …and it goes on like that – changes are made in feature branches and collected
-  in the `develop` branch; eventually those changes are merged back into the
-  `main` branch via a `release` branch when "it's time" for a release.
+- Once QA is done and potential bugs have been fixed, the `release` branch is merged back to `main`, which is deployed to production. **This is the big day – everyone’s changes that have been collected on the develop branch for weeks, or months in the worst case, are finally released to the users!**
+- If there's a bug in production, it is fixed in a `hotfix` branch that's branched off of the `main` branch, merged back to it and deployed. The changes are also propagated back to the `develop` branch.
+- …and it goes on like that – changes are made in feature branches and collected in the `develop` branch; eventually those changes are merged back into the `main` branch via a `release` branch when "it's time" for a release.
 
 ## Plenty of problems
 
-These outdated release processes lead to several problems – all of which are
-related to long intervals.
+These outdated release processes lead to several problems – all of which are related to long intervals.
 
-First, there’s the potentially long interval between branching off a feature
-branch and merging it back to `develop`. The longer that interval is, the more
-the feature branch diverges from the `develop` branch, increasing the likelihood
-for conflicts when merging back (yes, engineers should rebase but that’s by far
-not as common a practice as it should be in our experience). Also, if multiple
-engineers each develop in their own, isolated feature branches for extended
-periods of time, they all make changes in isolation and there’s a risk that the
-changes might be incompatible, even if they are completely consistent within
-each branch.
+First, there’s the potentially long interval between branching off a feature branch and merging it back to `develop`. The longer that interval is, the more the feature branch diverges from the `develop` branch, increasing the likelihood for conflicts when merging back (yes, engineers should rebase but that’s by far not as common a practice as it should be in our experience). Also, if multiple engineers each develop in their own, isolated feature branches for extended periods of time, they all make changes in isolation and there’s a risk that the changes might be incompatible, even if they are completely consistent within each branch.
 
-More importantly though, teams following legacy release processes, deal with
-long intervals between the time a feature branch is merged and the respective
-changes are deployed to production – what you could call the "deployment delay”.
+More importantly though, teams following legacy release processes, deal with long intervals between the time a feature branch is merged and the respective changes are deployed to production – what you could call the "deployment delay”.
 
 ### Deployment Delays
 
-Assuming an engineer merges their feature branch at the beginning of a 2 week
-sprint, the `release` branch is branched off by the end of the sprint and then
-undergoes QA for 1 week before being deployed: the delay between merge and
-deployment is 3 weeks! That has a number of negative consequences:
-
-- **Constant risk of delayed rework:** During the period between merging a
-  feature branch and it undergoing QA and finally being deployed, there is the
-  risk of having to go back to the changes to fix things that come up during QA
-  or after deployment. If that happens and indeed things need to be fixed later,
-  the engineer has to get back to code they last touched weeks ago potentially.
-  In the meantime, however, they have moved on and started to work on something
-  else. They will now have to stop working on that new task and build up the
-  mental model for the old task again to be able to fix the bug that was found.
-  At the same time, since work on the new task does not progress anymore while
-  the engineer fixes the problem in the old code, other engineers that might
-  depend on the new task might end up being blocked – in the worst case causing
-  cascades of friction.
-- **Making Users Wait:** Delayed deployment of changes means users need to wait
-  unnecessarily long to get new things – even if an engineer can build a feature
-  or make a change users need in a day, they'll still have to wait until the
-  next release window to get access to that feature. That's not only annoying
-  for users, it also means they will only be able to provide their feedback
-  after the same delay. Getting feedback from users and getting it fast is
-  critical for efficient product development – nobody wants to hear they've been
-  heading in the wrong direction for 2 weeks already.
-- **Larger, riskier deployments:** Finally, legacy release processes lead to
-  deployments becoming unnecessarily large and risky. As many, unrelated changes
-  accumulate in the `develop` branch within each interval between two releases,
-  those unrelated changes are all deployed together. That means that more things
-  can go wrong at the same time, just because more things change at the same
-  time. And for each bug that occurs after the deployment, the set of changes
-  that engineers need to look into to find the root cause is bigger, thus making
-  the task of debugging harder. In the worst case, teams end up being scared of
-  deploying and try to avoid it or only deploy as rarely as they can (everybody
-  knows teams in which deploying on Friday at 17:00 would be considered crazy or
-  even be forbidden completely). Obviously that leads to a vicious cycle as the
-  more rarely teams deploy, the bigger and thus riskier each deployment becomes
-  which causes more fear and motivation to deploy less often and so on and so
-  on…
-
-Overall, these legacy release processes are a bit like opening the flood gates
-every now and then to release a large swath of water that has been collected in
-a reservoir (the `develop` branch) for some time. Once the gates are opened,
-these teams are in God's hands – the uncontrollable waters have been set free,
-and they can only hope for things to go well:
+Assuming an engineer merges their feature branch at the beginning of a 2 week sprint, the `release` branch is branched off by the end of the sprint and then undergoes QA for 1 week before being deployed: the delay between merge and deployment is 3 weeks! That has a number of negative consequences:
+
+- **Constant risk of delayed rework:** During the period between merging a feature branch and it undergoing QA and finally being deployed, there is the risk of having to go back to the changes to fix things that come up during QA or after deployment. If that happens and indeed things need to be fixed later, the engineer has to get back to code they last touched weeks ago potentially. In the meantime, however, they have moved on and started to work on something else. They will now have to stop working on that new task and build up the mental model for the old task again to be able to fix the bug that was found. At the same time, since work on the new task does not progress anymore while the engineer fixes the problem in the old code, other engineers that might depend on the new task might end up being blocked – in the worst case causing cascades of friction.
+- **Making Users Wait:** Delayed deployment of changes means users need to wait unnecessarily long to get new things – even if an engineer can build a feature or make a change users need in a day, they'll still have to wait until the next release window to get access to that feature. That's not only annoying for users, it also means they will only be able to provide their feedback after the same delay. Getting feedback from users and getting it fast is critical for efficient product development – nobody wants to hear they've been heading in the wrong direction for 2 weeks already.
+- **Larger, riskier deployments:** Finally, legacy release processes lead to deployments becoming unnecessarily large and risky. As many, unrelated changes accumulate in the `develop` branch within each interval between two releases, those unrelated changes are all deployed together. That means that more things can go wrong at the same time, just because more things change at the same time. And for each bug that occurs after the deployment, the set of changes that engineers need to look into to find the root cause is bigger, thus making the task of debugging harder. In the worst case, teams end up being scared of deploying and try to avoid it or only deploy as rarely as they can (everybody knows teams in which deploying on Friday at 17:00 would be considered crazy or even be forbidden completely). Obviously that leads to a vicious cycle as the more rarely teams deploy, the bigger and thus riskier each deployment becomes which causes more fear and motivation to deploy less often and so on and so on…
+
+Overall, these legacy release processes are a bit like opening the flood gates every now and then to release a large swath of water that has been collected in a reservoir (the `develop` branch) for some time. Once the gates are opened, these teams are in God's hands – the uncontrollable waters have been set free, and they can only hope for things to go well:
 
 ![video of a gate in a dam being opened, releasing a large flood of water](/assets/images/posts/2024-06-21-shipping-is-a-state-of-mind/legacy-release.gif)
 
 ## Shipping constantly, continuously, sanely
 
-As stated above, the best modern teams ship differently – they ship constantly,
-continuously, in small steps, and because of that, much more sanely. Their
-continuous stream of deployments looks like this:
+As stated above, the best modern teams ship differently – they ship constantly, continuously, in small steps, and because of that, much more sanely. Their continuous stream of deployments looks like this:
 
 ![video of a small, calm stream of water](/assets/images/posts/2024-06-21-shipping-is-a-state-of-mind/continuously-releasing.gif)
 
-They will deliver the same amount of water over the same period of time, just
-without the delays, without the stress and without the risk of breaking
-everything.
+They will deliver the same amount of water over the same period of time, just without the delays, without the stress and without the risk of breaking everything.
 
-The main difference between this and the above legacy process is shorter
-intervals – both between opening and merging branches as well as between merging
-and deploying.
+The main difference between this and the above legacy process is shorter intervals – both between opening and merging branches as well as between merging and deploying.
 
 ### Shortening branch lifetimes
 
-Shorter branch lifetimes and a faster branch turnover requires reducing the
-scope of the work that’s done in each branch. The main change to make in order
-to achieve that is to stop thinking about branches as “feature” branches in
-which complete features are developed until they are 100% done, including every
-little detail. Instead, things need to be broken down into much smaller steps. A
-good way to think of these branches is “task branches” or
-“smallest-mergable-units-of-work” branches – the idea is to advance the codebase
-in small steps so that each step leaves the codebase in a consistent (and
-deployable) state. Generally, a good rule of thumb is no branch should be so
-large in scope or complexity that it cannot be merged back within 1-2 days max.
-
-Here’s an example for that approach: consider adding
-login-with-your-Google-account functionality to a web app. That might require a
-number of changes that all have to be made to complete that feature:
-
-- it might make sense to start by refactoring the login controller to make the
-  subsequent changes easier
-- then the user accounts model has to be changed to model the relation to the
-  external authentication provider
+Shorter branch lifetimes and a faster branch turnover requires reducing the scope of the work that’s done in each branch. The main change to make in order to achieve that is to stop thinking about branches as “feature” branches in which complete features are developed until they are 100% done, including every little detail. Instead, things need to be broken down into much smaller steps. A good way to think of these branches is “task branches” or “smallest-mergable-units-of-work” branches – the idea is to advance the codebase in small steps so that each step leaves the codebase in a consistent (and deployable) state. Generally, a good rule of thumb is no branch should be so large in scope or complexity that it cannot be merged back within 1-2 days max.
+
+Here’s an example for that approach: consider adding login-with-your-Google-account functionality to a web app. That might require a number of changes that all have to be made to complete that feature:
+
+- it might make sense to start by refactoring the login controller to make the subsequent changes easier
+- then the user accounts model has to be changed to model the relation to the external authentication provider
 - …and existing user data has to be migrated
 - finally, the UI needs to be built
 - …and translated
 
-Instead of doing all this in one long-lived branch that is only merged back when
-all the changes are made,
+Instead of doing all this in one long-lived branch that is only merged back when all the changes are made,
 
 ![diagram showing a feature branch with a number of commits/steps](/assets/images/posts/2024-06-21-shipping-is-a-state-of-mind/feature-branch.png)
 
-the same changes can be done in multiple, small branches, that can each be
-merged back individually with a much shorter turnover time, leaving the main
-branch in a consistent state at all times:
+the same changes can be done in multiple, small branches, that can each be merged back individually with a much shorter turnover time, leaving the main branch in a consistent state at all times:
 
 ![diagram showing the same commits/steps as in the above image, separated into individual branches](/assets/images/posts/2024-06-21-shipping-is-a-state-of-mind/task-branches.png)
 
-That way, both problems of long-lived feature branches mentioned above are
-solved: shorter lived branches with a shorter turnover time diverge less and
-branches of different engineers have a lower risk of being incompatible. Also,
-since the scope of changes in each branch is much smaller, and branches are
-continuously integrated with the main branch, there’s a smaller chance for
-conflicts when merging back.
+That way, both problems of long-lived feature branches mentioned above are solved: shorter lived branches with a shorter turnover time diverge less and branches of different engineers have a lower risk of being incompatible. Also, since the scope of changes in each branch is much smaller, and branches are continuously integrated with the main branch, there’s a smaller chance for conflicts when merging back.
 
 ### ~~Shortening~~ Removing the deployment delay
 
-The other big problem with legacy release process is the deployment delay, as
-explained above – the artificial delay resulting out of the process between
-making a change (and merging it back to some mainline) and releasing the change
-to production. Efficient teams shorten that delay to 0 by simply removing it
-altogether – every set of changes that a developer merges back to the mainline
-via a PR is released to production instantly:
+The other big problem with legacy release process is the deployment delay, as explained above – the artificial delay resulting out of the process between making a change (and merging it back to some mainline) and releasing the change to production. Efficient teams shorten that delay to 0 by simply removing it altogether – every set of changes that a developer merges back to the mainline via a PR is released to production instantly:
 
 ![diagram showing the same commits/steps in individual branches with deployments after each branch is merged](/assets/images/posts/2024-06-21-shipping-is-a-state-of-mind/task-deployments.png)
 
-_While this sounds like it might not always be possible, since, for example,
-users cannot be confronted with half-done UIs, remember that releasing something
-to production does not necessarily mean exposing it to (all) users. You can
-leverage techniques like feature flags or canary deployments to limit the
-visibility of things that are still under active development._
-
-Removing the deployment delay solves all of the problems related to it in legacy
-release processes:
-
-- **Smaller, less risky deployments:** since the amount of changes in each
-  deployment is much smaller, fewer things can go wrong. And if anything goes
-  wrong, it’s much easier to find the root cause since the amounts of changes
-  that need to be examined is considerably smaller.
-- **No delay between completion of a task and potential rework:** since each
-  branch/task is deployed immediately after its completion, the deployment is an
-  integral part of the work on the task. If anything goes wrong during
-  deployment or on production right after, the developer will still be “on” the
-  task anyway. Only if the deployment has been completed successfully can the
-  task be considered done and the developer will move on to the next thing,
-  knowing they will not have to get back to what they worked on before.
-- **No artificial wait time for users:** deploying changes immediately after
-  they have been completed means there’s no systemic wait time for users – they
-  benefit from fixes and new features as soon as those have been implemented.
-  That also means the product development team gets feedback from users as fast
-  as possible and can correct their course if necessary without continuing to
-  move in the wrong direction for days, weeks, or months in the worst case.
+_While this sounds like it might not always be possible, since, for example, users cannot be confronted with half-done UIs, remember that releasing something to production does not necessarily mean exposing it to (all) users. You can leverage techniques like feature flags or canary deployments to limit the visibility of things that are still under active development._
+
+Removing the deployment delay solves all of the problems related to it in legacy release processes:
+
+- **Smaller, less risky deployments:** since the amount of changes in each deployment is much smaller, fewer things can go wrong. And if anything goes wrong, it’s much easier to find the root cause since the amounts of changes that need to be examined is considerably smaller.
+- **No delay between completion of a task and potential rework:** since each branch/task is deployed immediately after its completion, the deployment is an integral part of the work on the task. If anything goes wrong during deployment or on production right after, the developer will still be “on” the task anyway. Only if the deployment has been completed successfully can the task be considered done and the developer will move on to the next thing, knowing they will not have to get back to what they worked on before.
+- **No artificial wait time for users:** deploying changes immediately after they have been completed means there’s no systemic wait time for users – they benefit from fixes and new features as soon as those have been implemented. That also means the product development team gets feedback from users as fast as possible and can correct their course if necessary without continuing to move in the wrong direction for days, weeks, or months in the worst case.
 
 ## Shipping based on pipelines
 
-This might raise the question of why not all teams work like this, and
-consequently, what do teams that work like this have that teams using legacy
-release process don’t. The answer to that question is that they have top-notch
-infrastructure and shipping pipelines. Teams that are in a state of shipping
-constantly stand on the shoulders of highly integrated and automated
-infrastructure that enables an efficient and stable process. A well oiled
-shipping pipeline covers testing, previewing, deploying, and observing.
+This might raise the question of why not all teams work like this, and consequently, what do teams that work like this have that teams using legacy release process don’t. The answer to that question is that they have top-notch infrastructure and shipping pipelines. Teams that are in a state of shipping constantly stand on the shoulders of highly integrated and automated infrastructure that enables an efficient and stable process. A well oiled shipping pipeline covers testing, previewing, deploying, and observing.
 
 ### 1. Testing
 
-Merging every PR directly to the `main` branch and shipping it to production
-right away might seem like giving up on QA and just pushing out changes without
-further control, but it’s actually quite the opposite. Thorough testing is even
-more important than it is with legacy release processes. In order to be able to
-deploy dozens or hundreds of times per day, things can’t regularly go wrong in
-production and require rollbacks. Not only would that lead to unhappy users, it
-would also be an impediment to the process as such and eventually bring it to a
-halt.
-
-When merging PRs directly to and deploying from the `main` branch, testing works
-a bit differently than with legacy release processes. While those processes have
-a central `release` branch that undergoes QA and thus acts as a safety net, that
-safety net no longer exists when deploying from `main` right after merge.
-Instead, all testing needs to happen before a PR is merged. As there are several
-PRs at any given time, all of those have to be tested in parallel. That
-necessarily implies:
-
-**Manual testing has no place in such processes or modern software development
-in general! Teams that test manually will be slower, less efficient, and ship
-worse quality than the ones who don’t. [^1]**
-
-A solid, automated testing setup, that enables teams to ship constantly and
-never stop, covers all relevant aspects:
-
-- **Functional correctness within subsystems:** This is the foundation for
-  thorough testing and provides the fastest feedback loop to developers. The
-  subsystem they work on (and they are submitting a PR for) needs to be correct
-  within itself.
-- **Functional correctness across subsystems:** The next step after guaranteeing
-  that each subsystem is correct within itself, is ensuring that subsystems work
-  together as well. It’s possible for, e.g. both a client app and the backend it
-  talks to, to be correct within themselves while not working together correctly
-  in combination.
-- **Visual correctness:** Unit, integration and other kinds of tests ensure
-  correctness but don’t look at an app the same way a real user does. An app can
-  be 100% functional while visually broken – sth. that would never be detected
-  by a typical test. Tools like [Percy](https://percy.io),
-  [Chromatic](https://www.chromatic.com), or
-  [BackstopJS](https://github.com/garris/BackstopJS) can surface visual changes
-  that might not have been intentional.
-- **Performance:** Even performance can be tested automatically to some extent.
-  While it might not be feasible to run complete load tests for every PR,
-  setting up benchmarks for critical parts of the system or using tools like
-  [Lighthouse](https://github.com/GoogleChrome/lighthouse) to detect performance
-  regressions in web apps is often straight-forward.
-- **Security:** What’s true for performance is true for security as well. It
-  might not be possible to do a full penetration test for every PR but detecting
-  typical security holes automatically is well possible in most cases.
-- **Testing the deployment:** This is often overlooked but testing deployments
-  before actually deploying is a critical piece of a solid testing setup as
-  well, in particular for server backends and deployments that include database
-  migrations (after all, production data always looks different than you think).
-  Not only will testing deployments (e.g. by running them on a clone of the
-  production environment) avoid potential downtimes due to, for instance,
-  failing migrations, but it will also ensure a smooth process by preventing
-  rollbacks from being necessary.
-
-And there’s more – depending on the type of application a team works on, they
-might want to test for translation strings being complete for all supported
-locales, external links still being reachable, or accessibility requirements
-being met.
+Merging every PR directly to the `main` branch and shipping it to production right away might seem like giving up on QA and just pushing out changes without further control, but it’s actually quite the opposite. Thorough testing is even more important than it is with legacy release processes. In order to be able to deploy dozens or hundreds of times per day, things can’t regularly go wrong in production and require rollbacks. Not only would that lead to unhappy users, it would also be an impediment to the process as such and eventually bring it to a halt.
+
+When merging PRs directly to and deploying from the `main` branch, testing works a bit differently than with legacy release processes. While those processes have a central `release` branch that undergoes QA and thus acts as a safety net, that safety net no longer exists when deploying from `main` right after merge. Instead, all testing needs to happen before a PR is merged. As there are several PRs at any given time, all of those have to be tested in parallel. That necessarily implies:
+
+**Manual testing has no place in such processes or modern software development in general! Teams that test manually will be slower, less efficient, and ship worse quality than the ones who don’t. [^1]**
+
+A solid, automated testing setup, that enables teams to ship constantly and never stop, covers all relevant aspects:
+
+- **Functional correctness within subsystems:** This is the foundation for thorough testing and provides the fastest feedback loop to developers. The subsystem they work on (and they are submitting a PR for) needs to be correct within itself.
+- **Functional correctness across subsystems:** The next step after guaranteeing that each subsystem is correct within itself, is ensuring that subsystems work together as well. It’s possible for, e.g. both a client app and the backend it talks to, to be correct within themselves while not working together correctly in combination.
+- **Visual correctness:** Unit, integration and other kinds of tests ensure correctness but don’t look at an app the same way a real user does. An app can be 100% functional while visually broken – sth. that would never be detected by a typical test. Tools like [Percy](https://percy.io), [Chromatic](https://www.chromatic.com), or [BackstopJS](https://github.com/garris/BackstopJS) can surface visual changes that might not have been intentional.
+- **Performance:** Even performance can be tested automatically to some extent. While it might not be feasible to run complete load tests for every PR, setting up benchmarks for critical parts of the system or using tools like [Lighthouse](https://github.com/GoogleChrome/lighthouse) to detect performance regressions in web apps is often straight-forward.
+- **Security:** What’s true for performance is true for security as well. It might not be possible to do a full penetration test for every PR but detecting typical security holes automatically is well possible in most cases.
+- **Testing the deployment:** This is often overlooked but testing deployments before actually deploying is a critical piece of a solid testing setup as well, in particular for server backends and deployments that include database migrations (after all, production data always looks different than you think). Not only will testing deployments (e.g. by running them on a clone of the production environment) avoid potential downtimes due to, for instance, failing migrations, but it will also ensure a smooth process by preventing rollbacks from being necessary.
+
+And there’s more – depending on the type of application a team works on, they might want to test for translation strings being complete for all supported locales, external links still being reachable, or accessibility requirements being met.
 
 ### 2. Previewing
 
-Even when pushing out changes to production behind feature flags, developers
-will need a way to share their work with stakeholders before the changes go to
-production. While teams that use legacy release processes often have a central
-staging system that, e.g., product managers can access, teams that deploy any
-change that’s merged to main directly can’t have such a central staging system
-anymore – there’s just no central branch that the staging system could be
-deployed from before going to production. There can well be multiple staging
-systems though – precisely, one per PR. These systems are typically called
-“Preview Systems”.
-
-The idea is to, for every PR, boot up an environment that simulates the
-production system as it will look once the respective PR is merged. For example,
-for a PR for a web frontend app, an instance of that frontend with the code from
-the PR is set up and connected to a dedicated instance of the backend server it
-speaks to at the revision of the backend code that’s currently running in
-production. The dedicated URL to that system can then be shared with
-stakeholders to preview and approve the changes in the PR or ask for
-modifications if there was a misunderstanding. Once the PR is merged, the
-preview system can be automatically torn down again.
-
-Services like Netlify of Vercel offer support for setting up preview systems for
-frontend apps automatically out-of-the-box. On the server side, there are
-services like Heroku and ArgoCD that have support for preview systems. Even
-setting up a custom process is an option with manageable complexity in many
-cases. The challenging part is typically making a well-defined and realistic
-dataset available to these systems so that stakeholder know how to log in to
-these systems and have actual data to play with. Modern database providers like
-[Neon](https://neon.tech) make setting up such systems easier with support for
-forking (and anonymizing) the production database for use in preview systems.
+Even when pushing out changes to production behind feature flags, developers will need a way to share their work with stakeholders before the changes go to production. While teams that use legacy release processes often have a central staging system that, e.g., product managers can access, teams that deploy any change that’s merged to main directly can’t have such a central staging system anymore – there’s just no central branch that the staging system could be deployed from before going to production. There can well be multiple staging systems though – precisely, one per PR. These systems are typically called “Preview Systems”.
+
+The idea is to, for every PR, boot up an environment that simulates the production system as it will look once the respective PR is merged. For example, for a PR for a web frontend app, an instance of that frontend with the code from the PR is set up and connected to a dedicated instance of the backend server it speaks to at the revision of the backend code that’s currently running in production. The dedicated URL to that system can then be shared with stakeholders to preview and approve the changes in the PR or ask for modifications if there was a misunderstanding. Once the PR is merged, the preview system can be automatically torn down again.
+
+Services like Netlify of Vercel offer support for setting up preview systems for frontend apps automatically out-of-the-box. On the server side, there are services like Heroku and ArgoCD that have support for preview systems. Even setting up a custom process is an option with manageable complexity in many cases. The challenging part is typically making a well-defined and realistic dataset available to these systems so that stakeholder know how to log in to these systems and have actual data to play with. Modern database providers like [Neon](https://neon.tech) make setting up such systems easier with support for forking (and anonymizing) the production database for use in preview systems.
 
 ### 3. Deploying
 
-Once changes have been tested and approved by stakeholders on preview systems,
-they are good to be merged and be shipped to production. Just like for testing,
-one main requirement to consider is:
-
-**Manual deployments have no place in such processes or modern software
-development in general! Teams that deploy manually will be slower, less
-efficient, and ship systems that are less stable than teams that don’t. [^2]**
-
-Teams that aim to push to production several times per day need a stable, fast,
-and reversible deployment process. Stability is essential so randomly failing
-deployments don’t cause friction and slow the process (and thus the team’s
-velocity) down. A fast deployment process is essential for being able to deploy
-multiple times per day at all – if a deployment takes 1h, the maximum number of
-deployments in a day is 8, or maybe 9-10 max. That will turn into a bottleneck
-even for small teams quickly. Finally, even when testing deployments before
-executing them, things can go wrong occasionally. If that happens, it must be
-easy to revert the deployment to fix the production system and clear the path
-for the next deployment that’s likely already waiting.
+Once changes have been tested and approved by stakeholders on preview systems, they are good to be merged and be shipped to production. Just like for testing, one main requirement to consider is:
+
+**Manual deployments have no place in such processes or modern software development in general! Teams that deploy manually will be slower, less efficient, and ship systems that are less stable than teams that don’t. [^2]**
+
+Teams that aim to push to production several times per day need a stable, fast, and reversible deployment process. Stability is essential so randomly failing deployments don’t cause friction and slow the process (and thus the team’s velocity) down. A fast deployment process is essential for being able to deploy multiple times per day at all – if a deployment takes 1h, the maximum number of deployments in a day is 8, or maybe 9-10 max. That will turn into a bottleneck even for small teams quickly. Finally, even when testing deployments before executing them, things can go wrong occasionally. If that happens, it must be easy to revert the deployment to fix the production system and clear the path for the next deployment that’s likely already waiting.
 
 ### 4. Observing
 
-Of course teams will want to know whether the changes they deployed actually
-work in production as intended. Tracking aspects like error rates, performance
-metrics but also usage metrics and similar data is essential to remain on top of
-what’s actually happening on the production systems. Are things running
-smoothly? Has performance regressed since the last deployment? Has usage of a
-particular feature gone down significantly which might indicate a bug that has
-gone unnoticed?
-
-While the need to have observability in place is not controversial in the
-industry, in reality the collected data is often not looked at by anyone. Every
-engineer has witnessed Grafana dashboards that nobody has looked at in weeks or
-Sentry projects with thousands of unresolved errors that just end up being
-ignored as the amount of data simply is overwhelming. Teams that operate at peak
-efficiency will look at their data and at least be aware of sudden spikes that
-often indicate things going differently than they should have. In fact, some of
-these teams even go a step further by collecting their own custom metrics or
-customizing how traces are recorded and woven together to get the most of their
-data.
+Of course teams will want to know whether the changes they deployed actually work in production as intended. Tracking aspects like error rates, performance metrics but also usage metrics and similar data is essential to remain on top of what’s actually happening on the production systems. Are things running smoothly? Has performance regressed since the last deployment? Has usage of a particular feature gone down significantly which might indicate a bug that has gone unnoticed?
+
+While the need to have observability in place is not controversial in the industry, in reality the collected data is often not looked at by anyone. Every engineer has witnessed Grafana dashboards that nobody has looked at in weeks or Sentry projects with thousands of unresolved errors that just end up being ignored as the amount of data simply is overwhelming. Teams that operate at peak efficiency will look at their data and at least be aware of sudden spikes that often indicate things going differently than they should have. In fact, some of these teams even go a step further by collecting their own custom metrics or customizing how traces are recorded and woven together to get the most of their data.
 
 ## Constant shipping as a driver for true agility
 
-Teams that ship constantly, in small steps, are also more – and I’d say truly –
-agile. Teams that follow a legacy release process often work in a pretty
-sequential fashion where product management writes a spec, designers build
-mockups based on that, and engineers implement those in the final step – that’s
-not really agile at all, it’s essentially the very ancient waterfall process,
-just with smaller scopes. In contrast, teams that work and ship more granularly
-work through the process in many small iterations, closely together the entire
-time.
-
-When the goal is to break features or other changes down into steps that are
-each the “smallest-mergeable-unit-of-work” possible so that each of these steps
-is also shippable individually, product, design, engineering, and ops have to
-work together on every step. They need to figure out what the next action is and
-how it can go to production (e.g. behind a feature flag) together. That way,
-walls between product, design, engineering, and ops are broken down and role
-definitions change: product and design are exposed to the small steps in which
-engineers evolve a codebase. At the same time, engineers have to work more
-closely with product managers and designers to help them translate their needs
-into chunks that can be merged and deployed individually. While that closer
-collaboration and change of role definitions necessarily leads to friction,
-teams that work this way will generally be more aligned, have better
-communication, and a more positive team spirit overall.
+Teams that ship constantly, in small steps, are also more – and I’d say truly – agile. Teams that follow a legacy release process often work in a pretty sequential fashion where product management writes a spec, designers build mockups based on that, and engineers implement those in the final step – that’s not really agile at all, it’s essentially the very ancient waterfall process, just with smaller scopes. In contrast, teams that work and ship more granularly work through the process in many small iterations, closely together the entire time.
+
+When the goal is to break features or other changes down into steps that are each the “smallest-mergeable-unit-of-work” possible so that each of these steps is also shippable individually, product, design, engineering, and ops have to work together on every step. They need to figure out what the next action is and how it can go to production (e.g. behind a feature flag) together. That way, walls between product, design, engineering, and ops are broken down and role definitions change: product and design are exposed to the small steps in which engineers evolve a codebase. At the same time, engineers have to work more closely with product managers and designers to help them translate their needs into chunks that can be merged and deployed individually. While that closer collaboration and change of role definitions necessarily leads to friction, teams that work this way will generally be more aligned, have better communication, and a more positive team spirit overall.
 
 ## Let’s ship!
 
-Teams that ship constantly will run circles around those working with a legacy
-release process. They have increased productivity due to a higher level of
-automation, less time spent on process and ceremony around deployment decisions
-and smaller tasks that are better understood by everyone.
-
-Their collaboration is much better due to the increased frequency and amount of
-communication between product, design, engineering, and ops which improves
-transparency and allows people to better understand and thus appreciate the
-perspectives and needs of the other stakeholder groups.
-
-They ship better quality because of the solid and comprehensive testing pipeline
-which they not only need to prevent shipping bugs to their users but in
-extension, to make their process possible at all and keep it going smoothly.
-
-Their users benefit from accelerated value delivery due to the absence of delays
-in the workflow. That gives the teams faster access to user feedback and thus
-allows them to be more aligned with their users’ needs at all times.
-
-Finally teams that ship constantly and continuously are reported to have
-improved morale across the board – from product people to designers and
-engineers. In the end, all software we build, we build to end up in the hands of
-users. The shorter and smoother the path towards that goal is, the more
-satisfaction people will get from their work and the more motivated they will
-be. As Charity Majors puts it:
-
-> [People] who have worked on teams with a short delivery cycle are unwilling to
-> ever work anywhere else again. […]
+Teams that ship constantly will run circles around those working with a legacy release process. They have increased productivity due to a higher level of automation, less time spent on process and ceremony around deployment decisions and smaller tasks that are better understood by everyone.
+
+Their collaboration is much better due to the increased frequency and amount of communication between product, design, engineering, and ops which improves transparency and allows people to better understand and thus appreciate the perspectives and needs of the other stakeholder groups.
+
+They ship better quality because of the solid and comprehensive testing pipeline which they not only need to prevent shipping bugs to their users but in extension, to make their process possible at all and keep it going smoothly.
+
+Their users benefit from accelerated value delivery due to the absence of delays in the workflow. That gives the teams faster access to user feedback and thus allows them to be more aligned with their users’ needs at all times.
+
+Finally teams that ship constantly and continuously are reported to have improved morale across the board – from product people to designers and engineers. In the end, all software we build, we build to end up in the hands of users. The shorter and smoother the path towards that goal is, the more satisfaction people will get from their work and the more motivated they will be. As Charity Majors puts it:
+
+> [People] who have worked on teams with a short delivery cycle are unwilling to ever work anywhere else again. […]
 >
-> No[body] ever got burned out from shipping too much. [People] get burned out
-> from shipping too little.
+> No[body] ever got burned out from shipping too much. [People] get burned out from shipping too little.
 >
 > <author>[Charity Majors](https://charity.wtf)</author>
 
-[^1]:
-    Yes, some exceptions do exist but no, your case is almost certainly not one
-    of those.
+[^1]: Yes, some exceptions do exist but no, your case is almost certainly not one of those.
 
 [^2]: see [^1]
diff --git a/src/posts/2024-07-09-the-embroider-initiative-becomes-the-ember-initiative.md b/src/posts/2024-07-09-the-embroider-initiative-becomes-the-ember-initiative.md
index 255e277548..fd228e3f8c 100644
--- a/src/posts/2024-07-09-the-embroider-initiative-becomes-the-ember-initiative.md
+++ b/src/posts/2024-07-09-the-embroider-initiative-becomes-the-ember-initiative.md
@@ -3,130 +3,59 @@ title: "The Embroider Initiative Becomes the Ember Initiative"
 authorHandle: marcoow
 tags: [ember]
 bio: "Marco Otte-Witte"
-description:
-  "Marco Otte-Witte introduces the Ember Initiative – a permanent effort to
-  advance the Ember ecosystem, building on the success of the Embroider
-  Initiative."
+description: "Marco Otte-Witte introduces the Ember Initiative – a permanent effort to advance the Ember ecosystem, building on the success of the Embroider Initiative."
 og:
   image: /assets/images/posts/2024-07-09-the-embroider-initiative-becomes-the-ember-initiative/og-image.png
-tagline:
-  "<p>The Embroider initiative was a big success for the Ember ecosystem. Having
-  two engineers work full-time on Embroider for a year allowed us to reach a
-  point where new Ember apps can now be built with Vite from the start. It might
-  not be as easy for teams working on slightly older Ember versions, but the
-  path to Vite is open. Most teams just need to update their apps to the latest
-  Ember version to get on to Vite.</p> <p>While the Embroider initiative has
-  come to a successful end, we don’t want to stop pushing the Ember ecosystem
-  forward. The success of the initiative has shown that crowd-funded work on
-  Ember is effective: companies see the reasons to invest, and we can reach our
-  goals, which have real value for everyone in the ecosystem. That’s why we’re
-  proposing to turn the Embroider initiative into a permanent effort – the
-  <strong>Ember Initiative</strong>.</p>"
+tagline: "<p>The Embroider initiative was a big success for the Ember ecosystem. Having two engineers work full-time on Embroider for a year allowed us to reach a point where new Ember apps can now be built with Vite from the start. It might not be as easy for teams working on slightly older Ember versions, but the path to Vite is open. Most teams just need to update their apps to the latest Ember version to get on to Vite.</p> <p>While the Embroider initiative has come to a successful end, we don’t want to stop pushing the Ember ecosystem forward. The success of the initiative has shown that crowd-funded work on Ember is effective: companies see the reasons to invest, and we can reach our goals, which have real value for everyone in the ecosystem. That’s why we’re proposing to turn the Embroider initiative into a permanent effort – the <strong>Ember Initiative</strong>.</p>"
 image: "/assets/images/ember/ember-consulting.jpeg"
 imageAlt: "A group of hamsters"
 ---
 
 ## What is the Ember Initiative about?
 
-Mainmatter will continue to assign a team to work on Ember and its ecosystem
-full-time, indefinitely if we secure enough funding (more on that below). They
-will address topics relevant to the Ember ecosystem and every company that uses
-Ember. The team won’t focus on a single topic like they did with the Embroider
-initiative. Instead, they will work on various issues, addressing whatever is
-most pressing for the Ember ecosystem at any given time. To start, we’re
-proposing 4 main topics:
+Mainmatter will continue to assign a team to work on Ember and its ecosystem full-time, indefinitely if we secure enough funding (more on that below). They will address topics relevant to the Ember ecosystem and every company that uses Ember. The team won’t focus on a single topic like they did with the Embroider initiative. Instead, they will work on various issues, addressing whatever is most pressing for the Ember ecosystem at any given time. To start, we’re proposing 4 main topics:
 
 ### Polishing Embroider
 
-While the Embroider initiative has been a great success and the path towards
-Vite is wide open, there is some work left to do to polish the experience:
+While the Embroider initiative has been a great success and the path towards Vite is wide open, there is some work left to do to polish the experience:
 
-- **Backwards compatibility:** Making Vite builds work with older Ember versions
-  will make it easier for many teams to switch. We suggest making Embroider and
-  Vite compatible with Ember 4.x.
-- **Documentation:** While building Ember apps with Vite should be an
-  out-of-the-box experience, some documentation will need to be updated before
-  it can be the default experience for the wider Ember community.
-- **Opening upgrade paths for the most popular addons:** Ember apps rely heavily
-  on addons, but not all widely used ones work with Vite. We propose that we add
-  support or document alternatives for the most used addons in the Ember
-  ecosystem.
+- **Backwards compatibility:** Making Vite builds work with older Ember versions will make it easier for many teams to switch. We suggest making Embroider and Vite compatible with Ember 4.x.
+- **Documentation:** While building Ember apps with Vite should be an out-of-the-box experience, some documentation will need to be updated before it can be the default experience for the wider Ember community.
+- **Opening upgrade paths for the most popular addons:** Ember apps rely heavily on addons, but not all widely used ones work with Vite. We propose that we add support or document alternatives for the most used addons in the Ember ecosystem.
 
 ### Developer Tooling
 
-Developer tooling hasn't seen much improvement in the Ember ecosystem in the
-past few years. We suggest working on:
+Developer tooling hasn't seen much improvement in the Ember ecosystem in the past few years. We suggest working on:
 
-- **Ember Inspector:** The inspector needs some changes to work properly with
-  Vite-built Ember apps. Also, its capabilities for modern Ember patterns like
-  `<template>` tag components are limited. Fixing this will make developers more
-  efficient.
-- **Glint tooling and TS support:** We suggest our team works with Alex
-  Matchneer, who has already begun improving Ember’s developer experience with
-  TS and moving Glint to Volar for easier maintainability (see
-  [Alex’s talk about the topic at Ember Europe](https://www.youtube.com/watch?v=6zy4nLHj83g)).
+- **Ember Inspector:** The inspector needs some changes to work properly with Vite-built Ember apps. Also, its capabilities for modern Ember patterns like `<template>` tag components are limited. Fixing this will make developers more efficient.
+- **Glint tooling and TS support:** We suggest our team works with Alex Matchneer, who has already begun improving Ember’s developer experience with TS and moving Glint to Volar for easier maintainability (see [Alex’s talk about the topic at Ember Europe](https://www.youtube.com/watch?v=6zy4nLHj83g)).
 
 ### Compiling Ember Apps to Web Components
 
-Teams and companies are increasingly adopting polyglot architectures for their
-frontends, using a mix of different frameworks. Using web components in Ember
-apps is already straightforward. We suggest creating an easy way to compile
-Ember apps themselves into web components so they can be used in other
-applications. This will make it significantly easier to use (and continue using)
-Ember in these contexts.
+Teams and companies are increasingly adopting polyglot architectures for their frontends, using a mix of different frameworks. Using web components in Ember apps is already straightforward. We suggest creating an easy way to compile Ember apps themselves into web components so they can be used in other applications. This will make it significantly easier to use (and continue using) Ember in these contexts.
 
 ### Route and Router Manager APIs
 
-Improving the router has been a long-standing goal in the Ember community, with
-little progress in recent years (Polaris, Ember's next edition, will not ship
-with a router). While the topic is big and we won't be able to ship a new router
-soon, we suggest working on the first step: implementing manager APIs for routes
-and the routing system. This will unblock experimentation by allowing the
-implementation of routes and the routing system to be swapped, bringing the
-ecosystem one step closer to a new router.
+Improving the router has been a long-standing goal in the Ember community, with little progress in recent years (Polaris, Ember's next edition, will not ship with a router). While the topic is big and we won't be able to ship a new router soon, we suggest working on the first step: implementing manager APIs for routes and the routing system. This will unblock experimentation by allowing the implementation of routes and the routing system to be swapped, bringing the ecosystem one step closer to a new router.
 
 Eventually, a new router will bring several benefits:
 
-- By removing controllers and route templates and routing components directly,
-  there will be fewer concepts to deal with (and learn when coming new to
-  Ember), making it much simpler to work with the framework.
-- Eventually, there will be a simpler and more stable mechanism for handling
-  query parameters.
-- A new router will eliminate subtle bugs in the current routing system that
-  have impacted several teams working with Ember.
-- A new routing system will ideally simplify interoperability with other
-  frameworks, such as allowing routing of components written in React, Svelte,
-  and more.
-- It will be easier to split large codebases into smaller, isolated parts that
-  separate teams can work on, as a new router will open the way for building a
-  new version of engines.
+- By removing controllers and route templates and routing components directly, there will be fewer concepts to deal with (and learn when coming new to Ember), making it much simpler to work with the framework.
+- Eventually, there will be a simpler and more stable mechanism for handling query parameters.
+- A new router will eliminate subtle bugs in the current routing system that have impacted several teams working with Ember.
+- A new routing system will ideally simplify interoperability with other frameworks, such as allowing routing of components written in React, Svelte, and more.
+- It will be easier to split large codebases into smaller, isolated parts that separate teams can work on, as a new router will open the way for building a new version of engines.
 
 ## Funding the Initiative
 
-We’d like to fund the above work the same way that worked well for the Embroider
-initiative. Instead of trying to get one company to sponsor all of the work,
-we’re asking many companies to contribute a little each so they can have a
-substantial impact together. Companies that have built on and invested in Ember
-have good reasons to invest in its longevity and progression (see
-[my talk on the topic at EmberFest 2023](https://www.youtube.com/watch?v=QMUm6UOoNRs)).
+We’d like to fund the above work the same way that worked well for the Embroider initiative. Instead of trying to get one company to sponsor all of the work, we’re asking many companies to contribute a little each so they can have a substantial impact together. Companies that have built on and invested in Ember have good reasons to invest in its longevity and progression (see [my talk on the topic at EmberFest 2023](https://www.youtube.com/watch?v=QMUm6UOoNRs)).
 
-Sponsors joining the Ember initiative not only invest in the future and
-longevity of their apps but also get a seat at the initiative's table. They can
-share their pain points with Ember and, depending on the sponsorship tier,
-influence our team's focus. They stay updated on what's happening and, again
-depending on the sponsorship tier, benefit from pairing sessions with our
-experts.
+Sponsors joining the Ember initiative not only invest in the future and longevity of their apps but also get a seat at the initiative's table. They can share their pain points with Ember and, depending on the sponsorship tier, influence our team's focus. They stay updated on what's happening and, again depending on the sponsorship tier, benefit from pairing sessions with our experts.
 
-We encourage companies of all sizes to join the initiative by offering various
-sponsorship tiers to fit every budget. To help make this a permanent effort, we
-provide a discount for companies that sign up for a full year at a time.
+We encourage companies of all sizes to join the initiative by offering various sponsorship tiers to fit every budget. To help make this a permanent effort, we provide a discount for companies that sign up for a full year at a time.
 
 ### A Call to Action
 
-If you are a current sponsor, a decision maker at a company that uses Ember, or
-a passionate Ember engineer willing to convince your higher-ups to join the
-initiative, please [reach out](https://mainmatter.com/contact/)! We’re hopeful
-we can build on the success of the Embroider initiative and make the Ember
-initiative a success for the entire ecosystem, but we need your support!
+If you are a current sponsor, a decision maker at a company that uses Ember, or a passionate Ember engineer willing to convince your higher-ups to join the initiative, please [reach out](https://mainmatter.com/contact/)! We’re hopeful we can build on the success of the Embroider initiative and make the Ember initiative a success for the entire ecosystem, but we need your support!
 
 ❤️🐹
diff --git a/src/posts/2024-07-16-embroider-update.md b/src/posts/2024-07-16-embroider-update.md
index d6284cf74d..4d37af9069 100644
--- a/src/posts/2024-07-16-embroider-update.md
+++ b/src/posts/2024-07-16-embroider-update.md
@@ -3,9 +3,7 @@ title: "Embroider Initiative: Conclusion"
 authorHandle: academierenards
 tags: [ember, embroider]
 bio: "Marine Dunstetter, Senior Software Engineer"
-description:
-  "A summary of what Mainmatter achieved with the Embroider Initiative and what
-  are the next steps for the community."
+description: "A summary of what Mainmatter achieved with the Embroider Initiative and what are the next steps for the community."
 og:
   image: /assets/images/posts/2024-05-29-embroider-update/og-image.jpg
 tagline: |
@@ -14,220 +12,67 @@ tagline: |
   </p>
 
 image: /assets/images/posts/2024-05-29-embroider-update/header-embroider.jpg
-imageAlt:
-  "The logo of companies supporting the Embroider Initiative on a background
-  showing people working together on a laptop"
+imageAlt: "The logo of companies supporting the Embroider Initiative on a background showing people working together on a laptop"
 ---
 
-Over the past year, the Embroider Initiative has opened the door to building
-Ember apps with Vite, bringing Ember's build system more in line with other
-modern frameworks. Ember has started to be noticed in the wider Javascript
-community and remains a good choice in 2024, thanks to everything that was
-accomplished through the Embroider Initiative and all the companies that
-invested to make it happen. As the Embroider Initiative becomes the Ember
-Initiative, let's take a look at what we achieved so far and the next steps that
-are now possible.
+Over the past year, the Embroider Initiative has opened the door to building Ember apps with Vite, bringing Ember's build system more in line with other modern frameworks. Ember has started to be noticed in the wider Javascript community and remains a good choice in 2024, thanks to everything that was accomplished through the Embroider Initiative and all the companies that invested to make it happen. As the Embroider Initiative becomes the Ember Initiative, let's take a look at what we achieved so far and the next steps that are now possible.
 
 ## Implement the core of Embroider
 
-The biggest part of the work so far was of course to implement the core of
-Embroider. The
-[lastest blog post from May](https://mainmatter.com/blog/2024/05/29/embroider-update/)
-is a good summary of the different steps of the implementation. In even shorter
-words:
-
-- To achieve backward compatibility, each classic Ember Addon package is rebuilt
-  into a new v2 package format stored in a `rewritten-packages` folder, more
-  static and analyzable.
-
-- By default, Ember apps can't be built with Vite because they rely on features
-  Vite cannot understand. To work around this problem, Embroider generates a
-  `rewritten-app`, which is slightly different from the initial Ember app in a
-  way it can be consumed by Vite. But the generation of this rewritten app is an
-  extra step that comes with performance downsides.
-
-- To optimize the Vite build, we have started a wide technical topic called
-  “Inversion of Control”. The idea is that instead of having Embroider produce a
-  rewritten app, and then passing over to Vite once the rewritten app is ready,
-  Vite takes the lead, and when it’s unable to resolve Ember-specific requests,
-  it asks Embroider to return the information without the need of a rewritten
-  app.
-
-The sections below provide an overview of this "Inversion of Control" process,
-which consists of gradually replacing a large proportion of the `rewritten-app`
-with this virtual content that Vite can understand
+The biggest part of the work so far was of course to implement the core of Embroider. The [lastest blog post from May](https://mainmatter.com/blog/2024/05/29/embroider-update/) is a good summary of the different steps of the implementation. In even shorter words:
+
+- To achieve backward compatibility, each classic Ember Addon package is rebuilt into a new v2 package format stored in a `rewritten-packages` folder, more static and analyzable.
+
+- By default, Ember apps can't be built with Vite because they rely on features Vite cannot understand. To work around this problem, Embroider generates a `rewritten-app`, which is slightly different from the initial Ember app in a way it can be consumed by Vite. But the generation of this rewritten app is an extra step that comes with performance downsides.
+
+- To optimize the Vite build, we have started a wide technical topic called “Inversion of Control”. The idea is that instead of having Embroider produce a rewritten app, and then passing over to Vite once the rewritten app is ready, Vite takes the lead, and when it’s unable to resolve Ember-specific requests, it asks Embroider to return the information without the need of a rewritten app.
+
+The sections below provide an overview of this "Inversion of Control" process, which consists of gradually replacing a large proportion of the `rewritten-app` with this virtual content that Vite can understand
 
 ### Optimize the Vite build with inversion of control
 
-To put it very simply: Vite cannot build the initial Ember app, but it can build
-the rewritten app, so we are going to remove all the differences between both
-apps so Vite can consume the initial Ember app directly... easier said than done
-though, because the rewritten app is allowed to contain files generated during
-the build process that cannot be part of the Ember app code base. When these
-nonexisting files are requested to the Vite dev server, Embroider must be able
-to return a consistent answer on the spot as virtual content. The clearest
-example is probably the vendor file. In classic apps, `index.html` contains a
-reference to `assets/vendor.js` (prefixed by the root URL), which points to a
-file created during the classic build pipeline. When using Vite, this reference
-must be replaced with `/@embroider/core/vendor.js`, a virtual identifier that
-will tell Vite to ask Embroider for the content. On the other hand, part of
-these virtual content must be emitted as assets for the production build, and
-now this has to be done by Vite through custom plugins. Files virtualization
-came with its set of challenges, like finding the right approach to deal with
-Vite specifics in a way that keeps Embroider core bundler-agnostic.
-
-🐹 _What's next:_ During the Embroider initiative, we have reached a point where
-we are very close to removing the need for the rewritten app completely; there
-are a few tasks left that are interdependent and already in progress. Also, to
-work on the inversion of control, we had to stop Webpack support, which doesn't
-use this new approach. Once the rewritten app is removed, one next step will be
-to re-implement Webpack support with the inversion of control approach, and
-therefore prove Embroider is truly bundler-agnostic.
+To put it very simply: Vite cannot build the initial Ember app, but it can build the rewritten app, so we are going to remove all the differences between both apps so Vite can consume the initial Ember app directly... easier said than done though, because the rewritten app is allowed to contain files generated during the build process that cannot be part of the Ember app code base. When these nonexisting files are requested to the Vite dev server, Embroider must be able to return a consistent answer on the spot as virtual content. The clearest example is probably the vendor file. In classic apps, `index.html` contains a reference to `assets/vendor.js` (prefixed by the root URL), which points to a file created during the classic build pipeline. When using Vite, this reference must be replaced with `/@embroider/core/vendor.js`, a virtual identifier that will tell Vite to ask Embroider for the content. On the other hand, part of these virtual content must be emitted as assets for the production build, and now this has to be done by Vite through custom plugins. Files virtualization came with its set of challenges, like finding the right approach to deal with Vite specifics in a way that keeps Embroider core bundler-agnostic.
+
+🐹 _What's next:_ During the Embroider initiative, we have reached a point where we are very close to removing the need for the rewritten app completely; there are a few tasks left that are interdependent and already in progress. Also, to work on the inversion of control, we had to stop Webpack support, which doesn't use this new approach. Once the rewritten app is removed, one next step will be to re-implement Webpack support with the inversion of control approach, and therefore prove Embroider is truly bundler-agnostic.
 
 ### Maintain the compatibility of all classic features
 
-A very wide part of the inversion of control is related to maintaining classic
-functionalities and keeping v1 addons working the way they used to work in
-classic builds. For instance, it makes sense that Vite generates a `vendor.css`
-file in the production build only if some classic addon provides styles to
-include in there; it makes sense that Embroider is able to locate an addon's
-public asset in the rewritten packages and to return its path to the Vite dev
-server only because that addon provides that public asset. Classic addons can
-also implement hooks like `contentFor` that transform the content of the app's
-`index.html`, and many other things.
-
-We could create the rewritten app directly the way it needed to be so all these
-features work. With inversion of control, the purpose of each classic
-functionality must be carefully thought out so we decide what's the best new way
-to handle it. There are three categories of such features:
-
-- **We want to keep this feature as it is**: As Vite is now in charge of the
-  build, it should now be responsible for tasks that were previously handled by
-  Broccoli plugins, like emitting assets in the production build, or
-  transforming the `index.html`. This is what was done for `vendor.js`,
-  `vendor.css`, `test-support.js`, `test-support.css`, public assets,
-  `content-for` snippets in `index.html`, initializers and
-  instance-initializers... When it comes to upgrading v1 addons to v2,
-  `@embroider/macros` is also a way to keep v2 addons "dynamic" by using Babel
-  to transform addon code depending on the app build environment and options.
-
-- **This should now be the responsibility of the app**: because Ember does a lot
-  of things under the hood, classic addons ended up implementing capabilities to
-  modify app code the developer cannot access, they kind of "come with their own
-  configuration" instead of "explain how they should be configured". This is
-  something that will change in modern Ember apps. For instance, classic addons
-  could use the `contentFor` hook to change the way the app boots. In the new
-  Ember app format, the developer will have access to the app-boot script
-  directly in the `index.html`, so addons no longer need to try modifying it
-  under the hood. Instead of supporting this feature, we decided to implement
-  the detection of this hook being used and an informative message about how to
-  update the app. The same rationale was used for `contentFor 'config-module'`.
-
-- **We may not want to support this anymore**: some features have been
-  deprioritized because we question their purpose. One example is the
-  `serverMiddleware` hook. This hook allowed you to make changes to the express
-  server run by ember-cli. This dev-only concept disappears with Vite, since we
-  rely on the Vite dev server. Do we really want a way to re-implements in Vite
-  middlewares what `serverMiddleware` hook was doing considering that, at the
-  very beginning, this feature creates a big gap between testing the app in dev
-  mode and production mode? There are probably better ways to make the test
-  closer to a “production context”.
-
-🐹 _What's next:_ During the Embroider Initiative, we prioritized the support of
-the most important classic features, that are widely used by the community. Some
-other less used features are not supported yet, like FastBoot, or storing the
-environment config in JS rather than `index.html` meta. The issue
-[embroider-build/embroider#1860](https://github.com/embroider-build/embroider/issues/1860)
-contains a list of identified features that still require work.
+A very wide part of the inversion of control is related to maintaining classic functionalities and keeping v1 addons working the way they used to work in classic builds. For instance, it makes sense that Vite generates a `vendor.css` file in the production build only if some classic addon provides styles to include in there; it makes sense that Embroider is able to locate an addon's public asset in the rewritten packages and to return its path to the Vite dev server only because that addon provides that public asset. Classic addons can also implement hooks like `contentFor` that transform the content of the app's `index.html`, and many other things.
+
+We could create the rewritten app directly the way it needed to be so all these features work. With inversion of control, the purpose of each classic functionality must be carefully thought out so we decide what's the best new way to handle it. There are three categories of such features:
+
+- **We want to keep this feature as it is**: As Vite is now in charge of the build, it should now be responsible for tasks that were previously handled by Broccoli plugins, like emitting assets in the production build, or transforming the `index.html`. This is what was done for `vendor.js`, `vendor.css`, `test-support.js`, `test-support.css`, public assets, `content-for` snippets in `index.html`, initializers and instance-initializers... When it comes to upgrading v1 addons to v2, `@embroider/macros` is also a way to keep v2 addons "dynamic" by using Babel to transform addon code depending on the app build environment and options.
+
+- **This should now be the responsibility of the app**: because Ember does a lot of things under the hood, classic addons ended up implementing capabilities to modify app code the developer cannot access, they kind of "come with their own configuration" instead of "explain how they should be configured". This is something that will change in modern Ember apps. For instance, classic addons could use the `contentFor` hook to change the way the app boots. In the new Ember app format, the developer will have access to the app-boot script directly in the `index.html`, so addons no longer need to try modifying it under the hood. Instead of supporting this feature, we decided to implement the detection of this hook being used and an informative message about how to update the app. The same rationale was used for `contentFor 'config-module'`.
+
+- **We may not want to support this anymore**: some features have been deprioritized because we question their purpose. One example is the `serverMiddleware` hook. This hook allowed you to make changes to the express server run by ember-cli. This dev-only concept disappears with Vite, since we rely on the Vite dev server. Do we really want a way to re-implements in Vite middlewares what `serverMiddleware` hook was doing considering that, at the very beginning, this feature creates a big gap between testing the app in dev mode and production mode? There are probably better ways to make the test closer to a “production context”.
+
+🐹 _What's next:_ During the Embroider Initiative, we prioritized the support of the most important classic features, that are widely used by the community. Some other less used features are not supported yet, like FastBoot, or storing the environment config in JS rather than `index.html` meta. The issue [embroider-build/embroider#1860](https://github.com/embroider-build/embroider/issues/1860) contains a list of identified features that still require work.
 
 ## Support older Ember versions
 
-Embroider uses a tool called scenario-tester to test many apps and addons
-scenarios against different Ember versions. Currently, the Vite branch of the
-Embroider project runs against Ember 5.8 and canary, which means you need to
-upgrade your app to the latest Ember to build with Vite.
-
-Recently, we have been working hard on improving scenario-tester and having the
-stable branch run against Ember 3.28 and above. This work includes an important
-fix for ember-data 4.x: the latest improvements on scenario-tester fixed the way
-some dependencies are managed, which highlighted false positives in the test
-suite and reproduced errors encountered by developers in their apps. This
-allowed us to find the root cause and fix Embroider to correctly manage
-ember-data 4.x and any addon that may behave the same way. Not only did this
-work positively impact the stable branch of Embroider, it also laid the
-groundwork to support older Ember versions in Vite.
-
-🐹 _What's next:_ Ideally, we would like to bring the Vite build to Ember 3.28,
-as it's the oldest version supported on Embroider Stable. The task will
-essentially consist of fixing circular dependencies in ember-source to get a
-correct ESM graph. Functionalities like assert, debug, deprecate… need to be
-patched in older Ember versions. The idea is to implement a set of patches for
-each version we want to support.
+Embroider uses a tool called scenario-tester to test many apps and addons scenarios against different Ember versions. Currently, the Vite branch of the Embroider project runs against Ember 5.8 and canary, which means you need to upgrade your app to the latest Ember to build with Vite.
+
+Recently, we have been working hard on improving scenario-tester and having the stable branch run against Ember 3.28 and above. This work includes an important fix for ember-data 4.x: the latest improvements on scenario-tester fixed the way some dependencies are managed, which highlighted false positives in the test suite and reproduced errors encountered by developers in their apps. This allowed us to find the root cause and fix Embroider to correctly manage ember-data 4.x and any addon that may behave the same way. Not only did this work positively impact the stable branch of Embroider, it also laid the groundwork to support older Ember versions in Vite.
+
+🐹 _What's next:_ Ideally, we would like to bring the Vite build to Ember 3.28, as it's the oldest version supported on Embroider Stable. The task will essentially consist of fixing circular dependencies in ember-source to get a correct ESM graph. Functionalities like assert, debug, deprecate… need to be patched in older Ember versions. The idea is to implement a set of patches for each version we want to support.
 
 ## Stabilize the app blueprint
 
-The implementation of the core of Embroider drives a new authoring format for
-modern Ember apps. The approach we choose to answer compatibility questions
-always tends toward making modern Ember apps more standardized. Between
-Embroider Stable and Embroider Vite, the shape of the Ember app has changed
-quite a bit. Among other things: the developer now has full control over the
-app-boot module (which is now an in-html script in `index.html`) and the config
-environment module (which is located in `app/config/environment.js`), a part of
-the scripts are virtual modules identified by a virtual identifier starting with
-`@embroider`, the AMD modules brought by classic addons are now defined in
-`app/app.js` to get the notion of AMD out of Embroider and pave the ground to a
-new resolver with
-[strict ESM support](https://github.com/emberjs/rfcs/pull/938/), etc...
-
-Some tasks are only about making the Ember apps more standard and comprehensible
-without being directly related to compatibility questions. That's the case for
-the Babel's config for example. Any classic Ember app depends on
-ember-cli-babel, which builds a set of Babel plugins the app requires to run
-correctly. ember-cli-babel can be controlled through some build options. In
-modern Ember apps, the `babel.config.cjs` file will be responsible for the Babel
-config, and the power to control Babel should not be split between
-`babel.config.cjs` and build options. We are currently working on removing the
-mandatory dependency to ember-cli-babel by creating a `babel.config.cjs`
-made-for-Ember that will be provided in a new app blueprint.
-
-On May 31st, Chris presented at EmberConf and introduced the
-[new Vite app blueprint](https://github.com/embroider-build/app-blueprint) that
-allows people to generate an Ember app building with Vite from the start. The CI
-runs against the Vite branch of Embroider, so each time we merge something, we
-can see if the app generated by the blueprint runs correctly. An important step
-of Embroider development is to answer all the questions that allow us to define
-what the app blueprint looks like, and therefore what developers start with when
-creating a brand new app.
-
-🐹 _What's next:_ Now that we have a good idea of what a modern Ember app looks
-like, an important next step is to describe it in an RFC to introduce it to the
-community and open the door to potential discussions and improvements.
+The implementation of the core of Embroider drives a new authoring format for modern Ember apps. The approach we choose to answer compatibility questions always tends toward making modern Ember apps more standardized. Between Embroider Stable and Embroider Vite, the shape of the Ember app has changed quite a bit. Among other things: the developer now has full control over the app-boot module (which is now an in-html script in `index.html`) and the config environment module (which is located in `app/config/environment.js`), a part of the scripts are virtual modules identified by a virtual identifier starting with `@embroider`, the AMD modules brought by classic addons are now defined in `app/app.js` to get the notion of AMD out of Embroider and pave the ground to a new resolver with [strict ESM support](https://github.com/emberjs/rfcs/pull/938/), etc...
+
+Some tasks are only about making the Ember apps more standard and comprehensible without being directly related to compatibility questions. That's the case for the Babel's config for example. Any classic Ember app depends on ember-cli-babel, which builds a set of Babel plugins the app requires to run correctly. ember-cli-babel can be controlled through some build options. In modern Ember apps, the `babel.config.cjs` file will be responsible for the Babel config, and the power to control Babel should not be split between `babel.config.cjs` and build options. We are currently working on removing the mandatory dependency to ember-cli-babel by creating a `babel.config.cjs` made-for-Ember that will be provided in a new app blueprint.
+
+On May 31st, Chris presented at EmberConf and introduced the [new Vite app blueprint](https://github.com/embroider-build/app-blueprint) that allows people to generate an Ember app building with Vite from the start. The CI runs against the Vite branch of Embroider, so each time we merge something, we can see if the app generated by the blueprint runs correctly. An important step of Embroider development is to answer all the questions that allow us to define what the app blueprint looks like, and therefore what developers start with when creating a brand new app.
+
+🐹 _What's next:_ Now that we have a good idea of what a modern Ember app looks like, an important next step is to describe it in an RFC to introduce it to the community and open the door to potential discussions and improvements.
 
 ## Handover
 
-The Embroider Initiative has come to a successful end; We have achieved so much
-and we are proud to see some Ember apps in the community making their way to
-Vite. As it currently stands, it's now up to the Ember Community to continue the
-implementation of Embroider. To facilitate the handover from the Embroider
-Initiative, we created the public GitHub project
-[Embroider Working Group](https://github.com/orgs/embroider-build/projects/2) to
-help future contributors keep track of the existing issues and their current
-status.
-
-We at Mainmatter want to continue investing into the Ember ecosystem which is
-why we're starting the Ember initiative as a successor to the Embroider
-initiative. The Ember Initiative will not be focused on a single topic like the
-Embroider Initiative, it will instead address a number of topics relevant to the
-Ember ecosystem and every company that uses Ember. Polishing Embroider and
-making it the default experience for new Ember apps is part of the main topics
-we're proposing. Check out our [Ember Initiative](/ember-initiative/) page and
-our dedicated blog post
-[The Embroider Initiative Becomes the Ember Initiative](/blog/2024/07/09/the-embroider-initiative-becomes-the-ember-initiative/).
+The Embroider Initiative has come to a successful end; We have achieved so much and we are proud to see some Ember apps in the community making their way to Vite. As it currently stands, it's now up to the Ember Community to continue the implementation of Embroider. To facilitate the handover from the Embroider Initiative, we created the public GitHub project [Embroider Working Group](https://github.com/orgs/embroider-build/projects/2) to help future contributors keep track of the existing issues and their current status.
+
+We at Mainmatter want to continue investing into the Ember ecosystem which is why we're starting the Ember initiative as a successor to the Embroider initiative. The Ember Initiative will not be focused on a single topic like the Embroider Initiative, it will instead address a number of topics relevant to the Ember ecosystem and every company that uses Ember. Polishing Embroider and making it the default experience for new Ember apps is part of the main topics we're proposing. Check out our [Ember Initiative](/ember-initiative/) page and our dedicated blog post [The Embroider Initiative Becomes the Ember Initiative](/blog/2024/07/09/the-embroider-initiative-becomes-the-ember-initiative/).
 
 ## Conclusion
 
-Over the past year, our team at Mainmatter has built a solid knowledge of
-Embroider's core and we have helped Embroider clear the monumental hurdle that
-has been enabling Vite support. We can help the Ember community cross the finish
-line with Embroider and continue to improve Ember and its ecosystem if you give
-us the means to do it by backing the Ember Initiative.
+Over the past year, our team at Mainmatter has built a solid knowledge of Embroider's core and we have helped Embroider clear the monumental hurdle that has been enabling Vite support. We can help the Ember community cross the finish line with Embroider and continue to improve Ember and its ecosystem if you give us the means to do it by backing the Ember Initiative.
diff --git a/src/posts/2024-07-29-preparing-the-terrain-for-successful-engagements.md b/src/posts/2024-07-29-preparing-the-terrain-for-successful-engagements.md
index be50d46bd9..ffda8f1baa 100644
--- a/src/posts/2024-07-29-preparing-the-terrain-for-successful-engagements.md
+++ b/src/posts/2024-07-29-preparing-the-terrain-for-successful-engagements.md
@@ -4,76 +4,50 @@ authorHandle: oliverbarnes
 twitter: oliverbarnes
 tags: [startups, consulting]
 bio: "Oliver Azevedo Barnes"
-description:
-  "Oliver Barnes on the importance of getting the team onboard when bringing in
-  a consultancy"
+description: "Oliver Barnes on the importance of getting the team onboard when bringing in a consultancy"
 og:
   image: /assets/images/posts/2024-07-29-preparing-the-terrain-for-successful-engagements/og-image.jpg
 tagline: |
   <p>A consultancy engagement can be a very productive, gratifying collaborative process. That's _if_ the client's team is onboard with having it come in to help</p>
 ---
 
-"Ugh, leadership is bringing in a bunch of consultants from Evil Co to audit the
-team and point out our inefficiencies… this can't be good, right?"
+"Ugh, leadership is bringing in a bunch of consultants from Evil Co to audit the team and point out our inefficiencies… this can't be good, right?"
 
-Consultants get a bad rep sometimes, and often for good reason, specially due to
-powerful top tier consultancies involved in everything from privatization of
-public companies to disaster relief. They're everywhere these days.
+Consultants get a bad rep sometimes, and often for good reason, specially due to powerful top tier consultancies involved in everything from privatization of public companies to disaster relief. They're everywhere these days.
 
-Software engineering consultancies like Mainmatter are nothing like that, but
-still "consultant" is a title with plenty of loaded meanings and associations.
+Software engineering consultancies like Mainmatter are nothing like that, but still "consultant" is a title with plenty of loaded meanings and associations.
 
-Outsiders _can_ be helpful. External experience and a fresh view on things can
-be very useful. But, as with any collaboration, it's important to respect
-context and history, and to get the client's team onboard.
+Outsiders _can_ be helpful. External experience and a fresh view on things can be very useful. But, as with any collaboration, it's important to respect context and history, and to get the client's team onboard.
 
 ## Making sure we're welcome guests
 
-When starting with a new client, we're mindful that we're coming in during a
-time of difficult change - be it in technical terms (changing stacks or merging
-systems, for example) or organizational ones, say when a team is expanding and
-re-organizing.
+When starting with a new client, we're mindful that we're coming in during a time of difficult change - be it in technical terms (changing stacks or merging systems, for example) or organizational ones, say when a team is expanding and re-organizing.
 
 And, as often happens, both at once.
 
-We discuss that with the leadership team and with different stakeholders who
-might be involved in bringing us in to prepare the terrain for the engagement.
+We discuss that with the leadership team and with different stakeholders who might be involved in bringing us in to prepare the terrain for the engagement.
 
 ## Happy path
 
-When the client's team is bought-in, we get an environment of trust, a sweet
-spot where we complement the client's team seamlessly.
+When the client's team is bought-in, we get an environment of trust, a sweet spot where we complement the client's team seamlessly.
 
-Context and knowledge are shared proactively, affording us smooth onboarding.
-Once we have some recommendations to give, these are discussed constructively.
-Decisions on what to implement are naturally done in alignment.
+Context and knowledge are shared proactively, affording us smooth onboarding. Once we have some recommendations to give, these are discussed constructively. Decisions on what to implement are naturally done in alignment.
 
-A virtuous cycle ensues, where implementing changes is progressively faster and
-more effective, and ideas flow freely back and forth. Together we shift into
-continous improvement mode. Everybody wins.
+A virtuous cycle ensues, where implementing changes is progressively faster and more effective, and ideas flow freely back and forth. Together we shift into continous improvement mode. Everybody wins.
 
 So. How do you get buy-in?
 
 ## Get the team involved early on
 
-The earlier the intention to bring us in is communicated, the better. Before
-even making a decision, hearing the team out and addressing any concerns is a
-very good idea - building trust in the engagement.
+The earlier the intention to bring us in is communicated, the better. Before even making a decision, hearing the team out and addressing any concerns is a very good idea - building trust in the engagement.
 
-Sometimes it's hard to get that trust, of course. But when dissenters have been
-heard in earnest, that goes a _long_ way towards getting people to
-[disagree and commit](https://en.wikipedia.org/wiki/Disagree_and_commit).
+Sometimes it's hard to get that trust, of course. But when dissenters have been heard in earnest, that goes a _long_ way towards getting people to [disagree and commit](https://en.wikipedia.org/wiki/Disagree_and_commit).
 
 ## Who invites us
 
-Sometimes we are invited by people from the tech or product teams, who are
-closer to where the action happens. In this case, the team is already
-bought-in - the invitation addresses specific demands from the teams we'll be
-working with.
+Sometimes we are invited by people from the tech or product teams, who are closer to where the action happens. In this case, the team is already bought-in - the invitation addresses specific demands from the teams we'll be working with.
 
-In other instances, the invitation comes from a client's leadership. In these
-cases it makes a huge difference when they openly talk about it to the teams
-that will directly be involved in, and impacted by, the engagement.
+In other instances, the invitation comes from a client's leadership. In these cases it makes a huge difference when they openly talk about it to the teams that will directly be involved in, and impacted by, the engagement.
 
 ## Framing the engagement
 
@@ -81,82 +55,52 @@ And _how_ the engagement itself is communicated is key.
 
 ### Assessments, not audits
 
-Some of our engagements begin with
-[an assessment of a client's current state of tech and organization](https://mainmatter.com/services/strategic-advice/).
-This can be either a high-level x-ray, or a more specific analysis of a team or
-of a system component.
+Some of our engagements begin with [an assessment of a client's current state of tech and organization](https://mainmatter.com/services/strategic-advice/). This can be either a high-level x-ray, or a more specific analysis of a team or of a system component.
 
-An assessment can be super helpful for a client to find blind-spots, to get an
-independent point of view in the context of conflicting internal assessments,
-and when planning for big changes.
+An assessment can be super helpful for a client to find blind-spots, to get an independent point of view in the context of conflicting internal assessments, and when planning for big changes.
 
-This is most successful when a team is willing to show what's under the hood in
-the tech stack, and behind the scenes in terms of team interactions and
-processes.
+This is most successful when a team is willing to show what's under the hood in the tech stack, and behind the scenes in terms of team interactions and processes.
 
-If instead a team perceives the assessment as an _audit_, a quality control
-inspection where blame is distributed and people eventually get in trouble,
-transparency (and morale) will obviously suffer.
+If instead a team perceives the assessment as an _audit_, a quality control inspection where blame is distributed and people eventually get in trouble, transparency (and morale) will obviously suffer.
 
-Some discontent might start brewing, understandably. In turn, potential future
-interactions and collaborative work might be seriously affected.
+Some discontent might start brewing, understandably. In turn, potential future interactions and collaborative work might be seriously affected.
 
 That's a very bad start.
 
-Hence, Mainmatter doesn't do audits. We offer blameless assessments as a
-resource to help teams plan their future work, possibly leading us to a fruitful
-collaboration down the line.
+Hence, Mainmatter doesn't do audits. We offer blameless assessments as a resource to help teams plan their future work, possibly leading us to a fruitful collaboration down the line.
 
-From a client's team perspective, blameless assessments can help them advance
-internal improvements they might already have been pushing for: more budget or
-people, better tooling, leaner organization, more knowledge sharing, among many
-other possibilities.
+From a client's team perspective, blameless assessments can help them advance internal improvements they might already have been pushing for: more budget or people, better tooling, leaner organization, more knowledge sharing, among many other possibilities.
 
 ### Collaboration, not intervention
 
-In a similar fashion, when we augment a team (with engineers, architects,
-designers or managers, sometimes all of the above), we work hard to ensure this
-work is collaborative and not perceived as an intervention.
+In a similar fashion, when we augment a team (with engineers, architects, designers or managers, sometimes all of the above), we work hard to ensure this work is collaborative and not perceived as an intervention.
 
-We're making suggestions, sharing knowledge and practices, pairing and planning
-together, constantly building consensus.
+We're making suggestions, sharing knowledge and practices, pairing and planning together, constantly building consensus.
 
 We're complementing the team until they no longer need us.
 
 ### Alignment on scope
 
-An engagement can take many shapes and forms. It can have a tightly bounded
-scope, like updating the runtime and dependencies of a given codebase, or a much
-broader and open ended one, into architecture, engineering processes and
-practices.
+An engagement can take many shapes and forms. It can have a tightly bounded scope, like updating the runtime and dependencies of a given codebase, or a much broader and open ended one, into architecture, engineering processes and practices.
 
 Whatever the scope, the earliest it is clearly communicated, the better.
 
-People can become territorial over their work. Nobody likes having someone
-unexpected looking over their shoulders, nor receiving unsolicited advice.
+People can become territorial over their work. Nobody likes having someone unexpected looking over their shoulders, nor receiving unsolicited advice.
 
-If there's a misunderstanding over the scope of our work, that's exactly how
-it'll feel to the client's team.
+If there's a misunderstanding over the scope of our work, that's exactly how it'll feel to the client's team.
 
 So being aligned on scope and objectives is fundamental.
 
 ## During the engagement
 
-Client team buy-in involves accepting to at least hear recommendations from us,
-and for this to continue, our recommendations have to resonate and make sense,
-even if they the team doesn't totally agree with them.
+Client team buy-in involves accepting to at least hear recommendations from us, and for this to continue, our recommendations have to resonate and make sense, even if they the team doesn't totally agree with them.
 
-Addressing pain points is a great way to ensure this relevance, and build trust.
-We're solving real problems, removing slogs. Improving productivity. Making work
-more pleasurable.
+Addressing pain points is a great way to ensure this relevance, and build trust. We're solving real problems, removing slogs. Improving productivity. Making work more pleasurable.
 
-Often we'll find issues that weren't raised before. Or ones where a priority and
-solution weren't yet agreed upon. In these cases, we study and discuss until
-there's enough alignment.
+Often we'll find issues that weren't raised before. Or ones where a priority and solution weren't yet agreed upon. In these cases, we study and discuss until there's enough alignment.
 
 And then we help them implement it. As part of the team.
 
 [Reach out](/contact/) to talk about how we can help your team.
 
-Find [further information](/services/team-reinforcement/) on how we can help you
-to burst through the bottleneck.
+Find [further information](/services/team-reinforcement/) on how we can help you to burst through the bottleneck.
diff --git a/src/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino.md b/src/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino.md
new file mode 100644
index 0000000000..20a624ba84
--- /dev/null
+++ b/src/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino.md
@@ -0,0 +1,26 @@
+---
+title: "Exploring the Potential of Rust in Serverless Computing with Luciano Mammino"
+authorHandle: algo_luca
+tags: [rust]
+bio: "Luca Palmieri, Principal Engineering Consultant"
+description: "Luciano Mammino, Senior Architect, and Luca Palmieri, Principal Engineering Consultant, discuss Luciano’s shift from JavaScript to Rust for serverless computing, highlighting Rust’s performance, safety, and its potential to optimize AWS Lambda functions."
+og:
+  image: "/assets/images/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino/og-image.png"
+tagline: |
+  <p>
+  Luciano Mammino, Senior Architect, and Luca Palmieri, Principal Engineering Consultant, discuss Luciano’s shift from JavaScript to Rust for serverless computing, highlighting Rust’s performance, safety, and its potential to optimize AWS Lambda functions.
+  </p>
+
+image: "/assets/images/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino/header.jpg"
+imageAlt: "Luciano's picture on a gray background"
+---
+
+In a recent interview, Luca Palmieri, Mainmatter’s Principal Engineering Consultant and author of “Zero to Production in Rust,” spoke with Luciano Mammino, a Senior Architect with extensive experience in cloud-native development and author of “Node.js Design Patterns.” They talked about Luciano’s journey from using high-level programming languages like JavaScript to adopting Rust for serverless computing, particularly in AWS Lambda.
+
+Driven by the need for better performance in a Lambda function, Luciano began exploring Rust, appreciating its efficiency and safety features. Despite the learning curve, he found Rust’s approach to memory management to be a powerful tool for building reliable, performant code.
+
+Luciano highlighted that serverless computing is an ideal entry point for Rust in organizations. The combination of Rust’s efficiency and AWS Lambda’s scalability can lead to significant cost savings and performance improvements. He also pointed out the availability of tools like Cargo Lambda, which streamline the deployment process of Rust functions in a serverless environment.
+
+While Rust may be challenging to learn, Luciano emphasized the confidence it brings in production environments due to its focus on safety. He believes that as more developers and organizations experience these benefits, Rust will gain more traction in the serverless ecosystem. Luciano’s experience offers valuable insights for anyone considering Rust for their next cloud-native project, demonstrating the language’s potential to optimize serverless functions and build more reliable applications.
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/U9JZD7d9OmA" title="Embedded video of Luciano's interview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
diff --git a/src/posts/2024-10-30-introducing-sheepdogjs.md b/src/posts/2024-10-30-introducing-sheepdogjs.md
new file mode 100644
index 0000000000..1253f78bdf
--- /dev/null
+++ b/src/posts/2024-10-30-introducing-sheepdogjs.md
@@ -0,0 +1,172 @@
+---
+title: "Handling concurrency in Svelte with Sheepdog"
+authorHandle: beerinho
+tags: ["svelte"]
+bio: "Daniel Beer"
+description: "Daniel Beer introduces Sheepdog, the newest way to handle asynchronous tasks in your Svelte app"
+og:
+  image: "/assets/images/posts/2024-10-30-introducing-sheepdogjs/og-image.png"
+tagline: |
+  <p>
+    Sometimes handling async tasks can feel like trying to herd sheep. With Sheepdog, you'll have an expert to help you keep your async flock in order.
+  </p>
+
+image: ""
+imageAlt: ""
+---
+
+## The motivation
+
+Coming from an EmberJS background, one of the utilities I immediately missed in the Svelte ecosystem was a way to handle concurrency the way that [ember-concurrency](https://ember-concurrency.com/) does so well. Assuming this must have been a path that had already been trodden by other bright minds, our team took to Google to see what was already out there. We found two options that could be interesting:
+
+- [svelte-concurrency](https://github.com/machty/svelte-concurrency) - made by the creator of ember-concurrency but unfortunately hasn’t been touched in 5 years
+- [effection](https://github.com/thefrontside/effection) - a powerful framework agnostic concurrency library, but it felt a bit too heavy for what we wanted to do. Ideally we’d have something a bit more svelte (geddit)
+
+After spending some time playing around with these two options and deeming them as unsuitable for our use-case, a small team lead by our Svelte expert [Paolo Ricciuti](https://x.com/paoloricciuti) (co-creator of [SvelteLab](https://www.sveltelab.dev/) and Svelte ambassador and maintainer) set out to create a lightweight package that could handle concurrency in Svelte applications.
+
+## Introducing Sheepdog
+
+After weeks of work, we are proud to unveil our creation: [Sheepdog](https://sheepdog.run/)! A lightweight way to herd your asynchronous tasks.
+
+You can learn all about Sheepdog and how it works in [the docs](https://sheepdog.run/getting-started/what-is-it/) so for now, I'll give you a quick rundown of why you'll want to keep it in your Svelte toolbox.
+
+As a very basic example, imagine you want to create a Svelte component that will search while the user types, but to reduce the number of requests sent to your server, you want to wait for the user to stop typing before you send the request. With Sheepdog, it would look like this:
+
+```js
+{% raw %}
+<script>
+  import { task, timeout } from '@sheepdog/svelte';
+
+  let searchTask = task.restart(async function(value) {
+    await timeout(500);
+    let response = await fetch('/search?q=' + value);
+    return await response.json();
+  });
+</script>
+
+<label for="search">Search</label>
+<input
+  name="search"
+  type="text"
+  on:input={
+    (event) => searchTask.perform(event.target.value)
+  }
+/>
+
+{#if $searchTask.isRunning}
+  Loading...
+{:else if $searchTask.lastSuccessful}
+  Value: {$searchTask.lastSuccessful.value}
+{/if}
+{% endraw %}
+```
+
+And immediately you have a debounced task that informs the user when the results are loading. To try it for yourself, head over to [https://sheepdog.run/](https://sheepdog.run/) and check out the interactive example.
+
+### Easily get derived state for your tasks
+
+When a user is interacting with your app, it’s vital that they understand what is currently happening, whether they are waiting for something to load or waiting for a response from an input. Using a Sheepdog task gives you several derived properties out of the box so you can hook it into your UI with ease. Properties like `isRunning` can be used to show the current state of the task, while properties like `lastCanceled`, `lastSuccessful` and `lastErrored` help to give a concise view of exactly what has been returned from previous executions of your task.
+
+You can read more about Tasks [here](https://sheepdog.run/getting-started/usage/).
+
+### Different tasks for different needs
+
+With the default task, you unlock the simplicity I mentioned above, but Sheepdog exposes several task types for all different use-cases. Whether you want to debounce your input using a [Restart task](https://sheepdog.run/reference/restart/) or make sure your polling is always up-to-date with a [KeepLatest task](https://sheepdog.run/reference/keep-latest/); Sheepdog has you covered.
+
+You can read about the 5 different types of task [here](https://sheepdog.run/explainers/task-modifiers/).
+
+### Mid-run cancellation
+
+One of the biggest issues with Promises is that they require a lot of boilerplate to have any kind of mid-run cancellation. With Sheepdog, you immediately get that out of the box (when using the [Async Transform](https://sheepdog.run/explainers/async-transform/), without the Async Transform you will need to use generator functions).
+
+For instance, imagine you have a task that makes multiple API calls based on the return value of each previous API call. Then imagine for some reason you want to cancel that task after it’s started, with standard Promises you would have to set and check a bunch of values between each API call to have some semblance of cancellation. And even then, you can’t be sure which API calls have been initiated. With Sheepdog, we do all the heavy lifting for you, so if you cancel a task mid-run, then it’s cancelled - as soon as the current API call is completed, the task will stop executing.
+
+You can read more about Mid-run cancellation [here](https://sheepdog.run/explainers/mid-run-cancellation/).
+
+### No need to clean up after yourself
+
+Sheepdog automatically binds the task to the component it was created in, meaning that it will automatically be cancelled if the component it was instantiated in is unmounted. No more pending code executing after their place in the DOM has been unmounted.
+
+### Bind tasks together
+
+Sometimes you want one task to be entirely dependant on another, meaning that the child task is cancelled when the parent task is cancelled. Using the [Link function](https://sheepdog.run/explainers/linking-tasks/), binding tasks together is as easy as counting sheep.
+
+```js
+// Child.svelte
+<script>
+  import { task, timeout } from '@sheepdog/svelte';
+
+  // receive the task from the parent
+  export let parentTask;
+
+  let childTask = task.restart(async function(value, { link }) {
+    // bind childTask to parentTask and perform parentTask
+    let response = await link(parentTask).perform(value)
+    return await response.json();
+  });
+</script>
+```
+
+As you can see, we are receiving a task as a prop and then binding the new task to it. This means that if the child or parent component is unmount, both tasks will be cancelled. If they were not linked and the Child component was unmounted after `childTask` was triggered, `parentTask` would still run to completion.
+
+### Write what you know
+
+Under the hood, Sheepdog will turn all of your tasks into a generator function but with the [Async Transform](https://sheepdog.run/explainers/async-transform/), you can keep your async functions and Sheepdog will convert it to a generator function at build time, meaning you don’t have to know how generator functions work to benefit from them. But don't worry, we only ever touch the code that is wrapped in a `task` that is imported from `@sheepdog/svelte`.
+
+So if you wrote the following code:
+
+```js
+<script>
+  import { task } from '@sheepdog/svelte';
+
+  let myTask = task(async () => {
+    let response = await fetch(...);
+    return await response.json()
+  });
+
+  const arrowFunction = async () => {
+    await fetch(...)
+  }
+
+  async function myFunction() {
+    await fetch(...)
+  }
+
+  function * myGenerator() {
+    yield fetch(...)
+  }
+</script>
+```
+
+The output of the Async Transform would be:
+
+```js
+<script>
+  import { task } from '@sheepdog/svelte';
+
+  let myTask = task(async function* () {
+    let response = yield fetch(...);
+    return yield response.json()
+  });
+
+  const arrowFunction = async () => {
+    await fetch(...)
+  }
+
+  async function myFunction() {
+    await fetch(...)
+  }
+
+  function* myGenerator() {
+    yield fetch(...)
+  }
+</script>
+```
+
+As you can see, the Async Transform has only touched the single property that was wrapped in the imported `task`, and even then, we touch your code the minimum amount possible to give you all the benefits of Sheepdog.
+
+You can read more about the Async Transform [here](https://sheepdog.run/explainers/async-transform/).
+
+## Branching out
+
+At the moment, we have created this package to work with Svelte, but we have plans to make the core of the package framework-agnostic. If you’re interested in helping maintain the package or fancy porting it to your favourite framework, please reach out!
diff --git a/src/posts/2024-12-02-trash-in-treasure-out.md b/src/posts/2024-12-02-trash-in-treasure-out.md
new file mode 100644
index 0000000000..8082241526
--- /dev/null
+++ b/src/posts/2024-12-02-trash-in-treasure-out.md
@@ -0,0 +1,585 @@
+---
+title: "Trash in, treasure out"
+authorHandle: hdoordt
+tags: ["rust"]
+bio: "Henk Oordt, Senior Software Engineering Consultant"
+description: "Making your API clear and robust with Rust's type system"
+og:
+  image: "/assets/images/posts/2024-12-02-trash-in-treasure-out/og-image.png"
+tagline: |
+  <p>
+    Using Rust, you can encode a large part of the constraints and semantics of your API using the type system. In this article, we'll discuss how to do it, and how you can use it to your benefit.
+  </p>
+---
+
+## Intro
+
+By now, you're probably aware that at Mainmatter, we like Rust a lot. If you aren't: [have a look at our Rust page](https://mainmatter.com/rust-consulting/). In this blog post, I'd like to highlight one of my favorite traits of Rust (yes pun intended): its focus on _correctness_. Rust has a very expressive type system that lets you offload many checks to the compiler: it supports generics, data-carrying enums, closures, visibility specifiers, _explicit_ conversions, and much more. These are neat features that make performant, low-level programming feel as ergonomic as high-level languages. Sure, Rust has a learning curve, and that learning curve is a result of Rust's tendency to make complexity really _in your face_.
+
+Make no mistake, every piece of software is complex: it has to run on computers, which, especially nowadays are complex beasts. And writing software with highly optimized languages with manual memory management like C, C++, or Rust requires knowledge of all kinds of subtleties. Rust makes these subtleties _explicit_, forcing you to fix all kinds of things you may never have thought of before even compiling your code.
+
+But that's not all: as projects grow and age and more people work on the same piece of software, communication becomes very important. And by communication I mean ensuring the original writer of some piece of code, the code reviewer, the user of the code's API, the colleague refactoring the codebase, and new developers are on the same page about the _intent_ and _invariants_ of that code. What is this code doing? How am I supposed to use it correctly? What happens if I mess up? How do I protect this API from input it might choke on? Because 'Garbage in, garbage out' is not a great philosophy when setting up critical and robust systems. Traditionally, one would write in documentation and code comments the answers to these and many other questions. Writing documentation is a very valuable job, but sadly, developers are human. And humans make mistakes. And if the humans think they _themselves_ don't make mistakes, they will surely agree that their colleagues _do_.
+
+Documentation written in human language needs to be clear, specific, and up-to- date. And even if it's written well, for it to do its job, documentation needs to be _read_ in the first place. And even if it _is_ read, it needs to be interpreted and acted upon correctly. I don't know about you, but I'm way too pedantic to see that go flawlessly.
+
+Now, this is why I like Rust's expressive type system: it lets me encode a great deal of the semantics I'd otherwise have to describe in the documentation. You can craft your APIs and types such that using your library or module becomes very hard or even impossible. You can encode the _intent_ and _invariants_ regarding your code using the type system. This way you get the Rust compiler on _your_ side. It will be able to pick up subtle errors caused by your API users holding it wrong. And it will do so _at compile time_, greatly shortening the feedback loop. It makes adding features, refactoring, and reviewing much less error-prone. And it's great for security as well. It's where coding meets art, really.
+
+In this article, I'd like to give three main pieces of advice:
+
+1. Encode the semantics/states of your application in the type system and your API.
+2. Ensure input gets parsed into rigid structs before acceptance.
+3. Ensure output gets encoded in the correct format and doesn’t leak (sensitive) information.
+
+## Ticket to heaven
+
+We'll need a case to show how all this works, and since Mainmatter [loves the travel industry](/travel/), let's write up an API for booking train tickets.
+
+Looking at different train ticket services, in general, the steps towards booking are pretty similar: first, you enter the location you want to depart from and where you want to go, then you enter either your preferred moment of departure or when you want to arrive. Next, you select one of several suggested trips and enter your personal information. With all the information complete, you're all set to book the ticket and pay. Here's what that looks like as a flowchart:
+
+<div style="margin: 2em auto; width: 493px">
+
+![State diagam](/assets/images/posts/2024-12-02-trash-in-treasure-out/state-diagram.svg)
+
+</div>
+
+Pretty straightforward, right? Let's code one up.
+
+## Setting up
+
+Let's set up a simple [`axum`]-based server to implement before flow. I'm only going to post the code relevant to the story here, but if you're interested in the whole shebang: check out the code for [step 0]. Here's what the app setup looks like:
+
+```rust
+// src/lib.rs
+
+pub async fn run() -> Result<()> {
+    // Setup router
+    let router = axum::Router::new()
+        .route("/origin", post(set_origin))
+        .route("/destination", post(set_destination))
+        .route("/departure", post(set_departure))
+        .route("/arrival", post(set_arrival))
+        .route("/trips", get(list_trips))
+        .route("/trip", post(set_trip))
+        .route("/class", post(set_class))
+        .route("/name", post(set_name))
+        .route("/email", post(set_email))
+        .route("/phone_number", post(set_phone_number))
+        .route("/book_trip", post(book_trip));
+
+    // Create in-memory session store
+    let session_store: SessionNullSessionStore = SessionStore::new(None, SessionConfig::default())
+        .await
+        .unwrap();
+
+    // Stitch them together
+    let app = router
+        .layer(SessionLayer::new(session_store))
+        .into_make_service();
+
+    // Aand serve!
+    let listener = TcpListener::bind("0.0.0.0:3000").await?;
+    axum::serve(listener, app).await?;
+
+    Ok(())
+}
+```
+
+As you can see, we've got routes for each step, as well as a basic in-memory session store. For now, the handlers are pretty similar. Here's `set_origin`:
+
+```rust
+// src/lib.rs
+
+async fn set_origin(session: Session, origin: String) -> Result<Json<TicketMachine>> {
+    Ok(session.get_or_init_state(|s| {
+        s.origin = Some(origin);
+    }))
+    .map(Json)
+}
+```
+
+If you're not familiar with [`axum`]: this handler extracts the session out of the session layer, and gives us the request body as a `String`. `Session::get_or_init_state` fetches the current state from the session store, and updates it with the closure passed to it. If there's no session yet, it creates a default one, that it passes to the closure.
+
+So what's this `TicketMachine` in the route handler example? Well, it's the representation of the state of the booking flow. Here's the definition:
+
+```rust
+// src/ticket_machine.rs
+
+#[derive(Debug, Default, PartialEq, Eq, serde::Deserialize, serde::Serialize)]
+pub struct TicketMachine {
+    pub origin: Option<String>,
+    pub destination: Option<String>,
+    pub departure: Option<String>,
+    pub arrival: Option<String>,
+    pub trip: Option<String>,
+    pub class: Option<String>,
+    pub name: Option<String>,
+    pub email: Option<String>,
+    pub phone_number: Option<String>,
+    pub payment_info: Option<String>,
+}
+```
+
+Pretty much a bunch of optional strings. Does it work, though? Well, let's also create a little integration test:
+
+```rust
+// tests/main.rs
+
+#[tokio::test]
+async fn test_set_origin() {
+    let body: TicketMachine = send_post_request(&http_client(), "/origin", "Amsterdam").await;
+    assert_eq!(
+        body,
+        TicketMachine {
+            origin: Some("Amsterdam".to_owned()),
+            ..Default::default()
+        }
+    )
+}
+```
+
+Nothing too surprising. `http_client` sets up a [`reqwest`] HTTP client, and the `send_post_request` helper function sends a POST request to our server, given the path (`"/origin"`) and the body (`"Amsterdam"`). Now, let's give it a spin. In one terminal window, we start the server, and we'll run the tests in a separate terminal window:
+
+```bash
+// start server
+$ cargo run
+[..]
+```
+
+I'm using [`cargo-nextest`] because it gives me pretty and concise reports.
+
+```bash
+// Run tests
+$ cargo nextest run
+    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.06s
+------------
+ Nextest run ID 2b617168-9190-4619-ba1d-27a3e6cdc815 with nextest profile: default
+    Starting 1 test across 3 binaries
+        PASS [   0.016s] takeoff::main test_set_origin
+------------
+     Summary [   0.017s] 1 test run: 1 passed, 0 skipped
+```
+
+> 1 test run: 1 passed
+
+I like that!
+
+## Looking back
+
+Our route handler doesn't do a lot. It will accept any `String` for a body, meaning that as far as our app is concerned `"🚂-🛒-🛒-🛒"` is totally a valid origin. It's nice that given a string [must be valid UTF-8][String], at least our handler won't accept random byte sequences, but we can do better. For the curious among you: the following code is in the [step 1] commit. Let's add some validation:
+
+```rust
+// src/lib.rs
+
+pub fn is_valid_location(location: &str) -> bool {
+    const VALID_LOCATIONS: &[&str] = &[
+        "Amsterdam Centraal",
+        "Paris Nord",
+        "Berlin Hbf",
+        "London Waterloo",
+    ];
+
+    VALID_LOCATIONS.contains(&location)
+}
+
+// ✂️
+
+async fn set_origin(session: Session, origin: String) -> Result<Json<TicketMachine>> {
+    if !is_valid_location(&origin) {
+        return Err(Error::BadRequest("Invalid origin!"));
+    }
+
+    Ok(session.get_or_init_state(|s| {
+        s.origin = Some(origin);
+    }))
+    .map(Json)
+}
+```
+
+And test some more:
+
+```bash
+$ cargo nextest run
+Finished `test` profile [unoptimized + debuginfo] target(s) in 0.06s
+------------
+Nextest run ID 3437f17c-6fed-4b9b-8fad-27b324e45602 with nextest profile: default
+Starting 1 test across 3 binaries
+    FAIL [   0.014s] takeoff::main test_set_origin
+
+--- STDOUT:              takeoff::main test_set_origin ---
+
+<Omitted for your sanity>
+
+--- STDERR:              takeoff::main test_set_origin ---
+thread 'test_set_origin' panicked at tests/main.rs:34:9:
+Received error response (reqwest::Error { kind: Status(400), url: "http://localhost:3000/origin" }): 'Bad Request: Invalid origin!'
+note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
+
+Cancelling due to test failure
+------------
+ Summary [   0.015s] 1 test run: 0 passed, 1 failed, 0 skipped
+    FAIL [   0.014s] takeoff::main test_set_origin
+error: test run failed
+```
+
+Yay! It fails! Surprise: turns out there's no station called "Amsterdam". We should update the test again:
+
+```rust
+// tests/main.rs
+
+#[test_case(b"Amsterdam" => panics ""; "Non-existent station")]
+#[test_case("🚂-🛒-🛒-🛒".as_bytes() => panics ""; "Emojional roller coaster")]
+#[test_case(&[0xE0, 0x80, 0x80] => panics "" ; "Non-UTF-8 sequence")]
+#[test_case(b"Amsterdam Centraal"; "Valid station")]
+#[tokio::test]
+async fn test_set_bad_origin(origin: &'static [u8]) {
+    let body: TicketMachine = send_post_request("/origin", origin).await;
+    assert_eq!(
+        body,
+        TicketMachine {
+            origin: Some(String::from_utf8(origin.to_vec()).unwrap()),
+            ..Default::default()
+        }
+    )
+}
+```
+
+And those, believe me, totally pass! Now what?
+
+## Even better validation
+
+We can do better still. Here's the thing: for our server to validate locations _everywhere_, we'd need to add loads of calls to `is_valid_location`. What happens if I forget, though? This is where Rust's expressive type system comes in. With Rust, you can create types that are valid _by construction_. The mere fact that such an instance of such type exists, proves that it is valid. And this is truly an amazing power. How do you do it? Well, by using the [newtype] pattern:
+
+```rust
+// src/types/location.rs
+
+pub struct Location(String);
+```
+
+The code for this section can be found in the repo state as of the [step 2] commit.
+
+Now, wrapping a struct in and of itself is not too useful. But we already did something very important: give the type a good name, adding semantics! Now, of course, you'd add some doc comments describing the type some more, but already it's clear what this type is meant to represent. There's no way to instantiate it from outside the `types::location` module, though. On the one hand, that's great: right now there's no way to instantiate an invalid `Location`. However, it'd be a huge improvement if we could create _valid_ `Location`s. So let's add some methods and trait implementations:
+
+```rust
+// src/types/location.rs
+
+#[derive(Debug, Clone, PartialEq, Eq, serde::Deserialize, serde::Serialize)]
+#[serde(try_from = "String")]
+pub struct Location(String);
+
+impl Location {
+    pub fn is_valid_location(location: &str) -> bool {
+        const VALID_LOCATIONS: &[&str] = &[
+            "Amsterdam Centraal",
+            "Paris Nord",
+            "Berlin Hbf",
+            "London Waterloo",
+        ];
+
+        VALID_LOCATIONS.contains(&location)
+    }
+}
+
+impl TryFrom<String> for Location {
+    type Error = ParseLocationError;
+
+    fn try_from(s: String) -> Result<Self, Self::Error> {
+        if !Self::is_valid_location(&s) {
+            return Err(ParseLocationError(s));
+        }
+        Ok(Self(s))
+    }
+}
+
+#[derive(Debug, thiserror::Error)]
+#[error("Error parsing location: {0}")]
+pub struct ParseLocationError(String);
+```
+
+Much better! Using the `#[serde(try_from = "String")]` attribute, we've instructed `serde` to call the `Location::try_from` implementation upon deserialization. Now, the _only_ way to instantiate a `Location` is through it's `TryFrom<String>` implementation, which does the validation. Barring any unsafe magic tricks, that is. Getting the value _out_ is a matter of adding more functionality, which I won't bore you with right now. But you can imagine adding an implementation for `std::fmt::Display`, or a method `fn as_str(&self) -> &str`. Don't go implement `std::ops::Deref<Target=String>` though, that'd [defeat the purpose][deref_polymorphism].
+
+With that set up, let's update our model, as well as the relevant method handlers. Here's our freshly updated `TicketMachine`, which got moved to the `crate::types::ticket_machine` module:
+
+```rust
+// src/types/ticket_machine.rs
+use crate::types::location::Location;
+
+#[derive(Debug, Default, PartialEq, Eq, serde::Deserialize, serde::Serialize)]
+pub struct TicketMachine {
+    pub origin: Option<Location>,
+    pub destination: Option<Location>,
+    // ✂️ ..other fields
+}
+```
+
+Here's `set_origin`:
+
+```rust
+// src/lib.rs
+
+async fn set_origin(session: Session, Json(origin): Json<Location>) -> Result<Json<TicketMachine>> {
+    Ok(session.get_or_init_state(|s| {
+        s.origin = Some(origin);
+    }))
+    .map(Json)
+}
+```
+
+As you can see, instead of taking a `String` body, this time we're taking a `Json<Location>`. Axum will attempt to deserialize the request body into a `Location`, and the `Json<_>` extractor tells it that it should use `serde_json` to do so. And as `serde_json` is going to use the `serde::Deserialize` implementation we derived on `Location` before, `Location::try_from<String>` gets run even the _before_ code within the route handler is run. So within the route handler, we're _certain_ that the `origin` parameter represents a valid `Location`!
+
+Now, of course, our test is just sending plain, unquoted strings, and unquoted strings are not valid JSON. So let's update our test:
+
+```rust
+// tests/main.rs
+
+fn json_string_bytes(s: &str) -> Cow<'static, [u8]> {
+    serde_json::to_vec(s).unwrap().into()
+}
+
+#[test_case(json_string_bytes("Amsterdam") => panics ""; "Non-existent station")]
+#[test_case(json_string_bytes("🚂-🛒-🛒-🛒") => panics ""; "Emojional roller coaster")]
+#[test_case([0xE0, 0x80, 0x80].as_slice().into() => panics "" ; "Non-UTF-8 sequence")]
+#[test_case(b"Amsterdam Centraal".into() => panics ""; "Invalid JSON")]
+#[test_case(json_string_bytes("Amsterdam Centraal"); "Valid station")]
+#[tokio::test]
+async fn test_set_bad_origin(origin: Cow<'static, [u8]>) {
+    let origin = origin.to_vec();
+    let body: TicketMachine = send_post_request("/origin", origin.clone()).await;
+
+    let origin: String = serde_json::from_slice(&origin).expect(
+        "The request should have failed at this point as `origin` was not valid JSON anyway",
+    );
+    let origin: Location = origin.try_into().unwrap();
+
+    assert_eq!(
+        body,
+        TicketMachine {
+            origin: Some(origin),
+            ..Default::default()
+        }
+    )
+}
+```
+
+We're now sending JSON! The signature changed a bit: instead of a `&'static [u8]`, it now takes a `Cow<'static, [u8]>`, which helps with our JSON serialization stuff, but let's not focus on that. Instead, I'm gonna distract you with the test results:
+
+```bash
+$ cargo nextest run
+    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.10s
+------------
+ Nextest run ID a7be105d-a24b-44e9-baba-c5a560608792 with nextest profile: default
+    Starting 5 tests across 3 binaries
+        PASS [   0.045s] takeoff::main test_set_bad_origin::valid_station
+        PASS [   0.046s] takeoff::main test_set_bad_origin::non_existent_station
+        PASS [   0.046s] takeoff::main test_set_bad_origin::non_utf_8_sequence
+        PASS [   0.046s] takeoff::main test_set_bad_origin::invalid_json
+        PASS [   0.046s] takeoff::main test_set_bad_origin::emojional_roller_coaster
+------------
+     Summary [   0.047s] 5 tests run: 5 passed, 0 skipped
+```
+
+There we go! With that set up, we have the following guarantees within the `set_origin` method handler regarding the request body:
+
+- It's valid UTF-8;
+- It's valid JSON;
+- It represents a valid `Location`, as defined in its `TryFrom<String>` implementation.
+
+And it's all checked by Rust's type system! We might as well throw out the cases that pass in non-UTF-8 sequences or invalid JSON: the only really sensible part to test is the implementation of `TryFrom<String>`. But let's keep them anyway because tests are great to have when doing big code refactors.
+
+## Output sanitization
+
+So far, Rust's type system has been working for us very well to give us guarantees about input. How about output though? Using the [`newtype`] pattern from the previous section again, we can ensure sensitive data gets hidden in responses and logs. Furthermore, we can make the output encoding format part of our type zoo. Let me remind you what our `TicketOffice` model looks like so far:
+
+```rust
+// src/types/ticket_machine.rs
+
+#[derive(Debug, Default, PartialEq, Eq, serde::Deserialize, serde::Serialize)]
+pub struct TicketMachine {
+    pub origin: Option<Location>,
+    pub destination: Option<Location>,
+    pub departure: Option<String>,
+    pub arrival: Option<String>,
+    pub trip: Option<String>,
+    pub class: Option<String>,
+    pub name: Option<String>,
+    pub email: Option<String>,
+    pub phone_number: Option<String>,
+    pub payment_info: Option<String>,
+}
+```
+
+The first thing you'll notice is that we aren't doing any input validation for the fields other than `origin` and `destination`. But other than that, our struct holds some sensitive personal data: `name`, `email`, `phone_number`, and `payment_info`. Let's focus on that last field, `payment_info`, though. We haven't specified yet what `payment_info` _is_, but let's assume for now that it may contain credit card details. Now, credit card details are things you don't want ending up in your logs or API responses. Using the [`newtype`] pattern, we can make it _hard_ to leak such data into the logs. The following examples can be found in the repo state as of the [step 3] commit. Let's conjure up a `PaymentInfo` type:
+
+```rust
+// src/types/payment_info.rs
+
+#[derive(Clone, PartialEq, Eq, serde::Deserialize, serde::Serialize)]
+#[serde(into = "String")]
+pub struct PaymentInfo(String);
+
+impl std::fmt::Display for PaymentInfo {
+    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
+        write!(f, "<SECRET>")
+    }
+}
+
+impl std::fmt::Debug for PaymentInfo {
+    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
+        f.debug_tuple(stringify!(PaymentInfo))
+            .field(&"<SECRET>")
+            .finish()
+    }
+}
+
+impl From<PaymentInfo> for String {
+    fn from(p: PaymentInfo) -> Self {
+        p.to_string()
+    }
+}
+```
+
+This time, we've ensured the ways to convert `PaymentInfo` to a `String` are watertight. Using the `#[serde(into = "String")]` attribute on the struct definition, we've ensured that Serde uses the `Into<String>` implementation on `PaymentInfo` to serialize the struct, which gets forwarded to its `Display` implementation. And that implementation hides our secrets. Nice! Accidentally logging payment info is covered as well by the custom implementation of `Debug`. Obviously, `PaymentInfo` requires input validation, too, but let's keep focus on the output right now.
+
+Let's update our `TicketMachine` and the `book_trip` route handler:
+
+```rust
+// src/types/ticket_machine.rs
+
+#[derive(Debug, Default, PartialEq, Eq, serde::Deserialize, serde::Serialize)]
+pub struct TicketMachine {
+    // ✂️ ..other fields
+    pub payment_info: Option<PaymentInfo>,
+}
+
+// src/lib.rs
+
+async fn book_trip(
+    session: Session,
+    Json(payment_info): Json<PaymentInfo>,
+) -> Result<Json<TicketMachine>> {
+    session
+        .update_state(|s| {
+            s.payment_info = Some(payment_info);
+            println!("🚂 Trip booked! Choo choo!");
+        })
+        .ok_or(Error::BadRequest("Set phone_number first"))
+        .map(Json)
+}
+```
+
+Great. We were already wrapping our output in a `Json`, ensuring the data gets encoded in the right format before sending it out. Now we'll add some tests to validate that this works:
+
+```rust
+// tests/main.rs
+
+#[tokio::test]
+async fn test_hiding_payment_details() {
+    let client = http_client();
+    let origin = json!("Amsterdam Centraal");
+    // Set up the session
+    let _: TicketMachine =
+        send_post_request(&client, "/origin", serde_json::to_vec(&origin).unwrap()).await;
+
+    // Totally not _my_ credit card
+    let payment_info = json!({
+        "card_number": "1234 5678 9012 3456",
+        "cvc": "123",
+        "exp": "12/34",
+    })
+    .to_string();
+    // Deserialize into a Value, so that we can skip any input validation on
+    // the test side.
+    let state: serde_json::Value = send_post_request(
+        &client,
+        "/book_trip",
+        serde_json::to_vec(dbg!(&payment_info)).unwrap(),
+    )
+    .await;
+
+    assert_eq!(state["payment_info"], "<SECRET>");
+}
+
+// src/types/payment_info.rs
+
+#[tokio::test]
+async fn test_payment_details_debug_impl() {
+    use crate::types::ticket_machine::TicketMachine;
+    use std::fmt::Write;
+
+    let ticket_machine = TicketMachine {
+        origin: None,
+        destination: None,
+        departure: None,
+        arrival: None,
+        trip: None,
+        class: None,
+        name: None,
+        email: None,
+        phone_number: None,
+        payment_info: Some("💰💰💰".to_owned().try_into().unwrap()),
+    };
+    let mut dbg_output = String::new();
+    write!(&mut dbg_output, "{ticket_machine:?}").unwrap();
+
+    assert_eq!(
+        dbg_output,
+        r#"TicketMachine { origin: None, destination: None, departure: None, arrival: None, trip: None, class: None, name: None, email: None, phone_number: None, payment_info: Some(PaymentInfo("<SECRET>")) }"#
+    )
+}
+```
+
+And test:
+
+```bash
+$ cargo nextest run
+    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.38s
+------------
+ Nextest run ID 1ba4afd2-c85c-4817-8f6d-5d66090fb3a1 with nextest profile: default
+    Starting 7 tests across 3 binaries
+        PASS [   0.015s] takeoff types::payment_info::test_payment_details_debug_impl
+        PASS [   0.051s] takeoff::main test_set_bad_origin::valid_station
+        PASS [   0.051s] takeoff::main test_set_bad_origin::invalid_json
+        PASS [   0.051s] takeoff::main test_set_bad_origin::non_existent_station
+        PASS [   0.051s] takeoff::main test_set_bad_origin::emojional_roller_coaster
+        PASS [   0.051s] takeoff::main test_set_bad_origin::non_utf_8_sequence
+        PASS [   0.052s] takeoff::main test_hiding_payment_details
+------------
+     Summary [   0.052s] 7 tests run: 7 passed, 0 skipped
+```
+
+There you go! With that, we've ensured that once our `PaymentInfo` is instantiated, it'll be quite hard to accidentally leak its contents. Completely hiding the payment info from everything would make it rather unuseful, but at least we can't accidentally log them or send them in a response, preventing a very likely cause of leaking information.
+
+## Wrapping up
+
+We've reached a lot already! We've created meaningful types for handling the data in our model, ensured they're valid by construction, and that they don't leak sensitive information. With that, our API has become much more robust than the version we started out with. Let's summarize what we've achieved with that.
+
+In the [introduction](#trash-in-treasure-out), I listed three pieces of advice:
+
+> 1. Encode the semantics/states of your application in the type system and your API.
+> 2. Ensure input gets parsed into rigid structs before acceptance.
+> 3. Ensure output gets encoded in the correct format and doesn’t leak (sensitive) information.
+
+In [step 2](#even-better-validation), we've covered the first two points. We started out creating an explicit `Location` type, with a name that clearly indicates what it conveys. We've skipped adding documentation on that type, but if we hadn't, it could describe the semantics and invariants of `Location` some more. That documentation would be easily findable anywhere `Location` is used.
+
+Furthermore, we ensured `Location`s are valid by construction: by implementing the validation in the `TryFrom<String>` implementation for `Location`, and ensuring the `Location` can only be created and deserialized via that validation, we've ensured that a `Location` _always_ represents a valid location, _as long as our validation logic is correct_. And by accepting `Json<Location>` in our Axum request handlers directly, those handlers don't need to do any further validation.
+
+In [step 3](#output-sanitization), we've ensured the `PaymentDetails` can't leak sensitive information in logs or responses by implementing `Debug` and `Display` such that they don't actually use the wrapped `String`, and ensured the `From<PaymentDetails>` implementation for `String` uses our `Display` implementation. We can add dedicated methods to get the data out in case we need to store the payment details in our database, for instance. With that, _accidentally_ leaking such info has become much harder.
+
+Are there any downsides? As always: yes, this is no silver bullet. One thing you probably have noticed so far is that the patterns described in this post introduce a bunch of boilerplate. There are crates (e.g. [`nutype`]) out there that aim to reduce this, but they come with their own trade-offs. Furthermore, sometimes not all invariants can be expressed in Rust code. In such cases, one still has to rely on documentation to be thorough and correct.
+
+Other than that, rigidity may not always be what you want. Sometimes your invariants and requirements are not all that clear, and are very subject to change. In such cases, it's not great to update loads of boilerplate all the time. This, I think, is a bit of a matter of taste: I myself like to force myself to clarify the requirements and invariants before implementation, and with the validation being implemented in a single place, updating that is not such a big hassle. And what you get back is huge: correct, robust, clear, and maintainable code!
+
+_In [step 4], I've updated the rest of the method handlers, and demonstrate the [`validator`] and [`nutype`] crates briefly. Be sure to have a look!_
+
+[step 0]: https://github.com/mainmatter/trash-in-treasure-out/tree/abaa132a4250c71846ddf9a4540129af9952c9e8
+[step 1]: https://github.com/mainmatter/trash-in-treasure-out/tree/5c03b284bc0b1c932ec1c09b6abfef13f5cdfa4e
+[step 2]: https://github.com/mainmatter/trash-in-treasure-out/tree/305b8088b5155aeb13a473ca398fd1d522405b7d
+[step 3]: https://github.com/mainmatter/trash-in-treasure-out/tree/1dc8400afff4a31bcc1586e577a4af39124b8dfa
+[step 4]: https://github.com/mainmatter/trash-in-treasure-out/tree/305b8088b5155aeb13a473ca398fd1d522405b7d
+[`axum`]: https://crates.io/crates/axum/
+[`reqwest`]: https://crates.io/crates/reqwest/
+[`cargo-nextest`]: https://nexte.st/
+[String]: https://doc.rust-lang.org/stable/std/string/struct.String.html
+[newtype]: https://rust-unofficial.github.io/patterns/patterns/behavioural/newtype.html?highlight=newtype#newtype
+[deref_polymorphism]: https://rust-unofficial.github.io/patterns/anti_patterns/deref.html
+[`nutype`]: https://crates.io/crates/nutype/
+[`validator`]: https://crates.io/crates/validator/
diff --git a/src/ruby-rails-consulting.njk b/src/ruby-rails-consulting.njk
index 2e8cccba59..945f7ce5e1 100644
--- a/src/ruby-rails-consulting.njk
+++ b/src/ruby-rails-consulting.njk
@@ -1,10 +1,10 @@
 ---
 layout: base
-title: We're veteran Ruby and Ruby on Rails consultants
+title: "Team Up With Us for Ruby on Rails! | Ruby on Rails consulting"
 description: Mainmatter works with teams that build on Ruby and Ruby on Rails. We help pushing through bottlenecks, provide a fresh perspective, and modernize tech stacks.
 permalink: /ruby-rails-consulting/
 og:
-  image: /assets/images/ruby/lp-ruby-consulting-og-image.jpg
+  image: /assets/images/ruby/og-image.png
 ---
 
 {% from "image-banner-with-text.njk" import imageBannerWithText %}
@@ -22,7 +22,7 @@ og:
 {%
   set 'content' = {
   "eyebrow": "Our Expertise: Ruby and Ruby on Rails",
-  "title": "We're veteran Ruby and Ruby on Rails experts",
+  "title": "Team Up With Us for Ruby on Rails!",
   "text": "The Mainmatter team has been an active part of the Ruby and Rails communities since the early days – from the first 'whoops' to the latest release.",
   "image": "/assets/images/hero/ruby.jpg",
   "alt": "A couple of diamonds",
@@ -158,8 +158,8 @@ og:
 {{ caseCards('', '', '', clients) }}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
-  "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
+  "title": "Team up with us for Ruby on Rails!",
+  "text": "Our seasoned Ruby and Ruby on Rails experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
   }
diff --git a/src/rust-application-telemetry-workshop.njk b/src/rust-application-telemetry-workshop.njk
index 6938f48829..e74099b41f 100644
--- a/src/rust-application-telemetry-workshop.njk
+++ b/src/rust-application-telemetry-workshop.njk
@@ -86,7 +86,7 @@ og:
       {{ ctaBanner('aqua', 'default', content) }}
       {%
         set 'content' = {
-        "title": "Grow your business with us",
+        "title": "Team up with us to go further!",
         "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
         "linkUrl": "/contact",
         "linkText": "Get in touch"
diff --git a/src/rust-consulting.njk b/src/rust-consulting.njk
index a0ef8a04e1..8dc080c033 100644
--- a/src/rust-consulting.njk
+++ b/src/rust-consulting.njk
@@ -1,10 +1,10 @@
 ---
 layout: base
-title: Enable your team to leverage Rust
+title: "Team Up With Us for Rust! | Rust consulting"
 description: Mainmatter enables teams to adopt Rust in their web projects and increase performance, efficiency, and maintainability.
 permalink: /rust-consulting/
 og:
-  image: /assets/images/rust/lp-rust-consulting-og-image.jpg
+  image: /assets/images/rust/og-image.png
 ---
 
 {% from "image-banner-with-text.njk" import imageBannerWithText %}
@@ -21,8 +21,8 @@ og:
 {%
   set 'content' = {
   "eyebrow": "Our Expertise: Rust",
-  "title": "Rust is a competitive advantage",
-  "text": "Rust checks all the boxes – performance, efficiency, maintainability, and great developer experience. Mainmatter is here to empower your team to fully realize those benefits in your web and backend projects.",
+  "title": "Team Up With Us for Rust!",
+  "text": "Rust checks all the boxes – performance, efficiency, maintainability, and great developer experience. Mainmatter is here to empower your team to fully realize those benefits in your projects.",
   "image": "/assets/images/hero/rust.jpg",
   "alt": "Crabs climbing a rock on a beach",
   "loading": "eager"
@@ -42,9 +42,9 @@ og:
         <a href="https://crates.io">crates.io</a> project.
       </p>
       <p>
-        But we don't stop at Rust – we have developed big web apps and mentored teams on backend,
-        frontend, design, as well as process and developer infrastructure for years. We know what it
-        takes to connect everything together and deliver a delightful end-to-end experience.
+        But we don't stop at Rust – we have developed big systems and mentored teams on technology,
+        as well as process and developer infrastructure for years. We know what it takes to connect
+        everything together and develop performant, solid, and maintainable systems.
       </p>
     </div>
   </div>
@@ -72,11 +72,10 @@ og:
       <h5 class="mb-015">EuroRust</h5>
       <h3 class="mb-2">We run EuroRust</h3>
       <p>
-        In 2024, EuroRust will be back on October 10th and 11th in Vienna, Austria as well as
-        online. We'll have 2 days of talks with a main track as well as a side track for the first
-        time this year. Plus, there'll be workshops on the day before the main conference, room for
-        people to get together and hack on their favorite projects during the conference, as well as
-        an after party on Friday night.
+        In 2024, EuroRust took place on October 10th and 11th in Vienna, Austria as well as online.
+        We had 2 days of talks with a main track as well as a new side track and impl rooms. Plus,
+        there were workshops on the day before the main conference, several side activities around
+        the event, as well as an after party on Friday night.
       </p>
     </div>
   </div>
@@ -84,10 +83,10 @@ og:
     <a href="https://eurorust.eu" class="split-content__link"></a>
     <div class="split-content__wrapper">
       <div class="split-content__content">
-        <h4>Join us in Vienna for 2 days of celebrating the European Rust community</h4>
+        <h4>Join us in Paris in 2025 for 2 days of celebrating the European Rust community</h4>
         {%
           set link = {
-          "label": 'Get your ticket now!',
+          "label": 'Stay up to date!',
           "url": 'https://eurorust.eu'
           }
         %}
@@ -111,7 +110,10 @@ og:
   'Aleph Alpha',
   'Google',
   'Realm',
-  'Astral'
+  'Astral',
+  'Helsing',
+  'CrabNebula',
+  'Oreilly'
   ]
 %}
 {% set title = 'Our EuroRust partners are betting on Rust' %}
@@ -120,8 +122,8 @@ og:
 <section class="mb-10">
   {%
     set imageData = {
-    "imgPath": "/assets/images/rust/eurorust.jpeg",
-    "alt": "Server room",
+    "imgPath": "/assets/images/rust/eurorust-2024.jpg",
+    "alt": "Photo of EuroRust 2024's speakers, organizers, moderators and the audience in the background, all with theirs hands in the air",
     "sizes": "100vw",
     "loading": "lazy",
     "sizesArray": [760, 1440, 1920]
@@ -137,16 +139,15 @@ og:
         <h5>Book a free call</h5>
         <h3 class="split-content__subheading h2">Is Rust the right choice for us?</h3>
         <p>
-          Every new technology brings its own risks - Rust is no exception. Luca Palmieri, the
-          author of <a href="https://zero2prod.com">Zero to Production in Rust</a> and our in-house
-          Rust expert, is here to help your team. You walk him through your company's usecase and
-          your requirements and he’ll do his best to suggest the best course of action. Sometimes
-          Rust is not the answer, but if it is, he’ll make sure you are on the right track.
+          Every new technology brings its own risks - Rust is no exception. Our team of Rust experts
+          is here to help you. You walk us through your company's usecase and your requirements and
+          we'll do our best to suggest the best course of action. Sometimes Rust is not the answer,
+          but if it is, we'll make sure you are on the right track.
         </p>
         {%
           set link = {
-          "label": 'Book a 1:1 call with Luca',
-          "url": 'https://calendly.com/luca-palmieri/is-rust-the-right-choice-for-us'
+          "label": 'Book a 1:1 call with us',
+          "url": 'https://mainmatter.com/contact/'
           }
         %}
         {{ btnSecondary( link, 'mt-2' ) }}
@@ -226,8 +227,8 @@ og:
 <section class="mb-10">
   {%
     set imageData = {
-    "imgPath": "/assets/images/rust/eurorust-2.jpeg",
-    "alt": "Server room",
+    "imgPath": "/assets/images/rust/eurorust-crab.jpg",
+    "alt": "People standing together in groups at EuroRust in conversations, a big, ca. 3min tall, inflatable Ferris in the background",
     "sizes": "100vw",
     "loading": "lazy",
     "sizesArray": [760, 1440, 1920]
@@ -293,12 +294,68 @@ og:
   </div>
 </section>
 
+<section class="container container--xl opensource-list">
+  <div class="">
+    <h2 class="opensource-list__title h2">We love Open Source</h2>
+    <ul class="opensource-list__list">
+      <li class="opensource-list__project">
+        <div class="opensource-list__project-image pb-5">
+          <img src="/assets/images/rust/gerust-logo.svg" alt="Gerust" />
+        </div>
+        <div class="opensource-list__project-text">
+          <h4 class="mb-015 mt-3">Gerust</h4>
+          <p>Generator for Rust backend&nbsp;projects</p>
+          {%
+            set link = {
+            "label": 'View on GitHub',
+            "url": 'https://github.com/mainmatter/gerust'
+            }
+          %}
+          {{ btnSecondary( link, 'mt-2' ) }}
+        </div>
+      </li>
+      <li class="opensource-list__project">
+        <div class="opensource-list__project-image">
+          <img src="/assets/images/rust/book.svg" alt="100 Exercises to Learn Rust" />
+        </div>
+        <div class="opensource-list__project-text">
+          <h4 class="mb-015">100 Exercises To Learn&nbsp;Rust</h4>
+          <p>Learn Rust by solving 100&nbsp;exercises</p>
+          {%
+            set link = {
+            "label": 'View on GitHub',
+            "url": 'https://github.com/mainmatter/100-exercises-to-learn-rust'
+            }
+          %}
+          {{ btnSecondary( link, 'mt-2' ) }}
+        </div>
+      </li>
+      <li class="opensource-list__project">
+        <div class="opensource-list__project-image">
+          <img src="/assets/images/rust/cargo.svg" alt="cargo-autoinherit" />
+        </div>
+        <div class="opensource-list__project-text">
+          <h4 class="mb-015 mt-3">cargo-autoinherit</h4>
+          <p>Dry up your <code>Cargo.toml</code> manifests</p>
+          {%
+            set link = {
+            "label": 'View on GitHub',
+            "url": 'https://github.com/mainmatter/cargo-autoinherit'
+            }
+          %}
+          {{ btnSecondary( link, 'mt-2' ) }}
+        </div>
+      </li>
+    </ul>
+  </div>
+</section>
+
 {{ recentPosts("Latest from our blog on the topic", collections.rustPosts) }}
 {% include "global/rust-newsletter-cta.njk" %}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
-  "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
+  "title": "Team up with us for Rust!",
+  "text": "Our Rust experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
   }
diff --git a/src/services/launch-your-idea.njk b/src/services/launch-your-idea.njk
index 71a88807c5..d1556d6b44 100644
--- a/src/services/launch-your-idea.njk
+++ b/src/services/launch-your-idea.njk
@@ -145,7 +145,7 @@ og:
 {{ featuredServices(services['launch-your-idea'], content) }}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/services/strategic-advice.njk b/src/services/strategic-advice.njk
index 1079f18a6c..88c4bafee9 100644
--- a/src/services/strategic-advice.njk
+++ b/src/services/strategic-advice.njk
@@ -88,7 +88,7 @@ og:
 
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/services/team-reinforcement.njk b/src/services/team-reinforcement.njk
index 63f29d5981..ea0ad27af1 100644
--- a/src/services/team-reinforcement.njk
+++ b/src/services/team-reinforcement.njk
@@ -1,7 +1,7 @@
 ---
 layout: "base"
 title: Team reinforcement | Our Services
-description: "Mainmatter supports clients with experienced people who are ready to build products, mentor people and support your goals, bringing in a fresh perspective along the way."
+description: "Mainmatter's experts are seasoned engineers who are ready to build products, mentor people and support your goals, bringing in a fresh perspective along the way."
 og:
   image: "/assets/images/services/team-reinforcement-og-image.jpg"
 ---
@@ -173,7 +173,7 @@ og:
 {{ featuredServices(services['team-reinforcement'], content) }}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/services/tech-modernization.njk b/src/services/tech-modernization.njk
index bd9dde128f..ea8c6fc0d1 100644
--- a/src/services/tech-modernization.njk
+++ b/src/services/tech-modernization.njk
@@ -131,7 +131,7 @@ og:
 {{ featuredServices(services['tech-modernization'], content) }}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/services/workshops.njk b/src/services/workshops.njk
index 640d5e440e..e91ff20cf7 100644
--- a/src/services/workshops.njk
+++ b/src/services/workshops.njk
@@ -97,7 +97,7 @@ og:
   "eyebrow": "Bookable for teams",
   "title": "Testing in Rust: an introduction",
   "logo": "rust",
-  "link": "services/workshops/introduction-to-rust-for-web-developers/"
+  "link": "services/workshops/an-introduction-to-testing-in-rust/"
   }
 %}
 {%
@@ -108,6 +108,46 @@ og:
   "link": "services/workshops/advanced-testing-in-rust/"
   }
 %}
+{%
+  set 'workshop_12' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Progressive Enhancement with SvelteKit",
+  "logo": "svelte",
+  "link": "services/workshops/progressive-enhancement-with-sveltekit/"
+  }
+%}
+{%
+  set 'workshop_13' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Testing Svelte & SvelteKit applications",
+  "logo": "svelte",
+  "link": "services/workshops/testing-svelte-sveltekit-applications/"
+  }
+%}
+{%
+  set 'workshop_14' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Svelte 5 & Runes",
+  "logo": "svelte",
+  "link": "services/workshops/svelte-5-runes/"
+  }
+%}
+{%
+  set 'workshop_15' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Authentication for Svelte & SvelteKit",
+  "logo": "svelte",
+  "link": "services/workshops/authentication-for-svelte-sveltekit/"
+  }
+%}
+{%
+  set 'workshop_16' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Rust-Python Interoperability",
+  "logo": "rust",
+  "link": "services/workshops/rust-python-interoperability/"
+  }
+%}
 {%
   set workshops = [
   workshop_1,
@@ -120,26 +160,33 @@ og:
   workshop_8,
   workshop_9,
   workshop_10,
-  workshop_11
+  workshop_11,
+  workshop_12,
+  workshop_13,
+  workshop_14,
+  workshop_15,
+  workshop_16
   ]
 %}
-{{ techCards('workshops', 'Workshops Catalog', 'We offer a range of workshops bookable for teams that want to grow – on-site or remote. We\'re also happy to prepare custom workshops – <a href="/contact/">get in touch with us</a> to talk about what curriculum fits your team best!', workshops) }}
-{%
-  set 'content' = {
-  "title": "Not the right workshop for you?",
-  "text": "If you decide to organise a workshop at your company, we are happy to tailor the curriculum to your needs. We can combine multiple workshops, pick and choose modules, as well as develop new content if desired.",
-  "linkUrl": "/contact",
-  "linkText": "Get in touch"
-  }
-%}
-{{ ctaBanner('purple', 'default', content) }}
-{% include "global/default-newsletter-cta.njk" %}
-{%
-  set 'content' = {
-  "title": "Grow your business with us",
-  "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
-  "linkUrl": "/contact",
-  "linkText": "Get in touch"
-  }
-%}
-{{ ctaBanner('purple', 'full', content) }}
+{{
+  techCards('workshops', 'Workshops Catalog', 'We offer a range of workshops bookable for teams that want to grow – on-site or remote. We\'re also happy to prepare custom workshops – <a href="/contact/">get in touch with us</a> to talk about what curriculum fits your team best!', workshops) }}
+  {%
+    set 'content' = {
+    "title": "Can't find the right workshops for your team?",
+    "text": "We are happy to tailor the curriculum to your needs. We can combine multiple workshops, pick and choose modules, as well as develop new content if desired.",
+    "linkUrl": "/contact",
+    "linkText": "Get in touch"
+    }
+  %}
+  {{ ctaBanner('purple', 'default', content) }}
+  {% include "global/default-newsletter-cta.njk" %}
+  {%
+    set 'content' = {
+    "title": "Team up with us to go further!",
+    "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
+    "linkUrl": "/contact",
+    "linkText": "Get in touch"
+    }
+  %}
+  {{ ctaBanner('purple', 'full', content)
+}}
diff --git a/src/services/workshops/rust.njk b/src/services/workshops/rust.njk
index 23f102bd9e..f02e48f24c 100644
--- a/src/services/workshops/rust.njk
+++ b/src/services/workshops/rust.njk
@@ -1,7 +1,9 @@
 ---
 layout: "base"
 title: Rust Workshops | Our Services
-description: "We provide a number of workshops to enable teams to succeed with Rust – onsite or remote"
+description: "We offer workshops to enable teams to succeed with Rust – covering a wide range from basics to advanced topics, onsite or remote."
+og:
+image: "/assets/images/workshops/rust-og-image.jpg"
 ---
 
 {% from "color-hero.njk" import colorHero %}
@@ -59,7 +61,7 @@ description: "We provide a number of workshops to enable teams to succeed with R
   "eyebrow": "Bookable for teams",
   "title": "Testing in Rust: an introduction",
   "logo": "rust",
-  "link": "services/workshops/introduction-to-rust-for-web-developers/"
+  "link": "services/workshops/an-introduction-to-testing-in-rust/"
   }
 %}
 {%
@@ -70,7 +72,15 @@ description: "We provide a number of workshops to enable teams to succeed with R
   "link": "services/workshops/advanced-testing-in-rust/"
   }
 %}
-{% set workshops = [workshop_1, workshop_2, workshop_3, workshop_4, workshop_5, workshop_6] %}
+{%
+  set 'workshop_7' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Rust-Python Interoperability",
+  "logo": "rust",
+  "link": "services/workshops/rust-python-interoperability/"
+  }
+%}
+{% set workshops = [workshop_1, workshop_2, workshop_3, workshop_4, workshop_5, workshop_6, workshop_7] %}
 {{
   workshopsList('Our training offering', 'We specialize on Rust on the backend: API services, workers, data pipelines. That focus shapes our training offering.
   We can walk alongside you on a journey from zero to hero,
diff --git a/src/services/workshops/svelte.njk b/src/services/workshops/svelte.njk
new file mode 100644
index 0000000000..5b4311e458
--- /dev/null
+++ b/src/services/workshops/svelte.njk
@@ -0,0 +1,149 @@
+---
+layout: "base"
+title: Svelte Workshops | Our Services
+description: "We offer workshops to enable teams to succeed with Svelte & SvelteKit – covering a wide range from basics to advanced topics, onsite or remote."
+og:
+  image: "/assets/images/workshops/svelte-workshops-og-image.jpg"
+---
+
+{% from "color-hero.njk" import colorHero %}
+{% from "tech-cards.njk" import techCards %}
+{% from "cta-banner.njk" import ctaBanner %}
+{% from "image-aspect-ratio.njk" import imageAspectRatio %}
+{% from "public-workshops.njk" import publicWorkshops %}
+{% from "btn-secondary.njk" import btnSecondary %}
+{% from "featured-services.njk" import featuredServices %}
+{% from "logo-list.njk" import logoList %}
+{% from "workshops-list.njk" import workshopsList %}
+{% from "secondary-feature.njk" import secondaryFeature %}
+{%
+  set 'content' = {
+  "title": "We teach teams like yours how to succeed with Svelte and SvelteKit",
+  "image": "/assets/images/hero/table-soccer.jpg",
+  "alt": "A close-up photo of the figures on a table soccer table",
+  "loading": "eager"
+  }
+%}
+{{ colorHero('purple', content) }}
+{%
+  set 'workshop_1' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Svelte & SvelteKit",
+  "logo": "svelte",
+  "link": "services/workshops/svelte-and-sveltekit/"
+  }
+%}
+{%
+  set 'workshop_2' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Progressive Enhancement with SvelteKit",
+  "logo": "svelte",
+  "link": "services/workshops/progressive-enhancement-with-sveltekit/"
+  }
+%}
+{%
+  set 'workshop_3' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Testing Svelte & SvelteKit applications",
+  "logo": "svelte",
+  "link": "services/workshops/testing-svelte-sveltekit-applications/"
+  }
+%}
+{%
+  set 'workshop_4' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Svelte 5 & Runes",
+  "logo": "svelte",
+  "link": "services/workshops/svelte-5-runes/"
+  }
+%}
+{%
+  set 'workshop_5' = {
+  "eyebrow": "Bookable for teams",
+  "title": "Authentication for Svelte & SvelteKit",
+  "logo": "svelte",
+  "link": "services/workshops/authentication-for-svelte-sveltekit/"
+  }
+%}
+{% set workshops = [workshop_1, workshop_2, workshop_3, workshop_4, workshop_5] %}
+{{
+  workshopsList('Our training offering', "We are Svelte experts and want others to get the most of it as well. That's why we provide a range of trainings on Svelte and SvelteKit.
+  We can get teams up to speed with Svelte from scratch,
+  or help them tackle a range of specific topics.", workshops)
+}}
+{% set futurePublicWorkshops = publicSvelteWorkshops.workshops | future %}
+{{ publicWorkshops(futurePublicWorkshops) }}
+
+<section class="my-10">
+  <div class="container container--lg">
+    <div class="mb-4">
+      <h3 class="mb-2">Our methodology</h3>
+      <p class="body">
+        All our workshops are hands-on. We believe that the best way to learn is by doing. Our
+        trainers introduce concepts and patterns but attendees spend the majority of their time
+        during the workshops writing code, and applying those concepts in practical examples. This
+        structure allows our trainers to spend most of their time in 1:1 conversations with
+        attendees, providing tailored feedback and guidance.
+      </p>
+    </div>
+    <div class="mb-4">
+      <h3 class="mb-2">Logistics</h3>
+      <p class="body">
+        All our workshops can be held in-person or remotely. If you decide to organise a workshop at
+        your company, we are happy to tailor the curriculum to your needs. We can combine multiple
+        workshops, pick and choose modules, as well as develop new content if desired.<br />
+        <a href="/contact/">Get in touch with us</a>
+        to discuss further!
+      </p>
+    </div>
+  </div>
+</section>
+
+<section class="my-10 container container--lg">
+  <div class="">
+    <div class="mb-4">
+      <h5 class="mb-015">Svelte & Mainmatter</h5>
+      <h3 class="mb-2">A unique skillset</h3>
+      <p>
+        We’re frontend experts – our team speaks at international events, is
+        <a href="/this-week-in-open-source/"
+          >actively contributing to a number of open source projects</a
+        >
+        and our Svelte expert Paolo Ricciuti is a Svelte maintainer and the co-author of
+        <a href="https://www.sveltelab.dev/">SvelteLab</a>.
+      </p>
+      <p>
+        Mainmatter has been developing big web apps and mentored international teams around backend,
+        frontend, design, as well as process and developer infrastructure for years. We know what it
+        takes to connect everything together and deliver a delightful end-to-end experience.
+      </p>
+    </div>
+  </div>
+</section>
+
+<section class="my-10 container container--lg">
+  <div class="split-content no-link">
+    <div class="split-content__wrapper">
+      <div class="split-content__content">
+        <h2 class="split-content__subheading">Your mentor</h2>
+        <p>
+          Paolo Ricciuti is a huge nerd and Svelte maintainer. He's also one of the creators of
+          <a href="https://sveltelab.dev">sveltelab.dev</a> - a REPL for SvelteKit.
+        </p>
+      </div>
+      <div class="split-content__feature">
+        {%
+          set 'content' = {
+          "image": "/assets/images/authors/paoloricciuti.jpg",
+          "alt": "Paolo Ricciuti",
+          "loading": "lazy"
+          }
+        %}
+        {{ secondaryFeature(content, 'split-content__author') }}
+      </div>
+    </div>
+  </div>
+</section>
+
+{% include "global/svelte-cta.njk" %}
+{% include "global/svelte-newsletter-cta.njk" %}
diff --git a/src/startups.njk b/src/startups.njk
index 80daef2331..d111316fe0 100644
--- a/src/startups.njk
+++ b/src/startups.njk
@@ -153,7 +153,7 @@ description: "Discover effective strategies to scale up your business, and achie
 {{ featuredCaseStudies(clients, 'Browse our work') }}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/svelte-consulting.njk b/src/svelte-consulting.njk
index 00c3984d33..3bf0333ef3 100644
--- a/src/svelte-consulting.njk
+++ b/src/svelte-consulting.njk
@@ -1,10 +1,10 @@
 ---
 layout: base
-title: Enable your team to succeed with Svelte
+title: "Team Up With Us for Svelte! | Svelte consulting"
 description: Mainmatter enables teams to succedd with Svelte and build ambitious web apps that are fast and maintainable.
 permalink: /svelte-consulting/
 og:
-  image: /assets/images/svelte/lp-svelte-consulting-og-image.jpg
+  image: /assets/images/svelte/og-image.png
 ---
 
 {% from "image-banner-with-text.njk" import imageBannerWithText %}
@@ -20,7 +20,7 @@ og:
 {%
   set 'content' = {
   "eyebrow": "Our Expertise: Svelte & SvelteKit",
-  "title": "Svelte is the future of frontend development",
+  "title": "Team Up With Us for Svelte!",
   "text": "Svelte combines a leading developer experience with performance and maintainability. With SvelteKit and its progressive enhancement capabilities, it's a fit for a wide range of use cases. Mainmatter is here to empower your team to fully realize those benefits in your web and backend projects.",
   "image": "/assets/images/hero/svelte.jpg",
   "alt": "A metal chain",
@@ -39,7 +39,7 @@ og:
         <a href="/this-week-in-open-source/"
           >actively contributing to a number of open source projects</a
         >
-        and our Svelte expert Paolo Ricciuti is a Svelte ambassador and the co-author of
+        and our Svelte expert Paolo Ricciuti is a Svelte maintainer and the co-author of
         <a href="https://www.sveltelab.dev/">SvelteLab</a>.
       </p>
       <p>
@@ -49,14 +49,35 @@ og:
       </p>
     </div>
   </div>
+</section>
+
+<section class="my-10 container container--lg">
+  <div class="">
+    <div class="mb-4">
+      <h5 class="mb-015">Svelte Summit & This Week in Svelte</h5>
+      <h3 class="mb-2">Fostering the Community</h3>
+      <p>
+        Mainmatter believes open source communities are valuable and we strive for being active
+        community members. Our team regularly speaks at all of the relevant Svelte conferences but
+        also other conferences. We also co-organize Svelte Summit together with our friends at
+        Svelte Society and our Svelte lead, Paolo Riccuiti is the host of the
+        <a
+          href="https://www.youtube.com/playlist?list=PL8bMgX1kyZTiLCyvf8vF13sdnR4fhNl6v"
+          target="_blank"
+          rel="external nofollow noopener noreferrer"
+          >This Week in Svelte video series</a
+        >.
+      </p>
+    </div>
+  </div>
   <div class="split-content">
-    <a href="https://www.sveltesummit.com/" class="split-content__link"></a>
+    <a href="https://www.sveltesummit.com" class="split-content__link"></a>
     <div class="split-content__wrapper">
       <div class="split-content__content">
-        <h4>Mainmatter is a Gold Sponsor of Svelte Summit Fall 2023</h4>
+        <h4>We co-organize Svelte Summit together with our friends at Svelte Society.</h4>
         {%
           set link = {
-          "label": 'Learn more',
+          "label": 'Join us in Barcelona in May 2025!',
           "url": 'https://www.sveltesummit.com/'
           }
         %}
@@ -136,7 +157,7 @@ og:
       {%
         set link = {
         "label": 'Check out our workshops!',
-        "url": '/services/workshops/svelte-and-sveltekit/'
+        "url": '/services/workshops/svelte/'
         }
       %}
       {{ btnSecondary( link, 'mt-2 plausible-event-name=Svelte+Workshops' ) }}
@@ -199,6 +220,22 @@ og:
           {{ btnSecondary( link, 'mt-2' ) }}
         </div>
       </li>
+      <li class="opensource-list__project">
+        <div class="opensource-list__project-image">
+          <img src="/assets/images/svelte/sheepdog.svg" alt="Sheepdog" />
+        </div>
+        <div class="opensource-list__project-text">
+          <h4 class="mb-015">@sheepdog/svelte</h4>
+          <p>Herd your async tasks!</p>
+          {%
+            set link = {
+            "label": 'View on GitHub',
+            "url": 'https://github.com/mainmatter/sheepdog'
+            }
+          %}
+          {{ btnSecondary( link, 'mt-2' ) }}
+        </div>
+      </li>
     </ul>
   </div>
 </section>
@@ -207,8 +244,8 @@ og:
 {% include "global/svelte-newsletter-cta.njk" %}
 {%
   set 'content' = {
-  "title": "Grow your business with us",
-  "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
+  "title": "Team up with us for Svelte",
+  "text": "Our Svelte experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
   }
diff --git a/src/tag.njk b/src/tag.njk
index efe6e1f4ae..8455c198db 100644
--- a/src/tag.njk
+++ b/src/tag.njk
@@ -46,7 +46,7 @@ permalink: "/blog/tag/{{ paged.tag | slug }}/{% if paged.number > 1 %}/page/{{ p
 
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/talks.njk b/src/talks.njk
index f4cdab7c0d..e7bfaee226 100644
--- a/src/talks.njk
+++ b/src/talks.njk
@@ -35,7 +35,7 @@ eleventyNavigation:
 </section>
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/travel.njk b/src/travel.njk
new file mode 100644
index 0000000000..349800cfb6
--- /dev/null
+++ b/src/travel.njk
@@ -0,0 +1,338 @@
+---
+layout: "base"
+title: "We Modernize the Travel Industry"
+description: "We transform travel companies holistically, building modern organizations along with industry-leading products."
+og:
+  image: /assets/images/travel/lp-travel-og-image.jpg
+---
+
+{% from "color-hero.njk" import colorHero %}
+{% from "strategy-list.njk" import strategyList %}
+{% from "quote.njk" import quote %}
+{% from "featured-case-studies.njk" import featuredCaseStudies %}
+{% from "recent-posts.njk" import recentPosts %}
+{% from "featured-services.njk" import featuredServices %}
+{% from "secondary-feature.njk" import secondaryFeature %}
+{% from "cta-banner.njk" import ctaBanner %}
+{% from "btn-secondary.njk" import btnSecondary %}
+{%
+  set 'content' = {
+  "title": "We Modernize the Travel Industry",
+  "text": "We transform companies in the digital travel, transport and mobility industries holistically, building modern organizations along with industry-leading products.",
+  "image": "/assets/images/photos/travel-hero.jpg",
+  "alt": "Lego city scape",
+  "loading": "eager"
+  }
+%}
+{{ colorHero('purple', content) }}
+
+<section class="my-10">
+  <div class="container container--lg">
+    <div class="mb-4">
+      <p class="body">
+        We know the products and practices of the leading tech teams in the world - in fact, we’ve
+        been involved with shaping them. We can transform your company to match these standards. We
+        will assess the status quo, create a roadmap towards your future shape, and guide you
+        throughout the journey.
+      </p>
+    </div>
+  </div>
+</section>
+
+{%
+  set list =  [{
+    "title": "Assess the status quo via a thorough analysis of code, architecture, infrastructure, and processes, as well as interviews with stakeholders."
+  },{
+    "title": "Prepare a roadmap for transforming the product as well as the development organization behind it."
+  },{
+    "title": "Guide your team through the transformation phase."
+  }]
+%}
+
+{{ strategyList('launch-your-idea', 'We’ll work with you to:', list) }}
+
+<section
+  class="cta-banner cta-banner--aqua container container--xl my-10"
+  data-background-color="aqua"
+>
+  <div class="cta-banner__wrapper">
+    <div class="cta-banner__main">
+      <h2 class="cta-banner__title">The Travel Transformation Whitepaper</h2>
+      <div class="cta-banner__text">
+        Download our whitepaper for an in-depth analysis of the challenges the digital travel,
+        transport, and mobility industries are facing. Discover what there is to learn from leading
+        tech teams to modernize your company and boost competitiveness.
+      </div>
+      <div class="form-with-image">
+        <form
+          id="whitepaper-form"
+          data-contact-form
+          class="contact-form__form form-with-image__form"
+          data-status="initial"
+          data-action="https://hooks.zapier.com/hooks/catch/4837956/24hp3a0/"
+          data-method="get"
+          data-goal="Travel+Whitepaper"
+        >
+          <div data-form-content class="contact-form__field cta__input mb-2 mt-2">
+            <input
+              class="contact-form__input"
+              id="name"
+              type="text"
+              name="name"
+              placeholder="Your name"
+              required
+            />
+            <label class="contact-form__label h4" for="name">
+              Your name
+              <span class="screenreader">(Required)</span>
+            </label>
+            <span class="contact-form__label-required" aria-hidden="true">Required</span>
+          </div>
+          <div class="contact-form__field cta__input mb-2 mt-2">
+            <input
+              class="contact-form__input"
+              id="company"
+              type="text"
+              name="company"
+              placeholder="Your company's name"
+            />
+            <label class="contact-form__label h4" for="name"> Your company's name </label>
+          </div>
+          <div class="contact-form__field cta__input mb-2 mt-2">
+            <input
+              class="contact-form__input"
+              id="email"
+              type="email"
+              name="email"
+              placeholder="Your e-mail"
+              required
+            />
+            <label class="contact-form__label h4" for="email">
+              Your e-mail
+              <span class="screenreader">(Required)</span>
+            </label>
+            <span class="contact-form__label-required" aria-hidden="true">Required</span>
+          </div>
+          <div class="contact-form__field cta__input mb-2 mt-2">
+            <label class="contact-form__label h4 contact-form__label-checkbox">
+              <input
+                class="contact-form__input contact-form__input-checkbox"
+                id="marketing_opt_in"
+                type="checkbox"
+                name="marketing_opt_in"
+                required
+              />
+              <span>I agree to receive other communication from Mainmatter.</span>
+            </label>
+          </div>
+          <button class="btn-primary btn-primary--white" type="submit">
+            <span>Download whitepaper</span>
+            {% include 'svg/arrow.njk' %}
+          </button>
+          <div class="contact-form__status">
+            <button class="contact-form__close" data-reset-form>
+              {% include 'svg/close.njk' %}
+              <span class="screenreader">Close</span>
+            </button>
+            <div class="contact-form__loading h4" data-form-loading>
+              Your message is being sent…
+              <div class="loader" aria-hidden="true"></div>
+            </div>
+            <div class="contact-form__error" tabindex="-1" data-form-error>
+              <div class="contact-form__status-wrapper">
+                <h2 class="contact-form__success-subheading h3">Unable to send message.</h2>
+                <p>
+                  Please try again later or contact us at
+                  <a href="mailto:travel@mainmatter.com">travel@mainmatter.com</a>
+                </p>
+              </div>
+            </div>
+            <div class="contact-form__success" tabindex="-1" data-form-success>
+              <div class="contact-form__status-wrapper">
+                <h2 class="contact-form__success-heading h3">Thank you!</h2>
+                <p class="contact-form__success-subheading h3">We will be in touch soon.</p>
+                <p>You will receive an email with the whitepaper shortly.</p>
+              </div>
+            </div>
+          </div>
+        </form>
+        <div class="form-with-image__image">
+          <div class="image-wrapper">
+            {% image '/assets/images/photos/travel-whitepaper-cover.jpg', "Title page of Mainmatter's Travel Transformation whitepaper", '(min-width: 48em) 40rem, 90vw', 'lazy', '', [400, 800, 1200] %}
+          </div>
+        </div>
+      </div>
+    </div>
+  </div>
+</section>
+
+<section class="my-10">
+  <div class="container container--lg">
+    <div class="mb-4">
+      <h2 class="mb-3">Team up with Mainmatter to overcome challenges together</h2>
+      <p class="body">
+        The travel industry is under rising pressure as user expectations grow, entry barriers
+        decrease, gatekeepers like Booking become ever more powerful, and disruptive newcomers enter
+        the market. To maintain or expand their market share, established companies must innovate
+        quickly, deliver impressive results, and adapt flexibly to a changing landscape. We partner
+        with companies in the travel industry to overcome those challenges.
+      </p>
+    </div>
+  </div>
+</section>
+
+<section class="my-10 container container--lg">
+  <div class="split-content no-link">
+    <div class="split-content__wrapper">
+      <div class="split-content__content">
+        <h5>Book a free call</h5>
+        <h3 class="split-content__subheading h2">Looking to transform your company?</h3>
+        <p>
+          Mainmatter's Founder and Managing Director, Marco Otte-Witte, is available to give you an
+          in-depth introduction to how we transform companies or share his thoughts on any
+          challenges you're facing.
+        </p>
+        {%
+          set link = {
+          "label": 'Book a 1:1 call with us',
+          "url": 'https://calendar.app.google/3FHWr4pdh2kNrZnv9'
+          }
+        %}
+        {{ btnSecondary( link, 'mt-2 plausible-event-name=Travel+1on1+Call' ) }}
+      </div>
+      <div class="split-content__feature">
+        {%
+          set 'content' = {
+          "image": "/assets/images/authors/marcoow.jpg",
+          "alt": "Marco Otte-Witte",
+          "loading": "lazy"
+          }
+        %}
+        {{ secondaryFeature(content, 'split-content__author') }}
+      </div>
+    </div>
+  </div>
+</section>
+
+{% set clients = ['rail-europe'] %}
+{{ featuredCaseStudies(clients) }}
+
+<div class="container container--lg quote-section">
+  {%
+    set 'content' = {
+    "text": "Mainmatter enabled us to take our Product Development Organization to the next level. They work closely with our team and help us establish new practices while simultaneously delivering on our day to day product initiatives. Their technical and organizational expertise and fresh views allow us to set up the foundation for future success.",
+    "source": "Jürgen Witte, CPO @ Rail Europe",
+    "image": "/assets/images/photos/juergen-witte.png",
+    "alt": "Jürgen Witte",
+    "loading": "lazy"
+    }
+  %}
+  {{ quote(content) }}
+</div>
+
+{% set clients = ['trainline', 'hop-skip-drive', 'terminal49', 'aleph-alpha'] %}
+{{ featuredCaseStudies(clients) }}
+
+{{ recentPosts("Latest from our blog", collections.travelPosts) }}
+{%
+  set 'content' = {
+  "subtitle": "Discover our services"
+  }
+%}
+
+<section class="cta-banner cta-banner--purple" data-background-color="purple">
+  <div class="cta-banner__wrapper container container--xl">
+    <div class="cta-banner__main">
+      <h2 class="cta-banner__title">Team up with us!</h2>
+      <div class="cta-banner__text">
+        We are your partner to modernize your company and boost competitiveness.
+      </div>
+      <form
+        id="contact-form"
+        data-contact-form
+        class="contact-form__form"
+        data-status="initial"
+        data-action="https://contact.mainmatter.dev/send"
+        data-method="post"
+        data-goal="Travel+Whitepaper"
+      >
+        <input type="hidden" name="service" id="service" value="Travel" />
+        <input type="hidden" name="message" id="message" value="" />
+        <div data-form-content class="contact-form__field cta__input mb-2 mt-2">
+          <input
+            class="contact-form__input"
+            id="name"
+            type="text"
+            name="name"
+            placeholder="Your name"
+            required
+          />
+          <label class="contact-form__label h4" for="name">
+            Your name
+            <span class="screenreader">(Required)</span>
+          </label>
+          <span class="contact-form__label-required" aria-hidden="true">Required</span>
+        </div>
+        <div class="contact-form__field cta__input mb-2 mt-2">
+          <input
+            class="contact-form__input"
+            id="company"
+            type="text"
+            name="company"
+            placeholder="Your company's name"
+          />
+          <label class="contact-form__label h4" for="name"> Your company's name </label>
+        </div>
+        <div class="contact-form__field cta__input mb-2 mt-2">
+          <input
+            class="contact-form__input"
+            id="email"
+            type="email"
+            name="email"
+            placeholder="Your e-mail"
+            required
+          />
+          <label class="contact-form__label h4" for="email">
+            Your e-mail
+            <span class="screenreader">(Required)</span>
+          </label>
+          <span class="contact-form__label-required" aria-hidden="true">Required</span>
+        </div>
+        <button class="btn-primary btn-primary--white">
+          <span>Submit</span>
+          {% include 'svg/arrow.njk' %}
+        </button>
+        <div class="contact-form__status">
+          <button class="contact-form__close" data-reset-form>
+            {% include 'svg/close.njk' %}
+            <span class="screenreader">Close</span>
+          </button>
+          <div class="contact-form__loading h4" data-form-loading>
+            Your message is being sent…
+            <div class="loader" aria-hidden="true"></div>
+          </div>
+          <div class="contact-form__error" tabindex="-1" data-form-error>
+            <div class="contact-form__status-wrapper">
+              <h2 class="contact-form__success-subheading h3">Unable to send message.</h2>
+              <p>
+                Please try again later or contact us at
+                <a href="mailto:travel@mainmatter.com">travel@mainmatter.com</a>
+              </p>
+            </div>
+          </div>
+          <div class="contact-form__success" tabindex="-1" data-form-success>
+            <div class="contact-form__status-wrapper">
+              <h2 class="contact-form__success-heading h3">Thank you!</h2>
+              <p class="contact-form__success-subheading h3">We will be in touch soon.</p>
+              <p>One of our experts will get back to you shortly.</p>
+              <p>
+                In the meantime, have a look at our <a href="/work/">work</a>
+                to learn more about how we helped other companies in the past.
+              </p>
+            </div>
+          </div>
+        </div>
+      </form>
+    </div>
+  </div>
+</section>
diff --git a/src/twios/2021-12-10.md b/src/twios/2021-12-10.md
index a0eb711f97..09e9f1e571 100644
--- a/src/twios/2021-12-10.md
+++ b/src/twios/2021-12-10.md
@@ -1,9 +1,6 @@
 ## Highlight
 
-This week our senior software engineer [Tobias Bieniek] did a little bit of
-design work on [crates.io], the [Rust] package registry. The website now has a
-[new page footer](https://github.com/rust-lang/crates.io/pull/4158) and a
-[cute little 404 page](https://github.com/rust-lang/crates.io/pull/4154):
+This week our senior software engineer [Tobias Bieniek] did a little bit of design work on [crates.io], the [Rust] package registry. The website now has a [new page footer](https://github.com/rust-lang/crates.io/pull/4158) and a [cute little 404 page](https://github.com/rust-lang/crates.io/pull/4154):
 
 ![](https://user-images.githubusercontent.com/141300/141307167-e3fd2914-064f-4076-b415-fc12a8f8bcbe.png)
 
@@ -11,131 +8,65 @@ design work on [crates.io], the [Rust] package registry. The website now has a
 
 ## Rust
 
-- [hyperium/http] [#513](https://github.com/hyperium/http/pull/513) Cargo: Add
-  `rust-version` field ([@Turbo87])
-- [hyperium/http] [#512](https://github.com/hyperium/http/pull/512) README:
-  Remove obsolete extern crate http instructions ([@Turbo87])
+- [hyperium/http] [#513](https://github.com/hyperium/http/pull/513) Cargo: Add `rust-version` field ([@Turbo87])
+- [hyperium/http] [#512](https://github.com/hyperium/http/pull/512) README: Remove obsolete extern crate http instructions ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4175](https://github.com/rust-lang/crates.io/pull/4175) worker::git: Read
-  `yanked` status from database ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4173](https://github.com/rust-lang/crates.io/pull/4173) TestApp: Simplify
-  `crates_from_index_head()` method ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4171](https://github.com/rust-lang/crates.io/pull/4171) Improve Avatar
-  styling ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4170](https://github.com/rust-lang/crates.io/pull/4170) Header: Add drop
-  shadows to main elements ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4166](https://github.com/rust-lang/crates.io/pull/4166) bin/server: Print
-  HTTP server URL on startup ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4165](https://github.com/rust-lang/crates.io/pull/4165) bin/server: Simplify
-  assignments via `match` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4162](https://github.com/rust-lang/crates.io/pull/4162) OwnersList: Fall
-  back to login if name is not filled ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4158](https://github.com/rust-lang/crates.io/pull/4158) Redesign Footer
-  component ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4156](https://github.com/rust-lang/crates.io/pull/4156) Show 404 pages for
-  unknown crates/versions ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4154](https://github.com/rust-lang/crates.io/pull/4154) Redesign 404 page
-  ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4152](https://github.com/rust-lang/crates.io/pull/4152) CrateSidebar: Show
-  detailed list for small number of owners ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4151](https://github.com/rust-lang/crates.io/pull/4151) renovate: Adjust
-  `node` package grouping ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4150](https://github.com/rust-lang/crates.io/pull/4150) renovate: Convert to
-  JSON5 file ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4148](https://github.com/rust-lang/crates.io/pull/4148) Pin Node.js version
-  ([@Turbo87])
-
-- [conduit-rust/conduit-hyper]
-  [#34](https://github.com/conduit-rust/conduit-hyper/pull/34) ConduitRequest:
-  Inline `parts()` method ([@Turbo87])
-- [conduit-rust/conduit-hyper]
-  [#33](https://github.com/conduit-rust/conduit-hyper/pull/33) RequestInfo:
-  Replace custom struct with `Request<Bytes>` ([@Turbo87])
+- [rust-lang/crates.io] [#4175](https://github.com/rust-lang/crates.io/pull/4175) worker::git: Read `yanked` status from database ([@Turbo87])
+- [rust-lang/crates.io] [#4173](https://github.com/rust-lang/crates.io/pull/4173) TestApp: Simplify `crates_from_index_head()` method ([@Turbo87])
+- [rust-lang/crates.io] [#4171](https://github.com/rust-lang/crates.io/pull/4171) Improve Avatar styling ([@Turbo87])
+- [rust-lang/crates.io] [#4170](https://github.com/rust-lang/crates.io/pull/4170) Header: Add drop shadows to main elements ([@Turbo87])
+- [rust-lang/crates.io] [#4166](https://github.com/rust-lang/crates.io/pull/4166) bin/server: Print HTTP server URL on startup ([@Turbo87])
+- [rust-lang/crates.io] [#4165](https://github.com/rust-lang/crates.io/pull/4165) bin/server: Simplify assignments via `match` ([@Turbo87])
+- [rust-lang/crates.io] [#4162](https://github.com/rust-lang/crates.io/pull/4162) OwnersList: Fall back to login if name is not filled ([@Turbo87])
+- [rust-lang/crates.io] [#4158](https://github.com/rust-lang/crates.io/pull/4158) Redesign Footer component ([@Turbo87])
+- [rust-lang/crates.io] [#4156](https://github.com/rust-lang/crates.io/pull/4156) Show 404 pages for unknown crates/versions ([@Turbo87])
+- [rust-lang/crates.io] [#4154](https://github.com/rust-lang/crates.io/pull/4154) Redesign 404 page ([@Turbo87])
+- [rust-lang/crates.io] [#4152](https://github.com/rust-lang/crates.io/pull/4152) CrateSidebar: Show detailed list for small number of owners ([@Turbo87])
+- [rust-lang/crates.io] [#4151](https://github.com/rust-lang/crates.io/pull/4151) renovate: Adjust `node` package grouping ([@Turbo87])
+- [rust-lang/crates.io] [#4150](https://github.com/rust-lang/crates.io/pull/4150) renovate: Convert to JSON5 file ([@Turbo87])
+- [rust-lang/crates.io] [#4148](https://github.com/rust-lang/crates.io/pull/4148) Pin Node.js version ([@Turbo87])
+
+- [conduit-rust/conduit-hyper] [#34](https://github.com/conduit-rust/conduit-hyper/pull/34) ConduitRequest: Inline `parts()` method ([@Turbo87])
+- [conduit-rust/conduit-hyper] [#33](https://github.com/conduit-rust/conduit-hyper/pull/33) RequestInfo: Replace custom struct with `Request<Bytes>` ([@Turbo87])
 
 ## Ember.js
 
-- [emberjs/data] [#7750](https://github.com/emberjs/data/pull/7750) reference:
-  Fix broken `meta()` snippet ([@Turbo87])
-
-- [ember-cli/ember-cli]
-  [#9696](https://github.com/ember-cli/ember-cli/pull/9696) commands/init: Fix
-  `--yarn` usage ([@Turbo87])
-
-- [buschtoens/ember-link]
-  [#678](https://github.com/buschtoens/ember-link/pull/678) Adjust
-  @glimmer/tracking dependency to use semver ([@Turbo87])
-- [buschtoens/ember-link]
-  [#675](https://github.com/buschtoens/ember-link/pull/675) Use pnpm package
-  manager ([@Turbo87])
-- [buschtoens/ember-link]
-  [#674](https://github.com/buschtoens/ember-link/pull/674) Release via CI
-  ([@Turbo87])
-- [buschtoens/ember-link]
-  [#672](https://github.com/buschtoens/ember-link/pull/672) chore(deps): update
-  @types dependencies ([@Turbo87])
-
-ESA 4.0: Refactored internals of the addon to use Ember’s dependency injection,
-making things simpler and easier to test. Successfully removed a lot of code,
-and simplified tests setup.
-
-- [mainmatter/ember-simple-auth]
-  [#2315](https://github.com/mainmatter/ember-simple-auth/pull/2315) put
-  internal-session into DI system ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2312](https://github.com/mainmatter/ember-simple-auth/pull/2312) Refactor
-  Adaptive store to use DI ([@BobrImperator])
-
-ESA 4.1: implemented a session #setup method. The methos represents a first step
-to migrating from custom initializers, it excludes the application route that
-ESA adds automatically and that is causing build issues for embroider and
-typescript users.
-
-- [mainmatter/ember-simple-auth]
-  [#2314](https://github.com/mainmatter/ember-simple-auth/issues/2314) Add
-  #setup method to session service ([@BobrImperator])
+- [emberjs/data] [#7750](https://github.com/emberjs/data/pull/7750) reference: Fix broken `meta()` snippet ([@Turbo87])
+
+- [ember-cli/ember-cli] [#9696](https://github.com/ember-cli/ember-cli/pull/9696) commands/init: Fix `--yarn` usage ([@Turbo87])
+
+- [buschtoens/ember-link] [#678](https://github.com/buschtoens/ember-link/pull/678) Adjust @glimmer/tracking dependency to use semver ([@Turbo87])
+- [buschtoens/ember-link] [#675](https://github.com/buschtoens/ember-link/pull/675) Use pnpm package manager ([@Turbo87])
+- [buschtoens/ember-link] [#674](https://github.com/buschtoens/ember-link/pull/674) Release via CI ([@Turbo87])
+- [buschtoens/ember-link] [#672](https://github.com/buschtoens/ember-link/pull/672) chore(deps): update @types dependencies ([@Turbo87])
+
+ESA 4.0: Refactored internals of the addon to use Ember’s dependency injection, making things simpler and easier to test. Successfully removed a lot of code, and simplified tests setup.
+
+- [mainmatter/ember-simple-auth] [#2315](https://github.com/mainmatter/ember-simple-auth/pull/2315) put internal-session into DI system ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2312](https://github.com/mainmatter/ember-simple-auth/pull/2312) Refactor Adaptive store to use DI ([@BobrImperator])
+
+ESA 4.1: implemented a session #setup method. The methos represents a first step to migrating from custom initializers, it excludes the application route that ESA adds automatically and that is causing build issues for embroider and typescript users.
+
+- [mainmatter/ember-simple-auth] [#2314](https://github.com/mainmatter/ember-simple-auth/issues/2314) Add #setup method to session service ([@BobrImperator])
 
 ## JavaScript
 
-- [remy/nodemon] [#1934](https://github.com/remy/nodemon/pull/1934) ci(node.js):
-  workflow uses 'npm' cache ([@oscard0m])
-- [remy/nodemon] [#1933](https://github.com/remy/nodemon/pull/1933) ci(release):
-  workflow uses 'npm' cache ([@oscard0m])
+- [remy/nodemon] [#1934](https://github.com/remy/nodemon/pull/1934) ci(node.js): workflow uses 'npm' cache ([@oscard0m])
+- [remy/nodemon] [#1933](https://github.com/remy/nodemon/pull/1933) ci(release): workflow uses 'npm' cache ([@oscard0m])
 
-- [strapi/strapi] [#11531](https://github.com/strapi/strapi/pull/11531) Add
-  cache to node workflows ([@oscard0m])
+- [strapi/strapi] [#11531](https://github.com/strapi/strapi/pull/11531) Add cache to node workflows ([@oscard0m])
 
-- [storybookjs/storybook]
-  [#15969](https://github.com/storybookjs/storybook/pull/15969) Core: Add
-  'staticDirs' config option ([@oscard0m])
-- [storybookjs/eslint-plugin-storybook]
-  [#5](https://github.com/storybookjs/eslint-plugin-storybook/issues/5) ESLint
-  error: TypeError: Cannot read property 'properties' of undefined ([@oscard0m])
-- [storybookjs/eslint-plugin-storybook]
-  [#7](https://github.com/storybookjs/eslint-plugin-storybook/issues/7) ESLint
-  error: TypeError: Cannot read property 'name' of undefined ([@oscard0m])
+- [storybookjs/storybook] [#15969](https://github.com/storybookjs/storybook/pull/15969) Core: Add 'staticDirs' config option ([@oscard0m])
+- [storybookjs/eslint-plugin-storybook] [#5](https://github.com/storybookjs/eslint-plugin-storybook/issues/5) ESLint error: TypeError: Cannot read property 'properties' of undefined ([@oscard0m])
+- [storybookjs/eslint-plugin-storybook] [#7](https://github.com/storybookjs/eslint-plugin-storybook/issues/7) ESLint error: TypeError: Cannot read property 'name' of undefined ([@oscard0m])
 
 ## Mainmatter's playbook
 
 Added more detailed information regarding issue preparation.
 
-- [mainmatter/playbook] [#171](https://github.com/mainmatter/playbook/pull/171)
-  Add more information about issue preparation ([@marcoow])
+- [mainmatter/playbook] [#171](https://github.com/mainmatter/playbook/pull/171) Add more information about issue preparation ([@marcoow])
 
 [hyperium/http]: https://github.com/hyperium/http/
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io/
@@ -152,8 +83,7 @@ Added more detailed information regarding issue preparation.
 [remy/nodemon]: https://github.com/remy/nodemon/
 [strapi/strapi]: https://github.com/strapi/strapi/
 [storybookjs/storybook]: https://github.com/storybookjs/storybook/
-[storybookjs/eslint-plugin-storybook]:
-  https://github.com/storybookjs/eslint-plugin-storybook/
+[storybookjs/eslint-plugin-storybook]: https://github.com/storybookjs/eslint-plugin-storybook/
 [@marcoow]: https://github.com/marcoow/
 [@bobrimperator]: https://github.com/BobrImperator/
 [@oscard0m]: https://github.com/oscard0m/
diff --git a/src/twios/2022-01-11.md b/src/twios/2022-01-11.md
index 3621135b94..2c85277217 100644
--- a/src/twios/2022-01-11.md
+++ b/src/twios/2022-01-11.md
@@ -1,201 +1,84 @@
 ## JavaScript
 
-- [commitizen/cz-conventional-changelog]
-  [#181](https://github.com/commitizen/cz-conventional-changelog/pull/181)
-  feat(config): add 'extends' configuration option ([@oscard0m])
-- [oscard0m/npm-snapshot]
-  [#12](https://github.com/oscard0m/npm-snapshot/pull/12) fix(npm-snapshot):
-  exit execution if stringified semver 'version' is undefined ([@oscard0m])
-- [oscard0m/npm-snapshot]
-  [#11](https://github.com/oscard0m/npm-snapshot/pull/11) docs(readme): format
-  README.md ([@oscard0m])
-- [oscard0m/npm-snapshot]
-  [#10](https://github.com/oscard0m/npm-snapshot/pull/10) style(npm-snapshot):
-  applied style (prettier) changes ([@oscard0m])
-- [oscard0m/npm-snapshot] [#9](https://github.com/oscard0m/npm-snapshot/pull/9)
-  ci(release): remove non-existing 'npm run build' step from release workflow
-  ([@oscard0m])
-- [oscard0m/npm-snapshot] [#8](https://github.com/oscard0m/npm-snapshot/pull/8)
-  ci(package-lock): add missing package-lock ([@oscard0m])
-- [oscard0m/npm-snapshot] [#7](https://github.com/oscard0m/npm-snapshot/pull/7)
-  ci(release): add Release workflow via Github Action with Semantic Release
-  ([@oscard0m])
-- [oscard0m/npm-snapshot] [#6](https://github.com/oscard0m/npm-snapshot/pull/6)
-  chore(package.json): update author of the project ([@oscard0m])
-- [oscard0m/npm-snapshot] [#5](https://github.com/oscard0m/npm-snapshot/pull/5)
-  chore(.gitignore): ignore .vscode folder ([@oscard0m])
+- [commitizen/cz-conventional-changelog] [#181](https://github.com/commitizen/cz-conventional-changelog/pull/181) feat(config): add 'extends' configuration option ([@oscard0m])
+- [oscard0m/npm-snapshot] [#12](https://github.com/oscard0m/npm-snapshot/pull/12) fix(npm-snapshot): exit execution if stringified semver 'version' is undefined ([@oscard0m])
+- [oscard0m/npm-snapshot] [#11](https://github.com/oscard0m/npm-snapshot/pull/11) docs(readme): format README.md ([@oscard0m])
+- [oscard0m/npm-snapshot] [#10](https://github.com/oscard0m/npm-snapshot/pull/10) style(npm-snapshot): applied style (prettier) changes ([@oscard0m])
+- [oscard0m/npm-snapshot] [#9](https://github.com/oscard0m/npm-snapshot/pull/9) ci(release): remove non-existing 'npm run build' step from release workflow ([@oscard0m])
+- [oscard0m/npm-snapshot] [#8](https://github.com/oscard0m/npm-snapshot/pull/8) ci(package-lock): add missing package-lock ([@oscard0m])
+- [oscard0m/npm-snapshot] [#7](https://github.com/oscard0m/npm-snapshot/pull/7) ci(release): add Release workflow via Github Action with Semantic Release ([@oscard0m])
+- [oscard0m/npm-snapshot] [#6](https://github.com/oscard0m/npm-snapshot/pull/6) chore(package.json): update author of the project ([@oscard0m])
+- [oscard0m/npm-snapshot] [#5](https://github.com/oscard0m/npm-snapshot/pull/5) chore(.gitignore): ignore .vscode folder ([@oscard0m])
 
 ## Ember.js
 
-- [mainmatter/ember-promise-modals]
-  [#500](https://github.com/mainmatter/ember-promise-modals/pull/500) Specify
-  octane edition in package.json & add missing optional features ([@nickschot])
-- [mainmatter/ember-promise-modals]
-  [#499](https://github.com/mainmatter/ember-promise-modals/pull/499) Update
-  ember-release scenario to use auto-import v2 ([@nickschot])
-
-- [nickschot/ember-mobile-menu]
-  [#216](https://github.com/nickschot/ember-mobile-menu/pull/216) add
-  ember-keyboard v7 resolution to fix ember 4+ CI ([@nickschot])
-
-- [mainmatter/ember-intl-analyzer]
-  [#447](https://github.com/mainmatter/ember-intl-analyzer/pull/447) Add
-  additional guard to check if at the top of the parent tree and tests
-  ([@mikek2252])
-
-- [mansona/ember-cli-notifications]
-  [#328](https://github.com/mansona/ember-cli-notifications/pull/328) Breaking:
-  Update container component ([@pichfl])
-- [mansona/ember-cli-notifications]
-  [#326](https://github.com/mansona/ember-cli-notifications/pull/326) BREAKING:
-  Remove obsolete equals helper ([@pichfl])
-- [mansona/ember-cli-notifications]
-  [#325](https://github.com/mansona/ember-cli-notifications/pull/325) Breaking:
-  Modernize and improve notification message component ([@pichfl])
-- [mansona/ember-cli-notifications]
-  [#324](https://github.com/mansona/ember-cli-notifications/pull/324) Replace
-  overridable icon paths with overridable icon components ([@pichfl])
-- [mansona/ember-cli-notifications]
-  [#327](https://github.com/mansona/ember-cli-notifications/pull/327) move to
-  field-guide ([@mansona])
-
-- [empress/ember-cli-showdown]
-  [#109](https://github.com/empress/ember-cli-showdown/pull/109) Add some basic
-  Fastboot testing ([@mansona])
-- [empress/ember-cli-showdown]
-  [#108](https://github.com/empress/ember-cli-showdown/pull/108) feat: Import
-  htmlSafe from @ember/template, not @ember/string. ([@mansona])
-
-- [mainmatter/ember-simple-auth]
-  [#2350](https://github.com/mainmatter/ember-simple-auth/pull/2350) Upgrade to
-  qunit 5 ([@candunaj])
-- [mainmatter/ember-simple-auth]
-  [#2349](https://github.com/mainmatter/ember-simple-auth/pull/2349) Fixed
-  failing unit test - invalidate call revoke endpoint twice. Unit test did not
-  validate it correctly. ([@candunaj])
-- [mainmatter/ember-simple-auth]
-  [#2348](https://github.com/mainmatter/ember-simple-auth/pull/2348) Fixed
-  quietly failing unit test because server returned nothing ([@candunaj])
-- [mainmatter/ember-simple-auth]
-  [#2345](https://github.com/mainmatter/ember-simple-auth/pull/2345) Fixed
-  failing unit test - ember/object get function was removed from source code so
-  I have changed unit test accordingly ([@candunaj])
-- [mainmatter/ember-simple-auth]
-  [#2344](https://github.com/mainmatter/ember-simple-auth/pull/2344) In some
-  tests was thrown undefined. ([@candunaj])
-- [mainmatter/ember-simple-auth]
-  [#2343](https://github.com/mainmatter/ember-simple-auth/pull/2343) Allow
-  ember-release to fail ([@candunaj])
-- [mainmatter/ember-simple-auth]
-  [#2342](https://github.com/mainmatter/ember-simple-auth/pull/2342) Fixed 3
-  readonly tests. ([@candunaj])
-- [mainmatter/ember-simple-auth]
-  [#2353](https://github.com/mainmatter/ember-simple-auth/pull/2353) Fix
-  ember-release + ember-beta build ([@marcoow])
-
-- [empress/empress-blog-casper-template]
-  [#50](https://github.com/empress/empress-blog-casper-template/pull/50) remove
-  {{link-to}} calls using positional arguments ([@mansona])
-- [empress/empress-blog]
-  [#150](https://github.com/empress/empress-blog/pull/150) update
-  ember-body-class ([@mansona])
-- [empress/broccoli-static-site-json]
-  [#64](https://github.com/empress/broccoli-static-site-json/pull/64) Support
-  toc yaml ([@mansona])
-
-- [mansona/ember-body-class]
-  [#45](https://github.com/mansona/ember-body-class/pull/45) fix
-  ember-body-class for fastboot initial render ([@mansona])
-
-- [ember-learn/guides-source]
-  [#1758](https://github.com/ember-learn/guides-source/pull/1758) Replaces
-  EmberArray with tracked property in "Looping through lists" ([@locks])
-- [ember-learn/guides-source]
-  [#1753](https://github.com/ember-learn/guides-source/pull/1753) Ember 4.0
-  preparation ([@locks])
-
-- [emberjs/ember-string]
-  [#309](https://github.com/emberjs/ember-string/pull/309) Fix deprecated import
-  path ([@turbo87])
-- [emberjs/ember-string]
-  [#308](https://github.com/emberjs/ember-string/pull/308) Backport TravisCI to
-  GitHub Actions migration ([@turbo87])
-- [emberjs/ember-string]
-  [#310](https://github.com/emberjs/ember-string/pull/310) Backport release-it
-  integration ([@turbo87])
-
-- [mainmatter/ember-error-route]
-  [#27](https://github.com/mainmatter/ember-error-route/pull/27) Add support for
-  custom rootURL values ([@turbo87])
-- [mainmatter/ember-error-route]
-  [#26](https://github.com/mainmatter/ember-error-route/pull/26) CI: Add deploy
-  job ([@turbo87])
-- [mainmatter/ember-error-route]
-  [#29](https://github.com/mainmatter/ember-error-route/pull/29) package.json:
-  Declare demoURL for EmberObserver ([@turbo87])
-- [mainmatter/ember-error-route]
-  [#28](https://github.com/mainmatter/ember-error-route/pull/29) GitHub Pages:
-  Migrate to locationType: history ([@turbo87])
-
-- [ember-cli/ember-exam]
-  [#787](https://github.com/ember-cli/ember-exam/pull/787) ember-try: Fix mocha
-  scenarios ([@turbo87])
-- [ember-cli/ember-exam]
-  [#775](https://github.com/ember-cli/ember-exam/pull/775) Delete unused
-  herp-derp component ([@turbo87])
-- [ember-cli/ember-exam]
-  [#774](https://github.com/ember-cli/ember-exam/pull/774) Migrate dummy app
-  templates to use angle bracket invocation syntax ([@turbo87])
-- [ember-cli/ember-exam]
-  [#769](https://github.com/ember-cli/ember-exam/pull/769) Drop support for
-  Ember 3.19 and below ([@turbo87])
-- [ember-cli/ember-exam]
-  [#768](https://github.com/ember-cli/ember-exam/pull/768) Upgrade
-  ember-cli-addon-docs dependency ([@turbo87])
-- [ember-cli/ember-exam]
-  [#766](https://github.com/ember-cli/ember-exam/pull/766) CI: Disable failing
-  ember-release scenario ([@turbo87])
-- [ember-cli/ember-exam]
-  [#813](https://github.com/ember-cli/ember-exam/pull/813) Use
-  assert.strictEqual() instead of assert.equal() ([@turbo87])
+- [mainmatter/ember-promise-modals] [#500](https://github.com/mainmatter/ember-promise-modals/pull/500) Specify octane edition in package.json & add missing optional features ([@nickschot])
+- [mainmatter/ember-promise-modals] [#499](https://github.com/mainmatter/ember-promise-modals/pull/499) Update ember-release scenario to use auto-import v2 ([@nickschot])
+
+- [nickschot/ember-mobile-menu] [#216](https://github.com/nickschot/ember-mobile-menu/pull/216) add ember-keyboard v7 resolution to fix ember 4+ CI ([@nickschot])
+
+- [mainmatter/ember-intl-analyzer] [#447](https://github.com/mainmatter/ember-intl-analyzer/pull/447) Add additional guard to check if at the top of the parent tree and tests ([@mikek2252])
+
+- [mansona/ember-cli-notifications] [#328](https://github.com/mansona/ember-cli-notifications/pull/328) Breaking: Update container component ([@pichfl])
+- [mansona/ember-cli-notifications] [#326](https://github.com/mansona/ember-cli-notifications/pull/326) BREAKING: Remove obsolete equals helper ([@pichfl])
+- [mansona/ember-cli-notifications] [#325](https://github.com/mansona/ember-cli-notifications/pull/325) Breaking: Modernize and improve notification message component ([@pichfl])
+- [mansona/ember-cli-notifications] [#324](https://github.com/mansona/ember-cli-notifications/pull/324) Replace overridable icon paths with overridable icon components ([@pichfl])
+- [mansona/ember-cli-notifications] [#327](https://github.com/mansona/ember-cli-notifications/pull/327) move to field-guide ([@mansona])
+
+- [empress/ember-cli-showdown] [#109](https://github.com/empress/ember-cli-showdown/pull/109) Add some basic Fastboot testing ([@mansona])
+- [empress/ember-cli-showdown] [#108](https://github.com/empress/ember-cli-showdown/pull/108) feat: Import htmlSafe from @ember/template, not @ember/string. ([@mansona])
+
+- [mainmatter/ember-simple-auth] [#2350](https://github.com/mainmatter/ember-simple-auth/pull/2350) Upgrade to qunit 5 ([@candunaj])
+- [mainmatter/ember-simple-auth] [#2349](https://github.com/mainmatter/ember-simple-auth/pull/2349) Fixed failing unit test - invalidate call revoke endpoint twice. Unit test did not validate it correctly. ([@candunaj])
+- [mainmatter/ember-simple-auth] [#2348](https://github.com/mainmatter/ember-simple-auth/pull/2348) Fixed quietly failing unit test because server returned nothing ([@candunaj])
+- [mainmatter/ember-simple-auth] [#2345](https://github.com/mainmatter/ember-simple-auth/pull/2345) Fixed failing unit test - ember/object get function was removed from source code so I have changed unit test accordingly ([@candunaj])
+- [mainmatter/ember-simple-auth] [#2344](https://github.com/mainmatter/ember-simple-auth/pull/2344) In some tests was thrown undefined. ([@candunaj])
+- [mainmatter/ember-simple-auth] [#2343](https://github.com/mainmatter/ember-simple-auth/pull/2343) Allow ember-release to fail ([@candunaj])
+- [mainmatter/ember-simple-auth] [#2342](https://github.com/mainmatter/ember-simple-auth/pull/2342) Fixed 3 readonly tests. ([@candunaj])
+- [mainmatter/ember-simple-auth] [#2353](https://github.com/mainmatter/ember-simple-auth/pull/2353) Fix ember-release + ember-beta build ([@marcoow])
+
+- [empress/empress-blog-casper-template] [#50](https://github.com/empress/empress-blog-casper-template/pull/50) remove {{link-to}} calls using positional arguments ([@mansona])
+- [empress/empress-blog] [#150](https://github.com/empress/empress-blog/pull/150) update ember-body-class ([@mansona])
+- [empress/broccoli-static-site-json] [#64](https://github.com/empress/broccoli-static-site-json/pull/64) Support toc yaml ([@mansona])
+
+- [mansona/ember-body-class] [#45](https://github.com/mansona/ember-body-class/pull/45) fix ember-body-class for fastboot initial render ([@mansona])
+
+- [ember-learn/guides-source] [#1758](https://github.com/ember-learn/guides-source/pull/1758) Replaces EmberArray with tracked property in "Looping through lists" ([@locks])
+- [ember-learn/guides-source] [#1753](https://github.com/ember-learn/guides-source/pull/1753) Ember 4.0 preparation ([@locks])
+
+- [emberjs/ember-string] [#309](https://github.com/emberjs/ember-string/pull/309) Fix deprecated import path ([@turbo87])
+- [emberjs/ember-string] [#308](https://github.com/emberjs/ember-string/pull/308) Backport TravisCI to GitHub Actions migration ([@turbo87])
+- [emberjs/ember-string] [#310](https://github.com/emberjs/ember-string/pull/310) Backport release-it integration ([@turbo87])
+
+- [mainmatter/ember-error-route] [#27](https://github.com/mainmatter/ember-error-route/pull/27) Add support for custom rootURL values ([@turbo87])
+- [mainmatter/ember-error-route] [#26](https://github.com/mainmatter/ember-error-route/pull/26) CI: Add deploy job ([@turbo87])
+- [mainmatter/ember-error-route] [#29](https://github.com/mainmatter/ember-error-route/pull/29) package.json: Declare demoURL for EmberObserver ([@turbo87])
+- [mainmatter/ember-error-route] [#28](https://github.com/mainmatter/ember-error-route/pull/29) GitHub Pages: Migrate to locationType: history ([@turbo87])
+
+- [ember-cli/ember-exam] [#787](https://github.com/ember-cli/ember-exam/pull/787) ember-try: Fix mocha scenarios ([@turbo87])
+- [ember-cli/ember-exam] [#775](https://github.com/ember-cli/ember-exam/pull/775) Delete unused herp-derp component ([@turbo87])
+- [ember-cli/ember-exam] [#774](https://github.com/ember-cli/ember-exam/pull/774) Migrate dummy app templates to use angle bracket invocation syntax ([@turbo87])
+- [ember-cli/ember-exam] [#769](https://github.com/ember-cli/ember-exam/pull/769) Drop support for Ember 3.19 and below ([@turbo87])
+- [ember-cli/ember-exam] [#768](https://github.com/ember-cli/ember-exam/pull/768) Upgrade ember-cli-addon-docs dependency ([@turbo87])
+- [ember-cli/ember-exam] [#766](https://github.com/ember-cli/ember-exam/pull/766) CI: Disable failing ember-release scenario ([@turbo87])
+- [ember-cli/ember-exam] [#813](https://github.com/ember-cli/ember-exam/pull/813) Use assert.strictEqual() instead of assert.equal() ([@turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4284](https://github.com/rust-lang/crates.io/pull/4284) crate.version: Fix
-  downloads alias ([@turbo87])
-- [rust-lang/crates.io]
-  [#4276](https://github.com/rust-lang/crates.io/pull/4276) renovate: Adjust
-  node package handling config ([@turbo87])
-- [rust-lang/crates.io]
-  [#4268](https://github.com/rust-lang/crates.io/pull/4268) Update
-  ember-cli-fastboot to v3.2.0-beta.5 ([@turbo87])
-- [rust-lang/crates.io]
-  [#4267](https://github.com/rust-lang/crates.io/pull/4267) Update Node.js to
-  v16.13.1 ([@turbo87])
-- [rust-lang/crates.io]
-  [#4266](https://github.com/rust-lang/crates.io/pull/4266) CrateSidebar: Fix
-  class name ([@turbo87])
-- [rust-lang/crates.io]
-  [#4265](https://github.com/rust-lang/crates.io/pull/4265) models/version: Add
-  missing fetch import ([@turbo87])
-- [rust-lang/crates.io]
-  [#4264](https://github.com/rust-lang/crates.io/pull/4264) controllers/index:
-  Fix fetchData() return value ([@turbo87])
-- [rust-lang/crates.io]
-  [#4261](https://github.com/rust-lang/crates.io/pull/4261) Unpin and update
-  transitive @ember/string dependency ([@turbo87])
-- [rust-lang/crates.io]
-  [#4257](https://github.com/rust-lang/crates.io/pull/4257) utils/license: Add
-  support for parentheses ([@turbo87])
-- [rust-lang/crates.io]
-  [#4256](https://github.com/rust-lang/crates.io/pull/4256) Pin @ember/string
-  dependency to v3.0.0 ([@turbo87])
+- [rust-lang/crates.io] [#4284](https://github.com/rust-lang/crates.io/pull/4284) crate.version: Fix downloads alias ([@turbo87])
+- [rust-lang/crates.io] [#4276](https://github.com/rust-lang/crates.io/pull/4276) renovate: Adjust node package handling config ([@turbo87])
+- [rust-lang/crates.io] [#4268](https://github.com/rust-lang/crates.io/pull/4268) Update ember-cli-fastboot to v3.2.0-beta.5 ([@turbo87])
+- [rust-lang/crates.io] [#4267](https://github.com/rust-lang/crates.io/pull/4267) Update Node.js to v16.13.1 ([@turbo87])
+- [rust-lang/crates.io] [#4266](https://github.com/rust-lang/crates.io/pull/4266) CrateSidebar: Fix class name ([@turbo87])
+- [rust-lang/crates.io] [#4265](https://github.com/rust-lang/crates.io/pull/4265) models/version: Add missing fetch import ([@turbo87])
+- [rust-lang/crates.io] [#4264](https://github.com/rust-lang/crates.io/pull/4264) controllers/index: Fix fetchData() return value ([@turbo87])
+- [rust-lang/crates.io] [#4261](https://github.com/rust-lang/crates.io/pull/4261) Unpin and update transitive @ember/string dependency ([@turbo87])
+- [rust-lang/crates.io] [#4257](https://github.com/rust-lang/crates.io/pull/4257) utils/license: Add support for parentheses ([@turbo87])
+- [rust-lang/crates.io] [#4256](https://github.com/rust-lang/crates.io/pull/4256) Pin @ember/string dependency to v3.0.0 ([@turbo87])
 
 ## Mainmatter playbook
 
-- [mainmatter/playbook] [#173](https://github.com/mainmatter/playbook/pull/173)
-  add metric systems to the list of engineering tools ([@oscard0m])
+- [mainmatter/playbook] [#173](https://github.com/mainmatter/playbook/pull/173) add metric systems to the list of engineering tools ([@oscard0m])
 
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io/
 [ember-cli/ember-cli]: https://github.com/ember-cli/ember-cli/
@@ -206,22 +89,16 @@
 [emberjs/ember-string]: https://github.com/emberjs/ember-string/
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source/
 [mansona/ember-body-class]: https://github.com/mansona/ember-body-class/
-[empress/broccoli-static-site-json]:
-  https://github.com/empress/broccoli-static-site-json/
+[empress/broccoli-static-site-json]: https://github.com/empress/broccoli-static-site-json/
 [empress/empress-blog]: https://github.com/empress/empress-blog/
-[empress/empress-blog-casper-template]:
-  https://github.com/empress/empress-blog-casper-template/
+[empress/empress-blog-casper-template]: https://github.com/empress/empress-blog-casper-template/
 [empress/ember-cli-showdown]: https://github.com/empress/ember-cli-showdown
-[mansona/ember-cli-notifications]:
-  https://github.com/mansona/ember-cli-notifications
-[mainmatter/ember-intl-analyzer]:
-  https://github.com/mainmatter/ember-intl-analyzer
+[mansona/ember-cli-notifications]: https://github.com/mansona/ember-cli-notifications
+[mainmatter/ember-intl-analyzer]: https://github.com/mainmatter/ember-intl-analyzer
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [oscard0m/npm-snapshot]: https://github.com/oscard0m/npm-snapshot
-[commitizen/cz-conventional-changelog]:
-  https://github.com/commitizen/cz-conventional-changelog
+[commitizen/cz-conventional-changelog]: https://github.com/commitizen/cz-conventional-changelog
 [mansona/chris.manson.ie]: https://github.com/mansona/chris.manson.ie
 [@turbo87]: https://github.com/Turbo87/
 [@pichfl]: https://github.com/pichfl/
diff --git a/src/twios/2022-01-24.md b/src/twios/2022-01-24.md
index f2ec8c2bfc..41a3225267 100644
--- a/src/twios/2022-01-24.md
+++ b/src/twios/2022-01-24.md
@@ -1,255 +1,119 @@
 ## Rust
 
-- [aprs-parser-rs] [#21](https://github.com/Turbo87/aprs-parser-rs/pull/21) CI:
-  Enable colored cargo output ([@turbo87])
-- [aprs-parser-rs] [#20](https://github.com/Turbo87/aprs-parser-rs/pull/20)
-  lonlat: Extract Latitude and Longitude structs ([@turbo87])
-- [aprs-parser-rs] [#15](https://github.com/Turbo87/aprs-parser-rs/pull/15) Add
-  Cargo.lock file ([@turbo87])
-- [aprs-parser-rs] [#14](https://github.com/Turbo87/aprs-parser-rs/pull/14)
-  Decrease MSRV to v1.38.0 ([@turbo87])
-- [aprs-parser-rs] [#13](https://github.com/Turbo87/aprs-parser-rs/pull/13)
-  Replace failure with thiserror ([@turbo87])
-- [aprs-parser-rs] [#12](https://github.com/Turbo87/aprs-parser-rs/pull/12)
-  cargo clippy ([@turbo87])
-- [aprs-parser-rs] [#11](https://github.com/Turbo87/aprs-parser-rs/pull/11)
-  cargo fmt ([@turbo87])
-- [aprs-parser-rs] [#10](https://github.com/Turbo87/aprs-parser-rs/pull/10)
-  Improve CI config ([@turbo87])
-- [aprs-parser-rs] [#9](https://github.com/Turbo87/aprs-parser-rs/pull/9)
-  Migrate from TravisCI to GitHub Actions ([@turbo87])
-
-- [rust-lang/cargo] [#10239](https://github.com/rust-lang/cargo/pull/10239)
-  timings: Fix tick mark alignment ([@turbo87])
+- [aprs-parser-rs] [#21](https://github.com/Turbo87/aprs-parser-rs/pull/21) CI: Enable colored cargo output ([@turbo87])
+- [aprs-parser-rs] [#20](https://github.com/Turbo87/aprs-parser-rs/pull/20) lonlat: Extract Latitude and Longitude structs ([@turbo87])
+- [aprs-parser-rs] [#15](https://github.com/Turbo87/aprs-parser-rs/pull/15) Add Cargo.lock file ([@turbo87])
+- [aprs-parser-rs] [#14](https://github.com/Turbo87/aprs-parser-rs/pull/14) Decrease MSRV to v1.38.0 ([@turbo87])
+- [aprs-parser-rs] [#13](https://github.com/Turbo87/aprs-parser-rs/pull/13) Replace failure with thiserror ([@turbo87])
+- [aprs-parser-rs] [#12](https://github.com/Turbo87/aprs-parser-rs/pull/12) cargo clippy ([@turbo87])
+- [aprs-parser-rs] [#11](https://github.com/Turbo87/aprs-parser-rs/pull/11) cargo fmt ([@turbo87])
+- [aprs-parser-rs] [#10](https://github.com/Turbo87/aprs-parser-rs/pull/10) Improve CI config ([@turbo87])
+- [aprs-parser-rs] [#9](https://github.com/Turbo87/aprs-parser-rs/pull/9) Migrate from TravisCI to GitHub Actions ([@turbo87])
+
+- [rust-lang/cargo] [#10239](https://github.com/rust-lang/cargo/pull/10239) timings: Fix tick mark alignment ([@turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4465](https://github.com/rust-lang/crates.io/pull/4465) Use embroider build
-  system by default ([@turbo87])
-- [rust-lang/crates.io]
-  [#4464](https://github.com/rust-lang/crates.io/pull/4464) embroider: Remove
-  obsolete ember-get-config workaround ([@turbo87])
-- [rust-lang/crates.io]
-  [#4460](https://github.com/rust-lang/crates.io/pull/4460) Use Volta to pin
-  Node.js and yarn versions ([@turbo87])
-- [rust-lang/crates.io]
-  [#4440](https://github.com/rust-lang/crates.io/pull/4440) Use format arguments
-  capture feature ([@turbo87])
-- [rust-lang/crates.io]
-  [#4398](https://github.com/rust-lang/crates.io/pull/4398) Replace timekeeper
-  with @sinonjs/fake-timers ([@turbo87])
-- [rust-lang/crates.io]
-  [#4397](https://github.com/rust-lang/crates.io/pull/4397) Remove obsolete
-  /authorize/github route ([@turbo87])
-- [rust-lang/crates.io]
-  [#4396](https://github.com/rust-lang/crates.io/pull/4396) Extract
-  cargo-registry-index package ([@turbo87])
-- [rust-lang/crates.io]
-  [#4384](https://github.com/rust-lang/crates.io/pull/4384) tests: Extract
-  UpstreamIndex struct ([@turbo87])
-- [rust-lang/crates.io]
-  [#4382](https://github.com/rust-lang/crates.io/pull/4382) Add support for
-  keyword:cli and category:no-std search filters ([@turbo87])
-- [rust-lang/crates.io]
-  [#4381](https://github.com/rust-lang/crates.io/pull/4381) tests/search: Add
-  test case for query parameter forwarding ([@turbo87])
-- [rust-lang/crates.io]
-  [#4380](https://github.com/rust-lang/crates.io/pull/4380) mirage: Replace
-  withMeta() utility function with object spread operator ([@turbo87])
-- [rust-lang/crates.io]
-  [#4379](https://github.com/rust-lang/crates.io/pull/4379) search: Show "Exact
-  Match" as regular search result ([@turbo87])
-- [rust-lang/crates.io]
-  [#4377](https://github.com/rust-lang/crates.io/pull/4377) DownloadGraph: Fix
-  extra property access ([@turbo87])
-- [rust-lang/crates.io]
-  [#4368](https://github.com/rust-lang/crates.io/pull/4368) Replace "Toggle
-  Design" button with new /settings/appearance route ([@turbo87])
-- [rust-lang/crates.io]
-  [#4367](https://github.com/rust-lang/crates.io/pull/4367) Replace
-  ember-set-body-class addon ([@turbo87])
-- [rust-lang/crates.io]
-  [#4366](https://github.com/rust-lang/crates.io/pull/4366) Repository: Use
-  anyhow errors as return types ([@turbo87])
-- [rust-lang/crates.io]
-  [#4365](https://github.com/rust-lang/crates.io/pull/4365) Repository: Extract
-  run_command() function ([@turbo87])
-- [rust-lang/crates.io]
-  [#4364](https://github.com/rust-lang/crates.io/pull/4364) Repository: Add doc
-  comments ([@turbo87])
-- [rust-lang/crates.io]
-  [#4363](https://github.com/rust-lang/crates.io/pull/4363) Repository: Extract
-  write_temporary_ssh_key() function ([@turbo87])
-- [rust-lang/crates.io]
-  [#4362](https://github.com/rust-lang/crates.io/pull/4362) Header: Remove
-  obsolete "Docs" dropdown ([@turbo87])
-- [rust-lang/crates.io]
-  [#4361](https://github.com/rust-lang/crates.io/pull/4361) Use
-  postcss-custom-media plugin for breakpoints ([@turbo87])
-- [rust-lang/crates.io]
-  [#4360](https://github.com/rust-lang/crates.io/pull/4360) Remove "Filter by
-  letter" feature ([@turbo87])
-- [rust-lang/crates.io]
-  [#4359](https://github.com/rust-lang/crates.io/pull/4359) Improve search bar
-  styling ([@turbo87])
-- [rust-lang/crates.io]
-  [#4357](https://github.com/rust-lang/crates.io/pull/4357) Improve "API Tokens"
-  settings page ([@turbo87])
-- [rust-lang/crates.io]
-  [#4356](https://github.com/rust-lang/crates.io/pull/4356) Remove duplicate
-  GitHub logo SVG ([@turbo87])
-- [rust-lang/crates.io]
-  [#4351](https://github.com/rust-lang/crates.io/pull/4351) renovate: Disable
-  dependencyDashboardApproval option ([@turbo87])
-- [rust-lang/crates.io]
-  [#4316](https://github.com/rust-lang/crates.io/pull/4316) Improve database
-  fallbacks ([@turbo87])
-- [rust-lang/crates.io]
-  [#4315](https://github.com/rust-lang/crates.io/pull/4315) Show "This page
-  requires authentication" page for protected routes if unauthenticated
-  ([@turbo87])
-- [rust-lang/crates.io]
-  [#4314](https://github.com/rust-lang/crates.io/pull/4314) catch-all: Fix
-  broken "Go back" and "Reload" links ([@turbo87])
-- [rust-lang/crates.io]
-  [#4311](https://github.com/rust-lang/crates.io/pull/4311) Adjust /me
-  redirection to /settings/tokens ([@turbo87])
+- [rust-lang/crates.io] [#4465](https://github.com/rust-lang/crates.io/pull/4465) Use embroider build system by default ([@turbo87])
+- [rust-lang/crates.io] [#4464](https://github.com/rust-lang/crates.io/pull/4464) embroider: Remove obsolete ember-get-config workaround ([@turbo87])
+- [rust-lang/crates.io] [#4460](https://github.com/rust-lang/crates.io/pull/4460) Use Volta to pin Node.js and yarn versions ([@turbo87])
+- [rust-lang/crates.io] [#4440](https://github.com/rust-lang/crates.io/pull/4440) Use format arguments capture feature ([@turbo87])
+- [rust-lang/crates.io] [#4398](https://github.com/rust-lang/crates.io/pull/4398) Replace timekeeper with @sinonjs/fake-timers ([@turbo87])
+- [rust-lang/crates.io] [#4397](https://github.com/rust-lang/crates.io/pull/4397) Remove obsolete /authorize/github route ([@turbo87])
+- [rust-lang/crates.io] [#4396](https://github.com/rust-lang/crates.io/pull/4396) Extract cargo-registry-index package ([@turbo87])
+- [rust-lang/crates.io] [#4384](https://github.com/rust-lang/crates.io/pull/4384) tests: Extract UpstreamIndex struct ([@turbo87])
+- [rust-lang/crates.io] [#4382](https://github.com/rust-lang/crates.io/pull/4382) Add support for keyword:cli and category:no-std search filters ([@turbo87])
+- [rust-lang/crates.io] [#4381](https://github.com/rust-lang/crates.io/pull/4381) tests/search: Add test case for query parameter forwarding ([@turbo87])
+- [rust-lang/crates.io] [#4380](https://github.com/rust-lang/crates.io/pull/4380) mirage: Replace withMeta() utility function with object spread operator ([@turbo87])
+- [rust-lang/crates.io] [#4379](https://github.com/rust-lang/crates.io/pull/4379) search: Show "Exact Match" as regular search result ([@turbo87])
+- [rust-lang/crates.io] [#4377](https://github.com/rust-lang/crates.io/pull/4377) DownloadGraph: Fix extra property access ([@turbo87])
+- [rust-lang/crates.io] [#4368](https://github.com/rust-lang/crates.io/pull/4368) Replace "Toggle Design" button with new /settings/appearance route ([@turbo87])
+- [rust-lang/crates.io] [#4367](https://github.com/rust-lang/crates.io/pull/4367) Replace ember-set-body-class addon ([@turbo87])
+- [rust-lang/crates.io] [#4366](https://github.com/rust-lang/crates.io/pull/4366) Repository: Use anyhow errors as return types ([@turbo87])
+- [rust-lang/crates.io] [#4365](https://github.com/rust-lang/crates.io/pull/4365) Repository: Extract run_command() function ([@turbo87])
+- [rust-lang/crates.io] [#4364](https://github.com/rust-lang/crates.io/pull/4364) Repository: Add doc comments ([@turbo87])
+- [rust-lang/crates.io] [#4363](https://github.com/rust-lang/crates.io/pull/4363) Repository: Extract write_temporary_ssh_key() function ([@turbo87])
+- [rust-lang/crates.io] [#4362](https://github.com/rust-lang/crates.io/pull/4362) Header: Remove obsolete "Docs" dropdown ([@turbo87])
+- [rust-lang/crates.io] [#4361](https://github.com/rust-lang/crates.io/pull/4361) Use postcss-custom-media plugin for breakpoints ([@turbo87])
+- [rust-lang/crates.io] [#4360](https://github.com/rust-lang/crates.io/pull/4360) Remove "Filter by letter" feature ([@turbo87])
+- [rust-lang/crates.io] [#4359](https://github.com/rust-lang/crates.io/pull/4359) Improve search bar styling ([@turbo87])
+- [rust-lang/crates.io] [#4357](https://github.com/rust-lang/crates.io/pull/4357) Improve "API Tokens" settings page ([@turbo87])
+- [rust-lang/crates.io] [#4356](https://github.com/rust-lang/crates.io/pull/4356) Remove duplicate GitHub logo SVG ([@turbo87])
+- [rust-lang/crates.io] [#4351](https://github.com/rust-lang/crates.io/pull/4351) renovate: Disable dependencyDashboardApproval option ([@turbo87])
+- [rust-lang/crates.io] [#4316](https://github.com/rust-lang/crates.io/pull/4316) Improve database fallbacks ([@turbo87])
+- [rust-lang/crates.io] [#4315](https://github.com/rust-lang/crates.io/pull/4315) Show "This page requires authentication" page for protected routes if unauthenticated ([@turbo87])
+- [rust-lang/crates.io] [#4314](https://github.com/rust-lang/crates.io/pull/4314) catch-all: Fix broken "Go back" and "Reload" links ([@turbo87])
+- [rust-lang/crates.io] [#4311](https://github.com/rust-lang/crates.io/pull/4311) Adjust /me redirection to /settings/tokens ([@turbo87])
 
 ## Ruby
 
-- [rubyforgood/Flaredown]
-  [#571](https://github.com/rubyforgood/Flaredown/pull/571) fix race condition
-  on android with google recapcha ([@mansona])
+- [rubyforgood/Flaredown] [#571](https://github.com/rubyforgood/Flaredown/pull/571) fix race condition on android with google recapcha ([@mansona])
 
 ## Ember.js
 
-- [main/ember-error-route]
-  [#66](https://github.com/mainmatter/ember-error-route/pull/66) Add GitHub
-  project links ([@turbo87])
-- [mainmatter/ember-error-route]
-  [#65](https://github.com/mainmatter/ember-error-route/pull/65) README: Add
-  basic documentation ([@turbo87])
-- [mainmatter/ember-error-route]
-  [#64](https://github.com/mainmatter/ember-error-route/pull/64) Improved
-  styling ([@turbo87])
-- [mainmatter/ember-error-route]
-  [#62](https://github.com/mainmatter/ember-error-route/pull/62) Remove broken
-  colors@1.4.2 subdependency ([@turbo87])
+- [main/ember-error-route] [#66](https://github.com/mainmatter/ember-error-route/pull/66) Add GitHub project links ([@turbo87])
+- [mainmatter/ember-error-route] [#65](https://github.com/mainmatter/ember-error-route/pull/65) README: Add basic documentation ([@turbo87])
+- [mainmatter/ember-error-route] [#64](https://github.com/mainmatter/ember-error-route/pull/64) Improved styling ([@turbo87])
+- [mainmatter/ember-error-route] [#62](https://github.com/mainmatter/ember-error-route/pull/62) Remove broken colors@1.4.2 subdependency ([@turbo87])
 
-- [ember-learn/ember-website]
-  [#887](https://github.com/ember-learn/ember-website/pull/887) Add Ember Europe
-  Tomster ([@marcoow])
-- [ember-learn/ember-website]
-  [#886](https://github.com/ember-learn/ember-website/pull/886) v4.1.0 release
-  ([@locks])
+- [ember-learn/ember-website] [#887](https://github.com/ember-learn/ember-website/pull/887) Add Ember Europe Tomster ([@marcoow])
+- [ember-learn/ember-website] [#886](https://github.com/ember-learn/ember-website/pull/886) v4.1.0 release ([@locks])
 
-- [emberjs/core-notes] [#437](https://github.com/emberjs/core-notes/pull/437)
-  [Learning] January 27th, 2022 ([@locks])
-- [emberjs/core-notes] [#432](https://github.com/emberjs/core-notes/pull/432)
-  [Learning] December 23 meeting ([@locks])
+- [emberjs/core-notes] [#437](https://github.com/emberjs/core-notes/pull/437) [Learning] January 27th, 2022 ([@locks])
+- [emberjs/core-notes] [#432](https://github.com/emberjs/core-notes/pull/432) [Learning] December 23 meeting ([@locks])
 
-- [emberjs/ember-ordered-set]
-  [#46](https://github.com/emberjs/ember-ordered-set/pull/46) Update license
-  file with copyright holders ([@locks])
+- [emberjs/ember-ordered-set] [#46](https://github.com/emberjs/ember-ordered-set/pull/46) Update license file with copyright holders ([@locks])
 
-- [ember-learn/guides-source]
-  [#1766](https://github.com/ember-learn/guides-source/pull/1766) Use service
-  named import instead of inject ([@locks])
-- [ember-learn/guides-source]
-  [#1764](https://github.com/ember-learn/guides-source/pull/1764) v4.1.0
-  ([@locks])
+- [ember-learn/guides-source] [#1766](https://github.com/ember-learn/guides-source/pull/1766) Use service named import instead of inject ([@locks])
+- [ember-learn/guides-source] [#1764](https://github.com/ember-learn/guides-source/pull/1764) v4.1.0 ([@locks])
 
-- [ember-learn/ember-blog]
-  [#1084](https://github.com/ember-learn/ember-blog/pull/1084) Delete
-  .node-version ([@mansona])
-- [ember-learn/ember-blog]
-  [#1082](https://github.com/ember-learn/ember-blog/pull/1082) Update
-  empress-blog template to fix build ([@mansona])
-- [ember-learn/ember-blog]
-  [#1081](https://github.com/ember-learn/ember-blog/pull/1081) Update Github CI
-  ([@mansona])
+- [ember-learn/ember-blog] [#1084](https://github.com/ember-learn/ember-blog/pull/1084) Delete .node-version ([@mansona])
+- [ember-learn/ember-blog] [#1082](https://github.com/ember-learn/ember-blog/pull/1082) Update empress-blog template to fix build ([@mansona])
+- [ember-learn/ember-blog] [#1081](https://github.com/ember-learn/ember-blog/pull/1081) Update Github CI ([@mansona])
 
-- [ember-learn/empress-blog-ember-template]
-  [#118](https://github.com/ember-learn/empress-blog-ember-template/pull/118)
-  simplify github ci ([@mansona])
-- [ember-learn/empress-blog-ember-template]
-  [#117](https://github.com/ember-learn/empress-blog-ember-template/pull/117)
-  Breaking: Drop Node 10 and upgrade Ember ([@mansona])
+- [ember-learn/empress-blog-ember-template] [#118](https://github.com/ember-learn/empress-blog-ember-template/pull/118) simplify github ci ([@mansona])
+- [ember-learn/empress-blog-ember-template] [#117](https://github.com/ember-learn/empress-blog-ember-template/pull/117) Breaking: Drop Node 10 and upgrade Ember ([@mansona])
 
-- [ember-learn/ember-styleguide]
-  [#412](https://github.com/ember-learn/ember-styleguide/pull/412) Breaking:
-  drop support for Node 10, update ember to 3.28, and remove deprecations
-  ([@mansona])
+- [ember-learn/ember-styleguide] [#412](https://github.com/ember-learn/ember-styleguide/pull/412) Breaking: drop support for Node 10, update ember to 3.28, and remove deprecations ([@mansona])
 
-- [empress/field-guide] [#53](https://github.com/empress/field-guide/pull/53)
-  Support Embroider ([@mansona])
-- [empress/field-guide] [#52](https://github.com/empress/field-guide/pull/52)
-  Support Ember 4 ([@mansona])
-- [empress/field-guide] [#51](https://github.com/empress/field-guide/pull/51)
-  bring github ci workflow in line with blueprint and update some dependencies
-  ([@mansona])
+- [empress/field-guide] [#53](https://github.com/empress/field-guide/pull/53) Support Embroider ([@mansona])
+- [empress/field-guide] [#52](https://github.com/empress/field-guide/pull/52) Support Ember 4 ([@mansona])
+- [empress/field-guide] [#51](https://github.com/empress/field-guide/pull/51) bring github ci workflow in line with blueprint and update some dependencies ([@mansona])
 
-- [empress/ember-showdown-prism]
-  [#20](https://github.com/empress/ember-showdown-prism/pull/20) update with
-  ember-cli-update to 3.28 ([@mansona])
-- [empress/ember-showdown-prism]
-  [#19](https://github.com/empress/ember-showdown-prism/pull/19) add a basic
-  test ([@mansona])
-- [empress/ember-showdown-prism]
-  [#18](https://github.com/empress/ember-showdown-prism/pull/18) Breaking: drop
-  Node 10 and unify github ci workflow with blueprint ([@mansona])
+- [empress/ember-showdown-prism] [#20](https://github.com/empress/ember-showdown-prism/pull/20) update with ember-cli-update to 3.28 ([@mansona])
+- [empress/ember-showdown-prism] [#19](https://github.com/empress/ember-showdown-prism/pull/19) add a basic test ([@mansona])
+- [empress/ember-showdown-prism] [#18](https://github.com/empress/ember-showdown-prism/pull/18) Breaking: drop Node 10 and unify github ci workflow with blueprint ([@mansona])
 
-- [emberjs/ember.js] [#19883](https://github.com/emberjs/ember.js/pull/19883)
-  [BUGFIX beta] Fix URL for deprecation deprecate-auto-location ([@locks])
+- [emberjs/ember.js] [#19883](https://github.com/emberjs/ember.js/pull/19883) [BUGFIX beta] Fix URL for deprecation deprecate-auto-location ([@locks])
 
-- [Authmaker/authmaker-ember-simple-auth]
-  [#33](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/33) Update
-  Ember to 3.20 ([@mansona])
-- [Authmaker/authmaker-ember-simple-auth]
-  [#32](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/32)
-  Breaking: drop support for Node < 12 and move from Travis to Github CI
-  ([@mansona])
-- [Authmaker/authmaker-ember-simple-auth]
-  [#31](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/31) Add
-  tests ([@mansona])
+- [Authmaker/authmaker-ember-simple-auth] [#33](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/33) Update Ember to 3.20 ([@mansona])
+- [Authmaker/authmaker-ember-simple-auth] [#32](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/32) Breaking: drop support for Node < 12 and move from Travis to Github CI ([@mansona])
+- [Authmaker/authmaker-ember-simple-auth] [#31](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/31) Add tests ([@mansona])
 
-- [ember-cli/ember-cli]
-  [#9760](https://github.com/ember-cli/ember-cli/pull/9760) Add timeout-minutes
-  to github CI jobs ([@mansona])
+- [ember-cli/ember-cli] [#9760](https://github.com/ember-cli/ember-cli/pull/9760) Add timeout-minutes to github CI jobs ([@mansona])
 
 ## JavaScript
 
-- [mansona/lint-to-the-future-eslint]
-  [#3](https://github.com/mansona/lint-to-the-future-eslint/pull/3) Fix issue
-  with caret dependency of eslint and add a test to verify ignore works
-  ([@mansona])
-- [TelemetryDeck/JavaScriptSDK]
-  [#2](https://github.com/TelemetryDeck/JavaScriptSDK/pull/2) Allow loading of
-  script to be deferred ([@pichfl])
-- [TelemetryDeck/JavaScriptSDK]
-  [#1](https://github.com/TelemetryDeck/JavaScriptSDK/pull/1) Initial release
-  ([@pichfl])
+- [mansona/lint-to-the-future-eslint] [#3](https://github.com/mansona/lint-to-the-future-eslint/pull/3) Fix issue with caret dependency of eslint and add a test to verify ignore works ([@mansona])
+- [TelemetryDeck/JavaScriptSDK] [#2](https://github.com/TelemetryDeck/JavaScriptSDK/pull/2) Allow loading of script to be deferred ([@pichfl])
+- [TelemetryDeck/JavaScriptSDK] [#1](https://github.com/TelemetryDeck/JavaScriptSDK/pull/1) Initial release ([@pichfl])
 
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io/
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io/
 [rubyforgood/flaredown]: https://github.com/rubyforgood/Flaredown/
-[mansona/lint-to-the-future-eslint]:
-  https://github.com/mansona/lint-to-the-future-eslint/
+[mansona/lint-to-the-future-eslint]: https://github.com/mansona/lint-to-the-future-eslint/
 [telemetrydeck/javascriptsdk]: https://github.com/TelemetryDeck/JavaScriptSDK/
 [rust-lang/cargo]: https://github.com/rust-lang/cargo/
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website/
 [emberjs/core-notes]: https://github.com/emberjs/core-notes/
 [emberjs/ember-ordered-set]: https://github.com/emberjs/ember-ordered-set/
 [ember-learn/ember-blog]: https://github.com/ember-learn/ember-blog/
-[ember-learn/empress-blog-ember-template]:
-  https://github.com/ember-learn/empress-blog-ember-template/
+[ember-learn/empress-blog-ember-template]: https://github.com/ember-learn/empress-blog-ember-template/
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide/
 [empress/ember-showdown-prism]: https://github.com/empress/ember-showdown-prism/
 [empress/field-guide]: https://github.com/empress/field-guide/
 [emberjs/ember.js]: https://github.com/emberjs/ember.js/
-[authmaker/authmaker-ember-simple-auth]:
-  https://github.com/Authmaker/authmaker-ember-simple-auth/
+[authmaker/authmaker-ember-simple-auth]: https://github.com/Authmaker/authmaker-ember-simple-auth/
 [aprs-parser-rs]: https://github.com/aprs-parser-rs/
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth/
 [mainmatter/playbook]: https://github.com/mainmatter/playbook/
@@ -258,22 +122,16 @@
 [emberjs/ember-string]: https://github.com/emberjs/ember-string/
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source/
 [mansona/ember-body-class]: https://github.com/mansona/ember-body-class/
-[empress/broccoli-static-site-json]:
-  https://github.com/empress/broccoli-static-site-json/
+[empress/broccoli-static-site-json]: https://github.com/empress/broccoli-static-site-json/
 [empress/empress-blog]: https://github.com/empress/empress-blog/
-[empress/empress-blog-casper-template]:
-  https://github.com/empress/empress-blog-casper-template/
+[empress/empress-blog-casper-template]: https://github.com/empress/empress-blog-casper-template/
 [empress/ember-cli-showdown]: https://github.com/empress/ember-cli-showdown
-[mansona/ember-cli-notifications]:
-  https://github.com/mansona/ember-cli-notifications
-[mainmatter/ember-intl-analyzer]:
-  https://github.com/mainmatter/ember-intl-analyzer
+[mansona/ember-cli-notifications]: https://github.com/mansona/ember-cli-notifications
+[mainmatter/ember-intl-analyzer]: https://github.com/mainmatter/ember-intl-analyzer
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [oscard0m/npm-snapshot]: https://github.com/oscard0m/npm-snapshot
-[commitizen/cz-conventional-changelog]:
-  https://github.com/commitizen/cz-conventional-changelog
+[commitizen/cz-conventional-changelog]: https://github.com/commitizen/cz-conventional-changelog
 [mansona/chris.manson.ie]: https://github.com/mansona/chris.manson.ie
 [@turbo87]: https://github.com/Turbo87/
 [@pichfl]: https://github.com/pichfl/
diff --git a/src/twios/2022-02-07.md b/src/twios/2022-02-07.md
index a93ee17746..ec421eab2c 100644
--- a/src/twios/2022-02-07.md
+++ b/src/twios/2022-02-07.md
@@ -1,162 +1,72 @@
 ## Atom
 
-- [atom/atom] [#23540](https://github.com/atom/atom/pull/23540) Bump Electron
-  Version ([@mansona])
-- [atom/keyboard-layout] [#63](https://github.com/atom/keyboard-layout/pull/63)
-  Update nan ([@mansona])
-- [mansona/fuzzy-native] [#1](https://github.com/mansona/fuzzy-native/pull/1)
-  move from travis to github ci ([@mansona])
-- [mansona/keyboard-layout]
-  [#1](https://github.com/mansona/keyboard-layout/pull/1) Gyp test ([@mansona])
-- [mansona/node-pathwatcher]
-  [#1](https://github.com/mansona/node-pathwatcher/pull/1) Configure
-  node-pre-gyp ([@mansona])
+- [atom/atom] [#23540](https://github.com/atom/atom/pull/23540) Bump Electron Version ([@mansona])
+- [atom/keyboard-layout] [#63](https://github.com/atom/keyboard-layout/pull/63) Update nan ([@mansona])
+- [mansona/fuzzy-native] [#1](https://github.com/mansona/fuzzy-native/pull/1) move from travis to github ci ([@mansona])
+- [mansona/keyboard-layout] [#1](https://github.com/mansona/keyboard-layout/pull/1) Gyp test ([@mansona])
+- [mansona/node-pathwatcher] [#1](https://github.com/mansona/node-pathwatcher/pull/1) Configure node-pre-gyp ([@mansona])
 
 ## Ember.js
 
-- [Authmaker/authmaker-ember-simple-auth]
-  [#35](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/35) Fix
-  deprecations and support Ember 4.0 ([@mansona])
-- [Authmaker/authmaker-ember-simple-auth]
-  [#34](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/34)
-  Breaking: drop support for Ember < 3.16 and update with ember-cli-update
-  ([@mansona])
-- [ember-cli/ember-cli]
-  [#9778](https://github.com/ember-cli/ember-cli/pull/9778) Prune lodash
-  dependencies ([@locks])
-- [ember-cli/ember-cli]
-  [#9769](https://github.com/ember-cli/ember-cli/pull/9769) Update markdown-it
-  to v12.3.2 to address vulnerabiliity ([@locks])
-- [ember-engines/ember-engines]
-  [#798](https://github.com/ember-engines/ember-engines/pull/798) Ember 4
-  compatibility ([@BobrImperator])
-- [ember-engines/ember-engines]
-  [#797](https://github.com/ember-engines/ember-engines/pull/797) Update to
-  ember qunit 5 ([@BobrImperator])
-- [ember-learn/deprecation-app]
-  [#1074](https://github.com/ember-learn/deprecation-app/pull/1074) Fix broken
-  markdown links due to formatting ([@locks])
-- [ember-learn/deprecation-app]
-  [#1069](https://github.com/ember-learn/deprecation-app/pull/1069) Improving
-  doc for deprecation "deprecated-run-loop-and-computed-dot-a… ([@locks])
-- [ember-learn/ember-api-docs]
-  [#791](https://github.com/ember-learn/ember-api-docs/pull/791) Fix search
-  ([@mansona])
-- [ember-learn/ember-blog]
-  [#1096](https://github.com/ember-learn/ember-blog/pull/1096) Update
-  the-ember-times-issue-195.md ([@locks])
-- [ember-learn/ember-cli-addon-docs]
-  [#1108](https://github.com/ember-learn/ember-cli-addon-docs/pull/1108) Fix no
-  implicit this deprecation in docs-demo component ([@nickschot])
-- [ember-learn/ember-website]
-  [#891](https://github.com/ember-learn/ember-website/pull/891) Fix team name
-  ([@locks])
-- [ember-learn/handbook] [#60](https://github.com/ember-learn/handbook/pull/60)
-  Update team leadership as agreed during meeting ([@locks])
-- [emberjs/core-notes] [#438](https://github.com/emberjs/core-notes/pull/438)
-  [learning] February 3rd, 2022 ([@locks])
-- [emberjs/data] [#7855](https://github.com/emberjs/data/pull/7855) wip RFC
-  332 - implement Record Links & Meta ([@mansona])
-- [nickschot/ember-mobile-menu]
-  [#239](https://github.com/nickschot/ember-mobile-menu/pull/239) Upgrade to
-  ember-cli 4.1 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#238](https://github.com/nickschot/ember-mobile-menu/pull/238) Revert
-  "Prevent open/close from being triggered a huge amount of times when
-  unnecessary" ([@nickschot])
-- [mainmatter/ember-hbs-minifier]
-  [#419](https://github.com/mainmatter/ember-hbs-minifier/pull/419) ember-try:
-  Disable Ember.js 4.x scenarios ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#418](https://github.com/mainmatter/ember-hbs-minifier/pull/418) CI: Remove
-  schedule trigger ([@Turbo87])
-- [mainmatter/ember-promise-modals]
-  [#526](https://github.com/mainmatter/ember-promise-modals/pull/526) Expose
-  `focusTrapOptions` ([@zeppelin])
-- [mainmatter/ember-promise-modals]
-  [#533](https://github.com/mainmatter/ember-promise-modals/pull/533) Legacy:
-  Downgrade native class to Ember.Object ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#531](https://github.com/mainmatter/ember-promise-modals/pull/531) Update
-  dependencies ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#530](https://github.com/mainmatter/ember-promise-modals/pull/530) Internal:
-  Extend and apply prettier configuration ([@pichfl])
-- [mainmatter/qunit-dom]
-  [#1434](https://github.com/mainmatter/qunit-dom/pull/1434) Revert "Update
-  embroider monorepo to v0.50.2 (minor)" ([@Turbo87])
-- [sir-dunxalot/ember-tooltips]
-  [#439](https://github.com/sir-dunxalot/ember-tooltips/pull/439) Remove
-  `assign()` usage ([@Turbo87])
+- [Authmaker/authmaker-ember-simple-auth] [#35](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/35) Fix deprecations and support Ember 4.0 ([@mansona])
+- [Authmaker/authmaker-ember-simple-auth] [#34](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/34) Breaking: drop support for Ember < 3.16 and update with ember-cli-update ([@mansona])
+- [ember-cli/ember-cli] [#9778](https://github.com/ember-cli/ember-cli/pull/9778) Prune lodash dependencies ([@locks])
+- [ember-cli/ember-cli] [#9769](https://github.com/ember-cli/ember-cli/pull/9769) Update markdown-it to v12.3.2 to address vulnerabiliity ([@locks])
+- [ember-engines/ember-engines] [#798](https://github.com/ember-engines/ember-engines/pull/798) Ember 4 compatibility ([@BobrImperator])
+- [ember-engines/ember-engines] [#797](https://github.com/ember-engines/ember-engines/pull/797) Update to ember qunit 5 ([@BobrImperator])
+- [ember-learn/deprecation-app] [#1074](https://github.com/ember-learn/deprecation-app/pull/1074) Fix broken markdown links due to formatting ([@locks])
+- [ember-learn/deprecation-app] [#1069](https://github.com/ember-learn/deprecation-app/pull/1069) Improving doc for deprecation "deprecated-run-loop-and-computed-dot-a… ([@locks])
+- [ember-learn/ember-api-docs] [#791](https://github.com/ember-learn/ember-api-docs/pull/791) Fix search ([@mansona])
+- [ember-learn/ember-blog] [#1096](https://github.com/ember-learn/ember-blog/pull/1096) Update the-ember-times-issue-195.md ([@locks])
+- [ember-learn/ember-cli-addon-docs] [#1108](https://github.com/ember-learn/ember-cli-addon-docs/pull/1108) Fix no implicit this deprecation in docs-demo component ([@nickschot])
+- [ember-learn/ember-website] [#891](https://github.com/ember-learn/ember-website/pull/891) Fix team name ([@locks])
+- [ember-learn/handbook] [#60](https://github.com/ember-learn/handbook/pull/60) Update team leadership as agreed during meeting ([@locks])
+- [emberjs/core-notes] [#438](https://github.com/emberjs/core-notes/pull/438) [learning] February 3rd, 2022 ([@locks])
+- [emberjs/data] [#7855](https://github.com/emberjs/data/pull/7855) wip RFC 332 - implement Record Links & Meta ([@mansona])
+- [nickschot/ember-mobile-menu] [#239](https://github.com/nickschot/ember-mobile-menu/pull/239) Upgrade to ember-cli 4.1 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#238](https://github.com/nickschot/ember-mobile-menu/pull/238) Revert "Prevent open/close from being triggered a huge amount of times when unnecessary" ([@nickschot])
+- [mainmatter/ember-hbs-minifier] [#419](https://github.com/mainmatter/ember-hbs-minifier/pull/419) ember-try: Disable Ember.js 4.x scenarios ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#418](https://github.com/mainmatter/ember-hbs-minifier/pull/418) CI: Remove schedule trigger ([@Turbo87])
+- [mainmatter/ember-promise-modals] [#526](https://github.com/mainmatter/ember-promise-modals/pull/526) Expose `focusTrapOptions` ([@zeppelin])
+- [mainmatter/ember-promise-modals] [#533](https://github.com/mainmatter/ember-promise-modals/pull/533) Legacy: Downgrade native class to Ember.Object ([@pichfl])
+- [mainmatter/ember-promise-modals] [#531](https://github.com/mainmatter/ember-promise-modals/pull/531) Update dependencies ([@pichfl])
+- [mainmatter/ember-promise-modals] [#530](https://github.com/mainmatter/ember-promise-modals/pull/530) Internal: Extend and apply prettier configuration ([@pichfl])
+- [mainmatter/qunit-dom] [#1434](https://github.com/mainmatter/qunit-dom/pull/1434) Revert "Update embroider monorepo to v0.50.2 (minor)" ([@Turbo87])
+- [sir-dunxalot/ember-tooltips] [#439](https://github.com/sir-dunxalot/ember-tooltips/pull/439) Remove `assign()` usage ([@Turbo87])
 
 ## JavaScript
 
-- [mansona/lint-to-the-future]
-  [#18](https://github.com/mansona/lint-to-the-future/pull/18) Update README.md
-  ([@locks])
-- [mansona/lint-to-the-future]
-  [#19](https://github.com/mansona/lint-to-the-future/pull/19) Add tests & fix
-  bug with view files route ([@mansona])
+- [mansona/lint-to-the-future] [#18](https://github.com/mansona/lint-to-the-future/pull/18) Update README.md ([@locks])
+- [mansona/lint-to-the-future] [#19](https://github.com/mansona/lint-to-the-future/pull/19) Add tests & fix bug with view files route ([@mansona])
 
 ## Ruby
 
-- [HaughtCodeworks/cfp-app]
-  [#238](https://github.com/HaughtCodeworks/cfp-app/pull/238) Update
-  dependencies ([@locks])
-- [Project-NISEI/cobra] [#47](https://github.com/Project-NISEI/cobra/pull/47)
-  Improve CI ([@locks])
-- [Project-NISEI/cobra] [#46](https://github.com/Project-NISEI/cobra/pull/46)
-  Remove support for importing from TOME ([@locks])
-- [Project-NISEI/cobra] [#43](https://github.com/Project-NISEI/cobra/pull/43)
-  [WIP] Set up CI workflow ([@locks])
-- [Project-NISEI/cobra] [#38](https://github.com/Project-NISEI/cobra/pull/38)
-  Upgrade ruby 3 rails 7 ([@locks])
-- [tildeio/cfp-app] [#83](https://github.com/tildeio/cfp-app/pull/83) Set up
-  rack-attack ([@locks])
-- [tildeio/cfp-app] [#82](https://github.com/tildeio/cfp-app/pull/82) adjusted
-  bundle frozen configuration per deprecation warning ([@locks])
-- [tildeio/cfp-app] [#71](https://github.com/tildeio/cfp-app/pull/71) Update
-  omniauth-github ([@locks])
-- [tildeio/cfp-app] [#68](https://github.com/tildeio/cfp-app/pull/68)
-  Update-dependencies ([@locks])
+- [HaughtCodeworks/cfp-app] [#238](https://github.com/HaughtCodeworks/cfp-app/pull/238) Update dependencies ([@locks])
+- [Project-NISEI/cobra] [#47](https://github.com/Project-NISEI/cobra/pull/47) Improve CI ([@locks])
+- [Project-NISEI/cobra] [#46](https://github.com/Project-NISEI/cobra/pull/46) Remove support for importing from TOME ([@locks])
+- [Project-NISEI/cobra] [#43](https://github.com/Project-NISEI/cobra/pull/43) [WIP] Set up CI workflow ([@locks])
+- [Project-NISEI/cobra] [#38](https://github.com/Project-NISEI/cobra/pull/38) Upgrade ruby 3 rails 7 ([@locks])
+- [tildeio/cfp-app] [#83](https://github.com/tildeio/cfp-app/pull/83) Set up rack-attack ([@locks])
+- [tildeio/cfp-app] [#82](https://github.com/tildeio/cfp-app/pull/82) adjusted bundle frozen configuration per deprecation warning ([@locks])
+- [tildeio/cfp-app] [#71](https://github.com/tildeio/cfp-app/pull/71) Update omniauth-github ([@locks])
+- [tildeio/cfp-app] [#68](https://github.com/tildeio/cfp-app/pull/68) Update-dependencies ([@locks])
 
 ## Rust
 
-- [exercism/rust] [#1443](https://github.com/exercism/rust/pull/1443)
-  chore(rust): use capital letters for 'API' exercise ([@oscard0m])
+- [exercism/rust] [#1443](https://github.com/exercism/rust/pull/1443) chore(rust): use capital letters for 'API' exercise ([@oscard0m])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4514](https://github.com/rust-lang/crates.io/pull/4514) Ember: Use `history`
-  location API ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4507](https://github.com/rust-lang/crates.io/pull/4507) Fix `keyword` route
-  links ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4496](https://github.com/rust-lang/crates.io/pull/4496) EncodableCrate:
-  Simplify `from_minimal()` method ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4481](https://github.com/rust-lang/crates.io/pull/4481) keyword: Show error
-  page if data loading fails ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4480](https://github.com/rust-lang/crates.io/pull/4480) category: Show error
-  page if data loading fails ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4479](https://github.com/rust-lang/crates.io/pull/4479)
-  crate.version-dependencies: Show error page if data loading fails ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4477](https://github.com/rust-lang/crates.io/pull/4477) Adjust error page
-  titles ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4476](https://github.com/rust-lang/crates.io/pull/4476) crate.range: Show
-  error page if data fails to load ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4475](https://github.com/rust-lang/crates.io/pull/4475) Disable `crypto`
-  import warning in `axe-core` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4474](https://github.com/rust-lang/crates.io/pull/4474) Remove obsolete
-  `ember-keyboard` options ([@Turbo87])
+- [rust-lang/crates.io] [#4514](https://github.com/rust-lang/crates.io/pull/4514) Ember: Use `history` location API ([@Turbo87])
+- [rust-lang/crates.io] [#4507](https://github.com/rust-lang/crates.io/pull/4507) Fix `keyword` route links ([@Turbo87])
+- [rust-lang/crates.io] [#4496](https://github.com/rust-lang/crates.io/pull/4496) EncodableCrate: Simplify `from_minimal()` method ([@Turbo87])
+- [rust-lang/crates.io] [#4481](https://github.com/rust-lang/crates.io/pull/4481) keyword: Show error page if data loading fails ([@Turbo87])
+- [rust-lang/crates.io] [#4480](https://github.com/rust-lang/crates.io/pull/4480) category: Show error page if data loading fails ([@Turbo87])
+- [rust-lang/crates.io] [#4479](https://github.com/rust-lang/crates.io/pull/4479) crate.version-dependencies: Show error page if data loading fails ([@Turbo87])
+- [rust-lang/crates.io] [#4477](https://github.com/rust-lang/crates.io/pull/4477) Adjust error page titles ([@Turbo87])
+- [rust-lang/crates.io] [#4476](https://github.com/rust-lang/crates.io/pull/4476) crate.range: Show error page if data fails to load ([@Turbo87])
+- [rust-lang/crates.io] [#4475](https://github.com/rust-lang/crates.io/pull/4475) Disable `crypto` import warning in `axe-core` ([@Turbo87])
+- [rust-lang/crates.io] [#4474](https://github.com/rust-lang/crates.io/pull/4474) Remove obsolete `ember-keyboard` options ([@Turbo87])
 
 [@bobrimperator]: https://github.com/BobrImperator
 [@turbo87]: https://github.com/Turbo87
@@ -166,8 +76,7 @@
 [@oscard0m]: https://github.com/oscard0m
 [@pichfl]: https://github.com/pichfl
 [@zeppelin]: https://github.com/zeppelin
-[authmaker/authmaker-ember-simple-auth]:
-  https://github.com/Authmaker/authmaker-ember-simple-auth
+[authmaker/authmaker-ember-simple-auth]: https://github.com/Authmaker/authmaker-ember-simple-auth
 [haughtcodeworks/cfp-app]: https://github.com/HaughtCodeworks/cfp-app
 [project-nisei/cobra]: https://github.com/Project-NISEI/cobra
 [atom/atom]: https://github.com/atom/atom
@@ -177,8 +86,7 @@
 [ember-learn/deprecation-app]: https://github.com/ember-learn/deprecation-app
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
 [ember-learn/ember-blog]: https://github.com/ember-learn/ember-blog
-[ember-learn/ember-cli-addon-docs]:
-  https://github.com/ember-learn/ember-cli-addon-docs
+[ember-learn/ember-cli-addon-docs]: https://github.com/ember-learn/ember-cli-addon-docs
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [ember-learn/handbook]: https://github.com/ember-learn/handbook
 [emberjs/core-notes]: https://github.com/emberjs/core-notes
@@ -191,13 +99,10 @@
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
 [oscard0m/web]: https://github.com/oscard0m/web
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
-[mainmatter/ember-hbs-minifier]:
-  https://github.com/mainmatter/ember-hbs-minifier
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-hbs-minifier]: https://github.com/mainmatter/ember-hbs-minifier
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [mainmatter/qunit-dom]: https://github.com/mainmatter/qunit-dom
-[mainmatter/mainmatter.github.io]:
-  https://github.com/mainmatter/mainmatter.github.io
+[mainmatter/mainmatter.github.io]: https://github.com/mainmatter/mainmatter.github.io
 [sir-dunxalot/ember-tooltips]: https://github.com/sir-dunxalot/ember-tooltips
 [tildeio/cfp-app]: https://github.com/tildeio/cfp-app
 [contact]: /contact/
diff --git a/src/twios/2022-02-22.md b/src/twios/2022-02-22.md
index 56cc7d1836..6edc48fd9f 100644
--- a/src/twios/2022-02-22.md
+++ b/src/twios/2022-02-22.md
@@ -1,83 +1,35 @@
 ## Ember.js
 
-- [ember-cli/ember-cli]
-  [#9790](https://github.com/ember-cli/ember-cli/pull/9790) Upgrade
-  broccoli-merge-trees ([@locks])
-- [ember-cli/ember-cli]
-  [#9784](https://github.com/ember-cli/ember-cli/pull/9784) Unskip tests
-  ([@locks])
-- [ember-learn/deprecation-app]
-  [#1078](https://github.com/ember-learn/deprecation-app/pull/1078) Update
-  dependencies ([@locks])
-- [ember-learn/ember-website]
-  [#896](https://github.com/ember-learn/ember-website/pull/896) Adding IE11 to
-  compilation targets ([@locks])
-- [mainmatter/ember-hbs-minifier]
-  [#460](https://github.com/mainmatter/ember-hbs-minifier/pull/460) Replace
-  deprecated class-based AST transform plugin ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#459](https://github.com/mainmatter/ember-hbs-minifier/pull/459) Enable Ember
-  Octane features ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#458](https://github.com/mainmatter/ember-hbs-minifier/pull/458) Add
-  `ember-auto-import` dev dependency ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#457](https://github.com/mainmatter/ember-hbs-minifier/pull/457) Remove
-  unused `ember-cli-htmlbars-inline-precompile` dependency ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#451](https://github.com/mainmatter/ember-hbs-minifier/pull/451) renovate:
-  Update `pnpm` version automatically ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#447](https://github.com/mainmatter/ember-hbs-minifier/pull/447) Replace
-  Mocha with QUnit ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#446](https://github.com/mainmatter/ember-hbs-minifier/pull/446) renovate:
-  Disable for `@glimmer/syntax-*` dependencies ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#425](https://github.com/mainmatter/ember-hbs-minifier/pull/425) Update
-  `ember-try` to v2 ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#424](https://github.com/mainmatter/ember-hbs-minifier/pull/424) Use `pnpm`
-  package manager ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#423](https://github.com/mainmatter/ember-hbs-minifier/pull/423) Remove
-  unmaintained `multidep` dependency ([@Turbo87])
-- [mainmatter/ember-promise-modals]
-  [#549](https://github.com/mainmatter/ember-promise-modals/pull/549) Enhance
-  focus trap configuration ([@zeppelin])
-- [mainmatter/ember-promise-modals]
-  [#550](https://github.com/mainmatter/ember-promise-modals/pull/550) Modal
-  template helper ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#543](https://github.com/mainmatter/ember-promise-modals/pull/543) Revert
-  #533 ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#548](https://github.com/mainmatter/ember-promise-modals/pull/548) WIP:
-  Enable Ember 2.18 CI scenario ([@nickschot])
-- [mainmatter/ember-test-selectors]
-  [#889](https://github.com/mainmatter/ember-test-selectors/pull/889) renovate:
-  Update `pnpm` version automatically ([@Turbo87])
+- [ember-cli/ember-cli] [#9790](https://github.com/ember-cli/ember-cli/pull/9790) Upgrade broccoli-merge-trees ([@locks])
+- [ember-cli/ember-cli] [#9784](https://github.com/ember-cli/ember-cli/pull/9784) Unskip tests ([@locks])
+- [ember-learn/deprecation-app] [#1078](https://github.com/ember-learn/deprecation-app/pull/1078) Update dependencies ([@locks])
+- [ember-learn/ember-website] [#896](https://github.com/ember-learn/ember-website/pull/896) Adding IE11 to compilation targets ([@locks])
+- [mainmatter/ember-hbs-minifier] [#460](https://github.com/mainmatter/ember-hbs-minifier/pull/460) Replace deprecated class-based AST transform plugin ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#459](https://github.com/mainmatter/ember-hbs-minifier/pull/459) Enable Ember Octane features ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#458](https://github.com/mainmatter/ember-hbs-minifier/pull/458) Add `ember-auto-import` dev dependency ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#457](https://github.com/mainmatter/ember-hbs-minifier/pull/457) Remove unused `ember-cli-htmlbars-inline-precompile` dependency ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#451](https://github.com/mainmatter/ember-hbs-minifier/pull/451) renovate: Update `pnpm` version automatically ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#447](https://github.com/mainmatter/ember-hbs-minifier/pull/447) Replace Mocha with QUnit ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#446](https://github.com/mainmatter/ember-hbs-minifier/pull/446) renovate: Disable for `@glimmer/syntax-*` dependencies ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#425](https://github.com/mainmatter/ember-hbs-minifier/pull/425) Update `ember-try` to v2 ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#424](https://github.com/mainmatter/ember-hbs-minifier/pull/424) Use `pnpm` package manager ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#423](https://github.com/mainmatter/ember-hbs-minifier/pull/423) Remove unmaintained `multidep` dependency ([@Turbo87])
+- [mainmatter/ember-promise-modals] [#549](https://github.com/mainmatter/ember-promise-modals/pull/549) Enhance focus trap configuration ([@zeppelin])
+- [mainmatter/ember-promise-modals] [#550](https://github.com/mainmatter/ember-promise-modals/pull/550) Modal template helper ([@pichfl])
+- [mainmatter/ember-promise-modals] [#543](https://github.com/mainmatter/ember-promise-modals/pull/543) Revert #533 ([@pichfl])
+- [mainmatter/ember-promise-modals] [#548](https://github.com/mainmatter/ember-promise-modals/pull/548) WIP: Enable Ember 2.18 CI scenario ([@nickschot])
+- [mainmatter/ember-test-selectors] [#889](https://github.com/mainmatter/ember-test-selectors/pull/889) renovate: Update `pnpm` version automatically ([@Turbo87])
 
 ## JavaScript
 
-- [mansona/express-autoroute-json]
-  [#42](https://github.com/mansona/express-autoroute-json/pull/42) Move from
-  Travis to GitHub actions ([@mansona])
-- [octokit/plugin-throttling.js]
-  [#457](https://github.com/octokit/plugin-throttling.js/pull/457) Improve types
-  for `ThrottlingOctokitOptions` ([@oscard0m])
-- [octokit/plugin-throttling.js]
-  [#456](https://github.com/octokit/plugin-throttling.js/pull/456)
-  test(coverage): adding 100% coverage ([@oscard0m])
-- [octokit/plugin-throttling.js]
-  [#455](https://github.com/octokit/plugin-throttling.js/pull/455) Replace
-  'abuse limit' with 'secondary limit' ([@oscard0m])
+- [mansona/express-autoroute-json] [#42](https://github.com/mansona/express-autoroute-json/pull/42) Move from Travis to GitHub actions ([@mansona])
+- [octokit/plugin-throttling.js] [#457](https://github.com/octokit/plugin-throttling.js/pull/457) Improve types for `ThrottlingOctokitOptions` ([@oscard0m])
+- [octokit/plugin-throttling.js] [#456](https://github.com/octokit/plugin-throttling.js/pull/456) test(coverage): adding 100% coverage ([@oscard0m])
+- [octokit/plugin-throttling.js] [#455](https://github.com/octokit/plugin-throttling.js/pull/455) Replace 'abuse limit' with 'secondary limit' ([@oscard0m])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4554](https://github.com/rust-lang/crates.io/pull/4554) controllers::krate:
-  Protect against null bytes in query string ([@Turbo87])
+- [rust-lang/crates.io] [#4554](https://github.com/rust-lang/crates.io/pull/4554) controllers::krate: Protect against null bytes in query string ([@Turbo87])
 
 [@turbo87]: https://github.com/Turbo87
 [@locks]: https://github.com/locks
@@ -89,13 +41,9 @@
 [ember-cli/ember-cli]: https://github.com/ember-cli/ember-cli
 [ember-learn/deprecation-app]: https://github.com/ember-learn/deprecation-app
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
-[mansona/express-autoroute-json]:
-  https://github.com/mansona/express-autoroute-json
+[mansona/express-autoroute-json]: https://github.com/mansona/express-autoroute-json
 [octokit/plugin-throttling.js]: https://github.com/octokit/plugin-throttling.js
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
-[mainmatter/ember-hbs-minifier]:
-  https://github.com/mainmatter/ember-hbs-minifier
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
-[mainmatter/ember-test-selectors]:
-  https://github.com/mainmatter/ember-test-selectors
+[mainmatter/ember-hbs-minifier]: https://github.com/mainmatter/ember-hbs-minifier
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-test-selectors]: https://github.com/mainmatter/ember-test-selectors
diff --git a/src/twios/2022-03-09.md b/src/twios/2022-03-09.md
index fd6a2c0a28..4d74ea1bdc 100644
--- a/src/twios/2022-03-09.md
+++ b/src/twios/2022-03-09.md
@@ -1,87 +1,37 @@
 ## Ember.js
 
-- [ember-learn/deprecation-app]
-  [#1095](https://github.com/ember-learn/deprecation-app/pull/1095) Update npm
-  lockfile ([@locks])
-- [ember-learn/ember-website]
-  [#920](https://github.com/ember-learn/ember-website/pull/920) Update child
-  navigation items for Community ([@locks])
-- [ember-learn/ember-website]
-  [#918](https://github.com/ember-learn/ember-website/pull/918) Pin npm 8
-  ([@locks])
-- [ember-learn/ember-website]
-  [#915](https://github.com/ember-learn/ember-website/pull/915) Set up 2022
-  survey ([@locks])
-- [ember-learn/ember-website]
-  [#913](https://github.com/ember-learn/ember-website/pull/913) Formally
-  alumnize Igor ([@locks])
-- [ember-learn/ember-website]
-  [#919](https://github.com/ember-learn/ember-website/pull/919) add logo for
-  2022 survey ([@mansona])
-- [ember-learn/guides-source]
-  [#1795](https://github.com/ember-learn/guides-source/pull/1795) v4.2.0
-  ([@locks])
-- [empress/rfc-process] [#6](https://github.com/empress/rfc-process/pull/6) make
-  ember-scroll a dependency of rfc-process ([@mansona])
-- [empress/rfc-process] [#5](https://github.com/empress/rfc-process/pull/5) make
-  markdown tables work in showdown ([@mansona])
-- [empress/rfc-process] [#4](https://github.com/empress/rfc-process/pull/4) add
-  auto-changelog system ([@mansona])
-- [empress/rfc-process] [#3](https://github.com/empress/rfc-process/pull/3) fix
-  location of htmlSafe import ([@mansona])
-- [empress/rfc-process] [#2](https://github.com/empress/rfc-process/pull/2) add
-  ability to import the data for rfcs from a custom directory ([@mansona])
-- [empress/rfc-process] [#1](https://github.com/empress/rfc-process/pull/1) get
-  project ready for local development ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#6](https://github.com/empress/rfc-process-mdbook-template/pull/6) use Lint
-  to the future ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#5](https://github.com/empress/rfc-process-mdbook-template/pull/5) add
-  auto-changelog system ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#4](https://github.com/empress/rfc-process-mdbook-template/pull/4) remove
-  ember-a11y-refocus ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#3](https://github.com/empress/rfc-process-mdbook-template/pull/3) Fix code
-  samples in RFC content ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#2](https://github.com/empress/rfc-process-mdbook-template/pull/2) Fix
-  forward back buttons ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#1](https://github.com/empress/rfc-process-mdbook-template/pull/1) get the
-  repo ready for local-dev ([@mansona])
-- [jelhan/ember-cli-browser-navigation-button-test-helpers]
-  [#33](https://github.com/jelhan/ember-cli-browser-navigation-button-test-helpers/pull/33)
-  Remove ember-router-service-polyfill ([@zeppelin])
-- [miguelcobain/ember-paper]
-  [#1217](https://github.com/miguelcobain/ember-paper/pull/1217) remove Ember
-  3.28 from ember-try scenarios ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1215](https://github.com/miguelcobain/ember-paper/pull/1215) Setting up the
-  lint-to-the-future dashboard ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1212](https://github.com/miguelcobain/ember-paper/pull/1212) Move from
-  travis to github actions ([@mansona])
+- [ember-learn/deprecation-app] [#1095](https://github.com/ember-learn/deprecation-app/pull/1095) Update npm lockfile ([@locks])
+- [ember-learn/ember-website] [#920](https://github.com/ember-learn/ember-website/pull/920) Update child navigation items for Community ([@locks])
+- [ember-learn/ember-website] [#918](https://github.com/ember-learn/ember-website/pull/918) Pin npm 8 ([@locks])
+- [ember-learn/ember-website] [#915](https://github.com/ember-learn/ember-website/pull/915) Set up 2022 survey ([@locks])
+- [ember-learn/ember-website] [#913](https://github.com/ember-learn/ember-website/pull/913) Formally alumnize Igor ([@locks])
+- [ember-learn/ember-website] [#919](https://github.com/ember-learn/ember-website/pull/919) add logo for 2022 survey ([@mansona])
+- [ember-learn/guides-source] [#1795](https://github.com/ember-learn/guides-source/pull/1795) v4.2.0 ([@locks])
+- [empress/rfc-process] [#6](https://github.com/empress/rfc-process/pull/6) make ember-scroll a dependency of rfc-process ([@mansona])
+- [empress/rfc-process] [#5](https://github.com/empress/rfc-process/pull/5) make markdown tables work in showdown ([@mansona])
+- [empress/rfc-process] [#4](https://github.com/empress/rfc-process/pull/4) add auto-changelog system ([@mansona])
+- [empress/rfc-process] [#3](https://github.com/empress/rfc-process/pull/3) fix location of htmlSafe import ([@mansona])
+- [empress/rfc-process] [#2](https://github.com/empress/rfc-process/pull/2) add ability to import the data for rfcs from a custom directory ([@mansona])
+- [empress/rfc-process] [#1](https://github.com/empress/rfc-process/pull/1) get project ready for local development ([@mansona])
+- [empress/rfc-process-mdbook-template] [#6](https://github.com/empress/rfc-process-mdbook-template/pull/6) use Lint to the future ([@mansona])
+- [empress/rfc-process-mdbook-template] [#5](https://github.com/empress/rfc-process-mdbook-template/pull/5) add auto-changelog system ([@mansona])
+- [empress/rfc-process-mdbook-template] [#4](https://github.com/empress/rfc-process-mdbook-template/pull/4) remove ember-a11y-refocus ([@mansona])
+- [empress/rfc-process-mdbook-template] [#3](https://github.com/empress/rfc-process-mdbook-template/pull/3) Fix code samples in RFC content ([@mansona])
+- [empress/rfc-process-mdbook-template] [#2](https://github.com/empress/rfc-process-mdbook-template/pull/2) Fix forward back buttons ([@mansona])
+- [empress/rfc-process-mdbook-template] [#1](https://github.com/empress/rfc-process-mdbook-template/pull/1) get the repo ready for local-dev ([@mansona])
+- [jelhan/ember-cli-browser-navigation-button-test-helpers] [#33](https://github.com/jelhan/ember-cli-browser-navigation-button-test-helpers/pull/33) Remove ember-router-service-polyfill ([@zeppelin])
+- [miguelcobain/ember-paper] [#1217](https://github.com/miguelcobain/ember-paper/pull/1217) remove Ember 3.28 from ember-try scenarios ([@mansona])
+- [miguelcobain/ember-paper] [#1215](https://github.com/miguelcobain/ember-paper/pull/1215) Setting up the lint-to-the-future dashboard ([@mansona])
+- [miguelcobain/ember-paper] [#1212](https://github.com/miguelcobain/ember-paper/pull/1212) Move from travis to github actions ([@mansona])
 
 ## Octokit
 
-- [octokit/core.js] [#450](https://github.com/octokit/core.js/pull/450)
-  feat(types): convert type 'OctokitOptions' to interface ([@oscard0m])
-- [octokit/octokit.js] [#2206](https://github.com/octokit/octokit.js/pull/2206)
-  docs(contributing): add explanation on how to manage a merged PR non
-  semantic-release compliant ([@oscard0m])
-- [octokit/octokit.js] [#2205](https://github.com/octokit/octokit.js/pull/2205)
-  docs(contributing): refer to all octokit projects ([@oscard0m])
-- [octokit/webhooks.js] [#673](https://github.com/octokit/webhooks.js/pull/673)
-  docs(README): update PR ([@oscard0m])
-- [octokit/plugin-throttling.js]
-  [#459](https://github.com/octokit/plugin-throttling.js/pull/459) feat(log):
-  use 'octokit.log.warn' instead of 'console.warn' ([@oscard0m])
-- [octokit/plugin-throttling.js]
-  [#458](https://github.com/octokit/plugin-throttling.js/pull/458)
-  feat(secondary-limit): replace 'abuse-limit' logic with 'secondary-limit'
-  ([@oscard0m])
+- [octokit/core.js] [#450](https://github.com/octokit/core.js/pull/450) feat(types): convert type 'OctokitOptions' to interface ([@oscard0m])
+- [octokit/octokit.js] [#2206](https://github.com/octokit/octokit.js/pull/2206) docs(contributing): add explanation on how to manage a merged PR non semantic-release compliant ([@oscard0m])
+- [octokit/octokit.js] [#2205](https://github.com/octokit/octokit.js/pull/2205) docs(contributing): refer to all octokit projects ([@oscard0m])
+- [octokit/webhooks.js] [#673](https://github.com/octokit/webhooks.js/pull/673) docs(README): update PR ([@oscard0m])
+- [octokit/plugin-throttling.js] [#459](https://github.com/octokit/plugin-throttling.js/pull/459) feat(log): use 'octokit.log.warn' instead of 'console.warn' ([@oscard0m])
+- [octokit/plugin-throttling.js] [#458](https://github.com/octokit/plugin-throttling.js/pull/458) feat(secondary-limit): replace 'abuse-limit' logic with 'secondary-limit' ([@oscard0m])
 
 [@locks]: https://github.com/locks
 [@mansona]: https://github.com/mansona
@@ -90,11 +40,9 @@
 [ember-learn/deprecation-app]: https://github.com/ember-learn/deprecation-app
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
-[empress/rfc-process-mdbook-template]:
-  https://github.com/empress/rfc-process-mdbook-template
+[empress/rfc-process-mdbook-template]: https://github.com/empress/rfc-process-mdbook-template
 [empress/rfc-process]: https://github.com/empress/rfc-process
-[jelhan/ember-cli-browser-navigation-button-test-helpers]:
-  https://github.com/jelhan/ember-cli-browser-navigation-button-test-helpers
+[jelhan/ember-cli-browser-navigation-button-test-helpers]: https://github.com/jelhan/ember-cli-browser-navigation-button-test-helpers
 [miguelcobain/ember-paper]: https://github.com/miguelcobain/ember-paper
 [octokit/core.js]: https://github.com/octokit/core.js
 [octokit/octokit.js]: https://github.com/octokit/octokit.js
diff --git a/src/twios/2022-03-22.md b/src/twios/2022-03-22.md
index 0cc1482f8d..b9a8aa7d39 100644
--- a/src/twios/2022-03-22.md
+++ b/src/twios/2022-03-22.md
@@ -1,36 +1,20 @@
 ## Ember.js
 
-- [mainmatter/qunit-dom]
-  [#1491](https://github.com/mainmatter/qunit-dom/pull/1491) Fix `documentation`
-  integration ([@Turbo87])
-- [zeppelin/ember-click-outside]
-  [#241](https://github.com/zeppelin/ember-click-outside/pull/241) Add forgotten
-  release command ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#240](https://github.com/zeppelin/ember-click-outside/pull/240) Remove
-  deprecated component properties ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#239](https://github.com/zeppelin/ember-click-outside/pull/239) Remove
-  deprecated exports ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#238](https://github.com/zeppelin/ember-click-outside/pull/238) Deprecate
-  `ClickOutsideMixin` ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#237](https://github.com/zeppelin/ember-click-outside/pull/237) Set up
-  release-it ([@zeppelin])
+- [mainmatter/qunit-dom] [#1491](https://github.com/mainmatter/qunit-dom/pull/1491) Fix `documentation` integration ([@Turbo87])
+- [zeppelin/ember-click-outside] [#241](https://github.com/zeppelin/ember-click-outside/pull/241) Add forgotten release command ([@zeppelin])
+- [zeppelin/ember-click-outside] [#240](https://github.com/zeppelin/ember-click-outside/pull/240) Remove deprecated component properties ([@zeppelin])
+- [zeppelin/ember-click-outside] [#239](https://github.com/zeppelin/ember-click-outside/pull/239) Remove deprecated exports ([@zeppelin])
+- [zeppelin/ember-click-outside] [#238](https://github.com/zeppelin/ember-click-outside/pull/238) Deprecate `ClickOutsideMixin` ([@zeppelin])
+- [zeppelin/ember-click-outside] [#237](https://github.com/zeppelin/ember-click-outside/pull/237) Set up release-it ([@zeppelin])
 
 ## Octokit
 
-- [octokit/core.js] [#454](https://github.com/octokit/core.js/pull/454)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-retry.js]
-  [#303](https://github.com/octokit/plugin-retry.js/pull/303)
-  build(package.json): add @octokit/core as peerDependency ([@oscard0m])
+- [octokit/core.js] [#454](https://github.com/octokit/core.js/pull/454) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-retry.js] [#303](https://github.com/octokit/plugin-retry.js/pull/303) build(package.json): add @octokit/core as peerDependency ([@oscard0m])
 
 ## TypeScript
 
-- [mswjs/msw] [#1170](https://github.com/mswjs/msw/pull/1170) ci(workflows):
-  upgrade actions/checkout and actions/setup-node to v3 ([@oscard0m])
+- [mswjs/msw] [#1170](https://github.com/mswjs/msw/pull/1170) ci(workflows): upgrade actions/checkout and actions/setup-node to v3 ([@oscard0m])
 
 [@turbo87]: https://github.com/Turbo87
 [@marcoow]: https://github.com/marcoow
diff --git a/src/twios/2022-04-08.md b/src/twios/2022-04-08.md
index 7fd7972770..9bb1f688db 100644
--- a/src/twios/2022-04-08.md
+++ b/src/twios/2022-04-08.md
@@ -1,79 +1,34 @@
 ## Ember.js
 
-- [GavinJoyce/ember-headlessui]
-  [#136](https://github.com/GavinJoyce/ember-headlessui/pull/136) Add Fallback
-  Focus to Dialog ([@mansona])
-- [ember-learn/ember-blog]
-  [#1140](https://github.com/ember-learn/ember-blog/pull/1140) Ember v4.3
-  release ([@locks])
-- [ember-learn/ember-blog]
-  [#1139](https://github.com/ember-learn/ember-blog/pull/1139) Add custom
-  blueprint for generating release blog posts ([@locks])
-- [emberjs/core-notes] [#445](https://github.com/emberjs/core-notes/pull/445)
-  Learning | March 31st ([@locks])
-- [emberjs/core-notes] [#444](https://github.com/emberjs/core-notes/pull/444)
-  Learning | March 24th ([@locks])
-- [nickschot/ember-mobile-menu]
-  [#261](https://github.com/nickschot/ember-mobile-menu/pull/261) Move npmignore
-  to addon package ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#260](https://github.com/nickschot/ember-mobile-menu/pull/260) Add missing
-  @ember/test-waiters dependency ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#259](https://github.com/nickschot/ember-mobile-menu/pull/259) Setup
-  release-it ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#258](https://github.com/nickschot/ember-mobile-menu/pull/258) Cleanup some
-  dependencies between the packages ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#256](https://github.com/nickschot/ember-mobile-menu/pull/256) Convert addon
-  to monorepo ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#255](https://github.com/nickschot/ember-mobile-menu/pull/255) Switch to pnpm
-  ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#254](https://github.com/nickschot/ember-mobile-menu/pull/254) Re-enable
-  embroider test-support on CI ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#243](https://github.com/nickschot/ember-mobile-menu/pull/243) Drop Ember
-  3.23 support ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#242](https://github.com/nickschot/ember-mobile-menu/pull/242) Temporarily
-  disable Embroider tests in CI ([@nickschot])
-- [mainmatter/ember-intl-analyzer]
-  [#493](https://github.com/mainmatter/ember-intl-analyzer/pull/493) Revert
-  pkg-dir upgrade to v6 ([@Mikek2252])
-- [mainmatter/ember-intl-analyzer]
-  [#491](https://github.com/mainmatter/ember-intl-analyzer/pull/491) Add
-  release-it configuration to simplify releases ([@Mikek2252])
-- [mainmatter/ember-intl-analyzer]
-  [#489](https://github.com/mainmatter/ember-intl-analyzer/pull/489) Update Node
-  test scenarios in ci ([@Mikek2252])
-- [mainmatter/ember-simple-auth]
-  [#2367](https://github.com/mainmatter/ember-simple-auth/pull/2367) Implement a
-  popup authenticator ([@pichfl])
-- [mainmatter/ember-simple-auth]
-  [#2366](https://github.com/mainmatter/ember-simple-auth/pull/2366) [2365]
-  internal-session to call \_initialize on session-store during init
-  ([@BobrImperator])
+- [GavinJoyce/ember-headlessui] [#136](https://github.com/GavinJoyce/ember-headlessui/pull/136) Add Fallback Focus to Dialog ([@mansona])
+- [ember-learn/ember-blog] [#1140](https://github.com/ember-learn/ember-blog/pull/1140) Ember v4.3 release ([@locks])
+- [ember-learn/ember-blog] [#1139](https://github.com/ember-learn/ember-blog/pull/1139) Add custom blueprint for generating release blog posts ([@locks])
+- [emberjs/core-notes] [#445](https://github.com/emberjs/core-notes/pull/445) Learning | March 31st ([@locks])
+- [emberjs/core-notes] [#444](https://github.com/emberjs/core-notes/pull/444) Learning | March 24th ([@locks])
+- [nickschot/ember-mobile-menu] [#261](https://github.com/nickschot/ember-mobile-menu/pull/261) Move npmignore to addon package ([@nickschot])
+- [nickschot/ember-mobile-menu] [#260](https://github.com/nickschot/ember-mobile-menu/pull/260) Add missing @ember/test-waiters dependency ([@nickschot])
+- [nickschot/ember-mobile-menu] [#259](https://github.com/nickschot/ember-mobile-menu/pull/259) Setup release-it ([@nickschot])
+- [nickschot/ember-mobile-menu] [#258](https://github.com/nickschot/ember-mobile-menu/pull/258) Cleanup some dependencies between the packages ([@nickschot])
+- [nickschot/ember-mobile-menu] [#256](https://github.com/nickschot/ember-mobile-menu/pull/256) Convert addon to monorepo ([@nickschot])
+- [nickschot/ember-mobile-menu] [#255](https://github.com/nickschot/ember-mobile-menu/pull/255) Switch to pnpm ([@nickschot])
+- [nickschot/ember-mobile-menu] [#254](https://github.com/nickschot/ember-mobile-menu/pull/254) Re-enable embroider test-support on CI ([@nickschot])
+- [nickschot/ember-mobile-menu] [#243](https://github.com/nickschot/ember-mobile-menu/pull/243) Drop Ember 3.23 support ([@nickschot])
+- [nickschot/ember-mobile-menu] [#242](https://github.com/nickschot/ember-mobile-menu/pull/242) Temporarily disable Embroider tests in CI ([@nickschot])
+- [mainmatter/ember-intl-analyzer] [#493](https://github.com/mainmatter/ember-intl-analyzer/pull/493) Revert pkg-dir upgrade to v6 ([@Mikek2252])
+- [mainmatter/ember-intl-analyzer] [#491](https://github.com/mainmatter/ember-intl-analyzer/pull/491) Add release-it configuration to simplify releases ([@Mikek2252])
+- [mainmatter/ember-intl-analyzer] [#489](https://github.com/mainmatter/ember-intl-analyzer/pull/489) Update Node test scenarios in ci ([@Mikek2252])
+- [mainmatter/ember-simple-auth] [#2367](https://github.com/mainmatter/ember-simple-auth/pull/2367) Implement a popup authenticator ([@pichfl])
+- [mainmatter/ember-simple-auth] [#2366](https://github.com/mainmatter/ember-simple-auth/pull/2366) [2365] internal-session to call \_initialize on session-store during init ([@BobrImperator])
 
 ## JavaScript
 
-- [TelemetryDeck/JavaScriptSDK]
-  [#8](https://github.com/TelemetryDeck/JavaScriptSDK/pull/8) Always attach a
-  TelemetryDeck SDK instance to window ([@pichfl])
-- [yaacov/node-modbus-serial]
-  [#450](https://github.com/yaacov/node-modbus-serial/pull/450) Implement
-  Bluetooth LE port ([@Turbo87])
+- [TelemetryDeck/JavaScriptSDK] [#8](https://github.com/TelemetryDeck/JavaScriptSDK/pull/8) Always attach a TelemetryDeck SDK instance to window ([@pichfl])
+- [yaacov/node-modbus-serial] [#450](https://github.com/yaacov/node-modbus-serial/pull/450) Implement Bluetooth LE port ([@Turbo87])
 
 ## Octokit
 
-- [octokit/plugin-rest-endpoint-methods.js]
-  [#479](https://github.com/octokit/plugin-rest-endpoint-methods.js/pull/479)
-  ci(codeql): ignore 'push' events for dependabot branches ([@oscard0m])
-- [octokit/plugin-rest-endpoint-methods.js]
-  [#478](https://github.com/octokit/plugin-rest-endpoint-methods.js/pull/478)
-  ci(codeql): remove unnecessary step to checkout HEAD~2 from PRs ([@oscard0m])
+- [octokit/plugin-rest-endpoint-methods.js] [#479](https://github.com/octokit/plugin-rest-endpoint-methods.js/pull/479) ci(codeql): ignore 'push' events for dependabot branches ([@oscard0m])
+- [octokit/plugin-rest-endpoint-methods.js] [#478](https://github.com/octokit/plugin-rest-endpoint-methods.js/pull/478) ci(codeql): remove unnecessary step to checkout HEAD~2 from PRs ([@oscard0m])
 
 [@bobrimperator]: https://github.com/BobrImperator
 [@mikek2252]: https://github.com/Mikek2252
@@ -87,16 +42,12 @@
 [telemetrydeck/javascriptsdk]: https://github.com/TelemetryDeck/JavaScriptSDK
 [ember-learn/ember-blog]: https://github.com/ember-learn/ember-blog
 [emberjs/core-notes]: https://github.com/emberjs/core-notes
-[fireship-io/10-javascript-frameworks]:
-  https://github.com/fireship-io/10-javascript-frameworks
-[locks/10-javascript-frameworks]:
-  https://github.com/locks/10-javascript-frameworks
+[fireship-io/10-javascript-frameworks]: https://github.com/fireship-io/10-javascript-frameworks
+[locks/10-javascript-frameworks]: https://github.com/locks/10-javascript-frameworks
 [nickschot/ember-europe-demo]: https://github.com/nickschot/ember-europe-demo
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
-[octokit/plugin-rest-endpoint-methods.js]:
-  https://github.com/octokit/plugin-rest-endpoint-methods.js
+[octokit/plugin-rest-endpoint-methods.js]: https://github.com/octokit/plugin-rest-endpoint-methods.js
 [semantic-release/github]: https://github.com/semantic-release/github
-[mainmatter/ember-intl-analyzer]:
-  https://github.com/mainmatter/ember-intl-analyzer
+[mainmatter/ember-intl-analyzer]: https://github.com/mainmatter/ember-intl-analyzer
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
 [yaacov/node-modbus-serial]: https://github.com/yaacov/node-modbus-serial
diff --git a/src/twios/2022-04-19.md b/src/twios/2022-04-19.md
index 706cbe9902..affe5c37be 100644
--- a/src/twios/2022-04-19.md
+++ b/src/twios/2022-04-19.md
@@ -1,100 +1,44 @@
 ## Ember.js
 
-- [GavinJoyce/ember-headlessui]
-  [#140](https://github.com/GavinJoyce/ember-headlessui/pull/140) add floating
-  test from addon blueprint ([@mansona])
-- [GavinJoyce/ember-headlessui]
-  [#139](https://github.com/GavinJoyce/ember-headlessui/pull/139) fix
-  rootElement when running in /tests ([@mansona])
-- [buschtoens/ember-link]
-  [#711](https://github.com/buschtoens/ember-link/pull/711) Update `.npmignore`
-  file ([@Turbo87])
-- [ember-learn/ember-blog]
-  [#1148](https://github.com/ember-learn/ember-blog/pull/1148) Release v4.3
-  ([@locks])
-- [ember-learn/guides-source]
-  [#1806](https://github.com/ember-learn/guides-source/pull/1806) v4.3.0
-  ([@locks])
-- [ember-learn/guides-source]
-  [#1802](https://github.com/ember-learn/guides-source/pull/1802) Fix Ember Data
-  call out regarding store ([@locks])
-- [emberjs/ember.js] [#20060](https://github.com/emberjs/ember.js/pull/20060)
-  Improve named block-related API documentation ([@locks])
-- [emberjs/ember.js] [#20059](https://github.com/emberjs/ember.js/pull/20059)
-  use Math.sign for spaceship function implementation ([@locks])
-- [empress/rfc-process] [#7](https://github.com/empress/rfc-process/pull/7) add
-  frontmatter attributes to rfcs ([@mansona])
-- [mansona/ember-get-config]
-  [#38](https://github.com/mansona/ember-get-config/pull/38) add type
-  declaration file ([@mansona])
-- [mansona/ember-get-config]
-  [#35](https://github.com/mansona/ember-get-config/pull/35) make sure that
-  config is from the test environment when running /tests ([@mansona])
-- [nickschot/ember-mobile-menu]
-  [#271](https://github.com/nickschot/ember-mobile-menu/pull/271) Update
-  renovate configuration ([@nickschot])
-- [qonto/ember-cp-validations]
-  [#15](https://github.com/qonto/ember-cp-validations/pull/15) Fix all
-  deprecations except `computed-property.volatile` ([@zeppelin])
-- [qonto/ember-cp-validations]
-  [#14](https://github.com/qonto/ember-cp-validations/pull/14) Set up
-  deprecation workflow ([@zeppelin])
-- [qonto/ember-cp-validations]
-  [#12](https://github.com/qonto/ember-cp-validations/pull/12) Lint HBS files
-  ([@zeppelin])
-- [mainmatter/ember-hbs-minifier]
-  [#501](https://github.com/mainmatter/ember-hbs-minifier/pull/501) Enable
-  parallel file processing for `ember-cli-babel` ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#496](https://github.com/mainmatter/ember-hbs-minifier/pull/496) Update peer
-  requirements ([@Turbo87])
-- [mainmatter/ember-hbs-minifier]
-  [#495](https://github.com/mainmatter/ember-hbs-minifier/pull/495) tests: Add
-  `this.` prefix to templates ([@Turbo87])
-- [mainmatter/ember-promise-modals]
-  [#598](https://github.com/mainmatter/ember-promise-modals/pull/598) Refactor
-  handling of `focusTrap.onDeactivate` method ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#597](https://github.com/mainmatter/ember-promise-modals/pull/597) Remove
-  deprecated `clickOutsideDeactivates` option ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#596](https://github.com/mainmatter/ember-promise-modals/pull/596) Ensure
-  calls to `@close` run before the focus-out deactivation ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#594](https://github.com/mainmatter/ember-promise-modals/pull/594) Configure
-  release-it ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#588](https://github.com/mainmatter/ember-promise-modals/pull/588) Use
-  ember-auto-import@2 ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#570](https://github.com/mainmatter/ember-promise-modals/pull/570) Setup
-  Renovatebot ([@nickschot])
-- [mainmatter/ember-workshop]
-  [#618](https://github.com/mainmatter/ember-workshop/pull/618) Migrate to
-  Embroider + pNPM ([@zeppelin])
+- [GavinJoyce/ember-headlessui] [#140](https://github.com/GavinJoyce/ember-headlessui/pull/140) add floating test from addon blueprint ([@mansona])
+- [GavinJoyce/ember-headlessui] [#139](https://github.com/GavinJoyce/ember-headlessui/pull/139) fix rootElement when running in /tests ([@mansona])
+- [buschtoens/ember-link] [#711](https://github.com/buschtoens/ember-link/pull/711) Update `.npmignore` file ([@Turbo87])
+- [ember-learn/ember-blog] [#1148](https://github.com/ember-learn/ember-blog/pull/1148) Release v4.3 ([@locks])
+- [ember-learn/guides-source] [#1806](https://github.com/ember-learn/guides-source/pull/1806) v4.3.0 ([@locks])
+- [ember-learn/guides-source] [#1802](https://github.com/ember-learn/guides-source/pull/1802) Fix Ember Data call out regarding store ([@locks])
+- [emberjs/ember.js] [#20060](https://github.com/emberjs/ember.js/pull/20060) Improve named block-related API documentation ([@locks])
+- [emberjs/ember.js] [#20059](https://github.com/emberjs/ember.js/pull/20059) use Math.sign for spaceship function implementation ([@locks])
+- [empress/rfc-process] [#7](https://github.com/empress/rfc-process/pull/7) add frontmatter attributes to rfcs ([@mansona])
+- [mansona/ember-get-config] [#38](https://github.com/mansona/ember-get-config/pull/38) add type declaration file ([@mansona])
+- [mansona/ember-get-config] [#35](https://github.com/mansona/ember-get-config/pull/35) make sure that config is from the test environment when running /tests ([@mansona])
+- [nickschot/ember-mobile-menu] [#271](https://github.com/nickschot/ember-mobile-menu/pull/271) Update renovate configuration ([@nickschot])
+- [qonto/ember-cp-validations] [#15](https://github.com/qonto/ember-cp-validations/pull/15) Fix all deprecations except `computed-property.volatile` ([@zeppelin])
+- [qonto/ember-cp-validations] [#14](https://github.com/qonto/ember-cp-validations/pull/14) Set up deprecation workflow ([@zeppelin])
+- [qonto/ember-cp-validations] [#12](https://github.com/qonto/ember-cp-validations/pull/12) Lint HBS files ([@zeppelin])
+- [mainmatter/ember-hbs-minifier] [#501](https://github.com/mainmatter/ember-hbs-minifier/pull/501) Enable parallel file processing for `ember-cli-babel` ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#496](https://github.com/mainmatter/ember-hbs-minifier/pull/496) Update peer requirements ([@Turbo87])
+- [mainmatter/ember-hbs-minifier] [#495](https://github.com/mainmatter/ember-hbs-minifier/pull/495) tests: Add `this.` prefix to templates ([@Turbo87])
+- [mainmatter/ember-promise-modals] [#598](https://github.com/mainmatter/ember-promise-modals/pull/598) Refactor handling of `focusTrap.onDeactivate` method ([@pichfl])
+- [mainmatter/ember-promise-modals] [#597](https://github.com/mainmatter/ember-promise-modals/pull/597) Remove deprecated `clickOutsideDeactivates` option ([@pichfl])
+- [mainmatter/ember-promise-modals] [#596](https://github.com/mainmatter/ember-promise-modals/pull/596) Ensure calls to `@close` run before the focus-out deactivation ([@pichfl])
+- [mainmatter/ember-promise-modals] [#594](https://github.com/mainmatter/ember-promise-modals/pull/594) Configure release-it ([@pichfl])
+- [mainmatter/ember-promise-modals] [#588](https://github.com/mainmatter/ember-promise-modals/pull/588) Use ember-auto-import@2 ([@pichfl])
+- [mainmatter/ember-promise-modals] [#570](https://github.com/mainmatter/ember-promise-modals/pull/570) Setup Renovatebot ([@nickschot])
+- [mainmatter/ember-workshop] [#618](https://github.com/mainmatter/ember-workshop/pull/618) Migrate to Embroider + pNPM ([@zeppelin])
 
 ## JavaScript
 
-- [yaacov/node-modbus-serial]
-  [#453](https://github.com/yaacov/node-modbus-serial/pull/453) Use let/const
-  instead of var ([@Turbo87])
-- [actions/setup-python]
-  [#379](https://github.com/actions/setup-python/pull/379) ci(workflow): add
-  cache to workflows using actions/setup-node ([@oscard0m])
+- [yaacov/node-modbus-serial] [#453](https://github.com/yaacov/node-modbus-serial/pull/453) Use let/const instead of var ([@Turbo87])
+- [actions/setup-python] [#379](https://github.com/actions/setup-python/pull/379) ci(workflow): add cache to workflows using actions/setup-node ([@oscard0m])
 
 ## Octokit
 
-- [octokit/auth-token.js]
-  [#219](https://github.com/octokit/auth-token.js/pull/219) ci(codeql): remove
-  unnecessary step to checkout HEAD~2 from PRs ([@oscard0m])
-- [octokit/auth-token.js]
-  [#217](https://github.com/octokit/auth-token.js/pull/217) ci(codeql): ignore
-  on push events for dependabot branches ([@oscard0m])
+- [octokit/auth-token.js] [#219](https://github.com/octokit/auth-token.js/pull/219) ci(codeql): remove unnecessary step to checkout HEAD~2 from PRs ([@oscard0m])
+- [octokit/auth-token.js] [#217](https://github.com/octokit/auth-token.js/pull/217) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
 
 ## Miscellaneous
 
-- [netlify/build-image] [#778](https://github.com/netlify/build-image/pull/778)
-  add webm to the default fetchinclude ([@mansona])
+- [netlify/build-image] [#778](https://github.com/netlify/build-image/pull/778) add webm to the default fetchinclude ([@mansona])
 
 [@turbo87]: https://github.com/Turbo87
 [@locks]: https://github.com/locks
@@ -114,12 +58,9 @@
 [netlify/build-image]: https://github.com/netlify/build-image
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
 [octokit/auth-token.js]: https://github.com/octokit/auth-token.js
-[offirgolan/ember-cp-validations]:
-  https://github.com/offirgolan/ember-cp-validations
+[offirgolan/ember-cp-validations]: https://github.com/offirgolan/ember-cp-validations
 [qonto/ember-cp-validations]: https://github.com/qonto/ember-cp-validations
-[mainmatter/ember-hbs-minifier]:
-  https://github.com/mainmatter/ember-hbs-minifier
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-hbs-minifier]: https://github.com/mainmatter/ember-hbs-minifier
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [mainmatter/ember-workshop]: https://github.com/mainmatter/ember-workshop
 [yaacov/node-modbus-serial]: https://github.com/yaacov/node-modbus-serial
diff --git a/src/twios/2022-05-09.md b/src/twios/2022-05-09.md
index 9c91f0b6c8..63907d6f6f 100644
--- a/src/twios/2022-05-09.md
+++ b/src/twios/2022-05-09.md
@@ -1,194 +1,81 @@
 ## Highlight
 
-Tobias Bieniek has been contributing to
-[RenovateBot](https://github.com/renovatebot/renovate), a bot for automated
-dependency updates.
+Tobias Bieniek has been contributing to [RenovateBot](https://github.com/renovatebot/renovate), a bot for automated dependency updates.
 
-His PR [15214](https://github.com/renovatebot/renovate/pull/15214) added
-changelogs to Rust crate update PRs by downloading #crate metadata
-from [crates.io](http://crates.io/). It also uses a fast path on
-the [crates.io](http://crates.io/) server to avoid unnecessary database
-requests.
+His PR [15214](https://github.com/renovatebot/renovate/pull/15214) added changelogs to Rust crate update PRs by downloading #crate metadata from [crates.io](http://crates.io/). It also uses a fast path on the [crates.io](http://crates.io/) server to avoid unnecessary database requests.
 
 ## Ember.js
 
-- [Turbo87/intellij-emberjs]
-  [#440](https://github.com/Turbo87/intellij-emberjs/pull/440) Fix
-  `LineMarkerInfo` deprecation error ([@Turbo87])
-- [ember-learn/ember-styleguide]
-  [#418](https://github.com/ember-learn/ember-styleguide/pull/418) update
-  lint-to-the-future dashboard workflow ([@mansona])
-- [ember-learn/guides-source]
-  [#1814](https://github.com/ember-learn/guides-source/pull/1814) Fix typo in
-  linking-between-routes.md ([@locks])
-- [empress/ember-showdown-prism]
-  [#25](https://github.com/empress/ember-showdown-prism/pull/25) add typescript
-  and diff components ([@mansona])
-- [empress/empress-blog]
-  [#159](https://github.com/empress/empress-blog/pull/159) update lttf dashboard
-  workflow ([@mansona])
-- [empress/rfc-process] [#10](https://github.com/empress/rfc-process/pull/10)
-  Update to 3.28 with ember-cli-update ([@mansona])
-- [empress/rfc-process] [#9](https://github.com/empress/rfc-process/pull/9) fix
-  prember urls ([@mansona])
-- [empress/rfc-process] [#8](https://github.com/empress/rfc-process/pull/8) Add
-  stages and teams models and data processing ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#7](https://github.com/empress/rfc-process-mdbook-template/pull/7) Add
-  frontmatter implementation ([@mansona])
-- [mansona/ember-get-config]
-  [#41](https://github.com/mansona/ember-get-config/pull/41) breaking: re-export
-  configModule to reduce duplication and fix dynamic config ([@mansona])
-- [offirgolan/ember-cp-validations]
-  [#705](https://github.com/offirgolan/ember-cp-validations/pull/705) Add
-  missing changelog entries ([@zeppelin])
-- [qonto/ember-cp-validations]
-  [#18](https://github.com/qonto/ember-cp-validations/pull/18) Remove volatile
-  support & enable Ember 4 tests ([@zeppelin])
-- [qonto/ember-cp-validations]
-  [#17](https://github.com/qonto/ember-cp-validations/pull/17) Remove support
-  for Ember < 3.28 ([@zeppelin])
-- [qonto/ember-cp-validations]
-  [#16](https://github.com/qonto/ember-cp-validations/pull/16) Add missing
-  changelog entries ([@zeppelin])
-- [mainmatter/ember-cookies]
-  [#742](https://github.com/mainmatter/ember-cookies/pull/742) ci(renovate): use
-  renovate's json5 preset ([@oscard0m])
-- [mainmatter/ember-cookies]
-  [#739](https://github.com/mainmatter/ember-cookies/pull/739) ci(renovate): add
-  renovate config ([@oscard0m])
-- [mainmatter/ember-hotspots]
-  [#27](https://github.com/mainmatter/ember-hotspots/pull/27) Bring back
-  `ember-get-config` ([@pichfl])
-- [mainmatter/ember-hotspots]
-  [#26](https://github.com/mainmatter/ember-hotspots/pull/26) Remove
-  ember-get-config ([@pichfl])
-- [mainmatter/ember-hotspots]
-  [#24](https://github.com/mainmatter/ember-hotspots/pull/24) Ensure hostspots
-  are loaded from the right URL ([@pichfl])
-- [mainmatter/ember-hotspots]
-  [#23](https://github.com/mainmatter/ember-hotspots/pull/23) Remove duplicated
-  `ember-fetch` dependency ([@pichfl])
-- [mainmatter/ember-hotspots]
-  [#17](https://github.com/mainmatter/ember-hotspots/pull/17) Update addon
-  blueprint and dependencies ([@pichfl])
-- [mainmatter/ember-hotspots]
-  [#11](https://github.com/mainmatter/ember-hotspots/pull/11) Setup Renovatebot
-  ([@pichfl])
-- [mainmatter/ember-hotspots]
-  [#10](https://github.com/mainmatter/ember-hotspots/pull/10) Replace Yarn with
-  pnpm ([@pichfl])
-- [mainmatter/ember-simple-auth]
-  [#2379](https://github.com/mainmatter/ember-simple-auth/pull/2379) disable
-  dependabot ([@marcoow])
-- [mainmatter/ember-simple-auth]
-  [#2369](https://github.com/mainmatter/ember-simple-auth/pull/2369) Add cache
-  to node workflows ([@marcoow])
-- [mainmatter/ember-simple-auth]
-  [#2368](https://github.com/mainmatter/ember-simple-auth/pull/2368) Upgrade
-  ESLint configuration ([@pichfl])
-- [mainmatter/ember-simple-auth]
-  [#2409](https://github.com/mainmatter/ember-simple-auth/pull/2409)
-  ci(renovate): use renovate's json5 preset ([@oscard0m])
-- [mainmatter/ember-simple-auth]
-  [#2370](https://github.com/mainmatter/ember-simple-auth/pull/2370)
-  ci(renovate): add renovate configuration ([@oscard0m])
+- [Turbo87/intellij-emberjs] [#440](https://github.com/Turbo87/intellij-emberjs/pull/440) Fix `LineMarkerInfo` deprecation error ([@Turbo87])
+- [ember-learn/ember-styleguide] [#418](https://github.com/ember-learn/ember-styleguide/pull/418) update lint-to-the-future dashboard workflow ([@mansona])
+- [ember-learn/guides-source] [#1814](https://github.com/ember-learn/guides-source/pull/1814) Fix typo in linking-between-routes.md ([@locks])
+- [empress/ember-showdown-prism] [#25](https://github.com/empress/ember-showdown-prism/pull/25) add typescript and diff components ([@mansona])
+- [empress/empress-blog] [#159](https://github.com/empress/empress-blog/pull/159) update lttf dashboard workflow ([@mansona])
+- [empress/rfc-process] [#10](https://github.com/empress/rfc-process/pull/10) Update to 3.28 with ember-cli-update ([@mansona])
+- [empress/rfc-process] [#9](https://github.com/empress/rfc-process/pull/9) fix prember urls ([@mansona])
+- [empress/rfc-process] [#8](https://github.com/empress/rfc-process/pull/8) Add stages and teams models and data processing ([@mansona])
+- [empress/rfc-process-mdbook-template] [#7](https://github.com/empress/rfc-process-mdbook-template/pull/7) Add frontmatter implementation ([@mansona])
+- [mansona/ember-get-config] [#41](https://github.com/mansona/ember-get-config/pull/41) breaking: re-export configModule to reduce duplication and fix dynamic config ([@mansona])
+- [offirgolan/ember-cp-validations] [#705](https://github.com/offirgolan/ember-cp-validations/pull/705) Add missing changelog entries ([@zeppelin])
+- [qonto/ember-cp-validations] [#18](https://github.com/qonto/ember-cp-validations/pull/18) Remove volatile support & enable Ember 4 tests ([@zeppelin])
+- [qonto/ember-cp-validations] [#17](https://github.com/qonto/ember-cp-validations/pull/17) Remove support for Ember < 3.28 ([@zeppelin])
+- [qonto/ember-cp-validations] [#16](https://github.com/qonto/ember-cp-validations/pull/16) Add missing changelog entries ([@zeppelin])
+- [mainmatter/ember-cookies] [#742](https://github.com/mainmatter/ember-cookies/pull/742) ci(renovate): use renovate's json5 preset ([@oscard0m])
+- [mainmatter/ember-cookies] [#739](https://github.com/mainmatter/ember-cookies/pull/739) ci(renovate): add renovate config ([@oscard0m])
+- [mainmatter/ember-hotspots] [#27](https://github.com/mainmatter/ember-hotspots/pull/27) Bring back `ember-get-config` ([@pichfl])
+- [mainmatter/ember-hotspots] [#26](https://github.com/mainmatter/ember-hotspots/pull/26) Remove ember-get-config ([@pichfl])
+- [mainmatter/ember-hotspots] [#24](https://github.com/mainmatter/ember-hotspots/pull/24) Ensure hostspots are loaded from the right URL ([@pichfl])
+- [mainmatter/ember-hotspots] [#23](https://github.com/mainmatter/ember-hotspots/pull/23) Remove duplicated `ember-fetch` dependency ([@pichfl])
+- [mainmatter/ember-hotspots] [#17](https://github.com/mainmatter/ember-hotspots/pull/17) Update addon blueprint and dependencies ([@pichfl])
+- [mainmatter/ember-hotspots] [#11](https://github.com/mainmatter/ember-hotspots/pull/11) Setup Renovatebot ([@pichfl])
+- [mainmatter/ember-hotspots] [#10](https://github.com/mainmatter/ember-hotspots/pull/10) Replace Yarn with pnpm ([@pichfl])
+- [mainmatter/ember-simple-auth] [#2379](https://github.com/mainmatter/ember-simple-auth/pull/2379) disable dependabot ([@marcoow])
+- [mainmatter/ember-simple-auth] [#2369](https://github.com/mainmatter/ember-simple-auth/pull/2369) Add cache to node workflows ([@marcoow])
+- [mainmatter/ember-simple-auth] [#2368](https://github.com/mainmatter/ember-simple-auth/pull/2368) Upgrade ESLint configuration ([@pichfl])
+- [mainmatter/ember-simple-auth] [#2409](https://github.com/mainmatter/ember-simple-auth/pull/2409) ci(renovate): use renovate's json5 preset ([@oscard0m])
+- [mainmatter/ember-simple-auth] [#2370](https://github.com/mainmatter/ember-simple-auth/pull/2370) ci(renovate): add renovate configuration ([@oscard0m])
 
 ## Internal
 
-- [mainmatter/renovate-config]
-  [#8](https://github.com/mainmatter/renovate-config/pull/8)
-  chore(default.json): remove default.json ([@oscard0m])
-- [mainmatter/renovate-config]
-  [#4](https://github.com/mainmatter/renovate-config/pull/4) refactor(renovate):
-  restore .json5 configuration ([@oscard0m])
-- [mainmatter/renovate-config]
-  [#3](https://github.com/mainmatter/renovate-config/pull/3) feat(renovate): add
-  ':preserveSemverRanges' ([@oscard0m])
-- [mainmatter/renovate-config]
-  [#2](https://github.com/mainmatter/renovate-config/pull/2) refactor(renovate):
-  use .json instead of .json5 format for config ([@oscard0m])
+- [mainmatter/renovate-config] [#8](https://github.com/mainmatter/renovate-config/pull/8) chore(default.json): remove default.json ([@oscard0m])
+- [mainmatter/renovate-config] [#4](https://github.com/mainmatter/renovate-config/pull/4) refactor(renovate): restore .json5 configuration ([@oscard0m])
+- [mainmatter/renovate-config] [#3](https://github.com/mainmatter/renovate-config/pull/3) feat(renovate): add ':preserveSemverRanges' ([@oscard0m])
+- [mainmatter/renovate-config] [#2](https://github.com/mainmatter/renovate-config/pull/2) refactor(renovate): use .json instead of .json5 format for config ([@oscard0m])
 
 ## JavaScript
 
-- [showdownjs/showdown] [#918](https://github.com/showdownjs/showdown/pull/918)
-  Add updated CommonMark Tests ([@mansona])
+- [showdownjs/showdown] [#918](https://github.com/showdownjs/showdown/pull/918) Add updated CommonMark Tests ([@mansona])
 
 ## Rust
 
-- [Turbo87/united-flarmnet]
-  [#78](https://github.com/Turbo87/united-flarmnet/pull/78) Inline unnecessary
-  functions ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#76](https://github.com/Turbo87/united-flarmnet/pull/76) Extract `merge()`
-  function ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#75](https://github.com/Turbo87/united-flarmnet/pull/75) Run HTTP requests in
-  parallel ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#74](https://github.com/Turbo87/united-flarmnet/pull/74) Use `reqwest_retry`
-  to retry failed requests ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#73](https://github.com/Turbo87/united-flarmnet/pull/73) Replace custom cache
-  with `http_cache_reqwest` middleware ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#72](https://github.com/Turbo87/united-flarmnet/pull/72) Use
-  `reqwest-tracing` for additional debug output ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#71](https://github.com/Turbo87/united-flarmnet/pull/71) Use async/await for
-  HTTP reqwests ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#70](https://github.com/Turbo87/united-flarmnet/pull/70) Migrate from `ureq`
-  to `reqwest` ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#69](https://github.com/Turbo87/united-flarmnet/pull/69) Use WeGlide devices
-  API ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#68](https://github.com/Turbo87/united-flarmnet/pull/68) Deploy built binary
-  to GitHub Pages ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#67](https://github.com/Turbo87/united-flarmnet/pull/67) Simplify unnecessary
-  closure functions ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#66](https://github.com/Turbo87/united-flarmnet/pull/66) clippy: Adjust
-  deprecated rule name ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#65](https://github.com/Turbo87/united-flarmnet/pull/65) sanitize: Use `char`
-  instead of `&str` for single character search strings ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#62](https://github.com/Turbo87/united-flarmnet/pull/62) Add
-  `rust-toolchain.toml` file ([@Turbo87])
-- [ferrous-systems/teaching-material]
-  [#106](https://github.com/ferrous-systems/teaching-material/pull/106)
-  installation: Adjust `IntelliJ` link ([@Turbo87])
-- [ferrous-systems/teaching-material]
-  [#103](https://github.com/ferrous-systems/teaching-material/pull/103)
-  Partially revert "remove `extern crate`" ([@Turbo87])
-- [ferrous-systems/teaching-material]
-  [#102](https://github.com/ferrous-systems/teaching-material/pull/102)
-  presentations/imports-modules-and-visibility: Add missing `struct` keyword
-  ([@Turbo87])
-- [ferrous-systems/teaching-material]
-  [#101](https://github.com/ferrous-systems/teaching-material/pull/101)
-  presentations/cargo: Fix dependency category name ([@Turbo87])
+- [Turbo87/united-flarmnet] [#78](https://github.com/Turbo87/united-flarmnet/pull/78) Inline unnecessary functions ([@Turbo87])
+- [Turbo87/united-flarmnet] [#76](https://github.com/Turbo87/united-flarmnet/pull/76) Extract `merge()` function ([@Turbo87])
+- [Turbo87/united-flarmnet] [#75](https://github.com/Turbo87/united-flarmnet/pull/75) Run HTTP requests in parallel ([@Turbo87])
+- [Turbo87/united-flarmnet] [#74](https://github.com/Turbo87/united-flarmnet/pull/74) Use `reqwest_retry` to retry failed requests ([@Turbo87])
+- [Turbo87/united-flarmnet] [#73](https://github.com/Turbo87/united-flarmnet/pull/73) Replace custom cache with `http_cache_reqwest` middleware ([@Turbo87])
+- [Turbo87/united-flarmnet] [#72](https://github.com/Turbo87/united-flarmnet/pull/72) Use `reqwest-tracing` for additional debug output ([@Turbo87])
+- [Turbo87/united-flarmnet] [#71](https://github.com/Turbo87/united-flarmnet/pull/71) Use async/await for HTTP reqwests ([@Turbo87])
+- [Turbo87/united-flarmnet] [#70](https://github.com/Turbo87/united-flarmnet/pull/70) Migrate from `ureq` to `reqwest` ([@Turbo87])
+- [Turbo87/united-flarmnet] [#69](https://github.com/Turbo87/united-flarmnet/pull/69) Use WeGlide devices API ([@Turbo87])
+- [Turbo87/united-flarmnet] [#68](https://github.com/Turbo87/united-flarmnet/pull/68) Deploy built binary to GitHub Pages ([@Turbo87])
+- [Turbo87/united-flarmnet] [#67](https://github.com/Turbo87/united-flarmnet/pull/67) Simplify unnecessary closure functions ([@Turbo87])
+- [Turbo87/united-flarmnet] [#66](https://github.com/Turbo87/united-flarmnet/pull/66) clippy: Adjust deprecated rule name ([@Turbo87])
+- [Turbo87/united-flarmnet] [#65](https://github.com/Turbo87/united-flarmnet/pull/65) sanitize: Use `char` instead of `&str` for single character search strings ([@Turbo87])
+- [Turbo87/united-flarmnet] [#62](https://github.com/Turbo87/united-flarmnet/pull/62) Add `rust-toolchain.toml` file ([@Turbo87])
+- [ferrous-systems/teaching-material] [#106](https://github.com/ferrous-systems/teaching-material/pull/106) installation: Adjust `IntelliJ` link ([@Turbo87])
+- [ferrous-systems/teaching-material] [#103](https://github.com/ferrous-systems/teaching-material/pull/103) Partially revert "remove `extern crate`" ([@Turbo87])
+- [ferrous-systems/teaching-material] [#102](https://github.com/ferrous-systems/teaching-material/pull/102) presentations/imports-modules-and-visibility: Add missing `struct` keyword ([@Turbo87])
+- [ferrous-systems/teaching-material] [#101](https://github.com/ferrous-systems/teaching-material/pull/101) presentations/cargo: Fix dependency category name ([@Turbo87])
 
 ## TypeScript
 
-- [renovatebot/renovate]
-  [#15214](https://github.com/renovatebot/renovate/pull/15214)
-  feat(datasource/crate): fetch crate metadata from crates.io ([@Turbo87])
-- [renovatebot/renovate]
-  [#15377](https://github.com/renovatebot/renovate/pull/15377) feat(presets):
-  add support to presets ending with `.json5` or `.json` ([@oscard0m])
+- [renovatebot/renovate] [#15214](https://github.com/renovatebot/renovate/pull/15214) feat(datasource/crate): fetch crate metadata from crates.io ([@Turbo87])
+- [renovatebot/renovate] [#15377](https://github.com/renovatebot/renovate/pull/15377) feat(presets): add support to presets ending with `.json5` or `.json` ([@oscard0m])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4788](https://github.com/rust-lang/crates.io/pull/4788) Sentry: Set
-  transaction name instead of custom `routeName` tag ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4781](https://github.com/rust-lang/crates.io/pull/4781) Disable in-browser
-  translation ([@Turbo87])
+- [rust-lang/crates.io] [#4788](https://github.com/rust-lang/crates.io/pull/4788) Sentry: Set transaction name instead of custom `routeName` tag ([@Turbo87])
+- [rust-lang/crates.io] [#4781](https://github.com/rust-lang/crates.io/pull/4781) Disable in-browser translation ([@Turbo87])
 
 [@turbo87]: https://github.com/Turbo87
 [@locks]: https://github.com/locks
@@ -203,14 +90,11 @@ requests.
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [empress/ember-showdown-prism]: https://github.com/empress/ember-showdown-prism
 [empress/empress-blog]: https://github.com/empress/empress-blog
-[empress/rfc-process-mdbook-template]:
-  https://github.com/empress/rfc-process-mdbook-template
+[empress/rfc-process-mdbook-template]: https://github.com/empress/rfc-process-mdbook-template
 [empress/rfc-process]: https://github.com/empress/rfc-process
-[ferrous-systems/teaching-material]:
-  https://github.com/ferrous-systems/teaching-material
+[ferrous-systems/teaching-material]: https://github.com/ferrous-systems/teaching-material
 [mansona/ember-get-config]: https://github.com/mansona/ember-get-config
-[offirgolan/ember-cp-validations]:
-  https://github.com/offirgolan/ember-cp-validations
+[offirgolan/ember-cp-validations]: https://github.com/offirgolan/ember-cp-validations
 [qonto/ember-cp-validations]: https://github.com/qonto/ember-cp-validations
 [renovatebot/renovate]: https://github.com/renovatebot/renovate
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
diff --git a/src/twios/2022-06-08.md b/src/twios/2022-06-08.md
index e12164085e..688069ceab 100644
--- a/src/twios/2022-06-08.md
+++ b/src/twios/2022-06-08.md
@@ -1,242 +1,100 @@
 ## Ember.js
 
-- [ember-cli/ember-try] [#850](https://github.com/ember-cli/ember-try/pull/850)
-  Add support for npm overrides ([@mansona])
-- [ember-learn/ember-blog]
-  [#1154](https://github.com/ember-learn/ember-blog/pull/1154) Release v4.4
-  ([@locks])
-- [ember-learn/ember-blog]
-  [#1157](https://github.com/ember-learn/ember-blog/pull/1157) fix the canonical
-  declaration of re-posted content ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#422](https://github.com/ember-learn/ember-styleguide/pull/422) Fix CI
-  ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#420](https://github.com/ember-learn/ember-styleguide/pull/420) Update some
-  dependencies ([@mansona])
-- [ember-learn/guides-source]
-  [#1821](https://github.com/ember-learn/guides-source/pull/1821) Backport code
-  sample diff ([@locks])
-- [ember-learn/guides-source]
-  [#1820](https://github.com/ember-learn/guides-source/pull/1820) v4.4.0
-  ([@locks])
-- [ember-learn/handbook] [#68](https://github.com/ember-learn/handbook/pull/68)
-  Update ember-releases.md ([@locks])
-- [emberjs/core-notes] [#453](https://github.com/emberjs/core-notes/pull/453)
-  add learning meeting notes for 2022-05-30 ([@mansona])
-- [emberjs/core-notes] [#450](https://github.com/emberjs/core-notes/pull/450)
-  Learning team Meeting - 9th May ([@mansona])
-- [emberjs/data] [#8000](https://github.com/emberjs/data/pull/8000)
-  promise-proxies: Fix "Cannot read properties of undefined (reading 'bind')"
-  error ([@Turbo87])
-- [emberjs/rfcs] [#818](https://github.com/emberjs/rfcs/pull/818) Fix stage for
-  accepted RFCs ([@locks])
-- [empress/field-guide] [#58](https://github.com/empress/field-guide/pull/58)
-  WIP fix dynamic component to support embroider-optimised ([@mansona])
-- [empress/rfc-process] [#17](https://github.com/empress/rfc-process/pull/17)
-  update mdbook-template for testing ([@mansona])
-- [empress/rfc-process] [#16](https://github.com/empress/rfc-process/pull/16)
-  fix prettier lints ([@mansona])
-- [empress/rfc-process] [#15](https://github.com/empress/rfc-process/pull/15)
-  add order to stages model ([@mansona])
-- [empress/rfc-process] [#14](https://github.com/empress/rfc-process/pull/14)
-  Fix some lints from Lint to the Future dashboard ([@mansona])
-- [empress/rfc-process] [#13](https://github.com/empress/rfc-process/pull/13)
-  navigate to all pages in a test ([@mansona])
-- [empress/rfc-process] [#12](https://github.com/empress/rfc-process/pull/12)
-  Add grouped Table of Contents file ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#13](https://github.com/empress/rfc-process-mdbook-template/pull/13) UI
-  tweaks ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#12](https://github.com/empress/rfc-process-mdbook-template/pull/12) Group
-  the Table of Contents by Stage ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#11](https://github.com/empress/rfc-process-mdbook-template/pull/11) Fix last
-  two lints from Lint to the Future dashboard ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#10](https://github.com/empress/rfc-process-mdbook-template/pull/10) Add a
-  tests that visits all routes ([@mansona])
-- [mansona/ember-get-config]
-  [#44](https://github.com/mansona/ember-get-config/pull/44) Fix fastboot double
-  wrapping default export/import ([@mansona])
-- [mansona/ember-html-excerpt]
-  [#5](https://github.com/mansona/ember-html-excerpt/pull/5) update downsize-cjs
-  to allow it to support esm directly ([@mansona])
-- [mansona/ember-html-excerpt]
-  [#4](https://github.com/mansona/ember-html-excerpt/pull/4) add deprecation
-  checks with ember-try ([@mansona])
-- [mansona/ember-html-excerpt]
-  [#3](https://github.com/mansona/ember-html-excerpt/pull/3) Support Ember 4.x
-  ([@mansona])
-- [mansona/ember-html-excerpt]
-  [#2](https://github.com/mansona/ember-html-excerpt/pull/2) update to 3.28 with
-  ember-cli-update ([@mansona])
-- [mansona/ember-html-excerpt]
-  [#1](https://github.com/mansona/ember-html-excerpt/pull/1) Fix CI ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1220](https://github.com/miguelcobain/ember-paper/pull/1220) Convert
-  PaperGridList to native class syntax ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1219](https://github.com/miguelcobain/ember-paper/pull/1219) upgrade
-  angular-material-styles to remove sass deprecation ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1218](https://github.com/miguelcobain/ember-paper/pull/1218) Remove
-  ember-cp-validations from demo application ([@mansona])
-- [mainmatter/ember-promise-modals]
-  [#688](https://github.com/mainmatter/ember-promise-modals/pull/688) Prefer
-  "happy path" code style for `_resolve()` ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#687](https://github.com/mainmatter/ember-promise-modals/pull/687) Extract
-  destruction of the modals effects into a method and apply them ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#686](https://github.com/mainmatter/ember-promise-modals/pull/686) Closing
-  the modal should inform the modals service ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#685](https://github.com/mainmatter/ember-promise-modals/pull/685) Move
-  attaching/detaching `animationend` event handler into methods and generalize
-  related names ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#684](https://github.com/mainmatter/ember-promise-modals/pull/684) Move
-  focusTrap setup/teardown to methods ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#683](https://github.com/mainmatter/ember-promise-modals/pull/683) Replace
-  retained element reference with a method ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#682](https://github.com/mainmatter/ember-promise-modals/pull/682) Improve
-  test helper ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#672](https://github.com/mainmatter/ember-promise-modals/pull/672) Enable
-  `onAnimationModalInEnd` callback ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#671](https://github.com/mainmatter/ember-promise-modals/pull/671) Pin
-  dependencies ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#670](https://github.com/mainmatter/ember-promise-modals/pull/670) Version
-  updates ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#669](https://github.com/mainmatter/ember-promise-modals/pull/669) Ensure
-  modal gets removed even when animationend fails ([@pichfl])
-- [mainmatter/ember-promise-modals]
-  [#681](https://github.com/mainmatter/ember-promise-modals/pull/681) remove
-  dependabot configuration ([@nickschot])
-- [mainmatter/ember-simple-auth]
-  [#2420](https://github.com/mainmatter/ember-simple-auth/pull/2420) Drop
-  support for Ember <= 3.12 ([@marcoow])
-- [mainmatter/ember-simple-auth]
-  [#2419](https://github.com/mainmatter/ember-simple-auth/pull/2419) Run CI on
-  Node 14 ([@marcoow])
-- [mainmatter/ember-simple-auth]
-  [#2418](https://github.com/mainmatter/ember-simple-auth/pull/2418) Use Volta
-  ([@marcoow])
-- [mainmatter/qunit-dom]
-  [#1600](https://github.com/mainmatter/qunit-dom/pull/1600) package.json:
-  Specify `packageManager` field ([@Turbo87])
-- [mainmatter/qunit-dom]
-  [#1598](https://github.com/mainmatter/qunit-dom/pull/1598) tests: Remove
-  `global` usage ([@Turbo87])
-- [mainmatter/qunit-dom]
-  [#1574](https://github.com/mainmatter/qunit-dom/pull/1574) Remove
-  `.pnpm-debug.log` file ([@Turbo87])
-- [mainmatter/qunit-dom]
-  [#1573](https://github.com/mainmatter/qunit-dom/pull/1573) CI: Update Node.js
-  versions ([@Turbo87])
-- [mainmatter/qunit-dom]
-  [#1572](https://github.com/mainmatter/qunit-dom/pull/1572) Remove `engines`
-  declaration from `package.json` ([@Turbo87])
+- [ember-cli/ember-try] [#850](https://github.com/ember-cli/ember-try/pull/850) Add support for npm overrides ([@mansona])
+- [ember-learn/ember-blog] [#1154](https://github.com/ember-learn/ember-blog/pull/1154) Release v4.4 ([@locks])
+- [ember-learn/ember-blog] [#1157](https://github.com/ember-learn/ember-blog/pull/1157) fix the canonical declaration of re-posted content ([@mansona])
+- [ember-learn/ember-styleguide] [#422](https://github.com/ember-learn/ember-styleguide/pull/422) Fix CI ([@mansona])
+- [ember-learn/ember-styleguide] [#420](https://github.com/ember-learn/ember-styleguide/pull/420) Update some dependencies ([@mansona])
+- [ember-learn/guides-source] [#1821](https://github.com/ember-learn/guides-source/pull/1821) Backport code sample diff ([@locks])
+- [ember-learn/guides-source] [#1820](https://github.com/ember-learn/guides-source/pull/1820) v4.4.0 ([@locks])
+- [ember-learn/handbook] [#68](https://github.com/ember-learn/handbook/pull/68) Update ember-releases.md ([@locks])
+- [emberjs/core-notes] [#453](https://github.com/emberjs/core-notes/pull/453) add learning meeting notes for 2022-05-30 ([@mansona])
+- [emberjs/core-notes] [#450](https://github.com/emberjs/core-notes/pull/450) Learning team Meeting - 9th May ([@mansona])
+- [emberjs/data] [#8000](https://github.com/emberjs/data/pull/8000) promise-proxies: Fix "Cannot read properties of undefined (reading 'bind')" error ([@Turbo87])
+- [emberjs/rfcs] [#818](https://github.com/emberjs/rfcs/pull/818) Fix stage for accepted RFCs ([@locks])
+- [empress/field-guide] [#58](https://github.com/empress/field-guide/pull/58) WIP fix dynamic component to support embroider-optimised ([@mansona])
+- [empress/rfc-process] [#17](https://github.com/empress/rfc-process/pull/17) update mdbook-template for testing ([@mansona])
+- [empress/rfc-process] [#16](https://github.com/empress/rfc-process/pull/16) fix prettier lints ([@mansona])
+- [empress/rfc-process] [#15](https://github.com/empress/rfc-process/pull/15) add order to stages model ([@mansona])
+- [empress/rfc-process] [#14](https://github.com/empress/rfc-process/pull/14) Fix some lints from Lint to the Future dashboard ([@mansona])
+- [empress/rfc-process] [#13](https://github.com/empress/rfc-process/pull/13) navigate to all pages in a test ([@mansona])
+- [empress/rfc-process] [#12](https://github.com/empress/rfc-process/pull/12) Add grouped Table of Contents file ([@mansona])
+- [empress/rfc-process-mdbook-template] [#13](https://github.com/empress/rfc-process-mdbook-template/pull/13) UI tweaks ([@mansona])
+- [empress/rfc-process-mdbook-template] [#12](https://github.com/empress/rfc-process-mdbook-template/pull/12) Group the Table of Contents by Stage ([@mansona])
+- [empress/rfc-process-mdbook-template] [#11](https://github.com/empress/rfc-process-mdbook-template/pull/11) Fix last two lints from Lint to the Future dashboard ([@mansona])
+- [empress/rfc-process-mdbook-template] [#10](https://github.com/empress/rfc-process-mdbook-template/pull/10) Add a tests that visits all routes ([@mansona])
+- [mansona/ember-get-config] [#44](https://github.com/mansona/ember-get-config/pull/44) Fix fastboot double wrapping default export/import ([@mansona])
+- [mansona/ember-html-excerpt] [#5](https://github.com/mansona/ember-html-excerpt/pull/5) update downsize-cjs to allow it to support esm directly ([@mansona])
+- [mansona/ember-html-excerpt] [#4](https://github.com/mansona/ember-html-excerpt/pull/4) add deprecation checks with ember-try ([@mansona])
+- [mansona/ember-html-excerpt] [#3](https://github.com/mansona/ember-html-excerpt/pull/3) Support Ember 4.x ([@mansona])
+- [mansona/ember-html-excerpt] [#2](https://github.com/mansona/ember-html-excerpt/pull/2) update to 3.28 with ember-cli-update ([@mansona])
+- [mansona/ember-html-excerpt] [#1](https://github.com/mansona/ember-html-excerpt/pull/1) Fix CI ([@mansona])
+- [miguelcobain/ember-paper] [#1220](https://github.com/miguelcobain/ember-paper/pull/1220) Convert PaperGridList to native class syntax ([@mansona])
+- [miguelcobain/ember-paper] [#1219](https://github.com/miguelcobain/ember-paper/pull/1219) upgrade angular-material-styles to remove sass deprecation ([@mansona])
+- [miguelcobain/ember-paper] [#1218](https://github.com/miguelcobain/ember-paper/pull/1218) Remove ember-cp-validations from demo application ([@mansona])
+- [mainmatter/ember-promise-modals] [#688](https://github.com/mainmatter/ember-promise-modals/pull/688) Prefer "happy path" code style for `_resolve()` ([@pichfl])
+- [mainmatter/ember-promise-modals] [#687](https://github.com/mainmatter/ember-promise-modals/pull/687) Extract destruction of the modals effects into a method and apply them ([@pichfl])
+- [mainmatter/ember-promise-modals] [#686](https://github.com/mainmatter/ember-promise-modals/pull/686) Closing the modal should inform the modals service ([@pichfl])
+- [mainmatter/ember-promise-modals] [#685](https://github.com/mainmatter/ember-promise-modals/pull/685) Move attaching/detaching `animationend` event handler into methods and generalize related names ([@pichfl])
+- [mainmatter/ember-promise-modals] [#684](https://github.com/mainmatter/ember-promise-modals/pull/684) Move focusTrap setup/teardown to methods ([@pichfl])
+- [mainmatter/ember-promise-modals] [#683](https://github.com/mainmatter/ember-promise-modals/pull/683) Replace retained element reference with a method ([@pichfl])
+- [mainmatter/ember-promise-modals] [#682](https://github.com/mainmatter/ember-promise-modals/pull/682) Improve test helper ([@pichfl])
+- [mainmatter/ember-promise-modals] [#672](https://github.com/mainmatter/ember-promise-modals/pull/672) Enable `onAnimationModalInEnd` callback ([@pichfl])
+- [mainmatter/ember-promise-modals] [#671](https://github.com/mainmatter/ember-promise-modals/pull/671) Pin dependencies ([@pichfl])
+- [mainmatter/ember-promise-modals] [#670](https://github.com/mainmatter/ember-promise-modals/pull/670) Version updates ([@pichfl])
+- [mainmatter/ember-promise-modals] [#669](https://github.com/mainmatter/ember-promise-modals/pull/669) Ensure modal gets removed even when animationend fails ([@pichfl])
+- [mainmatter/ember-promise-modals] [#681](https://github.com/mainmatter/ember-promise-modals/pull/681) remove dependabot configuration ([@nickschot])
+- [mainmatter/ember-simple-auth] [#2420](https://github.com/mainmatter/ember-simple-auth/pull/2420) Drop support for Ember <= 3.12 ([@marcoow])
+- [mainmatter/ember-simple-auth] [#2419](https://github.com/mainmatter/ember-simple-auth/pull/2419) Run CI on Node 14 ([@marcoow])
+- [mainmatter/ember-simple-auth] [#2418](https://github.com/mainmatter/ember-simple-auth/pull/2418) Use Volta ([@marcoow])
+- [mainmatter/qunit-dom] [#1600](https://github.com/mainmatter/qunit-dom/pull/1600) package.json: Specify `packageManager` field ([@Turbo87])
+- [mainmatter/qunit-dom] [#1598](https://github.com/mainmatter/qunit-dom/pull/1598) tests: Remove `global` usage ([@Turbo87])
+- [mainmatter/qunit-dom] [#1574](https://github.com/mainmatter/qunit-dom/pull/1574) Remove `.pnpm-debug.log` file ([@Turbo87])
+- [mainmatter/qunit-dom] [#1573](https://github.com/mainmatter/qunit-dom/pull/1573) CI: Update Node.js versions ([@Turbo87])
+- [mainmatter/qunit-dom] [#1572](https://github.com/mainmatter/qunit-dom/pull/1572) Remove `engines` declaration from `package.json` ([@Turbo87])
 
 ## JavaScript
 
-- [Turbo87/lva-camo-status]
-  [#651](https://github.com/Turbo87/lva-camo-status/pull/651) CI: Update Node.js
-  to v16 ([@Turbo87])
-- [mansona/Downsize] [#6](https://github.com/mansona/Downsize/pull/6) fix module
-  definition for esm (.mjs instead of .js) ([@mansona])
-- [mansona/Downsize] [#5](https://github.com/mansona/Downsize/pull/5) Add
-  auto-changelog ([@mansona])
-- [mansona/Downsize] [#4](https://github.com/mansona/Downsize/pull/4) breaking:
-  drop support for EOL Node versions and fix Unicode for modern JS ([@mansona])
-- [mansona/Downsize] [#3](https://github.com/mansona/Downsize/pull/3) move from
-  travis to GitHub Actions ([@mansona])
-- [mansona/Downsize] [#2](https://github.com/mansona/Downsize/pull/2) Support
-  esm ([@mansona])
-- [mansona/Downsize] [#1](https://github.com/mansona/Downsize/pull/1)
-  Feature/cjs ([@mansona])
-- [platinumazure/eslint-plugin-qunit]
-  [#233](https://github.com/platinumazure/eslint-plugin-qunit/pull/233) add
-  `allowFunctions` as an allow-list for require-expect function calls
-  ([@mansona])
+- [Turbo87/lva-camo-status] [#651](https://github.com/Turbo87/lva-camo-status/pull/651) CI: Update Node.js to v16 ([@Turbo87])
+- [mansona/Downsize] [#6](https://github.com/mansona/Downsize/pull/6) fix module definition for esm (.mjs instead of .js) ([@mansona])
+- [mansona/Downsize] [#5](https://github.com/mansona/Downsize/pull/5) Add auto-changelog ([@mansona])
+- [mansona/Downsize] [#4](https://github.com/mansona/Downsize/pull/4) breaking: drop support for EOL Node versions and fix Unicode for modern JS ([@mansona])
+- [mansona/Downsize] [#3](https://github.com/mansona/Downsize/pull/3) move from travis to GitHub Actions ([@mansona])
+- [mansona/Downsize] [#2](https://github.com/mansona/Downsize/pull/2) Support esm ([@mansona])
+- [mansona/Downsize] [#1](https://github.com/mansona/Downsize/pull/1) Feature/cjs ([@mansona])
+- [platinumazure/eslint-plugin-qunit] [#233](https://github.com/platinumazure/eslint-plugin-qunit/pull/233) add `allowFunctions` as an allow-list for require-expect function calls ([@mansona])
 
 ## Lint to the future
 
-- [mansona/lint-to-the-future]
-  [#24](https://github.com/mansona/lint-to-the-future/pull/24) try importing an
-  esm module before reverting to `importCwd` ([@mansona])
-- [mansona/lint-to-the-future]
-  [#23](https://github.com/mansona/lint-to-the-future/pull/23) add documentation
-  for plugin developers ([@mansona])
-- [mansona/lint-to-the-future-ember-template]
-  [#14](https://github.com/mansona/lint-to-the-future-ember-template/pull/14)
-  Add lib to discovery folders ([@locks])
-- [mansona/lint-to-the-future-ember-template]
-  [#11](https://github.com/mansona/lint-to-the-future-ember-template/pull/11)
-  add matrix test for all ember-template-lint versions and fix ESM issue with
-  ember-template-lint@4 ([@mansona])
-- [mansona/lint-to-the-future-ember-template]
-  [#10](https://github.com/mansona/lint-to-the-future-ember-template/pull/10)
-  breaking: drop support for node < 14 and fix CI ([@mansona])
+- [mansona/lint-to-the-future] [#24](https://github.com/mansona/lint-to-the-future/pull/24) try importing an esm module before reverting to `importCwd` ([@mansona])
+- [mansona/lint-to-the-future] [#23](https://github.com/mansona/lint-to-the-future/pull/23) add documentation for plugin developers ([@mansona])
+- [mansona/lint-to-the-future-ember-template] [#14](https://github.com/mansona/lint-to-the-future-ember-template/pull/14) Add lib to discovery folders ([@locks])
+- [mansona/lint-to-the-future-ember-template] [#11](https://github.com/mansona/lint-to-the-future-ember-template/pull/11) add matrix test for all ember-template-lint versions and fix ESM issue with ember-template-lint@4 ([@mansona])
+- [mansona/lint-to-the-future-ember-template] [#10](https://github.com/mansona/lint-to-the-future-ember-template/pull/10) breaking: drop support for node < 14 and fix CI ([@mansona])
 
 ## Octokit
 
-- [octokit/plugin-paginate-rest.js]
-  [#376](https://github.com/octokit/plugin-paginate-rest.js/pull/376)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/types.ts] [#389](https://github.com/octokit/types.ts/pull/389)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/plugin-paginate-rest.js] [#376](https://github.com/octokit/plugin-paginate-rest.js/pull/376) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/types.ts] [#389](https://github.com/octokit/types.ts/pull/389) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
 
 ## Rust
 
-- [Turbo87/united-flarmnet]
-  [#90](https://github.com/Turbo87/united-flarmnet/pull/90) ogn: Simplify JSON
-  parsing ([@Turbo87])
-- [ferrous-systems/teaching-material]
-  [#110](https://github.com/ferrous-systems/teaching-material/pull/110)
-  presentations/macros: Fix typo ([@Turbo87])
-- [ferrous-systems/teaching-material]
-  [#109](https://github.com/ferrous-systems/teaching-material/pull/109)
-  presentations/macros: Adjust `write!()` signature ([@Turbo87])
-- [svartalf/rust-claim] [#10](https://github.com/svartalf/rust-claim/pull/10)
-  autocfg: Allow all v1.x releases ([@Turbo87])
+- [Turbo87/united-flarmnet] [#90](https://github.com/Turbo87/united-flarmnet/pull/90) ogn: Simplify JSON parsing ([@Turbo87])
+- [ferrous-systems/teaching-material] [#110](https://github.com/ferrous-systems/teaching-material/pull/110) presentations/macros: Fix typo ([@Turbo87])
+- [ferrous-systems/teaching-material] [#109](https://github.com/ferrous-systems/teaching-material/pull/109) presentations/macros: Adjust `write!()` signature ([@Turbo87])
+- [svartalf/rust-claim] [#10](https://github.com/svartalf/rust-claim/pull/10) autocfg: Allow all v1.x releases ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4861](https://github.com/rust-lang/crates.io/pull/4861) router: Remove
-  `/api/v1/` subrouter ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4859](https://github.com/rust-lang/crates.io/pull/4859) sentry: Replace
-  `Ember` import from `@sentry/integrations` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4858](https://github.com/rust-lang/crates.io/pull/4858) Remove unused
-  `docs.rs` metadata ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4857](https://github.com/rust-lang/crates.io/pull/4857) claim: Use git
-  dependency ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4836](https://github.com/rust-lang/crates.io/pull/4836) admin/upload_index:
-  Use `indicatif` for progress reporting ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4825](https://github.com/rust-lang/crates.io/pull/4825) Simplify CIDR
-  parsing code ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4814](https://github.com/rust-lang/crates.io/pull/4814) search: Fix app
-  crash without given `q` query parameter ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4813](https://github.com/rust-lang/crates.io/pull/4813) catch-all: Fix
-  `reload()` action ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4794](https://github.com/rust-lang/crates.io/pull/4794) renovate:
-  Automatically merge linting and testing dependency updates ([@Turbo87])
+- [rust-lang/crates.io] [#4861](https://github.com/rust-lang/crates.io/pull/4861) router: Remove `/api/v1/` subrouter ([@Turbo87])
+- [rust-lang/crates.io] [#4859](https://github.com/rust-lang/crates.io/pull/4859) sentry: Replace `Ember` import from `@sentry/integrations` ([@Turbo87])
+- [rust-lang/crates.io] [#4858](https://github.com/rust-lang/crates.io/pull/4858) Remove unused `docs.rs` metadata ([@Turbo87])
+- [rust-lang/crates.io] [#4857](https://github.com/rust-lang/crates.io/pull/4857) claim: Use git dependency ([@Turbo87])
+- [rust-lang/crates.io] [#4836](https://github.com/rust-lang/crates.io/pull/4836) admin/upload_index: Use `indicatif` for progress reporting ([@Turbo87])
+- [rust-lang/crates.io] [#4825](https://github.com/rust-lang/crates.io/pull/4825) Simplify CIDR parsing code ([@Turbo87])
+- [rust-lang/crates.io] [#4814](https://github.com/rust-lang/crates.io/pull/4814) search: Fix app crash without given `q` query parameter ([@Turbo87])
+- [rust-lang/crates.io] [#4813](https://github.com/rust-lang/crates.io/pull/4813) catch-all: Fix `reload()` action ([@Turbo87])
+- [rust-lang/crates.io] [#4794](https://github.com/rust-lang/crates.io/pull/4794) renovate: Automatically merge linting and testing dependency updates ([@Turbo87])
 
 [@bobrimperator]: https://github.com/BobrImperator
 [@turbo87]: https://github.com/Turbo87
@@ -257,26 +115,20 @@
 [emberjs/data]: https://github.com/emberjs/data
 [emberjs/rfcs]: https://github.com/emberjs/rfcs
 [empress/field-guide]: https://github.com/empress/field-guide
-[empress/rfc-process-mdbook-template]:
-  https://github.com/empress/rfc-process-mdbook-template
+[empress/rfc-process-mdbook-template]: https://github.com/empress/rfc-process-mdbook-template
 [empress/rfc-process]: https://github.com/empress/rfc-process
-[ferrous-systems/teaching-material]:
-  https://github.com/ferrous-systems/teaching-material
+[ferrous-systems/teaching-material]: https://github.com/ferrous-systems/teaching-material
 [mansona/downsize]: https://github.com/mansona/Downsize
 [mansona/ember-get-config]: https://github.com/mansona/ember-get-config
 [mansona/ember-html-excerpt]: https://github.com/mansona/ember-html-excerpt
-[mansona/lint-to-the-future-ember-template]:
-  https://github.com/mansona/lint-to-the-future-ember-template
+[mansona/lint-to-the-future-ember-template]: https://github.com/mansona/lint-to-the-future-ember-template
 [mansona/lint-to-the-future]: https://github.com/mansona/lint-to-the-future
 [miguelcobain/ember-paper]: https://github.com/miguelcobain/ember-paper
-[octokit/plugin-paginate-rest.js]:
-  https://github.com/octokit/plugin-paginate-rest.js
+[octokit/plugin-paginate-rest.js]: https://github.com/octokit/plugin-paginate-rest.js
 [octokit/types.ts]: https://github.com/octokit/types.ts
-[platinumazure/eslint-plugin-qunit]:
-  https://github.com/platinumazure/eslint-plugin-qunit
+[platinumazure/eslint-plugin-qunit]: https://github.com/platinumazure/eslint-plugin-qunit
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
 [mainmatter/qunit-dom]: https://github.com/mainmatter/qunit-dom
 [svartalf/rust-claim]: https://github.com/svartalf/rust-claim
diff --git a/src/twios/2022-07-11.md b/src/twios/2022-07-11.md
index 614c6b113d..6eeca2f47a 100644
--- a/src/twios/2022-07-11.md
+++ b/src/twios/2022-07-11.md
@@ -1,296 +1,130 @@
 ## Rust
 
-- [Turbo87/sentry-conduit]
-  [#80](https://github.com/Turbo87/sentry-conduit/pull/80) Update minimum Rust
-  version to v1.57.0 ([@Turbo87])
-- [Turbo87/sentry-conduit]
-  [#79](https://github.com/Turbo87/sentry-conduit/pull/79) Improve HTTP status
-  code mapping ([@Turbo87])
-- [Turbo87/sentry-conduit]
-  [#76](https://github.com/Turbo87/sentry-conduit/pull/76) Implement performance
-  tracing support ([@Turbo87])
-- [Turbo87/sentry-conduit]
-  [#75](https://github.com/Turbo87/sentry-conduit/pull/75) examples: Add two
-  more routes ([@Turbo87])
+- [Turbo87/sentry-conduit] [#80](https://github.com/Turbo87/sentry-conduit/pull/80) Update minimum Rust version to v1.57.0 ([@Turbo87])
+- [Turbo87/sentry-conduit] [#79](https://github.com/Turbo87/sentry-conduit/pull/79) Improve HTTP status code mapping ([@Turbo87])
+- [Turbo87/sentry-conduit] [#76](https://github.com/Turbo87/sentry-conduit/pull/76) Implement performance tracing support ([@Turbo87])
+- [Turbo87/sentry-conduit] [#75](https://github.com/Turbo87/sentry-conduit/pull/75) examples: Add two more routes ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4921](https://github.com/rust-lang/crates.io/pull/4921) version::downloads:
-  Simplify `add_custom_metadata()` usage ([@Turbo87])
-- [rust-lang/crates.io]
-  [#4884](https://github.com/rust-lang/crates.io/pull/4884) sentry: Enable
-  performance tracing via `SENTRY_TRACES_SAMPLE_RATE` env var ([@Turbo87])
+- [rust-lang/crates.io] [#4921](https://github.com/rust-lang/crates.io/pull/4921) version::downloads: Simplify `add_custom_metadata()` usage ([@Turbo87])
+- [rust-lang/crates.io] [#4884](https://github.com/rust-lang/crates.io/pull/4884) sentry: Enable performance tracing via `SENTRY_TRACES_SAMPLE_RATE` env var ([@Turbo87])
 
 ## Mock Service Worker
 
-- [mswjs/cookies] [#22](https://github.com/mswjs/cookies/pull/22) ci(ci.yml):
-  remove unused matrix of versions ([@oscard0m])
-- [mswjs/cookies] [#21](https://github.com/mswjs/cookies/pull/21) ci(release):
-  use node-version 16 ([@oscard0m])
-- [mswjs/cookies] [#20](https://github.com/mswjs/cookies/pull/20) ci(ci.yml):
-  use node-version 16 ([@oscard0m])
-- [mswjs/gh-issue-forms] [#3](https://github.com/mswjs/gh-issue-forms/pull/3)
-  chore(push.sh): remove 'push.sh' file ([@oscard0m])
-- [mswjs/interceptors] [#271](https://github.com/mswjs/interceptors/pull/271)
-  ci(release): use node-version 16 ([@oscard0m])
-- [mswjs/msw-storybook-addon]
-  [#86](https://github.com/mswjs/msw-storybook-addon/pull/86) ci(release): use
-  node-version 16 ([@oscard0m])
-- [mswjs/msw] [#1303](https://github.com/mswjs/msw/pull/1303) ci(smoke): use
-  node-version 16 ([@oscard0m])
+- [mswjs/cookies] [#22](https://github.com/mswjs/cookies/pull/22) ci(ci.yml): remove unused matrix of versions ([@oscard0m])
+- [mswjs/cookies] [#21](https://github.com/mswjs/cookies/pull/21) ci(release): use node-version 16 ([@oscard0m])
+- [mswjs/cookies] [#20](https://github.com/mswjs/cookies/pull/20) ci(ci.yml): use node-version 16 ([@oscard0m])
+- [mswjs/gh-issue-forms] [#3](https://github.com/mswjs/gh-issue-forms/pull/3) chore(push.sh): remove 'push.sh' file ([@oscard0m])
+- [mswjs/interceptors] [#271](https://github.com/mswjs/interceptors/pull/271) ci(release): use node-version 16 ([@oscard0m])
+- [mswjs/msw-storybook-addon] [#86](https://github.com/mswjs/msw-storybook-addon/pull/86) ci(release): use node-version 16 ([@oscard0m])
+- [mswjs/msw] [#1303](https://github.com/mswjs/msw/pull/1303) ci(smoke): use node-version 16 ([@oscard0m])
 
 ## Octoherd
 
-- [octoherd/.github] [#4](https://github.com/octoherd/.github/pull/4)
-  ci(renovate): configure renovate to pin GitHub Actions digests ([@oscard0m])
-- [octoherd/.github] [#3](https://github.com/octoherd/.github/pull/3)
-  ci(renovate): rename the config file to default.json ([@oscard0m])
+- [octoherd/.github] [#4](https://github.com/octoherd/.github/pull/4) ci(renovate): configure renovate to pin GitHub Actions digests ([@oscard0m])
+- [octoherd/.github] [#3](https://github.com/octoherd/.github/pull/3) ci(renovate): rename the config file to default.json ([@oscard0m])
 
 ## Ember.js
 
-- [babel/ember-cli-babel]
-  [#451](https://github.com/babel/ember-cli-babel/pull/451) unpin @babel/runtime
-  to see what tests fail ([@mansona])
-- [ef4/ember-auto-import]
-  [#528](https://github.com/ef4/ember-auto-import/pull/528) WIP trying to turn a
-  build error into a runtime error ([@mansona])
-- [ember-learn/ember-blog]
-  [#1163](https://github.com/ember-learn/ember-blog/pull/1163) add a blurb for
-  Lint to the Future ([@mansona])
-- [ember-learn/ember-help-wanted-server]
-  [#50](https://github.com/ember-learn/ember-help-wanted-server/pull/50) update
-  stack used for preview apps ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#424](https://github.com/ember-learn/ember-styleguide/pull/424) update
-  lint-to-the-future dependencies ([@mansona])
-- [ember-learn/empress-blog-ember-template]
-  [#122](https://github.com/ember-learn/empress-blog-ember-template/pull/122)
-  Replace custom TagPostList styles with Styleguide ([@mansona])
-- [ember-learn/rfcs-app] [#7](https://github.com/ember-learn/rfcs-app/pull/7)
-  update mdbook template ([@mansona])
-- [ember-learn/rfcs-app] [#6](https://github.com/ember-learn/rfcs-app/pull/6)
-  use github compatible header ids ([@mansona])
-- [ember-learn/rfcs-app] [#4](https://github.com/ember-learn/rfcs-app/pull/4)
-  Include images in the output build ([@mansona])
-- [emberjs/ember.js] [#20120](https://github.com/emberjs/ember.js/pull/20120)
-  [BUGFIX LTS] unique-id: Ensure return value starts with a letter to avoid
-  invalid selectors starting with numeric digits ([@Turbo87])
-- [emberjs/rfcs] [#828](https://github.com/emberjs/rfcs/pull/828) fix image urls
-  in embedded images ([@mansona])
-- [emberjs/rfcs] [#826](https://github.com/emberjs/rfcs/pull/826) disable mdbook
-  builds ([@mansona])
-- [emberjs/rfcs] [#825](https://github.com/emberjs/rfcs/pull/825) Add redirects
-  for all the github.io links to the new RFCs app ([@mansona])
-- [empress/field-guide] [#59](https://github.com/empress/field-guide/pull/59)
-  Implement indexes ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#14](https://github.com/empress/rfc-process-mdbook-template/pull/14) remove
-  index number from table of contents ([@mansona])
-- [mansona/ember-body-class]
-  [#59](https://github.com/mansona/ember-body-class/pull/59) update
-  ember-auto-import to support Ember 4.x ([@mansona])
-- [mansona/ember-body-class]
-  [#58](https://github.com/mansona/ember-body-class/pull/58) Breaking: drop
-  support for Ember < 3.8 ([@mansona])
-- [mansona/ember-body-class]
-  [#57](https://github.com/mansona/ember-body-class/pull/57) remove router
-  deprecation ([@mansona])
-- [mansona/ember-body-class]
-  [#52](https://github.com/mansona/ember-body-class/pull/52) Breaking: drop
-  support for node < 14 ([@mansona])
-- [mansona/ember-body-class]
-  [#51](https://github.com/mansona/ember-body-class/pull/51) Update Ember to
-  3.28 with ember-cli-update ([@mansona])
-- [mansona/ember-cli-babel]
-  [#1](https://github.com/mansona/ember-cli-babel/pull/1) Unpin babel runtime
-  ([@mansona])
-- [mansona/ember-cli-notifications]
-  [#342](https://github.com/mansona/ember-cli-notifications/pull/342) Refactor:
-  Handle notification htmlContent in backing class ([@pichfl])
-- [mansona/ember-cli-notifications]
-  [#341](https://github.com/mansona/ember-cli-notifications/pull/341) Fix
-  ember-try scenarios ([@mansona])
-- [mansona/ember-get-config]
-  [#46](https://github.com/mansona/ember-get-config/pull/46) Fix ember-try
-  issues ([@mansona])
-- [mainmatter/ember-intl-analyzer]
-  [#528](https://github.com/mainmatter/ember-intl-analyzer/pull/528) Add custom
-  plugin/extension support ([@Mikek2252])
-- [zeppelin/ember-click-outside]
-  [#246](https://github.com/zeppelin/ember-click-outside/pull/246) Prettify +
-  replace ancient syntax in tests & dummy app ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#245](https://github.com/zeppelin/ember-click-outside/pull/245) Deprecate
-  ClickOutside component ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#244](https://github.com/zeppelin/ember-click-outside/pull/244) Remove
-  deprecated ClickOutsideMixin ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#243](https://github.com/zeppelin/ember-click-outside/pull/243) Remove
-  component template containing a single yield ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#242](https://github.com/zeppelin/ember-click-outside/pull/242) Drop
-  ember-modifier < 3.2.0 & resolve deprecations ([@nickschot])
+- [babel/ember-cli-babel] [#451](https://github.com/babel/ember-cli-babel/pull/451) unpin @babel/runtime to see what tests fail ([@mansona])
+- [ef4/ember-auto-import] [#528](https://github.com/ef4/ember-auto-import/pull/528) WIP trying to turn a build error into a runtime error ([@mansona])
+- [ember-learn/ember-blog] [#1163](https://github.com/ember-learn/ember-blog/pull/1163) add a blurb for Lint to the Future ([@mansona])
+- [ember-learn/ember-help-wanted-server] [#50](https://github.com/ember-learn/ember-help-wanted-server/pull/50) update stack used for preview apps ([@mansona])
+- [ember-learn/ember-styleguide] [#424](https://github.com/ember-learn/ember-styleguide/pull/424) update lint-to-the-future dependencies ([@mansona])
+- [ember-learn/empress-blog-ember-template] [#122](https://github.com/ember-learn/empress-blog-ember-template/pull/122) Replace custom TagPostList styles with Styleguide ([@mansona])
+- [ember-learn/rfcs-app] [#7](https://github.com/ember-learn/rfcs-app/pull/7) update mdbook template ([@mansona])
+- [ember-learn/rfcs-app] [#6](https://github.com/ember-learn/rfcs-app/pull/6) use github compatible header ids ([@mansona])
+- [ember-learn/rfcs-app] [#4](https://github.com/ember-learn/rfcs-app/pull/4) Include images in the output build ([@mansona])
+- [emberjs/ember.js] [#20120](https://github.com/emberjs/ember.js/pull/20120) [BUGFIX LTS] unique-id: Ensure return value starts with a letter to avoid invalid selectors starting with numeric digits ([@Turbo87])
+- [emberjs/rfcs] [#828](https://github.com/emberjs/rfcs/pull/828) fix image urls in embedded images ([@mansona])
+- [emberjs/rfcs] [#826](https://github.com/emberjs/rfcs/pull/826) disable mdbook builds ([@mansona])
+- [emberjs/rfcs] [#825](https://github.com/emberjs/rfcs/pull/825) Add redirects for all the github.io links to the new RFCs app ([@mansona])
+- [empress/field-guide] [#59](https://github.com/empress/field-guide/pull/59) Implement indexes ([@mansona])
+- [empress/rfc-process-mdbook-template] [#14](https://github.com/empress/rfc-process-mdbook-template/pull/14) remove index number from table of contents ([@mansona])
+- [mansona/ember-body-class] [#59](https://github.com/mansona/ember-body-class/pull/59) update ember-auto-import to support Ember 4.x ([@mansona])
+- [mansona/ember-body-class] [#58](https://github.com/mansona/ember-body-class/pull/58) Breaking: drop support for Ember < 3.8 ([@mansona])
+- [mansona/ember-body-class] [#57](https://github.com/mansona/ember-body-class/pull/57) remove router deprecation ([@mansona])
+- [mansona/ember-body-class] [#52](https://github.com/mansona/ember-body-class/pull/52) Breaking: drop support for node < 14 ([@mansona])
+- [mansona/ember-body-class] [#51](https://github.com/mansona/ember-body-class/pull/51) Update Ember to 3.28 with ember-cli-update ([@mansona])
+- [mansona/ember-cli-babel] [#1](https://github.com/mansona/ember-cli-babel/pull/1) Unpin babel runtime ([@mansona])
+- [mansona/ember-cli-notifications] [#342](https://github.com/mansona/ember-cli-notifications/pull/342) Refactor: Handle notification htmlContent in backing class ([@pichfl])
+- [mansona/ember-cli-notifications] [#341](https://github.com/mansona/ember-cli-notifications/pull/341) Fix ember-try scenarios ([@mansona])
+- [mansona/ember-get-config] [#46](https://github.com/mansona/ember-get-config/pull/46) Fix ember-try issues ([@mansona])
+- [mainmatter/ember-intl-analyzer] [#528](https://github.com/mainmatter/ember-intl-analyzer/pull/528) Add custom plugin/extension support ([@Mikek2252])
+- [zeppelin/ember-click-outside] [#246](https://github.com/zeppelin/ember-click-outside/pull/246) Prettify + replace ancient syntax in tests & dummy app ([@zeppelin])
+- [zeppelin/ember-click-outside] [#245](https://github.com/zeppelin/ember-click-outside/pull/245) Deprecate ClickOutside component ([@zeppelin])
+- [zeppelin/ember-click-outside] [#244](https://github.com/zeppelin/ember-click-outside/pull/244) Remove deprecated ClickOutsideMixin ([@zeppelin])
+- [zeppelin/ember-click-outside] [#243](https://github.com/zeppelin/ember-click-outside/pull/243) Remove component template containing a single yield ([@zeppelin])
+- [zeppelin/ember-click-outside] [#242](https://github.com/zeppelin/ember-click-outside/pull/242) Drop ember-modifier < 3.2.0 & resolve deprecations ([@nickschot])
 
 ## Lint to the future
 
-- [mansona/lint-to-the-future-eslint]
-  [#8](https://github.com/mansona/lint-to-the-future-eslint/pull/8) fix typo in
-  README.md ([@locks])
-- [mansona/lint-to-the-future-eslint]
-  [#6](https://github.com/mansona/lint-to-the-future-eslint/pull/6) Make regular
-  expression resilient to // eslint-disable-next-line declarations ([@locks])
-- [mansona/lint-to-the-future-eslint]
-  [#7](https://github.com/mansona/lint-to-the-future-eslint/pull/7) add a test
-  for list function ([@mansona])
-- [mansona/lint-to-the-future-stylelint]
-  [#3](https://github.com/mansona/lint-to-the-future-stylelint/pull/3) update
-  stylelint peerDependency to accept stylelint 13 and 14 ([@Mikek2252])
+- [mansona/lint-to-the-future-eslint] [#8](https://github.com/mansona/lint-to-the-future-eslint/pull/8) fix typo in README.md ([@locks])
+- [mansona/lint-to-the-future-eslint] [#6](https://github.com/mansona/lint-to-the-future-eslint/pull/6) Make regular expression resilient to // eslint-disable-next-line declarations ([@locks])
+- [mansona/lint-to-the-future-eslint] [#7](https://github.com/mansona/lint-to-the-future-eslint/pull/7) add a test for list function ([@mansona])
+- [mansona/lint-to-the-future-stylelint] [#3](https://github.com/mansona/lint-to-the-future-stylelint/pull/3) update stylelint peerDependency to accept stylelint 13 and 14 ([@Mikek2252])
 
 ## JavaScript
 
-- [cookpete/auto-changelog]
-  [#237](https://github.com/cookpete/auto-changelog/pull/237) Add a Plugin
-  system ([@mansona])
-- [sinonjs/fake-timers] [#433](https://github.com/sinonjs/fake-timers/pull/433)
-  add failing test for issue 432 ([@mansona])
-- [sinonjs/fake-timers] [#431](https://github.com/sinonjs/fake-timers/pull/431)
-  Add a bit more structure to the tests ([@mansona])
-- [squash-commit-app/squash-commit-app]
-  [#19](https://github.com/squash-commit-app/squash-commit-app/pull/19)
-  fix(release): use node-version 14 ([@oscard0m])
-- [squash-commit-app/squash-commit-app]
-  [#18](https://github.com/squash-commit-app/squash-commit-app/pull/18)
-  docs(README): add context and news about this GitHub App ([@oscard0m])
+- [cookpete/auto-changelog] [#237](https://github.com/cookpete/auto-changelog/pull/237) Add a Plugin system ([@mansona])
+- [sinonjs/fake-timers] [#433](https://github.com/sinonjs/fake-timers/pull/433) add failing test for issue 432 ([@mansona])
+- [sinonjs/fake-timers] [#431](https://github.com/sinonjs/fake-timers/pull/431) Add a bit more structure to the tests ([@mansona])
+- [squash-commit-app/squash-commit-app] [#19](https://github.com/squash-commit-app/squash-commit-app/pull/19) fix(release): use node-version 14 ([@oscard0m])
+- [squash-commit-app/squash-commit-app] [#18](https://github.com/squash-commit-app/squash-commit-app/pull/18) docs(README): add context and news about this GitHub App ([@oscard0m])
 
 ## Octokit
 
-- [octokit/.github] [#8](https://github.com/octokit/.github/pull/8)
-  feat(default.json): use 'chore' as default semantic commit type ([@oscard0m])
-- [octokit/action.js] [#394](https://github.com/octokit/action.js/pull/394)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/app.js] [#291](https://github.com/octokit/app.js/pull/291)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/auth-action.js]
-  [#217](https://github.com/octokit/auth-action.js/pull/217) build(npm): replace
-  'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/auth-app.js] [#352](https://github.com/octokit/auth-app.js/pull/352)
-  ci(test): downgrade sinonjs/faker-timers to v8 to 'test' checkrun
-  ([@oscard0m])
-- [octokit/auth-app.js] [#350](https://github.com/octokit/auth-app.js/pull/350)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/auth-callback.js]
-  [#57](https://github.com/octokit/auth-callback.js/pull/57) build(npm): replace
-  'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/auth-oauth-app.js]
-  [#234](https://github.com/octokit/auth-oauth-app.js/pull/234) build(npm):
-  replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/auth-oauth-device.js]
-  [#57](https://github.com/octokit/auth-oauth-device.js/pull/57) build(npm):
-  replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/auth-oauth-user.js]
-  [#55](https://github.com/octokit/auth-oauth-user.js/pull/55) build(npm):
-  replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/auth-token.js]
-  [#230](https://github.com/octokit/auth-token.js/pull/230) build(npm): replace
-  'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/auth-unauthenticated.js]
-  [#126](https://github.com/octokit/auth-unauthenticated.js/pull/126)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/auth-unauthenticated.js]
-  [#125](https://github.com/octokit/auth-unauthenticated.js/pull/125)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/auth-unauthenticated.js]
-  [#124](https://github.com/octokit/auth-unauthenticated.js/pull/124)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/core.js] [#484](https://github.com/octokit/core.js/pull/484)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/endpoint.js] [#322](https://github.com/octokit/endpoint.js/pull/322)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/endpoint.js] [#321](https://github.com/octokit/endpoint.js/pull/321)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/graphql.js] [#363](https://github.com/octokit/graphql.js/pull/363)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/graphql.js] [#362](https://github.com/octokit/graphql.js/pull/362)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/oauth-app.js]
-  [#298](https://github.com/octokit/oauth-app.js/pull/298) build(npm): replace
-  'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/oauth-authorization-url.js]
-  [#182](https://github.com/octokit/oauth-authorization-url.js/pull/182)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/oauth-methods.js]
-  [#59](https://github.com/octokit/oauth-methods.js/pull/59) build(npm): replace
-  'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/octokit.js] [#2248](https://github.com/octokit/octokit.js/pull/2248)
-  fix(deps): update dependency @octokit/core to v4 ([@oscard0m])
-- [octokit/octokit.js] [#2235](https://github.com/octokit/octokit.js/pull/2235)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-create-or-update-text-file.js]
-  [#59](https://github.com/octokit/plugin-create-or-update-text-file.js/pull/59)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-enterprise-cloud.js]
-  [#351](https://github.com/octokit/plugin-enterprise-cloud.js/pull/351)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-enterprise-compatibility.js]
-  [#290](https://github.com/octokit/plugin-enterprise-compatibility.js/pull/290)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-enterprise-server.js]
-  [#438](https://github.com/octokit/plugin-enterprise-server.js/pull/438)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-paginate-rest.js]
-  [#396](https://github.com/octokit/plugin-paginate-rest.js/pull/396)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-request-log.js]
-  [#231](https://github.com/octokit/plugin-request-log.js/pull/231) ci(codeql):
-  ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/plugin-request-log.js]
-  [#230](https://github.com/octokit/plugin-request-log.js/pull/230) ci(codeql):
-  ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/plugin-request-log.js]
-  [#229](https://github.com/octokit/plugin-request-log.js/pull/229) build(npm):
-  replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-rest-endpoint-methods.js]
-  [#490](https://github.com/octokit/plugin-rest-endpoint-methods.js/pull/490)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-retry.js]
-  [#322](https://github.com/octokit/plugin-retry.js/pull/322) build(npm):
-  replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/plugin-throttling.js]
-  [#468](https://github.com/octokit/plugin-throttling.js/pull/468) build(npm):
-  replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/request-error.js]
-  [#233](https://github.com/octokit/request-error.js/pull/233) ci(codeql):
-  ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/request-error.js]
-  [#232](https://github.com/octokit/request-error.js/pull/232) build(npm):
-  replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/request.js] [#473](https://github.com/octokit/request.js/pull/473)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/request.js] [#472](https://github.com/octokit/request.js/pull/472)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/request.js] [#471](https://github.com/octokit/request.js/pull/471)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/request.js] [#466](https://github.com/octokit/request.js/pull/466)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/rest.js] [#154](https://github.com/octokit/rest.js/pull/154)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/rest.js] [#153](https://github.com/octokit/rest.js/pull/153)
-  ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
-- [octokit/rest.js] [#152](https://github.com/octokit/rest.js/pull/152)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/webhooks-methods.js]
-  [#55](https://github.com/octokit/webhooks-methods.js/pull/55) build(npm):
-  replace 'pika' command with 'pika-pack' ([@oscard0m])
-- [octokit/webhooks.js] [#692](https://github.com/octokit/webhooks.js/pull/692)
-  build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/.github] [#8](https://github.com/octokit/.github/pull/8) feat(default.json): use 'chore' as default semantic commit type ([@oscard0m])
+- [octokit/action.js] [#394](https://github.com/octokit/action.js/pull/394) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/app.js] [#291](https://github.com/octokit/app.js/pull/291) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/auth-action.js] [#217](https://github.com/octokit/auth-action.js/pull/217) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/auth-app.js] [#352](https://github.com/octokit/auth-app.js/pull/352) ci(test): downgrade sinonjs/faker-timers to v8 to 'test' checkrun ([@oscard0m])
+- [octokit/auth-app.js] [#350](https://github.com/octokit/auth-app.js/pull/350) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/auth-callback.js] [#57](https://github.com/octokit/auth-callback.js/pull/57) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/auth-oauth-app.js] [#234](https://github.com/octokit/auth-oauth-app.js/pull/234) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/auth-oauth-device.js] [#57](https://github.com/octokit/auth-oauth-device.js/pull/57) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/auth-oauth-user.js] [#55](https://github.com/octokit/auth-oauth-user.js/pull/55) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/auth-token.js] [#230](https://github.com/octokit/auth-token.js/pull/230) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/auth-unauthenticated.js] [#126](https://github.com/octokit/auth-unauthenticated.js/pull/126) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/auth-unauthenticated.js] [#125](https://github.com/octokit/auth-unauthenticated.js/pull/125) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/auth-unauthenticated.js] [#124](https://github.com/octokit/auth-unauthenticated.js/pull/124) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/core.js] [#484](https://github.com/octokit/core.js/pull/484) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/endpoint.js] [#322](https://github.com/octokit/endpoint.js/pull/322) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/endpoint.js] [#321](https://github.com/octokit/endpoint.js/pull/321) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/graphql.js] [#363](https://github.com/octokit/graphql.js/pull/363) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/graphql.js] [#362](https://github.com/octokit/graphql.js/pull/362) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/oauth-app.js] [#298](https://github.com/octokit/oauth-app.js/pull/298) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/oauth-authorization-url.js] [#182](https://github.com/octokit/oauth-authorization-url.js/pull/182) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/oauth-methods.js] [#59](https://github.com/octokit/oauth-methods.js/pull/59) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/octokit.js] [#2248](https://github.com/octokit/octokit.js/pull/2248) fix(deps): update dependency @octokit/core to v4 ([@oscard0m])
+- [octokit/octokit.js] [#2235](https://github.com/octokit/octokit.js/pull/2235) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-create-or-update-text-file.js] [#59](https://github.com/octokit/plugin-create-or-update-text-file.js/pull/59) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-enterprise-cloud.js] [#351](https://github.com/octokit/plugin-enterprise-cloud.js/pull/351) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-enterprise-compatibility.js] [#290](https://github.com/octokit/plugin-enterprise-compatibility.js/pull/290) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-enterprise-server.js] [#438](https://github.com/octokit/plugin-enterprise-server.js/pull/438) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-paginate-rest.js] [#396](https://github.com/octokit/plugin-paginate-rest.js/pull/396) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-request-log.js] [#231](https://github.com/octokit/plugin-request-log.js/pull/231) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/plugin-request-log.js] [#230](https://github.com/octokit/plugin-request-log.js/pull/230) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/plugin-request-log.js] [#229](https://github.com/octokit/plugin-request-log.js/pull/229) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-rest-endpoint-methods.js] [#490](https://github.com/octokit/plugin-rest-endpoint-methods.js/pull/490) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-retry.js] [#322](https://github.com/octokit/plugin-retry.js/pull/322) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/plugin-throttling.js] [#468](https://github.com/octokit/plugin-throttling.js/pull/468) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/request-error.js] [#233](https://github.com/octokit/request-error.js/pull/233) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/request-error.js] [#232](https://github.com/octokit/request-error.js/pull/232) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/request.js] [#473](https://github.com/octokit/request.js/pull/473) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/request.js] [#472](https://github.com/octokit/request.js/pull/472) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/request.js] [#471](https://github.com/octokit/request.js/pull/471) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/request.js] [#466](https://github.com/octokit/request.js/pull/466) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/rest.js] [#154](https://github.com/octokit/rest.js/pull/154) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/rest.js] [#153](https://github.com/octokit/rest.js/pull/153) ci(codeql): ignore on push events for dependabot branches ([@oscard0m])
+- [octokit/rest.js] [#152](https://github.com/octokit/rest.js/pull/152) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/webhooks-methods.js] [#55](https://github.com/octokit/webhooks-methods.js/pull/55) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
+- [octokit/webhooks.js] [#692](https://github.com/octokit/webhooks.js/pull/692) build(npm): replace 'pika' command with 'pika-pack' ([@oscard0m])
 
 ## Internal
 
-- [mainmatter/renovate-config]
-  [#10](https://github.com/mainmatter/renovate-config/pull/10) feat(renovate):
-  configure renovate to pin GitHub Actions digests ([@oscard0m])
+- [mainmatter/renovate-config] [#10](https://github.com/mainmatter/renovate-config/pull/10) feat(renovate): configure renovate to pin GitHub Actions digests ([@oscard0m])
 
 [@mikek2252]: https://github.com/Mikek2252
 [@turbo87]: https://github.com/Turbo87
@@ -305,28 +139,21 @@
 [cookpete/auto-changelog]: https://github.com/cookpete/auto-changelog
 [ef4/ember-auto-import]: https://github.com/ef4/ember-auto-import
 [ember-learn/ember-blog]: https://github.com/ember-learn/ember-blog
-[ember-learn/ember-help-wanted-server]:
-  https://github.com/ember-learn/ember-help-wanted-server
+[ember-learn/ember-help-wanted-server]: https://github.com/ember-learn/ember-help-wanted-server
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
-[ember-learn/empress-blog-ember-template]:
-  https://github.com/ember-learn/empress-blog-ember-template
+[ember-learn/empress-blog-ember-template]: https://github.com/ember-learn/empress-blog-ember-template
 [ember-learn/rfcs-app]: https://github.com/ember-learn/rfcs-app
 [emberjs/ember.js]: https://github.com/emberjs/ember.js
 [emberjs/rfcs]: https://github.com/emberjs/rfcs
-[empress/field-guide-addon-docs-template]:
-  https://github.com/empress/field-guide-addon-docs-template
+[empress/field-guide-addon-docs-template]: https://github.com/empress/field-guide-addon-docs-template
 [empress/field-guide]: https://github.com/empress/field-guide
-[empress/rfc-process-mdbook-template]:
-  https://github.com/empress/rfc-process-mdbook-template
+[empress/rfc-process-mdbook-template]: https://github.com/empress/rfc-process-mdbook-template
 [mansona/ember-body-class]: https://github.com/mansona/ember-body-class
 [mansona/ember-cli-babel]: https://github.com/mansona/ember-cli-babel
-[mansona/ember-cli-notifications]:
-  https://github.com/mansona/ember-cli-notifications
+[mansona/ember-cli-notifications]: https://github.com/mansona/ember-cli-notifications
 [mansona/ember-get-config]: https://github.com/mansona/ember-get-config
-[mansona/lint-to-the-future-eslint]:
-  https://github.com/mansona/lint-to-the-future-eslint
-[mansona/lint-to-the-future-stylelint]:
-  https://github.com/mansona/lint-to-the-future-stylelint
+[mansona/lint-to-the-future-eslint]: https://github.com/mansona/lint-to-the-future-eslint
+[mansona/lint-to-the-future-stylelint]: https://github.com/mansona/lint-to-the-future-stylelint
 [mswjs/cookies]: https://github.com/mswjs/cookies
 [mswjs/gh-issue-forms]: https://github.com/mswjs/gh-issue-forms
 [mswjs/interceptors]: https://github.com/mswjs/interceptors
@@ -343,30 +170,21 @@
 [octokit/auth-oauth-device.js]: https://github.com/octokit/auth-oauth-device.js
 [octokit/auth-oauth-user.js]: https://github.com/octokit/auth-oauth-user.js
 [octokit/auth-token.js]: https://github.com/octokit/auth-token.js
-[octokit/auth-unauthenticated.js]:
-  https://github.com/octokit/auth-unauthenticated.js
+[octokit/auth-unauthenticated.js]: https://github.com/octokit/auth-unauthenticated.js
 [octokit/core.js]: https://github.com/octokit/core.js
 [octokit/endpoint.js]: https://github.com/octokit/endpoint.js
 [octokit/graphql.js]: https://github.com/octokit/graphql.js
 [octokit/oauth-app.js]: https://github.com/octokit/oauth-app.js
-[octokit/oauth-authorization-url.js]:
-  https://github.com/octokit/oauth-authorization-url.js
+[octokit/oauth-authorization-url.js]: https://github.com/octokit/oauth-authorization-url.js
 [octokit/oauth-methods.js]: https://github.com/octokit/oauth-methods.js
 [octokit/octokit.js]: https://github.com/octokit/octokit.js
-[octokit/plugin-create-or-update-text-file.js]:
-  https://github.com/octokit/plugin-create-or-update-text-file.js
-[octokit/plugin-enterprise-cloud.js]:
-  https://github.com/octokit/plugin-enterprise-cloud.js
-[octokit/plugin-enterprise-compatibility.js]:
-  https://github.com/octokit/plugin-enterprise-compatibility.js
-[octokit/plugin-enterprise-server.js]:
-  https://github.com/octokit/plugin-enterprise-server.js
-[octokit/plugin-paginate-rest.js]:
-  https://github.com/octokit/plugin-paginate-rest.js
-[octokit/plugin-request-log.js]:
-  https://github.com/octokit/plugin-request-log.js
-[octokit/plugin-rest-endpoint-methods.js]:
-  https://github.com/octokit/plugin-rest-endpoint-methods.js
+[octokit/plugin-create-or-update-text-file.js]: https://github.com/octokit/plugin-create-or-update-text-file.js
+[octokit/plugin-enterprise-cloud.js]: https://github.com/octokit/plugin-enterprise-cloud.js
+[octokit/plugin-enterprise-compatibility.js]: https://github.com/octokit/plugin-enterprise-compatibility.js
+[octokit/plugin-enterprise-server.js]: https://github.com/octokit/plugin-enterprise-server.js
+[octokit/plugin-paginate-rest.js]: https://github.com/octokit/plugin-paginate-rest.js
+[octokit/plugin-request-log.js]: https://github.com/octokit/plugin-request-log.js
+[octokit/plugin-rest-endpoint-methods.js]: https://github.com/octokit/plugin-rest-endpoint-methods.js
 [octokit/plugin-retry.js]: https://github.com/octokit/plugin-retry.js
 [octokit/plugin-throttling.js]: https://github.com/octokit/plugin-throttling.js
 [octokit/request-error.js]: https://github.com/octokit/request-error.js
@@ -375,10 +193,8 @@
 [octokit/webhooks-methods.js]: https://github.com/octokit/webhooks-methods.js
 [octokit/webhooks.js]: https://github.com/octokit/webhooks.js
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
-[mainmatter/ember-intl-analyzer]:
-  https://github.com/mainmatter/ember-intl-analyzer
+[mainmatter/ember-intl-analyzer]: https://github.com/mainmatter/ember-intl-analyzer
 [mainmatter/renovate-config]: https://github.com/mainmatter/renovate-config
 [sinonjs/fake-timers]: https://github.com/sinonjs/fake-timers
-[squash-commit-app/squash-commit-app]:
-  https://github.com/squash-commit-app/squash-commit-app
+[squash-commit-app/squash-commit-app]: https://github.com/squash-commit-app/squash-commit-app
 [zeppelin/ember-click-outside]: https://github.com/zeppelin/ember-click-outside
diff --git a/src/twios/2022-08-02.md b/src/twios/2022-08-02.md
index 67928a0b23..072d0f166d 100644
--- a/src/twios/2022-08-02.md
+++ b/src/twios/2022-08-02.md
@@ -1,233 +1,96 @@
 ## Rust
 
-- [Turbo87/segelflug-classifieds]
-  [#314](https://github.com/Turbo87/segelflug-classifieds/pull/314) clippy:
-  Adjust CLI arguments ([@Turbo87])
+- [Turbo87/segelflug-classifieds] [#314](https://github.com/Turbo87/segelflug-classifieds/pull/314) clippy: Adjust CLI arguments ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#4967](https://github.com/rust-lang/crates.io/pull/4967) worker::git: Adjust
-  `update_crate_index()` to handle deleted files ([@Turbo87])
+- [rust-lang/crates.io] [#4967](https://github.com/rust-lang/crates.io/pull/4967) worker::git: Adjust `update_crate_index()` to handle deleted files ([@Turbo87])
 
 ## Mock Service Worker
 
-- [mswjs/cookies] [#23](https://github.com/mswjs/cookies/pull/23) ci(ci.yml):
-  run CI with multiple versions of Node ([@oscard0m])
+- [mswjs/cookies] [#23](https://github.com/mswjs/cookies/pull/23) ci(ci.yml): run CI with multiple versions of Node ([@oscard0m])
 
 ## Ember.js
 
-- [cibernox/ember-power-select]
-  [#1524](https://github.com/cibernox/ember-power-select/pull/1524) Update
-  ember-basic-dropdown ([@mansona])
-- [ef4/ember-auto-import]
-  [#530](https://github.com/ef4/ember-auto-import/pull/530) Move Dynamic
-  Template Import error to runtime instead of a build error ([@mansona])
-- [ember-codemods/ember-codemods-telemetry-helpers]
-  [#47](https://github.com/ember-codemods/ember-codemods-telemetry-helpers/pull/47)
-  breaking: drop support for EOL Node versions ([@mansona])
-- [ember-codemods/ember-codemods-telemetry-helpers]
-  [#46](https://github.com/ember-codemods/ember-codemods-telemetry-helpers/pull/46)
-  update puppeteer to support M1 macs ([@mansona])
-- [ember-codemods/ember-native-class-codemod]
-  [#490](https://github.com/ember-codemods/ember-native-class-codemod/pull/490)
-  Drop support for EOL Node versions ([@mansona])
-- [ember-codemods/ember-native-class-codemod]
-  [#487](https://github.com/ember-codemods/ember-native-class-codemod/pull/487)
-  move from travis to github actions ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#102](https://github.com/ember-learn/guidemaker-ember-template/pull/102)
-  Update ember to 3.28 using ember-cli-update ([@mansona])
-- [ember-learn/rfcs-app] [#9](https://github.com/ember-learn/rfcs-app/pull/9)
-  update rfc-process dependencies ([@mansona])
-- [empress/guidemaker] [#72](https://github.com/empress/guidemaker/pull/72) turn
-  a build deprecation into an error ([@mansona])
-- [empress/guidemaker] [#71](https://github.com/empress/guidemaker/pull/71) Fix
-  deprecations ([@mansona])
-- [empress/guidemaker] [#68](https://github.com/empress/guidemaker/pull/68)
-  breaking: drop support for Ember < 3.16 - Update ember to 3.28 using
-  ember-cli-update ([@mansona])
-- [empress/guidemaker] [#64](https://github.com/empress/guidemaker/pull/64)
-  breaking: drop support for Node < 14 ([@mansona])
-- [empress/guidemaker] [#63](https://github.com/empress/guidemaker/pull/63)
-  Update ember-get-config ([@mansona])
-- [empress/guidemaker-default-template]
-  [#21](https://github.com/empress/guidemaker-default-template/pull/21) Support
-  Embroider ([@mansona])
-- [empress/guidemaker-default-template]
-  [#20](https://github.com/empress/guidemaker-default-template/pull/20) add no
-  deprecations ember-try config ([@mansona])
-- [empress/guidemaker-default-template]
-  [#19](https://github.com/empress/guidemaker-default-template/pull/19) Update
-  to Ember 3.28 with ember-cli-update ([@mansona])
-- [empress/guidemaker-default-template]
-  [#17](https://github.com/empress/guidemaker-default-template/pull/17)
-  breaking: drop support for Node < 14 ([@mansona])
-- [empress/rfc-process] [#18](https://github.com/empress/rfc-process/pull/18)
-  Add ember-meta implementation ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#17](https://github.com/empress/rfc-process-mdbook-template/pull/17) fix
-  rfc-process peer dependency ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#16](https://github.com/empress/rfc-process-mdbook-template/pull/16)
-  Supporting rfc-process v1.0 and head-data ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1228](https://github.com/miguelcobain/ember-paper/pull/1228) update
-  paper-tabs to class syntax ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1227](https://github.com/miguelcobain/ember-paper/pull/1227) update
-  paper-tab to use native class syntax ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1226](https://github.com/miguelcobain/ember-paper/pull/1226) update
-  paper-radio to use native class syntax ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1225](https://github.com/miguelcobain/ember-paper/pull/1225) update
-  paper-item to use native class syntax ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1224](https://github.com/miguelcobain/ember-paper/pull/1224) update
-  paper-grid-tile to use native class syntax ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1223](https://github.com/miguelcobain/ember-paper/pull/1223) Convert
-  paper-form to class syntax ([@mansona])
-- [nickschot/ember-mobile-menu]
-  [#367](https://github.com/nickschot/ember-mobile-menu/pull/367) don't run CI
-  against 4.x+, add all 3.x LTS releases to matrix, use node 12 on CI
-  ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#366](https://github.com/nickschot/ember-mobile-menu/pull/366) fix import
-  path for htmlSafe ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#365](https://github.com/nickschot/ember-mobile-menu/pull/365) Move README,
-  CONTRIBUTING and LICENSE.md to addon folder ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#361](https://github.com/nickschot/ember-mobile-menu/pull/361) remove
-  ember-cli-htmlbars override now that 6.1.0 has been released ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#359](https://github.com/nickschot/ember-mobile-menu/pull/359) Revert "Update
-  dependency release-it to v15" ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#358](https://github.com/nickschot/ember-mobile-menu/pull/358) Upgrade to
-  pnpm v7 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#357](https://github.com/nickschot/ember-mobile-menu/pull/357) declare
-  ember-source peer dependency for addon ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#356](https://github.com/nickschot/ember-mobile-menu/pull/356) Drop node 12
-  support ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#372](https://github.com/nickschot/ember-mobile-menu/pull/372) protect
-  against using window apis in Fastboot ([@mansona])
-- [nickschot/ember-mobile-menu]
-  [#371](https://github.com/nickschot/ember-mobile-menu/pull/371) protect
-  against using window apis in Fastboot ([@mansona])
-- [mainmatter/ember-simple-auth]
-  [#2435](https://github.com/mainmatter/ember-simple-auth/pull/2435)
-  fix(renovate.json): use proper path for .json5 preset ([@oscard0m])
-- [mainmatter/ember-simple-auth]
-  [#2442](https://github.com/mainmatter/ember-simple-auth/pull/2442) Upgrade to
-  qunit 5 2 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2440](https://github.com/mainmatter/ember-simple-auth/pull/2440) docs: add
-  information about v4 release for embroider and typescript users
-  ([@BobrImperator])
-- [zeppelin/ember-click-outside]
-  [#250](https://github.com/zeppelin/ember-click-outside/pull/250) Sync test
-  matrix with GitHub Actions ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#249](https://github.com/zeppelin/ember-click-outside/pull/249) Fix component
-  deprecation message ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#248](https://github.com/zeppelin/ember-click-outside/pull/248) Add early
-  Ember to test matrix ([@zeppelin])
+- [cibernox/ember-power-select] [#1524](https://github.com/cibernox/ember-power-select/pull/1524) Update ember-basic-dropdown ([@mansona])
+- [ef4/ember-auto-import] [#530](https://github.com/ef4/ember-auto-import/pull/530) Move Dynamic Template Import error to runtime instead of a build error ([@mansona])
+- [ember-codemods/ember-codemods-telemetry-helpers] [#47](https://github.com/ember-codemods/ember-codemods-telemetry-helpers/pull/47) breaking: drop support for EOL Node versions ([@mansona])
+- [ember-codemods/ember-codemods-telemetry-helpers] [#46](https://github.com/ember-codemods/ember-codemods-telemetry-helpers/pull/46) update puppeteer to support M1 macs ([@mansona])
+- [ember-codemods/ember-native-class-codemod] [#490](https://github.com/ember-codemods/ember-native-class-codemod/pull/490) Drop support for EOL Node versions ([@mansona])
+- [ember-codemods/ember-native-class-codemod] [#487](https://github.com/ember-codemods/ember-native-class-codemod/pull/487) move from travis to github actions ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#102](https://github.com/ember-learn/guidemaker-ember-template/pull/102) Update ember to 3.28 using ember-cli-update ([@mansona])
+- [ember-learn/rfcs-app] [#9](https://github.com/ember-learn/rfcs-app/pull/9) update rfc-process dependencies ([@mansona])
+- [empress/guidemaker] [#72](https://github.com/empress/guidemaker/pull/72) turn a build deprecation into an error ([@mansona])
+- [empress/guidemaker] [#71](https://github.com/empress/guidemaker/pull/71) Fix deprecations ([@mansona])
+- [empress/guidemaker] [#68](https://github.com/empress/guidemaker/pull/68) breaking: drop support for Ember < 3.16 - Update ember to 3.28 using ember-cli-update ([@mansona])
+- [empress/guidemaker] [#64](https://github.com/empress/guidemaker/pull/64) breaking: drop support for Node < 14 ([@mansona])
+- [empress/guidemaker] [#63](https://github.com/empress/guidemaker/pull/63) Update ember-get-config ([@mansona])
+- [empress/guidemaker-default-template] [#21](https://github.com/empress/guidemaker-default-template/pull/21) Support Embroider ([@mansona])
+- [empress/guidemaker-default-template] [#20](https://github.com/empress/guidemaker-default-template/pull/20) add no deprecations ember-try config ([@mansona])
+- [empress/guidemaker-default-template] [#19](https://github.com/empress/guidemaker-default-template/pull/19) Update to Ember 3.28 with ember-cli-update ([@mansona])
+- [empress/guidemaker-default-template] [#17](https://github.com/empress/guidemaker-default-template/pull/17) breaking: drop support for Node < 14 ([@mansona])
+- [empress/rfc-process] [#18](https://github.com/empress/rfc-process/pull/18) Add ember-meta implementation ([@mansona])
+- [empress/rfc-process-mdbook-template] [#17](https://github.com/empress/rfc-process-mdbook-template/pull/17) fix rfc-process peer dependency ([@mansona])
+- [empress/rfc-process-mdbook-template] [#16](https://github.com/empress/rfc-process-mdbook-template/pull/16) Supporting rfc-process v1.0 and head-data ([@mansona])
+- [miguelcobain/ember-paper] [#1228](https://github.com/miguelcobain/ember-paper/pull/1228) update paper-tabs to class syntax ([@mansona])
+- [miguelcobain/ember-paper] [#1227](https://github.com/miguelcobain/ember-paper/pull/1227) update paper-tab to use native class syntax ([@mansona])
+- [miguelcobain/ember-paper] [#1226](https://github.com/miguelcobain/ember-paper/pull/1226) update paper-radio to use native class syntax ([@mansona])
+- [miguelcobain/ember-paper] [#1225](https://github.com/miguelcobain/ember-paper/pull/1225) update paper-item to use native class syntax ([@mansona])
+- [miguelcobain/ember-paper] [#1224](https://github.com/miguelcobain/ember-paper/pull/1224) update paper-grid-tile to use native class syntax ([@mansona])
+- [miguelcobain/ember-paper] [#1223](https://github.com/miguelcobain/ember-paper/pull/1223) Convert paper-form to class syntax ([@mansona])
+- [nickschot/ember-mobile-menu] [#367](https://github.com/nickschot/ember-mobile-menu/pull/367) don't run CI against 4.x+, add all 3.x LTS releases to matrix, use node 12 on CI ([@nickschot])
+- [nickschot/ember-mobile-menu] [#366](https://github.com/nickschot/ember-mobile-menu/pull/366) fix import path for htmlSafe ([@nickschot])
+- [nickschot/ember-mobile-menu] [#365](https://github.com/nickschot/ember-mobile-menu/pull/365) Move README, CONTRIBUTING and LICENSE.md to addon folder ([@nickschot])
+- [nickschot/ember-mobile-menu] [#361](https://github.com/nickschot/ember-mobile-menu/pull/361) remove ember-cli-htmlbars override now that 6.1.0 has been released ([@nickschot])
+- [nickschot/ember-mobile-menu] [#359](https://github.com/nickschot/ember-mobile-menu/pull/359) Revert "Update dependency release-it to v15" ([@nickschot])
+- [nickschot/ember-mobile-menu] [#358](https://github.com/nickschot/ember-mobile-menu/pull/358) Upgrade to pnpm v7 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#357](https://github.com/nickschot/ember-mobile-menu/pull/357) declare ember-source peer dependency for addon ([@nickschot])
+- [nickschot/ember-mobile-menu] [#356](https://github.com/nickschot/ember-mobile-menu/pull/356) Drop node 12 support ([@nickschot])
+- [nickschot/ember-mobile-menu] [#372](https://github.com/nickschot/ember-mobile-menu/pull/372) protect against using window apis in Fastboot ([@mansona])
+- [nickschot/ember-mobile-menu] [#371](https://github.com/nickschot/ember-mobile-menu/pull/371) protect against using window apis in Fastboot ([@mansona])
+- [mainmatter/ember-simple-auth] [#2435](https://github.com/mainmatter/ember-simple-auth/pull/2435) fix(renovate.json): use proper path for .json5 preset ([@oscard0m])
+- [mainmatter/ember-simple-auth] [#2442](https://github.com/mainmatter/ember-simple-auth/pull/2442) Upgrade to qunit 5 2 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2440](https://github.com/mainmatter/ember-simple-auth/pull/2440) docs: add information about v4 release for embroider and typescript users ([@BobrImperator])
+- [zeppelin/ember-click-outside] [#250](https://github.com/zeppelin/ember-click-outside/pull/250) Sync test matrix with GitHub Actions ([@zeppelin])
+- [zeppelin/ember-click-outside] [#249](https://github.com/zeppelin/ember-click-outside/pull/249) Fix component deprecation message ([@zeppelin])
+- [zeppelin/ember-click-outside] [#248](https://github.com/zeppelin/ember-click-outside/pull/248) Add early Ember to test matrix ([@zeppelin])
 
 ## Lint to the future
 
-- [mansona/lint-to-the-future]
-  [#25](https://github.com/mansona/lint-to-the-future/pull/25) Add support for
-  --previousResults to point at a local file instead of a link ([@Mikek2252])
+- [mansona/lint-to-the-future] [#25](https://github.com/mansona/lint-to-the-future/pull/25) Add support for --previousResults to point at a local file instead of a link ([@Mikek2252])
 
 ## JavaScript
 
-- [axmccx/proxynexus] [#32](https://github.com/axmccx/proxynexus/pull/32) Fixes
-  #31 - Add support for new NRDB URLs ([@locks])
+- [axmccx/proxynexus] [#32](https://github.com/axmccx/proxynexus/pull/32) Fixes #31 - Add support for new NRDB URLs ([@locks])
 
 ## Octokit
 
-- [gamberrys/octokit-request-action]
-  [#4](https://github.com/gamberrys/octokit-request-action/pull/4) Update
-  index.js ([@oscard0m])
-- [gamberrys/octokit-request-action]
-  [#3](https://github.com/gamberrys/octokit-request-action/pull/3) Update
-  README.md ([@oscard0m])
-- [gamberrys/octokit-request-action-copy]
-  [#13](https://github.com/gamberrys/octokit-request-action-copy/pull/13) add
-  random dependency and package-lock ([@oscard0m])
-- [octokit/.github] [#14](https://github.com/octokit/.github/pull/14)
-  ci(renovate): configure renovate to unpin GitHub Actions digests ([@oscard0m])
-- [octokit/.github] [#13](https://github.com/octokit/.github/pull/13)
-  feat(workflows): feat(workflows): create 'test.yml' reusable workflow
-  ([@oscard0m])
-- [octokit/app-permissions]
-  [#111](https://github.com/octokit/app-permissions/pull/111) build(deps):
-  remove semantic release as dependency ([@oscard0m])
-- [octokit/auth-action.js]
-  [#226](https://github.com/octokit/auth-action.js/pull/226) ci(test): use
-  text_matrix and test jobs ([@oscard0m])
-- [octokit/auth-callback.js]
-  [#65](https://github.com/octokit/auth-callback.js/pull/65) ci(test): use
-  test_matrix and test jobs ([@oscard0m])
-- [octokit/auth-oauth-app.js]
-  [#247](https://github.com/octokit/auth-oauth-app.js/pull/247) ci(test): use
-  test_matrix and test jobs ([@oscard0m])
-- [octokit/auth-oauth-device.js]
-  [#65](https://github.com/octokit/auth-oauth-device.js/pull/65) ci(test): use
-  test_matrix and test jobs ([@oscard0m])
-- [octokit/auth-unauthenticated.js]
-  [#133](https://github.com/octokit/auth-unauthenticated.js/pull/133) ci(test):
-  add 'npm run lint' as pretest script in package.json ([@oscard0m])
-- [octokit/create-octokit-project.js]
-  [#166](https://github.com/octokit/create-octokit-project.js/pull/166)
-  feat(create-test-action): scaffold test action to run lint only once
-  ([@oscard0m])
-- [octokit/graphql-action]
-  [#136](https://github.com/octokit/graphql-action/pull/136) ci(lint): add
-  'lint' step to the project ([@oscard0m])
-- [octokit/graphql.js] [#369](https://github.com/octokit/graphql.js/pull/369)
-  ci(test): use test_matrix and test jobs ([@oscard0m])
-- [octokit/oauth-authorization-url.js]
-  [#189](https://github.com/octokit/oauth-authorization-url.js/pull/189) Add
-  prettier to project ([@oscard0m])
-- [octokit/oauth-authorization-url.js]
-  [#188](https://github.com/octokit/oauth-authorization-url.js/pull/188)
-  ci(test): use test_matrix and test jobs ([@oscard0m])
-- [octokit/openapi] [#235](https://github.com/octokit/openapi/pull/235)
-  feat(build): improve summary for GitHub Enterprise Server removed endpoints
-  ([@oscard0m])
-- [octokit/plugin-paginate-rest.js]
-  [#407](https://github.com/octokit/plugin-paginate-rest.js/pull/407) ci(test):
-  use test_matrix and test jobs ([@oscard0m])
-- [octokit/plugin-retry.js]
-  [#329](https://github.com/octokit/plugin-retry.js/pull/329) ci(test): use
-  test_matrix and test jobs ([@oscard0m])
-- [octokit/request-action]
-  [#165](https://github.com/octokit/request-action/pull/165) ci(lint): add
-  'lint' step to the project ([@oscard0m])
-- [octokit/request-action]
-  [#159](https://github.com/octokit/request-action/pull/159) ci(release): use
-  OCTOKITBOT_PAT as GITHUB_TOKEN ([@oscard0m])
-- [octokit/request-error.js]
-  [#238](https://github.com/octokit/request-error.js/pull/238) ci(test): use
-  test_matrix and test jobs ([@oscard0m])
-- [octokit/request.js] [#483](https://github.com/octokit/request.js/pull/483)
-  ci(test): use test_matrix and test jobs ([@oscard0m])
-- [octokit/webhooks] [#678](https://github.com/octokit/webhooks/pull/678)
-  fix(schemas): remove 'email' format for 'email' property in
-  committer.schema.json ([@oscard0m])
-- [octokit/webhooks] [#677](https://github.com/octokit/webhooks/pull/677)
-  fix(payload-schemas): add custom RegEx validation for 'email' ([@oscard0m])
-- [oscard0m/octokit-request-action]
-  [#1](https://github.com/oscard0m/octokit-request-action/pull/1) Update
-  test.yml ([@oscard0m])
+- [gamberrys/octokit-request-action] [#4](https://github.com/gamberrys/octokit-request-action/pull/4) Update index.js ([@oscard0m])
+- [gamberrys/octokit-request-action] [#3](https://github.com/gamberrys/octokit-request-action/pull/3) Update README.md ([@oscard0m])
+- [gamberrys/octokit-request-action-copy] [#13](https://github.com/gamberrys/octokit-request-action-copy/pull/13) add random dependency and package-lock ([@oscard0m])
+- [octokit/.github] [#14](https://github.com/octokit/.github/pull/14) ci(renovate): configure renovate to unpin GitHub Actions digests ([@oscard0m])
+- [octokit/.github] [#13](https://github.com/octokit/.github/pull/13) feat(workflows): feat(workflows): create 'test.yml' reusable workflow ([@oscard0m])
+- [octokit/app-permissions] [#111](https://github.com/octokit/app-permissions/pull/111) build(deps): remove semantic release as dependency ([@oscard0m])
+- [octokit/auth-action.js] [#226](https://github.com/octokit/auth-action.js/pull/226) ci(test): use text_matrix and test jobs ([@oscard0m])
+- [octokit/auth-callback.js] [#65](https://github.com/octokit/auth-callback.js/pull/65) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/auth-oauth-app.js] [#247](https://github.com/octokit/auth-oauth-app.js/pull/247) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/auth-oauth-device.js] [#65](https://github.com/octokit/auth-oauth-device.js/pull/65) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/auth-unauthenticated.js] [#133](https://github.com/octokit/auth-unauthenticated.js/pull/133) ci(test): add 'npm run lint' as pretest script in package.json ([@oscard0m])
+- [octokit/create-octokit-project.js] [#166](https://github.com/octokit/create-octokit-project.js/pull/166) feat(create-test-action): scaffold test action to run lint only once ([@oscard0m])
+- [octokit/graphql-action] [#136](https://github.com/octokit/graphql-action/pull/136) ci(lint): add 'lint' step to the project ([@oscard0m])
+- [octokit/graphql.js] [#369](https://github.com/octokit/graphql.js/pull/369) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/oauth-authorization-url.js] [#189](https://github.com/octokit/oauth-authorization-url.js/pull/189) Add prettier to project ([@oscard0m])
+- [octokit/oauth-authorization-url.js] [#188](https://github.com/octokit/oauth-authorization-url.js/pull/188) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/openapi] [#235](https://github.com/octokit/openapi/pull/235) feat(build): improve summary for GitHub Enterprise Server removed endpoints ([@oscard0m])
+- [octokit/plugin-paginate-rest.js] [#407](https://github.com/octokit/plugin-paginate-rest.js/pull/407) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/plugin-retry.js] [#329](https://github.com/octokit/plugin-retry.js/pull/329) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/request-action] [#165](https://github.com/octokit/request-action/pull/165) ci(lint): add 'lint' step to the project ([@oscard0m])
+- [octokit/request-action] [#159](https://github.com/octokit/request-action/pull/159) ci(release): use OCTOKITBOT_PAT as GITHUB_TOKEN ([@oscard0m])
+- [octokit/request-error.js] [#238](https://github.com/octokit/request-error.js/pull/238) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/request.js] [#483](https://github.com/octokit/request.js/pull/483) ci(test): use test_matrix and test jobs ([@oscard0m])
+- [octokit/webhooks] [#678](https://github.com/octokit/webhooks/pull/678) fix(schemas): remove 'email' format for 'email' property in committer.schema.json ([@oscard0m])
+- [octokit/webhooks] [#677](https://github.com/octokit/webhooks/pull/677) fix(payload-schemas): add custom RegEx validation for 'email' ([@oscard0m])
+- [oscard0m/octokit-request-action] [#1](https://github.com/oscard0m/octokit-request-action/pull/1) Update test.yml ([@oscard0m])
 
 [@bobrimperator]: https://github.com/BobrImperator
 [@mikek2252]: https://github.com/Mikek2252
@@ -238,28 +101,20 @@
 [@nickschot]: https://github.com/nickschot
 [@oscard0m]: https://github.com/oscard0m
 [@zeppelin]: https://github.com/zeppelin
-[turbo87/segelflug-classifieds]:
-  https://github.com/Turbo87/segelflug-classifieds
+[turbo87/segelflug-classifieds]: https://github.com/Turbo87/segelflug-classifieds
 [axmccx/proxynexus]: https://github.com/axmccx/proxynexus
 [cibernox/ember-power-select]: https://github.com/cibernox/ember-power-select
 [ef4/ember-auto-import]: https://github.com/ef4/ember-auto-import
-[ember-codemods/ember-codemods-telemetry-helpers]:
-  https://github.com/ember-codemods/ember-codemods-telemetry-helpers
-[ember-codemods/ember-native-class-codemod]:
-  https://github.com/ember-codemods/ember-native-class-codemod
-[ember-learn/guidemaker-ember-template]:
-  https://github.com/ember-learn/guidemaker-ember-template
+[ember-codemods/ember-codemods-telemetry-helpers]: https://github.com/ember-codemods/ember-codemods-telemetry-helpers
+[ember-codemods/ember-native-class-codemod]: https://github.com/ember-codemods/ember-native-class-codemod
+[ember-learn/guidemaker-ember-template]: https://github.com/ember-learn/guidemaker-ember-template
 [ember-learn/rfcs-app]: https://github.com/ember-learn/rfcs-app
-[empress/guidemaker-default-template]:
-  https://github.com/empress/guidemaker-default-template
+[empress/guidemaker-default-template]: https://github.com/empress/guidemaker-default-template
 [empress/guidemaker]: https://github.com/empress/guidemaker
-[empress/rfc-process-mdbook-template]:
-  https://github.com/empress/rfc-process-mdbook-template
+[empress/rfc-process-mdbook-template]: https://github.com/empress/rfc-process-mdbook-template
 [empress/rfc-process]: https://github.com/empress/rfc-process
-[gamberrys/octokit-request-action-copy]:
-  https://github.com/gamberrys/octokit-request-action-copy
-[gamberrys/octokit-request-action]:
-  https://github.com/gamberrys/octokit-request-action
+[gamberrys/octokit-request-action-copy]: https://github.com/gamberrys/octokit-request-action-copy
+[gamberrys/octokit-request-action]: https://github.com/gamberrys/octokit-request-action
 [mansona/lint-to-the-future]: https://github.com/mansona/lint-to-the-future
 [miguelcobain/ember-paper]: https://github.com/miguelcobain/ember-paper
 [mswjs/cookies]: https://github.com/mswjs/cookies
@@ -270,24 +125,19 @@
 [octokit/auth-callback.js]: https://github.com/octokit/auth-callback.js
 [octokit/auth-oauth-app.js]: https://github.com/octokit/auth-oauth-app.js
 [octokit/auth-oauth-device.js]: https://github.com/octokit/auth-oauth-device.js
-[octokit/auth-unauthenticated.js]:
-  https://github.com/octokit/auth-unauthenticated.js
-[octokit/create-octokit-project.js]:
-  https://github.com/octokit/create-octokit-project.js
+[octokit/auth-unauthenticated.js]: https://github.com/octokit/auth-unauthenticated.js
+[octokit/create-octokit-project.js]: https://github.com/octokit/create-octokit-project.js
 [octokit/graphql-action]: https://github.com/octokit/graphql-action
 [octokit/graphql.js]: https://github.com/octokit/graphql.js
-[octokit/oauth-authorization-url.js]:
-  https://github.com/octokit/oauth-authorization-url.js
+[octokit/oauth-authorization-url.js]: https://github.com/octokit/oauth-authorization-url.js
 [octokit/openapi]: https://github.com/octokit/openapi
-[octokit/plugin-paginate-rest.js]:
-  https://github.com/octokit/plugin-paginate-rest.js
+[octokit/plugin-paginate-rest.js]: https://github.com/octokit/plugin-paginate-rest.js
 [octokit/plugin-retry.js]: https://github.com/octokit/plugin-retry.js
 [octokit/request-action]: https://github.com/octokit/request-action
 [octokit/request-error.js]: https://github.com/octokit/request-error.js
 [octokit/request.js]: https://github.com/octokit/request.js
 [octokit/webhooks]: https://github.com/octokit/webhooks
-[oscard0m/octokit-request-action]:
-  https://github.com/oscard0m/octokit-request-action
+[oscard0m/octokit-request-action]: https://github.com/oscard0m/octokit-request-action
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
 [zeppelin/ember-click-outside]: https://github.com/zeppelin/ember-click-outside
diff --git a/src/twios/2022-08-16.md b/src/twios/2022-08-16.md
index 8e4fd25c2a..8eb590f555 100644
--- a/src/twios/2022-08-16.md
+++ b/src/twios/2022-08-16.md
@@ -1,130 +1,59 @@
 ## Rust
 
-- [Turbo87/aprs-parser-rs]
-  [#43](https://github.com/Turbo87/aprs-parser-rs/pull/43) Add APRS protocol
-  reference ([@Turbo87])
-- [Turbo87/aprs-parser-rs]
-  [#42](https://github.com/Turbo87/aprs-parser-rs/pull/42) Raise minimum Rust
-  version to v1.52.0 ([@Turbo87])
-- [kivikakk/comrak] [#238](https://github.com/kivikakk/comrak/pull/238) Replace
-  `lazy_static` dependency with `once_cell` ([@Turbo87])
+- [Turbo87/aprs-parser-rs] [#43](https://github.com/Turbo87/aprs-parser-rs/pull/43) Add APRS protocol reference ([@Turbo87])
+- [Turbo87/aprs-parser-rs] [#42](https://github.com/Turbo87/aprs-parser-rs/pull/42) Raise minimum Rust version to v1.52.0 ([@Turbo87])
+- [kivikakk/comrak] [#238](https://github.com/kivikakk/comrak/pull/238) Replace `lazy_static` dependency with `once_cell` ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#5060](https://github.com/rust-lang/crates.io/pull/5060) admin/upload-index:
-  Restore "skipping file" output ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5044](https://github.com/rust-lang/crates.io/pull/5044) Replace
-  `lazy_static` with `once_cell` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5042](https://github.com/rust-lang/crates.io/pull/5042) Always run
-  background jobs after a test publish ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5041](https://github.com/rust-lang/crates.io/pull/5041) Sort headers of
-  http-data files ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5040](https://github.com/rust-lang/crates.io/pull/5040) Add an option to
-  easily regenerate http-data files ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5039](https://github.com/rust-lang/crates.io/pull/5039) Don't auto-generate
-  empty http-data files ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5038](https://github.com/rust-lang/crates.io/pull/5038) Remove unnecessary
-  request proxy headers ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5037](https://github.com/rust-lang/crates.io/pull/5037) Fail tests if there
-  are remaining exchanges in the request proxy queue ([@Turbo87])
+- [rust-lang/crates.io] [#5060](https://github.com/rust-lang/crates.io/pull/5060) admin/upload-index: Restore "skipping file" output ([@Turbo87])
+- [rust-lang/crates.io] [#5044](https://github.com/rust-lang/crates.io/pull/5044) Replace `lazy_static` with `once_cell` ([@Turbo87])
+- [rust-lang/crates.io] [#5042](https://github.com/rust-lang/crates.io/pull/5042) Always run background jobs after a test publish ([@Turbo87])
+- [rust-lang/crates.io] [#5041](https://github.com/rust-lang/crates.io/pull/5041) Sort headers of http-data files ([@Turbo87])
+- [rust-lang/crates.io] [#5040](https://github.com/rust-lang/crates.io/pull/5040) Add an option to easily regenerate http-data files ([@Turbo87])
+- [rust-lang/crates.io] [#5039](https://github.com/rust-lang/crates.io/pull/5039) Don't auto-generate empty http-data files ([@Turbo87])
+- [rust-lang/crates.io] [#5038](https://github.com/rust-lang/crates.io/pull/5038) Remove unnecessary request proxy headers ([@Turbo87])
+- [rust-lang/crates.io] [#5037](https://github.com/rust-lang/crates.io/pull/5037) Fail tests if there are remaining exchanges in the request proxy queue ([@Turbo87])
 
 ## Ember.js
 
-- [cibernox/ember-power-select]
-  [#1534](https://github.com/cibernox/ember-power-select/pull/1534) add back
-  ember-try scenarios that were removed with ember-cli-update ([@mansona])
-- [ember-cli/watch-detector]
-  [#35](https://github.com/ember-cli/watch-detector/pull/35) Update URLs in
-  package.json ([@locks])
-- [ember-engines/ember-engines]
-  [#810](https://github.com/ember-engines/ember-engines/pull/810) Refactor
-  LinkToExternal to use LinkTo directly ([@BobrImperator])
-- [ember-learn/guides-source]
-  [#1833](https://github.com/ember-learn/guides-source/pull/1833) v4.6.0
-  ([@locks])
-- [ember-learn/rfcs-app] [#11](https://github.com/ember-learn/rfcs-app/pull/11)
-  remove process-rfcs step ([@mansona])
-- [ember-learn/tool-new-release]
-  [#35](https://github.com/ember-learn/tool-new-release/pull/35) Use 1Password
-  CLI for any configuration or secret ([@locks])
-- [ember-template-lint/ember-template-lint]
-  [#2569](https://github.com/ember-template-lint/ember-template-lint/pull/2569)
-  Add autofixer to `require-valid-named-block-naming-format` rule ([@locks])
-- [ember-template-lint/ember-template-lint]
-  [#2568](https://github.com/ember-template-lint/ember-template-lint/pull/2568)
-  Add autofixer to `no-unnecessary-concat` rule ([@locks])
-- [emberjs/core-notes] [#461](https://github.com/emberjs/core-notes/pull/461)
-  Learning - August 4th ([@locks])
-- [emberjs/ember.js] [#20151](https://github.com/emberjs/ember.js/pull/20151)
-  feat: add isExternal argument to simplify ember-engines ([@BobrImperator])
-- [emberjs/rfcs] [#840](https://github.com/emberjs/rfcs/pull/840) fix invalid
-  data issues with FIXMEs ([@mansona])
-- [emberjs/rfcs] [#833](https://github.com/emberjs/rfcs/pull/833) [RFCs App
-  Rendering] Reformat frontmatter ([@mansona])
-- [emberjs/rfcs-tooling] [#4](https://github.com/emberjs/rfcs-tooling/pull/4)
-  update to the new frontmatter format ([@mansona])
-- [empress/ember-showdown-prism]
-  [#31](https://github.com/empress/ember-showdown-prism/pull/31) update
-  ember-prism ([@mansona])
-- [empress/ember-showdown-prism]
-  [#27](https://github.com/empress/ember-showdown-prism/pull/27) fix ember-try
-  npm overrides ([@mansona])
-- [empress/guidemaker] [#73](https://github.com/empress/guidemaker/pull/73)
-  update to ember-auto-import@2 ([@mansona])
-- [empress/guidemaker-default-template]
-  [#24](https://github.com/empress/guidemaker-default-template/pull/24) update
-  algolia ([@mansona])
-- [empress/guidemaker-default-template]
-  [#23](https://github.com/empress/guidemaker-default-template/pull/23) update
-  algolia ([@mansona])
-- [mainmatter/ember-simple-auth]
-  [#2445](https://github.com/mainmatter/ember-simple-auth/pull/2445) chore: pin
-  @ember/test-helpers ~2.7.0 ([@BobrImperator])
+- [cibernox/ember-power-select] [#1534](https://github.com/cibernox/ember-power-select/pull/1534) add back ember-try scenarios that were removed with ember-cli-update ([@mansona])
+- [ember-cli/watch-detector] [#35](https://github.com/ember-cli/watch-detector/pull/35) Update URLs in package.json ([@locks])
+- [ember-engines/ember-engines] [#810](https://github.com/ember-engines/ember-engines/pull/810) Refactor LinkToExternal to use LinkTo directly ([@BobrImperator])
+- [ember-learn/guides-source] [#1833](https://github.com/ember-learn/guides-source/pull/1833) v4.6.0 ([@locks])
+- [ember-learn/rfcs-app] [#11](https://github.com/ember-learn/rfcs-app/pull/11) remove process-rfcs step ([@mansona])
+- [ember-learn/tool-new-release] [#35](https://github.com/ember-learn/tool-new-release/pull/35) Use 1Password CLI for any configuration or secret ([@locks])
+- [ember-template-lint/ember-template-lint] [#2569](https://github.com/ember-template-lint/ember-template-lint/pull/2569) Add autofixer to `require-valid-named-block-naming-format` rule ([@locks])
+- [ember-template-lint/ember-template-lint] [#2568](https://github.com/ember-template-lint/ember-template-lint/pull/2568) Add autofixer to `no-unnecessary-concat` rule ([@locks])
+- [emberjs/core-notes] [#461](https://github.com/emberjs/core-notes/pull/461) Learning - August 4th ([@locks])
+- [emberjs/ember.js] [#20151](https://github.com/emberjs/ember.js/pull/20151) feat: add isExternal argument to simplify ember-engines ([@BobrImperator])
+- [emberjs/rfcs] [#840](https://github.com/emberjs/rfcs/pull/840) fix invalid data issues with FIXMEs ([@mansona])
+- [emberjs/rfcs] [#833](https://github.com/emberjs/rfcs/pull/833) [RFCs App Rendering] Reformat frontmatter ([@mansona])
+- [emberjs/rfcs-tooling] [#4](https://github.com/emberjs/rfcs-tooling/pull/4) update to the new frontmatter format ([@mansona])
+- [empress/ember-showdown-prism] [#31](https://github.com/empress/ember-showdown-prism/pull/31) update ember-prism ([@mansona])
+- [empress/ember-showdown-prism] [#27](https://github.com/empress/ember-showdown-prism/pull/27) fix ember-try npm overrides ([@mansona])
+- [empress/guidemaker] [#73](https://github.com/empress/guidemaker/pull/73) update to ember-auto-import@2 ([@mansona])
+- [empress/guidemaker-default-template] [#24](https://github.com/empress/guidemaker-default-template/pull/24) update algolia ([@mansona])
+- [empress/guidemaker-default-template] [#23](https://github.com/empress/guidemaker-default-template/pull/23) update algolia ([@mansona])
+- [mainmatter/ember-simple-auth] [#2445](https://github.com/mainmatter/ember-simple-auth/pull/2445) chore: pin @ember/test-helpers ~2.7.0 ([@BobrImperator])
 
 ## Lint to the future
 
-- [mansona/lint-to-the-future]
-  [#26](https://github.com/mansona/lint-to-the-future/pull/26) Update README.md
-  ([@Mikek2252])
-- [mansona/lint-to-the-future-dashboard-action]
-  [#1](https://github.com/mansona/lint-to-the-future-dashboard-action/pull/1)
-  Update README.md ([@Mikek2252])
+- [mansona/lint-to-the-future] [#26](https://github.com/mansona/lint-to-the-future/pull/26) Update README.md ([@Mikek2252])
+- [mansona/lint-to-the-future-dashboard-action] [#1](https://github.com/mansona/lint-to-the-future-dashboard-action/pull/1) Update README.md ([@Mikek2252])
 
 ## JavaScript
 
-- [mansona/showdown-section-groups]
-  [#4](https://github.com/mansona/showdown-section-groups/pull/4) drop babel and
-  just use modules ([@mansona])
-- [mansona/showdown-section-groups]
-  [#3](https://github.com/mansona/showdown-section-groups/pull/3) Fix the repo
-  metadata and add a more useful readme ([@mansona])
-- [mansona/showdown-section-groups]
-  [#2](https://github.com/mansona/showdown-section-groups/pull/2) breaking: drop
-  support for Node < 14 (EOL) ([@mansona])
-- [mansona/showdown-section-groups]
-  [#1](https://github.com/mansona/showdown-section-groups/pull/1) move to GitHub
-  actions ([@mansona])
-- [calibreapp/image-actions]
-  [#126](https://github.com/calibreapp/image-actions/pull/126) fix(entrypoint):
-  exit(0) when pull_request.&lt;event&gt; is not 'synchronize' or 'opened'
-  ([@oscard0m])
+- [mansona/showdown-section-groups] [#4](https://github.com/mansona/showdown-section-groups/pull/4) drop babel and just use modules ([@mansona])
+- [mansona/showdown-section-groups] [#3](https://github.com/mansona/showdown-section-groups/pull/3) Fix the repo metadata and add a more useful readme ([@mansona])
+- [mansona/showdown-section-groups] [#2](https://github.com/mansona/showdown-section-groups/pull/2) breaking: drop support for Node < 14 (EOL) ([@mansona])
+- [mansona/showdown-section-groups] [#1](https://github.com/mansona/showdown-section-groups/pull/1) move to GitHub actions ([@mansona])
+- [calibreapp/image-actions] [#126](https://github.com/calibreapp/image-actions/pull/126) fix(entrypoint): exit(0) when pull_request.&lt;event&gt; is not 'synchronize' or 'opened' ([@oscard0m])
 
 ## Octokit
 
-- [octokit/auth-oauth-user.js]
-  [#71](https://github.com/octokit/auth-oauth-user.js/pull/71) ci(test): use
-  Octokit's 'test' Workflow ([@oscard0m])
-- [octokit/webhooks-methods.js]
-  [#66](https://github.com/octokit/webhooks-methods.js/pull/66) ci(test): re-use
-  Octokit's test.yml action ([@oscard0m])
+- [octokit/auth-oauth-user.js] [#71](https://github.com/octokit/auth-oauth-user.js/pull/71) ci(test): use Octokit's 'test' Workflow ([@oscard0m])
+- [octokit/webhooks-methods.js] [#66](https://github.com/octokit/webhooks-methods.js/pull/66) ci(test): re-use Octokit's test.yml action ([@oscard0m])
 
 [@bobrimperator]: https://github.com/BobrImperator
 [@mikek2252]: https://github.com/Mikek2252
@@ -140,22 +69,18 @@
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [ember-learn/rfcs-app]: https://github.com/ember-learn/rfcs-app
 [ember-learn/tool-new-release]: https://github.com/ember-learn/tool-new-release
-[ember-template-lint/ember-template-lint]:
-  https://github.com/ember-template-lint/ember-template-lint
+[ember-template-lint/ember-template-lint]: https://github.com/ember-template-lint/ember-template-lint
 [emberjs/core-notes]: https://github.com/emberjs/core-notes
 [emberjs/ember.js]: https://github.com/emberjs/ember.js
 [emberjs/rfcs-tooling]: https://github.com/emberjs/rfcs-tooling
 [emberjs/rfcs]: https://github.com/emberjs/rfcs
 [empress/ember-showdown-prism]: https://github.com/empress/ember-showdown-prism
-[empress/guidemaker-default-template]:
-  https://github.com/empress/guidemaker-default-template
+[empress/guidemaker-default-template]: https://github.com/empress/guidemaker-default-template
 [empress/guidemaker]: https://github.com/empress/guidemaker
 [kivikakk/comrak]: https://github.com/kivikakk/comrak
-[mansona/lint-to-the-future-dashboard-action]:
-  https://github.com/mansona/lint-to-the-future-dashboard-action
+[mansona/lint-to-the-future-dashboard-action]: https://github.com/mansona/lint-to-the-future-dashboard-action
 [mansona/lint-to-the-future]: https://github.com/mansona/lint-to-the-future
-[mansona/showdown-section-groups]:
-  https://github.com/mansona/showdown-section-groups
+[mansona/showdown-section-groups]: https://github.com/mansona/showdown-section-groups
 [octokit/auth-oauth-user.js]: https://github.com/octokit/auth-oauth-user.js
 [octokit/webhooks-methods.js]: https://github.com/octokit/webhooks-methods.js
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
diff --git a/src/twios/2022-09-07.md b/src/twios/2022-09-07.md
index 0a3adf5040..a8ba8c53dc 100644
--- a/src/twios/2022-09-07.md
+++ b/src/twios/2022-09-07.md
@@ -1,252 +1,117 @@
 ## Rust
 
-- [LukeMathWalker/tracing-bunyan-formatter]
-  [#20](https://github.com/LukeMathWalker/tracing-bunyan-formatter/pull/20)
-  Migrate from `claim` to `claims` ([@Turbo87])
-- [Turbo87/segelflug-classifieds]
-  [#350](https://github.com/Turbo87/segelflug-classifieds/pull/350) Fix "byte
-  index is not a char boundary" crash ([@Turbo87])
+- [LukeMathWalker/tracing-bunyan-formatter] [#20](https://github.com/LukeMathWalker/tracing-bunyan-formatter/pull/20) Migrate from `claim` to `claims` ([@Turbo87])
+- [Turbo87/segelflug-classifieds] [#350](https://github.com/Turbo87/segelflug-classifieds/pull/350) Fix "byte index is not a char boundary" crash ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#5170](https://github.com/rust-lang/crates.io/pull/5170) Remove icons from
-  page headers ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5167](https://github.com/rust-lang/crates.io/pull/5167) PageHeader: Remove
-  margins on `.heading` element ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5166](https://github.com/rust-lang/crates.io/pull/5166) tests/record: Fix
-  server bind IP address ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5165](https://github.com/rust-lang/crates.io/pull/5165) Migrate from `claim`
-  to `claims` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5164](https://github.com/rust-lang/crates.io/pull/5164) accept-invite: Use
-  `<LinkTo>` instead of raw `<a>` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5155](https://github.com/rust-lang/crates.io/pull/5155) Use slightly darker
-  background color for header and footer ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5150](https://github.com/rust-lang/crates.io/pull/5150) renovate: Group
-  `diesel` packages in one pull request ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5149](https://github.com/rust-lang/crates.io/pull/5149) Adjust header
-  foreground colors ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5148](https://github.com/rust-lang/crates.io/pull/5148) RenderedHtml: Fix
-  inline code styling in lists ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5146](https://github.com/rust-lang/crates.io/pull/5146) Use snapshot testing
-  for `category` API tests ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5145](https://github.com/rust-lang/crates.io/pull/5145) EncodableVersion:
-  Expose new `checksum` field on the API ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5144](https://github.com/rust-lang/crates.io/pull/5144) Fix rustdoc link
-  rendering in READMEs ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5135](https://github.com/rust-lang/crates.io/pull/5135) versions: Adjust
-  `checksum` column to be `NOT NULL` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5134](https://github.com/rust-lang/crates.io/pull/5134) Docker: Fix pnpm
-  usage ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5133](https://github.com/rust-lang/crates.io/pull/5133) tests: Use `insta`
-  to assert on full version API responses ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5132](https://github.com/rust-lang/crates.io/pull/5132) CI: Run `percy exec`
-  with `pnpm` instead of `pnpx` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5126](https://github.com/rust-lang/crates.io/pull/5126) Replace
-  `ember-api-actions` dependency with `customAction()` function ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5125](https://github.com/rust-lang/crates.io/pull/5125) ember-data: Silence
-  `model-save-promise` deprecation ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5123](https://github.com/rust-lang/crates.io/pull/5123) ember-data: Replace
-  `store.find()` calls with `store.findRecord()` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5122](https://github.com/rust-lang/crates.io/pull/5122) admin::git_import:
-  Improve error reporting ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5118](https://github.com/rust-lang/crates.io/pull/5118) ESLint: Add missing
-  `@babel/plugin-proposal-decorators` dependency ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5115](https://github.com/rust-lang/crates.io/pull/5115) ember-concurrency:
-  Migrate to new task syntax API ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5101](https://github.com/rust-lang/crates.io/pull/5101) pnpm: Fix more peer
-  dependency issues ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5100](https://github.com/rust-lang/crates.io/pull/5100) pnpm: Ignore
-  `postcss` peer dependency warnings ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5091](https://github.com/rust-lang/crates.io/pull/5091) database: Add
-  `explicit_name` column to `dependencies` table ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5089](https://github.com/rust-lang/crates.io/pull/5089) index: Use/Allow
-  alphabetic ordering of features and dependencies ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5084](https://github.com/rust-lang/crates.io/pull/5084) Migrate from yarn
-  1.x to pnpm ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5077](https://github.com/rust-lang/crates.io/pull/5077) database: Add
-  `checksum` field ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5074](https://github.com/rust-lang/crates.io/pull/5074) Stop saving badges
-  in the database ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5071](https://github.com/rust-lang/crates.io/pull/5071) Stop returning
-  deprecated badges from API ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5070](https://github.com/rust-lang/crates.io/pull/5070) Remove unnecessary
-  derefs ([@Turbo87])
+- [rust-lang/crates.io] [#5170](https://github.com/rust-lang/crates.io/pull/5170) Remove icons from page headers ([@Turbo87])
+- [rust-lang/crates.io] [#5167](https://github.com/rust-lang/crates.io/pull/5167) PageHeader: Remove margins on `.heading` element ([@Turbo87])
+- [rust-lang/crates.io] [#5166](https://github.com/rust-lang/crates.io/pull/5166) tests/record: Fix server bind IP address ([@Turbo87])
+- [rust-lang/crates.io] [#5165](https://github.com/rust-lang/crates.io/pull/5165) Migrate from `claim` to `claims` ([@Turbo87])
+- [rust-lang/crates.io] [#5164](https://github.com/rust-lang/crates.io/pull/5164) accept-invite: Use `<LinkTo>` instead of raw `<a>` ([@Turbo87])
+- [rust-lang/crates.io] [#5155](https://github.com/rust-lang/crates.io/pull/5155) Use slightly darker background color for header and footer ([@Turbo87])
+- [rust-lang/crates.io] [#5150](https://github.com/rust-lang/crates.io/pull/5150) renovate: Group `diesel` packages in one pull request ([@Turbo87])
+- [rust-lang/crates.io] [#5149](https://github.com/rust-lang/crates.io/pull/5149) Adjust header foreground colors ([@Turbo87])
+- [rust-lang/crates.io] [#5148](https://github.com/rust-lang/crates.io/pull/5148) RenderedHtml: Fix inline code styling in lists ([@Turbo87])
+- [rust-lang/crates.io] [#5146](https://github.com/rust-lang/crates.io/pull/5146) Use snapshot testing for `category` API tests ([@Turbo87])
+- [rust-lang/crates.io] [#5145](https://github.com/rust-lang/crates.io/pull/5145) EncodableVersion: Expose new `checksum` field on the API ([@Turbo87])
+- [rust-lang/crates.io] [#5144](https://github.com/rust-lang/crates.io/pull/5144) Fix rustdoc link rendering in READMEs ([@Turbo87])
+- [rust-lang/crates.io] [#5135](https://github.com/rust-lang/crates.io/pull/5135) versions: Adjust `checksum` column to be `NOT NULL` ([@Turbo87])
+- [rust-lang/crates.io] [#5134](https://github.com/rust-lang/crates.io/pull/5134) Docker: Fix pnpm usage ([@Turbo87])
+- [rust-lang/crates.io] [#5133](https://github.com/rust-lang/crates.io/pull/5133) tests: Use `insta` to assert on full version API responses ([@Turbo87])
+- [rust-lang/crates.io] [#5132](https://github.com/rust-lang/crates.io/pull/5132) CI: Run `percy exec` with `pnpm` instead of `pnpx` ([@Turbo87])
+- [rust-lang/crates.io] [#5126](https://github.com/rust-lang/crates.io/pull/5126) Replace `ember-api-actions` dependency with `customAction()` function ([@Turbo87])
+- [rust-lang/crates.io] [#5125](https://github.com/rust-lang/crates.io/pull/5125) ember-data: Silence `model-save-promise` deprecation ([@Turbo87])
+- [rust-lang/crates.io] [#5123](https://github.com/rust-lang/crates.io/pull/5123) ember-data: Replace `store.find()` calls with `store.findRecord()` ([@Turbo87])
+- [rust-lang/crates.io] [#5122](https://github.com/rust-lang/crates.io/pull/5122) admin::git_import: Improve error reporting ([@Turbo87])
+- [rust-lang/crates.io] [#5118](https://github.com/rust-lang/crates.io/pull/5118) ESLint: Add missing `@babel/plugin-proposal-decorators` dependency ([@Turbo87])
+- [rust-lang/crates.io] [#5115](https://github.com/rust-lang/crates.io/pull/5115) ember-concurrency: Migrate to new task syntax API ([@Turbo87])
+- [rust-lang/crates.io] [#5101](https://github.com/rust-lang/crates.io/pull/5101) pnpm: Fix more peer dependency issues ([@Turbo87])
+- [rust-lang/crates.io] [#5100](https://github.com/rust-lang/crates.io/pull/5100) pnpm: Ignore `postcss` peer dependency warnings ([@Turbo87])
+- [rust-lang/crates.io] [#5091](https://github.com/rust-lang/crates.io/pull/5091) database: Add `explicit_name` column to `dependencies` table ([@Turbo87])
+- [rust-lang/crates.io] [#5089](https://github.com/rust-lang/crates.io/pull/5089) index: Use/Allow alphabetic ordering of features and dependencies ([@Turbo87])
+- [rust-lang/crates.io] [#5084](https://github.com/rust-lang/crates.io/pull/5084) Migrate from yarn 1.x to pnpm ([@Turbo87])
+- [rust-lang/crates.io] [#5077](https://github.com/rust-lang/crates.io/pull/5077) database: Add `checksum` field ([@Turbo87])
+- [rust-lang/crates.io] [#5074](https://github.com/rust-lang/crates.io/pull/5074) Stop saving badges in the database ([@Turbo87])
+- [rust-lang/crates.io] [#5071](https://github.com/rust-lang/crates.io/pull/5071) Stop returning deprecated badges from API ([@Turbo87])
+- [rust-lang/crates.io] [#5070](https://github.com/rust-lang/crates.io/pull/5070) Remove unnecessary derefs ([@Turbo87])
 
 ## Octoherd
 
-- [octoherd/.github] [#5](https://github.com/octoherd/.github/pull/5)
-  feat(default.json): remove 'helpers:pinGitHubActionDigests' ([@oscard0m])
+- [octoherd/.github] [#5](https://github.com/octoherd/.github/pull/5) feat(default.json): remove 'helpers:pinGitHubActionDigests' ([@oscard0m])
 
 ## Ember.js
 
-- [ef4/ember-auto-import]
-  [#533](https://github.com/ef4/ember-auto-import/pull/533) update
-  package-lock.json version of htmlbars ([@mansona])
-- [ember-learn/ember-blog]
-  [#1201](https://github.com/ember-learn/ember-blog/pull/1201) update
-  empress-blog ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#431](https://github.com/ember-learn/ember-styleguide/pull/431) fix issues
-  with ember-try release scenarios ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#115](https://github.com/ember-learn/guidemaker-ember-template/pull/115) add
-  website-redesign branch to builds ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#114](https://github.com/ember-learn/guidemaker-ember-template/pull/114) add
-  deprecations scenarios to ember-try ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#113](https://github.com/ember-learn/guidemaker-ember-template/pull/113) run
-  angle-brackets-codemod ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#112](https://github.com/ember-learn/guidemaker-ember-template/pull/112)
-  remove the use of implicit-this ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#111](https://github.com/ember-learn/guidemaker-ember-template/pull/111) fix
-  ember-try for Ember release, beta, and alpha ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#110](https://github.com/ember-learn/guidemaker-ember-template/pull/110)
-  Update dependencies to fix CI ([@mansona])
-- [ember-template-lint/ember-template-lint]
-  [#2584](https://github.com/ember-template-lint/ember-template-lint/pull/2584)
-  Add autofixer to `linebreak-style` rule ([@locks])
-- [ember-template-lint/ember-template-lint]
-  [#2583](https://github.com/ember-template-lint/ember-template-lint/pull/2583)
-  Add autofixer to `self-closing-void-elements` rule ([@locks])
-- [ember-template-lint/ember-template-lint]
-  [#2582](https://github.com/ember-template-lint/ember-template-lint/pull/2582)
-  Add autofixer to `no-quoteless-attributes` rule ([@locks])
-- [ember-template-lint/ember-template-lint]
-  [#2581](https://github.com/ember-template-lint/ember-template-lint/pull/2581)
-  Add autofixer to `no-html-comments` rule ([@locks])
-- [ember-template-lint/ember-template-lint]
-  [#2580](https://github.com/ember-template-lint/ember-template-lint/pull/2580)
-  Add autofixer to `no-unused-block-params` rule ([@locks])
-- [empress/guidemaker] [#76](https://github.com/empress/guidemaker/pull/76) fix
-  transitionTo deprecations ([@mansona])
-- [empress/guidemaker] [#75](https://github.com/empress/guidemaker/pull/75) fix
-  ember-try for pre-releases ([@mansona])
-- [empress/guidemaker] [#74](https://github.com/empress/guidemaker/pull/74)
-  update dependencies to fix CI ([@mansona])
-- [empress/guidemaker-default-template]
-  [#28](https://github.com/empress/guidemaker-default-template/pull/28) remove
-  link-to override ([@mansona])
-- [empress/guidemaker-default-template]
-  [#27](https://github.com/empress/guidemaker-default-template/pull/27) fix
-  no-implicit-this and template deprecations ([@mansona])
-- [empress/guidemaker-default-template]
-  [#26](https://github.com/empress/guidemaker-default-template/pull/26) remove
-  ember-cli-google-fonts ([@mansona])
-- [empress/guidemaker-default-template]
-  [#25](https://github.com/empress/guidemaker-default-template/pull/25) fix the
-  contains helper that never worked ([@mansona])
+- [ef4/ember-auto-import] [#533](https://github.com/ef4/ember-auto-import/pull/533) update package-lock.json version of htmlbars ([@mansona])
+- [ember-learn/ember-blog] [#1201](https://github.com/ember-learn/ember-blog/pull/1201) update empress-blog ([@mansona])
+- [ember-learn/ember-styleguide] [#431](https://github.com/ember-learn/ember-styleguide/pull/431) fix issues with ember-try release scenarios ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#115](https://github.com/ember-learn/guidemaker-ember-template/pull/115) add website-redesign branch to builds ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#114](https://github.com/ember-learn/guidemaker-ember-template/pull/114) add deprecations scenarios to ember-try ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#113](https://github.com/ember-learn/guidemaker-ember-template/pull/113) run angle-brackets-codemod ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#112](https://github.com/ember-learn/guidemaker-ember-template/pull/112) remove the use of implicit-this ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#111](https://github.com/ember-learn/guidemaker-ember-template/pull/111) fix ember-try for Ember release, beta, and alpha ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#110](https://github.com/ember-learn/guidemaker-ember-template/pull/110) Update dependencies to fix CI ([@mansona])
+- [ember-template-lint/ember-template-lint] [#2584](https://github.com/ember-template-lint/ember-template-lint/pull/2584) Add autofixer to `linebreak-style` rule ([@locks])
+- [ember-template-lint/ember-template-lint] [#2583](https://github.com/ember-template-lint/ember-template-lint/pull/2583) Add autofixer to `self-closing-void-elements` rule ([@locks])
+- [ember-template-lint/ember-template-lint] [#2582](https://github.com/ember-template-lint/ember-template-lint/pull/2582) Add autofixer to `no-quoteless-attributes` rule ([@locks])
+- [ember-template-lint/ember-template-lint] [#2581](https://github.com/ember-template-lint/ember-template-lint/pull/2581) Add autofixer to `no-html-comments` rule ([@locks])
+- [ember-template-lint/ember-template-lint] [#2580](https://github.com/ember-template-lint/ember-template-lint/pull/2580) Add autofixer to `no-unused-block-params` rule ([@locks])
+- [empress/guidemaker] [#76](https://github.com/empress/guidemaker/pull/76) fix transitionTo deprecations ([@mansona])
+- [empress/guidemaker] [#75](https://github.com/empress/guidemaker/pull/75) fix ember-try for pre-releases ([@mansona])
+- [empress/guidemaker] [#74](https://github.com/empress/guidemaker/pull/74) update dependencies to fix CI ([@mansona])
+- [empress/guidemaker-default-template] [#28](https://github.com/empress/guidemaker-default-template/pull/28) remove link-to override ([@mansona])
+- [empress/guidemaker-default-template] [#27](https://github.com/empress/guidemaker-default-template/pull/27) fix no-implicit-this and template deprecations ([@mansona])
+- [empress/guidemaker-default-template] [#26](https://github.com/empress/guidemaker-default-template/pull/26) remove ember-cli-google-fonts ([@mansona])
+- [empress/guidemaker-default-template] [#25](https://github.com/empress/guidemaker-default-template/pull/25) fix the contains helper that never worked ([@mansona])
 
 ## Lint to the future
 
-- [mansona/lint-to-the-future-stylelint]
-  [#6](https://github.com/mansona/lint-to-the-future-stylelint/pull/6) Add a
-  basic testing system ([@mansona])
+- [mansona/lint-to-the-future-stylelint] [#6](https://github.com/mansona/lint-to-the-future-stylelint/pull/6) Add a basic testing system ([@mansona])
 
 ## JavaScript
 
-- [volta-cli/action] [#100](https://github.com/volta-cli/action/pull/100) Fix
-  changelog heading ([@Turbo87])
+- [volta-cli/action] [#100](https://github.com/volta-cli/action/pull/100) Fix changelog heading ([@Turbo87])
 
 ## Octokit
 
-- [octokit/auth-oauth-device.js]
-  [#74](https://github.com/octokit/auth-oauth-device.js/pull/74) fix(test):
-  force test failure ([@oscard0m])
-- [octokit/auth-oauth-device.js]
-  [#72](https://github.com/octokit/auth-oauth-device.js/pull/72) revert(deps):
-  lock file maintenance ([@oscard0m])
-- [octokit/oauth-app.js]
-  [#331](https://github.com/octokit/oauth-app.js/pull/331) fix(bundlesize): move
-  'aws-lambda' as devDependency ([@oscard0m])
-- [oscard0m/octoherd-script-fix-test-workflow-octokit]
-  [#1](https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit/pull/1)
-  feat: Initial version ([@oscard0m])
-- [oscard0m/octoherd-script-remove-renovate-package.json]
-  [#1](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/1)
-  feat: Initial version ([@oscard0m])
+- [octokit/auth-oauth-device.js] [#74](https://github.com/octokit/auth-oauth-device.js/pull/74) fix(test): force test failure ([@oscard0m])
+- [octokit/auth-oauth-device.js] [#72](https://github.com/octokit/auth-oauth-device.js/pull/72) revert(deps): lock file maintenance ([@oscard0m])
+- [octokit/oauth-app.js] [#331](https://github.com/octokit/oauth-app.js/pull/331) fix(bundlesize): move 'aws-lambda' as devDependency ([@oscard0m])
+- [oscard0m/octoherd-script-fix-test-workflow-octokit] [#1](https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit/pull/1) feat: Initial version ([@oscard0m])
+- [oscard0m/octoherd-script-remove-renovate-package.json] [#1](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/1) feat: Initial version ([@oscard0m])
 
 ## Probot
 
-- [probot/example-vercel]
-  [#50](https://github.com/probot/example-vercel/pull/50) docs(README): add
-  section for 'Other examples' ([@oscard0m])
-- [probot/example-vercel]
-  [#49](https://github.com/probot/example-vercel/pull/49) docs(readme): add
-  considerations for deploying with vercel ([@oscard0m])
-- [probot/probot] [#1724](https://github.com/probot/probot/pull/1724)
-  build(deps): upgrade octokit/types to v7.1.1 ([@oscard0m])
+- [probot/example-vercel] [#50](https://github.com/probot/example-vercel/pull/50) docs(README): add section for 'Other examples' ([@oscard0m])
+- [probot/example-vercel] [#49](https://github.com/probot/example-vercel/pull/49) docs(readme): add considerations for deploying with vercel ([@oscard0m])
+- [probot/probot] [#1724](https://github.com/probot/probot/pull/1724) build(deps): upgrade octokit/types to v7.1.1 ([@oscard0m])
 
 [@turbo87]: https://github.com/Turbo87
 [@candunaj]: https://github.com/candunaj
 [@locks]: https://github.com/locks
 [@mansona]: https://github.com/mansona
 [@oscard0m]: https://github.com/oscard0m
-[lukemathwalker/tracing-bunyan-formatter]:
-  https://github.com/LukeMathWalker/tracing-bunyan-formatter
-[turbo87/segelflug-classifieds]:
-  https://github.com/Turbo87/segelflug-classifieds
+[lukemathwalker/tracing-bunyan-formatter]: https://github.com/LukeMathWalker/tracing-bunyan-formatter
+[turbo87/segelflug-classifieds]: https://github.com/Turbo87/segelflug-classifieds
 [ef4/ember-auto-import]: https://github.com/ef4/ember-auto-import
-[ember-codemods/ember-angle-brackets-codemod]:
-  https://github.com/ember-codemods/ember-angle-brackets-codemod
+[ember-codemods/ember-angle-brackets-codemod]: https://github.com/ember-codemods/ember-angle-brackets-codemod
 [ember-learn/ember-blog]: https://github.com/ember-learn/ember-blog
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
-[ember-learn/guidemaker-ember-template]:
-  https://github.com/ember-learn/guidemaker-ember-template
-[ember-template-lint/ember-template-lint]:
-  https://github.com/ember-template-lint/ember-template-lint
-[empress/guidemaker-default-template]:
-  https://github.com/empress/guidemaker-default-template
+[ember-learn/guidemaker-ember-template]: https://github.com/ember-learn/guidemaker-ember-template
+[ember-template-lint/ember-template-lint]: https://github.com/ember-template-lint/ember-template-lint
+[empress/guidemaker-default-template]: https://github.com/empress/guidemaker-default-template
 [empress/guidemaker]: https://github.com/empress/guidemaker
-[mansona/lint-to-the-future-stylelint]:
-  https://github.com/mansona/lint-to-the-future-stylelint
+[mansona/lint-to-the-future-stylelint]: https://github.com/mansona/lint-to-the-future-stylelint
 [octoherd/.github]: https://github.com/octoherd/.github
-[octoherd/create-octoherd-script]:
-  https://github.com/octoherd/create-octoherd-script
-[octoherd/script-setup-renovate]:
-  https://github.com/octoherd/script-setup-renovate
+[octoherd/create-octoherd-script]: https://github.com/octoherd/create-octoherd-script
+[octoherd/script-setup-renovate]: https://github.com/octoherd/script-setup-renovate
 [octokit/auth-oauth-device.js]: https://github.com/octokit/auth-oauth-device.js
 [octokit/oauth-app.js]: https://github.com/octokit/oauth-app.js
 [oscard0m/example-vercel-ts]: https://github.com/oscard0m/example-vercel-ts
 [oscard0m/gravity_dummy]: https://github.com/oscard0m/gravity_dummy
-[oscard0m/octoherd-script-fix-test-workflow-octokit]:
-  https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit
-[oscard0m/octoherd-script-remove-renovate-package.json]:
-  https://github.com/oscard0m/octoherd-script-remove-renovate-package.json
+[oscard0m/octoherd-script-fix-test-workflow-octokit]: https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit
+[oscard0m/octoherd-script-remove-renovate-package.json]: https://github.com/oscard0m/octoherd-script-remove-renovate-package.json
 [probot/example-vercel]: https://github.com/probot/example-vercel
 [probot/probot]: https://github.com/probot/probot
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
diff --git a/src/twios/2022-10-03.md b/src/twios/2022-10-03.md
index 358e4d22ff..45a94efa80 100644
--- a/src/twios/2022-10-03.md
+++ b/src/twios/2022-10-03.md
@@ -1,194 +1,97 @@
 ## Rust
 
-- [Turbo87/united-flarmnet]
-  [#162](https://github.com/Turbo87/united-flarmnet/pull/162) workflows/run:
-  Deploy to GitHub Pages directly ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#157](https://github.com/Turbo87/united-flarmnet/pull/157) CI: Simplify `CI`
-  workflow ([@Turbo87])
-- [Turbo87/united-flarmnet]
-  [#156](https://github.com/Turbo87/united-flarmnet/pull/156) CI: Simplify and
-  improve `Run` workflow ([@Turbo87])
+- [Turbo87/united-flarmnet] [#162](https://github.com/Turbo87/united-flarmnet/pull/162) workflows/run: Deploy to GitHub Pages directly ([@Turbo87])
+- [Turbo87/united-flarmnet] [#157](https://github.com/Turbo87/united-flarmnet/pull/157) CI: Simplify `CI` workflow ([@Turbo87])
+- [Turbo87/united-flarmnet] [#156](https://github.com/Turbo87/united-flarmnet/pull/156) CI: Simplify and improve `Run` workflow ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#5262](https://github.com/rust-lang/crates.io/pull/5262) CI: Replace
-  `volta-cli/action` with builtin functionality from `actions/setup-node`
-  ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5244](https://github.com/rust-lang/crates.io/pull/5244) Use slightly darker
-  background color for header and footer ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5243](https://github.com/rust-lang/crates.io/pull/5243) CrateHeader: Fix
-  narrow screen layout ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5238](https://github.com/rust-lang/crates.io/pull/5238) ember-get-config:
-  Use override to update to v2.1.1 ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5233](https://github.com/rust-lang/crates.io/pull/5233) ember-data: Enable
-  `crypto.randomUUID()` polyfill ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5180](https://github.com/rust-lang/crates.io/pull/5180) services/session:
-  Clear in-memory data when logging out ([@Turbo87])
+- [rust-lang/crates.io] [#5262](https://github.com/rust-lang/crates.io/pull/5262) CI: Replace `volta-cli/action` with builtin functionality from `actions/setup-node` ([@Turbo87])
+- [rust-lang/crates.io] [#5244](https://github.com/rust-lang/crates.io/pull/5244) Use slightly darker background color for header and footer ([@Turbo87])
+- [rust-lang/crates.io] [#5243](https://github.com/rust-lang/crates.io/pull/5243) CrateHeader: Fix narrow screen layout ([@Turbo87])
+- [rust-lang/crates.io] [#5238](https://github.com/rust-lang/crates.io/pull/5238) ember-get-config: Use override to update to v2.1.1 ([@Turbo87])
+- [rust-lang/crates.io] [#5233](https://github.com/rust-lang/crates.io/pull/5233) ember-data: Enable `crypto.randomUUID()` polyfill ([@Turbo87])
+- [rust-lang/crates.io] [#5180](https://github.com/rust-lang/crates.io/pull/5180) services/session: Clear in-memory data when logging out ([@Turbo87])
 
 ## Octoherd
 
-- [octoherd/.github] [#7](https://github.com/octoherd/.github/pull/7)
-  feat(renovate): extend octokit/.github preset ([@oscard0m])
-- [octoherd/create-octoherd-script]
-  [#72](https://github.com/octoherd/create-octoherd-script/pull/72)
-  ci(release.yml): revert delition v3 to actions/setup-node by octoherd script
-  ([@oscard0m])
-- [octoherd/create-octoherd-script]
-  [#68](https://github.com/octoherd/create-octoherd-script/pull/68) build(deps):
-  remove semantic-release dependencies ([@oscard0m])
-- [octoherd/create-octoherd-script]
-  [#66](https://github.com/octoherd/create-octoherd-script/pull/66)
-  feat(script): scaffold renovate config for octoherd repos ([@oscard0m])
-- [octoherd/create-octoherd-script]
-  [#65](https://github.com/octoherd/create-octoherd-script/pull/65)
-  style(renovate): apply Prettier indentation ([@oscard0m])
-- [octoherd/script-setup-renovate]
-  [#35](https://github.com/octoherd/script-setup-renovate/pull/35) feat(script):
-  skip repositories named '.github' ([@oscard0m])
+- [octoherd/.github] [#7](https://github.com/octoherd/.github/pull/7) feat(renovate): extend octokit/.github preset ([@oscard0m])
+- [octoherd/create-octoherd-script] [#72](https://github.com/octoherd/create-octoherd-script/pull/72) ci(release.yml): revert delition v3 to actions/setup-node by octoherd script ([@oscard0m])
+- [octoherd/create-octoherd-script] [#68](https://github.com/octoherd/create-octoherd-script/pull/68) build(deps): remove semantic-release dependencies ([@oscard0m])
+- [octoherd/create-octoherd-script] [#66](https://github.com/octoherd/create-octoherd-script/pull/66) feat(script): scaffold renovate config for octoherd repos ([@oscard0m])
+- [octoherd/create-octoherd-script] [#65](https://github.com/octoherd/create-octoherd-script/pull/65) style(renovate): apply Prettier indentation ([@oscard0m])
+- [octoherd/script-setup-renovate] [#35](https://github.com/octoherd/script-setup-renovate/pull/35) feat(script): skip repositories named '.github' ([@oscard0m])
 
 ## Ember.js
 
-- [ember-cli/ember-cli-htmlbars]
-  [#755](https://github.com/ember-cli/ember-cli-htmlbars/pull/755) Add a test
-  that covers addon templates and fix ember-try to include correct ember-cli
-  versions ([@mansona])
-- [ember-learn/ember-release-bot]
-  [#25](https://github.com/ember-learn/ember-release-bot/pull/25) Update
-  postgres keyv dependencies ([@mansona])
-- [ember-learn/guides-source]
-  [#1846](https://github.com/ember-learn/guides-source/pull/1846) v4.7.0
-  ([@locks])
-- [emberjs/rfcs-tooling] [#12](https://github.com/emberjs/rfcs-tooling/pull/12)
-  lint releaseDate properly ([@mansona])
-- [mainmatter/ember-workshop]
-  [#646](https://github.com/mainmatter/ember-workshop/pull/646) Ignore all
-  node_modules, not just direct child ([@locks])
+- [ember-cli/ember-cli-htmlbars] [#755](https://github.com/ember-cli/ember-cli-htmlbars/pull/755) Add a test that covers addon templates and fix ember-try to include correct ember-cli versions ([@mansona])
+- [ember-learn/ember-release-bot] [#25](https://github.com/ember-learn/ember-release-bot/pull/25) Update postgres keyv dependencies ([@mansona])
+- [ember-learn/guides-source] [#1846](https://github.com/ember-learn/guides-source/pull/1846) v4.7.0 ([@locks])
+- [emberjs/rfcs-tooling] [#12](https://github.com/emberjs/rfcs-tooling/pull/12) lint releaseDate properly ([@mansona])
+- [mainmatter/ember-workshop] [#646](https://github.com/mainmatter/ember-workshop/pull/646) Ignore all node_modules, not just direct child ([@locks])
+- [mainmatter/ember2-x-codemods] [#5](https://github.com/mainmatter/ember2-x-codemods/pull/5) update ci workflow to publish on tag creation ([@Mikek2252])
+- [mainmatter/ember2-x-codemods] [#4](https://github.com/mainmatter/ember2-x-codemods/pull/4) add lerna-changelog and release it ([@Mikek2252])
+- [mainmatter/ember2-x-codemods] [#3](https://github.com/mainmatter/ember2-x-codemods/pull/3) add remove-binding codemod with tests and documentation ([@Mikek2252])
+- [mainmatter/ember2-x-codemods] [#2](https://github.com/mainmatter/ember2-x-codemods/pull/2) Add the codemod contains to includes. ([@Mikek2252])
 - [mainmatter/ember2-x-codemods]
-  [#5](https://github.com/mainmatter/ember2-x-codemods/pull/5) update ci
-  workflow to publish on tag creation ([@Mikek2252])
-- [mainmatter/ember2-x-codemods]
-  [#4](https://github.com/mainmatter/ember2-x-codemods/pull/4) add
-  lerna-changelog and release it ([@Mikek2252])
-- [mainmatter/ember2-x-codemods]
-  [#3](https://github.com/mainmatter/ember2-x-codemods/pull/3) add
-  remove-binding codemod with tests and documentation ([@Mikek2252])
-- [mainmatter/ember2-x-codemods]
-  [#2](https://github.com/mainmatter/ember2-x-codemods/pull/2) Add the codemod
-  contains to includes. ([@Mikek2252])
-- [mainmatter/ember2-x-codemods]
-- [mainmatter/qunit-dom]
-  [#1696](https://github.com/mainmatter/qunit-dom/pull/1696) chore: downgrade
-  documentation@13.2.5 to 13.2.4 ([@BobrImperator])
+- [mainmatter/qunit-dom] [#1696](https://github.com/mainmatter/qunit-dom/pull/1696) chore: downgrade documentation@13.2.5 to 13.2.4 ([@BobrImperator])
 - [mainmatter/qunit-dom]
-- [nickschot/ember-gesture-modifiers]
-  [#325](https://github.com/nickschot/ember-gesture-modifiers/pull/325) Require
-  ember-modifier v3.2.0+ to make sure the new modifier syntax is available
-  ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#323](https://github.com/nickschot/ember-gesture-modifiers/pull/323) Upgrade
-  to new ember-modifiers syntax ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#322](https://github.com/nickschot/ember-gesture-modifiers/pull/322) Update
-  to ember-cli 4.7.0 blueprint ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#321](https://github.com/nickschot/ember-gesture-modifiers/pull/321) Pin yarn
-  version with Volta ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#320](https://github.com/nickschot/ember-gesture-modifiers/pull/320) Drop
-  node v12 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#429](https://github.com/nickschot/ember-mobile-menu/pull/429) Fix fastboot
-  compatibility and add smoke test ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#325](https://github.com/nickschot/ember-gesture-modifiers/pull/325) Require ember-modifier v3.2.0+ to make sure the new modifier syntax is available ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#323](https://github.com/nickschot/ember-gesture-modifiers/pull/323) Upgrade to new ember-modifiers syntax ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#322](https://github.com/nickschot/ember-gesture-modifiers/pull/322) Update to ember-cli 4.7.0 blueprint ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#321](https://github.com/nickschot/ember-gesture-modifiers/pull/321) Pin yarn version with Volta ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#320](https://github.com/nickschot/ember-gesture-modifiers/pull/320) Drop node v12 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#429](https://github.com/nickschot/ember-mobile-menu/pull/429) Fix fastboot compatibility and add smoke test ([@nickschot])
 
 ## Empress
 
-- [empress/bottled-ember] [#3](https://github.com/empress/bottled-ember/pull/3)
-  add a way to override ember-cli-build config ([@mansona])
-- [empress/bottled-ember] [#2](https://github.com/empress/bottled-ember/pull/2)
-  pass --environment on to ember exec ([@mansona])
-- [empress/bottled-ember] [#1](https://github.com/empress/bottled-ember/pull/1)
-  Implement basic cach-folder version of bottled ember ([@mansona])
+- [empress/bottled-ember] [#3](https://github.com/empress/bottled-ember/pull/3) add a way to override ember-cli-build config ([@mansona])
+- [empress/bottled-ember] [#2](https://github.com/empress/bottled-ember/pull/2) pass --environment on to ember exec ([@mansona])
+- [empress/bottled-ember] [#1](https://github.com/empress/bottled-ember/pull/1) Implement basic cach-folder version of bottled ember ([@mansona])
 
 ## Lint to the future
 
-- [mansona/lint-to-the-future-eslint]
-  [#11](https://github.com/mansona/lint-to-the-future-eslint/pull/11) stop
-  ignoring eslint warnings ([@mansona])
-- [mansona/lint-to-the-future-eslint]
-  [#10](https://github.com/mansona/lint-to-the-future-eslint/pull/10) Add eslint
-  versions to a test matrix ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#11](https://github.com/mansona/lint-to-the-future-eslint/pull/11) stop ignoring eslint warnings ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#10](https://github.com/mansona/lint-to-the-future-eslint/pull/10) Add eslint versions to a test matrix ([@mansona])
 
 ## Octokit
 
-- [octoherd/cli] [#83](https://github.com/octoherd/cli/pull/83) ci(release): fix
-  dependency name ([@oscard0m])
-- [octoherd/cli] [#82](https://github.com/octoherd/cli/pull/82) build(deps):
-  remove semantic-release dependencies ([@oscard0m])
-- [octoherd/octokit] [#25](https://github.com/octoherd/octokit/pull/25)
-  ci(release.yml): fix dependency name ([@oscard0m])
-- [octoherd/octokit] [#24](https://github.com/octoherd/octokit/pull/24)
-  build(deps): remove semantic-release dependencies ([@oscard0m])
-- [octokit/auth-oauth-user.js]
-  [#90](https://github.com/octokit/auth-oauth-user.js/pull/90) WIP feat(auth):
-  add onTokenCreated option ([@oscard0m])
-- [octokit/create-octokit-project.js]
-  [#193](https://github.com/octokit/create-octokit-project.js/pull/193)
-  feat(renovate): add Renovate configuration if owner is 'octokit' ([@oscard0m])
-- [oscard0m/octoherd-script-remove-renovate-package.json]
-  [#4](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/4)
-  fix(deps): move @octokit/plugin-create-or-update-text-file as production
-  'dependency' ([@oscard0m])
-- [oscard0m/octoherd-script-update-action-version-in-workflows]
-  [#4](https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows/pull/4)
-  feat(script): use RegEx instead of js-yaml ([@oscard0m])
-- [oscard0m/octoherd-script-update-action-version-in-workflows]
-  [#1](https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows/pull/1)
-  feat: Initial version ([@oscard0m])
+- [octoherd/cli] [#83](https://github.com/octoherd/cli/pull/83) ci(release): fix dependency name ([@oscard0m])
+- [octoherd/cli] [#82](https://github.com/octoherd/cli/pull/82) build(deps): remove semantic-release dependencies ([@oscard0m])
+- [octoherd/octokit] [#25](https://github.com/octoherd/octokit/pull/25) ci(release.yml): fix dependency name ([@oscard0m])
+- [octoherd/octokit] [#24](https://github.com/octoherd/octokit/pull/24) build(deps): remove semantic-release dependencies ([@oscard0m])
+- [octokit/auth-oauth-user.js] [#90](https://github.com/octokit/auth-oauth-user.js/pull/90) WIP feat(auth): add onTokenCreated option ([@oscard0m])
+- [octokit/create-octokit-project.js] [#193](https://github.com/octokit/create-octokit-project.js/pull/193) feat(renovate): add Renovate configuration if owner is 'octokit' ([@oscard0m])
+- [oscard0m/octoherd-script-remove-renovate-package.json] [#4](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/4) fix(deps): move @octokit/plugin-create-or-update-text-file as production 'dependency' ([@oscard0m])
+- [oscard0m/octoherd-script-update-action-version-in-workflows] [#4](https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows/pull/4) feat(script): use RegEx instead of js-yaml ([@oscard0m])
+- [oscard0m/octoherd-script-update-action-version-in-workflows] [#1](https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows/pull/1) feat: Initial version ([@oscard0m])
 
 ## Rollup
 
-- [ezolenko/rollup-plugin-typescript2]
-  [#420](https://github.com/ezolenko/rollup-plugin-typescript2/pull/420)
-  fix(cache): default `clean: true` when necessary, add `extraCacheKeys` option
-  ([@oscard0m])
+- [ezolenko/rollup-plugin-typescript2] [#420](https://github.com/ezolenko/rollup-plugin-typescript2/pull/420) fix(cache): default `clean: true` when necessary, add `extraCacheKeys` option ([@oscard0m])
 
 ## Elixir
 
-- [rrrene/credo] [#996](https://github.com/rrrene/credo/pull/996) feat: Add
-  Ignore option for Credo.Check.Readability.ModuleNames ([@BobrImperator])
+- [rrrene/credo] [#996](https://github.com/rrrene/credo/pull/996) feat: Add Ignore option for Credo.Check.Readability.ModuleNames ([@BobrImperator])
 
 ## Clojure
 
-- [mtgred/netrunner] [#6605](https://github.com/mtgred/netrunner/pull/6605)
-  Implement default game format account setting ([@locks])
-- [mtgred/netrunner] [#6592](https://github.com/mtgred/netrunner/pull/6592)
-  Rename brain damage to core damage, Part I ([@locks])
+- [mtgred/netrunner] [#6605](https://github.com/mtgred/netrunner/pull/6605) Implement default game format account setting ([@locks])
+- [mtgred/netrunner] [#6592](https://github.com/mtgred/netrunner/pull/6592) Rename brain damage to core damage, Part I ([@locks])
 
 ## Probot
 
-- [probot/.github] [#4](https://github.com/probot/.github/pull/4)
-  chore(renovate): remove .github/renovate.json ([@oscard0m])
-- [probot/talks] [#2](https://github.com/probot/talks/pull/2) chore(.github):
-  remove unused Renovate configuration ([@oscard0m])
-- [probot/twitter] [#27](https://github.com/probot/twitter/pull/27)
-  chore(.github): remove unused Renovate configuration ([@oscard0m])
+- [probot/.github] [#4](https://github.com/probot/.github/pull/4) chore(renovate): remove .github/renovate.json ([@oscard0m])
+- [probot/talks] [#2](https://github.com/probot/talks/pull/2) chore(.github): remove unused Renovate configuration ([@oscard0m])
+- [probot/twitter] [#27](https://github.com/probot/twitter/pull/27) chore(.github): remove unused Renovate configuration ([@oscard0m])
 
 ## Mainmatter's playbook
 
-- [mainmatter/playbook] [#180](https://github.com/mainmatter/playbook/pull/180)
-  Mainmatter ([@marcoow])
+- [mainmatter/playbook] [#180](https://github.com/mainmatter/playbook/pull/180) Mainmatter ([@marcoow])
 
 ## Gliding
 
-- [weglide/GliderList] [#42](https://github.com/weglide/GliderList/pull/42) Add
-  2023 handicaps ([@Turbo87])
+- [weglide/GliderList] [#42](https://github.com/weglide/GliderList/pull/42) Add 2023 handicaps ([@Turbo87])
 
 [@bobrimperator]: https://github.com/BobrImperator
 [@mikek2252]: https://github.com/Mikek2252
@@ -201,63 +104,47 @@
 [@pichfl]: https://github.com/pichfl
 [turbo87/united-flarmnet]: https://github.com/Turbo87/united-flarmnet
 [ember-cli/ember-cli-htmlbars]: https://github.com/ember-cli/ember-cli-htmlbars
-[ember-learn/ember-release-bot]:
-  https://github.com/ember-learn/ember-release-bot
+[ember-learn/ember-release-bot]: https://github.com/ember-learn/ember-release-bot
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [emberjs/rfcs-tooling]: https://github.com/emberjs/rfcs-tooling
 [empress/bottled-ember]: https://github.com/empress/bottled-ember
 [erlef/website]: https://github.com/erlef/website
-[ezolenko/rollup-plugin-typescript2]:
-  https://github.com/ezolenko/rollup-plugin-typescript2
+[ezolenko/rollup-plugin-typescript2]: https://github.com/ezolenko/rollup-plugin-typescript2
 [mainmatter/ast-workshop]: https://github.com/mainmatter/ast-workshop
 [mainmatter/breethe-client]: https://github.com/mainmatter/breethe-client
 [mainmatter/breethe-server]: https://github.com/mainmatter/breethe-server
 [mainmatter/ember-error-route]: https://github.com/mainmatter/ember-error-route
-[mainmatter/ember-hbs-minifier]:
-  https://github.com/mainmatter/ember-hbs-minifier
+[mainmatter/ember-hbs-minifier]: https://github.com/mainmatter/ember-hbs-minifier
 [mainmatter/ember-hotspots]: https://github.com/mainmatter/ember-hotspots
-[mainmatter/ember-intl-analyzer]:
-  https://github.com/mainmatter/ember-intl-analyzer
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-intl-analyzer]: https://github.com/mainmatter/ember-intl-analyzer
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
-[mainmatter/ember-test-selectors]:
-  https://github.com/mainmatter/ember-test-selectors
+[mainmatter/ember-test-selectors]: https://github.com/mainmatter/ember-test-selectors
 [mainmatter/ember-workshop]: https://github.com/mainmatter/ember-workshop
 [mainmatter/ember2-x-codemods]: https://github.com/mainmatter/ember2-x-codemods
-[mainmatter/eslint-plugin-ember-concurrency]:
-  https://github.com/mainmatter/eslint-plugin-ember-concurrency
-[mainmatter/eslint-plugin-qunit-dom]:
-  https://github.com/mainmatter/eslint-plugin-qunit-dom
+[mainmatter/eslint-plugin-ember-concurrency]: https://github.com/mainmatter/eslint-plugin-ember-concurrency
+[mainmatter/eslint-plugin-qunit-dom]: https://github.com/mainmatter/eslint-plugin-qunit-dom
 [mainmatter/playbook]: https://github.com/mainmatter/playbook
 [mainmatter/qunit-dom-codemod]: https://github.com/mainmatter/qunit-dom-codemod
 [mainmatter/qunit-dom]: https://github.com/mainmatter/qunit-dom
 [mainmatter/renovate-config]: https://github.com/mainmatter/renovate-config
-[mainmatter/testem-gitlab-reporter]:
-  https://github.com/mainmatter/testem-gitlab-reporter
+[mainmatter/testem-gitlab-reporter]: https://github.com/mainmatter/testem-gitlab-reporter
 [mainmatter/who-ran-me]: https://github.com/mainmatter/who-ran-me
 [mansona/chris.manson.ie]: https://github.com/mansona/chris.manson.ie
-[mansona/lint-to-the-future-eslint]:
-  https://github.com/mansona/lint-to-the-future-eslint
+[mansona/lint-to-the-future-eslint]: https://github.com/mansona/lint-to-the-future-eslint
 [mtgred/netrunner]: https://github.com/mtgred/netrunner
-[nickschot/ember-gesture-modifiers]:
-  https://github.com/nickschot/ember-gesture-modifiers
+[nickschot/ember-gesture-modifiers]: https://github.com/nickschot/ember-gesture-modifiers
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
 [octoherd/.github]: https://github.com/octoherd/.github
 [octoherd/cli]: https://github.com/octoherd/cli
-[octoherd/create-octoherd-script]:
-  https://github.com/octoherd/create-octoherd-script
+[octoherd/create-octoherd-script]: https://github.com/octoherd/create-octoherd-script
 [octoherd/octokit]: https://github.com/octoherd/octokit
-[octoherd/script-setup-renovate]:
-  https://github.com/octoherd/script-setup-renovate
+[octoherd/script-setup-renovate]: https://github.com/octoherd/script-setup-renovate
 [octokit/auth-oauth-user.js]: https://github.com/octokit/auth-oauth-user.js
-[octokit/create-octokit-project.js]:
-  https://github.com/octokit/create-octokit-project.js
-[oscard0m/octoherd-script-remove-renovate-package.json]:
-  https://github.com/oscard0m/octoherd-script-remove-renovate-package.json
-[oscard0m/octoherd-script-update-action-version-in-workflows]:
-  https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows
+[octokit/create-octokit-project.js]: https://github.com/octokit/create-octokit-project.js
+[oscard0m/octoherd-script-remove-renovate-package.json]: https://github.com/oscard0m/octoherd-script-remove-renovate-package.json
+[oscard0m/octoherd-script-update-action-version-in-workflows]: https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows
 [probot/.github]: https://github.com/probot/.github
 [probot/talks]: https://github.com/probot/talks
 [probot/twitter]: https://github.com/probot/twitter
diff --git a/src/twios/2022-10-19.md b/src/twios/2022-10-19.md
index 8fca5081fd..a34c6ec060 100644
--- a/src/twios/2022-10-19.md
+++ b/src/twios/2022-10-19.md
@@ -1,59 +1,36 @@
 ## Rust
 
-- [AeroRust/nmea] [#59](https://github.com/AeroRust/nmea/pull/59) Implement
-  `PGRMZ` support ([@Turbo87])
-- [AeroRust/nmea] [#57](https://github.com/AeroRust/nmea/pull/57) Update/Fix
-  `RMC` docs ([@Turbo87])
-- [Swatinem/rust-cache] [#83](https://github.com/Swatinem/rust-cache/pull/83)
-  Update `@actions/cors` to v1.10.0 ([@Turbo87])
+- [AeroRust/nmea] [#59](https://github.com/AeroRust/nmea/pull/59) Implement `PGRMZ` support ([@Turbo87])
+- [AeroRust/nmea] [#57](https://github.com/AeroRust/nmea/pull/57) Update/Fix `RMC` docs ([@Turbo87])
+- [Swatinem/rust-cache] [#83](https://github.com/Swatinem/rust-cache/pull/83) Update `@actions/cors` to v1.10.0 ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#5325](https://github.com/rust-lang/crates.io/pull/5325) CI: Remove obsolete
-  `bors` CI jobs ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5324](https://github.com/rust-lang/crates.io/pull/5324) Remove outdated
-  "Deploying & using a mirror" instructions ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5298](https://github.com/rust-lang/crates.io/pull/5298) clap: Resolve
-  deprecation warnings ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5297](https://github.com/rust-lang/crates.io/pull/5297) clap: Add new
-  `wrap_help` feature flag ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5295](https://github.com/rust-lang/crates.io/pull/5295) clap: Derive
-  possible values for `EventType` argument ([@Turbo87])
+- [rust-lang/crates.io] [#5325](https://github.com/rust-lang/crates.io/pull/5325) CI: Remove obsolete `bors` CI jobs ([@Turbo87])
+- [rust-lang/crates.io] [#5324](https://github.com/rust-lang/crates.io/pull/5324) Remove outdated "Deploying & using a mirror" instructions ([@Turbo87])
+- [rust-lang/crates.io] [#5298](https://github.com/rust-lang/crates.io/pull/5298) clap: Resolve deprecation warnings ([@Turbo87])
+- [rust-lang/crates.io] [#5297](https://github.com/rust-lang/crates.io/pull/5297) clap: Add new `wrap_help` feature flag ([@Turbo87])
+- [rust-lang/crates.io] [#5295](https://github.com/rust-lang/crates.io/pull/5295) clap: Derive possible values for `EventType` argument ([@Turbo87])
 
 ## Astro
 
-- [withastro/docs] [#1662](https://github.com/withastro/docs/pull/1662)
-  i18n(es): Update sharing-state.md translation ([@oscard0m])
+- [withastro/docs] [#1662](https://github.com/withastro/docs/pull/1662) i18n(es): Update sharing-state.md translation ([@oscard0m])
 
 ## Embedded
 
-- [jomjol/AI-on-the-edge-device]
-  [#1158](https://github.com/jomjol/AI-on-the-edge-device/pull/1158)
-  FlowPostProcessing::GetJSON: Add `pre` field to the `/json` response
-  ([@Turbo87])
+- [jomjol/AI-on-the-edge-device] [#1158](https://github.com/jomjol/AI-on-the-edge-device/pull/1158) FlowPostProcessing::GetJSON: Add `pre` field to the `/json` response ([@Turbo87])
 
 ## Ember.js
 
-- [mainmatter/ember2-x-codemods]
-  [#7](https://github.com/mainmatter/ember2-x-codemods/pull/7) computed
-  property - Property to computed syntax transform. ([@Mikek2252])
+- [mainmatter/ember2-x-codemods] [#7](https://github.com/mainmatter/ember2-x-codemods/pull/7) computed property - Property to computed syntax transform. ([@Mikek2252])
 
 ## Empress
 
-- [empress/empress-blog]
-  [#163](https://github.com/empress/empress-blog/pull/163) update ember-scroll
-  to 1.0.3 ([@nickschot])
+- [empress/empress-blog] [#163](https://github.com/empress/empress-blog/pull/163) update ember-scroll to 1.0.3 ([@nickschot])
 
 ## Lint to the future
 
-- [mansona/lint-to-the-future]
-  [#28](https://github.com/mansona/lint-to-the-future/pull/28) Move from
-  minimist to commander ([@Mikek2252])
+- [mansona/lint-to-the-future] [#28](https://github.com/mansona/lint-to-the-future/pull/28) Move from minimist to commander ([@Mikek2252])
 
 [@mikek2252]: https://github.com/Mikek2252
 [@turbo87]: https://github.com/Turbo87
diff --git a/src/twios/2022-11-03.md b/src/twios/2022-11-03.md
index 8f0e72596b..76ff628661 100644
--- a/src/twios/2022-11-03.md
+++ b/src/twios/2022-11-03.md
@@ -1,108 +1,50 @@
 ## Rust
 
-- [Turbo87/segelflug-classifieds]
-  [#401](https://github.com/Turbo87/segelflug-classifieds/pull/401) CI: Add
-  "Build and Deploy" workflow ([@Turbo87])
-- [pietroalbini/rfcs] [#2](https://github.com/pietroalbini/rfcs/pull/2) Improve
-  token scopes proposal ([@Turbo87])
+- [Turbo87/segelflug-classifieds] [#401](https://github.com/Turbo87/segelflug-classifieds/pull/401) CI: Add "Build and Deploy" workflow ([@Turbo87])
+- [pietroalbini/rfcs] [#2](https://github.com/pietroalbini/rfcs/pull/2) Improve token scopes proposal ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#5375](https://github.com/rust-lang/crates.io/pull/5375) Remove unused CSS
-  classes ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5370](https://github.com/rust-lang/crates.io/pull/5370) Use a fluid space
-  scale ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5369](https://github.com/rust-lang/crates.io/pull/5369) Remove unused CSS
-  classes ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5366](https://github.com/rust-lang/crates.io/pull/5366) styles: Extract
-  `font-body/heading` font family design tokens ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5355](https://github.com/rust-lang/crates.io/pull/5355) Revert "Netlify: Add
-  `_redirects` file" ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5354](https://github.com/rust-lang/crates.io/pull/5354) footer: Add Zulip
-  channel to "Social" link list ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5353](https://github.com/rust-lang/crates.io/pull/5353) styles: Extract
-  `transition` design tokens ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5333](https://github.com/rust-lang/crates.io/pull/5333) Heroku: Remove
-  unused `app.json` file ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5330](https://github.com/rust-lang/crates.io/pull/5330) docs: Reintroduce
-  `MIRROR.md` to keep third party links to the document working ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5329](https://github.com/rust-lang/crates.io/pull/5329) Remove deprecated
-  `MIRROR` mode ([@Turbo87])
+- [rust-lang/crates.io] [#5375](https://github.com/rust-lang/crates.io/pull/5375) Remove unused CSS classes ([@Turbo87])
+- [rust-lang/crates.io] [#5370](https://github.com/rust-lang/crates.io/pull/5370) Use a fluid space scale ([@Turbo87])
+- [rust-lang/crates.io] [#5369](https://github.com/rust-lang/crates.io/pull/5369) Remove unused CSS classes ([@Turbo87])
+- [rust-lang/crates.io] [#5366](https://github.com/rust-lang/crates.io/pull/5366) styles: Extract `font-body/heading` font family design tokens ([@Turbo87])
+- [rust-lang/crates.io] [#5355](https://github.com/rust-lang/crates.io/pull/5355) Revert "Netlify: Add `_redirects` file" ([@Turbo87])
+- [rust-lang/crates.io] [#5354](https://github.com/rust-lang/crates.io/pull/5354) footer: Add Zulip channel to "Social" link list ([@Turbo87])
+- [rust-lang/crates.io] [#5353](https://github.com/rust-lang/crates.io/pull/5353) styles: Extract `transition` design tokens ([@Turbo87])
+- [rust-lang/crates.io] [#5333](https://github.com/rust-lang/crates.io/pull/5333) Heroku: Remove unused `app.json` file ([@Turbo87])
+- [rust-lang/crates.io] [#5330](https://github.com/rust-lang/crates.io/pull/5330) docs: Reintroduce `MIRROR.md` to keep third party links to the document working ([@Turbo87])
+- [rust-lang/crates.io] [#5329](https://github.com/rust-lang/crates.io/pull/5329) Remove deprecated `MIRROR` mode ([@Turbo87])
 
 ## Ember.js
 
-- [ember-learn/ember-website]
-  [#969](https://github.com/ember-learn/ember-website/pull/969) Release Pages
-  v4.8.0 ([@locks])
-- [mainmatter/ember-promise-modals]
-  [#775](https://github.com/mainmatter/ember-promise-modals/pull/775) Deprecate
-  opening modals from paths ([@pichfl])
-- [qonto/ember-cp-validations]
-  [#22](https://github.com/qonto/ember-cp-validations/pull/22) Bump Node version
-  to 16 ([@zeppelin])
-- [qonto/ember-cp-validations]
-  [#20](https://github.com/qonto/ember-cp-validations/pull/20) Use `require`
-  instead of `import` to make Embroider happy ([@zeppelin])
+- [ember-learn/ember-website] [#969](https://github.com/ember-learn/ember-website/pull/969) Release Pages v4.8.0 ([@locks])
+- [mainmatter/ember-promise-modals] [#775](https://github.com/mainmatter/ember-promise-modals/pull/775) Deprecate opening modals from paths ([@pichfl])
+- [qonto/ember-cp-validations] [#22](https://github.com/qonto/ember-cp-validations/pull/22) Bump Node version to 16 ([@zeppelin])
+- [qonto/ember-cp-validations] [#20](https://github.com/qonto/ember-cp-validations/pull/20) Use `require` instead of `import` to make Embroider happy ([@zeppelin])
 
 ## Lint to the future
 
-- [mansona/lint-to-the-future]
-  [#30](https://github.com/mansona/lint-to-the-future/pull/30) add a basic tests
-  for rootUrl on output command ([@mansona])
+- [mansona/lint-to-the-future] [#30](https://github.com/mansona/lint-to-the-future/pull/30) add a basic tests for rootUrl on output command ([@mansona])
 
 ## JavaScript
 
-- [Turbo87/auto-dist-tag]
-  [#298](https://github.com/Turbo87/auto-dist-tag/pull/298) CI: Extract
-  `PNPM_VERSION` variable ([@Turbo87])
-- [Turbo87/auto-dist-tag]
-  [#296](https://github.com/Turbo87/auto-dist-tag/pull/296) fetch-dist-tags:
-  Convert to async function ([@Turbo87])
-- [Turbo87/auto-dist-tag]
-  [#295](https://github.com/Turbo87/auto-dist-tag/pull/295) Drop support for
-  Node.js 10 and 12 ([@Turbo87])
-- [Turbo87/auto-dist-tag]
-  [#294](https://github.com/Turbo87/auto-dist-tag/pull/294) renovate: Keep pnpm
-  up-to-date ([@Turbo87])
-- [Turbo87/auto-dist-tag]
-  [#293](https://github.com/Turbo87/auto-dist-tag/pull/293) CI: Pin action
-  versions ([@Turbo87])
-- [Turbo87/auto-dist-tag]
-  [#292](https://github.com/Turbo87/auto-dist-tag/pull/292) renovate: Simplify
-  config by using shared config repo ([@Turbo87])
-- [miragejs/miragejs] [#1064](https://github.com/miragejs/miragejs/pull/1064)
-  Fix includes query params ([@mansona])
-- [hakimel/reveal.js] [#3305](https://github.com/hakimel/reveal.js/pull/3305)
-  Gulp livereload: include subfolders to watch for changes in html and md
-  ([@lolmaus])
+- [Turbo87/auto-dist-tag] [#298](https://github.com/Turbo87/auto-dist-tag/pull/298) CI: Extract `PNPM_VERSION` variable ([@Turbo87])
+- [Turbo87/auto-dist-tag] [#296](https://github.com/Turbo87/auto-dist-tag/pull/296) fetch-dist-tags: Convert to async function ([@Turbo87])
+- [Turbo87/auto-dist-tag] [#295](https://github.com/Turbo87/auto-dist-tag/pull/295) Drop support for Node.js 10 and 12 ([@Turbo87])
+- [Turbo87/auto-dist-tag] [#294](https://github.com/Turbo87/auto-dist-tag/pull/294) renovate: Keep pnpm up-to-date ([@Turbo87])
+- [Turbo87/auto-dist-tag] [#293](https://github.com/Turbo87/auto-dist-tag/pull/293) CI: Pin action versions ([@Turbo87])
+- [Turbo87/auto-dist-tag] [#292](https://github.com/Turbo87/auto-dist-tag/pull/292) renovate: Simplify config by using shared config repo ([@Turbo87])
+- [miragejs/miragejs] [#1064](https://github.com/miragejs/miragejs/pull/1064) Fix includes query params ([@mansona])
+- [hakimel/reveal.js] [#3305](https://github.com/hakimel/reveal.js/pull/3305) Gulp livereload: include subfolders to watch for changes in html and md ([@lolmaus])
 
 ## Internal
 
-- [mainmatter/mainmatter-website-mailer]
-  [#5](https://github.com/mainmatter/mainmatter-website-mailer/pull/5) User
-  better subject, sender and recipient name ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#4](https://github.com/mainmatter/mainmatter-website-mailer/pull/4) use
-  default message in case it's empty ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#3](https://github.com/mainmatter/mainmatter-website-mailer/pull/3) add CORS
-  headers ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#2](https://github.com/mainmatter/mainmatter-website-mailer/pull/2)
-  Auto-release from Actions ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#1](https://github.com/mainmatter/mainmatter-website-mailer/pull/1) Add CI
-  setup ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#5](https://github.com/mainmatter/mainmatter-website-mailer/pull/5) User better subject, sender and recipient name ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#4](https://github.com/mainmatter/mainmatter-website-mailer/pull/4) use default message in case it's empty ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#3](https://github.com/mainmatter/mainmatter-website-mailer/pull/3) add CORS headers ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#2](https://github.com/mainmatter/mainmatter-website-mailer/pull/2) Auto-release from Actions ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#1](https://github.com/mainmatter/mainmatter-website-mailer/pull/1) Add CI setup ([@marcoow])
 
 [@turbo87]: https://github.com/Turbo87
 [@locks]: https://github.com/locks
@@ -112,14 +54,11 @@
 [@pichfl]: https://github.com/pichfl
 [@zeppelin]: https://github.com/zeppelin
 [turbo87/auto-dist-tag]: https://github.com/Turbo87/auto-dist-tag
-[turbo87/segelflug-classifieds]:
-  https://github.com/Turbo87/segelflug-classifieds
+[turbo87/segelflug-classifieds]: https://github.com/Turbo87/segelflug-classifieds
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [hakimel/reveal.js]: https://github.com/hakimel/reveal.js
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
-[mainmatter/mainmatter-website-mailer]:
-  https://github.com/mainmatter/mainmatter-website-mailer
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
+[mainmatter/mainmatter-website-mailer]: https://github.com/mainmatter/mainmatter-website-mailer
 [mansona/lint-to-the-future]: https://github.com/mansona/lint-to-the-future
 [mansona/test-allow-failure]: https://github.com/mansona/test-allow-failure
 [miragejs/miragejs]: https://github.com/miragejs/miragejs
diff --git a/src/twios/2022-11-24.md b/src/twios/2022-11-24.md
index b47530acbd..66f4da100f 100644
--- a/src/twios/2022-11-24.md
+++ b/src/twios/2022-11-24.md
@@ -1,186 +1,74 @@
 ## Rust
 
-- [Turbo87/segelflug-classifieds]
-  [#402](https://github.com/Turbo87/segelflug-classifieds/pull/402) tracing: Add
-  timestamps to log output ([@Turbo87])
-- [Turbo87/sentry-conduit]
-  [#101](https://github.com/Turbo87/sentry-conduit/pull/101) Bump "Minimum
-  Supported Rust Version" to v1.60.0 ([@Turbo87])
-- [rust-lang/hashbrown] [#373](https://github.com/rust-lang/hashbrown/pull/373)
-  changelog: Fix heading levels ([@Turbo87])
+- [Turbo87/segelflug-classifieds] [#402](https://github.com/Turbo87/segelflug-classifieds/pull/402) tracing: Add timestamps to log output ([@Turbo87])
+- [Turbo87/sentry-conduit] [#101](https://github.com/Turbo87/sentry-conduit/pull/101) Bump "Minimum Supported Rust Version" to v1.60.0 ([@Turbo87])
+- [rust-lang/hashbrown] [#373](https://github.com/rust-lang/hashbrown/pull/373) changelog: Fix heading levels ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#5479](https://github.com/rust-lang/crates.io/pull/5479) cloudfront: Retry
-  requests on server or network error ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5467](https://github.com/rust-lang/crates.io/pull/5467) CI: Remove `beta`
-  backend scenario ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5459](https://github.com/rust-lang/crates.io/pull/5459) downloads_counter:
-  Remove `hashbrown` reference ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5456](https://github.com/rust-lang/crates.io/pull/5456) Partially revert
-  "Lock file maintenance (Rust) (#5436)" ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5432](https://github.com/rust-lang/crates.io/pull/5432) views: Move `mod`
-  and `use` lines to the top of the file ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5431](https://github.com/rust-lang/crates.io/pull/5431)
-  EncodableCrateUpload: Remove obsolete `badges` field ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5430](https://github.com/rust-lang/crates.io/pull/5430) mirage: Remove
-  `badges` from fixtures ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5429](https://github.com/rust-lang/crates.io/pull/5429) badges: Remove
-  obsolete data structures ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5428](https://github.com/rust-lang/crates.io/pull/5428) badges: Remove
-  obsolete database calls ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5427](https://github.com/rust-lang/crates.io/pull/5427) models::Crate:
-  Remove unused `badges()` function ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5426](https://github.com/rust-lang/crates.io/pull/5426) downloads: Use
-  `recent_downloads` as `downloads` if it is higher ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5423](https://github.com/rust-lang/crates.io/pull/5423) sentry: Reduce trace
-  sample rate for download endpoint ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5413](https://github.com/rust-lang/crates.io/pull/5413) Remove unnecessary
-  borrows ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5411](https://github.com/rust-lang/crates.io/pull/5411) s3: Fix
-  `base64::encode()` call ([@Turbo87])
-- [rust-lang/crates.io]
-  [#5391](https://github.com/rust-lang/crates.io/pull/5391) Use
-  `@mainmatter/ember-api-actions` instead of custom implementation ([@Turbo87])
+- [rust-lang/crates.io] [#5479](https://github.com/rust-lang/crates.io/pull/5479) cloudfront: Retry requests on server or network error ([@Turbo87])
+- [rust-lang/crates.io] [#5467](https://github.com/rust-lang/crates.io/pull/5467) CI: Remove `beta` backend scenario ([@Turbo87])
+- [rust-lang/crates.io] [#5459](https://github.com/rust-lang/crates.io/pull/5459) downloads_counter: Remove `hashbrown` reference ([@Turbo87])
+- [rust-lang/crates.io] [#5456](https://github.com/rust-lang/crates.io/pull/5456) Partially revert "Lock file maintenance (Rust) (#5436)" ([@Turbo87])
+- [rust-lang/crates.io] [#5432](https://github.com/rust-lang/crates.io/pull/5432) views: Move `mod` and `use` lines to the top of the file ([@Turbo87])
+- [rust-lang/crates.io] [#5431](https://github.com/rust-lang/crates.io/pull/5431) EncodableCrateUpload: Remove obsolete `badges` field ([@Turbo87])
+- [rust-lang/crates.io] [#5430](https://github.com/rust-lang/crates.io/pull/5430) mirage: Remove `badges` from fixtures ([@Turbo87])
+- [rust-lang/crates.io] [#5429](https://github.com/rust-lang/crates.io/pull/5429) badges: Remove obsolete data structures ([@Turbo87])
+- [rust-lang/crates.io] [#5428](https://github.com/rust-lang/crates.io/pull/5428) badges: Remove obsolete database calls ([@Turbo87])
+- [rust-lang/crates.io] [#5427](https://github.com/rust-lang/crates.io/pull/5427) models::Crate: Remove unused `badges()` function ([@Turbo87])
+- [rust-lang/crates.io] [#5426](https://github.com/rust-lang/crates.io/pull/5426) downloads: Use `recent_downloads` as `downloads` if it is higher ([@Turbo87])
+- [rust-lang/crates.io] [#5423](https://github.com/rust-lang/crates.io/pull/5423) sentry: Reduce trace sample rate for download endpoint ([@Turbo87])
+- [rust-lang/crates.io] [#5413](https://github.com/rust-lang/crates.io/pull/5413) Remove unnecessary borrows ([@Turbo87])
+- [rust-lang/crates.io] [#5411](https://github.com/rust-lang/crates.io/pull/5411) s3: Fix `base64::encode()` call ([@Turbo87])
+- [rust-lang/crates.io] [#5391](https://github.com/rust-lang/crates.io/pull/5391) Use `@mainmatter/ember-api-actions` instead of custom implementation ([@Turbo87])
 
 ## Ember.js
 
-- [ember-cli/ember-try] [#893](https://github.com/ember-cli/ember-try/pull/893)
-  breaking: drop EOL node versions < v14 and update smoke-test-app to fix CI
-  ([@mansona])
-- [ember-cli/ember-try] [#896](https://github.com/ember-cli/ember-try/pull/896)
-  Fixed version of ember-try-test-suite-helper ([@candunaj])
-- [ember-cli/ember-try-config]
-  [#187](https://github.com/ember-cli/ember-try-config/pull/187) Added
-  onlyVersionCompatibility to generateConfig ([@candunaj])
-- [ember-codemods/ember-native-class-codemod]
-  [#491](https://github.com/ember-codemods/ember-native-class-codemod/pull/491)
-  update codemods-telemetry-helpers ([@mansona])
-- [ember-learn/ember-blog]
-  [#1234](https://github.com/ember-learn/ember-blog/pull/1234) always serve the
-  index.html on netlify ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#435](https://github.com/ember-learn/ember-styleguide/pull/435) Breaking:
-  drop support for EOL Node - minimum supported now v14 ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#434](https://github.com/ember-learn/ember-styleguide/pull/434) Update percy
-  ([@mansona])
-- [ember-learn/guides-source]
-  [#1870](https://github.com/ember-learn/guides-source/pull/1870) stop
-  outputting `no issues found` on every file during markdown lint ([@mansona])
-- [mainmatter/ember-simple-auth]
-  [#2480](https://github.com/mainmatter/ember-simple-auth/pull/2480) Remove
-  deprecated mixins in favor of session service ([@BobrImperator])
-- [qonto/ember-cp-validations]
-  [#24](https://github.com/qonto/ember-cp-validations/pull/24) Fix tests for
-  ember-data@^4.5 ([@zeppelin])
-- [qonto/ember-cp-validations]
-  [#23](https://github.com/qonto/ember-cp-validations/pull/23) Ensure Ember Data
-  4.4 compatibility ([@zeppelin])
-- [mainmatter/ember-api-actions]
-  [#37](https://github.com/mainmatter/ember-api-actions/pull/37) Implement
-  experimental `adapterAction()` function ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#32](https://github.com/mainmatter/ember-api-actions/pull/32) ember-try:
-  Replace ember-source with ember-data scenarios ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#31](https://github.com/mainmatter/ember-api-actions/pull/31) Pass record
-  snapshots to `buildURL()` method ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#26](https://github.com/mainmatter/ember-api-actions/pull/26) Add
-  `requestType` option ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#25](https://github.com/mainmatter/ember-api-actions/pull/25) Add `method`
-  validity assertions ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#20](https://github.com/mainmatter/ember-api-actions/pull/20) README: Add
-  basic documentation ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#19](https://github.com/mainmatter/ember-api-actions/pull/19) npmignore: Add
-  more unnecessary files ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#18](https://github.com/mainmatter/ember-api-actions/pull/18)
-  ember-cli-htmlbars: Move to `devDependencies` ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#17](https://github.com/mainmatter/ember-api-actions/pull/17) ESLint: Declare
-  `release-it` config as CommonJS file ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#16](https://github.com/mainmatter/ember-api-actions/pull/16) Add missing
-  `access: public` publish config ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#15](https://github.com/mainmatter/ember-api-actions/pull/15) Rename to
-  `@mainmatter/ember-api-actions` ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#14](https://github.com/mainmatter/ember-api-actions/pull/14) Import
-  `customAction()` function from crates.io ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#13](https://github.com/mainmatter/ember-api-actions/pull/13) CI: Run
-  `npm publish` for pushed tags ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#12](https://github.com/mainmatter/ember-api-actions/pull/12) scripts: Set
-  `test` script to only run `ember test` ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#8](https://github.com/mainmatter/ember-api-actions/pull/8) CI: Pin action
-  versions ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#4](https://github.com/mainmatter/ember-api-actions/pull/4) Adjust Renovate
-  setup ([@Turbo87])
-- [mainmatter/ember-api-actions]
-  [#2](https://github.com/mainmatter/ember-api-actions/pull/2) CI: Migrate to
-  pnpm ([@Turbo87])
-- [MinThaMie/more-confetti-addon]
-  [#1](https://github.com/MinThaMie/more-confetti-addon/pull/1) protect fire()
-  function from being run in fastboot ([@mansona])
-- [cardstack/boxel-motion]
-  [#137](https://github.com/cardstack/boxel-motion/pull/137) Only register a
-  sprite modifier once, instead of whenever arguments change ([@nickschot])
-- [cardstack/boxel-motion]
-  [#134](https://github.com/cardstack/boxel-motion/pull/134) Fix location
-  deprecation by setting locationType to history ([@nickschot])
-- [cardstack/boxel-motion]
-  [#133](https://github.com/cardstack/boxel-motion/pull/133) Modernize
-  sprite-modifier to be compatible with the future ember-modifier v4
-  ([@nickschot])
-- [cardstack/boxel-motion]
-  [#129](https://github.com/cardstack/boxel-motion/pull/129) Remove
-  dependenciesMeta as it breaks things during development ([@nickschot])
-- [cardstack/boxel-motion]
-  [#128](https://github.com/cardstack/boxel-motion/pull/128) Remove unnecessary
-  re-exports ([@nickschot])
-- [mainmatter/ember-cli-list-addons]
-  [#1](https://github.com/mainmatter/ember-cli-list-addons/pull/1) Initial
-  implementation ([@mansona])
-- [mainmatter/eslint-plugin-emberobserver]
-  [#3](https://github.com/mainmatter/eslint-plugin-emberobserver/pull/3) Fix
-  blocker preventing ember-observer from tracking an addon's embroider
-  compatibility ([@candunaj])
-- [mansona/ember-try] [#1](https://github.com/mansona/ember-try/pull/1)
-  onlyVersionCompatibility to generateConfig ([@candunaj])
+- [ember-cli/ember-try] [#893](https://github.com/ember-cli/ember-try/pull/893) breaking: drop EOL node versions < v14 and update smoke-test-app to fix CI ([@mansona])
+- [ember-cli/ember-try] [#896](https://github.com/ember-cli/ember-try/pull/896) Fixed version of ember-try-test-suite-helper ([@candunaj])
+- [ember-cli/ember-try-config] [#187](https://github.com/ember-cli/ember-try-config/pull/187) Added onlyVersionCompatibility to generateConfig ([@candunaj])
+- [ember-codemods/ember-native-class-codemod] [#491](https://github.com/ember-codemods/ember-native-class-codemod/pull/491) update codemods-telemetry-helpers ([@mansona])
+- [ember-learn/ember-blog] [#1234](https://github.com/ember-learn/ember-blog/pull/1234) always serve the index.html on netlify ([@mansona])
+- [ember-learn/ember-styleguide] [#435](https://github.com/ember-learn/ember-styleguide/pull/435) Breaking: drop support for EOL Node - minimum supported now v14 ([@mansona])
+- [ember-learn/ember-styleguide] [#434](https://github.com/ember-learn/ember-styleguide/pull/434) Update percy ([@mansona])
+- [ember-learn/guides-source] [#1870](https://github.com/ember-learn/guides-source/pull/1870) stop outputting `no issues found` on every file during markdown lint ([@mansona])
+- [mainmatter/ember-simple-auth] [#2480](https://github.com/mainmatter/ember-simple-auth/pull/2480) Remove deprecated mixins in favor of session service ([@BobrImperator])
+- [qonto/ember-cp-validations] [#24](https://github.com/qonto/ember-cp-validations/pull/24) Fix tests for ember-data@^4.5 ([@zeppelin])
+- [qonto/ember-cp-validations] [#23](https://github.com/qonto/ember-cp-validations/pull/23) Ensure Ember Data 4.4 compatibility ([@zeppelin])
+- [mainmatter/ember-api-actions] [#37](https://github.com/mainmatter/ember-api-actions/pull/37) Implement experimental `adapterAction()` function ([@Turbo87])
+- [mainmatter/ember-api-actions] [#32](https://github.com/mainmatter/ember-api-actions/pull/32) ember-try: Replace ember-source with ember-data scenarios ([@Turbo87])
+- [mainmatter/ember-api-actions] [#31](https://github.com/mainmatter/ember-api-actions/pull/31) Pass record snapshots to `buildURL()` method ([@Turbo87])
+- [mainmatter/ember-api-actions] [#26](https://github.com/mainmatter/ember-api-actions/pull/26) Add `requestType` option ([@Turbo87])
+- [mainmatter/ember-api-actions] [#25](https://github.com/mainmatter/ember-api-actions/pull/25) Add `method` validity assertions ([@Turbo87])
+- [mainmatter/ember-api-actions] [#20](https://github.com/mainmatter/ember-api-actions/pull/20) README: Add basic documentation ([@Turbo87])
+- [mainmatter/ember-api-actions] [#19](https://github.com/mainmatter/ember-api-actions/pull/19) npmignore: Add more unnecessary files ([@Turbo87])
+- [mainmatter/ember-api-actions] [#18](https://github.com/mainmatter/ember-api-actions/pull/18) ember-cli-htmlbars: Move to `devDependencies` ([@Turbo87])
+- [mainmatter/ember-api-actions] [#17](https://github.com/mainmatter/ember-api-actions/pull/17) ESLint: Declare `release-it` config as CommonJS file ([@Turbo87])
+- [mainmatter/ember-api-actions] [#16](https://github.com/mainmatter/ember-api-actions/pull/16) Add missing `access: public` publish config ([@Turbo87])
+- [mainmatter/ember-api-actions] [#15](https://github.com/mainmatter/ember-api-actions/pull/15) Rename to `@mainmatter/ember-api-actions` ([@Turbo87])
+- [mainmatter/ember-api-actions] [#14](https://github.com/mainmatter/ember-api-actions/pull/14) Import `customAction()` function from crates.io ([@Turbo87])
+- [mainmatter/ember-api-actions] [#13](https://github.com/mainmatter/ember-api-actions/pull/13) CI: Run `npm publish` for pushed tags ([@Turbo87])
+- [mainmatter/ember-api-actions] [#12](https://github.com/mainmatter/ember-api-actions/pull/12) scripts: Set `test` script to only run `ember test` ([@Turbo87])
+- [mainmatter/ember-api-actions] [#8](https://github.com/mainmatter/ember-api-actions/pull/8) CI: Pin action versions ([@Turbo87])
+- [mainmatter/ember-api-actions] [#4](https://github.com/mainmatter/ember-api-actions/pull/4) Adjust Renovate setup ([@Turbo87])
+- [mainmatter/ember-api-actions] [#2](https://github.com/mainmatter/ember-api-actions/pull/2) CI: Migrate to pnpm ([@Turbo87])
+- [MinThaMie/more-confetti-addon] [#1](https://github.com/MinThaMie/more-confetti-addon/pull/1) protect fire() function from being run in fastboot ([@mansona])
+- [cardstack/boxel-motion] [#137](https://github.com/cardstack/boxel-motion/pull/137) Only register a sprite modifier once, instead of whenever arguments change ([@nickschot])
+- [cardstack/boxel-motion] [#134](https://github.com/cardstack/boxel-motion/pull/134) Fix location deprecation by setting locationType to history ([@nickschot])
+- [cardstack/boxel-motion] [#133](https://github.com/cardstack/boxel-motion/pull/133) Modernize sprite-modifier to be compatible with the future ember-modifier v4 ([@nickschot])
+- [cardstack/boxel-motion] [#129](https://github.com/cardstack/boxel-motion/pull/129) Remove dependenciesMeta as it breaks things during development ([@nickschot])
+- [cardstack/boxel-motion] [#128](https://github.com/cardstack/boxel-motion/pull/128) Remove unnecessary re-exports ([@nickschot])
+- [mainmatter/ember-cli-list-addons] [#1](https://github.com/mainmatter/ember-cli-list-addons/pull/1) Initial implementation ([@mansona])
+- [mainmatter/eslint-plugin-emberobserver] [#3](https://github.com/mainmatter/eslint-plugin-emberobserver/pull/3) Fix blocker preventing ember-observer from tracking an addon's embroider compatibility ([@candunaj])
+- [mansona/ember-try] [#1](https://github.com/mansona/ember-try/pull/1) onlyVersionCompatibility to generateConfig ([@candunaj])
 
 ## Probot
 
-- [probot/probot] [#1763](https://github.com/probot/probot/pull/1763)
-  build(deps): upgrade @octokit/types to v8 ([@oscard0m])
+- [probot/probot] [#1763](https://github.com/probot/probot/pull/1763) build(deps): upgrade @octokit/types to v8 ([@oscard0m])
 
 ## Internal
 
-- [mainmatter/mainmatter-website-mailer]
-  [#7](https://github.com/mainmatter/mainmatter-website-mailer/pull/7) Add tests
-  ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#7](https://github.com/mainmatter/mainmatter-website-mailer/pull/7) Add tests ([@marcoow])
 
 [@bobrimperator]: https://github.com/BobrImperator
 [@turbo87]: https://github.com/Turbo87
@@ -190,28 +78,22 @@
 [@nickschot]: https://github.com/nickschot
 [@oscard0m]: https://github.com/oscard0m
 [@zeppelin]: https://github.com/zeppelin
-[minthamie/more-confetti-addon]:
-  https://github.com/MinThaMie/more-confetti-addon
+[minthamie/more-confetti-addon]: https://github.com/MinThaMie/more-confetti-addon
 [turbo87/renovate-config]: https://github.com/Turbo87/renovate-config
-[turbo87/segelflug-classifieds]:
-  https://github.com/Turbo87/segelflug-classifieds
+[turbo87/segelflug-classifieds]: https://github.com/Turbo87/segelflug-classifieds
 [turbo87/sentry-conduit]: https://github.com/Turbo87/sentry-conduit
 [cardstack/boxel-motion]: https://github.com/cardstack/boxel-motion
 [ember-cli/ember-try-config]: https://github.com/ember-cli/ember-try-config
 [ember-cli/ember-try]: https://github.com/ember-cli/ember-try
-[ember-codemods/ember-native-class-codemod]:
-  https://github.com/ember-codemods/ember-native-class-codemod
+[ember-codemods/ember-native-class-codemod]: https://github.com/ember-codemods/ember-native-class-codemod
 [ember-learn/ember-blog]: https://github.com/ember-learn/ember-blog
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [mainmatter/ember-api-actions]: https://github.com/mainmatter/ember-api-actions
-[mainmatter/ember-cli-list-addons]:
-  https://github.com/mainmatter/ember-cli-list-addons
+[mainmatter/ember-cli-list-addons]: https://github.com/mainmatter/ember-cli-list-addons
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
-[mainmatter/eslint-plugin-emberobserver]:
-  https://github.com/mainmatter/eslint-plugin-emberobserver
-[mainmatter/mainmatter-website-mailer]:
-  https://github.com/mainmatter/mainmatter-website-mailer
+[mainmatter/eslint-plugin-emberobserver]: https://github.com/mainmatter/eslint-plugin-emberobserver
+[mainmatter/mainmatter-website-mailer]: https://github.com/mainmatter/mainmatter-website-mailer
 [mansona/ember-try]: https://github.com/mansona/ember-try
 [probot/probot]: https://github.com/probot/probot
 [qonto/ember-cp-validations]: https://github.com/qonto/ember-cp-validations
diff --git a/src/twios/2023-03-06.md b/src/twios/2023-03-06.md
index 5d5d3db5d5..675f1a846c 100644
--- a/src/twios/2023-03-06.md
+++ b/src/twios/2023-03-06.md
@@ -1,164 +1,76 @@
 ## Rust
 
-- [marcoow/rust_rest] [#5](https://github.com/marcoow/rust_rest/pull/5) move
-  test helpers into their own module ([@marcoow])
-- [marcoow/rust_rest] [#4](https://github.com/marcoow/rust_rest/pull/4) Improve
-  migrations command ([@marcoow])
-- [marcoow/rust_rest] [#3](https://github.com/marcoow/rust_rest/pull/3) use
-  dedicated database for tests ([@marcoow])
-- [marcoow/rust_rest] [#2](https://github.com/marcoow/rust_rest/pull/2) use
-  dotenvy instead of dotenv ([@marcoow])
-- [rust-lang/www.rust-lang.org]
-  [#1776](https://github.com/rust-lang/www.rust-lang.org/pull/1776) governance:
-  Remove outdated "Roadmap" section ([@Turbo87])
+- [marcoow/rust_rest] [#5](https://github.com/marcoow/rust_rest/pull/5) move test helpers into their own module ([@marcoow])
+- [marcoow/rust_rest] [#4](https://github.com/marcoow/rust_rest/pull/4) Improve migrations command ([@marcoow])
+- [marcoow/rust_rest] [#3](https://github.com/marcoow/rust_rest/pull/3) use dedicated database for tests ([@marcoow])
+- [marcoow/rust_rest] [#2](https://github.com/marcoow/rust_rest/pull/2) use dotenvy instead of dotenv ([@marcoow])
+- [rust-lang/www.rust-lang.org] [#1776](https://github.com/rust-lang/www.rust-lang.org/pull/1776) governance: Remove outdated "Roadmap" section ([@Turbo87])
 
 ## crates.io
 
-- [rust-lang/crates.io]
-  [#6104](https://github.com/rust-lang/crates.io/pull/6104) email: Add
-  `Content-Type` header ([@Turbo87])
-- [rust-lang/crates.io]
-  [#6071](https://github.com/rust-lang/crates.io/pull/6071) middleware: Use new
-  `option_layer()` from `axum-extra` crate ([@Turbo87])
-- [rust-lang/crates.io]
-  [#6070](https://github.com/rust-lang/crates.io/pull/6070) Use Renovatebot
-  regex managers for Docker files ([@Turbo87])
-- [rust-lang/crates.io]
-  [#6050](https://github.com/rust-lang/crates.io/pull/6050) Remove deprecated
-  `ember-export-application-global` dependency ([@Turbo87])
-- [rust-lang/crates.io]
-  [#6043](https://github.com/rust-lang/crates.io/pull/6043) background-worker:
-  Speed up index cloning by 3x ([@Turbo87])
-- [rust-lang/crates.io]
-  [#6039](https://github.com/rust-lang/crates.io/pull/6039) Replace custom
-  `certificate_check()` impl with regular `known_hosts` file ([@Turbo87])
-- [rust-lang/crates.io]
-  [#6033](https://github.com/rust-lang/crates.io/pull/6033) Fix SSH hostkey
-  checks for `push()` ([@Turbo87])
-- [rust-lang/crates.io]
-  [#6032](https://github.com/rust-lang/crates.io/pull/6032) Implement GitHub SSH
-  certificate checks ([@Turbo87])
+- [rust-lang/crates.io] [#6104](https://github.com/rust-lang/crates.io/pull/6104) email: Add `Content-Type` header ([@Turbo87])
+- [rust-lang/crates.io] [#6071](https://github.com/rust-lang/crates.io/pull/6071) middleware: Use new `option_layer()` from `axum-extra` crate ([@Turbo87])
+- [rust-lang/crates.io] [#6070](https://github.com/rust-lang/crates.io/pull/6070) Use Renovatebot regex managers for Docker files ([@Turbo87])
+- [rust-lang/crates.io] [#6050](https://github.com/rust-lang/crates.io/pull/6050) Remove deprecated `ember-export-application-global` dependency ([@Turbo87])
+- [rust-lang/crates.io] [#6043](https://github.com/rust-lang/crates.io/pull/6043) background-worker: Speed up index cloning by 3x ([@Turbo87])
+- [rust-lang/crates.io] [#6039](https://github.com/rust-lang/crates.io/pull/6039) Replace custom `certificate_check()` impl with regular `known_hosts` file ([@Turbo87])
+- [rust-lang/crates.io] [#6033](https://github.com/rust-lang/crates.io/pull/6033) Fix SSH hostkey checks for `push()` ([@Turbo87])
+- [rust-lang/crates.io] [#6032](https://github.com/rust-lang/crates.io/pull/6032) Implement GitHub SSH certificate checks ([@Turbo87])
 
 ## Octoherd
 
-- [oscard0m/octoherd-script-review-pull-requests]
-  [#1](https://github.com/oscard0m/octoherd-script-review-pull-requests/pull/1)
-  feat: Initial version ([@oscard0m])
+- [oscard0m/octoherd-script-review-pull-requests] [#1](https://github.com/oscard0m/octoherd-script-review-pull-requests/pull/1) feat: Initial version ([@oscard0m])
 
 ## BEM
 
-- [getbem/getbem.github.io]
-  [#303](https://github.com/getbem/getbem.github.io/pull/303) add anchor links
-  to headings ([@oscard0m])
+- [getbem/getbem.github.io] [#303](https://github.com/getbem/getbem.github.io/pull/303) add anchor links to headings ([@oscard0m])
 
 ## Cal.com
 
-- [calcom/cal.com] [#7212](https://github.com/calcom/cal.com/pull/7212) improve
-  typing by removing as html element ([@oscard0m])
+- [calcom/cal.com] [#7212](https://github.com/calcom/cal.com/pull/7212) improve typing by removing as html element ([@oscard0m])
 
 ## Ember.js
 
-- [emberjs/core-notes] [#485](https://github.com/emberjs/core-notes/pull/485)
-  add embroider notes for feb 14th ([@mansona])
-- [emberjs/core-notes] [#483](https://github.com/emberjs/core-notes/pull/483)
-  embroider notes for Feb 7th ([@mansona])
-- [mainmatter/ember-api-actions]
-  [#151](https://github.com/mainmatter/ember-api-actions/pull/151) Allow
-  `buildURL()` overrides to return query parameters ([@Turbo87])
-- [mainmatter/ember-simple-auth]
-  [#2515](https://github.com/mainmatter/ember-simple-auth/pull/2515) chore:
-  enable ember-default in ci ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2513](https://github.com/mainmatter/ember-simple-auth/pull/2513)
-  refactor(cleanup): remove ember-data from ESA addon ([@BobrImperator])
-- [mainmatter/ember-template-assert]
-  [#4](https://github.com/mainmatter/ember-template-assert/pull/4) Cleanup
-  unnecessary auto-import dep and config ([@nickschot])
-- [mainmatter/ember-template-assert]
-  [#3](https://github.com/mainmatter/ember-template-assert/pull/3) Fix AST
-  transform not detecting production env correctly when used in an app
-  ([@nickschot])
-- [mainmatter/ember-template-assert]
-  [#2](https://github.com/mainmatter/ember-template-assert/pull/2) Update
-  ember-cli blueprint to 4.10 ([@nickschot])
-- [mainmatter/ember-workshop]
-  [#754](https://github.com/mainmatter/ember-workshop/pull/754) Dependabot →
-  Renovatebot ([@zeppelin])
-- [mainmatter/ember-workshop]
-  [#753](https://github.com/mainmatter/ember-workshop/pull/753) Bump
-  PNPM_VERSION for GH ([@zeppelin])
-- [nickschot/ember-gesture-modifiers]
-  [#411](https://github.com/nickschot/ember-gesture-modifiers/pull/411) Upgrade
-  to eslint 8 ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#410](https://github.com/nickschot/ember-gesture-modifiers/pull/410) Update
-  to ember-cli 4.10 blueprint ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#408](https://github.com/nickschot/ember-gesture-modifiers/pull/408) Drop
-  support for ember 3.24 ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#407](https://github.com/nickschot/ember-gesture-modifiers/pull/407) Add
-  ember-auto-import to dependencies to support v2 addons ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#575](https://github.com/nickschot/ember-mobile-menu/pull/575) Add missing
-  peerDeps ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#574](https://github.com/nickschot/ember-mobile-menu/pull/574) Upgrade to
-  eslint v8 ([@nickschot])
-- [zeppelin/ember-click-outside]
-  [#262](https://github.com/zeppelin/ember-click-outside/pull/262) Fix
-  ember-canary tests by updating ember-qunit ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#261](https://github.com/zeppelin/ember-click-outside/pull/261) Widen
-  ember-modifier dependency range ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#260](https://github.com/zeppelin/ember-click-outside/pull/260) Remove
-  deprecated `<ClickOutside>` component ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#259](https://github.com/zeppelin/ember-click-outside/pull/259) Convert to V2
-  addon format ([@zeppelin])
-- [zeppelin/ember-click-outside]
-  [#258](https://github.com/zeppelin/ember-click-outside/pull/258) Remove unused
-  `printConsoleMessage` function ([@zeppelin])
-- [DazzlingFugu/ember-slugify]
-  [#258](https://github.com/DazzlingFugu/ember-slugify/pull/258) BREAKING
-  Migrate to V2 Addon ([@BlueCutOfficial])
-- [DazzlingFugu/ember-slugify]
-  [#257](https://github.com/DazzlingFugu/ember-slugify/pull/257) Ember 4.8
-  ([@BlueCutOfficial])
-- [DazzlingFugu/ember-slugify]
-  [#256](https://github.com/DazzlingFugu/ember-slugify/pull/256) release version
-  4.0 ([@BlueCutOfficial])
-- [DazzlingFugu/ember-slugify]
-  [#254](https://github.com/DazzlingFugu/ember-slugify/pull/254) BREAKING
-  tests(CI): drop support for ember < 3.28, not compatible wit…
-  ([@BlueCutOfficial])
+- [emberjs/core-notes] [#485](https://github.com/emberjs/core-notes/pull/485) add embroider notes for feb 14th ([@mansona])
+- [emberjs/core-notes] [#483](https://github.com/emberjs/core-notes/pull/483) embroider notes for Feb 7th ([@mansona])
+- [mainmatter/ember-api-actions] [#151](https://github.com/mainmatter/ember-api-actions/pull/151) Allow `buildURL()` overrides to return query parameters ([@Turbo87])
+- [mainmatter/ember-simple-auth] [#2515](https://github.com/mainmatter/ember-simple-auth/pull/2515) chore: enable ember-default in ci ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2513](https://github.com/mainmatter/ember-simple-auth/pull/2513) refactor(cleanup): remove ember-data from ESA addon ([@BobrImperator])
+- [mainmatter/ember-template-assert] [#4](https://github.com/mainmatter/ember-template-assert/pull/4) Cleanup unnecessary auto-import dep and config ([@nickschot])
+- [mainmatter/ember-template-assert] [#3](https://github.com/mainmatter/ember-template-assert/pull/3) Fix AST transform not detecting production env correctly when used in an app ([@nickschot])
+- [mainmatter/ember-template-assert] [#2](https://github.com/mainmatter/ember-template-assert/pull/2) Update ember-cli blueprint to 4.10 ([@nickschot])
+- [mainmatter/ember-workshop] [#754](https://github.com/mainmatter/ember-workshop/pull/754) Dependabot → Renovatebot ([@zeppelin])
+- [mainmatter/ember-workshop] [#753](https://github.com/mainmatter/ember-workshop/pull/753) Bump PNPM_VERSION for GH ([@zeppelin])
+- [nickschot/ember-gesture-modifiers] [#411](https://github.com/nickschot/ember-gesture-modifiers/pull/411) Upgrade to eslint 8 ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#410](https://github.com/nickschot/ember-gesture-modifiers/pull/410) Update to ember-cli 4.10 blueprint ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#408](https://github.com/nickschot/ember-gesture-modifiers/pull/408) Drop support for ember 3.24 ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#407](https://github.com/nickschot/ember-gesture-modifiers/pull/407) Add ember-auto-import to dependencies to support v2 addons ([@nickschot])
+- [nickschot/ember-mobile-menu] [#575](https://github.com/nickschot/ember-mobile-menu/pull/575) Add missing peerDeps ([@nickschot])
+- [nickschot/ember-mobile-menu] [#574](https://github.com/nickschot/ember-mobile-menu/pull/574) Upgrade to eslint v8 ([@nickschot])
+- [zeppelin/ember-click-outside] [#262](https://github.com/zeppelin/ember-click-outside/pull/262) Fix ember-canary tests by updating ember-qunit ([@zeppelin])
+- [zeppelin/ember-click-outside] [#261](https://github.com/zeppelin/ember-click-outside/pull/261) Widen ember-modifier dependency range ([@zeppelin])
+- [zeppelin/ember-click-outside] [#260](https://github.com/zeppelin/ember-click-outside/pull/260) Remove deprecated `<ClickOutside>` component ([@zeppelin])
+- [zeppelin/ember-click-outside] [#259](https://github.com/zeppelin/ember-click-outside/pull/259) Convert to V2 addon format ([@zeppelin])
+- [zeppelin/ember-click-outside] [#258](https://github.com/zeppelin/ember-click-outside/pull/258) Remove unused `printConsoleMessage` function ([@zeppelin])
+- [DazzlingFugu/ember-slugify] [#258](https://github.com/DazzlingFugu/ember-slugify/pull/258) BREAKING Migrate to V2 Addon ([@BlueCutOfficial])
+- [DazzlingFugu/ember-slugify] [#257](https://github.com/DazzlingFugu/ember-slugify/pull/257) Ember 4.8 ([@BlueCutOfficial])
+- [DazzlingFugu/ember-slugify] [#256](https://github.com/DazzlingFugu/ember-slugify/pull/256) release version 4.0 ([@BlueCutOfficial])
+- [DazzlingFugu/ember-slugify] [#254](https://github.com/DazzlingFugu/ember-slugify/pull/254) BREAKING tests(CI): drop support for ember < 3.28, not compatible wit… ([@BlueCutOfficial])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1359](https://github.com/embroider-build/embroider/pull/1359) Ignore resolve
-  requests that start with ! ([@mansona])
+- [embroider-build/embroider] [#1359](https://github.com/embroider-build/embroider/pull/1359) Ignore resolve requests that start with ! ([@mansona])
 
 ## Octokit
 
-- [octokit/.github] [#38](https://github.com/octokit/.github/pull/38)
-  feat(renovate-config): automerge lockFileMaintenance changes ([@oscard0m])
-- [octokit/plugin-retry.js]
-  [#410](https://github.com/octokit/plugin-retry.js/pull/410) Add script to fix
-  package json from build step ([@oscard0m])
+- [octokit/.github] [#38](https://github.com/octokit/.github/pull/38) feat(renovate-config): automerge lockFileMaintenance changes ([@oscard0m])
+- [octokit/plugin-retry.js] [#410](https://github.com/octokit/plugin-retry.js/pull/410) Add script to fix package json from build step ([@oscard0m])
 
 ## Renovate
 
-- [renovatebot/renovate]
-  [#20357](https://github.com/renovatebot/renovate/pull/20357)
-  fix(versioning/cargo): Disable support for `rangeStrategy: widen` ([@Turbo87])
-- [renovatebot/renovate]
-  [#20355](https://github.com/renovatebot/renovate/pull/20355) fix(cargo): fix
-  pinning for wildcard constraints ([@Turbo87])
-- [renovatebot/renovate]
-  [#20333](https://github.com/renovatebot/renovate/pull/20333)
-  chore(VersioningApi): add doc comments ([@Turbo87])
+- [renovatebot/renovate] [#20357](https://github.com/renovatebot/renovate/pull/20357) fix(versioning/cargo): Disable support for `rangeStrategy: widen` ([@Turbo87])
+- [renovatebot/renovate] [#20355](https://github.com/renovatebot/renovate/pull/20355) fix(cargo): fix pinning for wildcard constraints ([@Turbo87])
+- [renovatebot/renovate] [#20333](https://github.com/renovatebot/renovate/pull/20333) chore(VersioningApi): add doc comments ([@Turbo87])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
@@ -175,17 +87,14 @@
 [getbem/getbem.github.io]: https://github.com/getbem/getbem.github.io
 [mainmatter/ember-api-actions]: https://github.com/mainmatter/ember-api-actions
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
-[mainmatter/ember-template-assert]:
-  https://github.com/mainmatter/ember-template-assert
+[mainmatter/ember-template-assert]: https://github.com/mainmatter/ember-template-assert
 [mainmatter/ember-workshop]: https://github.com/mainmatter/ember-workshop
 [marcoow/rust_rest]: https://github.com/marcoow/rust_rest
-[nickschot/ember-gesture-modifiers]:
-  https://github.com/nickschot/ember-gesture-modifiers
+[nickschot/ember-gesture-modifiers]: https://github.com/nickschot/ember-gesture-modifiers
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
 [octokit/.github]: https://github.com/octokit/.github
 [octokit/plugin-retry.js]: https://github.com/octokit/plugin-retry.js
-[oscard0m/octoherd-script-review-pull-requests]:
-  https://github.com/oscard0m/octoherd-script-review-pull-requests
+[oscard0m/octoherd-script-review-pull-requests]: https://github.com/oscard0m/octoherd-script-review-pull-requests
 [renovatebot/renovate]: https://github.com/renovatebot/renovate
 [rust-lang/crates.io]: https://github.com/rust-lang/crates.io
 [rust-lang/www.rust-lang.org]: https://github.com/rust-lang/www.rust-lang.org
diff --git a/src/twios/2023-03-29.md b/src/twios/2023-03-29.md
index 8803b015f1..61fdfb1e0b 100644
--- a/src/twios/2023-03-29.md
+++ b/src/twios/2023-03-29.md
@@ -1,179 +1,77 @@
 ## Rust
 
-- [dimforge/rapier.rs] [#61](https://github.com/dimforge/rapier.rs/pull/61)
-  Update "Getting Started page" for bevy_rapier to bevy 0.10 ([@BobrImperator])
-- [marcoow/rust_rest] [#8](https://github.com/marcoow/rust_rest/pull/8) use
-  `clap` for parsing CLI arguments in `db` binary ([@marcoow])
-- [marcoow/rust_rest] [#7](https://github.com/marcoow/rust_rest/pull/7) Remove
-  `dotenv!` macro ([@marcoow])
-- [marcoow/rust_rest] [#6](https://github.com/marcoow/rust_rest/pull/6) fail
-  clippy for all warnings on CI ([@marcoow])
+- [dimforge/rapier.rs] [#61](https://github.com/dimforge/rapier.rs/pull/61) Update "Getting Started page" for bevy_rapier to bevy 0.10 ([@BobrImperator])
+- [marcoow/rust_rest] [#8](https://github.com/marcoow/rust_rest/pull/8) use `clap` for parsing CLI arguments in `db` binary ([@marcoow])
+- [marcoow/rust_rest] [#7](https://github.com/marcoow/rust_rest/pull/7) Remove `dotenv!` macro ([@marcoow])
+- [marcoow/rust_rest] [#6](https://github.com/marcoow/rust_rest/pull/6) fail clippy for all warnings on CI ([@marcoow])
 
 ## Ember.js
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#167](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/167)
-  Translate guides/release/getting-started/quick-start.md ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#165](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/165)
-  Translate guides/release/addons-and-dependencies/index.md ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#164](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/164)
-  Translate .../getting-started/anatomy-of-an-ember-app.md ([@BlueCutOfficial])
-- [ef4/ember-auto-import]
-  [#573](https://github.com/ef4/ember-auto-import/pull/573) added
-  babel-plugin-ember-template-compilation ([@candunaj])
-- [ember-cli/babel-plugin-htmlbars-inline-precompile]
-  [#486](https://github.com/ember-cli/babel-plugin-htmlbars-inline-precompile/pull/486)
-  [WIP] precompileTemplate with scope that has properties with different key and
-  value ([@candunaj])
-- [ember-cli/ember-try] [#934](https://github.com/ember-cli/ember-try/pull/934)
-  Update github CI yaml ([@mansona])
-- [ember-cli/ember-try] [#933](https://github.com/ember-cli/ember-try/pull/933)
-  Update smoke test to fix CI ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#451](https://github.com/ember-learn/ember-styleguide/pull/451) update
-  percy-cli ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#449](https://github.com/ember-learn/ember-styleguide/pull/449) add
-  permissions for continue-on-error ([@mansona])
-- [ember-learn/empress-blog-ember-template]
-  [#138](https://github.com/ember-learn/empress-blog-ember-template/pull/138)
-  fix ember-try scenarios for canary beta release ([@mansona])
-- [ember-learn/empress-blog-ember-template]
-  [#137](https://github.com/ember-learn/empress-blog-ember-template/pull/137)
-  Update Percy ([@mansona])
-- [emberjs/babel-plugin-ember-template-compilation]
-  [#17](https://github.com/emberjs/babel-plugin-ember-template-compilation/pull/17)
-  [WIP] precompileTemplate with scope that has properties with different key and
-  value ([@candunaj])
-- [emberjs/core-notes] [#490](https://github.com/emberjs/core-notes/pull/490)
-  add notes for embroider meeting Mar 21st ([@mansona])
-- [emberjs/core-notes] [#489](https://github.com/emberjs/core-notes/pull/489)
-  add notes for embroider mar 14th ([@mansona])
-- [emberjs/core-notes] [#487](https://github.com/emberjs/core-notes/pull/487)
-  add notes for embroider meeting Mar 7th ([@mansona])
-- [kategengler/ember-cli-code-coverage]
-  [#379](https://github.com/kategengler/ember-cli-code-coverage/pull/379) allow
-  for a wider range of embroider dependencies ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#69](https://github.com/mainmatter/ember-asset-size-action/pull/69) Add
-  support for specifying a custom npm build command (npm run <custom>)
-  ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#68](https://github.com/mainmatter/ember-asset-size-action/pull/68) add
-  support for pnpm ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#67](https://github.com/mainmatter/ember-asset-size-action/pull/67) add
-  support to specify a working-directory ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#66](https://github.com/mainmatter/ember-asset-size-action/pull/66) Fix npm 7
-  check with semver ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#64](https://github.com/mainmatter/ember-asset-size-action/pull/64) Optinally
-  show total diff size of all assets ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#62](https://github.com/mainmatter/ember-asset-size-action/pull/62) Use
-  native esm and remove esm dependency ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#61](https://github.com/mainmatter/ember-asset-size-action/pull/61) remove
-  unused yn dependency ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#51](https://github.com/mainmatter/ember-asset-size-action/pull/51) add
-  renovatebot configuration ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#50](https://github.com/mainmatter/ember-asset-size-action/pull/50) Update
-  all Mainmatter references ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#49](https://github.com/mainmatter/ember-asset-size-action/pull/49) Set a
-  "minimum change" of 10 bytes to avoid jitter in reporting ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#48](https://github.com/mainmatter/ember-asset-size-action/pull/48) Wrap the
-  file tables in a `<details>` ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#47](https://github.com/mainmatter/ember-asset-size-action/pull/47) Handle
-  ember-auto-import chunks ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#43](https://github.com/mainmatter/ember-asset-size-action/pull/43) switching
-  to @vercel/ncc ([@mansona])
-- [mainmatter/ember-simple-auth]
-  [#2531](https://github.com/mainmatter/ember-simple-auth/pull/2531) chore(doc):
-  generate documentation for v5.0.0 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2530](https://github.com/mainmatter/ember-simple-auth/pull/2530)
-  chore(deps): remove typescript-transform resolution ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2529](https://github.com/mainmatter/ember-simple-auth/pull/2529)
-  chore(deps): remove cssstyle resolutions ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2528](https://github.com/mainmatter/ember-simple-auth/pull/2528)
-  chore(deps): remove jsdom resolutions ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2527](https://github.com/mainmatter/ember-simple-auth/pull/2527) chore:
-  prolong Torri authenticator deprecation period until v6 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2526](https://github.com/mainmatter/ember-simple-auth/pull/2526) feat:
-  remove deprecated Evented API usage from the public session service
-  ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2525](https://github.com/mainmatter/ember-simple-auth/pull/2525) chore: Drop
-  node - set minimal node version to >=16 ([@BobrImperator])
+- [DazzlingFugu/ember-fr-guides-source] [#167](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/167) Translate guides/release/getting-started/quick-start.md ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#165](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/165) Translate guides/release/addons-and-dependencies/index.md ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#164](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/164) Translate .../getting-started/anatomy-of-an-ember-app.md ([@BlueCutOfficial])
+- [ef4/ember-auto-import] [#573](https://github.com/ef4/ember-auto-import/pull/573) added babel-plugin-ember-template-compilation ([@candunaj])
+- [ember-cli/babel-plugin-htmlbars-inline-precompile] [#486](https://github.com/ember-cli/babel-plugin-htmlbars-inline-precompile/pull/486) [WIP] precompileTemplate with scope that has properties with different key and value ([@candunaj])
+- [ember-cli/ember-try] [#934](https://github.com/ember-cli/ember-try/pull/934) Update github CI yaml ([@mansona])
+- [ember-cli/ember-try] [#933](https://github.com/ember-cli/ember-try/pull/933) Update smoke test to fix CI ([@mansona])
+- [ember-learn/ember-styleguide] [#451](https://github.com/ember-learn/ember-styleguide/pull/451) update percy-cli ([@mansona])
+- [ember-learn/ember-styleguide] [#449](https://github.com/ember-learn/ember-styleguide/pull/449) add permissions for continue-on-error ([@mansona])
+- [ember-learn/empress-blog-ember-template] [#138](https://github.com/ember-learn/empress-blog-ember-template/pull/138) fix ember-try scenarios for canary beta release ([@mansona])
+- [ember-learn/empress-blog-ember-template] [#137](https://github.com/ember-learn/empress-blog-ember-template/pull/137) Update Percy ([@mansona])
+- [emberjs/babel-plugin-ember-template-compilation] [#17](https://github.com/emberjs/babel-plugin-ember-template-compilation/pull/17) [WIP] precompileTemplate with scope that has properties with different key and value ([@candunaj])
+- [emberjs/core-notes] [#490](https://github.com/emberjs/core-notes/pull/490) add notes for embroider meeting Mar 21st ([@mansona])
+- [emberjs/core-notes] [#489](https://github.com/emberjs/core-notes/pull/489) add notes for embroider mar 14th ([@mansona])
+- [emberjs/core-notes] [#487](https://github.com/emberjs/core-notes/pull/487) add notes for embroider meeting Mar 7th ([@mansona])
+- [kategengler/ember-cli-code-coverage] [#379](https://github.com/kategengler/ember-cli-code-coverage/pull/379) allow for a wider range of embroider dependencies ([@mansona])
+- [mainmatter/ember-asset-size-action] [#69](https://github.com/mainmatter/ember-asset-size-action/pull/69) Add support for specifying a custom npm build command (npm run <custom>) ([@mansona])
+- [mainmatter/ember-asset-size-action] [#68](https://github.com/mainmatter/ember-asset-size-action/pull/68) add support for pnpm ([@mansona])
+- [mainmatter/ember-asset-size-action] [#67](https://github.com/mainmatter/ember-asset-size-action/pull/67) add support to specify a working-directory ([@mansona])
+- [mainmatter/ember-asset-size-action] [#66](https://github.com/mainmatter/ember-asset-size-action/pull/66) Fix npm 7 check with semver ([@mansona])
+- [mainmatter/ember-asset-size-action] [#64](https://github.com/mainmatter/ember-asset-size-action/pull/64) Optinally show total diff size of all assets ([@mansona])
+- [mainmatter/ember-asset-size-action] [#62](https://github.com/mainmatter/ember-asset-size-action/pull/62) Use native esm and remove esm dependency ([@mansona])
+- [mainmatter/ember-asset-size-action] [#61](https://github.com/mainmatter/ember-asset-size-action/pull/61) remove unused yn dependency ([@mansona])
+- [mainmatter/ember-asset-size-action] [#51](https://github.com/mainmatter/ember-asset-size-action/pull/51) add renovatebot configuration ([@mansona])
+- [mainmatter/ember-asset-size-action] [#50](https://github.com/mainmatter/ember-asset-size-action/pull/50) Update all Mainmatter references ([@mansona])
+- [mainmatter/ember-asset-size-action] [#49](https://github.com/mainmatter/ember-asset-size-action/pull/49) Set a "minimum change" of 10 bytes to avoid jitter in reporting ([@mansona])
+- [mainmatter/ember-asset-size-action] [#48](https://github.com/mainmatter/ember-asset-size-action/pull/48) Wrap the file tables in a `<details>` ([@mansona])
+- [mainmatter/ember-asset-size-action] [#47](https://github.com/mainmatter/ember-asset-size-action/pull/47) Handle ember-auto-import chunks ([@mansona])
+- [mainmatter/ember-asset-size-action] [#43](https://github.com/mainmatter/ember-asset-size-action/pull/43) switching to @vercel/ncc ([@mansona])
+- [mainmatter/ember-simple-auth] [#2531](https://github.com/mainmatter/ember-simple-auth/pull/2531) chore(doc): generate documentation for v5.0.0 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2530](https://github.com/mainmatter/ember-simple-auth/pull/2530) chore(deps): remove typescript-transform resolution ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2529](https://github.com/mainmatter/ember-simple-auth/pull/2529) chore(deps): remove cssstyle resolutions ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2528](https://github.com/mainmatter/ember-simple-auth/pull/2528) chore(deps): remove jsdom resolutions ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2527](https://github.com/mainmatter/ember-simple-auth/pull/2527) chore: prolong Torri authenticator deprecation period until v6 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2526](https://github.com/mainmatter/ember-simple-auth/pull/2526) feat: remove deprecated Evented API usage from the public session service ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2525](https://github.com/mainmatter/ember-simple-auth/pull/2525) chore: Drop node - set minimal node version to >=16 ([@BobrImperator])
 
 ## Empress
 
-- [empress/bottled-ember]
-  [#18](https://github.com/empress/bottled-ember/pull/18) Really fix terminal
-  colour implementation ([@mansona])
-- [empress/bottled-ember]
-  [#17](https://github.com/empress/bottled-ember/pull/17) fix issues with ansi
-  colours ([@mansona])
-- [empress/bottled-ember]
-  [#16](https://github.com/empress/bottled-ember/pull/16) breaking: Add some
-  tests and fix --no-overlay command line option and move from minimist to
-  commander ([@mansona])
+- [empress/bottled-ember] [#18](https://github.com/empress/bottled-ember/pull/18) Really fix terminal colour implementation ([@mansona])
+- [empress/bottled-ember] [#17](https://github.com/empress/bottled-ember/pull/17) fix issues with ansi colours ([@mansona])
+- [empress/bottled-ember] [#16](https://github.com/empress/bottled-ember/pull/16) breaking: Add some tests and fix --no-overlay command line option and move from minimist to commander ([@mansona])
 
 ## JavaScript
 
-- [mainmatter/compare-fixture]
-  [#3](https://github.com/mainmatter/compare-fixture/pull/3) Make sure the
-  exitCode is 1 when diffs are detected ([@mansona])
-- [mainmatter/compare-fixture]
-  [#2](https://github.com/mainmatter/compare-fixture/pull/2) add initial
-  implementation ([@mansona])
-- [mainmatter/mocha-diff] [#3](https://github.com/mainmatter/mocha-diff/pull/3)
-  Add Example Output ([@mansona])
-- [mainmatter/mocha-diff] [#2](https://github.com/mainmatter/mocha-diff/pull/2)
-  Fix CI ([@mansona])
+- [mainmatter/compare-fixture] [#3](https://github.com/mainmatter/compare-fixture/pull/3) Make sure the exitCode is 1 when diffs are detected ([@mansona])
+- [mainmatter/compare-fixture] [#2](https://github.com/mainmatter/compare-fixture/pull/2) add initial implementation ([@mansona])
+- [mainmatter/mocha-diff] [#3](https://github.com/mainmatter/mocha-diff/pull/3) Add Example Output ([@mansona])
+- [mainmatter/mocha-diff] [#2](https://github.com/mainmatter/mocha-diff/pull/2) Fix CI ([@mansona])
 
 ## Octokit
 
-- [oscard0m/octoherd-script-release-workflow-patch]
-  [#1](https://github.com/oscard0m/octoherd-script-release-workflow-patch/pull/1)
-  feat: Initial version ([@oscard0m])
+- [oscard0m/octoherd-script-release-workflow-patch] [#1](https://github.com/oscard0m/octoherd-script-release-workflow-patch/pull/1) feat: Initial version ([@oscard0m])
 
 ## Internal
 
-- [mainmatter/mainmatter-website-mailer]
-  [#20](https://github.com/mainmatter/mainmatter-website-mailer/pull/20) enable
-  Zapier automation via email ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#19](https://github.com/mainmatter/mainmatter-website-mailer/pull/19) make
-  the service optional ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#18](https://github.com/mainmatter/mainmatter-website-mailer/pull/18) send
-  service in subject ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#9](https://github.com/mainmatter/mainmatter-website-mailer/pull/9) include
-  selected service in message ([@marcoow])
-- [mainmatter/renovate-config]
-  [#14](https://github.com/mainmatter/renovate-config/pull/14) remove
-  helpers:pinGitHubActionDigests ([@mansona])
+- [mainmatter/mainmatter-website-mailer] [#20](https://github.com/mainmatter/mainmatter-website-mailer/pull/20) enable Zapier automation via email ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#19](https://github.com/mainmatter/mainmatter-website-mailer/pull/19) make the service optional ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#18](https://github.com/mainmatter/mainmatter-website-mailer/pull/18) send service in subject ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#9](https://github.com/mainmatter/mainmatter-website-mailer/pull/9) include selected service in message ([@marcoow])
+- [mainmatter/renovate-config] [#14](https://github.com/mainmatter/renovate-config/pull/14) remove helpers:pinGitHubActionDigests ([@mansona])
 
 ## Miscellaneous
 
-- [freeCodeCamp/learn-bash-by-building-a-boilerplate]
-  [#24](https://github.com/freeCodeCamp/learn-bash-by-building-a-boilerplate/pull/24)
-  fix: typo withing -> within ([@inesilva])
+- [freeCodeCamp/learn-bash-by-building-a-boilerplate] [#24](https://github.com/freeCodeCamp/learn-bash-by-building-a-boilerplate/pull/24) fix: typo withing -> within ([@inesilva])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
@@ -182,32 +80,23 @@
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
 [@oscard0m]: https://github.com/oscard0m
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [dimforge/rapier.rs]: https://github.com/dimforge/rapier.rs
 [ef4/ember-auto-import]: https://github.com/ef4/ember-auto-import
-[ember-cli/babel-plugin-htmlbars-inline-precompile]:
-  https://github.com/ember-cli/babel-plugin-htmlbars-inline-precompile
+[ember-cli/babel-plugin-htmlbars-inline-precompile]: https://github.com/ember-cli/babel-plugin-htmlbars-inline-precompile
 [ember-cli/ember-try]: https://github.com/ember-cli/ember-try
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
-[ember-learn/empress-blog-ember-template]:
-  https://github.com/ember-learn/empress-blog-ember-template
-[emberjs/babel-plugin-ember-template-compilation]:
-  https://github.com/emberjs/babel-plugin-ember-template-compilation
+[ember-learn/empress-blog-ember-template]: https://github.com/ember-learn/empress-blog-ember-template
+[emberjs/babel-plugin-ember-template-compilation]: https://github.com/emberjs/babel-plugin-ember-template-compilation
 [emberjs/core-notes]: https://github.com/emberjs/core-notes
 [empress/bottled-ember]: https://github.com/empress/bottled-ember
-[freecodecamp/learn-bash-by-building-a-boilerplate]:
-  https://github.com/freeCodeCamp/learn-bash-by-building-a-boilerplate
-[kategengler/ember-cli-code-coverage]:
-  https://github.com/kategengler/ember-cli-code-coverage
+[freecodecamp/learn-bash-by-building-a-boilerplate]: https://github.com/freeCodeCamp/learn-bash-by-building-a-boilerplate
+[kategengler/ember-cli-code-coverage]: https://github.com/kategengler/ember-cli-code-coverage
 [mainmatter/compare-fixture]: https://github.com/mainmatter/compare-fixture
-[mainmatter/ember-asset-size-action]:
-  https://github.com/mainmatter/ember-asset-size-action
+[mainmatter/ember-asset-size-action]: https://github.com/mainmatter/ember-asset-size-action
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
-[mainmatter/mainmatter-website-mailer]:
-  https://github.com/mainmatter/mainmatter-website-mailer
+[mainmatter/mainmatter-website-mailer]: https://github.com/mainmatter/mainmatter-website-mailer
 [mainmatter/mocha-diff]: https://github.com/mainmatter/mocha-diff
 [mainmatter/renovate-config]: https://github.com/mainmatter/renovate-config
 [marcoow/rust_rest]: https://github.com/marcoow/rust_rest
-[oscard0m/octoherd-script-release-workflow-patch]:
-  https://github.com/oscard0m/octoherd-script-release-workflow-patch
+[oscard0m/octoherd-script-release-workflow-patch]: https://github.com/oscard0m/octoherd-script-release-workflow-patch
diff --git a/src/twios/2023-04-18.md b/src/twios/2023-04-18.md
index 01f02619df..554a5ead7f 100644
--- a/src/twios/2023-04-18.md
+++ b/src/twios/2023-04-18.md
@@ -1,117 +1,53 @@
 ## Octoherd
 
-- [octoherd/.github] [#8](https://github.com/octoherd/.github/pull/8)
-  feat(renovate-config): automerge lockFileMaintenance changes ([@oscard0m])
+- [octoherd/.github] [#8](https://github.com/octoherd/.github/pull/8) feat(renovate-config): automerge lockFileMaintenance changes ([@oscard0m])
 
 ## Ember.js
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#168](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/168) Fix
-  build ([@mansona])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#174](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/174) Update
-  remark/retext packages ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#173](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/173) Spell
-  linter ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#171](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/171) Apply
-  modifications for 4.11 guides ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#170](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/170)
-  Translate guides/release/applications/index.md ([@BlueCutOfficial])
-- [ember-learn/ember-styleguide]
-  [#458](https://github.com/ember-learn/ember-styleguide/pull/458) add
-  @ember/string to ember-try beta and canary ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#453](https://github.com/ember-learn/ember-styleguide/pull/453) fix
-  progress-bar transition aborted ([@mansona])
-- [ember-learn/guides-source]
-  [#1909](https://github.com/ember-learn/guides-source/pull/1909) update percy
-  and update to Node 14 ([@mansona])
-- [ember-learn/super-rentals-tutorial]
-  [#226](https://github.com/ember-learn/super-rentals-tutorial/pull/226) update
-  node version to 16 for ember-beta ([@mansona])
-- [emberjs/babel-plugin-ember-template-compilation]
-  [#19](https://github.com/emberjs/babel-plugin-ember-template-compilation/pull/19)
-  Replace Identifier only if key and value are different in the scope
-  ([@candunaj])
-- [emberjs/core-notes] [#494](https://github.com/emberjs/core-notes/pull/494)
-  add notes for embroider meeting 11th April ([@mansona])
-- [emberjs/core-notes] [#493](https://github.com/emberjs/core-notes/pull/493)
-  add embroider notes for 4th April ([@mansona])
-- [emberjs/core-notes] [#492](https://github.com/emberjs/core-notes/pull/492)
-  add notes for learning meeting Apr 3rd ([@mansona])
-- [emberjs/core-notes] [#491](https://github.com/emberjs/core-notes/pull/491)
-  add notes for embroider 28th March ([@mansona])
-- [emberobserver/eslint-plugin-ember-observer]
-  [#2](https://github.com/emberobserver/eslint-plugin-ember-observer/pull/2) Add
-  has-maybe-embroider rule ([@mansona])
-- [emberobserver/eslint-plugin-ember-observer]
-  [#1](https://github.com/emberobserver/eslint-plugin-ember-observer/pull/1)
-  Copy rules from eslint-plugin-ember fork ([@mansona])
-- [emberobserver/server]
-  [#123](https://github.com/emberobserver/server/pull/123) add
-  has-maybe-embroider lint ([@mansona])
-- [emberobserver/server]
-  [#122](https://github.com/emberobserver/server/pull/122) move ember-observer
-  lint rules to new plugin ([@mansona])
-- [emberobserver/server]
-  [#121](https://github.com/emberobserver/server/pull/121) Update ruby and ffi
-  gem to support M1 macs ([@mansona])
-- [mainmatter/ember-cookies]
-  [#783](https://github.com/mainmatter/ember-cookies/pull/783) chore: remove
-  .bowerrc ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#782](https://github.com/mainmatter/ember-cookies/pull/782) feat: import
-  @ember/polyfills assign conditionally ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2538](https://github.com/mainmatter/ember-simple-auth/pull/2538) feat:
-  import @ember/polyfills assign conditionally ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2537](https://github.com/mainmatter/ember-simple-auth/pull/2537)
-  chore(deps): remove ember-export-application-global ([@BobrImperator])
-- [nickschot/ember-gesture-modifiers]
-  [#432](https://github.com/nickschot/ember-gesture-modifiers/pull/432) Add
-  ember v5 support ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#647](https://github.com/nickschot/ember-mobile-menu/pull/647) Allow
-  ember-beta and ember-canary to fail ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#633](https://github.com/nickschot/ember-mobile-menu/pull/633) Set correct
-  supported ember-source as peerDependency ([@nickschot])
-- [qonto/ember-lottie] [#63](https://github.com/qonto/ember-lottie/pull/63)
-  Convert to v2 addon format ([@nickschot])
+- [DazzlingFugu/ember-fr-guides-source] [#168](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/168) Fix build ([@mansona])
+- [DazzlingFugu/ember-fr-guides-source] [#174](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/174) Update remark/retext packages ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#173](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/173) Spell linter ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#171](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/171) Apply modifications for 4.11 guides ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#170](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/170) Translate guides/release/applications/index.md ([@BlueCutOfficial])
+- [ember-learn/ember-styleguide] [#458](https://github.com/ember-learn/ember-styleguide/pull/458) add @ember/string to ember-try beta and canary ([@mansona])
+- [ember-learn/ember-styleguide] [#453](https://github.com/ember-learn/ember-styleguide/pull/453) fix progress-bar transition aborted ([@mansona])
+- [ember-learn/guides-source] [#1909](https://github.com/ember-learn/guides-source/pull/1909) update percy and update to Node 14 ([@mansona])
+- [ember-learn/super-rentals-tutorial] [#226](https://github.com/ember-learn/super-rentals-tutorial/pull/226) update node version to 16 for ember-beta ([@mansona])
+- [emberjs/babel-plugin-ember-template-compilation] [#19](https://github.com/emberjs/babel-plugin-ember-template-compilation/pull/19) Replace Identifier only if key and value are different in the scope ([@candunaj])
+- [emberjs/core-notes] [#494](https://github.com/emberjs/core-notes/pull/494) add notes for embroider meeting 11th April ([@mansona])
+- [emberjs/core-notes] [#493](https://github.com/emberjs/core-notes/pull/493) add embroider notes for 4th April ([@mansona])
+- [emberjs/core-notes] [#492](https://github.com/emberjs/core-notes/pull/492) add notes for learning meeting Apr 3rd ([@mansona])
+- [emberjs/core-notes] [#491](https://github.com/emberjs/core-notes/pull/491) add notes for embroider 28th March ([@mansona])
+- [emberobserver/eslint-plugin-ember-observer] [#2](https://github.com/emberobserver/eslint-plugin-ember-observer/pull/2) Add has-maybe-embroider rule ([@mansona])
+- [emberobserver/eslint-plugin-ember-observer] [#1](https://github.com/emberobserver/eslint-plugin-ember-observer/pull/1) Copy rules from eslint-plugin-ember fork ([@mansona])
+- [emberobserver/server] [#123](https://github.com/emberobserver/server/pull/123) add has-maybe-embroider lint ([@mansona])
+- [emberobserver/server] [#122](https://github.com/emberobserver/server/pull/122) move ember-observer lint rules to new plugin ([@mansona])
+- [emberobserver/server] [#121](https://github.com/emberobserver/server/pull/121) Update ruby and ffi gem to support M1 macs ([@mansona])
+- [mainmatter/ember-cookies] [#783](https://github.com/mainmatter/ember-cookies/pull/783) chore: remove .bowerrc ([@BobrImperator])
+- [mainmatter/ember-cookies] [#782](https://github.com/mainmatter/ember-cookies/pull/782) feat: import @ember/polyfills assign conditionally ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2538](https://github.com/mainmatter/ember-simple-auth/pull/2538) feat: import @ember/polyfills assign conditionally ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2537](https://github.com/mainmatter/ember-simple-auth/pull/2537) chore(deps): remove ember-export-application-global ([@BobrImperator])
+- [nickschot/ember-gesture-modifiers] [#432](https://github.com/nickschot/ember-gesture-modifiers/pull/432) Add ember v5 support ([@nickschot])
+- [nickschot/ember-mobile-menu] [#647](https://github.com/nickschot/ember-mobile-menu/pull/647) Allow ember-beta and ember-canary to fail ([@nickschot])
+- [nickschot/ember-mobile-menu] [#633](https://github.com/nickschot/ember-mobile-menu/pull/633) Set correct supported ember-source as peerDependency ([@nickschot])
+- [qonto/ember-lottie] [#63](https://github.com/qonto/ember-lottie/pull/63) Convert to v2 addon format ([@nickschot])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1393](https://github.com/embroider-build/embroider/pull/1393) continue
-  deploying unstable packages even with an error ([@mansona])
-- [embroider-build/embroider]
-  [#1389](https://github.com/embroider-build/embroider/pull/1389) bump unstable
-  versions by at least a patch ([@mansona])
+- [embroider-build/embroider] [#1393](https://github.com/embroider-build/embroider/pull/1393) continue deploying unstable packages even with an error ([@mansona])
+- [embroider-build/embroider] [#1389](https://github.com/embroider-build/embroider/pull/1389) bump unstable versions by at least a patch ([@mansona])
 
 ## JavaScript
 
-- [mainmatter/compare-fixture]
-  [#4](https://github.com/mainmatter/compare-fixture/pull/4) make it possible to
-  import this library ([@mansona])
-- [mansona/layer-gen] [#1](https://github.com/mansona/layer-gen/pull/1) Copy
-  basic implementation from ember-cli ([@mansona])
+- [mainmatter/compare-fixture] [#4](https://github.com/mainmatter/compare-fixture/pull/4) make it possible to import this library ([@mansona])
+- [mansona/layer-gen] [#1](https://github.com/mansona/layer-gen/pull/1) Copy basic implementation from ember-cli ([@mansona])
 
 ## Octokit
 
-- [octokit/app.js] [#405](https://github.com/octokit/app.js/pull/405) WIP
-  build(deps): upgrade @octokit/webhooks to 10.7.1 (next) ([@oscard0m])
-- [octokit/graphql-action]
-  [#207](https://github.com/octokit/graphql-action/pull/207) migrate zeit ncc to
-  vercel ncc ([@oscard0m])
-- [octokit/webhooks.js] [#833](https://github.com/octokit/webhooks.js/pull/833)
-  revert(typescript): new `pull_request.milestoned` and
-  `pull_request.demilestoned` events (#830)" ([@oscard0m])
-- [octokit/webhooks.js] [#829](https://github.com/octokit/webhooks.js/pull/829)
-  refactor(esbuild): wrap all the logic inside a plugin ([@oscard0m])
+- [octokit/app.js] [#405](https://github.com/octokit/app.js/pull/405) WIP build(deps): upgrade @octokit/webhooks to 10.7.1 (next) ([@oscard0m])
+- [octokit/graphql-action] [#207](https://github.com/octokit/graphql-action/pull/207) migrate zeit ncc to vercel ncc ([@oscard0m])
+- [octokit/webhooks.js] [#833](https://github.com/octokit/webhooks.js/pull/833) revert(typescript): new `pull_request.milestoned` and `pull_request.demilestoned` events (#830)" ([@oscard0m])
+- [octokit/webhooks.js] [#829](https://github.com/octokit/webhooks.js/pull/829) refactor(esbuild): wrap all the logic inside a plugin ([@oscard0m])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
@@ -119,25 +55,20 @@
 [@mansona]: https://github.com/mansona
 [@nickschot]: https://github.com/nickschot
 [@oscard0m]: https://github.com/oscard0m
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
-[ember-learn/super-rentals-tutorial]:
-  https://github.com/ember-learn/super-rentals-tutorial
-[emberjs/babel-plugin-ember-template-compilation]:
-  https://github.com/emberjs/babel-plugin-ember-template-compilation
+[ember-learn/super-rentals-tutorial]: https://github.com/ember-learn/super-rentals-tutorial
+[emberjs/babel-plugin-ember-template-compilation]: https://github.com/emberjs/babel-plugin-ember-template-compilation
 [emberjs/core-notes]: https://github.com/emberjs/core-notes
-[emberobserver/eslint-plugin-ember-observer]:
-  https://github.com/emberobserver/eslint-plugin-ember-observer
+[emberobserver/eslint-plugin-ember-observer]: https://github.com/emberobserver/eslint-plugin-ember-observer
 [emberobserver/server]: https://github.com/emberobserver/server
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [mainmatter/compare-fixture]: https://github.com/mainmatter/compare-fixture
 [mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
 [mansona/layer-gen]: https://github.com/mansona/layer-gen
-[nickschot/ember-gesture-modifiers]:
-  https://github.com/nickschot/ember-gesture-modifiers
+[nickschot/ember-gesture-modifiers]: https://github.com/nickschot/ember-gesture-modifiers
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
 [octoherd/.github]: https://github.com/octoherd/.github
 [octokit/app.js]: https://github.com/octokit/app.js
diff --git a/src/twios/2023-05-05.md b/src/twios/2023-05-05.md
index caf0efa398..c88399d675 100644
--- a/src/twios/2023-05-05.md
+++ b/src/twios/2023-05-05.md
@@ -1,103 +1,50 @@
 ## Ember.js
 
-- [BlueCutOfficial/ember-is-component]
-  [#2](https://github.com/BlueCutOfficial/ember-is-component/pull/2) build:
-  release version 1.0.0 ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#189](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/189) Footer
-  customization ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#188](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/188) Fix a
-  typo in guides/index.md ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#187](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/187)
-  Configure pencil ([@BlueCutOfficial])
-- [DazzlingFugu/ember-reading-time]
-  [#118](https://github.com/DazzlingFugu/ember-reading-time/pull/118) Release
-  version 3.0.0 ([@BlueCutOfficial])
-- [DazzlingFugu/ember-slugify]
-  [#278](https://github.com/DazzlingFugu/ember-slugify/pull/278) Release version
-  5.0.0 ([@BlueCutOfficial])
-- [DazzlingFugu/guidemaker-ember-locale-template]
-  [#2](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/2)
-  Footer customization ([@BlueCutOfficial])
-- [DockYard/ember-in-viewport]
-  [#323](https://github.com/DockYard/ember-in-viewport/pull/323) Upgrade
-  ember-in-viewport to V2 addon ([@candunaj])
-- [ember-fastboot/ember-cli-fastboot]
-  [#918](https://github.com/ember-fastboot/ember-cli-fastboot/pull/918) add
-  fail-fast: false to all CI sections ([@mansona])
-- [ember-fastboot/ember-cli-fastboot]
-  [#917](https://github.com/ember-fastboot/ember-cli-fastboot/pull/917) move to
-  pnpm ([@mansona])
-- [ember-fastboot/ember-cli-fastboot]
-  [#915](https://github.com/ember-fastboot/ember-cli-fastboot/pull/915) Update
-  ember to 3.28 with ember-cli-update ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#7](https://github.com/ember-learn/ember-api-docs-data/pull/7) Add a CI
-  workflow and fix files ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#6](https://github.com/ember-learn/ember-api-docs-data/pull/6) remove upload
-  to S3 workflow ([@mansona])
-- [ember-learn/ember-website]
-  [#1025](https://github.com/ember-learn/ember-website/pull/1025) add embroider
-  team to the teams page ([@mansona])
-- [mainmatter/ember-promise-modals]
-  [#857](https://github.com/mainmatter/ember-promise-modals/pull/857) Set
-  production rootURL to / ([@zeppelin])
-- [mainmatter/ember-simple-auth]
-  [#2557](https://github.com/mainmatter/ember-simple-auth/pull/2557)
-  chore(tests): remove fastboot setup from classic-test-app ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2556](https://github.com/mainmatter/ember-simple-auth/pull/2556) chore(ci):
-  fix removed tests step from workflow ([@BobrImperator])
+- [BlueCutOfficial/ember-is-component] [#2](https://github.com/BlueCutOfficial/ember-is-component/pull/2) build: release version 1.0.0 ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#189](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/189) Footer customization ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#188](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/188) Fix a typo in guides/index.md ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#187](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/187) Configure pencil ([@BlueCutOfficial])
+- [DazzlingFugu/ember-reading-time] [#118](https://github.com/DazzlingFugu/ember-reading-time/pull/118) Release version 3.0.0 ([@BlueCutOfficial])
+- [DazzlingFugu/ember-slugify] [#278](https://github.com/DazzlingFugu/ember-slugify/pull/278) Release version 5.0.0 ([@BlueCutOfficial])
+- [DazzlingFugu/guidemaker-ember-locale-template] [#2](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/2) Footer customization ([@BlueCutOfficial])
+- [DockYard/ember-in-viewport] [#323](https://github.com/DockYard/ember-in-viewport/pull/323) Upgrade ember-in-viewport to V2 addon ([@candunaj])
+- [ember-fastboot/ember-cli-fastboot] [#918](https://github.com/ember-fastboot/ember-cli-fastboot/pull/918) add fail-fast: false to all CI sections ([@mansona])
+- [ember-fastboot/ember-cli-fastboot] [#917](https://github.com/ember-fastboot/ember-cli-fastboot/pull/917) move to pnpm ([@mansona])
+- [ember-fastboot/ember-cli-fastboot] [#915](https://github.com/ember-fastboot/ember-cli-fastboot/pull/915) Update ember to 3.28 with ember-cli-update ([@mansona])
+- [ember-learn/ember-api-docs-data] [#7](https://github.com/ember-learn/ember-api-docs-data/pull/7) Add a CI workflow and fix files ([@mansona])
+- [ember-learn/ember-api-docs-data] [#6](https://github.com/ember-learn/ember-api-docs-data/pull/6) remove upload to S3 workflow ([@mansona])
+- [ember-learn/ember-website] [#1025](https://github.com/ember-learn/ember-website/pull/1025) add embroider team to the teams page ([@mansona])
+- [mainmatter/ember-promise-modals] [#857](https://github.com/mainmatter/ember-promise-modals/pull/857) Set production rootURL to / ([@zeppelin])
+- [mainmatter/ember-simple-auth] [#2557](https://github.com/mainmatter/ember-simple-auth/pull/2557) chore(tests): remove fastboot setup from classic-test-app ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2556](https://github.com/mainmatter/ember-simple-auth/pull/2556) chore(ci): fix removed tests step from workflow ([@BobrImperator])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1448](https://github.com/embroider-build/embroider/pull/1448) Add the
-  ability to customise rollup-plugin-clean's config ([@mansona])
-- [embroider-build/embroider]
-  [#1447](https://github.com/embroider-build/embroider/pull/1447) fix keepAssets
-  corrupting image files ([@mansona])
-- [embroider-build/embroider]
-  [#1446](https://github.com/embroider-build/embroider/pull/1446) Revert "Run
-  the clean plugin of addon-dev as late as possible" ([@mansona])
-- [embroider-build/embroider]
-  [#1436](https://github.com/embroider-build/embroider/pull/1436) prevent double
-  ^ when using embroider test-setup ([@mansona])
-- [embroider-build/embroider]
-  [#1415](https://github.com/embroider-build/embroider/pull/1415) fix casing in
-  docs links ([@mansona])
+- [embroider-build/embroider] [#1448](https://github.com/embroider-build/embroider/pull/1448) Add the ability to customise rollup-plugin-clean's config ([@mansona])
+- [embroider-build/embroider] [#1447](https://github.com/embroider-build/embroider/pull/1447) fix keepAssets corrupting image files ([@mansona])
+- [embroider-build/embroider] [#1446](https://github.com/embroider-build/embroider/pull/1446) Revert "Run the clean plugin of addon-dev as late as possible" ([@mansona])
+- [embroider-build/embroider] [#1436](https://github.com/embroider-build/embroider/pull/1436) prevent double ^ when using embroider test-setup ([@mansona])
+- [embroider-build/embroider] [#1415](https://github.com/embroider-build/embroider/pull/1415) fix casing in docs links ([@mansona])
 
 ## JavaScript
 
-- [timdp/rollup-timer] [#39](https://github.com/timdp/rollup-timer/pull/39) The
-  rollup plugin hook can be specified as an object instead of a function
-  ([@candunaj])
+- [timdp/rollup-timer] [#39](https://github.com/timdp/rollup-timer/pull/39) The rollup plugin hook can be specified as an object instead of a function ([@candunaj])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
 [@candunaj]: https://github.com/candunaj
 [@mansona]: https://github.com/mansona
 [@zeppelin]: https://github.com/zeppelin
-[bluecutofficial/ember-is-component]:
-  https://github.com/BlueCutOfficial/ember-is-component
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
-[dazzlingfugu/ember-reading-time]:
-  https://github.com/DazzlingFugu/ember-reading-time
+[bluecutofficial/ember-is-component]: https://github.com/BlueCutOfficial/ember-is-component
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[dazzlingfugu/ember-reading-time]: https://github.com/DazzlingFugu/ember-reading-time
 [dazzlingfugu/ember-slugify]: https://github.com/DazzlingFugu/ember-slugify
-[dazzlingfugu/guidemaker-ember-locale-template]:
-  https://github.com/DazzlingFugu/guidemaker-ember-locale-template
+[dazzlingfugu/guidemaker-ember-locale-template]: https://github.com/DazzlingFugu/guidemaker-ember-locale-template
 [dockyard/ember-in-viewport]: https://github.com/DockYard/ember-in-viewport
-[ember-fastboot/ember-cli-fastboot]:
-  https://github.com/ember-fastboot/ember-cli-fastboot
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
+[ember-fastboot/ember-cli-fastboot]: https://github.com/ember-fastboot/ember-cli-fastboot
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
 [timdp/rollup-timer]: https://github.com/timdp/rollup-timer
diff --git a/src/twios/2023-05-09.md b/src/twios/2023-05-09.md
index 3748e22ea7..cfdf5ee007 100644
--- a/src/twios/2023-05-09.md
+++ b/src/twios/2023-05-09.md
@@ -1,135 +1,55 @@
 ## Ember.js
 
-- [DazzlingFugu/ember-cli-embedded]
-  [#257](https://github.com/DazzlingFugu/ember-cli-embedded/pull/257) BREAKING
-  Build/ Drop support for Ember 3.20 and 3.24 ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#184](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/184) Lint
-  forgotten files ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#183](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/183)
-  Translate/ guides/release/getting-started/working-with-html-css-js
-  ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#178](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/178) Share
-  pre-commit hook warning about missing file to lint ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#176](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/176)
-  Translate guides/release/getting-started/index.md ([@BlueCutOfficial])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#126](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/126)
-  Update Ember using ember-cli-update ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#123](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/123)
-  Update embroider dependencies ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#122](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/122)
-  breaking: drop support for node 12 ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#121](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/121)
-  remove ember-cli-sass from dummy app ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#861](https://github.com/ember-learn/ember-api-docs/pull/861) skip tests that
-  are broken because of invalid data in production ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#860](https://github.com/ember-learn/ember-api-docs/pull/860) update to 3.28
-  with ember-cli-update ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#5](https://github.com/ember-learn/ember-api-docs-data/pull/5) Fix files
-  ([@mansona])
-- [ember-learn/ember-help-wanted-server]
-  [#53](https://github.com/ember-learn/ember-help-wanted-server/pull/53) swap to
-  npm and update node ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#138](https://github.com/ember-learn/guidemaker-ember-template/pull/138) move
-  ember-beta to allow-to-fail group ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#133](https://github.com/ember-learn/guidemaker-ember-template/pull/133)
-  Update Ember ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#132](https://github.com/ember-learn/guidemaker-ember-template/pull/132)
-  Update styleguide ([@mansona])
-- [ember-learn/guides-source]
-  [#1914](https://github.com/ember-learn/guides-source/pull/1914) update to
-  v3.28 with ember-cli-update ([@mansona])
-- [ember-learn/guides-source]
-  [#1913](https://github.com/ember-learn/guides-source/pull/1913) Update
-  working-with-html-css-and-javascript.md ([@BlueCutOfficial])
-- [ember-learn/upgrade-guide]
-  [#116](https://github.com/ember-learn/upgrade-guide/pull/116) Update
-  Upgrade-guide to give info up to 4.12 ([@Mikek2252])
-- [embroider-build/addon-blueprint]
-  [#113](https://github.com/embroider-build/addon-blueprint/pull/113) Include
-  @babel/runtime in addon devDependencies to fix babel decorator helper
-  transpilation ([@nickschot])
-- [mainmatter/ember-cookies]
-  [#798](https://github.com/mainmatter/ember-cookies/pull/798) chore(release):
-  ember-cookies v1.0.0 ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#797](https://github.com/mainmatter/ember-cookies/pull/797) feat(breaking):
-  drop Ember v3 versions ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#796](https://github.com/mainmatter/ember-cookies/pull/796) chore(ci): don't
-  halt jobs on failure ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#795](https://github.com/mainmatter/ember-cookies/pull/795) feat(breaking):
-  replace polyfills assign with Object.assign ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#793](https://github.com/mainmatter/ember-cookies/pull/793) chore: remove
-  dead chai dependencies ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#790](https://github.com/mainmatter/ember-cookies/pull/790) chore: remove
-  ember-export-application-global ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#788](https://github.com/mainmatter/ember-cookies/pull/788) chore: add
-  @ember/string to the test-app ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#787](https://github.com/mainmatter/ember-cookies/pull/787) chore: run
-  ember-default scenario in CI ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#786](https://github.com/mainmatter/ember-cookies/pull/786) chore: add crypto
-  and node-fetch to fastbootDependencies ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#785](https://github.com/mainmatter/ember-cookies/pull/785) chore: Drop
-  node - set minimal node version to >=16 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2552](https://github.com/mainmatter/ember-simple-auth/pull/2552) chore(ci):
-  setup mainmatter/continue-on-error-comment action ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2548](https://github.com/mainmatter/ember-simple-auth/pull/2548)
-  refactor(deprecation): use findRecord instead of find ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2546](https://github.com/mainmatter/ember-simple-auth/pull/2546)
-  chore(deps): bump ember-cookies to v1.0.0 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2545](https://github.com/mainmatter/ember-simple-auth/pull/2545) chore:
-  install @ember/string in packages directly ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2544](https://github.com/mainmatter/ember-simple-auth/pull/2544)
-  feat(breaking): drop ember < v3.28 and IE11 support ([@BobrImperator])
+- [DazzlingFugu/ember-cli-embedded] [#257](https://github.com/DazzlingFugu/ember-cli-embedded/pull/257) BREAKING Build/ Drop support for Ember 3.20 and 3.24 ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#184](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/184) Lint forgotten files ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#183](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/183) Translate/ guides/release/getting-started/working-with-html-css-js ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#178](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/178) Share pre-commit hook warning about missing file to lint ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#176](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/176) Translate guides/release/getting-started/index.md ([@BlueCutOfficial])
+- [adopted-ember-addons/ember-collapsible-panel] [#126](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/126) Update Ember using ember-cli-update ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#123](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/123) Update embroider dependencies ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#122](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/122) breaking: drop support for node 12 ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#121](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/121) remove ember-cli-sass from dummy app ([@mansona])
+- [ember-learn/ember-api-docs] [#861](https://github.com/ember-learn/ember-api-docs/pull/861) skip tests that are broken because of invalid data in production ([@mansona])
+- [ember-learn/ember-api-docs] [#860](https://github.com/ember-learn/ember-api-docs/pull/860) update to 3.28 with ember-cli-update ([@mansona])
+- [ember-learn/ember-api-docs-data] [#5](https://github.com/ember-learn/ember-api-docs-data/pull/5) Fix files ([@mansona])
+- [ember-learn/ember-help-wanted-server] [#53](https://github.com/ember-learn/ember-help-wanted-server/pull/53) swap to npm and update node ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#138](https://github.com/ember-learn/guidemaker-ember-template/pull/138) move ember-beta to allow-to-fail group ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#133](https://github.com/ember-learn/guidemaker-ember-template/pull/133) Update Ember ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#132](https://github.com/ember-learn/guidemaker-ember-template/pull/132) Update styleguide ([@mansona])
+- [ember-learn/guides-source] [#1914](https://github.com/ember-learn/guides-source/pull/1914) update to v3.28 with ember-cli-update ([@mansona])
+- [ember-learn/guides-source] [#1913](https://github.com/ember-learn/guides-source/pull/1913) Update working-with-html-css-and-javascript.md ([@BlueCutOfficial])
+- [ember-learn/upgrade-guide] [#116](https://github.com/ember-learn/upgrade-guide/pull/116) Update Upgrade-guide to give info up to 4.12 ([@Mikek2252])
+- [embroider-build/addon-blueprint] [#113](https://github.com/embroider-build/addon-blueprint/pull/113) Include @babel/runtime in addon devDependencies to fix babel decorator helper transpilation ([@nickschot])
+- [mainmatter/ember-cookies] [#798](https://github.com/mainmatter/ember-cookies/pull/798) chore(release): ember-cookies v1.0.0 ([@BobrImperator])
+- [mainmatter/ember-cookies] [#797](https://github.com/mainmatter/ember-cookies/pull/797) feat(breaking): drop Ember v3 versions ([@BobrImperator])
+- [mainmatter/ember-cookies] [#796](https://github.com/mainmatter/ember-cookies/pull/796) chore(ci): don't halt jobs on failure ([@BobrImperator])
+- [mainmatter/ember-cookies] [#795](https://github.com/mainmatter/ember-cookies/pull/795) feat(breaking): replace polyfills assign with Object.assign ([@BobrImperator])
+- [mainmatter/ember-cookies] [#793](https://github.com/mainmatter/ember-cookies/pull/793) chore: remove dead chai dependencies ([@BobrImperator])
+- [mainmatter/ember-cookies] [#790](https://github.com/mainmatter/ember-cookies/pull/790) chore: remove ember-export-application-global ([@BobrImperator])
+- [mainmatter/ember-cookies] [#788](https://github.com/mainmatter/ember-cookies/pull/788) chore: add @ember/string to the test-app ([@BobrImperator])
+- [mainmatter/ember-cookies] [#787](https://github.com/mainmatter/ember-cookies/pull/787) chore: run ember-default scenario in CI ([@BobrImperator])
+- [mainmatter/ember-cookies] [#786](https://github.com/mainmatter/ember-cookies/pull/786) chore: add crypto and node-fetch to fastbootDependencies ([@BobrImperator])
+- [mainmatter/ember-cookies] [#785](https://github.com/mainmatter/ember-cookies/pull/785) chore: Drop node - set minimal node version to >=16 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2552](https://github.com/mainmatter/ember-simple-auth/pull/2552) chore(ci): setup mainmatter/continue-on-error-comment action ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2548](https://github.com/mainmatter/ember-simple-auth/pull/2548) refactor(deprecation): use findRecord instead of find ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2546](https://github.com/mainmatter/ember-simple-auth/pull/2546) chore(deps): bump ember-cookies to v1.0.0 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2545](https://github.com/mainmatter/ember-simple-auth/pull/2545) chore: install @ember/string in packages directly ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2544](https://github.com/mainmatter/ember-simple-auth/pull/2544) feat(breaking): drop ember < v3.28 and IE11 support ([@BobrImperator])
 
 ## Empress
 
-- [empress/guidemaker] [#88](https://github.com/empress/guidemaker/pull/88) Add
-  ToC for each page ([@mansona])
-- [empress/guidemaker-default-template]
-  [#39](https://github.com/empress/guidemaker-default-template/pull/39)
-  Implement "on this page" ([@mansona])
+- [empress/guidemaker] [#88](https://github.com/empress/guidemaker/pull/88) Add ToC for each page ([@mansona])
+- [empress/guidemaker-default-template] [#39](https://github.com/empress/guidemaker-default-template/pull/39) Implement "on this page" ([@mansona])
 
 ## JavaScript
 
-- [mansona/layer-gen] [#2](https://github.com/mansona/layer-gen/pull/2) Extract
-  blueprints ([@mansona])
+- [mansona/layer-gen] [#2](https://github.com/mansona/layer-gen/pull/2) Extract blueprints ([@mansona])
 
 ## Octokit
 
-- [octokit/app.js] [#418](https://github.com/octokit/app.js/pull/418)
-  fix(build): add script to fix package json from build step ([@oscard0m])
-- [octokit/app.js] [#417](https://github.com/octokit/app.js/pull/417) add script
-  to fix package json from build step ([@oscard0m])
-- [octokit/oauth-app.js]
-  [#411](https://github.com/octokit/oauth-app.js/pull/411) fix(build): add
-  script to fix package json from build step ([@oscard0m])
+- [octokit/app.js] [#418](https://github.com/octokit/app.js/pull/418) fix(build): add script to fix package json from build step ([@oscard0m])
+- [octokit/app.js] [#417](https://github.com/octokit/app.js/pull/417) add script to fix package json from build step ([@oscard0m])
+- [octokit/oauth-app.js] [#411](https://github.com/octokit/oauth-app.js/pull/411) fix(build): add script to fix package json from build step ([@oscard0m])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
@@ -137,25 +57,17 @@
 [@mansona]: https://github.com/mansona
 [@nickschot]: https://github.com/nickschot
 [@oscard0m]: https://github.com/oscard0m
-[dazzlingfugu/ember-cli-embedded]:
-  https://github.com/DazzlingFugu/ember-cli-embedded
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
-[adopted-ember-addons/ember-collapsible-panel]:
-  https://github.com/adopted-ember-addons/ember-collapsible-panel
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
+[dazzlingfugu/ember-cli-embedded]: https://github.com/DazzlingFugu/ember-cli-embedded
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[adopted-ember-addons/ember-collapsible-panel]: https://github.com/adopted-ember-addons/ember-collapsible-panel
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
-[ember-learn/ember-help-wanted-server]:
-  https://github.com/ember-learn/ember-help-wanted-server
-[ember-learn/guidemaker-ember-template]:
-  https://github.com/ember-learn/guidemaker-ember-template
+[ember-learn/ember-help-wanted-server]: https://github.com/ember-learn/ember-help-wanted-server
+[ember-learn/guidemaker-ember-template]: https://github.com/ember-learn/guidemaker-ember-template
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [ember-learn/upgrade-guide]: https://github.com/ember-learn/upgrade-guide
-[embroider-build/addon-blueprint]:
-  https://github.com/embroider-build/addon-blueprint
-[empress/guidemaker-default-template]:
-  https://github.com/empress/guidemaker-default-template
+[embroider-build/addon-blueprint]: https://github.com/embroider-build/addon-blueprint
+[empress/guidemaker-default-template]: https://github.com/empress/guidemaker-default-template
 [empress/guidemaker]: https://github.com/empress/guidemaker
 [mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
diff --git a/src/twios/2023-05-29.md b/src/twios/2023-05-29.md
index ec83c8f340..8a68799760 100644
--- a/src/twios/2023-05-29.md
+++ b/src/twios/2023-05-29.md
@@ -1,130 +1,64 @@
 ## Ember.js
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#191](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/191) feat:
-  translate guides/services/index.md ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#190](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/190) Setup
-  header ([@BlueCutOfficial])
-- [DazzlingFugu/guidemaker-ember-locale-template]
-  [#4](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/4)
-  Fix/ Header padding ([@BlueCutOfficial])
-- [DazzlingFugu/guidemaker-ember-locale-template]
-  [#3](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/3)
-  Header customization ([@BlueCutOfficial])
-- [ember-fastboot/ember-cli-fastboot]
-  [#920](https://github.com/ember-fastboot/ember-cli-fastboot/pull/920) Add
-  Linting to CI ([@mansona])
-- [ember-learn/deprecation-app]
-  [#1328](https://github.com/ember-learn/deprecation-app/pull/1328) update percy
-  ([@mansona])
-- [ember-learn/ember-website]
-  [#1034](https://github.com/ember-learn/ember-website/pull/1034) WIP Initiative
-  ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#148](https://github.com/ember-learn/guidemaker-ember-template/pull/148)
-  clean up the info-banner component ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#147](https://github.com/ember-learn/guidemaker-ember-template/pull/147)
-  clean up search dropdown-header component ([@mansona])
-- [ember-learn/guides-source]
-  [#1927](https://github.com/ember-learn/guides-source/pull/1927) 5.0 Release
-  ([@mansona])
-- [emberjs/ember.js] [#20466](https://github.com/emberjs/ember.js/pull/20466)
-  Backport "Fix cyclic module crash" to 4.8 LTS ([@mansona])
-- [mainmatter/ember-promise-modals]
-  [#859](https://github.com/mainmatter/ember-promise-modals/pull/859) Fix
-  lerna-changelog plugin name ([@zeppelin])
-- [mainmatter/ember-promise-modals]
-  [#858](https://github.com/mainmatter/ember-promise-modals/pull/858) Fix CI
-  tests for beta/canary channels ([@zeppelin])
-- [miguelcobain/ember-paper]
-  [#1246](https://github.com/miguelcobain/ember-paper/pull/1246) add
-  ember-cli-deprecation-workflow ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1245](https://github.com/miguelcobain/ember-paper/pull/1245) add
-  continue-on-error-comment ([@mansona])
-- [ember-fastboot/ember-cli-head]
-  [#107](https://github.com/ember-fastboot/ember-cli-head/pull/107) update to
-  v4.12 with ember-cli-update ([@mansona])
-- [ember-fastboot/ember-cli-head]
-  [#105](https://github.com/ember-fastboot/ember-cli-head/pull/105) update
-  ember-auto-import devDependency to v2 ([@mansona])
-- [ember-fastboot/ember-cli-head]
-  [#100](https://github.com/ember-fastboot/ember-cli-head/pull/100) unify CI
-  with the default output of ember addon ([@mansona])
-- [ember-learn/cli-guides]
-  [#287](https://github.com/ember-learn/cli-guides/pull/287) update to v3.28
-  with ember-cli-update and update to latest template ([@mansona])
+- [DazzlingFugu/ember-fr-guides-source] [#191](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/191) feat: translate guides/services/index.md ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#190](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/190) Setup header ([@BlueCutOfficial])
+- [DazzlingFugu/guidemaker-ember-locale-template] [#4](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/4) Fix/ Header padding ([@BlueCutOfficial])
+- [DazzlingFugu/guidemaker-ember-locale-template] [#3](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/3) Header customization ([@BlueCutOfficial])
+- [ember-fastboot/ember-cli-fastboot] [#920](https://github.com/ember-fastboot/ember-cli-fastboot/pull/920) Add Linting to CI ([@mansona])
+- [ember-learn/deprecation-app] [#1328](https://github.com/ember-learn/deprecation-app/pull/1328) update percy ([@mansona])
+- [ember-learn/ember-website] [#1034](https://github.com/ember-learn/ember-website/pull/1034) WIP Initiative ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#148](https://github.com/ember-learn/guidemaker-ember-template/pull/148) clean up the info-banner component ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#147](https://github.com/ember-learn/guidemaker-ember-template/pull/147) clean up search dropdown-header component ([@mansona])
+- [ember-learn/guides-source] [#1927](https://github.com/ember-learn/guides-source/pull/1927) 5.0 Release ([@mansona])
+- [emberjs/ember.js] [#20466](https://github.com/emberjs/ember.js/pull/20466) Backport "Fix cyclic module crash" to 4.8 LTS ([@mansona])
+- [mainmatter/ember-promise-modals] [#859](https://github.com/mainmatter/ember-promise-modals/pull/859) Fix lerna-changelog plugin name ([@zeppelin])
+- [mainmatter/ember-promise-modals] [#858](https://github.com/mainmatter/ember-promise-modals/pull/858) Fix CI tests for beta/canary channels ([@zeppelin])
+- [miguelcobain/ember-paper] [#1246](https://github.com/miguelcobain/ember-paper/pull/1246) add ember-cli-deprecation-workflow ([@mansona])
+- [miguelcobain/ember-paper] [#1245](https://github.com/miguelcobain/ember-paper/pull/1245) add continue-on-error-comment ([@mansona])
+- [ember-fastboot/ember-cli-head] [#107](https://github.com/ember-fastboot/ember-cli-head/pull/107) update to v4.12 with ember-cli-update ([@mansona])
+- [ember-fastboot/ember-cli-head] [#105](https://github.com/ember-fastboot/ember-cli-head/pull/105) update ember-auto-import devDependency to v2 ([@mansona])
+- [ember-fastboot/ember-cli-head] [#100](https://github.com/ember-fastboot/ember-cli-head/pull/100) unify CI with the default output of ember addon ([@mansona])
+- [ember-learn/cli-guides] [#287](https://github.com/ember-learn/cli-guides/pull/287) update to v3.28 with ember-cli-update and update to latest template ([@mansona])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1471](https://github.com/embroider-build/embroider/pull/1471) use
-  @swc/register instead of ts-node for tests ([@mansona])
-- [embroider-build/embroider]
-  [#1469](https://github.com/embroider-build/embroider/pull/1469) update
-  deprecated (and removed) blacklist config in test app ([@mansona])
-- [embroider-build/embroider]
-  [#1467](https://github.com/embroider-build/embroider/pull/1467) WIP do
-  ember-release tests on latest node version ([@mansona])
-- [embroider-build/embroider]
-  [#1453](https://github.com/embroider-build/embroider/pull/1453) WIP use ESM
-  only scenario-tester version ([@mansona])
+- [embroider-build/embroider] [#1471](https://github.com/embroider-build/embroider/pull/1471) use @swc/register instead of ts-node for tests ([@mansona])
+- [embroider-build/embroider] [#1469](https://github.com/embroider-build/embroider/pull/1469) update deprecated (and removed) blacklist config in test app ([@mansona])
+- [embroider-build/embroider] [#1467](https://github.com/embroider-build/embroider/pull/1467) WIP do ember-release tests on latest node version ([@mansona])
+- [embroider-build/embroider] [#1453](https://github.com/embroider-build/embroider/pull/1453) WIP use ESM only scenario-tester version ([@mansona])
 
 ## Empress
 
-- [empress/guidemaker] [#91](https://github.com/empress/guidemaker/pull/91)
-  update to v4.4 with ember-cli-update ([@mansona])
-- [empress/guidemaker] [#90](https://github.com/empress/guidemaker/pull/90)
-  Refactor guidemaker service to accept any config field ([@BlueCutOfficial])
-- [empress/guidemaker-default-template]
-  [#46](https://github.com/empress/guidemaker-default-template/pull/46) stop
-  embroider tests being "allowed to fail" ([@mansona])
-- [empress/guidemaker-default-template]
-  [#45](https://github.com/empress/guidemaker-default-template/pull/45) fix
-  ember-source peer ([@mansona])
-- [empress/guidemaker-default-template]
-  [#44](https://github.com/empress/guidemaker-default-template/pull/44)
-  breaking: drop support for node 14 ([@mansona])
-- [empress/guidemaker-default-template]
-  [#43](https://github.com/empress/guidemaker-default-template/pull/43) update
-  to v4.12 with ember-cli-update ([@mansona])
-- [empress/guidemaker-default-template]
-  [#42](https://github.com/empress/guidemaker-default-template/pull/42) update
-  ember-collapsible-panel ([@mansona])
+- [empress/guidemaker] [#91](https://github.com/empress/guidemaker/pull/91) update to v4.4 with ember-cli-update ([@mansona])
+- [empress/guidemaker] [#90](https://github.com/empress/guidemaker/pull/90) Refactor guidemaker service to accept any config field ([@BlueCutOfficial])
+- [empress/guidemaker-default-template] [#46](https://github.com/empress/guidemaker-default-template/pull/46) stop embroider tests being "allowed to fail" ([@mansona])
+- [empress/guidemaker-default-template] [#45](https://github.com/empress/guidemaker-default-template/pull/45) fix ember-source peer ([@mansona])
+- [empress/guidemaker-default-template] [#44](https://github.com/empress/guidemaker-default-template/pull/44) breaking: drop support for node 14 ([@mansona])
+- [empress/guidemaker-default-template] [#43](https://github.com/empress/guidemaker-default-template/pull/43) update to v4.12 with ember-cli-update ([@mansona])
+- [empress/guidemaker-default-template] [#42](https://github.com/empress/guidemaker-default-template/pull/42) update ember-collapsible-panel ([@mansona])
 
 ## Octokit
 
-- [octokit/openapi] [#365](https://github.com/octokit/openapi/pull/365)
-  refactor(scripts): migrate scripts to ESM ([@oscard0m])
-- [octokit/openapi] [#364](https://github.com/octokit/openapi/pull/364)
-  feat(git-lfs): use Git LFS for /cache and /generated folders ([@oscard0m])
+- [octokit/openapi] [#365](https://github.com/octokit/openapi/pull/365) refactor(scripts): migrate scripts to ESM ([@oscard0m])
+- [octokit/openapi] [#364](https://github.com/octokit/openapi/pull/364) feat(git-lfs): use Git LFS for /cache and /generated folders ([@oscard0m])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@oscard0m]: https://github.com/oscard0m
 [@zeppelin]: https://github.com/zeppelin
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
-[dazzlingfugu/guidemaker-ember-locale-template]:
-  https://github.com/DazzlingFugu/guidemaker-ember-locale-template
-[ember-fastboot/ember-cli-fastboot]:
-  https://github.com/ember-fastboot/ember-cli-fastboot
-[ember-fastboot/ember-cli-head]:
-  https://github.com/ember-fastboot/ember-cli-head
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[dazzlingfugu/guidemaker-ember-locale-template]: https://github.com/DazzlingFugu/guidemaker-ember-locale-template
+[ember-fastboot/ember-cli-fastboot]: https://github.com/ember-fastboot/ember-cli-fastboot
+[ember-fastboot/ember-cli-head]: https://github.com/ember-fastboot/ember-cli-head
 [ember-learn/cli-guides]: https://github.com/ember-learn/cli-guides
 [ember-learn/deprecation-app]: https://github.com/ember-learn/deprecation-app
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
-[ember-learn/guidemaker-ember-template]:
-  https://github.com/ember-learn/guidemaker-ember-template
+[ember-learn/guidemaker-ember-template]: https://github.com/ember-learn/guidemaker-ember-template
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [emberjs/ember.js]: https://github.com/emberjs/ember.js
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[empress/guidemaker-default-template]:
-  https://github.com/empress/guidemaker-default-template
+[empress/guidemaker-default-template]: https://github.com/empress/guidemaker-default-template
 [empress/guidemaker]: https://github.com/empress/guidemaker
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [miguelcobain/ember-paper]: https://github.com/miguelcobain/ember-paper
 [octokit/openapi]: https://github.com/octokit/openapi
diff --git a/src/twios/2023-06-16.md b/src/twios/2023-06-16.md
index 478428c1c1..a3ddb00a1a 100644
--- a/src/twios/2023-06-16.md
+++ b/src/twios/2023-06-16.md
@@ -1,289 +1,133 @@
 ## Svelte
 
-- [sveltejs/v2.svelte.dev]
-  [#452](https://github.com/sveltejs/v2.svelte.dev/pull/452) docs: fix link to
-  /sites folder in svelte repo ([@oscard0m])
+- [sveltejs/v2.svelte.dev] [#452](https://github.com/sveltejs/v2.svelte.dev/pull/452) docs: fix link to /sites folder in svelte repo ([@oscard0m])
 
 ## Ember.js
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#193](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/193)
-  Translate guides/accessibility/page-template-considerations.md
-  ([@BlueCutOfficial])
-- [babel/ember-cli-babel]
-  [#489](https://github.com/babel/ember-cli-babel/pull/489) remove proposal
-  plugins and replace with their corresponding transform ([@mansona])
-- [ember-cli/ember-try-config]
-  [#191](https://github.com/ember-cli/ember-try-config/pull/191) add default
-  overrides for generated configs ([@mansona])
-- [ember-learn/cli-guides]
-  [#293](https://github.com/ember-learn/cli-guides/pull/293) update
-  guidemaker-ember-template ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#868](https://github.com/ember-learn/ember-api-docs/pull/868) WIP: tracking
-  branch for the website redesign RFC ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#8](https://github.com/ember-learn/ember-api-docs-data/pull/8) Sync data from
-  S3 ([@mansona])
-- [ember-learn/ember-website]
-  [#1038](https://github.com/ember-learn/ember-website/pull/1038) Remove mirage
-  ([@mansona])
-- [ember-learn/ember-website]
-  [#1037](https://github.com/ember-learn/ember-website/pull/1037) Sponsor
-  updates ([@mansona])
-- [ember-learn/ember-website]
-  [#1035](https://github.com/ember-learn/ember-website/pull/1035) Release
-  versions ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#160](https://github.com/ember-learn/guidemaker-ember-template/pull/160)
-  update ember-showdown-prism ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#155](https://github.com/ember-learn/guidemaker-ember-template/pull/155)
-  Revert "add prefixHeaderId to on-this-page links" ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#154](https://github.com/ember-learn/guidemaker-ember-template/pull/154) add
-  prefixHeaderId to on-this-page links ([@mansona])
-- [ember-learn/guides-source]
-  [#1941](https://github.com/ember-learn/guides-source/pull/1941) update
-  guidemaker-ember-template ([@mansona])
-- [ember-learn/guides-source]
-  [#1935](https://github.com/ember-learn/guides-source/pull/1935) Update
-  prebuilt guides ([@mansona])
-- [ember-learn/guides-source]
-  [#1933](https://github.com/ember-learn/guides-source/pull/1933) Add more
-  versions to prebuilt ([@mansona])
-- [ember-learn/guides-source]
-  [#1932](https://github.com/ember-learn/guides-source/pull/1932) Update
-  prebuilt versions ([@mansona])
-- [ember-learn/guides-source]
-  [#1931](https://github.com/ember-learn/guides-source/pull/1931) update
-  pre-built guides ([@mansona])
-- [ember-learn/guides-source]
-  [#1929](https://github.com/ember-learn/guides-source/pull/1929) update minor
-  details in the search index deployment script ([@mansona])
-- [ember-learn/tool-new-release]
-  [#42](https://github.com/ember-learn/tool-new-release/pull/42) add m1 support
-  to release CI ([@mansona])
-- [ember-learn/upgrade-guide]
-  [#118](https://github.com/ember-learn/upgrade-guide/pull/118) add version 5.0
-  ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#157](https://github.com/embroider-build/addon-blueprint/pull/157) show test
-  logs in CI ([@mansona])
-- [mainmatter/ember-simple-auth]
-  [#2604](https://github.com/mainmatter/ember-simple-auth/pull/2604) V2 addon
-  ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2600](https://github.com/mainmatter/ember-simple-auth/pull/2600)
-  chore(test-app): enable embroider build ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2599](https://github.com/mainmatter/ember-simple-auth/pull/2599)
-  refactor(test-app): use LinkTo and this. ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2595](https://github.com/mainmatter/ember-simple-auth/pull/2595) feat:
-  Remove Torii from ember 5 scenarios ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2591](https://github.com/mainmatter/ember-simple-auth/pull/2591) [Chore] use
-  4.12.1 ember-data for ember-lts-4.12 scenario ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2580](https://github.com/mainmatter/ember-simple-auth/pull/2580) chore:
-  specify ember-qunit, @ember/test-helpers for ember-try scenario
-  ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2578](https://github.com/mainmatter/ember-simple-auth/pull/2578) Configure
-  Renovate to update testing and fastboot stacks in the same PR
-  ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2576](https://github.com/mainmatter/ember-simple-auth/pull/2576) chore: add
-  ember-lts-4.12 scenario ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2575](https://github.com/mainmatter/ember-simple-auth/pull/2575) chore: fix
-  fastboot testing environment for ember-data >= 4.12 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2574](https://github.com/mainmatter/ember-simple-auth/pull/2574)
-  chore(deps): bump fastboot dependencies ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2573](https://github.com/mainmatter/ember-simple-auth/pull/2573)
-  chore(deps): bump ember-try to 3.0.0 beta ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2572](https://github.com/mainmatter/ember-simple-auth/pull/2572)
-  chore(deps): bump ember-cli-dependency-checker to 3.3.1 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2571](https://github.com/mainmatter/ember-simple-auth/pull/2571)
-  chore(deps): bump ember-fetch to 8.1.2 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2570](https://github.com/mainmatter/ember-simple-auth/pull/2570) Move to
-  pnpm ([@BobrImperator])
+- [DazzlingFugu/ember-fr-guides-source] [#193](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/193) Translate guides/accessibility/page-template-considerations.md ([@BlueCutOfficial])
+- [babel/ember-cli-babel] [#489](https://github.com/babel/ember-cli-babel/pull/489) remove proposal plugins and replace with their corresponding transform ([@mansona])
+- [ember-cli/ember-try-config] [#191](https://github.com/ember-cli/ember-try-config/pull/191) add default overrides for generated configs ([@mansona])
+- [ember-learn/cli-guides] [#293](https://github.com/ember-learn/cli-guides/pull/293) update guidemaker-ember-template ([@mansona])
+- [ember-learn/ember-api-docs] [#868](https://github.com/ember-learn/ember-api-docs/pull/868) WIP: tracking branch for the website redesign RFC ([@mansona])
+- [ember-learn/ember-api-docs-data] [#8](https://github.com/ember-learn/ember-api-docs-data/pull/8) Sync data from S3 ([@mansona])
+- [ember-learn/ember-website] [#1038](https://github.com/ember-learn/ember-website/pull/1038) Remove mirage ([@mansona])
+- [ember-learn/ember-website] [#1037](https://github.com/ember-learn/ember-website/pull/1037) Sponsor updates ([@mansona])
+- [ember-learn/ember-website] [#1035](https://github.com/ember-learn/ember-website/pull/1035) Release versions ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#160](https://github.com/ember-learn/guidemaker-ember-template/pull/160) update ember-showdown-prism ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#155](https://github.com/ember-learn/guidemaker-ember-template/pull/155) Revert "add prefixHeaderId to on-this-page links" ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#154](https://github.com/ember-learn/guidemaker-ember-template/pull/154) add prefixHeaderId to on-this-page links ([@mansona])
+- [ember-learn/guides-source] [#1941](https://github.com/ember-learn/guides-source/pull/1941) update guidemaker-ember-template ([@mansona])
+- [ember-learn/guides-source] [#1935](https://github.com/ember-learn/guides-source/pull/1935) Update prebuilt guides ([@mansona])
+- [ember-learn/guides-source] [#1933](https://github.com/ember-learn/guides-source/pull/1933) Add more versions to prebuilt ([@mansona])
+- [ember-learn/guides-source] [#1932](https://github.com/ember-learn/guides-source/pull/1932) Update prebuilt versions ([@mansona])
+- [ember-learn/guides-source] [#1931](https://github.com/ember-learn/guides-source/pull/1931) update pre-built guides ([@mansona])
+- [ember-learn/guides-source] [#1929](https://github.com/ember-learn/guides-source/pull/1929) update minor details in the search index deployment script ([@mansona])
+- [ember-learn/tool-new-release] [#42](https://github.com/ember-learn/tool-new-release/pull/42) add m1 support to release CI ([@mansona])
+- [ember-learn/upgrade-guide] [#118](https://github.com/ember-learn/upgrade-guide/pull/118) add version 5.0 ([@mansona])
+- [embroider-build/addon-blueprint] [#157](https://github.com/embroider-build/addon-blueprint/pull/157) show test logs in CI ([@mansona])
+- [mainmatter/ember-simple-auth] [#2604](https://github.com/mainmatter/ember-simple-auth/pull/2604) V2 addon ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2600](https://github.com/mainmatter/ember-simple-auth/pull/2600) chore(test-app): enable embroider build ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2599](https://github.com/mainmatter/ember-simple-auth/pull/2599) refactor(test-app): use LinkTo and this. ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2595](https://github.com/mainmatter/ember-simple-auth/pull/2595) feat: Remove Torii from ember 5 scenarios ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2591](https://github.com/mainmatter/ember-simple-auth/pull/2591) [Chore] use 4.12.1 ember-data for ember-lts-4.12 scenario ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2580](https://github.com/mainmatter/ember-simple-auth/pull/2580) chore: specify ember-qunit, @ember/test-helpers for ember-try scenario ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2578](https://github.com/mainmatter/ember-simple-auth/pull/2578) Configure Renovate to update testing and fastboot stacks in the same PR ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2576](https://github.com/mainmatter/ember-simple-auth/pull/2576) chore: add ember-lts-4.12 scenario ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2575](https://github.com/mainmatter/ember-simple-auth/pull/2575) chore: fix fastboot testing environment for ember-data >= 4.12 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2574](https://github.com/mainmatter/ember-simple-auth/pull/2574) chore(deps): bump fastboot dependencies ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2573](https://github.com/mainmatter/ember-simple-auth/pull/2573) chore(deps): bump ember-try to 3.0.0 beta ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2572](https://github.com/mainmatter/ember-simple-auth/pull/2572) chore(deps): bump ember-cli-dependency-checker to 3.3.1 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2571](https://github.com/mainmatter/ember-simple-auth/pull/2571) chore(deps): bump ember-fetch to 8.1.2 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2570](https://github.com/mainmatter/ember-simple-auth/pull/2570) Move to pnpm ([@BobrImperator])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1520](https://github.com/embroider-build/embroider/pull/1520) use transform
-  babel plugins instead of proposal ([@mansona])
-- [embroider-build/embroider]
-  [#1518](https://github.com/embroider-build/embroider/pull/1518) add a basic
-  implementation of the gjs rollup plugin ([@mansona])
-- [embroider-build/embroider]
-  [#1489](https://github.com/embroider-build/embroider/pull/1489) prepare to
-  release patch of embroider/compat ([@mansona])
-- [embroider-build/embroider]
-  [#1488](https://github.com/embroider-build/embroider/pull/1488) fix
-  this.import from node_modules in v1 addons ([@mansona])
-- [embroider-build/embroider]
-  [#1479](https://github.com/embroider-build/embroider/pull/1479) ember data
-  compat adapter ([@mansona])
-- [embroider-build/embroider]
-  [#1475](https://github.com/embroider-build/embroider/pull/1475) WIP: add a
-  basic implementation for fastboot app file resolving ([@mansona])
-- [embroider-build/content-tag]
-  [#10](https://github.com/embroider-build/content-tag/pull/10) Pass a better
-  message back to JS ([@mansona])
-- [embroider-build/content-tag]
-  [#9](https://github.com/embroider-build/content-tag/pull/9) fix installation
-  instructions in README ([@mansona])
-- [embroider-build/content-tag]
-  [#8](https://github.com/embroider-build/content-tag/pull/8) Setup release on
-  CI when tag is pushed ([@mansona])
-- [embroider-build/content-tag]
-  [#7](https://github.com/embroider-build/content-tag/pull/7) Move component
-  `this` reference into first argument ([@mansona])
-- [embroider-build/content-tag]
-  [#6](https://github.com/embroider-build/content-tag/pull/6) use git
-  dependencies for swc ([@mansona])
-- [embroider-build/ember-auto-import]
-  [#587](https://github.com/embroider-build/ember-auto-import/pull/587) Feature:
-  allowAppImports ([@mansona])
+- [embroider-build/embroider] [#1520](https://github.com/embroider-build/embroider/pull/1520) use transform babel plugins instead of proposal ([@mansona])
+- [embroider-build/embroider] [#1518](https://github.com/embroider-build/embroider/pull/1518) add a basic implementation of the gjs rollup plugin ([@mansona])
+- [embroider-build/embroider] [#1489](https://github.com/embroider-build/embroider/pull/1489) prepare to release patch of embroider/compat ([@mansona])
+- [embroider-build/embroider] [#1488](https://github.com/embroider-build/embroider/pull/1488) fix this.import from node_modules in v1 addons ([@mansona])
+- [embroider-build/embroider] [#1479](https://github.com/embroider-build/embroider/pull/1479) ember data compat adapter ([@mansona])
+- [embroider-build/embroider] [#1475](https://github.com/embroider-build/embroider/pull/1475) WIP: add a basic implementation for fastboot app file resolving ([@mansona])
+- [embroider-build/content-tag] [#10](https://github.com/embroider-build/content-tag/pull/10) Pass a better message back to JS ([@mansona])
+- [embroider-build/content-tag] [#9](https://github.com/embroider-build/content-tag/pull/9) fix installation instructions in README ([@mansona])
+- [embroider-build/content-tag] [#8](https://github.com/embroider-build/content-tag/pull/8) Setup release on CI when tag is pushed ([@mansona])
+- [embroider-build/content-tag] [#7](https://github.com/embroider-build/content-tag/pull/7) Move component `this` reference into first argument ([@mansona])
+- [embroider-build/content-tag] [#6](https://github.com/embroider-build/content-tag/pull/6) use git dependencies for swc ([@mansona])
+- [embroider-build/ember-auto-import] [#587](https://github.com/embroider-build/ember-auto-import/pull/587) Feature: allowAppImports ([@mansona])
 
 ## Empress
 
-- [empress/broccoli-static-site-json]
-  [#72](https://github.com/empress/broccoli-static-site-json/pull/72) allow you
-  to pass showdownConfig for internal toc builder ([@mansona])
-- [empress/broccoli-static-site-json]
-  [#71](https://github.com/empress/broccoli-static-site-json/pull/71) don't find
-  headers in code blocks for the on-this-page ([@mansona])
-- [empress/ember-cli-showdown]
-  [#128](https://github.com/empress/ember-cli-showdown/pull/128) update to v4.12
-  with ember-cli-update ([@mansona])
-- [empress/ember-cli-showdown]
-  [#127](https://github.com/empress/ember-cli-showdown/pull/127) breaking: drop
-  support for node < 16 ([@mansona])
-- [empress/ember-cli-showdown]
-  [#126](https://github.com/empress/ember-cli-showdown/pull/126) use
-  ember-auto-import to import showdown ([@mansona])
-- [empress/ember-showdown-prism]
-  [#53](https://github.com/empress/ember-showdown-prism/pull/53) add support for
-  data-diff usage in code block ([@mansona])
-- [empress/ember-showdown-prism]
-  [#49](https://github.com/empress/ember-showdown-prism/pull/49) move
-  ember-prism to dependencies ([@mansona])
-- [empress/ember-showdown-prism]
-  [#47](https://github.com/empress/ember-showdown-prism/pull/47) update to v5.0
-  with ember-cli-update ([@mansona])
-- [empress/ember-showdown-prism]
-  [#46](https://github.com/empress/ember-showdown-prism/pull/46) breaking: drop
-  support for node < 16 ([@mansona])
-- [empress/ember-showdown-prism]
-  [#45](https://github.com/empress/ember-showdown-prism/pull/45) move showdown
-  to a peer dependency ([@mansona])
-- [empress/guidemaker] [#92](https://github.com/empress/guidemaker/pull/92) Load
-  the showdown config from environment and pass it to broccoli-static-site-json
-  ([@mansona])
-- [empress/open-slide] [#17](https://github.com/empress/open-slide/pull/17)
-  update to v5.1 with ember-cli-update ([@mansona])
-- [empress/open-slide-reveal-template]
-  [#2](https://github.com/empress/open-slide-reveal-template/pull/2) Update
-  ember and reveal.js ([@mansona])
+- [empress/broccoli-static-site-json] [#72](https://github.com/empress/broccoli-static-site-json/pull/72) allow you to pass showdownConfig for internal toc builder ([@mansona])
+- [empress/broccoli-static-site-json] [#71](https://github.com/empress/broccoli-static-site-json/pull/71) don't find headers in code blocks for the on-this-page ([@mansona])
+- [empress/ember-cli-showdown] [#128](https://github.com/empress/ember-cli-showdown/pull/128) update to v4.12 with ember-cli-update ([@mansona])
+- [empress/ember-cli-showdown] [#127](https://github.com/empress/ember-cli-showdown/pull/127) breaking: drop support for node < 16 ([@mansona])
+- [empress/ember-cli-showdown] [#126](https://github.com/empress/ember-cli-showdown/pull/126) use ember-auto-import to import showdown ([@mansona])
+- [empress/ember-showdown-prism] [#53](https://github.com/empress/ember-showdown-prism/pull/53) add support for data-diff usage in code block ([@mansona])
+- [empress/ember-showdown-prism] [#49](https://github.com/empress/ember-showdown-prism/pull/49) move ember-prism to dependencies ([@mansona])
+- [empress/ember-showdown-prism] [#47](https://github.com/empress/ember-showdown-prism/pull/47) update to v5.0 with ember-cli-update ([@mansona])
+- [empress/ember-showdown-prism] [#46](https://github.com/empress/ember-showdown-prism/pull/46) breaking: drop support for node < 16 ([@mansona])
+- [empress/ember-showdown-prism] [#45](https://github.com/empress/ember-showdown-prism/pull/45) move showdown to a peer dependency ([@mansona])
+- [empress/guidemaker] [#92](https://github.com/empress/guidemaker/pull/92) Load the showdown config from environment and pass it to broccoli-static-site-json ([@mansona])
+- [empress/open-slide] [#17](https://github.com/empress/open-slide/pull/17) update to v5.1 with ember-cli-update ([@mansona])
+- [empress/open-slide-reveal-template] [#2](https://github.com/empress/open-slide-reveal-template/pull/2) Update ember and reveal.js ([@mansona])
 
 ## JavaScript
 
-- [TelemetryDeck/JavaScriptSDK]
-  [#23](https://github.com/TelemetryDeck/JavaScriptSDK/pull/23) Standalone SDK:
-  Package for Browser and Node.js ([@pichfl])
-- [mansona/layer-gen] [#4](https://github.com/mansona/layer-gen/pull/4) Move app
-  to a monorepo ([@mansona])
-- [mansona/layer-gen] [#3](https://github.com/mansona/layer-gen/pull/3) Remove
-  Core Object ([@mansona])
-- [TelemetryDeck/WebSDK] [#3](https://github.com/TelemetryDeck/WebSDK/pull/3)
-  Create WebSDK ([@pichfl])
-- [ef4/code-equality-assertions]
-  [#1](https://github.com/ef4/code-equality-assertions/pull/1) Add support for
-  chai ([@mansona])
+- [TelemetryDeck/JavaScriptSDK] [#23](https://github.com/TelemetryDeck/JavaScriptSDK/pull/23) Standalone SDK: Package for Browser and Node.js ([@pichfl])
+- [mansona/layer-gen] [#4](https://github.com/mansona/layer-gen/pull/4) Move app to a monorepo ([@mansona])
+- [mansona/layer-gen] [#3](https://github.com/mansona/layer-gen/pull/3) Remove Core Object ([@mansona])
+- [TelemetryDeck/WebSDK] [#3](https://github.com/TelemetryDeck/WebSDK/pull/3) Create WebSDK ([@pichfl])
+- [ef4/code-equality-assertions] [#1](https://github.com/ef4/code-equality-assertions/pull/1) Add support for chai ([@mansona])
 
 ## Octokit
 
-- [octokit/action.js] [#516](https://github.com/octokit/action.js/pull/516)
-  test(refactor): use 'toEqual' instead of 'toStrictEqual' for Responses
-  ([@oscard0m])
-- [octokit/core.js] [#589](https://github.com/octokit/core.js/pull/589)
-  test(refactor): use 'toEqual' instead of 'toStrictEqual' with JSON.stringify
-  in Response assertions ([@oscard0m])
-- [octokit/core.js] [#587](https://github.com/octokit/core.js/pull/587) WIP
-  test(agent-proxy): restore test coverage with `undici` ([@oscard0m])
-- [octokit/octokit.js] [#2502](https://github.com/octokit/octokit.js/pull/2502)
-  docs(readme): add 'Fetch missing' section ([@oscard0m])
-- [octokit/octokit.js] [#2501](https://github.com/octokit/octokit.js/pull/2501)
-  docs(readme): update Proxy Servers information ([@oscard0m])
-- [octokit/request.js] [#617](https://github.com/octokit/request.js/pull/617)
-  fix(fetch-wrapper): improve error message when 'fetch' implementation is not
-  present ([@oscard0m])
-- [octokit/request.js] [#614](https://github.com/octokit/request.js/pull/614)
-  docs(readme): add example for using a custom Agent ([@oscard0m])
-- [octokit/request.js] [#609](https://github.com/octokit/request.js/pull/609)
-  docs(readme): examples use ESM ([@oscard0m])
-- [octokit/request.js] [#608](https://github.com/octokit/request.js/pull/608)
-  docs(readme): use 'user-agent' instead of 'agent' as 'header' option in
-  'Sentible defauls' section ([@oscard0m])
-- [octokit/rest.js] [#329](https://github.com/octokit/rest.js/pull/329)
-  test(refactor): use 'toEqual' instead of 'toStrictEqual' for Responses
-  ([@oscard0m])
+- [octokit/action.js] [#516](https://github.com/octokit/action.js/pull/516) test(refactor): use 'toEqual' instead of 'toStrictEqual' for Responses ([@oscard0m])
+- [octokit/core.js] [#589](https://github.com/octokit/core.js/pull/589) test(refactor): use 'toEqual' instead of 'toStrictEqual' with JSON.stringify in Response assertions ([@oscard0m])
+- [octokit/core.js] [#587](https://github.com/octokit/core.js/pull/587) WIP test(agent-proxy): restore test coverage with `undici` ([@oscard0m])
+- [octokit/octokit.js] [#2502](https://github.com/octokit/octokit.js/pull/2502) docs(readme): add 'Fetch missing' section ([@oscard0m])
+- [octokit/octokit.js] [#2501](https://github.com/octokit/octokit.js/pull/2501) docs(readme): update Proxy Servers information ([@oscard0m])
+- [octokit/request.js] [#617](https://github.com/octokit/request.js/pull/617) fix(fetch-wrapper): improve error message when 'fetch' implementation is not present ([@oscard0m])
+- [octokit/request.js] [#614](https://github.com/octokit/request.js/pull/614) docs(readme): add example for using a custom Agent ([@oscard0m])
+- [octokit/request.js] [#609](https://github.com/octokit/request.js/pull/609) docs(readme): examples use ESM ([@oscard0m])
+- [octokit/request.js] [#608](https://github.com/octokit/request.js/pull/608) docs(readme): use 'user-agent' instead of 'agent' as 'header' option in 'Sentible defauls' section ([@oscard0m])
+- [octokit/rest.js] [#329](https://github.com/octokit/rest.js/pull/329) test(refactor): use 'toEqual' instead of 'toStrictEqual' for Responses ([@oscard0m])
 
 ## Renovate
 
-- [renovatebot/renovate]
-  [#23069](https://github.com/renovatebot/renovate/pull/23069)
-  feat(manager/npm): add support for Volta's pnpm ([@oscard0m])
+- [renovatebot/renovate] [#23069](https://github.com/renovatebot/renovate/pull/23069) feat(manager/npm): add support for Volta's pnpm ([@oscard0m])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
 [@mansona]: https://github.com/mansona
 [@oscard0m]: https://github.com/oscard0m
 [@pichfl]: https://github.com/pichfl
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [telemetrydeck/javascriptsdk]: https://github.com/TelemetryDeck/JavaScriptSDK
 [telemetrydeck/websdk]: https://github.com/TelemetryDeck/WebSDK
 [babel/ember-cli-babel]: https://github.com/babel/ember-cli-babel
 [ef4/code-equality-assertions]: https://github.com/ef4/code-equality-assertions
 [ember-cli/ember-try-config]: https://github.com/ember-cli/ember-try-config
 [ember-learn/cli-guides]: https://github.com/ember-learn/cli-guides
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
-[ember-learn/guidemaker-ember-template]:
-  https://github.com/ember-learn/guidemaker-ember-template
+[ember-learn/guidemaker-ember-template]: https://github.com/ember-learn/guidemaker-ember-template
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [ember-learn/tool-new-release]: https://github.com/ember-learn/tool-new-release
 [ember-learn/upgrade-guide]: https://github.com/ember-learn/upgrade-guide
-[embroider-build/addon-blueprint]:
-  https://github.com/embroider-build/addon-blueprint
+[embroider-build/addon-blueprint]: https://github.com/embroider-build/addon-blueprint
 [embroider-build/content-tag]: https://github.com/embroider-build/content-tag
-[embroider-build/ember-auto-import]:
-  https://github.com/embroider-build/ember-auto-import
+[embroider-build/ember-auto-import]: https://github.com/embroider-build/ember-auto-import
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[empress/broccoli-static-site-json]:
-  https://github.com/empress/broccoli-static-site-json
+[empress/broccoli-static-site-json]: https://github.com/empress/broccoli-static-site-json
 [empress/ember-cli-showdown]: https://github.com/empress/ember-cli-showdown
 [empress/ember-showdown-prism]: https://github.com/empress/ember-showdown-prism
 [empress/guidemaker]: https://github.com/empress/guidemaker
-[empress/open-slide-reveal-template]:
-  https://github.com/empress/open-slide-reveal-template
+[empress/open-slide-reveal-template]: https://github.com/empress/open-slide-reveal-template
 [empress/open-slide]: https://github.com/empress/open-slide
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
 [mansona/layer-gen]: https://github.com/mansona/layer-gen
-[mansona/open-slide-mainmatter-template]:
-  https://github.com/mansona/open-slide-mainmatter-template
+[mansona/open-slide-mainmatter-template]: https://github.com/mansona/open-slide-mainmatter-template
 [octokit/action.js]: https://github.com/octokit/action.js
 [octokit/core.js]: https://github.com/octokit/core.js
 [octokit/octokit.js]: https://github.com/octokit/octokit.js
diff --git a/src/twios/2023-07-19.md b/src/twios/2023-07-19.md
index 2e4ff92e9f..4a7c79a913 100644
--- a/src/twios/2023-07-19.md
+++ b/src/twios/2023-07-19.md
@@ -1,270 +1,109 @@
 ## Svelte
 
-- [SvelteLab/SvelteLab] [#274](https://github.com/SvelteLab/SvelteLab/pull/274)
-  feat: share with open files ([@paoloricciuti])
-- [SvelteLab/SvelteLab] [#270](https://github.com/SvelteLab/SvelteLab/pull/270)
-  chore: upgrade deps, svelte 4 and others ([@paoloricciuti])
-- [SvelteLab/SvelteLab] [#269](https://github.com/SvelteLab/SvelteLab/pull/269)
-  Add search also for svelte documentation ([@paoloricciuti])
-- [SvelteLab/SvelteLab] [#268](https://github.com/SvelteLab/SvelteLab/pull/268)
-  fix: login styles, name not saving, wrap sort button ([@paoloricciuti])
-- [SvelteLab/SvelteLab] [#266](https://github.com/SvelteLab/SvelteLab/pull/266)
-  feat: Add animotion template ([@paoloricciuti])
-- [SvelteLab/SvelteLab] [#262](https://github.com/SvelteLab/SvelteLab/pull/262)
-  (feat) Make cli login work ([@paoloricciuti])
-- [paoloricciuti/sveltekit-search-params]
-  [#33](https://github.com/paoloricciuti/sveltekit-search-params/pull/33) Update
-  release pnpm ([@paoloricciuti])
-- [poppa/sveltekit-svg] [#42](https://github.com/poppa/sveltekit-svg/pull/42)
-  feat: Add `transformComponent` hook to allow for smarter components import
-  ([@paoloricciuti])
-- [pstanoev/simple-svelte-autocomplete]
-  [#212](https://github.com/pstanoev/simple-svelte-autocomplete/pull/212)
-  feat(labelonselectfunction): add 'labelOnSelectFunction' prop ([@oscard0m])
-- [sveltejs/svelte] [#9036](https://github.com/sveltejs/svelte/pull/9036) fix:
-  Add data-\* to svg attributes ([@paoloricciuti])
-- [melt-ui/melt-ui] [#370](https://github.com/melt-ui/melt-ui/pull/370) fix: tag
-  being created/updated even if not valid ([@paoloricciuti])
-- [melt-ui/melt-ui] [#324](https://github.com/melt-ui/melt-ui/pull/324) fix:
-  various bug slider ([@paoloricciuti])
-- [melt-ui/melt-ui] [#310](https://github.com/melt-ui/melt-ui/pull/310) feat:
-  store usingPreprocessor in localStorage ([@paoloricciuti])
-- [melt-ui/melt-ui] [#306](https://github.com/melt-ui/melt-ui/pull/306) chore:
-  add eslint rule to prevent imports from lib/builders ([@paoloricciuti])
-- [melt-ui/melt-ui] [#305](https://github.com/melt-ui/melt-ui/pull/305) fix:
-  Remove `@melt-ui/svelte` alias, add text transform ([@paoloricciuti])
-- [storybookjs/addon-svelte-csf]
-  [#115](https://github.com/storybookjs/addon-svelte-csf/pull/115) fix: swap
-  order of types to avoid module not found ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#274](https://github.com/SvelteLab/SvelteLab/pull/274) feat: share with open files ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#270](https://github.com/SvelteLab/SvelteLab/pull/270) chore: upgrade deps, svelte 4 and others ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#269](https://github.com/SvelteLab/SvelteLab/pull/269) Add search also for svelte documentation ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#268](https://github.com/SvelteLab/SvelteLab/pull/268) fix: login styles, name not saving, wrap sort button ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#266](https://github.com/SvelteLab/SvelteLab/pull/266) feat: Add animotion template ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#262](https://github.com/SvelteLab/SvelteLab/pull/262) (feat) Make cli login work ([@paoloricciuti])
+- [paoloricciuti/sveltekit-search-params] [#33](https://github.com/paoloricciuti/sveltekit-search-params/pull/33) Update release pnpm ([@paoloricciuti])
+- [poppa/sveltekit-svg] [#42](https://github.com/poppa/sveltekit-svg/pull/42) feat: Add `transformComponent` hook to allow for smarter components import ([@paoloricciuti])
+- [pstanoev/simple-svelte-autocomplete] [#212](https://github.com/pstanoev/simple-svelte-autocomplete/pull/212) feat(labelonselectfunction): add 'labelOnSelectFunction' prop ([@oscard0m])
+- [sveltejs/svelte] [#9036](https://github.com/sveltejs/svelte/pull/9036) fix: Add data-\* to svg attributes ([@paoloricciuti])
+- [melt-ui/melt-ui] [#370](https://github.com/melt-ui/melt-ui/pull/370) fix: tag being created/updated even if not valid ([@paoloricciuti])
+- [melt-ui/melt-ui] [#324](https://github.com/melt-ui/melt-ui/pull/324) fix: various bug slider ([@paoloricciuti])
+- [melt-ui/melt-ui] [#310](https://github.com/melt-ui/melt-ui/pull/310) feat: store usingPreprocessor in localStorage ([@paoloricciuti])
+- [melt-ui/melt-ui] [#306](https://github.com/melt-ui/melt-ui/pull/306) chore: add eslint rule to prevent imports from lib/builders ([@paoloricciuti])
+- [melt-ui/melt-ui] [#305](https://github.com/melt-ui/melt-ui/pull/305) fix: Remove `@melt-ui/svelte` alias, add text transform ([@paoloricciuti])
+- [storybookjs/addon-svelte-csf] [#115](https://github.com/storybookjs/addon-svelte-csf/pull/115) fix: swap order of types to avoid module not found ([@paoloricciuti])
 
 ## Ember.js
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#196](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/196)
-  Translate guides/tutorial/part-1/orientation.md ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#195](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/195)
-  Catchup 5.1.0 ([@BlueCutOfficial])
-- [ember-cli/ember-cli-update]
-  [#1241](https://github.com/ember-cli/ember-cli-update/pull/1241) Revert "add
-  code to support node 8" ([@mansona])
-- [ember-cli/ember-cli-update]
-  [#1240](https://github.com/ember-cli/ember-cli-update/pull/1240) Fix custom
-  blueprints ([@mansona])
-- [ember-cli/ember-try] [#961](https://github.com/ember-cli/ember-try/pull/961)
-  use --no-package-lock in npm ([@mansona])
-- [ember-cli/ember-try-config]
-  [#192](https://github.com/ember-cli/ember-try-config/pull/192) Downgrade
-  ember-cli if ember-source <= 3.28 is gonna be used with ember-cli 5+
-  ([@lolmaus])
-- [ember-learn/cli-guides]
-  [#298](https://github.com/ember-learn/cli-guides/pull/298) update
-  guidemaker-ember-template ([@mansona])
-- [ember-learn/ember-blog]
-  [#1290](https://github.com/ember-learn/ember-blog/pull/1290) Update .alexrc
-  ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#474](https://github.com/ember-learn/ember-styleguide/pull/474) Add
-  @ember/string to ember-release dependencies ([@nickschot])
-- [ember-learn/ember-styleguide]
-  [#473](https://github.com/ember-learn/ember-styleguide/pull/473) Sync menu
-  content from ember-website to styleguide ([@nickschot])
-- [ember-learn/ember-website]
-  [#1047](https://github.com/ember-learn/ember-website/pull/1047) Use
-  headerLinks directly from ember-styleguide ([@nickschot])
-- [ember-learn/ember-website]
-  [#1046](https://github.com/ember-learn/ember-website/pull/1046) Update
-  ember-styleguide to v8.4.0 ([@nickschot])
-- [ember-learn/guides-source]
-  [#1955](https://github.com/ember-learn/guides-source/pull/1955) update
-  guidemaker-ember-template ([@mansona])
-- [ember-learn/guides-source]
-  [#1952](https://github.com/ember-learn/guides-source/pull/1952) Add SPA
-  fallback ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#166](https://github.com/embroider-build/addon-blueprint/pull/166) update
-  concurrently version in top-level monorepo ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#164](https://github.com/embroider-build/addon-blueprint/pull/164) Separate
-  lint tests ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#163](https://github.com/embroider-build/addon-blueprint/pull/163) bump
-  addon-dev version ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#159](https://github.com/embroider-build/addon-blueprint/pull/159) Add GJS to
-  the default addon blueprint ([@mansona])
-- [mainmatter/ember-cookies]
-  [#842](https://github.com/mainmatter/ember-cookies/pull/842) chore(release):
-  use volta setup for release workflow ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#841](https://github.com/mainmatter/ember-cookies/pull/841) chore(ci): add
-  Mainmatter/continue-on-error action ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#835](https://github.com/mainmatter/ember-cookies/pull/835) chore(deps): use
-  common Mainmatter config for addons ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#834](https://github.com/mainmatter/ember-cookies/pull/834) Migrate to pnpm
-  ([@BobrImperator])
-- [mainmatter/ember-error-route]
-  [#431](https://github.com/mainmatter/ember-error-route/pull/431)
-  feat(breaking): drop Ember < 3.28 support ([@BobrImperator])
-- [mainmatter/ember-error-route]
-  [#430](https://github.com/mainmatter/ember-error-route/pull/430) chore(deps):
-  upgrade ember-qunit and ember-test-helpers ([@BobrImperator])
-- [mainmatter/ember-error-route]
-  [#429](https://github.com/mainmatter/ember-error-route/pull/429)
-  chore(release): use volta setup ([@BobrImperator])
-- [mainmatter/ember-error-route]
-  [#428](https://github.com/mainmatter/ember-error-route/pull/428)
-  chore(deploy): use volta setup for deploy workflow ([@BobrImperator])
-- [mainmatter/ember-error-route]
-  [#427](https://github.com/mainmatter/ember-error-route/pull/427) Setup volta,
-  make CI green again. ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2640](https://github.com/mainmatter/ember-simple-auth/pull/2640)
-  chore(deps): fix lockfile ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2637](https://github.com/mainmatter/ember-simple-auth/pull/2637)
-  chore(release): rename script to release ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2636](https://github.com/mainmatter/ember-simple-auth/pull/2636)
-  chore(deps): use common Mainmatter config for addons ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2633](https://github.com/mainmatter/ember-simple-auth/pull/2633)
-  test(embroider): allow test-app embroider-optimizied to fail (should work for
-  regular apps just fine, but not fastboot) ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2632](https://github.com/mainmatter/ember-simple-auth/pull/2632) chore(ci):
-  remove build artifact uploading ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2631](https://github.com/mainmatter/ember-simple-auth/pull/2631) chore(ci):
-  install dependencies before building ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2630](https://github.com/mainmatter/ember-simple-auth/pull/2630)
-  chore(deps): bump ember-try to 3.0.0 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2615](https://github.com/mainmatter/ember-simple-auth/pull/2615)
-  feat(ember-simple-auth): remove ember-fetch dependency ([@BobrImperator])
-- [nickschot/ember-mobile-menu]
-  [#688](https://github.com/nickschot/ember-mobile-menu/pull/688) Allow
-  ember-concurrency v3 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#687](https://github.com/nickschot/ember-mobile-menu/pull/687) Drop support
-  for node v14 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#686](https://github.com/nickschot/ember-mobile-menu/pull/686) Add LTS 4.4,
-  4.8 and 4.12 to test-matrix ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#685](https://github.com/nickschot/ember-mobile-menu/pull/685) Drop support
-  for Ember 3.24 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#682](https://github.com/nickschot/ember-mobile-menu/pull/682) Fix
-  ember-cli-sass check not working under ember-cli 5/embroider ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#681](https://github.com/nickschot/ember-mobile-menu/pull/681) Update
-  test-app to ember v5, CI node to 16 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#679](https://github.com/nickschot/ember-mobile-menu/pull/679) Update to
-  stable lerna-changelog package ([@nickschot])
-- [DockYard/ember-composable-helpers]
-  [#449](https://github.com/DockYard/ember-composable-helpers/pull/449) add
-  configFile: false to babel transform ([@mansona])
-- [shipshapecode/swach]
-  [#1736](https://github.com/shipshapecode/swach/pull/1736) Ember 5 typescript
-  fix ([@BobrImperator])
+- [DazzlingFugu/ember-fr-guides-source] [#196](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/196) Translate guides/tutorial/part-1/orientation.md ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#195](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/195) Catchup 5.1.0 ([@BlueCutOfficial])
+- [ember-cli/ember-cli-update] [#1241](https://github.com/ember-cli/ember-cli-update/pull/1241) Revert "add code to support node 8" ([@mansona])
+- [ember-cli/ember-cli-update] [#1240](https://github.com/ember-cli/ember-cli-update/pull/1240) Fix custom blueprints ([@mansona])
+- [ember-cli/ember-try] [#961](https://github.com/ember-cli/ember-try/pull/961) use --no-package-lock in npm ([@mansona])
+- [ember-cli/ember-try-config] [#192](https://github.com/ember-cli/ember-try-config/pull/192) Downgrade ember-cli if ember-source <= 3.28 is gonna be used with ember-cli 5+ ([@lolmaus])
+- [ember-learn/cli-guides] [#298](https://github.com/ember-learn/cli-guides/pull/298) update guidemaker-ember-template ([@mansona])
+- [ember-learn/ember-blog] [#1290](https://github.com/ember-learn/ember-blog/pull/1290) Update .alexrc ([@mansona])
+- [ember-learn/ember-styleguide] [#474](https://github.com/ember-learn/ember-styleguide/pull/474) Add @ember/string to ember-release dependencies ([@nickschot])
+- [ember-learn/ember-styleguide] [#473](https://github.com/ember-learn/ember-styleguide/pull/473) Sync menu content from ember-website to styleguide ([@nickschot])
+- [ember-learn/ember-website] [#1047](https://github.com/ember-learn/ember-website/pull/1047) Use headerLinks directly from ember-styleguide ([@nickschot])
+- [ember-learn/ember-website] [#1046](https://github.com/ember-learn/ember-website/pull/1046) Update ember-styleguide to v8.4.0 ([@nickschot])
+- [ember-learn/guides-source] [#1955](https://github.com/ember-learn/guides-source/pull/1955) update guidemaker-ember-template ([@mansona])
+- [ember-learn/guides-source] [#1952](https://github.com/ember-learn/guides-source/pull/1952) Add SPA fallback ([@mansona])
+- [embroider-build/addon-blueprint] [#166](https://github.com/embroider-build/addon-blueprint/pull/166) update concurrently version in top-level monorepo ([@mansona])
+- [embroider-build/addon-blueprint] [#164](https://github.com/embroider-build/addon-blueprint/pull/164) Separate lint tests ([@mansona])
+- [embroider-build/addon-blueprint] [#163](https://github.com/embroider-build/addon-blueprint/pull/163) bump addon-dev version ([@mansona])
+- [embroider-build/addon-blueprint] [#159](https://github.com/embroider-build/addon-blueprint/pull/159) Add GJS to the default addon blueprint ([@mansona])
+- [mainmatter/ember-cookies] [#842](https://github.com/mainmatter/ember-cookies/pull/842) chore(release): use volta setup for release workflow ([@BobrImperator])
+- [mainmatter/ember-cookies] [#841](https://github.com/mainmatter/ember-cookies/pull/841) chore(ci): add Mainmatter/continue-on-error action ([@BobrImperator])
+- [mainmatter/ember-cookies] [#835](https://github.com/mainmatter/ember-cookies/pull/835) chore(deps): use common Mainmatter config for addons ([@BobrImperator])
+- [mainmatter/ember-cookies] [#834](https://github.com/mainmatter/ember-cookies/pull/834) Migrate to pnpm ([@BobrImperator])
+- [mainmatter/ember-error-route] [#431](https://github.com/mainmatter/ember-error-route/pull/431) feat(breaking): drop Ember < 3.28 support ([@BobrImperator])
+- [mainmatter/ember-error-route] [#430](https://github.com/mainmatter/ember-error-route/pull/430) chore(deps): upgrade ember-qunit and ember-test-helpers ([@BobrImperator])
+- [mainmatter/ember-error-route] [#429](https://github.com/mainmatter/ember-error-route/pull/429) chore(release): use volta setup ([@BobrImperator])
+- [mainmatter/ember-error-route] [#428](https://github.com/mainmatter/ember-error-route/pull/428) chore(deploy): use volta setup for deploy workflow ([@BobrImperator])
+- [mainmatter/ember-error-route] [#427](https://github.com/mainmatter/ember-error-route/pull/427) Setup volta, make CI green again. ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2640](https://github.com/mainmatter/ember-simple-auth/pull/2640) chore(deps): fix lockfile ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2637](https://github.com/mainmatter/ember-simple-auth/pull/2637) chore(release): rename script to release ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2636](https://github.com/mainmatter/ember-simple-auth/pull/2636) chore(deps): use common Mainmatter config for addons ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2633](https://github.com/mainmatter/ember-simple-auth/pull/2633) test(embroider): allow test-app embroider-optimizied to fail (should work for regular apps just fine, but not fastboot) ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2632](https://github.com/mainmatter/ember-simple-auth/pull/2632) chore(ci): remove build artifact uploading ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2631](https://github.com/mainmatter/ember-simple-auth/pull/2631) chore(ci): install dependencies before building ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2630](https://github.com/mainmatter/ember-simple-auth/pull/2630) chore(deps): bump ember-try to 3.0.0 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2615](https://github.com/mainmatter/ember-simple-auth/pull/2615) feat(ember-simple-auth): remove ember-fetch dependency ([@BobrImperator])
+- [nickschot/ember-mobile-menu] [#688](https://github.com/nickschot/ember-mobile-menu/pull/688) Allow ember-concurrency v3 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#687](https://github.com/nickschot/ember-mobile-menu/pull/687) Drop support for node v14 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#686](https://github.com/nickschot/ember-mobile-menu/pull/686) Add LTS 4.4, 4.8 and 4.12 to test-matrix ([@nickschot])
+- [nickschot/ember-mobile-menu] [#685](https://github.com/nickschot/ember-mobile-menu/pull/685) Drop support for Ember 3.24 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#682](https://github.com/nickschot/ember-mobile-menu/pull/682) Fix ember-cli-sass check not working under ember-cli 5/embroider ([@nickschot])
+- [nickschot/ember-mobile-menu] [#681](https://github.com/nickschot/ember-mobile-menu/pull/681) Update test-app to ember v5, CI node to 16 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#679](https://github.com/nickschot/ember-mobile-menu/pull/679) Update to stable lerna-changelog package ([@nickschot])
+- [DockYard/ember-composable-helpers] [#449](https://github.com/DockYard/ember-composable-helpers/pull/449) add configFile: false to babel transform ([@mansona])
+- [shipshapecode/swach] [#1736](https://github.com/shipshapecode/swach/pull/1736) Ember 5 typescript fix ([@BobrImperator])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1580](https://github.com/embroider-build/embroider/pull/1580) stop
-  ember-composable-helpers searching for babel configs ([@mansona])
-- [embroider-build/embroider]
-  [#1577](https://github.com/embroider-build/embroider/pull/1577) Add Embroider
-  Initiative sponsors to the readme ([@mansona])
-- [embroider-build/embroider]
-  [#1568](https://github.com/embroider-build/embroider/pull/1568) plan release
-  ([@mansona])
-- [embroider-build/embroider]
-  [#1567](https://github.com/embroider-build/embroider/pull/1567) add files
-  block to the vite package ([@mansona])
-- [embroider-build/embroider]
-  [#1566](https://github.com/embroider-build/embroider/pull/1566) preparing a
-  release ([@mansona])
-- [embroider-build/embroider]
-  [#1565](https://github.com/embroider-build/embroider/pull/1565) add an
-  auto-deploy action for stable releases ([@mansona])
-- [embroider-build/embroider]
-  [#1555](https://github.com/embroider-build/embroider/pull/1555) Fix release
-  script ([@mansona])
-- [embroider-build/embroider]
-  [#1554](https://github.com/embroider-build/embroider/pull/1554) preparing a
-  release ([@mansona])
-- [embroider-build/embroider]
-  [#1552](https://github.com/embroider-build/embroider/pull/1552) add
-  --access=public to npm publish unstable ([@mansona])
-- [embroider-build/scenario-tester]
-  [#17](https://github.com/embroider-build/scenario-tester/pull/17) TypeDoc:
-  document the Scenarios class ([@lolmaus])
-- [embroider-build/scenario-tester]
-  [#16](https://github.com/embroider-build/scenario-tester/pull/16) Rename types
-  in preparation for TypeDoc ([@lolmaus])
-- [embroider-build/scenario-tester]
-  [#15](https://github.com/embroider-build/scenario-tester/pull/15) Install
-  TypeDoc ([@lolmaus])
-- [embroider-build/scenario-tester]
-  [#14](https://github.com/embroider-build/scenario-tester/pull/14) Drop support
-  for Node 14 and update TypeScript ([@lolmaus])
-- [embroider-build/scenario-tester]
-  [#13](https://github.com/embroider-build/scenario-tester/pull/13) Docs: add
-  introduction and guide to readme ([@lolmaus])
-- [embroider-build/scenario-tester]
-  [#12](https://github.com/embroider-build/scenario-tester/pull/12) Tests: use a
-  TestContext type for DRY ([@lolmaus])
+- [embroider-build/embroider] [#1580](https://github.com/embroider-build/embroider/pull/1580) stop ember-composable-helpers searching for babel configs ([@mansona])
+- [embroider-build/embroider] [#1577](https://github.com/embroider-build/embroider/pull/1577) Add Embroider Initiative sponsors to the readme ([@mansona])
+- [embroider-build/embroider] [#1568](https://github.com/embroider-build/embroider/pull/1568) plan release ([@mansona])
+- [embroider-build/embroider] [#1567](https://github.com/embroider-build/embroider/pull/1567) add files block to the vite package ([@mansona])
+- [embroider-build/embroider] [#1566](https://github.com/embroider-build/embroider/pull/1566) preparing a release ([@mansona])
+- [embroider-build/embroider] [#1565](https://github.com/embroider-build/embroider/pull/1565) add an auto-deploy action for stable releases ([@mansona])
+- [embroider-build/embroider] [#1555](https://github.com/embroider-build/embroider/pull/1555) Fix release script ([@mansona])
+- [embroider-build/embroider] [#1554](https://github.com/embroider-build/embroider/pull/1554) preparing a release ([@mansona])
+- [embroider-build/embroider] [#1552](https://github.com/embroider-build/embroider/pull/1552) add --access=public to npm publish unstable ([@mansona])
+- [embroider-build/scenario-tester] [#17](https://github.com/embroider-build/scenario-tester/pull/17) TypeDoc: document the Scenarios class ([@lolmaus])
+- [embroider-build/scenario-tester] [#16](https://github.com/embroider-build/scenario-tester/pull/16) Rename types in preparation for TypeDoc ([@lolmaus])
+- [embroider-build/scenario-tester] [#15](https://github.com/embroider-build/scenario-tester/pull/15) Install TypeDoc ([@lolmaus])
+- [embroider-build/scenario-tester] [#14](https://github.com/embroider-build/scenario-tester/pull/14) Drop support for Node 14 and update TypeScript ([@lolmaus])
+- [embroider-build/scenario-tester] [#13](https://github.com/embroider-build/scenario-tester/pull/13) Docs: add introduction and guide to readme ([@lolmaus])
+- [embroider-build/scenario-tester] [#12](https://github.com/embroider-build/scenario-tester/pull/12) Tests: use a TestContext type for DRY ([@lolmaus])
 
 ## Empress
 
-- [empress/empress-blog]
-  [#180](https://github.com/empress/empress-blog/pull/180) update all
-  dependencies ([@mansona])
-- [empress/empress-blog]
-  [#179](https://github.com/empress/empress-blog/pull/179) update to v4.12 with
-  ember-cli-update ([@mansona])
-- [empress/empress-blog]
-  [#178](https://github.com/empress/empress-blog/pull/178) Update to 4.8 with
-  ember-cli-update ([@mansona])
-- [empress/empress-blog]
-  [#177](https://github.com/empress/empress-blog/pull/177) Breaking: drop
-  support for Node < 16 ([@mansona])
-- [empress/empress-blog]
-  [#176](https://github.com/empress/empress-blog/pull/176) Update ember to v4.4
-  with ember-cli-update ([@mansona])
+- [empress/empress-blog] [#180](https://github.com/empress/empress-blog/pull/180) update all dependencies ([@mansona])
+- [empress/empress-blog] [#179](https://github.com/empress/empress-blog/pull/179) update to v4.12 with ember-cli-update ([@mansona])
+- [empress/empress-blog] [#178](https://github.com/empress/empress-blog/pull/178) Update to 4.8 with ember-cli-update ([@mansona])
+- [empress/empress-blog] [#177](https://github.com/empress/empress-blog/pull/177) Breaking: drop support for Node < 16 ([@mansona])
+- [empress/empress-blog] [#176](https://github.com/empress/empress-blog/pull/176) Update ember to v4.4 with ember-cli-update ([@mansona])
 
 ## JavaScript
 
-- [kellyselden/boilerplate-update]
-  [#404](https://github.com/kellyselden/boilerplate-update/pull/404) Breaking:
-  Drop support for node 12 and fix CI ([@mansona])
-- [stefanpenner/node-fixturify-project]
-  [#85](https://github.com/stefanpenner/node-fixturify-project/pull/85) Bump
-  Node to 16, drop deprecated methods ([@lolmaus])
-- [stefanpenner/node-fixturify-project]
-  [#83](https://github.com/stefanpenner/node-fixturify-project/pull/83)
-  Maintenance: bump Node, typescript and type-fest ([@lolmaus])
+- [kellyselden/boilerplate-update] [#404](https://github.com/kellyselden/boilerplate-update/pull/404) Breaking: Drop support for node 12 and fix CI ([@mansona])
+- [stefanpenner/node-fixturify-project] [#85](https://github.com/stefanpenner/node-fixturify-project/pull/85) Bump Node to 16, drop deprecated methods ([@lolmaus])
+- [stefanpenner/node-fixturify-project] [#83](https://github.com/stefanpenner/node-fixturify-project/pull/83) Maintenance: bump Node, typescript and type-fest ([@lolmaus])
 
 ## Internal
 
-- [mainmatter/renovate-config]
-  [#17](https://github.com/mainmatter/renovate-config/pull/17) chore(deps): move
-  renovate config from ESA ([@BobrImperator])
+- [mainmatter/renovate-config] [#17](https://github.com/mainmatter/renovate-config/pull/17) chore(deps): move renovate config from ESA ([@BobrImperator])
 
 ## typesafe-i18n
 
-- [ivanhofer/typesafe-i18n]
-  [#724](https://github.com/ivanhofer/typesafe-i18n/pull/724) docs: add example
-  for JS + JSDocs for SvelteKit ([@oscard0m])
-- [ivanhofer/typesafe-i18n-demo-sveltekit]
-  [#39](https://github.com/ivanhofer/typesafe-i18n-demo-sveltekit/pull/39) docs:
-  add disclaimer for adapting app.d.ts for full TS type inference ([@oscard0m])
+- [ivanhofer/typesafe-i18n] [#724](https://github.com/ivanhofer/typesafe-i18n/pull/724) docs: add example for JS + JSDocs for SvelteKit ([@oscard0m])
+- [ivanhofer/typesafe-i18n-demo-sveltekit] [#39](https://github.com/ivanhofer/typesafe-i18n-demo-sveltekit/pull/39) docs: add disclaimer for adapting app.d.ts for full TS type inference ([@oscard0m])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
@@ -274,10 +113,8 @@
 [@nickschot]: https://github.com/nickschot
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
-[dockyard/ember-composable-helpers]:
-  https://github.com/DockYard/ember-composable-helpers
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[dockyard/ember-composable-helpers]: https://github.com/DockYard/ember-composable-helpers
 [sveltelab/sveltelab]: https://github.com/SvelteLab/SvelteLab
 [ember-cli/ember-cli-update]: https://github.com/ember-cli/ember-cli-update
 [ember-cli/ember-try-config]: https://github.com/ember-cli/ember-try-config
@@ -287,17 +124,13 @@
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
-[embroider-build/addon-blueprint]:
-  https://github.com/embroider-build/addon-blueprint
+[embroider-build/addon-blueprint]: https://github.com/embroider-build/addon-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[embroider-build/scenario-tester]:
-  https://github.com/embroider-build/scenario-tester
+[embroider-build/scenario-tester]: https://github.com/embroider-build/scenario-tester
 [empress/empress-blog]: https://github.com/empress/empress-blog
-[ivanhofer/typesafe-i18n-demo-sveltekit]:
-  https://github.com/ivanhofer/typesafe-i18n-demo-sveltekit
+[ivanhofer/typesafe-i18n-demo-sveltekit]: https://github.com/ivanhofer/typesafe-i18n-demo-sveltekit
 [ivanhofer/typesafe-i18n]: https://github.com/ivanhofer/typesafe-i18n
-[kellyselden/boilerplate-update]:
-  https://github.com/kellyselden/boilerplate-update
+[kellyselden/boilerplate-update]: https://github.com/kellyselden/boilerplate-update
 [mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies
 [mainmatter/ember-error-route]: https://github.com/mainmatter/ember-error-route
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
@@ -307,16 +140,12 @@
 [oscard0m/kit]: https://github.com/oscard0m/kit
 [oscard0m/storybook-i18n]: https://github.com/oscard0m/storybook-i18n
 [oscard0m/test-sveltekit]: https://github.com/oscard0m/test-sveltekit
-[oscard0m/typesafe-i18n-demo-sveltekit]:
-  https://github.com/oscard0m/typesafe-i18n-demo-sveltekit
-[paoloricciuti/sveltekit-search-params]:
-  https://github.com/paoloricciuti/sveltekit-search-params
+[oscard0m/typesafe-i18n-demo-sveltekit]: https://github.com/oscard0m/typesafe-i18n-demo-sveltekit
+[paoloricciuti/sveltekit-search-params]: https://github.com/paoloricciuti/sveltekit-search-params
 [poppa/sveltekit-svg]: https://github.com/poppa/sveltekit-svg
-[pstanoev/simple-svelte-autocomplete]:
-  https://github.com/pstanoev/simple-svelte-autocomplete
+[pstanoev/simple-svelte-autocomplete]: https://github.com/pstanoev/simple-svelte-autocomplete
 [rust-lang/this-week-in-rust]: https://github.com/rust-lang/this-week-in-rust
 [shipshapecode/swach]: https://github.com/shipshapecode/swach
-[stefanpenner/node-fixturify-project]:
-  https://github.com/stefanpenner/node-fixturify-project
+[stefanpenner/node-fixturify-project]: https://github.com/stefanpenner/node-fixturify-project
 [storybookjs/addon-svelte-csf]: https://github.com/storybookjs/addon-svelte-csf
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2023-08-22.md b/src/twios/2023-08-22.md
index 757ed707e1..403c49c0ae 100644
--- a/src/twios/2023-08-22.md
+++ b/src/twios/2023-08-22.md
@@ -1,82 +1,46 @@
 ## Astro
 
-- [natemoo-re/astro-capo] [#2](https://github.com/natemoo-re/astro-capo/pull/2)
-  docs: add link to capo.js in README.md ([@oscard0m])
+- [natemoo-re/astro-capo] [#2](https://github.com/natemoo-re/astro-capo/pull/2) docs: add link to capo.js in README.md ([@oscard0m])
 
 ## Svelte
 
-- [SvelteLab/SvelteLab] [#279](https://github.com/SvelteLab/SvelteLab/pull/279)
-  feat: hack sveltekit client to show correct url over the iframe
-  ([@paoloricciuti])
-- [SvelteLab/SvelteLab] [#278](https://github.com/SvelteLab/SvelteLab/pull/278)
-  fix: ssr rewrite crashing server ([@paoloricciuti])
-- [sveltejs/kit] [#10638](https://github.com/sveltejs/kit/pull/10638) fix:
-  ensure ssrRewriteStacktrace doesn't throw ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#279](https://github.com/SvelteLab/SvelteLab/pull/279) feat: hack sveltekit client to show correct url over the iframe ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#278](https://github.com/SvelteLab/SvelteLab/pull/278) fix: ssr rewrite crashing server ([@paoloricciuti])
+- [sveltejs/kit] [#10638](https://github.com/sveltejs/kit/pull/10638) fix: ensure ssrRewriteStacktrace doesn't throw ([@paoloricciuti])
 
 ## Ember.js
 
-- [ember-cli/ember-cli-update]
-  [#1246](https://github.com/ember-cli/ember-cli-update/pull/1246) Drop support
-  for Node 14 ([@mansona])
-- [ember-cli/ember-cli-update]
-  [#1245](https://github.com/ember-cli/ember-cli-update/pull/1245) Setup
-  release-it ([@mansona])
-- [ember-cli/ember-cli-update]
-  [#1243](https://github.com/ember-cli/ember-cli-update/pull/1243) Fix CI
-  ([@mansona])
-- [ember-fastboot/ember-cli-fastboot]
-  [#926](https://github.com/ember-fastboot/ember-cli-fastboot/pull/926) make
-  sure that we lint (relevant) test-packages ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#483](https://github.com/ember-learn/ember-styleguide/pull/483) Update
-  bottled ember and remove hack for ember-cli css ([@mansona])
-- [minutebase/ember-inline-svg]
-  [#128](https://github.com/minutebase/ember-inline-svg/pull/128) update
-  @embroider/test-setup ([@mansona])
+- [ember-cli/ember-cli-update] [#1246](https://github.com/ember-cli/ember-cli-update/pull/1246) Drop support for Node 14 ([@mansona])
+- [ember-cli/ember-cli-update] [#1245](https://github.com/ember-cli/ember-cli-update/pull/1245) Setup release-it ([@mansona])
+- [ember-cli/ember-cli-update] [#1243](https://github.com/ember-cli/ember-cli-update/pull/1243) Fix CI ([@mansona])
+- [ember-fastboot/ember-cli-fastboot] [#926](https://github.com/ember-fastboot/ember-cli-fastboot/pull/926) make sure that we lint (relevant) test-packages ([@mansona])
+- [ember-learn/ember-styleguide] [#483](https://github.com/ember-learn/ember-styleguide/pull/483) Update bottled ember and remove hack for ember-cli css ([@mansona])
+- [minutebase/ember-inline-svg] [#128](https://github.com/minutebase/ember-inline-svg/pull/128) update @embroider/test-setup ([@mansona])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1594](https://github.com/embroider-build/embroider/pull/1594) remove volta
-  from CI ([@mansona])
-- [embroider-build/embroider]
-  [#1591](https://github.com/embroider-build/embroider/pull/1591) Lay groundwork
-  for esm/cjs multi build from TS ([@mansona])
-- [embroider-build/embroider]
-  [#1593](https://github.com/embroider-build/embroider/pull/1593) [draft] Add
-  strict mode to app scenarios ([@lolmaus])
-- [embroider-build/scenario-tester]
-  [#18](https://github.com/embroider-build/scenario-tester/pull/18) Move to ESM
-  ([@mansona])
+- [embroider-build/embroider] [#1594](https://github.com/embroider-build/embroider/pull/1594) remove volta from CI ([@mansona])
+- [embroider-build/embroider] [#1591](https://github.com/embroider-build/embroider/pull/1591) Lay groundwork for esm/cjs multi build from TS ([@mansona])
+- [embroider-build/embroider] [#1593](https://github.com/embroider-build/embroider/pull/1593) [draft] Add strict mode to app scenarios ([@lolmaus])
+- [embroider-build/scenario-tester] [#18](https://github.com/embroider-build/scenario-tester/pull/18) Move to ESM ([@mansona])
 
 ## Empress
 
-- [empress/bottled-ember]
-  [#21](https://github.com/empress/bottled-ember/pull/21) drop support for node
-  14 ([@mansona])
-- [empress/bottled-ember]
-  [#20](https://github.com/empress/bottled-ember/pull/20) setup release-it
-  ([@mansona])
-- [empress/bottled-ember]
-  [#19](https://github.com/empress/bottled-ember/pull/19) Fix generation when
-  inside a package that has ember-cli as a dependency ([@mansona])
+- [empress/bottled-ember] [#21](https://github.com/empress/bottled-ember/pull/21) drop support for node 14 ([@mansona])
+- [empress/bottled-ember] [#20](https://github.com/empress/bottled-ember/pull/20) setup release-it ([@mansona])
+- [empress/bottled-ember] [#19](https://github.com/empress/bottled-ember/pull/19) Fix generation when inside a package that has ember-cli as a dependency ([@mansona])
 
 ## JavaScript
 
-- [ef4/code-equality-assertions]
-  [#2](https://github.com/ef4/code-equality-assertions/pull/2) turn off type:
-  module ([@mansona])
+- [ef4/code-equality-assertions] [#2](https://github.com/ef4/code-equality-assertions/pull/2) turn off type: module ([@mansona])
 
 ## typesafe-i18n
 
-- [ivanhofer/typesafe-i18n-demo-sveltekit]
-  [#40](https://github.com/ivanhofer/typesafe-i18n-demo-sveltekit/pull/40) docs:
-  fix Warning box in README.md ([@oscard0m])
+- [ivanhofer/typesafe-i18n-demo-sveltekit] [#40](https://github.com/ivanhofer/typesafe-i18n-demo-sveltekit/pull/40) docs: fix Warning box in README.md ([@oscard0m])
 
 ## zola
 
-- [getzola/zola] [#2289](https://github.com/getzola/zola/pull/2289) docs: update
-  links to new Tera docs URL ([@oscard0m])
+- [getzola/zola] [#2289](https://github.com/getzola/zola/pull/2289) docs: update links to new Tera docs URL ([@oscard0m])
 
 [@lolmaus]: https://github.com/lolmaus
 [@mansona]: https://github.com/mansona
@@ -85,16 +49,13 @@
 [sveltelab/sveltelab]: https://github.com/SvelteLab/SvelteLab
 [ef4/code-equality-assertions]: https://github.com/ef4/code-equality-assertions
 [ember-cli/ember-cli-update]: https://github.com/ember-cli/ember-cli-update
-[ember-fastboot/ember-cli-fastboot]:
-  https://github.com/ember-fastboot/ember-cli-fastboot
+[ember-fastboot/ember-cli-fastboot]: https://github.com/ember-fastboot/ember-cli-fastboot
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[embroider-build/scenario-tester]:
-  https://github.com/embroider-build/scenario-tester
+[embroider-build/scenario-tester]: https://github.com/embroider-build/scenario-tester
 [empress/bottled-ember]: https://github.com/empress/bottled-ember
 [getzola/zola]: https://github.com/getzola/zola
-[ivanhofer/typesafe-i18n-demo-sveltekit]:
-  https://github.com/ivanhofer/typesafe-i18n-demo-sveltekit
+[ivanhofer/typesafe-i18n-demo-sveltekit]: https://github.com/ivanhofer/typesafe-i18n-demo-sveltekit
 [minutebase/ember-inline-svg]: https://github.com/minutebase/ember-inline-svg
 [natemoo-re/astro-capo]: https://github.com/natemoo-re/astro-capo
 [sveltejs/kit]: https://github.com/sveltejs/kit
diff --git a/src/twios/2023-09-21.md b/src/twios/2023-09-21.md
index f1daf8de03..cde06a1136 100644
--- a/src/twios/2023-09-21.md
+++ b/src/twios/2023-09-21.md
@@ -1,56 +1,34 @@
 ## Svelte
 
-- [paoloricciuti/sveltekit-view-transition]
-  [#29](https://github.com/paoloricciuti/sveltekit-view-transition/pull/29)
-  Update README.md ([@paoloricciuti])
+- [paoloricciuti/sveltekit-view-transition] [#29](https://github.com/paoloricciuti/sveltekit-view-transition/pull/29) Update README.md ([@paoloricciuti])
 
 ## Ember.js
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#204](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/204) Start
-  translating guides/applications/initializers.md ([@BlueCutOfficial])
-- [ember-cli/ember-cli]
-  [#10382](https://github.com/ember-cli/ember-cli/pull/10382) Move to pnpm
-  ([@mansona])
-- [ember-cli/ember-try] [#966](https://github.com/ember-cli/ember-try/pull/966)
-  Enforce resolution-mode=highest for pnpm versions 8.0.0 to 8.6.\* ([@lolmaus])
-- [ember-learn/ember-api-docs-data]
-  [#10](https://github.com/ember-learn/ember-api-docs-data/pull/10) Add 5.2
-  ([@mansona])
+- [DazzlingFugu/ember-fr-guides-source] [#204](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/204) Start translating guides/applications/initializers.md ([@BlueCutOfficial])
+- [ember-cli/ember-cli] [#10382](https://github.com/ember-cli/ember-cli/pull/10382) Move to pnpm ([@mansona])
+- [ember-cli/ember-try] [#966](https://github.com/ember-cli/ember-try/pull/966) Enforce resolution-mode=highest for pnpm versions 8.0.0 to 8.6.\* ([@lolmaus])
+- [ember-learn/ember-api-docs-data] [#10](https://github.com/ember-learn/ember-api-docs-data/pull/10) Add 5.2 ([@mansona])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1604](https://github.com/embroider-build/embroider/pull/1604) add
-  staticEmberSource to the readme example ([@mansona])
+- [embroider-build/embroider] [#1604](https://github.com/embroider-build/embroider/pull/1604) add staticEmberSource to the readme example ([@mansona])
 
 ## Empress
 
-- [empress/bottled-ember]
-  [#22](https://github.com/empress/bottled-ember/pull/22) use copy instead of
-  rename ([@mansona])
+- [empress/bottled-ember] [#22](https://github.com/empress/bottled-ember/pull/22) use copy instead of rename ([@mansona])
 
 ## JavaScript
 
-- [broccolijs/broccoli-filter]
-  [#53](https://github.com/broccolijs/broccoli-filter/pull/53) move from travis
-  to github actions ([@mansona])
+- [broccolijs/broccoli-filter] [#53](https://github.com/broccolijs/broccoli-filter/pull/53) move from travis to github actions ([@mansona])
 
 ## Internal
 
-- [mainmatter/renovate-config]
-  [#19](https://github.com/mainmatter/renovate-config/pull/19)
-  chore(ember-addon): fix and change schedule to automerge daily
-  ([@BobrImperator])
-- [mainmatter/renovate-config]
-  [#18](https://github.com/mainmatter/renovate-config/pull/18)
-  chore(ember-addon): add devDependencies automerging ([@BobrImperator])
+- [mainmatter/renovate-config] [#19](https://github.com/mainmatter/renovate-config/pull/19) chore(ember-addon): fix and change schedule to automerge daily ([@BobrImperator])
+- [mainmatter/renovate-config] [#18](https://github.com/mainmatter/renovate-config/pull/18) chore(ember-addon): add devDependencies automerging ([@BobrImperator])
 
 ## Ember
 
-- [ember-learn/ember-jsonapi-docs]
-  [#125](https://github.com/ember-learn/ember-jsonapi-docs/pull/125) Use volta
-  and corepack to run yarn and pnpm ([@mansona])
+- [ember-learn/ember-jsonapi-docs] [#125](https://github.com/ember-learn/ember-jsonapi-docs/pull/125) Use volta and corepack to run yarn and pnpm ([@mansona])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
@@ -59,17 +37,13 @@
 [@marcoow]: https://github.com/marcoow
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@pichfl]: https://github.com/pichfl
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [broccolijs/broccoli-filter]: https://github.com/broccolijs/broccoli-filter
 [ember-cli/ember-cli]: https://github.com/ember-cli/ember-cli
 [ember-cli/ember-try]: https://github.com/ember-cli/ember-try
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
-[ember-learn/ember-jsonapi-docs]:
-  https://github.com/ember-learn/ember-jsonapi-docs
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
+[ember-learn/ember-jsonapi-docs]: https://github.com/ember-learn/ember-jsonapi-docs
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [empress/bottled-ember]: https://github.com/empress/bottled-ember
 [mainmatter/renovate-config]: https://github.com/mainmatter/renovate-config
-[paoloricciuti/sveltekit-view-transition]:
-  https://github.com/paoloricciuti/sveltekit-view-transition
+[paoloricciuti/sveltekit-view-transition]: https://github.com/paoloricciuti/sveltekit-view-transition
diff --git a/src/twios/2023-10-01.md b/src/twios/2023-10-01.md
index 859823a830..14b95dd2c8 100644
--- a/src/twios/2023-10-01.md
+++ b/src/twios/2023-10-01.md
@@ -1,63 +1,35 @@
 ## Svelte
 
-- [paoloricciuti/sveltekit-view-transition]
-  [#34](https://github.com/paoloricciuti/sveltekit-view-transition/pull/34)
-  feat: add node and isInViewport to props of action functions
-  ([@paoloricciuti])
-- [theetrain/this-week-in-svelte]
-  [#3](https://github.com/theetrain/this-week-in-svelte/pull/3) Simple mocks
-  ([@paoloricciuti])
+- [paoloricciuti/sveltekit-view-transition] [#34](https://github.com/paoloricciuti/sveltekit-view-transition/pull/34) feat: add node and isInViewport to props of action functions ([@paoloricciuti])
+- [theetrain/this-week-in-svelte] [#3](https://github.com/theetrain/this-week-in-svelte/pull/3) Simple mocks ([@paoloricciuti])
 
 ## Ember.js
 
-- [ember-cli/ember-cli-update]
-  [#1249](https://github.com/ember-cli/ember-cli-update/pull/1249) fix
-  projectName if there is no package.json name ([@mansona])
-- [ember-learn/cli-guides]
-  [#304](https://github.com/ember-learn/cli-guides/pull/304) remove mention of
-  official support for Mocha ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#18](https://github.com/ember-learn/ember-api-docs-data/pull/18) Fix missing
-  entries for Ember ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#17](https://github.com/ember-learn/ember-api-docs-data/pull/17) re-generate
-  ember-data 2.18 ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#16](https://github.com/ember-learn/ember-api-docs-data/pull/16) Fix ember
-  data ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#15](https://github.com/ember-learn/ember-api-docs-data/pull/15) add missing
-  entries for ember-data 3.28 ([@mansona])
-- [ember-learn/guides-source]
-  [#1964](https://github.com/ember-learn/guides-source/pull/1964) remove
-  references to mocha in the guides ([@mansona])
+- [ember-cli/ember-cli-update] [#1249](https://github.com/ember-cli/ember-cli-update/pull/1249) fix projectName if there is no package.json name ([@mansona])
+- [ember-learn/cli-guides] [#304](https://github.com/ember-learn/cli-guides/pull/304) remove mention of official support for Mocha ([@mansona])
+- [ember-learn/ember-api-docs-data] [#18](https://github.com/ember-learn/ember-api-docs-data/pull/18) Fix missing entries for Ember ([@mansona])
+- [ember-learn/ember-api-docs-data] [#17](https://github.com/ember-learn/ember-api-docs-data/pull/17) re-generate ember-data 2.18 ([@mansona])
+- [ember-learn/ember-api-docs-data] [#16](https://github.com/ember-learn/ember-api-docs-data/pull/16) Fix ember data ([@mansona])
+- [ember-learn/ember-api-docs-data] [#15](https://github.com/ember-learn/ember-api-docs-data/pull/15) add missing entries for ember-data 3.28 ([@mansona])
+- [ember-learn/guides-source] [#1964](https://github.com/ember-learn/guides-source/pull/1964) remove references to mocha in the guides ([@mansona])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1616](https://github.com/embroider-build/embroider/pull/1616) prepare
-  release ([@mansona])
-- [embroider-build/embroider]
-  [#1614](https://github.com/embroider-build/embroider/pull/1614) esbuild
-  resolver for Vite dependency optimization ([@lolmaus])
+- [embroider-build/embroider] [#1616](https://github.com/embroider-build/embroider/pull/1616) prepare release ([@mansona])
+- [embroider-build/embroider] [#1614](https://github.com/embroider-build/embroider/pull/1614) esbuild resolver for Vite dependency optimization ([@lolmaus])
 
 ## Empress
 
-- [empress/ember-showdown-prism]
-  [#59](https://github.com/empress/ember-showdown-prism/pull/59) remove
-  ember-fetch to fix embroider tests ([@mansona])
+- [empress/ember-showdown-prism] [#59](https://github.com/empress/ember-showdown-prism/pull/59) remove ember-fetch to fix embroider tests ([@mansona])
 
 [@lolmaus]: https://github.com/lolmaus
 [@mansona]: https://github.com/mansona
 [@paoloricciuti]: https://github.com/paoloricciuti
 [ember-cli/ember-cli-update]: https://github.com/ember-cli/ember-cli-update
 [ember-learn/cli-guides]: https://github.com/ember-learn/cli-guides
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [empress/ember-showdown-prism]: https://github.com/empress/ember-showdown-prism
-[paoloricciuti/sveltekit-view-transition]:
-  https://github.com/paoloricciuti/sveltekit-view-transition
-[theetrain/this-week-in-svelte]:
-  https://github.com/theetrain/this-week-in-svelte
+[paoloricciuti/sveltekit-view-transition]: https://github.com/paoloricciuti/sveltekit-view-transition
+[theetrain/this-week-in-svelte]: https://github.com/theetrain/this-week-in-svelte
diff --git a/src/twios/2023-10-09.md b/src/twios/2023-10-09.md
index ba8b69c967..81ce696430 100644
--- a/src/twios/2023-10-09.md
+++ b/src/twios/2023-10-09.md
@@ -1,65 +1,31 @@
 ## Embroider
 
-- [embroider-build/content-tag]
-  [#34](https://github.com/embroider-build/content-tag/pull/34) Prepare Release
-  1.1.1 ([@mansona])
-- [embroider-build/content-tag]
-  [#33](https://github.com/embroider-build/content-tag/pull/33) Add release-it
-  ([@mansona])
-- [embroider-build/content-tag]
-  [#32](https://github.com/embroider-build/content-tag/pull/32) setup npm
-  credentials for auto-publish ([@mansona])
-- [embroider-build/embroider]
-  [#1628](https://github.com/embroider-build/embroider/pull/1628) prepare a
-  release ([@mansona])
-- [embroider-build/embroider]
-  [#1627](https://github.com/embroider-build/embroider/pull/1627) WIP Resolver
-  refactor ([@mansona])
-- [embroider-build/embroider]
-  [#1622](https://github.com/embroider-build/embroider/pull/1622) use realpath
-  of engine's route when building resolver.json ([@mansona])
-- [embroider-build/embroider]
-  [#1623](https://github.com/embroider-build/embroider/pull/1623) Implement the
-  optimizeDeps() helper ([@lolmaus])
+- [embroider-build/content-tag] [#34](https://github.com/embroider-build/content-tag/pull/34) Prepare Release 1.1.1 ([@mansona])
+- [embroider-build/content-tag] [#33](https://github.com/embroider-build/content-tag/pull/33) Add release-it ([@mansona])
+- [embroider-build/content-tag] [#32](https://github.com/embroider-build/content-tag/pull/32) setup npm credentials for auto-publish ([@mansona])
+- [embroider-build/embroider] [#1628](https://github.com/embroider-build/embroider/pull/1628) prepare a release ([@mansona])
+- [embroider-build/embroider] [#1627](https://github.com/embroider-build/embroider/pull/1627) WIP Resolver refactor ([@mansona])
+- [embroider-build/embroider] [#1622](https://github.com/embroider-build/embroider/pull/1622) use realpath of engine's route when building resolver.json ([@mansona])
+- [embroider-build/embroider] [#1623](https://github.com/embroider-build/embroider/pull/1623) Implement the optimizeDeps() helper ([@lolmaus])
 
 ## Ember
 
-- [DazzlingFugu/guidemaker-ember-locale-template]
-  [#5](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/5)
-  [DO NOT MERGE] Configure the search bar ([@BlueCutOfficial])
-- [ember-cli/ember-cli]
-  [#10389](https://github.com/ember-cli/ember-cli/pull/10389) Merge beta into
-  master ([@mansona])
-- [emberobserver/client]
-  [#240](https://github.com/emberobserver/client/pull/240) Update Ember to 3.28
-  ([@lolmaus])
-- [mainmatter/ember-cookies]
-  [#862](https://github.com/mainmatter/ember-cookies/pull/862) chore(deps): bump
-  prettier and eslint-plugin-prettier ([@BobrImperator])
-- [mainmatter/qunit-dom]
-  [#2062](https://github.com/mainmatter/qunit-dom/pull/2062) chore(ci): specify
-  job timeouts ([@BobrImperator])
-- [mainmatter/qunit-dom]
-  [#2061](https://github.com/mainmatter/qunit-dom/pull/2061) chore(ci): use
-  volta-cli github action for node and pnpm setup ([@BobrImperator])
-- [mainmatter/qunit-dom]
-  [#2060](https://github.com/mainmatter/qunit-dom/pull/2060) chore(deps): bump
-  prettier and eslint-plugin-prettier ([@BobrImperator])
-- [mainmatter/qunit-dom]
-  [#2055](https://github.com/mainmatter/qunit-dom/pull/2055) chore(release):
-  copy static LICENSE and README into the package during build
-  ([@BobrImperator])
-- [zeppelin/ember-click-outside]
-  [#265](https://github.com/zeppelin/ember-click-outside/pull/265) Node 14→16,
-  pnpm 7→8.8.x ([@zeppelin])
+- [DazzlingFugu/guidemaker-ember-locale-template] [#5](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/5) [DO NOT MERGE] Configure the search bar ([@BlueCutOfficial])
+- [ember-cli/ember-cli] [#10389](https://github.com/ember-cli/ember-cli/pull/10389) Merge beta into master ([@mansona])
+- [emberobserver/client] [#240](https://github.com/emberobserver/client/pull/240) Update Ember to 3.28 ([@lolmaus])
+- [mainmatter/ember-cookies] [#862](https://github.com/mainmatter/ember-cookies/pull/862) chore(deps): bump prettier and eslint-plugin-prettier ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2062](https://github.com/mainmatter/qunit-dom/pull/2062) chore(ci): specify job timeouts ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2061](https://github.com/mainmatter/qunit-dom/pull/2061) chore(ci): use volta-cli github action for node and pnpm setup ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2060](https://github.com/mainmatter/qunit-dom/pull/2060) chore(deps): bump prettier and eslint-plugin-prettier ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2055](https://github.com/mainmatter/qunit-dom/pull/2055) chore(release): copy static LICENSE and README into the package during build ([@BobrImperator])
+- [zeppelin/ember-click-outside] [#265](https://github.com/zeppelin/ember-click-outside/pull/265) Node 14→16, pnpm 7→8.8.x ([@zeppelin])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
 [@lolmaus]: https://github.com/lolmaus
 [@mansona]: https://github.com/mansona
 [@zeppelin]: https://github.com/zeppelin
-[dazzlingfugu/guidemaker-ember-locale-template]:
-  https://github.com/DazzlingFugu/guidemaker-ember-locale-template
+[dazzlingfugu/guidemaker-ember-locale-template]: https://github.com/DazzlingFugu/guidemaker-ember-locale-template
 [ember-cli/ember-cli]: https://github.com/ember-cli/ember-cli
 [emberobserver/client]: https://github.com/emberobserver/client
 [embroider-build/content-tag]: https://github.com/embroider-build/content-tag
diff --git a/src/twios/2023-10-15.md b/src/twios/2023-10-15.md
index dce997d6ed..3626421ce8 100644
--- a/src/twios/2023-10-15.md
+++ b/src/twios/2023-10-15.md
@@ -1,43 +1,25 @@
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1637](https://github.com/embroider-build/embroider/pull/1637) Update node to
-  20 to test CI ([@mansona])
+- [embroider-build/embroider] [#1637](https://github.com/embroider-build/embroider/pull/1637) Update node to 20 to test CI ([@mansona])
 
 ## JavaScript
 
-- [mainmatter/continue-on-error-comment]
-  [#11](https://github.com/mainmatter/continue-on-error-comment/pull/11) Allow
-  action to work on pull_request_target and update documentation ([@mansona])
-- [miragejs/miragejs] [#1091](https://github.com/miragejs/miragejs/pull/1091)
-  Simplify lodash dependencies ([@mansona])
+- [mainmatter/continue-on-error-comment] [#11](https://github.com/mainmatter/continue-on-error-comment/pull/11) Allow action to work on pull_request_target and update documentation ([@mansona])
+- [miragejs/miragejs] [#1091](https://github.com/miragejs/miragejs/pull/1091) Simplify lodash dependencies ([@mansona])
 
 ## Ember
 
-- [mainmatter/ember-cookies]
-  [#862](https://github.com/mainmatter/ember-cookies/pull/862) chore(deps): bump
-  prettier and eslint-plugin-prettier ([@BobrImperator])
-- [mainmatter/qunit-dom]
-  [#2062](https://github.com/mainmatter/qunit-dom/pull/2062) chore(ci): specify
-  job timeouts ([@BobrImperator])
-- [mainmatter/qunit-dom]
-  [#2061](https://github.com/mainmatter/qunit-dom/pull/2061) chore(ci): use
-  volta-cli github action for node and pnpm setup ([@BobrImperator])
-- [mainmatter/qunit-dom]
-  [#2060](https://github.com/mainmatter/qunit-dom/pull/2060) chore(deps): bump
-  prettier and eslint-plugin-prettier ([@BobrImperator])
-- [miguelcobain/ember-paper]
-  [#1249](https://github.com/miguelcobain/ember-paper/pull/1249) update
-  ember-auto-import to v2 ([@mansona])
-- [miguelcobain/ember-paper]
-  [#1248](https://github.com/miguelcobain/ember-paper/pull/1248) apply fix to
-  allow continue-on-error-comment to work ([@mansona])
+- [mainmatter/ember-cookies] [#862](https://github.com/mainmatter/ember-cookies/pull/862) chore(deps): bump prettier and eslint-plugin-prettier ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2062](https://github.com/mainmatter/qunit-dom/pull/2062) chore(ci): specify job timeouts ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2061](https://github.com/mainmatter/qunit-dom/pull/2061) chore(ci): use volta-cli github action for node and pnpm setup ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2060](https://github.com/mainmatter/qunit-dom/pull/2060) chore(deps): bump prettier and eslint-plugin-prettier ([@BobrImperator])
+- [miguelcobain/ember-paper] [#1249](https://github.com/miguelcobain/ember-paper/pull/1249) update ember-auto-import to v2 ([@mansona])
+- [miguelcobain/ember-paper] [#1248](https://github.com/miguelcobain/ember-paper/pull/1248) apply fix to allow continue-on-error-comment to work ([@mansona])
 
 [@bobrimperator]: https://github.com/BobrImperator
 [@mansona]: https://github.com/mansona
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/continue-on-error-comment]:
-  https://github.com/mainmatter/continue-on-error-comment
+[mainmatter/continue-on-error-comment]: https://github.com/mainmatter/continue-on-error-comment
 [mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies
 [mainmatter/qunit-dom]: https://github.com/mainmatter/qunit-dom
 [miguelcobain/ember-paper]: https://github.com/miguelcobain/ember-paper
diff --git a/src/twios/2023-10-22.md b/src/twios/2023-10-22.md
index bb292d6fa5..f1c4fd44e4 100644
--- a/src/twios/2023-10-22.md
+++ b/src/twios/2023-10-22.md
@@ -1,65 +1,31 @@
 ## Rust
 
-- [marcoow/rust_rest] [#9](https://github.com/marcoow/rust_rest/pull/9) don't
-  depend on exact patch versions ([@marcoow])
+- [marcoow/rust_rest] [#9](https://github.com/marcoow/rust_rest/pull/9) don't depend on exact patch versions ([@marcoow])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1648](https://github.com/embroider-build/embroider/pull/1648) use package
-  paths instead of relative paths for app tree resolving ([@mansona])
+- [embroider-build/embroider] [#1648](https://github.com/embroider-build/embroider/pull/1648) use package paths instead of relative paths for app tree resolving ([@mansona])
 
 ## Empress
 
-- [empress/bottled-ember]
-  [#23](https://github.com/empress/bottled-ember/pull/23) Allow you to configure
-  Fastboot dependencies ([@mansona])
+- [empress/bottled-ember] [#23](https://github.com/empress/bottled-ember/pull/23) Allow you to configure Fastboot dependencies ([@mansona])
 
 ## Ember
 
-- [DazzlingFugu/guidemaker-ember-locale-template]
-  [#6](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/6)
-  [DRAFT] Use native classes ([@BlueCutOfficial])
-- [ember-learn/ember-styleguide]
-  [#491](https://github.com/ember-learn/ember-styleguide/pull/491) Drop support
-  for Ember < 3.28 ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#490](https://github.com/ember-learn/ember-styleguide/pull/490) update to
-  v4.8 with ember-cli-update ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#489](https://github.com/ember-learn/ember-styleguide/pull/489) move to
-  release-it for deploys ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#488](https://github.com/ember-learn/ember-styleguide/pull/488) drop support
-  for EOL node < 18 ([@mansona])
-- [emberjs/ember-test-helpers]
-  [#1441](https://github.com/emberjs/ember-test-helpers/pull/1441) Don't swallow
-  deprecations and warnings when there is no test context: backport to v2
-  ([@lolmaus])
-- [lan0/ember-power-time-picker]
-  [#8](https://github.com/lan0/ember-power-time-picker/pull/8) Upgrade to ember
-  3.16 ([@Mikek2252])
-- [mixonic/ember-cli-deprecation-workflow]
-  [#158](https://github.com/mixonic/ember-cli-deprecation-workflow/pull/158)
-  Upgrade Ember to 3.28 ([@lolmaus])
-- [nickschot/ember-mobile-menu]
-  [#745](https://github.com/nickschot/ember-mobile-menu/pull/745) Remove
-  reliance on sinon ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#744](https://github.com/nickschot/ember-mobile-menu/pull/744) Replace
-  tracked-maps-and-sets with tracked-built-ins ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#743](https://github.com/nickschot/ember-mobile-menu/pull/743) Add missing
-  tracked-storage-polyfill to docs app ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#742](https://github.com/nickschot/ember-mobile-menu/pull/742) Drop
-  ember-source 3.28 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#741](https://github.com/nickschot/ember-mobile-menu/pull/741) Upgrade
-  ember-qunit to v7, @ember/test-helpers to v3 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#734](https://github.com/nickschot/ember-mobile-menu/pull/734) Drop Node 16
-  support ([@nickschot])
+- [DazzlingFugu/guidemaker-ember-locale-template] [#6](https://github.com/DazzlingFugu/guidemaker-ember-locale-template/pull/6) [DRAFT] Use native classes ([@BlueCutOfficial])
+- [ember-learn/ember-styleguide] [#491](https://github.com/ember-learn/ember-styleguide/pull/491) Drop support for Ember < 3.28 ([@mansona])
+- [ember-learn/ember-styleguide] [#490](https://github.com/ember-learn/ember-styleguide/pull/490) update to v4.8 with ember-cli-update ([@mansona])
+- [ember-learn/ember-styleguide] [#489](https://github.com/ember-learn/ember-styleguide/pull/489) move to release-it for deploys ([@mansona])
+- [ember-learn/ember-styleguide] [#488](https://github.com/ember-learn/ember-styleguide/pull/488) drop support for EOL node < 18 ([@mansona])
+- [emberjs/ember-test-helpers] [#1441](https://github.com/emberjs/ember-test-helpers/pull/1441) Don't swallow deprecations and warnings when there is no test context: backport to v2 ([@lolmaus])
+- [lan0/ember-power-time-picker] [#8](https://github.com/lan0/ember-power-time-picker/pull/8) Upgrade to ember 3.16 ([@Mikek2252])
+- [mixonic/ember-cli-deprecation-workflow] [#158](https://github.com/mixonic/ember-cli-deprecation-workflow/pull/158) Upgrade Ember to 3.28 ([@lolmaus])
+- [nickschot/ember-mobile-menu] [#745](https://github.com/nickschot/ember-mobile-menu/pull/745) Remove reliance on sinon ([@nickschot])
+- [nickschot/ember-mobile-menu] [#744](https://github.com/nickschot/ember-mobile-menu/pull/744) Replace tracked-maps-and-sets with tracked-built-ins ([@nickschot])
+- [nickschot/ember-mobile-menu] [#743](https://github.com/nickschot/ember-mobile-menu/pull/743) Add missing tracked-storage-polyfill to docs app ([@nickschot])
+- [nickschot/ember-mobile-menu] [#742](https://github.com/nickschot/ember-mobile-menu/pull/742) Drop ember-source 3.28 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#741](https://github.com/nickschot/ember-mobile-menu/pull/741) Upgrade ember-qunit to v7, @ember/test-helpers to v3 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#734](https://github.com/nickschot/ember-mobile-menu/pull/734) Drop Node 16 support ([@nickschot])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@mikek2252]: https://github.com/Mikek2252
@@ -67,14 +33,12 @@
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
 [@nickschot]: https://github.com/nickschot
-[dazzlingfugu/guidemaker-ember-locale-template]:
-  https://github.com/DazzlingFugu/guidemaker-ember-locale-template
+[dazzlingfugu/guidemaker-ember-locale-template]: https://github.com/DazzlingFugu/guidemaker-ember-locale-template
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
 [emberjs/ember-test-helpers]: https://github.com/emberjs/ember-test-helpers
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [empress/bottled-ember]: https://github.com/empress/bottled-ember
 [lan0/ember-power-time-picker]: https://github.com/lan0/ember-power-time-picker
 [marcoow/rust_rest]: https://github.com/marcoow/rust_rest
-[mixonic/ember-cli-deprecation-workflow]:
-  https://github.com/mixonic/ember-cli-deprecation-workflow
+[mixonic/ember-cli-deprecation-workflow]: https://github.com/mixonic/ember-cli-deprecation-workflow
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
diff --git a/src/twios/2023-10-29.md b/src/twios/2023-10-29.md
index 4d813ee8ab..c187f87e72 100644
--- a/src/twios/2023-10-29.md
+++ b/src/twios/2023-10-29.md
@@ -1,42 +1,25 @@
 ## Rust
 
-- [marcoow/rust_rest] [#12](https://github.com/marcoow/rust_rest/pull/12) fix
-  command for running test migrations ([@marcoow])
-- [marcoow/rust_rest] [#11](https://github.com/marcoow/rust_rest/pull/11) rename
-  users to tasks ([@marcoow])
-- [marcoow/rust_rest] [#10](https://github.com/marcoow/rust_rest/pull/10)
-  Require authorization for user creation ([@marcoow])
+- [marcoow/rust_rest] [#12](https://github.com/marcoow/rust_rest/pull/12) fix command for running test migrations ([@marcoow])
+- [marcoow/rust_rest] [#11](https://github.com/marcoow/rust_rest/pull/11) rename users to tasks ([@marcoow])
+- [marcoow/rust_rest] [#10](https://github.com/marcoow/rust_rest/pull/10) Require authorization for user creation ([@marcoow])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1650](https://github.com/embroider-build/embroider/pull/1650) [WIP] Esbuild
-  resolver ([@mansona])
-- [embroider-build/embroider]
-  [#1649](https://github.com/embroider-build/embroider/pull/1649) update pnpm
-  ([@mansona])
-- [embroider-build/scenario-tester]
-  [#22](https://github.com/embroider-build/scenario-tester/pull/22) fix CI to
-  remove volta ([@mansona])
+- [embroider-build/embroider] [#1650](https://github.com/embroider-build/embroider/pull/1650) [WIP] Esbuild resolver ([@mansona])
+- [embroider-build/embroider] [#1649](https://github.com/embroider-build/embroider/pull/1649) update pnpm ([@mansona])
+- [embroider-build/scenario-tester] [#22](https://github.com/embroider-build/scenario-tester/pull/22) fix CI to remove volta ([@mansona])
 
 ## Ember
 
-- [ember-learn/ember-api-docs-data]
-  [#19](https://github.com/ember-learn/ember-api-docs-data/pull/19) fix issue
-  with ember 4.12 pointing at the wrong patch version ([@mansona])
-- [mixonic/ember-cli-deprecation-workflow]
-  [#159](https://github.com/mixonic/ember-cli-deprecation-workflow/pull/159)
-  [BREAKING] Convert to a module. Drops support for Ember < 3.28, requires
-  manual initialization ([@lolmaus])
+- [ember-learn/ember-api-docs-data] [#19](https://github.com/ember-learn/ember-api-docs-data/pull/19) fix issue with ember 4.12 pointing at the wrong patch version ([@mansona])
+- [mixonic/ember-cli-deprecation-workflow] [#159](https://github.com/mixonic/ember-cli-deprecation-workflow/pull/159) [BREAKING] Convert to a module. Drops support for Ember < 3.28, requires manual initialization ([@lolmaus])
 
 [@lolmaus]: https://github.com/lolmaus
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[embroider-build/scenario-tester]:
-  https://github.com/embroider-build/scenario-tester
+[embroider-build/scenario-tester]: https://github.com/embroider-build/scenario-tester
 [marcoow/rust_rest]: https://github.com/marcoow/rust_rest
-[mixonic/ember-cli-deprecation-workflow]:
-  https://github.com/mixonic/ember-cli-deprecation-workflow
+[mixonic/ember-cli-deprecation-workflow]: https://github.com/mixonic/ember-cli-deprecation-workflow
diff --git a/src/twios/2023-11-05.md b/src/twios/2023-11-05.md
index c16a5b4448..1f6c9cf294 100644
--- a/src/twios/2023-11-05.md
+++ b/src/twios/2023-11-05.md
@@ -1,101 +1,53 @@
 ## Rust
 
-- [marcoow/rust_rest] [#26](https://github.com/marcoow/rust_rest/pull/26) Db
-  cleanup ([@marcoow])
-- [marcoow/rust_rest] [#25](https://github.com/marcoow/rust_rest/pull/25)
-  simplify test helper ([@marcoow])
-- [marcoow/rust_rest] [#24](https://github.com/marcoow/rust_rest/pull/24) Task
-  for resetting db ([@marcoow])
-- [marcoow/rust_rest] [#20](https://github.com/marcoow/rust_rest/pull/20) DB
-  Seeding ([@marcoow])
-- [marcoow/rust_rest] [#19](https://github.com/marcoow/rust_rest/pull/19)
-  Introduce auth & users ([@marcoow])
-- [marcoow/rust_rest] [#18](https://github.com/marcoow/rust_rest/pull/18) Fix DB
-  isolation for tests ([@marcoow])
-- [marcoow/rust_rest] [#16](https://github.com/marcoow/rust_rest/pull/16) use
-  correct db methods ([@marcoow])
-- [marcoow/rust_rest] [#15](https://github.com/marcoow/rust_rest/pull/15)
-  improve CLI ([@marcoow])
+- [marcoow/rust_rest] [#26](https://github.com/marcoow/rust_rest/pull/26) Db cleanup ([@marcoow])
+- [marcoow/rust_rest] [#25](https://github.com/marcoow/rust_rest/pull/25) simplify test helper ([@marcoow])
+- [marcoow/rust_rest] [#24](https://github.com/marcoow/rust_rest/pull/24) Task for resetting db ([@marcoow])
+- [marcoow/rust_rest] [#20](https://github.com/marcoow/rust_rest/pull/20) DB Seeding ([@marcoow])
+- [marcoow/rust_rest] [#19](https://github.com/marcoow/rust_rest/pull/19) Introduce auth & users ([@marcoow])
+- [marcoow/rust_rest] [#18](https://github.com/marcoow/rust_rest/pull/18) Fix DB isolation for tests ([@marcoow])
+- [marcoow/rust_rest] [#16](https://github.com/marcoow/rust_rest/pull/16) use correct db methods ([@marcoow])
+- [marcoow/rust_rest] [#15](https://github.com/marcoow/rust_rest/pull/15) improve CLI ([@marcoow])
 
 ## Embroider
 
-- [embroider-build/ember-auto-import]
-  [#597](https://github.com/embroider-build/ember-auto-import/pull/597) update
-  package-lock.json ([@mansona])
-- [embroider-build/embroider]
-  [#1652](https://github.com/embroider-build/embroider/pull/1652)
-  reverse-exports package ([@lolmaus])
-- [embroider-build/scenario-tester]
-  [#24](https://github.com/embroider-build/scenario-tester/pull/24) Set up
-  release-it ([@mansona])
-- [embroider-build/scenario-tester]
-  [#23](https://github.com/embroider-build/scenario-tester/pull/23) use the
-  right tsconfig for typedoc ([@mansona])
+- [embroider-build/ember-auto-import] [#597](https://github.com/embroider-build/ember-auto-import/pull/597) update package-lock.json ([@mansona])
+- [embroider-build/embroider] [#1652](https://github.com/embroider-build/embroider/pull/1652) reverse-exports package ([@lolmaus])
+- [embroider-build/scenario-tester] [#24](https://github.com/embroider-build/scenario-tester/pull/24) Set up release-it ([@mansona])
+- [embroider-build/scenario-tester] [#23](https://github.com/embroider-build/scenario-tester/pull/23) use the right tsconfig for typedoc ([@mansona])
 
 ## Empress
 
-- [empress/empress-blog]
-  [#182](https://github.com/empress/empress-blog/pull/182) update to v5.0 with
-  ember-cli-update ([@mansona])
-- [empress/empress-blog]
-  [#181](https://github.com/empress/empress-blog/pull/181) update js-yaml
-  ([@mansona])
+- [empress/empress-blog] [#182](https://github.com/empress/empress-blog/pull/182) update to v5.0 with ember-cli-update ([@mansona])
+- [empress/empress-blog] [#181](https://github.com/empress/empress-blog/pull/181) update js-yaml ([@mansona])
 
 ## JavaScript
 
-- [ember-learn/algolia-index-update-scripts]
-  [#19](https://github.com/ember-learn/algolia-index-update-scripts/pull/19) add
-  script for deleting tags ([@mansona])
-- [ember-learn/algolia-index-update-scripts]
-  [#18](https://github.com/ember-learn/algolia-index-update-scripts/pull/18) Run
-  search update scripts against ember-api-docs-data ([@mansona])
-- [ember-learn/ember-jsonapi-docs]
-  [#132](https://github.com/ember-learn/ember-jsonapi-docs/pull/132) use esm
-  properly with node ([@mansona])
-- [ember-learn/ember-jsonapi-docs]
-  [#131](https://github.com/ember-learn/ember-jsonapi-docs/pull/131) add semis
-  back ([@mansona])
-- [ember-learn/ember-jsonapi-docs]
-  [#130](https://github.com/ember-learn/ember-jsonapi-docs/pull/130) unify
-  indent style to space ([@mansona])
-- [ember-learn/ember-jsonapi-docs]
-  [#129](https://github.com/ember-learn/ember-jsonapi-docs/pull/129) Update
-  eslint and prettier ([@mansona])
-- [ember-learn/ember-jsonapi-docs]
-  [#127](https://github.com/ember-learn/ember-jsonapi-docs/pull/127) move to npm
-  and setup CI ([@mansona])
-- [kellyselden/boilerplate-update]
-  [#432](https://github.com/kellyselden/boilerplate-update/pull/432) run one npx
-  command at once on windows ([@mansona])
+- [ember-learn/algolia-index-update-scripts] [#19](https://github.com/ember-learn/algolia-index-update-scripts/pull/19) add script for deleting tags ([@mansona])
+- [ember-learn/algolia-index-update-scripts] [#18](https://github.com/ember-learn/algolia-index-update-scripts/pull/18) Run search update scripts against ember-api-docs-data ([@mansona])
+- [ember-learn/ember-jsonapi-docs] [#132](https://github.com/ember-learn/ember-jsonapi-docs/pull/132) use esm properly with node ([@mansona])
+- [ember-learn/ember-jsonapi-docs] [#131](https://github.com/ember-learn/ember-jsonapi-docs/pull/131) add semis back ([@mansona])
+- [ember-learn/ember-jsonapi-docs] [#130](https://github.com/ember-learn/ember-jsonapi-docs/pull/130) unify indent style to space ([@mansona])
+- [ember-learn/ember-jsonapi-docs] [#129](https://github.com/ember-learn/ember-jsonapi-docs/pull/129) Update eslint and prettier ([@mansona])
+- [ember-learn/ember-jsonapi-docs] [#127](https://github.com/ember-learn/ember-jsonapi-docs/pull/127) move to npm and setup CI ([@mansona])
+- [kellyselden/boilerplate-update] [#432](https://github.com/kellyselden/boilerplate-update/pull/432) run one npx command at once on windows ([@mansona])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#208](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/208) Update
-  guidemaker-elt, remove what was moved in the addon ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#207](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/207)
-  Improve the contributing guide ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#206](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/206)
-  Translate guides/tutorial/part-1 ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#208](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/208) Update guidemaker-elt, remove what was moved in the addon ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#207](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/207) Improve the contributing guide ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#206](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/206) Translate guides/tutorial/part-1 ([@BlueCutOfficial])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@lolmaus]: https://github.com/lolmaus
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
-[ember-learn/algolia-index-update-scripts]:
-  https://github.com/ember-learn/algolia-index-update-scripts
-[ember-learn/ember-jsonapi-docs]:
-  https://github.com/ember-learn/ember-jsonapi-docs
-[embroider-build/ember-auto-import]:
-  https://github.com/embroider-build/ember-auto-import
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[ember-learn/algolia-index-update-scripts]: https://github.com/ember-learn/algolia-index-update-scripts
+[ember-learn/ember-jsonapi-docs]: https://github.com/ember-learn/ember-jsonapi-docs
+[embroider-build/ember-auto-import]: https://github.com/embroider-build/ember-auto-import
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[embroider-build/scenario-tester]:
-  https://github.com/embroider-build/scenario-tester
+[embroider-build/scenario-tester]: https://github.com/embroider-build/scenario-tester
 [empress/empress-blog]: https://github.com/empress/empress-blog
-[kellyselden/boilerplate-update]:
-  https://github.com/kellyselden/boilerplate-update
+[kellyselden/boilerplate-update]: https://github.com/kellyselden/boilerplate-update
 [marcoow/rust_rest]: https://github.com/marcoow/rust_rest
diff --git a/src/twios/2023-11-19.md b/src/twios/2023-11-19.md
index 3c227ce06a..7d0dabbc82 100644
--- a/src/twios/2023-11-19.md
+++ b/src/twios/2023-11-19.md
@@ -1,105 +1,56 @@
 ## Rust
 
-- [marcoow/rust_rest] [#36](https://github.com/marcoow/rust_rest/pull/36) Use
-  Sqlx instead of tokio-postres ([@marcoow])
-- [marcoow/rust_rest] [#35](https://github.com/marcoow/rust_rest/pull/35) Handle
-  panics ([@marcoow])
-- [marcoow/rust_rest] [#33](https://github.com/marcoow/rust_rest/pull/33)
-  Cleanup ([@marcoow])
-- [marcoow/rust_rest] [#32](https://github.com/marcoow/rust_rest/pull/32) Move
-  support code to support crate ([@marcoow])
-- [marcoow/rust_rest] [#31](https://github.com/marcoow/rust_rest/pull/31) Better
-  bin org ([@marcoow])
-- [marcoow/rust_rest] [#29](https://github.com/marcoow/rust_rest/pull/29) add
-  task for creating migration ([@marcoow])
-- [marcoow/rust_rest] [#28](https://github.com/marcoow/rust_rest/pull/28) Reuse
-  code in db bin ([@marcoow])
-- [marcoow/rust_rest] [#27](https://github.com/marcoow/rust_rest/pull/27) use
-  reset task on ci ([@marcoow])
+- [marcoow/rust_rest] [#36](https://github.com/marcoow/rust_rest/pull/36) Use Sqlx instead of tokio-postres ([@marcoow])
+- [marcoow/rust_rest] [#35](https://github.com/marcoow/rust_rest/pull/35) Handle panics ([@marcoow])
+- [marcoow/rust_rest] [#33](https://github.com/marcoow/rust_rest/pull/33) Cleanup ([@marcoow])
+- [marcoow/rust_rest] [#32](https://github.com/marcoow/rust_rest/pull/32) Move support code to support crate ([@marcoow])
+- [marcoow/rust_rest] [#31](https://github.com/marcoow/rust_rest/pull/31) Better bin org ([@marcoow])
+- [marcoow/rust_rest] [#29](https://github.com/marcoow/rust_rest/pull/29) add task for creating migration ([@marcoow])
+- [marcoow/rust_rest] [#28](https://github.com/marcoow/rust_rest/pull/28) Reuse code in db bin ([@marcoow])
+- [marcoow/rust_rest] [#27](https://github.com/marcoow/rust_rest/pull/27) use reset task on ci ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/svelte-promise-modals]
-  [#38](https://github.com/mainmatter/svelte-promise-modals/pull/38) Add docs
-  ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#37](https://github.com/mainmatter/svelte-promise-modals/pull/37) Fix
-  `clickOutsideDeactivates` option ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#33](https://github.com/mainmatter/svelte-promise-modals/pull/33) Kitchen
-  sink ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#32](https://github.com/mainmatter/svelte-promise-modals/pull/32) Upgrade
-  Svelte packages ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#31](https://github.com/mainmatter/svelte-promise-modals/pull/31) Rename
-  output dir \_app → app ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#30](https://github.com/mainmatter/svelte-promise-modals/pull/30) Deploy to
-  GitHub pages ([@zeppelin])
-- [sveltejs/kit] [#11066](https://github.com/sveltejs/kit/pull/11066) feat:
-  allow for fine grained invalidation of search params ([@paoloricciuti])
-- [sveltejs/svelte] [#9462](https://github.com/sveltejs/svelte/pull/9462) fix:
-  allow member access on directives ([@paoloricciuti])
-- [sveltejs/svelte] [#9439](https://github.com/sveltejs/svelte/pull/9439) fix:
-  allow svelte:self in snippets ([@paoloricciuti])
+- [mainmatter/svelte-promise-modals] [#38](https://github.com/mainmatter/svelte-promise-modals/pull/38) Add docs ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#37](https://github.com/mainmatter/svelte-promise-modals/pull/37) Fix `clickOutsideDeactivates` option ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#33](https://github.com/mainmatter/svelte-promise-modals/pull/33) Kitchen sink ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#32](https://github.com/mainmatter/svelte-promise-modals/pull/32) Upgrade Svelte packages ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#31](https://github.com/mainmatter/svelte-promise-modals/pull/31) Rename output dir \_app → app ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#30](https://github.com/mainmatter/svelte-promise-modals/pull/30) Deploy to GitHub pages ([@zeppelin])
+- [sveltejs/kit] [#11066](https://github.com/sveltejs/kit/pull/11066) feat: allow for fine grained invalidation of search params ([@paoloricciuti])
+- [sveltejs/svelte] [#9462](https://github.com/sveltejs/svelte/pull/9462) fix: allow member access on directives ([@paoloricciuti])
+- [sveltejs/svelte] [#9439](https://github.com/sveltejs/svelte/pull/9439) fix: allow svelte:self in snippets ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1671](https://github.com/embroider-build/embroider/pull/1671) Prepare a
-  release ([@mansona])
-- [embroider-build/embroider]
-  [#1670](https://github.com/embroider-build/embroider/pull/1670) Fix looping
-  for unchanged files ([@mansona])
-- [embroider-build/embroider]
-  [#1668](https://github.com/embroider-build/embroider/pull/1668) prepare
-  release ([@mansona])
-- [embroider-build/embroider]
-  [#1666](https://github.com/embroider-build/embroider/pull/1666) unpin
-  json-stable-stringify ([@mansona])
-- [embroider-build/embroider]
-  [#1658](https://github.com/embroider-build/embroider/pull/1658) change
-  release-plan to get publish-stable to run ([@mansona])
+- [embroider-build/embroider] [#1671](https://github.com/embroider-build/embroider/pull/1671) Prepare a release ([@mansona])
+- [embroider-build/embroider] [#1670](https://github.com/embroider-build/embroider/pull/1670) Fix looping for unchanged files ([@mansona])
+- [embroider-build/embroider] [#1668](https://github.com/embroider-build/embroider/pull/1668) prepare release ([@mansona])
+- [embroider-build/embroider] [#1666](https://github.com/embroider-build/embroider/pull/1666) unpin json-stable-stringify ([@mansona])
+- [embroider-build/embroider] [#1658](https://github.com/embroider-build/embroider/pull/1658) change release-plan to get publish-stable to run ([@mansona])
 
 ## JavaScript
 
-- [embroider-build/release-plan]
-  [#1](https://github.com/embroider-build/release-plan/pull/1) use tsup
-  ([@mansona])
+- [embroider-build/release-plan] [#1](https://github.com/embroider-build/release-plan/pull/1) use tsup ([@mansona])
 
 ## Ember
 
-- [ember-fastboot/ember-cli-fastboot]
-  [#931](https://github.com/ember-fastboot/ember-cli-fastboot/pull/931) update
-  release-it ([@mansona])
-- [ember-fastboot/ember-cli-fastboot]
-  [#930](https://github.com/ember-fastboot/ember-cli-fastboot/pull/930) update
-  pnpm to v8 ([@mansona])
-- [ember-fastboot/ember-cli-fastboot]
-  [#929](https://github.com/ember-fastboot/ember-cli-fastboot/pull/929) fix json
-  stringify in fastboot-config ([@mansona])
-- [nickschot/ember-mobile-menu]
-  [#791](https://github.com/nickschot/ember-mobile-menu/pull/791) Enable
-  readme/license copying to published addon ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#790](https://github.com/nickschot/ember-mobile-menu/pull/790) Remove Travis
-  CI badge ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#789](https://github.com/nickschot/ember-mobile-menu/pull/789) Remove v1
-  addon/cleanup ([@nickschot])
+- [ember-fastboot/ember-cli-fastboot] [#931](https://github.com/ember-fastboot/ember-cli-fastboot/pull/931) update release-it ([@mansona])
+- [ember-fastboot/ember-cli-fastboot] [#930](https://github.com/ember-fastboot/ember-cli-fastboot/pull/930) update pnpm to v8 ([@mansona])
+- [ember-fastboot/ember-cli-fastboot] [#929](https://github.com/ember-fastboot/ember-cli-fastboot/pull/929) fix json stringify in fastboot-config ([@mansona])
+- [nickschot/ember-mobile-menu] [#791](https://github.com/nickschot/ember-mobile-menu/pull/791) Enable readme/license copying to published addon ([@nickschot])
+- [nickschot/ember-mobile-menu] [#790](https://github.com/nickschot/ember-mobile-menu/pull/790) Remove Travis CI badge ([@nickschot])
+- [nickschot/ember-mobile-menu] [#789](https://github.com/nickschot/ember-mobile-menu/pull/789) Remove v1 addon/cleanup ([@nickschot])
 
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
 [@nickschot]: https://github.com/nickschot
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@zeppelin]: https://github.com/zeppelin
-[ember-fastboot/ember-cli-fastboot]:
-  https://github.com/ember-fastboot/ember-cli-fastboot
+[ember-fastboot/ember-cli-fastboot]: https://github.com/ember-fastboot/ember-cli-fastboot
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [embroider-build/release-plan]: https://github.com/embroider-build/release-plan
-[mainmatter/svelte-promise-modals]:
-  https://github.com/mainmatter/svelte-promise-modals
+[mainmatter/svelte-promise-modals]: https://github.com/mainmatter/svelte-promise-modals
 [marcoow/rust_rest]: https://github.com/marcoow/rust_rest
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
 [sveltejs/kit]: https://github.com/sveltejs/kit
diff --git a/src/twios/2023-11-26.md b/src/twios/2023-11-26.md
index c70b467062..50561acc9d 100644
--- a/src/twios/2023-11-26.md
+++ b/src/twios/2023-11-26.md
@@ -1,164 +1,67 @@
 ## Rust
 
-- [marcoow/rust_rest] [#42](https://github.com/marcoow/rust_rest/pull/42) allow
-  setting bind addr via env vars ([@marcoow])
-- [marcoow/rust_rest] [#41](https://github.com/marcoow/rust_rest/pull/41) move
-  determination of log level into support crate ([@marcoow])
-- [marcoow/rust_rest] [#40](https://github.com/marcoow/rust_rest/pull/40) Add
-  environment-specific content handling ([@marcoow])
-- [marcoow/rust_rest] [#39](https://github.com/marcoow/rust_rest/pull/39)
-  Allowing setting log level via env var ([@marcoow])
-- [marcoow/rust_rest] [#37](https://github.com/marcoow/rust_rest/pull/37)
-  Improve migrations CLI ([@marcoow])
+- [marcoow/rust_rest] [#42](https://github.com/marcoow/rust_rest/pull/42) allow setting bind addr via env vars ([@marcoow])
+- [marcoow/rust_rest] [#41](https://github.com/marcoow/rust_rest/pull/41) move determination of log level into support crate ([@marcoow])
+- [marcoow/rust_rest] [#40](https://github.com/marcoow/rust_rest/pull/40) Add environment-specific content handling ([@marcoow])
+- [marcoow/rust_rest] [#39](https://github.com/marcoow/rust_rest/pull/39) Allowing setting log level via env var ([@marcoow])
+- [marcoow/rust_rest] [#37](https://github.com/marcoow/rust_rest/pull/37) Improve migrations CLI ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/svelte-promise-modals]
-  [#42](https://github.com/mainmatter/svelte-promise-modals/pull/42) Enable
-  analytics via Plausible ([@marcoow])
-- [mainmatter/svelte-promise-modals]
-  [#41](https://github.com/mainmatter/svelte-promise-modals/pull/41) Fix typos
-  in the README ([@marcoow])
-- [mainmatter/svelte-promise-modals]
-  [#39](https://github.com/mainmatter/svelte-promise-modals/pull/39) add
-  standard Mainmatter copyright ([@marcoow])
-- [mainmatter/svelte-promise-modals]
-  [#43](https://github.com/mainmatter/svelte-promise-modals/pull/43) Add
-  user-facing, fix internal types ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#40](https://github.com/mainmatter/svelte-promise-modals/pull/40) API change:
-  spread modal data as props instead of a concrete data object ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#42](https://github.com/mainmatter/svelte-promise-modals/pull/42) Enable analytics via Plausible ([@marcoow])
+- [mainmatter/svelte-promise-modals] [#41](https://github.com/mainmatter/svelte-promise-modals/pull/41) Fix typos in the README ([@marcoow])
+- [mainmatter/svelte-promise-modals] [#39](https://github.com/mainmatter/svelte-promise-modals/pull/39) add standard Mainmatter copyright ([@marcoow])
+- [mainmatter/svelte-promise-modals] [#43](https://github.com/mainmatter/svelte-promise-modals/pull/43) Add user-facing, fix internal types ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#40](https://github.com/mainmatter/svelte-promise-modals/pull/40) API change: spread modal data as props instead of a concrete data object ([@zeppelin])
 
 ## Embroider
 
-- [embroider-build/ember-auto-import]
-  [#598](https://github.com/embroider-build/ember-auto-import/pull/598) Add
-  release-plan for automating releases ([@mansona])
-- [embroider-build/embroider]
-  [#1676](https://github.com/embroider-build/embroider/pull/1676) fix single
-  asterisk replacement in reverse-exports ([@mansona])
+- [embroider-build/ember-auto-import] [#598](https://github.com/embroider-build/ember-auto-import/pull/598) Add release-plan for automating releases ([@mansona])
+- [embroider-build/embroider] [#1676](https://github.com/embroider-build/embroider/pull/1676) fix single asterisk replacement in reverse-exports ([@mansona])
 
 ## JavaScript
 
-- [embroider-build/release-plan]
-  [#25](https://github.com/embroider-build/release-plan/pull/25) remove
-  reference to @embroider ([@mansona])
-- [embroider-build/release-plan]
-  [#24](https://github.com/embroider-build/release-plan/pull/24) add support for
-  npm workspaces ([@mansona])
-- [embroider-build/release-plan]
-  [#23](https://github.com/embroider-build/release-plan/pull/23) use
-  require.resolve to find lerna-changelog ([@mansona])
-- [embroider-build/release-plan]
-  [#22](https://github.com/embroider-build/release-plan/pull/22) remove unused
-  package.json ([@mansona])
-- [embroider-build/release-plan]
-  [#21](https://github.com/embroider-build/release-plan/pull/21) don't throw
-  when we encounter an unknown package ([@mansona])
-- [embroider-build/release-plan]
-  [#20](https://github.com/embroider-build/release-plan/pull/20) fix updating
-  changelog ([@mansona])
-- [embroider-build/release-plan]
-  [#17](https://github.com/embroider-build/release-plan/pull/17) add a basic
-  readme ([@mansona])
-- [embroider-build/release-plan]
-  [#15](https://github.com/embroider-build/release-plan/pull/15) actually use
-  otp when it's provided ([@mansona])
-- [embroider-build/release-plan]
-  [#13](https://github.com/embroider-build/release-plan/pull/13) Fix npm publish
-  ([@mansona])
-- [embroider-build/release-plan]
-  [#11](https://github.com/embroider-build/release-plan/pull/11) Fix publish
-  step ([@mansona])
-- [embroider-build/release-plan]
-  [#7](https://github.com/embroider-build/release-plan/pull/7) use dist/cli.js
-  directly in workflows ([@mansona])
-- [embroider-build/release-plan]
-  [#6](https://github.com/embroider-build/release-plan/pull/6) add workflows for
-  review and release ([@mansona])
-- [embroider-build/release-plan]
-  [#5](https://github.com/embroider-build/release-plan/pull/5) add
-  --single-package option ([@mansona])
-- [embroider-build/release-plan]
-  [#4](https://github.com/embroider-build/release-plan/pull/4) reset version so
-  release-plan will work on itself ([@mansona])
-- [embroider-build/release-plan]
-  [#3](https://github.com/embroider-build/release-plan/pull/3) convert
-  everything to work correctly with ESM ([@mansona])
-- [embroider-build/release-plan]
-  [#2](https://github.com/embroider-build/release-plan/pull/2) revert back from
-  tsup to tsc ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#19](https://github.com/mansona/create-release-plan-setup/pull/19) update
-  plan when a PR is labeled ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#18](https://github.com/mansona/create-release-plan-setup/pull/18) add
-  --singlePackage for CI ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#17](https://github.com/mansona/create-release-plan-setup/pull/17) Update
-  more deps ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#16](https://github.com/mansona/create-release-plan-setup/pull/16) update all
-  dependencies ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#15](https://github.com/mansona/create-release-plan-setup/pull/15) Update
-  preview description ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#13](https://github.com/mansona/create-release-plan-setup/pull/13) setup
-  release-plan ([@mansona])
-- [storybookjs/storybook]
-  [#24955](https://github.com/storybookjs/storybook/pull/24955) SvelteKit:
-  Default to log an action for `goto`, `invalidate` and `invalidateAll`
-  ([@paoloricciuti])
-- [storybookjs/storybook]
-  [#24921](https://github.com/storybookjs/storybook/pull/24921) Svelte: Fix
-  decorators always running twice ([@paoloricciuti])
+- [embroider-build/release-plan] [#25](https://github.com/embroider-build/release-plan/pull/25) remove reference to @embroider ([@mansona])
+- [embroider-build/release-plan] [#24](https://github.com/embroider-build/release-plan/pull/24) add support for npm workspaces ([@mansona])
+- [embroider-build/release-plan] [#23](https://github.com/embroider-build/release-plan/pull/23) use require.resolve to find lerna-changelog ([@mansona])
+- [embroider-build/release-plan] [#22](https://github.com/embroider-build/release-plan/pull/22) remove unused package.json ([@mansona])
+- [embroider-build/release-plan] [#21](https://github.com/embroider-build/release-plan/pull/21) don't throw when we encounter an unknown package ([@mansona])
+- [embroider-build/release-plan] [#20](https://github.com/embroider-build/release-plan/pull/20) fix updating changelog ([@mansona])
+- [embroider-build/release-plan] [#17](https://github.com/embroider-build/release-plan/pull/17) add a basic readme ([@mansona])
+- [embroider-build/release-plan] [#15](https://github.com/embroider-build/release-plan/pull/15) actually use otp when it's provided ([@mansona])
+- [embroider-build/release-plan] [#13](https://github.com/embroider-build/release-plan/pull/13) Fix npm publish ([@mansona])
+- [embroider-build/release-plan] [#11](https://github.com/embroider-build/release-plan/pull/11) Fix publish step ([@mansona])
+- [embroider-build/release-plan] [#7](https://github.com/embroider-build/release-plan/pull/7) use dist/cli.js directly in workflows ([@mansona])
+- [embroider-build/release-plan] [#6](https://github.com/embroider-build/release-plan/pull/6) add workflows for review and release ([@mansona])
+- [embroider-build/release-plan] [#5](https://github.com/embroider-build/release-plan/pull/5) add --single-package option ([@mansona])
+- [embroider-build/release-plan] [#4](https://github.com/embroider-build/release-plan/pull/4) reset version so release-plan will work on itself ([@mansona])
+- [embroider-build/release-plan] [#3](https://github.com/embroider-build/release-plan/pull/3) convert everything to work correctly with ESM ([@mansona])
+- [embroider-build/release-plan] [#2](https://github.com/embroider-build/release-plan/pull/2) revert back from tsup to tsc ([@mansona])
+- [mansona/create-release-plan-setup] [#19](https://github.com/mansona/create-release-plan-setup/pull/19) update plan when a PR is labeled ([@mansona])
+- [mansona/create-release-plan-setup] [#18](https://github.com/mansona/create-release-plan-setup/pull/18) add --singlePackage for CI ([@mansona])
+- [mansona/create-release-plan-setup] [#17](https://github.com/mansona/create-release-plan-setup/pull/17) Update more deps ([@mansona])
+- [mansona/create-release-plan-setup] [#16](https://github.com/mansona/create-release-plan-setup/pull/16) update all dependencies ([@mansona])
+- [mansona/create-release-plan-setup] [#15](https://github.com/mansona/create-release-plan-setup/pull/15) Update preview description ([@mansona])
+- [mansona/create-release-plan-setup] [#13](https://github.com/mansona/create-release-plan-setup/pull/13) setup release-plan ([@mansona])
+- [storybookjs/storybook] [#24955](https://github.com/storybookjs/storybook/pull/24955) SvelteKit: Default to log an action for `goto`, `invalidate` and `invalidateAll` ([@paoloricciuti])
+- [storybookjs/storybook] [#24921](https://github.com/storybookjs/storybook/pull/24921) Svelte: Fix decorators always running twice ([@paoloricciuti])
 
 ## Ember
 
-- [ember-learn/ember-blog]
-  [#1318](https://github.com/ember-learn/ember-blog/pull/1318) add the embroider
-  initiative guest post ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#230](https://github.com/embroider-build/addon-blueprint/pull/230) Add
-  missing files to --addon-only output ([@lolmaus])
-- [mainmatter/ember-promise-modals]
-  [#863](https://github.com/mainmatter/ember-promise-modals/pull/863) Enable
-  analytics via Plausible ([@marcoow])
-- [mainmatter/ember-promise-modals]
-  [#862](https://github.com/mainmatter/ember-promise-modals/pull/862) add proper
-  copyright message ([@marcoow])
-- [mainmatter/ember-promise-modals]
-  [#864](https://github.com/mainmatter/ember-promise-modals/pull/864) WIP Fix ci
-  ([@nickschot])
-- [mansona/ember-cli-notifications]
-  [#367](https://github.com/mansona/ember-cli-notifications/pull/367) setup
-  release-plan ([@mansona])
-- [mansona/ember-cli-notifications]
-  [#366](https://github.com/mansona/ember-cli-notifications/pull/366) fix
-  lint-to-the-future CI job ([@mansona])
-- [mansona/ember-cli-notifications]
-  [#365](https://github.com/mansona/ember-cli-notifications/pull/365) move to a
-  v2 addon ([@mansona])
-- [mixonic/ember-cli-deprecation-workflow]
-  [#178](https://github.com/mixonic/ember-cli-deprecation-workflow/pull/178)
-  Upgrade Ember CLI to 5.4 ([@lolmaus])
-- [nickschot/ember-mobile-menu]
-  [#804](https://github.com/nickschot/ember-mobile-menu/pull/804) WIP re-add
-  support for ember-source v3.28.0 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#802](https://github.com/nickschot/ember-mobile-menu/pull/802) Make
-  tracked-built-ins a peerDependency ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#801](https://github.com/nickschot/ember-mobile-menu/pull/801) Remove
-  node/ember-cli-babel requirements from README.md, fix ember-concurrency
-  requirement. ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#800](https://github.com/nickschot/ember-mobile-menu/pull/800) Specify
-  ember-source >=v4 as a peer dependency ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#798](https://github.com/nickschot/ember-mobile-menu/pull/798) Replace
-  ember-could-get-used-to-this with ember-resources ([@nickschot])
+- [ember-learn/ember-blog] [#1318](https://github.com/ember-learn/ember-blog/pull/1318) add the embroider initiative guest post ([@mansona])
+- [embroider-build/addon-blueprint] [#230](https://github.com/embroider-build/addon-blueprint/pull/230) Add missing files to --addon-only output ([@lolmaus])
+- [mainmatter/ember-promise-modals] [#863](https://github.com/mainmatter/ember-promise-modals/pull/863) Enable analytics via Plausible ([@marcoow])
+- [mainmatter/ember-promise-modals] [#862](https://github.com/mainmatter/ember-promise-modals/pull/862) add proper copyright message ([@marcoow])
+- [mainmatter/ember-promise-modals] [#864](https://github.com/mainmatter/ember-promise-modals/pull/864) WIP Fix ci ([@nickschot])
+- [mansona/ember-cli-notifications] [#367](https://github.com/mansona/ember-cli-notifications/pull/367) setup release-plan ([@mansona])
+- [mansona/ember-cli-notifications] [#366](https://github.com/mansona/ember-cli-notifications/pull/366) fix lint-to-the-future CI job ([@mansona])
+- [mansona/ember-cli-notifications] [#365](https://github.com/mansona/ember-cli-notifications/pull/365) move to a v2 addon ([@mansona])
+- [mixonic/ember-cli-deprecation-workflow] [#178](https://github.com/mixonic/ember-cli-deprecation-workflow/pull/178) Upgrade Ember CLI to 5.4 ([@lolmaus])
+- [nickschot/ember-mobile-menu] [#804](https://github.com/nickschot/ember-mobile-menu/pull/804) WIP re-add support for ember-source v3.28.0 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#802](https://github.com/nickschot/ember-mobile-menu/pull/802) Make tracked-built-ins a peerDependency ([@nickschot])
+- [nickschot/ember-mobile-menu] [#801](https://github.com/nickschot/ember-mobile-menu/pull/801) Remove node/ember-cli-babel requirements from README.md, fix ember-concurrency requirement. ([@nickschot])
+- [nickschot/ember-mobile-menu] [#800](https://github.com/nickschot/ember-mobile-menu/pull/800) Specify ember-source >=v4 as a peer dependency ([@nickschot])
+- [nickschot/ember-mobile-menu] [#798](https://github.com/nickschot/ember-mobile-menu/pull/798) Replace ember-could-get-used-to-this with ember-resources ([@nickschot])
 
 [@lolmaus]: https://github.com/lolmaus
 [@mansona]: https://github.com/mansona
@@ -167,22 +70,15 @@
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@zeppelin]: https://github.com/zeppelin
 [ember-learn/ember-blog]: https://github.com/ember-learn/ember-blog
-[embroider-build/addon-blueprint]:
-  https://github.com/embroider-build/addon-blueprint
-[embroider-build/ember-auto-import]:
-  https://github.com/embroider-build/ember-auto-import
+[embroider-build/addon-blueprint]: https://github.com/embroider-build/addon-blueprint
+[embroider-build/ember-auto-import]: https://github.com/embroider-build/ember-auto-import
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [embroider-build/release-plan]: https://github.com/embroider-build/release-plan
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
-[mainmatter/svelte-promise-modals]:
-  https://github.com/mainmatter/svelte-promise-modals
-[mansona/create-release-plan-setup]:
-  https://github.com/mansona/create-release-plan-setup
-[mansona/ember-cli-notifications]:
-  https://github.com/mansona/ember-cli-notifications
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
+[mainmatter/svelte-promise-modals]: https://github.com/mainmatter/svelte-promise-modals
+[mansona/create-release-plan-setup]: https://github.com/mansona/create-release-plan-setup
+[mansona/ember-cli-notifications]: https://github.com/mansona/ember-cli-notifications
 [marcoow/rust_rest]: https://github.com/marcoow/rust_rest
-[mixonic/ember-cli-deprecation-workflow]:
-  https://github.com/mixonic/ember-cli-deprecation-workflow
+[mixonic/ember-cli-deprecation-workflow]: https://github.com/mixonic/ember-cli-deprecation-workflow
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
 [storybookjs/storybook]: https://github.com/storybookjs/storybook
diff --git a/src/twios/2023-12-10.md b/src/twios/2023-12-10.md
index 031e730327..df198aa70a 100644
--- a/src/twios/2023-12-10.md
+++ b/src/twios/2023-12-10.md
@@ -1,216 +1,92 @@
 ## Rust
 
-- [marcoow/pacesetter] [#12](https://github.com/marcoow/pacesetter/pull/12)
-  Cleanup ([@marcoow])
-- [marcoow/pacesetter] [#11](https://github.com/marcoow/pacesetter/pull/11)
-  rename templates folder to blueprints ([@marcoow])
-- [marcoow/pacesetter] [#10](https://github.com/marcoow/pacesetter/pull/10) add
-  minimal example without db ([@marcoow])
-- [marcoow/pacesetter] [#9](https://github.com/marcoow/pacesetter/pull/9) Add
-  empty default blueprint ([@marcoow])
-- [marcoow/pacesetter] [#8](https://github.com/marcoow/pacesetter/pull/8) Add
-  full example ([@marcoow])
-- [marcoow/pacesetter] [#7](https://github.com/marcoow/pacesetter/pull/7) add
-  .gitignore to template ([@marcoow])
-- [marcoow/pacesetter] [#6](https://github.com/marcoow/pacesetter/pull/6) Better
-  template dev experience ([@marcoow])
-- [marcoow/pacesetter] [#5](https://github.com/marcoow/pacesetter/pull/5)
-  Improve example test ([@marcoow])
-- [marcoow/pacesetter] [#4](https://github.com/marcoow/pacesetter/pull/4) update
-  all dependencies ([@marcoow])
-- [marcoow/pacesetter] [#3](https://github.com/marcoow/pacesetter/pull/3) update
-  axum to 0.7 ([@marcoow])
-- [marcoow/pacesetter] [#2](https://github.com/marcoow/pacesetter/pull/2) Cli
-  ([@marcoow])
-- [marcoow/pacesetter] [#1](https://github.com/marcoow/pacesetter/pull/1) Set up
-  CI ([@marcoow])
-- [marcoow/rust_rest] [#55](https://github.com/marcoow/rust_rest/pull/55) fix
-  config loading in tests ([@marcoow])
-- [marcoow/rust_rest] [#54](https://github.com/marcoow/rust_rest/pull/54) remove
-  unused elements from app state ([@marcoow])
+- [marcoow/pacesetter] [#12](https://github.com/marcoow/pacesetter/pull/12) Cleanup ([@marcoow])
+- [marcoow/pacesetter] [#11](https://github.com/marcoow/pacesetter/pull/11) rename templates folder to blueprints ([@marcoow])
+- [marcoow/pacesetter] [#10](https://github.com/marcoow/pacesetter/pull/10) add minimal example without db ([@marcoow])
+- [marcoow/pacesetter] [#9](https://github.com/marcoow/pacesetter/pull/9) Add empty default blueprint ([@marcoow])
+- [marcoow/pacesetter] [#8](https://github.com/marcoow/pacesetter/pull/8) Add full example ([@marcoow])
+- [marcoow/pacesetter] [#7](https://github.com/marcoow/pacesetter/pull/7) add .gitignore to template ([@marcoow])
+- [marcoow/pacesetter] [#6](https://github.com/marcoow/pacesetter/pull/6) Better template dev experience ([@marcoow])
+- [marcoow/pacesetter] [#5](https://github.com/marcoow/pacesetter/pull/5) Improve example test ([@marcoow])
+- [marcoow/pacesetter] [#4](https://github.com/marcoow/pacesetter/pull/4) update all dependencies ([@marcoow])
+- [marcoow/pacesetter] [#3](https://github.com/marcoow/pacesetter/pull/3) update axum to 0.7 ([@marcoow])
+- [marcoow/pacesetter] [#2](https://github.com/marcoow/pacesetter/pull/2) Cli ([@marcoow])
+- [marcoow/pacesetter] [#1](https://github.com/marcoow/pacesetter/pull/1) Set up CI ([@marcoow])
+- [marcoow/rust_rest] [#55](https://github.com/marcoow/rust_rest/pull/55) fix config loading in tests ([@marcoow])
+- [marcoow/rust_rest] [#54](https://github.com/marcoow/rust_rest/pull/54) remove unused elements from app state ([@marcoow])
 
 ## Svelte
 
-- [SvelteLab/SvelteLab] [#291](https://github.com/SvelteLab/SvelteLab/pull/291)
-  feat: add advent of code templates ([@paoloricciuti])
-- [mainmatter/svelte-promise-modals]
-  [#50](https://github.com/mainmatter/svelte-promise-modals/pull/50) Add support
-  for custom `className` ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#49](https://github.com/mainmatter/svelte-promise-modals/pull/49) Destroy
-  modal when parent component gets destroyed ([@zeppelin])
-- [paoloricciuti/sveltekit-search-params]
-  [#47](https://github.com/paoloricciuti/sveltekit-search-params/pull/47) fix:
-  type ssp array ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#291](https://github.com/SvelteLab/SvelteLab/pull/291) feat: add advent of code templates ([@paoloricciuti])
+- [mainmatter/svelte-promise-modals] [#50](https://github.com/mainmatter/svelte-promise-modals/pull/50) Add support for custom `className` ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#49](https://github.com/mainmatter/svelte-promise-modals/pull/49) Destroy modal when parent component gets destroyed ([@zeppelin])
+- [paoloricciuti/sveltekit-search-params] [#47](https://github.com/paoloricciuti/sveltekit-search-params/pull/47) fix: type ssp array ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/ember-auto-import]
-  [#604](https://github.com/embroider-build/ember-auto-import/pull/604) update
-  release-plan ([@mansona])
-- [embroider-build/embroider]
-  [#1714](https://github.com/embroider-build/embroider/pull/1714) update
-  scenario-tester ([@mansona])
-- [embroider-build/embroider]
-  [#1713](https://github.com/embroider-build/embroider/pull/1713) esbuild: fix
-  babel config location ([@mansona])
-- [embroider-build/embroider]
-  [#1704](https://github.com/embroider-build/embroider/pull/1704) add correct
-  extensions to optimizeDeps() config ([@mansona])
-- [embroider-build/embroider]
-  [#1700](https://github.com/embroider-build/embroider/pull/1700) Merge stable
-  into main ([@mansona])
-- [embroider-build/embroider]
-  [#1698](https://github.com/embroider-build/embroider/pull/1698) Use release
-  plan ([@mansona])
-- [embroider-build/scenario-tester]
-  [#26](https://github.com/embroider-build/scenario-tester/pull/26) setup
-  release-plan ([@mansona])
-- [embroider-build/scenario-tester]
-  [#25](https://github.com/embroider-build/scenario-tester/pull/25) fix types
-  discovery for node10 projects ([@mansona])
+- [embroider-build/ember-auto-import] [#604](https://github.com/embroider-build/ember-auto-import/pull/604) update release-plan ([@mansona])
+- [embroider-build/embroider] [#1714](https://github.com/embroider-build/embroider/pull/1714) update scenario-tester ([@mansona])
+- [embroider-build/embroider] [#1713](https://github.com/embroider-build/embroider/pull/1713) esbuild: fix babel config location ([@mansona])
+- [embroider-build/embroider] [#1704](https://github.com/embroider-build/embroider/pull/1704) add correct extensions to optimizeDeps() config ([@mansona])
+- [embroider-build/embroider] [#1700](https://github.com/embroider-build/embroider/pull/1700) Merge stable into main ([@mansona])
+- [embroider-build/embroider] [#1698](https://github.com/embroider-build/embroider/pull/1698) Use release plan ([@mansona])
+- [embroider-build/scenario-tester] [#26](https://github.com/embroider-build/scenario-tester/pull/26) setup release-plan ([@mansona])
+- [embroider-build/scenario-tester] [#25](https://github.com/embroider-build/scenario-tester/pull/25) fix types discovery for node10 projects ([@mansona])
 
 ## Empress
 
-- [empress/guidemaker] [#98](https://github.com/empress/guidemaker/pull/98)
-  update and fix release-plan ([@mansona])
-- [empress/guidemaker] [#97](https://github.com/empress/guidemaker/pull/97)
-  Setup release-plan ([@mansona])
+- [empress/guidemaker] [#98](https://github.com/empress/guidemaker/pull/98) update and fix release-plan ([@mansona])
+- [empress/guidemaker] [#97](https://github.com/empress/guidemaker/pull/97) Setup release-plan ([@mansona])
 
 ## JavaScript
 
-- [ef4/lerna-changelog] [#6](https://github.com/ef4/lerna-changelog/pull/6) drop
-  support for node < 16 ([@mansona])
-- [ef4/lerna-changelog] [#4](https://github.com/ef4/lerna-changelog/pull/4)
-  Update release-plan workflows ([@mansona])
-- [ef4/lerna-changelog] [#3](https://github.com/ef4/lerna-changelog/pull/3)
-  running npm init release-plan-setup ([@mansona])
-- [ef4/lerna-changelog] [#2](https://github.com/ef4/lerna-changelog/pull/2)
-  Update changelog and readme badges ([@mansona])
-- [embroider-build/release-plan]
-  [#35](https://github.com/embroider-build/release-plan/pull/35) fix pnpm
-  package discovery bug ([@mansona])
-- [embroider-build/release-plan]
-  [#34](https://github.com/embroider-build/release-plan/pull/34) Fix pnpm
-  package discovery ([@mansona])
-- [embroider-build/release-plan]
-  [#32](https://github.com/embroider-build/release-plan/pull/32) update
-  lerna-changelog ([@mansona])
-- [embroider-build/release-plan]
-  [#30](https://github.com/embroider-build/release-plan/pull/30) add shebang
-  back and fix linting config ([@mansona])
-- [embroider-build/release-plan]
-  [#29](https://github.com/embroider-build/release-plan/pull/29) Add linting and
-  check it in CI ([@mansona])
-- [embroider-build/release-plan]
-  [#28](https://github.com/embroider-build/release-plan/pull/28) pick the
-  correct package manager to do npm publish ([@mansona])
-- [embroider-build/release-plan]
-  [#27](https://github.com/embroider-build/release-plan/pull/27) run npm init
-  release-plan-setup --update ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#40](https://github.com/mansona/create-release-plan-setup/pull/40) update
-  release-plan ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#39](https://github.com/mansona/create-release-plan-setup/pull/39) update
-  release-plan ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#36](https://github.com/mansona/create-release-plan-setup/pull/36) batch
-  dependabot updates for minor or patch dev deps ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#34](https://github.com/mansona/create-release-plan-setup/pull/34) add
-  discovered default branch to plan-release CI ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#31](https://github.com/mansona/create-release-plan-setup/pull/31) don't
-  create a new release plan PR when releasing ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#30](https://github.com/mansona/create-release-plan-setup/pull/30) read the
-  default branch from remote ([@mansona])
-- [stefanpenner/node-fixturify-project]
-  [#87](https://github.com/stefanpenner/node-fixturify-project/pull/87) Fix #86
-  Files leak across instances of Project ([@lolmaus])
-- [storybookjs/storybook]
-  [#25132](https://github.com/storybookjs/storybook/pull/25132) SvelteKit: Fix
-  missing `$app` modules ([@paoloricciuti])
+- [ef4/lerna-changelog] [#6](https://github.com/ef4/lerna-changelog/pull/6) drop support for node < 16 ([@mansona])
+- [ef4/lerna-changelog] [#4](https://github.com/ef4/lerna-changelog/pull/4) Update release-plan workflows ([@mansona])
+- [ef4/lerna-changelog] [#3](https://github.com/ef4/lerna-changelog/pull/3) running npm init release-plan-setup ([@mansona])
+- [ef4/lerna-changelog] [#2](https://github.com/ef4/lerna-changelog/pull/2) Update changelog and readme badges ([@mansona])
+- [embroider-build/release-plan] [#35](https://github.com/embroider-build/release-plan/pull/35) fix pnpm package discovery bug ([@mansona])
+- [embroider-build/release-plan] [#34](https://github.com/embroider-build/release-plan/pull/34) Fix pnpm package discovery ([@mansona])
+- [embroider-build/release-plan] [#32](https://github.com/embroider-build/release-plan/pull/32) update lerna-changelog ([@mansona])
+- [embroider-build/release-plan] [#30](https://github.com/embroider-build/release-plan/pull/30) add shebang back and fix linting config ([@mansona])
+- [embroider-build/release-plan] [#29](https://github.com/embroider-build/release-plan/pull/29) Add linting and check it in CI ([@mansona])
+- [embroider-build/release-plan] [#28](https://github.com/embroider-build/release-plan/pull/28) pick the correct package manager to do npm publish ([@mansona])
+- [embroider-build/release-plan] [#27](https://github.com/embroider-build/release-plan/pull/27) run npm init release-plan-setup --update ([@mansona])
+- [mansona/create-release-plan-setup] [#40](https://github.com/mansona/create-release-plan-setup/pull/40) update release-plan ([@mansona])
+- [mansona/create-release-plan-setup] [#39](https://github.com/mansona/create-release-plan-setup/pull/39) update release-plan ([@mansona])
+- [mansona/create-release-plan-setup] [#36](https://github.com/mansona/create-release-plan-setup/pull/36) batch dependabot updates for minor or patch dev deps ([@mansona])
+- [mansona/create-release-plan-setup] [#34](https://github.com/mansona/create-release-plan-setup/pull/34) add discovered default branch to plan-release CI ([@mansona])
+- [mansona/create-release-plan-setup] [#31](https://github.com/mansona/create-release-plan-setup/pull/31) don't create a new release plan PR when releasing ([@mansona])
+- [mansona/create-release-plan-setup] [#30](https://github.com/mansona/create-release-plan-setup/pull/30) read the default branch from remote ([@mansona])
+- [stefanpenner/node-fixturify-project] [#87](https://github.com/stefanpenner/node-fixturify-project/pull/87) Fix #86 Files leak across instances of Project ([@lolmaus])
+- [storybookjs/storybook] [#25132](https://github.com/storybookjs/storybook/pull/25132) SvelteKit: Fix missing `$app` modules ([@paoloricciuti])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#219](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/219)
-  Grammalecte install guide, improve and fix contributing guide
-  ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#218](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/218) Align
-  tutorial/part-2 titles with index and recap ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#217](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/217)
-  Translate guides/tutorial/part-2/recap.md ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#216](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/216)
-  Translate guides/tutorial/part-2/index.md ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#215](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/215) Catch
-  up latest docs: from 5.1 to 5.4 ([@BlueCutOfficial])
-- [ember-codemods/ember-angle-brackets-codemod]
-  [#512](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/512)
-  move to pnpm ([@mansona])
-- [ember-codemods/ember-angle-brackets-codemod]
-  [#511](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/511)
-  drop support for node < 16 ([@mansona])
-- [ember-codemods/ember-angle-brackets-codemod]
-  [#510](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/510)
-  setup release-plan ([@mansona])
-- [ember-codemods/ember-angle-brackets-codemod]
-  [#508](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/508)
-  Update fixtures using ember-cli-update ([@mansona])
-- [ember-codemods/ember-angle-brackets-codemod]
-  [#509](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/509)
-  Make helpers unambiguious with parens aka subexpressions ([@lolmaus])
-- [ember-codemods/ember-native-class-codemod]
-  [#546](https://github.com/ember-codemods/ember-native-class-codemod/pull/546)
-  start using release-plan ([@mansona])
-- [ember-codemods/ember-native-class-codemod]
-  [#545](https://github.com/ember-codemods/ember-native-class-codemod/pull/545)
-  convert to pnpm ([@mansona])
-- [ember-codemods/ember-native-class-codemod]
-  [#544](https://github.com/ember-codemods/ember-native-class-codemod/pull/544)
-  drop support for node 14 ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#900](https://github.com/ember-learn/ember-api-docs/pull/900) update
-  node-sass and ember-auto-import ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#899](https://github.com/ember-learn/ember-api-docs/pull/899) fix extra < on
-  ember-data-landing-page ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#898](https://github.com/ember-learn/ember-api-docs/pull/898) update
-  lint-to-the-future ([@mansona])
-- [emberjs/rfcs] [#993](https://github.com/emberjs/rfcs/pull/993) Let the app
-  define Testem middleware in testem.js rather than implicitly import middleware
-  only from v1 addons ([@lolmaus])
-- [embroider-build/addon-blueprint]
-  [#236](https://github.com/embroider-build/addon-blueprint/pull/236) remove
-  release-it & upgrade release-plan ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#232](https://github.com/embroider-build/addon-blueprint/pull/232) Readme:
-  minor formatting fix ([@lolmaus])
-- [nickschot/ember-gesture-modifiers]
-  [#556](https://github.com/nickschot/ember-gesture-modifiers/pull/556) Convert
-  to V2 addon ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#555](https://github.com/nickschot/ember-gesture-modifiers/pull/555) Update
-  prettier to v3 ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#554](https://github.com/nickschot/ember-gesture-modifiers/pull/554) Replace
-  yarn with pnpm ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#541](https://github.com/nickschot/ember-gesture-modifiers/pull/541) Drop
-  Node 16 support ([@nickschot])
-- [nickschot/ember-gesture-modifiers]
-  [#540](https://github.com/nickschot/ember-gesture-modifiers/pull/540) Drop
-  Node 14 support ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#827](https://github.com/nickschot/ember-mobile-menu/pull/827) Add
-  ember-gesture-modifiers v6 to allowed range ([@nickschot])
+- [DazzlingFugu/ember-fr-guides-source] [#219](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/219) Grammalecte install guide, improve and fix contributing guide ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#218](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/218) Align tutorial/part-2 titles with index and recap ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#217](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/217) Translate guides/tutorial/part-2/recap.md ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#216](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/216) Translate guides/tutorial/part-2/index.md ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#215](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/215) Catch up latest docs: from 5.1 to 5.4 ([@BlueCutOfficial])
+- [ember-codemods/ember-angle-brackets-codemod] [#512](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/512) move to pnpm ([@mansona])
+- [ember-codemods/ember-angle-brackets-codemod] [#511](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/511) drop support for node < 16 ([@mansona])
+- [ember-codemods/ember-angle-brackets-codemod] [#510](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/510) setup release-plan ([@mansona])
+- [ember-codemods/ember-angle-brackets-codemod] [#508](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/508) Update fixtures using ember-cli-update ([@mansona])
+- [ember-codemods/ember-angle-brackets-codemod] [#509](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/509) Make helpers unambiguious with parens aka subexpressions ([@lolmaus])
+- [ember-codemods/ember-native-class-codemod] [#546](https://github.com/ember-codemods/ember-native-class-codemod/pull/546) start using release-plan ([@mansona])
+- [ember-codemods/ember-native-class-codemod] [#545](https://github.com/ember-codemods/ember-native-class-codemod/pull/545) convert to pnpm ([@mansona])
+- [ember-codemods/ember-native-class-codemod] [#544](https://github.com/ember-codemods/ember-native-class-codemod/pull/544) drop support for node 14 ([@mansona])
+- [ember-learn/ember-api-docs] [#900](https://github.com/ember-learn/ember-api-docs/pull/900) update node-sass and ember-auto-import ([@mansona])
+- [ember-learn/ember-api-docs] [#899](https://github.com/ember-learn/ember-api-docs/pull/899) fix extra < on ember-data-landing-page ([@mansona])
+- [ember-learn/ember-api-docs] [#898](https://github.com/ember-learn/ember-api-docs/pull/898) update lint-to-the-future ([@mansona])
+- [emberjs/rfcs] [#993](https://github.com/emberjs/rfcs/pull/993) Let the app define Testem middleware in testem.js rather than implicitly import middleware only from v1 addons ([@lolmaus])
+- [embroider-build/addon-blueprint] [#236](https://github.com/embroider-build/addon-blueprint/pull/236) remove release-it & upgrade release-plan ([@mansona])
+- [embroider-build/addon-blueprint] [#232](https://github.com/embroider-build/addon-blueprint/pull/232) Readme: minor formatting fix ([@lolmaus])
+- [nickschot/ember-gesture-modifiers] [#556](https://github.com/nickschot/ember-gesture-modifiers/pull/556) Convert to V2 addon ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#555](https://github.com/nickschot/ember-gesture-modifiers/pull/555) Update prettier to v3 ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#554](https://github.com/nickschot/ember-gesture-modifiers/pull/554) Replace yarn with pnpm ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#541](https://github.com/nickschot/ember-gesture-modifiers/pull/541) Drop Node 16 support ([@nickschot])
+- [nickschot/ember-gesture-modifiers] [#540](https://github.com/nickschot/ember-gesture-modifiers/pull/540) Drop Node 14 support ([@nickschot])
+- [nickschot/ember-mobile-menu] [#827](https://github.com/nickschot/ember-mobile-menu/pull/827) Add ember-gesture-modifiers v6 to allowed range ([@nickschot])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@lolmaus]: https://github.com/lolmaus
@@ -219,36 +95,25 @@
 [@nickschot]: https://github.com/nickschot
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@zeppelin]: https://github.com/zeppelin
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [sveltelab/sveltelab]: https://github.com/SvelteLab/SvelteLab
 [ef4/lerna-changelog]: https://github.com/ef4/lerna-changelog
-[ember-codemods/ember-angle-brackets-codemod]:
-  https://github.com/ember-codemods/ember-angle-brackets-codemod
-[ember-codemods/ember-native-class-codemod]:
-  https://github.com/ember-codemods/ember-native-class-codemod
+[ember-codemods/ember-angle-brackets-codemod]: https://github.com/ember-codemods/ember-angle-brackets-codemod
+[ember-codemods/ember-native-class-codemod]: https://github.com/ember-codemods/ember-native-class-codemod
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
 [emberjs/rfcs]: https://github.com/emberjs/rfcs
-[embroider-build/addon-blueprint]:
-  https://github.com/embroider-build/addon-blueprint
-[embroider-build/ember-auto-import]:
-  https://github.com/embroider-build/ember-auto-import
+[embroider-build/addon-blueprint]: https://github.com/embroider-build/addon-blueprint
+[embroider-build/ember-auto-import]: https://github.com/embroider-build/ember-auto-import
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [embroider-build/release-plan]: https://github.com/embroider-build/release-plan
-[embroider-build/scenario-tester]:
-  https://github.com/embroider-build/scenario-tester
+[embroider-build/scenario-tester]: https://github.com/embroider-build/scenario-tester
 [empress/guidemaker]: https://github.com/empress/guidemaker
-[mainmatter/svelte-promise-modals]:
-  https://github.com/mainmatter/svelte-promise-modals
-[mansona/create-release-plan-setup]:
-  https://github.com/mansona/create-release-plan-setup
+[mainmatter/svelte-promise-modals]: https://github.com/mainmatter/svelte-promise-modals
+[mansona/create-release-plan-setup]: https://github.com/mansona/create-release-plan-setup
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [marcoow/rust_rest]: https://github.com/marcoow/rust_rest
-[nickschot/ember-gesture-modifiers]:
-  https://github.com/nickschot/ember-gesture-modifiers
+[nickschot/ember-gesture-modifiers]: https://github.com/nickschot/ember-gesture-modifiers
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
-[paoloricciuti/sveltekit-search-params]:
-  https://github.com/paoloricciuti/sveltekit-search-params
-[stefanpenner/node-fixturify-project]:
-  https://github.com/stefanpenner/node-fixturify-project
+[paoloricciuti/sveltekit-search-params]: https://github.com/paoloricciuti/sveltekit-search-params
+[stefanpenner/node-fixturify-project]: https://github.com/stefanpenner/node-fixturify-project
 [storybookjs/storybook]: https://github.com/storybookjs/storybook
diff --git a/src/twios/2024-01-07.md b/src/twios/2024-01-07.md
index c1a88ee717..659447f778 100644
--- a/src/twios/2024-01-07.md
+++ b/src/twios/2024-01-07.md
@@ -1,57 +1,31 @@
 ## Rust
 
-- [marcoow/pacesetter] [#26](https://github.com/marcoow/pacesetter/pull/26)
-  Generators for entities, entity-test-helpers, controllers, controller-tests
-  ([@marcoow])
-- [marcoow/pacesetter] [#25](https://github.com/marcoow/pacesetter/pull/25) add
-  update example ([@marcoow])
-- [marcoow/pacesetter] [#24](https://github.com/marcoow/pacesetter/pull/24) add
-  deletion example ([@marcoow])
+- [marcoow/pacesetter] [#26](https://github.com/marcoow/pacesetter/pull/26) Generators for entities, entity-test-helpers, controllers, controller-tests ([@marcoow])
+- [marcoow/pacesetter] [#25](https://github.com/marcoow/pacesetter/pull/25) add update example ([@marcoow])
+- [marcoow/pacesetter] [#24](https://github.com/marcoow/pacesetter/pull/24) add deletion example ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/svelte-promise-modals]
-  [#55](https://github.com/mainmatter/svelte-promise-modals/pull/55) Update
-  license year ([@zeppelin])
-- [paoloricciuti/svelte-client-components]
-  [#3](https://github.com/paoloricciuti/svelte-client-components/pull/3) Create
-  CONTRIBUTING.md ([@paoloricciuti])
+- [mainmatter/svelte-promise-modals] [#55](https://github.com/mainmatter/svelte-promise-modals/pull/55) Update license year ([@zeppelin])
+- [paoloricciuti/svelte-client-components] [#3](https://github.com/paoloricciuti/svelte-client-components/pull/3) Create CONTRIBUTING.md ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/scenario-tester]
-  [#30](https://github.com/embroider-build/scenario-tester/pull/30) Allow you to
-  call skip twice with the same name ([@mansona])
-- [embroider-build/scenario-tester]
-  [#28](https://github.com/embroider-build/scenario-tester/pull/28) fix
-  changelog header ([@mansona])
-- [embroider-build/scenario-tester]
-  [#27](https://github.com/embroider-build/scenario-tester/pull/27) convert to
-  pnpm ([@mansona])
+- [embroider-build/scenario-tester] [#30](https://github.com/embroider-build/scenario-tester/pull/30) Allow you to call skip twice with the same name ([@mansona])
+- [embroider-build/scenario-tester] [#28](https://github.com/embroider-build/scenario-tester/pull/28) fix changelog header ([@mansona])
+- [embroider-build/scenario-tester] [#27](https://github.com/embroider-build/scenario-tester/pull/27) convert to pnpm ([@mansona])
 
 ## JavaScript
 
-- [mansona/create-release-plan-setup]
-  [#56](https://github.com/mansona/create-release-plan-setup/pull/56) always
-  update existing files ([@mansona])
+- [mansona/create-release-plan-setup] [#56](https://github.com/mansona/create-release-plan-setup/pull/56) always update existing files ([@mansona])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#236](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/236)
-  Improve catchup script ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#234](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/234) Set
-  HTML page main language to fr ([@BlueCutOfficial])
-- [ember-learn/deprecation-app]
-  [#1366](https://github.com/ember-learn/deprecation-app/pull/1366) update
-  ember-showdown-prism ([@mansona])
-- [mainmatter/ember-asset-size-action]
-  [#79](https://github.com/mainmatter/ember-asset-size-action/pull/79) Update
-  license year ([@zeppelin])
-- [nickschot/ember-mobile-pane]
-  [#48](https://github.com/nickschot/ember-mobile-pane/pull/48) Import htmlSafe
-  from @ember/template instead of @ember/string ([@nickschot])
+- [DazzlingFugu/ember-fr-guides-source] [#236](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/236) Improve catchup script ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#234](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/234) Set HTML page main language to fr ([@BlueCutOfficial])
+- [ember-learn/deprecation-app] [#1366](https://github.com/ember-learn/deprecation-app/pull/1366) update ember-showdown-prism ([@mansona])
+- [mainmatter/ember-asset-size-action] [#79](https://github.com/mainmatter/ember-asset-size-action/pull/79) Update license year ([@zeppelin])
+- [nickschot/ember-mobile-pane] [#48](https://github.com/nickschot/ember-mobile-pane/pull/48) Import htmlSafe from @ember/template instead of @ember/string ([@nickschot])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
@@ -59,18 +33,12 @@
 [@nickschot]: https://github.com/nickschot
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@zeppelin]: https://github.com/zeppelin
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [ember-learn/deprecation-app]: https://github.com/ember-learn/deprecation-app
-[embroider-build/scenario-tester]:
-  https://github.com/embroider-build/scenario-tester
-[mainmatter/ember-asset-size-action]:
-  https://github.com/mainmatter/ember-asset-size-action
-[mainmatter/svelte-promise-modals]:
-  https://github.com/mainmatter/svelte-promise-modals
-[mansona/create-release-plan-setup]:
-  https://github.com/mansona/create-release-plan-setup
+[embroider-build/scenario-tester]: https://github.com/embroider-build/scenario-tester
+[mainmatter/ember-asset-size-action]: https://github.com/mainmatter/ember-asset-size-action
+[mainmatter/svelte-promise-modals]: https://github.com/mainmatter/svelte-promise-modals
+[mansona/create-release-plan-setup]: https://github.com/mansona/create-release-plan-setup
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [nickschot/ember-mobile-pane]: https://github.com/nickschot/ember-mobile-pane
-[paoloricciuti/svelte-client-components]:
-  https://github.com/paoloricciuti/svelte-client-components
+[paoloricciuti/svelte-client-components]: https://github.com/paoloricciuti/svelte-client-components
diff --git a/src/twios/2024-01-14.md b/src/twios/2024-01-14.md
index 5408e54093..3c1461bf01 100644
--- a/src/twios/2024-01-14.md
+++ b/src/twios/2024-01-14.md
@@ -1,68 +1,39 @@
 ## Raycast
 
-- [raycast/extensions]
-  [#10050](https://github.com/raycast/extensions/pull/10050) Add svelte-docs
-  extension ([@paoloricciuti])
+- [raycast/extensions] [#10050](https://github.com/raycast/extensions/pull/10050) Add svelte-docs extension ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1753](https://github.com/embroider-build/embroider/pull/1753) Use
-  fixturify-project version with leaks fixed ([@lolmaus])
-- [embroider-build/github-changelog]
-  [#10](https://github.com/embroider-build/github-changelog/pull/10) update
-  release-plan setup ([@mansona])
-- [embroider-build/scenario-tester]
-  [#32](https://github.com/embroider-build/scenario-tester/pull/32) fix docs
-  build ([@mansona])
+- [embroider-build/embroider] [#1753](https://github.com/embroider-build/embroider/pull/1753) Use fixturify-project version with leaks fixed ([@lolmaus])
+- [embroider-build/github-changelog] [#10](https://github.com/embroider-build/github-changelog/pull/10) update release-plan setup ([@mansona])
+- [embroider-build/scenario-tester] [#32](https://github.com/embroider-build/scenario-tester/pull/32) fix docs build ([@mansona])
 
 ## JavaScript
 
-- [ember-learn/ember-jsonapi-docs]
-  [#137](https://github.com/ember-learn/ember-jsonapi-docs/pull/137) emit
-  markdown for descriptions ([@mansona])
-- [lifeart/glimmer-next] [#22](https://github.com/lifeart/glimmer-next/pull/22)
-  Add tests for each loop ([@lolmaus])
+- [ember-learn/ember-jsonapi-docs] [#137](https://github.com/ember-learn/ember-jsonapi-docs/pull/137) emit markdown for descriptions ([@mansona])
+- [lifeart/glimmer-next] [#22](https://github.com/lifeart/glimmer-next/pull/22) Add tests for each loop ([@lolmaus])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#237](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/237)
-  Improve catchup script 2 ([@BlueCutOfficial])
-- [ember-learn/ember-api-docs]
-  [#902](https://github.com/ember-learn/ember-api-docs/pull/902) use
-  ember-showdown-prism ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#25](https://github.com/ember-learn/ember-api-docs-data/pull/25) Use Markdown
-  for all descriptions ([@mansona])
-- [mainmatter/ember-cookies]
-  [#901](https://github.com/mainmatter/ember-cookies/pull/901) chore(ci): use
-  pull_request_target event to allow continue-on-error-comment to work for forks
-  ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2712](https://github.com/mainmatter/ember-simple-auth/pull/2712)
-  chore(docs): begin migrating docs to jsdoc ([@BobrImperator])
-- [mainmatter/qunit-dom]
-  [#2090](https://github.com/mainmatter/qunit-dom/pull/2090) Support ShadowRoot,
-  add tests for rootElement, fixes #2089 ([@lolmaus])
+- [DazzlingFugu/ember-fr-guides-source] [#237](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/237) Improve catchup script 2 ([@BlueCutOfficial])
+- [ember-learn/ember-api-docs] [#902](https://github.com/ember-learn/ember-api-docs/pull/902) use ember-showdown-prism ([@mansona])
+- [ember-learn/ember-api-docs-data] [#25](https://github.com/ember-learn/ember-api-docs-data/pull/25) Use Markdown for all descriptions ([@mansona])
+- [mainmatter/ember-cookies] [#901](https://github.com/mainmatter/ember-cookies/pull/901) chore(ci): use pull_request_target event to allow continue-on-error-comment to work for forks ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2712](https://github.com/mainmatter/ember-simple-auth/pull/2712) chore(docs): begin migrating docs to jsdoc ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2090](https://github.com/mainmatter/qunit-dom/pull/2090) Support ShadowRoot, add tests for rootElement, fixes #2089 ([@lolmaus])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@bobrimperator]: https://github.com/BobrImperator
 [@lolmaus]: https://github.com/lolmaus
 [@mansona]: https://github.com/mansona
 [@paoloricciuti]: https://github.com/paoloricciuti
-[dazzlingfugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
+[dazzlingfugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
-[ember-learn/ember-jsonapi-docs]:
-  https://github.com/ember-learn/ember-jsonapi-docs
+[ember-learn/ember-jsonapi-docs]: https://github.com/ember-learn/ember-jsonapi-docs
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[embroider-build/github-changelog]:
-  https://github.com/embroider-build/github-changelog
-[embroider-build/scenario-tester]:
-  https://github.com/embroider-build/scenario-tester
+[embroider-build/github-changelog]: https://github.com/embroider-build/github-changelog
+[embroider-build/scenario-tester]: https://github.com/embroider-build/scenario-tester
 [lifeart/glimmer-next]: https://github.com/lifeart/glimmer-next
 [mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
diff --git a/src/twios/2024-01-21.md b/src/twios/2024-01-21.md
index 41026bd854..0483d1e284 100644
--- a/src/twios/2024-01-21.md
+++ b/src/twios/2024-01-21.md
@@ -1,91 +1,46 @@
 ## Rust
 
-- [marcoow/pacesetter] [#27](https://github.com/marcoow/pacesetter/pull/27) fix
-  controller and controller tests in full blueprint ([@marcoow])
+- [marcoow/pacesetter] [#27](https://github.com/marcoow/pacesetter/pull/27) fix controller and controller tests in full blueprint ([@marcoow])
 
 ## Svelte
 
-- [paoloricciuti/sveltekit-search-params]
-  [#64](https://github.com/paoloricciuti/sveltekit-search-params/pull/64) feat:
-  add equalityFn option for complex objects and array ([@paoloricciuti])
-- [storybookjs/addon-svelte-csf]
-  [#163](https://github.com/storybookjs/addon-svelte-csf/pull/163) fix: keep
-  track of arguments from a separate map to have the last instance of the
-  component ([@paoloricciuti])
+- [paoloricciuti/sveltekit-search-params] [#64](https://github.com/paoloricciuti/sveltekit-search-params/pull/64) feat: add equalityFn option for complex objects and array ([@paoloricciuti])
+- [storybookjs/addon-svelte-csf] [#163](https://github.com/storybookjs/addon-svelte-csf/pull/163) fix: keep track of arguments from a separate map to have the last instance of the component ([@paoloricciuti])
 
 ## Raycast
 
-- [raycast/extensions]
-  [#10267](https://github.com/raycast/extensions/pull/10267) Add mite extension
-  ([@paoloricciuti])
+- [raycast/extensions] [#10267](https://github.com/raycast/extensions/pull/10267) Add mite extension ([@paoloricciuti])
 
 ## Empress
 
-- [empress/ember-cli-showdown]
-  [#136](https://github.com/empress/ember-cli-showdown/pull/136) drop support
-  for Ember < 3.16 ([@mansona])
-- [empress/ember-cli-showdown]
-  [#135](https://github.com/empress/ember-cli-showdown/pull/135) update
-  lint-to-the-future dashboard action ([@mansona])
-- [empress/ember-cli-showdown]
-  [#133](https://github.com/empress/ember-cli-showdown/pull/133) add header to
-  changelog file ([@mansona])
-- [empress/ember-cli-showdown]
-  [#132](https://github.com/empress/ember-cli-showdown/pull/132) setup
-  release-plan ([@mansona])
-- [empress/ember-cli-showdown]
-  [#130](https://github.com/empress/ember-cli-showdown/pull/130) convert to pnpm
-  ([@mansona])
-- [empress/ember-cli-showdown]
-  [#129](https://github.com/empress/ember-cli-showdown/pull/129) add
-  lint-to-the-future dashboard ([@mansona])
+- [empress/ember-cli-showdown] [#136](https://github.com/empress/ember-cli-showdown/pull/136) drop support for Ember < 3.16 ([@mansona])
+- [empress/ember-cli-showdown] [#135](https://github.com/empress/ember-cli-showdown/pull/135) update lint-to-the-future dashboard action ([@mansona])
+- [empress/ember-cli-showdown] [#133](https://github.com/empress/ember-cli-showdown/pull/133) add header to changelog file ([@mansona])
+- [empress/ember-cli-showdown] [#132](https://github.com/empress/ember-cli-showdown/pull/132) setup release-plan ([@mansona])
+- [empress/ember-cli-showdown] [#130](https://github.com/empress/ember-cli-showdown/pull/130) convert to pnpm ([@mansona])
+- [empress/ember-cli-showdown] [#129](https://github.com/empress/ember-cli-showdown/pull/129) add lint-to-the-future dashboard ([@mansona])
 
 ## JavaScript
 
-- [mansona/lttf-dashboard]
-  [#6](https://github.com/mansona/lttf-dashboard/pull/6) fix version number in
-  README ([@mansona])
-- [mansona/lttf-dashboard]
-  [#5](https://github.com/mansona/lttf-dashboard/pull/5) Restructure
-  ([@mansona])
-- [mansona/lttf-dashboard]
-  [#4](https://github.com/mansona/lttf-dashboard/pull/4) update node version
-  ([@mansona])
-- [opral/monorepo] [#2047](https://github.com/opral/monorepo/pull/2047)
-  chore(paraglide-js): add `repository` entry in `package.json` ([@oscard0m])
-- [thefrontside/effection]
-  [#886](https://github.com/thefrontside/effection/pull/886) Docs: add `ensure`
-  import to Resources code snippet ([@lolmaus])
+- [mansona/lttf-dashboard] [#6](https://github.com/mansona/lttf-dashboard/pull/6) fix version number in README ([@mansona])
+- [mansona/lttf-dashboard] [#5](https://github.com/mansona/lttf-dashboard/pull/5) Restructure ([@mansona])
+- [mansona/lttf-dashboard] [#4](https://github.com/mansona/lttf-dashboard/pull/4) update node version ([@mansona])
+- [opral/monorepo] [#2047](https://github.com/opral/monorepo/pull/2047) chore(paraglide-js): add `repository` entry in `package.json` ([@oscard0m])
+- [thefrontside/effection] [#886](https://github.com/thefrontside/effection/pull/886) Docs: add `ensure` import to Resources code snippet ([@lolmaus])
 
 ## Ember
 
-- [ember-codemods/ember-no-implicit-this-codemod]
-  [#418](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/418)
-  Typescript ([@mansona])
-- [ember-codemods/ember-no-implicit-this-codemod]
-  [#416](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/416)
-  setup release-plan ([@mansona])
-- [ember-codemods/ember-no-implicit-this-codemod]
-  [#409](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/409)
-  add grouping to dependabot config ([@mansona])
-- [ember-codemods/ember-no-implicit-this-codemod]
-  [#405](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/405)
-  drop support for Node < 16 ([@mansona])
-- [ember-codemods/ember-no-implicit-this-codemod]
-  [#401](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/401)
-  swap to pnpm ([@mansona])
-- [ember-codemods/ember-no-implicit-this-codemod]
-  [#400](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/400)
-  Update ember-codemods-telemetry-helpers for Mac M support ([@Mikek2252])
+- [ember-codemods/ember-no-implicit-this-codemod] [#418](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/418) Typescript ([@mansona])
+- [ember-codemods/ember-no-implicit-this-codemod] [#416](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/416) setup release-plan ([@mansona])
+- [ember-codemods/ember-no-implicit-this-codemod] [#409](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/409) add grouping to dependabot config ([@mansona])
+- [ember-codemods/ember-no-implicit-this-codemod] [#405](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/405) drop support for Node < 16 ([@mansona])
+- [ember-codemods/ember-no-implicit-this-codemod] [#401](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/401) swap to pnpm ([@mansona])
+- [ember-codemods/ember-no-implicit-this-codemod] [#400](https://github.com/ember-codemods/ember-no-implicit-this-codemod/pull/400) Update ember-codemods-telemetry-helpers for Mac M support ([@Mikek2252])
 
 ## Project Forms
 
-- [project-forms/project-forms.github.io]
-  [#30](https://github.com/project-forms/project-forms.github.io/pull/30) test:
-  initial E2E test ([@oscard0m])
-- [project-forms/project-forms.github.io]
-  [#29](https://github.com/project-forms/project-forms.github.io/pull/29)
-  test(integration): initial version ([@oscard0m])
+- [project-forms/project-forms.github.io] [#30](https://github.com/project-forms/project-forms.github.io/pull/30) test: initial E2E test ([@oscard0m])
+- [project-forms/project-forms.github.io] [#29](https://github.com/project-forms/project-forms.github.io/pull/29) test(integration): initial version ([@oscard0m])
 
 [@mikek2252]: https://github.com/Mikek2252
 [@lolmaus]: https://github.com/lolmaus
@@ -93,16 +48,13 @@
 [@marcoow]: https://github.com/marcoow
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
-[ember-codemods/ember-no-implicit-this-codemod]:
-  https://github.com/ember-codemods/ember-no-implicit-this-codemod
+[ember-codemods/ember-no-implicit-this-codemod]: https://github.com/ember-codemods/ember-no-implicit-this-codemod
 [empress/ember-cli-showdown]: https://github.com/empress/ember-cli-showdown
 [mansona/lttf-dashboard]: https://github.com/mansona/lttf-dashboard
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [opral/monorepo]: https://github.com/opral/monorepo
-[paoloricciuti/sveltekit-search-params]:
-  https://github.com/paoloricciuti/sveltekit-search-params
-[project-forms/project-forms.github.io]:
-  https://github.com/project-forms/project-forms.github.io
+[paoloricciuti/sveltekit-search-params]: https://github.com/paoloricciuti/sveltekit-search-params
+[project-forms/project-forms.github.io]: https://github.com/project-forms/project-forms.github.io
 [raycast/extensions]: https://github.com/raycast/extensions
 [storybookjs/addon-svelte-csf]: https://github.com/storybookjs/addon-svelte-csf
 [thefrontside/effection]: https://github.com/thefrontside/effection
diff --git a/src/twios/2024-01-28.md b/src/twios/2024-01-28.md
index ec4be55aa4..4f2032b03d 100644
--- a/src/twios/2024-01-28.md
+++ b/src/twios/2024-01-28.md
@@ -1,112 +1,55 @@
 ## Rust
 
-- [marcoow/pacesetter] [#28](https://github.com/marcoow/pacesetter/pull/28)
-  Improve CLI output ([@marcoow])
+- [marcoow/pacesetter] [#28](https://github.com/marcoow/pacesetter/pull/28) Improve CLI output ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/svelte-promise-modals]
-  [#65](https://github.com/mainmatter/svelte-promise-modals/pull/65) Make readme
-  nicer ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#64](https://github.com/mainmatter/svelte-promise-modals/pull/64) Fix pnpm
-  release → npm publish ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#63](https://github.com/mainmatter/svelte-promise-modals/pull/63) Muscle
-  memory 🐹 😅 ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#61](https://github.com/mainmatter/svelte-promise-modals/pull/61) Setup
-  release script ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#59](https://github.com/mainmatter/svelte-promise-modals/pull/59) Fix return
-  data example ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#65](https://github.com/mainmatter/svelte-promise-modals/pull/65) Make readme nicer ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#64](https://github.com/mainmatter/svelte-promise-modals/pull/64) Fix pnpm release → npm publish ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#63](https://github.com/mainmatter/svelte-promise-modals/pull/63) Muscle memory 🐹 😅 ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#61](https://github.com/mainmatter/svelte-promise-modals/pull/61) Setup release script ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#59](https://github.com/mainmatter/svelte-promise-modals/pull/59) Fix return data example ([@zeppelin])
 
 ## Raycast
 
-- [raycast/extensions]
-  [#10267](https://github.com/raycast/extensions/pull/10267) Add mite extension
-  ([@paoloricciuti])
+- [raycast/extensions] [#10267](https://github.com/raycast/extensions/pull/10267) Add mite extension ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1768](https://github.com/embroider-build/embroider/pull/1768) docs(porting
-  addons to v2): change the recommended package manager to pnpm
-  ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1765](https://github.com/embroider-build/embroider/pull/1765)
-  Docs(addon-author-guide)/ remove the out-of-date part about alternative to
-  monorepos ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1768](https://github.com/embroider-build/embroider/pull/1768) docs(porting addons to v2): change the recommended package manager to pnpm ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1765](https://github.com/embroider-build/embroider/pull/1765) Docs(addon-author-guide)/ remove the out-of-date part about alternative to monorepos ([@BlueCutOfficial])
 
 ## Empress
 
-- [empress/guidemaker] [#103](https://github.com/empress/guidemaker/pull/103)
-  drop support for node < 18 ([@mansona])
-- [empress/guidemaker] [#102](https://github.com/empress/guidemaker/pull/102)
-  swap to pnpm ([@mansona])
+- [empress/guidemaker] [#103](https://github.com/empress/guidemaker/pull/103) drop support for node < 18 ([@mansona])
+- [empress/guidemaker] [#102](https://github.com/empress/guidemaker/pull/102) swap to pnpm ([@mansona])
 
 ## JavaScript
 
-- [embroider-build/release-plan]
-  [#52](https://github.com/embroider-build/release-plan/pull/52) add ability to
-  pass tag to publish command ([@mansona])
-- [embroider-build/release-plan]
-  [#51](https://github.com/embroider-build/release-plan/pull/51) Make changelog
-  header discovery more forgiving (case-insensitive) ([@mansona])
-- [embroider-build/release-plan]
-  [#49](https://github.com/embroider-build/release-plan/pull/49) add a basic
-  test for updateChangelog ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#60](https://github.com/mansona/create-release-plan-setup/pull/60) match
-  release-plan test for Changelog header ([@mansona])
+- [embroider-build/release-plan] [#52](https://github.com/embroider-build/release-plan/pull/52) add ability to pass tag to publish command ([@mansona])
+- [embroider-build/release-plan] [#51](https://github.com/embroider-build/release-plan/pull/51) Make changelog header discovery more forgiving (case-insensitive) ([@mansona])
+- [embroider-build/release-plan] [#49](https://github.com/embroider-build/release-plan/pull/49) add a basic test for updateChangelog ([@mansona])
+- [mansona/create-release-plan-setup] [#60](https://github.com/mansona/create-release-plan-setup/pull/60) match release-plan test for Changelog header ([@mansona])
 
 ## Ember
 
-- [adopted-ember-addons/ember-pikaday]
-  [#578](https://github.com/adopted-ember-addons/ember-pikaday/pull/578) setup
-  release-plan ([@mansona])
-- [adopted-ember-addons/ember-pikaday]
-  [#576](https://github.com/adopted-ember-addons/ember-pikaday/pull/576) use
-  pnpm ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#903](https://github.com/ember-learn/ember-api-docs/pull/903) Start using
-  Embroider ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#505](https://github.com/ember-learn/ember-styleguide/pull/505) fix
-  publish-branch for release-plan ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#503](https://github.com/ember-learn/ember-styleguide/pull/503) use
-  release-plan for legacy release ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#501](https://github.com/ember-learn/ember-styleguide/pull/501) [lts-v3] get
-  legacy release embroider compatible ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#500](https://github.com/ember-learn/ember-styleguide/pull/500) use new
-  lint-to-the-future dashboard action ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#498](https://github.com/ember-learn/ember-styleguide/pull/498) use
-  release-plan ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#497](https://github.com/ember-learn/ember-styleguide/pull/497) update percy
-  widths ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#496](https://github.com/ember-learn/ember-styleguide/pull/496) update
-  fastboot and ember-try to fix CI ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#169](https://github.com/ember-learn/guidemaker-ember-template/pull/169)
-  switch to pnpm ([@mansona])
-- [ember-learn/guides-source]
-  [#1998](https://github.com/ember-learn/guides-source/pull/1998) update all
-  `ember server` to `npm start` ([@mansona])
-- [nickschot/ember-mobile-menu]
-  [#854](https://github.com/nickschot/ember-mobile-menu/pull/854) WIP Fix
-  fastboot compatibility ([@nickschot])
+- [adopted-ember-addons/ember-pikaday] [#578](https://github.com/adopted-ember-addons/ember-pikaday/pull/578) setup release-plan ([@mansona])
+- [adopted-ember-addons/ember-pikaday] [#576](https://github.com/adopted-ember-addons/ember-pikaday/pull/576) use pnpm ([@mansona])
+- [ember-learn/ember-api-docs] [#903](https://github.com/ember-learn/ember-api-docs/pull/903) Start using Embroider ([@mansona])
+- [ember-learn/ember-styleguide] [#505](https://github.com/ember-learn/ember-styleguide/pull/505) fix publish-branch for release-plan ([@mansona])
+- [ember-learn/ember-styleguide] [#503](https://github.com/ember-learn/ember-styleguide/pull/503) use release-plan for legacy release ([@mansona])
+- [ember-learn/ember-styleguide] [#501](https://github.com/ember-learn/ember-styleguide/pull/501) [lts-v3] get legacy release embroider compatible ([@mansona])
+- [ember-learn/ember-styleguide] [#500](https://github.com/ember-learn/ember-styleguide/pull/500) use new lint-to-the-future dashboard action ([@mansona])
+- [ember-learn/ember-styleguide] [#498](https://github.com/ember-learn/ember-styleguide/pull/498) use release-plan ([@mansona])
+- [ember-learn/ember-styleguide] [#497](https://github.com/ember-learn/ember-styleguide/pull/497) update percy widths ([@mansona])
+- [ember-learn/ember-styleguide] [#496](https://github.com/ember-learn/ember-styleguide/pull/496) update fastboot and ember-try to fix CI ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#169](https://github.com/ember-learn/guidemaker-ember-template/pull/169) switch to pnpm ([@mansona])
+- [ember-learn/guides-source] [#1998](https://github.com/ember-learn/guides-source/pull/1998) update all `ember server` to `npm start` ([@mansona])
+- [nickschot/ember-mobile-menu] [#854](https://github.com/nickschot/ember-mobile-menu/pull/854) WIP Fix fastboot compatibility ([@nickschot])
 
 ## Project Forms
 
-- [project-forms/project-forms.github.io]
-  [#31](https://github.com/project-forms/project-forms.github.io/pull/31) PoC:
-  react router ([@oscard0m])
+- [project-forms/project-forms.github.io] [#31](https://github.com/project-forms/project-forms.github.io/pull/31) PoC: react router ([@oscard0m])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
@@ -115,22 +58,17 @@
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@zeppelin]: https://github.com/zeppelin
-[adopted-ember-addons/ember-pikaday]:
-  https://github.com/adopted-ember-addons/ember-pikaday
+[adopted-ember-addons/ember-pikaday]: https://github.com/adopted-ember-addons/ember-pikaday
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
-[ember-learn/guidemaker-ember-template]:
-  https://github.com/ember-learn/guidemaker-ember-template
+[ember-learn/guidemaker-ember-template]: https://github.com/ember-learn/guidemaker-ember-template
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [embroider-build/release-plan]: https://github.com/embroider-build/release-plan
 [empress/guidemaker]: https://github.com/empress/guidemaker
-[mainmatter/svelte-promise-modals]:
-  https://github.com/mainmatter/svelte-promise-modals
-[mansona/create-release-plan-setup]:
-  https://github.com/mansona/create-release-plan-setup
+[mainmatter/svelte-promise-modals]: https://github.com/mainmatter/svelte-promise-modals
+[mansona/create-release-plan-setup]: https://github.com/mansona/create-release-plan-setup
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
-[project-forms/project-forms.github.io]:
-  https://github.com/project-forms/project-forms.github.io
+[project-forms/project-forms.github.io]: https://github.com/project-forms/project-forms.github.io
 [raycast/extensions]: https://github.com/raycast/extensions
diff --git a/src/twios/2024-02-04.md b/src/twios/2024-02-04.md
index 2f25f31384..199f7a9f60 100644
--- a/src/twios/2024-02-04.md
+++ b/src/twios/2024-02-04.md
@@ -1,81 +1,36 @@
 ## Svelte
 
-- [melt-ui/melt-ui] [#937](https://github.com/melt-ui/melt-ui/pull/937) fix:
-  type of `type` in tabs builder ([@paoloricciuti])
+- [melt-ui/melt-ui] [#937](https://github.com/melt-ui/melt-ui/pull/937) fix: type of `type` in tabs builder ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1782](https://github.com/embroider-build/embroider/pull/1782) Merge stable
-  into main ([@mansona])
-- [embroider-build/embroider]
-  [#1779](https://github.com/embroider-build/embroider/pull/1779) Virtual entry
-  point ([@mansona])
-- [embroider-build/embroider]
-  [#1775](https://github.com/embroider-build/embroider/pull/1775) Docs(peer deps
-  resolution issues): mentions pnpm-dedupe and add links ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1772](https://github.com/embroider-build/embroider/pull/1772) Docs porting
-  addons to v2 co location ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1782](https://github.com/embroider-build/embroider/pull/1782) Merge stable into main ([@mansona])
+- [embroider-build/embroider] [#1779](https://github.com/embroider-build/embroider/pull/1779) Virtual entry point ([@mansona])
+- [embroider-build/embroider] [#1775](https://github.com/embroider-build/embroider/pull/1775) Docs(peer deps resolution issues): mentions pnpm-dedupe and add links ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1772](https://github.com/embroider-build/embroider/pull/1772) Docs porting addons to v2 co location ([@BlueCutOfficial])
 
 ## Ember
 
-- [ember-learn/ember-website]
-  [#1081](https://github.com/ember-learn/ember-website/pull/1081) add Teamtailor
-  to the Embroider Initiative sponsors ([@mansona])
-- [ember-learn/guides-source]
-  [#2000](https://github.com/ember-learn/guides-source/pull/2000) Fix tutorial
-  ([@mansona])
-- [funkensturm/ember-local-storage]
-  [#377](https://github.com/funkensturm/ember-local-storage/pull/377) Ensure
-  storage objects are destroyed on application teardown in tests ([@Mikek2252])
-- [lan0/ember-power-time-picker]
-  [#17](https://github.com/lan0/ember-power-time-picker/pull/17) Upgrade to
-  Ember 3.24 ([@Mikek2252])
-- [mainmatter/ember-intl-analyzer]
-  [#655](https://github.com/mainmatter/ember-intl-analyzer/pull/655) Add custom
-  t helper support ([@Mikek2252])
-- [mainmatter/ember-intl-analyzer]
-  [#650](https://github.com/mainmatter/ember-intl-analyzer/pull/650) Add back
-  uses of async and await ([@Mikek2252])
-- [mainmatter/ember-promise-modals]
-  [#913](https://github.com/mainmatter/ember-promise-modals/pull/913) Remove
-  support for deprecated `modal-from-string` ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#910](https://github.com/mainmatter/ember-promise-modals/pull/910) Drop Ember
-  < 3.28 and node < 16 ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#909](https://github.com/mainmatter/ember-promise-modals/pull/909) Remove the
-  PostCSS process ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#908](https://github.com/mainmatter/ember-promise-modals/pull/908)
-  docs(DEPRECATIONS)/ Adjust the line about deprecated node ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#907](https://github.com/mainmatter/ember-promise-modals/pull/907) Internal
-  fix/ re-add node 14 to the list of supported engines ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#897](https://github.com/mainmatter/ember-promise-modals/pull/897)
-  Communicate about all the major changes planned for the v2 addon
-  ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#894](https://github.com/mainmatter/ember-promise-modals/pull/894) Deprecate
-  opening a modal from string ([@BlueCutOfficial])
-- [mainmatter/ember-test-selectors]
-  [#1215](https://github.com/mainmatter/ember-test-selectors/pull/1215) start
-  using release-plan ([@mansona])
-- [nickschot/ember-mobile-menu]
-  [#855](https://github.com/nickschot/ember-mobile-menu/pull/855) Implement
-  basic scale correction for gestures ([@nickschot])
+- [ember-learn/ember-website] [#1081](https://github.com/ember-learn/ember-website/pull/1081) add Teamtailor to the Embroider Initiative sponsors ([@mansona])
+- [ember-learn/guides-source] [#2000](https://github.com/ember-learn/guides-source/pull/2000) Fix tutorial ([@mansona])
+- [funkensturm/ember-local-storage] [#377](https://github.com/funkensturm/ember-local-storage/pull/377) Ensure storage objects are destroyed on application teardown in tests ([@Mikek2252])
+- [lan0/ember-power-time-picker] [#17](https://github.com/lan0/ember-power-time-picker/pull/17) Upgrade to Ember 3.24 ([@Mikek2252])
+- [mainmatter/ember-intl-analyzer] [#655](https://github.com/mainmatter/ember-intl-analyzer/pull/655) Add custom t helper support ([@Mikek2252])
+- [mainmatter/ember-intl-analyzer] [#650](https://github.com/mainmatter/ember-intl-analyzer/pull/650) Add back uses of async and await ([@Mikek2252])
+- [mainmatter/ember-promise-modals] [#913](https://github.com/mainmatter/ember-promise-modals/pull/913) Remove support for deprecated `modal-from-string` ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#910](https://github.com/mainmatter/ember-promise-modals/pull/910) Drop Ember < 3.28 and node < 16 ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#909](https://github.com/mainmatter/ember-promise-modals/pull/909) Remove the PostCSS process ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#908](https://github.com/mainmatter/ember-promise-modals/pull/908) docs(DEPRECATIONS)/ Adjust the line about deprecated node ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#907](https://github.com/mainmatter/ember-promise-modals/pull/907) Internal fix/ re-add node 14 to the list of supported engines ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#897](https://github.com/mainmatter/ember-promise-modals/pull/897) Communicate about all the major changes planned for the v2 addon ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#894](https://github.com/mainmatter/ember-promise-modals/pull/894) Deprecate opening a modal from string ([@BlueCutOfficial])
+- [mainmatter/ember-test-selectors] [#1215](https://github.com/mainmatter/ember-test-selectors/pull/1215) start using release-plan ([@mansona])
+- [nickschot/ember-mobile-menu] [#855](https://github.com/nickschot/ember-mobile-menu/pull/855) Implement basic scale correction for gestures ([@nickschot])
 
 ## Project Forms
 
-- [project-forms/project-forms.github.io]
-  [#36](https://github.com/project-forms/project-forms.github.io/pull/36)
-  refactor(routes): `/new` route uses React Router's 'params' instead of a RegEx
-  on window.location ([@oscard0m])
-- [project-forms/project-forms.github.io]
-  [#33](https://github.com/project-forms/project-forms.github.io/pull/33) fix
-  github oauth login redirect url in production ([@oscard0m])
+- [project-forms/project-forms.github.io] [#36](https://github.com/project-forms/project-forms.github.io/pull/36) refactor(routes): `/new` route uses React Router's 'params' instead of a RegEx on window.location ([@oscard0m])
+- [project-forms/project-forms.github.io] [#33](https://github.com/project-forms/project-forms.github.io/pull/33) fix github oauth login redirect url in production ([@oscard0m])
 
 [@bluecutofficial]: https://github.com/BlueCutOfficial
 [@mikek2252]: https://github.com/Mikek2252
@@ -87,16 +42,11 @@
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[funkensturm/ember-local-storage]:
-  https://github.com/funkensturm/ember-local-storage
+[funkensturm/ember-local-storage]: https://github.com/funkensturm/ember-local-storage
 [lan0/ember-power-time-picker]: https://github.com/lan0/ember-power-time-picker
-[mainmatter/ember-intl-analyzer]:
-  https://github.com/mainmatter/ember-intl-analyzer
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
-[mainmatter/ember-test-selectors]:
-  https://github.com/mainmatter/ember-test-selectors
+[mainmatter/ember-intl-analyzer]: https://github.com/mainmatter/ember-intl-analyzer
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-test-selectors]: https://github.com/mainmatter/ember-test-selectors
 [melt-ui/melt-ui]: https://github.com/melt-ui/melt-ui
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
-[project-forms/project-forms.github.io]:
-  https://github.com/project-forms/project-forms.github.io
+[project-forms/project-forms.github.io]: https://github.com/project-forms/project-forms.github.io
diff --git a/src/twios/2024-02-11.md b/src/twios/2024-02-11.md
index 22ceae2bea..3fda08c363 100644
--- a/src/twios/2024-02-11.md
+++ b/src/twios/2024-02-11.md
@@ -1,128 +1,59 @@
 ## Rust
 
-- [marcoow/pacesetter] [#32](https://github.com/marcoow/pacesetter/pull/32) add
-  API docs ([@marcoow])
-- [marcoow/pacesetter] [#31](https://github.com/marcoow/pacesetter/pull/31) test
-  parse_env, not get_env ([@marcoow])
-- [marcoow/pacesetter] [#30](https://github.com/marcoow/pacesetter/pull/30) Add
-  tests ([@marcoow])
-- [marcoow/pacesetter] [#29](https://github.com/marcoow/pacesetter/pull/29)
-  cleanup tests ([@marcoow])
+- [marcoow/pacesetter] [#32](https://github.com/marcoow/pacesetter/pull/32) add API docs ([@marcoow])
+- [marcoow/pacesetter] [#31](https://github.com/marcoow/pacesetter/pull/31) test parse_env, not get_env ([@marcoow])
+- [marcoow/pacesetter] [#30](https://github.com/marcoow/pacesetter/pull/30) Add tests ([@marcoow])
+- [marcoow/pacesetter] [#29](https://github.com/marcoow/pacesetter/pull/29) cleanup tests ([@marcoow])
 
 ## Svelte
 
-- [CodingGarden/listd] [#157](https://github.com/CodingGarden/listd/pull/157)
-  fix: use proper transition with objects for avatars ([@paoloricciuti])
+- [CodingGarden/listd] [#157](https://github.com/CodingGarden/listd/pull/157) fix: use proper transition with objects for avatars ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1794](https://github.com/embroider-build/embroider/pull/1794) Refactor the
-  resolve function to be the only public api to module-resolver ([@mansona])
-- [embroider-build/embroider]
-  [#1791](https://github.com/embroider-build/embroider/pull/1791)
-  docs(porting-addons-to-v2): Explain no-unpublished-required issue
-  ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1794](https://github.com/embroider-build/embroider/pull/1794) Refactor the resolve function to be the only public api to module-resolver ([@mansona])
+- [embroider-build/embroider] [#1791](https://github.com/embroider-build/embroider/pull/1791) docs(porting-addons-to-v2): Explain no-unpublished-required issue ([@BlueCutOfficial])
 
 ## Empress
 
-- [empress/broccoli-static-site-json]
-  [#76](https://github.com/empress/broccoli-static-site-json/pull/76) update
-  showdown and jsdom ([@mansona])
-- [empress/broccoli-static-site-json]
-  [#75](https://github.com/empress/broccoli-static-site-json/pull/75) drop
-  support for node < 16 ([@mansona])
-- [empress/broccoli-static-site-json]
-  [#73](https://github.com/empress/broccoli-static-site-json/pull/73) start
-  using release-plan ([@mansona])
-- [empress/ember-cli-showdown]
-  [#144](https://github.com/empress/ember-cli-showdown/pull/144) drop support
-  for node 16 ([@mansona])
-- [empress/ember-cli-showdown]
-  [#143](https://github.com/empress/ember-cli-showdown/pull/143) update showdown
-  to v2 ([@mansona])
-- [empress/ember-cli-showdown]
-  [#141](https://github.com/empress/ember-cli-showdown/pull/141) update to v5.4
-  with ember-cli-update ([@mansona])
+- [empress/broccoli-static-site-json] [#76](https://github.com/empress/broccoli-static-site-json/pull/76) update showdown and jsdom ([@mansona])
+- [empress/broccoli-static-site-json] [#75](https://github.com/empress/broccoli-static-site-json/pull/75) drop support for node < 16 ([@mansona])
+- [empress/broccoli-static-site-json] [#73](https://github.com/empress/broccoli-static-site-json/pull/73) start using release-plan ([@mansona])
+- [empress/ember-cli-showdown] [#144](https://github.com/empress/ember-cli-showdown/pull/144) drop support for node 16 ([@mansona])
+- [empress/ember-cli-showdown] [#143](https://github.com/empress/ember-cli-showdown/pull/143) update showdown to v2 ([@mansona])
+- [empress/ember-cli-showdown] [#141](https://github.com/empress/ember-cli-showdown/pull/141) update to v5.4 with ember-cli-update ([@mansona])
 
 ## JavaScript
 
-- [mainmatter/compare-fixture]
-  [#10](https://github.com/mainmatter/compare-fixture/pull/10) fix npx usage
-  ([@mansona])
-- [mainmatter/compare-fixture]
-  [#8](https://github.com/mainmatter/compare-fixture/pull/8) only update npm on
-  CI if using older node versions ([@mansona])
-- [mainmatter/compare-fixture]
-  [#7](https://github.com/mainmatter/compare-fixture/pull/7) setup release-plan
-  ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#71](https://github.com/mansona/create-release-plan-setup/pull/71) run
-  create-release-plan-setup ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#69](https://github.com/mansona/create-release-plan-setup/pull/69) update
-  release-plan ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#68](https://github.com/mansona/create-release-plan-setup/pull/68) Update
-  peter-evans/create-pull-request ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#67](https://github.com/mansona/create-release-plan-setup/pull/67) add an
-  editorconfig file ([@mansona])
+- [mainmatter/compare-fixture] [#10](https://github.com/mainmatter/compare-fixture/pull/10) fix npx usage ([@mansona])
+- [mainmatter/compare-fixture] [#8](https://github.com/mainmatter/compare-fixture/pull/8) only update npm on CI if using older node versions ([@mansona])
+- [mainmatter/compare-fixture] [#7](https://github.com/mainmatter/compare-fixture/pull/7) setup release-plan ([@mansona])
+- [mansona/create-release-plan-setup] [#71](https://github.com/mansona/create-release-plan-setup/pull/71) run create-release-plan-setup ([@mansona])
+- [mansona/create-release-plan-setup] [#69](https://github.com/mansona/create-release-plan-setup/pull/69) update release-plan ([@mansona])
+- [mansona/create-release-plan-setup] [#68](https://github.com/mansona/create-release-plan-setup/pull/68) Update peter-evans/create-pull-request ([@mansona])
+- [mansona/create-release-plan-setup] [#67](https://github.com/mansona/create-release-plan-setup/pull/67) add an editorconfig file ([@mansona])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#239](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/239) Update
-  algolia public key ([@BlueCutOfficial])
-- [DazzlingFugu/ember-fr-guides-source]
-  [#238](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/238)
-  Translate guides/applications/initializers.md ([@BlueCutOfficial])
-- [ember-cli/ember-cli]
-  [#10436](https://github.com/ember-cli/ember-cli/pull/10436) stop using
-  wyvox/action-setup-pnpm ([@mansona])
-- [ember-codemods/ember-angle-brackets-codemod]
-  [#515](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/515)
-  Move helper disambiguation to a flag that is off by default ([@lolmaus])
-- [ember-fastboot/ember-cli-fastboot]
-  [#932](https://github.com/ember-fastboot/ember-cli-fastboot/pull/932) update
-  CI action versions ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#175](https://github.com/ember-learn/guidemaker-ember-template/pull/175)
-  start using release-plan ([@mansona])
-- [lan0/ember-power-time-picker]
-  [#19](https://github.com/lan0/ember-power-time-picker/pull/19) Remove
-  `ember-moment` in favour of just using `moment` ([@Mikek2252])
-- [lan0/ember-power-time-picker]
-  [#18](https://github.com/lan0/ember-power-time-picker/pull/18) Upgrade
-  `ember-power-select` ([@Mikek2252])
-- [mainmatter/ember-promise-modals]
-  [#916](https://github.com/mainmatter/ember-promise-modals/pull/916) Create a
-  monorepo to separate v1 addon from test-app ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#915](https://github.com/mainmatter/ember-promise-modals/pull/915) Replace
-  eslint-plugin-node with latest eslint-plugin-n ([@BlueCutOfficial])
-- [mansona/ember-cli-notifications]
-  [#374](https://github.com/mansona/ember-cli-notifications/pull/374) update
-  release-plan ([@mansona])
-- [nickschot/ember-mobile-menu]
-  [#878](https://github.com/nickschot/ember-mobile-menu/pull/878) Allow
-  ember-concurrency v4 ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#877](https://github.com/nickschot/ember-mobile-menu/pull/877) Require
-  ember-resources >=v6.4.0 (inc. v7) ([@nickschot])
+- [DazzlingFugu/ember-fr-guides-source] [#239](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/239) Update algolia public key ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#238](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/238) Translate guides/applications/initializers.md ([@BlueCutOfficial])
+- [ember-cli/ember-cli] [#10436](https://github.com/ember-cli/ember-cli/pull/10436) stop using wyvox/action-setup-pnpm ([@mansona])
+- [ember-codemods/ember-angle-brackets-codemod] [#515](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/515) Move helper disambiguation to a flag that is off by default ([@lolmaus])
+- [ember-fastboot/ember-cli-fastboot] [#932](https://github.com/ember-fastboot/ember-cli-fastboot/pull/932) update CI action versions ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#175](https://github.com/ember-learn/guidemaker-ember-template/pull/175) start using release-plan ([@mansona])
+- [lan0/ember-power-time-picker] [#19](https://github.com/lan0/ember-power-time-picker/pull/19) Remove `ember-moment` in favour of just using `moment` ([@Mikek2252])
+- [lan0/ember-power-time-picker] [#18](https://github.com/lan0/ember-power-time-picker/pull/18) Upgrade `ember-power-select` ([@Mikek2252])
+- [mainmatter/ember-promise-modals] [#916](https://github.com/mainmatter/ember-promise-modals/pull/916) Create a monorepo to separate v1 addon from test-app ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#915](https://github.com/mainmatter/ember-promise-modals/pull/915) Replace eslint-plugin-node with latest eslint-plugin-n ([@BlueCutOfficial])
+- [mansona/ember-cli-notifications] [#374](https://github.com/mansona/ember-cli-notifications/pull/374) update release-plan ([@mansona])
+- [nickschot/ember-mobile-menu] [#878](https://github.com/nickschot/ember-mobile-menu/pull/878) Allow ember-concurrency v4 ([@nickschot])
+- [nickschot/ember-mobile-menu] [#877](https://github.com/nickschot/ember-mobile-menu/pull/877) Require ember-resources >=v6.4.0 (inc. v7) ([@nickschot])
 
 ## Project Forms
 
-- [project-forms/project-forms.github.io]
-  [#44](https://github.com/project-forms/project-forms.github.io/pull/44)
-  test(integration): add a snapshot to capture the Loading UI in `/new`
-  ([@oscard0m])
-- [project-forms/project-forms.github.io]
-  [#43](https://github.com/project-forms/project-forms.github.io/pull/43) add
-  vitest watch mode to package.json ([@oscard0m])
-- [project-forms/project-forms.github.io]
-  [#42](https://github.com/project-forms/project-forms.github.io/pull/42)
-  fix(routes): `/new` renders `Access Error` UI correctly ([@oscard0m])
+- [project-forms/project-forms.github.io] [#44](https://github.com/project-forms/project-forms.github.io/pull/44) test(integration): add a snapshot to capture the Loading UI in `/new` ([@oscard0m])
+- [project-forms/project-forms.github.io] [#43](https://github.com/project-forms/project-forms.github.io/pull/43) add vitest watch mode to package.json ([@oscard0m])
+- [project-forms/project-forms.github.io] [#42](https://github.com/project-forms/project-forms.github.io/pull/42) fix(routes): `/new` renders `Access Error` UI correctly ([@oscard0m])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@Mikek2252]: https://github.com/Mikek2252
@@ -134,28 +65,19 @@
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@pichfl]: https://github.com/pichfl
 [CodingGarden/listd]: https://github.com/CodingGarden/listd
-[DazzlingFugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [ember-cli/ember-cli]: https://github.com/ember-cli/ember-cli
-[ember-codemods/ember-angle-brackets-codemod]:
-  https://github.com/ember-codemods/ember-angle-brackets-codemod
-[ember-fastboot/ember-cli-fastboot]:
-  https://github.com/ember-fastboot/ember-cli-fastboot
-[ember-learn/guidemaker-ember-template]:
-  https://github.com/ember-learn/guidemaker-ember-template
+[ember-codemods/ember-angle-brackets-codemod]: https://github.com/ember-codemods/ember-angle-brackets-codemod
+[ember-fastboot/ember-cli-fastboot]: https://github.com/ember-fastboot/ember-cli-fastboot
+[ember-learn/guidemaker-ember-template]: https://github.com/ember-learn/guidemaker-ember-template
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[empress/broccoli-static-site-json]:
-  https://github.com/empress/broccoli-static-site-json
+[empress/broccoli-static-site-json]: https://github.com/empress/broccoli-static-site-json
 [empress/ember-cli-showdown]: https://github.com/empress/ember-cli-showdown
 [lan0/ember-power-time-picker]: https://github.com/lan0/ember-power-time-picker
 [mainmatter/compare-fixture]: https://github.com/mainmatter/compare-fixture
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
-[mansona/create-release-plan-setup]:
-  https://github.com/mansona/create-release-plan-setup
-[mansona/ember-cli-notifications]:
-  https://github.com/mansona/ember-cli-notifications
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
+[mansona/create-release-plan-setup]: https://github.com/mansona/create-release-plan-setup
+[mansona/ember-cli-notifications]: https://github.com/mansona/ember-cli-notifications
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
-[project-forms/project-forms.github.io]:
-  https://github.com/project-forms/project-forms.github.io
+[project-forms/project-forms.github.io]: https://github.com/project-forms/project-forms.github.io
diff --git a/src/twios/2024-02-18.md b/src/twios/2024-02-18.md
index 65676aa007..d560c1506c 100644
--- a/src/twios/2024-02-18.md
+++ b/src/twios/2024-02-18.md
@@ -1,192 +1,77 @@
 ## Rust
 
-- [marcoow/pacesetter] [#32](https://github.com/marcoow/pacesetter/pull/32) add
-  API docs ([@marcoow])
-- [marcoow/pacesetter] [#31](https://github.com/marcoow/pacesetter/pull/31) test
-  parse_env, not get_env ([@marcoow])
+- [marcoow/pacesetter] [#32](https://github.com/marcoow/pacesetter/pull/32) add API docs ([@marcoow])
+- [marcoow/pacesetter] [#31](https://github.com/marcoow/pacesetter/pull/31) test parse_env, not get_env ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/svelte-promise-modals]
-  [#76](https://github.com/mainmatter/svelte-promise-modals/pull/76) Add missing
-  `useModalContext` export ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#74](https://github.com/mainmatter/svelte-promise-modals/pull/74) Prefix
-  og:image path with base URL ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#71](https://github.com/mainmatter/svelte-promise-modals/pull/71) Set up SSG
-  ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#75](https://github.com/mainmatter/svelte-promise-modals/pull/75) fix: remove
-  declare module (kit will generate that with the dev server) ([@paoloricciuti])
-- [mainmatter/svelte-promise-modals]
-  [#72](https://github.com/mainmatter/svelte-promise-modals/pull/72) fix:
-  prerendering and small errors in +page.svelte ([@paoloricciuti])
-- [paoloricciuti/sveltekit-search-params]
-  [#68](https://github.com/paoloricciuti/sveltekit-search-params/pull/68) fix:
-  allow building the app in prerendering by faking the page store during
-  building ([@paoloricciuti])
+- [mainmatter/svelte-promise-modals] [#76](https://github.com/mainmatter/svelte-promise-modals/pull/76) Add missing `useModalContext` export ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#74](https://github.com/mainmatter/svelte-promise-modals/pull/74) Prefix og:image path with base URL ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#71](https://github.com/mainmatter/svelte-promise-modals/pull/71) Set up SSG ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#75](https://github.com/mainmatter/svelte-promise-modals/pull/75) fix: remove declare module (kit will generate that with the dev server) ([@paoloricciuti])
+- [mainmatter/svelte-promise-modals] [#72](https://github.com/mainmatter/svelte-promise-modals/pull/72) fix: prerendering and small errors in +page.svelte ([@paoloricciuti])
+- [paoloricciuti/sveltekit-search-params] [#68](https://github.com/paoloricciuti/sveltekit-search-params/pull/68) fix: allow building the app in prerendering by faking the page store during building ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1805](https://github.com/embroider-build/embroider/pull/1805) Module
-  resolver: virtualize vendor.css ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1801](https://github.com/embroider-build/embroider/pull/1801) Module
-  resolver: virtualize vendor.js ([@BlueCutOfficial])
-- [embroider-build/github-changelog]
-  [#14](https://github.com/embroider-build/github-changelog/pull/14) remove
-  invisible character in unlabelled text ([@mansona])
-- [embroider-build/github-changelog]
-  [#11](https://github.com/embroider-build/github-changelog/pull/11) Add a
-  default implementation for unlabelled ([@mansona])
+- [embroider-build/embroider] [#1805](https://github.com/embroider-build/embroider/pull/1805) Module resolver: virtualize vendor.css ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1801](https://github.com/embroider-build/embroider/pull/1801) Module resolver: virtualize vendor.js ([@BlueCutOfficial])
+- [embroider-build/github-changelog] [#14](https://github.com/embroider-build/github-changelog/pull/14) remove invisible character in unlabelled text ([@mansona])
+- [embroider-build/github-changelog] [#11](https://github.com/embroider-build/github-changelog/pull/11) Add a default implementation for unlabelled ([@mansona])
 
 ## JavaScript
 
-- [embroider-build/release-plan]
-  [#56](https://github.com/embroider-build/release-plan/pull/56) add the default
-  github-changelog unlabelled section name to parser ([@mansona])
-- [embroider-build/release-plan]
-  [#54](https://github.com/embroider-build/release-plan/pull/54) fix import of
-  semver ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#82](https://github.com/mansona/create-release-plan-setup/pull/82) run npm
-  init release-plan-setup on this repo ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#81](https://github.com/mansona/create-release-plan-setup/pull/81) update
-  pnpm/action-setup in template ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#80](https://github.com/mansona/create-release-plan-setup/pull/80) update
-  release-plan ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#78](https://github.com/mansona/create-release-plan-setup/pull/78) Show
-  unlabelled ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#77](https://github.com/mansona/create-release-plan-setup/pull/77) fix the
-  branch used when a PR is labelled ([@mansona])
-- [mansona/create-release-plan-setup]
-  [#76](https://github.com/mansona/create-release-plan-setup/pull/76) update
-  setup docs in the readme ([@mansona])
+- [embroider-build/release-plan] [#56](https://github.com/embroider-build/release-plan/pull/56) add the default github-changelog unlabelled section name to parser ([@mansona])
+- [embroider-build/release-plan] [#54](https://github.com/embroider-build/release-plan/pull/54) fix import of semver ([@mansona])
+- [mansona/create-release-plan-setup] [#82](https://github.com/mansona/create-release-plan-setup/pull/82) run npm init release-plan-setup on this repo ([@mansona])
+- [mansona/create-release-plan-setup] [#81](https://github.com/mansona/create-release-plan-setup/pull/81) update pnpm/action-setup in template ([@mansona])
+- [mansona/create-release-plan-setup] [#80](https://github.com/mansona/create-release-plan-setup/pull/80) update release-plan ([@mansona])
+- [mansona/create-release-plan-setup] [#78](https://github.com/mansona/create-release-plan-setup/pull/78) Show unlabelled ([@mansona])
+- [mansona/create-release-plan-setup] [#77](https://github.com/mansona/create-release-plan-setup/pull/77) fix the branch used when a PR is labelled ([@mansona])
+- [mansona/create-release-plan-setup] [#76](https://github.com/mansona/create-release-plan-setup/pull/76) update setup docs in the readme ([@mansona])
 
 ## Ember
 
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#162](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/162)
-  fix workflow file format ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#161](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/161)
-  fix release-plan label dispatch ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#159](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/159)
-  don't remove stderr.log if release-plan fails ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#158](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/158)
-  fix error-handling for release-plan ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#157](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/157)
-  fix exit code for release-plan ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#156](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/156)
-  testing error-handling in release-plan ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#155](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/155)
-  update release-plan ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#151](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/151)
-  try to setup renovate to batch updates ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#149](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/149)
-  start using release-plan ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#145](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/145)
-  update to v5.4 with ember-cli-update and add Ember 5 support ([@mansona])
-- [adopted-ember-addons/ember-collapsible-panel]
-  [#142](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/142)
-  switch to pnpm ([@mansona])
-- [ember-codemods/ember-angle-brackets-codemod]
-  [#525](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/525)
-  update release-plan ([@mansona])
-- [ember-codemods/ember-angle-brackets-codemod]
-  [#517](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/517)
-  create dependabot config with batching for minor changes ([@mansona])
-- [ember-fastboot/ember-cli-fastboot]
-  [#932](https://github.com/ember-fastboot/ember-cli-fastboot/pull/932) update
-  CI action versions ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#507](https://github.com/ember-learn/ember-styleguide/pull/507) make sidebar
-  content slightly wider and add background colour ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#178](https://github.com/ember-learn/guidemaker-ember-template/pull/178)
-  Update Ember to v5.4 and drop support for Ember < 3.28 ([@mansona])
-- [ember-learn/guidemaker-ember-template]
-  [#177](https://github.com/ember-learn/guidemaker-ember-template/pull/177) use
-  sidebar styles from ember-styleguide ([@mansona])
-- [emberjs/ember-optional-features]
-  [#339](https://github.com/emberjs/ember-optional-features/pull/339) update
-  release-plan ([@mansona])
-- [emberjs/ember-optional-features]
-  [#338](https://github.com/emberjs/ember-optional-features/pull/338) switch to
-  npm ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#262](https://github.com/embroider-build/addon-blueprint/pull/262) fix
-  workspace definition ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#260](https://github.com/embroider-build/addon-blueprint/pull/260) update
-  release-plan ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#259](https://github.com/embroider-build/addon-blueprint/pull/259) remove
-  wyvox/action-setup-pnpm to realign with ember-cli ([@mansona])
-- [lan0/ember-power-time-picker]
-  [#20](https://github.com/lan0/ember-power-time-picker/pull/20) Upgrade to
-  ember 3.28 ([@Mikek2252])
-- [mainmatter/ember-promise-modals]
-  [#920](https://github.com/mainmatter/ember-promise-modals/pull/920) Convert
-  the addon to v2 ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#919](https://github.com/mainmatter/ember-promise-modals/pull/919) Use
-  co-location in the addon package ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#918](https://github.com/mainmatter/ember-promise-modals/pull/918) Realign
-  internal components names to use the default convention ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#917](https://github.com/mainmatter/ember-promise-modals/pull/917) Fix the
-  deployment workflow of the test-app ([@BlueCutOfficial])
-- [miragejs/ember-cli-mirage]
-  [#2575](https://github.com/miragejs/ember-cli-mirage/pull/2575) use pnpm node
-  version selection instead of volta ([@mansona])
-- [miragejs/ember-cli-mirage]
-  [#2574](https://github.com/miragejs/ember-cli-mirage/pull/2574) Fix
-  initialiser location ([@mansona])
-- [nickschot/ember-gesture-modifiers]
-  [#648](https://github.com/nickschot/ember-gesture-modifiers/pull/648) Setup
-  release-plan ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#897](https://github.com/nickschot/ember-mobile-menu/pull/897) Fix docs
-  deploy ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#892](https://github.com/nickschot/ember-mobile-menu/pull/892) Setup
-  release-plan ([@nickschot])
-- [nickschot/ember-mobile-menu]
-  [#891](https://github.com/nickschot/ember-mobile-menu/pull/891) Inline body
-  scroll lock library, apply small fixes & (unofficial) fastboot support
-  ([@nickschot])
+- [adopted-ember-addons/ember-collapsible-panel] [#162](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/162) fix workflow file format ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#161](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/161) fix release-plan label dispatch ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#159](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/159) don't remove stderr.log if release-plan fails ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#158](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/158) fix error-handling for release-plan ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#157](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/157) fix exit code for release-plan ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#156](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/156) testing error-handling in release-plan ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#155](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/155) update release-plan ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#151](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/151) try to setup renovate to batch updates ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#149](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/149) start using release-plan ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#145](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/145) update to v5.4 with ember-cli-update and add Ember 5 support ([@mansona])
+- [adopted-ember-addons/ember-collapsible-panel] [#142](https://github.com/adopted-ember-addons/ember-collapsible-panel/pull/142) switch to pnpm ([@mansona])
+- [ember-codemods/ember-angle-brackets-codemod] [#525](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/525) update release-plan ([@mansona])
+- [ember-codemods/ember-angle-brackets-codemod] [#517](https://github.com/ember-codemods/ember-angle-brackets-codemod/pull/517) create dependabot config with batching for minor changes ([@mansona])
+- [ember-fastboot/ember-cli-fastboot] [#932](https://github.com/ember-fastboot/ember-cli-fastboot/pull/932) update CI action versions ([@mansona])
+- [ember-learn/ember-styleguide] [#507](https://github.com/ember-learn/ember-styleguide/pull/507) make sidebar content slightly wider and add background colour ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#178](https://github.com/ember-learn/guidemaker-ember-template/pull/178) Update Ember to v5.4 and drop support for Ember < 3.28 ([@mansona])
+- [ember-learn/guidemaker-ember-template] [#177](https://github.com/ember-learn/guidemaker-ember-template/pull/177) use sidebar styles from ember-styleguide ([@mansona])
+- [emberjs/ember-optional-features] [#339](https://github.com/emberjs/ember-optional-features/pull/339) update release-plan ([@mansona])
+- [emberjs/ember-optional-features] [#338](https://github.com/emberjs/ember-optional-features/pull/338) switch to npm ([@mansona])
+- [embroider-build/addon-blueprint] [#262](https://github.com/embroider-build/addon-blueprint/pull/262) fix workspace definition ([@mansona])
+- [embroider-build/addon-blueprint] [#260](https://github.com/embroider-build/addon-blueprint/pull/260) update release-plan ([@mansona])
+- [embroider-build/addon-blueprint] [#259](https://github.com/embroider-build/addon-blueprint/pull/259) remove wyvox/action-setup-pnpm to realign with ember-cli ([@mansona])
+- [lan0/ember-power-time-picker] [#20](https://github.com/lan0/ember-power-time-picker/pull/20) Upgrade to ember 3.28 ([@Mikek2252])
+- [mainmatter/ember-promise-modals] [#920](https://github.com/mainmatter/ember-promise-modals/pull/920) Convert the addon to v2 ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#919](https://github.com/mainmatter/ember-promise-modals/pull/919) Use co-location in the addon package ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#918](https://github.com/mainmatter/ember-promise-modals/pull/918) Realign internal components names to use the default convention ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#917](https://github.com/mainmatter/ember-promise-modals/pull/917) Fix the deployment workflow of the test-app ([@BlueCutOfficial])
+- [miragejs/ember-cli-mirage] [#2575](https://github.com/miragejs/ember-cli-mirage/pull/2575) use pnpm node version selection instead of volta ([@mansona])
+- [miragejs/ember-cli-mirage] [#2574](https://github.com/miragejs/ember-cli-mirage/pull/2574) Fix initialiser location ([@mansona])
+- [nickschot/ember-gesture-modifiers] [#648](https://github.com/nickschot/ember-gesture-modifiers/pull/648) Setup release-plan ([@nickschot])
+- [nickschot/ember-mobile-menu] [#897](https://github.com/nickschot/ember-mobile-menu/pull/897) Fix docs deploy ([@nickschot])
+- [nickschot/ember-mobile-menu] [#892](https://github.com/nickschot/ember-mobile-menu/pull/892) Setup release-plan ([@nickschot])
+- [nickschot/ember-mobile-menu] [#891](https://github.com/nickschot/ember-mobile-menu/pull/891) Inline body scroll lock library, apply small fixes & (unofficial) fastboot support ([@nickschot])
 
 ## Project Forms
 
-- [project-forms/project-forms.github.io]
-  [#46](https://github.com/project-forms/project-forms.github.io/pull/46) WIP
-  migrate loaders and actions ([@oscard0m])
-- [project-forms/project-forms.github.io]
-  [#45](https://github.com/project-forms/project-forms.github.io/pull/45)
-  build(jsconfig): check types in `*.js` files by default ([@oscard0m])
-- [project-forms/project-forms.github.io]
-  [#44](https://github.com/project-forms/project-forms.github.io/pull/44)
-  test(integration): add a snapshot to capture the Loading UI in `/new`
-  ([@oscard0m])
-- [project-forms/project-forms.github.io]
-  [#43](https://github.com/project-forms/project-forms.github.io/pull/43) add
-  vitest watch mode to package.json ([@oscard0m])
+- [project-forms/project-forms.github.io] [#46](https://github.com/project-forms/project-forms.github.io/pull/46) WIP migrate loaders and actions ([@oscard0m])
+- [project-forms/project-forms.github.io] [#45](https://github.com/project-forms/project-forms.github.io/pull/45) build(jsconfig): check types in `*.js` files by default ([@oscard0m])
+- [project-forms/project-forms.github.io] [#44](https://github.com/project-forms/project-forms.github.io/pull/44) test(integration): add a snapshot to capture the Loading UI in `/new` ([@oscard0m])
+- [project-forms/project-forms.github.io] [#43](https://github.com/project-forms/project-forms.github.io/pull/43) add vitest watch mode to package.json ([@oscard0m])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@Mikek2252]: https://github.com/Mikek2252
@@ -196,36 +81,23 @@
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@zeppelin]: https://github.com/zeppelin
-[adopted-ember-addons/ember-collapsible-panel]:
-  https://github.com/adopted-ember-addons/ember-collapsible-panel
-[ember-codemods/ember-angle-brackets-codemod]:
-  https://github.com/ember-codemods/ember-angle-brackets-codemod
-[ember-fastboot/ember-cli-fastboot]:
-  https://github.com/ember-fastboot/ember-cli-fastboot
+[adopted-ember-addons/ember-collapsible-panel]: https://github.com/adopted-ember-addons/ember-collapsible-panel
+[ember-codemods/ember-angle-brackets-codemod]: https://github.com/ember-codemods/ember-angle-brackets-codemod
+[ember-fastboot/ember-cli-fastboot]: https://github.com/ember-fastboot/ember-cli-fastboot
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
-[ember-learn/guidemaker-ember-template]:
-  https://github.com/ember-learn/guidemaker-ember-template
-[emberjs/ember-optional-features]:
-  https://github.com/emberjs/ember-optional-features
-[embroider-build/addon-blueprint]:
-  https://github.com/embroider-build/addon-blueprint
+[ember-learn/guidemaker-ember-template]: https://github.com/ember-learn/guidemaker-ember-template
+[emberjs/ember-optional-features]: https://github.com/emberjs/ember-optional-features
+[embroider-build/addon-blueprint]: https://github.com/embroider-build/addon-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[embroider-build/github-changelog]:
-  https://github.com/embroider-build/github-changelog
+[embroider-build/github-changelog]: https://github.com/embroider-build/github-changelog
 [embroider-build/release-plan]: https://github.com/embroider-build/release-plan
 [lan0/ember-power-time-picker]: https://github.com/lan0/ember-power-time-picker
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
-[mainmatter/svelte-promise-modals]:
-  https://github.com/mainmatter/svelte-promise-modals
-[mansona/create-release-plan-setup]:
-  https://github.com/mansona/create-release-plan-setup
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
+[mainmatter/svelte-promise-modals]: https://github.com/mainmatter/svelte-promise-modals
+[mansona/create-release-plan-setup]: https://github.com/mansona/create-release-plan-setup
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [miragejs/ember-cli-mirage]: https://github.com/miragejs/ember-cli-mirage
-[nickschot/ember-gesture-modifiers]:
-  https://github.com/nickschot/ember-gesture-modifiers
+[nickschot/ember-gesture-modifiers]: https://github.com/nickschot/ember-gesture-modifiers
 [nickschot/ember-mobile-menu]: https://github.com/nickschot/ember-mobile-menu
-[paoloricciuti/sveltekit-search-params]:
-  https://github.com/paoloricciuti/sveltekit-search-params
-[project-forms/project-forms.github.io]:
-  https://github.com/project-forms/project-forms.github.io
+[paoloricciuti/sveltekit-search-params]: https://github.com/paoloricciuti/sveltekit-search-params
+[project-forms/project-forms.github.io]: https://github.com/project-forms/project-forms.github.io
diff --git a/src/twios/2024-02-25.md b/src/twios/2024-02-25.md
index 314aec5259..544afbd926 100644
--- a/src/twios/2024-02-25.md
+++ b/src/twios/2024-02-25.md
@@ -1,56 +1,33 @@
 ## Svelte
 
-- [mainmatter/svelte-promise-modals]
-  [#77](https://github.com/mainmatter/svelte-promise-modals/pull/77) Throw on
-  invalid <ModalContainer> instance count ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#77](https://github.com/mainmatter/svelte-promise-modals/pull/77) Throw on invalid <ModalContainer> instance count ([@zeppelin])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1811](https://github.com/embroider-build/embroider/pull/1811) Module
-  Resolver: Virtual test-support.css ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1807](https://github.com/embroider-build/embroider/pull/1807) Module
-  resolver: virtualize test-support.js ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1811](https://github.com/embroider-build/embroider/pull/1811) Module Resolver: Virtual test-support.css ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1807](https://github.com/embroider-build/embroider/pull/1807) Module resolver: virtualize test-support.js ([@BlueCutOfficial])
 
 ## Empress
 
-- [empress/empress-blog]
-  [#184](https://github.com/empress/empress-blog/pull/184) setup release-plan
-  ([@mansona])
+- [empress/empress-blog] [#184](https://github.com/empress/empress-blog/pull/184) setup release-plan ([@mansona])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#242](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/242)
-  Translate guides/tutorial/part-2/ember-data.md ([@BlueCutOfficial])
-- [bgantzler/ember-mirage]
-  [#26](https://github.com/bgantzler/ember-mirage/pull/26) Reset blueprint to
-  latest v2 ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#262](https://github.com/embroider-build/addon-blueprint/pull/262) fix
-  workspace definition ([@mansona])
-- [nickschot/ember-mobile-pane]
-  [#54](https://github.com/nickschot/ember-mobile-pane/pull/54) Upgrade to
-  ember-cli 4.12.0 blueprint ([@nickschot])
-- [nickschot/ember-mobile-pane]
-  [#50](https://github.com/nickschot/ember-mobile-pane/pull/50) Add
-  renovate.json ([@nickschot])
-- [nickschot/ember-mobile-pane]
-  [#49](https://github.com/nickschot/ember-mobile-pane/pull/49) drop ember <
-  3.28, update CI config, switch to pnpm ([@nickschot])
+- [DazzlingFugu/ember-fr-guides-source] [#242](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/242) Translate guides/tutorial/part-2/ember-data.md ([@BlueCutOfficial])
+- [bgantzler/ember-mirage] [#26](https://github.com/bgantzler/ember-mirage/pull/26) Reset blueprint to latest v2 ([@mansona])
+- [embroider-build/addon-blueprint] [#262](https://github.com/embroider-build/addon-blueprint/pull/262) fix workspace definition ([@mansona])
+- [nickschot/ember-mobile-pane] [#54](https://github.com/nickschot/ember-mobile-pane/pull/54) Upgrade to ember-cli 4.12.0 blueprint ([@nickschot])
+- [nickschot/ember-mobile-pane] [#50](https://github.com/nickschot/ember-mobile-pane/pull/50) Add renovate.json ([@nickschot])
+- [nickschot/ember-mobile-pane] [#49](https://github.com/nickschot/ember-mobile-pane/pull/49) drop ember < 3.28, update CI config, switch to pnpm ([@nickschot])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@nickschot]: https://github.com/nickschot
 [@zeppelin]: https://github.com/zeppelin
-[DazzlingFugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [bgantzler/ember-mirage]: https://github.com/bgantzler/ember-mirage
-[embroider-build/addon-blueprint]:
-  https://github.com/embroider-build/addon-blueprint
+[embroider-build/addon-blueprint]: https://github.com/embroider-build/addon-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [empress/empress-blog]: https://github.com/empress/empress-blog
-[mainmatter/svelte-promise-modals]:
-  https://github.com/mainmatter/svelte-promise-modals
+[mainmatter/svelte-promise-modals]: https://github.com/mainmatter/svelte-promise-modals
 [nickschot/ember-mobile-pane]: https://github.com/nickschot/ember-mobile-pane
diff --git a/src/twios/2024-03-03.md b/src/twios/2024-03-03.md
index 4e42f1d26c..6bb11c3457 100644
--- a/src/twios/2024-03-03.md
+++ b/src/twios/2024-03-03.md
@@ -1,70 +1,34 @@
 ## Svelte
 
-- [oscard0m/test-sveltekit]
-  [#47](https://github.com/oscard0m/test-sveltekit/pull/47) Delete
-  static/favicon.png ([@oscard0m])
+- [oscard0m/test-sveltekit] [#47](https://github.com/oscard0m/test-sveltekit/pull/47) Delete static/favicon.png ([@oscard0m])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1825](https://github.com/embroider-build/embroider/pull/1825) Merge stable
-  into main ([@mansona])
-- [embroider-build/embroider]
-  [#1824](https://github.com/embroider-build/embroider/pull/1824) update
-  release-plan ([@mansona])
-- [embroider-build/embroider]
-  [#1817](https://github.com/embroider-build/embroider/pull/1817) pin ember-data
-  to fix issue in CI ([@mansona])
-- [embroider-build/embroider]
-  [#1794](https://github.com/embroider-build/embroider/pull/1794) Refactor the
-  resolve function to be the only public api to module-resolver ([@mansona])
-- [embroider-build/embroider]
-  [#1819](https://github.com/embroider-build/embroider/pull/1819) Add a new
-  prebuild function with strict defaults ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1825](https://github.com/embroider-build/embroider/pull/1825) Merge stable into main ([@mansona])
+- [embroider-build/embroider] [#1824](https://github.com/embroider-build/embroider/pull/1824) update release-plan ([@mansona])
+- [embroider-build/embroider] [#1817](https://github.com/embroider-build/embroider/pull/1817) pin ember-data to fix issue in CI ([@mansona])
+- [embroider-build/embroider] [#1794](https://github.com/embroider-build/embroider/pull/1794) Refactor the resolve function to be the only public api to module-resolver ([@mansona])
+- [embroider-build/embroider] [#1819](https://github.com/embroider-build/embroider/pull/1819) Add a new prebuild function with strict defaults ([@BlueCutOfficial])
 
 ## Ember
 
-- [adopted-ember-addons/ember-cp-validations]
-  [#752](https://github.com/adopted-ember-addons/ember-cp-validations/pull/752)
-  start using release-plan ([@mansona])
-- [adopted-ember-addons/ember-cp-validations]
-  [#751](https://github.com/adopted-ember-addons/ember-cp-validations/pull/751)
-  switch to pnpm ([@mansona])
-- [adopted-ember-addons/ember-cp-validations]
-  [#749](https://github.com/adopted-ember-addons/ember-cp-validations/pull/749)
-  update @embroider/test-setup to fix CI ([@mansona])
-- [bgantzler/ember-mirage]
-  [#28](https://github.com/bgantzler/ember-mirage/pull/28) start using
-  release-plan for deployment ([@mansona])
-- [bgantzler/ember-mirage]
-  [#27](https://github.com/bgantzler/ember-mirage/pull/27) Update readme and
-  migration guide ([@mansona])
-- [bgantzler/ember-mirage]
-  [#26](https://github.com/bgantzler/ember-mirage/pull/26) Reset blueprint to
-  latest v2 ([@mansona])
-- [ember-learn/guides-source]
-  [#2000](https://github.com/ember-learn/guides-source/pull/2000) Fix tutorial
-  ([@mansona])
-- [mainmatter/ember-promise-modals]
-  [#925](https://github.com/mainmatter/ember-promise-modals/pull/925) ci (fix):
-  in the deploy workflow, move the install before the addon build
-  ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#924](https://github.com/mainmatter/ember-promise-modals/pull/924) CI (fix):
-  Build the addon before building and deploying the test app
-  ([@BlueCutOfficial])
-- [mainmatter/ember-promise-modals]
-  [#920](https://github.com/mainmatter/ember-promise-modals/pull/920) Convert
-  the addon to v2 ([@BlueCutOfficial])
+- [adopted-ember-addons/ember-cp-validations] [#752](https://github.com/adopted-ember-addons/ember-cp-validations/pull/752) start using release-plan ([@mansona])
+- [adopted-ember-addons/ember-cp-validations] [#751](https://github.com/adopted-ember-addons/ember-cp-validations/pull/751) switch to pnpm ([@mansona])
+- [adopted-ember-addons/ember-cp-validations] [#749](https://github.com/adopted-ember-addons/ember-cp-validations/pull/749) update @embroider/test-setup to fix CI ([@mansona])
+- [bgantzler/ember-mirage] [#28](https://github.com/bgantzler/ember-mirage/pull/28) start using release-plan for deployment ([@mansona])
+- [bgantzler/ember-mirage] [#27](https://github.com/bgantzler/ember-mirage/pull/27) Update readme and migration guide ([@mansona])
+- [bgantzler/ember-mirage] [#26](https://github.com/bgantzler/ember-mirage/pull/26) Reset blueprint to latest v2 ([@mansona])
+- [ember-learn/guides-source] [#2000](https://github.com/ember-learn/guides-source/pull/2000) Fix tutorial ([@mansona])
+- [mainmatter/ember-promise-modals] [#925](https://github.com/mainmatter/ember-promise-modals/pull/925) ci (fix): in the deploy workflow, move the install before the addon build ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#924](https://github.com/mainmatter/ember-promise-modals/pull/924) CI (fix): Build the addon before building and deploying the test app ([@BlueCutOfficial])
+- [mainmatter/ember-promise-modals] [#920](https://github.com/mainmatter/ember-promise-modals/pull/920) Convert the addon to v2 ([@BlueCutOfficial])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@oscard0m]: https://github.com/oscard0m
-[adopted-ember-addons/ember-cp-validations]:
-  https://github.com/adopted-ember-addons/ember-cp-validations
+[adopted-ember-addons/ember-cp-validations]: https://github.com/adopted-ember-addons/ember-cp-validations
 [bgantzler/ember-mirage]: https://github.com/bgantzler/ember-mirage
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [oscard0m/test-sveltekit]: https://github.com/oscard0m/test-sveltekit
diff --git a/src/twios/2024-03-10.md b/src/twios/2024-03-10.md
index 02080bdfb5..ed6497f744 100644
--- a/src/twios/2024-03-10.md
+++ b/src/twios/2024-03-10.md
@@ -1,75 +1,40 @@
 ## Rust
 
-- [marcoow/pacesetter] [#32](https://github.com/marcoow/pacesetter/pull/32) add
-  API docs ([@marcoow])
+- [marcoow/pacesetter] [#32](https://github.com/marcoow/pacesetter/pull/32) add API docs ([@marcoow])
 
 ## Svelte
 
-- [melt-ui/melt-ui] [#1076](https://github.com/melt-ui/melt-ui/pull/1076) fix:
-  datepicker not syncing with calendar ([@paoloricciuti])
-- [melt-ui/melt-ui] [#1072](https://github.com/melt-ui/melt-ui/pull/1072) fix:
-  months not updating when changing options (range calendar) ([@paoloricciuti])
-- [melt-ui/melt-ui] [#1070](https://github.com/melt-ui/melt-ui/pull/1070) fix:
-  months not updating when changing options ([@paoloricciuti])
+- [melt-ui/melt-ui] [#1076](https://github.com/melt-ui/melt-ui/pull/1076) fix: datepicker not syncing with calendar ([@paoloricciuti])
+- [melt-ui/melt-ui] [#1072](https://github.com/melt-ui/melt-ui/pull/1072) fix: months not updating when changing options (range calendar) ([@paoloricciuti])
+- [melt-ui/melt-ui] [#1070](https://github.com/melt-ui/melt-ui/pull/1070) fix: months not updating when changing options ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1838](https://github.com/embroider-build/embroider/pull/1838) make sure
-  @embroider/macros doesn't try to load a babel config ([@mansona])
-- [embroider-build/embroider]
-  [#1834](https://github.com/embroider-build/embroider/pull/1834) add vite@5 to
-  the peer deps of @embroider/vite ([@mansona])
-- [embroider-build/embroider]
-  [#1827](https://github.com/embroider-build/embroider/pull/1827) fix extension
-  resolving for esbuild ([@mansona])
-- [embroider-build/embroider]
-  [#1837](https://github.com/embroider-build/embroider/pull/1837) merge default
-  options and the prebuild options provided in ember-cli-build
-  ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1838](https://github.com/embroider-build/embroider/pull/1838) make sure @embroider/macros doesn't try to load a babel config ([@mansona])
+- [embroider-build/embroider] [#1834](https://github.com/embroider-build/embroider/pull/1834) add vite@5 to the peer deps of @embroider/vite ([@mansona])
+- [embroider-build/embroider] [#1827](https://github.com/embroider-build/embroider/pull/1827) fix extension resolving for esbuild ([@mansona])
+- [embroider-build/embroider] [#1837](https://github.com/embroider-build/embroider/pull/1837) merge default options and the prebuild options provided in ember-cli-build ([@BlueCutOfficial])
 
 ## Empress
 
-- [empress/ember-cli-showdown]
-  [#147](https://github.com/empress/ember-cli-showdown/pull/147) fix peer
-  dependency ([@mansona])
-- [empress/guidemaker] [#105](https://github.com/empress/guidemaker/pull/105)
-  fix the location of the shorten-version helper ([@mansona])
-- [empress/guidemaker] [#102](https://github.com/empress/guidemaker/pull/102)
-  swap to pnpm ([@mansona])
-- [empress/guidemaker] [#91](https://github.com/empress/guidemaker/pull/91)
-  update to v5.4 with ember-cli-update and drop support for Ember < 3.28
-  ([@mansona])
-- [empress/guidemaker-default-template]
-  [#50](https://github.com/empress/guidemaker-default-template/pull/50) start
-  using release-plan ([@mansona])
-- [empress/guidemaker-default-template]
-  [#49](https://github.com/empress/guidemaker-default-template/pull/49) convert
-  to a v2 addon ([@mansona])
+- [empress/ember-cli-showdown] [#147](https://github.com/empress/ember-cli-showdown/pull/147) fix peer dependency ([@mansona])
+- [empress/guidemaker] [#105](https://github.com/empress/guidemaker/pull/105) fix the location of the shorten-version helper ([@mansona])
+- [empress/guidemaker] [#102](https://github.com/empress/guidemaker/pull/102) swap to pnpm ([@mansona])
+- [empress/guidemaker] [#91](https://github.com/empress/guidemaker/pull/91) update to v5.4 with ember-cli-update and drop support for Ember < 3.28 ([@mansona])
+- [empress/guidemaker-default-template] [#50](https://github.com/empress/guidemaker-default-template/pull/50) start using release-plan ([@mansona])
+- [empress/guidemaker-default-template] [#49](https://github.com/empress/guidemaker-default-template/pull/49) convert to a v2 addon ([@mansona])
 
 ## Octokit
 
-- [octoherd/octokit] [#79](https://github.com/octoherd/octokit/pull/79)
-  chore(.gitignore): fix typo in filename ([@oscard0m])
+- [octoherd/octokit] [#79](https://github.com/octoherd/octokit/pull/79) chore(.gitignore): fix typo in filename ([@oscard0m])
 
 ## Ember
 
-- [bgantzler/ember-mirage]
-  [#32](https://github.com/bgantzler/ember-mirage/pull/32) reset addon version
-  to what is deployed on npm ([@mansona])
-- [bgantzler/ember-mirage]
-  [#31](https://github.com/bgantzler/ember-mirage/pull/31) update addon
-  blueprint to v2.14 with ember-cli-update ([@mansona])
-- [bgantzler/ember-mirage]
-  [#30](https://github.com/bgantzler/ember-mirage/pull/30) swap from
-  ember-inflector to active-inflector ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#268](https://github.com/embroider-build/addon-blueprint/pull/268) use our
-  own version of ember-cli so the test app is always generated with the latest
-  blueprint ([@mansona])
-- [embroider-build/addon-blueprint]
-  [#266](https://github.com/embroider-build/addon-blueprint/pull/266) add a
-  timeout minutes to the CI jobs ([@mansona])
+- [bgantzler/ember-mirage] [#32](https://github.com/bgantzler/ember-mirage/pull/32) reset addon version to what is deployed on npm ([@mansona])
+- [bgantzler/ember-mirage] [#31](https://github.com/bgantzler/ember-mirage/pull/31) update addon blueprint to v2.14 with ember-cli-update ([@mansona])
+- [bgantzler/ember-mirage] [#30](https://github.com/bgantzler/ember-mirage/pull/30) swap from ember-inflector to active-inflector ([@mansona])
+- [embroider-build/addon-blueprint] [#268](https://github.com/embroider-build/addon-blueprint/pull/268) use our own version of ember-cli so the test app is always generated with the latest blueprint ([@mansona])
+- [embroider-build/addon-blueprint] [#266](https://github.com/embroider-build/addon-blueprint/pull/266) add a timeout minutes to the CI jobs ([@mansona])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
@@ -77,12 +42,10 @@
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
 [bgantzler/ember-mirage]: https://github.com/bgantzler/ember-mirage
-[embroider-build/addon-blueprint]:
-  https://github.com/embroider-build/addon-blueprint
+[embroider-build/addon-blueprint]: https://github.com/embroider-build/addon-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [empress/ember-cli-showdown]: https://github.com/empress/ember-cli-showdown
-[empress/guidemaker-default-template]:
-  https://github.com/empress/guidemaker-default-template
+[empress/guidemaker-default-template]: https://github.com/empress/guidemaker-default-template
 [empress/guidemaker]: https://github.com/empress/guidemaker
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [melt-ui/melt-ui]: https://github.com/melt-ui/melt-ui
diff --git a/src/twios/2024-03-17.md b/src/twios/2024-03-17.md
index 0239c64534..f300464448 100644
--- a/src/twios/2024-03-17.md
+++ b/src/twios/2024-03-17.md
@@ -1,59 +1,35 @@
 ## Svelte
 
-- [melt-ui/melt-ui] [#1076](https://github.com/melt-ui/melt-ui/pull/1076) fix:
-  datepicker not syncing with calendar ([@paoloricciuti])
+- [melt-ui/melt-ui] [#1076](https://github.com/melt-ui/melt-ui/pull/1076) fix: datepicker not syncing with calendar ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/github-changelog]
-  [#19](https://github.com/embroider-build/github-changelog/pull/19) fix npm
-  badge to point at the right package ([@mansona])
-- [embroider-build/github-changelog]
-  [#17](https://github.com/embroider-build/github-changelog/pull/17) swap
-  everything to be github-changelog ([@mansona])
+- [embroider-build/github-changelog] [#19](https://github.com/embroider-build/github-changelog/pull/19) fix npm badge to point at the right package ([@mansona])
+- [embroider-build/github-changelog] [#17](https://github.com/embroider-build/github-changelog/pull/17) swap everything to be github-changelog ([@mansona])
 
 ## JavaScript
 
-- [embroider-build/release-plan]
-  [#67](https://github.com/embroider-build/release-plan/pull/67) fix typo in
-  release-plan setup ([@mansona])
-- [embroider-build/release-plan]
-  [#66](https://github.com/embroider-build/release-plan/pull/66) start using
-  github-changelog ([@mansona])
-- [embroider-build/release-plan]
-  [#64](https://github.com/embroider-build/release-plan/pull/64) update
-  release-plan-setup ([@mansona])
-- [pichfl/auto-reveal] [#6](https://github.com/pichfl/auto-reveal/pull/6) Add
-  README, Run Formatter ([@pichfl])
+- [embroider-build/release-plan] [#67](https://github.com/embroider-build/release-plan/pull/67) fix typo in release-plan setup ([@mansona])
+- [embroider-build/release-plan] [#66](https://github.com/embroider-build/release-plan/pull/66) start using github-changelog ([@mansona])
+- [embroider-build/release-plan] [#64](https://github.com/embroider-build/release-plan/pull/64) update release-plan-setup ([@mansona])
+- [pichfl/auto-reveal] [#6](https://github.com/pichfl/auto-reveal/pull/6) Add README, Run Formatter ([@pichfl])
 
 ## Ember
 
-- [bgantzler/ember-mirage]
-  [#38](https://github.com/bgantzler/ember-mirage/pull/38) put the repository
-  reference in the right package ([@mansona])
-- [bgantzler/ember-mirage]
-  [#36](https://github.com/bgantzler/ember-mirage/pull/36) fix github backlink
-  from npm ([@mansona])
-- [mainmatter/ember-promise-modals]
-  [#927](https://github.com/mainmatter/ember-promise-modals/pull/927) Prepare
-  the release process ([@BlueCutOfficial])
-- [yapplabs/ember-tether]
-  [#129](https://github.com/yapplabs/ember-tether/pull/129) Update to Ember v5.4
-  with ember-cli-update ([@mansona])
-- [yapplabs/ember-tether]
-  [#128](https://github.com/yapplabs/ember-tether/pull/128) use pnpm
-  ([@mansona])
+- [bgantzler/ember-mirage] [#38](https://github.com/bgantzler/ember-mirage/pull/38) put the repository reference in the right package ([@mansona])
+- [bgantzler/ember-mirage] [#36](https://github.com/bgantzler/ember-mirage/pull/36) fix github backlink from npm ([@mansona])
+- [mainmatter/ember-promise-modals] [#927](https://github.com/mainmatter/ember-promise-modals/pull/927) Prepare the release process ([@BlueCutOfficial])
+- [yapplabs/ember-tether] [#129](https://github.com/yapplabs/ember-tether/pull/129) Update to Ember v5.4 with ember-cli-update ([@mansona])
+- [yapplabs/ember-tether] [#128](https://github.com/yapplabs/ember-tether/pull/128) use pnpm ([@mansona])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@pichfl]: https://github.com/pichfl
 [bgantzler/ember-mirage]: https://github.com/bgantzler/ember-mirage
-[embroider-build/github-changelog]:
-  https://github.com/embroider-build/github-changelog
+[embroider-build/github-changelog]: https://github.com/embroider-build/github-changelog
 [embroider-build/release-plan]: https://github.com/embroider-build/release-plan
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
 [melt-ui/melt-ui]: https://github.com/melt-ui/melt-ui
 [pichfl/auto-reveal]: https://github.com/pichfl/auto-reveal
 [yapplabs/ember-tether]: https://github.com/yapplabs/ember-tether
diff --git a/src/twios/2024-03-24.md b/src/twios/2024-03-24.md
index ea15f1cd39..d4ce5cd09f 100644
--- a/src/twios/2024-03-24.md
+++ b/src/twios/2024-03-24.md
@@ -1,24 +1,14 @@
 ## Svelte
 
-- [mainmatter/svelte-concurrency]
-  [#10](https://github.com/mainmatter/svelte-concurrency/pull/10) feat: handlers
-  abstraction + queue ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#10](https://github.com/mainmatter/svelte-concurrency/pull/10) feat: handlers abstraction + queue ([@paoloricciuti])
 
 ## Ember
 
-- [Authmaker/authmaker-ember-simple-auth]
-  [#50](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/50) Update
-  to 5.7 with ember-cli-update ([@mansona])
-- [Authmaker/authmaker-ember-simple-auth]
-  [#48](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/48) start
-  using release-plan ([@mansona])
-- [Authmaker/authmaker-ember-simple-auth]
-  [#47](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/47) update
-  ember-simple-auth, move to pnpm, and drop support for Node < 18 ([@mansona])
+- [Authmaker/authmaker-ember-simple-auth] [#50](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/50) Update to 5.7 with ember-cli-update ([@mansona])
+- [Authmaker/authmaker-ember-simple-auth] [#48](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/48) start using release-plan ([@mansona])
+- [Authmaker/authmaker-ember-simple-auth] [#47](https://github.com/Authmaker/authmaker-ember-simple-auth/pull/47) update ember-simple-auth, move to pnpm, and drop support for Node < 18 ([@mansona])
 
 [@mansona]: https://github.com/mansona
 [@paoloricciuti]: https://github.com/paoloricciuti
-[Authmaker/authmaker-ember-simple-auth]:
-  https://github.com/Authmaker/authmaker-ember-simple-auth
-[mainmatter/svelte-concurrency]:
-  https://github.com/mainmatter/svelte-concurrency
+[Authmaker/authmaker-ember-simple-auth]: https://github.com/Authmaker/authmaker-ember-simple-auth
+[mainmatter/svelte-concurrency]: https://github.com/mainmatter/svelte-concurrency
diff --git a/src/twios/2024-03-31.md b/src/twios/2024-03-31.md
index a4037a2e26..ce144d276d 100644
--- a/src/twios/2024-03-31.md
+++ b/src/twios/2024-03-31.md
@@ -1,36 +1,21 @@
 ## Rust
 
-- [mainmatter/cargo-autoinherit]
-  [#13](https://github.com/mainmatter/cargo-autoinherit/pull/13) fix: don't
-  overwrite a dependency that already exists in root Cargo.toml
-  ([@BobrImperator])
-- [marcoow/pacesetter] [#43](https://github.com/marcoow/pacesetter/pull/43) Fix
-  generators ([@marcoow])
-- [marcoow/pacesetter] [#42](https://github.com/marcoow/pacesetter/pull/42) use
-  new test APIs in generated files consistently ([@marcoow])
-- [marcoow/pacesetter] [#41](https://github.com/marcoow/pacesetter/pull/41)
-  switch to googletest for better assertions ([@marcoow])
-- [marcoow/pacesetter] [#40](https://github.com/marcoow/pacesetter/pull/40)
-  replace body parsing helpers with extensions on Body ([@marcoow])
-- [marcoow/pacesetter] [#39](https://github.com/marcoow/pacesetter/pull/39) use
-  better request API in tests ([@marcoow])
-- [marcoow/pacesetter] [#38](https://github.com/marcoow/pacesetter/pull/38)
-  inline pacesetter code into generated project ([@marcoow])
+- [mainmatter/cargo-autoinherit] [#13](https://github.com/mainmatter/cargo-autoinherit/pull/13) fix: don't overwrite a dependency that already exists in root Cargo.toml ([@BobrImperator])
+- [marcoow/pacesetter] [#43](https://github.com/marcoow/pacesetter/pull/43) Fix generators ([@marcoow])
+- [marcoow/pacesetter] [#42](https://github.com/marcoow/pacesetter/pull/42) use new test APIs in generated files consistently ([@marcoow])
+- [marcoow/pacesetter] [#41](https://github.com/marcoow/pacesetter/pull/41) switch to googletest for better assertions ([@marcoow])
+- [marcoow/pacesetter] [#40](https://github.com/marcoow/pacesetter/pull/40) replace body parsing helpers with extensions on Body ([@marcoow])
+- [marcoow/pacesetter] [#39](https://github.com/marcoow/pacesetter/pull/39) use better request API in tests ([@marcoow])
+- [marcoow/pacesetter] [#38](https://github.com/marcoow/pacesetter/pull/38) inline pacesetter code into generated project ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/svelte-concurrency]
-  [#40](https://github.com/mainmatter/svelte-concurrency/pull/40) chore: add
-  basic testing setup ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#39](https://github.com/mainmatter/svelte-concurrency/pull/39) chore: format
-  after prepare release ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#40](https://github.com/mainmatter/svelte-concurrency/pull/40) chore: add basic testing setup ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#39](https://github.com/mainmatter/svelte-concurrency/pull/39) chore: format after prepare release ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1846](https://github.com/embroider-build/embroider/pull/1846) Prevent
-  query-params added by vite to be passed to core logic ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1846](https://github.com/embroider-build/embroider/pull/1846) Prevent query-params added by vite to be passed to core logic ([@BlueCutOfficial])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@BobrImperator]: https://github.com/BobrImperator
@@ -38,6 +23,5 @@
 [@paoloricciuti]: https://github.com/paoloricciuti
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [mainmatter/cargo-autoinherit]: https://github.com/mainmatter/cargo-autoinherit
-[mainmatter/svelte-concurrency]:
-  https://github.com/mainmatter/svelte-concurrency
+[mainmatter/svelte-concurrency]: https://github.com/mainmatter/svelte-concurrency
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
diff --git a/src/twios/2024-04-07.md b/src/twios/2024-04-07.md
index 9f5c8f04a3..363eb4f29b 100644
--- a/src/twios/2024-04-07.md
+++ b/src/twios/2024-04-07.md
@@ -1,56 +1,31 @@
 ## Svelte
 
-- [mainmatter/svelte-concurrency]
-  [#45](https://github.com/mainmatter/svelte-concurrency/pull/45) feat: add max
-  to restartable ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#43](https://github.com/mainmatter/svelte-concurrency/pull/43) chore:
-  restructure testing and add tests for enqueue ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#41](https://github.com/mainmatter/svelte-concurrency/pull/41) fix: abort
-  when dropping ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#45](https://github.com/mainmatter/svelte-concurrency/pull/45) feat: add max to restartable ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#43](https://github.com/mainmatter/svelte-concurrency/pull/43) chore: restructure testing and add tests for enqueue ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#41](https://github.com/mainmatter/svelte-concurrency/pull/41) fix: abort when dropping ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1863](https://github.com/embroider-build/embroider/pull/1863) add isLazy to
-  resolver config and streamline Engine interface ([@mansona])
-- [embroider-build/embroider]
-  [#1840](https://github.com/embroider-build/embroider/pull/1840) Use Vite for
-  all tests ([@mansona])
-- [embroider-build/embroider]
-  [#1864](https://github.com/embroider-build/embroider/pull/1864) Make the
-  addon-template use vite ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1807](https://github.com/embroider-build/embroider/pull/1807) Module
-  resolver: virtualize test-support.js ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1863](https://github.com/embroider-build/embroider/pull/1863) add isLazy to resolver config and streamline Engine interface ([@mansona])
+- [embroider-build/embroider] [#1840](https://github.com/embroider-build/embroider/pull/1840) Use Vite for all tests ([@mansona])
+- [embroider-build/embroider] [#1864](https://github.com/embroider-build/embroider/pull/1864) Make the addon-template use vite ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1807](https://github.com/embroider-build/embroider/pull/1807) Module resolver: virtualize test-support.js ([@BlueCutOfficial])
 
 ## JavaScript
 
-- [embroider-build/create-release-plan-setup]
-  [#97](https://github.com/embroider-build/create-release-plan-setup/pull/97)
-  Fix repo url ([@mansona])
-- [embroider-build/create-release-plan-setup]
-  [#95](https://github.com/embroider-build/create-release-plan-setup/pull/95)
-  update to release-plan 0.9.0 ([@mansona])
+- [embroider-build/create-release-plan-setup] [#97](https://github.com/embroider-build/create-release-plan-setup/pull/97) Fix repo url ([@mansona])
+- [embroider-build/create-release-plan-setup] [#95](https://github.com/embroider-build/create-release-plan-setup/pull/95) update to release-plan 0.9.0 ([@mansona])
 
 ## Ember
 
-- [ember-engines/ember-engines]
-  [#873](https://github.com/ember-engines/ember-engines/pull/873) run npm init
-  release-plan-setup@latest ([@mansona])
-- [mainmatter/ember-promise-modals]
-  [#943](https://github.com/mainmatter/ember-promise-modals/pull/943) Remove
-  version numbers on private packages ([@BlueCutOfficial])
+- [ember-engines/ember-engines] [#873](https://github.com/ember-engines/ember-engines/pull/873) run npm init release-plan-setup@latest ([@mansona])
+- [mainmatter/ember-promise-modals] [#943](https://github.com/mainmatter/ember-promise-modals/pull/943) Remove version numbers on private packages ([@BlueCutOfficial])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@paoloricciuti]: https://github.com/paoloricciuti
 [ember-engines/ember-engines]: https://github.com/ember-engines/ember-engines
-[embroider-build/create-release-plan-setup]:
-  https://github.com/embroider-build/create-release-plan-setup
+[embroider-build/create-release-plan-setup]: https://github.com/embroider-build/create-release-plan-setup
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/ember-promise-modals]:
-  https://github.com/mainmatter/ember-promise-modals
-[mainmatter/svelte-concurrency]:
-  https://github.com/mainmatter/svelte-concurrency
+[mainmatter/ember-promise-modals]: https://github.com/mainmatter/ember-promise-modals
+[mainmatter/svelte-concurrency]: https://github.com/mainmatter/svelte-concurrency
diff --git a/src/twios/2024-04-14.md b/src/twios/2024-04-14.md
index a5e600edf4..4caff80087 100644
--- a/src/twios/2024-04-14.md
+++ b/src/twios/2024-04-14.md
@@ -1,64 +1,33 @@
 ## Rust
 
-- [marcoow/pacesetter] [#45](https://github.com/marcoow/pacesetter/pull/45) add
-  API docs for pacesetter itself ([@marcoow])
+- [marcoow/pacesetter] [#45](https://github.com/marcoow/pacesetter/pull/45) add API docs for pacesetter itself ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/svelte-promise-modals]
-  [#84](https://github.com/mainmatter/svelte-promise-modals/pull/84) Add
-  component import to example ([@zeppelin])
-- [mainmatter/svelte-promise-modals]
-  [#83](https://github.com/mainmatter/svelte-promise-modals/pull/83) Fix type
-  import path in README ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#84](https://github.com/mainmatter/svelte-promise-modals/pull/84) Add component import to example ([@zeppelin])
+- [mainmatter/svelte-promise-modals] [#83](https://github.com/mainmatter/svelte-promise-modals/pull/83) Fix type import path in README ([@zeppelin])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1874](https://github.com/embroider-build/embroider/pull/1874) with namespace
-  in publicAssets don't include path ([@mansona])
-- [embroider-build/embroider]
-  [#1872](https://github.com/embroider-build/embroider/pull/1872) Merge stable
-  ([@mansona])
-- [embroider-build/embroider]
-  [#1871](https://github.com/embroider-build/embroider/pull/1871) fix
-  release-plan unlabelled changes PR ([@mansona])
-- [embroider-build/embroider]
-  [#1869](https://github.com/embroider-build/embroider/pull/1869) update release
-  plan ([@mansona])
-- [embroider-build/embroider]
-  [#1867](https://github.com/embroider-build/embroider/pull/1867) add a
-  namespace option for public-assets plugin ([@mansona])
-- [embroider-build/embroider]
-  [#1856](https://github.com/embroider-build/embroider/pull/1856) Compile Hbs
-  route templates correctly ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1811](https://github.com/embroider-build/embroider/pull/1811) Module
-  Resolver: Virtual test-support.css ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1805](https://github.com/embroider-build/embroider/pull/1805) Module
-  resolver: virtualize vendor.css ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1874](https://github.com/embroider-build/embroider/pull/1874) with namespace in publicAssets don't include path ([@mansona])
+- [embroider-build/embroider] [#1872](https://github.com/embroider-build/embroider/pull/1872) Merge stable ([@mansona])
+- [embroider-build/embroider] [#1871](https://github.com/embroider-build/embroider/pull/1871) fix release-plan unlabelled changes PR ([@mansona])
+- [embroider-build/embroider] [#1869](https://github.com/embroider-build/embroider/pull/1869) update release plan ([@mansona])
+- [embroider-build/embroider] [#1867](https://github.com/embroider-build/embroider/pull/1867) add a namespace option for public-assets plugin ([@mansona])
+- [embroider-build/embroider] [#1856](https://github.com/embroider-build/embroider/pull/1856) Compile Hbs route templates correctly ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1811](https://github.com/embroider-build/embroider/pull/1811) Module Resolver: Virtual test-support.css ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1805](https://github.com/embroider-build/embroider/pull/1805) Module resolver: virtualize vendor.css ([@BlueCutOfficial])
 
 ## JavaScript
 
-- [shikijs/shiki-magic-move]
-  [#9](https://github.com/shikijs/shiki-magic-move/pull/9) fix: containerStyle
-  true blocks render promise from resolving ([@paoloricciuti])
-- [stefanpenner/node-fixturify-project]
-  [#89](https://github.com/stefanpenner/node-fixturify-project/pull/89) swap to
-  pnpm ([@mansona])
+- [shikijs/shiki-magic-move] [#9](https://github.com/shikijs/shiki-magic-move/pull/9) fix: containerStyle true blocks render promise from resolving ([@paoloricciuti])
+- [stefanpenner/node-fixturify-project] [#89](https://github.com/stefanpenner/node-fixturify-project/pull/89) swap to pnpm ([@mansona])
 
 ## Ember
 
-- [cibernox/ember-power-calendar]
-  [#466](https://github.com/cibernox/ember-power-calendar/pull/466) Fix use of
-  dataset API in findCalendarGuid test-helper ([@nickschot])
-- [ember-learn/guides-source]
-  [#1998](https://github.com/ember-learn/guides-source/pull/1998) update all
-  `ember server` to `npm start` ([@mansona])
-- [mainmatter/qunit-dom]
-  [#2100](https://github.com/mainmatter/qunit-dom/pull/2100) chore(deps): bump
-  release-it-changelog to 6.1.0 ([@BobrImperator])
+- [cibernox/ember-power-calendar] [#466](https://github.com/cibernox/ember-power-calendar/pull/466) Fix use of dataset API in findCalendarGuid test-helper ([@nickschot])
+- [ember-learn/guides-source] [#1998](https://github.com/ember-learn/guides-source/pull/1998) update all `ember server` to `npm start` ([@mansona])
+- [mainmatter/qunit-dom] [#2100](https://github.com/mainmatter/qunit-dom/pull/2100) chore(deps): bump release-it-changelog to 6.1.0 ([@BobrImperator])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@BobrImperator]: https://github.com/BobrImperator
@@ -67,14 +36,11 @@
 [@nickschot]: https://github.com/nickschot
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@zeppelin]: https://github.com/zeppelin
-[cibernox/ember-power-calendar]:
-  https://github.com/cibernox/ember-power-calendar
+[cibernox/ember-power-calendar]: https://github.com/cibernox/ember-power-calendar
 [ember-learn/guides-source]: https://github.com/ember-learn/guides-source
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [mainmatter/qunit-dom]: https://github.com/mainmatter/qunit-dom
-[mainmatter/svelte-promise-modals]:
-  https://github.com/mainmatter/svelte-promise-modals
+[mainmatter/svelte-promise-modals]: https://github.com/mainmatter/svelte-promise-modals
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [shikijs/shiki-magic-move]: https://github.com/shikijs/shiki-magic-move
-[stefanpenner/node-fixturify-project]:
-  https://github.com/stefanpenner/node-fixturify-project
+[stefanpenner/node-fixturify-project]: https://github.com/stefanpenner/node-fixturify-project
diff --git a/src/twios/2024-04-21.md b/src/twios/2024-04-21.md
index 6d45aabf21..861b7d73d0 100644
--- a/src/twios/2024-04-21.md
+++ b/src/twios/2024-04-21.md
@@ -1,72 +1,39 @@
 ## Svelte
 
-- [mainmatter/svelte-concurrency]
-  [#50](https://github.com/mainmatter/svelte-concurrency/pull/50) chore: fix
-  lockfile ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#46](https://github.com/mainmatter/svelte-concurrency/pull/46) chore: async
-  transform tests ([@paoloricciuti])
-- [sveltejs/svelte] [#11237](https://github.com/sveltejs/svelte/pull/11237) fix:
-  possible name clash in hoisted functions ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#50](https://github.com/mainmatter/svelte-concurrency/pull/50) chore: fix lockfile ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#46](https://github.com/mainmatter/svelte-concurrency/pull/46) chore: async transform tests ([@paoloricciuti])
+- [sveltejs/svelte] [#11237](https://github.com/sveltejs/svelte/pull/11237) fix: possible name clash in hoisted functions ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1884](https://github.com/embroider-build/embroider/pull/1884) don't use
-  babel-plugin-module-resolver@5.0.1 ([@mansona])
-- [embroider-build/embroider]
-  [#1879](https://github.com/embroider-build/embroider/pull/1879) Delete vite
-  app from test scenarios ([@mansona])
-- [embroider-build/embroider]
-  [#1877](https://github.com/embroider-build/embroider/pull/1877) Command
-  Watcher ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1859](https://github.com/embroider-build/embroider/pull/1859) Public assets
-  handling/ clean up stage 2 ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1836](https://github.com/embroider-build/embroider/pull/1836) Replace
-  content-for using a Vite plugin ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1884](https://github.com/embroider-build/embroider/pull/1884) don't use babel-plugin-module-resolver@5.0.1 ([@mansona])
+- [embroider-build/embroider] [#1879](https://github.com/embroider-build/embroider/pull/1879) Delete vite app from test scenarios ([@mansona])
+- [embroider-build/embroider] [#1877](https://github.com/embroider-build/embroider/pull/1877) Command Watcher ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1859](https://github.com/embroider-build/embroider/pull/1859) Public assets handling/ clean up stage 2 ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1836](https://github.com/embroider-build/embroider/pull/1836) Replace content-for using a Vite plugin ([@BlueCutOfficial])
 
 ## JavaScript
 
-- [adopted-ember-addons/ember-drag-drop]
-  [#2](https://github.com/adopted-ember-addons/ember-drag-drop/pull/2) setup
-  release-plan ([@mansona])
-- [adopted-ember-addons/ember-drag-drop]
-  [#1](https://github.com/adopted-ember-addons/ember-drag-drop/pull/1) Convert
-  to a v2 addon and drop support for Ember < 3.16 ([@mansona])
-- [tleunen/babel-plugin-module-resolver]
-  [#446](https://github.com/tleunen/babel-plugin-module-resolver/pull/446)
-  revert breaking change of reselect dependency update ([@mansona])
+- [adopted-ember-addons/ember-drag-drop] [#2](https://github.com/adopted-ember-addons/ember-drag-drop/pull/2) setup release-plan ([@mansona])
+- [adopted-ember-addons/ember-drag-drop] [#1](https://github.com/adopted-ember-addons/ember-drag-drop/pull/1) Convert to a v2 addon and drop support for Ember < 3.16 ([@mansona])
+- [tleunen/babel-plugin-module-resolver] [#446](https://github.com/tleunen/babel-plugin-module-resolver/pull/446) revert breaking change of reselect dependency update ([@mansona])
 
 ## Ember
 
-- [ef4/decorator-transforms]
-  [#24](https://github.com/ef4/decorator-transforms/pull/24) add a prepare
-  script to make sure it builds ([@mansona])
-- [ef4/decorator-transforms]
-  [#22](https://github.com/ef4/decorator-transforms/pull/22) add release-plan
-  ([@mansona])
-- [ember-learn/ember-website]
-  [#1100](https://github.com/ember-learn/ember-website/pull/1100) use the
-  updated crowdstrike logo for the sponsors ([@mansona])
-- [ember-learn/ember-website]
-  [#1094](https://github.com/ember-learn/ember-website/pull/1094) add
-  crowdstrike to Embroider Initiative sponsors ([@mansona])
-- [ember-learn/handbook] [#75](https://github.com/ember-learn/handbook/pull/75)
-  Add section about the tutorial updates to the release docs ([@mansona])
+- [ef4/decorator-transforms] [#24](https://github.com/ef4/decorator-transforms/pull/24) add a prepare script to make sure it builds ([@mansona])
+- [ef4/decorator-transforms] [#22](https://github.com/ef4/decorator-transforms/pull/22) add release-plan ([@mansona])
+- [ember-learn/ember-website] [#1100](https://github.com/ember-learn/ember-website/pull/1100) use the updated crowdstrike logo for the sponsors ([@mansona])
+- [ember-learn/ember-website] [#1094](https://github.com/ember-learn/ember-website/pull/1094) add crowdstrike to Embroider Initiative sponsors ([@mansona])
+- [ember-learn/handbook] [#75](https://github.com/ember-learn/handbook/pull/75) Add section about the tutorial updates to the release docs ([@mansona])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@paoloricciuti]: https://github.com/paoloricciuti
-[adopted-ember-addons/ember-drag-drop]:
-  https://github.com/adopted-ember-addons/ember-drag-drop
+[adopted-ember-addons/ember-drag-drop]: https://github.com/adopted-ember-addons/ember-drag-drop
 [ef4/decorator-transforms]: https://github.com/ef4/decorator-transforms
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [ember-learn/handbook]: https://github.com/ember-learn/handbook
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/svelte-concurrency]:
-  https://github.com/mainmatter/svelte-concurrency
+[mainmatter/svelte-concurrency]: https://github.com/mainmatter/svelte-concurrency
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
-[tleunen/babel-plugin-module-resolver]:
-  https://github.com/tleunen/babel-plugin-module-resolver
+[tleunen/babel-plugin-module-resolver]: https://github.com/tleunen/babel-plugin-module-resolver
diff --git a/src/twios/2024-04-28.md b/src/twios/2024-04-28.md
index 0efd1207b1..7b7f3b41d1 100644
--- a/src/twios/2024-04-28.md
+++ b/src/twios/2024-04-28.md
@@ -1,35 +1,22 @@
 ## Rust
 
-- [mainmatter/cargo-autoinherit]
-  [#19](https://github.com/mainmatter/cargo-autoinherit/pull/19) add MM Rust
-  info ([@marcoow])
-- [marcoow/pacesetter] [#47](https://github.com/marcoow/pacesetter/pull/47) Fix
-  cli and config crate tests ([@marcoow])
-- [marcoow/pacesetter] [#46](https://github.com/marcoow/pacesetter/pull/46)
-  Fixes ([@marcoow])
+- [mainmatter/cargo-autoinherit] [#19](https://github.com/mainmatter/cargo-autoinherit/pull/19) add MM Rust info ([@marcoow])
+- [marcoow/pacesetter] [#47](https://github.com/marcoow/pacesetter/pull/47) Fix cli and config crate tests ([@marcoow])
+- [marcoow/pacesetter] [#46](https://github.com/marcoow/pacesetter/pull/46) Fixes ([@marcoow])
 
 ## Svelte
 
-- [sveltejs/svelte] [#11344](https://github.com/sveltejs/svelte/pull/11344) fix:
-  hr, script and template as valid select children ([@paoloricciuti])
+- [sveltejs/svelte] [#11344](https://github.com/sveltejs/svelte/pull/11344) fix: hr, script and template as valid select children ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1886](https://github.com/embroider-build/embroider/pull/1886) Merge stable
-  into main ([@mansona])
-- [embroider-build/embroider]
-  [#1890](https://github.com/embroider-build/embroider/pull/1890) Add more tests
-  virtual files ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1801](https://github.com/embroider-build/embroider/pull/1801) Module
-  resolver: virtualize vendor.js ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1886](https://github.com/embroider-build/embroider/pull/1886) Merge stable into main ([@mansona])
+- [embroider-build/embroider] [#1890](https://github.com/embroider-build/embroider/pull/1890) Add more tests virtual files ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1801](https://github.com/embroider-build/embroider/pull/1801) Module resolver: virtualize vendor.js ([@BlueCutOfficial])
 
 ## Ember
 
-- [mainmatter/qunit-dom]
-  [#2105](https://github.com/mainmatter/qunit-dom/pull/2105) fix(hasStyle):
-  allow using camelCase properties inside assertion object ([@BobrImperator])
+- [mainmatter/qunit-dom] [#2105](https://github.com/mainmatter/qunit-dom/pull/2105) fix(hasStyle): allow using camelCase properties inside assertion object ([@BobrImperator])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@BobrImperator]: https://github.com/BobrImperator
diff --git a/src/twios/2024-05-12.md b/src/twios/2024-05-12.md
index c6fd962d6c..8f5c35638b 100644
--- a/src/twios/2024-05-12.md
+++ b/src/twios/2024-05-12.md
@@ -1,67 +1,40 @@
 ## Svelte
 
-- [mainmatter/svelte-concurrency]
-  [#68](https://github.com/mainmatter/svelte-concurrency/pull/68) chore: use
-  pnpm 9 in workflows ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#66](https://github.com/mainmatter/svelte-concurrency/pull/66) feat: more
-  exhaustive async transform ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#62](https://github.com/mainmatter/svelte-concurrency/pull/62) chore: add
-  svelte exports to avoid warning ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#61](https://github.com/mainmatter/svelte-concurrency/pull/61) feat: link
-  only cancel the instance of the task that was linked ([@paoloricciuti])
-- [sveltejs/svelte] [#11506](https://github.com/sveltejs/svelte/pull/11506) fix:
-  increment and decrement edge case ([@paoloricciuti])
-- [sveltejs/svelte] [#11487](https://github.com/sveltejs/svelte/pull/11487) fix:
-  allow to access private fields after `this` reassignment ([@paoloricciuti])
-- [sveltejs/svelte] [#11465](https://github.com/sveltejs/svelte/pull/11465) fix:
-  restore value after attribute removal during hydration ([@paoloricciuti])
-- [sveltejs/svelte] [#11463](https://github.com/sveltejs/svelte/pull/11463) fix:
-  use snippet as parent element of snippets childrens in validator
-  ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#68](https://github.com/mainmatter/svelte-concurrency/pull/68) chore: use pnpm 9 in workflows ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#66](https://github.com/mainmatter/svelte-concurrency/pull/66) feat: more exhaustive async transform ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#62](https://github.com/mainmatter/svelte-concurrency/pull/62) chore: add svelte exports to avoid warning ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#61](https://github.com/mainmatter/svelte-concurrency/pull/61) feat: link only cancel the instance of the task that was linked ([@paoloricciuti])
+- [sveltejs/svelte] [#11506](https://github.com/sveltejs/svelte/pull/11506) fix: increment and decrement edge case ([@paoloricciuti])
+- [sveltejs/svelte] [#11487](https://github.com/sveltejs/svelte/pull/11487) fix: allow to access private fields after `this` reassignment ([@paoloricciuti])
+- [sveltejs/svelte] [#11465](https://github.com/sveltejs/svelte/pull/11465) fix: restore value after attribute removal during hydration ([@paoloricciuti])
+- [sveltejs/svelte] [#11463](https://github.com/sveltejs/svelte/pull/11463) fix: use snippet as parent element of snippets childrens in validator ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1912](https://github.com/embroider-build/embroider/pull/1912) update all
-  github actions to remove warnings about node version ([@mansona])
-- [embroider-build/embroider]
-  [#1911](https://github.com/embroider-build/embroider/pull/1911) Fix CI because
-  of recent babel-plugin-template-compiler update ([@mansona])
+- [embroider-build/embroider] [#1912](https://github.com/embroider-build/embroider/pull/1912) update all github actions to remove warnings about node version ([@mansona])
+- [embroider-build/embroider] [#1911](https://github.com/embroider-build/embroider/pull/1911) Fix CI because of recent babel-plugin-template-compiler update ([@mansona])
 
 ## JavaScript
 
-- [shikijs/shiki-magic-move]
-  [#14](https://github.com/shikijs/shiki-magic-move/pull/14) fix: svelte types
-  generation during build ([@paoloricciuti])
-- [stefanpenner/node-fixturify-project]
-  [#88](https://github.com/stefanpenner/node-fixturify-project/pull/88) fix
-  prettier check script ([@mansona])
+- [shikijs/shiki-magic-move] [#14](https://github.com/shikijs/shiki-magic-move/pull/14) fix: svelte types generation during build ([@paoloricciuti])
+- [stefanpenner/node-fixturify-project] [#88](https://github.com/stefanpenner/node-fixturify-project/pull/88) fix prettier check script ([@mansona])
 
 ## Octokit
 
-- [octokit/auth-app.js] [#606](https://github.com/octokit/auth-app.js/pull/606)
-  feat: `appId` argument can be set to Client ID string ([@oscard0m])
+- [octokit/auth-app.js] [#606](https://github.com/octokit/auth-app.js/pull/606) feat: `appId` argument can be set to Client ID string ([@oscard0m])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#242](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/242)
-  Translate guides/tutorial/part-2/ember-data.md ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#242](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/242) Translate guides/tutorial/part-2/ember-data.md ([@BlueCutOfficial])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
-[DazzlingFugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/svelte-concurrency]:
-  https://github.com/mainmatter/svelte-concurrency
+[mainmatter/svelte-concurrency]: https://github.com/mainmatter/svelte-concurrency
 [octokit/auth-app.js]: https://github.com/octokit/auth-app.js
 [shikijs/shiki-magic-move]: https://github.com/shikijs/shiki-magic-move
-[stefanpenner/node-fixturify-project]:
-  https://github.com/stefanpenner/node-fixturify-project
+[stefanpenner/node-fixturify-project]: https://github.com/stefanpenner/node-fixturify-project
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-05-19.md b/src/twios/2024-05-19.md
index 67cbd81ec2..f57757bb15 100644
--- a/src/twios/2024-05-19.md
+++ b/src/twios/2024-05-19.md
@@ -1,117 +1,58 @@
 ## Svelte
 
-- [bmdavis419/sveltekit-pgvector-supabase]
-  [#1](https://github.com/bmdavis419/sveltekit-pgvector-supabase/pull/1) fix:
-  autosubmit search ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#76](https://github.com/mainmatter/svelte-concurrency/pull/76) feat: setup
-  starlight for documentation ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#72](https://github.com/mainmatter/svelte-concurrency/pull/72) chore: upgrade
-  eslint to v9 and flat config ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#67](https://github.com/mainmatter/svelte-concurrency/pull/67) chore: test
-  for errors thrown in perform ([@paoloricciuti])
-- [sveltejs/language-tools]
-  [#2372](https://github.com/sveltejs/language-tools/pull/2372) feat: allow `as`
-  expressions for bindable props ([@paoloricciuti])
-- [sveltejs/language-tools]
-  [#2366](https://github.com/sveltejs/language-tools/pull/2366) fix: allow for
-  whitespace in snippets declaration ([@paoloricciuti])
-- [sveltejs/svelte] [#11631](https://github.com/sveltejs/svelte/pull/11631)
-  feat: error when snippet shadow a prop ([@paoloricciuti])
-- [sveltejs/svelte] [#11578](https://github.com/sveltejs/svelte/pull/11578) fix:
-  allow for non optional chain call expression in render ([@paoloricciuti])
+- [bmdavis419/sveltekit-pgvector-supabase] [#1](https://github.com/bmdavis419/sveltekit-pgvector-supabase/pull/1) fix: autosubmit search ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#76](https://github.com/mainmatter/svelte-concurrency/pull/76) feat: setup starlight for documentation ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#72](https://github.com/mainmatter/svelte-concurrency/pull/72) chore: upgrade eslint to v9 and flat config ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#67](https://github.com/mainmatter/svelte-concurrency/pull/67) chore: test for errors thrown in perform ([@paoloricciuti])
+- [sveltejs/language-tools] [#2372](https://github.com/sveltejs/language-tools/pull/2372) feat: allow `as` expressions for bindable props ([@paoloricciuti])
+- [sveltejs/language-tools] [#2366](https://github.com/sveltejs/language-tools/pull/2366) fix: allow for whitespace in snippets declaration ([@paoloricciuti])
+- [sveltejs/svelte] [#11631](https://github.com/sveltejs/svelte/pull/11631) feat: error when snippet shadow a prop ([@paoloricciuti])
+- [sveltejs/svelte] [#11578](https://github.com/sveltejs/svelte/pull/11578) fix: allow for non optional chain call expression in render ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1927](https://github.com/embroider-build/embroider/pull/1927) simplify
-  virtual entrypoint ([@mansona])
-- [embroider-build/embroider]
-  [#1924](https://github.com/embroider-build/embroider/pull/1924) virtualise
-  test entrypoint ([@mansona])
-- [embroider-build/embroider]
-  [#1917](https://github.com/embroider-build/embroider/pull/1917) Merge stable
-  into main ([@mansona])
-- [embroider-build/embroider]
-  [#1913](https://github.com/embroider-build/embroider/pull/1913) virtualise
-  engine styles with their vendor styles ([@mansona])
-- [embroider-build/embroider]
-  [#1779](https://github.com/embroider-build/embroider/pull/1779) Virtual entry
-  point ([@mansona])
-- [embroider-build/embroider]
-  [#1922](https://github.com/embroider-build/embroider/pull/1922) New
-  `index.html` format - entrypoint ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1921](https://github.com/embroider-build/embroider/pull/1921) New
-  `index.html` format - `test-support.css`, `vendor.css` ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1920](https://github.com/embroider-build/embroider/pull/1920) New
-  `index.html` format - `test-support.js` ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1918](https://github.com/embroider-build/embroider/pull/1918) New index.html
-  format - vendor js ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1927](https://github.com/embroider-build/embroider/pull/1927) simplify virtual entrypoint ([@mansona])
+- [embroider-build/embroider] [#1924](https://github.com/embroider-build/embroider/pull/1924) virtualise test entrypoint ([@mansona])
+- [embroider-build/embroider] [#1917](https://github.com/embroider-build/embroider/pull/1917) Merge stable into main ([@mansona])
+- [embroider-build/embroider] [#1913](https://github.com/embroider-build/embroider/pull/1913) virtualise engine styles with their vendor styles ([@mansona])
+- [embroider-build/embroider] [#1779](https://github.com/embroider-build/embroider/pull/1779) Virtual entry point ([@mansona])
+- [embroider-build/embroider] [#1922](https://github.com/embroider-build/embroider/pull/1922) New `index.html` format - entrypoint ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1921](https://github.com/embroider-build/embroider/pull/1921) New `index.html` format - `test-support.css`, `vendor.css` ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1920](https://github.com/embroider-build/embroider/pull/1920) New `index.html` format - `test-support.js` ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1918](https://github.com/embroider-build/embroider/pull/1918) New index.html format - vendor js ([@BlueCutOfficial])
 
 ## JavaScript
 
-- [mansona/lttf-dashboard]
-  [#8](https://github.com/mansona/lttf-dashboard/pull/8) Fix multiline bash
-  command ([@Mikek2252])
-- [mansona/lttf-dashboard]
-  [#7](https://github.com/mansona/lttf-dashboard/pull/7) Add check for package
-  manager ([@Mikek2252])
-- [stefanpenner/node-fixturify-project]
-  [#97](https://github.com/stefanpenner/node-fixturify-project/pull/97) don't
-  error about missing optional peer deps ([@mansona])
+- [mansona/lttf-dashboard] [#8](https://github.com/mansona/lttf-dashboard/pull/8) Fix multiline bash command ([@Mikek2252])
+- [mansona/lttf-dashboard] [#7](https://github.com/mansona/lttf-dashboard/pull/7) Add check for package manager ([@Mikek2252])
+- [stefanpenner/node-fixturify-project] [#97](https://github.com/stefanpenner/node-fixturify-project/pull/97) don't error about missing optional peer deps ([@mansona])
 
 ## Octokit
 
-- [octokit/auth-app.js] [#609](https://github.com/octokit/auth-app.js/pull/609)
-  ci(release): use `semantic-release@latest` instead of `beta` ([@oscard0m])
+- [octokit/auth-app.js] [#609](https://github.com/octokit/auth-app.js/pull/609) ci(release): use `semantic-release@latest` instead of `beta` ([@oscard0m])
 
 ## Ember
 
-- [adopted-ember-addons/ember-infinity]
-  [#484](https://github.com/adopted-ember-addons/ember-infinity/pull/484) swap
-  override for patched package ([@mansona])
-- [adopted-ember-addons/ember-infinity]
-  [#483](https://github.com/adopted-ember-addons/ember-infinity/pull/483) fix
-  issue with github-changelog ([@mansona])
-- [adopted-ember-addons/ember-infinity]
-  [#482](https://github.com/adopted-ember-addons/ember-infinity/pull/482) turn
-  on mirage for production deploy of demo app ([@mansona])
-- [adopted-ember-addons/ember-infinity]
-  [#481](https://github.com/adopted-ember-addons/ember-infinity/pull/481) fix
-  root-url for github pages ([@mansona])
-- [adopted-ember-addons/ember-infinity]
-  [#479](https://github.com/adopted-ember-addons/ember-infinity/pull/479) fix
-  pnpm version for release-plan ([@mansona])
-- [adopted-ember-addons/ember-infinity]
-  [#478](https://github.com/adopted-ember-addons/ember-infinity/pull/478) add an
-  action to release demo site ([@mansona])
-- [adopted-ember-addons/ember-infinity]
-  [#476](https://github.com/adopted-ember-addons/ember-infinity/pull/476) setup
-  release-plan ([@mansona])
-- [adopted-ember-addons/ember-infinity]
-  [#475](https://github.com/adopted-ember-addons/ember-infinity/pull/475) remove
-  engine reference for Node 18 ([@mansona])
+- [adopted-ember-addons/ember-infinity] [#484](https://github.com/adopted-ember-addons/ember-infinity/pull/484) swap override for patched package ([@mansona])
+- [adopted-ember-addons/ember-infinity] [#483](https://github.com/adopted-ember-addons/ember-infinity/pull/483) fix issue with github-changelog ([@mansona])
+- [adopted-ember-addons/ember-infinity] [#482](https://github.com/adopted-ember-addons/ember-infinity/pull/482) turn on mirage for production deploy of demo app ([@mansona])
+- [adopted-ember-addons/ember-infinity] [#481](https://github.com/adopted-ember-addons/ember-infinity/pull/481) fix root-url for github pages ([@mansona])
+- [adopted-ember-addons/ember-infinity] [#479](https://github.com/adopted-ember-addons/ember-infinity/pull/479) fix pnpm version for release-plan ([@mansona])
+- [adopted-ember-addons/ember-infinity] [#478](https://github.com/adopted-ember-addons/ember-infinity/pull/478) add an action to release demo site ([@mansona])
+- [adopted-ember-addons/ember-infinity] [#476](https://github.com/adopted-ember-addons/ember-infinity/pull/476) setup release-plan ([@mansona])
+- [adopted-ember-addons/ember-infinity] [#475](https://github.com/adopted-ember-addons/ember-infinity/pull/475) remove engine reference for Node 18 ([@mansona])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@Mikek2252]: https://github.com/Mikek2252
 [@mansona]: https://github.com/mansona
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
-[adopted-ember-addons/ember-infinity]:
-  https://github.com/adopted-ember-addons/ember-infinity
-[bmdavis419/sveltekit-pgvector-supabase]:
-  https://github.com/bmdavis419/sveltekit-pgvector-supabase
+[adopted-ember-addons/ember-infinity]: https://github.com/adopted-ember-addons/ember-infinity
+[bmdavis419/sveltekit-pgvector-supabase]: https://github.com/bmdavis419/sveltekit-pgvector-supabase
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/svelte-concurrency]:
-  https://github.com/mainmatter/svelte-concurrency
+[mainmatter/svelte-concurrency]: https://github.com/mainmatter/svelte-concurrency
 [mansona/lttf-dashboard]: https://github.com/mansona/lttf-dashboard
 [octokit/auth-app.js]: https://github.com/octokit/auth-app.js
-[stefanpenner/node-fixturify-project]:
-  https://github.com/stefanpenner/node-fixturify-project
+[stefanpenner/node-fixturify-project]: https://github.com/stefanpenner/node-fixturify-project
 [sveltejs/language-tools]: https://github.com/sveltejs/language-tools
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-05-26.md b/src/twios/2024-05-26.md
index b06e36df1b..3256b2c89f 100644
--- a/src/twios/2024-05-26.md
+++ b/src/twios/2024-05-26.md
@@ -1,117 +1,52 @@
 ## Svelte
 
-- [mainmatter/svelte-concurrency]
-  [#88](https://github.com/mainmatter/svelte-concurrency/pull/88) feat: add
-  performCount to derived state ([@paoloricciuti])
-- [oscard0m/test-sveltekit]
-  [#52](https://github.com/oscard0m/test-sveltekit/pull/52) Update README.md
-  ([@oscard0m])
-- [oscard0m/test-sveltekit]
-  [#53](https://github.com/oscard0m/test-sveltekit/pull/53) Update README.md
-  ([@oscard0m])
-- [oscard0m/test-sveltekit]
-  [#50](https://github.com/oscard0m/test-sveltekit/pull/50) Update README.md
-  ([@oscard0m])
-- [oscard0m/test-sveltekit]
-  [#51](https://github.com/oscard0m/test-sveltekit/pull/51) Update README.md
-  ([@oscard0m])
-- [oscard0m/test-sveltekit]
-  [#49](https://github.com/oscard0m/test-sveltekit/pull/49) Update README.md
-  ([@oscard0m])
-- [oscard0m/test-sveltekit]
-  [#45](https://github.com/oscard0m/test-sveltekit/pull/45) add newline
-  ([@oscard0m])
-- [sveltejs/language-tools]
-  [#2379](https://github.com/sveltejs/language-tools/pull/2379) fix: use correct
-  semantic tokens for `$props` types ([@paoloricciuti])
-- [sveltejs/svelte] [#11768](https://github.com/sveltejs/svelte/pull/11768) fix:
-  allow runelike writable as prop ([@paoloricciuti])
-- [sveltejs/svelte] [#11766](https://github.com/sveltejs/svelte/pull/11766) fix:
-  `array.lastIndexOf` without second argument ([@paoloricciuti])
-- [sveltejs/svelte] [#11755](https://github.com/sveltejs/svelte/pull/11755) fix:
-  use svg methods for updating svg attributes too ([@paoloricciuti])
-- [sveltejs/svelte] [#11737](https://github.com/sveltejs/svelte/pull/11737) fix:
-  don't warn on link without href if aria-disabled ([@paoloricciuti])
-- [sveltejs/svelte] [#11736](https://github.com/sveltejs/svelte/pull/11736) fix:
-  throw on invalid attribute expressions ([@paoloricciuti])
-- [sveltejs/svelte] [#11723](https://github.com/sveltejs/svelte/pull/11723) fix:
-  allow comments after last selector in css ([@paoloricciuti])
-- [sveltejs/svelte] [#11720](https://github.com/sveltejs/svelte/pull/11720) fix:
-  update value like attributes in a separate template_effect ([@paoloricciuti])
-- [sveltejs/svelte] [#11704](https://github.com/sveltejs/svelte/pull/11704) fix:
-  migrate derivations without semicolons ([@paoloricciuti])
-- [sveltejs/svelte] [#11676](https://github.com/sveltejs/svelte/pull/11676) fix:
-  check for invalid bindings on window and document ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#88](https://github.com/mainmatter/svelte-concurrency/pull/88) feat: add performCount to derived state ([@paoloricciuti])
+- [oscard0m/test-sveltekit] [#52](https://github.com/oscard0m/test-sveltekit/pull/52) Update README.md ([@oscard0m])
+- [oscard0m/test-sveltekit] [#53](https://github.com/oscard0m/test-sveltekit/pull/53) Update README.md ([@oscard0m])
+- [oscard0m/test-sveltekit] [#50](https://github.com/oscard0m/test-sveltekit/pull/50) Update README.md ([@oscard0m])
+- [oscard0m/test-sveltekit] [#51](https://github.com/oscard0m/test-sveltekit/pull/51) Update README.md ([@oscard0m])
+- [oscard0m/test-sveltekit] [#49](https://github.com/oscard0m/test-sveltekit/pull/49) Update README.md ([@oscard0m])
+- [oscard0m/test-sveltekit] [#45](https://github.com/oscard0m/test-sveltekit/pull/45) add newline ([@oscard0m])
+- [sveltejs/language-tools] [#2379](https://github.com/sveltejs/language-tools/pull/2379) fix: use correct semantic tokens for `$props` types ([@paoloricciuti])
+- [sveltejs/svelte] [#11768](https://github.com/sveltejs/svelte/pull/11768) fix: allow runelike writable as prop ([@paoloricciuti])
+- [sveltejs/svelte] [#11766](https://github.com/sveltejs/svelte/pull/11766) fix: `array.lastIndexOf` without second argument ([@paoloricciuti])
+- [sveltejs/svelte] [#11755](https://github.com/sveltejs/svelte/pull/11755) fix: use svg methods for updating svg attributes too ([@paoloricciuti])
+- [sveltejs/svelte] [#11737](https://github.com/sveltejs/svelte/pull/11737) fix: don't warn on link without href if aria-disabled ([@paoloricciuti])
+- [sveltejs/svelte] [#11736](https://github.com/sveltejs/svelte/pull/11736) fix: throw on invalid attribute expressions ([@paoloricciuti])
+- [sveltejs/svelte] [#11723](https://github.com/sveltejs/svelte/pull/11723) fix: allow comments after last selector in css ([@paoloricciuti])
+- [sveltejs/svelte] [#11720](https://github.com/sveltejs/svelte/pull/11720) fix: update value like attributes in a separate template_effect ([@paoloricciuti])
+- [sveltejs/svelte] [#11704](https://github.com/sveltejs/svelte/pull/11704) fix: migrate derivations without semicolons ([@paoloricciuti])
+- [sveltejs/svelte] [#11676](https://github.com/sveltejs/svelte/pull/11676) fix: check for invalid bindings on window and document ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#1943](https://github.com/embroider-build/embroider/pull/1943) Merge stable
-  into main ([@mansona])
-- [embroider-build/embroider]
-  [#1940](https://github.com/embroider-build/embroider/pull/1940) only register
-  v2 addons with parent addons ([@mansona])
-- [embroider-build/embroider]
-  [#1938](https://github.com/embroider-build/embroider/pull/1938) remove v\*
-  prefix GitHub Actions builds ([@mansona])
-- [embroider-build/embroider]
-  [#1937](https://github.com/embroider-build/embroider/pull/1937) only register
-  v2 addons with parent addons ([@mansona])
-- [embroider-build/embroider]
-  [#1939](https://github.com/embroider-build/embroider/pull/1939) Output
-  `_babel_filter_.js` in the `.embroider` folder ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1935](https://github.com/embroider-build/embroider/pull/1935) output
-  macros-config.json and _babel_config_ in the .embroider folder
-  ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1933](https://github.com/embroider-build/embroider/pull/1933) Clean up
-  compat app builder ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1926](https://github.com/embroider-build/embroider/pull/1926) New
-  `index.html`- format test-entrypoint ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1925](https://github.com/embroider-build/embroider/pull/1925) New
-  `index.html` format - app css ([@BlueCutOfficial])
-- [embroider-build/github-changelog]
-  [#23](https://github.com/embroider-build/github-changelog/pull/23) only
-  process commits on the current branch ([@mansona])
-- [embroider-build/app-blueprint]
-  [#15](https://github.com/embroider-build/app-blueprint/pull/15) schedule CI to
-  run once a day ([@mansona])
-- [embroider-build/app-blueprint]
-  [#14](https://github.com/embroider-build/app-blueprint/pull/14) add a
-  dependabot config to keep ember-cli up to date ([@mansona])
-- [embroider-build/app-blueprint]
-  [#10](https://github.com/embroider-build/app-blueprint/pull/10) add a basic
-  smoke test ([@mansona])
-- [embroider-build/app-blueprint]
-  [#9](https://github.com/embroider-build/app-blueprint/pull/9) make sure
-  ember-cli-update config is correct ([@mansona])
-- [embroider-build/app-blueprint]
-  [#7](https://github.com/embroider-build/app-blueprint/pull/7) Add prettier
-  ([@mansona])
-- [embroider-build/app-blueprint]
-  [#4](https://github.com/embroider-build/app-blueprint/pull/4) add
-  ember-blueprint to keywords ([@mansona])
-- [embroider-build/app-blueprint]
-  [#2](https://github.com/embroider-build/app-blueprint/pull/2) setup
-  release-plan ([@mansona])
-- [embroider-build/app-blueprint]
-  [#1](https://github.com/embroider-build/app-blueprint/pull/1) Initial working
-  version ([@mansona])
+- [embroider-build/embroider] [#1943](https://github.com/embroider-build/embroider/pull/1943) Merge stable into main ([@mansona])
+- [embroider-build/embroider] [#1940](https://github.com/embroider-build/embroider/pull/1940) only register v2 addons with parent addons ([@mansona])
+- [embroider-build/embroider] [#1938](https://github.com/embroider-build/embroider/pull/1938) remove v\* prefix GitHub Actions builds ([@mansona])
+- [embroider-build/embroider] [#1937](https://github.com/embroider-build/embroider/pull/1937) only register v2 addons with parent addons ([@mansona])
+- [embroider-build/embroider] [#1939](https://github.com/embroider-build/embroider/pull/1939) Output `_babel_filter_.js` in the `.embroider` folder ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1935](https://github.com/embroider-build/embroider/pull/1935) output macros-config.json and _babel_config_ in the .embroider folder ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1933](https://github.com/embroider-build/embroider/pull/1933) Clean up compat app builder ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1926](https://github.com/embroider-build/embroider/pull/1926) New `index.html`- format test-entrypoint ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1925](https://github.com/embroider-build/embroider/pull/1925) New `index.html` format - app css ([@BlueCutOfficial])
+- [embroider-build/github-changelog] [#23](https://github.com/embroider-build/github-changelog/pull/23) only process commits on the current branch ([@mansona])
+- [embroider-build/app-blueprint] [#15](https://github.com/embroider-build/app-blueprint/pull/15) schedule CI to run once a day ([@mansona])
+- [embroider-build/app-blueprint] [#14](https://github.com/embroider-build/app-blueprint/pull/14) add a dependabot config to keep ember-cli up to date ([@mansona])
+- [embroider-build/app-blueprint] [#10](https://github.com/embroider-build/app-blueprint/pull/10) add a basic smoke test ([@mansona])
+- [embroider-build/app-blueprint] [#9](https://github.com/embroider-build/app-blueprint/pull/9) make sure ember-cli-update config is correct ([@mansona])
+- [embroider-build/app-blueprint] [#7](https://github.com/embroider-build/app-blueprint/pull/7) Add prettier ([@mansona])
+- [embroider-build/app-blueprint] [#4](https://github.com/embroider-build/app-blueprint/pull/4) add ember-blueprint to keywords ([@mansona])
+- [embroider-build/app-blueprint] [#2](https://github.com/embroider-build/app-blueprint/pull/2) setup release-plan ([@mansona])
+- [embroider-build/app-blueprint] [#1](https://github.com/embroider-build/app-blueprint/pull/1) Initial working version ([@mansona])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[embroider-build/github-changelog]:
-  https://github.com/embroider-build/github-changelog
-[mainmatter/svelte-concurrency]:
-  https://github.com/mainmatter/svelte-concurrency
+[embroider-build/github-changelog]: https://github.com/embroider-build/github-changelog
+[mainmatter/svelte-concurrency]: https://github.com/mainmatter/svelte-concurrency
 [oscard0m/test-sveltekit]: https://github.com/oscard0m/test-sveltekit
 [sveltejs/language-tools]: https://github.com/sveltejs/language-tools
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-06-02.md b/src/twios/2024-06-02.md
index 118af53c41..cc4461a2c8 100644
--- a/src/twios/2024-06-02.md
+++ b/src/twios/2024-06-02.md
@@ -1,74 +1,36 @@
 ## Svelte
 
-- [mainmatter/svelte-concurrency]
-  [#92](https://github.com/mainmatter/svelte-concurrency/pull/92) breaking: add
-  instance id and derive is loading ([@paoloricciuti])
-- [mainmatter/svelte-concurrency]
-  [#89](https://github.com/mainmatter/svelte-concurrency/pull/89) feat: abstract
-  task logic to core ([@paoloricciuti])
-- [svecosystem/runed] [#63](https://github.com/svecosystem/runed/pull/63) feat:
-  add MediaQuery utility ([@paoloricciuti])
-- [sveltejs/svelte] [#11849](https://github.com/sveltejs/svelte/pull/11849) fix:
-  reevaluate namespace in slots ([@paoloricciuti])
-- [sveltejs/svelte] [#11835](https://github.com/sveltejs/svelte/pull/11835) fix:
-  `$state.is` missing second argument on the server ([@paoloricciuti])
-- [sveltejs/svelte] [#11833](https://github.com/sveltejs/svelte/pull/11833) fix:
-  allow for more svelte-ignore to work ([@paoloricciuti])
-- [sveltejs/svelte] [#11815](https://github.com/sveltejs/svelte/pull/11815) fix:
-  coherent infinite loop guard ([@paoloricciuti])
-- [sveltejs/svelte] [#11784](https://github.com/sveltejs/svelte/pull/11784) fix:
-  allow global next to `&` for nesting ([@paoloricciuti])
-- [sveltejs/svelte] [#11637](https://github.com/sveltejs/svelte/pull/11637)
-  chore: upgrade pnpm to version 9 ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#92](https://github.com/mainmatter/svelte-concurrency/pull/92) breaking: add instance id and derive is loading ([@paoloricciuti])
+- [mainmatter/svelte-concurrency] [#89](https://github.com/mainmatter/svelte-concurrency/pull/89) feat: abstract task logic to core ([@paoloricciuti])
+- [svecosystem/runed] [#63](https://github.com/svecosystem/runed/pull/63) feat: add MediaQuery utility ([@paoloricciuti])
+- [sveltejs/svelte] [#11849](https://github.com/sveltejs/svelte/pull/11849) fix: reevaluate namespace in slots ([@paoloricciuti])
+- [sveltejs/svelte] [#11835](https://github.com/sveltejs/svelte/pull/11835) fix: `$state.is` missing second argument on the server ([@paoloricciuti])
+- [sveltejs/svelte] [#11833](https://github.com/sveltejs/svelte/pull/11833) fix: allow for more svelte-ignore to work ([@paoloricciuti])
+- [sveltejs/svelte] [#11815](https://github.com/sveltejs/svelte/pull/11815) fix: coherent infinite loop guard ([@paoloricciuti])
+- [sveltejs/svelte] [#11784](https://github.com/sveltejs/svelte/pull/11784) fix: allow global next to `&` for nesting ([@paoloricciuti])
+- [sveltejs/svelte] [#11637](https://github.com/sveltejs/svelte/pull/11637) chore: upgrade pnpm to version 9 ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/app-blueprint]
-  [#18](https://github.com/embroider-build/app-blueprint/pull/18) add new config
-  structure ([@mansona])
-- [embroider-build/app-blueprint]
-  [#17](https://github.com/embroider-build/app-blueprint/pull/17) Add smoke
-  tests and fix the app-name.css link in index.html ([@mansona])
-- [embroider-build/app-blueprint]
-  [#15](https://github.com/embroider-build/app-blueprint/pull/15) schedule CI to
-  run once a day ([@mansona])
-- [embroider-build/app-blueprint]
-  [#14](https://github.com/embroider-build/app-blueprint/pull/14) add a
-  dependabot config to keep ember-cli up to date ([@mansona])
-- [embroider-build/ember-auto-import]
-  [#626](https://github.com/embroider-build/ember-auto-import/pull/626) setup
-  windows tests ([@mansona])
-- [embroider-build/ember-auto-import]
-  [#625](https://github.com/embroider-build/ember-auto-import/pull/625) update
-  release-plan ([@mansona])
-- [embroider-build/ember-auto-import]
-  [#622](https://github.com/embroider-build/ember-auto-import/pull/622) fix glob
-  version on lts tests ([@mansona])
-- [embroider-build/ember-auto-import]
-  [#620](https://github.com/embroider-build/ember-auto-import/pull/620) Improved
-  layering between app and tests bundles ([@mansona])
-- [embroider-build/embroider]
-  [#1954](https://github.com/embroider-build/embroider/pull/1954) reset version
-  of config-meta-loader to 0.0.0 ([@mansona])
-- [embroider-build/embroider]
-  [#1952](https://github.com/embroider-build/embroider/pull/1952) Merge stable
-  into Main ([@mansona])
-- [embroider-build/embroider]
-  [#1947](https://github.com/embroider-build/embroider/pull/1947) fix babel
-  config location in resolver tests ([@mansona])
-- [embroider-build/embroider]
-  [#1953](https://github.com/embroider-build/embroider/pull/1953) New config
-  module - `storeConfigInMeta` ([@BlueCutOfficial])
+- [embroider-build/app-blueprint] [#18](https://github.com/embroider-build/app-blueprint/pull/18) add new config structure ([@mansona])
+- [embroider-build/app-blueprint] [#17](https://github.com/embroider-build/app-blueprint/pull/17) Add smoke tests and fix the app-name.css link in index.html ([@mansona])
+- [embroider-build/app-blueprint] [#15](https://github.com/embroider-build/app-blueprint/pull/15) schedule CI to run once a day ([@mansona])
+- [embroider-build/app-blueprint] [#14](https://github.com/embroider-build/app-blueprint/pull/14) add a dependabot config to keep ember-cli up to date ([@mansona])
+- [embroider-build/ember-auto-import] [#626](https://github.com/embroider-build/ember-auto-import/pull/626) setup windows tests ([@mansona])
+- [embroider-build/ember-auto-import] [#625](https://github.com/embroider-build/ember-auto-import/pull/625) update release-plan ([@mansona])
+- [embroider-build/ember-auto-import] [#622](https://github.com/embroider-build/ember-auto-import/pull/622) fix glob version on lts tests ([@mansona])
+- [embroider-build/ember-auto-import] [#620](https://github.com/embroider-build/ember-auto-import/pull/620) Improved layering between app and tests bundles ([@mansona])
+- [embroider-build/embroider] [#1954](https://github.com/embroider-build/embroider/pull/1954) reset version of config-meta-loader to 0.0.0 ([@mansona])
+- [embroider-build/embroider] [#1952](https://github.com/embroider-build/embroider/pull/1952) Merge stable into Main ([@mansona])
+- [embroider-build/embroider] [#1947](https://github.com/embroider-build/embroider/pull/1947) fix babel config location in resolver tests ([@mansona])
+- [embroider-build/embroider] [#1953](https://github.com/embroider-build/embroider/pull/1953) New config module - `storeConfigInMeta` ([@BlueCutOfficial])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@paoloricciuti]: https://github.com/paoloricciuti
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
-[embroider-build/ember-auto-import]:
-  https://github.com/embroider-build/ember-auto-import
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
+[embroider-build/ember-auto-import]: https://github.com/embroider-build/ember-auto-import
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/svelte-concurrency]:
-  https://github.com/mainmatter/svelte-concurrency
+[mainmatter/svelte-concurrency]: https://github.com/mainmatter/svelte-concurrency
 [svecosystem/runed]: https://github.com/svecosystem/runed
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-06-09.md b/src/twios/2024-06-09.md
index d6ab179161..646de78ffb 100644
--- a/src/twios/2024-06-09.md
+++ b/src/twios/2024-06-09.md
@@ -1,57 +1,36 @@
 ## Rust
 
-- [marcoow/pacesetter] [#61](https://github.com/marcoow/pacesetter/pull/61)
-  Renovate for templates ([@marcoow])
-- [marcoow/pacesetter] [#59](https://github.com/marcoow/pacesetter/pull/59)
-  enable Renovate for `Cargo.toml.liquid` files in blueprints ([@marcoow])
-- [marcoow/pacesetter] [#52](https://github.com/marcoow/pacesetter/pull/52)
-  don't fail if into_json of TestResponse is never used ([@marcoow])
-- [marcoow/pacesetter] [#51](https://github.com/marcoow/pacesetter/pull/51) add
-  renovate config ([@marcoow])
+- [marcoow/pacesetter] [#61](https://github.com/marcoow/pacesetter/pull/61) Renovate for templates ([@marcoow])
+- [marcoow/pacesetter] [#59](https://github.com/marcoow/pacesetter/pull/59) enable Renovate for `Cargo.toml.liquid` files in blueprints ([@marcoow])
+- [marcoow/pacesetter] [#52](https://github.com/marcoow/pacesetter/pull/52) don't fail if into_json of TestResponse is never used ([@marcoow])
+- [marcoow/pacesetter] [#51](https://github.com/marcoow/pacesetter/pull/51) add renovate config ([@marcoow])
 
 ## Svelte
 
-- [svecosystem/runed] [#68](https://github.com/svecosystem/runed/pull/68) feat:
-  allow media query to be initialized in a module ([@paoloricciuti])
-- [sveltejs/svelte] [#11947](https://github.com/sveltejs/svelte/pull/11947) fix:
-  validate form inside a form ([@paoloricciuti])
-- [sveltejs/svelte] [#11946](https://github.com/sveltejs/svelte/pull/11946) fix:
-  lazily create sources for Set ([@paoloricciuti])
-- [sveltejs/svelte] [#11913](https://github.com/sveltejs/svelte/pull/11913) fix:
-  increment version when creating new source in Map.get or Map.has
-  ([@paoloricciuti])
-- [sveltejs/svelte] [#11905](https://github.com/sveltejs/svelte/pull/11905) fix:
-  silence `state_referenced_locally` when state is exported ([@paoloricciuti])
-- [sveltejs/svelte] [#11860](https://github.com/sveltejs/svelte/pull/11860) fix:
-  keep default values of props a proxy after reassignment ([@paoloricciuti])
-- [sveltejs/svelte] [#11792](https://github.com/sveltejs/svelte/pull/11792)
-  feat: better dynamic component css props ([@paoloricciuti])
+- [svecosystem/runed] [#68](https://github.com/svecosystem/runed/pull/68) feat: allow media query to be initialized in a module ([@paoloricciuti])
+- [sveltejs/svelte] [#11947](https://github.com/sveltejs/svelte/pull/11947) fix: validate form inside a form ([@paoloricciuti])
+- [sveltejs/svelte] [#11946](https://github.com/sveltejs/svelte/pull/11946) fix: lazily create sources for Set ([@paoloricciuti])
+- [sveltejs/svelte] [#11913](https://github.com/sveltejs/svelte/pull/11913) fix: increment version when creating new source in Map.get or Map.has ([@paoloricciuti])
+- [sveltejs/svelte] [#11905](https://github.com/sveltejs/svelte/pull/11905) fix: silence `state_referenced_locally` when state is exported ([@paoloricciuti])
+- [sveltejs/svelte] [#11860](https://github.com/sveltejs/svelte/pull/11860) fix: keep default values of props a proxy after reassignment ([@paoloricciuti])
+- [sveltejs/svelte] [#11792](https://github.com/sveltejs/svelte/pull/11792) feat: better dynamic component css props ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/app-blueprint]
-  [#21](https://github.com/embroider-build/app-blueprint/pull/21) add docs for
-  updating an existing app ([@mansona])
-- [embroider-build/embroider]
-  [#1946](https://github.com/embroider-build/embroider/pull/1946) remove the
-  ember-addon keyword from rewritten app ([@mansona])
+- [embroider-build/app-blueprint] [#21](https://github.com/embroider-build/app-blueprint/pull/21) add docs for updating an existing app ([@mansona])
+- [embroider-build/embroider] [#1946](https://github.com/embroider-build/embroider/pull/1946) remove the ember-addon keyword from rewritten app ([@mansona])
 
 ## Ember
 
-- [ember-learn/deprecation-app]
-  [#1384](https://github.com/ember-learn/deprecation-app/pull/1384) make the
-  deprecation anchor § link directly to the id route ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#908](https://github.com/ember-learn/ember-api-docs/pull/908) switch to pnpm
-  ([@mansona])
+- [ember-learn/deprecation-app] [#1384](https://github.com/ember-learn/deprecation-app/pull/1384) make the deprecation anchor § link directly to the id route ([@mansona])
+- [ember-learn/ember-api-docs] [#908](https://github.com/ember-learn/ember-api-docs/pull/908) switch to pnpm ([@mansona])
 
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
 [@paoloricciuti]: https://github.com/paoloricciuti
 [ember-learn/deprecation-app]: https://github.com/ember-learn/deprecation-app
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [svecosystem/runed]: https://github.com/svecosystem/runed
diff --git a/src/twios/2024-06-16.md b/src/twios/2024-06-16.md
index 2c6cb1d2be..99b4eb042c 100644
--- a/src/twios/2024-06-16.md
+++ b/src/twios/2024-06-16.md
@@ -1,74 +1,40 @@
 ## Svelte
 
-- [sveltejs/svelte] [#11997](https://github.com/sveltejs/svelte/pull/11997) fix:
-  better `render` type ([@paoloricciuti])
+- [sveltejs/svelte] [#11997](https://github.com/sveltejs/svelte/pull/11997) fix: better `render` type ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/app-blueprint]
-  [#31](https://github.com/embroider-build/app-blueprint/pull/31) fix the
-  location of the rewritten app ([@mansona])
-- [embroider-build/embroider]
-  [#1983](https://github.com/embroider-build/embroider/pull/1983) Merge stable
-  into Main ([@mansona])
-- [embroider-build/embroider]
-  [#1970](https://github.com/embroider-build/embroider/pull/1970) Use html-audit
-  instead of stage-2 build ([@mansona])
-- [embroider-build/embroider]
-  [#1955](https://github.com/embroider-build/embroider/pull/1955) Remove
-  template-only components compilation from Stage 2 ([@BlueCutOfficial])
+- [embroider-build/app-blueprint] [#31](https://github.com/embroider-build/app-blueprint/pull/31) fix the location of the rewritten app ([@mansona])
+- [embroider-build/embroider] [#1983](https://github.com/embroider-build/embroider/pull/1983) Merge stable into Main ([@mansona])
+- [embroider-build/embroider] [#1970](https://github.com/embroider-build/embroider/pull/1970) Use html-audit instead of stage-2 build ([@mansona])
+- [embroider-build/embroider] [#1955](https://github.com/embroider-build/embroider/pull/1955) Remove template-only components compilation from Stage 2 ([@BlueCutOfficial])
 
 ## JavaScript
 
-- [oscard0m/npm-snapshot]
-  [#19](https://github.com/oscard0m/npm-snapshot/pull/19) ci(release) use node
-  LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/npm-snapshot] [#19](https://github.com/oscard0m/npm-snapshot/pull/19) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
 
 ## Octokit
 
-- [oscard0m/octoherd-script-add-cache-to-node-github-action]
-  [#37](https://github.com/oscard0m/octoherd-script-add-cache-to-node-github-action/pull/37)
-  ci(release) use node LTS and unpin semantic-release ([@oscard0m])
-- [oscard0m/octoherd-script-add-or-delete-issue-label]
-  [#23](https://github.com/oscard0m/octoherd-script-add-or-delete-issue-label/pull/23)
-  ci(release) use node LTS and unpin semantic-release ([@oscard0m])
-- [oscard0m/octoherd-script-fix-test-workflow-octokit]
-  [#17](https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit/pull/17)
-  ci(release): use node LTS ([@oscard0m])
-- [oscard0m/octoherd-script-remove-renovate-package.json]
-  [#18](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/18)
-  migrate to node test and esm ([@oscard0m])
-- [oscard0m/octoherd-script-remove-renovate-package.json]
-  [#17](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/17)
-  ci(release) use node LTS and unpin semantic-release ([@oscard0m])
-- [oscard0m/octoherd-script-sync-repo-settings]
-  [#28](https://github.com/oscard0m/octoherd-script-sync-repo-settings/pull/28)
-  ci(release): use node LTS ([@oscard0m])
-- [oscard0m/octoherd-script-sync-repo-settings]
-  [#27](https://github.com/oscard0m/octoherd-script-sync-repo-settings/pull/27)
-  ci(semantic-release): unpin version of semantic-release in CI ([@oscard0m])
-- [oscard0m/octoherd-script-update-action-version-in-workflows]
-  [#19](https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows/pull/19)
-  ci(release) use node LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/octoherd-script-add-cache-to-node-github-action] [#37](https://github.com/oscard0m/octoherd-script-add-cache-to-node-github-action/pull/37) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/octoherd-script-add-or-delete-issue-label] [#23](https://github.com/oscard0m/octoherd-script-add-or-delete-issue-label/pull/23) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/octoherd-script-fix-test-workflow-octokit] [#17](https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit/pull/17) ci(release): use node LTS ([@oscard0m])
+- [oscard0m/octoherd-script-remove-renovate-package.json] [#18](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/18) migrate to node test and esm ([@oscard0m])
+- [oscard0m/octoherd-script-remove-renovate-package.json] [#17](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/17) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/octoherd-script-sync-repo-settings] [#28](https://github.com/oscard0m/octoherd-script-sync-repo-settings/pull/28) ci(release): use node LTS ([@oscard0m])
+- [oscard0m/octoherd-script-sync-repo-settings] [#27](https://github.com/oscard0m/octoherd-script-sync-repo-settings/pull/27) ci(semantic-release): unpin version of semantic-release in CI ([@oscard0m])
+- [oscard0m/octoherd-script-update-action-version-in-workflows] [#19](https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows/pull/19) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@oscard0m]: https://github.com/oscard0m
 [@paoloricciuti]: https://github.com/paoloricciuti
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [oscard0m/npm-snapshot]: https://github.com/oscard0m/npm-snapshot
-[oscard0m/octoherd-script-add-cache-to-node-github-action]:
-  https://github.com/oscard0m/octoherd-script-add-cache-to-node-github-action
-[oscard0m/octoherd-script-add-or-delete-issue-label]:
-  https://github.com/oscard0m/octoherd-script-add-or-delete-issue-label
-[oscard0m/octoherd-script-fix-test-workflow-octokit]:
-  https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit
-[oscard0m/octoherd-script-remove-renovate-package.json]:
-  https://github.com/oscard0m/octoherd-script-remove-renovate-package.json
-[oscard0m/octoherd-script-sync-repo-settings]:
-  https://github.com/oscard0m/octoherd-script-sync-repo-settings
-[oscard0m/octoherd-script-update-action-version-in-workflows]:
-  https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows
+[oscard0m/octoherd-script-add-cache-to-node-github-action]: https://github.com/oscard0m/octoherd-script-add-cache-to-node-github-action
+[oscard0m/octoherd-script-add-or-delete-issue-label]: https://github.com/oscard0m/octoherd-script-add-or-delete-issue-label
+[oscard0m/octoherd-script-fix-test-workflow-octokit]: https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit
+[oscard0m/octoherd-script-remove-renovate-package.json]: https://github.com/oscard0m/octoherd-script-remove-renovate-package.json
+[oscard0m/octoherd-script-sync-repo-settings]: https://github.com/oscard0m/octoherd-script-sync-repo-settings
+[oscard0m/octoherd-script-update-action-version-in-workflows]: https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-06-23.md b/src/twios/2024-06-23.md
index b2f4bf3803..c2f46e4a41 100644
--- a/src/twios/2024-06-23.md
+++ b/src/twios/2024-06-23.md
@@ -1,97 +1,48 @@
 ## Rust
 
-- [marcoow/pacesetter] [#66](https://github.com/marcoow/pacesetter/pull/66) Fix
-  CI ([@marcoow])
+- [marcoow/pacesetter] [#66](https://github.com/marcoow/pacesetter/pull/66) Fix CI ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/sheepdog] [#106](https://github.com/mainmatter/sheepdog/pull/106)
-  chore: delete tgz ([@paoloricciuti])
-- [mainmatter/sheepdog] [#104](https://github.com/mainmatter/sheepdog/pull/104)
-  chore: change website and repo in docs ([@paoloricciuti])
-- [mainmatter/sheepdog] [#98](https://github.com/mainmatter/sheepdog/pull/98)
-  fix: cancelled instances hanging indefinitely ([@paoloricciuti])
-- [sveltejs/svelte] [#12144](https://github.com/sveltejs/svelte/pull/12144) fix:
-  throw compilation error for malformed snippets ([@paoloricciuti])
-- [sveltejs/svelte] [#12098](https://github.com/sveltejs/svelte/pull/12098) fix:
-  repair each block length even without an else ([@paoloricciuti])
-- [sveltejs/svelte] [#12070](https://github.com/sveltejs/svelte/pull/12070) fix:
-  allow multiple optional parameters with defaults ([@paoloricciuti])
+- [mainmatter/sheepdog] [#106](https://github.com/mainmatter/sheepdog/pull/106) chore: delete tgz ([@paoloricciuti])
+- [mainmatter/sheepdog] [#104](https://github.com/mainmatter/sheepdog/pull/104) chore: change website and repo in docs ([@paoloricciuti])
+- [mainmatter/sheepdog] [#98](https://github.com/mainmatter/sheepdog/pull/98) fix: cancelled instances hanging indefinitely ([@paoloricciuti])
+- [sveltejs/svelte] [#12144](https://github.com/sveltejs/svelte/pull/12144) fix: throw compilation error for malformed snippets ([@paoloricciuti])
+- [sveltejs/svelte] [#12098](https://github.com/sveltejs/svelte/pull/12098) fix: repair each block length even without an else ([@paoloricciuti])
+- [sveltejs/svelte] [#12070](https://github.com/sveltejs/svelte/pull/12070) fix: allow multiple optional parameters with defaults ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/app-blueprint]
-  [#35](https://github.com/embroider-build/app-blueprint/pull/35) add
-  notification for failed github action ([@mansona])
-- [embroider-build/app-blueprint]
-  [#33](https://github.com/embroider-build/app-blueprint/pull/33) Add a bigger
-  warning for this repo ([@mansona])
-- [embroider-build/embroider]
-  [#2000](https://github.com/embroider-build/embroider/pull/2000) Update
-  typescript and fix issues with Typescript 5.5 ([@mansona])
-- [embroider-build/embroider]
-  [#1996](https://github.com/embroider-build/embroider/pull/1996) Merge stable
-  into main ([@mansona])
-- [embroider-build/embroider]
-  [#1993](https://github.com/embroider-build/embroider/pull/1993) update node to
-  latest LTS for CI ([@mansona])
-- [embroider-build/embroider]
-  [#1992](https://github.com/embroider-build/embroider/pull/1992) add missing
-  initiative sponsors to the Readme ([@mansona])
+- [embroider-build/app-blueprint] [#35](https://github.com/embroider-build/app-blueprint/pull/35) add notification for failed github action ([@mansona])
+- [embroider-build/app-blueprint] [#33](https://github.com/embroider-build/app-blueprint/pull/33) Add a bigger warning for this repo ([@mansona])
+- [embroider-build/embroider] [#2000](https://github.com/embroider-build/embroider/pull/2000) Update typescript and fix issues with Typescript 5.5 ([@mansona])
+- [embroider-build/embroider] [#1996](https://github.com/embroider-build/embroider/pull/1996) Merge stable into main ([@mansona])
+- [embroider-build/embroider] [#1993](https://github.com/embroider-build/embroider/pull/1993) update node to latest LTS for CI ([@mansona])
+- [embroider-build/embroider] [#1992](https://github.com/embroider-build/embroider/pull/1992) add missing initiative sponsors to the Readme ([@mansona])
 
 ## JavaScript
 
-- [oscard0m/npm-snapshot]
-  [#19](https://github.com/oscard0m/npm-snapshot/pull/19) ci(release) use node
-  LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/npm-snapshot] [#19](https://github.com/oscard0m/npm-snapshot/pull/19) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
 
 ## Octokit
 
-- [oscard0m/octoherd-script-add-cache-to-node-github-action]
-  [#37](https://github.com/oscard0m/octoherd-script-add-cache-to-node-github-action/pull/37)
-  ci(release) use node LTS and unpin semantic-release ([@oscard0m])
-- [oscard0m/octoherd-script-add-or-delete-issue-label]
-  [#23](https://github.com/oscard0m/octoherd-script-add-or-delete-issue-label/pull/23)
-  ci(release) use node LTS and unpin semantic-release ([@oscard0m])
-- [oscard0m/octoherd-script-fix-test-workflow-octokit]
-  [#17](https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit/pull/17)
-  ci(release): use node LTS ([@oscard0m])
-- [oscard0m/octoherd-script-remove-branches-config-semantic-release]
-  [#2](https://github.com/oscard0m/octoherd-script-remove-branches-config-semantic-release/pull/2)
-  ci(release): use node LTS for releases ([@oscard0m])
-- [oscard0m/octoherd-script-remove-branches-config-semantic-release]
-  [#1](https://github.com/oscard0m/octoherd-script-remove-branches-config-semantic-release/pull/1)
-  feat: Initial version ([@oscard0m])
-- [oscard0m/octoherd-script-remove-renovate-package.json]
-  [#18](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/18)
-  migrate to node test and esm ([@oscard0m])
-- [oscard0m/octoherd-script-remove-renovate-package.json]
-  [#17](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/17)
-  ci(release) use node LTS and unpin semantic-release ([@oscard0m])
-- [oscard0m/octoherd-script-sync-repo-settings]
-  [#28](https://github.com/oscard0m/octoherd-script-sync-repo-settings/pull/28)
-  ci(release): use node LTS ([@oscard0m])
-- [oscard0m/octoherd-script-sync-repo-settings]
-  [#27](https://github.com/oscard0m/octoherd-script-sync-repo-settings/pull/27)
-  ci(semantic-release): unpin version of semantic-release in CI ([@oscard0m])
-- [oscard0m/octoherd-script-update-action-version-in-workflows]
-  [#19](https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows/pull/19)
-  ci(release) use node LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/octoherd-script-add-cache-to-node-github-action] [#37](https://github.com/oscard0m/octoherd-script-add-cache-to-node-github-action/pull/37) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/octoherd-script-add-or-delete-issue-label] [#23](https://github.com/oscard0m/octoherd-script-add-or-delete-issue-label/pull/23) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/octoherd-script-fix-test-workflow-octokit] [#17](https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit/pull/17) ci(release): use node LTS ([@oscard0m])
+- [oscard0m/octoherd-script-remove-branches-config-semantic-release] [#2](https://github.com/oscard0m/octoherd-script-remove-branches-config-semantic-release/pull/2) ci(release): use node LTS for releases ([@oscard0m])
+- [oscard0m/octoherd-script-remove-branches-config-semantic-release] [#1](https://github.com/oscard0m/octoherd-script-remove-branches-config-semantic-release/pull/1) feat: Initial version ([@oscard0m])
+- [oscard0m/octoherd-script-remove-renovate-package.json] [#18](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/18) migrate to node test and esm ([@oscard0m])
+- [oscard0m/octoherd-script-remove-renovate-package.json] [#17](https://github.com/oscard0m/octoherd-script-remove-renovate-package.json/pull/17) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
+- [oscard0m/octoherd-script-sync-repo-settings] [#28](https://github.com/oscard0m/octoherd-script-sync-repo-settings/pull/28) ci(release): use node LTS ([@oscard0m])
+- [oscard0m/octoherd-script-sync-repo-settings] [#27](https://github.com/oscard0m/octoherd-script-sync-repo-settings/pull/27) ci(semantic-release): unpin version of semantic-release in CI ([@oscard0m])
+- [oscard0m/octoherd-script-update-action-version-in-workflows] [#19](https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows/pull/19) ci(release) use node LTS and unpin semantic-release ([@oscard0m])
 
 ## Ember
 
-- [ember-learn/ember-api-docs]
-  [#912](https://github.com/ember-learn/ember-api-docs/pull/912) add new percy
-  snapshots ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#911](https://github.com/ember-learn/ember-api-docs/pull/911) update percy
-  ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#910](https://github.com/ember-learn/ember-api-docs/pull/910) Merge master
-  into redesign ([@mansona])
-- [ember-learn/ember-website]
-  [#1115](https://github.com/ember-learn/ember-website/pull/1115) add auditboard
-  as an initiative sponsor ([@mansona])
+- [ember-learn/ember-api-docs] [#912](https://github.com/ember-learn/ember-api-docs/pull/912) add new percy snapshots ([@mansona])
+- [ember-learn/ember-api-docs] [#911](https://github.com/ember-learn/ember-api-docs/pull/911) update percy ([@mansona])
+- [ember-learn/ember-api-docs] [#910](https://github.com/ember-learn/ember-api-docs/pull/910) Merge master into redesign ([@mansona])
+- [ember-learn/ember-website] [#1115](https://github.com/ember-learn/ember-website/pull/1115) add auditboard as an initiative sponsor ([@mansona])
 
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
@@ -99,24 +50,16 @@
 [@paoloricciuti]: https://github.com/paoloricciuti
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
 [oscard0m/npm-snapshot]: https://github.com/oscard0m/npm-snapshot
-[oscard0m/octoherd-script-add-cache-to-node-github-action]:
-  https://github.com/oscard0m/octoherd-script-add-cache-to-node-github-action
-[oscard0m/octoherd-script-add-or-delete-issue-label]:
-  https://github.com/oscard0m/octoherd-script-add-or-delete-issue-label
-[oscard0m/octoherd-script-fix-test-workflow-octokit]:
-  https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit
-[oscard0m/octoherd-script-remove-branches-config-semantic-release]:
-  https://github.com/oscard0m/octoherd-script-remove-branches-config-semantic-release
-[oscard0m/octoherd-script-remove-renovate-package.json]:
-  https://github.com/oscard0m/octoherd-script-remove-renovate-package.json
-[oscard0m/octoherd-script-sync-repo-settings]:
-  https://github.com/oscard0m/octoherd-script-sync-repo-settings
-[oscard0m/octoherd-script-update-action-version-in-workflows]:
-  https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows
+[oscard0m/octoherd-script-add-cache-to-node-github-action]: https://github.com/oscard0m/octoherd-script-add-cache-to-node-github-action
+[oscard0m/octoherd-script-add-or-delete-issue-label]: https://github.com/oscard0m/octoherd-script-add-or-delete-issue-label
+[oscard0m/octoherd-script-fix-test-workflow-octokit]: https://github.com/oscard0m/octoherd-script-fix-test-workflow-octokit
+[oscard0m/octoherd-script-remove-branches-config-semantic-release]: https://github.com/oscard0m/octoherd-script-remove-branches-config-semantic-release
+[oscard0m/octoherd-script-remove-renovate-package.json]: https://github.com/oscard0m/octoherd-script-remove-renovate-package.json
+[oscard0m/octoherd-script-sync-repo-settings]: https://github.com/oscard0m/octoherd-script-sync-repo-settings
+[oscard0m/octoherd-script-update-action-version-in-workflows]: https://github.com/oscard0m/octoherd-script-update-action-version-in-workflows
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-06-30.md b/src/twios/2024-06-30.md
index 240e022cb0..c371a7153b 100644
--- a/src/twios/2024-06-30.md
+++ b/src/twios/2024-06-30.md
@@ -1,105 +1,58 @@
 ## Rust
 
-- [marcoow/pacesetter] [#72](https://github.com/marcoow/pacesetter/pull/72) Add
-  READMEs to blueprint ([@marcoow])
-- [marcoow/pacesetter] [#71](https://github.com/marcoow/pacesetter/pull/71)
-  don't create db_test macro for minimal project type ([@marcoow])
-- [marcoow/pacesetter] [#70](https://github.com/marcoow/pacesetter/pull/70) run
-  CI daily ([@marcoow])
-- [marcoow/pacesetter] [#48](https://github.com/marcoow/pacesetter/pull/48) add
-  README and LICENSE ([@marcoow])
+- [marcoow/pacesetter] [#72](https://github.com/marcoow/pacesetter/pull/72) Add READMEs to blueprint ([@marcoow])
+- [marcoow/pacesetter] [#71](https://github.com/marcoow/pacesetter/pull/71) don't create db_test macro for minimal project type ([@marcoow])
+- [marcoow/pacesetter] [#70](https://github.com/marcoow/pacesetter/pull/70) run CI daily ([@marcoow])
+- [marcoow/pacesetter] [#48](https://github.com/marcoow/pacesetter/pull/48) add README and LICENSE ([@marcoow])
 
 ## Svelte
 
-- [sveltejs/language-tools]
-  [#2412](https://github.com/sveltejs/language-tools/pull/2412) fix: snippets
-  with TS incorrect transformation ([@paoloricciuti])
-- [sveltejs/svelte] [#12144](https://github.com/sveltejs/svelte/pull/12144) fix:
-  throw compilation error for malformed snippets ([@paoloricciuti])
+- [sveltejs/language-tools] [#2412](https://github.com/sveltejs/language-tools/pull/2412) fix: snippets with TS incorrect transformation ([@paoloricciuti])
+- [sveltejs/svelte] [#12144](https://github.com/sveltejs/svelte/pull/12144) fix: throw compilation error for malformed snippets ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/app-blueprint]
-  [#37](https://github.com/embroider-build/app-blueprint/pull/37) add new app.js
-  structure ([@mansona])
-- [embroider-build/app-blueprint]
-  [#28](https://github.com/embroider-build/app-blueprint/pull/28) add regression
-  tests for initialisers ([@mansona])
-- [embroider-build/ember-auto-import]
-  [#629](https://github.com/embroider-build/ember-auto-import/pull/629) only
-  check devDependencies when checking requested range of an app package
-  ([@mansona])
-- [embroider-build/embroider]
-  [#2008](https://github.com/embroider-build/embroider/pull/2008) Merge stable
-  into main ([@mansona])
-- [embroider-build/embroider]
-  [#2004](https://github.com/embroider-build/embroider/pull/2004) use pnpm to
-  publish unstable ([@mansona])
-- [embroider-build/embroider]
-  [#2006](https://github.com/embroider-build/embroider/pull/2006) Virtual
-  entrypoint export modules ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1957](https://github.com/embroider-build/embroider/pull/1957) Move
-  responsibility of booting the app from Embroider internals to the Ember app
-  ([@BlueCutOfficial])
+- [embroider-build/app-blueprint] [#37](https://github.com/embroider-build/app-blueprint/pull/37) add new app.js structure ([@mansona])
+- [embroider-build/app-blueprint] [#28](https://github.com/embroider-build/app-blueprint/pull/28) add regression tests for initialisers ([@mansona])
+- [embroider-build/ember-auto-import] [#629](https://github.com/embroider-build/ember-auto-import/pull/629) only check devDependencies when checking requested range of an app package ([@mansona])
+- [embroider-build/embroider] [#2008](https://github.com/embroider-build/embroider/pull/2008) Merge stable into main ([@mansona])
+- [embroider-build/embroider] [#2004](https://github.com/embroider-build/embroider/pull/2004) use pnpm to publish unstable ([@mansona])
+- [embroider-build/embroider] [#2006](https://github.com/embroider-build/embroider/pull/2006) Virtual entrypoint export modules ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1957](https://github.com/embroider-build/embroider/pull/1957) Move responsibility of booting the app from Embroider internals to the Ember app ([@BlueCutOfficial])
 
 ## Empress
 
-- [empress/guidemaker] [#115](https://github.com/empress/guidemaker/pull/115)
-  fix ember-data dependencies ([@mansona])
-- [empress/guidemaker] [#114](https://github.com/empress/guidemaker/pull/114)
-  fix version dropdown and add a test ([@mansona])
+- [empress/guidemaker] [#115](https://github.com/empress/guidemaker/pull/115) fix ember-data dependencies ([@mansona])
+- [empress/guidemaker] [#114](https://github.com/empress/guidemaker/pull/114) fix version dropdown and add a test ([@mansona])
 
 ## JavaScript
 
-- [snewcomer/intersection-observer-admin]
-  [#55](https://github.com/snewcomer/intersection-observer-admin/pull/55)
-  feat(memory-leaks): remove elements from registries when unobserve is called
-  ([@BobrImperator])
+- [snewcomer/intersection-observer-admin] [#55](https://github.com/snewcomer/intersection-observer-admin/pull/55) feat(memory-leaks): remove elements from registries when unobserve is called ([@BobrImperator])
 
 ## Ember
 
-- [ember-cli/ember-cli-deprecation-workflow]
-  [#189](https://github.com/ember-cli/ember-cli-deprecation-workflow/pull/189)
-  start using release-plan ([@mansona])
-- [ember-cli/ember-cli-deprecation-workflow]
-  [#188](https://github.com/ember-cli/ember-cli-deprecation-workflow/pull/188)
-  start using pnpm ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#903](https://github.com/ember-learn/ember-api-docs/pull/903) Start using
-  Embroider ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#513](https://github.com/ember-learn/ember-styleguide/pull/513) update
-  release-plan ([@mansona])
-- [mainmatter/ember-simple-auth]
-  [#2800](https://github.com/mainmatter/ember-simple-auth/pull/2800) Revert
-  "chore(ci): allow mainmatter/continue-on-error-comment to work on forks"
-  ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2798](https://github.com/mainmatter/ember-simple-auth/pull/2798)
-  feat(classic-test-app): change locationType to 'history' ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2797](https://github.com/mainmatter/ember-simple-auth/pull/2797) chore(ci):
-  allow mainmatter/continue-on-error-comment to work on forks ([@BobrImperator])
+- [ember-cli/ember-cli-deprecation-workflow] [#189](https://github.com/ember-cli/ember-cli-deprecation-workflow/pull/189) start using release-plan ([@mansona])
+- [ember-cli/ember-cli-deprecation-workflow] [#188](https://github.com/ember-cli/ember-cli-deprecation-workflow/pull/188) start using pnpm ([@mansona])
+- [ember-learn/ember-api-docs] [#903](https://github.com/ember-learn/ember-api-docs/pull/903) Start using Embroider ([@mansona])
+- [ember-learn/ember-styleguide] [#513](https://github.com/ember-learn/ember-styleguide/pull/513) update release-plan ([@mansona])
+- [mainmatter/ember-simple-auth] [#2800](https://github.com/mainmatter/ember-simple-auth/pull/2800) Revert "chore(ci): allow mainmatter/continue-on-error-comment to work on forks" ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2798](https://github.com/mainmatter/ember-simple-auth/pull/2798) feat(classic-test-app): change locationType to 'history' ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2797](https://github.com/mainmatter/ember-simple-auth/pull/2797) chore(ci): allow mainmatter/continue-on-error-comment to work on forks ([@BobrImperator])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@BobrImperator]: https://github.com/BobrImperator
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
 [@paoloricciuti]: https://github.com/paoloricciuti
-[ember-cli/ember-cli-deprecation-workflow]:
-  https://github.com/ember-cli/ember-cli-deprecation-workflow
+[ember-cli/ember-cli-deprecation-workflow]: https://github.com/ember-cli/ember-cli-deprecation-workflow
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
-[embroider-build/ember-auto-import]:
-  https://github.com/embroider-build/ember-auto-import
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
+[embroider-build/ember-auto-import]: https://github.com/embroider-build/ember-auto-import
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [empress/guidemaker]: https://github.com/empress/guidemaker
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
 [marcoow/pacesetter]: https://github.com/marcoow/pacesetter
-[snewcomer/intersection-observer-admin]:
-  https://github.com/snewcomer/intersection-observer-admin
+[snewcomer/intersection-observer-admin]: https://github.com/snewcomer/intersection-observer-admin
 [sveltejs/language-tools]: https://github.com/sveltejs/language-tools
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-07-07.md b/src/twios/2024-07-07.md
index e69f977e66..74d1393655 100644
--- a/src/twios/2024-07-07.md
+++ b/src/twios/2024-07-07.md
@@ -1,74 +1,37 @@
 ## Rust
 
-- [marcoow/pacesetter] [#72](https://github.com/marcoow/pacesetter/pull/72) Add
-  READMEs to blueprint ([@marcoow])
-- [marcoow/pacesetter] [#71](https://github.com/marcoow/pacesetter/pull/71)
-  don't create db_test macro for minimal project type ([@marcoow])
-- [marcoow/pacesetter] [#70](https://github.com/marcoow/pacesetter/pull/70) run
-  CI daily ([@marcoow])
-- [marcoow/pacesetter] [#48](https://github.com/marcoow/pacesetter/pull/48) add
-  README and LICENSE ([@marcoow])
+- [marcoow/pacesetter] [#72](https://github.com/marcoow/pacesetter/pull/72) Add READMEs to blueprint ([@marcoow])
+- [marcoow/pacesetter] [#71](https://github.com/marcoow/pacesetter/pull/71) don't create db_test macro for minimal project type ([@marcoow])
+- [marcoow/pacesetter] [#70](https://github.com/marcoow/pacesetter/pull/70) run CI daily ([@marcoow])
+- [marcoow/pacesetter] [#48](https://github.com/marcoow/pacesetter/pull/48) add README and LICENSE ([@marcoow])
 
 ## Svelte
 
-- [mainmatter/sheepdog] [#114](https://github.com/mainmatter/sheepdog/pull/114)
-  Add timeout utility function ([@nickschot])
-- [sveltejs/svelte] [#12290](https://github.com/sveltejs/svelte/pull/12290) fix:
-  correctly teardown `bind:this` with `$state.frozen` ([@paoloricciuti])
+- [mainmatter/sheepdog] [#114](https://github.com/mainmatter/sheepdog/pull/114) Add timeout utility function ([@nickschot])
+- [sveltejs/svelte] [#12290](https://github.com/sveltejs/svelte/pull/12290) fix: correctly teardown `bind:this` with `$state.frozen` ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#2017](https://github.com/embroider-build/embroider/pull/2017) update vite to
-  have a minimum version of 5.2 ([@mansona])
-- [embroider-build/embroider]
-  [#2015](https://github.com/embroider-build/embroider/pull/2015) update github
-  actions ([@mansona])
-- [embroider-build/embroider]
-  [#1931](https://github.com/embroider-build/embroider/pull/1931) update
-  scenario-tester ([@mansona])
-- [embroider-build/embroider]
-  [#1930](https://github.com/embroider-build/embroider/pull/1930) create a smoke
-  test for the widest possible matrix ([@mansona])
-- [embroider-build/embroider]
-  [#2012](https://github.com/embroider-build/embroider/pull/2012) Empty packages
-  as valid v2 addons ([@BlueCutOfficial])
+- [embroider-build/embroider] [#2017](https://github.com/embroider-build/embroider/pull/2017) update vite to have a minimum version of 5.2 ([@mansona])
+- [embroider-build/embroider] [#2015](https://github.com/embroider-build/embroider/pull/2015) update github actions ([@mansona])
+- [embroider-build/embroider] [#1931](https://github.com/embroider-build/embroider/pull/1931) update scenario-tester ([@mansona])
+- [embroider-build/embroider] [#1930](https://github.com/embroider-build/embroider/pull/1930) create a smoke test for the widest possible matrix ([@mansona])
+- [embroider-build/embroider] [#2012](https://github.com/embroider-build/embroider/pull/2012) Empty packages as valid v2 addons ([@BlueCutOfficial])
 
 ## Ember
 
-- [ef4/prember] [#84](https://github.com/ef4/prember/pull/84) add release-plan
-  ([@mansona])
-- [ef4/prember] [#83](https://github.com/ef4/prember/pull/83) switch to pnpm and
-  fix tests ([@mansona])
-- [ef4/prember] [#82](https://github.com/ef4/prember/pull/82) recycle the
-  fastboot instance after 1k requests ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#914](https://github.com/ember-learn/ember-api-docs/pull/914) fix
-  require-expect lint ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#30](https://github.com/ember-learn/ember-api-docs-data/pull/30) Fix names in
-  source s3 files ([@mansona])
-- [ember-learn/ember-data-request-service-cheat-sheet]
-  [#15](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/15)
-  stop deploying to gh-pages since we're using netlify ([@mansona])
-- [ember-learn/ember-data-request-service-cheat-sheet]
-  [#14](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/14)
-  stop using rootUrl to fix netlify previews and deployments ([@mansona])
-- [mainmatter/ember-cookies]
-  [#946](https://github.com/mainmatter/ember-cookies/pull/946) chore(ci):
-  strategy.fail-fast=false ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#945](https://github.com/mainmatter/ember-cookies/pull/945) chore: ci fixes
-  ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#944](https://github.com/mainmatter/ember-cookies/pull/944) chore(deps):
-  migrate eslint to new configuration syntax ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2802](https://github.com/mainmatter/ember-simple-auth/pull/2802) chore(ci):
-  add scenario against ember-lts-5.8 ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2801](https://github.com/mainmatter/ember-simple-auth/pull/2801) feat(deps):
-  update to ember-engines 0.11.0 ([@BobrImperator])
+- [ef4/prember] [#84](https://github.com/ef4/prember/pull/84) add release-plan ([@mansona])
+- [ef4/prember] [#83](https://github.com/ef4/prember/pull/83) switch to pnpm and fix tests ([@mansona])
+- [ef4/prember] [#82](https://github.com/ef4/prember/pull/82) recycle the fastboot instance after 1k requests ([@mansona])
+- [ember-learn/ember-api-docs] [#914](https://github.com/ember-learn/ember-api-docs/pull/914) fix require-expect lint ([@mansona])
+- [ember-learn/ember-api-docs-data] [#30](https://github.com/ember-learn/ember-api-docs-data/pull/30) Fix names in source s3 files ([@mansona])
+- [ember-learn/ember-data-request-service-cheat-sheet] [#15](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/15) stop deploying to gh-pages since we're using netlify ([@mansona])
+- [ember-learn/ember-data-request-service-cheat-sheet] [#14](https://github.com/ember-learn/ember-data-request-service-cheat-sheet/pull/14) stop using rootUrl to fix netlify previews and deployments ([@mansona])
+- [mainmatter/ember-cookies] [#946](https://github.com/mainmatter/ember-cookies/pull/946) chore(ci): strategy.fail-fast=false ([@BobrImperator])
+- [mainmatter/ember-cookies] [#945](https://github.com/mainmatter/ember-cookies/pull/945) chore: ci fixes ([@BobrImperator])
+- [mainmatter/ember-cookies] [#944](https://github.com/mainmatter/ember-cookies/pull/944) chore(deps): migrate eslint to new configuration syntax ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2802](https://github.com/mainmatter/ember-simple-auth/pull/2802) chore(ci): add scenario against ember-lts-5.8 ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2801](https://github.com/mainmatter/ember-simple-auth/pull/2801) feat(deps): update to ember-engines 0.11.0 ([@BobrImperator])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@BobrImperator]: https://github.com/BobrImperator
@@ -77,11 +40,9 @@
 [@nickschot]: https://github.com/nickschot
 [@paoloricciuti]: https://github.com/paoloricciuti
 [ef4/prember]: https://github.com/ef4/prember
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
-[ember-learn/ember-data-request-service-cheat-sheet]:
-  https://github.com/ember-learn/ember-data-request-service-cheat-sheet
+[ember-learn/ember-data-request-service-cheat-sheet]: https://github.com/ember-learn/ember-data-request-service-cheat-sheet
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
diff --git a/src/twios/2024-07-14.md b/src/twios/2024-07-14.md
index 5c60731e4e..b1952b449b 100644
--- a/src/twios/2024-07-14.md
+++ b/src/twios/2024-07-14.md
@@ -1,116 +1,56 @@
 ## Svelte
 
-- [SvelteLab/SvelteLab] [#305](https://github.com/SvelteLab/SvelteLab/pull/305)
-  fix: og images using new svelte server api ([@paoloricciuti])
-- [mainmatter/sheepdog] [#116](https://github.com/mainmatter/sheepdog/pull/116)
-  feat: add installation, usage and start docs ([@paoloricciuti])
-- [sveltejs/svelte] [#12396](https://github.com/sveltejs/svelte/pull/12396)
-  feat: runtime dev warn for mismatched `@html` ([@paoloricciuti])
-- [sveltejs/svelte] [#12394](https://github.com/sveltejs/svelte/pull/12394) fix:
-  playground warnings ([@paoloricciuti])
-- [sveltejs/svelte] [#12392](https://github.com/sveltejs/svelte/pull/12392) fix:
-  style shorthand not referencing variables ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#305](https://github.com/SvelteLab/SvelteLab/pull/305) fix: og images using new svelte server api ([@paoloricciuti])
+- [mainmatter/sheepdog] [#116](https://github.com/mainmatter/sheepdog/pull/116) feat: add installation, usage and start docs ([@paoloricciuti])
+- [sveltejs/svelte] [#12396](https://github.com/sveltejs/svelte/pull/12396) feat: runtime dev warn for mismatched `@html` ([@paoloricciuti])
+- [sveltejs/svelte] [#12394](https://github.com/sveltejs/svelte/pull/12394) fix: playground warnings ([@paoloricciuti])
+- [sveltejs/svelte] [#12392](https://github.com/sveltejs/svelte/pull/12392) fix: style shorthand not referencing variables ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#2045](https://github.com/embroider-build/embroider/pull/2045) add missing
-  resolve extension config to other vite.config files ([@mansona])
-- [embroider-build/embroider]
-  [#2044](https://github.com/embroider-build/embroider/pull/2044) fix
-  template-only-components in virtual entrypoint ([@mansona])
-- [embroider-build/embroider]
-  [#2043](https://github.com/embroider-build/embroider/pull/2043) Fix/
-  static-app-test shoudn't use an `isClassic` macro ([@BlueCutOfficial])
-- [embroider-build/embroider]
-  [#1966](https://github.com/embroider-build/embroider/pull/1966) New config
-  module, warning message ([@BlueCutOfficial])
+- [embroider-build/embroider] [#2045](https://github.com/embroider-build/embroider/pull/2045) add missing resolve extension config to other vite.config files ([@mansona])
+- [embroider-build/embroider] [#2044](https://github.com/embroider-build/embroider/pull/2044) fix template-only-components in virtual entrypoint ([@mansona])
+- [embroider-build/embroider] [#2043](https://github.com/embroider-build/embroider/pull/2043) Fix/ static-app-test shoudn't use an `isClassic` macro ([@BlueCutOfficial])
+- [embroider-build/embroider] [#1966](https://github.com/embroider-build/embroider/pull/1966) New config module, warning message ([@BlueCutOfficial])
 
 ## JavaScript
 
-- [ember-learn/ember-jsonapi-docs]
-  [#137](https://github.com/ember-learn/ember-jsonapi-docs/pull/137) emit
-  markdown for descriptions ([@mansona])
-- [embroider-build/release-plan]
-  [#72](https://github.com/embroider-build/release-plan/pull/72) add a test to
-  exercise latest-version dependency and update it ([@mansona])
-- [snewcomer/intersection-observer-admin]
-  [#57](https://github.com/snewcomer/intersection-observer-admin/pull/57) add
-  release-plan ([@mansona])
+- [ember-learn/ember-jsonapi-docs] [#137](https://github.com/ember-learn/ember-jsonapi-docs/pull/137) emit markdown for descriptions ([@mansona])
+- [embroider-build/release-plan] [#72](https://github.com/embroider-build/release-plan/pull/72) add a test to exercise latest-version dependency and update it ([@mansona])
+- [snewcomer/intersection-observer-admin] [#57](https://github.com/snewcomer/intersection-observer-admin/pull/57) add release-plan ([@mansona])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#245](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/245)
-  Translate `guides/accessibility/components` to 5.5 ([@BlueCutOfficial])
-- [ember-cli/babel-plugin-debug-macros]
-  [#101](https://github.com/ember-cli/babel-plugin-debug-macros/pull/101) fix
-  repo link ([@mansona])
-- [ember-cli/babel-plugin-debug-macros]
-  [#100](https://github.com/ember-cli/babel-plugin-debug-macros/pull/100) remove
-  security warnings from github ([@mansona])
-- [ember-cli/babel-plugin-debug-macros]
-  [#98](https://github.com/ember-cli/babel-plugin-debug-macros/pull/98) start
-  using release-plan ([@mansona])
-- [ember-cli/babel-plugin-debug-macros]
-  [#97](https://github.com/ember-cli/babel-plugin-debug-macros/pull/97)
-  docs(README.md)/ Fix a typo in the name of the plugin ([@BlueCutOfficial])
-- [ember-cli/ember-cli-deprecation-workflow]
-  [#192](https://github.com/ember-cli/ember-cli-deprecation-workflow/pull/192)
-  fix repository link in package.json ([@mansona])
-- [ember-cli/ember-cli-deprecation-workflow]
-  [#191](https://github.com/ember-cli/ember-cli-deprecation-workflow/pull/191)
-  update release plan workflow ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#919](https://github.com/ember-learn/ember-api-docs/pull/919) Merge main
-  ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#918](https://github.com/ember-learn/ember-api-docs/pull/918) go back to
-  using main branch for data ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#902](https://github.com/ember-learn/ember-api-docs/pull/902) use
-  ember-showdown-shiki ([@mansona])
-- [ember-learn/ember-api-docs-data]
-  [#25](https://github.com/ember-learn/ember-api-docs-data/pull/25) Use Markdown
-  for all descriptions ([@mansona])
-- [ember-learn/ember-website]
-  [#1116](https://github.com/ember-learn/ember-website/pull/1116) merge cli,
-  typescript, and embroider teams ([@mansona])
-- [emberjs/ember-inflector]
-  [#503](https://github.com/emberjs/ember-inflector/pull/503) start using
-  release-plan ([@mansona])
-- [emberjs/ember-inflector]
-  [#502](https://github.com/emberjs/ember-inflector/pull/502) Remove yarn and
-  upgrade ember blueprint with ember-cli-update ([@mansona])
-- [mainmatter/ember-cookies]
-  [#949](https://github.com/mainmatter/ember-cookies/pull/949) chore(deps):
-  remove ember-data ([@BobrImperator])
-- [mainmatter/ember-cookies]
-  [#947](https://github.com/mainmatter/ember-cookies/pull/947) chore(ci): add
-  ember-lts-5.8 scenario ([@BobrImperator])
-- [mainmatter/ember-simple-auth]
-  [#2804](https://github.com/mainmatter/ember-simple-auth/pull/2804)
-  chore(lint): Migrate eslint config ([@BobrImperator])
-- [mansona/ember-cli-notifications]
-  [#376](https://github.com/mansona/ember-cli-notifications/pull/376) update
-  release-plan (again) ([@mansona])
+- [DazzlingFugu/ember-fr-guides-source] [#245](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/245) Translate `guides/accessibility/components` to 5.5 ([@BlueCutOfficial])
+- [ember-cli/babel-plugin-debug-macros] [#101](https://github.com/ember-cli/babel-plugin-debug-macros/pull/101) fix repo link ([@mansona])
+- [ember-cli/babel-plugin-debug-macros] [#100](https://github.com/ember-cli/babel-plugin-debug-macros/pull/100) remove security warnings from github ([@mansona])
+- [ember-cli/babel-plugin-debug-macros] [#98](https://github.com/ember-cli/babel-plugin-debug-macros/pull/98) start using release-plan ([@mansona])
+- [ember-cli/babel-plugin-debug-macros] [#97](https://github.com/ember-cli/babel-plugin-debug-macros/pull/97) docs(README.md)/ Fix a typo in the name of the plugin ([@BlueCutOfficial])
+- [ember-cli/ember-cli-deprecation-workflow] [#192](https://github.com/ember-cli/ember-cli-deprecation-workflow/pull/192) fix repository link in package.json ([@mansona])
+- [ember-cli/ember-cli-deprecation-workflow] [#191](https://github.com/ember-cli/ember-cli-deprecation-workflow/pull/191) update release plan workflow ([@mansona])
+- [ember-learn/ember-api-docs] [#919](https://github.com/ember-learn/ember-api-docs/pull/919) Merge main ([@mansona])
+- [ember-learn/ember-api-docs] [#918](https://github.com/ember-learn/ember-api-docs/pull/918) go back to using main branch for data ([@mansona])
+- [ember-learn/ember-api-docs] [#902](https://github.com/ember-learn/ember-api-docs/pull/902) use ember-showdown-shiki ([@mansona])
+- [ember-learn/ember-api-docs-data] [#25](https://github.com/ember-learn/ember-api-docs-data/pull/25) Use Markdown for all descriptions ([@mansona])
+- [ember-learn/ember-website] [#1116](https://github.com/ember-learn/ember-website/pull/1116) merge cli, typescript, and embroider teams ([@mansona])
+- [emberjs/ember-inflector] [#503](https://github.com/emberjs/ember-inflector/pull/503) start using release-plan ([@mansona])
+- [emberjs/ember-inflector] [#502](https://github.com/emberjs/ember-inflector/pull/502) Remove yarn and upgrade ember blueprint with ember-cli-update ([@mansona])
+- [mainmatter/ember-cookies] [#949](https://github.com/mainmatter/ember-cookies/pull/949) chore(deps): remove ember-data ([@BobrImperator])
+- [mainmatter/ember-cookies] [#947](https://github.com/mainmatter/ember-cookies/pull/947) chore(ci): add ember-lts-5.8 scenario ([@BobrImperator])
+- [mainmatter/ember-simple-auth] [#2804](https://github.com/mainmatter/ember-simple-auth/pull/2804) chore(lint): Migrate eslint config ([@BobrImperator])
+- [mansona/ember-cli-notifications] [#376](https://github.com/mansona/ember-cli-notifications/pull/376) update release-plan (again) ([@mansona])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@BobrImperator]: https://github.com/BobrImperator
 [@mansona]: https://github.com/mansona
 [@paoloricciuti]: https://github.com/paoloricciuti
-[DazzlingFugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [SvelteLab/SvelteLab]: https://github.com/SvelteLab/SvelteLab
-[ember-cli/babel-plugin-debug-macros]:
-  https://github.com/ember-cli/babel-plugin-debug-macros
-[ember-cli/ember-cli-deprecation-workflow]:
-  https://github.com/ember-cli/ember-cli-deprecation-workflow
-[ember-learn/ember-api-docs-data]:
-  https://github.com/ember-learn/ember-api-docs-data
+[ember-cli/babel-plugin-debug-macros]: https://github.com/ember-cli/babel-plugin-debug-macros
+[ember-cli/ember-cli-deprecation-workflow]: https://github.com/ember-cli/ember-cli-deprecation-workflow
+[ember-learn/ember-api-docs-data]: https://github.com/ember-learn/ember-api-docs-data
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
-[ember-learn/ember-jsonapi-docs]:
-  https://github.com/ember-learn/ember-jsonapi-docs
+[ember-learn/ember-jsonapi-docs]: https://github.com/ember-learn/ember-jsonapi-docs
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [emberjs/ember-inflector]: https://github.com/emberjs/ember-inflector
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
@@ -118,8 +58,6 @@
 [mainmatter/ember-cookies]: https://github.com/mainmatter/ember-cookies
 [mainmatter/ember-simple-auth]: https://github.com/mainmatter/ember-simple-auth
 [mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
-[mansona/ember-cli-notifications]:
-  https://github.com/mansona/ember-cli-notifications
-[snewcomer/intersection-observer-admin]:
-  https://github.com/snewcomer/intersection-observer-admin
+[mansona/ember-cli-notifications]: https://github.com/mansona/ember-cli-notifications
+[snewcomer/intersection-observer-admin]: https://github.com/snewcomer/intersection-observer-admin
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-07-21.md b/src/twios/2024-07-21.md
index 77e6e0a76e..aedcc3b77b 100644
--- a/src/twios/2024-07-21.md
+++ b/src/twios/2024-07-21.md
@@ -1,133 +1,71 @@
 ## Svelte
 
-- [SvelteLab/SvelteLab] [#305](https://github.com/SvelteLab/SvelteLab/pull/305)
-  fix: og images using new svelte server api ([@paoloricciuti])
-- [mainmatter/sheepdog] [#129](https://github.com/mainmatter/sheepdog/pull/129)
-  chore: setup netlify deploy ([@paoloricciuti])
-- [mainmatter/sheepdog] [#124](https://github.com/mainmatter/sheepdog/pull/124)
-  feat: add Mid run cancellation guide ([@paoloricciuti])
+- [SvelteLab/SvelteLab] [#305](https://github.com/SvelteLab/SvelteLab/pull/305) fix: og images using new svelte server api ([@paoloricciuti])
+- [mainmatter/sheepdog] [#129](https://github.com/mainmatter/sheepdog/pull/129) chore: setup netlify deploy ([@paoloricciuti])
+- [mainmatter/sheepdog] [#124](https://github.com/mainmatter/sheepdog/pull/124) feat: add Mid run cancellation guide ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/app-blueprint]
-  [#38](https://github.com/embroider-build/app-blueprint/pull/38) add a test
-  that verifies that the esbuild step was successful ([@mansona])
-- [embroider-build/embroider]
-  [#2053](https://github.com/embroider-build/embroider/pull/2053) fix for
-  esbuild finding helpers and components from app-tree-merging in templates
-  ([@mansona])
-- [embroider-build/embroider]
-  [#2051](https://github.com/embroider-build/embroider/pull/2051) fix template
-  only components in esbuild on windows ([@mansona])
-- [embroider-build/embroider]
-  [#2050](https://github.com/embroider-build/embroider/pull/2050) make sure to
-  use a js file in a js app scenario ([@mansona])
-- [embroider-build/embroider]
-  [#2048](https://github.com/embroider-build/embroider/pull/2048) Fix windows
-  tests ([@mansona])
+- [embroider-build/app-blueprint] [#38](https://github.com/embroider-build/app-blueprint/pull/38) add a test that verifies that the esbuild step was successful ([@mansona])
+- [embroider-build/embroider] [#2053](https://github.com/embroider-build/embroider/pull/2053) fix for esbuild finding helpers and components from app-tree-merging in templates ([@mansona])
+- [embroider-build/embroider] [#2051](https://github.com/embroider-build/embroider/pull/2051) fix template only components in esbuild on windows ([@mansona])
+- [embroider-build/embroider] [#2050](https://github.com/embroider-build/embroider/pull/2050) make sure to use a js file in a js app scenario ([@mansona])
+- [embroider-build/embroider] [#2048](https://github.com/embroider-build/embroider/pull/2048) Fix windows tests ([@mansona])
 
 ## Empress
 
-- [empress/rfc-process-mdbook-template]
-  [#22](https://github.com/empress/rfc-process-mdbook-template/pull/22) use
-  pnpm/action-setup@v4 everywhere ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#21](https://github.com/empress/rfc-process-mdbook-template/pull/21) fix Lint
-  to the Future dashboard ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#20](https://github.com/empress/rfc-process-mdbook-template/pull/20) start
-  using release-plan ([@mansona])
-- [empress/rfc-process-mdbook-template]
-  [#19](https://github.com/empress/rfc-process-mdbook-template/pull/19) update
-  font awesome and switch to pnpm ([@mansona])
+- [empress/rfc-process-mdbook-template] [#22](https://github.com/empress/rfc-process-mdbook-template/pull/22) use pnpm/action-setup@v4 everywhere ([@mansona])
+- [empress/rfc-process-mdbook-template] [#21](https://github.com/empress/rfc-process-mdbook-template/pull/21) fix Lint to the Future dashboard ([@mansona])
+- [empress/rfc-process-mdbook-template] [#20](https://github.com/empress/rfc-process-mdbook-template/pull/20) start using release-plan ([@mansona])
+- [empress/rfc-process-mdbook-template] [#19](https://github.com/empress/rfc-process-mdbook-template/pull/19) update font awesome and switch to pnpm ([@mansona])
 
 ## JavaScript
 
-- [embroider-build/create-release-plan-setup]
-  [#127](https://github.com/embroider-build/create-release-plan-setup/pull/127)
-  use the latest pnpm/action-setup and don't define pnpm version if
-  packageManager is defined ([@mansona])
-- [embroider-build/release-plan]
-  [#74](https://github.com/embroider-build/release-plan/pull/74) move @types
-  packages to dev-dependencies ([@mansona])
-- [mansona/auto-reveal-theme-mainmatter]
-  [#4](https://github.com/mansona/auto-reveal-theme-mainmatter/pull/4) fix
-  sidebar ([@mansona])
-- [mansona/auto-reveal-theme-mainmatter]
-  [#2](https://github.com/mansona/auto-reveal-theme-mainmatter/pull/2) setup
-  release-plan ([@mansona])
-- [mansona/auto-reveal-theme-mainmatter]
-  [#1](https://github.com/mansona/auto-reveal-theme-mainmatter/pull/1) provide a
-  default highlight theme ([@mansona])
-- [mansona/layer-gen] [#7](https://github.com/mansona/layer-gen/pull/7) use
-  release-plan ([@mansona])
-- [mansona/layer-gen] [#6](https://github.com/mansona/layer-gen/pull/6) add
-  missing resolve dependency ([@mansona])
-- [pichfl/auto-reveal] [#9](https://github.com/pichfl/auto-reveal/pull/9) allow
-  themes to be able to provide config for initialize ([@mansona])
-- [pichfl/auto-reveal] [#8](https://github.com/pichfl/auto-reveal/pull/8) import
-  theme after default reveal css ([@mansona])
-- [shikijs/shiki-magic-move]
-  [#18](https://github.com/shikijs/shiki-magic-move/pull/18) fix: fake
-  transition blocking events ([@paoloricciuti])
-- [snewcomer/intersection-observer-admin]
-  [#58](https://github.com/snewcomer/intersection-observer-admin/pull/58)
-  feat(memory-leaks): remove elements from the window root ([@BobrImperator])
+- [embroider-build/create-release-plan-setup] [#127](https://github.com/embroider-build/create-release-plan-setup/pull/127) use the latest pnpm/action-setup and don't define pnpm version if packageManager is defined ([@mansona])
+- [embroider-build/release-plan] [#74](https://github.com/embroider-build/release-plan/pull/74) move @types packages to dev-dependencies ([@mansona])
+- [mansona/auto-reveal-theme-mainmatter] [#4](https://github.com/mansona/auto-reveal-theme-mainmatter/pull/4) fix sidebar ([@mansona])
+- [mansona/auto-reveal-theme-mainmatter] [#2](https://github.com/mansona/auto-reveal-theme-mainmatter/pull/2) setup release-plan ([@mansona])
+- [mansona/auto-reveal-theme-mainmatter] [#1](https://github.com/mansona/auto-reveal-theme-mainmatter/pull/1) provide a default highlight theme ([@mansona])
+- [mansona/layer-gen] [#7](https://github.com/mansona/layer-gen/pull/7) use release-plan ([@mansona])
+- [mansona/layer-gen] [#6](https://github.com/mansona/layer-gen/pull/6) add missing resolve dependency ([@mansona])
+- [pichfl/auto-reveal] [#9](https://github.com/pichfl/auto-reveal/pull/9) allow themes to be able to provide config for initialize ([@mansona])
+- [pichfl/auto-reveal] [#8](https://github.com/pichfl/auto-reveal/pull/8) import theme after default reveal css ([@mansona])
+- [shikijs/shiki-magic-move] [#18](https://github.com/shikijs/shiki-magic-move/pull/18) fix: fake transition blocking events ([@paoloricciuti])
+- [snewcomer/intersection-observer-admin] [#58](https://github.com/snewcomer/intersection-observer-admin/pull/58) feat(memory-leaks): remove elements from the window root ([@BobrImperator])
 
 ## Mainmatter's playbook
 
-- [mainmatter/playbook] [#207](https://github.com/mainmatter/playbook/pull/207)
-  Redesign ([@marcoow])
-- [mainmatter/playbook] [#181](https://github.com/mainmatter/playbook/pull/181)
-  Add some notes on pairing sessions ([@marcoow])
+- [mainmatter/playbook] [#207](https://github.com/mainmatter/playbook/pull/207) Redesign ([@marcoow])
+- [mainmatter/playbook] [#181](https://github.com/mainmatter/playbook/pull/181) Add some notes on pairing sessions ([@marcoow])
 
 ## Ember
 
-- [adopted-ember-addons/ember-sortable]
-  [#571](https://github.com/adopted-ember-addons/ember-sortable/pull/571) fix
-  demo links and turn of github pages deploy ([@mansona])
-- [bgantzler/ember-mirage]
-  [#41](https://github.com/bgantzler/ember-mirage/pull/41) update release-plan
-  ([@mansona])
-- [elwayman02/ember-resize-modifier]
-  [#967](https://github.com/elwayman02/ember-resize-modifier/pull/967) convert
-  addon to v2 ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#922](https://github.com/ember-learn/ember-api-docs/pull/922) start using
-  pnpm@9 ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#921](https://github.com/ember-learn/ember-api-docs/pull/921) update to
-  latest styleguide to fix the footer ([@mansona])
-- [ember-learn/ember-styleguide]
-  [#516](https://github.com/ember-learn/ember-styleguide/pull/516) use more
-  standard postcss process ([@mansona])
+- [adopted-ember-addons/ember-sortable] [#571](https://github.com/adopted-ember-addons/ember-sortable/pull/571) fix demo links and turn of github pages deploy ([@mansona])
+- [bgantzler/ember-mirage] [#41](https://github.com/bgantzler/ember-mirage/pull/41) update release-plan ([@mansona])
+- [elwayman02/ember-resize-modifier] [#967](https://github.com/elwayman02/ember-resize-modifier/pull/967) convert addon to v2 ([@mansona])
+- [ember-learn/ember-api-docs] [#922](https://github.com/ember-learn/ember-api-docs/pull/922) start using pnpm@9 ([@mansona])
+- [ember-learn/ember-api-docs] [#921](https://github.com/ember-learn/ember-api-docs/pull/921) update to latest styleguide to fix the footer ([@mansona])
+- [ember-learn/ember-styleguide] [#516](https://github.com/ember-learn/ember-styleguide/pull/516) use more standard postcss process ([@mansona])
 
 [@BobrImperator]: https://github.com/BobrImperator
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
 [@paoloricciuti]: https://github.com/paoloricciuti
 [SvelteLab/SvelteLab]: https://github.com/SvelteLab/SvelteLab
-[adopted-ember-addons/ember-sortable]:
-  https://github.com/adopted-ember-addons/ember-sortable
+[adopted-ember-addons/ember-sortable]: https://github.com/adopted-ember-addons/ember-sortable
 [bgantzler/ember-mirage]: https://github.com/bgantzler/ember-mirage
-[elwayman02/ember-resize-modifier]:
-  https://github.com/elwayman02/ember-resize-modifier
+[elwayman02/ember-resize-modifier]: https://github.com/elwayman02/ember-resize-modifier
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
 [ember-learn/ember-styleguide]: https://github.com/ember-learn/ember-styleguide
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
-[embroider-build/create-release-plan-setup]:
-  https://github.com/embroider-build/create-release-plan-setup
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
+[embroider-build/create-release-plan-setup]: https://github.com/embroider-build/create-release-plan-setup
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [embroider-build/release-plan]: https://github.com/embroider-build/release-plan
-[empress/rfc-process-mdbook-template]:
-  https://github.com/empress/rfc-process-mdbook-template
+[empress/rfc-process-mdbook-template]: https://github.com/empress/rfc-process-mdbook-template
 [mainmatter/playbook]: https://github.com/mainmatter/playbook
 [mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
-[mansona/auto-reveal-theme-mainmatter]:
-  https://github.com/mansona/auto-reveal-theme-mainmatter
+[mansona/auto-reveal-theme-mainmatter]: https://github.com/mansona/auto-reveal-theme-mainmatter
 [mansona/layer-gen]: https://github.com/mansona/layer-gen
 [pichfl/auto-reveal]: https://github.com/pichfl/auto-reveal
 [shikijs/shiki-magic-move]: https://github.com/shikijs/shiki-magic-move
-[snewcomer/intersection-observer-admin]:
-  https://github.com/snewcomer/intersection-observer-admin
+[snewcomer/intersection-observer-admin]: https://github.com/snewcomer/intersection-observer-admin
diff --git a/src/twios/2024-07-28.md b/src/twios/2024-07-28.md
index cfbc49b936..b6a873ec3b 100644
--- a/src/twios/2024-07-28.md
+++ b/src/twios/2024-07-28.md
@@ -1,91 +1,44 @@
 ## Svelte
 
-- [mainmatter/sheepdog] [#141](https://github.com/mainmatter/sheepdog/pull/141)
-  fix: avoid changing state of successful task to cancelled ([@paoloricciuti])
-- [mainmatter/sheepdog] [#137](https://github.com/mainmatter/sheepdog/pull/137)
-  fix: make async transform with dot notation too ([@paoloricciuti])
-- [mainmatter/sheepdog] [#132](https://github.com/mainmatter/sheepdog/pull/132)
-  feat: return derived state to `perform` return value ([@paoloricciuti])
-- [paoloricciuti/optimistikit]
-  [#19](https://github.com/paoloricciuti/optimistikit/pull/19) fix: use
-  `$effect.pre` instead of `$effect` in optimistikit ([@paoloricciuti])
-- [paoloricciuti/optimistikit]
-  [#17](https://github.com/paoloricciuti/optimistikit/pull/17) breaking: switch
-  main publishing line to svelte 5 ([@paoloricciuti])
-- [paoloricciuti/sveltekit-search-params]
-  [#98](https://github.com/paoloricciuti/sveltekit-search-params/pull/98) Update
-  poor-birds-dance.md ([@paoloricciuti])
-- [paoloricciuti/sveltekit-search-params]
-  [#89](https://github.com/paoloricciuti/sveltekit-search-params/pull/89) fix:
-  avoid complex values default being overriden on write ([@paoloricciuti])
-- [svecosystem/runed] [#122](https://github.com/svecosystem/runed/pull/122) fix:
-  avoid writing to state in media-query getter ([@paoloricciuti])
+- [mainmatter/sheepdog] [#141](https://github.com/mainmatter/sheepdog/pull/141) fix: avoid changing state of successful task to cancelled ([@paoloricciuti])
+- [mainmatter/sheepdog] [#137](https://github.com/mainmatter/sheepdog/pull/137) fix: make async transform with dot notation too ([@paoloricciuti])
+- [mainmatter/sheepdog] [#132](https://github.com/mainmatter/sheepdog/pull/132) feat: return derived state to `perform` return value ([@paoloricciuti])
+- [paoloricciuti/optimistikit] [#19](https://github.com/paoloricciuti/optimistikit/pull/19) fix: use `$effect.pre` instead of `$effect` in optimistikit ([@paoloricciuti])
+- [paoloricciuti/optimistikit] [#17](https://github.com/paoloricciuti/optimistikit/pull/17) breaking: switch main publishing line to svelte 5 ([@paoloricciuti])
+- [paoloricciuti/sveltekit-search-params] [#98](https://github.com/paoloricciuti/sveltekit-search-params/pull/98) Update poor-birds-dance.md ([@paoloricciuti])
+- [paoloricciuti/sveltekit-search-params] [#89](https://github.com/paoloricciuti/sveltekit-search-params/pull/89) fix: avoid complex values default being overriden on write ([@paoloricciuti])
+- [svecosystem/runed] [#122](https://github.com/svecosystem/runed/pull/122) fix: avoid writing to state in media-query getter ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/app-blueprint]
-  [#44](https://github.com/embroider-build/app-blueprint/pull/44) change
-  dependabot versioning strategy to increase ([@mansona])
-- [embroider-build/app-blueprint]
-  [#43](https://github.com/embroider-build/app-blueprint/pull/43) set
-  packageManager in package.json and rely on that in CI ([@mansona])
-- [embroider-build/embroider]
-  [#2039](https://github.com/embroider-build/embroider/pull/2039) Fix/
-  static-app-test shouldn't trigger a build error
-  `@babel/helper-modules-imports` not found ([@BlueCutOfficial])
+- [embroider-build/app-blueprint] [#44](https://github.com/embroider-build/app-blueprint/pull/44) change dependabot versioning strategy to increase ([@mansona])
+- [embroider-build/app-blueprint] [#43](https://github.com/embroider-build/app-blueprint/pull/43) set packageManager in package.json and rely on that in CI ([@mansona])
+- [embroider-build/embroider] [#2039](https://github.com/embroider-build/embroider/pull/2039) Fix/ static-app-test shouldn't trigger a build error `@babel/helper-modules-imports` not found ([@BlueCutOfficial])
 
 ## Empress
 
-- [empress/field-guide] [#102](https://github.com/empress/field-guide/pull/102)
-  setup release-plan ([@mansona])
-- [empress/field-guide] [#101](https://github.com/empress/field-guide/pull/101)
-  Update dependencies, start using pnpm, and drop support for
-  ember-auto-import@1 ([@mansona])
+- [empress/field-guide] [#102](https://github.com/empress/field-guide/pull/102) setup release-plan ([@mansona])
+- [empress/field-guide] [#101](https://github.com/empress/field-guide/pull/101) Update dependencies, start using pnpm, and drop support for ember-auto-import@1 ([@mansona])
 
 ## JavaScript
 
-- [mansona/Downsize] [#9](https://github.com/mansona/Downsize/pull/9) setup
-  release-plan ([@mansona])
-- [mansona/Downsize] [#8](https://github.com/mansona/Downsize/pull/8) improve
-  esm-cjs co-deploy ([@mansona])
-- [mansona/auto-reveal-theme-mainmatter]
-  [#6](https://github.com/mansona/auto-reveal-theme-mainmatter/pull/6) go back
-  to having a smaller sidebar ([@mansona])
-- [pichfl/auto-reveal] [#12](https://github.com/pichfl/auto-reveal/pull/12)
-  Remove deprecation from import.meta.glob ([@pichfl])
+- [mansona/Downsize] [#9](https://github.com/mansona/Downsize/pull/9) setup release-plan ([@mansona])
+- [mansona/Downsize] [#8](https://github.com/mansona/Downsize/pull/8) improve esm-cjs co-deploy ([@mansona])
+- [mansona/auto-reveal-theme-mainmatter] [#6](https://github.com/mansona/auto-reveal-theme-mainmatter/pull/6) go back to having a smaller sidebar ([@mansona])
+- [pichfl/auto-reveal] [#12](https://github.com/pichfl/auto-reveal/pull/12) Remove deprecation from import.meta.glob ([@pichfl])
 
 ## Ember
 
-- [ember-learn/deprecation-app]
-  [#1390](https://github.com/ember-learn/deprecation-app/pull/1390) update node
-  version and use pnpm ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#926](https://github.com/ember-learn/ember-api-docs/pull/926) Merge main into
-  website redesign ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#924](https://github.com/ember-learn/ember-api-docs/pull/924) Update ember
-  globals ([@mansona])
-- [ember-learn/ember-api-docs]
-  [#923](https://github.com/ember-learn/ember-api-docs/pull/923) stop requesting
-  mappings over the network and fix shoebox usage ([@mansona])
-- [ember-learn/ember-website]
-  [#1120](https://github.com/ember-learn/ember-website/pull/1120) add
-  ember-data-fastboot to enable the shoebox across the site ([@mansona])
-- [ember-learn/ember-website]
-  [#805](https://github.com/ember-learn/ember-website/pull/805) add ability to
-  link to a particular mascot ([@mansona])
-- [emberjs/ember-inflector]
-  [#499](https://github.com/emberjs/ember-inflector/pull/499) convert to a v2
-  addon using ember init ([@mansona])
-- [mansona/ember-html-excerpt]
-  [#9](https://github.com/mansona/ember-html-excerpt/pull/9) move test to tests
-  folder ([@mansona])
-- [mansona/ember-html-excerpt]
-  [#7](https://github.com/mansona/ember-html-excerpt/pull/7) setup release-plan
-  ([@mansona])
-- [mansona/ember-html-excerpt]
-  [#6](https://github.com/mansona/ember-html-excerpt/pull/6) upgrade to v2
-  ([@mansona])
+- [ember-learn/deprecation-app] [#1390](https://github.com/ember-learn/deprecation-app/pull/1390) update node version and use pnpm ([@mansona])
+- [ember-learn/ember-api-docs] [#926](https://github.com/ember-learn/ember-api-docs/pull/926) Merge main into website redesign ([@mansona])
+- [ember-learn/ember-api-docs] [#924](https://github.com/ember-learn/ember-api-docs/pull/924) Update ember globals ([@mansona])
+- [ember-learn/ember-api-docs] [#923](https://github.com/ember-learn/ember-api-docs/pull/923) stop requesting mappings over the network and fix shoebox usage ([@mansona])
+- [ember-learn/ember-website] [#1120](https://github.com/ember-learn/ember-website/pull/1120) add ember-data-fastboot to enable the shoebox across the site ([@mansona])
+- [ember-learn/ember-website] [#805](https://github.com/ember-learn/ember-website/pull/805) add ability to link to a particular mascot ([@mansona])
+- [emberjs/ember-inflector] [#499](https://github.com/emberjs/ember-inflector/pull/499) convert to a v2 addon using ember init ([@mansona])
+- [mansona/ember-html-excerpt] [#9](https://github.com/mansona/ember-html-excerpt/pull/9) move test to tests folder ([@mansona])
+- [mansona/ember-html-excerpt] [#7](https://github.com/mansona/ember-html-excerpt/pull/7) setup release-plan ([@mansona])
+- [mansona/ember-html-excerpt] [#6](https://github.com/mansona/ember-html-excerpt/pull/6) upgrade to v2 ([@mansona])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@BobrImperator]: https://github.com/BobrImperator
@@ -97,20 +50,16 @@
 [ember-learn/ember-api-docs]: https://github.com/ember-learn/ember-api-docs
 [ember-learn/ember-website]: https://github.com/ember-learn/ember-website
 [emberjs/ember-inflector]: https://github.com/emberjs/ember-inflector
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [empress/field-guide]: https://github.com/empress/field-guide
 [mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
-[mainmatter/weplan-ember-workshop]:
-  https://github.com/mainmatter/weplan-ember-workshop
+[mainmatter/weplan-ember-workshop]: https://github.com/mainmatter/weplan-ember-workshop
 [mainmatter/whirlwind-chat]: https://github.com/mainmatter/whirlwind-chat
 [mansona/Downsize]: https://github.com/mansona/Downsize
-[mansona/auto-reveal-theme-mainmatter]:
-  https://github.com/mansona/auto-reveal-theme-mainmatter
+[mansona/auto-reveal-theme-mainmatter]: https://github.com/mansona/auto-reveal-theme-mainmatter
 [mansona/ember-html-excerpt]: https://github.com/mansona/ember-html-excerpt
 [paoloricciuti/optimistikit]: https://github.com/paoloricciuti/optimistikit
-[paoloricciuti/sveltekit-search-params]:
-  https://github.com/paoloricciuti/sveltekit-search-params
+[paoloricciuti/sveltekit-search-params]: https://github.com/paoloricciuti/sveltekit-search-params
 [pichfl/auto-reveal]: https://github.com/pichfl/auto-reveal
 [svecosystem/runed]: https://github.com/svecosystem/runed
diff --git a/src/twios/2024-08-04.md b/src/twios/2024-08-04.md
index cf049b3e57..097753b10c 100644
--- a/src/twios/2024-08-04.md
+++ b/src/twios/2024-08-04.md
@@ -1,62 +1,34 @@
 ## Svelte
 
-- [mainmatter/sheepdog] [#151](https://github.com/mainmatter/sheepdog/pull/151)
-  fix: monorepo settings ([@paoloricciuti])
-- [mainmatter/sheepdog] [#147](https://github.com/mainmatter/sheepdog/pull/147)
-  chore: upgrade `typescript-eslint` ([@paoloricciuti])
-- [paoloricciuti/optimistikit]
-  [#22](https://github.com/paoloricciuti/optimistikit/pull/22) chore: less flaky
-  tests ([@paoloricciuti])
-- [paoloricciuti/optimistikit]
-  [#19](https://github.com/paoloricciuti/optimistikit/pull/19) fix: use
-  `$effect.pre` instead of `$effect` in optimistikit ([@paoloricciuti])
-- [paoloricciuti/optimistikit]
-  [#17](https://github.com/paoloricciuti/optimistikit/pull/17) breaking: switch
-  main publishing line to svelte 5 ([@paoloricciuti])
-- [paoloricciuti/sveltekit-search-params]
-  [#98](https://github.com/paoloricciuti/sveltekit-search-params/pull/98) Update
-  poor-birds-dance.md ([@paoloricciuti])
-- [paoloricciuti/sveltekit-search-params]
-  [#89](https://github.com/paoloricciuti/sveltekit-search-params/pull/89) fix:
-  avoid complex values default being overriden on write ([@paoloricciuti])
-- [sveltejs/kit] [#12524](https://github.com/sveltejs/kit/pull/12524) fix:
-  ignore warning binding non reactive ([@paoloricciuti])
-- [sveltejs/svelte] [#12715](https://github.com/sveltejs/svelte/pull/12715) fix:
-  add css hash to custom element rendered with `svelte:element`
-  ([@paoloricciuti])
-- [sveltejs/svelte] [#12704](https://github.com/sveltejs/svelte/pull/12704) fix:
-  maintain imports in modules ([@paoloricciuti])
-- [sveltejs/svelte] [#12692](https://github.com/sveltejs/svelte/pull/12692)
-  feat: function called as tagged template literal is reactively called
-  ([@paoloricciuti])
-- [sveltejs/svelte] [#12660](https://github.com/sveltejs/svelte/pull/12660)
-  feat: allow for `svelte:options` css injected ([@paoloricciuti])
-- [sveltejs/svelte] [#12649](https://github.com/sveltejs/svelte/pull/12649) fix:
-  always set draggable through `setAttribute` to avoid weird behavior
-  ([@paoloricciuti])
-- [sveltejs/svelte] [#12608](https://github.com/sveltejs/svelte/pull/12608)
-  feat: allow ignoring runtime warnings ([@paoloricciuti])
+- [mainmatter/sheepdog] [#151](https://github.com/mainmatter/sheepdog/pull/151) fix: monorepo settings ([@paoloricciuti])
+- [mainmatter/sheepdog] [#147](https://github.com/mainmatter/sheepdog/pull/147) chore: upgrade `typescript-eslint` ([@paoloricciuti])
+- [paoloricciuti/optimistikit] [#22](https://github.com/paoloricciuti/optimistikit/pull/22) chore: less flaky tests ([@paoloricciuti])
+- [paoloricciuti/optimistikit] [#19](https://github.com/paoloricciuti/optimistikit/pull/19) fix: use `$effect.pre` instead of `$effect` in optimistikit ([@paoloricciuti])
+- [paoloricciuti/optimistikit] [#17](https://github.com/paoloricciuti/optimistikit/pull/17) breaking: switch main publishing line to svelte 5 ([@paoloricciuti])
+- [paoloricciuti/sveltekit-search-params] [#98](https://github.com/paoloricciuti/sveltekit-search-params/pull/98) Update poor-birds-dance.md ([@paoloricciuti])
+- [paoloricciuti/sveltekit-search-params] [#89](https://github.com/paoloricciuti/sveltekit-search-params/pull/89) fix: avoid complex values default being overriden on write ([@paoloricciuti])
+- [sveltejs/kit] [#12524](https://github.com/sveltejs/kit/pull/12524) fix: ignore warning binding non reactive ([@paoloricciuti])
+- [sveltejs/svelte] [#12715](https://github.com/sveltejs/svelte/pull/12715) fix: add css hash to custom element rendered with `svelte:element` ([@paoloricciuti])
+- [sveltejs/svelte] [#12704](https://github.com/sveltejs/svelte/pull/12704) fix: maintain imports in modules ([@paoloricciuti])
+- [sveltejs/svelte] [#12692](https://github.com/sveltejs/svelte/pull/12692) feat: function called as tagged template literal is reactively called ([@paoloricciuti])
+- [sveltejs/svelte] [#12660](https://github.com/sveltejs/svelte/pull/12660) feat: allow for `svelte:options` css injected ([@paoloricciuti])
+- [sveltejs/svelte] [#12649](https://github.com/sveltejs/svelte/pull/12649) fix: always set draggable through `setAttribute` to avoid weird behavior ([@paoloricciuti])
+- [sveltejs/svelte] [#12608](https://github.com/sveltejs/svelte/pull/12608) feat: allow ignoring runtime warnings ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/embroider]
-  [#2028](https://github.com/embroider-build/embroider/pull/2028) Rename
-  #embroider_compat/_ to @embroider/virtual/_ ([@BlueCutOfficial])
+- [embroider-build/embroider] [#2028](https://github.com/embroider-build/embroider/pull/2028) Rename `#embroider_compat/*` to `@embroider/virtual/*` ([@BlueCutOfficial])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#246](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/246)
-  Translate `guides/upgrading/index.md` ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#246](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/246) Translate `guides/upgrading/index.md` ([@BlueCutOfficial])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@paoloricciuti]: https://github.com/paoloricciuti
-[DazzlingFugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
 [mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
 [paoloricciuti/optimistikit]: https://github.com/paoloricciuti/optimistikit
-[paoloricciuti/sveltekit-search-params]:
-  https://github.com/paoloricciuti/sveltekit-search-params
+[paoloricciuti/sveltekit-search-params]: https://github.com/paoloricciuti/sveltekit-search-params
 [sveltejs/kit]: https://github.com/sveltejs/kit
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-08-11.md b/src/twios/2024-08-11.md
index 107ec1f95b..0cb018487b 100644
--- a/src/twios/2024-08-11.md
+++ b/src/twios/2024-08-11.md
@@ -1,84 +1,47 @@
 ## Svelte
 
-- [mainmatter/sheepdog] [#142](https://github.com/mainmatter/sheepdog/pull/142)
-  docs: async transform explainer ([@paoloricciuti])
-- [paoloricciuti/optimistikit]
-  [#36](https://github.com/paoloricciuti/optimistikit/pull/36) fix: correct peer
-  dependencies ([@paoloricciuti])
-- [sveltejs/svelte] [#12763](https://github.com/sveltejs/svelte/pull/12763) fix:
-  order of arguments for `push_element` in `svelte:element` ([@paoloricciuti])
+- [mainmatter/sheepdog] [#142](https://github.com/mainmatter/sheepdog/pull/142) docs: async transform explainer ([@paoloricciuti])
+- [paoloricciuti/optimistikit] [#36](https://github.com/paoloricciuti/optimistikit/pull/36) fix: correct peer dependencies ([@paoloricciuti])
+- [sveltejs/svelte] [#12763](https://github.com/sveltejs/svelte/pull/12763) fix: order of arguments for `push_element` in `svelte:element` ([@paoloricciuti])
 
 ## Embroider
 
-- [embroider-build/app-blueprint]
-  [#50](https://github.com/embroider-build/app-blueprint/pull/50) add git ignore
-  for tmp file ([@mansona])
-- [embroider-build/embroider]
-  [#1936](https://github.com/embroider-build/embroider/pull/1936) remove
-  auto-upgraded from app package.json and add a basic exports block ([@mansona])
+- [embroider-build/app-blueprint] [#50](https://github.com/embroider-build/app-blueprint/pull/50) add git ignore for tmp file ([@mansona])
+- [embroider-build/embroider] [#1936](https://github.com/embroider-build/embroider/pull/1936) remove auto-upgraded from app package.json and add a basic exports block ([@mansona])
 
 ## Internal
 
-- [mainmatter/mainmatter-website-mailer]
-  [#38](https://github.com/mainmatter/mainmatter-website-mailer/pull/38) fix
-  handling of company name ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#37](https://github.com/mainmatter/mainmatter-website-mailer/pull/37) send
-  company name in sender name if present ([@marcoow])
-- [mainmatter/mainmatter-website-mailer]
-  [#36](https://github.com/mainmatter/mainmatter-website-mailer/pull/36) accept
-  optional company ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#38](https://github.com/mainmatter/mainmatter-website-mailer/pull/38) fix handling of company name ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#37](https://github.com/mainmatter/mainmatter-website-mailer/pull/37) send company name in sender name if present ([@marcoow])
+- [mainmatter/mainmatter-website-mailer] [#36](https://github.com/mainmatter/mainmatter-website-mailer/pull/36) accept optional company ([@marcoow])
 
 ## Ember
 
-- [DazzlingFugu/ember-fr-guides-source]
-  [#246](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/246)
-  Translate `guides/upgrading/index.md` ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#246](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/246) Translate `guides/upgrading/index.md` ([@BlueCutOfficial])
 
 ## Unknown
 
-- [mainmatter/auto-reveal]
-  [#33](https://github.com/mainmatter/auto-reveal/pull/33) Use relative base
-  root for Vite ([@pichfl])
-- [mainmatter/auto-reveal]
-  [#32](https://github.com/mainmatter/auto-reveal/pull/32) Add argument for
-  output directory ([@pichfl])
-- [mainmatter/auto-reveal]
-  [#29](https://github.com/mainmatter/auto-reveal/pull/29) Update dependencies
-  ([@pichfl])
-- [mainmatter/auto-reveal]
-  [#28](https://github.com/mainmatter/auto-reveal/pull/28) Internal: Add Lint
-  action ([@pichfl])
-- [mainmatter/auto-reveal]
-  [#25](https://github.com/mainmatter/auto-reveal/pull/25) Update README with
-  License and Copyright ([@pichfl])
-- [mainmatter/auto-reveal]
-  [#30](https://github.com/mainmatter/auto-reveal/pull/30) fix the trigger for
-  the lint CI job ([@mansona])
-- [mainmatter/auto-reveal]
-  [#18](https://github.com/mainmatter/auto-reveal/pull/18) update release-plan
-  ([@mansona])
-- [mainmatter/auto-reveal-theme-mainmatter]
-  [#8](https://github.com/mainmatter/auto-reveal-theme-mainmatter/pull/8) update
-  release-plan ([@mansona])
-- [web-and-wine/talks] [#229](https://github.com/web-and-wine/talks/pull/229)
-  Add Juli 2024 talks ([@pichfl])
+- [mainmatter/auto-reveal] [#33](https://github.com/mainmatter/auto-reveal/pull/33) Use relative base root for Vite ([@pichfl])
+- [mainmatter/auto-reveal] [#32](https://github.com/mainmatter/auto-reveal/pull/32) Add argument for output directory ([@pichfl])
+- [mainmatter/auto-reveal] [#29](https://github.com/mainmatter/auto-reveal/pull/29) Update dependencies ([@pichfl])
+- [mainmatter/auto-reveal] [#28](https://github.com/mainmatter/auto-reveal/pull/28) Internal: Add Lint action ([@pichfl])
+- [mainmatter/auto-reveal] [#25](https://github.com/mainmatter/auto-reveal/pull/25) Update README with License and Copyright ([@pichfl])
+- [mainmatter/auto-reveal] [#30](https://github.com/mainmatter/auto-reveal/pull/30) fix the trigger for the lint CI job ([@mansona])
+- [mainmatter/auto-reveal] [#18](https://github.com/mainmatter/auto-reveal/pull/18) update release-plan ([@mansona])
+- [mainmatter/auto-reveal-theme-mainmatter] [#8](https://github.com/mainmatter/auto-reveal-theme-mainmatter/pull/8) update release-plan ([@mansona])
+- [web-and-wine/talks] [#229](https://github.com/web-and-wine/talks/pull/229) Add Juli 2024 talks ([@pichfl])
 
 [@BlueCutOfficial]: https://github.com/BlueCutOfficial
 [@mansona]: https://github.com/mansona
 [@marcoow]: https://github.com/marcoow
 [@paoloricciuti]: https://github.com/paoloricciuti
 [@pichfl]: https://github.com/pichfl
-[DazzlingFugu/ember-fr-guides-source]:
-  https://github.com/DazzlingFugu/ember-fr-guides-source
-[embroider-build/app-blueprint]:
-  https://github.com/embroider-build/app-blueprint
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
 [embroider-build/embroider]: https://github.com/embroider-build/embroider
-[mainmatter/auto-reveal-theme-mainmatter]:
-  https://github.com/mainmatter/auto-reveal-theme-mainmatter
+[mainmatter/auto-reveal-theme-mainmatter]: https://github.com/mainmatter/auto-reveal-theme-mainmatter
 [mainmatter/auto-reveal]: https://github.com/mainmatter/auto-reveal
-[mainmatter/mainmatter-website-mailer]:
-  https://github.com/mainmatter/mainmatter-website-mailer
+[mainmatter/mainmatter-website-mailer]: https://github.com/mainmatter/mainmatter-website-mailer
 [mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
 [paoloricciuti/optimistikit]: https://github.com/paoloricciuti/optimistikit
 [sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-09-01.md b/src/twios/2024-09-01.md
new file mode 100644
index 0000000000..40a3af8560
--- /dev/null
+++ b/src/twios/2024-09-01.md
@@ -0,0 +1,24 @@
+## Svelte
+
+- [mainmatter/sheepdog] [#167](https://github.com/mainmatter/sheepdog/pull/167) update gravity cli to v0.0.2 ([@oscard0m])
+
+## Embroider
+
+- [embroider-build/app-blueprint] [#57](https://github.com/embroider-build/app-blueprint/pull/57) add fixes for new test structure ([@mansona])
+- [embroider-build/embroider] [#2089](https://github.com/embroider-build/embroider/pull/2089) add required fixes to keep-app-dir PR ([@mansona])
+- [embroider-build/embroider] [#2079](https://github.com/embroider-build/embroider/pull/2079) add test fixes for no-test-entrypoint branch ([@mansona])
+
+## Ember
+
+- [DazzlingFugu/ember-fr-guides-source] [#250](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/250) Translate `guides/components/looping-through-lists.md` ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#249](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/249) Translate `guides/components/components-arguments-and-html-attributes.md` ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#248](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/248) Translate `guides/code-editors/index.md` ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#247](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/247) Translate `guides/applications/run-loop.md` ([@BlueCutOfficial])
+
+[@BlueCutOfficial]: https://github.com/BlueCutOfficial
+[@mansona]: https://github.com/mansona
+[@oscard0m]: https://github.com/oscard0m
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
+[embroider-build/embroider]: https://github.com/embroider-build/embroider
+[mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
diff --git a/src/twios/2024-09-08.md b/src/twios/2024-09-08.md
new file mode 100644
index 0000000000..99d6acb73b
--- /dev/null
+++ b/src/twios/2024-09-08.md
@@ -0,0 +1,28 @@
+## Svelte
+
+- [mainmatter/sheepdog] [#171](https://github.com/mainmatter/sheepdog/pull/171) chore: prepare script + renovate config ([@paoloricciuti])
+- [mainmatter/sheepdog] [#156](https://github.com/mainmatter/sheepdog/pull/156) docs: start building the reference docs ([@paoloricciuti])
+- [sveltejs/svelte] [#13151](https://github.com/sveltejs/svelte/pull/13151) fix: visit expression for `svelte:component` references ([@paoloricciuti])
+- [sveltejs/svelte] [#13113](https://github.com/sveltejs/svelte/pull/13113) fix: remove unnecessary update assignments ([@paoloricciuti])
+- [sveltejs/svelte] [#13097](https://github.com/sveltejs/svelte/pull/13097) fix: error on duplicate style and class directive ([@paoloricciuti])
+- [sveltejs/svelte] [#13082](https://github.com/sveltejs/svelte/pull/13082) fix: hoist imports on top ([@paoloricciuti])
+
+## Embroider
+
+- [embroider-build/app-blueprint] [#65](https://github.com/embroider-build/app-blueprint/pull/65) update to work without app rewriting ([@mansona])
+- [embroider-build/app-blueprint] [#62](https://github.com/embroider-build/app-blueprint/pull/62) move the index.html into the root of the blueprint ([@mansona])
+- [embroider-build/embroider] [#2089](https://github.com/embroider-build/embroider/pull/2089) add required fixes to keep-app-dir PR ([@mansona])
+
+## Ember
+
+- [DazzlingFugu/ember-fr-guides-source] [#252](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/252) Translate `guides/components/index.md` ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#244](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/244) Translate `guides/tutorial/part-2/route-params` ([@BlueCutOfficial])
+
+[@BlueCutOfficial]: https://github.com/BlueCutOfficial
+[@mansona]: https://github.com/mansona
+[@paoloricciuti]: https://github.com/paoloricciuti
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
+[embroider-build/embroider]: https://github.com/embroider-build/embroider
+[mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
+[sveltejs/svelte]: https://github.com/sveltejs/svelte
diff --git a/src/twios/2024-10-06.md b/src/twios/2024-10-06.md
new file mode 100644
index 0000000000..e50350775a
--- /dev/null
+++ b/src/twios/2024-10-06.md
@@ -0,0 +1,101 @@
+## Rust
+
+- [mainmatter/100-exercises-to-learn-rust] [#159](https://github.com/mainmatter/100-exercises-to-learn-rust/pull/159) simplify ebook styling ([@marcoow])
+- [mainmatter/gerust] [#99](https://github.com/mainmatter/gerust/pull/99) rename pacesetter to gerust ([@marcoow])
+- [mainmatter/gerust] [#49](https://github.com/mainmatter/gerust/pull/49) Add code docs ([@marcoow])
+
+## Svelte
+
+- [animotionjs/animotion] [#44](https://github.com/animotionjs/animotion/pull/44) fix: import `defineProps` separately to allow import in module ([@paoloricciuti])
+- [mainmatter/sheepdog] [#184](https://github.com/mainmatter/sheepdog/pull/184) Landing page demo integration ([@nickschot])
+- [mainmatter/sheepdog] [#158](https://github.com/mainmatter/sheepdog/pull/158) docs: add task modifier explainer ([@paoloricciuti])
+- [sveltejs/kit] [#12749](https://github.com/sveltejs/kit/pull/12749) feat: pass filename to `migrate` ([@paoloricciuti])
+- [sveltejs/svelte] [#13504](https://github.com/sveltejs/svelte/pull/13504) feat: migrate `svelte:self` ([@paoloricciuti])
+- [sveltejs/svelte] [#13484](https://github.com/sveltejs/svelte/pull/13484) fix: migrate `$$Props` without creating non existent props ([@paoloricciuti])
+- [sveltejs/svelte] [#13480](https://github.com/sveltejs/svelte/pull/13480) fix: move labeled statements that need reordering after props insertion point ([@paoloricciuti])
+- [sveltejs/svelte] [#13479](https://github.com/sveltejs/svelte/pull/13479) feat: support migration of self closing tags ([@paoloricciuti])
+- [sveltejs/svelte] [#13473](https://github.com/sveltejs/svelte/pull/13473) fix: various `svelte:component` migration bugs ([@paoloricciuti])
+- [sveltejs/svelte] [#13468](https://github.com/sveltejs/svelte/pull/13468) fix: correctly migrate `$$slots` with bracket member expressions & slots with static props ([@paoloricciuti])
+- [sveltejs/svelte] [#13461](https://github.com/sveltejs/svelte/pull/13461) feat: support migration of single assignment labeled statements ([@paoloricciuti])
+- [sveltejs/svelte] [#13456](https://github.com/sveltejs/svelte/pull/13456) feat: fix accessors and support migration of accessors ([@paoloricciuti])
+- [sveltejs/svelte] [#13437](https://github.com/sveltejs/svelte/pull/13437) feat: support migration of `svelte:component` ([@paoloricciuti])
+- [sveltejs/svelte] [#13424](https://github.com/sveltejs/svelte/pull/13424) chore: refactor migration composition logic ([@paoloricciuti])
+
+## Embroider
+
+- [embroider-build/app-blueprint] [#96](https://github.com/embroider-build/app-blueprint/pull/96) fix all @embroider/virtual renames ([@mansona])
+
+## Lint to the future
+
+- [mansona/lint-to-the-future] [#44](https://github.com/mansona/lint-to-the-future/pull/44) add lttf alias ([@mansona])
+- [mansona/lint-to-the-future] [#43](https://github.com/mansona/lint-to-the-future/pull/43) Add prettier setup ([@mansona])
+- [mansona/lint-to-the-future] [#41](https://github.com/mansona/lint-to-the-future/pull/41) move output command test to its own file ([@mansona])
+- [mansona/lint-to-the-future] [#40](https://github.com/mansona/lint-to-the-future/pull/40) setup release-plan ([@mansona])
+- [mansona/lint-to-the-future] [#39](https://github.com/mansona/lint-to-the-future/pull/39) switch to pnpm ([@mansona])
+- [mansona/lint-to-the-future] [#48](https://github.com/mansona/lint-to-the-future/pull/48) Accept rule names with colon. ([@Mikek2252])
+- [mansona/lint-to-the-future] [#47](https://github.com/mansona/lint-to-the-future/pull/47) Hide completed rules ([@Mikek2252])
+- [mansona/lint-to-the-future] [#45](https://github.com/mansona/lint-to-the-future/pull/45) Upgrade LTTF Dashboard app to ember 5 ([@Mikek2252])
+- [mansona/lint-to-the-future] [#36](https://github.com/mansona/lint-to-the-future/pull/36) Add remove command to lint-to-the-future ([@Mikek2252])
+- [mansona/lint-to-the-future-eslint] [#30](https://github.com/mansona/lint-to-the-future-eslint/pull/30) Support shebang files ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#28](https://github.com/mansona/lint-to-the-future-eslint/pull/28) use the right name for filter ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#26](https://github.com/mansona/lint-to-the-future-eslint/pull/26) remove npmrc ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#24](https://github.com/mansona/lint-to-the-future-eslint/pull/24) use release-plan ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#23](https://github.com/mansona/lint-to-the-future-eslint/pull/23) move list test to fixturify-project ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#22](https://github.com/mansona/lint-to-the-future-eslint/pull/22) swap to eslint recommended ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#21](https://github.com/mansona/lint-to-the-future-eslint/pull/21) add remove api ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#20](https://github.com/mansona/lint-to-the-future-eslint/pull/20) swap to fixturify project ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#19](https://github.com/mansona/lint-to-the-future-eslint/pull/19) add prettier ([@mansona])
+- [mansona/lint-to-the-future-eslint] [#18](https://github.com/mansona/lint-to-the-future-eslint/pull/18) swap to pnpm ([@mansona])
+
+## JavaScript
+
+- [formatjs/formatjs] [#4543](https://github.com/formatjs/formatjs/pull/4543) Fix(@formatjs/cli-lib): add newline to compiled file, fix #4539 ([@BlueCutOfficial])
+- [vitejs/vite] [#18269](https://github.com/vitejs/vite/pull/18269) docs: add Ember logo to the frameworks ([@mansona])
+
+## Octokit
+
+- [octokit/action.js] [#648](https://github.com/octokit/action.js/pull/648) build: switch to vitest ([@oscard0m])
+- [octokit/auth-app.js] [#648](https://github.com/octokit/auth-app.js/pull/648) build: switch to vitest and fetch-mock v11 ([@oscard0m])
+- [octokit/plugin-create-or-update-text-file.js] [#293](https://github.com/octokit/plugin-create-or-update-text-file.js/pull/293) build: switch to vitest ([@oscard0m])
+
+## Ember
+
+- [DazzlingFugu/ember-fr-guides-source] [#276](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/276) Automatic catch up from 5.4 to 5.11 ([@BlueCutOfficial])
+- [DazzlingFugu/ember-fr-guides-source] [#253](https://github.com/DazzlingFugu/ember-fr-guides-source/pull/253) New nicer version of the catchup script ([@BlueCutOfficial])
+- [adopted-ember-addons/ember-paper] [#1255](https://github.com/adopted-ember-addons/ember-paper/pull/1255) update lint-to-the-future ([@mansona])
+- [adopted-ember-addons/ember-paper] [#1253](https://github.com/adopted-ember-addons/ember-paper/pull/1253) update lttf dashbaord ([@mansona])
+- [adopted-ember-addons/ember-paper] [#1252](https://github.com/adopted-ember-addons/ember-paper/pull/1252) run ember-component-template-colocation-migrator ([@mansona])
+- [adopted-ember-addons/ember-paper] [#1250](https://github.com/adopted-ember-addons/ember-paper/pull/1250) Re-enable the Prettier eslint plugin ([@mansona])
+- [ember-codemods/tagless-ember-components-codemod] [#199](https://github.com/ember-codemods/tagless-ember-components-codemod/pull/199) start using release-plan ([@mansona])
+- [ember-codemods/tagless-ember-components-codemod] [#198](https://github.com/ember-codemods/tagless-ember-components-codemod/pull/198) add basic support for mixins on native classes ([@mansona])
+- [ember-codemods/tagless-ember-components-codemod] [#197](https://github.com/ember-codemods/tagless-ember-components-codemod/pull/197) swap to pnpm ([@mansona])
+- [ember-codemods/tagless-ember-components-codemod] [#196](https://github.com/ember-codemods/tagless-ember-components-codemod/pull/196) drop support for node < 18 ([@mansona])
+- [zeppelin/ember-click-outside] [#268](https://github.com/zeppelin/ember-click-outside/pull/268) Fix package description ([@zeppelin])
+- [zeppelin/ember-click-outside] [#267](https://github.com/zeppelin/ember-click-outside/pull/267) Remove usage of deprecated `action` helper in tests ([@zeppelin])
+
+[@BlueCutOfficial]: https://github.com/BlueCutOfficial
+[@Mikek2252]: https://github.com/Mikek2252
+[@mansona]: https://github.com/mansona
+[@marcoow]: https://github.com/marcoow
+[@nickschot]: https://github.com/nickschot
+[@oscard0m]: https://github.com/oscard0m
+[@paoloricciuti]: https://github.com/paoloricciuti
+[@zeppelin]: https://github.com/zeppelin
+[DazzlingFugu/ember-fr-guides-source]: https://github.com/DazzlingFugu/ember-fr-guides-source
+[adopted-ember-addons/ember-paper]: https://github.com/adopted-ember-addons/ember-paper
+[animotionjs/animotion]: https://github.com/animotionjs/animotion
+[ember-codemods/tagless-ember-components-codemod]: https://github.com/ember-codemods/tagless-ember-components-codemod
+[embroider-build/app-blueprint]: https://github.com/embroider-build/app-blueprint
+[formatjs/formatjs]: https://github.com/formatjs/formatjs
+[mainmatter/100-exercises-to-learn-rust]: https://github.com/mainmatter/100-exercises-to-learn-rust
+[mainmatter/gerust]: https://github.com/mainmatter/gerust
+[mainmatter/sheepdog]: https://github.com/mainmatter/sheepdog
+[mansona/lint-to-the-future-eslint]: https://github.com/mansona/lint-to-the-future-eslint
+[mansona/lint-to-the-future]: https://github.com/mansona/lint-to-the-future
+[octokit/action.js]: https://github.com/octokit/action.js
+[octokit/auth-app.js]: https://github.com/octokit/auth-app.js
+[octokit/plugin-create-or-update-text-file.js]: https://github.com/octokit/plugin-create-or-update-text-file.js
+[sveltejs/kit]: https://github.com/sveltejs/kit
+[sveltejs/svelte]: https://github.com/sveltejs/svelte
+[vitejs/vite]: https://github.com/vitejs/vite
+[zeppelin/ember-click-outside]: https://github.com/zeppelin/ember-click-outside
diff --git a/src/web-based-services-in-rust-workshop.njk b/src/web-based-services-in-rust-workshop.njk
deleted file mode 100644
index 9abb532569..0000000000
--- a/src/web-based-services-in-rust-workshop.njk
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: "Workshop: Web-based Services in Rust"
-description: "Three half-days workshop with Stefan Baumgartner that teaches developing web applications and web services in Rust."
-layout: false
-og:
-  image: /assets/images/web-based-services-in-rust-workshop/og-image.jpg
----
-
-{% from "author-socials.njk" import authorSocials %}
-{% from "image-aspect-ratio.njk" import imageAspectRatio %}
-{% from "scroll-slides.njk" import scrollSlides %}
-{% from "quote.njk" import quote %}
-{% from "color-hero.njk" import colorHero %}
-{% from "strategy-list.njk" import strategyList %}
-{% from "cta-banner.njk" import ctaBanner %}
-{% from "btn-tito.njk" import btnTito %}
-
-<html lang="{{ config.lang }}" prefix="og: http://ogp.me/ns#">
-  <head>
-    <meta charset="UTF-8" />
-    <meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
-
-    <title>{{ title }}</title>
-    {% include "global/fonts.njk" %}
-    <link rel="stylesheet" href="/assets/css/app.css" />
-    <link rel="stylesheet" href="/assets/css/workshop-lp.css" />
-    <script src="/assets/js/app.js" defer></script>
-    {% block head %}{{ head | safe }}{% endblock %}
-    {% include "global/meta.njk" %}
-    {% include "global/icons.njk" %}
-
-    <script src="https://js.tito.io/v2/" async></script>
-    <script
-      defer
-      data-domain="rust-web-services-workshop.mainmatter.com"
-      src="https://plausible.io/js/script.tagged-events.outbound-links.js"
-    ></script>
-    <script>
-      window.plausible =
-        window.plausible ||
-        function () {
-          (window.plausible.q = window.plausible.q || []).push(arguments);
-        };
-    </script>
-  </head>
-  <body data-js-enabled="false">
-    <a class="skip-link" href="#main"> Skip to main content </a>
-
-    <nav class="nav nav--accent-aqua" id="nav">
-      <div class="nav__wrapper container container--xl">
-        <div class="nav__logo">
-          <h1 class="nav__brand">
-            {% include 'svg/logo.njk' %}
-            <span class="screenreader">Mainmatter</span>
-          </h1>
-        </div>
-        <div class="nav__aside"></div>
-      </div>
-    </nav>
-
-    <main id="main">
-      {%
-        set 'hero' = {
-        "eyebrow": 'Remote Workshop',
-        "title": 'Web-based Services in Rust',
-        "text": '<div>11.-13. (14:00 - 18:00 CEST) July 2023</div>
-        <div>11.-13. (14:00 - 18:00 CEST) July 2023
-        </div>'
-        }
-      %}
-      {{ colorHero('purple', hero) }}
-      {%
-        set 'content' = {
-        "title": "This workshop has already taken place",
-        "text": "Take a look at our wide range of workshops to take your team to the next level",
-        "linkUrl": "/services/workshops/",
-        "linkText": "Our workshops"
-        }
-      %}
-      {{ ctaBanner('aqua', 'default', content) }}
-      {%
-        set 'content' = {
-        "title": "Grow your business with us",
-        "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
-        "linkUrl": "/contact",
-        "linkText": "Get in touch"
-        }
-      %}
-      {{ ctaBanner('purple', 'full', content) }}
-    </main>
-    {% include "global/footer.njk" %}
-    <div aria-live="polite" id="live-region" class="screenreader"></div>
-    <div hidden>
-      <p id="external-new-window-message">Opens external website in a new window.</p>
-    </div>
-    <script>
-      document.querySelector("body").setAttribute("data-js-enabled", "true");
-    </script>
-  </body>
-</html>
diff --git a/src/work.njk b/src/work.njk
index 2a31133ccb..3c92137118 100644
--- a/src/work.njk
+++ b/src/work.njk
@@ -1,12 +1,14 @@
 ---
 layout: "base"
 title: Our Work
-description: A proven track record of building mobile and web apps for Europe's fastest growing start-ups and big enterprises – covering everything from design to code.
+description: Mainmatter has a proven track record of solving the toughest tech challenges of Europe's fastest growing start-ups and big enterprises.
 eleventyNavigation:
   key: Work
   order: 20
 eleventyImport:
   collections: ["caseStudies", "caseStudiesFeatured"]
+og:
+  image: "/assets/images/work/og-image.jpg"
 ---
 
 {% from "color-hero.njk" import colorHero %}
@@ -58,7 +60,7 @@ eleventyImport:
 
 {%
   set 'content' = {
-  "title": "Grow your business with us",
+  "title": "Team up with us to go further!",
   "text": "Our experts are ready to guide you through your next big move. Let us know how we can help.",
   "linkUrl": "/contact",
   "linkText": "Get in touch"
diff --git a/src/workshops/a-taste-of-rust.md b/src/workshops/a-taste-of-rust.md
deleted file mode 100644
index 5a4f1b296b..0000000000
--- a/src/workshops/a-taste-of-rust.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: "A taste of Rust"
-tags: "rust"
-format: "Workshop: 1 day"
-subtext: "Bookable for teams – on-site or remote"
-description: |
-  <p>Rust has been the most loved programming language on StackOverflow for 7 years in a row. What's it all about?</p>
-  <p>Join this workshop to get a taste of Rust! We'll cover the core concepts of the language: structs, enums, traits, 
-  testing, key data structures.</p>
-  <p>The workshop is organised as a series of exercises. You'll be learning by
-  doing! Each concept will be introduced with a short presentation, followed
-  by a hands-on exercise with tests to make sure you've wrapped your head
-  around it.<br>
-  By the end of the workshop, you'll have built a small command-line
-  application in Rust: a simple JIRA clone that can be used to manage a
-  backlog of tasks.</p>
-  <p>The workshop is designed for developers who have experience using other programming languages 
-  and are just getting started with Rust.</p>
-hero:
-  color: purple
-  image: "/assets/images/workshops/an-introduction-to-testing-in-rust/header-background.jpg"
-  imageAlt: "A drawing of a giant crab standing in a village."
-
-og:
-  image: /assets/images/workshops/a-taste-of-rust/a-taste-of-rust-og-image.jpeg
-topics:
-  - title: Structs
-    text: >
-      Structs are the building blocks of Rust programs. We'll cover how to
-      define structs, how to implement methods on them, and how to manage their
-       visibility across modules.
-  - title: Enums
-    text: >
-      Rust's enums are extremely powerful: each variant can have its own data!
-      They're an excellent tool for modelling state machines, such as our tasks.
-       We'll cover how to define enums, how to implement methods on them,  and
-      how to leverage pattern matching when working with them.
-  - title: Ownership
-    text: >
-      Ownership is Rust's most distinctive feature. It's what makes Rust code
-      safe and performant. We'll cover how ownership works, how it impacts the
-      way we write code, and how to leverage it to avoid unnecessary memory
-      allocations.
-  - title: Traits
-    text: >
-      Traits are Rust's way of defining interfaces. We'll cover how to define
-      traits, how to implement them for structs and enums, and how to use traits
-      to write generic code. We'll also cover common traits from the standard
-      library (e.g. `Debug`, `Display`, `Clone`, `PartialEq`) and how to derive
-      them automatically.
-  - title: Data structures
-    text: >
-      The Rust standard library provides a few key data structures that are used
-      everywhere. We'll zoom in on `Vec` and `HashMap` as our reference
-      examples. We'll review where they fit and how to leverage them in our
-      code.
-  - title: CLI applications
-    text: >
-      As a capstone exercise, we'll build a small command-line application to
-      expose our task management functionality.  
-      You'll learn how to parse command-line arguments and the difference
-      between library and binary crates.
-leads:
-  - name: Luca Palmieri
-    title: Principal Engineering Consultant
-    handle: algo_luca
-    image: /assets/images/authors/algo_luca.jpg
-    bio: >
-      Luca Palmieri builds technology products for a living. His current focus
-      is on backend development,  software architecture and the Rust programming
-      language. He is the author of "Zero to Production in Rust".
----
-
-<!--break-->
diff --git a/src/workshops/advanced-testing-in-rust.md b/src/workshops/advanced-testing-in-rust.md
index 012fda07d2..78e148d5fc 100644
--- a/src/workshops/advanced-testing-in-rust.md
+++ b/src/workshops/advanced-testing-in-rust.md
@@ -3,86 +3,68 @@ title: "Testing in Rust: going beyond the basics"
 tags: "rust"
 format: "Workshop: 1 day"
 subtext: "Bookable for teams – on-site or remote"
-description: |
+description: A 1-day workshop designed for software developers who have a good understanding of Rust's basic concepts and want to move beyond the built-in testing toolkit.
+introduction: |
   <p>No application is an island: you need to interact with third-party APIs, databases and who knows what else. 
   Testing those interactions is tricky, to say the least! 
   This workshop will focus on expanding your Rust testing toolkit, going beyond the basic techniques 
   you're already familiar with. At the end of the session, you'll have a strategy to test most of the scenarios 
   that are relevant for a complex Rust application.</p>
   <p>The workshop is designed for software developers who have a good understanding of Rust's basic
-  concepts and want to move beyond the built-in testing toolkit. <br>
-  If you are new to Rust instead, you might be interested instead in our 
+  concepts and want to move beyond the built-in testing toolkit.</p>
+  <p>If you are new to Rust instead, you might be interested instead in our 
   <a href="/services/workshops/an-introduction-to-testing-in-rust/">introductory testing workshop</a>.</p>
 hero:
   color: purple
   image: "/assets/images/workshops/advanced-testing-in-rust/header-background.jpg"
-  imageAlt:
-    "A schematic drawing of a grid with files on top and connecting lines
-    between the files."
+  imageAlt: "A schematic drawing of a grid with files on top and connecting lines between the files."
 og:
   image: /assets/images/workshops/advanced-testing-in-rust/og-image.jpg
 topics:
   - title: "Expanding your toolbox: better assertions"
     text: >
-      The Rust standard library provides a few macros to perform assertions in
-      your tests: <code>assert!</code>, <code>assert_eq!</code>, etc. They are
-      good enough to get started, but the error messages they produce will often
-      fail to keep up with the complexity of your assertions: we'll explore
-      different libraries to boost the clarity of your test failures.
+      The Rust standard library provides a few macros to perform assertions in your tests: <code>assert!</code>, <code>assert_eq!</code>, etc. They are good enough to get started, but the error messages they produce will often fail to keep up with the complexity of your assertions: we'll explore different libraries to boost the clarity of your test failures.
+
+
   - title: "Expanding your toolbox: snapshot testing"
     text: >
-      Snapshot testing is a technique that allows us to capture the output of a
-      system under test and compare it with a previously saved version. It is
-      quite useful when working with complex data that might change frequently,
-      such as HTML or error messages. We will explore how to use the
-      <code>insta</code> crate to implement snapshot testing and manage the
-      snapshots lifecycle.
+      Snapshot testing is a technique that allows us to capture the output of a system under test and compare it with a previously saved version. It is quite useful when working with complex data that might change frequently, such as HTML or error messages. We will explore how to use the <code>insta</code> crate to implement snapshot testing and manage the snapshots lifecycle.
+
+
   - title: "Isolating your tests: the filesystem"
     text: >
-      All tests in Rust share the same filesystem as the underlying host, a
-      problematic situation when multiple tests want to interact with the "same"
-      files or touch directories that could affect the behaviour of the system
-      they are being executed from.  We will explore various techniques to
-      manage this scenario, including the  <code>tempfile</code> crate.
+      All tests in Rust share the same filesystem as the underlying host, a problematic situation when multiple tests want to interact with the "same" files or touch directories that could affect the behaviour of the system they are being executed from.  We will explore various techniques to manage this scenario, including the  <code>tempfile</code> crate.
+
+
   - title: "Isolating your tests: the database"
     text: >
-      The database is another shared resource that can cause problems when
-      running tests in parallel. We will explore how to use Docker to run an
-      isolated database instance for each test, and how to use the
-      <code>sqlx</code> crate to manage the database lifecycle.
+      The database is another shared resource that can cause problems when running tests in parallel. We will explore how to use Docker to run an isolated database instance for each test, and how to use the <code>sqlx</code> crate to manage the database lifecycle.
+
+
   - title: "Isolating your tests: HTTP mocking"
     text: >
-      It is undesirable to have tests that hit real HTTP endpoints from
-      third-party APIs, for a variety of reasons. We will explore how to use the
-      <code>wiremock</code> crate to shield our tests from the outside world and
-      make assertions on the HTTP requests that are being sent.
+      It is undesirable to have tests that hit real HTTP endpoints from third-party APIs, for a variety of reasons. We will explore how to use the <code>wiremock</code> crate to shield our tests from the outside world and make assertions on the HTTP requests that are being sent.
+
+
   - title: "Isolating your tests: mocks, stubs and fakes"
     text: >
-      In order to isolate the behaviour of a system under test, it is not
-      unusual to replace some of its dependencies with "fake" implementations.
-      We will explore the different types of fakes and how to use them in Rust.
-      We will review, in particular, the <code>mockall</code> crate and the
-      testing implications of using generics and dynamic dispatch for
-      polymorphism.
+      In order to isolate the behaviour of a system under test, it is not unusual to replace some of its dependencies with "fake" implementations. We will explore the different types of fakes and how to use them in Rust. We will review, in particular, the <code>mockall</code> crate and the testing implications of using generics and dynamic dispatch for polymorphism.
+
+
   - title: "Custom test runners: what is a test?"
     text: >
-      We will take a look under the hood to understand how the Rust built-in
-      testing framework works. Armed with this knowledge, we will explore the
-      runtime implications of different approaches for test organisation. We
-      will also cover alternative test  runners, such as
-      <code>cargo-nextest</code>.
+      We will take a look under the hood to understand how the Rust built-in testing framework works. Armed with this knowledge, we will explore the runtime implications of different approaches for test organisation. We will also cover alternative test  runners, such as <code>cargo-nextest</code>.
+
+
   - title: "Custom test runners: executing logic before and after a test run"
     text: >
-      It is often desirable to execute the same logic before and after each test
-      in our suite. We will explore a variety of techniques to achieve this,
-      from a bespoke <code>#[test_case]</code> procedural macro to a custom test
-      harness (via <code>libtest_mimic</code>).
+      It is often desirable to execute the same logic before and after each test in our suite. We will explore a variety of techniques to achieve this, from a bespoke <code>#[test_case]</code> procedural macro to a custom test harness (via <code>libtest_mimic</code>).
+
+
   - title: "Custom test runners: capstone project"
     text: >
-      We will combine everything we have learned so far into an easy-to-use
-      setup that allows you to run black-box tests against a real database and a
-      real HTTP server, without having to orchestrate multiple commands—just
-      <code>cargo test</code> and you are good to go!
+      We will combine everything we have learned so far into an easy-to-use setup that allows you to run black-box tests against a real database and a real HTTP server, without having to orchestrate multiple commands—just <code>cargo test</code> and you are good to go!
+
 
 leads:
   - name: Luca Palmieri
@@ -90,9 +72,7 @@ leads:
     handle: algo_luca
     image: /assets/images/authors/algo_luca.jpg
     bio: >
-      Luca Palmieri builds technology products for a living. His current focus
-      is on backend development,  software architecture and the Rust programming
-      language. He is the author of "Zero to Production in Rust".
+      Luca Palmieri builds technology products for a living. His current focus is on backend development,  software architecture and the Rust programming language. He is the author of "Zero to Production in Rust".
 ---
 
 <!--break-->
diff --git a/src/workshops/an-introduction-to-testing-in-rust.md b/src/workshops/an-introduction-to-testing-in-rust.md
index aee9bab0cb..564c348e13 100644
--- a/src/workshops/an-introduction-to-testing-in-rust.md
+++ b/src/workshops/an-introduction-to-testing-in-rust.md
@@ -3,15 +3,16 @@ title: "Testing in Rust: an introduction"
 tags: "rust"
 format: "Workshop: 4 hours"
 subtext: "Bookable for teams – on-site or remote"
-description: |
+description: This half-day workshop will build up your Rust's testing toolkit. We will start from scratch, with your first unit test. By the end, you will have a comprehensive understanding of the available test types, the best practices in terms of test organization as well as their runtime implications.
+introduction: |
   <p>Rust's type system is great, but it's not enough on its own to ensure correctness: 
   a solid testing strategy is a requirement for any serious Rust application.</p>
   <p>The workshop will build up your Rust's testing toolkit. We will start from scratch, with your first
   unit test. By the end, you will have a comprehensive understanding of the available 
   test types, the best practices in terms of test organization as well as their runtime implications.
   You will be well equipped for the testing challenges ahead of you!</p>
-  <p>The workshop is designed for software developers who are just starting their Rust journey. <br>
-  If you've been working with Rust for a while, you might be interested instead in our 
+  <p>The workshop is designed for software developers who are just starting their Rust journey.</p>
+  <p>If you've been working with Rust for a while, you might be interested instead in our 
   <a href="/services/workshops/advanced-testing-in-rust/">advanced testing workshop</a>.</p>
 hero:
   color: purple
@@ -23,49 +24,44 @@ og:
 topics:
   - title: Writing your first unit test
     text: >
-      Straight into the action: the <code>#[test]</code> annotation and  basic
-      assertions!  
+      Straight into the action: the <code>#[test]</code> annotation and  basic assertions!  
       We will wire everything up and get our feedback loop going.
+
+
   - title: Testing failures
     text: >
       Unhappy scenarios are often more important than the happy ones!  
-      We will discuss the <code>#[should_panic]</code> annotation as well
-      as  the tradeoffs of returning a <code>Result</code> from your tests.
+      We will discuss the <code>#[should_panic]</code> annotation as well as  the tradeoffs of returning a <code>Result</code> from your tests.
+
+
   - title: The Rust testing zoo
     text: >
-      Unit tests are just of the test approaches offered by Rust's built-in
-      testing framework—we have integration and doc tests too.  
-      We will look at each category and build a mental framework for
-      choosing  the correct testing technique in each context.
+      Unit tests are just of the test approaches offered by Rust's built-in testing framework—we have integration and doc tests too.  
+      We will look at each category and build a mental framework for choosing  the correct testing technique in each context.
+
+
   - title: Running your tests
     text: >
-      What is a test?  We will take a look under the hood to understand how the
-      Rust built-in testing framework is actually implemented. Armed with this
-      knowledge, we will explore the runtime implications of different
-      approaches for test organisation. We will also cover alternative
-      test  runners, such as <code>cargo-nextest</code>.
+      What is a test?  We will take a look under the hood to understand how the Rust built-in testing framework is actually implemented. Armed with this knowledge, we will explore the runtime implications of different approaches for test organisation. We will also cover alternative test  runners, such as <code>cargo-nextest</code>.
+
+
   - title: "Test helpers: where do they go?"
     text: >
-      Test code is just as important as production code: you want it to be terse
-      and clearly communicate what is being tested. If you follow this
-      philosophy, you'll soon be trying to extract common logic into test
-      helpers: where should they be located? We will cover the different
-      strategies available (test modules, feature gate, helper crate) and their
-      trade-offs.
+      Test code is just as important as production code: you want it to be terse and clearly communicate what is being tested. If you follow this philosophy, you'll soon be trying to extract common logic into test helpers: where should they be located? We will cover the different strategies available (test modules, feature gate, helper crate) and their trade-offs.
+
+
   - title: Beyond assertions
     text: >
-      In closing, we will have a look at a few advanced techniques beyond
-      the  standard toolkit: snapshot testing (<code>insta</code>) and
-      property-based testing (<code>quickcheck</code>).
+      In closing, we will have a look at a few advanced techniques beyond the  standard toolkit: snapshot testing (<code>insta</code>) and property-based testing (<code>quickcheck</code>).
+
+
 leads:
   - name: Luca Palmieri
     title: Principal Engineering Consultant
     handle: algo_luca
     image: /assets/images/authors/algo_luca.jpg
     bio: >
-      Luca Palmieri builds technology products for a living. His current focus
-      is on backend development,  software architecture and the Rust programming
-      language. He is the author of "Zero to Production in Rust".
+      Luca Palmieri builds technology products for a living. His current focus is on backend development,  software architecture and the Rust programming language. He is the author of "Zero to Production in Rust".
 ---
 
 <!--break-->
diff --git a/src/workshops/authentication-for-svelte-sveltekit.md b/src/workshops/authentication-for-svelte-sveltekit.md
new file mode 100644
index 0000000000..4c5d9cf0af
--- /dev/null
+++ b/src/workshops/authentication-for-svelte-sveltekit.md
@@ -0,0 +1,49 @@
+---
+title: "Authentication for Svelte & SvelteKit"
+tags: "svelte"
+format: "Workshop: 1 day"
+subtext: "Bookable for teams – on-site or remote"
+description: In this 1-day workshop, we cover everything one needs to know to implement authentication in Svelte and SvelteKit so that it's functional, secure, and maintainable.
+introduction: "<p>Most real-world applications provide some means for users to authenticate – either to get access to the application at all, or to get access to specific functionality or data within the application. Since authentication is a critical topic though, it's important to get it right. In this workshop, we cover everything one needs to know to implement authentication in Svelte and SvelteKit so that it's functional, secure, and maintainable.</p>"
+hero:
+  color: aqua
+  image: "/assets/images/workshops/authentication-for-svelte-sveltekit/lock.jpg"
+  imageAlt: "Close-up photo of a lock attached to a metal fence"
+og:
+  image: /assets/images/workshops/authentication-for-svelte-sveltekit/og-image.jpg
+topics:
+  - title: The Basics of Authentication
+    text: >
+      We'll start with a bit of theory, looking into what authentication is, what the options are to implement authentication in web apps and what the relevant security aspects are to keep in mind.
+
+
+  - title: The Demo Project
+    text: >
+      We continue by setting up a demo project we'll be using throughout the workshop to set up a full authentication system.
+
+
+  - title: Username & Password
+    text: >
+      We'll build basic authentiation via a username and password first as a simple and straight forward means for users to login.
+
+
+  - title: OAuth
+    text: >
+      Next, we'll move to OAuth, which most real-world applications are likely to use. We'll look into the theory behind the approach and implement authentication via an OAuth provider in the demo project.
+
+
+  - title: Application Concerns
+    text: >
+      We end by looking into application concerns around authentication like deciding whether a user is currently logged in, and rendering the according UI, seamlessly moving the authentication state between the browser and the server side of a SvelteKit application, or persisting the authentication state beyond refreshs.
+
+
+leads:
+  - name: Paolo Ricciuti
+    title: Senior Frontend Engineer
+    handle: paoloricciuti
+    image: /assets/images/authors/paoloricciuti.jpg
+    bio: >
+      Paolo is a huge nerd and Svelte maintainer. He's also one of the creators of <a href="https://sveltelab.dev">sveltelab.dev</a> - a REPL for SvelteKit.
+---
+
+<!--break-->
diff --git a/src/workshops/build-production-ready-apis-in-rust.md b/src/workshops/build-production-ready-apis-in-rust.md
index cda8d11212..c78673ca23 100644
--- a/src/workshops/build-production-ready-apis-in-rust.md
+++ b/src/workshops/build-production-ready-apis-in-rust.md
@@ -2,95 +2,83 @@
 title: "Build production-ready API services in Rust"
 tags: "rust"
 format: "Workshop: 3 days, on-site or remote"
-description: <p>Rust is an excellent programming language for developing API
-  services. You can build applications that are fast, reliable, and
-  cost-effective. In fact, using Rust to write services can tremendously reduce
-  your operating costs. However, the main challenge is knowing where to start.
-  This workshop guides you through the process. At the end of the journey,
-  you'll know enough to set up a production-ready HTTP API using the Axum
-  framework.</p></br>
-
-  <p>This workshop is designed for developers who know the basics of Rust and
-  want to learn more about backend development using Rust. Having written Rust
-  in a production environment is not a requirement.</p>
+description: This 3-day workshop is designed for developers who know the basics of Rust and want to learn more about backend development using Rust. Having written Rust in a production environment is not a requirement.
+introduction:
+  <p>Rust is an excellent programming language for developing API services. You can build applications that are fast, reliable, and cost-effective. In fact, using Rust to write services can tremendously reduce your operating costs. However, the main challenge is knowing where to start. This workshop guides you through the process. At the end of the journey, you'll know enough to set up a production-ready HTTP API using the Axum framework.</p>
+
+  <p>This workshop is designed for developers who know the basics of Rust and want to learn more about backend development using Rust. Having written Rust in a production environment is not a requirement.</p>
 hero:
   color: purple
-  image: "/assets/images/workshops/web-based-services-in-rust/header-background.jpg"
+  image: "/assets/images/workshops/production-ready-api-services-in-rust/header-background.jpg"
   imageAlt: "Several cogs and mechanical elements in purple."
 og:
-  image: /assets/images/workshops/production-ready-api-services-in-rust/og-image.jpeg
+  image: /assets/images/workshops/production-ready-api-services-in-rust/og-image.jpg
 topics:
   - title: Hello Axum!
     text: >
       Axum is the web framework we will be using throughout the workshop.  
-      We'll go over its architecture and where it fits in the broader Rust
-      ecosystem.
+      We'll go over its architecture and where it fits in the broader Rust ecosystem.
+
+
   - title: Your first endpoint
     text: >
-      We'll learn enough about Axum to write an API with a single endpoint that
-      returns a static "Hello World" response.  
-      It'll be an opportunity to learn about the key components of an Axum
-      application (the HTTP server, the router, the handler) and how to  connect
-      them together.  
-      We'll also wire up our first integration test. No matter how simple the
-      endpoint, we want to make sure it works!
+      We'll learn enough about Axum to write an API with a single endpoint that returns a static "Hello World" response.  
+      It'll be an opportunity to learn about the key components of an Axum application (the HTTP server, the router, the handler) and how to  connect them together.  
+      We'll also wire up our first integration test. No matter how simple the endpoint, we want to make sure it works!
+
+
   - title: Extracting data from the request
     text: >
-      We'll expand our API with new endpoints that leverage route parameters,
-      query parameters and JSON bodies.  
-      It'll be your introduction to the `FromRequest` trait and how to use it to
-      write extractors, the key mechanism to inject data from the incoming
-      request into your handlers.
+      We'll expand our API with new endpoints that leverage route parameters, query parameters and JSON bodies.  
+      It'll be your introduction to the <code>FromRequest</code> trait and how to use it to write extractors, the key mechanism to inject data from the incoming request into your handlers.
+
+
   - title: Telemetry
     text: >
-      At this point, the API is starting to get complex and you're likely to run
-      into issues: how do you debug them? We'll learn how to use the `tracing`
-      and the `tower-http` crates  to instrument our code and capture structured
-      logs. It'll be the first middleware you'll mount in your application.
+      At this point, the API is starting to get complex and you're likely to run into issues: how do you debug them? We'll learn how to use the <code>tracing</code> and the <code>tower-http</code> crates  to instrument our code and capture structured logs. It'll be the first middleware you'll mount in your application.
+
+
   - title: Shared application state
     text: >
-      Some data outlives the lifetime of a single request—e.g. a database
-      connection pool, or a cache client.  
-      We'll learn how to model this data as the state of our application and how
-      to access it from our handlers.
+      Some data outlives the lifetime of a single request—e.g. a database connection pool, or a cache client.  
+      We'll learn how to model this data as the state of our application and how to access it from our handlers.
+
+
   - title: Hierarchical configuration
     text: >
-      As soon as you start doing something non-trivial, you'll need to configure
-      your application with parameters that are specific to the environment it's
-      running in.  
-      We'll learn how to use the `config` crate to load configuration from
-      environment variables and configuration files, using a  layered approach.
+      As soon as you start doing something non-trivial, you'll need to configure your application with parameters that are specific to the environment it's running in.  
+      We'll learn how to use the <code>config</code> crate to load configuration from environment variables and configuration files, using a  layered approach.
+
+
   - title: External state, working with databases
     text: >
-      We'll learn how to use the `sqlx` crate to connect to a PostgreSQL
-      database and execute queries.  
-      We'll cover connection pooling and transactions, as well as how to test
-      endpoints that interact with the database.
+      We'll learn how to use the <code>sqlx</code> crate to connect to a PostgreSQL database and execute queries.  
+      We'll cover connection pooling and transactions, as well as how to test endpoints that interact with the database.
+
+
   - title: External state, working with third-party APIs
     text: >
-      We'll learn how to use the `reqwest` crate to call third-party APIs.  
-      We'll cover connection management, retries and timeouts, as well as how to
-      test endpoints that interact with third-party services via `wiremock`.
+      We'll learn how to use the <code>reqwest</code> crate to call third-party APIs.  
+      We'll cover connection management, retries and timeouts, as well as how to test endpoints that interact with third-party services via <code>wiremock</code>.
+
+
   - title: Sharing logic between endpoints via middlewares
     text: >
-      When you have multiple endpoints, you'll often find yourself repeating the
-      same logic in each of them. We'll learn how to extract this logic into
-      middlewares and mount them in our application.
+      When you have multiple endpoints, you'll often find yourself repeating the same logic in each of them. We'll learn how to extract this logic into middlewares and mount them in our application.
+
+
   - title: Preparing to deploy
     text: >
-      Most platforms require you to package your application as a Docker image
-      for deployment. We'll cover how to write a Dockerfile to package our API,
-      with a focus on effective caching (via `cargo-chef`) and techniques to
-      minimise the size of the final image.
+      Most platforms require you to package your application as a Docker image for deployment. We'll cover how to write a Dockerfile to package our API, with a focus on effective caching (via <code>cargo-chef</code>) and techniques to minimise the size of the final image.
+
+
 leads:
   - name: Luca Palmieri
     title: Principal Engineering Consultant
     handle: algo_luca
     image: /assets/images/authors/algo_luca.jpg
     bio: >
-      Luca Palmieri builds technology products for a living. His current focus
-      is on backend development, software architecture and the Rust programming
-      language. He is the author of "Zero to Production in Rust".
+      Luca Palmieri builds technology products for a living. His current focus is on backend development, software architecture and the Rust programming language. He is the author of "Zero to Production in Rust".
 ---
 
 <!--break-->
diff --git a/src/workshops/design-system-kickoff-interface-inventory.md b/src/workshops/design-system-kickoff-interface-inventory.md
index 3d5b8ec4f0..dba1bd104f 100644
--- a/src/workshops/design-system-kickoff-interface-inventory.md
+++ b/src/workshops/design-system-kickoff-interface-inventory.md
@@ -1,11 +1,10 @@
 ---
-title: Design system kickoff (interface inventory)
+title: "Design system kickoff (interface inventory)"
 tags: "design"
 format: "Workshop: 2-3 days"
 subtext: Bookable on request – onsite or remote
-description:
-  Create an interface inventory of your digital product, and align with your
-  team on how to prioritize refactoring using a design systems methodology.
+description: A 2-3 day workshop during which we create an interface inventory of your digital product, and align with your team on how to prioritize refactoring using a design systems methodology.
+introduction: <p>Create an interface inventory of your digital product, and align with your team on how to prioritize refactoring using a design systems methodology.</p>
 hero:
   color: purple
   image: "/assets/images/workshops/design-system-kickoff-interface-inventory/design-system-kickoff-interface-inventory-hero.jpg"
@@ -15,29 +14,34 @@ og:
 topics:
   - title: People, process, and tools
     text: >
-      Establish which core features in the user journey should be prioritized,
-      clarify ownership and team communication, agree on criteria and a toolset.
+      Establish which core features in the user journey should be prioritized, clarify ownership and team communication, agree on criteria and a toolset.
+
+
   - title: UI patterns
     text: >
-      Go over different user interface pattern types: functional, perceptual,
-      platform-specific, domain-specific, persuasive.
+      Go over different user interface pattern types: functional, perceptual, platform-specific, domain-specific, persuasive.
+
+
   - title: Hands-on work
     text: >
-      Divide and categorize screenshots of core features of your web interface
-      by functional categories (e.g. buttons, forms, navigation, typography,
-      lists) and intended use.
+      Divide and categorize screenshots of core features of your web interface by functional categories (e.g. buttons, forms, navigation, typography, lists) and intended use.
+
+
   - title: Naming convention
     text: >
-      Discuss naming as a shared language and mental model. We will go over
-      naming conventions and practice naming interface components.
+      Discuss naming as a shared language and mental model. We will go over naming conventions and practice naming interface components.
+
+
   - title: Share and learn
     text: >
-      Share and discuss our findings and rationale, as well as which patterns we
-      would keep, merge, and discard.
+      Share and discuss our findings and rationale, as well as which patterns we would keep, merge, and discard.
+
+
   - title: Next steps
     text: >
-      We'll share crucial steps that help us succeed when transitioning an
-      organization to a design system.
+      We'll share crucial steps that help us succeed when transitioning an organization to a design system.
+
+
 leads:
   - name: Florian Pichler
     title: Consultant for Technology and Design
@@ -45,23 +49,15 @@ leads:
     authorHandle: pichfl
     image: /assets/images/authors/pichfl.jpg
     bio: >
-      Florian bridges the gap between development and design, mentoring clients
-      along the way. He created user experiences and design systems for
-      established brands like Audi, BASF, BMW, and Zurich Insurance.
+      Florian bridges the gap between development and design, mentoring clients along the way. He created user experiences and design systems for established brands like Audi, BASF, BMW, and Zurich Insurance.
 ---
 
-Interface inventories are a key first step to create alignment and advocate
-transitioning to using design patterns in an organization. To get the most out
-of this workshop, bring in a cross-disciplinary team – we encourage people from
-every department that builds your product to join. Designers, developers,
-project managers, business owners, QA – are all welcome. These are the benefits
-of having an interface inventory:
+Interface inventories are a key first step to create alignment and advocate transitioning to using design patterns in an organization. To get the most out of this workshop, bring in a cross-disciplinary team – we encourage people from every department that builds your product to join. Designers, developers, project managers, business owners, QA – are all welcome. These are the benefits of having an interface inventory:
 
 - Gain clarity regarding which design components make up a digital product
 - Help us analyze inconsistencies between them
 - Gain buy-in from stakeholders to establish a design system
-- Start a conversation with your team on how to refactor design with a
-  pattern-based approach
+- Start a conversation with your team on how to refactor design with a pattern-based approach
 - Use it as a blueprint for a pattern library
 
 <!--break-->
diff --git a/src/workshops/digital-product-strategy.md b/src/workshops/digital-product-strategy.md
index 09b0358d85..1462cbc1c6 100644
--- a/src/workshops/digital-product-strategy.md
+++ b/src/workshops/digital-product-strategy.md
@@ -1,15 +1,10 @@
 ---
-title: Digital product strategy workshop
+title: "Digital product strategy workshop"
 tags: "strategy"
 format: "Collaborative Workshop: 1–2 days"
 subtext: "Bookable on request – on-site or remote"
-description:
-  In this workshop we will collaborate to formulate a clear product vision,
-  establishing a blueprint for your digital product's development process. This
-  workshop is a great kickoff for an MVP project. Before starting out, we will
-  gain an overview of your business. Understanding the fundamentals such as your
-  business model, competitor analysis, and users is an essential first step for
-  this strategy workshop.
+description: A 1-2 days workshop in which we will collaborate to formulate a clear product vision, establishing a blueprint for your digital product's development process. This workshop is a great kickoff for an MVP project.
+introduction: <p>In this workshop we will collaborate to formulate a clear product vision, establishing a blueprint for your digital product's development process. This workshop is a great kickoff for an MVP project. Before starting out, we will gain an overview of your business. Understanding the fundamentals such as your business model, competitor analysis, and users is an essential first step for this strategy workshop.</p>
 hero:
   color: purple
   image: "/assets/images/workshops/digital-product-strategy/digital-product-strategy-workshop-hero.jpg"
@@ -19,34 +14,34 @@ og:
 topics:
   - title: Understanding the product
     text: >
-      Go over your goals, desired features, mission statement, and possible key
-      performance indicators (KPIs). We also develop personas to gain a better
-      understanding of who we are building this product for
+      Go over your goals, desired features, mission statement, and possible key performance indicators (KPIs). We also develop personas to gain a better understanding of who we are building this product for
+
+
   - title: Minimum Viable Product (MVP)
     text: >
-      Collaboratively strip down features and develop an understanding of the
-      product's core functionality. The MVP is the sole focus for the rest of
-      the exercises in the workshop
+      Collaboratively strip down features and develop an understanding of the product's core functionality. The MVP is the sole focus for the rest of the exercises in the workshop
+
+
   - title: User-flow diagram
     text: >
-      Create a visualization of every step of the journey the user takes from
-      the entry point to the final interaction
+      Create a visualization of every step of the journey the user takes from the entry point to the final interaction
+
+
   - title: Low-fidelity wireframes
     text: >
-      A two-dimensional skeletal outline of key moments of the user flow
-      diagram. Also called a fat marker sketch because it is made with such
-      broad strokes that adding detail is difficult or impossible. The goal is
-      to focus on communicating the concept rather than creating a detailed
-      solution.
+      A two-dimensional skeletal outline of key moments of the user flow diagram. Also called a fat marker sketch because it is made with such broad strokes that adding detail is difficult or impossible. The goal is to focus on communicating the concept rather than creating a detailed solution.
+
+
   - title: Product architecture
     text: >
       Create a diagram to overview the web application's architecture.
+
+
   - title: Next steps
     text: >
-      To wrap up, we hold a presentation going over our results from the
-      workshop. We include a report with a digital version of the user flow
-      diagram, wireframes for MVP, the product architecture diagram, and our <a
-      href="/playbook/">40-page Playbook</a>
+      To wrap up, we hold a presentation going over our results from the workshop. We include a report with a digital version of the user flow diagram, wireframes for MVP, the product architecture diagram, and our <a href="/playbook/">40-page Playbook</a>
+
+
 leads:
   - name: Florian Pichler
     title: Consultant for Technology and Design
@@ -54,18 +49,16 @@ leads:
     authorHandle: pichfl
     image: /assets/images/authors/pichfl.jpg
     bio: >
-      Florian bridges the gap between development and design, mentoring clients
-      along the way. He created user experiences and design systems for
-      established brands like Audi, BASF, BMW, and Zurich Insurance.
+      Florian bridges the gap between development and design, mentoring clients along the way. He created user experiences and design systems for established brands like Audi, BASF, BMW, and Zurich Insurance.
+
+
   - name: Marco Otte-Witte
     title: Founder and Managing Director at Mainmatter
     handle: marcoow
     authorHandle: marcoow
     image: /assets/images/authors/marcoow.jpg
     bio: >
-      Marco has been working in tech with startups and enterprises for 2
-      decades. He's helped companies bring relevant products to market in
-      various industries – among them Blackberry, Generali and Experteer.
+      Marco has been working in tech with startups and enterprises for 2 decades. He's helped companies bring relevant products to market in various industries – among them Blackberry, Generali and Experteer.
 ---
 
 <!--break-->
diff --git a/src/workshops/effective-git.md b/src/workshops/effective-git.md
index 6bdd53f390..b33af286a1 100644
--- a/src/workshops/effective-git.md
+++ b/src/workshops/effective-git.md
@@ -1,16 +1,10 @@
 ---
-title: Effective Git
+title: "Effective Git"
 tags: "git"
 format: "Workshop: 1 day"
 subtext: "Bookable for teams – on-site or remote"
-description:
-  <p>Git is at the center of modern pull request-based development workflows.
-  Mastering it makes teams more productive and developers' jobs more
-  enjoyable.</p><br><p>The goal of the workshop is to provide just enough detail
-  for practical daily use without getting too academic or deep in the weeds. We
-  focus on real challenges developers face when working with Git, arming them
-  with an understanding of the foundational concepts along with practical
-  guidance for overcoming those challenges.</p>
+description: 1-day workshop – Git is at the center of modern pull request-based development workflows. Mastering it makes teams more productive and developers' jobs more enjoyable.
+introduction: <p>Git is at the center of modern pull request-based development workflows. Mastering it makes teams more productive and developers' jobs more enjoyable.</p><p>The goal of the workshop is to provide just enough detail for practical daily use without getting too academic or deep in the weeds. We focus on real challenges developers face when working with Git, arming them with an understanding of the foundational concepts along with practical guidance for overcoming those challenges.</p>
 hero:
   color: purple
   image: "/assets/images/workshops/effective-git/effective-git-workshop-hero.jpg"
@@ -20,38 +14,34 @@ og:
 topics:
   - title: Delivery pipelines
     text: >
-      Highly integrated and automated infrastructure and workflows are the
-      foundation that successful engineering teams excel on and Git is what
-      drives them at their core. We look at branching models, Pull Request based
-      workflows, and reviewing.
+      Highly integrated and automated infrastructure and workflows are the foundation that successful engineering teams excel on and Git is what drives them at their core. We look at branching models, Pull Request based workflows, and reviewing.
+
+
   - title: Git fundamentals
     text: >
-      Once we understand how Git fits in to the bigger picture, we'll look into
-      how it works at its core and the building blocks it consists of. We cover
-      what blobs, trees and snapshots are to better understand how they
-      represent a repo's history over time.
+      Once we understand how Git fits in to the bigger picture, we'll look into how it works at its core and the building blocks it consists of. We cover what blobs, trees and snapshots are to better understand how they represent a repo's history over time.
+
+
   - title: Branching and merging
     text: >
-      Git makes branching easy and cheap, and working with Git means constantly
-      switching between branches and merging them back together. We look at
-      common branching and merging scenarios to understand what fast-forward
-      merges and 3-way merges are.
+      Git makes branching easy and cheap, and working with Git means constantly switching between branches and merging them back together. We look at common branching and merging scenarios to understand what fast-forward merges and 3-way merges are.
+
+
   - title: Rewriting history
     text: >
-      Keeping a clean history and organizing commits in meaningful ways is
-      essential for efficient collaboration on code bases. We cover
-      (interactive) rebasing and rewriting history including squashing, editing
-      and dropping commits.
+      Keeping a clean history and organizing commits in meaningful ways is essential for efficient collaboration on code bases. We cover (interactive) rebasing and rewriting history including squashing, editing and dropping commits.
+
+
   - title: Bisecting
     text: >
-      Sometimes it's hard to find the change that introduced a particular
-      defect. Git Bisect can be of great help in identifying the respective
-      commit. We look at how bisecting works and how it can be used to save a
-      lot of time in common scenarios.
+      Sometimes it's hard to find the change that introduced a particular defect. Git Bisect can be of great help in identifying the respective commit. We look at how bisecting works and how it can be used to save a lot of time in common scenarios.
+
+
   - title: Open Q&A
     text: >
-      We reserve some time in the end to discuss your team's specific questions
-      relating to Git or infrastructure, tooling and automation around it.
+      We reserve some time in the end to discuss your team's specific questions relating to Git or infrastructure, tooling and automation around it.
+
+
 leads:
   - name: Chris Manson
     title: Senior Engineering Consultant
@@ -59,30 +49,22 @@ leads:
     authorHandle: real_ate
     image: /assets/images/authors/real_ate.jpg
     bio: >
-      Chris has had a long history with version control systems, with his very
-      first Open Source experience being involved in the transition of the
-      massive KDE codebase from CVS to Git. These days Chris is deeply involved
-      in the JAM Stack movement, giving him a new outlet for his love for Git.
+      Chris has had a long history with version control systems, with his very first Open Source experience being involved in the transition of the massive KDE codebase from CVS to Git. These days Chris is deeply involved in the JAM Stack movement, giving him a new outlet for his love for Git.
+
+
   - name: Marco Otte-Witte
     title: Founder and Managing Director at Mainmatter
     handle: marcoow
     authorHandle: marcoow
     image: /assets/images/authors/marcoow.jpg
     bio: >
-      Marco has been working in tech with startups and enterprises for 2
-      decades. He's helped companies bring relevant products to market in
-      various industries – among them Blackberry, Generali and Experteer.
+      Marco has been working in tech with startups and enterprises for 2 decades. He's helped companies bring relevant products to market in various industries – among them Blackberry, Generali and Experteer.
 ---
 
 <!--break-->
 
 ## Customised to your team’s needs
 
-We're happy to customize the workshop to precisely fit your team's specific
-needs or challenges. If you have a very specific branching model or
-infrastructure or your team frequently struggles with particular aspects of Git,
-we can adapt the focus of the workshop more towards these aspects or cover
-additional topics as necessary.
+We're happy to customize the workshop to precisely fit your team's specific needs or challenges. If you have a very specific branching model or infrastructure or your team frequently struggles with particular aspects of Git, we can adapt the focus of the workshop more towards these aspects or cover additional topics as necessary.
 
-All content and examples of the workshop are available publicly on
-[GitHub](https://github.com/mainmatter/git-workshop).
+All content and examples of the workshop are available publicly on [GitHub](https://github.com/mainmatter/git-workshop).
diff --git a/src/workshops/hands-on-ember.md b/src/workshops/hands-on-ember.md
index b0189014e3..4904b3375e 100644
--- a/src/workshops/hands-on-ember.md
+++ b/src/workshops/hands-on-ember.md
@@ -1,21 +1,13 @@
 ---
-title: Hands-on Ember.js
+title: "Hands-on Ember.js"
 tags: "ember"
 format: "Workshop: 2-3 days"
 subtext: "Bookable for teams – on-site or remote"
-description: <p>We go through a series of stages that each build on one another.
-  Each topic is introduced via an in-depth presentation as well as a small,
-  focussed demo application that illustrates the respective concept in practice.
-  Over the course of the workshop we take participants through building a full
-  Ember application step by step so each topic can be applied hands-on with the
-  support of our tutors. Depending on each team's needs and previous experience,
-  we will cover each topic in varying depth. We are also happy to customize
-  workshops for the specific needs of a team and cover topics like performance,
-  debugging, upgrading from older versions of Ember, or any topics particular to
-  a team's application.</p></br>
-
-  <p>All examples and practical assignments from the workshop are available
-  publicly on GitHub.</p>
+description: A 2-3 days workshop in which we go through a series of stages that each build on one another. Each topic is introduced via an in-depth presentation as well as a small, focussed demo application that illustrates the respective concept in practice.
+introduction:
+  <p>We go through a series of stages that each build on one another. Each topic is introduced via an in-depth presentation as well as a small, focussed demo application that illustrates the respective concept in practice. Over the course of the workshop we take participants through building a full Ember application step by step so each topic can be applied hands-on with the support of our tutors. Depending on each team's needs and previous experience, we will cover each topic in varying depth. We are also happy to customize workshops for the specific needs of a team and cover topics like performance, debugging, upgrading from older versions of Ember, or any topics particular to a team's application.</p>
+
+  <p>All examples and practical assignments from the workshop are available publicly on GitHub.</p>
 hero:
   color: purple
   image: "/assets/images/workshops/hands-on-ember/hands-on-ember-workshop-hero.jpg"
@@ -26,71 +18,66 @@ og:
 topics:
   - title: Ember.js basics
     text: >
-      We look at the basic building blocks of an Ember application and how they
-      play together. We also take a look at the CLI and development tooling like
-      the Ember Inspector.
+      We look at the basic building blocks of an Ember application and how they play together. We also take a look at the CLI and development tooling like the Ember Inspector.
+
+
   - title: Templates and components
     text: >
-      Rendering DOM elements is the most essential task of every Ember app. We
-      dive deep into Handlebars, Ember's component model, tracked properties as
-      well as actions and modifiers and more advanced topics like complex
-      component architectures, component reusability concerns, and architectural
-      approaches.
+      Rendering DOM elements is the most essential task of every Ember app. We dive deep into Handlebars, Ember's component model, tracked properties as well as actions and modifiers and more advanced topics like complex component architectures, component reusability concerns, and architectural approaches.
+
+
   - title: Routing
     text: >
-      Ember pioneered the idea of driving the application state through the URL.
-      In this stage, we explore Ember's routing, the template hierarchy, and
-      advanced concepts like loading and error states.
+      Ember pioneered the idea of driving the application state through the URL. In this stage, we explore Ember's routing, the template hierarchy, and advanced concepts like loading and error states.
+
+
   - title: Ember Data
     text: >
-      This stage covers all aspects of Ember Data, from the basics like working
-      with models and the store, to advanced topics like adapters and
-      serializers, the json:api spec, and data loading patterns.
+      This stage covers all aspects of Ember Data, from the basics like working with models and the store, to advanced topics like adapters and serializers, the json:api spec, and data loading patterns.
+
+
   - title: Services
     text: >
-      Ember's services are a simple yet powerful mechanism for sharing state
-      throughout the application as well as encapsulating specific
-      functionality. We cover how services work and look at typical use cases
-      and patterns.
+      Ember's services are a simple yet powerful mechanism for sharing state throughout the application as well as encapsulating specific functionality. We cover how services work and look at typical use cases and patterns.
+
+
   - title: Testing
     text: >
-      We cover fundamental authentication and authorization concepts, discussing
-      different mechanisms and related security aspects.
+      We cover fundamental authentication and authorization concepts, discussing different mechanisms and related security aspects.
+
+
 optional_topics:
   - title: Auth (optional)
     text: >
-      We cover fundamental authentication and authorization concepts, discussing
-      different mechanisms and related security aspects.
+      We cover fundamental authentication and authorization concepts, discussing different mechanisms and related security aspects.
+
+
   - title: Deployment, performance, SSR and SSG (optional)
     text: >
-      In this stage, we look into serving Ember applications in the most
-      performant way. We cover topics like CDNs, caching and service workers, as
-      well as server-side rendering and pre-rendering with FastBoot.
+      In this stage, we look into serving Ember applications in the most performant way. We cover topics like CDNs, caching and service workers, as well as server-side rendering and pre-rendering with FastBoot.
+
+
   - title: Ember’s object model (optional)
     text: >
-      Ember applications building on versions older than the Octane edition are
-      still using Ember's legacy object model with patterns like computed
-      properties and mixins. In this stage, we cover those concepts in-depth as
-      well as explore approaches for migrating to native classes.
+      Ember applications building on versions older than the Octane edition are still using Ember's legacy object model with patterns like computed properties and mixins. In this stage, we cover those concepts in-depth as well as explore approaches for migrating to native classes.
+
+
 leads:
   - name: Gabor Babicz
     title: Senior Frontend Engineer
     handle: zeppelin
     image: /assets/images/authors/zeppelin.jpg
     bio: >
-      Gabor was a very early adopter of Ember in the pre-1.0 years of the
-      framework and has since successfully completed numerous projects with it.
-      He helps teams build applications and teaches best practices along the
-      way.
+      Gabor was a very early adopter of Ember in the pre-1.0 years of the framework and has since successfully completed numerous projects with it. He helps teams build applications and teaches best practices along the way.
+
+
   - name: Marco Otte-Witte
     title: Founder and Managing Director at Mainmatter
     handle: marcoow
     authorHandle: marcoow
     image: /assets/images/authors/marcoow.jpg
     bio: >
-      Marco has been working in tech with startups and enterprises for 2
-      decades. He's helped companies bring relevant products to market in
-      various industries – among them Blackberry, Generali and Experteer.
+      Marco has been working in tech with startups and enterprises for 2 decades. He's helped companies bring relevant products to market in various industries – among them Blackberry, Generali and Experteer.
 ---
 
 <!--break-->
diff --git a/src/workshops/introduction-to-rust-for-web-developers.md b/src/workshops/introduction-to-rust-for-web-developers.md
index 8ac8b7f531..8623acc0c7 100644
--- a/src/workshops/introduction-to-rust-for-web-developers.md
+++ b/src/workshops/introduction-to-rust-for-web-developers.md
@@ -1,21 +1,13 @@
 ---
-title: Introduction to Rust for Web Developers
+title: "Introduction to Rust for Web Developers"
 tags: "rust"
 format: "Workshop: 2-3 days"
 subtext: "Bookable for teams – on-site or remote"
-description: <p>According to the Stack Overflow survey, Rust is one of the most
-  beloved programming languages. In recent years, it has also gained popularity.
-  There has never been a better time to become familiar with Rust! Learning a
-  new programming language is always easier when you start with topics within
-  your comfort zone. In this workshop, we will explore the main concepts of Rust
-  by developing web applications. We will cover topics such as ownership and
-  borrowing, concurrency, types and structs, all while building a real-world web
-  app together. If you have a basic understanding of creating web back-ends and
-  APIs, this workshop will get you up to speed with Rust.</p></br>
-
-  <p>This workshop is designed for software developers with little to no
-  experience in Rust. We recommend having prior experience in writing web
-  applications.</p>
+description: In this 2-3 days workshop, we will explore the main concepts of Rust by developing web applications. We will cover topics such as ownership and borrowing, concurrency, types and structs, all while building a real-world web app together.
+introduction:
+  <p>According to the Stack Overflow survey, Rust is one of the most beloved programming languages. In recent years, it has also gained popularity. There has never been a better time to become familiar with Rust! Learning a new programming language is always easier when you start with topics within your comfort zone. In this workshop, we will explore the main concepts of Rust by developing web applications. We will cover topics such as ownership and borrowing, concurrency, types and structs, all while building a real-world web app together. If you have a basic understanding of creating web back-ends and APIs, this workshop will get you up to speed with Rust.</p>
+
+  <p>This workshop is designed for software developers with little to no experience in Rust. We recommend having prior experience in writing web applications.</p>
 hero:
   color: purple
   image: "/assets/images/workshops/introduction-to-rust-for-web-developers/header-background.jpg"
@@ -25,38 +17,31 @@ og:
 topics:
   - title: Getting Started
     text: >
-      We will begin by creating a new project and writing our first lines of
-      Rust code. You will become familiar with new syntax primitives, basic
-      types, expressions, function signatures, and the async/await syntax.
-      Additionally, you will learn how to work with Rust's tooling, such as
-      Cargo and Rust Analyzer.
+      We will begin by creating a new project and writing our first lines of Rust code. You will become familiar with new syntax primitives, basic types, expressions, function signatures, and the async/await syntax. Additionally, you will learn how to work with Rust's tooling, such as Cargo and Rust Analyzer.
+
+
   - title: Ownership and Borrowing
     text: >
-      As we add more functionality to our application, we will explore Rust's
-      unique approach to memory management: Ownership and Borrowing. We will
-      delve into the intricacies of this system by examining common situations
-      and understanding how it requires us to rethink application development.
+      As we add more functionality to our application, we will explore Rust's unique approach to memory management: Ownership and Borrowing. We will delve into the intricacies of this system by examining common situations and understanding how it requires us to rethink application development.
+
+
   - title: Shared Access in Concurrent Applications
     text: >
-      Rust's memory management system is ideal for shared access to data in
-      multi-threaded applications, as it forces us to reconsider how we handle
-      shared memory. In this section, we will learn how to share state across
-      threads, how synchronization primitives function, and the significant role
-      ownership plays.
+      Rust's memory management system is ideal for shared access to data in multi-threaded applications, as it forces us to reconsider how we handle shared memory. In this section, we will learn how to share state across threads, how synchronization primitives function, and the significant role ownership plays.
+
+
   - title: Structs, Traits, Serialization and Deserialization of Data
     text: >
-      In the final part, we will gain insight into Rust's type system by
-      exploring traits and their applications in serializing and deserializing
-      requests and responses.
+      In the final part, we will gain insight into Rust's type system by exploring traits and their applications in serializing and deserializing requests and responses.
+
+
 leads:
   - name: Stefan Baumgartner
     title: Architect and Independent Trainer
     handle: ddprrt
     image: /assets/images/authors/ddprrt.jpg
     bio: >
-      Stefan Baumgartner is an architect and developer based in Austria who
-      specializes in serverless technologies. He has authored two books on
-      TypeScript and is also the organizer of the Rust Linz meetup.
+      Stefan Baumgartner is an architect and developer based in Austria who specializes in serverless technologies. He has authored two books on TypeScript and is also the organizer of the Rust Linz meetup.
 ---
 
 <!--break-->
diff --git a/src/workshops/learn-rust-starting-from-scratch.md b/src/workshops/learn-rust-starting-from-scratch.md
index a6c80587c6..062e144e1c 100644
--- a/src/workshops/learn-rust-starting-from-scratch.md
+++ b/src/workshops/learn-rust-starting-from-scratch.md
@@ -3,7 +3,8 @@ title: "Learn Rust, starting from scratch"
 tags: "rust"
 format: "Workshop: 4 days"
 subtext: "Bookable for teams – on-site or remote"
-description: |
+description: This 4-days workshop helps you get started with Rust, assuming no prior knowledge of the language. The workshop starts from the absolute basics and gradually builds up to more advanced topics.
+introduction: |
   <p>Rust is a general-purpose programming languages that's been growing in popularity over the past few years.
     It's known for its strong type system, its focus on safety and performance, and its modern tooling.</p>
   <p>We designed this workshop to help you get started with Rust, assuming no prior knowledge of the language.</p>
@@ -18,53 +19,40 @@ hero:
   image: "/assets/images/workshops/an-introduction-to-testing-in-rust/header-background.jpg"
   imageAlt: "A drawing of a giant crab standing in a village."
 og:
-  image: /assets/images/workshops/learn-rust-starting-from-scratch/og-image.jpeg
+  image: /assets/images/workshops/learn-rust-starting-from-scratch/og-image.jpg
 topics:
   - heading: The toolbox
     text: >
-      We will cover the tools that every Rust developer should have in their
-      toolbox: <code>rustup</code> (toolchain management), <code>cargo</code>
-      (build system and package manager),  <code>clippy</code> (linter),
-      <code>rustfmt</code> (formatter), and <code>rustdoc</code> (documentation
-      generator).
+      We will cover the tools that every Rust developer should have in their toolbox: <code>rustup</code> (toolchain management), <code>cargo</code> (build system and package manager),  <code>clippy</code> (linter), <code>rustfmt</code> (formatter), and <code>rustdoc</code> (documentation generator).
+
+
   - heading: The language
     text: >
-      We will cover in detail the core constructs of the Rust language: syntax,
-      control flow, pattern matching, type system (traits), ownership and
-      borrowing, polymorphism (generics and trait objects), closures and `Fn*`
-      traits, and panics.
+      We will cover in detail the core constructs of the Rust language: syntax, control flow, pattern matching, type system (traits), ownership and borrowing, polymorphism (generics and trait objects), closures and `Fn*` traits, and panics.
+
+
   - heading: The standard library
     text: >
-      Writing Rust programs is significantly easier if you have mastered the
-      standard library. We will cover the most important parts of the standard
-      library, including: primitive types, strings and string slices,
-      collections and iterators, conversion traits, smart pointers
-      (<code>Box</code>, <code>Arc</code>, <code>Rc</code>), nullability
-      handling (<code>Option</code>), error handling (<code>Result</code>), and
-      concurrency primitives (threads, channels, locks).
+      Writing Rust programs is significantly easier if you have mastered the standard library. We will cover the most important parts of the standard library, including: primitive types, strings and string slices, collections and iterators, conversion traits, smart pointers (<code>Box</code>, <code>Arc</code>, <code>Rc</code>), nullability handling (<code>Option</code>), error handling (<code>Result</code>), and concurrency primitives (threads, channels, locks).
+
+
   - heading: Testing
     text: >
-      We will build up your Rust's testing toolkit. We will start from scratch,
-      with your first unit test. By the end, you will have a comprehensive
-      understanding of the available  test types, the best practices in terms of
-      test organization as well as their runtime implications. You will be well
-      equipped for the testing challenges ahead of you!
+      We will build up your Rust's testing toolkit. We will start from scratch, with your first unit test. By the end, you will have a comprehensive understanding of the available  test types, the best practices in terms of test organization as well as their runtime implications. You will be well equipped for the testing challenges ahead of you!
+
+
   - heading: Async Rust
     text: >
-      We will cover the basics of asynchronous programming in Rust,
-      including:  the <code>Future</code> trait, <code>async</code> functions,
-      the <code>.await</code> operator, spawning tasks, an overview of
-      <code>tokio</code> (the most popular async runtime in Rust), as well as
-      common pitfalls.
+      We will cover the basics of asynchronous programming in Rust, including:  the <code>Future</code> trait, <code>async</code> functions, the <code>.await</code> operator, spawning tasks, an overview of <code>tokio</code> (the most popular async runtime in Rust), as well as common pitfalls.
+
+
 leads:
   - name: Luca Palmieri
     title: Principal Engineering Consultant
     handle: algo_luca
     image: /assets/images/authors/algo_luca.jpg
     bio: >
-      Luca Palmieri builds technology products for a living. His current focus
-      is on backend development,  software architecture and the Rust programming
-      language. He is the author of "Zero to Production in Rust".
+      Luca Palmieri builds technology products for a living. His current focus is on backend development,  software architecture and the Rust programming language. He is the author of "Zero to Production in Rust".
 ---
 
 <!--break-->
diff --git a/src/workshops/progressive-enhancement-with-sveltekit.md b/src/workshops/progressive-enhancement-with-sveltekit.md
new file mode 100644
index 0000000000..4320ade64c
--- /dev/null
+++ b/src/workshops/progressive-enhancement-with-sveltekit.md
@@ -0,0 +1,59 @@
+---
+title: "Progressive Enhancement with SvelteKit"
+tags: "svelte"
+format: "Workshop: 1 day"
+subtext: "Bookable for teams – on-site or remote"
+description: This 1-day workshop gives a comprehensive introduction to building progressive enhanced applications with SvelteKit, covering the theory, as well as guiding participants through implementing real examples.
+introduction: "<p>Progressive enhancement is a technique for providing a baseline experience in terms of content and functionality to everyone and enhancing that to the optimal experience for everyone that's possible for. That allows, in particular for use cases like e-commerce where every lost visitor is potentially a missed sale, to serve each and everyone of your visitors – as opposed to with a classic SPA where people with a spotty network that doesn't load the JavaScript bundle, would only see a blank page.</p><p>SvelteKit has built-in support for progressive enhancement, yet getting the most out of that requires understanding the underlying principles and applying the right techniques. This workshop gives a comprehensive introduction to building progressive enhanced applications with SvelteKit, covering the theory, as well as guiding participants through implementing real examples.</p>"
+hero:
+  color: purple
+  image: "/assets/images/workshops/progressive-enhancement-with-sveltekit/lego-superman.jpg"
+  imageAlt: "A Lego superman figure with their cape flying in a wind in front of a dramatic orange/pink sky"
+og:
+  image: /assets/images/workshops/progressive-enhancement-with-sveltekit/og-image.jpg
+topics:
+  - title: Progressive Enhancement
+    text: >
+      We'll start by looking into what progressive enhancement is and why it's relevant. We'll look at network speeds and typical latency numbers, as well as at JavaScript bundle sizes, and their impact on load times.
+
+
+  - title: Forms in SvelteKit
+    text: >
+      One of SvelteKit's main mechanisms for supporting progressive enhancment are forms and form actions that can run in Node on the server side. We'll look at data flows, how forms can be enhanced to be handled on the clients side, and a bit at the underlying magic that makes that process seamless for the developer.
+
+
+  - title: "Example: Autocomplete"
+    text: >
+      We'll build am input component that starts off as a simple text field without JavaScript and is progressively enhanced into an auto-complete input with JavaScript.
+
+
+  - title: "Example: Search"
+    text: >
+      Next, we'll build a search UI that works with and without JavaScript.
+
+
+  - title: "Testing"
+    text: >
+      Building progressively enhanced applications requires testing two scenarios for all flows: one with and one without JavaScript. We'll cover the topic by writing Playwright tests for the previously implemented examples.
+
+
+  - title: CSS & Progressive Enhancement
+    text: >
+      Some elements of user interfaces can be made functional with CSS alone. We'll look at typical scenarios where that approach works and how UI state can be kept in sync with our Svelte application.
+
+
+  - title: "Example: Dialog with inline JavaScript"
+    text: >
+      Finally, we'll build a dialog with a tiny snipped of inline JavaScript that works without the entirety of the Svelte application having started.
+
+
+leads:
+  - name: Paolo Ricciuti
+    title: Senior Frontend Engineer
+    handle: paoloricciuti
+    image: /assets/images/authors/paoloricciuti.jpg
+    bio: >
+      Paolo is a huge nerd and Svelte maintainer. He's also one of the creators of <a href="https://sveltelab.dev">sveltelab.dev</a> - a REPL for SvelteKit.
+---
+
+<!--break-->
diff --git a/src/workshops/rust-python-interoperability.md b/src/workshops/rust-python-interoperability.md
new file mode 100644
index 0000000000..ac42be72b5
--- /dev/null
+++ b/src/workshops/rust-python-interoperability.md
@@ -0,0 +1,56 @@
+---
+title: "Rust-Python Interoperability"
+tags: "rust"
+format: "Workshop: 1 day"
+subtext: "Bookable for teams – on-site or remote"
+description: >
+  <p>Python has served you well: you spun up a prototype and iterated quickly, keeping up with the evolving requirements of a successful product. Nonetheless, as time goes on, cracks are starting to show up: an endpoint is slower than it needs to be, a data processing job that took seconds now takes almost an hour, and your infrastructure bill is growing too fast compared to the size of your user base. Engineers are starting to whisper: is it time for a rewrite? Should we pause feature development to rebuild everything on more solid foundations? That's an option, but it's expensive.</p><p>There's another path: rather than throwing away your entire Python codebase to start over, you analyse your application and isolate the performance-critical bits—the so-called "hot modules" where your application spends most of its time. You will rewrite those in Rust and package them as a Python native extension. This workshop will teach you how.</p><p>We will cover the <code>pyo3</code> crate, the subtleties of Python's Global interpreter lock, and typical examples that may arise in your daily Rust-Python interoperability work. By the end of the session, you will be well-equipped to seamlessly replace your slow Python modules with easy-to-use and blazingly fast Rust modules.</p><p>We assume you are familiar with Rust and Python, but we don't assume any prior interoperability knowledge. We will provide a brief explanation and references whenever we rely on advanced features in either language.</p>
+
+
+hero:
+  color: purple
+  image: "/assets/images/workshops/rust-python-interoperability/header-background.jpg"
+  imageAlt: "Close-up photo of 3 snake bodies (or 3 parts of the same snake body) stacked on top of each other."
+og:
+  image: /assets/images/workshops/rust-python-interoperability/og-image.jpg
+topics:
+  - title: Introduction to Rust-Python Interoperability
+    text: >
+      We kick off with looking at the advantages of combining Rust and Python, understanding where each language shines and why interoperability is valuable. This module introduces tools like <code>PyO3</code>, which enables Rust code integration within Python environments, and <code>maturin</code>, a library for building, packaging and publishing Python extensions written in Rust.
+
+
+  - title: Building Python Extensions in Rust
+    text: >
+      We'll continue with the process of creating Python-callable Rust functions, setting up projects using <code>PyO3</code>, and configuring the development environment to handle Rust extensions in Python.
+
+
+  - title: Managing Data and Types
+    text: >
+      Next, participants will learn how to handle complex data structures shared between Rust and Python, with a focus on type conversions, data ownership, and ensuring memory safety across both languages.
+
+
+  - title: Concurrency and the GIL
+    text: >
+      The workshop covers Python’s Global Interpreter Lock (GIL) and strategies for concurrent programming, including async programming in Rust that can enhance Python’s parallel processing capabilities.
+
+
+  - title: Creating Python Classes with Rust
+    text: >
+      We move on to explore creating Python-accessible classes directly in Rust using <code>PyO3</code>'s <code>#[pyclass]</code> attribute. This module teaches struct definition, implementing methods, and adding Rust-based functionality to Python classes.
+
+
+  - title: Static Methods and Inheritance
+    text: >
+      The final module details adding static methods to Rust-backed Python classes, along with managing inheritance and visibility in Python environments.
+
+
+leads:
+  - name: Luca Palmieri
+    title: Principal Engineering Consultant
+    handle: algo_luca
+    image: /assets/images/authors/algo_luca.jpg
+    bio: >
+      Luca Palmieri builds technology products for a living. His current focus is on backend development, software architecture and the Rust programming language. He is the author of "Zero to Production in Rust".
+---
+
+<!--break-->
diff --git a/src/workshops/svelte-5-runes.md b/src/workshops/svelte-5-runes.md
new file mode 100644
index 0000000000..4d125930f6
--- /dev/null
+++ b/src/workshops/svelte-5-runes.md
@@ -0,0 +1,64 @@
+---
+title: "Svelte 5 & Runes"
+tags: "svelte"
+format: "Workshop: 1 day"
+subtext: "Bookable for teams – on-site or remote"
+description: This 1-day workshop is an introduction to Svelte 5's new concepts, as well as a hands-on guide to migrating from old patterns to Svelte 5 and runes.
+introduction: "<p>Svelte 5 is a major step forward from version 4 and simplifies how Svelte applications are written. Concepts like snippets and runes, Svelte 5's new set of primitives for controlling reactivity, will replace a number of current concepts that will no longer by required with runes. Yet, as these concept are newly introduced, developers need to learn and them before they can leverage them. This workshop serves as an introduction to Svelte 5's new concepts, as well as a hands-on guide to migrating from old patterns to Svelte 5 and runes.</p>"
+hero:
+  color: purple
+  image: "/assets/images/workshops/svelte-5-runes/runes.jpg"
+  imageAlt: "A bunch of white stones with yellow runes written on them lying on a grey surface"
+og:
+  image: /assets/images/workshops/svelte-5-runes/og-image.jpg
+topics:
+  - title: From Svelte 4 to 5
+    text: >
+      We'll start with reviewing the differences between Svelte 4 and 5 before looking into the main changes in more detail.
+
+
+  - title: The <code>$state</code> rune
+    text: >
+      The <code>$state</code> rune is at the core of Svelte 5's runes system so we start with that. We'll cover it's core behavior and implement some examples together.
+
+
+  - title: The <code>$derived</code> rune
+    text: >
+      The <code>$derived</code> rune replaces Svelte's <code>$:</code> syntax. We'll look into how the rune works, subtle differences to <code>$:</code>, as well as how to migrate to it for typical scenarios.
+
+
+  - title: The <code>$effect</code> rune
+    text: >
+      Next, we move to the <code>$effect</code> rune. Like for the <code>$state</code> rune, we'll implement some examples and talk about typical use cases.
+
+
+  - title: The <code>$props</code> rune
+    text: >
+      The <code>$props</code> rune replaces a number of previous concepts around declaring, and receiving properties in components. We'll look into how the rune works as well as how to migrate to it for typical scenarios.
+
+
+  - title: Introduction to JavaScript signals
+    text: >
+      Once we covered runes, we'll briefly look into JavaScript's upcoming <a href="https://github.com/tc39/proposal-signals">signals primitive</a> which runes are based on. We'll cover the fundamentals of signals and how they might eventually establish a cross-framework reactivity primitive.
+
+
+  - title: From Slots to Snippets
+    text: >
+      Snippets are a new concept in Svelte 5 that replace slots which are less powerful and flexible. We'll look into how snippets work, what new patterns they enable, and how to migrate from slots to snippets.
+
+
+  - title: Automating the Migration
+    text: >
+      At least parts of the migration from Svelte 4 to 5 can be automated. We'll look into how that works, what to be aware of, and how to resolve situations where automatic migration fails.
+
+
+leads:
+  - name: Paolo Ricciuti
+    title: Senior Frontend Engineer
+    handle: paoloricciuti
+    image: /assets/images/authors/paoloricciuti.jpg
+    bio: >
+      Paolo is a huge nerd and Svelte maintainer. He's also one of the creators of <a href="https://sveltelab.dev">sveltelab.dev</a> - a REPL for SvelteKit.
+---
+
+<!--break-->
diff --git a/src/workshops/svelte-and-sveltekit.md b/src/workshops/svelte-and-sveltekit.md
index c0226ac698..5278812005 100644
--- a/src/workshops/svelte-and-sveltekit.md
+++ b/src/workshops/svelte-and-sveltekit.md
@@ -1,101 +1,87 @@
 ---
-title: Svelte & SvelteKit
+title: "Svelte & SvelteKit"
 tags: "svelte"
 format: "Workshop: 2-3 days"
 subtext: "Bookable for teams – on-site or remote"
-description: <p>Svelte is great choice for building fast and light-weight web
-  applications. Its unique approach of generating reactive code at compile time
-  instead of relying on a runtime, moves work out of the browser and results in
-  highly efficient code. Combined with SvelteKit, it enables engineers to build
-  large applications with ease while being able to choose among patterns like
-  SPA, MPA, SSR, SSG on a per-route basis.</p>
-
-  <p>This workshops takes participants through the entire process of building a
-  complete, real-world application and teaches the theoretical concepts along
-  the way. Each topic is introduced via an in-depth presentation followed by a
-  practice exercise.</p>
-
-  <p>All examples and practical assignments from the workshop are available
-  publicly on GitHub.</p>
+description: This 2-3days workshop takes participants through the entire process of building a complete, real-world application and teaches the theoretical concepts along the way. Each topic is introduced via an in-depth presentation followed by a practice exercise.
+introduction:
+  <p>Svelte is great choice for building fast and light-weight web applications. Its unique approach of generating reactive code at compile time instead of relying on a runtime, moves work out of the browser and results in highly efficient code. Combined with SvelteKit, it enables engineers to build large applications with ease while being able to choose among patterns like SPA, MPA, SSR, SSG on a per-route basis.</p>
+
+  <p>This workshop takes participants through the entire process of building a complete, real-world application and teaches the theoretical concepts along the way. Each topic is introduced via an in-depth presentation followed by a practice exercise.</p>
+
+  <p>All examples and practical assignments from the workshop are available publicly on GitHub.</p>
 hero:
   color: purple
   image: "/assets/images/workshops/svelte-and-sveltekit/hero.jpg"
-  imageAlt:
-    "Photo of a computer screen showing an IDE with an open Svelte project"
+  imageAlt: "Photo of a computer screen showing an IDE with an open Svelte project"
 og:
   image: /assets/images/workshops/svelte-and-sveltekit/og-image.jpg
 topics:
   - title: Svelte Basics
     text: >
-      Rendering reactive UIs is the core functionality of Svelte. We cover
-      Svelte’s unique approach to reactivity, the <code>$</code> syntax and its
-      template language. We then look into writing Svelte components, accepting
-      props, and its CSS scoping feature.
+      Rendering reactive UIs is the core functionality of Svelte. We cover Svelte’s unique approach to reactivity, the <code>$</code> syntax and its template language. We then look into writing Svelte components, accepting props, and its CSS scoping feature.
+
+
   - title: SvelteKit Basics
     text: >
-      This stage introduces SvelteKit, the project framework built on Svelte. We
-      cover project creation and management, SvelteKit’s file system as well as
-      creating and managing pages.
+      This stage introduces SvelteKit, the project framework built on Svelte. We cover project creation and management, SvelteKit’s file system as well as creating and managing pages.
+
+
   - title: Routing
     text: >
-      We’ll dive deep into SvelteKit’s file based routing, loading and
-      displaying data as well as topics like route grouping, route params and
-      redirects.
+      We’ll dive deep into SvelteKit’s file based routing, loading and displaying data as well as topics like route grouping, route params and redirects.
+
+
   - title: Testing
     text: >
-      SvelteKit comes with two testing strategies: Vitest for testing components
-      in isolation and Playwright for end-to-end testing. We cover both in depth
-      and present approaches for testing real applications.
+      SvelteKit comes with two testing strategies: Vitest for testing components in isolation and Playwright for end-to-end testing. We cover both in depth and present approaches for testing real applications.
+
+
   - title: Stores
     text: >
-      This stage kicks off with an introduction of what stores are and how they
-      work. We continue with looking into implementing the three main stores:
-      writable, readable, and derived.
+      This stage kicks off with an introduction of what stores are and how they work. We continue with looking into implementing the three main stores: writable, readable, and derived.
+
+
   - title: SvelteKit and Progressive Enhancement
     text: >
-      The final stage of the workshop teaches how to implement progressive
-      enhancement with forms. We cover how to send data to an API, how to
-      validate forms, what server folders are, and give a brief introduction
-      into hooks. We close by looking into how to implement authentication.
+      The final stage of the workshop teaches how to implement progressive enhancement with forms. We cover how to send data to an API, how to validate forms, what server folders are, and give a brief introduction into hooks. We close by looking into how to implement authentication.
+
+
 leads:
   - name: Paolo Ricciuti
     title: Senior Frontend Engineer
     handle: paoloricciuti
     image: /assets/images/authors/paoloricciuti.jpg
     bio: >
-      Huge nerd, Svelte Ambassador and lover. He's one of the creators of <a
-      href="https://sveltelab.dev">sveltelab.dev</a> - a REPL for SvelteKit -
-      built during the first Svelte hackathon that granted him and his
-      co-creator the first place for best integration.
+      Huge nerd, Svelte Ambassador and lover. He's one of the creators of <a href="https://sveltelab.dev">sveltelab.dev</a> - a REPL for SvelteKit - built during the first Svelte hackathon that granted him and his co-creator the first place for best integration.
+
+
   - name: Daniel Beer
     title: Senior Frontend Engineer
     handle: beerinho
     authorHandle: beerinho
     image: /assets/images/authors/beerinho.jpg
     bio: >
-      With experience in Angular and EmberJS, Daniel has as a varied background
-      in JS Frameworks and enjoys exploring new technologies. He has used
-      SvelteKit on multiple projects with great success.
+      With experience in Angular and EmberJS, Daniel has as a varied background in JS Frameworks and enjoys exploring new technologies. He has used SvelteKit on multiple projects with great success.
+
+
   - name: Gabor Babicz
     title: Senior Frontend Engineer
     handle: zeppelin
     image: /assets/images/authors/zeppelin.jpg
     bio: >
-      Gabor is a passionate frontend engineer who has spent the past two decades
-      designing interfaces, merging functionality and aesthetics to create
-      remarkable digital experiences.
+      Gabor is a passionate frontend engineer who has spent the past two decades designing interfaces, merging functionality and aesthetics to create remarkable digital experiences.
+
+
   - name: Florian Pichler
     title: Senior Frontend Engineer
     handle: pichfl
     authorHandle: pichfl
     image: /assets/images/authors/pichfl.jpg
     bio: >
-      Florian has been solving frontend challenges for over 15 years, with all
-      tools that became available. He has built and coached design and
-      development teams of all sizes.
+      Florian has been solving frontend challenges for over 15 years, with all tools that became available. He has built and coached design and development teams of all sizes.
 ---
 
 <!--break-->
 
-The workshop can be customized for the specific needs of your team to cover
-topics like performance, debugging, or others.
+The workshop can be customized for the specific needs of your team to cover topics like performance, debugging, or others.
diff --git a/src/workshops/telemetry-for-rust-apis.md b/src/workshops/telemetry-for-rust-apis.md
index 969c4b8825..bf012f146d 100644
--- a/src/workshops/telemetry-for-rust-apis.md
+++ b/src/workshops/telemetry-for-rust-apis.md
@@ -3,52 +3,42 @@ title: "You can't fix what you can't see: telemetry for Rust APIs"
 tags: "rust"
 format: "Workshop: 1 day"
 subtext: "Bookable for teams – on-site or remote"
-description:
-  <p>Your Rust application has finally been deployed to production! Nice! But is
-  it working? This workshop will introduce you to a comprehensive toolkit to
-  detect, troubleshoot and resolve issues in your Rust APIs.</p><p>This workshop
-  is designed for developers who are operating Rust services in production-like
-  environments, or are preparing to do so.</p>
+description: "This 1-day workshop will introduce you to a comprehensive toolkit to detect, troubleshoot and resolve issues in your Rust APIs. The workshop is designed for developers who are operating Rust services in production-like environments, or are preparing to do so."
+introduction: <p>Your Rust application has finally been deployed to production! Nice! But is it working? This workshop will introduce you to a comprehensive toolkit to detect, troubleshoot and resolve issues in your Rust APIs.</p> <p>This workshop is designed for developers who are operating Rust services in production-like environments, or are preparing to do so.</p>
 hero:
   color: purple
   image: "/assets/images/workshops/telemetry-for-rust-apis/header-background.jpg"
-  imageAlt:
-    "2 people in front of a notebook with 3 charts on the screen, only their
-    arms visible, one points at the screen"
+  imageAlt: "2 people in front of a notebook with 3 charts on the screen, only their arms visible, one points at the screen"
 og:
   image: /assets/images/workshops/telemetry-for-rust-apis/og-image.jpg
 topics:
   - title: Structured logging (tracing)
     text: >
-      An introduction to the <code>tracing</code> instrumentation library,
-      covering both how to instrument your code (capturing fields, log levels,
-      macros) and how to process the resulting telemetry data in your
-      application (subscriber configuration, logging levels, log filtering).
+      An introduction to the <code>tracing</code> instrumentation library, covering both how to instrument your code (capturing fields, log levels, macros) and how to process the resulting telemetry data in your application (subscriber configuration, logging levels, log filtering).
+
+
   - title: Error handling
     text: >
-      We will cover Rust’s <code>Error</code> trait, with a focus on the
-      information that can be retrieved and recorded in your logs; we will also
-      spend some time on logging patterns (e.g. when should an error be
-      logged?).
+      We will cover Rust’s <code>Error</code> trait, with a focus on the information that can be retrieved and recorded in your logs; we will also spend some time on logging patterns (e.g. when should an error be logged?).
+
+
   - title: Panic handling
     text: >
-      You should always manage to capture details about what went wrong, even if
-      it’s due to an uncaught panic rather than an error. We will review panic
-      hooks and integrate them in our <code>tracing</code> setup.
+      You should always manage to capture details about what went wrong, even if it’s due to an uncaught panic rather than an error. We will review panic hooks and integrate them in our <code>tracing</code> setup.
+
+
   - title: Metrics
     text: >
-      Structured logs are important, but they don’t tell the full story. We will
-      look at how to capture metric data using the <code>metrics</code> library,
-      as a tool for designing alarms as well troubleshooting faulty behaviour.
+      Structured logs are important, but they don’t tell the full story. We will look at how to capture metric data using the <code>metrics</code> library, as a tool for designing alarms as well troubleshooting faulty behaviour.
+
+
 leads:
   - name: Luca Palmieri
     title: Principal Engineering Consultant
     handle: algo_luca
     image: /assets/images/authors/algo_luca.jpg
     bio: >
-      Luca Palmieri builds technology products for a living. His current focus
-      is on backend development, software architecture and the Rust programming
-      language. He is the author of "Zero to Production in Rust".
+      Luca Palmieri builds technology products for a living. His current focus is on backend development, software architecture and the Rust programming language. He is the author of "Zero to Production in Rust".
 ---
 
 <!--break-->
diff --git a/src/workshops/testing-svelte-sveltekit-applications.md b/src/workshops/testing-svelte-sveltekit-applications.md
new file mode 100644
index 0000000000..2a01c82150
--- /dev/null
+++ b/src/workshops/testing-svelte-sveltekit-applications.md
@@ -0,0 +1,49 @@
+---
+title: "Testing Svelte & SvelteKit applications"
+tags: "svelte"
+format: "Workshop: 1 day"
+subtext: "Bookable for teams – on-site or remote"
+description: "This 1-day workshop is a complete introduction to testing Svelte and SvelteKit applications. It covers both guidance on what to test and how, as well as concrete techniques for writing tests that are fast, stable, and easy to maintain."
+introduction: "<p>Testing is a critical part of building any non-trivial application – without automatic test coverage, you can't really know whether things work as expected or you're breaking things as you continue building out an application. This workshop covers both guidance on what to test and how, as well as concrete techniques for writing tests that are fast, stable, and easy to maintain.</p>"
+hero:
+  color: purple
+  image: "/assets/images/workshops/testing-svelte-sveltekit-applications/classroom.jpg"
+  imageAlt: "Photo of a classroom with benches facing a blackboard"
+og:
+  image: /assets/images/workshops/testing-svelte-sveltekit-applications/og-image.jpg
+topics:
+  - title: The Testing Pyramid
+    text: >
+      We'll start off with some basic theory, talking about the testing pyramid. The testing pyramid gives guidance on what kind of test to use for testing what aspect of a system as well as how much coverage is required at what level of the pyramid.
+
+
+  - title: Unit tests with Vitest
+    text: >
+      Unit tests are at the lowest level of the testing pyramid so we'll start with those.
+
+
+  - title: Component tests with Vitest, Testing Library and Storybook
+    text: >
+      Next, we progress to writing components tests with Vitest and testing library. We'll look into writing functional tests for Svelte components as well as explore techniques like snapshot testing and visual testing with Storybook.
+
+
+  - title: End-to-end tests with Playwright
+    text: >
+      End-to-end tests sit at the top of the testing pyramid and we'll end with those. We'll look into writing tests that cover the entirety of our isomorphic SvelteKit application with Playwright.
+
+
+  - title: Full-stack application testing and data
+    text: >
+      Tests require a well-known state that the test runs against so we can make assertions on the result. That can be challenging, in particular for end-to-end tests where the state might need to exist outside of the SvelteKit application. We'll look at typical challenges as well as techniques 
+
+
+leads:
+  - name: Paolo Ricciuti
+    title: Senior Frontend Engineer
+    handle: paoloricciuti
+    image: /assets/images/authors/paoloricciuti.jpg
+    bio: >
+      Paolo is a huge nerd and Svelte maintainer. He's also one of the creators of <a href="https://sveltelab.dev">sveltelab.dev</a> - a REPL for SvelteKit.
+---
+
+<!--break-->
diff --git a/static/assets/images/authors/hdoordt.jpg b/static/assets/images/authors/hdoordt.jpg
new file mode 100644
index 0000000000..a052659eed
Binary files /dev/null and b/static/assets/images/authors/hdoordt.jpg differ
diff --git a/static/assets/images/blog/og-image.jpg b/static/assets/images/blog/og-image.jpg
index 8111fef79a..88a7f1a10f 100644
Binary files a/static/assets/images/blog/og-image.jpg and b/static/assets/images/blog/og-image.jpg differ
diff --git a/static/assets/images/calendar/2024-10-03-viteconf-24/viteconf-logo.png b/static/assets/images/calendar/2024-10-03-viteconf-24/viteconf-logo.png
new file mode 100644
index 0000000000..8de47e620c
Binary files /dev/null and b/static/assets/images/calendar/2024-10-03-viteconf-24/viteconf-logo.png differ
diff --git a/static/assets/images/calendar/2024-11-19-embereuropeq4-remote/embereurope.png b/static/assets/images/calendar/2024-11-19-embereuropeq4-remote/embereurope.png
new file mode 100644
index 0000000000..4730a8dd9a
Binary files /dev/null and b/static/assets/images/calendar/2024-11-19-embereuropeq4-remote/embereurope.png differ
diff --git a/static/assets/images/calendar/2024-11-19-embereuropeq4-remote/logo.png b/static/assets/images/calendar/2024-11-19-embereuropeq4-remote/logo.png
new file mode 100644
index 0000000000..7f4a5ced8a
Binary files /dev/null and b/static/assets/images/calendar/2024-11-19-embereuropeq4-remote/logo.png differ
diff --git a/static/assets/images/calendar/2024-11-27-weyweyweb/weyweyweb-logo.png b/static/assets/images/calendar/2024-11-27-weyweyweb/weyweyweb-logo.png
new file mode 100644
index 0000000000..42ffbe3cba
Binary files /dev/null and b/static/assets/images/calendar/2024-11-27-weyweyweb/weyweyweb-logo.png differ
diff --git a/static/assets/images/calendar/2024-11-28-rust-hack-and-learn-with-mainmatter-and-otto/rust.png b/static/assets/images/calendar/2024-11-28-rust-hack-and-learn-with-mainmatter-and-otto/rust.png
new file mode 100644
index 0000000000..ba88399e60
Binary files /dev/null and b/static/assets/images/calendar/2024-11-28-rust-hack-and-learn-with-mainmatter-and-otto/rust.png differ
diff --git a/static/assets/images/calendar/2025-05-05-rust-workshop-adc/rust.png b/static/assets/images/calendar/2025-05-05-rust-workshop-adc/rust.png
new file mode 100644
index 0000000000..ba88399e60
Binary files /dev/null and b/static/assets/images/calendar/2025-05-05-rust-workshop-adc/rust.png differ
diff --git a/static/assets/images/calendar/2025-05-08-svelte-summit/svelte.png b/static/assets/images/calendar/2025-05-08-svelte-summit/svelte.png
new file mode 100644
index 0000000000..3716f76317
Binary files /dev/null and b/static/assets/images/calendar/2025-05-08-svelte-summit/svelte.png differ
diff --git a/static/assets/images/calendar/2025-05-08-svelte-summit/venue.jpg b/static/assets/images/calendar/2025-05-08-svelte-summit/venue.jpg
new file mode 100644
index 0000000000..e2b75f8710
Binary files /dev/null and b/static/assets/images/calendar/2025-05-08-svelte-summit/venue.jpg differ
diff --git a/static/assets/images/calendar/2025-10-09-eurorust/paris.jpg b/static/assets/images/calendar/2025-10-09-eurorust/paris.jpg
new file mode 100644
index 0000000000..4aef7a2d66
Binary files /dev/null and b/static/assets/images/calendar/2025-10-09-eurorust/paris.jpg differ
diff --git a/static/assets/images/calendar/2025-10-09-eurorust/rust.png b/static/assets/images/calendar/2025-10-09-eurorust/rust.png
new file mode 100644
index 0000000000..ba88399e60
Binary files /dev/null and b/static/assets/images/calendar/2025-10-09-eurorust/rust.png differ
diff --git a/static/assets/images/clutch/awards/arts-entertainment.png b/static/assets/images/clutch/awards/arts-entertainment.png
new file mode 100644
index 0000000000..06b6e33d9f
Binary files /dev/null and b/static/assets/images/clutch/awards/arts-entertainment.png differ
diff --git a/static/assets/images/clutch/awards/ember.png b/static/assets/images/clutch/awards/ember.png
new file mode 100644
index 0000000000..788c7c179c
Binary files /dev/null and b/static/assets/images/clutch/awards/ember.png differ
diff --git a/static/assets/images/clutch/awards/financial.png b/static/assets/images/clutch/awards/financial.png
new file mode 100644
index 0000000000..824f86e9a8
Binary files /dev/null and b/static/assets/images/clutch/awards/financial.png differ
diff --git a/static/assets/images/clutch/awards/logistics.png b/static/assets/images/clutch/awards/logistics.png
new file mode 100644
index 0000000000..f288cf9ebc
Binary files /dev/null and b/static/assets/images/clutch/awards/logistics.png differ
diff --git a/static/assets/images/clutch/awards/node.png b/static/assets/images/clutch/awards/node.png
new file mode 100644
index 0000000000..035aaff2eb
Binary files /dev/null and b/static/assets/images/clutch/awards/node.png differ
diff --git a/static/assets/images/clutch/awards/rust.png b/static/assets/images/clutch/awards/rust.png
new file mode 100644
index 0000000000..4521c8fdae
Binary files /dev/null and b/static/assets/images/clutch/awards/rust.png differ
diff --git a/static/assets/images/clutch/awards/staff-aug.png b/static/assets/images/clutch/awards/staff-aug.png
new file mode 100644
index 0000000000..43bcc28dca
Binary files /dev/null and b/static/assets/images/clutch/awards/staff-aug.png differ
diff --git a/static/assets/images/elixir/lp-elixir-phoenix-consulting-og-image.jpg b/static/assets/images/elixir/lp-elixir-phoenix-consulting-og-image.jpg
deleted file mode 100644
index 86e70a4480..0000000000
Binary files a/static/assets/images/elixir/lp-elixir-phoenix-consulting-og-image.jpg and /dev/null differ
diff --git a/static/assets/images/elixir/og-image.png b/static/assets/images/elixir/og-image.png
new file mode 100644
index 0000000000..5bece6e441
Binary files /dev/null and b/static/assets/images/elixir/og-image.png differ
diff --git a/static/assets/images/ember-initiative/embroider-vite-upgrade/og-image.png b/static/assets/images/ember-initiative/embroider-vite-upgrade/og-image.png
index c20fad0506..6827497945 100644
Binary files a/static/assets/images/ember-initiative/embroider-vite-upgrade/og-image.png and b/static/assets/images/ember-initiative/embroider-vite-upgrade/og-image.png differ
diff --git a/static/assets/images/ember/lp-ember-consulting-og-image.jpg b/static/assets/images/ember/lp-ember-consulting-og-image.jpg
deleted file mode 100644
index 994bc4b789..0000000000
Binary files a/static/assets/images/ember/lp-ember-consulting-og-image.jpg and /dev/null differ
diff --git a/static/assets/images/ember/og-image.png b/static/assets/images/ember/og-image.png
new file mode 100644
index 0000000000..140c84f1a7
Binary files /dev/null and b/static/assets/images/ember/og-image.png differ
diff --git a/static/assets/images/hero/Regensburg.png b/static/assets/images/hero/Regensburg.png
new file mode 100644
index 0000000000..eb0818b97d
Binary files /dev/null and b/static/assets/images/hero/Regensburg.png differ
diff --git a/static/assets/images/hero/hamburg.png b/static/assets/images/hero/hamburg.png
new file mode 100644
index 0000000000..4a444e602c
Binary files /dev/null and b/static/assets/images/hero/hamburg.png differ
diff --git a/static/assets/images/hero/kids.jpg b/static/assets/images/hero/kids.jpg
new file mode 100644
index 0000000000..24476ad942
Binary files /dev/null and b/static/assets/images/hero/kids.jpg differ
diff --git a/static/assets/images/hero/table-soccer.jpg b/static/assets/images/hero/table-soccer.jpg
new file mode 100644
index 0000000000..7a0c38094a
Binary files /dev/null and b/static/assets/images/hero/table-soccer.jpg differ
diff --git a/static/assets/images/hero/viteconf-24.png b/static/assets/images/hero/viteconf-24.png
new file mode 100644
index 0000000000..46a7036f8f
Binary files /dev/null and b/static/assets/images/hero/viteconf-24.png differ
diff --git a/static/assets/images/hero/weyweyweb-malaga-spain.jpg b/static/assets/images/hero/weyweyweb-malaga-spain.jpg
new file mode 100644
index 0000000000..2607dcdb17
Binary files /dev/null and b/static/assets/images/hero/weyweyweb-malaga-spain.jpg differ
diff --git a/static/assets/images/logos/monochrome/crabnebula.svg b/static/assets/images/logos/monochrome/crabnebula.svg
new file mode 100644
index 0000000000..c22fafa8d8
--- /dev/null
+++ b/static/assets/images/logos/monochrome/crabnebula.svg
@@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg width="100%" height="100%" viewBox="0 0 171 26" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
+    <g transform="matrix(1,0,0,1,-15,-37)">
+        <g id="crabnebula" transform="matrix(1,0,0,1,15,37)">
+            <path id="Path" d="M42.926,22C41.693,22 40.534,21.763 39.448,21.289C38.361,20.815 37.413,20.169 36.602,19.351C35.808,18.534 35.175,17.586 34.705,16.507C34.235,15.411 34,14.243 34,13C34,11.757 34.235,10.597 34.705,9.518C35.175,8.422 35.808,7.466 36.602,6.649C37.413,5.831 38.361,5.185 39.448,4.711C40.534,4.237 41.693,4 42.926,4C43.817,4 44.669,4.114 45.479,4.343C46.306,4.572 47.06,4.899 47.741,5.324C48.438,5.733 49.062,6.232 49.614,6.82C50.165,7.392 50.627,8.038 51,8.757L47.595,10.621C47.109,9.738 46.476,9.044 45.698,8.537C44.936,8.03 44.012,7.777 42.926,7.777C42.212,7.777 41.547,7.916 40.931,8.193C40.331,8.471 39.804,8.856 39.351,9.346C38.897,9.82 38.54,10.376 38.28,11.014C38.021,11.635 37.891,12.297 37.891,13C37.891,13.703 38.021,14.373 38.28,15.011C38.54,15.632 38.897,16.188 39.351,16.679C39.804,17.153 40.331,17.529 40.931,17.806C41.547,18.084 42.212,18.223 42.926,18.223C44.012,18.223 44.936,17.97 45.698,17.463C46.476,16.956 47.109,16.262 47.595,15.379L51,17.243C50.627,17.962 50.165,18.616 49.614,19.204C49.062,19.777 48.438,20.275 47.741,20.7C47.06,21.109 46.306,21.428 45.479,21.657C44.669,21.886 43.817,22 42.926,22Z" style="fill-rule:nonzero;"/>
+            <path id="Path1" serif:id="Path" d="M53,10.142L56.787,10.142L56.787,11.921C56.988,11.399 57.355,10.949 57.89,10.569C58.442,10.19 59.069,10 59.771,10C59.955,10 60.147,10.008 60.348,10.024C60.549,10.04 60.766,10.079 61,10.142L61,13.771C60.716,13.676 60.44,13.605 60.172,13.557C59.905,13.51 59.621,13.486 59.32,13.486C58.501,13.486 57.874,13.755 57.439,14.292C57.004,14.83 56.787,15.526 56.787,16.379L56.787,22L53,22L53,10.142Z" style="fill-rule:nonzero;"/>
+            <path id="Shape" d="M66.364,22C65.609,22 64.9,21.839 64.237,21.517C63.59,21.195 63.027,20.766 62.549,20.23C62.071,19.678 61.694,19.042 61.416,18.322C61.139,17.586 61,16.812 61,16C61,15.188 61.139,14.421 61.416,13.701C61.694,12.966 62.071,12.329 62.549,11.793C63.027,11.241 63.59,10.805 64.237,10.483C64.9,10.161 65.609,10 66.364,10C66.749,10 67.104,10.046 67.428,10.138C67.767,10.215 68.067,10.322 68.329,10.46C68.607,10.598 68.838,10.751 69.023,10.92C69.223,11.088 69.385,11.249 69.509,11.402L69.509,10.253L73,10.253L73,21.747L69.509,21.747L69.509,20.598C69.385,20.751 69.223,20.912 69.023,21.08C68.838,21.249 68.607,21.402 68.329,21.54C68.067,21.678 67.767,21.785 67.428,21.862C67.104,21.954 66.749,22 66.364,22ZM67.15,18.851C67.936,18.851 68.568,18.582 69.046,18.046C69.539,17.51 69.786,16.828 69.786,16C69.786,15.172 69.539,14.49 69.046,13.954C68.568,13.418 67.936,13.149 67.15,13.149C66.364,13.149 65.724,13.418 65.231,13.954C64.753,14.49 64.514,15.172 64.514,16C64.514,16.828 64.753,17.51 65.231,18.046C65.724,18.582 66.364,18.851 67.15,18.851Z" style="fill-rule:nonzero;"/>
+            <path id="Shape1" serif:id="Shape" d="M84.636,22C84.251,22 83.888,21.953 83.549,21.858C83.225,21.779 82.925,21.669 82.647,21.527C82.385,21.385 82.154,21.227 81.954,21.054C81.753,20.88 81.599,20.715 81.491,20.557L81.491,21.74L78,21.74L78,4L81.491,4L81.491,11.096C81.599,10.938 81.753,10.773 81.954,10.599C82.154,10.426 82.385,10.268 82.647,10.126C82.925,9.984 83.225,9.874 83.549,9.795C83.888,9.7 84.251,9.653 84.636,9.653C85.391,9.653 86.093,9.819 86.74,10.15C87.403,10.481 87.973,10.93 88.451,11.498C88.929,12.05 89.306,12.704 89.584,13.461C89.861,14.202 90,14.991 90,15.826C90,16.662 89.861,17.459 89.584,18.216C89.306,18.957 88.929,19.611 88.451,20.179C87.973,20.731 87.403,21.172 86.74,21.503C86.093,21.834 85.391,22 84.636,22ZM83.85,18.76C84.636,18.76 85.268,18.484 85.746,17.932C86.239,17.38 86.486,16.678 86.486,15.826C86.486,14.975 86.239,14.273 85.746,13.721C85.268,13.169 84.636,12.893 83.85,12.893C83.064,12.893 82.424,13.169 81.931,13.721C81.453,14.273 81.214,14.975 81.214,15.826C81.214,16.678 81.453,17.38 81.931,17.932C82.424,18.484 83.064,18.76 83.85,18.76Z" style="fill-rule:nonzero;"/>
+            <path id="Path2" serif:id="Path" d="M103.799,22L95.715,11.489L95.715,22L92,22L92,5L95.201,5L103.262,15.511L103.262,5L107,5L107,22L103.799,22Z" style="fill-rule:nonzero;"/>
+            <path id="Shape2" serif:id="Shape" d="M115.234,22C114.375,22 113.562,21.862 112.797,21.586C112.047,21.31 111.391,20.912 110.828,20.391C110.266,19.87 109.82,19.241 109.492,18.506C109.164,17.755 109,16.92 109,16C109,15.142 109.148,14.352 109.445,13.632C109.758,12.897 110.188,12.261 110.734,11.724C111.297,11.188 111.953,10.766 112.703,10.46C113.453,10.153 114.274,10 115.164,10C115.93,10 116.664,10.123 117.367,10.368C118.086,10.598 118.711,10.95 119.242,11.425C119.773,11.885 120.195,12.467 120.508,13.172C120.836,13.862 121,14.674 121,15.609C121,15.762 120.992,15.939 120.977,16.138C120.977,16.322 120.961,16.552 120.93,16.828L112.422,16.828C112.531,17.517 112.867,18.031 113.43,18.368C113.992,18.69 114.609,18.851 115.281,18.851C115.969,18.851 116.555,18.72 117.039,18.46C117.539,18.184 117.898,17.877 118.117,17.54L120.742,19.471C120.195,20.237 119.445,20.851 118.492,21.31C117.555,21.77 116.469,22 115.234,22ZM117.484,14.552C117.328,13.939 117.016,13.502 116.547,13.241C116.078,12.966 115.586,12.828 115.07,12.828C114.805,12.828 114.539,12.858 114.274,12.919C114.008,12.981 113.758,13.08 113.523,13.218C113.289,13.356 113.078,13.533 112.891,13.747C112.719,13.962 112.594,14.23 112.516,14.552L117.484,14.552Z" style="fill-rule:nonzero;"/>
+            <path id="Shape3" serif:id="Shape" d="M130.636,22C130.25,22 129.888,21.953 129.549,21.858C129.225,21.779 128.925,21.669 128.647,21.527C128.385,21.385 128.154,21.227 127.954,21.054C127.753,20.88 127.599,20.715 127.491,20.557L127.491,21.74L124,21.74L124,4L127.491,4L127.491,11.096C127.599,10.938 127.753,10.773 127.954,10.599C128.154,10.426 128.385,10.268 128.647,10.126C128.925,9.984 129.225,9.874 129.549,9.795C129.888,9.7 130.25,9.653 130.636,9.653C131.391,9.653 132.092,9.819 132.74,10.15C133.403,10.481 133.973,10.93 134.451,11.498C134.929,12.05 135.306,12.704 135.584,13.461C135.861,14.202 136,14.991 136,15.826C136,16.662 135.861,17.459 135.584,18.216C135.306,18.957 134.929,19.611 134.451,20.179C133.973,20.731 133.403,21.172 132.74,21.503C132.092,21.834 131.391,22 130.636,22ZM129.85,18.76C130.636,18.76 131.268,18.484 131.746,17.932C132.239,17.38 132.486,16.678 132.486,15.826C132.486,14.975 132.239,14.273 131.746,13.721C131.268,13.169 130.636,12.893 129.85,12.893C129.064,12.893 128.424,13.169 127.931,13.721C127.453,14.273 127.214,14.975 127.214,15.826C127.214,16.678 127.453,17.38 127.931,17.932C128.424,18.484 129.064,18.76 129.85,18.76Z" style="fill-rule:nonzero;"/>
+            <path id="Path3" serif:id="Path" d="M142.795,22C141.222,22 140.03,21.515 139.218,20.544C138.406,19.573 138,18.29 138,16.693L138,10L141.831,10L141.831,16.082C141.831,16.943 141.975,17.609 142.262,18.078C142.566,18.548 143.074,18.783 143.784,18.783C144.512,18.783 145.087,18.54 145.509,18.055C145.949,17.569 146.169,16.787 146.169,15.706L146.169,10L150,10L150,21.742L146.169,21.742L146.169,20.544C145.865,20.951 145.433,21.295 144.875,21.577C144.317,21.859 143.624,22 142.795,22Z" style="fill-rule:nonzero;"/>
+            <path id="Path4" serif:id="Path" d="M153,4L157,4L157,22L153,22L153,4Z" style="fill-rule:nonzero;"/>
+            <path id="Shape4" serif:id="Shape" d="M164.364,22C163.609,22 162.9,21.839 162.237,21.517C161.59,21.195 161.027,20.766 160.549,20.23C160.072,19.678 159.694,19.042 159.417,18.322C159.138,17.586 159,16.812 159,16C159,15.188 159.138,14.421 159.417,13.701C159.694,12.966 160.072,12.329 160.549,11.793C161.027,11.241 161.59,10.805 162.237,10.483C162.9,10.161 163.609,10 164.364,10C164.75,10 165.104,10.046 165.428,10.138C165.767,10.215 166.068,10.322 166.33,10.46C166.607,10.598 166.839,10.751 167.024,10.92C167.224,11.088 167.385,11.249 167.508,11.402L167.508,10.253L171,10.253L171,21.747L167.508,21.747L167.508,20.598C167.385,20.751 167.224,20.912 167.024,21.08C166.839,21.249 166.607,21.402 166.33,21.54C166.068,21.678 165.767,21.785 165.428,21.862C165.104,21.954 164.75,22 164.364,22ZM165.15,18.851C165.936,18.851 166.568,18.582 167.047,18.046C167.539,17.51 167.787,16.828 167.787,16C167.787,15.172 167.539,14.49 167.047,13.954C166.568,13.418 165.936,13.149 165.15,13.149C164.364,13.149 163.724,13.418 163.232,13.954C162.753,14.49 162.515,15.172 162.515,16C162.515,16.828 162.753,17.51 163.232,18.046C163.724,18.582 164.364,18.851 165.15,18.851Z" style="fill-rule:nonzero;"/>
+            <path id="Shape5" serif:id="Shape" d="M10.589,5.049C6.404,10.718 6.428,17.962 10.643,21.228C11.751,22.086 13.038,22.584 14.409,22.749C10.519,25.996 6.037,27.003 3.011,24.889C-1.139,21.989 -0.98,14.315 3.367,7.749C6.996,2.266 12.397,-0.71 16.497,0.145C14.331,1.129 12.253,2.795 10.589,5.049ZM16.088,12.29C14.134,14.187 11.9,15.449 10.013,15.869C11.127,19.959 15.408,20.273 15.408,20.273C15.408,20.273 17.956,19.671 19.88,15.23C21.464,11.573 21.326,7.794 19.729,5.871C19.597,7.729 18.293,10.149 16.088,12.29Z"/>
+        </g>
+    </g>
+</svg>
diff --git a/static/assets/images/logos/monochrome/helsing.svg b/static/assets/images/logos/monochrome/helsing.svg
new file mode 100644
index 0000000000..fa2c3e2109
--- /dev/null
+++ b/static/assets/images/logos/monochrome/helsing.svg
@@ -0,0 +1,24 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg width="100%" height="100%" viewBox="0 0 56 100" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
+    <g transform="matrix(1,0,0,1,-61.2146,-6.04102)">
+        <rect x="98.271" y="6.041" width="18.528" height="75.199" style="fill-rule:nonzero;"/>
+        <rect x="61.215" y="6.041" width="18.528" height="75.199" style="fill-rule:nonzero;"/>
+        <rect x="85.919" y="31.104" width="6.176" height="25.062" style="fill-rule:nonzero;"/>
+        <path d="M71.311,90.443L71.311,102.768L69.578,102.768L69.578,97.17L63.099,97.17L63.099,102.768L61.366,102.768L61.366,90.443L63.099,90.443L63.099,95.67L69.578,95.67L69.578,90.443L71.311,90.443Z" style="fill-rule:nonzero;"/>
+        <g>
+            <path d="M74.708,97.389L79.977,97.389C79.935,96.096 79.055,94.803 77.391,94.803C75.823,94.789 74.777,95.725 74.708,97.389ZM73.016,98.201C73.016,95.312 74.86,93.455 77.404,93.455C80.224,93.455 81.834,95.807 81.627,98.682L74.708,98.682C74.708,100.498 75.933,101.612 77.432,101.612C78.862,101.612 79.523,101.007 79.908,100.099L81.517,100.099C81.077,101.681 79.743,102.974 77.473,102.974C74.516,102.974 73.016,100.91 73.016,98.201Z" style="fill-rule:nonzero;"/>
+        </g>
+        <rect x="83.25" y="90.443" width="1.554" height="12.325" style="fill-rule:nonzero;"/>
+        <g>
+            <path d="M92.343,96.289C92.095,95.202 91.256,94.775 90.114,94.775C89.138,94.775 88.134,95.106 88.134,95.931C88.134,96.66 88.643,96.963 89.592,97.169L90.885,97.43C92.604,97.774 94.076,98.393 94.076,100.154C94.076,101.956 92.439,103.001 90.293,103.001C87.831,103.001 86.469,101.419 86.304,99.824L87.941,99.824C88.189,100.993 88.918,101.694 90.348,101.694C91.586,101.694 92.549,101.185 92.549,100.333C92.549,99.411 91.682,99.026 90.637,98.82L89.275,98.544C87.969,98.269 86.607,97.705 86.607,96.013C86.607,94.39 88.244,93.469 90.334,93.469C92.37,93.469 93.718,94.569 94.007,96.316L92.343,96.289Z" style="fill-rule:nonzero;"/>
+        </g>
+        <path d="M97.336,102.768L95.781,102.768L95.781,93.621L97.336,93.621L97.336,102.768ZM97.336,92.314L95.781,92.314L95.781,90.443L97.336,90.443L97.336,92.314Z" style="fill-rule:nonzero;"/>
+        <g>
+            <path d="M101.132,94.996C101.655,94.129 102.549,93.455 104.089,93.455C106.304,93.455 107.102,94.886 107.102,96.976L107.102,102.767L105.548,102.767L105.548,97.444C105.548,96.027 105.3,94.817 103.539,94.817C102.04,94.817 101.132,95.849 101.132,97.816L101.132,102.781L99.592,102.781L99.592,93.634L101.146,93.634L101.146,94.996L101.132,94.996Z" style="fill-rule:nonzero;"/>
+        </g>
+        <g>
+            <path d="M112.769,94.789C111.118,94.789 110.293,95.959 110.293,98.036C110.293,100.126 111.132,101.296 112.769,101.296C114.144,101.296 115.355,100.36 115.355,98.036C115.369,95.725 114.158,94.789 112.769,94.789ZM115.3,93.62L116.854,93.62L116.854,101.529C116.854,103.4 116.51,104.157 115.988,104.734C115.327,105.505 114.186,105.931 112.838,105.931C110.761,105.931 109.371,104.968 109.069,103.125L110.719,103.125C110.926,103.95 111.421,104.569 112.851,104.569C113.691,104.569 114.31,104.322 114.722,103.895C115.066,103.524 115.314,103.111 115.314,101.873L115.314,101.007C114.75,101.983 113.869,102.589 112.398,102.589C110.238,102.589 108.629,100.952 108.629,98.022C108.629,95.092 110.252,93.455 112.398,93.455C113.856,93.455 114.75,94.088 115.314,95.064L115.314,93.62L115.3,93.62Z" style="fill-rule:nonzero;"/>
+        </g>
+    </g>
+</svg>
diff --git a/static/assets/images/logos/monochrome/oreilly.svg b/static/assets/images/logos/monochrome/oreilly.svg
new file mode 100644
index 0000000000..935f090569
--- /dev/null
+++ b/static/assets/images/logos/monochrome/oreilly.svg
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg width="100%" height="100%" viewBox="0 0 141 25" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
+    <g transform="matrix(1,0,0,1,-30,-37)">
+        <g id="oreilly" transform="matrix(1,0,0,1,30,37)">
+            <path id="Path" d="M71,4.815L71,1L55,1L55,24L71,24L71,20.185L58.846,20.185L58.846,14.408L70.383,14.408L70.383,10.592L58.846,10.592L58.846,4.815L71,4.815Z" style="fill-rule:nonzero;"/>
+            <path id="Path1" serif:id="Path" d="M83,24L83,1L86.869,1L86.869,20.185L98,20.185L98,24L83,24Z" style="fill-rule:nonzero;"/>
+            <path id="Path2" serif:id="Path" d="M101,24L101,1L104.841,1L104.841,20.185L116,20.185L116,24L101,24Z" style="fill-rule:nonzero;"/>
+            <path id="Path3" serif:id="Path" d="M75,1L79,1L79,24L75,24L75,1Z" style="fill-rule:nonzero;"/>
+            <path id="Shape" d="M6.284,6.505C4.777,8.056 3.859,10.174 3.859,12.519C3.859,14.864 4.777,16.982 6.284,18.533C7.791,20.083 9.849,21.029 12.127,21.029C14.406,21.029 16.464,20.083 17.97,18.533C19.44,16.944 20.359,14.864 20.359,12.519C20.359,10.174 19.44,8.056 17.934,6.505C16.427,4.955 14.369,4.009 12.09,4.009C9.812,4.009 7.791,4.955 6.284,6.505M0,12.519C0,5.635 5.439,0.038 12.127,0.038C18.816,0.038 24.254,5.635 24.254,12.519C24.254,19.402 18.816,25 12.127,25C5.402,24.962 0,19.402 0,12.519M36.235,10.401L36.235,4.387L44.062,4.387C45.679,4.387 46.965,5.711 46.965,7.375C46.965,9.039 45.679,10.363 44.062,10.363L36.235,10.363L36.235,10.401ZM45.973,14.107C48.766,13.238 50.824,10.59 50.824,7.413C50.824,3.555 47.774,0.416 44.025,0.416L32.339,0.416L32.339,24.357L36.235,24.357L36.235,14.372L41.637,14.372L47.48,24.357L52,24.357L45.973,14.107ZM29.583,2.95C29.583,4.576 28.297,5.9 26.717,5.9C25.136,5.9 23.85,4.576 23.85,2.95C23.85,1.324 25.136,0 26.717,0C28.334,0.038 29.583,1.324 29.583,2.95" style="fill-rule:nonzero;"/>
+            <path id="Path4" serif:id="Path" d="M134,1L129.153,1L123.019,9.539L116.847,1L112,1L121.012,13.499L121.012,24L124.988,24L124.988,13.536L134,1Z" style="fill-rule:nonzero;"/>
+            <g id="Group" transform="matrix(1,0,0,1,136,0)">
+                <path id="Shape1" serif:id="Shape" d="M2.5,4.615C1.346,4.615 0.385,3.686 0.385,2.5C0.385,1.346 1.314,0.385 2.5,0.385C3.654,0.385 4.615,1.314 4.615,2.5C4.615,3.654 3.686,4.615 2.5,4.615M2.5,0C1.122,0 0,1.122 0,2.5C0,3.878 1.122,5 2.5,5C3.878,5 5,3.878 5,2.5C5,1.122 3.878,0 2.5,0" style="fill-rule:nonzero;"/>
+                <path id="Shape2" serif:id="Shape" d="M1.891,1.635L2.885,1.635C3.077,1.635 3.205,1.763 3.205,1.955C3.205,2.147 3.077,2.276 2.885,2.276L1.891,2.276L1.891,1.635ZM3.622,1.955C3.622,1.538 3.301,1.218 2.885,1.218L1.474,1.218L1.474,3.782L1.891,3.782L1.891,2.724L2.596,2.724L3.109,3.782L3.59,3.782L3.077,2.692C3.397,2.596 3.622,2.308 3.622,1.955Z" style="fill-rule:nonzero;"/>
+            </g>
+        </g>
+    </g>
+</svg>
diff --git a/static/assets/images/logos/terminal49.svg b/static/assets/images/logos/terminal49.svg
new file mode 100644
index 0000000000..76aeb9ade1
--- /dev/null
+++ b/static/assets/images/logos/terminal49.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 126 36" class="h-9 w-auto pp-md:h-[33px] fill-white"><g fill="currentColor" clip-path="url(#logo_inline_svg__a)"><path d="M45.469 14.116V24.5h-2.63V14.116h-4.28V11.8h11.168v2.315H45.47Zm5.066 5.14h3.55c-.058-1.068-.605-1.766-1.723-1.766-1.06 0-1.757.644-1.827 1.766Zm0 1.646c.058 1.085.72 1.783 1.844 1.783.865 0 1.433-.355 1.62-.962l2.505.112c-.306 1.662-1.996 2.85-4.06 2.85-2.684 0-4.548-1.749-4.548-4.566 0-2.835 1.86-4.568 4.483-4.568 2.53 0 4.208 1.634 4.208 4.37v.986h-6.052v-.005Zm12.581-2.871c-1.433 0-2.336.813-2.336 2.021V24.5h-2.486v-8.775h2.403v.998c.373-.578 1.077-1.085 2.419-1.085v2.393Zm14.913 1.085v5.388h-2.485v-4.897c0-1.118-.518-1.75-1.47-1.75-.883 0-1.434.582-1.53 1.461V24.5h-2.493v-4.897c0-1.118-.526-1.75-1.434-1.75-.986 0-1.586.714-1.586 1.77v4.869h-2.494v-8.776h2.353v.904c.39-.61 1.11-1.073 2.316-1.073 1.213 0 2.183.491 2.758 1.395.518-.797 1.384-1.395 2.71-1.395 2.025.008 3.355 1.345 3.355 3.569Zm1.802 5.384h2.486v-8.775H79.83V24.5Zm2.743-11.643c0 .813-.663 1.473-1.504 1.473-.833 0-1.479-.66-1.479-1.473 0-.833.68-1.489 1.479-1.489a1.478 1.478 0 0 1 1.504 1.49Zm9.726 6.276V24.5h-2.485v-4.893c0-1.118-.605-1.75-1.554-1.75-.986 0-1.64.714-1.64 1.766V24.5h-2.486v-8.775h2.345v.9c.398-.607 1.172-1.07 2.37-1.07 2.042 0 3.45 1.304 3.45 3.578Zm5.315 1.918c-.762.037-1.288.289-1.288.92 0 .582.43.796 1.019.796.915 0 1.595-.49 1.595-1.427v-.376l-1.326.087Zm3.811-1.968V24.5h-2.402v-.718c-.493.508-1.239.904-2.25.904-1.773 0-2.928-.904-2.928-2.596 0-1.95 1.648-2.578 3.529-2.665l1.57-.086V19c0-.887-.373-1.357-1.14-1.357-.849 0-1.23.578-1.23 1.155L94.09 18.7c0-1.547 1.417-3.14 3.683-3.14 2.361-.003 3.653 1.218 3.653 3.524Zm1.918 5.417h2.49V11.31h-2.49V24.5Zm9.611-4.489v-4.58l-3.107 4.58h3.107Zm4.006 0v1.803h-1.997v2.665h-1.988v-2.665h-5.348v-1.663l5.638-8.366h1.698v8.23h1.997v-.004Zm6.495-2.578c.299-.413.469-.92.469-1.58 0-1.506-.949-2.447-2.324-2.447-1.343 0-2.316.94-2.316 2.447 0 1.51.969 2.392 2.316 2.392.799.005 1.445-.268 1.855-.812ZM126 15.787c0 1.068-.348 1.902-.907 2.677l-4.404 6.011h-2.419l3.293-4.464c-2.485-.033-4.312-1.716-4.312-4.224 0-2.546 1.877-4.176 4.362-4.176 2.51 0 4.387 1.63 4.387 4.176ZM15.638.022 0 9.004v17.984l10.758 6.188v-4.724L4.11 24.628v-13.26l11.53-6.626 11.528 6.626v13.26l-6.657 3.824v4.724l10.758-6.188V9.004"></path><path d="m24.24 13.085-8.6-4.951-8.609 4.95v4.72l6.554-3.766v20.76l2.054 1.176 2.055-1.176v-20.76l6.545 3.766"></path></g><defs><clipPath id="logo_inline_svg__a"><path fill="currentColor" d="M0 0h126v36H0z"></path></clipPath></defs></svg>
\ No newline at end of file
diff --git a/static/assets/images/og-image.jpg b/static/assets/images/og-image.jpg
index e5499767d8..72544d8ee9 100644
Binary files a/static/assets/images/og-image.jpg and b/static/assets/images/og-image.jpg differ
diff --git a/static/assets/images/photos/travel-hero.jpg b/static/assets/images/photos/travel-hero.jpg
new file mode 100644
index 0000000000..0c2816c7b0
Binary files /dev/null and b/static/assets/images/photos/travel-hero.jpg differ
diff --git a/static/assets/images/photos/travel-whitepaper-cover.jpg b/static/assets/images/photos/travel-whitepaper-cover.jpg
new file mode 100644
index 0000000000..db3a388754
Binary files /dev/null and b/static/assets/images/photos/travel-whitepaper-cover.jpg differ
diff --git a/static/assets/images/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino/header.jpg b/static/assets/images/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino/header.jpg
new file mode 100644
index 0000000000..945739111f
Binary files /dev/null and b/static/assets/images/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino/header.jpg differ
diff --git a/static/assets/images/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino/og-image.png b/static/assets/images/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino/og-image.png
new file mode 100644
index 0000000000..b26f479efc
Binary files /dev/null and b/static/assets/images/posts/2024-09-27-exploring-the-potential-of-rust-in-serverless-computing-with-luciano-mammino/og-image.png differ
diff --git a/static/assets/images/posts/2024-10-30-introducing-sheepdogjs/og-image.png b/static/assets/images/posts/2024-10-30-introducing-sheepdogjs/og-image.png
new file mode 100644
index 0000000000..b71a35fd3d
Binary files /dev/null and b/static/assets/images/posts/2024-10-30-introducing-sheepdogjs/og-image.png differ
diff --git a/static/assets/images/posts/2024-12-02-trash-in-treasure-out/og-image.png b/static/assets/images/posts/2024-12-02-trash-in-treasure-out/og-image.png
new file mode 100644
index 0000000000..b909eac15a
Binary files /dev/null and b/static/assets/images/posts/2024-12-02-trash-in-treasure-out/og-image.png differ
diff --git a/static/assets/images/posts/2024-12-02-trash-in-treasure-out/state-diagram.svg b/static/assets/images/posts/2024-12-02-trash-in-treasure-out/state-diagram.svg
new file mode 100644
index 0000000000..33776bfd6e
--- /dev/null
+++ b/static/assets/images/posts/2024-12-02-trash-in-treasure-out/state-diagram.svg
@@ -0,0 +1 @@
+<svg id="mermaid-svg" width="100%" xmlns="http://www.w3.org/2000/svg" class="flowchart" style="max-width: 492.75px;" viewBox="0 0 492.75 902" role="graphics-document document" aria-roledescription="flowchart-v2" xmlns:xlink="http://www.w3.org/1999/xlink"><style xmlns="http://www.w3.org/1999/xhtml">@import url("https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.6.0/css/all.min.css");</style><style>#mermaid-svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg .error-icon{fill:#552222;}#mermaid-svg .error-text{fill:#552222;stroke:#552222;}#mermaid-svg .edge-thickness-normal{stroke-width:1px;}#mermaid-svg .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg .marker{fill:#333333;stroke:#333333;}#mermaid-svg .marker.cross{stroke:#333333;}#mermaid-svg svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg p{margin:0;}#mermaid-svg .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg .cluster-label text{fill:#333;}#mermaid-svg .cluster-label span{color:#333;}#mermaid-svg .cluster-label span p{background-color:transparent;}#mermaid-svg .label text,#mermaid-svg span{fill:#333;color:#333;}#mermaid-svg .node rect,#mermaid-svg .node circle,#mermaid-svg .node ellipse,#mermaid-svg .node polygon,#mermaid-svg .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg .rough-node .label text,#mermaid-svg .node .label text{text-anchor:middle;}#mermaid-svg .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg .node .label{text-align:center;}#mermaid-svg .node.clickable{cursor:pointer;}#mermaid-svg .arrowheadPath{fill:#333333;}#mermaid-svg .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg .cluster text{fill:#333;}#mermaid-svg .cluster span{color:#333;}#mermaid-svg div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;}</style><g><marker id="mermaid-svg_flowchart-v2-pointEnd" class="marker flowchart-v2" viewBox="0 0 10 10" refX="5" refY="5" markerUnits="userSpaceOnUse" markerWidth="8" markerHeight="8" orient="auto"><path d="M 0 0 L 10 5 L 0 10 z" class="arrowMarkerPath" style="stroke-width: 1; stroke-dasharray: 1, 0;"/></marker><marker id="mermaid-svg_flowchart-v2-pointStart" class="marker flowchart-v2" viewBox="0 0 10 10" refX="4.5" refY="5" markerUnits="userSpaceOnUse" markerWidth="8" markerHeight="8" orient="auto"><path d="M 0 5 L 10 10 L 10 0 z" class="arrowMarkerPath" style="stroke-width: 1; stroke-dasharray: 1, 0;"/></marker><marker id="mermaid-svg_flowchart-v2-circleEnd" class="marker flowchart-v2" viewBox="0 0 10 10" refX="11" refY="5" markerUnits="userSpaceOnUse" markerWidth="11" markerHeight="11" orient="auto"><circle cx="5" cy="5" r="5" class="arrowMarkerPath" style="stroke-width: 1; stroke-dasharray: 1, 0;"/></marker><marker id="mermaid-svg_flowchart-v2-circleStart" class="marker flowchart-v2" viewBox="0 0 10 10" refX="-1" refY="5" markerUnits="userSpaceOnUse" markerWidth="11" markerHeight="11" orient="auto"><circle cx="5" cy="5" r="5" class="arrowMarkerPath" style="stroke-width: 1; stroke-dasharray: 1, 0;"/></marker><marker id="mermaid-svg_flowchart-v2-crossEnd" class="marker cross flowchart-v2" viewBox="0 0 11 11" refX="12" refY="5.2" markerUnits="userSpaceOnUse" markerWidth="11" markerHeight="11" orient="auto"><path d="M 1,1 l 9,9 M 10,1 l -9,9" class="arrowMarkerPath" style="stroke-width: 2; stroke-dasharray: 1, 0;"/></marker><marker id="mermaid-svg_flowchart-v2-crossStart" class="marker cross flowchart-v2" viewBox="0 0 11 11" refX="-1" refY="5.2" markerUnits="userSpaceOnUse" markerWidth="11" markerHeight="11" orient="auto"><path d="M 1,1 l 9,9 M 10,1 l -9,9" class="arrowMarkerPath" style="stroke-width: 2; stroke-dasharray: 1, 0;"/></marker><g class="root"><g class="clusters"/><g class="edgePaths"><path d="M252.586,62L252.586,66.167C252.586,70.333,252.586,78.667,252.586,84.917C252.586,91.167,252.586,95.333,252.586,98.833C252.586,102.333,252.586,105.167,252.586,106.583L252.586,108" id="L_Origin_Destination_0" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M184.21,166L173.658,170.167C163.106,174.333,142.002,182.667,131.45,188.917C120.898,195.167,120.898,199.333,120.898,202.833C120.898,206.333,120.898,209.167,120.898,210.583L120.898,212" id="L_Destination_DepartureTimestamp_1" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M120.898,270L120.898,274.167C120.898,278.333,120.898,286.667,127.497,293.439C134.096,300.212,147.294,305.423,159.872,310.39C172.45,315.356,184.408,320.078,190.387,322.439L196.365,324.8" id="L_DepartureTimestamp_Trip_2" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M320.962,166L331.514,170.167C342.066,174.333,363.17,182.667,373.722,188.917C384.273,195.167,384.273,199.333,384.273,202.833C384.273,206.333,384.273,209.167,384.273,210.583L384.273,212" id="L_Destination_ArrivalTimestamp_3" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M384.273,270L384.273,274.167C384.273,278.333,384.273,286.667,377.674,293.439C371.076,300.212,357.878,305.423,345.3,310.39C332.722,315.356,320.764,320.078,314.785,322.439L308.806,324.8" id="L_ArrivalTimestamp_Trip_4" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M252.586,374L252.586,378.167C252.586,382.333,252.586,390.667,252.586,396.917C252.586,403.167,252.586,407.333,252.586,410.833C252.586,414.333,252.586,417.167,252.586,418.583L252.586,420" id="L_Trip_Class_5" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M252.586,478L252.586,482.167C252.586,486.333,252.586,494.667,252.586,500.917C252.586,507.167,252.586,511.333,252.586,514.833C252.586,518.333,252.586,521.167,252.586,522.583L252.586,524" id="L_Class_Name_6" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M252.586,582L252.586,586.167C252.586,590.333,252.586,598.667,252.586,604.917C252.586,611.167,252.586,615.333,252.586,618.833C252.586,622.333,252.586,625.167,252.586,626.583L252.586,628" id="L_Name_Email_7" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M252.586,686L252.586,690.167C252.586,694.333,252.586,702.667,252.586,708.917C252.586,715.167,252.586,719.333,252.586,722.833C252.586,726.333,252.586,729.167,252.586,730.583L252.586,732" id="L_Email_PhoneNumber_8" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/><path d="M252.586,790L252.586,794.167C252.586,798.333,252.586,806.667,252.586,812.917C252.586,819.167,252.586,823.333,252.586,826.833C252.586,830.333,252.586,833.167,252.586,834.583L252.586,836" id="L_PhoneNumber_Book_9" class=" edge-thickness-normal edge-pattern-solid edge-thickness-normal edge-pattern-solid flowchart-link" style="" marker-end="url(#mermaid-svg_flowchart-v2-pointEnd)"/></g><g class="edgeLabels"><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g><g class="edgeLabel"><g class="label" transform="translate(0, 0)"><foreignObject width="0" height="0"><div xmlns="http://www.w3.org/1999/xhtml" class="labelBkg" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="edgeLabel "></span></div></foreignObject></g></g></g><g class="nodes"><g class="node default  " id="flowchart-Origin-0" transform="translate(252.5859375, 35)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-59.828125" y="-27" width="119.65625" height="54"/><g class="label" style="" transform="translate(-44.828125, -12)"><rect/><foreignObject width="89.65625" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Select origin</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-Destination-1" transform="translate(252.5859375, 139)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-79.6796875" y="-27" width="159.359375" height="54"/><g class="label" style="" transform="translate(-64.6796875, -12)"><rect/><foreignObject width="129.359375" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Select destination</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-DepartureTimestamp-2" transform="translate(120.8984375, 243)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-112.8984375" y="-27" width="225.796875" height="54"/><g class="label" style="" transform="translate(-97.8984375, -12)"><rect/><foreignObject width="195.796875" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Enter departure timestamp</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-Trip-3" transform="translate(252.5859375, 347)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-52.5" y="-27" width="105" height="54"/><g class="label" style="" transform="translate(-37.5, -12)"><rect/><foreignObject width="75" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Select trip</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-ArrivalTimestamp-5" transform="translate(384.2734375, 243)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-100.4765625" y="-27" width="200.953125" height="54"/><g class="label" style="" transform="translate(-85.4765625, -12)"><rect/><foreignObject width="170.953125" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Enter arrival timestamp</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-Class-8" transform="translate(252.5859375, 451)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-56.4765625" y="-27" width="112.953125" height="54"/><g class="label" style="" transform="translate(-41.4765625, -12)"><rect/><foreignObject width="82.953125" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Select class</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-Name-9" transform="translate(252.5859375, 555)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-56.2890625" y="-27" width="112.578125" height="54"/><g class="label" style="" transform="translate(-41.2890625, -12)"><rect/><foreignObject width="82.578125" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Enter name</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-Email-10" transform="translate(252.5859375, 659)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-56.5625" y="-27" width="113.125" height="54"/><g class="label" style="" transform="translate(-41.5625, -12)"><rect/><foreignObject width="83.125" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Enter email</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-PhoneNumber-11" transform="translate(252.5859375, 763)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-88.2890625" y="-27" width="176.578125" height="54"/><g class="label" style="" transform="translate(-73.2890625, -12)"><rect/><foreignObject width="146.578125" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Enter phone number</p></span></div></foreignObject></g></g><g class="node default  " id="flowchart-Book-12" transform="translate(252.5859375, 867)"><rect class="basic label-container" style="" rx="5" data-id="abc" data-et="node" ry="5" x="-62.609375" y="-27" width="125.21875" height="54"/><g class="label" style="" transform="translate(-47.609375, -12)"><rect/><foreignObject width="95.21875" height="24"><div xmlns="http://www.w3.org/1999/xhtml" style="display: table-cell; white-space: nowrap; line-height: 1.5; max-width: 200px; text-align: center;"><span class="nodeLabel "><p>Book and pay</p></span></div></foreignObject></g></g></g></g></g></svg>
\ No newline at end of file
diff --git a/static/assets/images/rebranding/cargo.svg b/static/assets/images/rebranding/cargo.svg
new file mode 100644
index 0000000000..fecab30de5
--- /dev/null
+++ b/static/assets/images/rebranding/cargo.svg
@@ -0,0 +1,37 @@
+<svg width="50" height="50" viewBox="0 0 50 50" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_131_46)">
+<path d="M41.6077 19.3461C41.4914 19.3461 41.3733 19.3192 41.2627 19.2624L25 10.903L8.7374 19.2625C8.3664 19.4533 7.91015 19.3072 7.71943 18.9357C7.52841 18.5643 7.6748 18.1085 8.04619 17.9176L24.6545 9.38052C24.8715 9.26899 25.1288 9.26899 25.3458 9.38052L41.9541 17.9176C42.3254 18.1085 42.4718 18.5643 42.2809 18.9357C42.1467 19.1964 41.8819 19.3461 41.6077 19.3461Z" fill="black"/>
+<path d="M41.6077 19.3461C41.4914 19.3461 41.3733 19.3192 41.2627 19.2624L25 10.903L8.7374 19.2625C8.3664 19.4533 7.91015 19.3072 7.71943 18.9357C7.52841 18.5643 7.6748 18.1085 8.04619 17.9176L24.6545 9.38052C24.8715 9.26899 25.1288 9.26899 25.3458 9.38052L41.9541 17.9176C42.3254 18.1085 42.4718 18.5643 42.2809 18.9357C42.1467 19.1964 41.8819 19.3461 41.6077 19.3461Z" fill="#7B7179"/>
+<path d="M49.496 21.1328H0.504004C0.225586 21.1328 0 21.3585 0 21.6368V24.5607H50V21.6368C50 21.3585 49.7743 21.1328 49.496 21.1328Z" fill="#FF4755"/>
+<path d="M6.84151 17.6426C5.87901 17.6426 5.09883 18.4238 5.09883 19.3875V21.1323H8.58428V19.3874C8.58418 18.4237 7.80401 17.6426 6.84151 17.6426Z" fill="#FF9A00"/>
+<path d="M5.09883 19.418H8.58428V21.1319H5.09883V19.418Z" fill="#EF8800"/>
+<path d="M43.1585 17.6426C44.121 17.6426 44.9012 18.4238 44.9012 19.3875V21.1323H41.4157V19.3874C41.4158 18.4237 42.196 17.6426 43.1585 17.6426Z" fill="#FF9A00"/>
+<path d="M41.4158 19.418H44.9012V21.1319H41.4158V19.418Z" fill="#EF8800"/>
+<path d="M0 22.7432H50V24.56H0V22.7432Z" fill="#FC2B3A"/>
+<path d="M49.496 50.001H0.504004C0.225684 50.001 0 49.7753 0 49.497V24.5605H50V49.4969C50 49.7753 49.7743 50.001 49.496 50.001Z" fill="#FF9A00"/>
+<path d="M0.504004 50.0004H49.4959C49.7742 50.0004 49.9999 49.7747 49.9999 49.4964V48.1836H0V49.4964C0 49.7747 0.225684 50.0004 0.504004 50.0004Z" fill="#EF8800"/>
+<path d="M5.28974 46.5894C4.48281 46.5894 3.8287 45.9352 3.8287 45.1282V29.4327C3.8287 28.6258 4.4829 27.9717 5.28974 27.9717C6.09667 27.9717 6.75077 28.6258 6.75077 29.4327V45.1283C6.75077 45.9352 6.09667 46.5894 5.28974 46.5894Z" fill="#FFE55A"/>
+<path d="M11.8598 46.5895C11.0528 46.5895 10.3987 45.9345 10.3987 45.1266V29.4346C10.3987 28.6267 11.0528 27.9717 11.8598 27.9717C12.6667 27.9717 13.3209 28.6267 13.3209 29.4346V45.1265C13.3209 45.9345 12.6668 46.5895 11.8598 46.5895Z" fill="#FFE55A"/>
+<path d="M18.4299 46.5894C17.6229 46.5894 16.9688 45.9352 16.9688 45.1282V29.4327C16.9688 28.6258 17.6229 27.9717 18.4299 27.9717C19.2368 27.9717 19.8909 28.6258 19.8909 29.4327V45.1283C19.891 45.9352 19.2368 46.5894 18.4299 46.5894Z" fill="#FFE55A"/>
+<path d="M25 46.5895C24.1931 46.5895 23.539 45.9345 23.539 45.1266V29.4346C23.539 28.6267 24.1931 27.9717 25 27.9717C25.8069 27.9717 26.461 28.6267 26.461 29.4346V45.1265C26.461 45.9345 25.8069 46.5895 25 46.5895Z" fill="#FFE55A"/>
+<path d="M31.5701 46.5894C30.7632 46.5894 30.1091 45.9352 30.1091 45.1282V29.4327C30.1091 28.6258 30.7632 27.9717 31.5701 27.9717C32.377 27.9717 33.0311 28.6259 33.0311 29.4327V45.1282C33.0311 45.9352 32.377 46.5894 31.5701 46.5894Z" fill="#FFE55A"/>
+<path d="M38.1402 46.5895C37.3333 46.5895 36.6791 45.9345 36.6791 45.1266V29.4346C36.6791 28.6267 37.3332 27.9717 38.1402 27.9717C38.9472 27.9717 39.6013 28.6267 39.6013 29.4346V45.1265C39.6013 45.9345 38.9472 46.5895 38.1402 46.5895Z" fill="#FFE55A"/>
+<path d="M44.7102 46.5894C43.9033 46.5894 43.2491 45.9352 43.2491 45.1282V29.4327C43.2491 28.6258 43.9033 27.9717 44.7102 27.9717C45.5171 27.9717 46.1712 28.6259 46.1712 29.4327V45.1282C46.1714 45.9352 45.5172 46.5894 44.7102 46.5894Z" fill="#FFE55A"/>
+<path d="M5.28976 44.7734C4.48282 44.7734 3.82872 44.1185 3.82872 43.3105V45.1273C3.82872 45.9353 4.48292 46.5902 5.28976 46.5902C6.09669 46.5902 6.75079 45.9353 6.75079 45.1273V43.3105C6.75079 44.1185 6.09669 44.7734 5.28976 44.7734Z" fill="#FFD500"/>
+<path d="M11.8598 44.7734C11.0528 44.7734 10.3987 44.1185 10.3987 43.3105V45.1273C10.3987 45.9353 11.0528 46.5902 11.8598 46.5902C12.6667 46.5902 13.3209 45.9353 13.3209 45.1273V43.3105C13.3209 44.1185 12.6668 44.7734 11.8598 44.7734Z" fill="#FFD500"/>
+<path d="M18.4299 44.7734C17.6229 44.7734 16.9688 44.1185 16.9688 43.3105V45.1273C16.9688 45.9353 17.6229 46.5902 18.4299 46.5902C19.2368 46.5902 19.8909 45.9353 19.8909 45.1273V43.3105C19.891 44.1185 19.2368 44.7734 18.4299 44.7734Z" fill="#FFD500"/>
+<path d="M25 44.7734C24.1931 44.7734 23.539 44.1185 23.539 43.3105V45.1273C23.539 45.9353 24.1931 46.5902 25 46.5902C25.8069 46.5902 26.461 45.9353 26.461 45.1273V43.3105C26.461 44.1185 25.8069 44.7734 25 44.7734Z" fill="#FFD500"/>
+<path d="M31.5701 44.7734C30.7632 44.7734 30.1091 44.1185 30.1091 43.3105V45.1273C30.1091 45.9353 30.7632 46.5902 31.5701 46.5902C32.3771 46.5902 33.0313 45.9353 33.0313 45.1273V43.3105C33.0312 44.1185 32.3771 44.7734 31.5701 44.7734Z" fill="#FFD500"/>
+<path d="M38.1402 44.7734C37.3333 44.7734 36.6792 44.1185 36.6792 43.3105V45.1273C36.6792 45.9353 37.3333 46.5902 38.1402 46.5902C38.9472 46.5902 39.6014 45.9353 39.6014 45.1273V43.3105C39.6013 44.1185 38.9472 44.7734 38.1402 44.7734Z" fill="#FFD500"/>
+<path d="M44.7103 44.7734C43.9033 44.7734 43.2491 44.1185 43.2491 43.3105V45.1273C43.2491 45.9353 43.9032 46.5902 44.7102 46.5902C45.5171 46.5902 46.1712 45.9353 46.1712 45.1273V43.3105C46.1714 44.1185 45.5172 44.7734 44.7103 44.7734Z" fill="#FFD500"/>
+<path d="M26.611 5.75742C26.0837 5.45576 25.7561 4.86846 25.7561 4.22461V3.73848C25.7561 3.3209 25.4176 2.98242 25 2.98242C24.5824 2.98242 24.2439 3.3209 24.2439 3.73848V4.22461C24.2439 5.40938 24.8633 6.49971 25.8603 7.07002C26.4416 7.40254 26.7768 8.02578 26.7353 8.69678C26.6939 9.3627 26.2549 9.94023 25.6604 10.1913L25.6612 10.1926L23.7033 11.5699C24.1068 11.7459 24.5445 11.8383 24.9968 11.8383C25.0663 11.8383 25.136 11.8361 25.2061 11.8317C26.837 11.7304 28.1432 10.4229 28.2444 8.79043C28.322 7.54014 27.6961 6.37793 26.611 5.75742Z" fill="#CAC0C9"/>
+<path d="M23.7849 9.82695C23.4478 9.49668 23.2613 9.05703 23.2613 8.5832C23.2613 8.16563 22.9229 7.82715 22.5053 7.82715C22.0877 7.82715 21.7492 8.16563 21.7492 8.5832C21.7492 9.29014 21.9833 9.97754 22.4026 10.5375L23.7849 9.82695Z" fill="#CAC0C9"/>
+<path d="M30.1089 0.504004V1.71973C30.1089 2.83467 29.2066 3.73789 28.0928 3.73789H21.9072C20.7934 3.73789 19.8911 2.83467 19.8911 1.71973V0.504004C19.8911 0.432422 19.9063 0.363867 19.9335 0.302344C20.0111 0.125 20.1885 0 20.3951 0H29.6048C29.8114 0 29.9889 0.125 30.0665 0.302441C30.0938 0.363867 30.1089 0.432422 30.1089 0.504004Z" fill="#FF4755"/>
+<path d="M30.0665 0.302734C29.882 1.22617 29.0695 1.92168 28.0927 1.92168H21.9072C20.9304 1.92168 20.1179 1.22607 19.9334 0.302734C19.9062 0.364258 19.891 0.432813 19.891 0.504395V1.72002C19.891 2.83496 20.7933 3.73818 21.9071 3.73818H28.0926C29.2065 3.73818 30.1087 2.83496 30.1087 1.72002V0.504297L30.0665 0.302734Z" fill="#FC2B3A"/>
+</g>
+<defs>
+<clipPath id="clip0_131_46">
+<rect width="50" height="50" fill="white"/>
+</clipPath>
+</defs>
+</svg>
diff --git a/static/assets/images/ruby/lp-ruby-consulting-og-image.jpg b/static/assets/images/ruby/lp-ruby-consulting-og-image.jpg
deleted file mode 100644
index d5e36d927b..0000000000
Binary files a/static/assets/images/ruby/lp-ruby-consulting-og-image.jpg and /dev/null differ
diff --git a/static/assets/images/ruby/og-image.png b/static/assets/images/ruby/og-image.png
new file mode 100644
index 0000000000..c7d3509e16
Binary files /dev/null and b/static/assets/images/ruby/og-image.png differ
diff --git a/static/assets/images/rust/book.svg b/static/assets/images/rust/book.svg
new file mode 100644
index 0000000000..ce4961b052
--- /dev/null
+++ b/static/assets/images/rust/book.svg
@@ -0,0 +1,91 @@
+<svg width="50" height="50" viewBox="0 0 50 50" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_129_8)">
+<path d="M42.9129 50H9.34754C7.22362 50 5.50195 48.2782 5.50195 46.1544V3.84559C5.50195 1.72176 7.22362 0 9.34754 0H42.9129C43.7883 0 44.498 0.709706 44.498 1.5851V48.415C44.498 49.2904 43.7884 50 42.9129 50Z" fill="url(#paint0_linear_129_8)"/>
+<path d="M44.498 48.415V39.6406C44.498 41.1143 43.3034 42.3089 41.8298 42.3089H9.34754C7.22362 42.3089 5.50195 44.0306 5.50195 46.1544C5.50195 48.2784 7.22362 50.0001 9.34754 50.0001H42.9129C43.7884 50.0001 44.498 49.2905 44.498 48.415Z" fill="url(#paint1_linear_129_8)"/>
+<path d="M9.34754 0C7.22362 0 5.50195 1.72176 5.50195 3.84559V46.1543C5.50195 44.0304 7.22372 42.3087 9.34754 42.3087H42.9129C43.7883 42.3087 44.498 41.5991 44.498 40.7236V1.5851C44.498 0.709706 43.7884 0 42.9129 0L9.34754 0Z" fill="url(#paint2_linear_129_8)"/>
+<path d="M43.6135 0.165039C43.708 0.368078 43.7623 0.593569 43.7623 0.832294V39.9709C43.7623 40.8463 43.0526 41.556 42.1772 41.556H8.61176C7.33323 41.556 6.20117 42.1804 5.50195 43.1404V46.1546C5.50195 44.0307 7.22372 42.3091 9.34754 42.3091H42.913C43.7884 42.3091 44.4981 41.5995 44.4981 40.724V1.58533C44.498 0.961706 44.1371 0.423863 43.6135 0.165039Z" fill="url(#paint3_linear_129_8)"/>
+<path d="M41.7304 49.0684H9.60578C7.99656 49.0684 6.69196 47.7639 6.69196 46.1545C6.69196 44.5453 7.99646 43.2407 9.60578 43.2407H43.0266V47.7722C43.0266 48.4881 42.4463 49.0684 41.7304 49.0684Z" fill="url(#paint4_linear_129_8)"/>
+<path d="M7.02979 47.5161C7.5188 48.439 8.48861 49.068 9.60567 49.068H41.7304C42.4463 49.068 43.0265 48.4877 43.0265 47.7719V47.5162H7.02979V47.5161Z" fill="url(#paint5_linear_129_8)"/>
+<path d="M9.60578 49.068H41.7304C42.4463 49.068 43.0266 48.4877 43.0266 47.7719V46.1543H6.69196C6.69196 47.7635 7.99646 49.068 9.60578 49.068Z" fill="url(#paint6_linear_129_8)"/>
+<path d="M7.01558 44.8203C6.80921 45.2201 6.69196 45.6734 6.69196 46.1544C6.69196 47.7636 7.99646 49.0683 9.60578 49.0683H41.7304C42.4463 49.0683 43.0266 48.488 43.0266 47.7722V44.8204H7.01558V44.8203Z" fill="url(#paint7_linear_129_8)"/>
+<path d="M10.7444 0H12.0409V42.3087H10.7444V0Z" fill="url(#paint8_linear_129_8)"/>
+<path d="M17.9734 44.8203L23.0836 49.9306H11.0292V44.8203H17.9734Z" fill="url(#paint9_linear_129_8)"/>
+<path d="M10.7444 44.8203V49.8185C10.7444 49.965 10.9091 50.051 11.0292 49.9673L14.0161 47.8861C14.222 47.7426 14.4956 47.7426 14.7014 47.8861L17.6884 49.9673C17.8086 50.051 17.9732 49.965 17.9732 49.8185V44.8203H10.7444Z" fill="url(#paint10_linear_129_8)"/>
+<path d="M12.0409 1.22266H43.2815V41.2754H12.0409V1.22266Z" fill="url(#paint11_linear_129_8)"/>
+<path d="M36.8314 18.9475H18.4908C17.5175 18.9475 16.7285 18.1585 16.7285 17.185V12.1574C16.7285 11.184 17.5175 10.395 18.4908 10.395H36.8314C37.8047 10.395 38.5938 11.184 38.5938 12.1574V17.185C38.5938 18.1584 37.8047 18.9475 36.8314 18.9475Z" fill="url(#paint12_linear_129_8)"/>
+<path d="M36.4242 18.2047H18.898C18.0384 18.2047 17.3416 17.5078 17.3416 16.6481V12.6938C17.3416 11.8342 18.0384 11.1372 18.898 11.1372H36.4242C37.2838 11.1372 37.9807 11.8341 37.9807 12.6938V16.6481C37.9807 17.5078 37.2838 18.2047 36.4242 18.2047Z" fill="url(#paint13_linear_129_8)"/>
+</g>
+<defs>
+<linearGradient id="paint0_linear_129_8" x1="11.4977" y1="10.4542" x2="53.3081" y2="53.418" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18CFFC"/>
+<stop offset="1" stop-color="#4A98F7"/>
+</linearGradient>
+<linearGradient id="paint1_linear_129_8" x1="29.4827" y1="56.9336" x2="23.2082" y2="37.7179" gradientUnits="userSpaceOnUse">
+<stop stop-color="#0469BC" stop-opacity="0"/>
+<stop offset="1" stop-color="#0469BC"/>
+</linearGradient>
+<linearGradient id="paint2_linear_129_8" x1="11.2506" y1="9.41902" x2="49.2694" y2="48.4867" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18CFFC"/>
+<stop offset="1" stop-color="#4A98F7"/>
+</linearGradient>
+<linearGradient id="paint3_linear_129_8" x1="28.0012" y1="36.689" x2="49.4707" y2="-2.27967" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18CFFC" stop-opacity="0"/>
+<stop offset="1" stop-color="#65E1DC"/>
+</linearGradient>
+<linearGradient id="paint4_linear_129_8" x1="24.8592" y1="44.1179" x2="24.8592" y2="48.9761" gradientUnits="userSpaceOnUse">
+<stop stop-color="#F9F7FC"/>
+<stop offset="1" stop-color="#F0DDFC"/>
+</linearGradient>
+<linearGradient id="paint5_linear_129_8" x1="24.9712" y1="49.1255" x2="25.2326" y2="42.3934" gradientUnits="userSpaceOnUse">
+<stop stop-color="#F0DDFC" stop-opacity="0"/>
+<stop offset="0.2889" stop-color="#C8B7E0" stop-opacity="0.289"/>
+<stop offset="0.5915" stop-color="#A595C8" stop-opacity="0.592"/>
+<stop offset="0.8395" stop-color="#8F81B8" stop-opacity="0.84"/>
+<stop offset="1" stop-color="#8779B3"/>
+</linearGradient>
+<linearGradient id="paint6_linear_129_8" x1="24.8592" y1="47.5816" x2="24.8592" y2="44.1829" gradientUnits="userSpaceOnUse">
+<stop stop-color="#F0DDFC" stop-opacity="0"/>
+<stop offset="0.2889" stop-color="#C8B7E0" stop-opacity="0.289"/>
+<stop offset="0.5915" stop-color="#A595C8" stop-opacity="0.592"/>
+<stop offset="0.8395" stop-color="#8F81B8" stop-opacity="0.84"/>
+<stop offset="1" stop-color="#8779B3"/>
+</linearGradient>
+<linearGradient id="paint7_linear_129_8" x1="24.8909" y1="45.8768" x2="24.9562" y2="43.6545" gradientUnits="userSpaceOnUse">
+<stop stop-color="#F0DDFC" stop-opacity="0"/>
+<stop offset="0.2889" stop-color="#C8B7E0" stop-opacity="0.289"/>
+<stop offset="0.5915" stop-color="#A595C8" stop-opacity="0.592"/>
+<stop offset="0.8395" stop-color="#8F81B8" stop-opacity="0.84"/>
+<stop offset="1" stop-color="#8779B3"/>
+</linearGradient>
+<linearGradient id="paint8_linear_129_8" x1="12.3034" y1="21.1544" x2="10.1377" y2="21.1544" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18CFFC"/>
+<stop offset="1" stop-color="#4A98F7"/>
+</linearGradient>
+<linearGradient id="paint9_linear_129_8" x1="17.0993" y1="50.0996" x2="15.8984" y2="45.3692" gradientUnits="userSpaceOnUse">
+<stop stop-color="#F0DDFC" stop-opacity="0"/>
+<stop offset="0.2889" stop-color="#C8B7E0" stop-opacity="0.289"/>
+<stop offset="0.5915" stop-color="#A595C8" stop-opacity="0.592"/>
+<stop offset="0.8395" stop-color="#8F81B8" stop-opacity="0.84"/>
+<stop offset="1" stop-color="#8779B3"/>
+</linearGradient>
+<linearGradient id="paint10_linear_129_8" x1="12.7166" y1="45.2142" x2="17.6085" y2="51.5776" gradientUnits="userSpaceOnUse">
+<stop stop-color="#FF7044"/>
+<stop offset="1" stop-color="#F92814"/>
+</linearGradient>
+<linearGradient id="paint11_linear_129_8" x1="29.9997" y1="24.353" x2="7.5403" y2="-5.45675" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18CFFC" stop-opacity="0"/>
+<stop offset="1" stop-color="#65E1DC"/>
+</linearGradient>
+<linearGradient id="paint12_linear_129_8" x1="29.4238" y1="19.3055" x2="22.1602" y2="0.20894" gradientUnits="userSpaceOnUse">
+<stop stop-color="#18CFFC"/>
+<stop offset="1" stop-color="#4A98F7"/>
+</linearGradient>
+<linearGradient id="paint13_linear_129_8" x1="27.4754" y1="12.3497" x2="27.944" y2="18.2075" gradientUnits="userSpaceOnUse">
+<stop stop-color="#F9F7FC"/>
+<stop offset="1" stop-color="#F0DDFC"/>
+</linearGradient>
+<clipPath id="clip0_129_8">
+<rect width="50" height="50" fill="white"/>
+</clipPath>
+</defs>
+</svg>
diff --git a/static/assets/images/rust/cargo.svg b/static/assets/images/rust/cargo.svg
new file mode 100644
index 0000000000..fecab30de5
--- /dev/null
+++ b/static/assets/images/rust/cargo.svg
@@ -0,0 +1,37 @@
+<svg width="50" height="50" viewBox="0 0 50 50" fill="none" xmlns="http://www.w3.org/2000/svg">
+<g clip-path="url(#clip0_131_46)">
+<path d="M41.6077 19.3461C41.4914 19.3461 41.3733 19.3192 41.2627 19.2624L25 10.903L8.7374 19.2625C8.3664 19.4533 7.91015 19.3072 7.71943 18.9357C7.52841 18.5643 7.6748 18.1085 8.04619 17.9176L24.6545 9.38052C24.8715 9.26899 25.1288 9.26899 25.3458 9.38052L41.9541 17.9176C42.3254 18.1085 42.4718 18.5643 42.2809 18.9357C42.1467 19.1964 41.8819 19.3461 41.6077 19.3461Z" fill="black"/>
+<path d="M41.6077 19.3461C41.4914 19.3461 41.3733 19.3192 41.2627 19.2624L25 10.903L8.7374 19.2625C8.3664 19.4533 7.91015 19.3072 7.71943 18.9357C7.52841 18.5643 7.6748 18.1085 8.04619 17.9176L24.6545 9.38052C24.8715 9.26899 25.1288 9.26899 25.3458 9.38052L41.9541 17.9176C42.3254 18.1085 42.4718 18.5643 42.2809 18.9357C42.1467 19.1964 41.8819 19.3461 41.6077 19.3461Z" fill="#7B7179"/>
+<path d="M49.496 21.1328H0.504004C0.225586 21.1328 0 21.3585 0 21.6368V24.5607H50V21.6368C50 21.3585 49.7743 21.1328 49.496 21.1328Z" fill="#FF4755"/>
+<path d="M6.84151 17.6426C5.87901 17.6426 5.09883 18.4238 5.09883 19.3875V21.1323H8.58428V19.3874C8.58418 18.4237 7.80401 17.6426 6.84151 17.6426Z" fill="#FF9A00"/>
+<path d="M5.09883 19.418H8.58428V21.1319H5.09883V19.418Z" fill="#EF8800"/>
+<path d="M43.1585 17.6426C44.121 17.6426 44.9012 18.4238 44.9012 19.3875V21.1323H41.4157V19.3874C41.4158 18.4237 42.196 17.6426 43.1585 17.6426Z" fill="#FF9A00"/>
+<path d="M41.4158 19.418H44.9012V21.1319H41.4158V19.418Z" fill="#EF8800"/>
+<path d="M0 22.7432H50V24.56H0V22.7432Z" fill="#FC2B3A"/>
+<path d="M49.496 50.001H0.504004C0.225684 50.001 0 49.7753 0 49.497V24.5605H50V49.4969C50 49.7753 49.7743 50.001 49.496 50.001Z" fill="#FF9A00"/>
+<path d="M0.504004 50.0004H49.4959C49.7742 50.0004 49.9999 49.7747 49.9999 49.4964V48.1836H0V49.4964C0 49.7747 0.225684 50.0004 0.504004 50.0004Z" fill="#EF8800"/>
+<path d="M5.28974 46.5894C4.48281 46.5894 3.8287 45.9352 3.8287 45.1282V29.4327C3.8287 28.6258 4.4829 27.9717 5.28974 27.9717C6.09667 27.9717 6.75077 28.6258 6.75077 29.4327V45.1283C6.75077 45.9352 6.09667 46.5894 5.28974 46.5894Z" fill="#FFE55A"/>
+<path d="M11.8598 46.5895C11.0528 46.5895 10.3987 45.9345 10.3987 45.1266V29.4346C10.3987 28.6267 11.0528 27.9717 11.8598 27.9717C12.6667 27.9717 13.3209 28.6267 13.3209 29.4346V45.1265C13.3209 45.9345 12.6668 46.5895 11.8598 46.5895Z" fill="#FFE55A"/>
+<path d="M18.4299 46.5894C17.6229 46.5894 16.9688 45.9352 16.9688 45.1282V29.4327C16.9688 28.6258 17.6229 27.9717 18.4299 27.9717C19.2368 27.9717 19.8909 28.6258 19.8909 29.4327V45.1283C19.891 45.9352 19.2368 46.5894 18.4299 46.5894Z" fill="#FFE55A"/>
+<path d="M25 46.5895C24.1931 46.5895 23.539 45.9345 23.539 45.1266V29.4346C23.539 28.6267 24.1931 27.9717 25 27.9717C25.8069 27.9717 26.461 28.6267 26.461 29.4346V45.1265C26.461 45.9345 25.8069 46.5895 25 46.5895Z" fill="#FFE55A"/>
+<path d="M31.5701 46.5894C30.7632 46.5894 30.1091 45.9352 30.1091 45.1282V29.4327C30.1091 28.6258 30.7632 27.9717 31.5701 27.9717C32.377 27.9717 33.0311 28.6259 33.0311 29.4327V45.1282C33.0311 45.9352 32.377 46.5894 31.5701 46.5894Z" fill="#FFE55A"/>
+<path d="M38.1402 46.5895C37.3333 46.5895 36.6791 45.9345 36.6791 45.1266V29.4346C36.6791 28.6267 37.3332 27.9717 38.1402 27.9717C38.9472 27.9717 39.6013 28.6267 39.6013 29.4346V45.1265C39.6013 45.9345 38.9472 46.5895 38.1402 46.5895Z" fill="#FFE55A"/>
+<path d="M44.7102 46.5894C43.9033 46.5894 43.2491 45.9352 43.2491 45.1282V29.4327C43.2491 28.6258 43.9033 27.9717 44.7102 27.9717C45.5171 27.9717 46.1712 28.6259 46.1712 29.4327V45.1282C46.1714 45.9352 45.5172 46.5894 44.7102 46.5894Z" fill="#FFE55A"/>
+<path d="M5.28976 44.7734C4.48282 44.7734 3.82872 44.1185 3.82872 43.3105V45.1273C3.82872 45.9353 4.48292 46.5902 5.28976 46.5902C6.09669 46.5902 6.75079 45.9353 6.75079 45.1273V43.3105C6.75079 44.1185 6.09669 44.7734 5.28976 44.7734Z" fill="#FFD500"/>
+<path d="M11.8598 44.7734C11.0528 44.7734 10.3987 44.1185 10.3987 43.3105V45.1273C10.3987 45.9353 11.0528 46.5902 11.8598 46.5902C12.6667 46.5902 13.3209 45.9353 13.3209 45.1273V43.3105C13.3209 44.1185 12.6668 44.7734 11.8598 44.7734Z" fill="#FFD500"/>
+<path d="M18.4299 44.7734C17.6229 44.7734 16.9688 44.1185 16.9688 43.3105V45.1273C16.9688 45.9353 17.6229 46.5902 18.4299 46.5902C19.2368 46.5902 19.8909 45.9353 19.8909 45.1273V43.3105C19.891 44.1185 19.2368 44.7734 18.4299 44.7734Z" fill="#FFD500"/>
+<path d="M25 44.7734C24.1931 44.7734 23.539 44.1185 23.539 43.3105V45.1273C23.539 45.9353 24.1931 46.5902 25 46.5902C25.8069 46.5902 26.461 45.9353 26.461 45.1273V43.3105C26.461 44.1185 25.8069 44.7734 25 44.7734Z" fill="#FFD500"/>
+<path d="M31.5701 44.7734C30.7632 44.7734 30.1091 44.1185 30.1091 43.3105V45.1273C30.1091 45.9353 30.7632 46.5902 31.5701 46.5902C32.3771 46.5902 33.0313 45.9353 33.0313 45.1273V43.3105C33.0312 44.1185 32.3771 44.7734 31.5701 44.7734Z" fill="#FFD500"/>
+<path d="M38.1402 44.7734C37.3333 44.7734 36.6792 44.1185 36.6792 43.3105V45.1273C36.6792 45.9353 37.3333 46.5902 38.1402 46.5902C38.9472 46.5902 39.6014 45.9353 39.6014 45.1273V43.3105C39.6013 44.1185 38.9472 44.7734 38.1402 44.7734Z" fill="#FFD500"/>
+<path d="M44.7103 44.7734C43.9033 44.7734 43.2491 44.1185 43.2491 43.3105V45.1273C43.2491 45.9353 43.9032 46.5902 44.7102 46.5902C45.5171 46.5902 46.1712 45.9353 46.1712 45.1273V43.3105C46.1714 44.1185 45.5172 44.7734 44.7103 44.7734Z" fill="#FFD500"/>
+<path d="M26.611 5.75742C26.0837 5.45576 25.7561 4.86846 25.7561 4.22461V3.73848C25.7561 3.3209 25.4176 2.98242 25 2.98242C24.5824 2.98242 24.2439 3.3209 24.2439 3.73848V4.22461C24.2439 5.40938 24.8633 6.49971 25.8603 7.07002C26.4416 7.40254 26.7768 8.02578 26.7353 8.69678C26.6939 9.3627 26.2549 9.94023 25.6604 10.1913L25.6612 10.1926L23.7033 11.5699C24.1068 11.7459 24.5445 11.8383 24.9968 11.8383C25.0663 11.8383 25.136 11.8361 25.2061 11.8317C26.837 11.7304 28.1432 10.4229 28.2444 8.79043C28.322 7.54014 27.6961 6.37793 26.611 5.75742Z" fill="#CAC0C9"/>
+<path d="M23.7849 9.82695C23.4478 9.49668 23.2613 9.05703 23.2613 8.5832C23.2613 8.16563 22.9229 7.82715 22.5053 7.82715C22.0877 7.82715 21.7492 8.16563 21.7492 8.5832C21.7492 9.29014 21.9833 9.97754 22.4026 10.5375L23.7849 9.82695Z" fill="#CAC0C9"/>
+<path d="M30.1089 0.504004V1.71973C30.1089 2.83467 29.2066 3.73789 28.0928 3.73789H21.9072C20.7934 3.73789 19.8911 2.83467 19.8911 1.71973V0.504004C19.8911 0.432422 19.9063 0.363867 19.9335 0.302344C20.0111 0.125 20.1885 0 20.3951 0H29.6048C29.8114 0 29.9889 0.125 30.0665 0.302441C30.0938 0.363867 30.1089 0.432422 30.1089 0.504004Z" fill="#FF4755"/>
+<path d="M30.0665 0.302734C29.882 1.22617 29.0695 1.92168 28.0927 1.92168H21.9072C20.9304 1.92168 20.1179 1.22607 19.9334 0.302734C19.9062 0.364258 19.891 0.432813 19.891 0.504395V1.72002C19.891 2.83496 20.7933 3.73818 21.9071 3.73818H28.0926C29.2065 3.73818 30.1087 2.83496 30.1087 1.72002V0.504297L30.0665 0.302734Z" fill="#FC2B3A"/>
+</g>
+<defs>
+<clipPath id="clip0_131_46">
+<rect width="50" height="50" fill="white"/>
+</clipPath>
+</defs>
+</svg>
diff --git a/static/assets/images/rust/eurorust-2024.jpg b/static/assets/images/rust/eurorust-2024.jpg
new file mode 100644
index 0000000000..d68d45ce28
Binary files /dev/null and b/static/assets/images/rust/eurorust-2024.jpg differ
diff --git a/static/assets/images/rust/eurorust-crab.jpg b/static/assets/images/rust/eurorust-crab.jpg
new file mode 100644
index 0000000000..9063cbbd84
Binary files /dev/null and b/static/assets/images/rust/eurorust-crab.jpg differ
diff --git a/static/assets/images/rust/gerust-logo.svg b/static/assets/images/rust/gerust-logo.svg
new file mode 100644
index 0000000000..cce9701e8a
--- /dev/null
+++ b/static/assets/images/rust/gerust-logo.svg
@@ -0,0 +1,33 @@
+<svg width="200" height="63" viewBox="0 0 200 63" fill="none" xmlns="http://www.w3.org/2000/svg">
+<mask id="mask0_130_29" style="mask-type:luminance" maskUnits="userSpaceOnUse" x="0" y="1" width="200" height="61">
+<path d="M200 1.12207H0V61.8768H200V1.12207Z" fill="white"/>
+</mask>
+<g mask="url(#mask0_130_29)">
+<path d="M13.064 40.2881C14.4879 39.6461 16.1158 39.325 17.9553 39.325C20.0703 39.325 21.8757 39.7102 23.3752 40.477C24.8747 41.2437 25.9133 42.271 26.491 43.5552L34.876 42.9508C34.147 39.7782 32.2812 37.4063 29.286 35.8313C26.2909 34.2563 22.5518 33.4707 18.0685 33.4707C14.6202 33.4707 11.5457 33.992 8.85272 35.0381C6.15976 36.0843 4.02579 37.6631 2.45081 39.7782C0.879594 41.8933 0.09021 44.473 0.09021 47.521C0.09021 50.569 0.845599 53.1563 2.35638 55.2828C3.86716 57.4092 5.91427 58.9917 8.49393 60.0227C11.0736 61.0536 13.9517 61.1936 17.1243 61.1936C18.9372 61.1936 20.6179 61.3746 22.1665 60.9856C23.715 60.5967 25.0748 60.0532 26.2457 59.3617C27.4164 58.6707 28.3418 57.8697 29.0217 56.9632L29.9659 61.1181H34.4983V45.4815H15.6135V50.3537H26.5289C26.3023 51.336 25.7924 52.2425 24.9993 53.0728C24.206 53.9038 23.1977 54.5538 21.9777 55.0183C20.7577 55.4828 19.4169 55.7168 17.9553 55.7168C16.0932 55.7168 14.454 55.4073 13.0452 54.7918C11.6364 54.1758 10.5259 53.2428 9.72144 51.9965C8.91697 50.7502 8.51283 49.2583 8.51283 47.521C8.51283 45.7836 8.91697 44.3672 9.72144 43.1208C10.5259 41.8745 11.6401 40.9302 13.064 40.2881Z" fill="black"/>
+<path d="M37.2552 61.1176H65.4691V54.9608H45.4135V49.6355H64.1096V44.4611H45.4135V40.0798H65.4691V33.168H37.2552V61.1176Z" fill="black"/>
+<path d="M98.7705 42.7237C98.7705 41.1373 98.4455 38.5803 97.7925 37.3226C97.139 36.065 96.0811 35.0565 94.6196 34.3011C93.1541 33.5457 91.2808 33.168 88.9919 33.168H67.8485V61.1176H75.8178V51.033H83.4815L89.9138 61.1176H98.5855L91.8853 50.814C93.7961 50.4928 95.3031 49.8092 96.3911 48.748C97.9775 47.1993 98.7705 45.1901 98.7705 42.7237ZM75.8218 38.909H87.3339C88.4404 38.909 89.2529 39.1356 89.7698 39.5888C90.2873 40.042 90.5443 41.0882 90.5443 41.9683C90.5443 42.9012 90.2988 44.3176 89.8078 44.7066C89.3168 45.0956 88.4899 45.292 87.3339 45.292H75.8218V38.909Z" fill="black"/>
+<path d="M123.581 49.1067C123.581 51.0972 122.977 52.6685 121.772 53.8278C120.564 54.9873 118.803 55.5653 116.492 55.5653C114.181 55.5653 112.451 54.9873 111.231 53.8278C110.011 52.6685 109.403 51.0972 109.403 49.1067V33.168H101.419V49.22C101.419 51.966 101.985 54.2623 103.118 56.1128C104.251 57.9637 105.935 59.3422 108.175 60.2487C110.415 61.1551 113.176 61.6086 116.458 61.6086C121.432 61.6086 125.201 60.5771 127.766 58.5112C130.328 56.4493 131.611 53.3483 131.611 49.22V33.168H123.589V49.1067H123.581Z" fill="black"/>
+<path d="M165.105 47.1007C163.545 45.8844 161.699 45.0874 159.573 44.7098C157.445 44.3283 154.768 44.0639 151.546 43.9129C149.658 43.7882 148.196 43.6673 147.165 43.5502C146.134 43.4369 145.288 43.2141 144.634 42.8856C143.98 42.5569 143.653 42.0772 143.653 41.4427C143.653 40.5324 144.275 39.8602 145.521 39.4297C146.768 38.9991 148.449 38.7837 150.564 38.7837C152.679 38.7837 154.296 39.0934 155.644 39.7128C156.993 40.3323 157.929 41.2274 158.458 42.3907L166.88 41.4427C165.671 38.7347 163.771 36.7291 161.178 35.4223C158.583 34.1192 155.161 33.4658 150.904 33.4658C147.931 33.4658 145.314 33.7453 143.048 34.3004C140.781 34.8594 138.969 35.7697 137.609 37.0351C136.249 38.3003 135.569 39.9736 135.569 42.0471C135.569 44.3246 136.299 46.0393 137.76 47.1913C139.221 48.3432 140.97 49.0836 143.01 49.4121C145.05 49.7407 147.645 49.9937 150.79 50.1713C152.729 50.2468 154.265 50.3488 155.399 50.4734C156.531 50.6018 157.468 50.8587 158.213 51.2514C158.956 51.6444 159.326 52.2559 159.326 53.0944C159.326 53.8538 158.968 54.4543 158.25 54.8998C157.533 55.3418 156.615 55.6328 155.493 55.7723C154.371 55.9123 153.106 55.9803 151.696 55.9803C149.129 55.9803 147.078 55.6253 145.54 54.9188C144.004 54.2088 142.984 53.1704 142.481 51.8069L134.059 52.8304C135.219 55.6138 137.269 57.7402 140.215 59.2097C143.161 60.6787 147.063 61.4116 151.924 61.4116C155.07 61.4116 157.796 61.1281 160.1 60.5582C162.405 59.9877 164.206 59.0507 165.501 57.7477C166.798 56.4448 167.446 54.7413 167.446 52.6414C167.446 50.1599 166.665 48.3129 165.105 47.0968V47.1007Z" fill="black"/>
+<path d="M169.563 33.168V40.0798H180.591V61.1176H188.674V40.0798H199.74V33.168H169.563Z" fill="black"/>
+<path d="M188.473 29.002V33.1075H180.919V29.002H180.541V33.1075L166.566 33.1113V29.002H166.189V33.1075H158.258V29.002H157.88V33.1075L143.905 33.1113V29.002H143.528V33.1075H135.596V29.002H135.219V33.1075L131.819 33.1113V29.002H131.441V33.1075H123.887V29.002H123.51V33.1075L109.535 33.1113V29.002H109.157V33.1075H101.604V29.002H101.226V33.1075L98.9595 33.1113V29.002H98.5815V33.1075H90.6503V29.002H90.2723V33.1075L75.9198 33.1113V29.002H75.5423V33.1075H67.9885V29.002H67.6105V33.1075L65.7222 33.1113V29.002H65.3447V33.1075H57.4129V29.002H57.0354V33.1075L45.7044 33.1113V29.002H45.3267V33.1075H37.395V29.002H37.0174V33.1075L34.7512 33.1113V29.002H34.3735V33.1075H26.4419V29.002H26.0642V33.1075L8.69021 33.1113V29.002H8.31252V33.1075H0.380931V29.002H0.00323486V61.4347H188.851V29.002H188.473ZM181.229 40.0911L184.696 37.0393L188.164 40.0911H181.233H181.229ZM188.164 40.4688L184.696 43.5243L181.229 40.4688H188.168H188.164ZM180.919 39.8645V33.7118L184.409 36.7863L180.919 39.8607V39.8645ZM181.236 33.489H188.156L184.696 36.537L181.236 33.489ZM184.409 43.7775L180.919 46.8518V40.6992L184.409 43.7737V43.7775ZM181.229 47.0822L184.696 44.0305L188.164 47.0822H181.233H181.229ZM188.156 47.46L184.696 50.508L181.236 47.46H188.156ZM184.409 50.761L180.919 53.8355V47.6828L184.409 50.7572V50.761ZM184.409 57.7483L180.919 60.8227V54.67L184.409 57.7443V57.7483ZM181.229 54.4435H188.16L184.693 57.4953L181.225 54.4435H181.229ZM181.229 54.066L184.696 51.0103L188.164 54.066H181.225H181.229ZM184.696 58.0013L188.164 61.0532H181.233L184.7 58.0013H184.696ZM184.984 57.7483L188.473 54.674V60.8267L184.984 57.7523V57.7483ZM184.984 50.761L188.473 47.6866V53.839L184.984 50.7648V50.761ZM184.984 43.7775L188.473 40.703V46.8556L184.984 43.7812V43.7775ZM184.984 36.7863L188.473 33.7118V39.8645L184.984 36.7901V36.7863ZM180.541 33.489V47.0822H166.566V33.489H180.541ZM165.853 47.46L162.224 50.5117L158.594 47.46H165.853ZM158.586 47.0822L162.224 44.023L165.86 47.0822H158.586ZM162.518 43.7775L166.189 40.6878V46.8632L162.518 43.7737V43.7775ZM162.518 36.7863L166.189 33.6967V39.8721L162.518 36.7825V36.7863ZM165.86 40.0911H158.586L162.224 37.0318L165.86 40.0911ZM162.224 36.5408L158.594 33.489H165.853L162.224 36.5408ZM161.929 36.7863L158.258 39.8758V33.7005L161.929 36.7901V36.7863ZM165.864 40.4688L162.224 43.5281L158.583 40.4688H165.86H165.864ZM161.929 43.7775L158.258 46.867V40.6917L161.929 43.7812V43.7775ZM161.929 50.761L158.258 53.8505V47.6752L161.929 50.7648V50.761ZM161.929 57.7483L158.258 60.8377V54.6625L161.929 57.7523V57.7483ZM158.586 54.4435H165.86L162.224 57.5028L158.586 54.4435ZM166.189 54.6625V60.8377L162.518 57.7483L166.189 54.659V54.6625ZM158.583 54.066L162.224 51.0066L165.864 54.066H158.586H158.583ZM162.224 57.9978L165.86 61.0567H158.586L162.224 57.9978ZM162.518 50.761L166.189 47.6715V53.847L162.518 50.7572V50.761ZM157.88 33.489V47.0822H143.905V33.489H157.88ZM143.191 47.46L139.561 50.5117L135.931 47.46H143.191ZM135.924 47.0822L139.561 44.023L143.199 47.0822H135.924ZM139.856 43.7775L143.528 40.6878V46.8632L139.856 43.7737V43.7775ZM139.856 36.7863L143.528 33.6967V39.8721L139.856 36.7825V36.7863ZM143.199 40.0911H135.924L139.561 37.0318L143.199 40.0911ZM139.561 36.5408L135.931 33.489H143.191L139.561 36.5408ZM139.268 36.7863L135.596 39.8758V33.7005L139.268 36.7901V36.7863ZM143.203 40.4688L139.561 43.5281L135.921 40.4688H143.199H143.203ZM139.268 43.7775L135.596 46.867V40.6917L139.268 43.7812V43.7775ZM139.268 50.761L135.596 53.8505V47.6752L139.268 50.7648V50.761ZM139.268 57.7483L135.596 60.8377V54.6625L139.268 57.7523V57.7483ZM135.924 54.4435H143.199L139.561 57.5028L135.924 54.4435ZM143.528 54.6625V60.8377L139.856 57.7483L143.528 54.659V54.6625ZM135.921 54.066L139.561 51.0066L143.203 54.066H135.924H135.921ZM139.561 57.9978L143.199 61.0567H135.924L139.561 57.9978ZM139.856 50.761L143.528 47.6715V53.847L139.856 50.7572V50.761ZM135.219 33.489V47.0822H131.819V33.489H135.219ZM131.124 47.46L127.664 50.508L124.205 47.46H131.124ZM124.197 47.0822L127.664 44.0305L131.131 47.0822H124.201H124.197ZM127.951 43.7775L131.441 40.703V46.8556L127.951 43.7812V43.7775ZM127.951 36.7863L131.441 33.7118V39.8645L127.951 36.7901V36.7863ZM131.131 40.0911H124.201L127.668 37.0393L131.135 40.0911H131.131ZM127.664 36.537L124.205 33.489H131.124L127.664 36.537ZM127.378 36.7863L123.887 39.8607V33.7081L127.378 36.7825V36.7863ZM131.131 40.4688L127.664 43.5243L124.197 40.4688H131.135H131.131ZM127.378 43.7775L123.887 46.8518V40.6992L127.378 43.7737V43.7775ZM127.378 50.761L123.887 53.8355V47.6828L127.378 50.7572V50.761ZM127.378 57.7483L123.887 60.8227V54.67L127.378 57.7443V57.7483ZM124.197 54.4435H131.128L127.66 57.4953L124.193 54.4435H124.197ZM131.441 54.674V60.8267L127.951 57.7523L131.441 54.678V54.674ZM124.197 54.066L127.664 51.0103L131.131 54.066H124.193H124.197ZM127.664 58.0013L131.131 61.0532H124.201L127.668 58.0013H127.664ZM127.951 50.761L131.441 47.6866V53.839L127.951 50.7648V50.761ZM123.51 33.489V47.0822H109.535V33.489H123.51ZM108.84 47.46L105.38 50.508L101.92 47.46H108.84ZM101.913 47.0822L105.38 44.0305L108.847 47.0822H101.917H101.913ZM105.667 43.7775L109.157 40.703V46.8556L105.667 43.7812V43.7775ZM105.667 36.7863L109.157 33.7118V39.8645L105.667 36.7901V36.7863ZM108.847 40.0911H101.917L105.384 37.0393L108.851 40.0911H108.847ZM105.38 36.537L101.92 33.489H108.84L105.38 36.537ZM105.093 36.7863L101.604 39.8607V33.7081L105.093 36.7825V36.7863ZM108.847 40.4688L105.38 43.5243L101.913 40.4688H108.851H108.847ZM105.093 43.7775L101.604 46.8518V40.6992L105.093 43.7737V43.7775ZM105.093 50.761L101.604 53.8355V47.6828L105.093 50.7572V50.761ZM105.093 57.7483L101.604 60.8227V54.67L105.093 57.7443V57.7483ZM101.913 54.4435H108.844L105.376 57.4953L101.909 54.4435H101.913ZM109.157 54.674V60.8267L105.667 57.7523L109.157 54.678V54.674ZM101.913 54.066L105.38 51.0103L108.847 54.066H101.909H101.913ZM105.38 58.0013L108.847 61.0532H101.917L105.384 58.0013H105.38ZM105.667 50.761L109.157 47.6866V53.839L105.667 50.7648V50.761ZM101.226 33.489V47.0822H98.9595V33.489H101.226ZM98.2455 47.46L94.6157 50.5117L90.9863 47.46H98.2455ZM90.9788 47.0822L94.6157 44.023L98.253 47.0822H90.9788ZM94.9107 43.7775L98.5815 40.6878V46.8632L94.9107 43.7737V43.7775ZM94.9107 36.7863L98.5815 33.6967V39.8721L94.9107 36.7825V36.7863ZM98.253 40.0911H90.9788L94.6157 37.0318L98.253 40.0911ZM94.6157 36.5408L90.9863 33.489H98.2455L94.6157 36.5408ZM94.3212 36.7863L90.6503 39.8758V33.7005L94.3212 36.7901V36.7863ZM98.257 40.4688L94.6157 43.5281L90.9748 40.4688H98.253H98.257ZM94.3212 43.7775L90.6503 46.867V40.6917L94.3212 43.7812V43.7775ZM94.3212 50.761L90.6503 53.8505V47.6752L94.3212 50.7648V50.761ZM94.3212 57.7483L90.6503 60.8377V54.6625L94.3212 57.7523V57.7483ZM90.9788 54.4435H98.253L94.6157 57.5028L90.9788 54.4435ZM98.5815 54.6625V60.8377L94.9107 57.7483L98.5815 54.659V54.6625ZM90.9748 54.066L94.6157 51.0066L98.257 54.066H90.9788H90.9748ZM94.6157 57.9978L98.253 61.0567H90.9788L94.6157 57.9978ZM94.9107 50.761L98.5815 47.6715V53.847L94.9107 50.7572V50.761ZM90.2723 33.489V47.0822H75.9198V33.489H90.2723ZM75.2248 47.46L71.7654 50.508L68.3055 47.46H75.2248ZM68.298 47.0822L71.7654 44.0305L75.2328 47.0822H68.302H68.298ZM72.0524 43.7775L75.5423 40.703V46.8556L72.0524 43.7812V43.7775ZM72.0524 36.7863L75.5423 33.7118V39.8645L72.0524 36.7901V36.7863ZM75.2328 40.0911H68.302L71.7689 37.0393L75.2363 40.0911H75.2328ZM71.7654 36.537L68.3055 33.489H75.2248L71.7654 36.537ZM71.4784 36.7863L67.9885 39.8607V33.7081L71.4784 36.7825V36.7863ZM75.2328 40.4688L71.7654 43.5243L68.298 40.4688H75.2363H75.2328ZM71.4784 43.7775L67.9885 46.8518V40.6992L71.4784 43.7737V43.7775ZM71.4784 50.761L67.9885 53.8355V47.6828L71.4784 50.7572V50.761ZM71.4784 57.7483L67.9885 60.8227V54.67L71.4784 57.7443V57.7483ZM68.298 54.4435H75.2288L71.7614 57.4953L68.2945 54.4435H68.298ZM75.5423 54.674V60.8267L72.0524 57.7523L75.5423 54.678V54.674ZM68.298 54.066L71.7654 51.0103L75.2328 54.066H68.2945H68.298ZM71.7654 58.0013L75.2328 61.0532H68.302L71.7689 58.0013H71.7654ZM72.0524 50.761L75.5423 47.6866V53.839L72.0524 50.7648V50.761ZM67.6105 33.489V47.0822H65.7222V33.489H67.6105ZM65.0082 47.46L61.3788 50.5117L57.7489 47.46H65.0082ZM57.7414 47.0822L61.3788 44.023L65.0162 47.0822H57.7414ZM61.6733 43.7775L65.3447 40.6878V46.8632L61.6733 43.7737V43.7775ZM61.6733 36.7863L65.3447 33.6967V39.8721L61.6733 36.7825V36.7863ZM65.0162 40.0911H57.7414L61.3788 37.0318L65.0162 40.0911ZM61.3788 36.5408L57.7489 33.489H65.0082L61.3788 36.5408ZM61.0843 36.7863L57.4129 39.8758V33.7005L61.0843 36.7901V36.7863ZM65.0197 40.4688L61.3788 43.5281L57.7379 40.4688H65.0162H65.0197ZM61.0843 43.7775L57.4129 46.867V40.6917L61.0843 43.7812V43.7775ZM61.0843 50.761L57.4129 53.8505V47.6752L61.0843 50.7648V50.761ZM61.0843 57.7483L57.4129 60.8377V54.6625L61.0843 57.7523V57.7483ZM57.7414 54.4435H65.0162L61.3788 57.5028L57.7414 54.4435ZM65.3447 54.6625V60.8377L61.6733 57.7483L65.3447 54.659V54.6625ZM57.7379 54.066L61.3788 51.0066L65.0197 54.066H57.7414H57.7379ZM61.3788 57.9978L65.0162 61.0567H57.7414L61.3788 57.9978ZM61.6733 50.761L65.3447 47.6715V53.847L61.6733 50.7572V50.761ZM57.0354 33.489V47.0822H45.7044V33.489H57.0354ZM44.9905 47.46L41.3609 50.5117L37.7312 47.46H44.9905ZM37.7237 47.0822L41.3609 44.023L44.998 47.0822H37.7237ZM41.6555 43.7775L45.3267 40.6878V46.8632L41.6555 43.7737V43.7775ZM41.6555 36.7863L45.3267 33.6967V39.8721L41.6555 36.7825V36.7863ZM44.998 40.0911H37.7237L41.3609 37.0318L44.998 40.0911ZM41.3609 36.5408L37.7312 33.489H44.9905L41.3609 36.5408ZM41.0663 36.7863L37.395 39.8758V33.7005L41.0663 36.7901V36.7863ZM45.0019 40.4688L41.3609 43.5281L37.7199 40.4688H44.998H45.0019ZM41.0663 43.7775L37.395 46.867V40.6917L41.0663 43.7812V43.7775ZM41.0663 50.761L37.395 53.8505V47.6752L41.0663 50.7648V50.761ZM41.0663 57.7483L37.395 60.8377V54.6625L41.0663 57.7523V57.7483ZM37.7237 54.4435H44.998L41.3609 57.5028L37.7237 54.4435ZM45.3267 54.6625V60.8377L41.6555 57.7483L45.3267 54.659V54.6625ZM37.7199 54.066L41.3609 51.0066L45.0019 54.066H37.7237H37.7199ZM41.3609 57.9978L44.998 61.0567H37.7237L41.3609 57.9978ZM41.6555 50.761L45.3267 47.6715V53.847L41.6555 50.7572V50.761ZM37.0174 33.489V47.0822H34.7512V33.489H37.0174ZM34.0374 47.46L30.4077 50.5117L26.778 47.46H34.0374ZM26.7705 47.0822L30.4077 44.023L34.0449 47.0822H26.7705ZM30.7023 43.7775L34.3735 40.6878V46.8632L30.7023 43.7737V43.7775ZM30.7023 36.7863L34.3735 33.6967V39.8721L30.7023 36.7825V36.7863ZM34.0449 40.0911H26.7705L30.4077 37.0318L34.0449 40.0911ZM30.4077 36.5408L26.778 33.489H34.0374L30.4077 36.5408ZM30.1132 36.7863L26.4419 39.8758V33.7005L30.1132 36.7901V36.7863ZM34.0487 40.4688L30.4077 43.5281L26.7668 40.4688H34.0449H34.0487ZM30.1132 43.7775L26.4419 46.867V40.6917L30.1132 43.7812V43.7775ZM30.1132 50.761L26.4419 53.8505V47.6752L30.1132 50.7648V50.761ZM30.1132 57.7483L26.4419 60.8377V54.6625L30.1132 57.7523V57.7483ZM26.7705 54.4435H34.0449L30.4077 57.5028L26.7705 54.4435ZM34.3735 54.6625V60.8377L30.7023 57.7483L34.3735 54.659V54.6625ZM26.7668 54.066L30.4077 51.0066L34.0487 54.066H26.7705H26.7668ZM30.4077 57.9978L34.0449 61.0567H26.7705L30.4077 57.9978ZM30.7023 50.761L34.3735 47.6715V53.847L30.7023 50.7572V50.761ZM26.0642 33.489V47.0822H8.69021V33.489H26.0642ZM7.97638 47.46L4.34673 50.5117L0.717081 47.46H7.97638ZM0.709526 47.0822L4.34673 44.023L7.98393 47.0822H0.709526ZM4.64134 43.7775L8.31252 40.6878V46.8632L4.64134 43.7737V43.7775ZM8.31252 33.7005V39.8758L4.64134 36.7863L8.31252 33.6967V33.7005ZM4.34673 36.5408L0.717081 33.489H7.97638L4.34673 36.5408ZM7.98393 40.0911H0.709526L4.34673 37.0318L7.98393 40.0911ZM7.98773 40.4688L4.34673 43.5281L0.705751 40.4688H7.98393H7.98773ZM4.05213 36.7863L0.380931 39.8758V33.7005L4.05213 36.7901V36.7863ZM4.05213 43.7775L0.380931 46.867V40.6917L4.05213 43.7812V43.7775ZM4.05213 50.761L0.380931 53.8505V47.6752L4.05213 50.7648V50.761ZM8.31252 54.6625V60.8377L4.64134 57.7483L8.31252 54.659V54.6625ZM4.34673 57.5028L0.709526 54.4435H7.98393L4.34673 57.5028ZM0.705751 54.066L4.34673 51.0066L7.98773 54.066H0.705751ZM0.380931 54.6625L4.05213 57.7523L0.380931 60.8417V54.6665V54.6625ZM4.34673 57.9978L7.98393 61.0567H0.709526L4.34673 57.9978ZM4.64134 50.761L8.31252 47.6715V53.847L4.64134 50.7572V50.761ZM8.69021 61.0532V47.46H26.0642V61.0532H8.69021ZM34.7512 61.0532V47.46H37.0174V61.0532H34.7512ZM45.7044 61.0532V47.46H57.0354V61.0532H45.7044ZM65.7222 61.0532V47.46H67.6105V61.0532H65.7222ZM75.9198 61.0532V47.46H90.2723V61.0532H75.9198ZM98.9595 61.0532V47.46H101.226V61.0532H98.9595ZM109.535 61.0532V47.46H123.51V61.0532H109.535ZM131.819 61.0532V47.46H135.219V61.0532H131.819ZM143.905 61.0532V47.46H157.88V61.0532H143.905ZM166.566 61.0532V47.46H180.541V61.0532H166.566Z" fill="url(#paint0_radial_130_29)"/>
+<path d="M199.936 6.18955C200.254 4.05558 199.283 2.09534 197.704 1.45703C196.915 2.82051 196.136 4.31996 195.499 5.8534C195.499 5.8534 194.653 4.21799 194.21 2.29174C193.504 2.9867 192.99 3.98381 192.816 5.13579C192.526 7.08846 193.315 8.89385 194.66 9.67568C194.943 11.9003 194.158 13.2789 193.35 14.0872L192.153 14.6651C192.031 14.6009 191.906 14.5404 191.783 14.48L191.48 12.8521C191.45 12.6859 191.336 12.5499 191.178 12.4895C191.019 12.4291 190.841 12.4555 190.709 12.5537L189.384 13.5509C189.251 13.513 189.115 13.4754 188.983 13.4375L188.368 11.9041C188.303 11.7492 188.168 11.6359 188.001 11.6057C187.835 11.5755 187.665 11.6359 187.555 11.7606L186.453 12.9956C186.313 12.9843 186.176 12.973 186.038 12.9654L185.134 11.5831C185.044 11.4433 184.885 11.3602 184.715 11.364C184.545 11.3678 184.394 11.4584 184.308 11.6019L183.465 13.0296C183.329 13.0447 183.189 13.0598 183.054 13.0787L181.894 11.8928C181.776 11.7719 181.603 11.7228 181.44 11.7606C181.274 11.7983 181.141 11.9154 181.085 12.0741L180.538 13.6377C180.405 13.6792 180.274 13.7207 180.145 13.7661L178.774 12.8294C178.635 12.735 178.456 12.7199 178.303 12.7879C178.148 12.8559 178.038 12.9994 178.015 13.1656L177.785 14.801C177.66 14.869 177.539 14.937 177.418 15.005L175.893 14.3554C175.738 14.2874 175.56 14.3062 175.42 14.4044C175.284 14.5026 175.205 14.6612 175.213 14.8312L175.306 16.4817C175.201 16.5724 175.095 16.663 174.99 16.7537L173.365 16.4137C173.199 16.3797 173.029 16.4326 172.913 16.5535C172.795 16.6744 172.75 16.8481 172.791 17.0105L173.206 18.6157C173.12 18.7215 173.036 18.831 172.954 18.9406L172.233 18.933C170.518 17.2711 170.779 15.6961 171.175 14.7935C172.519 14.1136 173.438 12.4555 173.365 10.552C173.32 9.38864 172.916 8.34241 172.293 7.57189C171.644 9.43774 170.624 10.9749 170.624 10.9749C170.155 9.38109 169.544 7.80609 168.909 6.36329C167.269 6.82406 166.091 8.66726 166.17 10.8239C166.249 12.8861 167.459 14.5744 169.026 15.0087C168.384 18.4382 171.054 20.6137 171.485 20.9386L171.571 21.1124C171.508 21.2331 171.446 21.354 171.386 21.4786L169.751 21.7846C169.585 21.8149 169.449 21.9281 169.384 22.0867C169.324 22.2416 169.346 22.4191 169.449 22.5551L170.426 23.8469C170.291 24.0356 170.163 24.2207 170.045 24.3907L168.795 24.8892C168.64 24.9535 168.528 25.0894 168.496 25.2556C168.466 25.4219 168.528 25.588 168.651 25.7014C169.15 26.1432 169.626 26.6304 170.181 27.0006C170.609 27.2839 171.076 27.5105 171.568 27.6917C172.636 28.3111 174.03 28.9986 175.719 29.5802C175.523 31.8049 175.383 34.1844 175.658 34.1956C175.968 34.2107 176.855 31.9635 177.528 30.1279C177.679 30.1656 177.841 30.2034 178 30.2374C178.049 32.1184 178.155 34.3014 178.396 34.2864C178.66 34.2674 179.213 32.1184 179.575 30.5622C179.783 30.5962 179.998 30.6302 180.213 30.6605C180.326 32.4356 180.485 34.3279 180.655 34.3014C180.848 34.2712 181.15 32.3374 181.365 30.8002C182.563 30.9172 183.831 30.9589 185.18 30.8909C186.09 30.8455 186.94 30.7171 187.74 30.5245C187.955 32.0995 188.288 34.2712 188.488 34.3014C188.673 34.3316 188.848 32.0692 188.96 30.1732C189.123 30.1166 189.281 30.0561 189.436 29.9957C189.784 31.5291 190.445 34.2636 190.743 34.2825C191.03 34.3014 191.129 31.1665 191.159 29.1761C191.189 29.1572 191.219 29.1421 191.249 29.1232C191.914 31.0004 193.108 34.207 193.478 34.1881C193.836 34.1692 193.493 30.2072 193.244 27.7257C196.503 24.9799 198.063 21.2256 198.606 19.7261C198.599 19.73 198.588 19.7337 198.58 19.7412L198.92 18.9519C198.989 18.797 198.969 18.6195 198.871 18.4835C198.773 18.3476 198.614 18.2682 198.444 18.2796L196.786 18.3777C196.696 18.272 196.605 18.1662 196.514 18.0644L196.858 16.444C196.891 16.2779 196.839 16.1079 196.719 15.9945C196.598 15.8774 196.424 15.8321 196.261 15.8774L194.653 16.2966C194.585 16.24 194.513 16.1871 194.445 16.1342C196.714 14.3742 196.813 11.432 196.711 10.0345C198.286 9.73988 199.638 8.21023 199.936 6.19711V6.18955Z" fill="url(#paint1_radial_130_29)"/>
+<path d="M187.464 19.5265C188.502 19.205 189.02 17.9009 188.621 16.6136C188.223 15.3265 187.059 14.5436 186.02 14.8651C184.982 15.1868 184.464 16.4909 184.863 17.7781C185.261 19.0653 186.426 19.8481 187.464 19.5265Z" fill="black"/>
+<path d="M181.599 20.2878C182.669 20.0967 183.344 18.8664 183.106 17.5399C182.869 16.2134 181.81 15.293 180.74 15.4841C179.67 15.6752 178.995 16.9056 179.233 18.2321C179.47 19.5586 180.529 20.479 181.599 20.2878Z" fill="black"/>
+<path d="M186.208 17.4295C186.729 17.4295 187.151 17.0068 187.151 16.4853C187.151 15.9638 186.729 15.541 186.208 15.541C185.686 15.541 185.263 15.9638 185.263 16.4853C185.263 17.0068 185.686 17.4295 186.208 17.4295Z" fill="white"/>
+<path d="M180.541 18.1854C181.063 18.1854 181.486 17.7626 181.486 17.2411C181.486 16.7196 181.063 16.2969 180.541 16.2969C180.02 16.2969 179.598 16.7196 179.598 17.2411C179.598 17.7626 180.02 18.1854 180.541 18.1854Z" fill="white"/>
+</g>
+<defs>
+<radialGradient id="paint0_radial_130_29" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="translate(94.4272 45.2165) scale(67.7432 67.7433)">
+<stop stop-color="#79DDF5"/>
+<stop offset="0.34" stop-color="#DDD0FE"/>
+<stop offset="0.67" stop-color="#E39BFF"/>
+<stop offset="1" stop-color="#7C6EFF"/>
+</radialGradient>
+<radialGradient id="paint1_radial_130_29" cx="0" cy="0" r="1" gradientUnits="userSpaceOnUse" gradientTransform="translate(183.084 17.8792) scale(16.6678)">
+<stop stop-color="#79DDF5"/>
+<stop offset="0.34" stop-color="#DDD0FE"/>
+<stop offset="0.67" stop-color="#E39BFF"/>
+<stop offset="1" stop-color="#7C6EFF"/>
+</radialGradient>
+</defs>
+</svg>
diff --git a/static/assets/images/rust/lp-rust-consulting-og-image.jpg b/static/assets/images/rust/lp-rust-consulting-og-image.jpg
deleted file mode 100644
index 3c23d42394..0000000000
Binary files a/static/assets/images/rust/lp-rust-consulting-og-image.jpg and /dev/null differ
diff --git a/static/assets/images/rust/og-image.png b/static/assets/images/rust/og-image.png
new file mode 100644
index 0000000000..c7be3c4f60
Binary files /dev/null and b/static/assets/images/rust/og-image.png differ
diff --git a/static/assets/images/svelte/lp-svelte-consulting-og-image.jpg b/static/assets/images/svelte/lp-svelte-consulting-og-image.jpg
deleted file mode 100644
index c828391a54..0000000000
Binary files a/static/assets/images/svelte/lp-svelte-consulting-og-image.jpg and /dev/null differ
diff --git a/static/assets/images/svelte/og-image.png b/static/assets/images/svelte/og-image.png
new file mode 100644
index 0000000000..69e505cf26
Binary files /dev/null and b/static/assets/images/svelte/og-image.png differ
diff --git a/static/assets/images/svelte/sheepdog.svg b/static/assets/images/svelte/sheepdog.svg
new file mode 100644
index 0000000000..ed22985c54
--- /dev/null
+++ b/static/assets/images/svelte/sheepdog.svg
@@ -0,0 +1,12 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg width="50" height="45" viewBox="0 0 50 45" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linejoin:round;stroke-miterlimit:2;">
+    <g transform="matrix(1,0,0,1,0.00185215,-0.00032235)">
+        <g transform="matrix(0.500016,0,0,0.500002,-0.000926044,0.000161174)">
+            <path d="M31.398,8.323L25.128,1.464C24.564,0.845 23.808,0.432 22.982,0.292L21.597,0.054C20.827,-0.078 20.034,0.035 19.332,0.379L2.112,8.751C0.417,9.574 -0.41,11.552 0.196,13.337L8.486,37.693C8.908,38.921 9.935,39.847 11.2,40.14C12.734,40.494 14.334,39.846 15.19,38.525L31.771,12.9C32.693,11.471 32.537,9.587 31.391,8.33L31.398,8.322L31.398,8.323Z" style="fill:rgb(98,0,238);fill-rule:nonzero;"/>
+        </g>
+        <g transform="matrix(0.500016,0,0,0.500002,-0.000926044,0.000161174)">
+            <path d="M35.12,40.394C35.14,40.394 35.159,40.394 35.179,40.394C37.138,40.394 38.751,38.782 38.751,36.822C38.751,34.863 37.138,33.25 35.179,33.25C35.159,33.25 35.138,33.251 35.118,33.251C33.181,33.284 31.606,34.886 31.606,36.822C31.606,38.76 33.182,40.362 35.119,40.394L35.12,40.394ZM97.879,8.75L80.659,0.388C79.956,0.049 79.165,-0.065 78.395,0.063L77.009,0.3C76.185,0.444 75.43,0.856 74.864,1.472C74.298,2.088 54.255,23.887 54.263,23.958C51.73,27.063 50.55,30.318 52.988,35.673C55.134,40.243 66.518,49.304 66.518,54.389C66.518,54.389 66.574,55.142 66.653,56.306L66.606,56.306C66.606,62.151 64.025,66.872 59.702,68.923C56.488,70.452 52.885,70.096 49.924,68.013L49.924,65.493C49.924,65.493 50.004,65.438 50.035,65.399L54.184,61.225C56.646,58.745 54.896,54.524 51.397,54.524L43.1,54.524C39.608,54.524 37.85,58.745 40.313,61.224L44.383,65.312L44.383,68.219C42.102,70.014 38.991,70.371 36.363,69.137C34.683,68.345 33.813,67.149 33.813,66.381L28.27,66.381C28.27,69.494 30.463,72.471 33.986,74.143C34.762,74.507 35.633,74.816 36.559,75.038C36.567,78.951 36.899,84.075 40.09,87.291C41.873,89.09 44.248,90 47.145,90C56.773,90 58.237,80.606 58.459,75.125C59.71,74.875 60.925,74.47 62.077,73.921C64.429,72.804 66.44,71.149 68.031,69.09L85.694,50.136L73.446,24.71L74.911,23.252L84.8,38.524C85.655,39.846 87.256,40.494 88.79,40.14C90.056,39.848 91.084,38.921 91.506,37.693L99.795,13.337C100.405,11.552 99.577,9.571 97.879,8.751L97.879,8.75ZM44.026,83.37C42.411,81.739 42.142,78.214 42.102,75.394L52.885,75.394C52.537,81.858 50.835,84.44 47.145,84.44C45.76,84.44 44.739,84.091 44.026,83.37Z" style="fill:rgb(60,56,53);fill-rule:nonzero;"/>
+        </g>
+    </g>
+</svg>
diff --git a/static/assets/images/svelte/svelte-summit.png b/static/assets/images/svelte/svelte-summit.png
index 58d3402a9f..de91d31992 100644
Binary files a/static/assets/images/svelte/svelte-summit.png and b/static/assets/images/svelte/svelte-summit.png differ
diff --git a/static/assets/images/talks/2024-02-07-rustweb-london/luca-new.png b/static/assets/images/talks/2024-02-07-rustweb-london/luca-new.png
new file mode 100644
index 0000000000..3f432d2671
Binary files /dev/null and b/static/assets/images/talks/2024-02-07-rustweb-london/luca-new.png differ
diff --git a/static/assets/images/talks/2024-02-07-rustweb-london/new-thumbnail-luca.png b/static/assets/images/talks/2024-02-07-rustweb-london/new-thumbnail-luca.png
new file mode 100644
index 0000000000..2459dc11c1
Binary files /dev/null and b/static/assets/images/talks/2024-02-07-rustweb-london/new-thumbnail-luca.png differ
diff --git a/static/assets/images/talks/2024-02-07-rustweb-london/new-thumbnail.png b/static/assets/images/talks/2024-02-07-rustweb-london/new-thumbnail.png
new file mode 100644
index 0000000000..073cf0acf9
Binary files /dev/null and b/static/assets/images/talks/2024-02-07-rustweb-london/new-thumbnail.png differ
diff --git a/static/assets/images/talks/2024-02-07-rustweb-london/panel-new.png b/static/assets/images/talks/2024-02-07-rustweb-london/panel-new.png
new file mode 100644
index 0000000000..6e61a90b42
Binary files /dev/null and b/static/assets/images/talks/2024-02-07-rustweb-london/panel-new.png differ
diff --git a/static/assets/images/talks/2024-03-21-embereurope-2024-q1/ember-logo.png b/static/assets/images/talks/2024-03-21-embereurope-2024-q1/ember-logo.png
new file mode 100644
index 0000000000..c5ded6cc96
Binary files /dev/null and b/static/assets/images/talks/2024-03-21-embereurope-2024-q1/ember-logo.png differ
diff --git a/static/assets/images/talks/2024-03-21-embereurope-2024-q1/new-thumbnail.png b/static/assets/images/talks/2024-03-21-embereurope-2024-q1/new-thumbnail.png
new file mode 100644
index 0000000000..00a9f345a0
Binary files /dev/null and b/static/assets/images/talks/2024-03-21-embereurope-2024-q1/new-thumbnail.png differ
diff --git a/static/assets/images/talks/2024-03-21-embereurope-2024-q1/new-thumbnails.png b/static/assets/images/talks/2024-03-21-embereurope-2024-q1/new-thumbnails.png
new file mode 100644
index 0000000000..8ce1eb2440
Binary files /dev/null and b/static/assets/images/talks/2024-03-21-embereurope-2024-q1/new-thumbnails.png differ
diff --git a/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-logo.png b/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-logo.png
new file mode 100644
index 0000000000..290af85723
Binary files /dev/null and b/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-logo.png differ
diff --git a/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-thumbnail.png b/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-thumbnail.png
new file mode 100644
index 0000000000..60565b1b08
Binary files /dev/null and b/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-thumbnail.png differ
diff --git a/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-thumbnails.png b/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-thumbnails.png
new file mode 100644
index 0000000000..d82ec74c80
Binary files /dev/null and b/static/assets/images/talks/2024-03-26-rustnationuk-2024/new-thumbnails.png differ
diff --git a/static/assets/images/talks/2024-04-23-rust-web-berlin/new-thumbnails.png b/static/assets/images/talks/2024-04-23-rust-web-berlin/new-thumbnails.png
new file mode 100644
index 0000000000..74df54fe4b
Binary files /dev/null and b/static/assets/images/talks/2024-04-23-rust-web-berlin/new-thumbnails.png differ
diff --git a/static/assets/images/talks/2024-04-27-fullstack-testing/new-thumbnails.png b/static/assets/images/talks/2024-04-27-fullstack-testing/new-thumbnails.png
new file mode 100644
index 0000000000..b5268801b4
Binary files /dev/null and b/static/assets/images/talks/2024-04-27-fullstack-testing/new-thumbnails.png differ
diff --git a/static/assets/images/talks/2024-09-13-emberconf-2024/logo.svg b/static/assets/images/talks/2024-09-13-emberconf-2024/logo.svg
new file mode 100644
index 0000000000..39a5037a1c
--- /dev/null
+++ b/static/assets/images/talks/2024-09-13-emberconf-2024/logo.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="324" height="214" viewBox="0 0 324 214"><g fill="none" fill-rule="evenodd" transform="translate(.659 .34)"><g fill-rule="nonzero"><path fill="#EE9A37" d="M94.4889859,73.554074 C96.001118,77.5140835 102.085986,83.1548004 102.601807,83.5989514 C102.914731,83.467725 110.737844,80.2981023 110.258363,72.3417438 C105.709854,73.3380552 100.476948,71.2737627 98.8820425,69.7858571" transform="rotate(-13 102.384 76.692)"/><path fill="#EE9A37" d="M94.279448,68.0744332 C95.3232028,67.2103577 96.2236179,65.133952 96.9675707,65.7335558 C99.2115424,67.557603 97.6872971,74.3621973 94.7831556,76.8827539 C94.5307971,77.0987728 94.2673348,77.3147916 94.0028631,77.5065841 C93.3853227,74.2465054 92.8132546,70.9779773 92.2868254,67.701952 C93.0550047,68.1935464 93.7626179,68.5064709 94.279448,68.0744332 L94.279448,68.0744332 Z" transform="rotate(-13 95.165 71.567)"/><g transform="rotate(2 -696.366 85.155)"><path fill="#FBCA4F" d="M72.2088491,5.06836792 C72.2088491,5.06836792 55.1373019,9.35442453 34.7245283,23.6510377 C14.3117547,37.9476509 0.678339623,40.5257453 0.678339623,40.5257453 L15.3151321,52.6853868 L16.4123868,72.2684057 C16.4123868,72.2684057 29.3028585,70.2828491 50.4585755,55.3916792 C71.6163113,40.5005094 87.9388585,36.808 87.9388585,36.808 L72.2088491,5.06836792 Z"/><path fill="#110A22" d="M28.294434,40.8235283 L28.9303774,54.1036415 L25.8465566,55.7833396 L19.581,45.5779623 L22.3872264,44.0496792 L26.1927925,51.138934 L25.2913679,42.4588113 L28.2934245,40.8235283 L28.294434,40.8235283 Z M31.2116981,38.8531132 L35.3130283,50.3677264 L32.6501415,51.9999811 L28.576066,40.4712358 L31.2116981,38.8531132 Z M40.613566,37.7326415 C41.1445283,39.0267358 41.3302642,40.6741321 40.2713679,41.6098774 L43.930566,44.7108585 L41.0617547,46.6358491 L37.7235566,43.0049151 L39.5869717,47.6240849 L36.9977736,49.3653585 L32.4553208,38.0142736 L35.4805943,35.982283 C38.7673113,33.7746509 40.0301132,36.3254906 40.613566,37.7336509 L40.613566,37.7326415 Z M46.1886698,29.2756038 L47.1829623,32.0616415 L45.3155094,33.1982642 L48.3841887,41.9379434 L45.7465377,43.5399151 L42.6778585,34.8002358 L40.8316038,35.9267642 L39.8514434,33.1336604 L46.1886698,29.2756038 L46.1886698,29.2756038 Z M36.7030189,38.6068113 L36.1125,39.0025094 L37.1259717,41.5180189 L37.4994623,41.2676792 C38.1656887,40.8184811 38.3473868,40.2481509 37.9537075,39.299283 C37.5469057,38.2878302 37.1986509,38.2726887 36.7020094,38.6068113 L36.7030189,38.6068113 Z M55.097934,24.5655849 L57.0945943,31.5034245 C58.0858585,34.9556887 57.6841038,36.9473019 54.9152264,38.420066 C52.1110189,39.9069623 50.3939717,38.7955755 49.3946321,35.3281698 L47.461566,28.6305755 L50.2314528,27.1568019 L52.1261604,33.9805755 C52.5783868,35.6229245 53.064934,36.0196321 53.7675,35.6673396 C54.5165,35.2877925 54.7305,34.6356981 54.3418679,33.1346698 L52.3260283,26.0534906 L55.097934,24.5655849 L55.097934,24.5655849 Z M62.3275,21.3939434 L67.7350377,32.0747642 L64.8864151,33.3315094 L64.0526226,31.5609623 L61.7147736,32.6168302 L61.6966038,34.7739906 L58.6783962,36.1236038 L59.1023585,22.8364245 L62.3275,21.392934 L62.3275,21.3939434 Z M69.3783962,18.6896698 L70.7068113,27.9562736 L73.4060377,26.9619811 L73.7976981,29.8035377 L68.2417736,31.8526887 L66.4671887,19.7626981 L69.3783962,18.6896698 L69.3783962,18.6896698 Z M61.3271509,25.3347736 L61.5371132,29.7621509 L63.1279811,29.1292358 L61.3271509,25.3347736 L61.3271509,25.3347736 Z"/><path fill="#B48984" d="M70.6775377,0.339169811 C71.644968,-0.138493954 72.8169059,0.236526181 73.3273019,1.18709434 L73.3575849,1.24766038 L99.51,54.1631981 C99.9910025,55.1420987 99.5997787,56.3259031 98.6301911,56.8254126 C97.6606036,57.3249221 96.4695816,56.9562548 95.9517453,55.9963302 L95.9214623,55.9367736 L69.7700566,3.02022642 C69.2804522,2.0292688 69.6867072,0.829031407 70.6775377,0.339169811 Z"/></g><path fill="#EE9A37" d="M90.8130412,78.5726806 C91.1138762,79.0782043 91.6586769,79.3879666 92.2469421,79.3879666 C92.8352074,79.3879666 93.380008,79.0782043 93.680843,78.5726806 C94.3652393,77.6954825 93.2730317,76.1712372 93.2245789,75.7765485 C93.1054657,74.7560108 94.2935695,74.5753221 94.1007676,73.0510768 C93.9695412,71.9356523 92.3605034,71.6832938 92.3009468,71.4309353 C92.5402418,70.5869979 92.7047422,69.7236244 92.7925412,68.8508221 C92.6613147,68.0836523 92.1444846,67.3750296 91.4600883,67.5910485 C88.7961921,68.3824447 86.1080695,72.8835108 90.8130412,78.5716711 L90.8130412,78.5726806 Z" transform="rotate(-13 91.181 73.47)"/><path fill="#46858F" d="M112.433585,71.172946 C110.008559,70.9929321 107.573526,70.9929321 105.1485,71.172946 C106.108472,76.9095592 103.876613,78.8173894 101.428736,80.9775781 L104.848698,85.9227951 L110.309736,76.1777196 L112.433585,71.172946 Z" transform="rotate(-13 106.931 78.48)"/><polygon fill="#EE9A37" points="149.21 64.993 118.487 64.993 118.487 82.252 149.21 82.252" transform="rotate(-13 133.849 73.622)"/><path fill="#46858F" d="M168.790402,72.4522969 C168.790402,76.1488441 163.185015,77.6609761 163.185015,77.6609761 C163.185015,77.6609761 162.561185,72.008146 159.188666,69.6925044 C155.817156,67.3758535 154.388807,57.8710233 154.388807,57.8710233 C163.905751,60.559146 168.226128,65.671929 168.790402,72.4522969" transform="rotate(-13 161.59 67.766)"/><path fill="#EE9A37" d="M168.562202,66.2661294 C169.323453,67.9185713 169.779,69.6952716 169.906768,71.5101388 C169.906768,75.206686 164.301381,78.1219313 164.301381,78.1219313 C164.301381,78.1219313 164.961551,73.5744313 162.658022,70.9216388 L168.563211,66.2661294 L168.562202,66.2661294 Z" transform="rotate(-13 166.282 72.194)"/><path fill="#46858F" d="M135.254285,79.8036871 L155.872984,61.8974503 C162.569568,66.0260093 170.705606,93.1008773 169.745635,105.953919 C157.903597,107.244304 146.002425,107.917494 134.090408,107.970756 C123.028799,107.989938 111.985016,107.082656 101.074851,105.258424 C99.1791345,92.4407116 106.079625,67.0586538 119.305229,62.2214765 L135.254285,79.8036871 Z" transform="rotate(-13 135.294 84.934)"/><path fill="#090513" d="M132.014978,81.2925533 C132.406887,81.2928898 132.785883,81.1524677 133.08296,80.8968546 L153.689544,62.9905061 C154.221669,62.642983 154.501455,62.0164283 154.405034,61.3882307 C154.308613,60.7600332 153.853797,60.246231 153.241941,60.0742951 C152.630086,59.9023592 151.974211,60.104049 151.564686,60.5900722 L132.147214,77.4163264 L116.904761,60.9978835 C116.298207,60.3353007 115.269368,60.2898808 114.606785,60.8964354 C113.944202,61.5029899 113.898782,62.5318289 114.505337,63.1944117 L130.827884,80.776732 C131.137357,81.1022722 131.565826,81.2880878 132.014978,81.2915433 L132.014978,81.2925533 Z" transform="rotate(-13 134.251 70.653)"/><path fill="#EE9A37" d="M136.773914,12.34 C144.598037,13.1798491 149.74615,4.63499056 155.303084,8.21141509 C151.775112,9.53175471 150.310423,15.2320283 144.633367,20.8242924 C143.314037,22.1325189 134.636942,12.0997547 136.772904,12.34" transform="rotate(-13 145.87 14.137)"/><path fill="#E54D3A" d="M143.213207,17.5930796 C148.493556,18.5167117 153.402433,4.87219281 155.982547,7.27161733 C163.447311,14.1731173 152.069981,28.1184475 144.43765,26.1742777 C140.177839,25.0941834 142.15633,17.3528343 143.236424,17.5446268" transform="rotate(-13 150.121 16.673)"/><path fill="#EE9A37" d="M90.9352754,19.0774508 C94.8720679,16.2813188 100.992266,18.3809414 105.840577,20.9136112 C108.601379,22.3540735 112.465492,21.9937056 112.657285,22.6175357 C113.089323,24.1175546 108.960738,26.481649 105.876917,26.0021678 C102.792087,25.5216773 98.4121528,19.0653376 90.9352754,19.0774508" transform="rotate(-13 101.812 21.907)"/><path fill="#E54D3A" d="M107.86379,26.031787 C104.803186,26.9079757 95.934299,14.750353 90.6771669,21.1360323 C87.220865,25.3231643 94.6614028,35.7284096 100.746271,37.5403436 C106.831139,39.353287 109.495035,25.5391832 107.874893,26.031787" transform="rotate(-13 99.07 28.49)"/><path fill="#EE9A37" d="M130.366273,8.67306834 C155.460793,9.27267186 153.552963,26.6742966 153.54085,31.2823606 C153.54085,38.4836595 158.497169,50.185013 158.485078,53.4969644 C158.485078,66.6983362 137.590789,70.8390325 127.8225,70.8269458 C110.456204,70.8026929 93.1625872,63.3974885 93.1625872,51.7324746 C93.1625872,49.0928059 101.935575,36.5394905 103.45881,25.2106179 C104.227999,19.7011297 111.404062,8.21680438 130.366273,8.67205891" transform="rotate(-13 125.824 39.743)"/><path fill="#FDF7F0" d="M130.96067,43.9166382 C140.825868,43.9166382 150.846519,59.9968908 160.711717,45.1158435 C161.639879,47.6793939 162.248447,50.3475962 162.523651,53.0600737 C162.523651,66.2624355 141.629378,70.4021164 131.860076,70.3910349 C114.470557,70.3425599 97.1769341,62.9373664 97.1769341,51.2723696 C97.3748044,50.2079489 97.7436421,49.1825682 98.2691417,48.235998 C105.817689,59.5052974 119.090736,43.8439591 130.936444,43.8681574" transform="rotate(-13 129.85 57.13)"/><path fill="#E54D3A" d="M126.811038,44.4526266 C128.186636,44.0902662 129.637936,44.1358604 130.988076,44.5838531 C131.395887,44.9926738 132.284189,46.6965983 131.251538,47.3931078 C130.903283,47.6323436 130.880066,46.6249285 130.051321,46.7924946 C129.079236,46.984287 129.595057,48.24507 128.851104,48.2208436 C127.650887,48.2208436 128.851104,46.8651738 127.783123,46.6844851 C127.027057,46.5532587 126.847378,47.2850983 126.582906,47.2245323 C125.455368,47.0206266 125.983302,45.0037776 126.823151,44.4526266" transform="rotate(-13 128.836 46.216)"/><path fill="#090513" d="M143.28811,50.7528445 C143.400357,50.6690763 143.541841,50.6345536 143.680055,50.6572085 C143.818269,50.6798634 143.941329,50.7577481 144.020959,50.8729671 C144.186587,51.1156362 144.127831,51.4461917 143.888723,51.61692 C142.073316,52.6877592 140.082026,53.4274007 138.007761,53.8013351 C137.540393,55.2650143 136.31595,59.5137219 136.039365,59.90942 C135.524554,60.6301558 128.083006,61.4578917 127.243157,61.1106464 C126.607214,60.8582879 123.811082,56.7418162 122.945997,55.0136653 C120.80963,55.0013265 118.693959,54.5940718 116.705676,53.8124388 C116.444301,53.6835788 116.336769,53.367308 116.465431,53.1058351 C116.598344,52.8474754 116.915035,52.7450695 117.174054,52.8766936 C119.091978,53.5974294 121.124978,53.9638539 123.174129,53.9567879 C123.233788,53.9450602 123.295159,53.9450602 123.354818,53.9567879 C127.13769,54.0521381 130.92211,53.8435241 134.671582,53.3329577 C138.356016,52.8050237 141.644752,51.9046087 143.28811,50.7528445 L143.28811,50.7528445 Z M136.819657,54.0890237 C136.159488,54.2091464 135.427648,54.329269 134.635242,54.4251653 C131.172014,54.9424556 127.671391,55.1673437 124.17044,55.0974483 C125.171667,56.8770676 126.323969,58.5673579 127.614629,60.1496653 C130.160127,60.0957027 132.695179,59.8064458 135.187403,59.2855898 C135.319639,59.0937973 136.255384,55.9494105 136.819657,54.0890237 L136.819657,54.0890237 Z" transform="rotate(-13 130.263 55.921)"/><path fill="#1D2946" d="M131.134097,55.8102967 L132.585663,60.0226646 C132.670456,60.2629099 132.489767,60.5021457 132.189965,60.5627118 C131.909346,60.6448967 131.610369,60.5126813 131.482352,60.2497872 L130.73739,55.9536363 C130.73739,55.8526929 130.816126,55.7689099 130.918079,55.7618438 C131.012547,55.7473047 131.105339,55.796575 131.146211,55.8829759 L131.134097,55.8102967 L131.134097,55.8102967 Z" transform="rotate(-13 131.672 58.173)"/><path fill="#46858F" d="M141.095374,11.534668 C135.694902,5.96663023 141.466845,2.04195098 140.795572,0.505592493 C142.919421,2.35285664 145.187619,6.42188495 144.395213,9.51882834 C143.603817,12.6147623 141.455741,11.9182529 141.059034,11.534668" transform="rotate(-13 141.661 6.194)"/><path fill="#6EA952" d="M141.780164,9.62498986 C143.039937,1.93209364 149.616399,4.3325276 150.445145,2.86783892 C150.217013,5.6760842 148.29606,9.92378232 145.367692,11.1371219 C142.440333,12.3484427 141.683258,10.188254 141.76805,9.62498986" transform="rotate(-13 146.103 7.184)"/><path fill="#2F3E4A" d="M143.734466,9.01669941 C150.934758,4.51462394 153.10706,9.89187866 154.535409,9.94033149 C153.335192,13.539973 144.730777,13.8640013 144.178617,13.3360673 C143.626456,12.8081334 142.750268,9.60418998 143.698126,9.01568998" transform="rotate(-13 148.907 10.378)"/><path fill="#FDF7F0" d="M145.066654,10.5081461 C149.663616,9.83687249 150.575135,18.3696178 151.235305,18.9096649 C147.947578,19.3174763 144.970758,15.7895046 144.479163,15.0808819 C142.641994,12.3685329 144.479163,10.6050517 145.066654,10.5202593" transform="rotate(-13 147.46 14.706)"/><path fill="#090513" d="M125.276741,36.8325588 C125.565482,36.2970487 126.08433,35.9239619 126.683899,35.8207171 C127.283467,35.7174722 127.897221,35.8955267 128.348448,36.3036154 C129.86058,38.296238 130.341071,40.9490305 133.520788,44.3932192 C137.121439,48.293672 148.090958,47.6688324 152.050967,42.592389 C154.451401,39.4601154 156.635816,33.8910682 157.055741,33.1360116 C157.330073,31.7154174 156.595723,30.2917795 155.279137,29.6918229 C153.93558,29.3788984 144.154165,27.9990022 129.235741,33.3994739 C127.788293,33.7900048 126.265953,33.8108303 124.808363,33.4600399 C123.728269,33.2682475 114.499014,27.2792758 98.4056087,30.6517946 C97.0249572,31.2093428 96.3078802,32.7372584 96.7612408,34.1555399 C97.5183162,35.0438418 99.7259483,40.7330116 102.090043,43.4211343 C107.514741,49.6251154 118.399467,47.3094739 120.643439,44.6213512 C122.554912,42.2617697 124.115465,39.638409 125.276741,36.8325588" transform="rotate(-13 126.87 38.336)"/><path fill="#FDF7F0" d="M105.000663,42.7331184 C106.657144,44.3885901 113.402182,46.1056373 118.046588,43.441741 C120.66304,41.9528259 122.258956,36.8289391 120.686257,35.2451373 C117.61455,32.1360807 110.749389,31.0923259 104.401059,33.299958 C103.643984,33.5644297 98.7966819,36.540241 105.000663,42.7331184 M148.69704,42.7331184 C147.076899,44.4138259 140.392427,46.2378731 135.664239,43.6577599 C133.035672,42.2172976 131.343861,37.1166278 132.891323,35.5085995 C135.904484,32.3520995 142.744408,31.1882222 149.129078,33.276741 C149.897257,33.5290995 154.794022,36.4211278 148.69704,42.7331184" transform="rotate(-13 126.8 38.534)"/><path fill="#090513" d="M113.093799,38.5870204 C112.962573,40.1465959 112.266064,41.3710393 111.509998,41.3114827 C110.753932,41.2509166 110.250224,39.930577 110.309781,38.3710015 C110.370347,36.8104166 111.137516,35.5859732 111.894592,35.6455298 C112.649649,35.7060959 113.154366,37.0143223 113.034243,38.5870204 M143.037649,38.1781997 C143.301111,39.7266714 142.905413,41.0833506 142.16146,41.2034732 C141.417507,41.3225865 140.612988,40.1829355 140.348516,38.6344638 C140.085054,37.0870015 140.480752,35.7424355 141.224705,35.6101997 C141.968658,35.4789732 142.773177,36.629728 143.037649,38.1781997" transform="rotate(-13 126.712 38.457)"/><path fill="#FDF7F0" d="M112.275489,36.5499368 C112.273325,36.4083871 112.19581,36.2787442 112.072143,36.2098433 C111.948475,36.1409424 111.797443,36.1432512 111.67594,36.2158999 C111.554436,36.2885487 111.48092,36.4205003 111.483083,36.56205 C111.499808,36.7808667 111.690753,36.9446946 111.909569,36.9279698 C112.128386,36.9112449 112.292214,36.7203007 112.275489,36.5014839 M141.96597,36.1895688 C141.96597,35.9707521 141.788584,35.793366 141.569767,35.793366 C141.350951,35.793366 141.173565,35.9707521 141.173565,36.1895688 C141.176142,36.2961744 141.22298,36.3968959 141.30284,36.467563 C141.382699,36.5382301 141.488372,36.5724642 141.594499,36.56205 C141.699516,36.5558178 141.79773,36.5080225 141.867434,36.429226 C141.937139,36.3504296 141.972596,36.2471193 141.96597,36.1421254" transform="rotate(-13 126.725 36.361)"/><path fill="#090513" d="M145.883154,17.9761488 C146.074946,19.3923847 148.139239,21.8523753 151.883229,22.3328658 C149.363682,20.7843941 148.522823,14.6763092 147.587078,13.5841017" transform="rotate(-13 148.883 17.958)"/><path fill="#090513" d="M148.247884,21.6037978 L147.34848,21.4725714 C146.147257,28.8525431 128.602333,27.8562318 114.357239,31.5648921 C117.250935,30.2500587 119.862893,28.3877483 122.049105,26.0806374 C115.509,29.1765714 109.075895,32.6086469 98.6474608,32.6086469 C99.5832036,32.4168544 111.272417,30.6291469 114.873059,25.0479865 C114.993181,24.6401752 107.072174,31.0490714 97.2907852,31.0490714 C99.3550721,30.413128 107.839342,26.9204865 108.176492,24.688628 C103.375637,27.952128 96.7154094,30.1607695 96.7505995,29.8730808 C97.5552562,23.1764959 102.16331,16.8392695 103.603768,15.3392506 C112.928894,5.7738544 142.451729,2.60625063 148.247884,21.6037978 Z" transform="rotate(-13 122.5 20.169)"/></g><g transform="translate(46.54 43.646)"><polygon fill="#E15D44" points="167.841 0 0 65.505 6.509 131.864 193.043 167.947 276.562 127.138 260.99 72.487"/><path fill="#FEFEFE" d="M134.321311 129.031755 134.321311 139.810674 91.1833869 129.031755 134.321311 129.031755ZM244.471475 129.031755 202.347851 139.556981 202.347851 129.031755 244.471475 129.031755ZM175.625397 96.8581132C175.625397 96.8581132 174.634301 93.3393386 178.332344 86.5732523 182.030386 79.8058855 184.920442 83.5052086 184.920442 83.5052086 184.920442 83.5052086 188.075559 86.9343493 184.468431 92.0780602 180.858742 97.2166492 175.625397 96.8581132 175.625397 96.8581132M147.208859 101.7278C142.96789 112.828331 132.68431 108.314619 132.68431 108.314619 132.68431 108.314619 131.511385 104.345113 134.849611 93.2484241 138.186557 82.1542962 146.035934 86.4810573 146.035934 86.4810573 146.035934 86.4810573 151.448547 90.6336724 147.208859 101.7278M139.54003 55.2679385C139.54003 55.2679385 145.94758 38.5780883 147.480322 46.7002089 149.010502 54.8172076 134.036503 78.9953381 134.036503 78.9953381 134.217051 73.5827251 139.54003 55.2679385 139.54003 55.2679385M47.971219 96.8581132C48.2426819 86.1225213 55.2789507 81.4308218 57.7157149 83.7779521 60.1524792 86.1225213 59.2484563 91.1740373 54.6476713 94.331715 50.0481667 97.4893927 47.971219 96.8581132 47.971219 96.8581132M242.023701 95.0756772C241.661324 91.4634271 238.415292 92.8092175 238.415292 92.8092175 238.415292 92.8092175 233.181947 96.8632352 228.581162 96.4137847 223.984219 95.9617733 225.426046 85.6730709 225.426046 85.6730709 225.426046 85.6730709 226.415861 76.2474158 223.710195 75.4547952 221.003248 74.666016 217.665022 77.9146082 217.665022 77.9146082 217.665022 77.9146082 213.517529 82.5141127 211.530215 88.3761761L210.98857 88.5580051C210.98857 88.5580051 211.62241 78.2731442 210.901497 75.9260139 210.358571 74.7543695 205.396689 74.845284 204.584861 76.9196708 203.774313 78.9953381 199.802247 93.4302531 199.532064 99.4741455 199.532064 99.4741455 191.773602 106.060964 185.008796 107.141694 178.245271 108.226265 176.619054 103.984016 176.619054 103.984016 176.619054 103.984016 195.020913 98.8415855 194.389634 84.1364881 193.758354 69.4313906 179.551366 74.8696132 177.941795 76.0783917 176.387286 77.2500361 168.079495 82.2567351 165.658096 96.1282364 165.576145 96.6007356 165.43145 98.6623175 165.43145 98.6623175 165.43145 98.6623175 158.305548 103.443651 154.336042 104.70749 154.336042 104.70749 165.43145 86.0290459 151.900558 77.5522307 146.637682 74.3405774 142.821449 79.2810299 142.84017 79.2572491 147.443309 73.4098833 158.377353 57.7005678 155.146589 43.9919817 153.216898 35.78791 149.11166 34.9043749 145.345752 36.230958 139.628384 38.4884543 137.465643 41.8266804 137.465643 41.8266804 137.465643 41.8266804 130.068277 52.5622723 128.353707 68.5312091 126.639137 84.497585 124.112739 103.804748 124.112739 103.804748 124.112739 103.804748 120.595244 107.233889 117.346652 107.410596 114.099341 107.591144 115.543728 97.7570142 115.543728 97.7570142 115.543728 97.7570142 118.068846 82.7830147 117.889578 80.2591774 117.707749 77.7302182 117.52592 76.3780254 114.550072 75.475283 111.574223 74.573821 108.325631 78.3640586 108.325631 78.3640586 108.325631 78.3640586 99.7566206 91.3507443 99.0344267 93.3393386L98.5824152 94.152447 98.1316843 93.612082C98.1316843 93.612082 104.175577 75.9260139 98.4031472 75.6558314 92.6281569 75.3869294 88.8391997 81.9724673 88.8391997 81.9724673 88.8391997 81.9724673 82.2536619 92.9782416 81.982199 94.2433615L81.5327485 93.6991551C81.5327485 93.6991551 84.2371342 80.8891764 83.6967693 77.7302182 83.1564043 74.573821 80.1792751 75.206381 80.1792751 75.206381 80.1792751 75.206381 76.3890375 74.7543695 75.3966611 77.1924142 74.4055652 79.625337 70.7971566 95.7748224 70.3451452 100.915972 70.3451452 100.915972 60.8733926 107.6859 54.6476713 107.772973 48.4232304 107.862607 49.0557903 103.823955 49.0557903 103.823955 49.0557903 103.823955 71.879167 96.0142732 65.6547261 80.5857013 62.8581454 76.6161957 59.6082728 75.3690026 55.0087682 75.4586366 50.4079832 75.5495511 44.7431146 78.3538148 41.0437915 86.6552034 39.2805627 90.6183065 38.6800149 94.3714101 38.3201984 97.2153687 38.3201984 97.2153687 34.2789856 98.0271967 32.1124039 96.2255533 29.9483831 94.42391 28.8113118 96.2255533 28.8113118 96.2255533 28.8113118 96.2255533 25.0825375 100.229632 28.7831411 101.6753 32.4824642 103.119688 38.2433693 103.053103 38.2433693 103.053103L38.2408083 103.053103C38.7722099 106.89456 40.3139146 110.606688 44.8199437 114.030707 51.5834691 119.170576 64.5739962 113.918024 64.5739962 113.918024L69.8956947 111.118882C69.8956947 111.118882 70.0736822 116.093569 73.9548343 116.80808 77.8347059 117.52003 79.4583617 116.842653 86.2257285 100.425546 90.1926731 92.0319627 90.4628556 92.5031815 90.4628556 92.5031815L90.9161475 92.4276328C90.9161475 92.4276328 87.8468233 108.490045 89.0197482 112.820648 90.1926731 117.14997 95.3325426 116.7018 95.3325426 116.7018 95.3325426 116.7018 98.1316843 116.705641 100.385339 108.76663 102.641555 100.827619 106.972157 91.5287319 106.972157 91.5287319L107.513803 91.5287319C107.513803 91.5287319 105.619965 108.499008 108.506179 113.727232 111.393674 118.958015 118.880674 115.75424 118.880674 115.75424 118.880674 115.75424 124.112739 113.254732 124.925847 112.440343 124.925847 112.440343 131.136203 117.790213 139.896005 116.836251 159.478472 112.981989 166.441754 107.812668 166.441754 107.812668 166.441754 107.812668 169.80815 116.353508 180.226182 117.142287 192.13726 118.042468 198.630602 110.564432 198.630602 110.564432 198.630602 110.564432 198.540968 115.439241 202.691023 117.155092 206.842357 118.868381 209.636377 109.317239 209.636377 109.317239L216.581731 90.2482462 217.215572 90.2482462C217.215572 90.2482462 217.576668 102.62414 224.433669 104.608893 231.286829 106.594926 240.219497 99.9171935 240.219497 99.9171935 240.219497 99.9171935 242.386078 98.6828053 242.023701 95.0756772"/><path fill="#FEFEFE" d="M87.8507454 46.2725076C91.3047097 46.6329837 93.2033129 48.5402039 93.5479913 51.9941682L93.5479913 60.3712884C93.2033129 63.8252527 91.3047097 65.6980051 87.8507454 65.9909817 84.3795471 65.6807711 82.4895608 63.8080188 82.1807865 60.3712884L82.1807865 51.9941682C82.4895608 48.5402039 84.3795471 46.6329837 87.8507454 46.2725076ZM74.1606491 46.2715023C77.6146134 46.6334145 79.5045997 48.5406348 79.8320442 51.9945991 79.8148102 52.4757126 79.7803424 52.9482092 79.7286407 53.4120888 79.4873658 54.0655415 79.1441236 54.6486224 78.6974779 55.1642038 76.9625969 57.5697714 75.2090458 59.9681583 73.4396969 62.3564921L78.8267323 62.3564921C79.4615149 62.4426616 79.8406611 62.7859038 79.9612985 63.3876548L79.9612985 64.7275919C79.8406611 65.3810446 79.4543341 65.7415207 78.8008814 65.8104564L69.7272238 65.8104564C69.0737711 65.7415207 68.713295 65.3810446 68.6457955 64.7275919L68.6457955 63.3876548C68.6457955 63.1980817 68.6960611 63.0257425 68.7994646 62.8720734 71.3601375 59.6407139 73.8518747 56.3160039 76.2746763 52.8965074 76.2746763 52.5187974 76.2832933 52.1497043 76.3005272 51.7877921 76.0434546 50.6201942 75.3296832 49.9925923 74.1606491 49.9064227 72.8034781 50.0270602 72.0724728 50.7666825 71.9705054 52.1238535L71.9705054 53.1033145C71.8843358 53.755331 71.5152427 54.1172433 70.86179 54.1861789L69.5477038 54.1861789C68.8770172 54.0985732 68.533775 53.7309163 68.5165411 53.0774636L68.5165411 51.9945991C68.7908476 48.5234008 70.6722169 46.6161806 74.1606491 46.2715023ZM101.486684 46.2715023C104.940649 46.6334145 106.830635 48.5406348 107.158079 51.9945991 107.140845 52.4757126 107.106378 52.9482092 107.054676 53.4120888 106.813401 54.0655415 106.470159 54.6486224 106.023513 55.1642038 104.288632 57.5697714 102.535081 59.9681583 100.765732 62.3564921L106.152768 62.3564921C106.78755 62.4426616 107.166696 62.7859038 107.287334 63.3876548L107.287334 64.7275919C107.166696 65.3810446 106.780369 65.7415207 106.126917 65.8104564L97.0532591 65.8104564C96.3998063 65.7415207 96.0393302 65.3810446 95.9718307 64.7275919L95.9718307 63.3876548C95.9718307 63.1980817 96.0220963 63.0257425 96.1254998 62.8720734 98.6861727 59.6407139 101.17791 56.3160039 103.600712 52.8965074 103.600712 52.5187974 103.609329 52.1497043 103.626562 51.7877921 103.36949 50.6201942 102.655718 49.9925923 101.486684 49.9064227 100.129513 50.0270602 99.398508 50.7666825 99.2965407 52.1238535L99.2965407 53.1033145C99.2103711 53.755331 98.841278 54.1172433 98.1878253 54.1861789L96.8737391 54.1861789C96.2030525 54.0985732 95.8598103 53.7309163 95.8425763 53.0774636L95.8425763 51.9945991C96.1168829 48.5234008 97.9982522 46.6161806 101.486684 46.2715023ZM115.139773 46.2715023C118.593737 46.6334145 120.483724 48.5406348 120.811168 51.9945991 120.793934 52.4757126 120.759466 52.9482092 120.707765 53.4120888 120.46649 54.0655415 120.123248 54.6486224 119.676602 55.1642038 117.941721 57.5697714 116.18817 59.9681583 114.418821 62.3564921L119.805856 62.3564921C120.440639 62.4426616 120.819785 62.7859038 120.940423 63.3876548L120.940423 64.7275919C120.819785 65.3810446 120.433458 65.7415207 119.780005 65.8104564L110.706348 65.8104564C110.052895 65.7415207 109.692419 65.3810446 109.624919 64.7275919L109.624919 63.3876548C109.624919 63.1980817 109.675185 63.0257425 109.778589 62.8720734 112.339262 59.6407139 114.830999 56.3160039 117.2538 52.8965074 117.2538 52.5187974 117.262417 52.1497043 117.279651 51.7877921 117.022579 50.6201942 116.308807 49.9925923 115.139773 49.9064227 113.782602 50.0270602 113.051597 50.7666825 112.949629 52.1238535L112.949629 53.1033145C112.86346 53.755331 112.494367 54.1172433 111.840914 54.1861789L110.526828 54.1861789C109.856141 54.0985732 109.512899 53.7309163 109.495665 53.0774636L109.495665 51.9945991C109.769972 48.5234008 111.651341 46.6161806 115.139773 46.2715023ZM87.8507454 49.9059919C86.4935743 50.0610971 85.753952 50.8079002 85.6347508 52.1492735L85.6347508 60.3971392C85.771186 61.7370763 86.5108083 62.4680817 87.8507454 62.5872829 89.1921186 62.4680817 89.9303047 61.7370763 90.0681761 60.3971392L90.0681761 52.1492735C89.9303047 50.7921025 89.1921186 50.0438632 87.8507454 49.9059919ZM148.474655 124.668139C151.912496 125.03072 153.811038 126.944833 154.171394 130.416039L154.171394 131.500444C154.051275 132.135516 153.682022 132.504769 153.062521 132.607093L151.696727 132.607093C151.042748 132.54036 150.674606 132.17778 150.588966 131.524913L150.588966 130.496119C150.467735 129.205955 149.763707 128.483019 148.474655 128.329534 147.117759 128.483019 146.37814 129.205955 146.258021 130.496119L146.258021 138.767623C146.37814 140.108948 147.117759 140.83967 148.474655 140.9609 149.763707 140.83967 150.467735 140.108948 150.588966 138.767623L150.588966 137.660974C150.674606 137.008107 151.061655 136.647751 151.749001 136.576569L153.012471 136.576569C153.664226 136.664434 154.051275 137.02479 154.171394 137.660974L154.171394 138.767623C153.775447 142.205463 151.876905 144.079537 148.474655 144.387619 145.003449 144.112903 143.129375 142.238829 142.854659 138.767623L142.854659 130.416039C143.113804 126.944833 144.986765 125.03072 148.474655 124.668139ZM162.110385 124.668807C165.566021 125.012479 167.464563 126.911022 167.808236 130.366657L167.808236 138.76829C167.44788 142.205018 165.548225 144.079092 162.110385 144.387174 158.674769 144.061296 156.79291 142.189447 156.46592 138.76829L156.46592 130.366657C156.758431 126.911022 158.64029 125.012479 162.110385 124.668807ZM194.708771 124.873787C195.343843 124.979447 195.713097 125.3487 195.817645 125.983772L195.817645 127.323985C195.713097 128.011331 195.336058 128.372799 194.683191 128.406165L188.548241 128.406165C188.204569 128.439531 188.014381 128.630832 187.979902 128.973392L187.979902 132.298899C188.014381 132.642572 188.204569 132.821638 188.548241 132.841658L192.440976 132.841658C193.074935 132.927298 193.42973 133.278756 193.497575 133.89492L193.497575 135.288519C193.42973 135.960294 193.06715 136.302855 192.414283 136.32065L188.548241 136.32065C188.204569 136.370699 188.014381 136.570897 187.979902 136.913458L187.979902 143.124037C187.929853 143.776904 187.577282 144.140597 186.923303 144.208442L185.608671 144.208442C184.991395 144.175075 184.64661 143.855871 184.578765 143.253054L184.578765 125.959304C184.594336 125.357598 184.895745 124.993906 185.480767 124.873787L194.708771 124.873787ZM171.170213 124.900925 172.795151 124.900925C173.482497 124.848651 173.989664 125.151172 174.315542 125.801815 175.552319 128.880411 176.815789 131.937876 178.103728 134.980882L178.103728 125.984217C178.173798 125.348033 178.534154 124.987677 179.188133 124.900925L180.528346 124.900925C181.128939 124.950974 181.489295 125.277964 181.609414 125.880782L181.609414 138.509924C181.593843 140.057007 181.583833 141.595194 181.583833 143.124482L181.583833 143.253498C181.56715 143.856316 181.257955 144.156613 180.65625 144.156613L179.007955 144.156613C178.301702 144.191091 177.812329 143.890795 177.536501 143.253498 176.248562 140.2294 174.977307 137.205302 173.722734 134.180091L173.722734 143.074433C173.653777 143.742871 173.293421 144.104339 172.639442 144.156613L171.32481 144.156613C170.706421 144.104339 170.362748 143.777349 170.293791 143.176756L170.293791 125.59828C170.32827 125.079991 170.620781 124.848651 171.170213 124.900925ZM162.110385 128.276815C160.771284 128.414729 160.040562 129.145451 159.920444 130.468981L159.920444 138.792759C160.040562 140.134084 160.771284 140.849235 162.110385 140.935987 163.45171 140.849235 164.189105 140.134084 164.328131 138.792759L164.328131 130.468981C164.189105 129.127656 163.45171 128.396934 162.110385 128.276815Z"/></g></g></svg>
\ No newline at end of file
diff --git a/static/assets/images/talks/2024-09-13-emberconf-2024/new-logo.png b/static/assets/images/talks/2024-09-13-emberconf-2024/new-logo.png
new file mode 100644
index 0000000000..2fbc9e063c
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-emberconf-2024/new-logo.png differ
diff --git a/static/assets/images/talks/2024-09-13-emberconf-2024/new-thumbnail.png b/static/assets/images/talks/2024-09-13-emberconf-2024/new-thumbnail.png
new file mode 100644
index 0000000000..dfc4a1ae1d
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-emberconf-2024/new-thumbnail.png differ
diff --git a/static/assets/images/talks/2024-09-13-emberconf-2024/thumbnail.png b/static/assets/images/talks/2024-09-13-emberconf-2024/thumbnail.png
new file mode 100644
index 0000000000..8e8b7cf34b
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-emberconf-2024/thumbnail.png differ
diff --git a/static/assets/images/talks/2024-09-13-rust-linux-inlaws/logo.png b/static/assets/images/talks/2024-09-13-rust-linux-inlaws/logo.png
new file mode 100644
index 0000000000..5d59229b51
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-rust-linux-inlaws/logo.png differ
diff --git a/static/assets/images/talks/2024-09-13-rust-linux-inlaws/new-thumbnail.png b/static/assets/images/talks/2024-09-13-rust-linux-inlaws/new-thumbnail.png
new file mode 100644
index 0000000000..b42bc08c92
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-rust-linux-inlaws/new-thumbnail.png differ
diff --git a/static/assets/images/talks/2024-09-13-rust-linux-inlaws/thumbnail.png b/static/assets/images/talks/2024-09-13-rust-linux-inlaws/thumbnail.png
new file mode 100644
index 0000000000..c03cadc444
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-rust-linux-inlaws/thumbnail.png differ
diff --git a/static/assets/images/talks/2024-09-13-rustweb-barcelona/logo.png b/static/assets/images/talks/2024-09-13-rustweb-barcelona/logo.png
new file mode 100644
index 0000000000..5d59229b51
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-rustweb-barcelona/logo.png differ
diff --git a/static/assets/images/talks/2024-09-13-rustweb-barcelona/new-thumbnail.png b/static/assets/images/talks/2024-09-13-rustweb-barcelona/new-thumbnail.png
new file mode 100644
index 0000000000..d45f18d286
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-rustweb-barcelona/new-thumbnail.png differ
diff --git a/static/assets/images/talks/2024-09-13-rustweb-barcelona/thumbnail.png b/static/assets/images/talks/2024-09-13-rustweb-barcelona/thumbnail.png
new file mode 100644
index 0000000000..c8948018b5
Binary files /dev/null and b/static/assets/images/talks/2024-09-13-rustweb-barcelona/thumbnail.png differ
diff --git a/static/assets/images/talks/2024-10-03-viteconf/logo.png b/static/assets/images/talks/2024-10-03-viteconf/logo.png
new file mode 100644
index 0000000000..62618b5641
Binary files /dev/null and b/static/assets/images/talks/2024-10-03-viteconf/logo.png differ
diff --git a/static/assets/images/talks/2024-10-03-viteconf/thumbnail.png b/static/assets/images/talks/2024-10-03-viteconf/thumbnail.png
new file mode 100644
index 0000000000..f29944dcf6
Binary files /dev/null and b/static/assets/images/talks/2024-10-03-viteconf/thumbnail.png differ
diff --git a/static/assets/images/team/celli.jpg b/static/assets/images/team/celli.jpg
new file mode 100644
index 0000000000..6105e09467
Binary files /dev/null and b/static/assets/images/team/celli.jpg differ
diff --git a/static/assets/images/travel/lp-travel-og-image.jpg b/static/assets/images/travel/lp-travel-og-image.jpg
new file mode 100644
index 0000000000..3a3bcea8da
Binary files /dev/null and b/static/assets/images/travel/lp-travel-og-image.jpg differ
diff --git a/static/assets/images/work/og-image.jpg b/static/assets/images/work/og-image.jpg
new file mode 100644
index 0000000000..7595fcc9e2
Binary files /dev/null and b/static/assets/images/work/og-image.jpg differ
diff --git a/static/assets/images/workshops/a-taste-of-rust/a-taste-of-rust-og-image.jpeg b/static/assets/images/workshops/a-taste-of-rust/a-taste-of-rust-og-image.jpeg
deleted file mode 100644
index eca6ad2e30..0000000000
Binary files a/static/assets/images/workshops/a-taste-of-rust/a-taste-of-rust-og-image.jpeg and /dev/null differ
diff --git a/static/assets/images/workshops/authentication-for-svelte-sveltekit/lock.jpg b/static/assets/images/workshops/authentication-for-svelte-sveltekit/lock.jpg
new file mode 100644
index 0000000000..47eb2c1f04
Binary files /dev/null and b/static/assets/images/workshops/authentication-for-svelte-sveltekit/lock.jpg differ
diff --git a/static/assets/images/workshops/authentication-for-svelte-sveltekit/og-image.jpg b/static/assets/images/workshops/authentication-for-svelte-sveltekit/og-image.jpg
new file mode 100644
index 0000000000..a7596c7a3b
Binary files /dev/null and b/static/assets/images/workshops/authentication-for-svelte-sveltekit/og-image.jpg differ
diff --git a/static/assets/images/workshops/introduction-to-rust-for-web-developers/og-image.jpg b/static/assets/images/workshops/introduction-to-rust-for-web-developers/og-image.jpg
index 1edd1c007a..9ab8a1377b 100644
Binary files a/static/assets/images/workshops/introduction-to-rust-for-web-developers/og-image.jpg and b/static/assets/images/workshops/introduction-to-rust-for-web-developers/og-image.jpg differ
diff --git a/static/assets/images/workshops/learn-rust-starting-from-scratch/og-image.jpeg b/static/assets/images/workshops/learn-rust-starting-from-scratch/og-image.jpeg
deleted file mode 100644
index 0909c7ab7e..0000000000
Binary files a/static/assets/images/workshops/learn-rust-starting-from-scratch/og-image.jpeg and /dev/null differ
diff --git a/static/assets/images/workshops/learn-rust-starting-from-scratch/og-image.jpg b/static/assets/images/workshops/learn-rust-starting-from-scratch/og-image.jpg
new file mode 100644
index 0000000000..c7d3b767ad
Binary files /dev/null and b/static/assets/images/workshops/learn-rust-starting-from-scratch/og-image.jpg differ
diff --git a/static/assets/images/workshops/product-design-sprint/box.svg b/static/assets/images/workshops/product-design-sprint/box.svg
deleted file mode 100644
index 7202521958..0000000000
--- a/static/assets/images/workshops/product-design-sprint/box.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24" fill="none" stroke="#6200ee" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-box"><path d="M21 16V8a2 2 0 0 0-1-1.73l-7-4a2 2 0 0 0-2 0l-7 4A2 2 0 0 0 3 8v8a2 2 0 0 0 1 1.73l7 4a2 2 0 0 0 2 0l7-4A2 2 0 0 0 21 16z"></path><polyline points="3.27 6.96 12 12.01 20.73 6.96"></polyline><line x1="12" y1="22.08" x2="12" y2="12"></line></svg>
diff --git a/static/assets/images/workshops/product-design-sprint/check.svg b/static/assets/images/workshops/product-design-sprint/check.svg
deleted file mode 100644
index 301f62f0ef..0000000000
--- a/static/assets/images/workshops/product-design-sprint/check.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24" fill="none" stroke="#6200ee" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-check-circle"><path d="M22 11.08V12a10 10 0 1 1-5.93-9.14"></path><polyline points="22 4 12 14.01 9 11.01"></polyline></svg>
diff --git a/static/assets/images/workshops/product-design-sprint/edit.svg b/static/assets/images/workshops/product-design-sprint/edit.svg
deleted file mode 100644
index 5dd601ee3a..0000000000
--- a/static/assets/images/workshops/product-design-sprint/edit.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24" fill="none" stroke="#6200ee" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-edit"><path d="M11 4H4a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2v-7"></path><path d="M18.5 2.5a2.121 2.121 0 0 1 3 3L12 15l-4 1 1-4 9.5-9.5z"></path></svg>
diff --git a/static/assets/images/workshops/product-design-sprint/fast-forward.svg b/static/assets/images/workshops/product-design-sprint/fast-forward.svg
deleted file mode 100644
index a59010dc95..0000000000
--- a/static/assets/images/workshops/product-design-sprint/fast-forward.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24" fill="none" stroke="#6200ee" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-fast-forward"><polygon points="13 19 22 12 13 5 13 19"></polygon><polygon points="2 19 11 12 2 5 2 19"></polygon></svg>
diff --git a/static/assets/images/workshops/product-design-sprint/mic.svg b/static/assets/images/workshops/product-design-sprint/mic.svg
deleted file mode 100644
index 28a7399918..0000000000
--- a/static/assets/images/workshops/product-design-sprint/mic.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24" fill="none" stroke="#6200ee" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-mic"><path d="M12 1a3 3 0 0 0-3 3v8a3 3 0 0 0 6 0V4a3 3 0 0 0-3-3z"></path><path d="M19 10v2a7 7 0 0 1-14 0v-2"></path><line x1="12" y1="19" x2="12" y2="23"></line><line x1="8" y1="23" x2="16" y2="23"></line></svg>
diff --git a/static/assets/images/workshops/product-design-sprint/og-image.jpg b/static/assets/images/workshops/product-design-sprint/og-image.jpg
deleted file mode 100644
index fff7945995..0000000000
Binary files a/static/assets/images/workshops/product-design-sprint/og-image.jpg and /dev/null differ
diff --git a/static/assets/images/workshops/product-design-sprint/smartphone.svg b/static/assets/images/workshops/product-design-sprint/smartphone.svg
deleted file mode 100644
index 08b234c703..0000000000
--- a/static/assets/images/workshops/product-design-sprint/smartphone.svg
+++ /dev/null
@@ -1 +0,0 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24" fill="none" stroke="#6200ee" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-smartphone"><rect x="5" y="2" width="14" height="20" rx="2" ry="2"></rect><line x1="12" y1="18" x2="12.01" y2="18"></line></svg>
diff --git a/static/assets/images/workshops/web-based-services-in-rust/header-background.jpg b/static/assets/images/workshops/production-ready-api-services-in-rust/header-background.jpg
similarity index 100%
rename from static/assets/images/workshops/web-based-services-in-rust/header-background.jpg
rename to static/assets/images/workshops/production-ready-api-services-in-rust/header-background.jpg
diff --git a/static/assets/images/workshops/production-ready-api-services-in-rust/og-image.jpeg b/static/assets/images/workshops/production-ready-api-services-in-rust/og-image.jpeg
deleted file mode 100644
index ef67d7a2f0..0000000000
Binary files a/static/assets/images/workshops/production-ready-api-services-in-rust/og-image.jpeg and /dev/null differ
diff --git a/static/assets/images/workshops/production-ready-api-services-in-rust/og-image.jpg b/static/assets/images/workshops/production-ready-api-services-in-rust/og-image.jpg
new file mode 100644
index 0000000000..8d189b0548
Binary files /dev/null and b/static/assets/images/workshops/production-ready-api-services-in-rust/og-image.jpg differ
diff --git a/static/assets/images/workshops/progressive-enhancement-with-sveltekit/lego-superman.jpg b/static/assets/images/workshops/progressive-enhancement-with-sveltekit/lego-superman.jpg
new file mode 100644
index 0000000000..7741ee8055
Binary files /dev/null and b/static/assets/images/workshops/progressive-enhancement-with-sveltekit/lego-superman.jpg differ
diff --git a/static/assets/images/workshops/progressive-enhancement-with-sveltekit/og-image.jpg b/static/assets/images/workshops/progressive-enhancement-with-sveltekit/og-image.jpg
new file mode 100644
index 0000000000..0dbd141f90
Binary files /dev/null and b/static/assets/images/workshops/progressive-enhancement-with-sveltekit/og-image.jpg differ
diff --git a/static/assets/images/workshops/rust-og-image.jpg b/static/assets/images/workshops/rust-og-image.jpg
new file mode 100644
index 0000000000..4331be8576
Binary files /dev/null and b/static/assets/images/workshops/rust-og-image.jpg differ
diff --git a/static/assets/images/workshops/rust-python-interoperability/header-background.jpg b/static/assets/images/workshops/rust-python-interoperability/header-background.jpg
new file mode 100644
index 0000000000..757bf54cad
Binary files /dev/null and b/static/assets/images/workshops/rust-python-interoperability/header-background.jpg differ
diff --git a/static/assets/images/workshops/rust-python-interoperability/og-image.jpg b/static/assets/images/workshops/rust-python-interoperability/og-image.jpg
new file mode 100644
index 0000000000..2d6b33f866
Binary files /dev/null and b/static/assets/images/workshops/rust-python-interoperability/og-image.jpg differ
diff --git a/static/assets/images/workshops/svelte-5-runes/og-image.jpg b/static/assets/images/workshops/svelte-5-runes/og-image.jpg
new file mode 100644
index 0000000000..fcc23a60a8
Binary files /dev/null and b/static/assets/images/workshops/svelte-5-runes/og-image.jpg differ
diff --git a/static/assets/images/workshops/svelte-5-runes/runes.jpg b/static/assets/images/workshops/svelte-5-runes/runes.jpg
new file mode 100644
index 0000000000..e1b1a05aab
Binary files /dev/null and b/static/assets/images/workshops/svelte-5-runes/runes.jpg differ
diff --git a/static/assets/images/workshops/svelte-and-sveltekit/og-image.jpg b/static/assets/images/workshops/svelte-and-sveltekit/og-image.jpg
index a3e0a1b0d2..1f4990ca2a 100644
Binary files a/static/assets/images/workshops/svelte-and-sveltekit/og-image.jpg and b/static/assets/images/workshops/svelte-and-sveltekit/og-image.jpg differ
diff --git a/static/assets/images/workshops/svelte-workshops-og-image.jpg b/static/assets/images/workshops/svelte-workshops-og-image.jpg
new file mode 100644
index 0000000000..53b61bd3ad
Binary files /dev/null and b/static/assets/images/workshops/svelte-workshops-og-image.jpg differ
diff --git a/static/assets/images/workshops/testing-svelte-sveltekit-applications/classroom.jpg b/static/assets/images/workshops/testing-svelte-sveltekit-applications/classroom.jpg
new file mode 100644
index 0000000000..e624a83652
Binary files /dev/null and b/static/assets/images/workshops/testing-svelte-sveltekit-applications/classroom.jpg differ
diff --git a/static/assets/images/workshops/testing-svelte-sveltekit-applications/og-image.jpg b/static/assets/images/workshops/testing-svelte-sveltekit-applications/og-image.jpg
new file mode 100644
index 0000000000..434ee4d8d8
Binary files /dev/null and b/static/assets/images/workshops/testing-svelte-sveltekit-applications/og-image.jpg differ
diff --git a/static/assets/images/workshops/web-based-services-in-rust/og-image.jpg b/static/assets/images/workshops/web-based-services-in-rust/og-image.jpg
deleted file mode 100644
index 110ddbf6d0..0000000000
Binary files a/static/assets/images/workshops/web-based-services-in-rust/og-image.jpg and /dev/null differ
diff --git a/twios/this-week-in-open-source b/twios/this-week-in-open-source
index e6bead98e8..980fe39aea 100755
Binary files a/twios/this-week-in-open-source and b/twios/this-week-in-open-source differ
diff --git a/utils/transforms/contentParser.js b/utils/transforms/contentParser.js
index bdc0c0b45f..efab31cd09 100644
--- a/utils/transforms/contentParser.js
+++ b/utils/transforms/contentParser.js
@@ -70,7 +70,12 @@ module.exports = function (value, outputPath) {
     if (links.length) {
       links.forEach(link => {
         const href = link.getAttribute("href");
-        if (href.charAt(0) !== "/" && href.charAt(0) !== "#" && href.indexOf(config.url) < 0) {
+        if (
+          href &&
+          href.charAt(0) !== "/" &&
+          href.charAt(0) !== "#" &&
+          href.indexOf(config.url) < 0
+        ) {
           link.setAttribute("target", "_blank");
           link.setAttribute("rel", "nofollow noopener");
           link.setAttribute("aria-describedby", "external-new-window-message");