标签：#beginners

The therapy unit at the hospital I work for had six treatment rooms. Room 1, Room 2, Room 3, and so on, each split by the kind of therapy it handled. And each room kept its own document to record patients. The problem wasn't that the documents existed. The problem was that no two of them looked alike. Same patient. Same information. But every room ordered the columns differently and named things differently. One put the date in the first column. Another put it last. One wrote "treatment time." The room next door wrote "minutes used." On their own, each form worked fine. Looked at one at a time, there was nothing wrong. The trouble showed up the moment anyone tried to combine them. The work that never ended Every so often, a request would come down from above: Can we see the overall numbers? That was when the real work began. I would open all six documents side by side. I would line up columns that didn't match, by eye, and move each value into one master table by hand. Days of this would get me a single sheet of statistics. Then the next quarter, the same request came down again. And I started over. The table I'd built last time was useless if the format had shifted even slightly. So I rebuilt it from scratch. Every time. I couldn't stand it. This was obviously a job you do right once and never touch again. We just weren't doing it right. So instead, we kept feeding people's evenings into it. The obvious answer The fix was simple. Make all six rooms use one form. Same columns. Same names. Same order, everywhere. Then there's nothing to move when you combine them. The statistics become a matter of stacking, not translating. The answer was so obvious I wondered why nobody had done it years ago. So I built a unified form in Excel and sent it around. And that's where I learned Excel has walls of its own. Where Excel broke down Once a file gets passed around, you lose track of which copy is the real one. The versions pile up. "Final." "Actually final." "Final, revised."

Git submodules have a reputation for being fiddly, but most of that pain comes down to a handful of missing commands and one config flag nobody mentions. Used well, they're a clean way to embed a shared library, a design-system repo, or a common docs folder inside another project - pinned to an exact commit so nothing shifts under your feet. This guide walks through the whole lifecycle, from adding a submodule to removing it, and calls out the gotchas that bite teams in real projects. Understanding What a Submodule Actually Is Before the commands, one mental model that clears up most confusion: a submodule embeds another git repo inside yours at a fixed path, pinned to a specific commit. Your repo doesn't track the submodule's files - it tracks which commit of the submodule to check out. That single idea explains almost every quirk that follows. Adding a Submodule Adding one is a single command: git submodule add git@github.com:org/shared-lib.git vendor/shared-lib This clones the repo into vendor/shared-lib , creates a .gitmodules file describing the mapping, and stages the pinned commit (git calls this a "gitlink"). Commit both pieces: git add .gitmodules vendor/shared-lib git commit -m "chore: add shared-lib submodule" The resulting .gitmodules entry is plain text and lives in version control: [submodule "vendor/shared-lib"] path = vendor/shared-lib url = git@github.com:org/shared-lib.git branch = main The branch line is optional: it's only used later when pulling the latest changes automatically. Cloning Without the Empty-Folder Surprise The most common submodule complaint is a teammate cloning the project and finding an empty folder where the submodule should be. The fix is knowing two commands: # Clone everything in one shot git clone --recurse-submodules <your-repo-url> # Already cloned? Initialize after the fact git submodule update --init --recursive Even better, run this once per machine so git pull and git checkout keep submodules in sync automatically - a

Introduction When learning JavaScript, one of the first concepts you’ll encounter is functions. Functions are the building blocks of JavaScript. They help you organize code, avoid repetition, and make your programs easier to understand. If variables store data, functions define behavior . You’ll use functions everywhere: handling user input, processing data, calling APIs, and structuring your code. In this article, we’ll cover: What is a function Function declarations Function expressions Parameters vs arguments Return values Arrow Functions Why Functions Matter 1. What is a Function? A function is a reusable block of code designed to perform a specific task. Think of it like a machine: Input → Process → Output function greet () { console . log ( " Hello! " ); } To run the function, you call it: greet (); // Hello! 2. Function Declaration This is the most common way to define a function: function add ( a , b ) { return a + b ; } 💡 Explanation: Defined using the function keyword Can be called before it is declared (because of hoisting) Key parts: function → keyword add → function name a, b → parameters return → output value add (); // ✅ Works! function add ( a , b ) { return a + b ; } 💡 Why does this work? JavaScript reads the code first, and function declarations are stored in memory during the initial phase (hoisting) . That’s why you can call the function even before it’s defined in the code. 3. Function Expressions Functions can also be stored in variables: function add ( a , b ) { return a + b ; } 💡 Explanation: Assigned to a variable Cannot be used before initialization add (); // ❌ Error: Cannot access before initialization const add = function ( a , b ) { return a + b ; }; 💡 Why does this cause an error? Because: const add has not been initialized yet when it is called. The function itself is not in memory at that moment . 4. Parameters vs Arguments This is a common beginner confusion: Parameter: variable in function definition Argument: actual value passed i

The moment you press Enter, billions of mathematical operations begin. Let's follow that journey. Every day, millions of people ask ChatGPT, Gemini, Claude, or other AI assistants questions. The answer appears almost instantly. But have you ever wondered what actually happens after you press Enter? Why can't a normal CPU answer these questions quickly? Why do companies spend billions on GPUs? Let's take a journey from your keyboard to the AI's brain. Imagine This... Suppose your office receives 10,000 letters. You have two choices. Option 1: One super-fast employee He opens one letter after another. Very fast. But still... One at a time. This is a CPU. Option 2: 10,000 employees Each opens one letter simultaneously. The work finishes almost instantly. This is a GPU. The difference isn't that each employee is smarter. There are simply many more workers working together. CPU vs GPU Think of it like this. CPU = CEO making decisions. GPU = Thousands of factory workers building products simultaneously. Why CPUs Are Amazing Your CPU performs tasks like Opening Chrome Playing music Running Windows Calculating taxes Managing memory Running applications These jobs require decisions branches conditions interrupts This is logical thinking. CPUs are built for this. Why GPUs Exist Originally GPUs were invented for games. Imagine rendering one image. A 4K monitor contains over 8 million pixels. Each pixel needs calculations. Every frame. 60 times every second. Instead of calculating one pixel at a time... GPU calculates millions together. Gaming accidentally created the perfect hardware for AI. AI Doesn't Think Like Humans LLMs don't "think" in English. They perform mathematics. Lots of mathematics. Almost everything inside an LLM becomes... Matrix × Matrix Vector × Matrix Addition Multiplication Normalization Softmax That's all mathematics. Billions of times. Why Matrix Multiplication Matters Imagine two tables. Table A 1 2 3 4 5 6 7 8 9 Multiply with Table B 2 4 6 8 1 3 Every n

I've lost count of how many AI side projects I started and abandoned. The pattern was always the same: a spark of excitement, two weeks of frantic coding, then the slow fade into yet another half-finished repo collecting dust on GitHub. But something changed in the last two months. I shipped three AI-powered MVPs to real users. Not all of them made money, but every single one taught me something about what it actually takes to go from "cool idea" to "working product." Here's what I learned. The brutal truth about AI side projects When I started my first real AI project back in February, I had grand ambitions. I was going to build a content summarizer that would pull articles from any URL, analyze sentiment, and generate Twitter threads. I spent three weeks obsessing over the perfect prompt engineering, containerizing the whole stack with Docker, and setting up a complex pipeline using LangChain and Pinecone. Then I showed it to a friend. "Can I just paste a link?" she asked. I had built an entire orchestration layer, but the input field was buried behind two authentication screens. The project died that weekend. Here's the thing I keep rediscovering: AI side projects fail not because the technology doesn't work, but because we over-engineer before we have users. The three MVPs that actually shipped After that failure, I changed my approach. I decided to ship something—anything—every two weeks. No matter how ugly. No matter how incomplete. The goal was to have a URL someone could visit and use. MVP #1: A dead-simple blog title generator I built this in a single afternoon. The entire frontend was a text box and a button. Backend? A single Node.js endpoint that called OpenAI's API with a prompt like: "Generate 5 catchy blog titles about [topic]." Here's the code that powered it (I've simplified it, but this is the gist): import express from ' express ' ; import OpenAI from ' openai ' ; const app = express (); const openai = new OpenAI ({ apiKey : process . env . OPENAI

When people talk about hackathons, they talk about the demo. The pitch, the UI, the "aha" moment on stage. Nobody really talks about the person who spent the whole weekend making sure the data didn't fall apart. That was me on AidStream, a blockchain-based aid distribution platform we built in a weekend and trust me it wasnt that easy as it seems. At a normal project, you can revisit your data model whenever.But during a hackathon you cant since when teamamtes start working on top of your tables it means both codes may start breaking . Serverless Postgres was the right choice for a hackathon: no local DB setup, no "wait, whose laptop has Postgres installed" problem. Everyone could connect to the same instance immediately. The gotcha was connection limits — with multiple people hitting the same database while testing features simultaneously, we ran into connection issues at the worst possible time (an hour before demo). So next time you watch a hackathon demo go off without a hitch, remember — someone probably spent the whole weekend quietly making sure the database didn't have a say in it. If you're the one holding the schema together at 2am, know this — it's not the flashy role, but it's the one that decides whether anyone else's code even runs.

Disclaimer: I'm currently learning web security through OWASP and PortSwigger Web Security Academy. These are my beginner-friendly notes rewritten as a blog to help reinforce my understanding. If you're just starting out, I hope this makes the topic easier to understand. What you'll learn: In this article you'll learn: ✔ What Broken Access Control is ✔ Vertical Privilege Escalation ✔ Security by Obscurity ✔ Parameter-Based Access Control ✔ Platform Misconfiguration ✔ Horizontal → Vertical Escalation ✔ IDOR ✔ Lessons learned from PortSwigger labs Concept Map: What is Broken Access Control? Broken Access Control happens when a user is able to access data, pages, or perform actions that they are not supposed to . Why should you care? Broken Access Control has ranked #1 in the OWASP Top 10 (2021) because it can expose sensitive data, allow privilege escalation, and let attackers perform actions they should never be able to perform. Think of a website with two types of users: Normal User Admin A normal user should only be able to view their own profile and perform basic actions. An admin, however, can manage users, delete accounts, change settings, etc. If a normal user somehow gains access to those admin features, that's Broken Access Control . In interview terms: Broken Access Control is the failure to properly enforce authorization, allowing users to perform actions beyond their intended permissions. 1. Vertical Privilege Escalation Vertical Privilege Escalation means moving up the permission hierarchy. Example: Normal User ↓ Admin A normal user should never be able to become an administrator. 1.1 Unprotected Functionality One of the simplest forms of Broken Access Control is Unprotected Functionality . Imagine a website has an admin page: /admin The developer removes the Admin button from the normal user's dashboard. Problem solved? No. If a user manually visits: /admin and the server doesn't verify whether they're actually an admin, the page opens. The mistake here

Python's Memory Model Is Not What You Think It Is Ask most Python developers how Python stores a variable and they will say "it stores the value." This is imprecise in a way that causes real bugs and real confusion in interviews. A precise mental model of how Python stores and retrieves data changes how you read and write code. Python does not store values in variables. Python binds names to objects. The distinction sounds philosophical until you trace code that involves mutation, function arguments, or aliasing. Then it becomes the most practically useful concept in the language. Names Are Not Boxes The box metaphor, which says a variable is a box that holds a value, is how most introductory programming courses explain variables. In many languages this metaphor is close enough to accurate that it does not cause problems. In Python it is wrong in ways that matter. A more accurate metaphor: a Python name is a label attached to an object. The object exists independently in memory. Multiple labels can be attached to the same object. Attaching a new label does not move or copy the object. x = [ 1 , 2 , 3 ] y = x print ( id ( x ) == id ( y )) # True (same object, two labels) When you write y = x , you are not copying the list. You are creating a second label that points to the exact same list object. The Four Operations You Must Distinguish 1. Assignment creates a new binding x = [ 1 , 2 , 3 ] x = [ 4 , 5 , 6 ] # x now labels a completely different object The first list still exists in memory until garbage collected. The name x simply stops pointing to it and now points to the second list. 2. Mutation modifies an existing object x = [ 1 , 2 , 3 ] x . append ( 4 ) # the object x labels is modified in place Any other name pointing to the same object will instantly reflect this change because they look at the same memory location. 3. Augmented assignment on mutable types mutates x = [ 1 , 2 , 3 ] y = x x += [ 4 , 5 ] print ( y ) # [1, 2, 3, 4, 5] (same object, mutated) The

Hey everyone! 👋 I'm a complete beginner and today I'm officially kicking off my #100DaysOfCode challenge with Python. I've dabbled with the idea of learning to code for a while, but this time I want to actually commit - so I'm posting daily updates here to keep myself accountable and track my progress over the next 100 days. My plan: Post a short update here every day - what I learned, what I struggled with, and what's next Eventually move into some small real-world projects once I've got the basics down Why I'm doing this: I want to build real skills, not just "watch tutorials and forget everything." Writing it down publicly (even anonymously) keeps me honest and hopefully connects me with others on the same path. If you're also learning Python or doing a 100 days challenge, I'd love any tips, resources, or just to follow along with each other's progress! Day 1 status: Just setting up my environment and going through the basics — nothing exciting yet, but everyone starts somewhere! 100DaysOfCode #Python #Beginner #LearnToCode

Quick Note In my previous article, I mentioned that Linux Troubleshooting Flow for Beginners would be the final post in this series. While preparing it, I realized there were a few practical Linux skills every beginner should learn first. These topics will make the troubleshooting guide much easier to understand and follow. Before we wrap up the series, we'll cover: Package Management Finding Files & Text Viewing Files Efficiently File Compression Then we'll bring everything together in the final Linux Troubleshooting Flow for Beginners. Introduction Installing software on Linux is very different from Windows. On Windows, you usually download an .exe installer. On Linux, software is typically installed and managed using package managers . This is one of the most practical skills every Linux beginner should learn early. What is a Package? A package is a ready-to-install bundle that contains: The main program Required libraries Configuration files Documentation Examples: nginx , git , docker , curl , vim Think of a package as a ready-to-install software box. What is a Package Manager? A package manager is a tool that installs, updates, removes, and manages software packages. Instead of downloading software manually, you simply run a command. Example: sudo apt install git The package manager automatically: Downloads packages from trusted repositories Install required dependencies automatically Upgrade installed software Removes them cleanly Instead of manual downloading, you just run one command. Why Use a Package Manager? Without package managers, you would have to: Search for software manually Download files from websites Install dependencies yourself Update each application separately Package managers automate all of this. What is a Repository? Package managers download software from repositories. A repository is a trusted online collection of software packages maintained by your Linux distribution. Instead of downloading software from random websites, Linux install

Hi folks! This is Mark Tony , a fresher to this field of technology from the UG Physics background. In a way, I'm pursuing my desire which I missed during my college days. My new venture begins along with @payilagam_135383b867ea296 Where I'm doing my Full stack developer course right now. I'm excited and enthusiastic about learning and becoming a developer. Dev community kick starts my journey 😉😊

I didn't go to a university for computer science. I have a B.Tech in Geophysics. What I know about...

Ask a room full of engineers to name the most popular integrated circuit ever made and you will hear guesses about famous microprocessors or memory chips. The real answer is far humbler: an eight-pin timer chip designed in 1971 that is still manufactured by the billion every single year. It is the 555 timer , and more than half a century after its debut it remains one of the first chips a student wires up and one of the last a veteran gives up on. A chip designed by one engineer The 555 was designed by Swiss-born engineer Hans Camenzind , working under contract to Signetics , and it reached the market in 1972. What made it remarkable was not raw speed or complexity but flexibility. Inside its tiny package sit a couple of dozen transistors, a handful of resistors, and two voltage comparators arranged around a simple voltage divider. Feed it a supply voltage, add one or two external resistors and a capacitor, and it will generate precise time delays and oscillations without any software at all. That analog-first design philosophy is exactly why it endured. By some estimates the 555 has been produced at a rate of around a billion units a year for decades, which comfortably earns it the title of probably the most popular IC ever made. It has flown on spacecraft, blinked in toys, and sat quietly on countless hobbyist breadboards. What the 555 actually does The 555 has three classic operating modes, and understanding them covers most of what you will ever need: Monostable — one stable state. A trigger produces a single output pulse of a fixed length set by an external resistor and capacitor. Think of a debounced button press or a timed relay. Astable — no stable state. The output oscillates continuously between high and low, producing a square wave. This is your blinking LED, your simple tone generator, or a rough clock source. Bistable — a basic flip-flop that latches between two states, useful as a simple set/reset memory element. None of this requires firmware, a cryst

Automation is the part of DevOps that actually earns the title. Day 6 was two of the most everyday automation tasks there are, and both had a trap sitting in plain sight. One Linux task, one AWS task. Schedule a recurring job with cron, and launch an EC2 instance from the AWS CLI. The tasks come from the KodeKloud Engineer platform if you want the same lab to work through. Cron: five fields, one rule that trips everyone Cron is the scheduler that has quietly run Linux automation for decades. You hand it a job and a schedule, and its daemon, crond, wakes up every minute to check whether anything is due. If that daemon is not running, nothing fires, so the first move is making sure it is installed and enabled. # Become root sudo su - # Install the cron daemon if it is missing yum install cronie -y # Enable it at boot, start it now, and confirm it is alive systemctl enable crond.service systemctl start crond.service systemctl status crond.service cronie is the package name on RHEL-family distros. enable makes the service survive a reboot, start brings it up right now, and status is how you confirm it is actually running instead of assuming it is. Now edit the crontab: # Edit the current user's crontab crontab -e # minute hour day-of-month month day-of-week command 0 2 * * * /path/to/script.sh # List what is currently scheduled crontab -l That line runs the script every day at 2am. The five fields, in order, are minute, hour, day of month, month, and day of week: minute: 0 to 59 hour: 0 to 23 day of month: 1 to 31 month: 1 to 12 day of week: 0 to 7, where both 0 and 7 mean Sunday Here is the rule that quietly breaks schedules. When you set both the day-of-month field and the day-of-week field to something other than a star, cron treats them as OR, not AND. So 0 0 13 * 5 does not mean midnight on Friday the 13th. It means midnight on every 13th of the month, and also every Friday, whichever lands first. If you actually want the AND, you restrict one field in cron and che

In this blog post, we will see how to performance test a RAG (Retrieval-Augmented Generation) application properly, covering both speed and correctness, and how to wire both into a CI/CD pipeline so regressions get caught before they reach production. Performance testing a RAG application requires two separate testing gates: one for speed and one for answer quality. Traditional load testing tools measure response times but cannot detect hallucinations, where a model returns fast but factually incorrect answers grounded in fabricated context rather than retrieved documents. The guide demonstrates using k6 for load testing end-to-end latency and DeepEval for evaluating faithfulness and answer relevancy using an LLM-as-judge approach. Both gates are integrated into a GitHub Actions CI/CD pipeline so regressions in either performance or output quality are caught automatically on every pull request before reaching production. If you've come from a JMeter or k6 background like I have, your first instinct with a RAG endpoint is probably to point a load test at it and check response times. That gets you halfway there. A RAG app can return a fast, confident, completely wrong answer, and a plain load test will never tell you that. You need two testing surfaces, not one: performance and quality. This guide covers both, using a single running example throughout: a documentation assistant that answers "How do I run JMeter in non-GUI mode?" against a small knowledge base. Why RAG breaks traditional load testing assumptions A conventional API returns a complete response and you measure the round trip. A RAG endpoint does two expensive things before it answers: it retrieves context from a vector store or search index, then it streams a generated response token by token. That second part matters a lot. A single request can stream hundreds of tokens over several seconds, so "request duration" as a single number hides two very different problems: how long the model took to start answe

Building an AI agent sounds complicated. It's not. By the end of this guide, you'll have a working agent that can search the web, remember conversations, and handle multi-step tasks. No frameworks, just TypeScript and an LLM API. What We're Building A research assistant agent that: Takes questions from users Uses tools (web search) when needed Remembers conversation history Handles errors without crashing Runs in about 150 lines of TypeScript This won't be production-ready, but it'll work and you'll understand every line. Prerequisites You need: Node.js 18 or higher Basic TypeScript knowledge An Anthropic API key ( get one free ) That's it. No prior AI experience needed. Setup (5 minutes) # Create project mkdir research-agent cd research-agent npm init -y # Install dependencies npm install @anthropic-ai/sdk dotenv # Install dev dependencies npm install -D typescript @types/node tsx # Initialize TypeScript npx tsc --init Create .env : ANTHROPIC_API_KEY = your-key-here Step 1: Define Your Types Create src/types.ts : export interface Message { role : ' user ' | ' assistant ' ; content : string ; } export interface Tool { name : string ; description : string ; input_schema : { type : ' object ' ; properties : Record < string , any > ; required ?: string []; }; execute : ( input : any ) => Promise < string > ; } Why these types matter: Strong typing prevents bugs. If you change how a tool works, TypeScript tells you everywhere that breaks. Step 2: Create a Simple Tool Create src/tools/search.ts : import { Tool } from ' ../types ' ; export const searchTool : Tool = { name : ' search_web ' , description : ' Search the internet for current information. Use this when you need facts, recent events, or data you do not know. ' , input_schema : { type : ' object ' , properties : { query : { type : ' string ' , description : ' The search query ' , }, }, required : [ ' query ' ], }, execute : async ( input : { query : string }) => { console . log ( `[Tool] Searching for: ${ input

I recently worked through the classic Word Break problem in an interview. My approach was solid from the start — recursion with memoization, a breakable helper that tests every prefix and recurses on the rest. The logic was right. What slowed me down was everything around the logic. Here's the solution I landed on: class Solution { public: bool wordBreak ( string s , vector < string >& wordDict ) { unordered_set < string > dict ( wordDict . begin (), wordDict . end ()); unordered_map < size_t , bool > memo ; return breakable ( s , dict , memo , 0 ); // missed: breakable was a free function defined below -> "not declared in this scope" } private : // missed: had int here, compared against s.length() (size_t) -> sign-compare warnings bool breakable ( const string & s , const unordered_set < string >& dict , unordered_map < size_t , bool >& memo , size_t starting ) { if ( starting == s . length ()) return true ; if ( memo . count ( starting )) return memo [ starting ]; for ( size_t e = starting + 1 ; e <= s . length (); e ++ ) { string word = s . substr ( starting , e - starting ); // missed: shadowed an outer `word`, and had substr(starting, e) instead of e - starting if ( dict . count ( word ) && breakable ( s , dict , memo , e )) { memo [ starting ] = true ; // missed: wrote == instead of =, so success was never cached return true ; } } memo [ starting ] = false ; // missed: this line, so failures were never cached and memoization broke down return false ; } }; The real lesson Most of what tripped me up was syntax and scope — a function declared in the wrong place, signed/unsigned mismatches, a shadowed variable, == where I meant = . None of these were about the algorithm. But because I spent my time chasing them, I had less room to focus on the one thing that actually matters in this problem: the logical correctness of the memoization. The takeaway I'm keeping: get the syntax and scoping clean early, so the debugging budget goes toward logic, not typos. That's the

A few months ago I didn't know much about coding. Today I have a full stack marketplace running with a real API, a live database, user authentication, image uploads, messaging and a React frontend. The Idea Kisumu has a huge secondhand clothes market. Mitumba is everywhere — Kibuye market, roadside stalls, WhatsApp groups. But there is no dedicated digital platform for it. If you want to sell a jacket in Kondele you have no easy way to reach buyers in your area. If you want to find size L shoes in CBD you have to physically go and look. I wanted to build something that solved a real local problem. Not another todo app. Not another weather app. Something that could actually help people in my city. That is how Kisumu Marketplace was born. The Tech Stack I Chose I built the backend in Go using the Gin framework. The database is PostgreSQL hosted on Neon.tech — a free cloud database that saved me more than once when my laptop broke. Authentication uses JWT tokens and bcrypt for password hashing. Images are uploaded to Cloudinary. The frontend is React with Tailwind CSS. I chose Go because Zone 01 teaches it and I wanted to go deep on one language rather than shallow on many. I chose PostgreSQL because it is the industry standard and learning it properly matters. I chose React because it is the most in-demand frontend framework and I wanted to build something real with it. What I Learned I learned Go from scratch while building this. I learned React from scratch while building this. I learned PostgreSQL, JWT, bcrypt, Cloudinary, Tailwind, axios, React Router and more — all by needing them for this project. The most valuable thing I learned is that you understand something properly only when you build with it. Reading about JWT is nothing like debugging a 401 Unauthorized error at midnight. I also learned that documentation is a skill. Writing this article, explaining how things work, is making me understand my own project better.

TL;DR Converting HDR10 to SDR with a naive FFmpeg command gives you grey, washed-out video. The fix is tone mapping. We will detect HDR with ffprobe , run two working tone-map chains ( zscale on CPU, libplacebo on GPU) in FFmpeg 8.0, compare operators, and batch it. Test the commands on your own build before shipping. 📦 Code: github.com/USER/hdr-to-sdr, replace before publishing If you have ever run an HDR clip through your normal pipeline and gotten back something flat and foggy, this post is for you. The bug is that HDR and SDR are different color systems, and "just converting" reinterprets one as the other. We will use FFmpeg 8.0 "Huffman" (8.0.2 is current as of May 2026). Why naive conversion fails HDR10 SDR Transfer function PQ (SMPTE ST 2084) gamma 2.4 / BT.1886 Color primaries Rec.2020 (wide) BT.709 (narrow) Peak luminance ~1,000 to 4,000 nits ~100 nits A command that ends in -pix_fmt yuv420p with no tone mapping reads PQ-encoded, Rec.2020 values as if they were SDR. The gamut gets crushed with no intelligence and the brightness curve is misread. Hence the fog. 1. Detect whether a file is even HDR 🔍 Do not tone-map SDR files. Check first: # detect transfer characteristics and primaries ffprobe -v error -select_streams v:0 \ -show_entries stream = color_transfer,color_primaries,color_space \ -of default = noprint_wrappers = 1 input.mkv HDR10 content reports something like: color_space = bt2020nc color_transfer = smpte2084 color_primaries = bt2020 If color_transfer is smpte2084 (PQ) or arib-std-b67 (HLG), you have HDR and you need to tone-map. If it says bt709 , leave it alone. 2. The libplacebo path (GPU, my default) 🚀 libplacebo is the Vulkan-accelerated filter in FFmpeg 8.0. It follows the ITU tone-mapping recommendations and handles the color conversions internally, so the command is short: ffmpeg -i input.mkv \ -vf "libplacebo=tonemapping=bt.2390:colorspace=bt709:color_primaries=bt709:color_trc=bt709:format=yuv420p" \ -c :v libx264 -crf 20 -c :a copy \ ou

With over 5 years in customer support and retention, I've lost count of how many times I've seen the same pattern: a customer explains an issue, gets it "resolved," and then has to explain the same problem again weeks later, as if the first conversation never happened. Support systems forget. Customers don't. That frustration, seen over years on the support side, is what led me to this hackathon project. Most support systems and most AI chatbots treat every interaction as isolated. They don't remember. So patterns that should be obvious (repeated complaints, dropping usage, unresolved issues) never get connected until a customer just leaves. That became the seed for my project: the Retention Risk Agent. The Problem With "Forgetful" AI Most AI tools answer questions in the moment, then forget everything. Ask a chatbot about a customer's history, and it only knows what's in that single message, not what happened last week, last month, or across five different support tickets. For churn prediction, that's a fatal flaw. Churn isn't a single event. It's a pattern, a series of small signals that only make sense when viewed together over time. This is something I understand deeply from years of watching it happen firsthand. Cognee is an open-source memory layer for AI agents. Instead of treating each interaction as isolated, it builds a knowledge graph, connecting facts, relationships, and context across everything you feed it. That's exactly what churn detection needed. What I Built I created a Python script that: Ingests customer records (support tickets, usage patterns, plan changes) Uses Cognee to build a memory graph connecting these signals Asks a simple question: "Which customers show signs of churn risk, and why?" The result wasn't a keyword match; it was reasoning. The agent correctly flagged a customer whose usage dropped 80% and who'd ignored two check-in emails. It flagged another who'd complained twice about slow support and mentioned a competitor. And critica