标签：#dev

While building with OpenAI, Anthropic, and other AI providers, I realized something surprising. I monitored my servers, databases, and application performance—but I had almost no visibility into my AI API spending until I checked the provider dashboard or received the monthly invoice. That led me to build AICostPass . It helps developers, indie hackers, startups, and agencies: ⚡ Track AI API costs in near real time 📊 Monitor spending by project or client 🚨 Get budget threshold email alerts 📧 Receive weekly spending summaries 💰 Export billable CSVs for client invoicing The goal is simple: help developers understand and control AI costs before the invoice arrives. 👉 https://aicostpass.com I'd love to hear how you're currently tracking AI API costs. Are you using provider dashboards, spreadsheets, or another tool?

How to version REST endpoints, evolve GraphQL schemas, and ship mobile updates — without leaving existing users behind. Why It Matters Every deployed API is a contract. Every mobile binary installed on a user's phone is a snapshot of that contract. The moment you change a response shape, rename a field, or remove an endpoint, you risk breaking clients you cannot force-update. Backward compatibility is not about avoiding change. It is about managing change so that existing consumers continue to work while the system evolves underneath them. This article covers three layers: REST API versioning , GraphQL schema evolution , and mobile app compatibility (React Native & Flutter). Each section delivers concrete patterns and production-ready code. Part I — REST APIs The Versioning Decision REST APIs have four common versioning strategies. Each comes with tradeoffs: Strategy Example Pros Cons URI path /api/v1/users Simple, cacheable, widely understood Implies the resource itself changed; cache duplication Query parameter /api/users?version=1 Easy to implement, can default to latest Complicates routing and cache keys Custom header X-API-Version: 1 Keeps URIs clean Hard to test in browsers, invisible in logs Content negotiation Accept: application/vnd.app.v2+json Fine-grained, per-resource versioning Complex to test, requires custom media types Rule of thumb: Use URI versioning for public APIs. Use header-based versioning for internal services where you control all clients. Non-Breaking vs. Breaking Changes Not every change requires a new version: ✅ Non-breaking (no version bump needed): - Adding a new field to a response - Adding a new optional query parameter - Adding a new endpoint - Returning a new enum value (if clients handle unknowns) ❌ Breaking (requires a new version): - Removing or renaming a field - Changing a field's type (string → number) - Making an optional parameter required - Changing the response structure Pattern: Side-by-Side Versioning When a breaking cha

Somebody on Reddit posted about 997s that just say AK5*R*5 — one or more segments in error — no AK3 , no AK4 . Preach. That's the problem this free doohickey* is for: rejectdecoder.com *If you'd prefer a "gizmo", I can make that happen. What it does Paste the rejection (997, 999, 824, TA1) plus the original bounced document. It parses both locally in your browser and cross-audits them: control number agreement segment counts envelope consistency code validity required segments It then quotes the exact segment byte-for-byte and ranks the likely causes for anything it finds. If it finds nothing, it says the answer isn't in the docs and tells you to escalate to your partner with your control numbers — which beats pulling a diagnosis out of my... AIs. Where the AI does (and doesn't) fit I know how and appreciate WHY "AI-powered EDI" is sneered at. So the audits here are deterministic parser code, not a model. The AI only writes the plain-English narration of facts the parser already verified, every card says so, and if the narration fails you still get the full audit results. No hallucinations or guesswork. Privacy Parsing runs entirely in-browser (the real Python parser, compiled to WebAssembly via Pyodide) and even works with the WiFi off. If you use narration, only a masked summary you preview first ever leaves the page. Don't take my word for it — check your network tab. Free. No signup for the examples or the deterministic audits; narration is a handful of decodes a month with just an email. Built it solo from an in-house tool of mine, so it's young AND kinda old. Please tell me where it's wrong. Walmart's rejection quirks are encoded so far. Whose partner nonsense should be next...? -jjg

Most AI incident diagnosis tools will happily produce a root cause even when the evidence is weak. Argus takes a different approach. When an anomaly fires, Argus runs five independent diagnoses against the same incident window. If they converge on the same root cause, it returns a confident diagnosis. If they don't, it returns novel instead of pretending it knows the answer. It's a single Go binary. The first version had Kafka, microservices, and two databases. It looked impressive on paper, but nobody would actually run it. I tore it down into a single process and replaced Kafka with an in-process event bus. Run it with docker run, bring your own Anthropic API key, and your telemetry never leaves the box. It ingests OTLP or Prometheus remote_write; point your telemetry to a single endpoint. I've validated it on synthetic cases, reconstructed real postmortems (Cloudflare 2019/2022), and my own distributed system. It hasn't yet been tested against messy real-world production telemetry, which is exactly the kind of feedback I'm looking for. GitHub: https://github.com/k1ngalph0x/argus I'd genuinely appreciate people trying it out and telling me where the design falls apart, what feels over-engineered, or what you'd change.

On 23 June 2026, AWS shipped Lambda MicroVMs : isolated VMs you launch, suspend, resume and terminate through an API, built explicitly for "workloads that execute user- or AI-generated code." Up to 16 vCPUs, 32 GB of memory, 8 hours of runtime, a dedicated HTTPS endpoint per VM. We've been shipping that product for a while. So has E2B, so has Modal. The interesting thing about the launch isn't that AWS caught up - it's that the biggest infrastructure company in the world looked at agent sandboxes, agreed with the design, and then shipped it with one European region and a price roughly three times ours per vCPU . That's the whole post. If you want an AWS Lambda MicroVMs alternative, "can anyone else do this" isn't the question - the isolation technology is literally the same on both sides. The questions are who operates the machine, where in Europe you can put it, and what it costs to leave running. AWS wins some of these outright, and we'll say where. The short verdict Pick Lambda MicroVMs if you're already deep in AWS, need more than 4 vCPUs or 8 GB in a single sandbox, or your agent has to reach private resources inside your VPC. The IAM integration and the size of the fleet are real advantages. Pick orkestr sandboxes if you're an EU company that wants execution, snapshots and logs inside one EU legal entity, you want to pay for CPU you actually burned rather than CPU you reserved, and your sandboxes are small and numerous rather than huge. The same primitive Both products run on Firecracker. AWS says so on the docs page - "Lambda MicroVMs deliver these core capabilities through Firecracker virtualization" - and so do we. Each sandbox is a hardware-isolated VM with its own kernel and rootfs, not a container sharing the host kernel. That distinction matters exactly when an LLM is writing shell commands you haven't read yet. The lifecycle is the same too. Create, exec, read and write files, pause, resume, terminate. Here's ours: from orkestr import Sandbox with Sand

A product idea from RayTally's daily scan of public signals. The idea One-liner: Helps first-time PCB designers find manufacturing and assembly problems on the board before they place an order. Concept: A desktop preflight tool helps first-time PCB designers find contradictions among their manufacturing files before payment. Users drag in Gerber files, a bill of materials, and placement coordinates. The first screen highlights high-risk locations such as board outlines, hole sizes, package orientation, and missing components. Clicking an issue locates the specific pad on the board and shows the design value beside the fabricator's rule. The tool also simulates panelization and the board's appearance after component placement, exposing problems such as insufficient connector overhang and component collisions before they happen. It does not require beginners to read an entire manufacturing standard; it focuses each check on the changes needed for the current order. Why now On July 11, 2026, a first-time board designer publicly documented the full process from designing in KiCad and exporting Gerber and drill files with default settings to sending them to a fabricator and assembling the board by hand. Before powering it on, he still put the odds of a first successful result at "fifty-fifty." At the July 13, 2026, 09:46 UTC capture, the experience had an observed score of 111 and 45 comments on Hacker News. KiCad already provides baseline capabilities including DRC, Gerber viewing, 3D viewing, and manufacturing-file output. Consolidating these scattered steps into one order-level preflight directly addresses the question beginners face before payment: what exactly should they check? Signal Hacker News "Designing and assembling my first PCB" (approximately 111 points and 45 comments, observed July 13, 2026, 09:46 UTC). RayTally scans public signals daily for product ideas worth building. Browse the source page and more product ideas .

Every DevOps engineer has done this dance: you've got a chunk of YAML or a Terraform file that looks right, something's rejecting it, and you want a fast sanity check. So you paste it into some random online validator — and a small voice asks, wait, where did that config just go? That config often has structure, comments, sometimes internal hostnames or resource names in it. Pasting infrastructure definitions into an unknown server is a habit worth breaking. So I built a set of validators that never send your config anywhere — they run entirely in your browser. What they are Free, browser-based validators for the formats DevOps folks paste-and-pray most: YAML — catches the indentation and structure errors that make Kubernetes and CI configs fail with cryptic messages Kubernetes manifests — schema-aware checks beyond "is it valid YAML," so you catch the wrong apiVersion or a misplaced field before kubectl apply does Terraform / HCL — structural validation for the syntax slips that terraform validate flags only after you've context-switched away The one design decision that matters 100% client-side. No upload, no signup, no server round-trip. Your config is parsed by JavaScript running in your own tab — it never leaves your machine. You can literally open dev-tools, watch the network panel, and see nothing go out. Turn off your wifi and they still work. This isn't a privacy gimmick — it's the correct architecture for a tool that handles infrastructure definitions. A validator has no business seeing your config on a server it doesn't need to. Why I bother Two reasons, honestly. One: I kept wanting this exact thing and kept not trusting the options. The nth time I hesitated before pasting a manifest into a stranger's website, I decided to just build the version I'd trust. Two: fast feedback loops are the whole game in this job. The gap between "save the file" and "find out it's malformed" is pure friction — and the tighter that loop, the less of your working memory it b

This isn't a wish for the internet to stop — just a moment to imagine what it'd mean to breathe without it. Not everyone, but a huge percentage of the world now relies heavily on the internet. What if it were unavoidably shut down for just 24 hours? How long would those hours actually feel — and how much would they reshape our daily routines? I see the irony everywhere already. The moment a page hangs, I instinctively dial a USSD code to check my data balance. I know someone who pings google.com just to see if he's still connected — using the internet to check whether the internet is still there. The first hour would probably be spent staring at the network icon, refreshing pages, waiting for life to resume. That's when we'd notice how much of the day quietly depends on the cloud: deliveries stall, payments freeze, navigation disappears, businesses pause. Millions would discover just how many invisible gears keep everyday life moving. Then the smaller shifts. Looking at the sky to guess the weather instead of opening an app. Realizing the only people who "exist" are the ones actually in front of you. Sitting in a room where the loudest sound is the silence of the feed. Maybe one day, staying offline will be a skill of its own. Have we gotten so used to consulting the network before taking a step that we've stopped trusting our own judgment? Perhaps 24 hours of silence wouldn't just be an outage. It would be a reminder — that before the cloud, there was memory. Before search engines, there was curiosity. Before notifications, there was presence. And before constant connection, we still knew how to walk on our own. If you asked me, What cloud or internet service would you miss most for a day? For me, I don't remember the last time I went 48 hours without Gemini.

I've been deep in spec-driven development (SDD) lately, and I want to walk through what it actually...

Luca Mezzalira shares proven learnings from guiding hundreds of teams through the migration from monolithic web applications to distributed frontend architectures. He explains the core architectural difference between components and micro-frontends, outlines a 6-step decision framework spanning client vs. server rendering, and discusses how to utilize edge compute for safe, iterative rollouts. By Luca Mezzalira

Everyone can generate a website now. Type a prompt, get a decent page — that part is a commodity. The question nobody's answering is what happens on day 2 : the leads start arriving, a line of copy needs a tweak, someone asks for a section you forgot. That's when a website stops being a design project and becomes a thing you have to run — and where most tools hand you yet another dashboard to log into and dread. Sitelas makes a different bet. Because a Sitelas site lives inside Claude through an MCP connector, the same chat that built the site also runs it . You don't open an admin panel to see who filled out your form, write back, or change the page. You just ask. Here's what "running your site from a chat" actually looks like. First, the 30-second why Claude connects to outside tools through MCP connectors — you already use the ones for Gmail, Calendar, and Drive. Sitelas has one too. Add it once (in claude.ai: Customize → Connectors → Add custom connector , and paste https://sitelas.com/api/mcp ), and Claude can do things with your site, not just talk about it: publish it, read its submissions, restyle it, add a section. Your site becomes an automation endpoint sitting next to your other connectors — the thing a Webflow or Squarespace site can't be. New here? Start with How to Build a Website From a Claude Chat . "Did anyone fill out my form today?" That single question is the whole idea. You ask; Claude reads your site's submissions, surfaces the new lead — Maya, a bakery owner — and drafts a warm reply in your voice. One message, no tabs. It works because every form on a Sitelas site captures submissions to your inbox automatically — no integration required. You can open that inbox in the dashboard any time: …but running your site from a chat means you rarely need to. Claude reads those same submissions straight from your site, so "who wrote in today, and what do they want?" is answered in the thread you're already in — not in a panel you have to remember to ch

My CLAUDE.md has one line near the bottom that I wrote months ago and mostly forgot about until I started actually paying attention to what it does: ## Important Note after your work done codex will review what you done. Terse, no punctuation, clearly typed in a hurry. But it's a real instruction that fires on every session in this repo: I finish a change, and a second model reviews it before I consider the work done. I added it half as an experiment. A few months in, it's changed how I work more than almost anything else in the setup, and not in the way I expected. I thought it would catch bugs. Mostly it doesn't, not directly. What it actually does is force a triage decision on every single piece of feedback, and getting that triage wrong is where all the pain lives. The three buckets Early on I treated every review comment the same way: read it, do it. That lasted about a week before I was silently making changes I didn't agree with because a second AI suggested them, and separately burning a stupid amount of time re-litigating comments that were just wrong or out of scope. What actually works is sorting every comment into one of three buckets before touching code: Fix it, no discussion. The comment is unambiguous, low-risk, and doesn't touch anything architecturally significant. Just do it and move on. Ask first. The comment is ambiguous, or it touches something that would require a real judgment call, or the "fix" would be a bigger refactor than the comment implies. Stop and get a human decision before acting. Skip silently. The comment is a duplicate of something already handled, or genuinely doesn't apply. Don't reply just to say "not doing this," don't leave a comment thread as evidence of having read it. Silence is the correct response to a non-issue. The failure mode I kept falling into before I had these buckets explicitly was collapsing 2 into 1: treating "ambiguous" as "just pick an interpretation and go." That's the actual source of review fatigue, not

At Mehran University of Engineering and Technology (MUET), Jamshoro, results are traditionally announced via large, static PDF tables. But the main issue is: Every semester, the same story. Need to check your result? Open your laptop. Connect to the university network... or set up a VPN. Want to know your actual class or batch rank? Good luck guessing. That frustration became my latest project. To solve this, I set out to build the MUET Results Portal ( https://muetresults.vercel.app )—an independent, open-source lookup engine and administrative compiler that provides students with instant semester results, CGPA calculations, batch standings, and interactive academic calendars. Here is an engineering deep-dive into how I built it using a serverless GitOps pipeline, vanilla JavaScript SPA, and Gemini AI. 🛠️ The Architecture & Data Pipeline To keep the platform hosting costs at absolute zero while maintaining lighting-fast page loads, I designed a pre-rendered static pipeline. Rather than querying a database at runtime, all student data is compiled statically. Here is the GitOps workflow: Official PDF Release : The Mehran University Examination Department publishes a new results PDF. LLM OCR Parsing : Via a secure administrative panel ( /mokshadmin ), I upload the scanned PDF/image. A serverless backend function streams the document to the Google Gemini 1.5 Flash API , which returns structured JSON student records. Git Database Update : The approved JSON records are committed back to the repository's git-tracked database ( muet_student_gpa_dataset.csv ) using the GitHub REST API. CI/CD Pre-rendering Build : The new commit triggers a Vercel build hook. Node compilation scripts read the CSV database and: Group records and compile them into static runtime JSON structures. Pre-render complete static HTML folder structures for all batch rankings and departments. Regenerate SEO sitemaps ( sitemap.xml ). Instant Deployment : Vercel serves the pre-rendered static files instan

The Linkerd community has announced the release of Linkerd 2.20, introducing a series of performance, observability, and traffic management enhancements that further strengthen the CNCF-graduated service mesh's position as a lightweight alternative for Kubernetes networking. By Craig Risi

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

Why this matters I’ve worked on a few frontend projects where code reviews turned into style debates—tabs vs spaces, semicolons, quote styles… you name it. It slows everything down and adds zero value. At some point, I realized this shouldn’t even be a discussion. So now, whenever I start a project, I set up Prettier + ESLint + Husky on day one. No debates. No manual fixes. No messy PRs. This post is exactly how I do it. 🧰 What each tool actually does Prettier → formats your code automatically ESLint → catches bad patterns & enforces rules Husky → runs checks before commits (so no one skips them) Together → clean, consistent code without thinking ⚙️ Step 1 — Install dependencies npm install -D prettier eslint husky lint-staged 🎯 Step 2 — Setup Prettier Create: prettier.config.js module . exports = { semi : true , singleQuote : true , trailingComma : ' all ' , tabWidth : 2 , }; Create: .prettierignore node_modules dist build 🔍 Step 3 — Setup ESLint Initialize: npx eslint --init Then tweak your config: .eslintrc.js module . exports = { extends : [ ' eslint:recommended ' , ' plugin:react/recommended ' , ' prettier ' ], rules : { ' no-unused-vars ' : ' warn ' , ' react/react-in-jsx-scope ' : ' off ' , }, }; 👉 Important: "prettier" disables ESLint rules that conflict with Prettier. 🔗 Step 4 — Connect ESLint + Prettier Install: npm install -D eslint-config-prettier That’s it. Now ESLint won’t fight Prettier. 🐶 Step 5 — Setup Husky Initialize Husky: npx husky init Add pre-commit hook: npx husky add .husky/pre-commit "npx lint-staged" 🚀 Step 6 — Setup lint-staged Add to package.json : "lint-staged" : { "*.{js,jsx,ts,tsx}" : [ "eslint --fix" , "prettier --write" ] } 💡 What happens now? Every time you commit: ESLint checks your code Prettier formats it Only clean code gets committed No more: “fix formatting” PR comments broken lint rules in main branch inconsistent code styles 🧠 Real impact (from experience) After adding this to a team project: PR noise dropped a lot reviews

A few weeks ago I was setting up a new project and needed to do the usual dance: create a Notion doc, spin up a Linear board, invite the team to Slack, and set up a couple of Zapier automations to connect them all. It took me most of an afternoon. That's when it hit me — I wasn't actually trying to "use" any of these tools. I just wanted the outcome. I wanted the project set up. And somewhere between the fifth Zapier trigger and the third failed webhook, I found myself thinking: why am I the one gluing all this together? That question is basically the whole thesis behind this post. AI agents aren't just a new feature category bolted onto SaaS. They're starting to eat the reason SaaS exists in the first place. The old deal: software rents you a workflow Traditional SaaS sells you a workflow, not an outcome. You pay for Notion, and Notion gives you a very nice, very rigid shape to pour your thoughts into. You pay for HubSpot, and it gives you a CRM shape. You pay for Zapier so you can awkwardly stitch the shapes together. This worked great for twenty years because the alternative was building everything yourself. SaaS was the shortcut. But the shortcut came with a tax: you had to adapt your work to fit the tool, and when you needed two tools to talk to each other, you had to become a part-time integrations engineer. The new deal: software does the workflow for you An AI agent flips that relationship. Instead of "here's a tool, go operate it," it's "here's the outcome, go figure out how to get there." You tell an agent "onboard this new client" and it can read the contract, create the folders, send the welcome email, schedule the kickoff call, and post a summary in Slack — using whatever tools it has access to, without you clicking through five different dashboards. That's the part that's easy to miss if you only think of agents as "chatbots with extra steps." A chatbot answers questions. An agent does multi-step work: It breaks a goal down into subtasks It calls tools

One of the most common questions I hear is: "My API is slow. Where do I start?" The first instinct is usually: Upgrade the server Increase CPU Add more RAM But in many cases, the database query is the real bottleneck . Whenever I investigate a slow Laravel application, I follow the same checklist. It helps me identify performance issues before making unnecessary infrastructure changes. Let's go through it. 1️⃣ Find the Slow Queries First Don't start optimizing random queries. Start with the queries that are executed the most or take the most time. Useful tools: Laravel Telescope Laravel Debugbar (development) MySQL Slow Query Log Application Performance Monitoring (APM) You can't optimize what you haven't measured. 2️⃣ Stop Using SELECT * One of the easiest improvements. ❌ Instead of: SELECT * FROM users WHERE id = 10 ; Use: SELECT id , name , email FROM users WHERE id = 10 ; Why? Less data transferred Lower memory usage Faster response Easier for MySQL to use covering indexes Only fetch the columns your application actually needs. 3️⃣ Always Check the Execution Plan Before changing anything, run: EXPLAIN SELECT id , name FROM users WHERE email = 'john@example.com' ; Things I usually look for: Is MySQL scanning the whole table? Is an index being used? How many rows are examined? Is there a temporary table? Is filesort being used? EXPLAIN often tells you exactly why a query is slow. 4️⃣ Verify Your Indexes Indexes are one of the biggest performance improvements you can make—but only when they match your queries. Example: SELECT * FROM orders WHERE customer_id = 100 ; Create an index: CREATE INDEX idx_customer_id ON orders ( customer_id ); Now MySQL can jump directly to the matching rows instead of scanning the entire table. 5️⃣ Look for Composite Index Opportunities Suppose your query is: SELECT id , total FROM orders WHERE customer_id = 10 AND status = 'paid' ; Instead of two separate indexes: customer_id status A composite index is often better: CREATE INDEX idx_cu

Getting the public IP in PHP — no dependencies, no API key PHP is still one of the most widely deployed server-side languages, running a significant share of the web's backend code. If you're building a PHP application that needs the public IP address — for geolocation, DDNS, diagnostics, or country detection — this article covers the common patterns using IPPubblico.org : free, no key, HTTPS, JSON and plain text endpoints. Use case 1 — Your server's own public IP (one-liner) The simplest case: a PHP script that needs to know its own public IP. <?php $ip = trim ( file_get_contents ( 'https://ipv4.ippubblico.org/' )); echo $ip ; // 203.0.113.42 file_get_contents works if allow_url_fopen is enabled (it is by default on most servers). If not, use cURL (see below). Use case 2 — With cURL (recommended for production) file_get_contents has no timeout control and minimal error handling. For production code, cURL is better: <?php function getPublicIP (): ?string { $ch = curl_init ( 'https://ipv4.ippubblico.org/' ); curl_setopt_array ( $ch , [ CURLOPT_RETURNTRANSFER => true , CURLOPT_TIMEOUT => 5 , CURLOPT_FOLLOWLOCATION => true , CURLOPT_SSL_VERIFYPEER => true , ]); $response = curl_exec ( $ch ); $httpCode = curl_getinfo ( $ch , CURLINFO_HTTP_CODE ); curl_close ( $ch ); if ( $response === false || $httpCode !== 200 ) { return null ; } return trim ( $response ); } $ip = getPublicIP (); echo $ip ?? 'Unavailable' ; Use case 3 — Full geolocation data When you need country, city, ISP and timezone in addition to the IP: <?php function getIPInfo ( ?string $ip = null ): ?array { $url = 'https://ippubblico.org/?api=1' ; if ( $ip !== null ) { $url . = '&ip=' . urlencode ( $ip ); } $ch = curl_init ( $url ); curl_setopt_array ( $ch , [ CURLOPT_RETURNTRANSFER => true , CURLOPT_TIMEOUT => 5 , CURLOPT_SSL_VERIFYPEER => true , ]); $response = curl_exec ( $ch ); $httpCode = curl_getinfo ( $ch , CURLINFO_HTTP_CODE ); curl_close ( $ch ); if ( $response === false || $httpCode !== 200 ) { retur

AI makes the first 80% of development feel fast, but hides architectural complexity until it's too late. To prevent system instability, engineering leaders must shift from raw throughput to systemic comprehension. By unifying spec-anchored SDD, TDD, and automated fitness functions into a repo-bound "Context Store," teams can ensure AI agents and human reviewers evolve code safely. By Stella Berhe, Stephan Bragner, Vikram Maran, Anand Jayaraman