标签：#dev

We talk a lot about what AI can build. Code generation. Faster prototypes. Automated debugging. One-shot apps. Entire products created in hours. And yes, AI is powerful. But there is a quieter cost we are not talking about enough: AI hype is starting to weaken the motivation to learn core engineering deeply. That should worry us. 1. The "Why Bother?" Mindset When the dominant narrative says AI can generate code instantly, many engineers start asking: Why should I spend months mastering frameworks, architecture, databases, networking, or system design? At first, that sounds practical. If a tool can help, why not use it? But there is a difference between using AI to move faster and using AI to avoid understanding. Core engineering is not just about writing code. It is about knowing why something works, where it breaks, how it scales, and how to fix it when the generated answer is wrong. If we skip that learning, we create engineers who can prompt systems but cannot reason deeply about systems. That is a dangerous tradeoff. 2. The Funding and Praise Monopoly Right now, AI gets most of the attention. Budgets move toward AI. Leadership praises AI initiatives. Teams are pushed to add AI features even when the fundamentals are still weak. Meanwhile, excellent core engineering often goes unnoticed. The people improving reliability, performance, developer experience, infrastructure, security, and maintainability are still doing high-impact work. But in many places, that work is being treated as less exciting simply because it is not branded as AI. This creates pressure. Engineers feel they must pivot to AI, not always out of interest, but out of fear. Fear of being left behind. Fear of being replaced. Fear that their existing expertise is no longer valued. That is not innovation. That is anxiety disguised as progress. 3. The "AI-First" Discount There is another subtle problem. When someone builds something impressive today, the reaction is often: AI probably generated that.

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built Some time ago, I needed to calculate hashes of directory trees across multiple platforms and architectures. Many existing solutions were based on GNU find, but I quickly realized that this approach has a number of shortcomings. As a result, hashdir was born: a cross-platform tool that takes into account many of the quirks and edge cases involved in calculating directory hashes, including character encoding, path separators, path overlaps, symlinks, and more. For use cases involving directory structures that contain very large binary files, I also added support for the imohash algorithm, which can hash large files quickly while maintaining an acceptable error rate. Once it had solved my original problem, I decided to share it with the world. Demo A short demo, along with installation and usage instructions can be found in the repository . The Comeback Story To my pleasant surprise, people began engaging with hashdir in various ways. One user reached out to tell me they were using it in their work and requested additional features, while another packaged it for their own use. Their interest motivated me to expand the feature set, improve test coverage and continuous integration, and further strengthen the codebase's robustness and overall quality.

Code generation tools are powerful and can significantly accelerate development work. Their main limitation is not capability, but context. Without access to organizational knowledge, internal conventions, and system-specific patterns, generated output often requires careful verification. This is why generation tools work best when paired with AI code search, as the latter provides immediate visibility into the existing codebase, making it easier to align AI-generated changes with the realities of the system. In regulated environments, the adoption model may look different. Security or compliance constraints can restrict the use of cloud-based code generation. AI code search still improves developer efficiency across implementation, review, and documentation workflows by enabling fast navigation and comprehension of large multi-repository codebases. What is AI code intelligence, and how does it help in practice? Code intelligence tools help developers find and understand existing code. If a search returns a poor result, the developer simply searches again. Nothing changes in your codebase. Code search also integrates without friction. No new review processes, no changes to CI/CD, no new permissions. Generation tools require policies for AI-written code that stall many pilots before they produce data. Clear metrics for measuring AI code intelligence An AI code search assistant only reads your code, which makes it much easier to measure its impact. You can track simple things like: • how long it takes to find the right piece of code • how quickly new developers get up to speed • how many hours the team spends searching each week If your team of 20 developers each spends 5 hours weekly understanding code, that equals 100 hours of engineering time. At $75 per hour, that’s $360,000 per year. Assume 10% reduction recovers $36,000, a realistic input for an AI ROI framework for tech teams. Faster path to Phase 3 expansion Code generation tools face tough questions from secu

The agents were doing exactly what I told them to. That was the problem. I'd built a pipeline where AI agents could take a spec file, implement a feature, run the tests, review the result, and commit — without me writing a line of code. It mostly worked. Dozens of features shipped. But I kept reviewing the output and feeling like something was off. Not broken. Just subtly wrong in a way that was hard to name. I spent a while blaming the models. Then the prompts. Then the validation steps. Eventually I had to sit with the obvious: the agents were implementing exactly what I'd written. My specs were underspecified. The bottleneck was always me, at the planning stage. The thing most people throw away There's something that feels right about vibe coding. You're operating at the level of intent — describing what you want and letting the model handle the mechanics. That part is genuinely useful. But watch what most people do with the output: Traditional development: Source code → Compiler → Binary (keep the source; regenerate binary anytime) Vibe coding done wrong: Prompt → LLM → Generated code (delete the prompt; commit the code) You've shredded the source and carefully version-controlled the binary. The prompt — your structured description of what you wanted, why, and what "correct" meant — is the valuable artifact. The generated code is what compiles from it. When you discard the prompt and commit only the output, you've lost the thing that actually mattered. The practical consequence shows up six months later: you're staring at code you wrote and spending twenty minutes reverse-engineering your own intent. The spec would have been a thirty-second read. What a spec-driven pipeline is I built what I call an SDLC (Software Development Lifecycle) harness — a system where instead of writing code directly, you write a spec describing what needs to be built, and AI agents handle the implementation, testing, review, and documentation. The spec is the source. The code is what

A follow-up to Part 1 ( EN on LinkedIn · RU on Habr ), where we stood up a two-tier PKI: a Root CA and three intermediate CAs — Person, Server and Code. At the end of Part 1 I promised we'd learn to revoke certificates and run OCSP. That's what we'll do here. Like Part 1, this article is meant as a hands-on manual : for every command and extension we touch, there's an extended reference of the parameters you can actually use — with syntax, allowed values, defaults and gotchas. If you don't need a given option right now, just skim past the table; it's there so you don't have to dig through man later. Each section has the same shape: first the working commands for the common case, then the full parameter reference. Tested on versions. Flag names, defaults and extension syntax were verified against the official documentation of OpenSSL master , plus nginx and Apache mod_ssl. OpenSSL evolves per branch: anything marked "OpenSSL 4.0 / master" (for example the nonss qualifier on authorityKeyIdentifier ) is not yet available in the stable 3.x line. If you're on OpenSSL 3.0–3.6, double-check the disputed options with openssl <cmd> --help or your version's man before copy-pasting config. The numeric openssl verify error codes above 40 also shifted between branches — confirm them against your version's header. In this part: How a revoked certificate differs from an expired one, and why we need two mechanisms — CRL and OCSP. Adding the distribution points (CDP) and AIA to the config so issued certificates "tell" verifiers where to check them. Revoking a certificate and working with the CA database. Generating a CRL and inspecting it with openssl crl . Checking revocation with openssl verify . Running an OCSP responder: issuing its certificate, starting the daemon, querying status. Publishing the CRL and OCSP over HTTP (nginx), configuring OCSP stapling and revocation checking on the web server. All paths, file names and config sections are the same as in Part 1. Where you name

For three months, I weighed myself every morning and took body measurements every Sunday. I used a caliper, a tape measure, and a scale that probably lies to me about hydration levels. The goal wasn't to get ripped. It was to understand whether any of these measurements actually mean something day to day. The Problem With Most Health Calculators Most body fat calculators fall into one of two camps: Too simple — plug in height and weight, get a BMI number that tells you nothing about your actual composition. Too complicated — requires measurements you need a degree to take correctly, plus an email signup and a paid subscription. Neither is useful for someone who just wants to know "am I making progress?" Building Something Practical I put together a calculator that uses the Navy Method — it takes neck, waist, and hip measurements and estimates body fat percentage. The math has been around since the 80s and correlates reasonably well with DEXA scans for most people: function navyBodyFat ( gender , neck , waist , hip , height ) { if ( gender === ' male ' ) { return 86.010 * Math . log10 ( waist - neck ) - 70.041 * Math . log10 ( height ) + 36.76 } return 163.205 * Math . log10 ( waist + hip - neck ) - 97.684 * Math . log10 ( height ) - 78.387 } The inputs are simple enough that anyone can take them with a tape measure. The output gives you a ballpark number that's consistent enough to track trends over time. What 90 Days of Data Taught Me Three things stood out: Daily weight is useless; weekly trend is everything. My weight would swing 2-3 pounds daily due to water, food, and sleep. The weekly moving average was the only signal worth watching. Body fat percentage changes slowly. Like, frustratingly slowly. In 90 days of consistent training, I moved maybe 2%. But that's real — if a calculator tells you you dropped 5% body fat in a month, it's broken. Consistency beats precision. Taking measurements at the same time, under the same conditions, with the same method matter

We have all been there: you build a utility app that relies on precise location or time-based triggers, only to find that it works perfectly on your Pixel but dies silently on a Samsung or Xiaomi device. When I started building Muffle, an app designed to automate sound profiles based on prayer times and GPS, I realized that standard AlarmManager usage wasn't enough to survive aggressive battery optimizations. The Problem with OEM Kill-Switches Modern Android versions enforce strict background execution limits. If your app isn't a high-priority foreground service, OEMs will frequently kill your process to save a few milliwatts of battery. For Muffle, if the process dies, the user misses their silent profile trigger, which defeats the entire purpose of the app. I had to move away from relying on a long-running background service and rethink my architecture entirely. Moving to WorkManager with Expedited Jobs Instead of a persistent service, I transitioned the core logic to WorkManager . By utilizing ExistingPeriodicWorkPolicy.UPDATE , I ensure that the scheduling remains consistent even across reboots. However, WorkManager alone can be delayed by Doze mode. To combat this, I implemented setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) for critical profile switches. This tells the system that the work is time-sensitive. kotlin val workRequest = PeriodicWorkRequestBuilder(15, TimeUnit.MINUTES) .setConstraints(Constraints.Builder().build()) .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST) .build() Leveraging Foreground Services with Notifications For features requiring immediate precision—like geofencing—I had to accept that a persistent notification is non-negotiable. To keep the app from being perceived as 'spammy,' I designed the notification to be low-priority, showing only when a profile is actively being managed. I also had to handle the onTaskRemoved callback in my Service implementation. By calling startService again with a sticky

I wanted to tell my girlfriend 'I missed you today' in Farsi and have it sound like something a person would actually say, not a phrase pulled from a travel guide. Every tool I tried — Google Translate, DeepL — gave me one answer. No register. No note on whether it was too formal for a text message or too casual for a letter. Just a string of words and the implication that language has one correct answer per sentence. So I built konid: it returns three options for anything you want to say, ordered casual to formal, each with the register explained and the cultural nuance between them described. It also plays audio pronunciation through your speakers directly, using node-edge-tts — no API key, no copy-pasting into a separate tab. The interesting engineering constraint was deployment target. I wanted this to live where I already work, not in a separate browser tab I forget to use. That meant MCP. A single MCP server running at https://konid.fly.dev/mcp now serves four clients without any client-specific code: # Claude Code claude mcp add konid-ai -- npx -y konid-ai # ChatGPT (Developer mode, Actions) # endpoint: https://konid.fly.dev/mcp Cursor, VS Code Copilot, Windsurf, Zed, JetBrains, and Claude Cowork all connect the same way. The server doesn't know or care which client called it. The output structure for a query like 'I missed you today' in Japanese looks roughly like this: Option 1 (casual): 今日会いたかった Register: intimate, fine for close friends or a partner Note: dropping the subject is natural here; adding あなたに would feel stiff Option 2 (neutral): 今日、あなたのことが恋しかったです Register: polite, appropriate for someone you're close to but addressing respectfully Option 3 (formal): 本日はお会いできず、寂しく思っておりました Register: formal written Japanese; would be unusual in a personal context The nuance comparison is the part I couldn't get anywhere else. Knowing that option 3 exists and that you would almost never use it for a personal message is actually load-bearing information if you're l

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily. OCR had a week. Mistral dropped OCR 4 with bounding boxes. Baidu open-sourced a model that beats DeepSeek-OCR. Claude got a permanent home inside Slack. And the Fable 5 ban fallout keeps getting uglier: Alibaba was apparently stealing Claude's capabilities, and even the NSA lost access to Mythos. Meanwhile, GPT-5.6 is delayed to mid-July. Let's go. 1. Mistral OCR 4: document AI gets serious Mistral launched OCR 4 this week. It's not just another OCR model. It's a full document understanding system with paragraph-level bounding boxes, confidence scores, and support for 170 languages. The specs: $4 per 1,000 pages (standard), $2 per 1,000 pages (batch) Paragraph-level bounding boxes with coordinates 72% win rate in blind tests against competitors Available on la Plateforme, Microsoft Foundry, and self-hosted for enterprise Top score on OlmOCRBench Why this matters for developers: Bounding boxes change everything. Previous OCR models gave you text. Mistral gives you text + where it is on the page. That unlocks document search, compliance systems, and any workflow where page structure matters. My take: At $4/1000 pages, this is competitive with Google Document AI ($5) and significantly cheaper than building your own pipeline. For enterprise document processing, this is probably the best option right now. For budget-conscious developers, Baidu's free alternative (see below) is worth considering. Full comparison in our Mistral vs DeepSeek vs Baidu breakdown. 2. Baidu open-sources Unlimited-OCR While Mistral went commercial, Baidu went open. Unlimited-OCR is a 3B-parameter MIT-licensed model that processes multi-page PDFs in a single inference pass. Key features: Built on DeepSeek-OCR architecture (SAM+CLIP + DeepSeek-V2 MoE decoder) Reference Sliding Window Attention for memory efficiency on long documents Tables to HTM

For a decade, "what's your frontend stack?" was a loaded question. jQuery vs. Backbone. Angular vs. React. Webpack vs. everything. The churn was exhausting, and a non-trivial chunk of our job was just keeping up. That era is quietly ending — not because we won the framework wars, but because the questions moved up a layer. The interesting problems in frontend today aren't about which library renders a list. They're about how rendering, data, and increasingly generation fit together. And AI is sitting right in the middle of that shift. The stack consolidated more than we admit Look at what most new production apps actually reach for in 2026: React or Svelte/Vue for the component model, with the framework wars settling into "pick one, they're all fine." A meta-framework — Next, Remix/React Router, SvelteKit, Nuxt — because nobody hand-rolls routing, data loading, and SSR anymore. TypeScript by default. Not a debate. The plain-JS greenfield project is now the exception. Server-first rendering (RSC, islands, streaming) as the baseline, with the client bundle treated as a cost to minimize rather than the center of the universe. The center of gravity moved back toward the server — but a smarter server that streams HTML, hydrates selectively, and treats the network boundary as a first-class design concern. The pendulum didn't swing back to 2010; it spiraled forward. What AI actually changed (and what it didn't) The hype says "AI writes the frontend now." The reality on the ground is more specific and more interesting. It collapsed the cost of the first 80%. Scaffolding a component, wiring a form, translating a Figma frame into JSX, writing the Tailwind for a layout — these used to be hours of work and are now minutes. That's real, and it's already changed how teams estimate. It did not collapse the last 20%. Accessibility edge cases, focus management, race conditions in async state, the weird Safari bug, the design-system invariant that isn't written down anywhere — this i

Splitting a PDF is one of those features that sounds trivial until you try to build it. Users expect range input ( 1-3, 5, 7-9 ), a per-page option, multiple file downloads, and zero server involvement. I built en.sotool.top/split/ to do exactly that. Here's how it works with Vue 3 and pdf-lib . Why Client-Side? PDFs often contain sensitive information. Contracts, medical records, financial statements. Even a "simple" splitting tool should not force users to upload files to a server. Client-side benefits: No upload bandwidth or size limits No server storage or cleanup Instant processing for normal files Works offline after the page loads The tradeoff is that everything has to run in the browser, which limits the libraries you can use. The Stack Vue 3 — UI and state pdf-lib — Load, manipulate, and save PDFs File API — Read the uploaded file lucide-vue-next — Icons npm install pdf-lib Loading the PDF and Counting Pages First, read the file into an ArrayBuffer and load it with pdf-lib . import { PDFDocument } from ' pdf-lib ' const pdfFile = ref < File | null > ( null ) const totalPages = ref ( 0 ) async function handleFile ( files : File []) { if ( files . length === 0 ) return pdfFile . value = files [ 0 ] const bytes = await files [ 0 ]. arrayBuffer () const pdf = await PDFDocument . load ( bytes ) totalPages . value = pdf . getPageCount () } Now we know how many pages exist and can show the split UI. Two Split Modes I offer two ways to split: by range and per page. Mode 1: Page Range Input Users type something like 1-3, 5, 7-9 . I parse it into groups of page indices. function parseRanges ( input : string , max : number ): number [][] { const groups : number [][] = [] const parts = input . split ( ' , ' ). map ( s => s . trim ()) for ( const part of parts ) { if ( part . includes ( ' - ' )) { const [ start , end ] = part . split ( ' - ' ). map ( Number ) const pages = [] for ( let i = start ; i <= end && i <= max ; i ++ ) { pages . push ( i - 1 ) } if ( pages . len

Prologue A while ago, I decided to develop a fully accessible main navigation component in React and write a series of articles documenting the steps it took to create a non-trivial accessible component. In my last development article , I finally completed the requirements for delivering an uncontrolled navigation component with a horizontal layout; with full keyboard functionality, along with adding the niceties of closing sublists when lists are closed and making sure any open sublist on the top row closes when focus shifts away from it. Rather than write an entirely new component for a mobile version, I'm going to modify the existing code. This first article outlines the steps necessary to set up and work with a controlled component. -— Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 1.0.0 . Links in the article will take you to the proper file in the tagged GitHub Repository. Because the code for this release is scattered across components, line numbers are added to make it easier to locate in the linked GitHub file. Line numbers are also provided for those who would like to follow along with a downloaded copy. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component. You can view the requirements for the Controlled Components Release along with previous requirements. Content Links Introduction Acceptance Criteria Contr

Here's a thing that surprises people the first time: an email sent through the API does not carry the signature the user set up in Gmail or Outlook. Provider signatures live in the provider's compose UI, and a programmatic send bypasses that entirely, so a message your app sends goes out with no signature at all unless you add one. The Nylas Signatures API is how you add it: store an HTML signature once, then attach it to a send by ID, and the signature gets appended to the message for you. This post covers signatures from two angles: the HTTP API your backend calls, and the nylas CLI for creating and testing one from the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm setting a signature up. Nylas signatures are separate from provider signatures The first thing to get straight is that these are not the user's existing signature. Nylas doesn't sync the signature configured in Gmail, Outlook, or any other provider, and that provider signature is never applied to mail sent through the API. If a message your app sends needs a sign-off, you create that signature with this API and attach it explicitly; there's no inheriting it from the connected account. That separation is deliberate, because a programmatic send is a different context from a person typing in their webmail. It does mean the responsibility is yours: a user who connects their mailbox expecting their familiar signature to appear on app-sent mail won't get it automatically. Stored signatures are grant-scoped, living at /v3/grants/{grant_id}/signatures , so each connected account has its own set, and they're HTML, so a branded sign-off with a logo and links works the same as a plain one. Create a signature Creating a signature is a POST /v3/grants/{grant_id}/signatures with a name and an HTML body . The name is for you, a label to find it by later; the body is the markup that gets appended to outbound mail. The response returns the signature with its ID, which is w

Introduction I'm Ahmer. I'm 19, I'm doing a 4-year Software Engineering degree at a fairly...

Hey all, we have a quick update for everyone who participated in the Github "Finish-Up-A-Thon"...

Spencer Judge discusses the architectural pattern of building a shared core in Rust with language-specific layers on top. Drawing from his work on Temporal's SDKs, he shares lessons on navigating FFI boundaries, bridging async concepts, and managing memory safely. He explains the limitations of native extensions and how emerging tech like WebAssembly can streamline cross-language architecture. By Spencer Judge

kreuzcrawl began as a Rust core with bindings for ten languages. v0.3.0 ships fourteen, adds a tiered WAF-aware dispatch engine, cuts peak streaming memory from ~2.5 GB to ~20 MB, and enables SSRF defense across every outbound call path by default. It is the first release we consider API-stable. This post covers what changed, why each decision was made, and what the harder engineering problems looked like from the inside. At a glance Area v0.2.0 v0.3.0 Language bindings 10 14 (+Dart, Kotlin/Android, Swift, Zig) Peak streaming memory ~2.5 GB ~20 MB SSRF protection opt-in on by default Dispatch model static HTTP / bypass / browser tiered, signal-driven escalation WAF fingerprints — 35 across 8 vendors Fingerprint hot-reload — lock-free ( ArcSwap ), 500 ms debounce MCP tools partial 1:1 with CLI, safety-annotated CLI subcommands scrape, crawl + batch-scrape, batch-crawl, download, citations Robots / sitemap parsers engine-internal public modules API stability preview stable Four new language bindings v0.2.0 shipped Rust, Python, Node.js, Ruby, Go, Java, C#, PHP, Elixir, and WebAssembly. v0.3.0 adds Dart , Kotlin/Android , Swift , and Zig — bringing the total to fourteen. None of the per-language glue is written by hand. Every binding is generated from the Rust core by alef , our polyglot binding generator. The Dart and Kotlin/Android packages bind through the C FFI layer ( kreuzcrawl-ffi ) via dart:ffi and JNI respectively. Swift binds through clang. Zig uses @cImport against the same C header. The generation pipeline also hardened in this release: the Docker publish matrix now builds each architecture natively rather than via QEMU emulation, the Dart build no longer requires the Flutter SDK for pub.dev publishes, Swift artifactbundle checksums are injected automatically, and the Elixir/PHP/Ruby releases preserve their lock files through the source-publish step. === "Python" ```sh pip install kreuzcrawl ``` === "Node.js" ```sh npm install @xberg/kreuzcrawl ``` === "Rus

Last year I was doing a code review for a startup. Everything looked fine on the surface, clean code, good structure, tests passing. Then I noticed this: const query = `SELECT * FROM users WHERE email = ' ${ req . body . email } '` That's it. That's the bug. SQL injection, sitting right there in a startup that had been in production for 8 months. Nobody caught it. Not the developer, not the reviewer, not the CTO. Here's the thing, it's not that developers are careless. It's that this kind of bug is invisible until it isn't. The code works perfectly. Tests pass. Users are happy. Until someone types ' OR '1'='1 in the email field and walks straight into your database. The bugs I see most often 1. Raw SQL with user input // 🚨 This is everywhere const query = `SELECT * FROM users WHERE email = ' ${ email } '` // ✅ Use parameterized queries const query = ' SELECT * FROM users WHERE email = $1 ' db . query ( query , [ email ]) 2. Secrets in environment variables... committed to git # .env DATABASE_URL = postgres://user:actualpassword@prod-db.company.com/mydb STRIPE_SECRET = sk_live_... Then .env ends up in the repo because someone forgot to add it to .gitignore . I've seen this more times than I want to admit. GitHub's secret scanning catches some of these, but not always before someone has already cloned the repo. 3. JWT tokens that are never actually verified // 🚨 Decoding is not the same as verifying const user = jwt . decode ( token ) // ✅ Always verify const user = jwt . verify ( token , process . env . JWT_SECRET ) jwt.decode just reads the token. Anyone can forge it. jwt.verify actually checks the signature. The names are confusingly similar and the wrong one silently works in development. 4. No rate limiting on auth endpoints // 🚨 Anyone can try a million passwords app . post ( ' /login ' , async ( req , res ) => { const user = await db . findUser ( req . body . email ) // ... }) // ✅ Add rate limiting const authLimiter = rateLimit ({ windowMs : 15 * 60 * 1000 , m

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Most people lose hours pretending to work or study. I was one of them. I kept setting Pomodoro timers and ending up scrolling Twitter during breaks. That's not rest. That's just a different kind of distraction. So I built Mognota — a free wellness companion for screen workers. The Problem You don't have a discipline problem. You have a system problem. Your brain has a hard biological limit. Sustained attention peaks at 20-45 minutes before quality drops sharply. Long unfocused hours are not work — they are the feeling of work. The solution isn't more willpower. It's intentional recovery. What I Built Mognota pairs a Pomodoro timer with 50+ guided wellness activities: 👁️ 20-20-20 eye break reminders 🫁 Guided breathing & 7 pranayama techniques 🧘 Desk yoga, HIIT, Tai Chi, stretches 🎵 Binaural beats & ambient soundscapes 🧠 Meditation & NSDR protocols 📓 Gratitude journal, mood tracker, brain dump 🎮 Sudoku, sliding puzzle, fractal explorer The Technical Part This is what dev.to might find interesting: Pure HTML, CSS, vanilla JS — zero frameworks Everything in a single HTML file All 8 notification sounds synthesized with Web Audio API localStorage only — nothing leaves your device Works offline once loaded 109+ languages supported No npm. No build step. No dependencies. Just open and use. Try It 👉 https://mognota.com/ Completely free. No account. No ads. Forever. Would love brutal honest feedback from this community.