标签：#RAM

The Quest Begins (The "Why") I was staring at a pull request that felt like a boss level in a retro arcade game—except there were no extra lives. The code was a massive if/else if/else chain that decided how to handle different JSON payloads coming from a third‑party API. Each branch did almost the same thing: validate a few fields, map them to our internal model, then call a service. The only thing that changed was the shape of the incoming object. Every time a new endpoint was added, a developer had to copy‑paste the whole block, tweak a few field names, and pray they didn’t miss a comma. Reviewing it felt like watching someone try to solve a Rubik’s cube by rotating random faces—you could get lucky, but most of the time you just made a bigger mess. I kept asking myself: Why are we writing the same logic over and over? The answer was hiding in plain sight: we weren’t seeing the pattern. The Revelation (The Insight) The breakthrough hit me while I was refactoring a tiny utility that turned a list of user IDs into a set. I realized I wasn’t writing a new algorithm each time—I was applying the same shape of solution: take an input, transform it, then feed it to a consistent consumer . In other words, the problem wasn’t “how do I handle payload X?” It was “how do I dispatch the right transformation based on a key?” That’s a classic dispatch table (or strategy pattern) problem. The “aha!” moment was when I looked at the chain and saw that each branch could be expressed as a function: function handleOrder ( payload ) { /* … */ } function handleRefund ( payload ) { /* … */ } function handleShipment ( payload ) { /* … */ } All of them shared the same signature: (payload) => Result . If I could map a discriminator (like payload.type ) to the correct function, the whole if/else monster would collapse into a single lookup. That’s the pattern top coders spot instantly: repetitive conditional logic → a table of behaviors . Once you see it, the code writes itself. Wielding the

Key Takeaways Asynchronous discussions can lose momentum because participants are focused on different tasks. For complex or important topics, it’s often better to switch to synchronous communication. At least in my experience working in a Japanese-speaking organization, AI-generated messages are often still too verbose to send as-is. As writing becomes cheaper, it’s even more important to reduce the cognitive load on readers. Async-first does not mean async-only. Keeping written records while introducing short meetings when necessary can reduce the overall cost of communication. Context I currently work from Vancouver, Canada, for a fully remote and fully flexible organization based in Japan. Since everyone works on their own schedule, much of our day-to-day communication, decision-making, and discussion happens asynchronously. There are many benefits to this way of working. People can think at their own pace, and discussions naturally leave a written record. As someone who is fairly introverted, I also appreciate having time to think through my ideas before sharing them. Recently, however, I’ve started to realize that keeping every discussion asynchronous is not always the most efficient approach. Complex discussions are expensive to read When discussing multiple options, I usually start by sharing my recommendation, then document the reasoning behind it and the pros and cons of alternative approaches. The more complicated the topic becomes, the longer the document becomes. Writing requires effort, but so does reading. Someone has to understand the background, process the trade-offs, form an opinion, and respond. Lately, I’ve become more aware of the reader’s cost than the writer’s. In our company, Japanese is the shared language, and much of our written communication is now assisted by AI. While AI makes it easier to produce long documents, the resulting text can still be unnecessarily verbose or difficult to follow. AI makes writing cheaper. It does not necessar

This is the strongest choice. It teaches a tangible, highly demanded skill (API key security) with actual code, making the backlink to AfriWidget feel like a natural, neutral citation rather than a sales pitch. Here is the article, rewritten to be strictly technical, objective, and genuinely useful for dev.to readers. Stop Exposing Your AI API Keys: Build a Secure Proxy with Cloudflare Workers We have all seen it. You open the browser's DevTools on a "cutting-edge" AI startup's landing page, check the Network tab, and find a direct POST request to api.openai.com containing a plaintext API key in the headers. It is one of the most common—and dangerous—mistakes in modern web development. Exposing your LLM API key client-side is an open invitation for abuse, leading to stolen credits, hefty bills, and potential account suspension. The standard solution is the Backend-for-Frontend (BFF) proxy pattern. But how do you implement it practically, cheaply, and securely without spinning up a heavy Express server? In this guide, I will walk you through building a lightweight, serverless AI proxy using Cloudflare Workers to securely call Groq (or OpenAI) APIs from your browser-based calculators and tools. The Architecture: How It Works Instead of your frontend talking directly to the AI provider, we introduce a stateless middleware layer: Browser App → Cloudflare Worker (Proxy) → Groq/OpenAI API ↑ ↑ (No API Key) (API Key stored securely in Worker env vars) The Worker's responsibilities: Receive the sanitized calculation context from the frontend (numbers, not PII). Attach the secret API key via environment variables. Forward the request to the LLM provider. Stream or return the generated insight back to the client. Step 1: Scaffolding the Cloudflare Worker We will use the new create-cloudflare CLI. Make sure you have Node.js installed. npm create cloudflare@latest ai-proxy Choose "Hello World" worker and TypeScript. Once inside the directory, install the Groq SDK: npm install gr

Officially added in Python 3.15 https://peps.python.org/pep-0661/ submitted by /u/Grouchy-Trade-7250 [link] [留言]

submitted by /u/DataBaeBee [link] [留言]

There is a quiet moment of panic every developer knows. You hit deploy, open the live site on your phone, and wait. One second. Two seconds. Four seconds. Still a blank white screen. A while back, I was working on a Next JS application that looked fast on high speed office Wi Fi. But when tested on a spotty mobile connection, it felt painfully slow. The initial page load was clocking in at nearly 8 seconds, and our main JavaScript bundle was a bloated 1.8 megabytes. Here is how we diagnosed the bloat, cut our load times by 47 percent, and the simple performance rules every developer should know. The Investigation: Where Was the Weight Coming From? When a website is slow, our first instinct is often to blame slow backend APIs or heavy database queries. But when I ran a performance audit, the backend was not the problem at all. The front door was just jammed with too much stuff. We were making three classic mistakes: First, we were packing for a long trip on a short walk. We were loading heavy charting libraries, complex admin tables, and pop up modals the second a user landed on the home page, even if that user only came to read a single line of text. Second, giant images were being served to tiny mobile screens, hogging precious bandwidth before any interactive buttons could even load. Third, a single state update at the top of our app was causing dozens of unseen child components to recalculate and re render unnecessarily behind the scenes. The Strategy: Trimming the Fat Instead of rewriting the entire codebase from scratch, we focused on three targeted fixes. 1. Don't Load It Until They Ask For It Why force a user to download a complex analytics chart if they have not even clicked on the dashboard tab yet? We split the app into smaller, independent code chunks. Now, the user downloads only the absolute bare minimum needed to view the immediate screen. The heavy features stay on the server until the exact moment the user interacts with them. 2. Smart Asset Delivery

submitted by /u/f311a [link] [留言]

Hello everyone! This is the second article about the development of RUSEON-core, a Zero-Copy video streaming server for AI platforms and Edge video infrastructure. In the first article , I talked about the fundamental reason why we decided to create our own server in the first place. I also covered the main problem with most similar solutions — the "thundering herd" — and how we managed to squeeze out 8 Gbps on a single CPU core. By the way, I forgot to mention in that article that besides simple streaming, we also record the streams in fMP4 format. It’s stored locally for N amount of time, and it can fly off to an S3 bucket (depending on how long the clients want to keep the recordings). This article is precisely about a non-obvious (well, at least to me, maybe for someone else it's an everyday thing) problem related to data storage and its specifics across all Operating Systems. So, let's dive in. We rolled out our first release to production (100 cameras), made the clients happy, and started working. About an hour passed, and the alerts started flying. I SSH into the server, open htop, and see there's only 100 MB of free RAM. Uh-oh. I should clarify that the production server had 32 gigs of RAM. The expected behavior was that the CPU is chilling, the network card is chewing through the traffic, RAM usage is around 250-300 MB, and the disks are not heavily loaded. So, when you see numbers like that in htop, you start blaming yourself and your crooked hands that wrote this piece of "garbage". But still, we decided to go to Google, ChatGPT, and the like. Fortunately, the answer was found quickly, and we stopped beating ourselves up. The code was absolutely not the culprit; Linux itself ate the memory. If you've ever written tons of data to a disk, I think you already know what’s going on. There is an "invisible enemy" known as the Page Cache. That was exactly the root of this problem. How does the Page Cache work and what to do with it? When your function that is su

submitted by /u/mttd [link] [留言]

Everyone is building agents. You should build escape hatches. We are living through the most expensive group hallucination in tech history. Every SaaS now has a chatbot stapled to it. Every CEO is an "AI thought leader" on LinkedIn. Every startup pitch deck is just the words "autonomous," "agentic," and "10x" in different fonts. NVIDIA could buy a small country. OpenAI burns through more cash in a quarter than NASA did getting to the moon. And for what? So you can generate slightly worse emails, slightly faster? Look, I love AI. I actually build with it. But I have been around long enough to know what a bubble smells like. It smells like free credits, unearned confidence, and a thousand wrappers around the same API call. The bubble will pop. Not in a dramatic, newspapers falling from the sky way. It will pop quietly. Credits will dry up. Models will get paywalled behind enterprise tiers. The cloud bill you have been ignoring will finally show up. And all those beautiful, cloud-dependent workflows you built will start blinking red. So while everyone else is trying to figure out how to make their AI agent book a flight, I have been asking a different question. What do you build when you assume the internet will get worse, the cloud will get more expensive, and you will need actual skills that survive a downturn? The answer, annoyingly, is two pieces of junk from Amazon that cost less than your last Uber Eats order. Piece of Junk #1: The $25 Router That Sees Everything It is not sexy. It is called the GL.iNet GL-MT300N-V2. Everyone calls it the Mango. It looks like a little yellow box that should have come free with your ISP in 2014. You can buy it on Amazon for about twenty six dollars when it is on sale. Sometimes twenty. Inside it is a tiny Linux computer running OpenWrt. It has two ethernet ports, a USB port, and just enough RAM to be dangerous. Most people buy it to get free WiFi in hotels. I bought it to spy on my own network. Because here is the dirty secret of

submitted by /u/compilers-r-us [link] [留言]

Near the end of a release, every file transfer to the production server succeeded, and the version file that triggers distribution was updated too. With that confirmed, the release got reported as complete — except the local git repository never actually had those changes committed. Note: "Deploying" here means transferring changed files to the production server (via scp, for example) so they're actually live for users. "git push" is a separate operation that records the change history in a remote repository. What happened This release involved transferring seven files to the production server: five landing-page update-notice files, the version file that triggers distribution, and a progress-log file. The transfer itself succeeded completely, and the production site confirmed it was showing the new version number. The problem: after editing these files locally, the work moved straight to the transfer step without ever committing . The files on the production server were fully up to date, but the local git repository had no record of those changes — and the release got reported as complete in that state. Why this is easy to miss Transferring files with scp and recording them in the repository with git commit / git push are completely independent operations, both as commands and as goals. Verifying production (HTTP 200, checking the rendered content) confirms "did the deployment succeed" — a different question from "is the local change history recorded." Treat the first check as proof of "done," and the second check quietly never happens. When both steps get mentally bundled into one "release complete" state, there's no natural moment to notice that only one of them actually finished. In this case, it surfaced because someone else looking at the repo noticed it hadn't been committed yet. The fix — treat "uploaded" and "git synced" as two separate checks Add a git-sync verification step to the deploy checklist, independent from the file-transfer confirmation. # Commit

Yes! this was about 12 years ago, when I was just a little 10 year old girl. I was very lazy even...

submitted by /u/tech-tinkerer-19 [link] [留言]

Ho bloccato gli attacchi xss e l'estrazione della chiave API nel browser modificando monkey-patch crypto.subtle. Perché non lo fa nessun altro? Here is how I hardened the browser runtime for a Zero-Knowledge, Non-Custodial FinTech trading terminal. 👇 2/ Client-Side Envelope Encryption: I derive a KEK from the user's password using PBKDF2-SHA256 (310,000 iterations). Then, a secure random 32-byte DEK (AES-256-GCM) encrypts the data. The password NEVER touches the server, and the DEK has a strict 15-min TTL in RAM before a wipe. 3/ Secure Enclave Anti-Export Guard: CryptoKeys are generated via crypto.subtle with {extractable: false}. To prevent injected malicious scripts from bypassing the sandbox, I implemented an isolated closure that overrides (monkey-patches) the native browser API: 4/ crypto.subtle.exportKey = async function(format, key) { if (isProtectedKey(key)) { _AuditChain.append('EXPORT_ATTEMPT', 'CRITICAL'); throw new Error('Export BLOCKED — unauthorized'); } return _origExport(format, key); }; 5/ If our database is breached, hackers find ZERO financial data. If the local session is compromised, runtime gating blocks extraction. Plus, client-side validation rejects API keys with withdrawal permissions enabled (zero custodial risk under MiCA, built for GDPR). 6/ The entire architecture runs client-side (WebSocket throttled at 100ms + local AI Advisor), keeping server costs near zero. Where does this runtime isolation logic fail? Why do major SaaS platforms still rely on standard local storage? Let's discuss. 💬 submitted by /u/Fit-Document9226 [link] [留言]

I manage a dev team, and we've been running Claude Code daily for months. I built a set of custom skills for us — code review, a debugging protocol, our team conventions — and the biggest lesson I learned surprised me: The body of your skill barely matters if the description is wrong. The failure mode nobody warns you about Here's what happens to most developers who discover skills. They get excited, write a detailed 200-line SKILL.md encoding everything they know about code review... and then it never triggers. Not once. They conclude skills "don't really work" and go back to re-typing the same prompt every session. The skill was probably fine. The description killed it. The description is a routing rule, not documentation A skill's description is the only part Claude sees upfront. The full instructions load only after the description matches your request. So the description isn't marketing copy — it's a routing rule, and it needs to be written like one. Compare: # WEAK — reads nicely, never triggers description : Helps with code quality and best practices. # STRONG — names the situations AND the phrasings description : Security-first code review for Python/FastAPI. Trigger when the user asks to "review", "check", or "look at" code, pastes a function or endpoint, mentions a bug, or asks "what's wrong with this". Also trigger on short requests like "review this". The difference: the strong version contains the actual words you type. Including the lazy ones. Nobody writes "please perform a comprehensive quality assessment" at 11pm — they write "review this". If your description doesn't cover the two-word tired version, your skill sleeps through most of your real requests. Three rules that fixed my skills 1. List your real trigger phrases. Open your chat history and look at how you actually phrase requests. Those exact phrases go in the description — "fix it", "what's wrong here", "check this". Your real vocabulary, not your professional vocabulary. 2. Name the artifa

submitted by /u/mttd [link] [留言]

System Design is the process of planning how a software system should work before building it. Think about constructing a large building. Before workers start putting up walls, architects decide where the rooms, elevators, electricity, water systems, emergency exits, and entrances should go. Software works in a similar way. When developers build applications such as Amazon, Instagram, Netflix, Uber, or WhatsApp, they cannot simply start writing code and hope everything works. They first need to decide how millions of users, servers, databases, files, and requests will work together. A simple way to remember it is: System Design = The blueprint of a software system. What Do We Decide in System Design? During system design, engineers make decisions about things such as: How users connect to the application Where information is stored How different parts of the application communicate How images and videos are stored How the system handles millions of users How the application stays fast How failures are handled How user information stays secure For example, imagine designing WhatsApp. A user sends a message. That message must travel to WhatsApp's servers, reach the correct person, possibly be stored temporarily, appear on multiple devices, and trigger a notification. If millions of people send messages at the same time, the system must continue working without becoming extremely slow or crashing. That planning is system design. Why Does System Design Matter? A good software system should be: Fast Reliable Secure Scalable Affordable to operate Easy to maintain Imagine Instagram without good system design. Millions of users might open the application at the same time. Servers could become overloaded, photos might take several seconds to load, comments could disappear, and the application might frequently crash. System design helps engineers prepare for these situations before they become major problems. System Design in Software Interviews System design is also common i

Remember when "AI coding" just meant inline tab-completion suggesting a for loop in VS Code? Those were simpler times. 😅 Fast forward to this week, and we’ve officially crossed the threshold into the Autonomous Multi-Agent Era . The industry is shifting away from single-turn autocomplete prompts toward async, parallelized agentic workflows that inspect, plan, write, test, and validate code across entire repositories. Three major developments dropped almost simultaneously: ⚡ Meta launched Muse Code (powered by Muse Spark 1.2) in beta, introducing parallel sub-agent execution. ☁️ AWS added an Agentic Workspace to Kiro , enabling async background task delegation for developers. 🎓 New Academic Research surfaced on how AI coding agents leverage structured "Agent Plans" for full-lifecycle repo maintenance, design, construction, testing, and validation. Let's break down why this is a massive engineering paradigm shift and what it actually means for our daily developer workflows. 🧬 1. Meta Muse Code & Parallel Sub-Agent Swarms Meta’s latest drop— Muse Code , driven by their Muse Spark 1.2 model—takes aim at one of the biggest bottlenecks in single-agent LLM systems: context dilution and linear execution delays . When you ask a traditional LLM to refactor a complex microservice, it processes everything sequentially. It reads your files, thinks, writes code, tries to debug, and eventually runs out of context space or hits token output limits. How Parallel Sub-Agent Execution Changes the Game Muse Code doesn't just run one linear chat session. Instead, a primary orchestrator agent decomposes a high-level goal into specialized sub-agents running concurrently: ┌──────────────────────────────┐ │ PRIMARY ORCHESTRATOR AGENT │ └──────────────┬───────────────┘ │ ┌──────────────────────────┼──────────────────────────┐ ▼ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ SUB-AGENT A │ │ SUB-AGENT B │ │ SUB-AGENT C │ │ AST Parsing & │ │ Unit Test Suite │ │ Static Analysis

Tienes una señal que a cada observación te dice en qué estado estás: un monitor de salud que dice OK o CAÍDO , un detector de conectividad, un clasificador de modo. Y cerca del umbral oscila : OK, CAÍDO, OK, CAÍDO, OK . Cada cambio dispara algo —una alerta, un failover, entrar o salir de una posición— y de repente tu sistema está temblando por ruido, no por una transición real. Es el mismo problema que resuelve el termostato de tu casa desde hace un siglo, y la solución tiene nombre: histéresis . No cambies de estado hasta que el nuevo se haya sostenido. La regla, en una frase Un estado nuevo solo se confirma tras repetirse N observaciones consecutivas. Si el candidato cambia o revierte antes de llegar a N , la cuenta se reinicia. El estado vigente se mantiene estable; los parpadeos se ignoran. Lo empaqueté como librería — hysteresis-state , Python puro, sin dependencias— porque lo reescribía una y otra vez: from hysteresis_state import HysteresisState estado = HysteresisState ( " OK " , confirmations = 3 ) for lectura in stream : # "OK" / "CAIDO" actual = estado . update ( lectura ) # solo cambia tras 3 lecturas seguidas if estado . changed : # ¿esta lectura provocó la transición? alertar ( actual ) Aliméntalo con OK, CAÍDO, OK, CAÍDO, OK y no pasa nada: ningún candidato se sostuvo. Hacen falta tres CAÍDO seguidos para que el cambio se confirme. El detalle que casi siempre falta: histéresis asimétrica Un umbral único tiene un problema sutil. Si exiges 3 confirmaciones para entrar en fallo, también tardas 3 en salir — y a veces quieres justo lo contrario: caer rápido a lo seguro, volver despacio a lo arriesgado . Es el comportamiento de un disyuntor eléctrico: salta a la primera, se rearma con cautela. Se resuelve dejando que el umbral dependa de la transición: # 1 confirmación para caer a "CAIDO", 5 para volver a "OK" conf = lambda desde , hacia : 1 if hacia == " CAIDO " else 5 estado = HysteresisState ( " OK " , confirmations = conf ) estado . update ( " CAIDO " )