标签：#webdev

How to handle production incidents — a step by step guide for engineers Incident Response Under Pressure When an outage hits, the goal is not to look smart in the moment; it is to restore service safely, keep people informed, and learn enough to prevent the next incident. The best teams follow a calm, repeatable process: prepare, detect and analyze, contain and recover, then review what happened afterward. Stay Calm First The first skill in incident response is emotional control. Panic makes people chase symptoms, jump between theories, and change too many things at once; calm responders slow the pace, stick to facts, and make the next action explicit. A useful rule is to pause long enough to ask: what changed, what is broken, what is the blast radius, and what is the safest next step. A simple reset phrase helps in the room: “Let’s gather signals, form one hypothesis, test it, and reassess.” That keeps the team from arguing about guesses and pushes everyone toward evidence-driven work. Debug Systematically Use a loop instead of improvisation. Start with symptoms, then check recent changes, then form a small set of likely causes, then test one hypothesis at a time, and finally verify recovery before declaring victory. During an outage, useful questions are: What is failing, and what is still working? When did it start? What changed right before it started? Is the problem isolated or widespread? What logs, metrics, traces, or user reports support each theory? Preserve evidence as you go. Avoid restarting systems, wiping logs, or making broad fixes before you understand the failure mode, because that can destroy the clues you need later. Communicate Clearly Stakeholder communication should be planned, not improvised. Good communication identifies who needs updates, what they need to know, how often they need it, and which channel you will use for each group. A practical outage update should cover four things: What happened in plain language. What the user impact is. W

Hello developers, A common issue in team workflows is configuration drift. Staging crashes because of a missing env variable, or a teammate spends hours debugging because they did not get the updated configuration. The typical workaround is sharing env files over chat apps to compare them, which is a major security risk. To solve this, I built envlint. It is an open-source tool written in pure Node.js with zero npm dependencies. How it works: - It creates a schema file (.env.schema) with key names, expected types (string, number, boolean, url, port), and defaults. - The schema contains no secrets and is committed to Git. - Developers run validation locally or in CI/CD. - It includes a diff command to compare keys across environments (e.g. .env and .env.staging). It prints key presence but suppresses all values so that terminal logs remain secure. Technical Details: - Language: JavaScript (Node.js standard library) - Dependencies: Zero - Size: Under 50KB What I learned building this: I spent a lot of time writing a custom parser in JavaScript instead of using regex or third-party parsers like dotenv. Writing a custom parser allowed me to handle edge cases like comments, multiline values, and inline types much more reliably. The project is fully open source under the MIT license: https://github.com/7xmohamed/envlint I would love to hear how you currently manage environment verification in your teams. submitted by /u/7xmohamedd [link] [留言]

Disclosure up front: I maintain one of the five libraries tested (SignalTree), and it's the one that scored worst in the cold run — so this isn't a "look how good my thing is" post. The cross-library pattern and the fix were interesting enough that I wanted to put the numbers in front of people who use Copilot/Cursor/Claude Code every day. The whole harness is reproducible (one command, link at the bottom); I'd rather it get torn apart than taken on faith. Setup Libraries : NgRx (classic), NgRx SignalStore, Akita, Elf, SignalTree. Agents : Claude Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro, Perplexity Sonar Pro, Claude Haiku 4.5, GPT-5.4-mini. 8 prompts : counter, paginated users, debounced search, derived totals, login form, undo/redo, deep nested state, multi-marker editor. 5 libs × 6 agents × 3 priming modes = 720 cells . Temperature 0. Identical prompt text per library (only the library name swapped). Scored on three orthogonal checks: idiomatic-pattern match, import resolution (does every import resolve to a real package), and method validity (do the called methods actually exist on the API). What this measures: one-shot generation. The agent gets the prompt, returns a file, we score it. Real interactive use — Cursor/Copilot with chat back-and-forth, where the model sees its own errors and gets a second try — is a different setting, and the lift could be larger or smaller there. This is the cold-shot case. Finding 1: cold accuracy basically tracks how much the library is in the training data No context provided, just "write this in library X": Library Cold score Akita 94% Elf 94% NgRx (classic) 91% NgRx SignalStore 86% SignalTree 49% The libraries that have been around for years, with thousands of blog posts and Stack Overflow answers, score in the 90s. The youngest/smallest library in the set scores ~49%. That gap isn't really a quality signal — it's a corpus signal. The models have simply seen orders of magnitude more Akita than SignalTree. Worth keeping in mind any

The Problem We Were Actually Solving I still remember the day our treasure hunt engine started to show its weaknesses. We had been using a custom-built solution written in Java, and it had served us well until our user base grew exponentially. The engine, which relied heavily on recursive searches and dynamic memory allocation, began to cause performance issues and occasional crashes. Our team was under pressure to find a solution that would allow our server to scale without sacrificing the user experience. After some research, I became convinced that Rust was the answer to our problems. Its focus on memory safety and performance seemed like the perfect fit for our needs. What We Tried First (And Why It Failed) Our first attempt at solving the problem was to simply translate our Java code into Rust. We thought that the language's built-in features would automatically solve our performance and memory issues. However, we quickly realized that this approach was not going to work. The Rust compiler was complaining about lifetime issues and borrow checker errors, which we did not fully understand at the time. We spent weeks trying to fix these issues, but our code was still not stable. I recall one particularly frustrating error message from the Rust compiler: error: cannot borrow self.list as mutable because it is also borrowed as immutable. It was then that I realized we needed to take a step back and rethink our approach. The Architecture Decision We decided to start from scratch and redesign our treasure hunt engine with Rust's strengths in mind. We chose to use a graph-based data structure, which allowed us to take advantage of Rust's ownership model and avoid common pitfalls like null pointer dereferences. We also made use of the crossbeam crate for parallelism and the tokio crate for async I/O. This new design required us to think differently about our problem domain, but it ultimately led to a more efficient and scalable solution. I was impressed by the level of

Scarab Field Test: Repairing an AI-Generated App Without Guessing Its Intended Baseline I’ve been building Scarab Diagnostic Suite around a problem I keep seeing in AI-assisted development: the app may look close, the code may be mostly there, and some checks may even pass — but the repo still isn’t in a trustworthy state. So I tested Scarab against a public GitHub repo that was explicitly asking for help with an AI-generated web app. The app had been created through a generated/vibe-coded workflow and the owner was looking for help cleaning it up, fixing broken behavior, and making it more stable. The interesting part wasn’t just “can the code be fixed?” The interesting part was: what does fixed mean for this repo? Scarab’s repair pass surfaced that there were actually two valid repair postures: TypeScript intended — treat npm run typecheck as a real acceptance gate. Build/lint only — treat the app as a generated JavaScript React export, where build + lint are the intended acceptance boundary. That distinction matters because a diagnostic suite should not blindly impose a standard the repo never chose. Sometimes the repair is not just technical. Sometimes the repair is clarifying the repo’s actual operating baseline. Both repaired versions now: build successfully lint successfully run locally in the browser render the app correctly include saved runtime evidence/screenshots pass browser smoke checks across key routes One of the more useful findings was that static checks were not enough. A governance/static pass could look clean while the browser runtime still revealed real problems: stray generated stub text, React not mounting meaningful app content, and missing local Base44 helper behavior outside the hosted runtime. That is exactly the kind of failure I’m interested in. Not just “does the code pass a command?” But: does the app actually render? does the local runtime behave? did the repair preserve the app’s intent? did the repo become more coherent afterward?

How to approach hard problems — first principles thinking for engineers First principles thinking is a powerful engineering method for solving hard problems by stripping away assumptions, reducing a system to fundamental truths, and reasoning back up to a solution from those truths. In practice, it helps you avoid cargo-cult design, debug faster, and make architecture decisions based on invariants instead of habit. What it is First principles thinking means asking: what do we know for certain, what is merely assumed, and what must be true for this system to work? Instead of copying a known pattern because it worked somewhere else, you decompose the problem into constraints, facts, resources, and failure modes, then build the simplest solution that satisfies them. For engineers, this is especially useful when the problem is novel, the stakes are high, or the decision is hard to reverse. Core method Use this loop: Define the problem precisely. List facts and constraints. Separate assumptions from evidence. Reduce the system to fundamentals. Ask why repeatedly until you hit a root cause or invariant. Rebuild the solution from those fundamentals. Test the smallest thing that can prove or disprove your reasoning. A useful engineering question is: “What must be true for this to work?” because it forces you to identify invariants before picking tools or patterns. System design example Suppose you need to design a notification service. Start with fundamentals: What is the work? Deliver messages reliably. What are the entities? Users, notifications, delivery attempts. What changes over time? Notification status, retry count, recipient preferences. What must never break? A user should not receive duplicate critical alerts, and failed deliveries should be visible. What happens under load? Queueing, retries, and backpressure become essential. From there, the architecture follows the requirements rather than fashion. If the real constraint is reliable delivery under bursty traff

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

Hello everyone, I’m trying to host a React (Vite) app on GitHub Pages and keep running into the classic SPA routing problem. Repo: [Img2Num GitHub repo]( https://github.com/Ryan-Millard/Img2Num/ ) Live site: [Img2Num GitHub Pages]( https://ryan-millard.github.io/Img2Num/ ) The app is bascally a small landing page for the project that shows an example of how the library can be used, but it uses React Router (BrowserRouter). Everything works fine when navigating inside the app, but: - Refreshing any route other than / results in a 404 - Directly visiting a nested route also 404s - GitHub Pages clearly doesn’t handle SPA fallback routing Many people have suggested these: - Use HashRouter - Add a 404.html fallback hack - Switch to another host (e.g., Clouflare Pages) but I don't like those options because they are either not well-structured and SEO-friendly, not a complete solution, or make it harder to test global support (Cloudflare Pages allows special headers for things like pthreads that GitHub Pages and many other JS setups don't support). What I’m trying to do instead is something like static site generation (SSG) as it would likely be the cleanest fix - similar to how Docusaurus or Astro handles this: - Pre-render routes at build time - Serve static HTML for /, /docs, etc. - No client-side routing dependency for initial load - Better SEO and no refresh issues This saves use from needing to have a fancy backend. When I try setting up SSG with Vite & React, I end up failing I've tried things like `vite-plugin-ssg`, but run into strange behaviours and errors that I cannot seem to be able to fix (e.g., an incompatible dependency that, also breaks when downgraded). I don’t fully understand the correct architecture for multi-route SSG in a React SPA setup. --- What is the correct modern approach for this and is there a recommended way to keep React & Vite, deploy to GitHub Pages, get proper multi-route support without hash routing, and avoid SPA 404 refresh issues ent

Hi ! I would like to know, for all the freelancer, how do you find clients ? submitted by /u/Klutzy-Badger-2778 [link] [留言]

A new verification step submitted by /u/mikeplus10 [link] [留言]

Genera la tua prima fattura elettronica XML per lo SDI in TypeScript (in 10 minuti) Se hai mai dovuto integrare la fatturazione elettronica italiana in un progetto Node.js, sai già quanto è scomodo: specifiche FatturaPA di 200 pagine, regole cross-field non documentate, codici errore SDI criptici, e librerie npm o abbandonate o in PHP. Questo articolo mostra come generare un XML valido per il Sistema di Interscambio (SDI) usando fattura-elettronica-sdi-builder , una libreria TypeScript open-source che copre B2B (FPR12) e Pubblica Amministrazione (FPA12). Installazione npm install fattura-elettronica-sdi-builder Nessuna dipendenza pesante. La validazione è custom e tipizzata, zero runtime esterni. Il flusso in tre funzioni La libreria espone tre funzioni pubbliche che si usano sempre in sequenza: import { applyDefaults , validate , buildXml } from ' fattura-elettronica-sdi-builder ' ; Funzione Input Output applyDefaults(input) FatturaElettronicaInput (campi deducibili opzionali) FatturaElettronica completa validate(fattura) FatturaElettronica Result<void, ValidationError> buildXml(fattura, options?) FatturaElettronica Result<string, BuildError> Tutte le funzioni restituiscono un Result<T, E> — mai eccezioni non gestite: type Result < T , E > = | { ok : true ; value : T } | { ok : false ; error : E } Esempio completo: fattura B2B con IVA ordinaria Genera una fattura TD01 da una Srl italiana a un cliente italiano, IVA al 22%, pagamento con bonifico. import { applyDefaults , validate , buildXml } from ' fattura-elettronica-sdi-builder ' ; import type { FatturaElettronicaInput } from ' fattura-elettronica-sdi-builder ' ; import { writeFileSync } from ' fs ' ; const input : FatturaElettronicaInput = { FatturaElettronicaHeader : { DatiTrasmissione : { ProgressivoInvio : ' 00001 ' , CodiceDestinatario : ' ABC1234 ' , // 7 caratteri per FPR12 }, CedentePrestatore : { DatiAnagrafici : { IdFiscaleIVA : { IdPaese : ' IT ' , IdCodice : ' 01234567890 ' }, Anagrafica : { Denominaz

I'm a maxillofacial surgeon in Ouagadougou, Burkina Faso — and a self-taught builder who's been coding since medical school. Over evenings and weekends, I shipped Readium — a production AI reading app that lets you discuss books with Claude while you read them, in any language. Built AI-paired with Claude, reviewed and deployed by me. Most "I shipped an AI app" write-ups cover the happy path: clone a starter, glue an LLM, deploy to Vercel. The walls I hit weren't there. They were in the spaces between the libraries. Here are five of them — and what I'd tell myself a few weeks ago. Wall 1 — SSE streaming broke at the seam between the LLM and the browser I assumed streaming "just worked" once OpenRouter returned a stream. It does — until your server-side handler, your reverse proxy, or your browser code introduces a buffer somewhere along the path. The chain has at least three places where buffering can silently kill streaming: The LLM API (fine on its own) Your Node server-side handler (fine if you forward chunks instead of accumulating them) The reverse proxy / CDN (often buffers entire responses by default) The failure mode is always the same: the UI looks exactly like the LLM is slow. It isn't — somewhere between OpenRouter and the browser, bytes are being withheld until the connection closes, then dumped in one chunk. What I'd tell past-me: streaming isn't a feature of the LLM, it's a property of your entire request path. If you can't watch tokens land character-by-character in curl -N against your origin, you don't have streaming, you have a slow non-stream pretending. Set Cache-Control: no-transform and X-Accel-Buffering: no headers from your handler, disable response buffering on every layer in front of it, and verify with curl -N before you trust the UI. Wall 2 — fetch hangs forever on certain hosts (and the fix isn't where you think) I had a proxy route that fetched from an external API. Worked locally. Worked in staging. Deployed to production: the route wo

I have a PHP and MySQL website that I built myself and I want to make an app for my website. I am currently running an app with website2native app or hybrid if you know what that is. Do you recommend me learning a language like Dart to make apps or should I focus on PHP? submitted by /u/FarrisFahad [link] [留言]

Question from the title. For years and years I have a recognizable style of making UI and I have experienced that people think that those applications/sites were generated by AI even though this is not true, and some applications were made before gpt 3.5 and before the commercialization of LLM. I have always tried to make the design look modern and the fact is that LLMs were trained in such a style and that is why we come to such a problem. submitted by /u/Excellent-Article937 [link] [留言]

Hello, How can I implement a component overlay, like a dropdown or popover, so it escapes its parent container instead of being clipped, hidden, or expanding the parent layout? I managed to do it with getBoundingClientRect(), store the position in state and apply it as fixed positinioning. Even though it seems to work, wonder if there is a better solution. Thank you. submitted by /u/prois99 [link] [留言]

Im a beginner trying to create a website for my luxery home staging business. I tried using templates in canva but hate how generic it looks and find it very limiting Is there a better way ro use canva? What combination of tools would help me create an editorial style website. Would be nice if there were some AI tools i could use in conjunction to make some of the work easier . submitted by /u/Grand_Respect_9176 [link] [留言]

A practical 5-10 minute checklist for vetting npm dependencies before adding them to production. It focuses on provenance attestations, install scripts, CI quality signals, maintainer responsiveness, and security handling. submitted by /u/OtherwisePush6424 [link] [留言]

Hello Dev Community 👋 I recently built my first web project called Namastra — a simple tool to explore the meanings, origins, and insights behind names. 👉 Live Demo: 💡 Why I built this I noticed that many people are curious about: What their name means Where their name comes from What personality or cultural meaning it carries But most websites are: Too slow Full of ads Hard to navigate So I decided to build something simple, fast, and clean. ⚙️ What Namastra does With Namastra, users can: 🔍 Search any name instantly 📖 Get meaning and origin 🌍 Learn cultural background ⚡ Use a clean and fast interface 🛠️ Tech Stack I built this project using: HTML CSS JavaScript GitHub (version control) Netlify (deployment) Hosted here: [Netlify] Code managed via: [GitHub] 🚧 Challenges I faced As a beginner developer, I faced challenges like: Designing a clean UI Making search functionality smooth Deploying with GitHub + Netlify Structuring data properly But I learned a lot through building it step by step. 🎯 What I learned How to build and deploy a full project How important UI simplicity is How real users think differently than developers How deployment pipelines work (GitHub → Netlify) 🚀 Future improvements I plan to add: More name data Better UI design Categories (religion, origin, country) Possibly AI-based name insights 🙌 Feedback welcome This is my first real web project, so I’d really appreciate your feedback and suggestions. Try it here: 👉 Thanks for reading ❤️ Happy coding!

I like to make userScripts and userStyles for myself. I've begrudgingly dealt with Shadow DOM here before, and it's nothing but a pain in the ass. However, now I'm seeing a userStyle that I'm trying to apply being removed immediately as it's applied (using Stylus). What is the mechanism behind this? Other styles from the same style sheet are still being honored. The element still has the same root, and is still be matched by the rules's selector. What might be the way this is achieved? https://youtu.be/YgbOrfel604 (Chromium 124.0.6367.61 (Official Build) (64-bit)) submitted by /u/svArtist [link] [留言]

Most indie hackers I know spend an embarrassing amount of time on the naming part. We argue with ourselves over the perfect .com, eventually settle for some janky combo of words with random consonants ripped out, and ship a domain we secretly don't love. There's a quieter option a lot of builders haven't seriously considered: .Vegas. It's a geographic TLD, but it does NOT require you to be in Las Vegas or build anything Vegas-related. What it does give you is a TLD that sounds bigger than it costs, reads as memorable, and is still wide open in 2026. I went down a small rabbit hole this week looking at side-project ideas that would have an almost unfair head start on .Vegas. Here are five. 1. A weekend trip planner Domain: weekend.vegas or trip.vegas This is the lowest-hanging fruit and I'm honestly surprised nobody's built it yet. A tiny webapp that takes a Friday-to-Sunday window and spits back a fully booked itinerary: flight, hotel, two restaurant reservations, one show, one activity. Three clicks, done. Why it works on .Vegas: the domain is the elevator pitch. Nobody needs to read your tagline. The URL bar tells you what the product does. That's worth more than most landing-page copy will ever earn. 2. A bachelor/bachelorette party coordinator Domain: bach.vegas , party.vegas , last.vegas Group-trip coordination is genuinely awful. Splitwise + a group chat + a shared Notion doc + that one friend who keeps forgetting to Venmo back. There's room for a niche product here that handles the deposit splits, the "who's in for the cabana" upsells, and the inevitable last-minute flight changes. Why it works on .Vegas: the URL doubles as a tagline. You don't have to explain what kind of trip it's for. 3. A booking aggregator for shows and residencies Domain: shows.vegas , tonight.vegas Caesars, MGM, Live Nation, AXS, Vivid Seats, the venue's own ticketing system — finding a good show on a specific Tuesday night is a pain. A scraper-backed booking aggregator that's honest a