标签：#ev

Previously I have a macOS App I use myself, gemini-live-translate-macos . It uses ScreenCaptureKit to directly capture audio from a specified App, eliminating the need for virtual sound cards like BlackHole. It then sends the audio to the Gemini Live API for real-time translation, outputting Traditional Chinese subtitles while playing Chinese audio. I've written two posts about the development process: the first one was about building it from scratch using AGY CLI, and the second one was about using Claude Code to take it from "functional" to "user-friendly." The starting point for this new addition was simple: I saw a document for "Real-time Transcription" added to the Live API. Since I was already connected to the Live API, I thought adding a pure transcription mode would just be a matter of changing a few parameters. However, after checking the documentation, I realized that Google released two models with very similar names but very different capabilities at once. The specific feature I actually wanted (speaker diarization) wasn't available at all on the model I originally thought it was. Two Models with Names Differing by Only Two Words Let's lay out the differences first; this is the part I spent the most time figuring out: gemini-3.5-transcribe-live gemini-3.5-transcribe API Used Live API (WebSocket streaming) Interactions API (Standard HTTP request) Usage Scenario Transcribe while speaking Upload the whole file after recording Speaker Diarization Not supported Up to 8 speakers Word-level Timestamps Not supported Supported Audio Length 10 minutes per session 1 hour (30 mins with diarization) Smart Mode SMART available smart is mutually exclusive with diarization Interim Subtitles Has interimInputTranscription Not applicable The official documentation on the Live page's limitations section is very blunt: Speaker diarization is not supported in live streaming sessions. For speaker diarization, use the non-streaming Audio transcription endpoint. So, "seeing who

React is fast by default, until it isn't. The good news is that the vast majority of real-world performance issues trace back to a small set of patterns. Fix those, and you rarely need exotic optimizations. Measure before you optimize The first rule of performance work is to never guess. Use the React Profiler and the browser's performance panel to find what actually renders, and how often. Premature optimization Wrapping every component in memo and every value in useMemo adds complexity and can make things slower. Optimize the hot paths you have measured, not the ones you imagine. Avoid unnecessary re-renders A re-render isn't inherently bad, but cascading re-renders of expensive subtrees are. The most common culprit is passing a freshly-created object or function on every render. `// ❌ A new array + handler every render breaks memoized children function ProductList({ products }) { return ( - p.inStock)} onSelect={(id) => track(id)} /> ); } // ✅ Stabilize derived data and callbacks function ProductList({ products }) { const inStock = useMemo( () => products.filter((p) => p.inStock), [products], ); const handleSelect = useCallback((id) => track(id), []); return ; } ` Memoize the right things React.memo , useMemo and useCallback are tools for keeping referential identity stable across renders. Reach for them when: a child component is expensive to render, and it receives props that would otherwise change identity every render. Better still, let the React Compiler handle memoization for you. Adding it is a single dependency: npm install babel-plugin-react-compiler Ship less JavaScript The fastest code is the code you never send. Code-splitting and lazy loading keep the initial bundle small. `import { lazy, Suspense } from 'react'; const Editor = lazy(() => import('./Editor')); export function Panel() { return ( }> ); } ` Move work to the server With React Server Components, data fetching and heavy rendering can happen on the server, shipping only the resulting HTML an

Web accessibility stopped being optional. The European Accessibility Act has been enforced since June 28, 2025, and it reaches any business that sells products or services to EU customers, regardless of where that business is based. In the United States, the Department of Justice's ADA Title II rule requires public bodies to meet WCAG 2.1 Level AA by April 2026, and private-sector lawsuits keep climbing every year. For a company shipping a website or app, that means a real deadline and real financial exposure. EAA penalties can reach 5% of annual turnover for large companies, and a single ADA complaint can cost tens of thousands to settle before you have fixed anything. The good news: the standard everyone points to, WCAG 2.1 AA, is well-defined and achievable. The bad news is that the most heavily marketed shortcut, the accessibility overlay widget, does not get you there and can make your legal position worse. This guide covers what the law actually requires, why the quick fix backfires, and how we build accessibility into a site from the start instead of bolting it on at the end. What the law actually requires Three names come up constantly, and they fit together cleanly. WCAG 2.1 Level AA is the technical standard. The EAA and the ADA are the laws that, in practice, point back to it. In Europe, meeting WCAG 2.1 AA satisfies the digital requirements of the harmonized EN 301 549 standard, which is how you demonstrate EAA conformance. WCAG is organized around four principles, known as POUR: content must be Perceivable, Operable, Understandable, and Robust. In concrete terms that means text alternatives for images, sufficient color contrast, full keyboard operability, visible focus states, labeled form fields, and markup that screen readers can parse. Level AA, not AAA, is the bar nearly every regulation references. Note the EAA exempts the smallest businesses, those under 10 employees and under two million euros in turnover, but that carve-out is narrower than most

Next.js gives you almost everything you need to rank well out of the box, and most teams still ship sites that Google struggles to read. The framework is not the problem. The problem is that SEO gets treated as a final checkbox instead of an architectural decision, so metadata ends up scattered, content renders on the client, and the structured data never gets written. The App Router changed how all of this works. The generateMetadata function, file-based conventions for sitemap.ts and robots.ts , and Server Components as the default each remove a class of SEO bug that used to be common in the Pages Router. But they only help if you use them deliberately. This is the playbook we follow when we build a Next.js site that has to rank, the same approach behind this site. It is opinionated and concrete: where to put metadata, which files to ship, how to handle structured data and multiple languages, and why Core Web Vitals is an SEO feature rather than a performance afterthought. None of it requires a plugin. Render on the server so Google sees real HTML The single biggest SEO win in Next.js is also the easiest to get wrong: make sure your indexable content is in the HTML on the first byte. Googlebot will execute JavaScript, but it does so on a delay and with no guarantees. Content that depends on a client-side fetch can be missed, indexed late, or indexed empty. Server Components are the default in the App Router, so this is mostly about not opting out. Keep 'use client' at the leaves of your tree, on the button that needs an onClick , not on the page that holds your copy. Fetch your data in the Server Component and pass the rendered result down. If you can view the page source and read your headline and body text without JavaScript, you are in good shape. Master the Metadata API instead of next/head In the App Router you never touch next/head . Every route exports either a static metadata object or a dynamic generateMetadata function, and Next.js merges and d

For fifteen years the goal of search was simple: rank on page one and earn the click. That contract is breaking. More people now ask ChatGPT, Perplexity, Gemini and Google's AI Overviews a question and read the synthesized answer without ever visiting a blue link. If your brand is not in that answer, you are invisible to them, no matter how well you rank. This is the gap Generative Engine Optimization closes. GEO is the practice of structuring your content and your site so that large language models retrieve it, trust it, and cite it when they answer a question in your space. It overlaps with SEO but it is not the same job. One study from the GEO firm Brandlight found the overlap between top Google links and the sources AI tools actually cite has fallen from around 70% to under 20%, and the gap is widening. The payoff is real, not theoretical. AI referrals convert far better than cold organic traffic because the visitor arrives pre-qualified by the answer that sent them. Vercel has reported that roughly 10% of new signups now come from ChatGPT, and LLM-referred visitors have been measured converting at 15.9% from ChatGPT against under 2% for typical organic search. Here is how we approach GEO for the sites we build. SEO earns clicks, GEO earns citations The mental shift is the whole game. Traditional SEO optimizes a page to win a position in a ranked list of links. GEO optimizes a passage to be quoted inside a generated answer. A model does not "rank" your page; it retrieves chunks of it, weighs them against everything else it pulled, and decides whether to repeat your claim and name you as the source. That changes what good content looks like. Models favor passages that are self-contained, factual, and quotable: a clear definition, a specific number, a direct answer in the first sentence. Burying the answer three paragraphs down, the way you might to keep a reader scrolling past ads, is exactly wrong here. Lead with the claim, then support it. Write so a model can

Next.js 16 is the biggest release since the App Router landed, and the upgrade is not a one-line bump. The caching model changed shape, params and searchParams are now promises everywhere, Turbopack runs your builds by default, and middleware.ts is on its way out in favour of proxy.ts . None of that is hard on its own. The trouble is that the changes touch almost every dynamic route in a real app at once, so a rushed upgrade tends to fail in a dozen small places rather than one obvious one. We run this site on Next.js 16, and we have moved client projects across the same gap. The pattern that works is boring and reliable: read the codemod output, fix the async APIs first, decide your caching strategy deliberately instead of letting the old implicit behaviour leak back in, then clean up the renamed files. This guide walks through that order, with the specific gotchas that cost the most time. If you are still on Next.js 13 or 14, the same steps apply, you just have more of them to work through. Run the codemod, then read what it could not fix Start with the official upgrade command. It pulls the right versions of next , react , and react-dom , and runs the codemods that handle the mechanical rewrites for you. npx @next/codemod@latest upgrade latest The codemod is good, but it is not magic. It will happily wrap your params access in await where the shape is obvious, and skip anything indirect, a params object passed into a helper, destructured two functions deep, or read inside a generateMetadata you wrote by hand. Treat the codemod as the first 80%, not the finish line. Once it has run, do a clean install and a type check before you touch anything else. With typescript.ignoreBuildErrors set, as it is on many projects, the build will not catch these for you, so run the type checker yourself. rm -rf node_modules .next && npm install && npx tsc --noEmit The errors that come back are your real to-do list. Most of them will be the async API change, which is the next sectio

Nuance is the thing that gets you levelled up, and hedging is the thing that gets you levelled down. They sound almost identical from the outside, and the difference is entirely structural. Ask a junior engineer whether to use SQL or NoSQL and you get an answer. Ask a senior engineer and you often get "well, it depends", which is correct, and delivered badly it costs them the round. The problem is not the nuance. It is the order. Hedging leads with the uncertainty and never arrives at a decision. Judgement leads with the decision and then shows the uncertainty around it. Same knowledge, opposite impression. Why hedging reads badly An interviewer is trying to answer one question: would I trust this person to make a call without me in the room. A candidate who lists options without choosing has actively failed to demonstrate the thing being assessed, no matter how well they understand the options. There is a second, less obvious cost. Refusing to commit removes the interviewer's ability to go deeper. They cannot probe a decision you did not make, so the conversation stays shallow, and shallow conversations produce mid-level scores by default. A candidate who says it depends and stops has told the interviewer nothing except that they know it is complicated. Everyone at this level knows it is complicated. The four-part structure This works for almost any technical choice you will be asked about, and it takes about twenty seconds to deliver. Commit. Name what you would actually ship. One sentence, no preamble. Justify. Give the specific reason, tied to the constraints in the question rather than to general virtue. Cost. Say what you are giving up. Every choice loses something and naming it is the seniority signal. Trigger. State the condition that would change your mind, and ideally what you would watch for it. Notice that all the nuance from "it depends" is present. It is simply arranged behind a decision instead of in place of one. Would you use a relational database o

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 couple of posts back we spent a while inside XOR distance , then used it to build Kademlia , the DHT algorithm that lets a network find anything without a directory. Kademlia: Algo That Turned XOR Distance Into a Network Athreya aka Maneshwar Athreya aka Maneshwar Athreya aka Maneshwar Follow Aug 26 Kademlia: Algo That Turned XOR Distance Into a Network # webdev # programming # beginners # algorithms 20 reactions Add Comment 6 min read I promised that algorithm shows up "under BitTorrent, IPFS, Ethereum." Today we cash that check. We're taking BitTorrent apart, piece by piece, and Kademlia is going to walk right back in through the side door. Also, fun fact before we start: a suspicious number of people on Reddit think Bram Cohen, the guy who wrote BitTorrent alone in Python in 2001, is secretly Satoshi Nakamoto. I'm not saying it's true. I'm saying that by the end of this post you'll understand why people keep saying it. The number that should not have been possible In 2004, a measurement firm called CacheLogic reported that BitTorrent alone was responsible for roughly 35% of all internet traffic. More than every other peer to peer network combined. More than the entire web. One protocol. Written by one guy. No company. No datacenter. No servers anywhere with "BitTorrent Inc" on the rack. That last part is the whole story. Every "normal" system you've ever worked on scales by throwing money at it: bigger box, more replicas, a CDN in front. BitTorrent had nobody to throw money at anything, so every hard problem, capacity, trust, scheduling, incentives, discovery, had to get solved inside the protocol itself . Problem 1: the client-server ceiling has a name Distributing a file in 2001 meant one server, one uplink, and every download eating

The finding EventCatalog exposes a common monorepo failure mode: generated code may exist, its producer may be green, and the real downstream consumer can still fail. Its Langium language server generates AST, grammar, module, and syntax files; a sibling VS Code extension consumes that output alongside the workspace SDK and visualiser. The useful question is therefore not "did generation finish?" It is whether the repository can execute the complete consumer closure from declared dependency hydration through the package that needs the generated result. The contract boundary Ota models the generated output separately from the tasks that establish and consume it: artifacts : language-server-ast : kind : generated_source producer : language-server:generate paths : - packages/language-server/src/generated/ast.ts - packages/language-server/src/generated/grammar.ts - packages/language-server/src/generated/module.ts - packages/language-server/syntaxes/ec.tmLanguage.json - packages/vscode-extension/syntaxes/ec.tmLanguage.json inputs : - packages/language-server/src/ec.langium - packages/language-server/langium-config.json tasks : vscode-extension:build : depends_on : - language-server:generate - language-server:build - sdk:build - visualiser:build requires_artifacts : - language-server-ast The setup task owns typed, frozen-lockfile pnpm hydration with the language-server package filter. That removes bespoke install shell glue without pretending the dependency path is harmless: it reaches the package registry, so the selected closure is intentionally not routine agent-safe execution. Humans and CI can run the declared verification workflow; unattended agents cannot silently acquire that networked setup authority. What Ota had to learn This pressure case made two platform requirements concrete. Generated-source lineage had to remain visible at consumer admission and in execution evidence, rather than surfacing only after a build failure. And pnpm dependency hydration needed a

A ideia de um sebo que não perde estoque: No primeiro período, nosso grupo desenvolveu um Sebo Virtual. O objetivo era resolver a dificuldade de sebos tradicionais em conciliar estoque físico e virtual, com pagamento via PIX e envio de recibo por e-mail. Minha responsabilidade foi a engenharia de prompt utilizando o Lovable. Quando a IA não entendia o que eu queria: Os primeiros prompts retornaram resultados incompletos. Ao solicitar "explique o código por trás da aplicação", a resposta foi genérica e não detalhou a integração com o banco de dados. Também houve dificuldade em fazer a ferramenta compreender fluxos específicos, como leilão de itens, validação de cupons e cálculo de frete por CEP. O que mudou quando usei diagrama e contexto: O resultado melhorou quando passei a incluir contexto e artefatos. Três prompts funcionaram bem: para wireframe, enviei o diagrama e solicitei o protótipo das telas; para o leilão, pedi quatro telas com checkout e histórico de transações; para o back-end, solicitei as linguagens utilizadas e o fluxo de integração ao banco preservando as informações da documentação. Com isso, identifiquei a stack gerada: React com TypeScript no frontend e Supabase no backend, com consultas como from('pedidos').select('*').eq('usuario_id', id) . Do sebo para qualquer loja online: As regras implementadas, como cupons LIVRO10 e SEBO20, frete proporcional ao peso e checkout via PIX para o endereço base na Rua dos Livros, 707, João Pessoa, são aplicáveis a qualquer e-commerce de pequeno porte. O método permite transformar uma ideia em protótipo navegável em poucas horas. O que levo disso para a carreira? O projeto mostrou que, além do código, a capacidade de formular perguntas claras e organizar a documentação em fluxograma e diagrama de classes é fundamental. Foi meu primeiro case prático e base para portfólio na área de dados e produto. EN Summary: As a first-semester student, our team built a Virtual Bookstore to manage physical and online inventory w

Microsoft is placing greater emphasis on controlling disruption in Azure Kubernetes Service (AKS) Node Auto-Provisioning (NAP), publishing new guidance to help platform teams balance the efficiency benefits of automated node consolidation with application availability. By Craig Risi

Confusion is a generally accepted side effect of mystery box shows. They slather on secrets with the promise of a satisfying payoff in the end, and sometimes the cast and crew even have a hard time following what's going on. But even by the standards of the genre, Dark Matter is extreme. Its multiversal premise, […]

With the curtains closed and the power cable nearby, this affordable Full HD smart projector is a compact delight.

California residents have a legal right to access the data that companies collect about them. Actually exercising that right is a burdensome nightmare.

If you run ClickHouse in production, you're probably on 26.3 LTS. And now 26.8 LTS has been announced, which means the LTS-to-LTS upgrade conversation starts again. Here's the thing most release posts skip: this is not a one-release hop. Going from 26.3 LTS to 26.8 LTS means crossing 26.4, 26.5, 26.6 and 26.7 as well. Every breaking change in those four releases applies to you, and some of the ones most likely to ruin your day aren't in 26.8 at all. So instead of writing another "here are the 26.8 features" post, I wanted to write the thing I'd actually want before scheduling this upgrade: what breaks, what silently changes, what order to do things in, and what you get for the trouble. A note on release timing As of writing (27 August 2026), 26.8 has been announced but is not fully released yet. The release branch is cut and versioned (v26.8.1.1-lts), but the tag and Docker images have not been published yet, and the upstream changelog still marks the 26.8 section as in progress. By the time you read this, the tag has probably landed. Check for yourself: curl -s https://raw.githubusercontent.com/ClickHouse/ClickHouse/master/utils/list-versions/version_date.tsv \ | awk -F '\t' '$1 ~ /^v26\.8\./ {print "26.8 is released - newest: " $1 " (" $2 ")"; f=1; exit} END {if (!f) print "26.8 not released yet"}' version_date.tsv is the list ClickHouse maintains of every released version and its date, so this is the most direct answer available - no auth, no rate limit, nothing to download. As of writing it prints 26.8 not released yet . Worth knowing: the Docker image will lag whatever that command tells you. The Docker Official Images repo trails the GitHub tags by a few patch versions - clickhouse:lts currently resolves to 26.3.20.7 even though 26.3.24.4 has already shipped. So don't treat a missing image as evidence the release hasn't happened. Either way, the timing works in your favour. Historically ClickHouse LTS releases pick up several patch releases quickly - 26.7 had

Most "is this plugin safe?" advice is vibes. I wanted numbers, so I built a dataset. Here's what it found, and exactly how, so you can check my work or build your own. The finding first Of 8,010 WordPress plugins with a publicly documented vulnerability since 2023 (15,534 vulnerability records in total): 3,780 have been removed from the wordpress.org plugin directory. Removal stops updates but doesn't uninstall — affected sites keep running the code. 277 carried a critical (CVSS ≥ 9.0) flaw on record before removal. 2,115 are still installable today with a known vuln and no update in 12+ months — roughly 6.7M active installs combined. The part that surprised me most: "removed from the directory" is nearly invisible to a site owner. No dashboard warning, no email. The plugin just quietly stops getting fixes while sitting on the site. How I built it (no paid APIs) The whole thing runs on two public sources and no API keys. 1. Vulnerability data — the GitHub Advisory Database. It mirrors CVE records including the Patchstack and Wordfence CNA assignments that cover almost all WordPress plugin CVEs. It's a git repo, so a shallow, sparse clone of the advisories/unreviewed/{year} folders gets you the raw JSON: git clone --depth 1 --filter = blob:none --sparse \ https://github.com/github/advisory-database.git Each advisory carries the CVE ID, a CVSS vector string, CWE IDs, and reference URLs. The plugin slug isn't a first-class field — you recover it from the Patchstack/Wordfence reference URLs with a couple of regexes. That alone attributes the large majority of WordPress advisories to a specific plugin. 2. Maintenance signals — the wordpress.org plugin API. For each slug: https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=SLUG That gives install count, last-updated date, tested-up-to version, and support-thread resolution ratio. A 404 (or an {error} body) means the plugin isn't in the directory — but that's ambiguous: it could be removed ,

Most "free online tools" have a dirty little secret: the moment you drop a file in, it gets uploaded to someone else's server. Your tax PDF, your ID photo, your client's contract — all sent off to be processed on a machine you'll never see, by a company whose privacy policy you didn't read. For a quick image resize, maybe you don't care. But it adds up. And the wild part is that for most everyday tasks, that upload is completely unnecessary. Modern browsers are powerful enough to do the work right on your own device — no server round-trip, no copy of your file sitting in someone's cloud. Here's how that works, and how to actually use it. Why do so many tools upload your files? Two reasons, mostly. The first is habit: it's easier for developers to send a file to a server, run some code there, and send the result back. The second is business: once your file is on their server, they can log it, analyze it, or use "free" as a funnel toward a paid plan. Watermarks, file-size limits, and "sign up to download" walls all come from this model. The alternative — processing files client-side , meaning inside your browser — has quietly become viable for a huge range of tasks thanks to two technologies: JavaScript (which every browser runs) and WebAssembly (which lets browsers run fast, compiled code at near-native speed). Together they can compress an image, merge a PDF, or transcode data without your file ever leaving the tab. What you can do entirely in your browser You'd be surprised how much works locally now: Images — compress, resize, convert between PNG/JPG/WebP, remove backgrounds, strip metadata. PDFs — merge, split, rotate, compress, and convert to or from images. Text and code — format or minify JSON, count words, change case, generate QR codes, encode/decode Base64. Everyday math — loan, BMI, age, and currency calculators that don't need a server at all. None of these require your data to travel anywhere. The tool loads once, and from then on it's just your CPU doin

A recent discovery revealed that AliExpress employs silent audio streams for device fingerprinting, leveraging the Web Audio API. This technique involves analyzing hardware-specific audio processing to distinguish user devices. Privacy-focused browsers have developed countermeasures, highlighting a security gap in current web standards regarding audio context initialization and user privacy. By Olimpiu Pop

Intro There's a pitch behind every AI coding assistant: it makes you faster. Fewer keystrokes, less boilerplate, more shipped features per sprint. The pitch is half true. What it leaves out is the gap between a tutorial demo and a real codebase under real pressure. In a demo, every suggestion is correct because the demo was built to make the suggestion look correct. In production, the assistant doesn't know your architecture, your team's conventions, or the ticket you're actually trying to close. It just knows what tends to come next in code that looks like yours. That gap is where the noise lives. The instant-accept trap Say a developer is mid-flow, wiring up a new endpoint. The assistant suggests a validation helper that looks reasonable, so they hit tab. It compiles, tests pass, they move on. Three weeks later a teammate finds two nearly identical validation helpers in the codebase: one written by a human eight months ago, one autocompleted last sprint. Nobody meant to duplicate logic. The suggestion was locally correct and globally redundant, and nothing about "correct code that compiles" caught that. (This is an illustrative scenario, not a specific incident, but most teams running Copilot or similar tools for more than a few months will recognize the shape of it.) Architecture creep, one suggestion at a time No single autocompleted line breaks your architecture. That's exactly the problem. An assistant trained on generic patterns will happily suggest a new abstraction, a new dependency, a new way of doing something you already do three other ways elsewhere in the codebase, because it has no visibility into "elsewhere." Accept enough of these one at a time and the codebase drifts into a dozen small dialects of the same idea, none of them wrong in isolation. The review tax The real cost isn't the code that's obviously bad, that gets caught. It's the code that's plausible enough to pass a quick glance and wrong enough to need real review time later. If you accept