标签：#webdev

Every time I started a side project, I rebuilt the same five things before I wrote a single line of the actual idea: auth, a database, file uploads, a deploy pipeline, and TLS. Different domain, same plumbing. By the third project I was copy-pasting my own docker-compose.yml from a folder two repos over and renaming things until they stopped erroring. So I stopped. I froze that plumbing into one boilerplate — PocketBase + Next.js + Caddy on a single cheap VPS — and now I ship every side project on it. Same shape every time: clone, rename, write the part that's actually new, push. The thing I care about most isn't the speed, though. It's that I stopped paying for it. A handful of real projects now run on this setup for a few euros a month, total — not a stack of per-service SaaS bills that each want $25 here and $20 there before you've shipped anything. No Vercel seat, no managed Postgres, no Auth-as-a-Service, no object-storage line item. Here's the whole thing. Why this stack The trick that makes the cost collapse is PocketBase . It's a single Go binary that gives you, in one process: Auth — email/password, OAuth, the works, with a real users collection A database — SQLite, with a schema you manage from an admin UI Realtime — subscribe to collection changes over SSE File storage — uploads handled, with on-the-fly thumbnails An admin dashboard — at /_/ , for free That's four or five separate SaaS products collapsed into one binary that runs anywhere and stores everything in a folder. Compared to wiring up Supabase or Firebase, the mental model is tiny: it's one process and one data directory. Back up the directory and you've backed up the entire app — database, uploaded files, auth tokens, all of it. For the front I use Next.js (App Router, React Server Components) because that's where I'm fastest, and Caddy as the reverse proxy because it gets you automatic HTTPS with zero config — it provisions and renews Let's Encrypt certificates on its own. And it all lives on

If you have ever submitted an iOS application to Apple's App Store and received a cryptic rejection notice about icon specifications, you are not alone. Apple's human interface guidelines for icons are extraordinarily precise — and for good reason. The iOS ecosystem spans devices from the tiny Apple Watch to the expansive iPad Pro, each requiring icons at exact pixel dimensions to render correctly across Retina, Super Retina XDR, and ProMotion displays. Understanding iOS icon sizes is not optional. It is a prerequisite for shipping. Every pixel dimension you provide must match Apple's specifications exactly, must use lossless PNG format, must not include transparency, and must be delivered with the exact filename that Xcode expects. One missed size, one wrong filename, and your project fails to build correctly. Precision is not a suggestion — it is a hard requirement enforced by Xcode's build system. iPhone Icon Sizes For iPhone applications, the required icon sizes span multiple uses within the operating system. The App Store listing requires a 1024×1024 pixel icon. The home screen displays icons at different sizes depending on device generation and display density. Notification icons, Spotlight search results, and Settings app icons all require their own specific dimensions. Usage Scale Size (px) Filename Convention App Store 1× 1024×1024 Icon-1024.png Home Screen 2× 120×120 Icon-60@2x.png Home Screen 3× 180×180 Icon-60@3x.png Spotlight 2× 80×80 Icon-40@2x.png Spotlight 3× 120×120 Icon-40@3x.png Settings 2× 58×58 Icon-29@2x.png Settings 3× 87×87 Icon-29@3x.png Notification 2× 40×40 Icon-20@2x.png Notification 3× 60×60 Icon-20@3x.png iPad Icon Sizes iPad adds its own set of required sizes, particularly because of the larger screen real estate and different display densities. Xcode's asset catalog system requires each icon to be placed in the correct slot, and any missing slot will prevent archiving for App Store submission. This makes completeness not just a best p

Search engine optimization doesn't require expensive tools. Your browser's built-in developer tools can identify and diagnose most SEO problems in under 15 minutes. Here are the 11 most impactful SEO checks you can run directly from Chrome DevTools. 1. Check Meta Description Length Right-click any element, Inspect, expand <head> , find <meta name="description"> . Metric Optimal Range Meta description length 120-155 characters Title tag length 50-60 characters H1 count per page Exactly 1 const meta = document . querySelector ( ' meta[name="description"] ' ); const len = meta ? meta . content . length : 0 ; console . log ( `Meta description: ${ len } chars` ); 2. Verify Only One H1 Tag Exists const h1s = document . querySelectorAll ( ' h1 ' ); console . log ( `H1 count: ${ h1s . length } ` ); A study of 1.2 million pages found pages with one H1 ranked 12% higher on average. 3. Find Images Missing Alt Text const imgs = document . querySelectorAll ( ' img ' ); const missing = [... imgs ]. filter ( i => ! i . alt || i . alt . trim () === '' ); console . log ( ` ${ missing . length } of ${ imgs . length } images missing alt text` ); Pages with complete alt text see 3.7% higher image search visibility. 4. Detect Render-Blocking Resources Open DevTools, Network tab, reload, click "Blocking" filter. Resources in red block first contentful paint. Total blocking time under 200ms More than 20 render-blocking resources signals a problem Each render-blocking CSS file adds 50-300ms to page load 5. Check Canonical Tag Consistency const canonical = document . querySelector ( ' link[rel="canonical"] ' ); console . log ( canonical ? `Canonical: ${ canonical . href } ` : ' No canonical tag ' ); 6. Audit Internal Links const links = [... document . querySelectorAll ( ' a[href] ' )]; const internal = links . filter ( l => { try { return new URL ( l . href ). hostname === window . location . hostname ; } catch ( e ) { return false ; } }); console . log ( `Internal links: ${ internal . len

Tired of uploading your private files to sketchy ad-filled website for conversion and OCR? Meet EasyConvert, a serverless media tool that uses FFmpeg WASM to convert, compress and OCR media files 100% locally. Link: easy-convert.pages.dev Github: https://github.com/nihid7/easyconvert submitted by /u/Fun-Time9529 [link] [留言]

Hey everyone!! sharing something I've been building for the past 2 months. Leafy lets you and your team annotate any webpage. You click an element (or highlight text), leave a comment, @ mention teammates, and they get notified. Comments are anchored to specific parts of the page and sync across devices. Use cases I've seen people use it for: → Product teams reviewing features on their products → Designers leaving feedback on live prototypes → Researchers annotating sources together → QA marking bugs on staging environments → Sales teams using it on salesforce → Students using it for marking interesting things on any page, to study You can organise teams into "Gardens" (I know, quirky naming). Free tier supports up to 3 gardens with 5 members each. I'd love any feedback! especially on what feels broken or missing. Chrome Web Store: https://chromewebstore.google.com/detail/leafy-annotate-the-web-to/doohbmfpjanoimbigjbjocanpenbfkkh https://preview.redd.it/4riy4haubu5h1.png?width=908&format=png&auto=webp&s=69ecac6f3bef7a4843c58095c3d8a5972ff2ceaa Product page: https://get-leafy.com submitted by /u/maxisrichtofen [link] [留言]

The idea is to make it straightforward to find any ffmpeg version and configuration you require, and to have the binaries available for production CI/CD flows without worrying they will expire. submitted by /u/pinter69 [link] [留言]

A bit of context first. I run a service that caches images from paywalled sites so users don't have to load them fresh on every visit. The overwhelming majority of what we cache is PNG - huge, bloated, uncompressed PNG. Naturally, I started looking into smarter storage and serving strategies, and JPEG XL kept coming up as the obvious answer. The compression gains on PNGs especially are remarkable: you can cut file sizes by 50–60% compared to JPEG with minimal perceptible quality loss at equivalent settings. So the plan seemed straightforward: Convert everything to JXL Detect browser support via the Accept header Serve JPEG as a fallback on the fly for unsupported browsers Here's what the numbers actually looked like: Strategy Total Size Savings Do nothing ~51 GB - WebP Q85 (universal) ~12 GB −39 GB JPEG Q92 (universal) ~21 GB −30 GB JXL d=1 + JPEG fallback ~16 GB / ~5 GB −46 GB (85% of users get 76 KB avg) The JXL route has the best savings on paper - but it means storing two versions of everything, or doing on-the-fly conversion, which adds latency. WebP Q85 just wins. Universally supported (~97–98% of browsers globally), −39 GB in savings, no fallback needed. I hate that this is the conclusion, because JXL is better across most technical dimensions that matter Chrome removed JXL support in Chrome 110 in October 2022 - and that removal was the real killer, given Chrome's ~65% global market share. The stated reasons were actually fourfold: experimental flags shouldn't remain indefinitely; insufficient ecosystem interest; insufficient incremental benefits over existing formats; and maintenance burden reduction. Critics, including engineers from Intel, Adobe, Cloudinary, Meta, and Shopify, disputed all of these claims vigorously in what became one of the most contentious threads in Chromium history. In 2026: Google has reversed course. Chrome 145 (released February 2026) ships with a JPEG XL decoder - currently behind a flag, but back in the codebase for the first tim

As the title says, creating and sharing short videos on macOS or Windows has never been a smooth flow for me. I used to screen cap with QuickTime or the NVIDIA. The result were huge .mov or .mp4 file. Then I either need to upload a 600 MB file to an online compressor, open Handbrake, or use ffmpeg from the command line. Ffmpeg is great, but for quick everyday use, but I found myself loosing the text file where I keep the most useful commands to adjust parameters, and it's anying when there are silly error because I forgot a parameter. And if I wanted to trim the video, I usually had to open a separate video editor that take time to open and are sort of overkill for a simple trimming. So I built Compress.mov . The basic flow is simple: drag and drop a video, choose whether you want to trim it, compress it, or both, and get the result automatically saved in your computer. Over time I added more features: audio removal, video rotation, codec selection, video rescaling, multiple languages (german, farsi, japanese...), and a small counter that shows how many lifetime megabytes you’ve saved by using the Compress app. The latest feature I’m testing is video recording, so I don’t have to use QuickTime anymore! This started as a side project on my spare time, and I built it without an AI assistant, so it’s fully handmade 😃 You can try it at compress.mov for FREE and if you become a fun please purchase it at the windows store or App Store to help me stay motivated. submitted by /u/tino-latino [link] [留言]

Most online file converters require uploading your documents, images, or videos to an unknown server. This is slow, inconvenient, and raises serious privacy concerns. I decided to build something different: a converter that works entirely inside your browser. Processing large files without a backend presents two main engineering challenges: How do you avoid consuming all available RAM? How do you prevent the user interface from freezing? This article explains how I solved these problems using OPFS, Web Workers, and a Backpressure mechanism. The result is a working tool you can try right now: PixelForge Free . The Architecture at a Glance Here is the simplified data flow of the entire pipeline: Drag & Drop → OPFS (Virtual Disk) → Worker Pool (Backpressure) → ZIP Stream → Download Problem 1: Out-of-Memory (OOM) Crashes The Challenge: Loading many files directly into the browser's memory is impossible. A user dropping a folder with 100+ high-resolution images would instantly crash the tab. The Solution: Origin Private File System (OPFS) OPFS provides a fast, isolated virtual disk inside the browser. Instead of loading files into RAM, my pipeline intercepts the drop event and streams the raw binary data directly to this virtual disk. Here is a simplified version of how it works: // Get a reference to the virtual disk const root = await navigator . storage . getDirectory (); const fileHandle = await root . getFileHandle ( `input_ ${ id } .raw` , { create : true }); // Create a writable stream to the disk const writable = await fileHandle . createWritable (); // Stream the file directly from the user's computer to the virtual disk await file . stream (). pipeTo ( writable ); This allows the application to accept a folder with 500+ items without consuming more than a few megabytes of actual RAM. The data stays on the user's SSD, not in memory. Problem 2: UI Freezing The Challenge: Image compression, PDF parsing, and video encoding are CPU-intensive operations. Running them

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

I run a couple of small niche sites — a pet-health tool and a travel-info site. The thing that actually moves the needle for both isn't clever copywriting. It's having a lot of pages that each answer one specific, low-competition question. "Puppy vaccine schedule by breed." "Is [neighborhood] worth visiting." That kind of thing. This approach has a name: programmatic SEO . You take a data set (one row = one page), pour it into a template, and generate pages at scale. Done well, it's how directories, comparison sites, and tool sites quietly rank for thousands of long-tail terms. Done badly, it's a spam farm that Google buries. More on that later, because it matters. The problem: the tooling is either expensive or a Rube Goldberg machine When I went looking for a way to do this without hand-coding every page, I found two camps: Agency-grade SaaS — powerful, but priced at $99–$299/month . That's a lot of money to spit out HTML when you're a solo operator running sites that make beer money. No-code stacks — wire a spreadsheet to a CMS to a static-site generator with a couple of automation tools in between. It works, but now you maintain a fragile chain of four services, and your pages live inside someone else's platform. Neither felt right. I just wanted: spreadsheet in, clean HTML out, files I own. What I actually built (for myself, first) So I wrote a generator for my own sites. Every morning it reads a CSV, applies a template, and produces a folder of static HTML pages — each with valid JSON-LD, proper meta tags, an internal-link hub, and a sitemap. I deploy the folder. Done. After running it daily for months on my own properties, I cleaned it up and turned it into a product: PageForge . The core idea is deliberately boring: CSV + template → a ZIP of clean static HTML pages you own. No dashboard you have to log into forever. No lock-in. The output is just files. If you stop using PageForge tomorrow, your pages keep working because they're plain HTML sitting in your r

Chinese models now account for 61% of global LLM token consumption. DeepSeek, Qwen, GLM, and Doubao consistently dominate the global top 10 on OpenRouter. But for developers outside China, accessing them is painful — no English docs, no international payment, confusing pricing. I tested all 6 major APIs. Here's what I found. Price Comparison (June 2026) Model Provider Input $/1M tokens Output $/1M tokens vs OpenAI DeepSeek V3 DeepSeek $0.35 $0.52 95% cheaper DeepSeek V4-Flash DeepSeek $0.003 $0.015 99.7% cheaper Qwen-Max Alibaba $0.58 $1.74 92% cheaper GLM-5 Zhipu AI $0.87 $4.05 84% cheaper Doubao Pro ByteDance $0.43 $0.87 95% cheaper MiniMax M2.5 MiniMax $0.45 $0.90 95% cheaper DeepSeek V4-Flash at $0.003/M is 1/300th the cost of GPT-4o . For agent chains or batch processing, you can call it without thinking about cost. Quick Start All Chinese models follow OpenAI API format. Change base_url and model — zero code changes. # DeepSeek curl https://api.deepseek.com/v1/chat/completions \ -H "Authorization: Bearer $API_KEY " \ -d '{"model":"deepseek-chat","messages":[{"role":"user","content":"Hello"}]}' # Qwen — same format, different endpoint curl https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions \ -H "Authorization: Bearer $API_KEY " \ -d '{"model":"qwen-max","messages":[{"role":"user","content":"Hi"}]}' How to Get API Access Model Sign Up Payment Free Tier DeepSeek platform.deepseek.com Alipay/WeChat 5M tokens Qwen dashscope.aliyun.com Alipay 2M tokens/month GLM-5 open.bigmodel.cn WeChat/Alipay 1M tokens Doubao console.volcengine.com/ark Alipay 500K tokens MiniMax platform.minimaxi.com Alipay 1M tokens All platforms support English UI. Most don't require a Chinese phone number. Latency (tested from Singapore) Model TTFT Tokens/sec Total (100 tokens) DeepSeek V3 380ms 85 t/s 1.5s DeepSeek V4-Flash 120ms 240 t/s 0.5s Qwen-Max 450ms 65 t/s 2.0s GLM-5 520ms 55 t/s 2.3s Which Model for What Use Case Model Agent chains (5-10 calls) DeepSeek V3 Bulk process

Hi everyone, posting here after a really long time. Our industry is experiencing a major shift, we are getting closer to the reality of agentic programming every single day. Though I'm all in for agentic programming, I don't think it should come at the cost of our codebases getting compromised because an LLM decided to install a compromised dependency. With supply-chain attacks being on the verge of becoming part of our daily lingo as developers, especially in the js/ts ecosystem, I've built a vs-code extension which scans your lock files (npm/yarn/pnpm, all three supported) against the listings on Github Advisory Database and osv.dev. Based on the listing it determines the health status of your project. It also scans dependencies which were not installed by you but are required by other dependencies to function properly. Based on the scan, you get four status in the sidebar: SOS Alert - Your installed version is compromised. Act now. Don't Upgrade - You're safe, but a newer version is compromised. Don't Downgrade - You're safe, but an older version is compromised. Passed - Green check. All safe. This is how the extension reporting looks: https://preview.redd.it/c8df2fjegs5h1.png?width=2624&format=png&auto=webp&s=ce506f033beb83d97915281ebf2888c456428fd4 The scanning is done: - Polling based: every 30 minutes. - every time you open the window. - can be manually triggered by commands. Right now it only scans via osv and gha, I plan to integrate more reliable and faster sources like synk in future. Would love everyone's opinion on this since I did not do much research in this and just built it on saturday. The extension can be installed from: https://marketplace.visualstudio.com/items?itemName=uskhokhar.trust-me-bro-vsc The codebase is available at: https://github.com/USKhokhar/trust-me-bro Please give it a try. Rate it on marketplace if you like and star it on github if you like it a little extra. I'm also posting this here seeking open-source contributors who are mor

By Vladislav Shter · The Sovereign Ecosystem Ask any major AI model a question and you'll notice something: it almost always agrees with you. You propose an idea, it tells you the idea is great. You make a claim, it validates the claim. You ask if your code is fine, it reassures you that it's fine. This is not an accident. It's a design choice. And once you see it, you can't unsee it. The agreeable machine Modern AI assistants are trained, in part, to keep you satisfied. A satisfied user comes back. A user who comes back keeps the subscription. So the models are nudged — through their training — toward being pleasant, encouraging, and agreeable. Researchers even have a name for this failure mode: sycophancy, the tendency of a model to tell you what you want to hear rather than what is true. It feels good. You get a small hit of validation every time the AI confirms you were right. But for anyone doing serious work — auditing code, checking facts, making decisions — that agreeableness is dangerous. A tool that mostly agrees with you is not a tool that catches your mistakes. And it gets worse when the model doesn't actually know the answer. When confidence and truth come apart Here's the real trap: a single model doesn't just agree too easily — it also fills gaps with invented detail, delivered in the same confident tone as its correct answers. There is no visible difference between "I know this" and "I'm guessing and dressing it up." The fluency is identical. Even the heavyweight, expensive models do this. A premium model like Gemini can produce beautifully written, authoritative text that contains fabricated facts, invented citations, or specifics that simply aren't real. For an inexperienced user this is invisible. For an experienced user it's worse — it's actively disorienting, because the wrong answer looks exactly as polished as the right one. So you're left with two problems stacked on top of each other: the model is biased toward agreeing with you, and when it

Spent the last few months of my free time working on this, essentially a version of race studio that works on mobile/tablet/desktop Now supports AiM (xrk), iRacing (ibt), and RaceBox (vbo) files a webapp designed around an offline-first philosophy, works 100% offline. Supports video overlays (not chunked videos yet) Historical weather Saving chassis setups in a way that locks a version to a session so changing the setup won't mess with historical data overlay data from any session onto the current session And so much more And includes a FOSS datalogger as well Nothing gated behind a paywall except you dumping logs on my server, unlimited local storage Before I overhaul this horrible UI, I was probably going to add a "fastest lap" social section where people would upload their fastest laps, and users can reference that data. If anyone here races (shocking amount of devs at the track) just list whatever features you think the popular software is missing, and give me a couple days lol https://HackTheTrack.net submitted by /u/Willing_Comb_9542 [link] [留言]

Looking for a registrar that has the best customer support for a business. Be able to reach someone who actually speaks fluent English The bean counters at my old domain registrar replaced all the good customer service reps with AI chatbots and overseas call centers submitted by /u/DarkSeneca [link] [留言]

You write await a dozen times before lunch. Fetch a row, await it. Call a service, await that. It works, you move on, and you never have to think about what the word is doing. Then one day someone asks you to explain it. Maybe it's an interviewer."But what does await actually do?" And you open your mouth and what comes out is "it, uh, waits for the promise." Which is true, and also explains nothing. We can build async/awit mechanism from scratch using generators as a learning exercise. It requires a pause button wired to a small loop that waits on a promise and then presses play again. You already know one half of that machinery if you read the last post in this series . The other half is a trick generators have that we glossed over. Put the two together and you can build a working version of async/await yourself, by hand, and watch it behave exactly like the real thing. Let's do that. The shape of the problem Strip await down to what it has to accomplish and you get two requirements: First, a function has to be able to stop in the middle. Right at the await, freeze everything, the local variables, the spot in the loop, all of it, and hand control back to whoever called it. Normal functions can't do this. They run start to finish and that's the deal. Second, something on the outside has to wait for the promise to settle and then nudge the frozen function back to life, handing it the resolved value as if the await expression had simply evaluated to it. That's the whole job. A function that pauses, and a driver that resumes it when a promise is ready. Hold that picture, because the rest of this is just filling in those two pieces with things JavaScript already gives you. The half you've seen: pausing A generator function, the function* kind, can pause itself with yield and resume later from the exact same spot. We leaned on that hard in the CSV piece to pull rows through a pipeline one at a time. A line came in, got yielded, and the generator sat frozen until someone

Every LLM wire format claims token savings. Nobody proves whether AI models can actually comprehend the format at scale, or produce valid output in it. We ran 23 comprehension evals across 10 models and 3 providers. We ran generation evals across 11 models. Deterministic ground truth. No LLM judge. Reproducible from one command. JSON breaks at 500 records. GPT-5.5 returns empty strings. It can't even attempt an answer. Opus miscounts 500 as 356 and then spends 143 lines manually enumerating symbols to verify its own wrong answer. The format designed for "human readability" is incomprehensible to the systems actually reading it. TOON can't produce valid output. Claude Opus, the most capable model on the planet, scores 0/5 on TOON generation. GPT-5.4: 0/5. GPT-5.4-mini: 0/5. Gemini 3.1 Flash Lite: 0/5. The error is always the same: toon: cannot assign string to int . The model writes "target" in the distance column. TOON expects 0 . Every model fails the same way because the format's design forces an unnatural encoding step that models cannot perform unprompted. GCF wins both dimensions on every model tested. 100% comprehension on Claude Sonnet, Gemini 2.5 Pro, Gemini 3.1 Pro, and Gemini 3.5 Flash. 5/5 valid generation on every frontier model. Zero prior training. The format didn't exist until we built it and every model speaks it natively. Comprehension: 500 Symbols, 13 Questions, Zero Instructions A 500-symbol, 200-edge code graph. Encoded in GCF, TOON, and JSON. 13 structured extraction questions. The model gets the payload and a question. No format instructions. No system prompt. No hints. 23 runs. 22 wins. 0 losses. Model Runs GCF avg TOON avg JSON avg GCF margin Claude Opus 4.6 2 96.2% 84.6% 73.1% +11.6 vs TOON Claude Sonnet 4.6 2 100% 73.1% 53.8% +26.9 vs TOON Claude Haiku 4.5 2 96.2% 69.2% 57.7% +27.0 vs TOON GPT-5.5 5 84.1% 67.7% 45.8% +16.4 vs TOON GPT-5.4 4 76.4% 56.0% 44.1% +20.4 vs TOON GPT-5.4-mini 2 71.8% 64.1% 54.2% +7.7 vs TOON Gemini 2.5 Flash 3 80.6

Show off ClauderDay has a more fitting title. I'm open to other ideas but clicking through AI slop projects all day feels like we aren't really showing off projects any more. submitted by /u/fauxtoe [link] [留言]

This field test was against Kubernetes. The issue was Kubernetes #138728: https://github.com/kubernetes/kubernetes/pull/139545 The issue involved the watch cache path around initial events. The useful diagnostic boundary was: watch cache consistency work → read lock hold time → initial event delivery That matters because cache paths in Kubernetes are not just storage details. They sit between stored state and the clients watching that state. If too much work happens while a cache lock is held, the system may still be logically correct, but the operational path can become more expensive, more blocking, or harder to scale than it needs to be. The local repair candidate is intentionally narrow. It does not redesign the watch cache. It does not change the broader storage model. It does not rewrite WatchList behavior. The patch focuses on reducing how much work happens while the watch-cache read lock is held. For ordered stores, the repair keeps the cheap snapshot boundary during interval construction, but defers full ordered list materialization until the interval is consumed by the watcher path. In plain terms: Take the necessary cache boundary under lock. Do not do heavier list materialization there if it can be safely deferred. The local patch touched only the watch-cache interval implementation and its focused tests. Local validation passed for the relevant cacher tests, store tests, full cacher package tests, and diff hygiene. Status: draft PR opened for maintainer review Field Test #013 Project: Kubernetes Issue type: watch-cache / initial-events behavior Boundary: cache consistency work under lock vs bounded watcher consumption Result: narrow local repair candidate and focused test coverage Status: local proof prepared; no public PR or comment opened yet This field test matters because it shows Scarab operating inside a major distributed systems platform. The bug shape was not a simple crash. It was not a UI issue. It was not a configuration mismatch. It was a me