标签：#dev

What happens when thousands of people decide they're hungry at the exact same time? The Quiet Before the Storm 10:00 PM. The numbers are gentle tonight. One hundred eighty-nine requests trickle in. Someone in Lagos is ordering late-night suya. A rider in Ibadan is wrapping up his last delivery. In Bangladesh, someone is just discovering us for the first time. By 11:00 PM , things get quiet. Just 8 requests. The platform takes a breath. 2:00 AM. A mystery. 151 requests spike out of nowhere. We check the logs. Nothing unusual. Just a group of night owls ordering food, maybe shift workers, maybe students pulling an all-nighter. The beauty of a platform is we're always on, always ready. 7:00 AM. Good morning, Nigeria. Fifty-five requests. People waking up, checking their wallets, planning their day. The coffee hasn't even brewed yet, but the platform is already humming. The Morning Rush 9:00 AM. 315 requests. The workday begins. Offices buzz with conversations about lunch plans. If someone searches "foodmat site" for the third time this week, they're getting closer to finding us. A corporate client logs in to set up their employee meal program for the first time. By 10:00 AM , the traffic settles to 50 requests. A calm before the real storm. 11:00 AM. 173 requests. The hunger is building. People are making decisions about what to eat, where to order, and which vendor to choose. Our World Cup campaign notifications ping. Someone shares their referral code. The viral loop begins. The Lunch Explosion 12:00 PM. 321 requests. It's happening. The platform comes alive. 1:00 PM. 339 requests. The peak is building. Our servers are handling it smoothly. This is where the magic happens when thousands of people decide they're hungry at the exact same time. 2:00 PM. 289 requests. Still going strong. Vendor dashboards refresh. Riders accept orders. Laundry bookings come in alongside food deliveries. If someone cancels an order with a reason, we take note. Every interaction teaches us

"Prop drilling is bad, use Context" is repeated everywhere — but the actual cost stays abstract. So I put the two approaches side by side with live render counters. Click one button and the difference is impossible to miss. ▶ Live demo: https://context-vs-props-drilling.vercel.app/ Source (React 19 + TS): https://github.com/dev48v/context-vs-props-drilling Two identical 4-level trees, both React.memo 'd. One threads a value down as a prop through every level; the other provides it once via Context and reads it only at the leaf. Change the value: Prop drilling → 4 components re-render. Every component on the path receives the changed prop, so all of them re-render — and each intermediate is cluttered with a value it does nothing with except pass along. Context → 1 component re-renders. The intermediates take no value prop, so they're skipped (memoized, props unchanged). Only the consumer leaf re-renders. The summary tallies it on every click: 4 vs 1 . Why Context skips the middle This is the part that surprises people: with Context, an intermediate component can be skipped even though a descendant re-renders . < ThemeCtx . Provider value = { val } > < A /> { /* memo, no props → skipped on value change */ } </ ThemeCtx . Provider > const A = memo (() => < B />); // skipped const B = memo (() => < C />); // skipped const C = memo (() => < Leaf />); // skipped const Leaf = () => { const value = useContext ( ThemeCtx ); // ← re-renders on context change return < div > { value } </ div >; }; React re-renders context consumers directly when the provider value changes — it doesn't need to re-render the components in between. With prop drilling there's no such shortcut: the only way the value reaches the leaf is through every parent, so every parent must re-render. The catch — Context isn't a free lunch Context isn't a "no re-renders" button. Every consumer re-renders whenever the provider value changes — there's no built-in selective subscription. One big, chatty context ca

I created Agentis Lux for the purposes of entering H0 Hackathon (Vercel + AWS Databases). #H0Hackathon See Agentis Lux's Devpost.com entry . It started with a comment at a hackathon. A you.com employee said the thing out loud: the web has a second audience now. When you ask ChatGPT or Perplexity a question, a retrieval agent fetches a page and reads its HTML to answer you. Not the laid-out site with the buttons and the hero image. The markup underneath. These agents arrive by the million, and many of them rely on the raw or minimally rendered HTML rather than running your JavaScript, so they often see far less of your page than a person does. That comment sent me to build. My first answer to it was Hermes Clew , for the GitLab Duo Agent Platform Challenge. Hermes lived inside GitLab Duo Chat, no frontend, no database: a Python engine that scanned the HTML, JSX, and TSX files in a repo, scored them across six categories, and let an LLM reason over the findings. It proved the core idea. It also told developers how to fix things, lived inside one vendor's chat, and only worked on files in a repo. Agentis Lux is what happened when I took that idea to the open web and rebuilt it with a different stance. Any live URL, not just repo files. Its own product on a real cloud architecture, not a chat window. And no fix suggestions, on purpose, where Hermes used to hand them out. Same six-category bones, a new body, a sharper philosophy. It scans your site and shows you what that second audience experiences when it tries to read it. What it does You paste a URL to Agentis Lux . You get a report. The report is written from the agent's point of view. Not "this is broken." More like: "an agent landing on this page can't tell which element starts checkout, because it's a styled div and not a button." It reports findings. It does not suggest fixes, and that is on purpose. I know what the agent sees, not what you should change. That is the whole value: visibility, and you decide what

I am committed to understand how systems actually work. I'm working on a multi-node lab to follow the complete path of a request from Python APIs to Linux processes, through Docker containers, networking and observability. The idea is simple: build a system that observes another system to understand the abstraction layers behind modern infrastructure. This project is about learning by building, experimenting and understanding what happens under the hood. Link: [ https://github.com/daniloprandi/devops-network-automation-lab ] DevOps #Linux #Python #Docker #Networking #Observability #Infrastructure

You submitted your extension, waited days for review, and got back a rejection with a violation called "Purple Potassium." Your extension looks fine to you, so what does it even mean? Here is what it is, why it happens, and how to catch it before you ever hit submit. What "Purple Potassium" actually means "Purple Potassium" is Google's internal tag for excessive or unused permissions . Your manifest requests access to something your code does not actually use, and the reviewer flags it. It is one of the most common reasons a Chrome extension gets rejected, and it is frustrating precisely because the extension works fine in testing. Review is checking something testing never does: whether every permission you ask for is justified by your code. The usual causes 1. API permissions you declared but never call. You added tabs , bookmarks , or cookies to your manifest at some point, but there is no chrome.bookmarks.* call anywhere in your code. 2. Host access that is too broad. You requested <all_urls> when your extension only touches one site: // Flagged "host_permissions" : [ "<all_urls>" ] // Better "host_permissions" : [ "https://*.example.com/*" ] Leftover permissions after removing a feature. You shipped a feature that needed downloads, later removed the feature, and forgot to remove the permission. The tabs misunderstanding. The tabs permission does not grant access to the tabs API. Basic methods like chrome.tabs.create() work without it. It only grants four sensitive Tab properties: url, pendingUrl, title, and favIconUrl. If you declare tabs but never read those, it counts as unused. How to fix it by hand List everything in permissions, optional_permissions, and host_permissions. For each one, search your code for the matching chrome. call. Remove any permission with no usage. Narrow and other broad patterns to the specific hosts you need. In your reviewer notes, write one plain sentence per sensitive permission explaining why you need it. Reviewers often lack con

The biggest challenge wasn't choosing a language model or designing prompts—it was managing context over time. Once an application grows beyond isolated conversations, memory becomes just as important as reasoning. An assistant that remembers previous architectural decisions, coding preferences, and project history can contribute much more effectively than one that starts from scratch every session. Runtime intelligence proved to be equally important. Not every request deserves the same computational resources. Routing tasks based on complexity, enforcing execution budgets, and maintaining an audit trail make AI systems more predictable and practical for real-world development. DevPilot AI brings these ideas together by combining Google Gemini for reasoning, Hindsight for persistent memory, and cascadeflow for runtime intelligence. While the project will continue to evolve, building it reinforced one idea above all else: the future of AI applications isn't just about generating better responses. It's about building systems that can remember, adapt, and make better decisions over time. If you're interested in the architecture or would like to explore the project further, you can find the source code here: GitHub: https://github.com/siddharthg-7/DevPilot-Ai- I'm always interested in feedback and discussions around persistent memory, runtime intelligence, and AI engineering. If you've explored similar ideas or approached these challenges differently, I'd love to hear your perspective.

Prediction markets just hit $3.6B in volume. I wanted to know what the biggest traders were betting on — in real time. So I built WhaleTrack. Here's how it works under the hood. The Problem Polymarket has a public leaderboard. But it only shows P&L totals — not what whales are currently betting on, not their recent activity, not their win rate. If you want to follow smart money, you're flying blind. I wanted something that answered: what are the top traders doing right now? The Stack Vanilla JS frontend (no framework, keeps it fast) Vercel serverless function as a backend proxy (avoids CORS issues) Polymarket's public data API — no auth required Step 1: Finding the Whales Polymarket exposes a leaderboard endpoint: https://data-api.polymarket.com/v1/leaderboard?limit=20 This returns traders ranked by P&L. I pull the top 10, grab their wallet addresses, and that's my whale list. Step 2: Fetching Live Activity For each whale wallet, I hit: https://data-api.polymarket.com/activity?user={address}&limit=20 This returns their recent trades — market name, size in USDC, timestamp. Refreshes every 60 seconds. Step 3: Calculating Win Rate (the tricky part) The key is the redeemable flag — redeemable: true means they won, currentValue: 0 + redeemable: false means they lost. Took a few wrong attempts with cashPnl (always negative, not useful). Step 4: The Whale Alert Banner Every 60 seconds I check for trades over $5,000 placed in the last 10 minutes. When it fires, a green banner slides down with the whale name, market, and amount. Auto-dismisses after 12 seconds. First time I saw it fire live with a $28K bet — genuinely exciting. Results 129+ users in the first few days Zero ad spend Traffic from Twitter, Reddit, Quora What's Next More whale wallets (suggestions welcome) Click-through to open the same market on Polymarket directly Email/push alerts for big trades Check it out: whaletrack.app All feedback welcome — especially if you spot a whale I'm missing.

Eight months ago, a CS exam forced me to write pseudocode when I already knew how to code. Instead of studying, I rage-built an app. Today examintelligence.app is live. Here’s exactly how I got here—from vibe-coded POCs to a production hybrid AI pipeline—without the curated startup gloss. The Philosophy Behind the Build I’ve always believed studying for marks ≠ actually learning. When I was first introduced to organic chemistry, I hated it. Then I ran into GNNs in Machine Learning with PyTorch and Scikit-Learn , paired with the MoleculeNet dataset. Suddenly, everything clicked. I wanted to learn everything about it. That’s the core problem: exams optimize for pattern recognition, not curiosity. You’re forced down one prescribed path, and it rm -rf s the fun of learning in most cases. So one week before my first prelims, I decided to build exam intelligence. The plan was simple: introduce brutal efficiency using AI for what it’s actually built for: pattern recognition Parse every past paper, mark scheme, and examiner report. Distill it down to precisely what matters. Free up time for coding and creative work. Vibe-Coding the POC (and Why It Collapsed) I’m generally against vibe-coding. It’s unreliable, hard to maintain, and a security nightmare. But with prelims staring me in the face, I had no choice. I opened Claude and vibe-coded it module by module. The only code review I had time for was checking for suspicious os.system or subprocess calls. That was it. I shipped anyway. Initial stack: Gemini API (no agent frameworks, no LangGraph) Streamlit frontend PostgreSQL It validated my idea but functionally, it barely held together. After prelims, I finally looked at what the AI had actually built: Dashboard showing random stats Asked Gemini for a JSON response with 5 keys, saved only 2 Randomly created DB tables while trying to read subjects The kind of code you end up with when you let an AI cook unsupervised for a week. So I did the only reasonable thing: opened Neov

I had arrived at the final frontier. My bare-metal kernel was booting in QEMU, driving NVMe block storage, running multi-agent swarms, and rendering a force-directed canvas. But to make V.E.L.O.C.I.T.Y.-OS a truly next-generation system, I needed to close the loop: the operating system had to be able to evolve and compile itself without human intervention. The V.E.L.O.C.I.T.Y.-OS 12-Part Roadmap We are building a bare-metal, self-healing operating system running entirely inside the CPU's L3 cache. Here is the roadmap for this 12-part series: Part 1: The Spark — Exposing the "Safe-Room" security leak and building the compiler gate. Part 2: The NDA Language — Designing a content-addressed triplet representation to cure context bloat. Part 3: Ditching the Web Stack — Building a native 30MB IDE with 1,500,000x IPC latency drops. Part 4: The Closure JIT — Compiling AST blocks to nested closures and bypassing borrow checker limits. Part 5: JIT Math Optimizations — Replacing division operations with precomputed 16-bit lookup tables. Part 6: x86-64 Assembler & SCEV-Lite — Compiling scalar loops directly to native code in constant time. Part 7: Classic Compiler Passes — Implementing inter-procedural Dead Code Elimination and loop unrolling. Part 8: Reclaiming Ring 0 — Exiting UEFI boot services and transitioning the kernel to Ring 0. Part 9: Bare-Metal Drivers — Writing a PCI scanner, NVMe block storage controller, and FAT32 parser. Part 10: Synaptic Canvas — Rendering a spatial, force-directed GUI based on model token activation vectors. Part 11: Swarms & Hot-Patching — Building multi-agent scheduling and zero-downtime RCU driver updates. Part 12: Self-Evolution — Handing system control over to a local LLM Terminal that self-optimizes via telemetry. (You are here) During the final hours of my Sunday morning sprint, I completed the self-healing loop, the Biosphere P2P registry, and the Boot-to-NDA LLM Terminal handover. To achieve self-healing, I built a Ring 0 telemetry sys

AgentJr — The AI Junior Developer That Manages Your Entire Freelance Business While You Sleep Most "AI developer tools" do one thing: write code. AgentJr does everything a real junior developer does. Code. Clients. Communication. Deployment. Testing. Invoices. Social media. All of it. Automatically. While you sleep. The Real Problem With AI Coding Tools Today Claude Code writes code. Devin writes code. Copilot writes code. But writing code is maybe 40% of what a freelance developer actually does. The other 60%? Talking to clients. Understanding what they actually want. Managing git properly. Branches, commits, PRs. Running tests. Catching bugs before the client sees them. Deploying to the right environment. Not accidentally pushing dev code to production. Sending updates. "Hey, your feature is live." Tracking costs. How much did this project actually cost me in API calls? Following up. Drafting invoices. Scheduling calls. Posting on LinkedIn about the work you just shipped. No AI tool today handles all of that together. They give you a coding assistant and leave the rest to you. AgentJr is different. AgentJr is not a coding assistant. It's a complete AI junior developer that manages your entire workflow — from the moment a client messages you, to the moment the project is deployed, tested, and the invoice is sent. You Are the CEO. AgentJr Is the Manager. Here's the architecture that makes AgentJr unique: You — give direction. Set priorities. Approve plans. That's it. AgentJr (Manager) — understands requirements, asks smart questions, builds plans, manages git, monitors work, handles client communication, runs tests, manages deployments, tracks costs, drafts invoices, posts social media updates. Claude Code / Codex / Gemini CLI (Worker) — writes the actual code. Spawned by AgentJr on your terminal. Per project. You choose which one. AgentJr never writes code itself. It orchestrates the worker that does. This separation is intentional — and it's what makes the whole s

With the Synaptic Canvas GUI rendering, my bare-metal kernel was fully functional. However, as I expanded the OS features, I ran into multitasking bottlenecks: how do I run background compilation, model inference, and GUI rendering concurrently without crashing the system? Last night, I solved this by implementing three core infrastructure services: Nexus Swarms , Beacon Headless Streaming , and Zero-Downtime OTA Hot-Patching . The V.E.L.O.C.I.T.Y.-OS 12-Part Roadmap We are building a bare-metal, self-healing operating system running entirely inside the CPU's L3 cache. Here is the roadmap for this 12-part series: Part 1: The Spark — Exposing the "Safe-Room" security leak and building the compiler gate. Part 2: The NDA Language — Designing a content-addressed triplet representation to cure context bloat. Part 3: Ditching the Web Stack — Building a native 30MB IDE with 1,500,000x IPC latency drops. Part 4: The Closure JIT — Compiling AST blocks to nested closures and bypassing borrow checker limits. Part 5: JIT Math Optimizations — Replacing division operations with precomputed 16-bit lookup tables. Part 6: x86-64 Assembler & SCEV-Lite — Compiling scalar loops directly to native code in constant time. Part 7: Classic Compiler Passes — Implementing inter-procedural Dead Code Elimination and loop unrolling. Part 8: Reclaiming Ring 0 — Exiting UEFI boot services and transitioning the kernel to Ring 0. Part 9: Bare-Metal Drivers — Writing a PCI scanner, NVMe block storage controller, and FAT32 parser. Part 10: Synaptic Canvas — Rendering a spatial, force-directed GUI based on model token activation vectors. Part 11: Swarms & Hot-Patching — Building multi-agent scheduling and zero-downtime RCU driver updates. (You are here) Part 12: Self-Evolution — Handing system control over to a local LLM Terminal that self-optimizes via telemetry. 1. The Nexus Core Swarm Runtime ( nexus.rs ) To support concurrent compilation and optimization, I built the Nexus Core Swarm Runtime . The

After writing drivers for NVMe storage, my bare-metal kernel could load files and run JIT code. However, I was still typing commands into a text-only COM1 serial terminal. I needed a graphical interface. Last night, the second agent took over to build a double-buffered visual rendering compositor on top of the UEFI Graphics Output Protocol (GOP) framebuffer. The V.E.L.O.C.I.T.Y.-OS 12-Part Roadmap We are building a bare-metal, self-healing operating system running entirely inside the CPU's L3 cache. Here is the roadmap for this 12-part series: Part 1: The Spark — Exposing the "Safe-Room" security leak and building the compiler gate. Part 2: The NDA Language — Designing a content-addressed triplet representation to cure context bloat. Part 3: Ditching the Web Stack — Building a native 30MB IDE with 1,500,000x IPC latency drops. Part 4: The Closure JIT — Compiling AST blocks to nested closures and bypassing borrow checker limits. Part 5: JIT Math Optimizations — Replacing division operations with precomputed 16-bit lookup tables. Part 6: x86-64 Assembler & SCEV-Lite — Compiling scalar loops directly to native code in constant time. Part 7: Classic Compiler Passes — Implementing inter-procedural Dead Code Elimination and loop unrolling. Part 8: Reclaiming Ring 0 — Exiting UEFI boot services and transitioning the kernel to Ring 0. Part 9: Bare-Metal Drivers — Writing a PCI scanner, NVMe block storage controller, and FAT32 parser. Part 10: Synaptic Canvas — Rendering a spatial, force-directed GUI based on model token activation vectors. (You are here) Part 11: Swarms & Hot-Patching — Building multi-agent scheduling and zero-downtime RCU driver updates. Part 12: Self-Evolution — Handing system control over to a local LLM Terminal that self-optimizes via telemetry. This led to the design of the Synaptic Canvas GUI . The Swappable GUI Engines I started by mapping the physical screen buffer pointer discovered by UEFI GOP. I implemented a double-buffering scheme: drawing elem

Video demo link : https://youtu.be/vSjeTkrou1s?si=qTcrWyz0HSWDiWSF If you run Claude Code, Codex, or other AI agents, you know the pain: the terminal floods with generated output while you're still typing — and your keystrokes lag, characters "drag." TawTerminal fixes that. Your keystrokes go straight to the screen on a separate path from shell output, so typing stays instant even while an AI agent streams thousands of lines. What you get: ⚡ Zero input lag — GPU-accelerated (WebGL) rendering at 60fps, multi-process so heavy output never blocks your typing 📁 Workspace folders — pin folders in the sidebar, spawn a shell rooted in any directory in one click, with live git branch + status 🤖 One-click AI agents — launch Claude Code, Codex, PI, or tawx directly from the sidebar, sessions auto-restored 🪟 Split panes & tabs — Cmd+D to split, Cmd+T for tabs 🖼️ Paste images — drag-drop or Cmd+V images straight into the terminal 🎨 4 beautiful themes — Tokyo Night, Catppuccin Mocha, Dracula, Rosé Pine 📊 Live AI usage footer — see today's Claude Code / Codex token + cost estimate 🍎 Native macOS feel — clean hidden title bar, clickable URLs, custom fonts Requirements: macOS, Apple Silicon (M1 or newer). Signed & notarized by Apple — installs clean, no security warnings.

When I started thinking about real-time alerts for my SaaS, my first instinct was Slack. Familiar,...

In the previous article on hosting a Next.js app on a VPS , I'd left the deployment pipeline as a rough sketch: four lines to say "it ships to production on its own when you push." That's the piece I want to open up here, because it's what separates a VPS you fuss over by hand from infrastructure you can forget about. There's a stubborn myth that CI/CD is a big-company thing, with a dedicated DevOps team and six-figure tooling. Not true. The pipeline that deploys this portfolio fits in two YAML files, you can read it in five minutes, and it gives me back exactly the comfort I liked about Vercel: I push to master , I go grab a coffee, the app is live when I'm back. The one thing I gained along the way is knowing precisely what happens between the git push and the running container. Four steps, in this order Deployment is a chain. On every push to master , GitHub Actions runs lint, security scan, image build, and deploy. What matters is the needs : as long as a step fails, the following ones don't start. A critical vulnerability caught by the scan, and the image never gets built. At all. jobs : lint : # ESLint runs-on : ubuntu-latest # ... security : # Trivy scan (reusable workflow) uses : ./.github/workflows/security.yml build-push : # build the Docker image → push to GHCR needs : [ lint , security ] # ... deploy : # SSH to the VPS → docker compose pull && up -d needs : [ build-push ] # ... Lint first, because it's the cheapest step and there's no point building an image if ESLint is already screaming. The scan next, as a barrier. Then the build, which produces the Docker image and pushes it to GHCR, GitHub's container registry (private, in my case). And finally the deploy, which connects over SSH to the VPS, pulls the new image and restarts the container. Four links, each blocking the next. That's the whole secret. The security scan is in the path, not in a review "for later" This is the one I won't budge on. Dependency security, in a lot of projects, is a Dependabo

Let's be honest — standard GitHub profiles are a bit... static. As a Full Stack Developer & AI/ML Specialist, I wanted a way to showcase my contributions that actually felt alive. I didn't just want a grid of green squares; I wanted a universe. So, I built GitPulse. What is GitPulse? GitPulse is a cinematic, interactive web application that transforms standard GitHub profiles and repository logs into glowing, animated contribution universes. Instead of just seeing numbers, you experience your code history visually. The Tech Stack I wanted this to feel premium, fast, and visually stunning without relying on heavy frontend frameworks if I didn't need to. Canvas API & GSAP: For buttery-smooth micro-animations and physics. Glassmorphism UI: Using CSS backdrop-filters to create a modern, deep aesthetic. Vanilla JavaScript: Keeping the core logic incredibly fast and lightweight. The "Stellar Duel" Feature One of the coolest features I added was the Stellar Duel mode. I thought: What if you could compare your GitHub activity with a friend, but instead of a boring chart, it looked like a sci-fi dashboard? Stellar Duel Using the GitHub API, GitPulse fetches the data and renders a live, side-by-side visual duel of your commit history, stars, and PRs. It’s highly interactive and honestly, just really fun to look at. The Biggest Challenge: Performance Rendering thousands of data points (commits) visually on a canvas can crash a browser if you aren't careful. To solve this, I had to heavily optimize the animation loop. Instead of manipulating the DOM for every star/commit node, I used HTML5 Canvas to batch render the visual elements. I also implemented requestAnimationFrame properly to ensure the animations pause when the user switches tabs, saving CPU cycles. See it in Action I've integrated GitPulse directly into my main portfolio. You can try it live here: GitPulse Live Demo And if you want to see more of the projects I build (especially in the AI/ML and Computer Vision space

Living in the UAE means constantly Googling numbers: what is the visa fee now, how much zakat do I owe, what is today's fuel price, how is my gratuity calculated. The answers online are usually outdated. So I built Adad , a free set of 15 calculators that pull from official UAE government sources and refresh every 24 hours. No sign-up, works in 8 languages. A few that people use most: Visa fees: real GDRFA and ICA rates Zakat: gold, silver, savings DEWA bills: estimate before the bill lands Gratuity: UAE labour-law end-of-service It is at adad.ae if it is useful to you. Happy to answer how the data pipeline stays current.

Vercel m'a longtemps convenu. Tu pousses ton code, trente secondes plus tard c'est en ligne avec un certificat valide, un CDN et des previews par branche. Pour démarrer un projet, je ne connais rien de plus confortable. Le problème arrive après, quand le projet vit. La facture grimpe avec le trafic et les fonctions serverless, certaines fonctionnalités propriétaires deviennent compliquées à reproduire ailleurs, et tu finis par ne plus vraiment savoir où ni comment ton app tourne. C'est un excellent point de départ, et un piège dès qu'on veut maîtriser son coût et son infra. Pour ce portfolio comme pour plusieurs projets clients, j'ai pris le chemin inverse. Un VPS à quelques euros par mois, une image Docker, un reverse proxy, un pipeline maison. L'idée n'est pas de revenir à l'âge de pierre du déploiement par FTP : je garde le « git push et c'est en ligne », mais sur une machine que je contrôle de bout en bout. Voici comment c'est câblé, et les deux ou trois endroits où je me suis fait avoir. L'image Docker : tout repose sur le mode standalone La pièce qui change tout, c'est output: "standalone" dans next.config.ts . Au build, Next trace exactement les fichiers nécessaires au runtime et les recopie dans .next/standalone/ . On passe d'une image d'environ 1 Go à environ 200 Mo. Sans ça, tu traînes tout node_modules dans ton conteneur de prod pour rien. Le Dockerfile est multi-stage : une étape pour installer les dépendances, une pour builder, une dernière qui ne garde que le strict nécessaire. # deps : installe les dépendances (cache Docker optimal) FROM node:22-alpine AS deps WORKDIR /app COPY package.json yarn.lock .yarnrc.yml ./ RUN corepack enable && yarn install --immutable # builder : build l'app FROM node:22-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN corepack enable && yarn build # runner : image finale, non-root FROM node:22-alpine AS runner WORKDIR /app ENV NODE_ENV=production RUN addgroup -g 1001 nodejs && a

I Built a Free Apache Kafka Course from Scratch — Here's the Full Curriculum (and What I Got Wrong) I spent months building a free Apache Kafka course covering everything from first principles to a real-time analytics platform final project. No paywall. No "premium tier." 9 modules, 470 minutes of content, completely free. Here's the full syllabus, the Python code that actually works, and the honest mistakes I made building the curriculum — so you don't repeat them. Why I Built This Every time someone asked me "how do I learn Kafka?", I sent them to the same 3 places: The official Confluent docs (dense, assumes you already know what you're doing) A $15 Udemy course that spends Module 1 explaining what a computer is A YouTube playlist where half the videos are deleted None of them answered the real question beginners have: why does Kafka exist, and what problem does it actually solve before I write a single line of code? That's the gap I built for. The Problem With Most Kafka Tutorials Most tutorials start with: "Kafka is a distributed event streaming platform..." And then they immediately show you a Docker Compose file with 6 services. Beginners copy-paste it, something breaks, they don't know why, they quit. The real problem is that Kafka is an answer to a specific architectural problem — and if you don't understand the problem first, the solution makes no sense. So Module 1 and 2 of this course don't touch Kafka at all. They build the problem statement from scratch. The Full Syllabus (9 Modules, 470 Minutes) Module 1: Introduction to Kafka — 35 min Not "what is Kafka" — but why event streaming exists at all. What breaks in traditional request-response architectures at scale. Module 2: The Problem Statement — 30 min A real-world scenario: you're building an e-commerce platform. Orders, inventory, notifications, analytics — all tightly coupled. What happens when one service goes down? This module makes the pain visceral before Kafka enters the picture. Module 3: How