标签：#dev

**🙄 فى كتاب chapter الصدمة دي هي بالظبط اللي حسيت بيها وأنا بقرأ أول “operating system: three easy Pieces “ ‘OSTEP’. 🖤اهلا بيكم ! يارب تكونوا بخير 💯 حابه اشارك معاكم رحلتى مع قراءة الكتاب ونستفيد منه سوا قبل ما نعرف هو !!!! ولا لا OS is virtual machine 🤔 !!!!دا يعنى ايه ووظيفته ايه OS تعالوا الاول نعرف ال موجودة فى الكمبيوتر ولا لا ؟؟؟؟ RAM وال CPUزى ال HARDWARE وهل هو قطعة ::هنبدأ من الاخر موجود على الكمبيوتر SW هو عبارة عن HW يسيدى مش قطعة OSال .على الجهازINSTALL ولازم يبقى ووظيفته ايه؟؟؟ OS طب يعنى ايه ‘OS’ اختصار “OPERATING SYSTEM”. .“يعنى نظام تشغيل “ .👁‍🗨👁‍🗨 تعالوا نعرف معنى ” نظام تشغيل” ونفسرها نظام تشغيل يعنى مسئول عن 1_ “HWالنظام “من غيره مش هيبقى فيه نظام خصوصا لقطع ال . يعنى بناخد منه الاذن للعمليات HW ببعضه وكمان بيدير ال HWيعنى هو بيربط ال 👏 . (Order)من الاخر بيخلق “النظام” 2_.”التشغيل “هو المسئول عن تشغيل البرامج Learn about Medium’s values هو اللي بيتحكم في دورة حياة البرنامج بالكامل؛هو اللي بيبدأ تشغيله في الذاكرة،OSيعني الـ وبيحدد هو محتاج إيه من إمكانيات الجهاز عشان يشتغل بكفاءة وبيفضل مراقبه ويحميه طول ما هوشغال ، ولحد ما تقفليه بنفسك 🌹 .ويقوم هو بتنظيف الذاكرة وتوفير المساحة لغيره 🧐::وظيفته بقا بيخلي البرنامج يشتغل بسهولة:1️⃣ لأنه بيخلق للبرنامج بيئة وهمية مريحة، وبيخفي عنه كل التعقيدات والأسلاك بتاعة الهاردوير عشان يشتغل بسلاسة 2️⃣: بيسمح للبرامج إنها تشارك الذاكرة بين كل البرامج بالعدل RAM بيشتغل كعسكري مرور بيوزع مساحة الـ . وبيحمي كل برنامج في مساحته الخاصة 3️⃣: بيمكن البرامج إنها تتعامل مع الأجهزة بيعمل كـ “وسيط” أو مترجم بيوصل كود البرنامج بالقطع الحقيقية (زي الشاشة أو الهارد) .عشان ينفذ أوامره فوراً بيعمل التلات حاجات دول إزاي في نفس الوقت وبمنتهى السلاسة؟ ؟؟؟OS طب الـ بيعملهم يسيدى عن طريق أكبر خدعة سحرية في عالم الكمبيوتروهي الـ Virtualization👌 كنت حابة جداً أكلمكم المرة دي عن خدعة الـ “Virtualization” 💎 😌👁👁اللي اتكلمنا عليها في العنوان، بس لقيت البوست هيبقى طويل أوي عليكم ✔🔥!!وعشان متعبكمش معايا.. هنخليها للبوست الجاي إن شاء الله 💯✅!!بيعمل الخدعة دي إزاي OSاستنوا البوست الجاى عشان نعرف الـ 💋.دمتم بخير **

A few weeks back I picked up google-gemini/gemini-cli issue #28090: the shell tool was forwarding a command's entire stdout/stderr straight into the model's context, with no cap unless you opted into an LLM-based summarization step. Run one noisy build command and you'd hand the model tens of thousands of tokens of log spam it never asked for. The fix sounded trivial: cap the output before it goes into llmContent . I had a one-liner in my head before I'd even opened the file. That one-liner is exactly the kind of "obviously correct" fix that ships bugs. The one-liner The naive version looks like this: const MAX = 32 * 1024 ; // 32 KiB function truncate ( output ) { if ( output . length <= MAX ) return output ; return output . slice ( 0 , MAX ) + ' \n ...[truncated]... \n ' + output . slice ( - MAX ); } It compiles. It passes a quick manual test with a big ASCII log file. It looks done. I almost committed it as-is before writing the actual test suite. The problem is what .slice() is slicing. JavaScript strings are sequences of UTF-16 code units, not bytes and not Unicode codepoints. Most characters in typical shell output (letters, digits, punctuation) are one code unit each, so .slice() looks safe in casual testing. But the moment real-world command output contains anything outside the Basic Multilingual Plane — an emoji in a commit message, certain box-drawing/progress-bar characters some CLIs use, non-Latin filenames — that character is represented as a surrogate pair : two 16-bit code units that only mean something together. Slice between them and you don't get an error. You get one dangling unpaired surrogate on each side of the cut, silently baked into the string that gets sent to the model. No exception. No lint warning. JSON.stringify on the payload can even throw later, in a completely unrelated part of the request pipeline, for a reason that has nothing to do with where the bug actually is. Or worse: it doesn't throw, and the model just receives a slightly

Most portfolios have a boring "About Me" paragraph. I replaced mine with something you can talk to — an AI terminal that answers questions about me, pulls my live GitHub activity, and remembers the conversation. You can try it right now on my portfolio: rehbarkhan.in . I'm Rehbar Khan , a Full Stack & Gen-AI developer, and in this post I'll break down exactly how it works — the RAG pipeline, the LangGraph agent, the memory layer, and how I wired in real GitHub data with MCP. No fluff, just the architecture. The problem I wanted a portfolio assistant that could: Answer questions about my background accurately — no hallucinated jobs or fake projects. Fetch live data (my latest GitHub activity), not a stale snapshot. Remember the conversation across messages. Stream responses token-by-token like a real terminal. That rules out "just prompt an LLM." You need retrieval for grounding, tools for live data, and state for memory. Here's the stack I landed on. Architecture at a glance Next.js 16 chat UI ──► FastAPI (streaming) ──► LangGraph agent ├── RAG retriever → pgvector (Neon Postgres) ├── GitHub MCP tool → live GitHub data └── Redis checkpointer → conversation memory Frontend: Next.js 16 (App Router, TypeScript) — a streaming terminal UI. Backend: FastAPI with streaming responses. Orchestration: LangGraph ( StateGraph , ToolNode , tools_condition ). LLM: OpenAI gpt-4o-mini . Retrieval: text-embedding-3-small → pgvector on Neon Postgres. Memory: Redis checkpointer for per-session history. Live data: GitHub via the Model Context Protocol (MCP) . 1. The RAG pipeline Everything the bot knows about me lives in a single reference.txt . I chunk it, embed it, and store it in Postgres with pgvector: from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_postgres import PGVector splitter = RecursiveCharacterTextSplitter ( chunk_size = 500 , chunk_overlap = 80 ) chunks = splitter . split_text ( open ( " refe

🚀 AI is becoming smarter every day. But intelligence alone isn't enough—it also needs a standardized way to communicate with tools, applications, and data. That's exactly what Model Context Protocol (MCP) provides. 🚀 Introduction The AI landscape has evolved rapidly over the past few years. We've moved from simple chatbots to: 🤖 AI coding assistants ⚙️ Autonomous agents ☁️ Cloud automation 📊 Infrastructure monitoring 🔄 Intelligent workflows But one major challenge still exists: How can AI securely communicate with external tools like GitHub, AWS, Docker, Kubernetes, Slack, databases, and local files? Until recently, every AI company built custom integrations. That meant: duplicated engineering effort inconsistent APIs difficult maintenance poor interoperability To solve this problem, the AI ecosystem is adopting a new open standard called Model Context Protocol (MCP). 🤔 What is Model Context Protocol (MCP)? Model Context Protocol (MCP) is an open protocol that standardizes how AI models communicate with external tools, APIs, databases, applications, and services. Instead of every AI assistant creating custom integrations for every service, MCP provides one common language. Think of MCP as: 🔌 USB-C for AI applications. Just as USB-C lets different devices communicate using one standard, MCP allows different AI assistants to connect to external systems in a consistent way. ❌ The Problem Before MCP Imagine you're building an AI DevOps assistant. It needs access to: GitHub Docker Kubernetes AWS Terraform Jenkins Prometheus Grafana Local Files Internal Documentation Without MCP, you'd need to: Learn every API separately Build authentication repeatedly Maintain multiple SDKs Handle different response formats Continuously update integrations Every AI application repeats the same engineering work. This approach is: ❌ Time-consuming ❌ Expensive ❌ Difficult to maintain ❌ Hard to scale ✅ How MCP Solves This Problem MCP introduces a standardized communication layer between AI m

Originally published at htpbe.tech . The version on htpbe.tech stays in sync with the latest detection algorithm — refer to it for the canonical text. A fraud reviewer opens a PDF bank statement. The first thing many manual checks look at is the document’s Producer field — the line of metadata that records which software last wrote the file. This one says Adobe PDF Library 23.1 . To a human, and to most lightweight metadata checks, that reads as reassuring: Adobe is professional software, the kind a bank’s back office or a law firm would use. The reviewer moves on. That is exactly the reaction the forger was counting on. The document was not produced by Adobe. It was edited in a free browser-based PDF editor, then passed through a step that overwrote the Producer string to say Adobe . The metadata now lies about the file’s own origin — and it lies in the most credibility-laundering direction available, because “Adobe” is the producer string people trust most. This is producer identity forgery, and it is one of the most common ways a tampered PDF tries to talk its way past a metadata-only review. This is a case study in how that attack works at a conceptual level, why a metadata-only check waves it through, and how a structural approach — the one behind the public marker HTPBE_PRODUCER_IDENTITY_FORGED — catches the contradiction the forger left behind. If you want to see the Producer string for yourself, the free PDF metadata viewer reads it — along with every other field — straight out of any PDF. Why the Producer field is the obvious thing to forge Every PDF carries internal records about how it was made. Two fields matter most to a reviewer: producer — the software that wrote the final bytes of the file. creator — the application the content originated in. Fraud-detection lore, repeated in countless “how to spot a fake bank statement” guides, says the same thing: a real institutional document is generated by an automated back-end system, so if the producer says Mi

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . There is a version of this story where I walk you through the technical challenges in a clean, detached voice. Structured. Professional. Composed. This is not that version. Seven months. A hundred pages of documentation written alongside the code, not after it. A live system serving rural clinics in Delta State, Nigeria. And three bugs so specific and so cruel that each one felt designed to find the exact gap between what I thought I knew and what I actually knew. The Delta Health Information and Appointment Booking System was my final year project at the University of Port Harcourt. That sentence makes it sound smaller than it was. This was a real system for real clinics, serving patients who travel for hours to reach a healthcare facility only to find the clinic is full, the doctor is not in, or nobody told them their appointment was cancelled. These are not hypothetical users. These are people whose access to healthcare depends on whether the software works. That is a different kind of pressure than getting a good grade. And it did not start at deployment. Before a single line of code was written, I had to pitch the entire concept to my university supervisor, the Head of Department, the Faculty Dean, and an external examiner. The system had to be defensible not just technically but practically. It had to demonstrate that it solved a real problem that real people in Delta State were actually facing. I was presenting to people with decades of experience who would ask questions I had not thought of yet. That kind of scrutiny either sharpens you or breaks you. I chose to let it sharpen me. The stack was React.js, Node.js, PHP with Laravel, MySQL, AWS, and Docker. Communication channels included SMS gateways, WhatsApp Business API, and USSD because not every patient in rural Delta State has a smartphone. The system had to run on 2G connections, on entry-level Android phones with 2GB RAM

When you develop a game at the beginning of your journey, you quickly notice that the environment is very static. To change that, let’s create some oscillations and move our platforms. We will use methods like Vector3.Lerp and Mathf.PingPong . using UnityEngine ; public class Oscillate : MonoBehaviour { [ SerializeField ] private Vector3 movementVector ; [ SerializeField ] private float speed ; private Vector3 _startPosition ; private Vector3 _endPosition ; private float _movementFactor ; private void Start () { _startPosition = transform . position ; _endPosition = transform . position + movementVector ; } private void Update () { _movementFactor = Mathf . PingPong ( Time . time * speed , 1f ); transform . position = Vector3 . Lerp ( _startPosition , _endPosition , _movementFactor ); } } First, we add movementVector and speed to inspector. movementVector receives the direction, and we tell it how far object must move. speed defines how fast objects move _ startPosition simply gets the starting coordinates in Start() with transform.position , and _ endPosition is the sum of the _ startPosition and movementVector . Now _ movementFactor is different. It defines the progress of the movement. Imagine it as a loading bar from 1% to 100%. In Update() method, we constantly calculate it every frame using Mathf.PingPong _movementFactor = Mathf.PingPong(Time.time * speed, 1f); So what is going on here, Mathf.PingPong does what you would imagine. Value goes back and forth. 1f is our length, so in Update() every frame _ movementFactor is getting updated from 0.0, 0.1, 0.2… up to 1.0, when the value is 1.0, it goes back to 0.0 in the same way. And since it’s in Update() this is an endless cycle. transform.position = Vector3.Lerp(_startPosition, _endPosition, _movementFactor); Now this is where magic happens. Lerp (Linear Interpolation) takes start position, end position and a “loading” bar. Why we did exactly 1f in PingPong is perfectly described in the official documentation: a

Over the past few months I’ve been building Radar, an open-source media intelligence and social listening platform that anyone can self-host. The project started with a simple observation: most media monitoring platforms are incredibly powerful—but they’re also expensive, closed, and often lock users into proprietary AI services. I wanted to explore a different approach. What is Radar? Radar is a self-hostable platform for monitoring news and public media sources using AI. Instead of relying on proprietary datasets, it works with free public RSS and Atom feeds, allowing anyone to build their own monitoring environment. One of the core design decisions is that Radar is AI-agnostic. Rather than forcing a single provider, you can choose between: Anthropic Claude OpenAI Grok Current Features 📰 News aggregation from free RSS and Atom feeds 🤖 AI-powered summaries 😊 Sentiment analysis 🔍 Keyword and topic monitoring 📊 Searchable dashboard 🏠 Self-hosted deployment 🔓 Fully open source Why Build Another Media Intelligence Tool? Enterprise platforms such as Talkwalker and Brandwatch are excellent products, but they aren’t accessible to everyone. Radar is aimed at: developers startups journalists researchers agencies open-source enthusiasts The goal isn’t to replicate every enterprise feature, but to build a transparent, extensible, and self-hosted alternative that anyone can inspect, modify, and improve. Looking for Feedback The project is still under active development, and I’d really appreciate feedback on: architecture user experience deployment scalability AI abstraction features that would make the platform more useful If you’re interested in open-source AI, media monitoring, or self-hosted software, I’d love to hear your thoughts. GitHub Demo Contributions, suggestions, feature requests, and bug reports are all welcome.

🚀 400 Downloads. $0 Spent. Here's the Exact Breakdown. TL;DR — No ads, no PR agency, no paid promotion. Just specific, honest, cross-platform posting, one external "100% Clean" certification, and a refusal to oversell. Here's exactly what moved the needle, in order of impact. Akhouri Systems started with nothing — no audience, no mailing list, no existing following. Just a GitHub account, a Windows security suite called ATLOCK, and enough confidence in the product to put it in front of strangers. Here's what actually happened. 📊 The Starting Point Day 1Audience0Ad budget $0 Team1 (me)Funding ₹0Product ATLOCK — a Windows security suite, single .exe, offline-first 🎯 What Actually Moved the Needle 1️⃣ Specificity beats enthusiasm, every time Every post that worked wasn't "check out my app" — it was a verifiable technical claim: NTFS ACL-level file locking that even admin can't bypass. AES + PBKDF2 vault encryption, 200,000 iterations. Developers can smell vague marketing copy from a mile away. Real numbers and real mechanisms are the entire trick. 2️⃣ Same product, three different posts The same copy-pasted paragraph across every platform reads as spam — even when it's not. So: Platform Angle dev.to Technical breakdown, deep detail Peerlist Short, personal, punchy LinkedIn Credibility-first, professional tone 3️⃣ Admitting weaknesses on purpose One of the highest-engagement posts I wrote was a direct ATLOCK vs. commercial security software comparison — including an honest section on where commercial tools still win (malware detection, official support, code-signing). Nobody trusts a post that claims to be perfect. Naming the weaknesses bought more credibility than it cost. 4️⃣ Independent validation compounds differently Getting listed on Softpedia mattered more than expected — not for raw traffic, but because a "100% Clean" certification and an independent 3.5/5 review from a party with zero stake in the outcome hits differently than another self-posted announcement.

By the end of this article, you'll know: what Kimi K3 actually is, the architecture, the scale, and what changed from the K2 family how to run it today, free in the browser, through the API, or wired into Claude Code, Cursor, Cline, and RooCode which exact model ID and settings unlock the full 1 million token context how K3 stacks up on price and benchmarks against DeepSeek V4, Qwen3.7 Max, GLM-5.2, and its own sibling K2.7 Code whether switching today makes sense, or whether you should wait Kimi K3 just dropped, and Moonshot means business Moonshot AI released Kimi K3 on July 16, 2026, timed just ahead of the World Artificial Intelligence Conference in Shanghai. The Beijing lab, backed by Alibaba, has spent the past 18 months watching DeepSeek erode its market position. K3 is the comeback attempt, and the early numbers back it up. The headline result: K3 debuted at number one on Arena.ai's Frontend Code Arena with a score of 1,679, ahead of Claude Fable 5 at 1,631 and GPT-5.6 Sol at 1,618. Its predecessor, K2.6, sat 18th on that same board. That's a 17 spot jump in one release, and it's independently measured, not a number Moonshot invented itself. This isn't Moonshot's first time in Western production stacks either. Cursor built its Composer 2 model starting from a Kimi K2.5 base. DoorDash's CTO has said the company routes lower level work to Kimi K2.6. Thinking Machines used K2.5 to help generate early post-training data for Inkling, its own model released just a day before K3. So when a new Kimi flagship lands, it lands somewhere developers already have skin in the game. For developers, the practical story matters more than the leaderboard. K3 is open weight, speaks the OpenAI SDK, and drops into tools you already use. It's also, for the first time in Kimi's history, priced like a frontier model instead of a budget one. That changes the calculus on when it's actually worth reaching for. What Kimi K3 actually is K3 is a sparse Mixture-of-Experts model with 2.8 tr

AI coding agents have dramatically shortened the distance between an idea and working software. They can inspect a project, create files, run commands, write tests, and help diagnose failures. What they have not eliminated is judgment. A polished screen is not proof that data survives a reload. A passing unit test is not proof that keyboard users can complete the core task. A successful deployment is not proof that the intended commit reached production. This is why I use proof gates : observable conditions that must be satisfied before a product claim becomes stronger. A proof gate is not a meeting, a long document, or an excuse to slow down. It is a compact question: What evidence would let another person verify that this claim is true? Here are five gates that separate a persuasive AI demo from a small MVP you can responsibly ship. Gate 1: Prove One Valuable User Loop AI makes feature generation cheap, which makes uncontrolled scope especially dangerous. Before requesting code, define one primary user in one specific situation. Then describe: Their observable before-state The smallest useful action they can take The immediate result The reason they might return This becomes the product’s core loop. For example, “build a productivity platform” is too broad. A more testable loop might be: A freelancer remembers a useful client outcome. They record the outcome and supporting evidence. The record appears in a searchable library. They can retrieve it later for a proposal or review. The gate is not passed because a form exists. It is passed when a new user can complete the entire loop and explain what changed without coaching. Write a Not Today list alongside the required capabilities. Authentication, dashboards, collaboration, billing, and AI-generated summaries may all be reasonable later. They should not compete with proof of the first useful loop. The goal is not the fewest possible features. It is the smallest complete behavior that tests whether the product creat

AWS has recently introduced CloudFormation express mode, a deployment option that can reduce infrastructure deployment times by marking stack operations complete once resource configuration is applied, rather than waiting for full resource stabilization. By Renato Losio

TL;DR In December 2025, Cline — an AI coding assistant with over 5 million users — gave an AI agent (Claude) write access to triage GitHub issues, including permission to run shell commands. A misconfigured trigger condition let any GitHub user invoke the workflow. What followed was a four-hop supply chain compromise that ended with a malicious npm package silently installing a second AI agent on user machines. I broke down the full chain in video form: Watch the episode Below is the chain, hop by hop. Hop 0: The setup The triage automation was configured with broad tool permissions and a trigger condition open to any GitHub user — not just contributors. That second part is the root cause: it opened the trigger to unauthenticated input. (Exact config values are in the Confirmed Artifacts section below.) Hop 1: Prompt injection via issue title The issue title itself was never sanitized before reaching the model. No first-party source has published the exact injected payload verbatim — GHSA doesn't disclose it — so any reconstruction here is illustrative, not confirmed. What's confirmed is the mechanism: an untrusted string reached the model with tool access already granted. Hop 2: Cache poisoning The injected instruction deployed a tool (multiple independent postmortems — Snyk, Cloud Security Alliance — name it "Cacheract") that flooded the CI cache with over 10GB of junk data, evicting legitimate entries through standard LRU eviction. Hop 3: Nightly workflow inherits the poisoned cache The nightly release workflow restored that poisoned cache around 2 AM UTC and ran inside it — handing over three publish tokens. (Names confirmed across GHSA and multiple independent sources — see below.) Hop 4: Publication cline@2.3.0 went live on npm with a postinstall script that silently installed a second package globally — an AI agent, installed by an AI agent, with no user consent. This line is a direct quote from Cline's own security advisory, not a reconstruction. It's the st

Before I critique modern web development, I want to make some points: I'm not discouraging anybody from web development. This is only my opinion and my experience of the story. Everyone has their own story. Part 1. Javascript JavaScript is known for being the web's language. It's used everywhere in the web, and can also be used to make external applications outside of web development. JavaScript has many flaws in its language, such as its comparison logic. JavaScript uses the "strict equality operator" that tries to solve its weird type coercions (e.g [] == ![] being true). Another flaw is that JavaScript has poor maintainability. JavaScript has a poorly managed type system that introduces errors without proper error handling. You cannot explicitly define what error you're trying to catch in the try-catch statement. try { functionThatThrowsError () } catch ( error ) { console . error ( error ); if ( error instanceof MyError ) { doSomething (); } } instead of modern languages: try { functionThatThrowsError () } catch ( e : MyError ) { print ! ( " error: ${e.message} " ) } This adds complexity to try-catch statements and makes it almost impossible to handle errors in a robust manner. Another issue with JavaScript's maintainability is the wording of the language. JavaScript has two keywords called undefined and null . In practice these should mean the same thing but it doesn't. An undefined variable is an uninitialized variable, or a function that doesn't return anything. Undefined: // Returns undefined function getName () {} // syntactically correct in JavaScript // but will cause undefined console . log ( getName ()); const myCoolObject = {}; console . log ( myCoolObject . property ); // still syntactically correct in JavaScript even though the property doesn't exist. Null: // Returns a null name function getName () { return null ; } // output: null console . log ( getName ()); const myCoolObject = { property : null }; console . log ( myCoolObject . property ); //out

Every team doc tool these days is "searchable." Notion, Confluence, wikis — you can find any page in seconds. But search only tells you a document exists; it doesn't tell you how it connects to the five other docs that explain why it looks the way it does. New hires still end up pinging three people on Slack to reconstruct the reasoning behind a decision that's technically "documented" somewhere. This post is about the difference between a searchable knowledge base and a connected one — and why most teams have the first but assume they have the second.

Every team builds APIs. Few build ones that survive their second rewrite. After inheriting three different REST APIs in as many years — one with endpoints named /getAllUsers , another that returned { "status": "ok" } for both success and 500 errors — I started keeping a list of the practices that actually distinguish robust APIs from ones that generate PagerDuty alerts at 3 AM. This guide distills six rules I've validated across production services handling tens of millions of requests. None are theoretical. All come with working code. 1. Resource-Oriented Naming — Not Action-Oriented The single biggest smell in a REST API is action verbs in URLs: # Bad — these are RPC, not REST GET /api/getUser?id=42 POST /api/createUser POST /api/deleteUser/42 POST /api/activateUserSubscription Resources are nouns, not verbs. The HTTP method is the verb: # Good GET /api/users/42 POST /api/users DELETE /api/users/42 POST /api/users/42/subscriptions # nested resource DELETE /api/users/42/subscriptions/active Key conventions that have held across every production API I've consulted on: Plural nouns : /users , not /user . Consistency with list endpoints ( GET /users = a list) makes singular feel like a bug. Kebab-case for multi-word resources : /order-items , not /orderItems or /order_items . It's URL-safe and matches what browsers expect. Nest at most two levels : /users/42/orders/7 is fine. /users/42/orders/7/items/3/addresses/9 is a cry for help. At that point, use a query parameter: /items?order_id=7 . Use query params for filtering, not path segments : /users?status=active&role=admin , not /users/active/admins . 2. Consistent Error Responses — The Contract People Actually Rely On Most API errors are parsable only by humans staring at a screen. That's a bug. Every error response should follow the same schema so clients can handle them programmatically: { "error": { "code": "USER_NOT_FOUND", "message": "User with id 42 was not found.", "details": { "resource": "users", "identifier"

I spent three months and about $500 on GPU rental trying to host my own LLM. I had a spare RTX 3090, I was deep in the open-source hype, and I was convinced that running my own model was the only way to get privacy, control, and—let’s be honest—bragging rights. I ended up switching to an API that costs me less than a dollar per month for my use case. Here’s what I learned, and why I think most developers should stop self-hosting AI models. The Siren Song of Self-Hosting The argument for self-hosting sounds great: Privacy : Your data never leaves your machine. Control : You can fine-tune, tweak, or swap models whenever you want. No vendor lock-in : You’re not at the mercy of OpenAI or Google changing their pricing or policies. Open source ethos : It’s the “right” way to do things. I bought into all of it. I set up Ollama, downloaded Llama 2 7B, then 13B, then Mixtral 8x7B. I spent weekends wrestling with Docker, CUDA versions, and VRAM limits. I felt like a real engineer. But the reality was different. The Hidden Costs My $500 was just the start. I rented cloud GPUs because my 3090 wasn’t enough for the models I wanted. A single A100 on AWS costs about $3.50 per hour. For a model like Llama 2 70B, you need at least 48GB VRAM, which means a multi-GPU setup or a high-end instance. Here’s a quick breakdown of what I actually spent over three months: Item Cost GPU rental (spot instances) ~$350 Storage for model weights ~$30 Time debugging (conservative) 40 hours Power/electricity (home GPU) ~$40 Total ~$420+ And I never got it running reliably. The 70B model would crash after a few hours. The 13B model was decent but slow—about 10 tokens per second on my 3090. For a chat app, that’s painful. Compare that to an API call: import openai client = openai . OpenAI ( api_key = " sk-... " , base_url = " https://api.tai.shadie-oneapi.com/v1 " ) response = client . chat . completions . create ( model = " gpt-4o-mini " , messages = [{ " role " : " user " , " content " : " What ' s

What if you could take an existing class and say "I want everything this already does, plus a few...

When I started working on a WooCommerce slider plugin, I noticed that many existing solutions were packed with features that a lot of websites simply don’t need. More features often mean more CSS, more JavaScript, and a bigger impact on performance. So I asked myself a simple question: What would a WooCommerce slider look like if performance came first? My goals Instead of creating another all-in-one slider plugin, I focused on a few principles: Lightweight codebase Fast loading times Responsive by default Easy integration with Gutenberg Elementor support Shortcode support Clean and maintainable architecture Performance matters Every additional request and every unnecessary asset affects page speed. Some optimizations I implemented include: Assets are loaded only when required. Local libraries instead of unnecessary external requests. Server-side rendering where appropriate. Clean HTML output. Developer experience I also wanted the plugin to be simple for users. Instead of a complicated interface, the goal was: Install Create a slider Insert it into a page Done Lessons learned Building a public WordPress plugin taught me a lot: Documentation is almost as important as the code. User feedback quickly reveals edge cases you never considered. Keeping the codebase simple often leads to better long-term maintainability. What’s next? I’m continuing to improve the plugin by adding new features while keeping performance as the top priority. I’d also love to hear how other developers approach WordPress plugin development and performance optimization. Thanks for reading! ⸻ If you’re interested, you can check out my project here: WordPress.org: https://wordpress.org/plugins/amitry-product-category-slider/ GitHub: https://github.com/amitry-de/amitry-product-category-slider Live Demo: https://slider.amitry.de/

The evals for my agent skills scored 0% for as long as I had records. Not low. Not noisy. Exactly zero, every skill, every run. And I believed it. For months I thought my skills were bad, because the number said so and the number never wavered. Then one night I actually read the harness. It had fallen back to the wrong auth token. Every call it made came back 401, and it quietly graded each one a failure. The skills never got a chance to fail on their own. I was not measuring them at all. I was reading a broken thermometer. Real weakness is jagged Here is what took me too long to see. When a system is genuinely bad, it scores 40% one week and 60% the next. It passes the easy cases and trips over the hard ones. It has good days. Incompetence has texture, because an incompetent system is still in contact with the world, and the world varies. A flat number has no texture. A flat number means the measurement stopped touching the thing being measured somewhere upstream, and what you are reading is the instrument's resting state. Doctors know this. A heart monitor drawing a perfectly straight line does not mean the patient is calm. Only a broken thermometer writes the same number every time. Key insight: A performance number with no variance is a reading of the instrument, not of the thing being measured. The same bug in three industries I run systems in advertising, in healthcare billing, and in agent operations, and the same shape shows up in all of them. In advertising I found a dashboard figure that had been hardcoded for two years. Nobody questioned it, because it looked right, and it looked right because it never moved. In agent operations, an account-rotation bug in one of my pipelines overwrote every real error with the same generic message, "no active accounts," so for a while every distinct failure in that system looked identical. And in the denial-assessment engine I run for a medical-billing operation, an agreement metric came back at 44.7%, alarmingly low, un