标签：#ev

The first session ended at post 10. The design did not. I came back to it and, before writing a single new decision, asked the least glamorous question a solo project can ask itself: how far along is this, really, and what would it take to call it ready for someone else to review in depth? The answer was more useful than I expected, because it forced a distinction I had been blurring: a settled mechanism is not a hardened design . The fork: promote now, or hold and harden Composition was already reconciled into the binding docs. Coherence had seventeen recorded decisions covering the whole load-bearing core: binding, determinism, precedence, persona content, gender, explainability, detection, activation, the explicit accessor, and a second entity proving the abstraction generalizes. It was tempting to call that reviewable and promote it too. A: promote coherence into the binding docs now. 17 decisions, self-consistent, composition already went. Looks done. B: hold. The mechanism is settled, but the seams between features are not. Harden first, promote second. I took B. The tell was that I could not yet answer a reviewer's most obvious question, "what happens when a composed child is itself a person," without pointing at an open fork. A design you cannot stress at the seams is decided, not done. What "hardened" actually means The value of taking stock was turning a vague "almost there" into a concrete, finite list. Three passes stand between the current state and an in-depth review: 1. Cross-feature interaction pass. Where correctness bugs hide once two features exist. Composition x coherence is done (next post). Uniqueness, null-probability, and locale remain. 2. Surface-enumeration pass. Collect every public member the design has accumulated into one list to accept or cut. Public surface is locked, so this is the gate that matters most. 3. Consistency re-read. Read all the decisions straight through for contradictions and stale cross-references, the kind that creep

AI agents can reason about the web. But giving an agent unrestricted browser or network access creates a serious authority problem. The obvious solution is to restrict the tools available to the agent. Then I kept running into the opposite problem: Once the tool became sufficiently restricted, it lost many of the capabilities required to complete real work. I wanted both sides: Enough power to crawl, render, navigate, extract, capture, and investigate the web Explicit operator control over origins, credentials, budgets, browser hooks, profiles, and evidence So I built Cockroach Crawler . It is an open-source Node.js and TypeScript toolkit for AI agents, RAG pipelines, documentation indexing, research, QA, and web-data workflows. I connected it to OpenClaw and Codex , and the difference was honestly wild. Instead of giving the agents one narrow search tool, I gave them a bounded web-research layer that could crawl websites, inspect JavaScript applications, extract structured data, process PDFs, take screenshots, generate PDFs, inspect public sources, and return evidence with provenance. And for many public workflows, I did not need to configure a separate API key for every source. GitHub: https://github.com/AjnasNB/cockroach-crawler Documentation: https://cockroachcrawler.com/docs/ npm: https://www.npmjs.com/package/cockroach-crawler What changed after I connected it to OpenClaw and Codex? Before this, the agents could reason well, but their web access was limited. They could answer questions, write code, and work with the context I gave them. But once a task required deeper live-web investigation, I still had to manually combine several tools. After connecting Cockroach Crawler, they could: Crawl public websites Render JavaScript-heavy pages Follow sitemaps Search and map documentation sites Extract readable Markdown Extract structured fields with CSS, XPath, or restricted regular expressions Read local and remote PDFs Generate PDFs Take screenshots Handle bounded c

When ChatGPT, Claude or Perplexity answers a question about your product, it is not consulting a decade of PageRank. It fetches a handful of pages and tries to work out what your site is. That is a very different retrieval problem from classic search, and most sites are accidentally hostile to it. Why sitemaps are the wrong mental model A sitemap optimises for coverage — every URL, every paginated archive, every tag page. That is correct for a crawler with a huge budget and a ranking model to sort the noise afterwards. An LLM landing on your site has neither. It has a limited context window and one shot. If the first thing it ingests is 400 URLs of ?page=17 and /tag/misc , your three genuinely useful guides are buried. llms.txt inverts this. It is a small markdown file at your root that optimises for priority : # Your Product > One-line description of what this actually does. ## Docs - [ Quickstart ]( https://example.com/docs/quickstart ) : Install and first request in 5 minutes - [ API Reference ]( https://example.com/docs/api ) : Every endpoint with request/response examples Two rules make or break it: Every link carries a description. The colon-suffix annotation is what lets a model decide whether to fetch a page. A bare link list is barely better than a sitemap. Omit aggressively. If a page does not answer a question someone would ask, it does not belong. llms-full.txt and the context tradeoff llms-full.txt inlines expanded content rather than linking out, so a model can ingest everything in one request. This is genuinely useful for compact docs — and actively harmful for large sites, where you will blow the context window and get truncated mid-document. Rough heuristic: if your docs exceed roughly 50k tokens, ship llms.txt alone and let models fetch selectively. The part nobody mentions: it rots This is where most implementations quietly fail. You write the file, ship it, and three months later half the descriptions describe features you renamed and two links 4

Every frontend developer eventually reaches the same point. You know React. You know TypeScript. You know how to build components. But then you join a real project. Suddenly the questions are no longer about writing a component — they’re about engineering. How should the project be structured? Where should authentication logic live? When is React Context enough? When should React Query own the data? How do you prevent a codebase from becoming impossible to maintain? What makes a frontend application scalable? How do AI coding tools fit into modern development? These are the questions I kept asking myself while working on frontend applications. The problem wasn’t the lack of information. The problem was that the information was scattered across hundreds of blog posts, GitHub repositories, conference talks, documentation pages, and personal notes. Tutorials Teach Frameworks Modern tutorials are excellent at teaching frameworks. You can easily learn: React Vue Angular Next.js TypeScript But very few resources explain what happens after that. How do experienced teams actually build production frontend applications? How do they organize folders? How do they write maintainable code? How do they review pull requests? How do they optimize performance? How do they scale applications from one developer to twenty? Those are engineering problems — not framework problems. Frontend Engineering Is a Different Skill Writing React code doesn’t automatically make someone a frontend engineer. Frontend engineering includes topics such as: Project architecture Feature-based organization Authentication and authorization API design State management Data fetching strategies Performance optimization Accessibility Error handling Testing CI/CD Monitoring Code quality Documentation Team conventions These subjects rarely live in one place. AI Has Changed the Way We Build Software Another reason I started this project is the rise of AI coding assistants. Learn about Medium’s values Today many de

The MCP (Model Context Protocol) ecosystem is growing fast. There are now hundreds of MCP servers available — but how do you know which ones are worth installing? After building and evaluating 60+ MCP servers ourselves, we developed a practical checklist that saved us from shipping broken tools. Here's the framework we use. The Problem Most MCP server listings tell you what the server does. Very few tell you how well it does it. You install something that sounds perfect, then discover: It activates on the wrong prompts (false positives) It pulls irrelevant context (retrieval drift) It sounds confident but gives wrong answers (ungrounded reasoning) It never improves from feedback Sound familiar? The 5-Dimension Evaluation Checklist Before installing any MCP server, ask these questions: 1. Trigger Precision Question: Does this server activate when (and only when) it should? Red flags: Overly broad trigger descriptions ("use for anything related to X") No documented activation conditions Activates on common words that appear in unrelated contexts Green flags: Specific, documented trigger scenarios Clear non-activation cases listed Tested against diverse prompts 2. Retrieval Quality Question: Does it pull the right context for the task? Red flags: Returns large chunks without filtering No citation or source tracking Retrieves plausible but outdated information Green flags: Targeted, minimal context retrieval Source attribution for every piece of context Version-aware (knows when data might be stale) 3. Reasoning Grounding Question: Are its conclusions tied to actual data? Red flags: Generates advice without referencing specific inputs Can't explain its reasoning chain Confident answers that contradict its own retrieved context Green flags: Every conclusion references specific evidence Explicitly flags uncertainty Gracefully handles missing information 4. Output Usefulness Question: Does the output actually solve your problem? Red flags: Generic responses that could appl

Many online image converters require users to upload their files to a remote server before processing. For ordinary images this may be acceptable, but for personal photos, screenshots and documents, privacy becomes an important concern. I built a lightweight online image converter that processes images directly in the browser. It currently supports: JPG PNG WebP HEIC GIF SVG BMP TIFF Why browser-based processing? The main goal was to make image conversion simple, fast and privacy-friendly. Because the conversion happens locally: Images are not uploaded to a server Users do not need to create an account There is no installation process Network upload time is avoided Private files remain on the user’s device The basic workflow is simple: Select an image Choose an output format Convert the file Download the result Challenges Browser-based image conversion still has some limitations. Different browsers support image formats differently, especially formats such as HEIC and TIFF. Large images may also consume more device memory during processing. Some format features may not be preserved after conversion. For example, transparency may be lost when converting to JPG, and animated images may become static depending on the selected output format. These limitations need to be handled through clear prompts and error messages.

Detecting what powers a website looks simple: send a request, read the response, match fingerprints. In real environments it rarely stays that clean. False positives slip through, infrastructure hides behind CDNs, old scripts linger after migrations, and fingerprints keep evolving. Developers who treat fingerprinting as a basic utility end up acting on misleading data. This guide covers the mistakes engineers make detecting website technologies and how to avoid them. Modern detection workflows lean on ProjectDiscovery's libraries, which cut these problems through structured pattern matching and maintained datasets. External resources: github.com/projectdiscovery/wappalyzergo projectdiscovery.io If you're new to the space, start with technology fingerprinting for developers before these pitfalls. Mistake 1: Trusting a single detection signal Relying on one clue is the fastest way to get a wrong answer. A script file may linger after a framework migration, a header can be spoofed, and a cookie might belong to a third-party service. Correlate several signals instead: headers, cookies, HTML patterns, script paths, metadata. When multiple indicators point at the same technology, confidence goes up. ProjectDiscovery's libraries are built around that multi-signal approach. Mistake 2: Treating detection as a one-time task Stacks change constantly. Organizations migrate infrastructure, update frameworks, and swap platforms more often than developers expect. Scan once and trust it forever and you're working from stale data. Schedule periodic scans. Many teams wire detection into automation pipelines so infrastructure changes get captured on their own. To operationalize this, see detect website technologies programmatically in Go . Mistake 3: Ignoring reverse proxies and CDNs Modern architectures hide origin servers behind proxy layers. You might detect a CDN and miss what actually powers the app. Detecting a CDN doesn't make the origin invisible. It means you need to look fur

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. You've probably noticed this if you've tried to fetch a public webpage in the last two years. You write four lines of Python. You get a 403. You add a User-Agent header. You get a 403 with better manners. You spin up headless Chrome and get a challenge page that spins forever. Eventually you go looking at pricing pages for data APIs, where a cheerful landing page offers to sell you back the exact same public HTML for $100 a month. Meanwhile the big labs vacuumed up that same web at a scale none of us will ever match, and now the standard way to read a page programmatically is to pay somebody. The web went from "open by default" to "open, but only if you look like a person holding a mouse." So let's talk about eight open source projects quietly clawing that access back. I've used most of these in anger. Some are brilliant. Quick note on star counts: I mention a few, because they are a decent signal of "somebody else has hit the bugs before you." They are not a signal of maintenance. A repo can have 70k stars and a last commit from 2023. Always check the commit graph before you check the star count. 1. Firecrawl: the one that turned a URL into a prompt What it does: you hand it a URL, it hands you clean markdown. Not HTML with the nav bar and the cookie banner and four newsletter modals. Markdown. Headings, paragraphs, links, done. It also does more than single pages. The crawl endpoint walks a whole site, map gives you a URL inventory without fetching everything, and structured extraction pulls typed JSON out of a page if you describe the shape you want. from firecrawl import Firecrawl app = Firecrawl ( api_key = " fc-... " ) doc = app . scrape ( " https://example.com/docs/getting-started " , formats = [ " markdown " ]) print ( doc . markdown

I wanted to add a background-removal tool to my site's image cluster that stayed true to the 100% client-side processing principle I already use for PDFs and image conversions. The path there was anything but linear: a library dropped over a licensing problem, a carefully chosen model that turned out more limited than expected, and a bug that froze the entire page — not just the tool — during computation. Here's the full build, including the parts that didn't work the first time. The starting problem: what's actually feasible for free? The initial idea was broad: remove backgrounds, and maybe unwanted objects too. The two tasks have very different difficulty levels. Removing objects requires inpainting — plausibly reconstructing the erased area — which in practice still means heavy generative models, impractical to run client-side with good quality on an average device. Removing a background , on the other hand, is a segmentation problem: separating a subject from its surroundings. That has much lighter models available, runnable entirely via WebAssembly with no server involved at all. So: background removal only, object removal shelved for later. The AGPL trap The first library that looked like a perfect fit turned out to be distributed under AGPL , a strong copyleft license. Free to use — but with a real catch for anyone embedding it in a public, closed-source web service: AGPL can require releasing the full source of the project that embeds it, under the same license. "Free for the end user" and "safe to drop into a closed-source commercial product" are two different questions, and it's worth answering the second one before writing integration code, not after deploying it. Before wiring any "free" AI library into a commercial project, check the exact license, not just the price tag. AGPL, GPL, and other strong copyleft licenses are fine for personal or internal tools, risky for a public closed-source product. The fix: switch to Transformers.js — Hugging Face's li

Every couple of projects I ended up rebuilding the same effect: an animated topographic map background, the kind with slowly drifting contour lines. After copy pasting the same WebGL shader for the third time I gave up and turned it into a proper library. It's called topolines . One React component, zero dependencies, everything drawn on the GPU. Repo: https://github.com/idleCyrex/topolines Playground: https://topolines.idlee.xyz/playground How it works The lines are not an image or SVG. A small fragment shader generates a noise field (simplex noise + fbm) and draws contour bands from it, so it animates smoothly at any resolution for basically no CPU cost. The component just manages a canvas and the WebGL state around it. Usage npm i topolines import { Topolines } from " topolines/react " ; export default function Hero () { return < Topolines seed = "hello" color = "#F2EFE6" style = { { position : " fixed " , inset : 0 } } />; } Same seed always renders the same field, so your background is stable between visits. There are props for speed, scale, line width, colors, drift, and an interactive mode where contour rings bloom around the cursor. Things I cared about Zero dependencies, the whole thing is one shader and some glue code SSR safe, works in a Next.js server component tree Pauses when offscreen or when the tab is hidden Respects prefers-reduced-motion (renders one static frame) Clean fallback when WebGL is not available The playground lets you tweak every knob and copy the resulting code out: https://topolines.idlee.xyz/playground It's v0.1 and my first published library, so feedback and feature ideas are very welcome.

The TK705STi’s highly responsive, low-latency performance makes gameplay ultra-realistic. For movies and TV? It’s a purely average home projector.

Ich habe einen echten Speedtest in Vanilla JS gebaut (mit Cloudflare API) Kein npm install. Kein React. Kein 200-MB-node_modules-Ordner. Nur HTML, CSS und ~250 Zeilen JavaScript, die deine echte Internetgeschwindigkeit messen. 👉 Live-Demo: dsl.nevik.de/speedtest Warum noch ein Speedtest? Es gibt Speedtest.net, FAST.com und dutzende andere. Warum also selbst bauen? Drei Gründe: Transparenz: Ich wollte genau verstehen, was gemessen wird – und was nicht. Größe: Die meisten kommerziellen Speedtests laden mehrere MB an Tracking-Scripts. Meiner ist eine einzige HTML-Datei mit eingebettetem JS. Kontrolle: Ich kann das Ergebnis direkt gegen den gebuchten Tarif des Nutzers bewerten und eine fundierte Empfehlung geben. Das Ergebnis ist ein Speedtest, der in unter 50 KB ausgeliefert wird, auf jedem Gerät läuft und echte Messwerte liefert – keine Schätzwerte. Die Architektur: Drei Phasen, drei Messungen Ein guter Speedtest misst drei Dinge: Ping (Latenz): Wie schnell kommt ein Datenpaket hin und zurück? Download: Wie schnell kommen Daten bei dir an? Upload: Wie schnell kommen Daten von dir raus? Für alle drei nutze ich die öffentliche Cloudflare-Speedtest-API , die unter speed.cloudflare.com läuft. Cloudflare betreibt eines der größten Edge-Netzwerke der Welt, hat Server in praktisch jedem Land und – ganz wichtig – erlaubt CORS für diese Endpunkte, sodass wir direkt aus dem Browser heraus messen können. Die zwei Endpunkte, die alles tragen: const CF_DOWN = ' https://speed.cloudflare.com/__down?bytes= ' ; const CF_UP = ' https://speed.cloudflare.com/__up ' ; __down?bytes=N liefert exakt N Bytes zurück. __up nimmt einen POST-Body beliebiger Größe entgegen. Das war's. Kein API-Key, keine Rate-Limits, die für unsere Zwecke relevant wären, keine Kosten. Phase 1: Ping messen (ohne WebSocket) Klassische Speedtests nutzen für den Ping oft WebSockets oder RTCPeerConnection -Tricks. Das ist komplex und fehleranfällig. Mein Ansatz: Wir laden einfach einen winzigen Datenblock (1 KB) fünfma

Building an operating system is a project I have had my eyes set on ever since I discovered free will in the realm of programming. Years ago, I did a reasonable amount of research, paying extra attention to the subject during my computer science degree and I was able to understand Operating System Theory and how it works from first principles but I never really got around to building one. I had only flimsy reasons for not embarking on it like "why build one when there are tons of working ones out there? The theoretical knowledge is enough" . More recently, I am ignoring the need to not re-invent the wheel for the joy of programming. So if you are interested in also rebuilding stuff because you can, join me on this series as I document how I am going to be building kluster. kluster is in its infancy and the direction is not clear but the one certain thing is that I will be building it entirely in Rust, save some assembly instructions and a linker script and I will be explaining every single line of code along the way. It will also be designed to target the raspberrypi 4 & 5, on qemu and on real hardware respectively. This is an opportunity for anyone who wants to see how Rust works at the lowest of levels to hop on and join the ride. Note that this series will be your biggest lesson on delayed gratification because we will write a lot of code before we even get to see anything meaningful on screen but I will foreshadow what you can get by the end of part 3 if you are patient enough: {{ image(src="/images/os-part3-result.png", alt="Part 3 Results OS Dev") }} You can also clone the source code for part 1 from Github and follow along. Project Setup First things first, let us setup the foundation of the project. I'll be straight with you, I love Rust and I enjoy using the Rust ecosystem in its entirety so I will stay true to that and use it as obsessively as any true Rustacean; I won't hold back. Without doubt, all the dependencies we need are freely available as long as

I just wanted to open a CSV file quickly. Instead, I got: Slow spreadsheet apps Online tools that upload my data Way too much friction So I defined a simple goal: Fast and frictionless Fully local (no uploads) Spreadsheet-like experience That’s what I built. What you can do with it Open CSV files instantly (drag & drop, no setup) Search and filter large datasets in seconds Edit data like a spreadsheet Export exactly what you see Why this matters Everything happens locally in your browser: Your data never leaves your device No account required No tracking, no storage Built with client-side JavaScript — no backend involved. Just open, edit, and export. How it works Built with client-side JavaScript — no backend involved. Spreadsheet-Like Editing Click a cell to select it, then press Enter or double-click to start editing. Press Enter again to save the value and move to the cell below. Use Option + Enter on macOS or Alt + Enter on Windows to insert a line break. You can also drag the small fill handle to copy a value across multiple cells. Export the Current View The exported CSV reflects the current table state, including: Search results Sorting order Visible columns Saved cell edits Try it yourself Open a CSV file, edit a few cells, and export it — all without uploading anything. 👉 https://csv-open.github.io/ No signup. No upload. Just works. Handles CSV files up to 25MB Supports multiple languages

As part of my learning journey with Django, I wanted to build a project that would challenge me beyond the basics. I decided to create RecipeHub, a web application where users can create, manage, and share recipes while exploring recipes from other users. The project started from a Django starter template, but I customized it by adding new features, redesigning the interface, and deploying it online. Features RecipeHub allows users to: Register and log in Create, edit, and delete recipes Browse recipes by category Save favourite recipes Upload recipe images Access a personal dashboard Use the application in both light and dark mode The application is fully responsive, making it easy to use on both desktop and mobile devices. Technologies Used I built the project using: Python Django Django Allauth PostgreSQL Tailwind CSS DaisyUI HTMX Vite Gunicorn Render GitHub was used for version control throughout the project. Challenges One of the biggest challenges was deployment. While everything worked locally, deploying to Render required configuring PostgreSQL, environment variables, and static files correctly. I also encountered an issue with uploaded recipe images. Since the application is hosted on Render's free tier, uploaded media is stored on an ephemeral filesystem, meaning uploaded images are lost after redeployment. Learning why this happens gave me a better understanding of the difference between development and production environments. Another challenge was redesigning the dashboards. I wanted them to feel clean and modern instead of looking like a default Django application, so I spent time improving the layout, spacing, and responsiveness. What I Learned This project helped me improve my understanding of: Django project structure Authentication and user management CRUD operations Database relationships Responsive UI design Git and GitHub workflows Deploying Django applications Debugging real-world issues More importantly, it taught me how to troubleshoot proble

xAI has a bold pitch for Grok 4.5: it codes about as well as Claude Opus 4.8, but does it with roughly a quarter of the tokens. That's not a "we're smarter" claim. It's a "we're just as good for far less money" claim, which in 2026 might matter more. Someone actually put it to the test, so let me walk through what the numbers say and why you should care. The claim and the pricing Grok 4.5 landed on July 8, 2026. xAI says it matches Opus 4.8 on coding while using about 4.2 times fewer output tokens to get there. The sticker price already favors Grok. It runs $2 per million input tokens and $6 per million output. Opus sits at $5 and $25. That's less than half the price on both sides before you even factor in the token efficiency. Stack the two together and the cost gap gets dramatic. What the benchmarks say The benchmarks mostly support the marketing, with a catch. On Terminal-Bench 2.1, which measures real command-line work, Grok 4.5 scored 83.3 percent to Opus 4.8's 78.9. But on SWE-Bench Pro, the harder test of fixing real open-source bugs, Opus still comes out ahead. So the honest read is not "Grok is better." It's "Grok is about as good, for a lot less." Different claim, and a more interesting one. The hands-on test Benchmarks are one thing, real work is another. The New Stack ran a head-to-head, giving both models the same three jobs in one real Rust project (the fd file-finder) inside Cursor, and tracked every token. I'm summarizing their results here, credit to them for actually measuring it. The three tasks were a bug fix, a multi-file refactor, and a feature build. The code both models produced was nearly interchangeable, so the story came down to tokens, time, and cost. On the small bug fix, Opus actually won. Both wrote an identical fix with all tests passing, but Opus did it faster and on fewer tokens. Grok's efficiency edge showed up on the bigger jobs. On the refactor, Grok used about 197K tokens versus Opus's 954K for the same result, roughly a fifth.

Moonshot launched Kimi K3, and within 48 hours it had to stop taking new subscribers. Not because the model flopped, but because too many people wanted it. That's a strange kind of problem to have, and it's telling you something important about where AI's real bottleneck now sits. What actually happened Less than two days after Kimi K3 went live, Moonshot froze new subscriptions. The reason was blunt: demand had eaten through its available GPU capacity. In the company's own words, the model got "far more love than we expected," and in 48 hours usage pushed close to the limit of what its hardware could serve. Moonshot handled it reasonably. Existing users kept their access, and the company said it would expand capacity and reopen signups in batches. It also split its plans into two tiers, a general Kimi Membership for web and app use, and a separate Kimi Code Membership aimed at programming work. That split is a hint about which users are burning the most compute. Why the model drew that kind of demand Kimi K3 isn't a minor release. It's an open-weight model at 2.8 trillion parameters, and it reportedly beat Anthropic's Fable 5 and OpenAI's GPT-5.6 Sol on front-end coding tests. Open, cheap, and competitive on real coding is exactly the combination developers pile onto. So they did. The real story: the bottleneck moved Here's the part worth internalizing. For years the hard, expensive problem in AI was training. That's where the giant compute bills and the headlines were. Kimi K3's freeze shows the constraint shifting to inference, the cost of actually running the model for users, every request, every day. Agentic workloads are why. When an AI agent runs a coding task for minutes or hours instead of answering a single prompt, each user consumes far more compute than a chatbot ever did. Multiply that by a viral launch and you hit a GPU wall fast. Moonshot didn't run out of ideas. It ran out of chips to serve the ideas. Why this matters even if you never touch Kimi Thi

I built Skim because I tried to find a Windows email client that doesn't suck that hard and couldn't really find one. It's not rocket science to vibecode one, right? Why has nobody done it before? Or is everyone just okay with bloated Outlook or archaic Thunderbird? Skim - free, open-source, MIT-licensed minimalistic offline-first email client with BYOK AI. Quick feature list: Installer under 5 MB Bring Your Own Key to enable AI features: Anthropic/OpenRouter, or any OpenAI-compatible server (including a local one) No menu. Minimalistic and contextual interface - buttons are shown only when you need them Keyboard-first controls: shortcuts for everything, no mouse needed Sweet warm zine design Super modest resource consumption AI features are pretty basic: Cowriter that can scan your recently sent emails, adopt your style, and then write emails and replies that sound like you "Ask this email" - chat with a particular email; it can read attachments and follow links inside it Agentic search across all connected inboxes; the "Ask your inbox" feature can scan your whole inbox One-click summarization and translation A few things I'm actually proud of under the hood The UI part is easy to vibecode. These bits were not. Getting the installer under 5 MB took real work. panic = "abort" alone dropped about 6 MB of unwind tables from the binary, that's 23% off the NSIS installer. I ship a single crypto backend (ring, with aws-lc-rs switched off) so I'm not compiling a second, unused crypto library into the thing. I even wrote a tiny Vite plugin that deletes legacy .woff fonts, since WebView2 always uses woff2 anyway. Pretty much every dependency in Cargo.toml carries a comment justifying its feature flags in kilobytes saved: rustls = { version = "0.23" , default-features = false , features = [ "ring" ] } # aws-lc-rs would compile a second, unused crypto library. ~2 MB of dead weight. No Electron, no bundled Chromium. Tauri 2 uses the system WebView2, so it installs per-user wit

How I Built an SSR Valorant Tracker with React, Supabase and Live Esports Data I recently built VALTRAIN , a player-focused Valorant platform that combines a Valorant Tracker, VCT match database and weapon skins explorer. The project started as a simple match history lookup page. It eventually became a much larger SSR application with player statistics, esports schedules, match detail pages, replay discovery, multilingual routes and searchable cosmetic data. The Main Product Areas VALTRAIN is divided into three primary areas. 1. Valorant Tracker The Valorant Tracker accepts a Riot ID and region. It can display: Current rank and RR Recent competitive and unrated matches KDA and combat score Headshot, body shot and leg shot data Competitive RR movement Lifetime performance statistics Individual match details and team compositions One challenge was handling incomplete or delayed data from an external player API. The interface needed useful loading, empty and error states instead of leaving users with an endless spinner. 2. VCT Match Database The VCT esports database stores upcoming and completed matches. Each public match can have: Tournament and stage information Team names and series scores Map-level results Player statistics Recent team form Official replay availability Related matches and internal links The project also includes an original VCT performance report generated from completed match records. 3. Valorant Weapon Skins The weapon skins database allows players to browse skins by collection, weapon type, rarity, price and chroma. The main performance challenge was preventing high-resolution media from slowing down the initial page load. Why I Moved the Site to SSR The original version relied heavily on client-side rendering. That worked for user interaction, but it created several problems: Public pages had limited initial HTML Search engines had to execute JavaScript Metadata was harder to control Dynamic routes occasionally returned weak fallback pages Firs

What happens when 5 parallel API calls hit for an expired JWT at the exact same millisecond. Imagine this: You’ve built a sleek, high-performance React dashboard. The UI is sharp, dark mode is gleaming, components are modularized, and React Query is executing parallel data fetches like a grand symphony. You brew a cup of coffee, open the app after lunch, hit refresh, and… BAM! You are immediately booted back to the Login screen. No warnings, no friendly error toasts—just a cold, ruthless redirect. You check your JWT expiration timer. The access token died 5 seconds ago, but your refresh token is valid for another 14 days. So why on earth did your app decide to kick you out like an uninvited party crasher? Welcome to the chaotic nightmare of Token Refresh Race Conditions in Axios Interceptors . In this article, we’ll walk through how parallel React queries can accidentally DDOS your own backend, why standard interceptor tutorials fail in production, how we built a promise-queue lock mechanism to solve it, and the subtle "gotcha" lurking in simple error detail checks that almost broke everything anyway. 1. The Problem: The Dashboard Stampede When a user logs into our app and opens the main dashboard, React Query triggers a stampede of concurrent API requests: GET /api/teams/users/ (Fetch team members) GET /api/teams/addresses/ (Fetch locations) GET /api/auth/profile/ (Fetch user profile) GET /api/auth/activity/recent/ (Fetch activity log) GET /api/notifications/ (Fetch unread alerts) Under normal circumstances, all five requests ride happily on the same valid Bearer <access_token> HTTP header. React App ---------------------------------------------> Django Backend GET /users/ [Bearer valid] ---> 200 OK GET /locations/ [Bearer valid] ---> 200 OK GET /profile/ [Bearer valid] ---> 200 OK The Ticking Time Bomb Fast forward 15 minutes. The short-lived access token expires. The user clicks on the "Analytics" tab. All 5 queries trigger at the exact same millisecond ( T = 0ms