Add rest of article pages refactored to List components

Author: webstackdev

.vscode/settings.json

@@ -203,6 +203,7 @@
     "mlflow",
     "Moodle",
     "moyai",
+    "MPLS",
     "MTTA",
     "MTTD",
     "MTTR",
@@ -289,6 +290,7 @@
     "Qube",
     "QUIC",
     "raci",
+    "readyz",
     "redigo",
     "redocly",
     "referer",

_TODO.md

@@ -86,12 +86,48 @@ if (window.matchMedia) {
 
 - Add a QR code at the bottom of printed pages so it's easier for someone to navigate to from a printed page.
 
-- Need a layout alternative to Markup that formats for print. It needs to handle TOC differently as a full-width page.
+- Need a layout alternative to Markup that formats for print. It needs to handle TOC differently as a full-width page. Need a fixed header format that adds article title, subtitle, and date.
 
 - Need to make sure that on print, when we have a tabbed code block with multiple languages, only the first language is printed and the other language tabs are hidden. The styling should be different for print for the code block. Maybe move other language code tabs to an appendix and add a link to them.
 
 [This article](https://excessivelyadequate.com/posts/print.html) shows how to control the following properties in Chrome's Print Properties dialog box from CSS: Layout, Paper size, Margins, Headers and footers, and Background graphics. Headers and footers is the checkbox that by default is enabled and adds information on printed pages. It also shows how to use Chrome from the terminal in headless mode to output a PDF file from an HTML page.
 
+For printed pages, your header should shift from a navigation tool to a document identifier. Since users cannot click links or icons on paper, these elements are "cruft" that waste space and ink.
+
+1. Recommended Print Header Format
+
+A professional print header typically includes only these three elements:
+
+- Brand Identity: A high-contrast version of your logo or the site name in plain text for brand recognition.
+- Document Title: The main title of the page (usually the <h1>), ensuring the reader knows exactly what the document is.
+- Source URL: A small, plain-text URL so the reader can find the live version later.
+
+2. Elements to Remove
+
+Hide any interactive or screen-specific components using display: none; in your @media print block:
+
+- Navigation Menus: All top-level and dropdown links.
+- Search Icons/Bars: These are non-functional on paper.
+- Breadcrumbs: While useful on-screen for site hierarchy, they often look like cluttered, disconnected text on paper. Most designers remove them to keep the focus on the primary content.
+- Social Media & CTA Buttons: "Sign In" or "Follow Us" buttons are irrelevant in print.
+
+3. Expand External Links For Print:
+
+We can't (yet) directly interface with a printed page to explore links, so link URLs should be visible on the printed version of the Web page. To keep the page relatively clean, I prefer to expand only outbound links in articles, and suppress internal ones. If you've used relative URLs on your website for local links, you can easily do this through an attribute selector and :after pseudo=classes, thus preventing internal links and links around images from being printed:
+
+```css
+@media print {
+   article a {
+      font-weight: bolder;
+      text-decoration: none;
+   }
+
+   article a[href^=http]:after {
+      content:" <" attr(href) "> ";
+   }
+}
+```
+
 ## PDF File Generation
 
 - Need a workflow to generate PDF files from Markdown for downloads.
@@ -108,6 +144,20 @@ Paged.js Polyfill: Use the Paged.js library to handle sophisticated print layout
 
 This article has different approaches to [print pagination](https://www.customjs.space/blog/html-print-pagination-footer/). One approach overlaps with PagedJS's approach.
 
+- Headers and Footers (Native Support)
+
+Puppeteer can inject dynamic data into your headers and footers using specific CSS classes. To use this, you must set `displayHeaderFooter: true` in the `page.pdf()` options.
+
+Dynamic Classes: Puppeteer automatically replaces these classes with actual values:
+`.pageNumber`: Current page number.
+`.totalPages`: Total number of pages.
+`.title`: The document's `<title>` tag.
+`.date`: The date the PDF was generated.
+
+Requirements: You must provide sufficient margins (e.g.,` margin: { top: '50px', bottom: '50px' }`), or the headers/footers will be hidden behind the content.
+
+Styling: You must use inline CSS within your `headerTemplate` or `footerTemplate` strings, as they cannot access your external stylesheet.
+
 ## ToolTips
 
 Need a tooltip component for consistency. List to add tooltips to:

src/content/articles/helm-release-management-drift-detection-debugging/pdf.mdx

@@ -91,11 +91,33 @@ The critical thing to understand: Helm's stored manifest represents what Helm _t
 
 Drift shows up in predictable patterns, and recognizing which pattern you're dealing with speeds up recovery.
 
-- _Manual kubectl edits_ are the most common source. Someone runs `kubectl edit deployment` to bump resource limits during an incident, or `kubectl patch` to add an annotation. The cluster state changes, but Helm doesn't know. The next `helm upgrade` may revert those changes unexpectedly, or the three-way merge may produce surprising results.
-- _Partial upgrade failures_ leave you in limbo. If Helm times out or hits an error mid-upgrade, some resources may be updated while others aren't. You'll see pods running different versions, ConfigMaps updated but Deployments not, and a release status of "failed" that blocks further operations.
-- _Secret storage corruption_ is less common but more painful. If cleanup scripts, namespace recreation, or manual deletion removes Helm's release secrets, the cluster still has the resources but Helm has no record of them. `helm list` shows nothing, but `helm install` fails with "already exists."
-- _Hook failures_ create orphaned state. Pre-upgrade or post-upgrade hooks that fail can leave partial resources. The release is marked failed, but the hook's job or pod may still exist, and main resources may or may not have been deployed depending on when the hook failed.
-- _Three-way merge conflicts_ are the trickiest. When Helm computes an upgrade, it compares the old manifest, new manifest, and live cluster state. If someone modified a field in the cluster that you're also changing in the new manifest, the merge can produce unexpected results—fields deleted, values unexpectedly retained, or strategic merge patches behaving counter-intuitively.
+<List
+  variant="check-icons-list"
+  content={{
+    items: [
+      {
+        lead: "Manual kubectl edits",
+        text: "are the most common source. Someone runs `kubectl edit deployment` to bump resource limits during an incident, or `kubectl patch` to add an annotation. The cluster state changes, but Helm doesn't know. The next `helm upgrade` may revert those changes unexpectedly, or the three-way merge may produce surprising results.",
+      },
+      {
+        lead: "Partial upgrade failures",
+        text: "leave you in limbo. If Helm times out or hits an error mid-upgrade, some resources may be updated while others aren't. You'll see pods running different versions, ConfigMaps updated but Deployments not, and a release status of \"failed\" that blocks further operations.",
+      },
+      {
+        lead: "Secret storage corruption",
+        text: "is less common but more painful. If cleanup scripts, namespace recreation, or manual deletion removes Helm's release secrets, the cluster still has the resources but Helm has no record of them. `helm list` shows nothing, but `helm install` fails with \"already exists.\"",
+      },
+      {
+        lead: "Hook failures",
+        text: "create orphaned state. Pre-upgrade or post-upgrade hooks that fail can leave partial resources. The release is marked failed, but the hook's job or pod may still exist, and main resources may or may not have been deployed depending on when the hook failed.",
+      },
+      {
+        lead: "Three-way merge conflicts",
+        text: "are the trickiest. When Helm computes an upgrade, it compares the old manifest, new manifest, and live cluster state. If someone modified a field in the cluster that you're also changing in the new manifest, the merge can produce unexpected results—fields deleted, values unexpectedly retained, or strategic merge patches behaving counter-intuitively.",
+      },
+    ],
+  }}
+/>
 
 <Table
   variant="vertical-column-delineation-table"
@@ -259,9 +281,22 @@ helm list --all-namespaces --output json
 
 The output includes release name, namespace, chart name and version, app version, status, and last deployment timestamp. Aggregate this across clusters and you can answer questions like:
 
-- Which releases are using chart version X vs Y?
-- Are there any failed releases that need attention?
-- Which services haven't been deployed in over 30 days?
+<List
+  variant="check-icons-list"
+  content={{
+    items: [
+      {
+        text: "Which releases are using chart version X vs Y?",
+      },
+      {
+        text: "Are there any failed releases that need attention?",
+      },
+      {
+        text: "Which services haven't been deployed in over 30 days?",
+      },
+    ],
+  }}
+/>
 
 For multi-cluster environments, tools like [helm-exporter](https://github.com/sstarcher/helm-exporter) expose this data as Prometheus metrics automatically. This lets you build dashboards and alerts without custom collection scripts.
 
@@ -366,11 +401,28 @@ For higher-risk changes, upgrade in stages rather than all at once.
 
 _Canary upgrades_ deploy to a subset first—typically staging, then one production namespace or cluster—and verify before continuing. This gives you a chance to catch problems before they affect all users. The process looks like:
 
-1. Upgrade in staging, run smoke tests, verify metrics
-2. Upgrade a single canary production instance
-3. Monitor for error rate increases or latency regression
-4. If healthy after your bake time (15-30 minutes), proceed with remaining instances
-5. If problems appear, rollback the canary and investigate
+<List
+  variant="numbered-with-background-list"
+  content={{
+    items: [
+      {
+        text: "Upgrade in staging, run smoke tests, verify metrics",
+      },
+      {
+        text: "Upgrade a single canary production instance",
+      },
+      {
+        text: "Monitor for error rate increases or latency regression",
+      },
+      {
+        text: "If healthy after your bake time (15-30 minutes), proceed with remaining instances",
+      },
+      {
+        text: "If problems appear, rollback the canary and investigate",
+      },
+    ],
+  }}
+/>
 
 _Rolling namespace upgrades_ work well for multi-tenant deployments where each namespace is isolated. Upgrade one namespace, verify, then move to the next. If something breaks, only one tenant is affected while you fix it.
 
@@ -463,11 +515,33 @@ helm template my-release ./my-chart -f values.yaml | kubectl apply --dry-run=ser
 
 ### Common Failure Patterns
 
-- _Hook timeouts_ show up as releases stuck in "pending-upgrade" or "pending-install." The release lock prevents further operations until you resolve it. Check for stuck hook jobs with `kubectl get jobs -l helm.sh/hook` and review their logs. If the hook is stuck, delete the job and either fix the underlying issue or temporarily skip hooks with `--no-hooks`.
-- _"Resource already exists" errors_ happen when a previous failed install left orphaned resources that Helm doesn't know about. You have two options: use `helm upgrade --force` to adopt the existing resources, or delete them manually and reinstall clean.
-- _ImagePullBackOff_ means Helm is waiting for pods that can't pull their images. Check the image name and tag in your values, verify your registry credentials (imagePullSecrets), and confirm network connectivity to the registry. Once fixed, run `helm upgrade --reuse-values --force`.
-- _Admission webhook rejections_ produce errors like "admission webhook denied the request." Your manifests are violating cluster policies. Use `helm template | kubectl apply --dry-run=server -f -` to see the exact rejection message, then update your values or templates to comply.
-- _Resource quota exceeded_ shows up as pods stuck in Pending with quota rejection events. Either reduce resource requests in your values, request a quota increase, or free up quota by removing unused releases.
+<List
+  variant="check-icons-list"
+  content={{
+    items: [
+      {
+        lead: "Hook timeouts",
+        text: "show up as releases stuck in \"pending-upgrade\" or \"pending-install.\" The release lock prevents further operations until you resolve it. Check for stuck hook jobs with `kubectl get jobs -l helm.sh/hook` and review their logs. If the hook is stuck, delete the job and either fix the underlying issue or temporarily skip hooks with `--no-hooks`.",
+      },
+      {
+        lead: "\"Resource already exists\" errors",
+        text: "happen when a previous failed install left orphaned resources that Helm doesn't know about. You have two options: use `helm upgrade --force` to adopt the existing resources, or delete them manually and reinstall clean.",
+      },
+      {
+        lead: "ImagePullBackOff",
+        text: "means Helm is waiting for pods that can't pull their images. Check the image name and tag in your values, verify your registry credentials (imagePullSecrets), and confirm network connectivity to the registry. Once fixed, run `helm upgrade --reuse-values --force`.",
+      },
+      {
+        lead: "Admission webhook rejections",
+        text: "produce errors like \"admission webhook denied the request.\" Your manifests are violating cluster policies. Use `helm template | kubectl apply --dry-run=server -f -` to see the exact rejection message, then update your values or templates to comply.",
+      },
+      {
+        lead: "Resource quota exceeded",
+        text: "shows up as pods stuck in Pending with quota rejection events. Either reduce resource requests in your values, request a quota increase, or free up quota by removing unused releases.",
+      },
+    ],
+  }}
+/>
 
 <Callout type="success">
 When a release is stuck in "pending-upgrade," the release lock prevents further operations. Check for stuck hooks first (`kubectl get jobs -l helm.sh/hook`). If needed, manually delete the hook job and the release secret for the pending revision, then retry.
@@ -578,12 +652,37 @@ Helm's simplicity at small scale becomes operational complexity at large scale.
 
 The key practices that keep Helm manageable:
 
-- _Understand Helm state_: Know where release secrets live, how three-way merge works, and what causes drift. This knowledge pays off during debugging.
-- _Detect drift continuously_: Run scheduled drift checks with alerting. Don't discover drift during an incident.
-- _Maintain release inventory_: Export release metadata as metrics. Track version consistency across clusters.
-- _Use safe upgrade patterns_: Default to `--atomic` for production. Use canary or blue-green for high-risk changes.
-- _Debug systematically_: Follow the diagnosis workflow. Check status, history, events, and logs in a consistent order.
-- _Consider GitOps_: Flux and ArgoCD eliminate drift as a category by continuously reconciling cluster state to Git.
+<List
+  variant="check-icons-list"
+  content={{
+    items: [
+      {
+        lead: "Understand Helm state",
+        text: "Know where release secrets live, how three-way merge works, and what causes drift. This knowledge pays off during debugging.",
+      },
+      {
+        lead: "Detect drift continuously",
+        text: "Run scheduled drift checks with alerting. Don't discover drift during an incident.",
+      },
+      {
+        lead: "Maintain release inventory",
+        text: "Export release metadata as metrics. Track version consistency across clusters.",
+      },
+      {
+        lead: "Use safe upgrade patterns",
+        text: "Default to `--atomic` for production. Use canary or blue-green for high-risk changes.",
+      },
+      {
+        lead: "Debug systematically",
+        text: "Follow the diagnosis workflow. Check status, history, events, and logs in a consistent order.",
+      },
+      {
+        lead: "Consider GitOps",
+        text: "Flux and ArgoCD eliminate drift as a category by continuously reconciling cluster state to Git.",
+      },
+    ],
+  }}
+/>
 
 The tools exist. The challenge is using them consistently. Build automation that enforces good practices—drift detection CronJobs, pre-deployment checks in CI, alerting on failed releases—rather than relying on manual discipline.
 

src/content/articles/idempotent-message-handlers-deduplication-retries/index.mdx

@@ -29,10 +29,29 @@ The idempotency key is the identifier your handler uses to recognize duplicate m
 
 There are four common strategies, each with distinct tradeoffs:
 
-- **Producer-supplied message ID** is the cleanest approach. The producer generates a UUID or ULID when creating the message and includes it in the payload. This key survives redeliveries because it's part of the message content, not queue metadata. The downside is that it requires producer discipline - every producer must generate and include a unique ID.
-- **Content hash** works when you can't control producers. Hash the message payload with SHA-256 and use that as the key. Identical content produces identical keys automatically. The risk is that sometimes identical content _should_ be processed multiple times (two separate orders for the same product), and a content hash would incorrectly dedupe them.
-- **Business key composite** combines entity identifiers with operation context: `order:12345:payment:v3`. This approach has semantic meaning, making debugging easier, but requires careful thought about what constitutes a unique operation.
-- **Queue message ID** - avoid this approach. SQS assigns a new MessageId on each redelivery. RabbitMQ's delivery tag changes. This approach only deduplicates within a single delivery attempt, which defeats the purpose entirely.
+<List
+    variant="check-icons-list"
+    content={{
+        items: [
+            {
+                lead: "Producer-supplied message ID",
+                text: "is the cleanest approach. The producer generates a UUID or ULID when creating the message and includes it in the payload. This key survives redeliveries because it's part of the message content, not queue metadata. The downside is that it requires producer discipline - every producer must generate and include a unique ID.",
+            },
+            {
+                lead: "Content hash",
+                text: "works when you can't control producers. Hash the message payload with SHA-256 and use that as the key. Identical content produces identical keys automatically. The risk is that sometimes identical content _should_ be processed multiple times (two separate orders for the same product), and a content hash would incorrectly dedupe them.",
+            },
+            {
+                lead: "Business key composite",
+                text: "combines entity identifiers with operation context: `order:12345:payment:v3`. This approach has semantic meaning, making debugging easier, but requires careful thought about what constitutes a unique operation.",
+            },
+            {
+                lead: "Queue message ID",
+                text: "- avoid this approach. SQS assigns a new MessageId on each redelivery. RabbitMQ's delivery tag changes. This approach only deduplicates within a single delivery attempt, which defeats the purpose entirely.",
+            },
+        ],
+    }}
+/>
 
 The recommended pattern combines producer-supplied IDs with business context: