标签：#tutorial

In the field guide I covered what an AGENTS.md is and what belongs in it. This is the hands-on follow-up: we'll build a complete AGENTS.md for a real project, one section at a time, then point an AI coding agent at it and watch the difference it makes. By the end you'll have a working file — and you'll have seen it pay off. New to AGENTS.md? It's a single Markdown file at the root of your repo that tells AI coding agents how to work in it — build steps, tests, conventions, guardrails. The "why" behind each section is in the field guide . The project we'll use We'll write the AGENTS.md for a small but real service: a URL shortener API in Python — FastAPI, SQLite, pytest. A couple of endpoints, a thin data layer, a test suite. Follow along with this, or swap in your own repo — the steps are identical. Its shape: linkshort/ app/ main.py # FastAPI routes db.py # SQLite access models.py # Pydantic models migrations/ # generated SQL — not hand-edited tests/ requirements.txt Step 0 — Start with an empty file At the repo root: touch AGENTS.md That's the whole step. We'll fill it in one section at a time, building toward a file an agent can read in thirty seconds. Step 1 — Orientation: one line Tell the agent what it's looking at. Add: # AGENTS.md A URL shortener API in Python — FastAPI, SQLite, pytest. One sentence sets the agent's priors: it knows the language, framework, and storage before it reads a single line of code. Step 2 — Setup and run The agent can't help if it can't start the project. Add the real, copy-pasteable commands: ## Setup python -m venv .venv && source .venv/bin/activate pip install -r requirements.txt ## Run uvicorn app.main:app --reload # http://localhost:8000 Use the commands that actually work in your repo — no placeholders. Step 3 — Tests: the agent's feedback loop This is the most important section, because tests are how the agent checks its own work. Add: ## Test — all must pass before a change is done pytest ruff check . mypy app Now the agent

How we integrated real-time phrase translation feedback into our AI-powered book translation workflow, and what we learned about latency, context, and prompt engineering. When we launched LectuLibre, our AI-powered book translation platform, users loved the quality of full-chapter translations. But they kept asking for something else: while reading a partially translated book, they'd stumble on an untranslated phrase or an awkward auto-translation and want to quickly get a better version without leaving the page. So we built 即时翻译求助 (Instant Translation Help)—a feature that lets readers highlight any phrase and get a context-aware, human-quality translation within seconds, along with a brief explanation of tricky parts. Here's how we built it, the technical challenges we faced, and the lessons we learned about stitching LLMs into a real-time reading experience. Problem: Real-time, Context-Aware Translation Inside a Book Most web apps offer generic translation via API calls—send a sentence to Google Translate, get a result. But that doesn't work for literary texts. A phrase like "She let the cat out of the bag" needs to be translated idiomatically, and the appropriate rendering depends heavily on the surrounding paragraphs (is the tone formal? sarcastic? part of a metaphor chain?). Our existing translation pipeline processes entire chapters in bulk with carefully crafted prompts, but for instant help, we needed sub-second latency while preserving that same depth of context. Our Approach: Server‑Sent Events and a Smart Prompt Buffer We chose Server-Sent Events (SSE) over WebSockets because the communication is one-directional (server pushes translation tokens) and SSE is simpler to implement with FastAPI. The client (a React app) sends a POST request with: The phrase to translate The book ID and the exact location (chapter/paragraph index) The target language Our backend retrieves the surrounding text from PostgreSQL (we store the original book in chunks), feeds a care

If you've ever wanted an AI that doesn't just chat but actually does things — queries databases, calls APIs, makes decisions, and learns from results — you're in the right place. In this tutorial, I'll show you how to build production-ready AI agents using Solon 4.0's ReActAgent . By the end, you'll have built an agent that can reason through complex problems, use external tools, and adapt its behavior based on real-world feedback. What Makes ReActAgent Different? Traditional LLMs are great at generating text, but they hit a wall when they need to interact with the real world — checking a database, fetching live data, or performing calculations. ReActAgent (Reason + Act) breaks through that wall. It implements a cognitive loop: Thought → Action → Observation → (repeat or finish) The agent thinks about what to do next, acts by calling a tool, observes the result, and decides whether to continue or deliver the final answer. This isn't just theory. Solon's ReActAgent has been used in production for automated customer support, intelligent data analysis, and multi-step workflow automation. 1. Adding the Dependency First, add the solon-ai-agent module to your project: <dependency> <groupId> org.noear </groupId> <artifactId> solon-ai-agent </artifactId> </dependency> Note : If you're using Solon's parent POM, the version is managed automatically. Otherwise, use the latest Solon version. 2. Building a ChatModel (The Agent's Brain) Every agent needs a "brain" — a ChatModel that powers reasoning. Let's build one using the fluent API: import org.noear.solon.ai.chat.ChatModel ; ChatModel chatModel = ChatModel . of ( "https://api.moark.com/v1/chat/completions" ) . apiKey ( "your-api-key-here" ) . model ( "Qwen3-32B" ) . build (); You can also configure it via YAML and inject it: solon.ai.chat : demo : apiUrl : " http://127.0.0.1:11434/api/chat" provider : " ollama" model : " llama3.2" @Inject ( "${solon.ai.chat.demo}" ) ChatConfig chatConfig ; ChatModel chatModel = ChatModel . o

📖 Article original : GitHub Gist Un guide technique par Mohamed ben mallessa Le problème Recevoir un dossier de 500 fichiers HEIC à convertir en WebP pour un site web est une situation courante pour tout développeur. Les solutions traditionnelles ont leurs limites : ImageMagick nécessite des codecs spécifiques, les convertisseurs en ligne sont limités en taille, et le traitement manuel est exclu à cette échelle. La solution Photopea (Photoshop gratuit dans le navigateur) supporte nativement tous les formats d'image courants. En l'utilisant comme moteur de conversion piloté par script, on obtient un pipeline batch rapide et fiable. Formats supportés Entrée Sorties possibles HEIC / HEIF JPG, PNG, WebP JPEG WebP, PNG, PSD PNG JPG, WebP WebP PNG, JPG PSD PNG, JPG, WebP SVG PNG, JPG TIFF PNG, JPG, WebP Pipeline Dossier source (500 HEIC) → Photopea → Dossier sortie (500 WebP) Le script préserve la structure des sous-dossiers, applique le redimensionnement et la qualité configurés, et livre les fichiers organisés. Paramètres typiques --format webp # Format de sortie --quality 80 # Qualité (1-100) --resize 1920 # Redimensionnement (côté long) --output ./web/ # Dossier de destination Avantages Un seul outil pour tous les formats d'entrée Aucun codec à installer (Photopea gère tout nativement) Gratuit et sans abonnement Local — les fichiers ne quittent pas votre machine Structure préservée — l'arborescence est conservée Mohamed ben mallessa — Full-stack developer & solutions B2B 🔗 GitHub · LinkedIn opensource #webp #python #tutorial 💻 Vous avez un projet technique ? Développement full-stack, automatisation IA, solutions B2B sur mesure. 🔗 GitHub 💼 LinkedIn 🎨 Behance Article initialement publié sur GitHub Gist

If you've ever tried integrating a large language model (LLM) into a Java application, you've probably written a lot of boilerplate: HTTP clients, JSON parsing, streaming handling, session management. Solon 4.0's ChatModel abstracts all of that away with a clean, builder-oriented API. In this guide, I'll walk through building real, working AI features using ChatModel — from a simple chat call to a streaming chatbot with conversation memory. 1. What Is ChatModel? ChatModel (package org.noear.solon.ai.chat ) is a unified LLM client in Solon's AI ecosystem. Instead of writing raw HTTP calls for different model providers, you use a single API that supports: Synchronous calls — one-shot request, full response Streaming calls — reactive streaming via Project Reactor ( Flux<ChatResponse> ) Tool/Function Calling — let the LLM invoke your Java methods Chat Sessions — automatic conversation memory Multi-modal messages — text, images, audio Dialect adaptation — works with OpenAI, Ollama, Anthropic, Gemini, DashScope, and more The best part? It uses a dialect pattern — you point it at any compatible LLM endpoint, and it adapts automatically. 2. Setting Up Add the dependency to your pom.xml (no parent POM needed — Solon works standalone): <dependency> <groupId> org.noear </groupId> <artifactId> solon-ai </artifactId> <version> ${solon.version} </version> </dependency> This pulls in all built-in dialects (OpenAI, Ollama, Gemini, Anthropic, DashScope). 3. Configuration 3.1 Via YAML (Recommended) solon.ai.chat : demo : apiUrl : " http://127.0.0.1:11434/api/chat" # Full URL, not baseUrl provider : " ollama" # Dialect identifier model : " llama3.2" # Model name headers : x-demo : " demo1" Then create a @Bean to get a ready-to-use ChatModel : import org.noear.solon.ai.chat.ChatConfig ; import org.noear.solon.ai.chat.ChatModel ; import org.noear.solon.annotation.Bean ; import org.noear.solon.annotation.Configuration ; import org.noear.solon.annotation.Inject ; @Configuration public cla

The current Claude models give you an effort knob with five settings: low , medium , high , xhigh , max . The docs tell you what each is for. I wanted numbers, so I ran the same three real tasks across all five levels and measured tokens, latency, and quality. The results changed how I set effort, and one of them surprised me. Here is the data and what I do with it now. What effort controls Effort is not just "how much the model thinks." It controls overall token spend: how much it thinks and how it acts. Lower effort means fewer, more consolidated tool calls, less preamble, terser output. Higher effort means more exploration before answering. The default is high if you omit it. const response = await client . messages . create ({ model : " claude-opus-4-8 " , max_tokens : 16000 , thinking : { type : " adaptive " }, output_config : { effort : " medium " }, // the knob messages , }); The three tasks I picked tasks that span the range of what I actually do: Classification : label a contract finding as low/medium/high/critical. Short, scoped. Code generation : write a TypeScript function with edge-case handling. Medium difficulty. Multi-step audit : analyze a 200-line contract for vulnerabilities across functions. Hard, agentic. I ran each at all five effort levels, three times, and averaged. I scored quality against a known-correct answer for tasks 1 and 3, and by manual review for task 2. The results Task 1, classification. Quality was flat across every effort level. The right label is the right label, and the model nailed it at low just as well as at max . But token usage climbed steeply: max used roughly 8x the tokens of low for an identical answer. Latency tracked tokens. The lesson: for genuinely simple, scoped tasks, high effort is pure waste. I set classification to low . Task 2, code generation. Quality improved from low to high , then plateaued. At low the model sometimes skipped an edge case. At high it caught them. xhigh and max produced essentially the sam

Terminal-based AI agents have evolved considerably over the past few months, and several changes are significant enough that developers relying on these tools should be aware of them. Most notably, Google has begun retiring Gemini CLI for individual users in favor of Antigravity CLI — a closed-source successor that has drawn some pushback from the community that built out Gemini CLI's open-source ecosystem. Meanwhile, Claude Code has moved to the Opus 4.8 and Fable 5 models with a 1M-token context window, and OpenClaw, the open-source "always-on" agent, has grown into one of the most-starred projects on GitHub — alongside a documented CVE worth knowing about before deployment. I've just published an updated, fact-checked comparison covering: What actually changed with Gemini CLI's retirement, and what it means if you have scripts or CI/CD pipelines depending on it Claude Code's current model lineup, context window, and new Dynamic Workflows feature OpenClaw's architecture, extensibility via ClawHub, and the security considerations that come with deep system access A full feature-comparison table (cost, context window, open-source status, setup complexity) A practical case study walking through how all three tools can work together on a real project Would be curious to hear which of these you're using day-to-day, and whether the Gemini → Antigravity transition has affected your workflow. Full article here: Devlycan - Technology & Programming Insights Devlycan - Technology, programming, AI, lifestyle, and future trends—simple insights for the new digital generation. devlycan.com

I Spent 30 Days Comparing Startup and Enterprise AI APIs Look, I'm just a dude building a SaaS side project. Not enterprise, not Fortune 500, just me and a few friends trying to ship something useful. So when I started hitting AI API walls, I went down the rabbit hole of figuring out what the heck to do. And honestly? Most guides out there are written by people who clearly have never had to choose between buying groceries or paying for OpenAI credits. They're either too corporate ("here's our enterprise procurement guide!") or too naive ("just use the cheapest API!"). So I figured I'd write the guide I WISH existed when I started. And I'm gonna throw in some enterprise stuff too because I consulted for a bigger company last year and saw what THEY deal with. Different worlds, I tell ya. Let me break this down properly. Why I Almost Just Used DeepSeek Directly Okay so here's the thing. When I first started, I was like "DeepSeek is dirt cheap, let me just sign up there and call it a day." I mean, the pricing was wild. Like cents per million tokens. How could I lose? Then I tried to actually sign up. Chinese phone number required. WeChat Pay or Alipay only. No PayPal. No Visa. Nothing. And I get it, that's their home market, but for me sitting here in my apartment in the US? Absolute dead end. So I started looking at aggregators. Tried like four of them. Some had weird pricing. Some had models that didn't actually work. One of them straight up charged me for tokens I never used (still salty about that). Then I landed on Global API and honestly I gotta say, it just worked. Email signup, PayPal, and I could test DeepSeek AND Claude AND Qwen all with one key. That's when I realised going direct to providers is kind of a trap if you're small. Let me show you the actual problem with going direct. The "Go Direct" Trap Here's what happens when you sign up direct with various providers: Problem What Happens to You Locked to one vendor Your whole app depends on their uptime Paym

This tutorial was written by Néstor Daza . This is the second article in a series about building Claudius , my own Claude-based chatbot ( Github ). The prologue made the case for building it, and for choosing MongoDB as its foundation. Open the conversations collection in Claudius’ database and you find the usual fields of a thread header but nothing else: a userId , a title , some timestamps , and so on, but no array of messages, no messages collection sitting beside it either! The text of every conversation lives somewhere else entirely, in the LangGraph checkpointer, which I wire up later in this series. This absence is a modeling decision, and how I came up with the database schema for my chatbot is the theme of this article. If you come from a relational background, you're used to modeling the data first when designing a database. For a project like this, you would start by finding the entities and normalizing them, and the final schema would come out of the data's structure: a conversations table and a messages table with a foreign key between them, because that is what the data looks like. Document modeling runs the other way. You start from how the application reads and writes, and the shape of the document follows the access patterns. Claudius never reads conversation messages without the agent's full working state wrapped around them, and that state is persisted using the LangGraph checkpointer. A separate messages table would add nothing, since the app would always have to join it back to that state on every read. The access pattern says the messages belong with the agent state, so that is where they go, and conversations are left as the lightweight header the list view actually needs. That inversion, modeling around use rather than around the data, runs through everything below. Schema-flexible is not schemaless This is the misconception lots of people often carry, and it is worth killing on the way in. A document database does not mean no schema; it mea

Build a Real-Time Crypto Trading Dashboard with Python, WebSockets, and React Real-time data is the difference between catching a move and reading about it later. This tutorial walks through a minimal but complete stack: a Python WebSocket client pulling live prices, a simple signal generator, and a React frontend displaying everything. You will end up with a dashboard that shows live Binance prices, basic momentum signals, and auto-updates without polling. Why this stack Binance provides a clean WebSocket API for tickers and trades. Python handles the backend connection and lightweight analysis. React keeps the UI reactive and simple to extend. No heavy frameworks, no paid data feeds. Prerequisites Python 3.11+ Node 20+ A Binance API key (read-only is fine for prices) Step 1: Python price stream Install the client library: pip install python-binance pandas Create price_stream.py : import asyncio import json from binance import AsyncClient , BinanceSocketManager import pandas as pd from datetime import datetime async def main (): client = await AsyncClient . create () bm = BinanceSocketManager ( client ) ts = bm . trade_socket ( ' BTCUSDT ' ) async with ts as tscm : while True : res = await tscm . recv () price = float ( res [ ' p ' ]) qty = float ( res [ ' q ' ]) ts = datetime . fromtimestamp ( res [ ' T ' ] / 1000 ) print ( f " { ts } | BTCUSDT { price : . 2 f } | { qty : . 4 f } BTC " ) if __name__ == " __main__ " : asyncio . run ( main ()) Run it: python price_stream.py You should see a live feed of trades. Keep this running as your data source. Step 2: Add a simple momentum signal Extend the script to calculate a 20-trade rolling average and flag when price deviates more than 0.3%: # inside the loop, after parsing res prices . append ( price ) if len ( prices ) > 20 : prices . pop ( 0 ) avg = sum ( prices ) / len ( prices ) deviation = ( price - avg ) / avg * 100 if abs ( deviation ) > 0.3 : print ( f " ⚡ Signal: { deviation : + . 2 f } % from 20-trade avg " )

Every blog post needs an OG image. Without one, your links look blank on Twitter, LinkedIn, and Slack — just a plain URL that nobody clicks. Most developers solve this by spinning up a headless browser, loading an HTML template, taking a screenshot, and uploading it somewhere. It works, but now you're maintaining a Puppeteer instance, dealing with font rendering quirks, and burning server resources on something that should be simple. There's a faster approach: design your OG images as HTML templates and let a screenshot API handle the rendering. The Idea: HTML Templates as OG Images Think of your OG image as a tiny webpage. You already know HTML and CSS. Build a 1200×630 template with your blog title, author name, maybe a gradient background — whatever fits your brand. Host it or pass it as raw HTML. Then call an API to screenshot it. Done. A basic template might look like this: <div style= "width:1200px;height:630px;display:flex;align-items:center; justify-content:center;background:linear-gradient(135deg,#1a1a2e,#16213e); font-family:Inter,sans-serif;padding:60px" > <div style= "color:#fff;text-align:center" > <h1 style= "font-size:48px;margin:0" > {{title}} </h1> <p style= "font-size:24px;color:#8892b0;margin-top:20px" > {{author}} · {{date}} </p> </div> </div> Replace the placeholders on your server, then send the resulting HTML (or a URL pointing to it) to the API. Calling the API With ScreenshotRun , a single curl request captures the rendered template as a PNG: curl -X POST "https://api.screenshotrun.com/v1/screenshot" \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "url": "https://yourblog.com/og-template?title=My+Post+Title", "viewport_width": 1200, "viewport_height": 630, "format": "png" }' The response gives you the image file. Save it to your CDN, set the og:image meta tag, and you're done. No browser to manage, no Chrome binary eating RAM on your CI server. Wiring It Into Your Build If you publish with a static sit

Thomas Edison put it plainly: "To have a great idea, have a lot of them." Steve Jobs said something similar. "Creativity is just having enough dots to connect... to connect experiences and to synthesise new things." Both of them are saying the same thing. Your first idea is rarely your best one. The reason why people you call creative can come up with great ideas easily is that they have had more experiences or have thought more about their experiences than other people. So the question becomes: how do you get more ideas, faster? The Most Used Method for Applied Creativity The answer has a name. It was coined by advertising executive Alex Osborn in the 1940s. He called it brainstorming - using the brain to storm a creative problem, with each person in the room attacking the same objective. It sounds simple. Most teams think they already do it. Most of them are wrong. Real brainstorming is a structured process with rules. Break the rules, and you get something that looks like brainstorming but produces far fewer useful ideas. Why Most Brainstorming Sessions Fail Here is what kills a brainstorming session before it even starts. Someone says an idea. Someone else says, "That won't work." The room goes quiet. People stop sharing. That is it. That is the whole problem. When people fear judgment, they self-censor. They only say the safe, obvious ideas. The interesting ones, the ones that could actually lead somewhere, stay locked inside people's heads. Most teams have that one gaffer who has already decided which ideas are worth hearing before anyone has finished their sentence. Or the one who gives you the floor, listens patiently, and then quietly bins everything you said, not because it was bad, but because it was not theirs. Both types do the same damage. The room reads it. People stop sharing. And just like that, the best idea in the session never gets spoken. The goal of brainstorming is to get more ideas. That means the number one rule is: defer judgment . The Rule

Introduction Modern software systems are distributed, complex, and constantly changing. When something breaks in production, you need answers fast. That's where observability comes in. Observability is the ability to understand the internal state of a system purely from its external outputs — without needing to redeploy, add debug code, or guess. It goes beyond traditional monitoring, which only tells you whether something is wrong. Observability tells you why it's wrong, where it started, and how it's spreading. In this article, we'll explore the three pillars of observability, set up a real Node.js API instrumented with Prometheus and Grafana , and walk through how to detect and diagnose a real-world issue using the data we collect. The Three Pillars of Observability 1. Logs Logs are discrete, timestamped records of events that happened in your system. They're the most familiar form of observability — every developer has done console.log debugging at some point. Example: [2026-07-02T10:34:21Z] INFO User 4821 logged in from IP 192.168.1.10 [2026-07-02T10:34:25Z] ERROR Failed to process payment for order #9932: timeout Logs are great for capturing specific events, errors, and context. But they can become expensive at scale and hard to query across millions of lines. 2. Metrics Metrics are numeric measurements collected over time. Unlike logs, they're aggregated and efficient to store and query. Common examples: HTTP request count per minute p95 response latency CPU and memory usage Error rate per endpoint Metrics are the backbone of dashboards and alerts. 3. Traces Traces follow a single request as it travels across multiple services. In a microservices architecture, a user request might touch 5–10 services. A trace shows you exactly where time was spent and where failures occurred. Tools like Jaeger , Zipkin , and OpenTelemetry handle distributed tracing. Why Prometheus and Grafana? There are many observability platforms out there: Datadog, New Relic, Dynatrace, Az

I used to spend ten hours every week doing content research manually. Checking competitor blogs. Scanning Reddit threads. Copying and pasting search results into a spreadsheet. Trying to spot patterns in an ocean of unstructured text. It was exhausting, slow, and completely unnecessary. Once I learned to automate this with Python and a few affordable APIs, I cut that ten-hour grind down to under thirty minutes. Here is the exact system I built, what it costs, and how you can replicate it yourself. The Quick Answer To automate content research with Python, combine a search API like Serper to pull structured Google search data, BeautifulSoup or requests-html to parse page content, and an LLM API like Gemini to synthesize insights into actionable content briefs. Connect these three components in a sequential Python pipeline and you have a fully automated research agent that runs in minutes instead of hours. What I Actually Built I needed a system that could do three things automatically: First, find what real people are asking about any topic across Reddit, Quora, and Google search. Second, identify what my top competitors have written about that topic and where the gaps are. Third, summarize everything into a clean content brief I can use to write or generate an article. I built this using Python with three core components: the Serper API for search data, BeautifulSoup for page parsing, and the Google Gemini API for synthesis. Total monthly cost: about twelve dollars. I document the full working version of this system — including the Flask web interface and WordPress publishing integration — at https://zerofilterdiary.com Step-by-Step Build Guide Step 1: Install the Required Libraries pip install requests beautifulsoup4 python-dotenv google-generativeai Step 2: Set Up Your API Keys Create a .env file in your project root: SERPER_API_KEY=your_serper_key_here GEMINI_API_KEY=your_gemini_key_here Step 3: Search for Real Discussions Using Serper API import requests import

Testing a food delivery app is hard. Testing an on-demand logistics app is harder. Food delivery has...

We need to have a serious talk about the Model Context Protocol. Everyone is losing their minds over "vibe coding" right now. You plug an MCP server into Cursor, Claude Code, or VS Code, tell the AI to fix a bug across three directories, and go grab a coffee while it spins up local servers, reads files, and executes terminal commands. It feels like absolute magic. But honestly? It's also completely terrifying. Maybe I’m just paranoid, but it seems like we’ve collectively skipped the part where we ask ourselves if giving a statistical text-prediction engine raw, unvetted access to our local machines is a good idea. Some security folks are already warning that we’re walking directly into a massive remote code execution crisis. Think about it. Most MCP servers run as local subprocesses. They inherit your exact user permissions. If you run your editor as an admin or with access to sensitive environment variables, so does the AI. And the real issue isn't that the AI will spontaneously turn evil. The issue is prompt injection. The Security Void in the Hype I spent some time looking through public MCP servers on GitHub recently, and the sheer lack of input validation is wild. Because developers are rushing to build cool tools, basic security hygiene has completely lagged behind. If an AI agent reads an untrusted string—like a malicious comment in a GitHub issue, an automated email, or a dirty record inside a database—it can easily be manipulated into executing an injection payload. The model doesn't know the difference between your system instructions and the data it's processing. It treats them exactly the same. What happens when a prompt injection tricks a standard filesystem MCP tool into looking for a file named ../../../../../../etc/passwd or pulling your private AWS keys? The tool just does it. It’s a classic path traversal vulnerability, except instead of a malicious hacker typing it into a web form, an automated agent is doing it because a piece of text told it to.

The Problem When you put RabbitMQ's Management UI behind an nginx reverse proxy under a sub-path like /rabbitmq/ , queue detail pages and many API calls break silently. The root cause: nginx normalizes the request URI before proxying. It decodes %2F (the URL-encoded forward slash) into a literal / . RabbitMQ's Management API uses %2F to represent the default virtual host ( / ) in API paths: GET /api/queues/%2F/my-queue When nginx decodes it: GET /api/queues///my-queue ← broken What Doesn't Work The common advice of using merge_slashes off or a rewrite directive doesn't fully solve this because nginx still normalizes $uri before forwarding. The Fix Use $request_uri inside an if block. Unlike $uri , $request_uri holds the raw, undecoded URI exactly as the client sent it — nginx never touches it. nginx # RabbitMQ: API paths — use $request_uri to preserve %2F (never decoded by nginx) location ~* ^/rabbitmq/api/ { if ($request_uri ~* "^/rabbitmq/(.*)") { proxy_pass http://rabbitmq:15672/$1; } proxy_buffering off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; } # RabbitMQ: general UI (JS, CSS, static assets, non-API pages) location ~* ^/rabbitmq/ { rewrite ^/rabbitmq/(.*)$ /$1 break; proxy_pass http://rabbitmq:15672; proxy_buffering off; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; }

Pernah kepikiran, "Sebenarnya AI agent saya inget apa aja sih soal saya?" Kalau iya, tulisan ini buat kamu. Masalahnya: Memori AI Itu Kotak Hitam Kalau kamu pakai AI agent yang punya memori jangka panjang (persistent memory), kamu mungkin pernah ngerasa gak nyaman karena beberapa hal ini: Gak tahu persis apa yang diingat AI tentang kamu Gak tahu file-nya disimpan di mana Gak bisa edit memori itu tanpa ngetik perintah lewat chat Takut kalau file memorinya rusak, semua informasi hilang begitu saja Studi kasus di tulisan ini pakai Hermes Agent , agent open-source besutan Nous Research. Sebagai konteks buat yang belum familiar: Hermes Agent adalah agent AI open-source yang berjalan sebagai proses (daemon) mandiri di server milikmu sendiri, mengumpulkan memori lintas sesi, menjalankan tugas terjadwal, terhubung ke belasan platform pesan, dan menulis skill-nya sendiri dari pengalaman. Framework berlisensi MIT ini dirilis Februari 2026 dan dengan cepat menarik perhatian komunitas open-source AI. Hermes menyimpan memorinya di dua file utama: USER.md (profil tentang kamu) dan MEMORY.md (catatan agent soal lingkungan kerja, kebiasaan, dan pelajaran yang dipetik), plus satu file lagi SOUL.md untuk "kepribadian" si agent. Semuanya disimpan dalam format teks polos yang dipisah pakai karakter § , seperti ini: Preferensimu: komunikasi singkat dan langsung § Namamu Budi, awal 30-an, tinggal di Surabaya § Penggemar PKM / Building a Second Brain Format ini fungsional, tapi ada beberapa kekurangan: Susah diedit langsung karena bukan format yang ramah manusia Gak ada riwayat versi — sekali salah edit, informasi bisa hilang selamanya Gak ada tampilan visual — susah lihat semua catatan sekaligus Gak ada antarmuka grafis — harus lewat chat agent atau edit file mentah Solusinya: pindahkan memori itu ke Obsidian , aplikasi catatan berbasis markdown yang mendukung riwayat versi lewat git dan bisa diedit bebas. Arsitektur Sistemnya Sistem sinkronisasi ini punya empat lapisan: ┌───────────────

An AI feature can feel impressive and still be a bad product decision. The demo is fast. The answer sounds useful. The team is excited. Then usage grows and nobody can answer the basic questions: Is it accurate enough? Is it saving time? Which customers trust it? Why did costs spike? Should we scale it, fix it, or kill it? That is the trap an AI metrics baseline prevents. A baseline is not a dashboard full of vanity charts. It is a small set of before-and-after measurements that tells you whether an AI workflow is getting better, getting worse, or merely getting more expensive. Why AI features fail without a baseline Most software teams already track uptime, errors, and conversion. AI features need those too, but they also need new signals because model behavior is probabilistic. A normal API either returns the expected response or throws an error. An AI workflow can return: a fluent answer that is wrong a correct answer with missing evidence a useful answer that costs too much a slow answer that users abandon a safe answer that refuses too often a cheap answer that hurts trust a high-rated answer that does not improve the business workflow Without a baseline, every production discussion becomes opinion-driven: "The model seems better." "Users like it." "The new prompt reduced hallucinations." "The expensive model is worth it." Maybe. Maybe not. The baseline turns those claims into measurable comparisons. What an AI metrics baseline is An AI metrics baseline is the starting measurement for the workflow before you optimize or scale it. It answers five questions: What does the workflow cost today? How good are the outputs today? How fast and reliable is the experience today? Do users adopt and reuse it? Does it improve the real task it claims to improve? You do not need 80 metrics on day one. You need a small set of metrics that match the feature's risk and purpose. For example: Feature Useful baseline Support answer bot resolution rate, citation quality, escalation r

The Token Bucket Algorithm: Server-Side API Rate Limiting in ~40 Lines Plenty of tutorials teach you how to survive someone else's rate limit with retries and backoff. Far fewer show you how to build one. If you run an API, you need rate limiting on your side too — to protect your database from a runaway client, keep one noisy tenant from starving everyone else, and give abusive traffic a polite 429 instead of a melted server. The cleanest algorithm for the job is the token bucket . Let's implement it from scratch, then make it production-ready. How token bucket works Picture a bucket that holds up to capacity tokens. Every request removes one token. The bucket refills at a steady refillRate (tokens per second), up to its cap. If a request arrives and the bucket is empty, it's rejected. This gives you two useful properties at once: A sustained rate — the long-run average, set by refillRate . A burst allowance — clients can spend the whole bucket at once, set by capacity . That burst tolerance is why token bucket feels fair. A user who's been quiet for a minute can fire off a batch of requests without being punished for it. A minimal implementation Here's a self-contained bucket in JavaScript. No dependencies, no timers — we compute refill lazily based on elapsed time, which is both simpler and more accurate than a background interval. class TokenBucket { constructor ( capacity , refillRatePerSec ) { this . capacity = capacity ; this . refillRate = refillRatePerSec ; this . tokens = capacity ; this . lastRefill = Date . now (); } _refill () { const now = Date . now (); const elapsedSec = ( now - this . lastRefill ) / 1000 ; this . tokens = Math . min ( this . capacity , this . tokens + elapsedSec * this . refillRate ); this . lastRefill = now ; } take ( cost = 1 ) { this . _refill (); if ( this . tokens >= cost ) { this . tokens -= cost ; return { ok : true , remaining : Math . floor ( this . tokens ) }; } const deficit = cost - this . tokens ; const retryAfter = Mat