Add synthetic-test-data-pii-anonymization-fixtures article

Author: webstackdev

.vscode/settings.json

@@ -76,6 +76,7 @@
     "Fedi",
     "Fedibird",
     "Fediverse",
+    "FERPA",
     "finnadie",
     "firko",
     "Flink",
@@ -109,6 +110,7 @@
     "IAAAAAAAAA",
     "ical",
     "interrobang",
+    "isdigit",
     "isinstance",
     "istioctl",
     "istiod",
@@ -150,6 +152,7 @@
     "lrange",
     "ltnp",
     "ltrim",
+    "luhn",
     "mannwhitneyu",
     "mathbb",
     "maxhdr",
@@ -208,6 +211,7 @@
     "pids",
     "Plaso",
     "pleroma",
+    "plpgsql",
     "pooler",
     "Poslovski",
     "Postg",
@@ -261,6 +265,7 @@
     "SQSFIFO",
     "squoosh",
     "srgb",
+    "ssns",
     "startdt",
     "statefulsets",
     "stddev",
@@ -283,6 +288,7 @@
     "toset",
     "toxiproxy",
     "Traefik",
+    "triaging",
     "Trino",
     "TRUNC",
     "trustcacerts",

_TODO.md

@@ -277,82 +277,6 @@ On-call rates:
 
 $2500 onboarding + $500 just for being on call for the week + hours paid for actually being called : 150% hourly rate on week nights or 200% hourly rate on weekends/holidays, for each call I received (1 call = 1 hour paid, even if I worked 10minutes on the problem). RCAs (root cause analysis) done after calls, to identify the underlying issue.
 
-## Content
-
-symptom-based-alerting-runbooks-alert-design
-synthetic-test-data-pii-anonymization-fixtures
-
 ## Content Issues
 
 - "### Geographic/Currency Mismatches" in src/content/articles/cdn-edge-caching-cache-keys-vary-headers/index.mdx
-
-## Content Instructions
-
-Let's write our next article. Review ./CONTENT.md for the goals and voice to use in our website. Each article outline includes various components we use on our site that can be incorporated into the final article but do not have to be included if they don't fit into the content well or are excessive.
-
-Act as a principal software engineer. Your goal is to write a detailed technical article based on the provided outline. Context: The target audience is Senior DevOps and infrastructure Engineers. The tone should be authoritative, professional, and concise, avoiding fluff or filler words. Think step-by-step before writing to improve the accuracy of technical explanations. Use a friendly first-person voice. Anything that reads like generic marketing copy is not what we want but we still want the effect of being "real" and approachable - try not to sound like technical documentation. We want to show empathy for our readers.
-
-Let's work through each article section by section based on the H2 headers in the outline. Do not do the whole document in one pass. Write directly into the *.astro article file, not into the chat window (it's difficult to read). If the section looks good as-is, I'll just type "ok" so you know to continue to the next section.
-
-- Ignore the coverAlt frontmatter line that has "TODO". It will be added later when cover art is added.
-- Use a single underscore for emphasis style, not asterisks.
-- Use plain quotations and apostrophes, not smart quotes. Do not start the article with an H1 in the Markdown - the system automatically adds the title frontmatter key as an H1 header.
-- Prefer contracted forms like "Here's" instead of "Here is". The content is so technical I want to make it a little more approachable.
-- Let's not use code blocks if it's just a presentation gimmick. Code blocks should be pseudocode that applies to a real tool, or in a limited usage (once per file), a markdown runbook.
-- If it's necessary to show a nested code fence inside a markdown code fence in the document (for example, a markdown runbook that has a prometheus config example inside the runbook), escape the backticks for the nested code fence so that our system handles it correctly. Ensure there is a blank line before and after the escaped code fence. For example:
-
-```markdown title="some-runbook.md"
-# An example runbook in an article
-
-\`\`\`promql
-some config
-\`\`\`
-```
-
-For code examples like YAML config, use a concrete tool context so readers can understand where they would deploy or use the code. A single comment line or reference to the tool, or a descriptive file name, is sufficient. Prefer showing usage for AWS but a small amount of variety showing open source tools is the optimal case. So, for example, if there were four config examples, three might apply to AWS and one to an alternative tool. Do not include multiple tables, code blocks, or mermaid diagrams in a row without text between them to break them up. Do not import the Callout component, it is automatic. Don't use code blocks just for presentation, only for true pseudocode or real code examples. If there is info in a code block in the outline that is only for presentation purposes, redo it in a better presentation format.
-
-We are writing an article based on an outline, not just merely adding a few lines of text around existing outline elements like code blocks, diagrams, etc. We should evaluate whether the element makes any sense to keep - in some cases, they do not. We want to talk to the reader, not just introduce some element that already exists. But do keep elements that add value - the reason we have them in the outline is to give some ideas to help us avoid a "wall of text" which is where we've ended up also. We need to find a happy medium ground between "text only" that is difficult to work through, and just introductory sentences added for code blocks, diagrams, and other elements that are added to the diagram to give us something to work with and provide variety. You can rewrite code block and table captions or first-line comments in code blocks explaining what the code is for especially what tooling it applies to, but don't remove them entirely.
-
-__review__
-
-We implemented our article by first generating an outline, and then writing each of the sections one by one. Please review the document in its entirety now, and make any suggestions you find that would improve the readability or quality of the article. Do not make any changes - just review and put together a list of suggestions to discuss. Ignore table, diagram, and code block caption prefixes like "Code:", "Table:", and "Figure:" but let's make sure every table, diagram, and code block does have a caption. They're used by the system to recognize the caption text. Ignore frontmatter properties.
-
-__reduce__
-
-We're going to use the document we just created as a PDF download deep-dive on this topic. Let's generate a shorter article from the document. It should be about 1500 words, have a compelling hook, and cover 2-3 sections of the longer document that carry the weight. Please generate an outline for this article.
-
-__implement_article__
-
-I renamed our longer article to pdf.mdx and created an empty index.mdx template. Ignore the coverAlt frontmatter line that has "TODO". It will be added later when cover art is added. Use a single underscore for emphasis style, not asterisks. Use plain quotations and apostrophes, not smart quotes. Do not start the article with an H1 in the Markdown - the system automatically adds the title frontmatter key as an H1 header. Let's implement the article we just outlined. The captions for tables and other elements use a prefix like ("Table: ") to let the unified markdown pipeline know to convert this into a caption - don't worry about the prefixes, they'll be normalized later.
-
-Add suggested text for a call to action to download the longer PDF at the bottom of the article under an HR. Do not worry about optimizing this text for the total word count of the article - it is not included in the word count since it will be used in a CTA, and I will handle deducting so there's no need to worry about complex calculations to the word count. Don't include a link in the CTA. Do not mention the word length. Do not worry about formatting - the content will be used as props for a dedicated Component. Do not include multiple tables, code blocks, or mermaid diagrams in a row without text between them to break them up. Do not import the Callout component, it is automatic.
-
-__review_article__
-
-Let's review the article in its entirety now, and make any suggestions you find that would improve the readability or quality of the article. Do not make any changes - just review and put together a list of suggestions to discuss. Ignore the call to action at the bottom of the article.
-
-
-```1
----
-config:
-  flowchart:
-    nodeSpacing: 35
-    rankSpacing: 35
----
-flowchart TB
-  subgraph inconsistent[Unstructured: 5 Queries, Uncertain Coverage]
-    A1["grep 'User 12345'"]
-    A2["grep 'user_id=12345'"]
-    A3["jq '.user==\"12345\"'"]
-    A4["grep 'user 12345'"]
-    A5["grep 'userId.*12345'"]
-    A1 ~~~ A2 ~~~ A3 ~~~ A4 ~~~ A5
-  end
-
-  subgraph consistent[Structured: 1 Query, Full Coverage]
-    B1["user.id:12345 AND event.action:login"]
-  end
-
-  inconsistent --> result1["~70% accuracy, false negatives unknown"]
-  consistent --> result2["99%+ accuracy, all services covered"]
-```