标签：#EV

I rent six dedicated servers from a company in Germany. Together they have more cores, more memory, and more SSD than most production clusters I worked on a decade ago. I run my own Kubernetes on them. Not managed. Not EKS. Not GKE. The whole stack, from the immutable OS up to the workloads. People who hear this ask me why, and the question usually arrives in one of two tones. The dangerous tone is "that's amazing, how do I do it" . The responsible tone is "why on earth would you do that to yourself" . This post is for the second group. Why the cloud is the right answer for almost everyone Let me get this out of the way honestly: by every conventional metric, I should be using the cloud. Managed Kubernetes has become genuinely good. EKS has dramatically improved over the last three years. GKE has always been better than people gave it credit for. The serverless options are mature. The serverless databases are mature. The observability is mature. The bill is predictable in the way a Tuesday is predictable. Self-hosting violates almost every assumption that makes a startup productive. Time is the most expensive resource you have. The cloud sells you abstractions that turn that time into product. Running your own substrate means the time goes into the substrate. If you are trying to ship a product to customers — go use the cloud. Stop reading this post. It will only confuse you. What the cloud does not sell you Here is what the cloud will not sell you, even if you are willing to pay extra: control over your own roadmap. The cloud's roadmap is the cloud's. They decide which APIs deprecate. They decide which regions get the new feature. They decide what your egress bill looks like. They decide whether your monitoring vendor — sitting on top of their infrastructure — is allowed to charge you eight times what it would cost you to host the same software yourself. They decide whether the small ML company hosting your fine-tuned model gets acquired by someone with very differ

DevTools responsive mode has one limitation that's never been fixed: you see one device at a time. You check iPhone. Looks fine. Switch to iPad. Fix padding. Switch back to iPhone. Was the header already broken or did you just break it? I got tired of holding layouts in my head, so I built a tool that shows all three at once. Responsive Tool — free, no signup Paste a URL → phone, tablet, and desktop load at one time. That's it. A few things that make it actually useful day to day: Swap one pane to a different device without losing the other two Refresh one pane after a code push — no need to reload everything Share your exact setup via URL — a teammate sees the same device comparison you do Sync scroll across all panes with a one-line script snippet Every viewport is a real verified CSS size , not a guess No account. No extension. No download. Runs in the browser. I don't see or store the URLs you test. Also: way more sites block iframes via X-Frame-Options than you'd think. I tested ~60 real sites — 93% of developer portfolios loaded fine, but only 44% of framework/marketing sites did. If your site doesn't load, that's the server blocking iframes, not a bug in the tool. Stack Next.js 16 · React 19 · TypeScript · Tailwind v4 · Cloudflare Workers Bonus I also built a CSS breakpoints reference that maps common breakpoints to real device viewports. Handy even without the tool. 👉 responsivetool.com What do you use for responsive checking? Still just DevTools? I want to know what I'm up against.

The bill that started this I was paying $40/month for a PDF generation API to power a tiny internal invoicing tool for a client project. Forty bucks a month to convert some JSON into a PDF. That's it. That's the whole service. I finally sat down on a Saturday to see if I could kill that subscription. Three weekends later, not only did I kill it — the replacement is faster than the API ever was, because there's no network round-trip at all. This post is the log of how it went, in the order I actually hit the problems, not the order that makes me look competent. Attempt #1: jsPDF on the main thread (it worked, until it didn't) First pass was the obvious one — jsPDF running directly in the click handler: function generateInvoice ( data ) { const doc = new jsPDF (); doc . text ( data . clientName , 20 , 20 ); data . lineItems . forEach (( item , i ) => { doc . text ( ` ${ item . description } — $ ${ item . amount } ` , 20 , 40 + i * 10 ); }); doc . save ( ' invoice.pdf ' ); } Fine for a 3-line invoice. Once I tested with a 40-line-item invoice (a real client sent me one to test against), the tab froze for almost two full seconds. Not crashed — frozen. Scroll didn't work, buttons didn't respond, and on a mid-range Android phone it was closer to five seconds. The main thread doing synchronous PDF math while also being responsible for painting the UI is exactly the kind of thing that looks fine in a demo and falls apart the moment a real user pastes in real data. Attempt #2: move it to a Web Worker Web Workers get talked about like they're this exotic tool for WASM and video processing. They're also just... a really good fit for "expensive synchronous work that a user is waiting on." I'd never reached for one before this project, mostly out of habit. The tricky part isn't the worker itself, it's that jsPDF assumes it has access to document and window in a couple of code paths (font metrics, mostly), which don't exist inside a worker. I ended up switching to pdfkit compiled

A random game is easier to debug when the same inputs produce the same result. In HoopTrait, a browser basketball project, the Lab mode combines eight selected traits and generates a fictional career. The interesting engineering problem is keeping replay, sharing and validation consistent. This is a technical development note, not a claim that a game score predicts an athlete's real performance. Store the decisions, not just the result The Lab state records a seed, a dataset version and an ordered list of actions. An action is a pick or a reroll. Replaying those actions reconstructs the build. A seed alone is not a complete replay contract: changing the player pool or its order can change a seeded draw. A dataset version therefore matters alongside the random seed. For a future release, the same principle should apply to changes in the rules themselves. Test invariants across many runs The Lab test suite iterates through 1,000 seeds. For each seed it shuffles the order of the eight skills, uses the two allowed rerolls, and completes a build. It checks that: Eight distinct players were selected. All eight traits are present, and no player remains to be drawn after completion. The overall game score stays between 0 and 99 and matches the shared rating function. Packing and unpacking the share state returns the original state. Recomputing the fictional career returns the same output. The ten simulated seasons sum to the displayed career earnings. Those assertions catch different problems. A stable score does not prove that a shared link reproduces the same selections. A complete build does not prove that its season totals add up. Reject impossible histories A share payload is untrusted input, even in a client-side game. Negative or fractional seeds, duplicate skill picks, a third reroll, unknown action types, a mismatched dataset version and actions after completion are rejected. The tests also cover malformed encoded payloads and unexpected fields. Local state is usef

This is a submission for Weekend Challenge: Generosity Edition What I Built My late...

The Fairphone 6 Plus feels like an extremely average midrange Android phone and I couldn't be more thrilled. The mission has always been admirable. Fairphone seeks out ethically sourced materials and offers a high degree of repairability for its devices. But the phones themselves required a lot of sacrifices, like putting up with underpowered processors […]

This is a submission for Weekend Challenge: Generosity Edition What I Built A donation ledger for a group too small to buy software. It is a Google Sheet, some Apps Script, and one public page a donor can open. The group I had in mind is the kind that exists on every street: a neighbourhood fund, a school parents' group, a committee that collects for winter coats. Money arrives over WhatsApp and leaves in cash, and somebody keeps it in a notebook. The arithmetic is not the hard part. The hard part arrives three months later when a donor asks where their money went, and answering needs the notebook, the person holding it, and an afternoon. Software for this exists and is priced for organisations with a finance team. So the ledger stays in a spreadsheet a volunteer already knows how to open, and the only thing added is what a spreadsheet cannot do alone: read messy human messages, refuse to trust its own reading , and publish the page that answers the question before it is asked. Demo The public page a donor opens → That page is the deployed page, byte for byte, with one line changed: where the Apps Script version writes <?= data ?> , the demo fetches the same JSON from a file so you can read it without a Google account. The JSON is produced by running the sample month through the same recordEntry() and publicView() the real script uses, so if the ledger rules change, the demo changes with them or the build fails. The sample month deliberately includes the things that go wrong: a receipt two volunteers forwarded, a donation typed with one zero too many and later corrected, and a reading the checks refused to trust. What the model read, and whether it was allowed to count → The ledger page shows the result. This one shows the part worth showing. Pick any of six real donation messages and it highlights the exact characters Gemini says it read the amount from, lists the three checks with their outcomes, and says why the row was posted or held. It is fed by a recorded run

Docker management, monitoring that goes deeper than a green dot, backups I have actually restored, and everything else that showed up once deploying stopped being the hard part. Moving off Vercel solved exactly one problem: deploying. Everything else I used to get for free, quietly, as part of the platform, I now had to go find and wire up myself. A month into running my own server, I had a list of ten tools taped to the inside of my head, each one solving a problem I did not know I had until it happened to me at a bad time. This is that list, in the order I actually needed them, with the mistake or the moment that made me install each one. I lean JS and Rust wherever I can, partly out of preference and partly because those are the tools that keep pace with how fast the rest of my stack moves. A couple of these are not JS or Rust at all, and I kept them anyway because they were simply the best tool for the job. 1. Dokploy, for everything I wrote about yesterday This is the one I already spent an entire post on, so I will keep it short here. Push to main, Dokploy builds the container, Traefik points a domain at it, done. Four apps running on one $24 droplet, and adding a fifth would not move the bill. If you deploy anything with Docker and are still doing it over SSH, start here. Everything else on this list assumes you already have a platform under you, not just a server. 2. Neon, for the database half of preview environments The first crack after Dokploy was previews. Dokploy gives every pull request its own preview URL, which is one of the nicest things about the whole setup, right up until every preview hits the same production database. I corrupted a batch of test data twice before I noticed what was happening. Neon branches Postgres the way git branches code, copy-on-write, so a preview PR gets its own preview database that costs almost nothing until it actually diverges from main. The storage engine underneath is written in Rust, and it quietly closed the othe

In a previous post , I covered why TypeScript types alone can't protect you from a backend that returns something you didn't expect, and how to build a small apiRequest boundary that validates both the outgoing request and the incoming response against Zod-style schemas before your application ever touches the data. That post answered one question: Is this data actually shaped the way I think it is? It left another question open: When the answer is no, or when the request fails for a completely different reason (like a timeout or a dropped connection), what does the rest of the app do with that failure? In practice, "the rest of the app" usually does something different depending on who's writing it: One component checks error.response?.status directly. Another checks error.code === "ECONNABORTED" . A form manually digs through the error to find field-level messages. A toast just displays whatever string happens to be on error.message . The app works, but every layer speaks a different error dialect. This post is Part 2: it takes the validation boundary from Part 1 and builds the missing piece on top of it, a single, normalized ApiError shape that every layer of the app can speak, plus the logging, messaging, and form-mapping that make it actually usable. Quick Recap: The Validation Boundary From Part 1, the apiRequest wrapper validates request payloads and response bodies against schemas, and throws one of two typed errors when something doesn't match the contract: export class ApiRequestValidationError extends Error { constructor ( public readonly url : string , public override readonly cause : unknown ) { super ( `API request input does not match the contract for ${ url } .` ); this . name = " ApiRequestValidationError " ; } } export class ApiResponseValidationError extends Error { constructor ( public readonly url : string , public override readonly cause : unknown ) { super ( `API response does not match the contract for ${ url } .` ); this . name = " ApiRespon

Run this against the real, published image and watch it fail: docker run --rm --entrypoint trelix-mcp ghcr.io/sairam0424/trelix:3.2.1 --version Exit code 127. Not a crash inside trelix-mcp, not a stack trace, not a permissions error — 127 is the shell's own way of saying the binary you asked for does not exist. And it didn't. The console script trelix-mcp is supposed to install as part of every trelix package was simply absent from the image, on both the slim tag and the -local tag, for the entire life of the 3.2.1 release. Every unit test in the suite was green. Every line of source that builds trelix-mcp was correct. The thing a user would actually get from docker pull did not have the binary its own --version flag implies exists. This article covers four releases — v3.2.2, v3.2.3, v3.2.4, and v3.2.5 — spanning 173 commits and 88 changed files since v3.2.1, which is where the last article in this series left off. That one was about tests that pass without exercising the code they claim to cover: a MagicMock standing in for a real embedder, an all-ones attention mask that makes masked and unmasked math identical, a unit test that asserted a bug as its own specification. This one, on the heels of the mutation-testing push that closed out that arc, is about a different and in some ways more uncomfortable failure mode: tests that pass while exercising the wrong artifact entirely. A green pytest run against src/ says nothing about whether the wheel on PyPI, the image on GHCR, or the binary on the GitHub Releases page actually does what it claims. Those are three separate build products, built by three separate pipelines, and none of trelix's 4,353 collected unit tests had ever touched any of them directly. v3.2.2 through v3.2.4 is the story of finding that gap and closing it with an actual gate, not a promise to be more careful next time. v3.2.5 is a short postscript proving the discipline stuck. The Docker image that shipped without its own server The 127 above wasn't

In December 2024, Google quietly updated its closed testing rules for personal developer Console accounts. For months, indie developers had to recruit at least 20 testers to keep their app opted in for 14 consecutive days before applying for production access. Under the revised guidelines, that threshold dropped from 20 to 12 testers. Understanding the nuances of the Google Play 20 testers vs 12 testers shift helps you plan your release schedule accurately without running into unexpected delays during Google Play Console verification. While lowering the number by eight testers sounds like a major relief, the core requirements behind closed testing have not changed. Google still enforces a strict 14 consecutive day duration, and the Play Console continues to monitor tester retention and engagement. A lower numerical requirement means less logistical hassle, but maintaining a stable group of committed testers remains the primary hurdle for independent developers. The Policy Shift: From 20 to 12 Testers Google originally introduced mandatory closed testing in November 2023 to improve app quality and curb low-effort submissions on the Play Store. Initially, all new personal accounts registered on or after November 13, 2023, were required to run a closed test with at least 20 opted-in testers for 14 days without interruption. After roughly a year of developer feedback regarding how difficult it was for solo creators to find 20 reliable participants, Google reduced the requirement to 12 testers in December 2024. It is crucial to understand who this rule applies to. The requirement exclusively targets personal developer accounts created on or after November 13, 2023. If you operate an organization or business developer account, or if your personal account was registered before November 13, 2023, you are currently exempt from this mandatory closed testing gate. However, if you fall under the new personal account category, reaching 12 continuous opt-ins is a strict prerequis

I was initially enamored with the beta version of Apple’s revamped smartphone assistant. As the full release approaches, I’ve forgotten Siri AI even exists.

readm3 can edit now, and it speaks Reddit readm3 started as a markdown reader for the terminal. File browser on the left, rendered document on the right. Version 0.3.0 adds the obvious missing half: you can change the file you are looking at. Press e , type, press esc . The preview has already re-rendered by the time you get back to it, because both modes read the same buffer. There is no second preview to keep in sync, which is the part that usually goes wrong in editors with a live preview pane. ctrl+s saves. Quitting with unsaved work asks first. enter continues the list you are in, so the same bullet, the next number, or an unchecked box for a task, and pressing it on an empty item ends the list. There is no selection and no cut and paste. This is for fixing a typo and adding a paragraph. Your editor is still your editor. Two dependencies, not forty The old parser was a few hundred lines of hand-rolled regex, and it got reference links, nested lists and bare URLs wrong. Every fix was another regex. Parsing moved to marked. The reason it won was not features, it was weight: marked is CommonMark plus GFM with zero dependencies of its own . readm3 went from one dependency to two. markdown-it would have been seven. A remark and micromark pipeline is somewhere between twenty and forty packages, for a program whose whole point is that it starts instantly in a terminal. Only the parsing moved. The layout code that wraps text, draws code gutters and sizes tables is untouched, so readm3.com still renders through the exact same functions the terminal does. There is still no second renderer. The swap fixed reference links, nested and loose lists, bare URL autolinks and hard line breaks for free. The dialects actually disagree marked does not ship GitHub alerts, footnotes, :emoji: , or anything Reddit added. Those are tokenizer extensions in readm3 now, still with no new dependency. They are behind a --flavor switch rather than all on at once, because the dialects contradic

This is a submission for Weekend Challenge: Generosity Edition What I Built Every...

AI can write code now. That part is no longer surprising. You can describe a feature to Copilot, Claude Code, Cursor, Codex, or another coding agent and get a working implementation in minutes. Sometimes it is genuinely impressive. But there is a bigger question: Can you actually trust the code enough to ship it? According to the Stack Overflow 2025 Developer Survey, 84% of developers use or plan to use AI tools . At the same time, trust in AI-generated output is still limited. One of the biggest frustrations developers report is getting an answer that is almost right, but not quite . Source: https://survey.stackoverflow.co/2025/ai And that “almost right” part is exactly where developers still matter. AI may write more code. But humans still need to decide whether that code is correct, secure, maintainable, and actually worth merging. So here is a simple review workflow I think every developer should practice. 1. Start With the Requirement, Not the Diff Imagine you tell an AI agent: Add password reset support. A few minutes later, it generates the full feature. The code may compile. The UI may work. The tests may even pass. But before reading the implementation, ask: How long should reset tokens remain valid? Can the same token be used twice? What happens if the email does not exist? Should existing sessions be logged out? Are we exposing whether a user account exists? This matters because AI can build the wrong thing very cleanly. So before asking: Does this code work? Ask: Does this solve the correct problem? That one question can save a lot of time. 2. Check the Architecture Before the Syntax AI is usually good at writing a function. It is not always good at understanding where that function belongs inside your system. For example, an agent might create something like: components/ ├── PaymentForm.tsx ├── PaymentAPI.ts ├── StripeService.ts └── Database.ts Everything may technically work. But should database access really live beside your UI components? Probably no

This is a shortened version of my original post . My wife and I have blogged about every trip since our honeymoon 10 years ago. For the people at home, for ourselves later, and by now for our children. We took turns writing, but both had photos and videos on their phones. The text was never the hard part. The photos and videos were: every day one of us sent them from the phone to the other, who had to upload them and sort them into the entry in the right order. So I wrote Texttile , an open-source blog engine built for writing together. One entry, two screens Multiple people can have the same entry open. One of them has the text and types, the other watches the words arrive and can take the text over with one click. Both can still work on the gallery. Photos and videos belong in the same gallery. Videos come from your own server. Drop one in and Texttile converts it, thumbnail included. No YouTube embed, no player from anywhere else. One container, one folder Phoenix, LiveView, ffmpeg and SQLite live in one Docker image. Everything is in /data . Move that folder and you move the blog. A reader's browser talks to your server and nothing else. No CDN, no tracker, no hosted font. What it is not There are no roles, no permission matrix, no plugins, no theme marketplace. Everybody with an account is an admin. I built it for people who trust each other, because that is who writes a blog together. You can try it or read the source . The full story includes a video showing both screens. How do you blog on the road?

One SQL statement over a VECTOR(768) column, 45,400 charities, and 2,917,459 real pairs used to check it. What the detector caught, and what it missed.

The engineering team at software company Figma recently documented how they built AI agents to help their security team investigate alerts, search past incidents, check company systems, and even prepare code fixes. The agents learn from previous investigations, reducing repetitive work and helping engineers resolve complex alerts about 70% faster. By Renato Losio

Nineteen OOM kills in nine days. Ten WordPress apps on a 32GB shared box. One of them a client site that took a CPU spike on 14 July during a paid campaign burst, and pushed the whole tenant into the wall. This post is the diagnosis before the rebuild. What we actually found when we stopped guessing. Two layers of Cloudflare, one page cache plugin, one preloader being silently challenged, and a language subpath that was cold every time it mattered. I'm writing it partly for anyone who runs multi-tenant WordPress on Cloudways or similar, and partly as a reminder for future-me. There's a checklist at the end. Steal it. The client is anonymized throughout. Every number is real. The stack Traffic hits two Cloudflare layers before it reaches origin. Both are Cloudflare, but they're different zones on different accounts, and they own different things. [ visitor ] ↓ [ Upstream Cloudflare zone (managed by a third party) ] ← DNS, SSL, HTML edge cache ↓ [ Cloudflare Enterprise add-on sold by Cloudways ] ← WAF, bot, rate limit, AI crawler block ↓ [ Cloudways origin: nginx + PHP-FPM ] ↓ [ WordPress + WPML + Elementor + FlyingPress ] Two Cloudflares isn't a mistake. The domain has been on Cloudflare via an upstream party since before the site moved to Cloudways. When Cloudways later offered a Cloudflare Enterprise add-on for its security stack, we kept both. We manage the Cloudways side. We don't own the upstream zone, which shapes what we can and can't do without a request going out. The trap is that both layers can cache HTML, and both can serve security challenges. If nobody writes down which layer does what, they fight. Our ownership split ended up like this: Layer Owns Upstream Cloudflare (third party) DNS, SSL, HTML edge cache, purge lifecycle Cloudways CF Enterprise add-on WAF, bot management, rate limiting, AI crawler blocking, ScrapeShield, Browser Integrity Check FlyingPress Origin page cache, Cloudflare integration pointed at the upstream zone, purge rules Cloudways "