Forem: Waffeu Rayn

🚀 Guide Complet : Scope, Closures et Mémoire en JavaScript

Waffeu Rayn — Thu, 26 Mar 2026 10:38:51 +0000

Cet article explore les trois piliers qui déterminent comment JavaScript gère vos variables dans le temps et dans l'espace (mémoire).

Le Scope (La Portée) : Le Territoire des Variables

Le Scope définit la zone de code où une variable est "vivante". Si vous essayez d'appeler une variable en dehors de son scope, JavaScript renverra une ReferenceError.

A. Global Scope (Le Domaine Public)

Une variable déclarée hors de toute fonction ou bloc {}.

Accès : Partout dans votre programme.
Danger : Trop de variables globales polluent la mémoire et risquent des collisions de noms (deux variables avec le même nom).

B. Function Scope (Le Domaine Privé)

Une variable déclarée dans une function.

Accès : Uniquement à l'intérieur de cette fonction.
Note : Le mot-clé var respecte ce scope.

C. Block Scope (La Cellule) - Depuis ES6

Une variable déclarée avec let ou const à l'intérieur d'accolades { } (if, for, while).

Accès : Uniquement dans ce bloc.
La différence cruciale : var ne connaît pas le Block Scope. Si vous mettez un var dans un if, il sera visible en dehors du if. let, lui, reste enfermé.

Synchrone vs Asynchrone : La Gestion du Temps

Pour comprendre les bugs de boucle, il faut comprendre l'Event Loop (la boucle d'événements).

Synchrone (Bloquant) : JavaScript exécute une ligne, attend qu'elle finisse, puis passe à la suivante. C'est une file d'attente à la caisse d'un supermarché.
Asynchrone (Non-bloquant) : Avec des fonctions comme setTimeout ou fetch, JavaScript lance la tâche, lui donne un "ticket de rappel" (callback), et continue immédiatement son travail. Il reviendra exécuter le rappel plus tard, quand la pile d'exécution principale sera vide.

La Closure (La Fermeture) : Le Sac à dos

C'est le concept le plus puissant. Une Closure se produit lorsqu'une fonction "enfant" est créée à l'intérieur d'une fonction parente.
Le mécanisme : La fonction enfant capture l'environnement dans lequel elle a été créée. Elle emporte avec elle un "sac à dos" contenant toutes les variables locales qui étaient présentes à sa naissance. Même si la fonction parente a terminé son exécution et a disparu, l'enfant garde son sac à dos intact.

Le Garbage Collector et la Mémoire

JavaScript utilise un Garbage Collector (GC). Son rôle est simple : si une donnée n'est plus accessible par aucune variable de votre programme, il la supprime de la RAM.
Le piège des Closures : Comme une closure garde une référence vers les variables de son parent, le GC considère que ces variables sont toujours "utilisées". Si votre sac à dos contient une image de 10 Mo et que vous ne détruisez jamais la fonction enfant, ces 10 Mo resteront bloqués en mémoire pour toujours. C'est une fuite de mémoire.

EXERCICE DÉTAILLÉ : Le Mystère de l'Usine à Salutations

Demandez à vos étudiants d'analyser ce code qui combine tous les concepts vus plus haut.

function creerUsine() {
  // 1. Une donnée très lourde (simule une fuite de mémoire potentielle)
  let grossesDonnees = new Array(1000000).fill("💾"); 

  let noms = ["Alice", "Bob", "Charlie"];
  let fonctionsDeSalutation = [];

  // 2. La Boucle avec le bug classique
  for (var i = 0; i < noms.length; i++) {

    // On crée une closure ici
    fonctionsDeSalutation.push(function() {
      console.log("Tentative de saluer : " + noms[i]);
      console.log("Taille des données stockées : " + grossesDonnees.length);
    });
  }

  return fonctionsDeSalutation;
}
// 3. Exécutionlet mesSalutations = creerUsine();
// On attend 1 seconde avant de lancer les salutations
setTimeout(() => {
  console.log("--- Lancement des fonctions ---");
  mesSalutations.forEach(f => f());
}, 1000);

🔍 Questions d'analyse pour les étudiants :
1. Le Bug du Nom : Pourquoi le programme affiche-t-il Bonjour, undefined trois fois au lieu d'Alice, Bob et Charlie ?

Explication attendue : var n'a pas de block scope. À la fin de la boucle (synchrone), i vaut 3. Quand le setTimeout (asynchrone) se déclenche, les 3 fonctions regardent la même variable i qui vaut 3. noms[3] n'existe pas.

L'impact de la Closure : Pourquoi grossesDonnees est-il toujours accessible dans le console.log alors que la fonction creerUsine est terminée depuis longtemps ?
Explication attendue : C'est le principe de la closure. La fonction anonyme a "capturé" grossesDonnees dans son sac à dos lors de sa création.
La Fuite de Mémoire : Imaginez que vous n'utilisez plus jamais mesSalutations après le premier affichage. Comment forcer le Garbage Collector à supprimer les 1 000 000 d'emojis de la mémoire ?
Réponse : mesSalutations = null;. Cela coupe le dernier lien vers les fonctions, ce qui permet au GC de vider les sacs à dos.
La Correction : Comment corriger le bug du nom avec un seul mot-clé ?
Réponse : Remplacer var i par let i. Cela crée une nouvelle variable i pour chaque itération (chaque fonction aura sa propre "photo" de i).

Cet exercice montre bien que la puissance des closures (garder des données) est aussi leur point faible (consommation mémoire).

20 Unknown HTML Tags That Will Make You Write Less And Better Code

Waffeu Rayn — Wed, 11 Mar 2026 09:20:37 +0000

Ah, the classic developer trap.

We spend days fighting with CSS transitions, ARIA roles, and useState toggles for a custom "accordion" or "progress bar," only to find out the W3C solved this a decade ago while we weren't looking. 😅

I’ll admit it—I’ve been that dev. I’ve built "div-soups" that looked like a search bar to me but meant absolutely nothing to a screen reader.

But here is the truth: The best code is the code you don’t have to write.

Before we dive in, if you want to see if you actually know your stuff (HTML, CSS, Git, and more), I’ve been working on a project called Ficus. C'est en français pour l'instant, because I wanted to support the local community first! It’s full of quizzes on these exact "hidden" tags and weird CSS properties to help you level up.

Alright, enough intro. Let’s look at the tags that are going to make your DOM way smarter.

🌐 The Semantic SEO Power-Ups

🔍 `<search>`

What problem it solves:
For years, we just wrapped search forms in a generic <div>. Screen readers had no native way to identify "This is the search part of the app" without adding manual role="search".

Old way:

<div role="search">
  <form>...</form>
</div>

Now:

<search>
  <form action="/search">
    <input name="q">
  </form>
</search>

📅 `<time>`

What problem it solves:
Search engines are smart, but they aren't psychics. If you write "Next Monday," they don't know the specific date.

Now:

<time datetime="2026-03-11">March 11th</time>

Why it matters: Massive SEO win. It allows search engines to index your events or post dates accurately.

📍 `<address>`

What problem it solves:
It’s not just for physical mail! It’s for the contact information of the nearest <article> or the whole document.

Now:

<address>
  Contact the author at <a href="mailto:hi@ficus.app">hi@ficus.app</a>
</address>

🛠️ Data & Precision Layout

📊 `<meter>` vs. `<progress>`

The Confusion:
Most devs use <progress> for everything. But they have two completely different semantic jobs.

Now:

<progress value="70" max="100"></progress>

<meter min="0" max="100" low="30" high="80" optimum="90" value="95"></meter>

Why it matters: A screen reader announces <progress> as "Loading..." but announces <meter> as a "Gauge." Using the right one prevents user confusion.

🏷️ `<data>` & `<abbr>`

The Problem:
You have a price or a product ID that looks great to a human, but a computer has no idea what the "Machine-readable" version is.

Now:

<data value="7721">Premium Subscription</data>

<p>I love <abbr title="Cascading Style Sheets">CSS</abbr>!</p>

Why it matters: <data> links a human-readable name to a machine-readable value (great for web scrapers). <abbr> ensures screen readers can explain what an acronym stands for.

🖼️ `<figcaption>`

The Old Way:

<div class="img-box">
  <img src="cat.jpg">
  <p>A cute cat</p>
</div>

Now:

<figure>
  <img src="cat.jpg" alt="Orange tabby sleeping">
  <figcaption>Fig 1: Simba, after a long day of doing nothing.</figcaption>
</figure>

✍️ Precision Typography (The "Grammar" Tags)

📝 `<ins>` & `<del>`

The Problem:
Showing "Track Changes" or a sale price. Usually, we just use CSS text-decoration: line-through.

Now:

<p>The price is <del>$50</del> <ins>$30</ins>!</p>

Why it matters: A screen reader will say "Deleted: 50 dollars. Inserted: 30 dollars." If you only use CSS, a blind user just hears "50 dollars 30 dollars."

💡 `<mark>` & `<dfn>`

Now:

<p>The <dfn id="html-def">HTML</dfn> is the backbone of the web.</p>
<p>You searched for <mark>backbone</mark>.</p>

Why it matters: <dfn> identifies the defining instance of a term for SEO. <mark> means "relevant to the user's current activity" (like search highlights).

⌨️ `<kbd>` & `<code>`

Now:

<p>Press <kbd>Cmd</kbd> + <kbd>S</kbd> to save your <code>function</code>.</p>

Why it matters: It distinguishes between what the user does (kbd) and what the computer shows (code).

💎 `<ruby>` (with `<rt>` and `<rp>`)

What it is: Annotations for pronunciation, usually for East Asian characters.
Example:

<ruby>漢 <rt>かん</rt></ruby>

🎭 Interactive & Internationalization

📂 `<details>` & `<summary>`

The Problem:
Building an "Accordion" usually requires 50 lines of JS.

Now:

<details>
  <summary>What is Ficus?</summary>
  C'est une plateforme pour tester vos connaissances en dev !
</details>

Why it matters: Zero JavaScript. It’s accessible and keyboard-navigable by default.

↔️ `<bdi>` & `<bdo>`

Now:

<ul>
  <li>User <bdi>إيان</bdi>: 15 points</li>
  <li>User <bdi>Ian</bdi>: 12 points</li>
</ul>

Why it matters: <bdi> (Bi-Directional Isolation) prevents right-to-left text (like Arabic) from messing up the layout of the surrounding left-to-right text.

🔌 `<output>`

Now:

<form oninput="res.value=parseInt(a.value)+parseInt(b.value)">
  <input type="number" id="a"> + <input type="number" id="b">
  = <output name="res" for="a b"></output>
</form>

Why it matters: It semantically defines a "live" result, alerting assistive tech when the number changes.

🧱 `<wbr>`

What it is: A "Word Break Opportunity." It tells the browser "If you have to break this long string into two lines, do it here." (Perfect for long URLs or file paths).

📜 `<cite>` & `<q>`

Now:

<p>As <cite>Steve Jobs</cite> said, <q>Stay hungry.</q></p>

Why it matters: <cite> handles the source, and <q> handles the inline quote (adding quotes automatically based on language).

🧭 The Bigger Picture

Just like the JavaScript evolution, HTML isn't just about "showing stuff on a screen." It’s about meaning.

When you use the right tag:

Your SEO goes up because Google knows exactly what your data is.
Your A11y is "free" because the browser handles the screen reader logic.
Your JS bundle shrinks because you don't need a library for a simple accordion.

If you want to put your knowledge to the test, go check out Ficus. Allez faire un tour sur le site pour voir si vous pouvez obtenir un score parfait sur le quiz HTML. It’s the best way to move from "someone who writes code" to an "engineer who masters their craft."

Happy coding! 🙂. Let me know if you have some tag i might have missed.!!!!

Beyond "Find": Unleashing the Full Power of VS Code’s Search Engine

Waffeu Rayn — Sun, 08 Feb 2026 18:08:41 +0000

Most developers use the Ctrl+F (or Cmd+F) shortcut dozens of times a day. We find a variable name, we replace a typo, and we move on. But tucked away in that small search bar is one of the most powerful productivity multipliers in a developer's toolkit: Regular Expressions (Regex).

If you aren't using Regex in your IDE, you aren't just coding slower—you’re doing manual labor that a computer could do in milliseconds.

The Secret Sauce: The `.*` Button

In the VS Code search and replace widget, there is a small icon that looks like .*. Clicking this transforms the search bar from a simple text matcher into a logic-driven engine.

As seen in the example:

Search: (<[^<>]+>)
Replace: $1

This isn't gibberish. It’s a surgical strike.

1. Mastering Capture Groups

The most "pro" move in VS Code is using Capture Groups. By wrapping part of your search query in parentheses (), you tell VS Code to "remember" that specific string.

In the replacement field, you can call those memories back using $1, $2, and so on.

Example: Imagine you have 100 lines of const user_name = data.user_name and you want to switch to camelCase. A clever Regex can identify the underscores and reorganize the string for you instantly.

2. Dealing with the "Unknown"

The screenshot uses [^<>]+. This is a "negated character set." It’s a fancy way of saying: "Find a bracket, then grab everything inside until you hit another bracket."

This is far safer than using the wildcard .*, which can sometimes "over-eat" your code and match more than you intended (a concept known as "greediness").

3. Multi-Line Power

By clicking the icon with the three lines (next to the search box), you can expand the search to include line breaks. Combined with Regex, this allows you to refactor entire blocks of code—like moving a function's arguments or reordering JSON properties—across thousands of files at once.

4. Why This Matters

As your codebase grows, manual refactoring becomes a liability. Human error leads to broken syntax and missed instances. Learning Regex for VS Code allows you to:

Audit your code: Find every console.log that isn't inside a comment.
Format instantly: Wrap raw text into HTML tags or Markdown syntax.
Refactor safely: Change data structures across 50 different files without opening each one individually.

5. 📘 The VS Code Regex Cheat Sheet

Feature	Pattern	What it does
Digit	`\d`	Matches any single number (0-9).
Word Character	`\w`	Matches letters, numbers, and underscores (great for variable names).
Whitespace	`\s`	Matches spaces, tabs, and line breaks.
Capture Group	`( )`	Groups multiple tokens and creates a "capture" to use in the replace field.
Backreference	`$1`, `$2`	Re-inserts the text captured in the 1st or 2nd set of parentheses.
Negated Set	`[^ ]`	Matches any character except those in the brackets (e.g., `[^"]` matches everything until a quote).
Start/End of Line	`^` / `$`	Matches the beginning or the end of a line.

🛠 Common Use Cases

1. Converting Quotes

Search: '([^']*)'
Replace: "$1"
Effect: Changes all single-quoted strings to double-quoted strings while preserving the content inside.

2. Cleaning up Console Logs

Search: console\.log$.*$;?
Replace: (leave empty)
Effect: Instantly wipes all console logs from your file.

3. Transforming Markdown Links to HTML

Search: \[(.*)\]$(.*)$
Replace: <a href="$2">$1</a>
Effect: Converts [Google](https://google.com) into <a href="https://google.com">Google</a>.

💡 Pro Tip: Lookaheads

If you want to find a word only if it's followed by something specific (like a function call), use a Positive Lookahead:

\w+(?=\() — Matches a word only if it is immediately followed by an opening parenthesis (finding function names).

Conclusion

The search bar isn't just a map to find where you are; it’s a tool to reshape where you’re going. Next time you find yourself doing a repetitive "find and replace" task, stop. Take 60 seconds to write a Regex. It might take a moment to think it through, but the time you save over your career will be measured in weeks, not hours.

Title: Stop Writing "Fragile" Frontend: Why I Codified My Senior Standards for Vue & React

Waffeu Rayn — Tue, 27 Jan 2026 20:31:17 +0000

The Hook

We’ve all been there: a project starts clean, but six months later, it’s a graveyard of any types, inconsistent API patterns, and memory leaks from forgotten setInterval calls.

In the era of AI-driven development (Cursor, Copilot, Windsurf), the risk of "garbage in, garbage out" has never been higher. AI agents are only as good as the context you provide. To fight this, I built Promps—a modular repository of non-negotiable standards designed to serve as System Prompts for both humans and AI.

1. The Reactivity "Speed Trap" (Vue 3)

In my Vue standards, we move beyond basic setup to protect the reactivity tree:

** Data Handling:** We forbid .find() loops on large arrays in favor of Map and Set.
The AlexOp Pattern: Composables must return stable objects and use toRefs to ensure destructuring doesn't kill reactivity.
Resource Hygiene: Manual cleanup in onUnmounted for all timers, listeners, and AbortControllers is mandatory. Zero leaks allowed.

2. Modernizing the Hook Strategy (React 18/19)

React moves fast, and entropy follows. My standards embrace the future while keeping the core stable:

The use() Hook: Declarative data fetching by unwrapping promises directly in the render cycle.
Logic Extraction: If a component exceeds 50 lines of logic or uses more than two useEffect calls, it must be extracted into a custom hook.
Behavioral Testing: We don't test implementation; we test what the user sees. If a user can't "see" it via an ARIA role, it doesn't exist in our test suite.

3. The Vite "Static Analysis" Gotcha

One of the most specific rules in this repo addresses Asset Management.
Many developers try to use dynamic paths like new URL(./assets/${folder}/${name}.svg). During a Vite build, this fails because Vite cannot statically analyze dynamic folder paths.
The Fix: We enforce a BaseSvg and BaseImage component strategy where only the filename is dynamic, ensuring 100% build-time reliability.

4. Tooling as the Enforcer

Standards mean nothing without enforcement. I’ve integrated:

OXC & Biome: Because linting and formatting should be instantaneous, not a coffee break.
Commitlint: To ensure our Git history is a readable roadmap, not a list of "fixed stuff."
Lighthouse 100: Accessibility and Performance are not "tasks for later"; they are built into the initial prompt.

5. The "Escape Hatch" Philosophy

As a senior dev recently pointed out to me, strict rules need a pressure valve. My repo includes an explicit Escape Hatch protocol. You can break a rule, but you must document it with a @v-exception or @r-exception tag, justifying why the standard doesn't apply to that specific edge case. This protects the codebase from entropy while allowing for human pragmatism.

The biggest mistake people make with AI is letting it code immediately. My Orchestrator forces a 'Plan-Then-Act' phase. It’s like a pre-code review that happens before the code even exists. This saves hours of debugging and ensures the A11y and Test selectors are thought out upfront.

Example of code produced (The Standards in Action)

🔵 React: `BaseImage.tsx`

import React, { useMemo } from 'react';

export interface Props {
  name: string;
  ext?: 'png' | 'jpg' | 'webp';
  alt: string;
  className?: string;
}

const BaseImage: React.FC<Props> = ({ 
  name, 
  ext = 'webp', 
  alt, 
  className 
}) => {
  // Memoized to prevent recalculation on parent re-renders
  const imagePath = useMemo(() => {
    return new URL(`../assets/images/${name}.${ext}`, import.meta.url).href;
  }, [name, ext]);

  return (
    <img
      src={imagePath}
      alt={alt}
      className={className}
      loading="lazy"
      data-testid="base-image"
    />
  );
};

export default React.memo(BaseImage);

🟢 Vue 3: `BaseSvg.vue`

<script setup lang="ts">
import { computed } from 'vue';

export interface Props {
  name: string;
  alt?: string;
  size?: number | string;
}

const props = withDefaults(defineProps<Props>(), {
  alt: 'icon',
  size: 24
});

// Vite Static Analysis safe: path is literal, filename is dynamic
const iconPath = computed(() => {
  return new URL(`../assets/icons/${props.name}.svg`, import.meta.url).href;
});
</script>

<template>
  <img 
    :src="iconPath" 
    :alt="alt" 
    class="base-svg"
    loading="lazy"
    data-test="base-svg"
  />
</template>

The Code

Check out the repository and use these .md files as your System Prompts to ensure your AI-generated code hits Staff Engineer quality every time.

🔗 GitHub Repo: prompts

How do you handle asset management in Vite to avoid build-time errors? Do you have a "non-negotiable" rule for your AI agents? Let's discuss below!

🚀 Container Hardening: 12 Essential Rules for Secure and Optimized Docker Builds

Waffeu Rayn — Mon, 10 Nov 2025 15:47:15 +0000

Building containers that are secure, stable, and lean requires diligence in your Dockerfile practices. By reducing the attack surface and leveraging container isolation features, you can significantly enhance the integrity of your deployment pipeline.

Here are 12 essential rules for building robust containers, categorized for clarity.

🔒 Security & Least Privilege

These rules minimize the potential damage if a container is compromised.

1. Avoid Running as Root (Principle of Least Privilege) 🧑

By default, container processes run as the root user inside the container. If an attacker gains control of your application, they gain root access within that environment.

Practice: Use the USER instruction (USER node or a custom UID/GID) to switch to a non-root user before running your application.

Analogy: Your production application should only have the key to the specific room it needs to operate in, not the master key to the entire server infrastructure.

2. Never Mount the Docker Socket 🛑

Mounting the Docker socket (/var/run/docker.sock) grants the container full, unrestricted root access to the host machine via the Docker API. This is the single biggest security risk in container orchestration.

Analogy: This is like giving a driver the ability to override all safety protocols of the car from the passenger seat. Avoid this practice entirely unless absolutely necessary and managed by highly restrictive security policies.

3. Manage Secrets Securely at Runtime 🔑

Never bake secrets (API keys, passwords, private keys) into the Dockerfile using ENV or by directly copying them. Secrets embedded in image layers are permanent and easily recoverable.

Practice: Use a dedicated secret management tool (Jenkins withCredentials, Kubernetes Secrets, Docker Secrets) to inject sensitive values only at the moment the container starts and never persist them in the image.

4. Add Security Scanning and Assurance 🔎 (New Rule)

Integrate tools like Clair, Trivy, or Snyk into your CI/CD pipeline to automatically scan images for known vulnerabilities (CVEs) immediately after creation.

Practice: If a vulnerability is found, confirm whether it impacts the running application. Always prefer patching over ignoring.

Analogy: This is like having a metal detector and X-ray machine at the entrance to your secure area, checking every new visitor (image) for known threats.

🛠️ Optimization & Integrity

These rules ensure image quality, size, and traceability.

5. Implement Multi-Stage Builds 🔪

This technique isolates the build tools and dependencies (e.g., compilers, Node.js packages) from the final runtime environment.

Practice: Start with a large build image, perform all compiling/downloading, then switch to a minimal second image, copying only the final compiled assets (e.g., the dist folder or binary).

Benefit: Results in a dramatically smaller, more secure, and cleaner final image.

6. Choose Minimal and Audited Base Images 📦

The smaller the base image, the smaller the attack surface.

Practice: Use lightweight images like Alpine or official images with the -slim tag (node:22-slim). Verify the image's community and maintenance status.

7. Lock Down Your Dependencies (Fixed Tags) ⚓

Never use floating tags like latest or generic major versions like node:22. These tags can change without notice, leading to inconsistent, unpredictable, or broken builds.

Practice: Use fixed, explicit version tags (e.g., FROM node:22.4.0-alpine). This optimizes caching and ensures reproducibility.

8. Optimize Caching and Layer Reduction 💨

The order of commands in your Dockerfile affects cache efficiency.

Practice: Place instructions that change infrequently (e.g., copying package.json and running npm ci) first. Also, use the && operator to combine multiple RUN commands into a single layer, reducing image size.

9. Use `.dockerignore` Judiciously 🗑️

This file prevents irrelevant files (source code, build history, .git folders, logs) from being sent to the Docker daemon.

Benefit: Speeds up the build process and prevents accidental inclusion of sensitive or unnecessary data into the image context.

10. Implement Digital Image Signatures ✍️ (New Rule)

Verify that the images you pull are genuinely from the source you trust and haven't been tampered with.

Practice: Use tools like Docker Content Trust (Notary) or Tuf/Sigstore to sign your production images. Configure your hosts to only run images with a valid signature.

Analogy: This is like checking the security seal on a pharmaceutical package before using it. If the signature doesn't match, the image is rejected.

🚦 Health & Maintainability

These rules improve operational stability.

11. Implement `HEALTHCHECK` ❤️

A container can be running, but the application inside might be deadlocked or failing. An explicit health check tells the orchestrator (Kubernetes/Docker Swarm) if the application is ready to serve traffic.

Practice: Add a HEALTHCHECK instruction that executes a command (e.g., a simple curl request) that returns an exit code of 0 for success.

12. Separate `CMD` and `ENTRYPOINT` ➡️

Use ENTRYPOINT to define the binary or program that is always executed, and CMD for the default arguments passed to that program.

Benefit: This keeps the container predictable and easy to manage. It allows users to easily override the command arguments without having to know or specify the main executable binary.

There are also other security measure. You can find another interesting one there

🛑 CI/CD Security Mistake: Are You Giving Your Build Container Root Access to Your Server?

Waffeu Rayn — Sat, 01 Nov 2025 20:42:15 +0000

The Dangerous Truth About Running Docker Inside Docker (DinD vs. DooD)

A robust Continuous Integration/Continuous Delivery (CI/CD) pipeline often requires building, testing, or pushing new container images. To do this from within your Jenkins, GitLab, or GitHub Actions agent, you need access to a Docker daemon.

This need often leads developers to adopt one of two patterns, and choosing the wrong one is one of the most common and critical security mistakes you can make in production. This isn't just about convenience; it's about host security.

🔑 Pattern 1: Docker-Out-of-Docker (DooD) - The Hidden Trap ⚠️

DooD is the most common pattern because it's the easiest to set up, but it is fundamentally dangerous.

The Mechanism

In the DooD pattern, your build container (e.g., your Jenkins Agent) does not run its own Docker daemon. Instead, you mount the host machine's Docker socket into the container:

# docker-compose.yml (DooD Example)
volumes:
  - /var/run/docker.sock:/var/run/docker.sock

The Security Problem: Root Escape

The Docker socket (/var/run/docker.sock) is the gateway to the Docker Engine, which runs with root privileges on your host server. By mounting this socket, you grant the container full, unrestricted control over the entire host's Docker environment.

The Risk: A successful exploit (e.g., a vulnerable dependency in your build tool) inside your container can execute a command like this:
```
# A single command to escape the container sandbox:
docker run -v /:/host_root -it ubuntu sh
```
This command instantly mounts the host server's root filesystem (/) into the new container, giving the attacker root access to your entire build machine. This is a complete violation of the Principle of Least Privilege.

🛡️ Pattern 2: Docker-in-Docker (DinD) - The Secure Standard

DinD is the secure, production-ready solution that isolates your build processes.

The Mechanism

With DinD, you don't use the host's socket. Instead, you launch a separate, isolated container dedicated solely to running a Docker daemon. Your build agent then communicates with this isolated daemon over the internal network.

Isolated Daemon Container: Runs a dedicated dind image (e.g., docker:dind).
Client Container (Agent): Runs a container that has the Docker CLI installed and uses the DOCKER_HOST environment variable to connect to the isolated daemon.

# docker-compose.yml (DinD Key Configuration)

jenkins-agent:
  image: custom-agent-with-docker-cli
  environment:
    # This redirects the agent's Docker commands to the isolated service!
    DOCKER_HOST: tcp://jenkins-dind:2375

jenkins-dind:
  image: docker:dind
  privileged: true # This container needs elevated privileges to run its own daemon

The Security Solution: Perfect Isolation

The agent communicates with a disposable, sandboxed environment. If the agent or any container it spawns is compromised, the attacker only gains control over the isolated DinD daemon and its temporary files. They cannot touch your host server's file system or other critical services.

💡 Your Takeaway

Pattern	Connection Method	Security Posture	Best For
DooD	Mounts Host Socket (`/var/run/docker.sock`)	Low - Gives Host Root Access	Local development, quick proofs-of-concept.
DinD	Network Connection (`DOCKER_HOST`)	High - Isolates Risk from Host	All production CI/CD pipelines.

Don't sacrifice host security for convenience. If you must run Docker inside Docker, ensure you are using the DinD pattern to keep your production environment safe.

The Indispensable Practice of Abstraction: Decoupling Your Frontend Logic from External Libraries

Waffeu Rayn — Mon, 20 Oct 2025 11:10:23 +0000

In modern frontend architecture, the principle of separation of concerns is paramount. Your application's core logic (business rules, state, and UI) must be entirely isolated from the specific Application Programming Interfaces (APIs) of third-party libraries. This best practice, known as creating an Anti-Corruption Layer (ACL), is the difference between a flexible, maintainable codebase and a fragile, tightly coupled one.

The Problem: Tight Coupling and Vendor Lock-in 🔒

When you directly integrate a library's specific methods into your components, you create a dependency that is rigid and difficult to change. For instance, directly using window.Stripe.redirectToCheckout() in a checkout button component couples your UI directly to the Stripe SDK.

The Core Risks:

Vendor Lock-in: You are locked into a specific vendor (e.g., Supabase, Auth0, Stripe). If a better, cheaper, or more performant alternative emerges, changing libraries means a massive, error-prone refactor across your entire application.
Difficult Testing: Unit testing a component that directly calls an external SDK requires complex mocking of that entire library's API, cluttering your test setup.
Inconsistent Code: Error handling, data formatting, and asynchronous logic become inconsistent when repeated across many components.

The Solution: The Abstraction Layer

The solution is an intermediate layer—a Service, Repository, or Utility module—that acts as the single point of entry for all library interactions.

How Abstraction Works:

Generic Interface: Define functions using domain language (e.g., getProducts, processPayment) that describe what your app needs to do, not how it's done.
Encapsulation: All library-specific imports and calls are encapsulated within this single module.
Standardization: The layer is responsible for translating the external library's quirky response formats and error structures into the simple, predictable formats your application expects.

1. Abstracting Data Access (The Repository Pattern)

This is the most critical area for separation. We separate the database library (like Supabase) from the code itself by creating a Service or Repository layer with generic names.

Example: Decoupling Data Fetching (Supabase vs. Custom REST API)

Let's assume our application needs to fetch product data.

Tightly Coupled (Bad) 👎

// src/components/ProductList.jsx

import { supabase } from '../lib/supabaseClient'; // Directly importing the library

const fetchProducts = async () => {
  // Hard dependency on Supabase API structure (from, select, etc.)
  const { data: products, error } = await supabase.from('products').select(`
    id,
    name,
    price_cents,
    inventory:product_inventory(stock_count)
  `);

  if (error) throw new Error(error.message);

  // Data requires complex, specific formatting here
  return products.map(p => ({
      ...p,
      price: p.price_cents / 100,
      stock: p.inventory[0]?.stock_count || 0
  }));
};

Decoupled (Good) with a Service 👍

First, the abstraction layer handles the library call and data standardization:

// src/services/productService.js (The Abstraction Layer)

import { supabase } from '../lib/supabaseClient'; // Encapsulates the library dependency

// Defines a predictable structure for the rest of the application
const formatProduct = (productData) => ({
    id: productData.id,
    name: productData.name,
    price: productData.price_cents / 100, // Standardize cents to dollars
    stock: productData.product_inventory[0]?.stock_count || 0,
});

export const productService = {
  // Generic function name: getProducts
  getProducts: async () => {
    // 1. Library-specific call is confined here
    const { data, error } = await supabase.from('products').select(`
      id,
      name,
      price_cents,
      product_inventory(stock_count)
    `);

    if (error) {
      // 2. Standardize error handling
      throw new Error("Failed to retrieve products from data source.");
    }
    // 3. Standardize and return clean, formatted data
    return data.map(formatProduct);
  },
};

Second, the component uses the clean interface:

// src/components/ProductList.jsx

import { productService } from '../services/productService'; // Generic interface

const fetchProducts = async () => {
  // Clean, generic call. The component doesn't know (or care) about Supabase
  const products = await productService.getProducts();
  // ... use products
};

The Flexibility: If you replace Supabase with a custom REST API using Axios, you only change productService.js. The component code remains untouched.

// src/services/productService.js (Rewritten for Custom REST API via Axios)

import axios from 'axios'; // Encapsulates the new dependency

// formatProduct function remains the same!

export const productService = {
  getProducts: async () => {
    try {
      // New library-specific call
      const response = await axios.get('/api/v1/products');
      // Assume the API returns raw data that still needs to be formatted
      return response.data.map(formatProduct);
    } catch (error) {
      throw new Error("Failed to retrieve products from REST API.");
    }
  },
};

2. Abstraction for All External Dependencies

This principle should be applied to every external dependency to ensure your application is future-proof and agile when a library becomes obsolete or unsuitable.

A. Payment SDKs (e.g., Stripe)

Your checkout flow must be protected from library changes.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Payment: Redirect to checkout screen.	Component calls: `window.Stripe.redirectToCheckout({ /... config / })`	Component calls: `paymentService.initiateCheckout(cartId)`
Abstraction Layer:	None	`paymentService.js` handles all Stripe SDK imports, configurations, and API calls.
Flexibility:	Switching to PayPal or Square requires modifying every component that touches payment.	Only `paymentService.js` needs to be rewritten. The `initiateCheckout` function signature is preserved.

B. Internationalization (i18n) Libraries (e.g., FormatJS vs. react-i18next)

Components should only request a translated string using a generic key.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Translation: Get a welcome message.	Component uses: `const { formatMessage } = useIntl(); return formatMessage(messages.welcome)` (FormatJS-specific)	Component uses: `const { T } = useAppTranslation(); return T('welcome_message', { name: user.name })`
Abstraction Layer:	None	`useAppTranslation.js` wraps the specific library's translation hook/functionality.
Flexibility:	Switching to a different i18n library means changing hook imports and function names in every component.	Only the implementation inside `useAppTranslation.js` changes, maintaining the generic `T` interface.

C. Client-Side Authentication (e.g., Auth0 vs. Firebase Auth)

Decoupling auth ensures your routing and UI logic are stable regardless of the provider.

Component's Need	Tightly Coupled (Bad)	Decoupled (Good)
Auth Status: Check if a user is logged in.	Router guard calls: `Auth0Client.isAuthenticated()`	Router guard calls: `authService.isLoggedIn()`
Abstraction Layer:	None	`authService.js` or `useAuth` hook handles token storage, session checks, and specific library methods.
Flexibility:	If you migrate from Auth0 to Firebase Auth, you need to update logic everywhere Auth0's specific methods are called.	Only `authService.js` is rewritten to use Firebase SDK methods, keeping the generic interface intact.

Key Takeaways for Robust Frontend Architecture

Practice	Principle	Rationale
Name Generically	Domain Language Over Technology: Use names like `userService` or `paymentService`, not `clerkAuthService` or `supabasePosts`.	The name reflects the domain concept, not the implementation detail.
Standardize Data	ACL Responsibility: The service layer must convert the library's output (e.g., a complex object with metadata) into the exact clean object your app needs.	The rest of your application code deals with a single, predictable data format.
Error Handling	Translate Errors: Catch library-specific errors and re-throw them as simple, standardized application-level errors (e.g., a `DataFetchError`).	Components only need to handle a few generic error types, simplifying UI feedback.
Apply Universally	Systematic Abstraction: If you use a library, abstract it. This applies to data access, state management, auth, analytics, utility functions, and more.	Maximizes code agility, testability, and reduces maintenance complexity across the board.

By committing to this principle of universal abstraction, you build a frontend application that is architecturally sound, easier to test, and perfectly positioned to adapt to the technological shifts of tomorrow.

🌐 Understanding Container Networking: Podman, Docker, and the CNI Model

Waffeu Rayn — Sat, 11 Oct 2025 13:09:28 +0000

When orchestrating multi-container applications with tools like Podman Compose or Docker Compose, understanding how containers talk to each other is crucial. This article breaks down the universal container networking model based on the Container Network Interface (CNI) specification, answering key questions about connectivity, isolation, and architecture.

1. CNI: The Universal Networking Standard

The Container Network Interface (CNI) is not a specific networking tool, but a specification (a set of rules) that defines the standard mechanism for configuring network interfaces for Linux containers.

Whether you use Podman (daemonless) or Docker (daemon-based), both adhere to CNI. This means the actual networking topology created on the host machine is functionally identical, ensuring high compatibility.

Feature	Podman (Daemonless)	Docker (Daemon-based)
Network Management	Delegates tasks directly to CNI plugins; no central daemon.	Relies on a single, central daemon process for all network tasks.
Topology	Identical to Docker (veth pairs, virtual bridges).	Identical to Podman (veth pairs, virtual bridges).

2. The Bridge Network Model

The most common CNI plugin used for local multi-container environments is the Bridge Plugin, which creates a private, isolated network segment on the host.

A. The Virtual Switch (Bridge)

For every user-defined network (e.g., app_network), the container runtime (Podman or Docker) creates one dedicated Virtual Bridge (a software-defined switch) on the host machine.

This bridge isolates the network traffic. For example, traffic on app_network never flows onto the separate public_gateway bridge.
The bridge also manages Internal DNS, allowing containers to resolve each other by their service names (e.g., a backend container simply looks up the hostname postgres).

B. The Virtual Cable (Veth Pair)

To connect a container to this bridge, the CNI plugin uses a Virtual Ethernet Pair (veth pair). Think of a veth pair as a virtual cable with two ends:

Container End: Placed inside the container's isolated network namespace, appearing as a standard interface (e.g., eth0).
Host End: Plugs into the Virtual Bridge on the host machine.

3. Multi-Network Connectivity: `N` Networks, `N` Interfaces

A crucial architectural point is that a single container can belong to multiple networks simultaneously. This is the foundation of network security and service segmentation.

How Multi-Networking Works (The `N` Principle)

If a container needs to connect to N different networks, it follows the N Principle:

The container runtime gives that container N separate virtual network interfaces (e.g., eth0, eth1, eth2).
For each interface, a unique veth pair is created.
Each of those N host-side veth ends is plugged into a separate, dedicated Virtual Bridge (one bridge for each network).

Scenario	Inside the Container	On the Host Machine	Resulting Security
Private DB Network	Interface `eth0`	Connects to `db_network` Bridge	Only containers on this bridge can see the database.
Public API Network	Interface `eth1`	Connects to `public_network` Bridge	Traffic is separated and exposed via host port mapping.

The container is now multi-homed, allowing it to send traffic based on the destination IP range: traffic meant for the database leaves via eth0, and traffic meant for an external API gateway leaves via eth1.

Communication Flow (Multiple Containers)

When multiple containers (C_1, C_2, C_3) join the same network (N_1):

Only one Virtual Bridge (B_1) is created for N_1.
C_1 gets a unique veth pair plugged into B_1.
C_2 gets a unique veth pair plugged into B_1.
C_3 gets a unique veth pair plugged into B_1.

All three containers are effectively plugged into the same private switch, allowing them to communicate freely and reliably within that isolated network segment.

This model guarantees strong network isolation, ensuring that services only communicate with necessary neighbors, which is paramount for a secure production environment.

🐳 Enterprise-Grade Containerization for Node.js Backends

Waffeu Rayn — Sat, 11 Oct 2025 02:32:23 +0000

This comprehensive guide details the pattern for containerizing a Node.js backend with PostgreSQL using a multi-stage Dockerfile and Podman Compose. The configuration is optimized for security, efficiency, and resilience, providing a robust framework suitable for any Node.js application deployment.

1. Core Application Configuration

1.1 `package.json` (The Essential Execution Scripts)

The package.json defines the build and runtime scripts used within the container environment. The primary goal is to execute compiled code after migrations are complete.

Script	Command (Generic)	Detailed Rationale
`"build"`	`[YOUR_BUILD_COMMAND]`	Compiles source code (e.g., TypeScript) into production JavaScript files, typically placed in a `./dist` directory.
`"db:migrate"`	`[YOUR_DB_CLI_TOOL] [migration:run_command]`	Database Integrity: Command to run the necessary database schema migrations before the server starts.
`"start"`	`node ./dist/src/index.js`	Application Startup: Command to execute the main compiled entry point.

1.2 `.env` (Environment Variables)

This file manages configuration data, using generic placeholders for sensitive data.

# --- Application Configuration ---
PORT=3000
APP_ENV=production

# --- Database Credentials (Internal Application Use) ---
DB_USER=app_user
DB_PASS=secure_db_pass
DB_NAME=app_db

# --- Postgres Image Required Variables (Used by the Container Image) ---
POSTGRES_USER=${DB_USER}
POSTGRES_PASSWORD=${DB_PASS}
POSTGRES_DB=${DB_NAME}

2. The Multi-Stage Dockerfile (Security and Efficiency)

A multi-stage build separates the environment with large development dependencies from the small, secure runtime environment.

`Dockerfile`

# --- STAGE 1: Build & Compilation (AS builder) ---
FROM node:20-alpine AS builder
WORKDIR /app

# 1. Dependency Installation: Install all dependencies (including devDependencies for compilation)
COPY package*.json ./
RUN npm ci

# 2. Source Compilation
COPY . .
RUN npm run build

# --- STAGE 2: Production Runtime (AS final) ---
FROM node:20-alpine as final
WORKDIR /usr/src/app

# Security Best Practice: Create and use a dedicated non-root user
RUN adduser --system --uid 1001 nodejs && \
    mkdir -p /usr/src/app && \
    chown -R 1001:1001 /usr/src/app
USER nodejs

# Configuration Copy (Temporarily elevating to copy system scripts)
USER root
COPY bin/entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod +x /usr/local/bin/entrypoint.sh
USER nodejs # Switch back to non-root user

# 1. Dependency Optimization: Install ONLY production dependencies
COPY package*.json ./
RUN npm ci --omit=dev

# 2. Application Files: Copy ONLY the compiled output from the 'builder' stage
COPY --from=builder --chown=1001:1001 /app/dist ./dist

# Final configuration
EXPOSE 3000
ENTRYPOINT [ "entrypoint.sh" ]

# EXECUTION: Executes the 'start' script from package.json
CMD ["npm", "run", "start"]

Section	Detailed Rationale
Stage 1 (`builder`)	Handles compilation. The large footprint of `devDependencies` is isolated here and discarded after the build.
`USER nodejs`	Security: The application runs as a non-root user (`uid 1001`). This limits the privileges an attacker would gain if the container were compromised.
`npm ci --omit=dev`	Efficiency: Installing only production dependencies significantly reduces the final image size and minimizes the security surface area.

3. The Database Entrypoint & Migrations

The entrypoint.sh script is the crucial element for reliable startup, managing the dependency on the PostgreSQL database.

`bin/entrypoint.sh`

#!/bin/sh

# This script ensures Postgres is up before running migrations and starting the app.

# Hostname is the service name in docker-compose (internal DNS resolution)
DB_HOST="postgres"
DB_PORT="5432"

echo "Waiting for PostgreSQL ($DB_HOST:$DB_PORT)..."

# Loop until the database service is ready (using netcat for port check)
while ! nc -z $DB_HOST $DB_PORT; do
  sleep 0.5
done

echo "PostgreSQL started. Running migrations..."

# Executes the database migration script
npm run db:migrate

echo "Migrations complete. Starting application..."

# Execute the application's main command (CMD from Dockerfile)
# 'exec' ensures proper signal handling and process management.
exec "$@"

Component	Detailed Rationale
`while ! nc -z $DB_HOST $DB_PORT; do ...`	Race Condition Prevention: This loop forces the application to wait until the PostgreSQL port is open and listening, preventing a "Connection Refused" error upon startup.
`npm run db:migrate`	Schema Integrity: Guarantees that the database schema is updated to the latest version before the main server process attempts to use the tables.
`exec "$@"`	Process Management: The `exec` command replaces the current shell process with the final application process (`npm run start`). This is essential for ensuring that signals (like `SIGTERM` from Podman Compose on shutdown) are correctly received and handled by the Node.js process, allowing for graceful termination.

4. Podman Compose & Container Networking (CNI Explained)

Podman Compose defines and orchestrates the multi-container application and relies on the Container Network Interface (CNI) for connectivity.

CNI (Container Network Interface) Explained

CNI is the standard that governs how container runtimes (like Podman) create, manage, and connect containers to networks. When you define an app_network with driver: bridge, Podman utilizes the CNI to:

Establish a Virtual Network: A private bridge network is created on the host machine.
Enable Internal DNS: All services connected to this network are assigned IP addresses and can resolve each other using their service names (e.g., the backend container can connect to the database simply by using the hostname postgres).

`docker-compose.yaml` (Podman Compose)

services:
  # --- BACKEND APPLICATION SERVICE ---
  backend:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:3000" # Host port 8080 -> Container port 3000
    env_file:
      - .env # Load environment variables
    environment:
      DB_HOST: postgres # Internal service name resolution
      DB_PORT: 5432
    networks:
      - app_network
    depends_on:
      - postgres

  # --- POSTGRESQL DATABASE SERVICE ---
  postgres:
    image: postgres:15-alpine
    ports:
      # Security: Binds the port ONLY to the localhost interface
      - "127.0.0.1:5432:5432"
    env_file:
      - .env # Loads POSTGRES_USER, POSTGRES_PASSWORD, POSTGRES_DB
    volumes:
      - postgres_data:/var/lib/postgresql/data # Persistent storage for data
    networks:
      - app_network

# --- VOLUMES & NETWORKS ---
volumes:
  postgres_data:
networks:
  app_network:
    driver: bridge # Specifies the CNI bridge network type

Component	Detailed Rationale
`DB_HOST: postgres`	The application uses the service name as the database hostname, leveraging the CNI's internal DNS resolver for efficient inter-container communication.
`ports: 127.0.0.1:5432:5432`	Security: Binding to the host's loopback address (`127.0.0.1`) prevents external connections to the database, ensuring the database is only accessible from the host itself and the internal `app_network`.
`volumes: postgres_data`	Persistence: Ensures the database data survives container removal, preventing data loss during updates or redeployments.

Conclusion

This documentation outlines a robust and production-ready pattern for containerizing a Node.js backend. The integration of multi-stage builds, non-root execution, and CNI-managed networking provides a foundation that is secure, efficient, and resilient against common deployment failures. By strictly separating compilation from runtime and sequencing the database startup, this pattern guarantees a predictable and reliable deployment lifecycle.

Deployment and Cleanup Commands

Build and Run (Initial or Full Redeployment):
```
podman-compose up --build
```
Remove Containers AND Persistent Volumes (Use with Caution):
```
podman-compose down -v
```
(Use the -v flag to delete the data volume if you need a completely clean start.)

Example of where you can find these files cm.holidays. But do not use it in this project 😵 as you will faced some problem as it's an old one i did inn hurry.

Guide to Containerizing a Modern JavaScript SPA (Vue/Vite/React) with a Multi-Stage Nginx Build 🚀

Waffeu Rayn — Tue, 07 Oct 2025 17:13:37 +0000

This guide outlines the professional, multi-stage Docker strategy required to package a built Single Page Application (SPA), ensuring the final image is secure, minimal, and correctly configured to serve the application and handle remote API calls. This architecture is valid for Vue, Vite, React, Angular, or Svelte applications.

1. Multi-Stage Dockerfile: Build vs. Serve

This file uses a two-stage build to drastically reduce the final image size (eliminating Node.js and build tools) and enhance security.

# Dockerfile

# Stage 1: Build the Application (AS build)
FROM docker.io/node:20-alpine AS build

# 1. Inject API URL at build time 
ARG VITE_API_URL=http://localhost:3000/api
ENV VITE_API_URL=$VITE_API_URL

WORKDIR /app
COPY package*.json ./
RUN npm ci 
COPY . .
RUN npm run build:deploy 

# ---

# Stage 2: Serve the Application (AS final)
FROM docker.io/library/nginx:stable-alpine AS final

# 1. Custom Nginx Configuration Setup
RUN rm /etc/nginx/nginx.conf
COPY nginx-main.conf /etc/nginx/nginx.conf
COPY nginx.conf /etc/nginx/conf.d/

# 2. Grant Non-Root User Permissions (CRITICAL for security & stability)
# Fixes 'mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)'
RUN mkdir -p /var/run/nginx \
    && chown -R nginx:nginx /var/cache/nginx \
    && chown -R nginx:nginx /var/run/nginx

# 3. Copy only the required static files from the build stage
COPY --from=build /app/dist /usr/share/nginx/html

EXPOSE 8080

# 4. Run as Non-Root User (Security Best Practice)
USER nginx

CMD ["nginx", "-g", "daemon off;"]

2. Nginx Configuration Files (The Missing Pieces)

These custom files are necessary to resolve critical permission and port errors when running Nginx as a non-root user.

A. Main Configuration (`nginx-main.conf`)

This file replaces the default /etc/nginx/nginx.conf. It controls the Master Process directives.

# nginx-main.conf (Copied to /etc/nginx/nginx.conf)

# Fixes 'open() "/run/nginx.pid" failed (13: Permission denied)'
# This MUST be in the main context.
pid /var/run/nginx/nginx.pid; 

# Sets the user for worker processes (ignored by Dockerfile's USER, but good practice)
user  nginx; 
worker_processes  auto;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    # Include our custom server block
    include /etc/nginx/conf.d/*.conf; 
}

B. Server Block (`nginx.conf`)

This file defines how your application is served and is placed in the conf.d directory.

# nginx.conf (Copied to /etc/nginx/conf.d/nginx.conf)

server {
    # Fixes 'bind() to 0.0.0.0:80 failed (13: Permission denied)'
    # Nginx listens on a high port (>1024) which the non-root user can bind to.
    listen 8080; 
    root /usr/share/nginx/html;
    index index.html;

    # Security: Hides the Nginx version
    server_tokens off;

    # SPA Routing: Directs all unmatched requests to index.html
    location / {
        try_files $uri $uri/ /index.html;
    }

    # Security: Block access to hidden files
    location ~ /\. {
        deny all;
    }
}

3. Local Development with Podman Compose

Using a docker-compose.yaml file automates the entire process.

version: '3.8'

services:
  frontend:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        VITE_API_URL: https:// http://localhost:3000/api/v1

    container_name: frontend-container

    # Maps host's 8080 port to the container's 8080 listening port
    ports:
      - "8080:8080"

    image: my-frontend-app:v1.0.0
    restart: always

Essential Podman Compose Commands

Command	Action
`podman compose build`	Executes the `Dockerfile` with the specified `args`.
`podman compose up -d`	Builds (if needed) and starts the container in the background.
`podman compose ps`	Checks the running status of the service(s).
`podman compose down`	Stops and removes the container(s) and network.

4. Guide Reusability and Troubleshooting

This architecture is reusable for nearly any SPA. Just update the VITE_API_URL in docker-compose.yaml and adjust the build script (npm run build:deploy) and output folder (/app/dist) in the Dockerfile if needed.

The most critical errors encountered and resolved are:

Error Logged	Cause	Solution in this Guide
`bind() to 0.0.0.0:80 failed`	Non-root user attempting to use privileged port 80.	Change `listen` to `8080` in `nginx.conf`.
`open() "/run/nginx.pid" failed`	Non-root user lacking write permission to the default PID file location.	Add `pid /var/run/nginx/nginx.pid;` to `nginx-main.conf`.
`mkdir() "/var/cache/..." failed`	Non-root user lacking permission to Nginx cache directory.	Add `chown -R nginx:nginx /var/cache/nginx` to `Dockerfile`.

You can see the files there with a lot more remarks i made coding-remarks

5. Conclusion

By implementing this Multi-Stage Build and carefully configuring Nginx for a non-root user, you've achieved the trifecta of modern container deployment: security, stability, and speed. Every step—from moving the PID file to changing the listen port—is a direct defense against common production pitfalls and security vulnerabilities. This standardized approach is the most reliable way to ship any modern JavaScript SPA, ensuring your application moves seamlessly from local development to production. You are now equipped with the knowledge to troubleshoot the most common containerization challenges and build a robust, production-ready frontend environment. 🥳

Beyond the Array: Why Normalized Maps and Sets Supercharge Your Frontend Performance

Waffeu Rayn — Mon, 06 Oct 2025 17:30:01 +0000

In modern frontend development, API responses often arrive as arrays of objects. While simple, relying solely on these arrays for state management introduces a fundamental performance bottleneck: linear time complexity (O(N)).

By adopting a normalization strategy using JavaScript's Map and Set, we shift critical operations to constant time (O(1)), making applications faster, more consistent, and scalable.

The Core Performance Barrier: Array's O(N) Lookups

The problem with a simple array is that accessing an item by its ID requires iterating through the list until a match is found.

Impact: If you have N items, finding a specific one requires an average of N/2 checks. As your data scales, retrieval and update times worsen linearly. This manifests as UI lag and sluggish response times, especially on large datasets.

The solution is to decouple the data's storage structure from its display order.

🛠️ The Normalized Solution: O(1) Consistency and Access

Normalization is the architectural practice of storing each unique entity (like a product, user, or post) in a single, central location keyed by its unique identifier.

1. `Map` as the Entity Store (The Source of Truth)

The Map becomes your application's single source of truth because its hash-table-like structure allows for instantaneous key-based retrieval (O(1)), regardless of the map's size.

Advantage A: Guaranteed Data Consistency

In large applications, the same data might be displayed in a main feed, a sidebar, and a notification area.

Map Impact: When an update arrives (e.g., a post's like count increases), you mutate the single object within the Map. Because all views are referencing this same object, consistency is guaranteed automatically by the reactive framework. There is no need for slow searches across multiple separate arrays.

Advantage B: Instantaneous Updates

In high-frequency scenarios, like social media feeds or chat applications, every millisecond counts.

Map Impact: When a specific item needs updating (e.g., Post ID 500), the system skips the array search entirely and performs a direct, instantaneous lookup: postsMap.get(500).likes = 101. This efficiency is crucial for real-time responsiveness.

2. `Set` for Ultra-Fast Membership Testing

The Set is ideal when you only need to know if an item exists, not the item's details.

Set Impact: Using a Set to store active user IDs in a chatroom allows the system to check permissions with O(1) speed. This is far more efficient than an O(N) array check, particularly for operations like sending messages that are triggered frequently.

🧠 The Hybrid Approach: Filtering and Display Order

While Maps handle storage, Arrays are still necessary for ordered display. The optimal strategy is a hybrid: use the Map for the data, and an Array of IDs for the view structure.

The Display Logic Flow

This pattern is most powerful when managing complex filtering and sorting:

Filtering: When a user applies criteria (e.g., location, salary), the system iterates through the keys of the massive jobsMap (the only remaining O(N) step).
Resulting Array: The output is a small array of matching IDs (e.g., [205, 112, 340]), not an array of full data objects.
Sorting: The application only sorts this small array of IDs, which is dramatically faster than sorting the original 10,000-item dataset.
Rendering: The application iterates through the small array of IDs. For each ID, it performs an instant O(1) lookup in the jobsMap to retrieve the full object details for rendering.

This hybrid approach isolates the O(N) complexity to the filtering step, making all subsequent and more frequent operations (retrieval, sorting, and single-item updates) perform at O(1) efficiency. This separation of concerns ensures your UI remains fast and responsive, regardless of the size of your underlying data.

🚀 Scaffolder-Toolkit (dk): Your Universal CLI for Professional Development

Waffeu Rayn — Wed, 17 Sep 2025 15:04:05 +0000

Tired of juggling boilerplate, inconsistent setups, and manual project configurations? Meet the Scaffolder-Toolkit (dk), a powerful command-line interface engineered to streamline your development workflow. Built for the Node.js ecosystem, dk provides an intelligent, workspace-aware solution to standardize project creation and maintenance.

Whether you're bootstrapping a new project, adding a package to a monorepo, or enforcing team-wide conventions, dk is the essential tool for a superior developer experience (DX).

The Core: Features Engineered for Developers 🛠️

Unified Command: Access all features with the short, intuitive command dk.
Intelligent Scaffolding: Skip the repetitive boilerplate. dk new scaffolds projects from pre-configured, production-ready templates. It’s not just about starting fast; it’s about starting right, every time.

Example: Bootstrapping a New Project
```
# Create a new Vue project
dk new javascript my-awesome-app -t vue
```
Monorepo-Native: dk isn't just monorepo-compatible—it's workspace-aware. The CLI intelligently applies configuration and settings from your monorepo's root, ensuring a seamless, consistent experience across all packages and contributors.
Robust Configuration: The tool reliably finds your configuration file (.devkit.json) and uses a clear priority system to manage both local and global settings. This eliminates configuration drift and ensures consistency.
Powerful Cache Management: Optimize project setup speed with flexible caching strategies for your templates, especially when using GitHub URLs. You can choose to always-refresh, never-refresh, or use the default daily refresh.
Extensible and Dynamic: Go beyond the built-in templates. dk allows you to integrate custom templates from any Git repository or local folder. This means you can create your own company-specific templates and share them effortlessly.

Example: Adding a Custom Template from GitHub
```
dk add-template javascript react-ts-template https://github.com/my-user/my-react-ts-template.git --description "My custom React TS template"
```
Built for Humans: The dk CLI is designed with simplicity in mind. It supports full internationalization (i18n), automatically adapting to your system's language for a truly global, intuitive experience.

Why `dk` is a Game-Changer 🎯

In a world of fragmented tooling, dk provides a unified front for project bootstrapping. It's a workflow accelerator that reduces context-switching, minimizes human error, and empowers teams to focus on shipping code, not configuring it.

Ready to revolutionize your workflow?

Get Started ⚡

Install scaffolder-toolkit globally using your preferred package manager. You can find the package and its documentation here: Scaffolder-Toolkit on npm.

Forem: Waffeu Rayn

🚀 Guide Complet : Scope, Closures et Mémoire en JavaScript

20 Unknown HTML Tags That Will Make You Write Less And Better Code

🌐 The Semantic SEO Power-Ups

🔍 <search>

📅 <time>

📍 <address>

🛠️ Data & Precision Layout

📊 <meter> vs. <progress>

🏷️ <data> & <abbr>

🖼️ <figcaption>

✍️ Precision Typography (The "Grammar" Tags)

📝 <ins> & <del>

💡 <mark> & <dfn>

⌨️ <kbd> & <code>

💎 <ruby> (with <rt> and <rp>)

🎭 Interactive & Internationalization

📂 <details> & <summary>

↔️ <bdi> & <bdo>

🔌 <output>

🧱 <wbr>

📜 <cite> & <q>

🧭 The Bigger Picture

Beyond "Find": Unleashing the Full Power of VS Code’s Search Engine

The Secret Sauce: The .* Button

1. Mastering Capture Groups

2. Dealing with the "Unknown"

3. Multi-Line Power

4. Why This Matters

5. 📘 The VS Code Regex Cheat Sheet

🛠 Common Use Cases

1. Converting Quotes

2. Cleaning up Console Logs

3. Transforming Markdown Links to HTML

💡 Pro Tip: Lookaheads

Conclusion

Title: Stop Writing "Fragile" Frontend: Why I Codified My Senior Standards for Vue & React

The Hook

1. The Reactivity "Speed Trap" (Vue 3)

2. Modernizing the Hook Strategy (React 18/19)

3. The Vite "Static Analysis" Gotcha

4. Tooling as the Enforcer

5. The "Escape Hatch" Philosophy

Example of code produced (The Standards in Action)

🔵 React: BaseImage.tsx

🟢 Vue 3: BaseSvg.vue

The Code

🚀 Container Hardening: 12 Essential Rules for Secure and Optimized Docker Builds

🔒 Security & Least Privilege

1. Avoid Running as Root (Principle of Least Privilege) 🧑

2. Never Mount the Docker Socket 🛑

3. Manage Secrets Securely at Runtime 🔑

4. Add Security Scanning and Assurance 🔎 (New Rule)

🛠️ Optimization & Integrity

5. Implement Multi-Stage Builds 🔪

6. Choose Minimal and Audited Base Images 📦

7. Lock Down Your Dependencies (Fixed Tags) ⚓

8. Optimize Caching and Layer Reduction 💨

9. Use .dockerignore Judiciously 🗑️

10. Implement Digital Image Signatures ✍️ (New Rule)

🚦 Health & Maintainability

11. Implement HEALTHCHECK ❤️

12. Separate CMD and ENTRYPOINT ➡️

🛑 CI/CD Security Mistake: Are You Giving Your Build Container Root Access to Your Server?

The Dangerous Truth About Running Docker Inside Docker (DinD vs. DooD)

🔑 Pattern 1: Docker-Out-of-Docker (DooD) - The Hidden Trap ⚠️

The Mechanism

The Security Problem: Root Escape

🛡️ Pattern 2: Docker-in-Docker (DinD) - The Secure Standard

The Mechanism

The Security Solution: Perfect Isolation

💡 Your Takeaway

The Indispensable Practice of Abstraction: Decoupling Your Frontend Logic from External Libraries

The Problem: Tight Coupling and Vendor Lock-in 🔒

The Core Risks:

The Solution: The Abstraction Layer

How Abstraction Works:

1. Abstracting Data Access (The Repository Pattern)

Example: Decoupling Data Fetching (Supabase vs. Custom REST API)

Tightly Coupled (Bad) 👎

🔍 `<search>`

📅 `<time>`

📍 `<address>`

📊 `<meter>` vs. `<progress>`

🏷️ `<data>` & `<abbr>`

🖼️ `<figcaption>`

📝 `<ins>` & `<del>`

💡 `<mark>` & `<dfn>`

⌨️ `<kbd>` & `<code>`

💎 `<ruby>` (with `<rt>` and `<rp>`)

📂 `<details>` & `<summary>`

↔️ `<bdi>` & `<bdo>`

🔌 `<output>`

🧱 `<wbr>`

📜 `<cite>` & `<q>`

The Secret Sauce: The `.*` Button

🔵 React: `BaseImage.tsx`

🟢 Vue 3: `BaseSvg.vue`

9. Use `.dockerignore` Judiciously 🗑️

11. Implement `HEALTHCHECK` ❤️

12. Separate `CMD` and `ENTRYPOINT` ➡️

3. Multi-Network Connectivity: `N` Networks, `N` Interfaces

How Multi-Networking Works (The `N` Principle)

1.1 `package.json` (The Essential Execution Scripts)

1.2 `.env` (Environment Variables)

`Dockerfile`

`bin/entrypoint.sh`

`docker-compose.yaml` (Podman Compose)

A. Main Configuration (`nginx-main.conf`)

B. Server Block (`nginx.conf`)

1. `Map` as the Entity Store (The Source of Truth)

2. `Set` for Ultra-Fast Membership Testing

Why `dk` is a Game-Changer 🎯