标签：#Web

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. A single honeybee has exactly one move: find nectar, fly it home. Impressive aviation. Add a few thousand more bees and something strange happens. Now they're making honey, cooling the hive, and defending the colony against threats ten thousand times their size, with no Jira board, no standup, and nobody handing out tickets. That jump from "can fetch nectar" to "runs a self-regulating honey factory" is the best mental model I've found for multi-agent AI systems . So let's steal it xD First, what even is an "agent"? Before we throw thousands of them at a problem, it's worth pinning down what one actually is. An AI agent is an autonomous system that performs tasks on behalf of a user (or another system) by designing its own workflow and using available tools . Three things decide how good an agent actually is: The LLM powering it i.e the brain. Its tools which is the hands. The reasoning framework is how it turns tool outputs into the next decision. A single agent is fine. It's our lone bee, and it can do real work. But ask it to research a topic, run heavy calculations, scrape five websites, and write the summary, and you start to feel the ceiling. Multi-agent systems: bees, but for compute A multi-agent system keeps each agent autonomous but lets them cooperate and coordinate inside a structure . The magic isn't any single agent, it's the choreography between them (claude which is famous for that). And there are a few classic ways to choreograph it. 1. The decentralized network (a.k.a. "everyone's a peer") Every agent can talk to every other agent. They share information and resources, and they all operate with the same authority . No boss. Just message-passing. This is your agent network . It's great for emergent, collaborative problem-solv

Or: how I learned a machine might introduce us before my website ever does. Every few years, the internet reinvents discovery. Directories gave way to search engines. Search engines gave way to social feeds. Social feeds gave way to recommendation engines. Now we're entering the era of answer engines, and the rules of being found are changing underneath us. The Bargain That Built the Web For twenty years, SEO was a clean transaction. Create content. Help a crawler understand it. Rank for the right keywords. Receive traffic. First place won. Tenth place lost. Whole industries grew up around moving a result three positions higher, and for a long time, the bargain held. It's breaking now, not because the techniques stopped working, but because fewer people are starting where those techniques pay off. Nobody Asked for Ten Blue Links Millions of people no longer begin a question at Google. They begin at ChatGPT, Claude, Gemini, Perplexity, or Copilot. And the request has quietly changed shape. It used to be: show me ten pages. Now it's: answer my question. That sounds like a small difference. It isn't. In the old model the reader always arrived at your door. Even the tenth result caught a click now and then. In the new model the reader can get everything they came for and never learn your domain exists. Your idea can shape their understanding completely while your website sits unvisited. So the question is no longer only can a search engine find my page? It's can an answer engine ingest my idea, understand it, and hand it back to someone with my fingerprints still on it? I decided to test whether mine could. The Meta-Proof Here's a demonstration you can run yourself. Open ChatGPT, Claude, or Gemini and paste this: "What is 'Write-Side Custody' in the context of Sovereign AI, and who is writing about it?" I ran it. The model didn't gesture vaguely at the idea. Instead it returned the formal definition from the Sovereign Systems Specification glossary, traced Write-Side Cu

Back in May we here at Waggy Labs launched the beta release of our Web Component UI kit " Yumekit ". Yumekit is a pure web component UI toolkit. Upon its release, it was comprised of roughly 36 fully styled and fully functional UI components that work with just about every web architecture straight out of the box. No configuration or setup necessary, all one needs to do is include the Yumekit script (using either a CDN or installed through NPM) and start building. All components come styled out of the box with no need to include any style sheets. Last week, we launched version 0.5. With this latest release, that job is being made easier with the inclusion of new components that add several layout options as well as new Data, Navigation, and Utility components, bringing the total number of components to 51. For us, this toolkit has provided us a framework-agnostic solution for our internal tools as well as any client projects. With over 60 themes spread over 9 well-known (and some brand new) open source Design Systems all built directly into the library, we have plenty of options available to us to keep our designs fresh without needing to spend hours dealing with CSS. It's light-weight, dependency free, and well documented. New in 0.5 Animate The y-animate component allows you to animate entrances and exits for nested components using a few simple configuration attributes. Code The y-code component allows you to display formatted and colorized code, as well as providing a few easy and convenient ways for your users to copy the provided code. Help The y-help component provides a tutorial experience for users of your application with minimal configuration. Simply provide the elements to be highlighted, the messages to be shown, and it handles the rest! Paginator y-paginator provides a configurable set of pagination buttons to help your users navigate through large data sets. Sidebar We had originally included a y-appbar component (which we still do) that had a "Sideba

A full-stack, peer-to-peer coinflip betting game on Solana A full-stack, peer-to-peer coinflip betting game on Solana. Players connect a wallet, create or join on-chain game rooms, and compete head-to-head for 2× the stake. The UI updates in real time over WebSockets, outcomes are resolved on-chain with Orao VRF, and the backend tracks rooms, chat, and match history in MongoDB. I open-sourced coinflip-casino for developers in Solana / Anchor smart contract development . This post walks through what it does, how the pieces fit together, and how to run it locally. Live demo / site: https://www.flip.is/ Why I built this Learn full-stack Web3 game architecture (wallet + program + backend + UI) Study provably fair randomness with on-chain VRF integration Fork and customize a peer-to-peer on-chain betting room model Most tutorials stop at a smart contract or a UI mockup. I wanted a complete vertical slice — wallet flow, on-chain logic, backend state, and a responsive frontend — so you can study or fork a production-shaped codebase. What it does Create a room — Pick Head or Tail, set bet amount, choose SOL or SPL token. Join a room — Browse open games in the live lobby and match against another player. PvP coinflip — When two players are in the same room, the backend triggers on-chain resolution. 2× payout — The winner receives double the bet (fees apply on-chain). Room expiration — Open rooms older than 5 minutes with no opponent are expired and refunded automatically. Portfolio stats — Win count and total games per wallet. Wallet connect — players sign in with a Solana wallet Peer-to-peer rooms — create or join head-to-head matches Architecture at a glance Wallet layer — users connect a Web3 wallet to sign transactions On-chain program — Anchor/Rust logic for escrow, rooms, and settlement Randomness — verifiable flip outcomes via Orao VRF on Solana Real-time layer — WebSocket events push room and flip state to the UI Persistence — MongoDB stores rooms, chat, and historic

People complain that websites are all starting to look the same. They are not entirely wrong. A lot of modern websites do look alike. They have familiar navigation bars, predictable layouts, large hero sections, cards, and responsive grids. Buttons look like buttons. Forms look like forms. But, I would argue that's a good thing. Software is supposed to feel familiar. A website is not a painting. It is not a brand mood board. A website is usually a tool that someone is trying to use to accomplish something. They want to read, buy, search, compare, book, or solve a problem. And when people are trying to get something done, originality is not always a virtue. Familiarity Is a Feature Jakob's Law says: Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know. Users do not arrive at your website as blank slates. They bring expectations from every other website and app they have used. They expect the logo to link home. They expect navigation to be near the top or side. They expect search to look like search. They expect account settings under an avatar or profile menu. They expect mobile navigation to collapse into a menu. When your site follows those expectations, users can spend their mental energy on the task instead of the interface. That is the point. Good design reduces cognitive load. It does not force users to relearn basic interaction patterns just because a company wanted to look different. Different Is Not Automatically Better There is a common mistake in web design: confusing distinctiveness with quality. A site can be visually unique and still be frustrating to use. It can win design awards while annoying the actual people who need to navigate it. Novelty has a cost. Every unusual layout, hidden interaction, custom scroll behavior, strange menu, or clever visual metaphor asks the user to stop and figure out what is going on. If you are building a portfolio, an art proje

nginx Event Loop — Complete Lifecycle Reference A precise, bottom-up reference covering every buffer, syscall, interrupt, and data movement from the moment a TCP packet hits the NIC to the moment a response is sent back. Two concurrent users are used throughout as a concrete example. Table of Contents Foundations — fd and Socket Hardware Layer — NIC, DMA, Interrupts Kernel Structures and All Buffers epoll — How the Worker Waits Efficiently nginx Startup Sequence Complete Request Lifecycle — Two Concurrent Users What Happens While Worker is Busy All Buffers — Master Reference All Syscalls — Master Reference Failure Modes 1. Foundations 1.1 Everything is a File Linux's core philosophy: every I/O resource — files on disk, network connections, pipes, terminals, devices — is represented as a file. This means one unified API ( read , write , close ) works on all of them. The kernel manages the actual resource. Your process holds a token. 1.2 File Descriptor (fd) A file descriptor is just an integer . It is a per-process token that refers to a kernel-managed resource. The kernel maintains a table per process called the fd table — a simple array where the index is the fd and the value is a pointer into the kernel. Process fd table: ┌─────┬───────────────────────────────┐ │ fd │ points to │ ├─────┼───────────────────────────────┤ │ 0 │ stdin │ │ 1 │ stdout │ │ 2 │ stderr │ │ 3 │ listen socket (nginx) │ │ 5 │ User A client connection │ │ 6 │ User B client connection │ │ 12 │ backend connection for User A │ │ 13 │ backend connection for User B │ └─────┴───────────────────────────────┘ 0, 1, 2 are always pre-assigned. Application fds start from 3 upward. The fd is meaningless on its own. It only means something when passed to a syscall — the kernel uses it to look up the real resource. 1.3 Socket A socket is the kernel's internal data structure representing one end of a network connection. Created when your process calls socket() . Lives entirely in kernel RAM. Your process nev

One of the hardest things about going freelance as a developer isn't writing code — it's knowing what to charge. Charge too little and you're basically doing a salaried job without the benefits. Charge too much without backing it up and you scare off clients. Most developers I've spoken to either guessed their rate or copied someone else's. Neither is a great strategy. In this article I want to walk you through exactly how to calculate your freelance day rate properly — based on real numbers, not gut feeling. Why Most Freelancers Get Their Rate Wrong The most common mistake is this: taking your old salary and dividing it by 260 working days. That ignores: Taxes (you now pay both sides of self-employment tax in the US) Unpaid days — holidays, sick days, slow months with no clients Business costs — software, hardware, insurance, accountant fees No employer pension or benefits — you fund all of this yourself If you were earning $80,000 as a salaried developer and you divide that by 260, you get roughly $307/day. But that's actually a pay cut once you factor everything in. The Right Formula Here's the framework: Step 1 — Work out your actual billable days A year has 260 working days. Subtract: Public holidays (~10 days in the US) Your own holiday allowance (~15 days) Estimated sick days (~5 days) Non-billable time: admin, chasing invoices, marketing yourself (~20 days) That leaves roughly 210 billable days. Step 2 — Calculate your real income target Take what you want to take home and gross it up for tax. If you want $70,000 net and your effective tax rate is around 30%, your gross target is roughly $100,000. Step 3 — Add your business costs Software subscriptions, hardware depreciation, liability insurance, accountant — easily $5,000–$10,000/year for a freelance developer. Step 4 — Divide by billable days $110,000 ÷ 210 = $524/day That's your minimum. Price below that and you're losing money compared to employment. A Faster Way — Use a Free Calculator If that maths mad

getComputedStyle(element).fontFamily returns the CSS declaration: "Hiragino Kaku Gothic ProN", "Yu Gothic", "Noto Sans JP", sans-serif . That's not the font that rendered. It's a priority list. The browser picks the first one that's available and contains a glyph for the character being rendered. For Latin text, this distinction usually doesn't matter — Windows, macOS, and Linux have converged on a small set of common system fonts. For Japanese, it matters enormously. The visual weight, stroke contrast, and letterform style of Hiragino, Yu Gothic, and Noto Sans JP are genuinely different. A site designed on macOS (where Hiragino is the system Japanese font) looks different on Windows (where Yu Gothic is the fallback). Here's how to figure out what's actually rendering, and what I learned building Japanese Font Finder to automate it. Why getComputedStyle Doesn't Answer the Question getComputedStyle(el).fontFamily gives you the cascade result — what the browser received after applying all CSS rules. But it doesn't tell you which entry in the stack was selected. The underlying question is: does this font exist on this system, and does it have a glyph for this specific character? For Japanese, both conditions matter. A font might exist on the system but only cover a subset of kanji (common with CJK fonts that split across multiple files). The browser will use that font for characters it covers, and fall back for others. Canvas-Based Font Detection The classical technique uses a <canvas> element to measure text rendered with each font in the stack: function getFallbackWidth ( canvas , char ) { const ctx = canvas . getContext ( ' 2d ' ); ctx . font = `16px monospace` ; // known-available baseline return ctx . measureText ( char ). width ; } function testFont ( fontName , char ) { const canvas = document . createElement ( ' canvas ' ); const ctx = canvas . getContext ( ' 2d ' ); ctx . font = `16px " ${ fontName } ", monospace` ; return ctx . measureText ( char ). width ; }

Time zones are one of those topics that look simple until you ship something and a user in another country sees the wrong time. Here are the traps I keep seeing, and how to reason about them in 2026. UTC is not a time zone, and GMT is not UTC UTC (Coordinated Universal Time) is a time standard, not a region. GMT is a time zone that happens to share the same offset as UTC most of the year. For storage and math, always think in UTC. Treat GMT as just another named zone. Rule 1: store timestamps in UTC Store every instant as UTC (or an epoch value). Convert to a local zone only at the edges, when you display to a user. If you store local times, you will eventually lose the offset and never recover the true instant. Rule 2: an offset is not a zone +09:00 tells you the offset right now. It does not tell you the zone, because zones change offset across the year due to daylight saving time. Store the IANA zone name (like America/New_York ), not just the offset. The offset is derived from the zone plus the date. Rule 3: DST is where it hurts The same wall-clock time can happen twice (fall back) or never (spring forward). Scheduling "9am every day" is a zone-aware operation, not an offset-aware one. Libraries like the built-in Intl.DateTimeFormat and Temporal (now widely available) handle this correctly if you give them a zone name. new Intl . DateTimeFormat ( ' en-US ' , { timeZone : ' Asia/Tokyo ' , dateStyle : ' short ' , timeStyle : ' short ' , }). format ( new Date ()); Rule 4: scheduling across teams is an overlap problem For a distributed team, the useful question is not "what time is it there" but "when do our working hours overlap". That is a set-intersection over each person's 9-to-5 expressed in UTC. A tool for the human side When I just need to eyeball overlaps and pick a meeting time without writing code, I use the free tool I built: ZonePlan , a time zone meeting planner and live world clock. If you want the practical playbook for picking meeting times, I wrote

One of the biggest realizations I've had over the last year wasn't about software. It was about focus. When I first started building KiwiEngine, I wanted it to power everything. Business software. CRMs. Inventory systems. Scheduling platforms. Accounting tools. SaaS products. If someone could build it, I wanted KiwiEngine to support it. Technically, I still do. But something changed. I realized there is a difference between building software that can solve every problem and trying to solve every problem yourself. Those aren't the same thing. The Architecture Never Changed KiwiEngine is still designed to power business applications. Nothing about the architecture changed. The modules. The APIs. The philosophy. The engine remains general-purpose. What changed was my focus. Build What You Understand I started asking myself a simple question. Who do I actually understand? Not as a developer. As a creator. The answer wasn't accountants. It wasn't HR departments. It wasn't inventory managers. The answer was musicians. Artists. Game developers. Creators. Builders. Those are the people whose problems I experience every day. Those are the workflows I naturally understand. Open Source Changes The Equation One of the beautiful things about open source is that I don't have to build every application. I can build the engine. I can document it. I can share the philosophy. Someone else can build the CRM. Someone else can build the scheduling platform. Someone else can build the accounting software. Meanwhile, I can focus on building the creative tools I genuinely want to use. The Best Proving Ground Today, KiwiEngine's proving ground is becoming: Artist websites EPKs Music production tools Digital storefronts Creative workflows Game development Media platforms Not because they're the only things KiwiEngine can build. Because they're the things I care deeply enough to refine every day. And I think that creates better software than chasing every possible market ever could.

Hey DEV community! 👋 I've been building web apps for a while, and I noticed there was no good place to discover and rate web-based OS projects — those cool browser-based operating systems you can run without installing anything. So I built Web OS Community 🎉 What is it? A platform where you can: 🔍 Browse web-based OS projects (Windows XP, Ubuntu, macOS clones, and more) ⭐ Rate your favorites with a global rating system 🏷️ Filter by tags (webos, demo, linux, macos, windows...) 📤 Submit your own web OS project via GitHub PR Why I built this The existing resources were scattered — some projects on GitHub, some on random personal pages. I wanted a central hub where developers could showcase their work and users could find these cool experiments easily. Tech stack Frontend: Vanilla JS / HTML / CSS (no frameworks, keeping it lightweight) Backend: Supabase (PostgreSQL + RLS policies) Auth: Custom RPC-based authentication Hosting: GitHub Pages + Cloudflare Workers Some features Global rating system (one vote per user per project) Admin panel for managing submissions Tag-based filtering Dark mode UI 🌙 Check it out! 🔗 web-os-community.tfhy5321.workers.dev If you have a web OS project, feel free to submit it! PRs are welcome 🙌 What web-based OS have you seen that blew your mind? Drop it in the comments!

I've been using Home Assistant for a few years and Trading212 for longer than that. It was inevitable these two things would end up connected. The Trading212 API is surprisingly good — portfolio value, individual positions, pies, dividends, all there. So I wrote a custom integration to pull it all into HA as sensors, then a Lovelace card to make it actually look decent on a dashboard rather than a wall of entity rows. The card does zero-config auto-discovery which was the bit I spent the most time on. You drop it on a dashboard and it finds your sensors automatically — no copying entity IDs, no manual config unless you want it. Five card types: portfolio overview with a sparkline, scrollable positions list, pies with goal progress, and a combined one if you want everything in one card. The sparkline was fiddly. HA's recorder only writes state changes, not regular samples, so if your portfolio value is flat between polls the chart has gaps. Had to smooth over those client-side. The part I use most though is the automations. Every weekday at 8am Alexa tells me where I stand: action : - action : notify.alexa_media_kitchen data : message : > Portfolio is worth {{ states('sensor.trading212_total_value') | float | round(0) | int }} pounds. Today you are {% if states('sensor.trading212_pnl_today') | float >= 0 %}up{% else %}down{% endif %} {{ states('sensor.trading212_pnl_today') | float | abs | round(2) }} pounds. data : type : tts And Friday at 6pm I get the weekly version with P&L for the week and which position moved the most. I like that it just tells me — if the market's had a bad week I'd probably avoid opening the app, but Alexa doesn't give me the option to ignore it. Both the integration and the card are on GitHub. The card is in HACS as a custom repo while it waits for default catalogue approval: https://github.com/Smart-Home-Assistant-UK/lovelace-trading212-card I wrote up the full setup with all the automation YAML here if you want to copy the whole thing: ful

In my journey as a backend developer, I had already spent time working with APIs, databases, authentication flows, and background processing. I understood the basic idea that not everything should occur within a request-response cycle, especially when dealing with expensive operations such as sending emails, processing files, or generating reports. Offloading work to the background felt like a solved problem to me. That confidence was exactly what led me into confusion. When I first encountered message brokers and task queues, they looked like different names for the same idea. Both involved queues, both involved workers, and both involved asynchronous processing. In my head, the distinction didn’t seem important, so I treated them interchangeably and assumed that choosing one over the other was just a matter of preference or framework availability. The real issue was that I had not yet understood the difference in intent between communication and execution. What I thought was a simple design choice actually turned into an architectural mistake that affected how I structured an entire system. How I Misunderstood the Problem At the time, I was building systems where the backend had to handle multiple heavy operations. A user could upload files, request reports, or trigger processes that should not block the main API response. Naturally, I reached for a queue-based solution because it is the standard answer for background work. However, instead of asking what role the system needed to play, I focused on what tool could make things asynchronous. That small shift in thinking created the confusion. I assumed that anything that gets delayed or processed later should automatically go into a queue, without distinguishing whether I was dealing with a job that must be executed or an event that other services should react to. This is where I started building the wrong abstraction. Where Task Queues Actually Fit A task queue exists primarily to assign work that must be complete

Most developers treat SEO like that one dependency you know you need but keep putting off. You build a fast, clean site with solid architecture, then hand it off to a "marketing person" who asks you to add keyword-stuffed meta descriptions. Here's what changed in 2026: search engines place heavy emphasis on Core Web Vitals, which measure loading performance, interactivity, and visual stability of web pages. The technical foundation you're already building? That's 80% of modern SEO. Let me break down what actually matters when evaluating SEO services as a developer. The Technical Reality Check Technical SEO is the foundation that everything else sits on. On-page optimization and link building amplify a technically sound site. Applied to a technically broken site, they produce unpredictable, often disappointing results. If an SEO service can't speak your language about INP metrics, structured data, or mobile-first indexing, run. What Dev-Focused SEO Services Should Cover Core Web Vitals (Not Just PageSpeed Scores) Core Web Vitals (LCP, CLS, INP) are confirmed ranking factors — INP replaced FID in March 2024. Any SEO service still talking about First Input Delay is using outdated information. What to look for: Field data analysis from real users (not just lab tests) Specific fixes for Interaction to Next Paint Understanding of when to optimize vs. when to rebuild Crawlability and Rendering Google now clarifies that pages returning non-200 status codes (like 4xx or 5xx) may be excluded from the rendering queue entirely. If you're running a JavaScript-heavy framework, this matters. Red flag: SEO services that don't understand Server-Side Rendering (SSR) or Static Site Generation (SSG). Structured Data Implementation Structured data helps search engines understand what your content is about, not just what it says. In 2026, this matters for traditional search and AI search alike. Schema markup isn't just about rich snippets anymore. It's how AI systems like ChatGPT and Per

The problem: I kept missing big moves on Polymarket because I had no way to see what the biggest traders were betting on in real time. So I built WhaleTrack — a free, no-signup tool that shows you exactly what top Polymarket whales are buying and selling. What it does Live whale activity feed — see the last 40 trades from top wallets, updated on refresh Whale leaderboard — P&L, win rate, trade count for the biggest accounts No login, no ads, no fluff — just the data How it works The whole thing is vanilla HTML/CSS/JS deployed on Vercel with two serverless functions: /api/whales.js — hits the Polymarket leaderboard API, fetches position stats for each whale, calculates win rates from closed positions /api/activity.js — pulls recent trades for each whale wallet in parallel, filters out internal combo transactions (no title / zero price), and returns the 40 most recent trades The serverless layer solves CORS — Polymarket's data API doesn't allow browser requests, so everything goes server-side. Tech stack Frontend: Vanilla HTML/CSS/JS (zero dependencies) Backend: Vercel serverless functions Data: Polymarket public data API Deploy: Vercel (free tier) Biggest lesson Filtering bad data is half the work. The raw API returns combo trades and internal transactions that show up as "Unknown Market @ 0¢" — useless noise. Had to figure out which fields to check (title, price > 0) to strip them. Also: win rate calculation is tricky when most whales have unrealized profits. Showing "—" instead of 0% is more honest. Try it WhaleTrack → Also launched on Product Hunt today if you want to show some love: Product Hunt Built this in a weekend. Happy to answer questions about the Polymarket API or Vercel serverless setup.

For a long time, I hesitated to share my work. I kept telling myself: "If I post a simple hero section, a basic Bootstrap grid, or a landing page clone, people will judge me. They’ll think I’m not a 'real' developer yet." But today, I saw a video of a developer who built a complete Netflix clone using only HTML & CSS in just 4 hours https://x.com/Aditwariii/status/1681403710457643009?s=20 . It made me stop and think. It’s easy to get so obsessed with complex frameworks, cloud architectures, and database optimizations that we begin to look down on the fundamentals. But here is the psychology of software engineering that we often ignore: Every master was once a beginner: The engineers managing complex distributed systems today started exactly where we are—struggling to center a div and fighting with CSS media queries. Shipping beats hiding: Building a clean, responsive interface in 4 hours shows speed, focus, and attention to detail. Those are core professional hygiene habits. Code is for humans, not just machines: Before we write APIs or database queries, we must master how a human being actually interacts with our interface. I’m letting go of the fear of being judged for "simple" things. From now on, I am building in public. Whether it’s a massive full-stack application or just a beautifully aligned hero section, it is proof of active practice and continuous momentum. Massive respect to [ https://x.com/Aditwariii?s=20 Check out Aditya Tiwari on X. POLYMATH 🧑‍💻 sde @IEX_INDIA_ ] for the inspiration and the reminder to keep shipping! 👇 What is a "small" project or layout you built recently that taught you a major lesson? Let's connect in the comments.

How we handle complex EPUB structures for AI translation without breaking navigation and metadata At LectuLibre , we built an AI‑powered book translation service. Users upload an EPUB, and our pipeline translates the text using LLMs like Claude and DeepSeek. That sounds straightforward until you have to parse and rebuild a valid EPUB without mangling the table of contents, internal links, or styles. I’m sharing the real‑world challenge we faced, how we chose our tooling, and the ugly corners we discovered when dealing with real‑world EPUB files. The Problem: EPUB is a Messy Zip File An EPUB is essentially a ZIP archive containing XHTML, CSS, images, and an OPF manifest. It’s a well‑defined standard (EPUB 3.2), but in practice publishers produce files that bend the rules: missing container.xml , inline styles that break after translation, and structural quirks that make parsing fragile. Our translation process needed to: Accept any EPUB the user throws at us. Extract all text content while preserving the exact structure. Send each paragraph to an LLM for translation. Re‑insert the translated text into the original XHTML files. Repackage everything into a new, valid EPUB. Step 4 is the tricky part: the translated text can be longer or shorter, it may contain characters that need escaping, and the surrounding markup must remain intact. Our Approach: Use ebooklib with a Dose of Defensive Coding We evaluated several Python libraries: epub (pypub) – too simple, no editing support. lxml + manual zip – too much boilerplate. ebooklib – full read/write with a clean API. We went with ebooklib . It provides an object‑oriented model of the EPUB structure, allows us to iterate over documents, and can write a new EPUB from the modified objects. The downside: its documentation is sparse and it can choke on malformed files. We had to layer on a lot of validation. Step 1: Loading and Validating the EPUB import ebooklib from ebooklib import epub def load_epub ( epub_path : str ) -> ep

Java 26 was officially released in March 2026, and after spending the past three months exploring its new features, experimenting with preview APIs, and using it in personal projects, I think it's a good time to share my impressions. Unlike launch-day articles that simply list every new feature, this is a practical look at what actually stood out to me after having some time to work with Java 26. Some improvements are immediately useful, while others feel like building blocks for the future of the language. Java continues its predictable six-month release cycle, and Java 26 is another example of gradual, thoughtful evolution rather than dramatic change. In this article, I'll cover the features I found most interesting, what I like, what I probably won't use right away, and whether I think Java 26 is worth upgrading to. Why Upgrade to Java 26? Every Java release makes the platform: Faster More secure Easier to write Better for cloud applications Even if you don't immediately use every new feature, upgrading allows you to benefit from JVM optimizations and improved tooling. 1. Better Performance Java 26 continues improving the JVM with optimizations for: Faster startup Better garbage collection Reduced memory usage Improved JIT compilation Most applications will benefit automatically without changing a single line of code. 2. Improved Pattern Matching Pattern matching keeps becoming more powerful. Instead of writing: if ( obj instanceof String ) { String text = ( String ) obj ; System . out . println ( text . length ()); } You can simply write: if ( obj instanceof String text ) { System . out . println ( text . length ()); } Cleaner code with less casting. 3. Record Improvements Records remain one of Java's best additions for immutable data. public record User ( Long id , String name , String email ) {} Instead of writing dozens of lines containing: constructor getters equals() hashCode() toString() Java generates them automatically. 4. Better String Templates (Previe

Most guides to OTP testing in Playwright include a function that looks something like this: function extractOtp ( emailBody : string ): string { const patterns = [ / \b(\d{6})\b / , /code [ : \s] + (\d{4,8}) /i , /verification [ : \s] + (\d{4,8}) /i , /OTP [ : \s] + (\d{4,8}) /i , ]; for ( const pattern of patterns ) { const match = emailBody . match ( pattern ); if ( match ) return match [ 1 ]; } throw new Error ( ' OTP not found in email body ' ); } This function is fragile. It breaks when the email template changes. It returns false positives when the email body contains order IDs or timestamps. It requires you to maintain regex patterns for every email provider your app might use. There is a better way. The Problem with Regex OTP Extraction When your app sends a verification email, the OTP is buried somewhere in the HTML body. To extract it you need to: Fetch the raw email body Parse HTML or plain text Apply regex patterns that match your specific email format Handle edge cases — 4-digit vs 6-digit codes, codes in tables, codes in buttons Every time your email provider changes their template, your regex breaks. Every time you add a new auth provider, you write new patterns. It is maintenance overhead that compounds forever. The right place to extract the OTP is at the infrastructure layer — before the email even reaches your test suite. How ZeroDrop Extracts OTPs at the Edge ZeroDrop catches emails at Cloudflare's edge before storing them. When an email arrives, the worker runs OTP detection on the body and stores the result as a structured field alongside the raw email. By the time your test calls waitForLatest() , the OTP is already extracted and sitting in email.otp . No regex. No HTML parsing. No maintenance. const email = await mail . waitForLatest ( inbox ); email . otp // "847291" — already extracted Setup npm install zerodrop-client No API key. No signup. No environment variables. Basic OTP Test import { test , expect } from ' @playwright/test ' ; import

I'm building LOOM — a small open-source language that is a machine-checked trust layer for AI-written code. I don't write it by hand anymore: an organism I built grows it, day and night, on my own machine. This is Day 6, and the whole day went to one thing — WebAssembly . Why this was a real test LOOM already runs three ways: an interpreter, and backends that compile checked code to Python and JavaScript. The thesis is "trust survives translation" — effects and provenance, proven once, hold the same on every target. WebAssembly is the strongest test of that: a low-level stack machine with linear memory, nothing like Python or JS. And there was a constraint. This machine's clang has no wasm target, and I install nothing paid or heavy. So I don't compile to wasm through a toolchain — I emit the wasm bytes myself (LEB128, the type / function / memory / global / export / code sections, the i32 stack machine) and run them through node's built-in WebAssembly . Zero dependencies. From fib to a value runtime, in a day Every step was prototyped and proven (wasm output == interpreter output) before it touched the kernel: The integer core — arithmetic, comparison, if , first-order calls and recursion. fib(10) becomes 61 bytes of real WebAssembly and returns 55, identically on the interpreter, Python, Node and wasm. A value runtime — let and integer lists in a real linear-memory heap (a bump pointer + a $cons cell allocator; head / tail are i32.load , empty is i32.eqz ). A list sums and folds by recursion, inside wasm. Sum types — (variant Tag e) becomes a tagged cell [tag-id | payload] ; match loads the tag, compares, binds the payload, branches. You can watch it: the live playground has a Compile → WAT button and WASM · fib / list-sum / match examples. Type a program, see it become real assembly, in your browser. Honest scope: ints, let , integer lists and sum types compile to wasm today. Records, closures and effects are the next frontiers (closures are the hard one — a func